TCP协议重点总结（万字总结-附实例）

迷南。 2023-09-25 14:25 2阅读 0赞

#### 文章目录 ####

*  前言
 *  一、网络的原生情况
 *  二、TCP协议
 *   *  2.1 TCP的特点
     *  2.2 TCP协议段格式
     *  2.3 TCP原理
     *   *  2.3.1 确认应答机制（可靠机制）
         *  2.3.2 序列号
         *  2.3.3 超时重传机制（可靠机制）
         *  2.3.4 连接管理机制（可靠机制）
         *  2.3.5 滑动窗口机制（效率机制）
     *  2.4 关于缓冲区
     *  2.5 关于ISN
     *  2.6 关于面向字节流
 *  三、实例演示（抓包）
 *  四、 TCP中的状态转移（重要）
 *  五、TCP异常情况
 *  六、关于粘包
 *  七、命令行查看TCP连接情况
 *  总结

--------------------

## 前言 ##

> 博主个人社区：[开发与算法学习社区][Link 1]
> 
> 博主个人主页：[Killing Vibe的博客][Killing Vibe]
> 
> 欢迎大家加入，一起交流学习~~

## 一、网络的原生情况 ##

网络中的数据，是经过路由器之间，一跳一跳地，接力一样地，传送到目标主机上的。

**这带来了两个问题：（站在网络层的视角上讨论）**

**✦ 网络传送是不可靠的**

1.  你的发送了数据，对方不保证一定能收到
2.  不能保证严格按照发送时的顺序被对方接收到

由于路可能不同，所以很难保证按照出发的顺序到达

![在这里插入图片描述][0ff63edb4dd249978ab2b4327a68e47b.png]

**✦ 网络传送是不安全的**

1.  你发送的所有数据，沿途的路由器都可以进行查看或者修改，窃听，篡改
2.  别人可以伪造成你发送的数据

**这两个问题需要交给网络层以上（传输层、应用层）去解决**

这篇文章博主将详细总结一下传输层的TCP协议

## 二、TCP协议 ##

TCP，即Transmission Control Protocol，传输控制协议。人如其名，要对数据的传输进行一个详细的控制。  
![在这里插入图片描述][fc273947e2204f91b36bf9b3b145c66e.png]

### 2.1 TCP的特点 ###

可靠的，有连接的，面向字节流的

**什么是可靠性？**

1.  TCP会尽自己所能，尽量将数据发送给对方；但并不能保证100%可以发给对方
2.  TCP会在数据发送不给对方的情况下，给应用层一个错误通知（**应用层发送数据，要么发送给对方了，要么知道数据丢失了，UDP则不会**）
3.  TCP可以保障接收方（应用层）严格按照发送时的数据顺序接收。
4.  TCP保障数据不会出现无意间损坏（UDP也做到了这一点）
5.  TCP尽可能的在维护网络质量

### 2.2 TCP协议段格式 ###

![在这里插入图片描述][efeebc6d07da4e4898d58d7c0a834e53.png]

*  **源/目的端口号**：表示数据是从哪个进程来，到哪个进程去；
 *  **32位序号/32位确认号**：下文详细讲；
 *  **4位TCP报头长度**：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15 \* 4 = 60 字节
 *  **6位标志位**:  
    ✭ URG：紧急指针是否有效  
    ✭ ACK：确认号是否有效  
    ✭ PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走  
    ✭ RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段  
    ✭ SYN：请求建立连接；我们把携带SYN标识的称为同步报文段  
    ✭ FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段
 *  **16位窗口大小**：下文详细讲
 *  **16位校验和**：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。
 *  **16位紧急指针**：标识哪部分数据是紧急数据；
 *  **40字节头部选项**：暂时忽略

### 2.3 TCP原理 ###

TCP对数据传输提供的管控机制，主要体现在两个方面：可靠和效率。

#### 2.3.1 确认应答机制（可靠机制） ####

![在这里插入图片描述][2e39e92bdf2c4f7fa81b313573b04bda.png]

**有了确认应答机制之后，现在还遗留两个问题：**

1.  如果发送方同时发送了很多数据，怎么知道对方确认收到的是哪一份？
2.  如果没有收到对方的确认（假定对方是处于正常工作流程的），接下来该怎么办？

**答：**

1.  **对数据进行编号**，这样，确认也带上编号，表明确认的是哪份数据。
2.  进行**重发**，重发的触发有个条件 ——— 超过一定时间没有收到确认，才要重复。（这就是超时重传机制）

