TCP协议、TCP报文首部格式、三次握手四次挥手、流量控制、拥塞控制、滑动窗口

旧城等待， 2023-03-02 10:53 102阅读 0赞

### 一、定义 ###

背景：

> TCP协议工作在运输层，下层的网际层，核心是IP协议，是一个不可靠的协议，因为他只是保证了数据能正确从源主机到达唯一的确定目的主机，但是传输的内容是不是被破坏，是不是按照正确顺序，没有进行处理，所以运输层的TCP协议在使用网际层的IP协议提供的服务同时，还要解决这个不可靠的问题。

TCP协议，Transmission control protocol，传输控制协议。

是一种可靠的运输层协议：他是**面向连接的**、**基于字节流**的协议。

1.  **基于字节流**：TCP协议将应用层的数据只看成一连串的字节流，将他们编号并存储在自己的发送缓存中，根据策略，每次从中拿出一部分构建成TCP报文；接收方也是一样，一遍将收到的报文拆开放进自己的缓存中，一边拿出字节流给上方应用层。这个过程中双方字节流内容是完全一致的。
2.  **面向连接**：在通信之前，通信双方必须进行三次握手、建立TCP连接，建立成功之后才能进行数据传输、数据传输结束要进行四次挥手，释放连接。
3.  TCP显然**只支持单播**（一对一的通信），逻辑上来看就像是通信双方建立一个专属的传输通道。

尽管网际层的IP协议并不可靠，但是由于使用TCP协议，确保了报文不会出现误码、丢失、乱序、重复等问题，所以说他是可靠的。

### 二、TCP报文的首部格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70]  
（*Ref： https://blog.csdn.net/qq\_32998153/article/details/79680704*）

TCP的协议的功能在首部的各个字段里都有体现，上面的字段解释如下：

1.  **源端口**：用来标识发送这个报文段的应用进程；（每一个计算机自己有端口号就能确定进程，不同计算机在交互过程，利用IP地址+协议+端口号唯一标识去标识网络中的一个进程，这种唯一标识的模式称为Socket）
2.  **目的端口**：标识接受这个报文段的应用进程；
3.  **序号（Seq）**：这个序号指出这个报文段的序号，TCP连接中传送的字节流中的每个字节都**按顺序编号**；
4.  **确认号（ACK）**：指出**期望**收到下一个报文段的序号，也起到了对前面发来的数据的确认，代表序号续上了；
5.  **数据偏移**：指出报文段的数据部分离起始多远（其实也就是指出这个报文段的头部多长，因为有可变部分）；
6.  **保留**：保留给今后使用的；
7.  **四个短标志位**：
    
     *  **URG**：紧急指针；
     *  **ACK**：确认标志位，1是说明确认号有效；（tcp规定连接建立后所有报文段的这个标志位都是1）
     *  **PSH**：推送标志位，如果是1就会尽快上交应用进程而不是等到接受缓存填满；
     *  **RST**：重置连接标志；
     *  **SYN**：同步标志位，用来同步序号；
     *  **FIN**：终止标志位，用来释放TCP连接。
8.  **窗口**：指出发送这个报文段的那一方的接收窗口，就是接收方用自己的接受能力提示发送方的发送能力，这就是**流量控制**的核心；
9.  **检验和**：检查整个报文段，**判断是否出错**（奇偶校验）；
10. 紧急指针：只有段标志位里面的URG为1的时候这段才有效；
11. 选项：增加功能的地方，定义其他内容；
12. 填充：由于选项是长度不定的，填充部分保证整个长度是能被4整除的，因为数据偏移位是以4位单位。

### 三、TCP的流量控制和乱序重排（滑动窗口） ###

流量控制指的是，希望发送方不要发数据发太快，让接收方能来得及，这也是TCP可靠性的一个保障。

##### 3.1 流量控制： #####

滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的**允许发送的帧的序号**，**称为发送窗口**；同时，接收方也维持了一个连续的允许接收的帧的序号，称为**接收窗口。**

采用滑动窗口机制来进行流量控制，是**接收方**用自己的窗口大小，去**限制发送方**发送数据的大小，从而进行流量控制，体现在报文段里就是上一节提到的窗口字段。

对于发送方而言：

*  当收到新的确认之后，说明可以继续发送了，那么慢指针就可以向前移；
 *  快指通常是不断向前移动的，但是没有收到确认，或者收到了但是又通知窗口缩小，那就不动，这样慢指针的移动就能起到窗口总容量变小的作用。

注意理解，双方都有窗口，但是主要是接收方通过自己的接受能力，来限制发送方的发送速度。这是流量控制。

##### 3.2 乱序重排 #####

