深入理解网络原理3----TCP核心特性介绍（上）【面试高频考点】

文章目录

前言
TCP协议段格式
一、确认应答【保证可靠性传输的机制】
二、超时重传【保证可靠性传输的机制】
三、连接管理机制【保证可靠性传输的机制】
- 3.1建立连接（TCP三次握手）---经典面试题
- 3.2断开连接（四次挥手）
- 3.3TCP状态转换
四、滑动窗口
五、流量控制

前言

随着时代的发展，越来越需要计算机之间互相通信，共享软件和数据，即以多个计算机协同⼯作来完成业务，就有了⽹络互连。

TCP协议段格式

在这里插入图片描述

一、确认应答【保证可靠性传输的机制】

确认应答，这是保证“可靠性”最核心的机制。

发送方发完数据之后，接收方收到数据就会返回一个应答报文ACK,每⼀个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下⼀次你从哪⾥开始发。发送方看到应答报文，就知道上个数据传输成功了。

如何解决“先发后至”问题？
引入序号和确认序号，区分出数据的顺序，接收方会按照序号把数据重新排序，确保应用程序read到的数据的顺序和发送顺序一致。

在这里插入图片描述

二、超时重传【保证可靠性传输的机制】

在网络传输中，丢包是一个普遍情况，无法预测哪个包会丢，也无法预测什么时候丢。
发送方如果一段时间之内，没有收到ACK应答报文（发的消息本身丢包），就会视为丢包，触发重传，通过重传操作，可以大幅度提升数据包到达对面的概率，但是重传也不是立即重传，数据在网络传输过程中，是需要时间的，等到达到超时时间（往往是一个ms甚至s级的数据）之后，再进行重传。
当前传输的数据，如果是数据到了，ACK丢了也会触发超时重传，此时可能导致接收方收到了重复的数据。TCP协议需要能够识别出哪些包是重复的包, 并且把重复的丢弃掉,这时候我们可以利⽤前⾯提到的序列号, 就可以很容易做到去重的效果。超时时间也不是固定数值，会随着重传的次数增加而增加（重传频率越来越低）。

在这里插入图片描述

那么, 如果超时的时间如何确定?
• 最理想的情况下, 找到⼀个最⼩的时间, 保证 “确认应答⼀定能在这个时间内返回”.
• 但是这个时间的⻓短, 随着⽹络环境的不同, 是有差异的.
• 如果超时时间设的太⻓, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁发送重复的包;
TCP为了保证⽆论在任何环境下都能⽐较⾼性能的通信, 因此会动态计算这个最⼤超时时间.
• Linux中(BSD Unix和Windows也是如此), 超时以500ms为⼀个单位进⾏控制, 每次判定超时重发的
超时时间都是500ms的整数倍.
• 如果重发⼀次之后, 仍然得不到应答, 等待 2500ms 后再进⾏重传.
• 如果仍然得不到应答, 等待 4500ms 进⾏重传. 依次类推, 以指数形式递增.
• 累计到⼀定的重传次数, TCP认为⽹络或者对端主机出现异常, 强制关闭连接.

三、连接管理机制【保证可靠性传输的机制】

3.1建立连接（TCP三次握手）—经典面试题

客户端执行，socket=new Socket(serverlp,serverPort);这个操作就是在建立连接；上述只是调用socket api，真正建立连接的过程，是在操作系统内核完成的。
在这里插入图片描述
内核是怎样完成上述“建立连接”过程的呢？
客户端是主动的一方，第一次交互，一定是客户端主动发起的。
所谓的syn是一个特殊的TCP数据报：
①它没有载荷，不会携带应用层数据，但是也会带有IP报头、以太网数据帧帧头、TCP报头…；
②六个标志位中第五位（SYN）为1。
服务器收到syn之后，会返回ack（确认应答），语义就是收到。接下来服务器还会返回syn，这个syn的语义就是愿意和你建立连接。最后客户端也要返回ack。
在这里插入图片描述
下面这张图非常重要=

所谓建立连接的过程，本质上就是通信双方各自给对方发起一个syn，各自给对方回应一个ack。就是为了让通信双方保存对方的信息。

建⽴连接（TCP三次握手）的意义:
1. 投⽯问路, 确认当前通信链路是否畅通，以及检验每个主机的发送能力和接收能力是否正常。

eg.玩家A和玩家B尝试连麦打游戏2. 协商参数, 通信双⽅共同确认⼀些通信中的必备参数数值，使客户端和服务器使用相同的参数进行消息传输。

Q：TCP为啥是三次握手？四次可不可以？两次可不可以？(经典面试题)
A:三次握手是为了确保双方建立起可靠的连接，并且在通信过程中能够进行可靠的数据传输。第一次握手是客户端向服务器发送请求连接的报文段，第二次握手是服务器接收到请求后确认连接，并向客户端发送确认报文段，第三次握手是客户端接收到确认后再次向服务器发送确认报文段，双方完成连接。
四次握手理论上也可以实现可靠的连接，但是通常情况下三次握手已经足够满足连接的可靠性要求，所以四次握手会增加连接的建立时间和网络负担，没有必要。
两次握手并不安全，因为服务器这边无法确认自身的发送能力对端的接收能力是否正确，此时就缺少了“可靠传输”前提，因此客户端必须再来一次握手普，把上述信息同步给服务器，否则无法确保连接双方都已经准备就绪，容易造成数据的丢失或混乱，所以通常不采用两次握手方式。
因此，三次握手是为了在保证连接可靠性的前提下，最大限度地减少连接建立的时间和网络负担，是一种合理且有效的方式。

3.2断开连接（四次挥手）