接下来就是围绕上述两个问题展开。

#### 2.3.2 序列号 ####

TCP将每个字节的数据都进行了编号。即为序列号。

![在这里插入图片描述][d6cf2772d75840acb3174edc5bb8ecde.png]  
每一个ACK都带有对应的**确认序列号**，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

下面围绕数据的编号以及确认的编号来讨论：

1.  发送的数据编号 —— 序列号（Sequence Number） SN
2.  确认的数据编号 —— 确认序列号（Acknowledge Sequence Number）ASN

**编号的规则**：

![在这里插入图片描述][6d800ded1aa64c5d8c0c6a3dadf9dd64.png]

**ASN的填写规则：**

填写的是要接受的下一个字节的数据（本次收到的数据的最后一个字节的下一个）  
![在这里插入图片描述][b87680f59d25425eb7beb108efdb4d35.png]

**SN在发送TCP Segment 时，Header中是如何体现的？**

注意：

1.TCP发送/接收的完整数据，一般称为segment（段）  
2.TCP segment = header + payload

举个栗子：

因为一次可以发送多个字节的数据

byte[] data = {
        1,2,3,4,5}
    tcp.write(data);  //一次性发送了5个字节的数据

所以，SN直接填写本次发送的数据中**第一个字节**的数据即可。segment会携带payload长度 SN=a

**TCP由于要进行发送，也要进行确认。所以实际上 TCP Segment有两种不同的角色：**

1.  send segment
2.  acknowledge segment

TCP设计的时候，一个segment可以身兼两种不同的角色。

无论何时，一个segment 都视为send segment角色。

**但当某个标志位被置位（开关被打开）时，segment具备了acknowledge segment的角色。**

![在这里插入图片描述][32809a3dbf43464ca36c8ef9b6d8aca9.png]

**这个开关在TCP Header是通过ack标志位进行处理的：**

![在这里插入图片描述][22c559d135ed41f980b86f31af533ea2.png]

#### 2.3.3 超时重传机制（可靠机制） ####

![在这里插入图片描述][ffa4ff5763534203a14eed4d8d7b8d12.png]

>  *  主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；
>  *  如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了；

![在这里插入图片描述][9e6b8901dabc4435adbaf4b3f17ca286.png]  
因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。

**这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。**

**那么，如果超时的时间如何确定？**

>  *  最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。
>  *  但是这个时间的长短，随着网络环境的不同，是有差异的。
>  *  如果超时时间设的太长，会影响整体的重传效率；
>  *  如果超时时间设的太短，有可能会频繁发送重复的包；

**TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。**

>  *  Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定
>  *  超时重发的超时时间都是500ms的整数倍。
>  *  如果重发一次之后，仍然得不到应答，等待 2\*500ms 后再进行重传。
>  *  如果仍然得不到应答，等待4\*500ms 进行重传。依次类推，以指数形式递增。
>  *  累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

TCP已经尽了自己最大的努力，接下来：

1.  需要通知应用层，发送失败（一般在java中，write（…）就会以异常的形式提示）
2.  尽自己最大的努力，再尝试联系一下对方（会发送一种叫做reset segment），对方如果收到了，就知道我这侧已经放弃了，如果对方收不到，也无所谓。

#### 2.3.4 连接管理机制（可靠机制） ####

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

**作为一台主机上的TCP，需要：**

1.  内部针对每一条TCP的通信链路（信道），维护一组数据  
    至少：ISN、当前SN、当前ASN、发送缓冲区、接收缓冲区、五元组信息…
2.  TCP为了可靠性、为了交互交换一些信息，在正式的数据通信之前，需要和对方（TCP）进行一定的同步（synchronize）操作
3.  A把主机的一些初始重要信息告诉了B；然后B发送应答给A，让A知道B肯定也在

**所以TCP就有了连接（Connection）的概念，以及连接管理（一条连接的医生= 开始创建+正式使用+销毁）**

**关于连接：**

![在这里插入图片描述][77cd898f4303417f9017ce027b1b7ca4.png]

**好了，有了如上的铺垫，接下来博主讲逐步讲解三次握手和四次挥手到底是怎么一回事：**

✭ 握手阶段其实就是**双方互相同步信息**的阶段：

![在这里插入图片描述][9d6f4261815c4d1589d5ded71808255c.png]

逻辑上需要四次，因为互相发同步信息（2次）都需要应答（2次）。

![在这里插入图片描述][0b2cb05af7194c1495b7a99e0970546a.png]