对于没有按顺序到达的报文，TCP没有明确的规定，但是一般的做法是：

（乱，说明后面的先来了，应该先来的还没来）将没有按序到达的数据都**临时存放在接收窗口**，等到所有的字节流中缺少的部分都收到了，那么就把他们**排序**，接上之前的顺序交付给上层的应用进程。主要依赖于首部的序号和确认号字段，来保证顺序。

### 四、TCP的拥塞控制 ###

早期的TCP实现是没有拥塞窗口的，发送方会一次将接收方所建议的数据长度，也就是滑动窗口都发过去。

但是随着发展，网络越来越复杂，某一时间段，如果对网络中某一个资源的请求超过了能提供的可用部分，就会导致性能变差，就是发生了拥塞。如果发生拥塞不处理，就会是的整个网络吞吐量为0，实际上也是一种死锁。

因此仅仅采用流量控制的滑动窗口已经不够了，采用了**拥塞窗口**代表着发送方的成熟，不再是人云亦云（接收方说发多少就发多少），这种机制和前面流量控制里的滑动窗口机制一起在控制传输的速度。

最开始，拥塞窗口的基本原则是，没有拥塞，那就尽量大一点，如果有拥塞了，就缩小，判断依据是，**有没有发生超时重传**。

> 简单来说，就是TCP的发送方虽然收到了接收方的**建议数据长度**，但是TCP发送方也不知道**传输路径**负载能力如何。  
> 因此TCP的发送方开始只发一小段数据，当收到了ACK之后，再增加每次发送的数据，直到达到接收方的处理能力上限或者传输路径的负载能力上限。  
>   
> 有点类似摸着石头过河。发送方每次发送的数据长度，就是拥塞窗口的大小。

TCP的拥塞控制主要由**四个算法**，协助窗口大小的修改来进行拥塞控制。

##### 4.1 慢开始 #####

慢开始就是，开始发送数据的时候因为不知道网络情况，所以先试探。

维护一个拥塞窗口 cwnd，开始的时候发送方将拥塞窗口作为发送窗口的大小，swnd=cwnd，同时还维护一个慢开始门限 ssthresh 。

*  当 cwnd<ssthresh 时，使用慢开始算法；
 *  当 cwnd>ssthresh 时，使用拥塞避免算法；
 *  等于的时候，随意。

慢开始指，一开始向网络注入的**报文段少**，**不是拥塞窗口 cwnd 的增长速度慢**，（事实上速度是所有阶段最快的）。

##### 4.2 拥塞避免 #####

让cwnd缓慢的增大，按照**线性规律**，而不是加倍，这样拥塞窗口cwnd比慢开始算法的拥塞窗口增长速率缓慢的多。

无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把**慢启动开始门限（ssthresh）设置为发送窗口的一半**，再重新开始。这样的目的是，能给网络一个空闲时间把堆积的数据处理完毕。

下面这个图看起来就更加直观：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 1]  
（*Ref： https://blog.csdn.net/m0\_37962600/article/details/79993310*）

就是这样一种简单思路：开始少，那么如果没问题，就保持增长飞速，到达门限ssthresh后为了防止拥塞就变为线性慢增长，一旦出现超时重传，代表拥塞了，那重新开始，继续慢开始-拥塞避免……

##### 4.3 快重传 #####

上面两种算法有明显的缺陷，那就是如果，网络没有拥塞，而是因为某一条报文丢失，引起了超时重传，这样直接重新开始慢开始算法，就会降低效率。

所以后来，TCP的拥塞控制又加入了**快重传**和**快恢复算法**。

快重传算法是这样的：

*  要求接收方，不要等到自己发送数据的时候再捎带确认，而是收到数据就**立即发送确认**给发送方；
 *  即使收到了失序的报文段，也要立即发送确认，不过不是发这个乱序报文的确认，而是发前面的**重复确认**；
 *  等到发送方连续收到三个重复确认，就知道后面的乱了，就会**立即重传**，而不是等超时重传，这样也就不会导致多余的慢开始。

##### 4.4 快恢复 #####

接上面的快重传算法，如果发送方收到了3个连续重复确认，那么就知道只是丢失了个别报文段，立即执行的就是**快恢复**算法：

*  将慢开始门限 ssthresh 和**拥塞窗口** cwnd 值**调整为当前窗口的一半**；
 *  **继续执行拥塞避免**算法。

使用快恢复，而不是重新来一轮慢开始。

如下图所示，结合了四种算法的TCP拥塞控制，过程曲线其实是这样的：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 2]  
（*Ref： https://blog.csdn.net/m0\_37962600/article/details/79993310*）

下面废弃的虚线部分，就是没有后面两种算法的旧版本，实际的曲线是实线部分。