断开连接的本质目的，就是为了把对端的信息，从数据结构中给删除掉/释放掉。
四次挥手，不一定得是客户端先发fin，服务器也可能先发fin,关键看代码如何写，调用socket.close()就会触发FIN(FIN也是内核负责完成），如果进程直接结束，也会触发FIN，关闭socket文件，结束进程，也会关闭文件。
在这里插入图片描述

在这里插入图片描述
Q:TCP三次握手与四次挥手的相似之处和不同之处？
A：相似之处---都是通信双方各自给对方发起一个syn/fin，各自给对方返回ack，

3.3TCP状态转换

TCP客户端和服务器都要有一定的数据结构来保存这个连接的信息，在这个数据结构中其中就有一种属性叫做“状态”，操作系统内核根据状态的不同，决定了当前要做什么。

几个重要状态如下：
在这里插入图片描述

TIME_WAIT
想⼀想, 为什么是TIME_WAIT的时间是2MSL?
• MSL是TCP报⽂的最⼤⽣存时间,因此TIME_WAIT持续存在2MSL的话
• 就能保证在两个传输⽅向上的尚未被接收或迟到的报⽂段都已经消失(否则服务器⽴刻重启, 可能会收到来⾃上⼀个进程的迟到的数据, 但是这种数据很可能是错误的);
• 同时也是在理论上保证最后⼀个报⽂可靠到达(假设最后⼀个ACK丢失,那么服务器会再重发⼀个 FIN. 这时虽然客⼾端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

CLOSE_WAIT
⼀般⽽⾔，对于服务器上出现⼤量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥⼿没有正确完成.这是⼀个 BUG. 只需要加上对应的 close 即可解决问题.

四、滑动窗口

这是TCP中非常有特点的机制。能提高传输效率，快速重传，处理丢包的情况。
确认应答，超时重传，连接管理==>确保可靠传输，但是也付出了代价——传输效率，单位时间内，能传输的数据量变少了。
因此，我们希望保证可靠传输的前提下，能够让效率尽量高一些，让消耗的时间成本尽可能少一些。滑动窗口的提出就解决了上述问题。注意这里的提高效率其实是降低损失，而不是增加速度。

⼀发⼀收的⽅式性能较低, 那么我们⼀次发送多条数据, 就可以⼤⼤的提⾼性能(其实是将多个段的等待时间重叠在⼀起了)。
在这里插入图片描述

• 窗⼝大小指的是⽆需等待确认应答⽽可以继续发送数据的最⼤值. 上图的窗⼝⼤⼩就是4000个字节 (四个段).
• 发送前四个段的时候,不需要等待任何ACK, 直接发送; • 收到第⼀个ACK后, 滑动窗⼝向后移动, 继续发送第五个段的数据; 依次类推;
•操作系统内核为了维护这个滑动窗⼝, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
•窗⼝越⼤, 则⽹络的吞吐率就越⾼;

请添加图片描述

滑动窗口，要保证可靠性是前提，那么如果出现了丢包, 如何进⾏重传? 这⾥分两种情况讨论。
情况⼀: 数据包已经抵达, ACK被丢了。
这种情况下，无需进行任何处理，除非是所有的 ACK 都丢失了（网络出现重大故障），否则只是出现一部分 ACK 的丢失，对于可靠性传输没有任何影响，也不需要进行重传。

情况⼆: 数据包就直接丢了。
这里的重传做到了“针对性”重传，哪个丢了就重传哪个，已经收到的数据，是不必重复发送的，整体的效率没有额外损失，这种机制被称为 “⾼速重发控制”(也叫 “快重传”)
确认应答，超时重传；滑动窗口，快速重传；这两者并不冲突，而且是同时存在的，滑动窗口中也有确认应答。只不过等待策略稍作调整，转成批量的，批量的前提是短时间发送了很多数据，如果通信双方大规模传输数据，用滑动窗口，按照快速重传保证可靠性，此时判定丢包的标准就是看连续有多个ack索要一个数据。如果通信双方传输数据规模较小，用超时重传。仍按照超时重传保证可靠性，此时判定丢包的标准就是达到超时时间还没有ack到达。

五、流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继⽽引起丢包重传等等⼀系列连锁反应。因此TCP⽀持根据接收端的处理能⼒, 来决定发送端的发送速度.。这个机制就叫做流量控制(FlowControl)。
• 接收端将⾃⼰可以接收的缓冲区大小放⼊ TCP ⾸部中的 “窗⼝大小” 字段, 通过ACK端通知发送端;
• 窗⼝大小字段越⼤, 说明⽹络的吞吐量越⾼;
• 接收端⼀旦发现⾃⼰的缓冲区快满了, 就会将窗⼝大小设置成⼀个更小的值通知给发送端;
• 发送端接受到这个窗⼝之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗⼝置为0; 这时发送⽅不再发送数据, 但是需要定期发送⼀个窗⼝探测数据段, 使接收端把窗⼝大小告诉发送端。
在这里插入图片描述
接收端如何把窗⼝大小告诉发送端呢?
TCP⾸部中, 有⼀个16位窗⼝字段, 就是存放了窗⼝大小信息;通过这个字段来给发送方反馈发送速度，这个字段要在ack报文中才有意义。通过这个大小反馈给发送方接下来要发送的窗口设置成多少合适。接收方会按照自己接收缓冲区剩余空间的大小，作为ack中的窗口大小的数值，下一步发送方就会根据这个数值来调整自己的窗口大小。
那么问题来了, 16位数字最⼤表⽰65535, 那么TCP窗⼝最⼤就是65535字节（64KB）么?
实际上, TCP⾸部40字节选项中还包含了⼀个窗⼝扩⼤因⼦M, 实际窗⼝大小是窗⼝字段的值左移 M 位。