由于第二步和第三步是可以同时发生的，TCP也支持一个Segment同时起到（syn和ack）的作用，所以上述2和3可以合并，减少网络数据发送的次数，整体上提高性能。

![在这里插入图片描述][734b7e880ebe4ae79407e877fb00cc4d.png]

✭ 同理，挥手阶段其实就是**双方互相确认要断开连接**的阶段：

1.  不过由于服务器不能收到客户端的fin请求就立刻也发一个fin请求，因为服务器此时可能仍有一些未处理完的数据要处理，要等这些数据处理完才可以close。
2.  还有种可能的情况就是双方都主动挥手close了。
3.  还有种情况就是双方同时主动挥手。

情况一：

![在这里插入图片描述][b9b46b3134a246739457d083290bfc11.png]

情况二：

![在这里插入图片描述][a27fc75076f04188a1ad16130c7becf8.png]  
情况三：  
![在这里插入图片描述][e981de591a1b440591f9a1a28dac5cb4.png]

**注意：**

**三次握手阶段是否可以携带payload？**

1.  第一次syn，不能携带数据
2.  第二次syn+ack，不能携带数据
3.  第三次ack，可以携带数据，但不强制

原因在于不能确认连接一定建立成功，如果携带数据，则提升发送成本，如果失败，一切白发，所以协议设计时禁止携带数据。

**syn序列号的变化：虽然不能携带数据，但也会消耗一个序列号：**

![在这里插入图片描述][28b937da4ee24fe89d7d85eb6b8021a0.png]

#### 2.3.5 滑动窗口机制（效率机制） ####

这是一块重要的内容，博主直接分P详细总结并且画图逐步讲解了，链接如下：

[TCP滑动窗口机制][TCP]

### 2.4 关于缓冲区 ###

![在这里插入图片描述][f5a8c904e16b44f4bb2b6a11756a1326.png]

### 2.5 关于ISN ###

![在这里插入图片描述][a58129493c0943d4a7277690cdafacc3.png]

### 2.6 关于面向字节流 ###

>  *  调用write时，数据会先写入发送缓冲区中；
>  *  如果发送的字节数太长，会被拆分成多个TCP的数据包发出；
>  *  如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适的时机发送出去；
>  *  接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区；
>  *  然后应用程序可以调用read从接收缓冲区拿数据；
>  *  另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既可以读数据，也可以写数据。这个概念叫做 全双工
>  *  写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节；
>  *  读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字节，也可以一次read一个字节，重复100次；

## 三、实例演示（抓包） ##

用Wireshark抓包工具，抓取传输协议为TCP的包：

![在这里插入图片描述][29d3d5c2e6a84a22b3f3f2effe769d39.png]以上就是三次握手的三个包。

下图为第一个包中的数据：（蓝色部分为TCP的部分）

![在这里插入图片描述][21989f28a98944a98cf671dc2e5bcade.png]

![在这里插入图片描述][2949a94c921e4922809f90ead4b6b1a1.png]

现在可以根据这些数据来一一计算验证我们的TCP头：

![在这里插入图片描述][273e9f0bd0234227900a8c78b28bc6ba.png]  
**验证如下：**

**16位源端口号**：首先前面两个字节是 0xe542，换算成十进制就是 58690  
**16位目的端口号**：然后就是后面的两个字节 0x22b8，换算过来就是 8888  
**32位SN：** 0xb1e9b0e0 ，可以看出来ISN不是0。  
**32位ASN：** 0x00000000，一开始发送的时候还没有ASN  
**4位首部长度：** 0x8，说明协议首部长度为 8 \* 4 = 32 字节（真实首部长度= 首部长度 \* 4 ，像这里的8表示有8个32为bit，也就是8个4字节 = 32字节）  
**保留6位+标志位6位：** 0x002 ，换算成二进制就是000000 000010，刚好对应的就是syn位被置为了1 .

后面的是一样计算的，博主就不一一列举了。

## 四、 TCP中的状态转移（重要） ##

以下内容博主也进行了分P总结，这块内容比较难理解，最好就是死记硬背，具体可以参考博主的图解，更容易理解，链接如下：

[TCP中的状态转移（三种情况）][TCP 1]

## 五、TCP异常情况 ##

>  *  进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。
>  *  机器重启：和进程终止的情况相同。
>  *  机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。

**拓展：**

*进程终止和机器关机/重启：*