### 五、TCP的超时重传 ###

TCP超时重传的方式是为每一个连接都创建计时器，有4个计时器：

1. 重传计时器：Retransmission Timer
    2. 坚持计时器：Persistent Timer
    3. 保活计时器：Keeplive Timer
    4. 时间等待计时器：Timer_Wait Timer

##### 5.1 重传计时器 #####

当TCP**发送报文段时**，就创建该特定报文的重传计时器。

*  如果计时器到点儿之前收到了确认信息，那撤销；
 *  否则，要重新发送，计时器复位。

这个计时器解决的问题是 **避免无限等待确认报文**。

##### 5.2 坚持计时器 #####

当接收端窗口大小为0时，发送端停止了发送，此后如果接收端有空余了，则发送一个新窗口大小的报文。可是如果这个报文丢失了，则导致双方都处于等待状态，产生死锁。

坚持计时器就是解决这个问题的：

*  当发送端**接收到**接收端发送的**零大小窗口的报文**时，就启动坚持计时器；
 *  当计时器到点了，发送端就主动发送一个报文段告诉接收端，他发送的新窗口大小的报文丢失了，需要重新发送。

##### 5.3 保活计时器 #####

如果说，一个客户端连接服务器后一直没有请求，而且也没有发送断开连接的请求，那么就会占用很长时间的资源。保活计时器就是解决这个问题的。

*  当**服务器收到数据时**都**将保活计时器重新设置**（一般2h）；
 *  保活计时器到点儿后，服务器如果没有收到数据，每隔75s发送一个探测报文给客户端，当连续发送10次后，仍然没有收到客户端的回复，则服务器主动断开连接（这种连接的断开当然不会使用四次握手，而是直接硬性的中断和客户端的TCP连接。）

##### 5.4 时间等待计时器 #####

时间等待计时器是在**四次挥手的时候使用**的。Time\_wait状态，而**时间等待计时器就是Time\_wait状态的持续时间**，具体看下面的三报文握手和四报文挥手。

##### 5.5 超时重传时间RTO的选择 #####

那么，TCP的超时重传很容易理解，就是为了避免一些无限等待导致的死锁问题，等等，会采用定时器来进行超时之后重传的策略，保证可靠性。

最核心的是超时时间的选择。

实际中RTO是根据网络中的**RTT（传输往返时间）来自适应调整的。采用特定的计算方式**。（个人觉得不用记详细公式了）

比如 5.1的重传计时器一般重传时间是 2\*RTT.

### 六、TCP的三报文握手、四报文挥手（运输连接管理） ###

运输连接的创建和释放是每次通信不可少的环节，因为TCP就是面向连接的协议，运输链接一般有如下三个阶段：

1.  建立连接，三报文握手；
2.  数据传输，基于已经建立好的连接进行可靠传输（全双工通信）；
3.  释放连接，数据传输结束后四报文挥手释放连接。

##### 6.1 三报文握手 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 3]  
（*Ref： https://blog.csdn.net/qzcsu/article/details/72861891*）

如图所示：

解释一下里面的英文：

*  里面起到作用的一些标志位就是TCP报文首部里的内容，ACK确认标志位，SYN同步标志位，ack确认号；
 *  两端的状态CLOSED 就是连接关闭状态，LISTEN状态就是监听状态，SYN-SENT就是同步已发送状态，SYN-RCVD就是同步已接受状态，ESTABLISHED就是连接已建立状态。

三报文挥手的过程如下：

1.  **客户端发送连接请求**：头部SYN=1，表明这是一个TCP连接请求报文段，序号seq有一个初始值，作为TCP客户进程选择的初始序号。（SYN=1的报文是不能携带数据的）
2.  **服务器发送针对收到的连接请求的确认**：头部SYN=1，确认位ACK=1，表明是一个TCP请求确认报文段，seq设定初值y，作为服务器进程选择的初始序号，确认号字段ack=x+1，是对刚才客户端的x的确认（不能携带数据）
3.  **客户端发送针对请求确认的确认**：发送一个普通的TCP确认报文段，进入连接已建立状态。这个报文的ACK设为1，表明是一个TCP确认报文段，seq=x+1是继续发送的序号，确认号字段ack=y+1是对上一个发出去的y的后续。

随后，服务器收到了客户端的3，那么就开始进入已建立状态，通信开始了。

简单来说，三个报文分别是，**请求-请求确认-请求确认确认**（禁止套娃）

**为什么不是两次握手，而是三次？**

主要是防止客户端发出的已经失效的连接请求报文段，又发送到了服务器，从而导致错误，白白浪费资源。

具体情况是

