当前位置：首页 > news >正文

TCP协议

news 来源：原创 2025/8/2 13:39:33

报文格式

源/目的端口号：数据从哪个进程来，到哪个进程去
32位序号：TCP传输过程中，在发送端出的字节流中，传输报文中的数据部分的每一个字节都有它的编号
32位确认号：标识了报文接收端期望接收的字节序列
4位首部长度：表示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字节头部选项：不是必须的，长度必须是32位bit（四个字节）的整数倍

TCP原理

连接管理机制（安全机制）

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

为什么 TIME_WAIT 的时间是 2MSL？

MSL是TCP报文的最大生存时间，因此 TIME_WAIT 持续等待存在 2MSL的话就能保证在两个传输方向上的尚未被接受或迟到的报文都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到数据，但是这种数据很可能是错误的），同时也是在理论上保证最后一个报文可靠到达（假设最后一个ACK丢失，那么服务器会重发一个FIN。这是虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发 LAST_ACK）。

服务器上出现大量的 CLOSE_WAIT 状态的原因

一般而言，对于服务器上出现大量的 CLOSE_WAIT 状态，原因是服务器没有正确的关闭 socket，导致四次挥手没有正确完成。这是一个bug，只需要加上对应的 close 即可解决问题。

确认应答机制（安全机制）

TCP为每个字节的数据都进行了编号，即序列号。每个ACK都带有对应的确认序列号，通知发送端已经接收到的数据，以及下一个希望接收到的数据。

超时重传机制（安全机制）

发送端在向接收端传输数据的过程中，可能因为网络等原因，数据无法到达接收端，或者确认应答无法到达发送端，如果发送端在一个特定的时间间隔内没有收到接收端发来的确认应答，就会触发超时重传机制，重新发送这部分数据。

如果是因为确认应答丢失导致发送端未接收到发送端发来的确认应答，那么发送端仍然会超时重传。因此接收端会收到很多重复的数据，那么TCP协议就需要利用序列号来达到去重的效果。

超时的时间如何确定？

理想状态下，找到一个能保证确认应答一定能返回的最小时间作为超时时间，但是这个时间的长短受网络环境的影响是会发生变化的。如果超时时间设的太长，会影响整体的重传效率；反之，又有可能会频繁发送重复的包。

为了保证无论在任何的环境下都能比较高性能的通信，因此会动态计算这个时间。在Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是它的整数倍。如果重发一次之后，仍得不到应答，等待 2*500ms 后在进行重传。如果仍得不到应答，等待 4*500ms 进行重传，以此类推，以指数形式递增。累计到一定的重传次数，TCP会认为网络或者对端主机出现异常，强制关闭连接。

滑动窗口（效率机制）

在刚才的确认应答机制中，对于每个要发送的数据段，都要先收到上一个发送的数据段对应的ACK确认应答，这样做有一个很明显的缺点，就是性能较差，尤其是数据往返的时间较长的时候。既然这样，那么我们一次发送多条数据，就可以大大提高性能（将多个数据段的等待时间叠加在了一起）。

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，上图的窗口大小就是4000个字节（四个数据段）。发送前四个段的时候无需等待任何ACK，收到第一个ACK后，滑动窗口向后移动，继续发送第五个数据段，以此类推。操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据才能从缓冲区删除。

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

情况一：数据包已经抵达，ACK丢了。

部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认；如果全部的ACK都丢失了，发送方会重新发送那些未被确认的数据段，接收方会继续确认已经接收到的数据，整个过程依赖超时重传和快速重传机制来确保数据的可靠传输。

情况二：数据包丢了。

“快速重传机制”（又叫“高速重发控制”）

当某一段报文段丢失以后，发送端会一直收到 1001 这样的ACK，如果发送端连续收到了三次同样一个 "1001" 这样的应答，就会将对应的数据 1001-2000 重新发送，这时候接收端收到了 1001 之后，再次返回的ACK就是 7001 了（因为 2001-7000 之前就已经收到并存放在接收缓冲区中了）。

流量控制（安全机制）

接收端处理数据的速度是有限的，如果发送端发的太快，会导致接收端的缓冲区被打满，这个时候如果发送端继续发送数据，就会造成丢包，进而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制（Flow Control）。

流量控制

接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。窗口大小字段越大，说明网络的吞吐量越高，接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知发送端，发送端接收到这个窗口后，就会减慢自己的发送速度。如果接收端缓冲区满了，就会将窗口置为0，这是发送方不再发送数据，但是需要定期发送一个窗口探测数据段，是接收端把窗口大小告诉发送端。

16位的窗口字段最大表示为 65535，那么TCP窗口最大就是 65535 字节吗？

答：TCP首部40字节选项中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。

拥塞控制（安全机制）

虽然TCP有了滑动窗口，能够高效可靠的发送大量的数据，但是如果再刚开始阶段就发送大量数据，仍然可能引发问题。因此TCP引入了慢启动机制，先发送少量的数据，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

拥塞窗口

发送开始时，定义拥塞窗口大小为1，每次收到一个ACK，拥塞窗口*2。每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口。为了防止拥塞窗口一直以指数级别的速度增长，我们又引入了一个叫做慢启动的阈值 ssthresh。当拥塞窗口超过这个阈值时，不再按照指数方式增长，而是按照线性方式增长。

当TCP开始启动时，慢启动阈值等于窗口最大值。每次超时重发时，慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口置回1。当TCP开始后，网络吞吐量会逐渐上升；随着网络发生拥堵（大量丢包），吞吐量就会立即下降。

拥塞控制归根结底是TCP协议想尽可能快的把数据传输给对方，但又要避免给网络造成太大的压力的这种方案。

延迟应答（效率机制）

假设接收端缓冲区为1M。一次收到了500K的数据，如果立刻应答，返回的窗口就是500K。但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了。在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M。如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

延迟应答的条件

数量限制：每隔N个包就应答一次
时间限制：超过最大延迟时间就应答一次
具体时间数量因操作系统的不同也有差异。一般N取2，超时时间取200ms

捎带应答（效率机制）

虽然有了延迟应答，但是客户端和服务器在应用层还是”一发一收”，捎带应答就是接收端在给发送端发送数据的时候，捎带着向发送端发去确认应答，应答的内容是接收端已经收到发送端发送的数据，这样就提高了数据的传输效率。

其他特性：面向字节流、缓冲区、大小限制

创建一个TCP的socket，同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区：

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

由于缓冲区的存在，TCP程序的读和写不需要匹配，例如：

写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节；读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字节，也可以一次read一个字节，重复100次。

粘包问题

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

如何避免“粘包问题”？

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

总结：明确两个包之间的边界。

对于UDP协议，是否也存在“粘包问题”？

对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层，就有很明确的数据边界。站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现"半个"的情况。

TCP异常情况

进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。

机器重启：和进程终止的情况相同。

机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。