一个进程的所有资源都是OS分配的（换言之，一个进程有哪些资源OS都是知道的），所以，即使进程内部没有关闭TCP连接，OS也会走进程资源释放流程，将TCP连接正常关闭，这个进程会作为主动关闭方，正常四次挥手

![在这里插入图片描述][e3c7a93bfe054c218467d18cad9b2932.png]

只要OS的代码能执行，连接就会正常关闭！！！

*机器掉电/网线断开：*

这种情况，OS的代码就不能执行了，因为机器掉电了。

**此时这条连接的命运需要分开来讨论：**

现在假设有两台主机 甲和乙。

1.  首先是甲的命运：由于连接只是逻辑上的概念，表现在现实中只是内存中的一段数据。电断了，内存中的数据就没有了，所以对于甲来说连接就没了（不是关闭，直接就是消失了）
2.  其实是乙的命运：在乙看来，连接仍然在，在没有特殊场景下，乙是不知道甲没了。（比如男女朋友的关系，男方突然挂了，女方不通过某些途径是不知道男方挂了的）
3.  所以乙的情况就会有两种： （1）保持原状 （2） 看乙有没有可能感知到甲已经没了这条信息
4.  如果乙发生写事件（乙尝试向甲发数据了），收不到ACK确认信息，即使超时重传了也收不到。多次尝试后，乙走异常关闭流程。（关闭该TCP连接，异常方式通知应用层，最后再发一条reset segment）
5.  如果乙只是单纯在读数据，那么乙不知道甲已经消失了这个信息，如果乙一直read，则乙就是死连接了（一直保持established状态，但永远收不到数据了）

**为了解决上述这个问题：**

1.  TCP层面有keepalive机制：定期的发送一些数据给对方（payload长度为0），segment长度不是0，就可以根据对方有没有应答来判断。（用的不多）
2.  更常见的办法是**应用层**自己来做这个工作：（1）read的时候，不要无限制read，而是带上超时时间（read timeout）。 （2） 定期互相报平安（定期都主动给对方发消息） ——heartbeat（心跳包）

例如QQ，在QQ断线之后，也会定期尝试重新连接。

**关于RST：**

![在这里插入图片描述][bb7197e771fd45caab0153e2147aac16.png]

## 六、关于粘包 ##

>  *  首先要明确，粘包问题中的 “包” ，是指的应用层的数据包。
>  *  在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。
>  *  站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
>  *  站在应用层的角度，看到的只是一串连续的字节数据。
>  *  那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

那么如何避免粘包问题呢？归根结底就是一句话，**明确两个包之间的边界**

>  *  对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；
>  *  对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
>  *  对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；

## 七、命令行查看TCP连接情况 ##

使用 netstat 命令：

![在这里插入图片描述][13d63b8d14a04f61bc496bfaf55a1fc1.png]

由于输出较多，可以结合findstr 做结果过滤：

![在这里插入图片描述][26df0fe6c3374df9beb289b48cab2a13.png]  
根据任务管理器，知道 pid为29632的进程占用了端口为8080的TCP连接：

![在这里插入图片描述][02dcf957d57e4287a69abe483a5bf9b1.png]

## 总结 ##

以上就是TCP协议的万字总结，内容有点多，但每个知识点的细节博主都有举实例，帮助大家更好的理解，码字不易，有帮助的话大家可以**点个赞收藏**起来慢慢看，有什么问题可以私信博主，大家交流一下。