1.  C发请求，某些原因没到S；
2.  C又发，到了S，这个时候因为没有三握手，两报文后，建立了正常通信，完了结束通信，两边连接都关闭了。
3.  C的第一条请求到了S，S又给了回应，因为是两握手，S觉得只用等C发请求就可以了，S是established状态，结果C是closed，白白浪费服务器资源。

##### 6.2 四报文挥手 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 4]  
（*Ref： https://blog.csdn.net/qzcsu/article/details/72861891*）

状态有所不同，是从连接建立状态变为closed状态的过程。  
解释一下：

*  里面起到作用的一些标志位是TCP报文首部里的内容，FIN终止标志位，其他的序号字段和变化不用再解释；
 *  FIN-WAIT-1是终止等待1，CLOSE-WAIT是关闭等待，FIN-WAIT-2是终止等待2，LAST-ACK是最后确认，TIME-WAIT是时间等待。

四报文挥手的过程如下：

1.  **客户端发送连接释放报文段**，进入FIN-WAIT1；
2.  **服务器**收到连接释放报文段后，**发送一个TCP确认报文段**，并**进入关闭等待CLOSED-WAIT状态**，此时服务器通知高层应用进程，客户端要释放连接了，有剩的数据赶紧发，如果有剩的，那还会继续进行数据传输。这个时候客户端还是要收这些数据，记为FIN-WAIT2，TCP连接属于客户端到服务端的半关闭状态；
3.  **服务器发出TCP连接释放报文段**（代表服务端的应用进程没有数据要发了），发完连接释放报文段，服务器进入LAST-ACK最后确认状态。
4.  **客户端**收到了这个连接释放报文段，知道了服务端也做好准备要释放连接了，就**发送一个TCP确认报文段**，（服务端收到这个后就CLOSED了），客户端同时进入TIME-WAIT时间等待状态，等待2倍的MSL（最长报文寿命）后，进入ClOSED。

总结一下，和三报文握手类似，也是**C先请求，S回应，C再确认**，不过中间**多了一个S返回没有发完的数据、同时C进行fin-wait2的状态**，为了保证数据传输完。

**为什么最后一次发过去ACK，客户端不直接关闭，还要进入TIME-WAIT，再等2倍的MSL呢？**

因为：如果最后一个ACK发过去失败了，那显然服务端没收到，就不能进入closed，此时服务端会重发上一条FIN-ACK报文，那你客户端已经关闭了，显然不合适吧。素以这个2SML正好就是来往一圈的时间，确保服务器能收到最后一条ACK。同时，这个过程还能确保一些异常的数据在网络中消失，不会影响到下一次通信。

那么，类似于三报文握手，四报文挥手也是采用了请求、确认、确认确认的机制。

不过这里还有一个问题，那就是四报文挥手是在连接本来建立的基础上进行的，那么**如果最后一次客户端发来的确认没有收到，或者已经通信的过程中，客户端出现问题，服务端就无法关闭，也会一直白白浪费资源，这怎么办呢?**

在前面的超时重传部分我们提到了，保活计时器，没有请求超过两小时，服务端就会主动发送探测报文段测试连接，一直没有响应，就会主动断开连接。

（这个问题也可以是，服务端只能被动关闭连接吗?显然也可以主动关闭连接）

### 七、为什么TCP是可靠的协议 ###

可靠指的就是，数据传输不会出现乱序、错误、不容易丢失、不会产生死锁等问题。  
从上面TCP的协议内容来看，TCP就是可靠的，总结一下主要原因是（可能不太准确）：

1.  TCP是面向连接的协议，链接创建之后点到点的通信相当于是独立的通道，创建连接采用三报文握手、四报文挥手；
2.  TCP有流量控制机制，采用滑动窗口的算法，保证了通信的尽量通畅；
3.  TCP对于没有按序到达的报文段，会利用缓存和序列号seq的作用将其恢复有序；
4.  流量控制是通信双方的控制，在复杂的网络环境里，TCP还采用了拥塞控制，基于四个算法、慢启动、拥塞避免、快重传、快恢复算法结合，进行拥塞控制；
5.  TCP采用超时重传机制，对于每一个连接都会维护四个计时器，选择时间，避免资源浪费。

所以TCP是可靠的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70]: /images/20230208/54cab4ea4c194b2da5c500f6591ea9ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 1]: /images/20230208/4fd9aa1eb979433f89762fe0608a53f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 2]: /images/20230208/047e73e0ee7b483cb6dc9e7f62424772.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 3]: /images/20230208/fe1af5b02d0a45c4878a89fa2773ce2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjA5Mjc4Nw_size_16_color_FFFFFF_t_70 4]: /images/20230208/28ef79034e294e6d81230a4bc54f02dc.png