[Link 1]: https://bbs.csdn.net/forums/killingvibe?joinKey=bxrj0yyjeyrk-2o9q4217kn-1-a7ba228d3f0db23bd3e669796abef74b
[Killing Vibe]: https://blog.csdn.net/qq_43575801
[0ff63edb4dd249978ab2b4327a68e47b.png]: https://img-blog.csdnimg.cn/0ff63edb4dd249978ab2b4327a68e47b.png
[fc273947e2204f91b36bf9b3b145c66e.png]: https://img-blog.csdnimg.cn/fc273947e2204f91b36bf9b3b145c66e.png
[efeebc6d07da4e4898d58d7c0a834e53.png]: https://img-blog.csdnimg.cn/efeebc6d07da4e4898d58d7c0a834e53.png
[2e39e92bdf2c4f7fa81b313573b04bda.png]: https://img-blog.csdnimg.cn/2e39e92bdf2c4f7fa81b313573b04bda.png
[d6cf2772d75840acb3174edc5bb8ecde.png]: https://img-blog.csdnimg.cn/d6cf2772d75840acb3174edc5bb8ecde.png
[6d800ded1aa64c5d8c0c6a3dadf9dd64.png]: https://img-blog.csdnimg.cn/6d800ded1aa64c5d8c0c6a3dadf9dd64.png
[b87680f59d25425eb7beb108efdb4d35.png]: https://img-blog.csdnimg.cn/b87680f59d25425eb7beb108efdb4d35.png
[32809a3dbf43464ca36c8ef9b6d8aca9.png]: https://img-blog.csdnimg.cn/32809a3dbf43464ca36c8ef9b6d8aca9.png
[22c559d135ed41f980b86f31af533ea2.png]: https://img-blog.csdnimg.cn/22c559d135ed41f980b86f31af533ea2.png
[ffa4ff5763534203a14eed4d8d7b8d12.png]: https://img-blog.csdnimg.cn/ffa4ff5763534203a14eed4d8d7b8d12.png
[9e6b8901dabc4435adbaf4b3f17ca286.png]: https://img-blog.csdnimg.cn/9e6b8901dabc4435adbaf4b3f17ca286.png
[77cd898f4303417f9017ce027b1b7ca4.png]: https://img-blog.csdnimg.cn/77cd898f4303417f9017ce027b1b7ca4.png
[9d6f4261815c4d1589d5ded71808255c.png]: https://img-blog.csdnimg.cn/9d6f4261815c4d1589d5ded71808255c.png
[0b2cb05af7194c1495b7a99e0970546a.png]: https://img-blog.csdnimg.cn/0b2cb05af7194c1495b7a99e0970546a.png
[734b7e880ebe4ae79407e877fb00cc4d.png]: https://img-blog.csdnimg.cn/734b7e880ebe4ae79407e877fb00cc4d.png
[b9b46b3134a246739457d083290bfc11.png]: https://img-blog.csdnimg.cn/b9b46b3134a246739457d083290bfc11.png
[a27fc75076f04188a1ad16130c7becf8.png]: https://img-blog.csdnimg.cn/a27fc75076f04188a1ad16130c7becf8.png
[e981de591a1b440591f9a1a28dac5cb4.png]: https://img-blog.csdnimg.cn/e981de591a1b440591f9a1a28dac5cb4.png
[28b937da4ee24fe89d7d85eb6b8021a0.png]: https://img-blog.csdnimg.cn/28b937da4ee24fe89d7d85eb6b8021a0.png
[TCP]: https://killingvibe.blog.csdn.net/article/details/128577307?spm=1001.2014.3001.5502
[f5a8c904e16b44f4bb2b6a11756a1326.png]: https://img-blog.csdnimg.cn/f5a8c904e16b44f4bb2b6a11756a1326.png
[a58129493c0943d4a7277690cdafacc3.png]: https://img-blog.csdnimg.cn/a58129493c0943d4a7277690cdafacc3.png
[29d3d5c2e6a84a22b3f3f2effe769d39.png]: https://img-blog.csdnimg.cn/29d3d5c2e6a84a22b3f3f2effe769d39.png
[21989f28a98944a98cf671dc2e5bcade.png]: https://img-blog.csdnimg.cn/21989f28a98944a98cf671dc2e5bcade.png
[2949a94c921e4922809f90ead4b6b1a1.png]: https://img-blog.csdnimg.cn/2949a94c921e4922809f90ead4b6b1a1.png
[273e9f0bd0234227900a8c78b28bc6ba.png]: https://img-blog.csdnimg.cn/273e9f0bd0234227900a8c78b28bc6ba.png
[TCP 1]: https://killingvibe.blog.csdn.net/article/details/128598768
[e3c7a93bfe054c218467d18cad9b2932.png]: https://img-blog.csdnimg.cn/e3c7a93bfe054c218467d18cad9b2932.png
[bb7197e771fd45caab0153e2147aac16.png]: https://img-blog.csdnimg.cn/bb7197e771fd45caab0153e2147aac16.png
[13d63b8d14a04f61bc496bfaf55a1fc1.png]: https://img-blog.csdnimg.cn/13d63b8d14a04f61bc496bfaf55a1fc1.png
[26df0fe6c3374df9beb289b48cab2a13.png]: https://img-blog.csdnimg.cn/26df0fe6c3374df9beb289b48cab2a13.png
[02dcf957d57e4287a69abe483a5bf9b1.png]: https://img-blog.csdnimg.cn/02dcf957d57e4287a69abe483a5bf9b1.png