TCP协议

目录

 ♫TCP协议段格式

♫确认应答

 

♫超时重传

 ♫连接管理

 ♫滑动窗口

 ♫流量控制

 ♫拥塞控制

 

 ♫延迟应答

 ♫捎带应答

---

TCP 相比于 UDP 具有有连接、可靠传输、面向字节流等特性，这注定了 TCP 协议要比 UDP 协议复杂的多。 

 ♫TCP协议段格式

首先，与 UDP 协议不同的一点就是，UDP 首部长度是固定为8字节的，而 TCP 首部中有个选项部分未指定其具体大小，所以 TDP 的首部长度是不确定的；此外，TCP 的首部长度单位是4字节，而除选项外的首部长度固定是20字节，故可以通过首部长度-20字节得到选项长度；另外，TCP 还增加了6位保留位，可以方便以后对 TCP 进行升级扩展，在保留位上进行扩展，可以让协议能够在不改变现有字段结构的情况下进行扩展，这样扩展后的 TCP 可以无需担心与旧版本的 TCP 的兼容性问题。

下面先简单说明下各个字段的作用：

♩.源端口（16位）：标识发送方应用进程的端口号。

♩.目标端口（16位）：标识接收方应用进程的端口号。

♩.序号（32位）：序号用于标识从TCP发送端向接收端发送的数据字节流的顺序。每一个字节都有一个序号，确保数据按顺序传输和重组。

♩.确认号（32位）：确认号用于告诉发送方已成功收到的数据字节的范围，即期望接收到的下一个数据字节的序号。这帮助发送方判断哪些数据需要重传。

♩.首部长度（4位）：表示TCP首部的长度，以32位（4字节）为单位。

♩.保留（6位）：保留字段目前未使用，保留供将来使用，设置为0。

♩.标志位（6位）：①.URG（紧急指针是否有效）、

                              ②.ACK（确认号是否有效）、

                              ③.PSH（提示接收端应用程序立刻从TCP缓冲区把数据读走 ）、

                              ④.RST（对方要求重新建立连接，把携带RST标识的称为复位报文段）、

                              ⑤.SYN（请求建立连接，把携带SYN标识的称为同步报文段）、

                              ⑥.FIN（通知对方，本端要关闭了，把携带FIN标识的为结束报文段）。

♩.窗口大小（16位）：窗口大小用于流量控制，表示发送方愿意接收的数据量，单位为字节。它告诉对方当前可以发送的数据范围。

♩.校验和（16位）：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光 包含TCP首部，也包含TCP数据部分。

♩.紧急指针（16位）：紧急指针仅在URG标志置位时才有意义，表示紧急数据的偏移量。当所有紧急数据处理完毕时，TCP会通知应用程序恢复到正常操。

♩.选项（可选，最长为40字节）：选项字段长度可变，最长可达40字节。当没有选项时，TCP的首部长度是20字节。选项可以支持特定的功能，如最大报文段长度（MSS）。

上面只是大概描述了序号、确认号、窗口大小等字段的功能，要想更清晰地了解这些字段的含义，我们需要先了解 TCP 的工作原理。

♫确认应答

TCP 是面向字节流的，故 TCP 将每个字节的数据都进行了编号，即为序号（32位）：

网络通信过程中，序号可以避免后发先至的问题，明确哪个响应对应哪个请求：

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经成功接收到了哪个序号之前的所有数据，请从这个序号开始发送后续的数据。

注：任何一条数据都有序号，而确认序号只有应答报文才有，当 ACK 为1表示是应答报文，ACK 为0则表示不是应答报文。

♫超时重传

网络传输过程存在不确定因素，当数据传输过程中如果丢包了，就会触发超时重传机制。

丢包分两种情况：

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

这种情况下，主机A只会收到一次ACK，主机B也只会收到一次数据。

♩.应答报文ACK丢包

这种情况下，主机A只会收到一次ACK，而主机B会收到两次数据。因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。TCP存在一个发送缓冲区和接收缓冲区接收缓冲区，主机B的接收到数据之后，将数据放到接收缓冲区中，我们可以将这个缓冲区想象成一个优先级阻塞队列，TCP 根据序号可以将数据进行去重排序。

 ♫连接管理

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

♪.三次握手

[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态，等待客户端连接；

♩第一次握手： 客户端发送一个SYN包（同步序列号）到服务器，并进入SYN_SEND状态，等待服务器确认。（相当于客户端向服务器询问：听到请回答~）

♩第二次握手：服务器收到SYN包后，需要对这个客户端请求进行确认，同时自己也会发送一个SYN包（自己的同步序列号）。此时服务器进入SYN_RECV状态。（（相当于服务器向客户端回答并询问：收到！你也能听到我说话吗？））

♩第二次握手：客户端收到服务器的SYN+ACK包后，会再给服务器发送一个确认ACK包，此时客户端进入ESTABLISHED状态。当服务器收到这个ACK包时，也进入ESTABLISHED状态，完成三次握手。（相当于客户端向服务器回答：收到！）

通过三次握手可以保证通信双方发送和接受信息的能力并建立连接。

注：三次握手中第二次握手，服务器之所以能将 ACK（收到！）和 SYN（你也能听到我说话吗？）合在一起发送是因为这两个行为都是纯内核完成的，它们的发生都处在同一时期。

♪.四次挥手

♩第一次挥手：若客户端要断开与服务器的连接，会发送一个FIN包（结束标志位）到服务器，然后客户端进入FIN_WAIT_1状态，表示客户端不再发送数据但还能接收数据。

♩第二次挥手：服务器收到客户端的FIN包后，会发送一个ACK包作为应答，此时服务器进入CLOSE_WAIT状态。

♩第三次挥手：服务器发送完所有数据后，会向客户端发送一个FIN包来断开与客户端的连接，并进入LAST_ACK状态。

♩第四次挥手：客户端收到服务器的FIN包后，会发送一个ACK包作为应答，然后进入TIME_WAIT状态。经过2MSL（2个最长报文段寿命）时间后，客户端会退出此状态，完成四次挥手。

注：

①.四次挥手这里由于第二次挥手和第三次挥手是不能合在一起发送的，这是因为 FIN 不是由内核控制的，而是由应用程序调用 clientSocket 的 close 方法才会触发，而 ACK 是由内核控制的，只要收到 FIN 就会立刻返回 ACK：

返回 FIN 和 ACK 不一定在同一时期，所有两次挥手不能合并。

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

 ♫滑动窗口

确认应答、超时重传、连接管理都为了 TCP 的可靠性，而滑动窗口则是为了提高 TCP 的传输效率。

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答；收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候：

这样子的时间都浪费在了通信的路上，所以我们可以一次发送多条数据，将多个段的等待时间重叠在一起了，就可以大大的提高性能了：

①. 发送前四个段的时候，不需要等待任何ACK，直接发送；

②. 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；

③. 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉；

④. 窗口越大，则网络的吞吐率就越高。

TCP 报文里的窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。(如：上图的窗口大小就是4000个字节（四个段））

滑动窗口情况下，如果只是部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认，如果是数据包丢失了，接受端就会一直提醒发送端想要丢失的数据包：

①.当2001段报文段丢失之后，发送端会一直收到 2001 这样的ACK，就像是在提醒发送端 "我想要的是 2001" 一样；

②.如果发送端主机连续三次收到了同样一个 "2001" 这样的应答，就会将对应的数据 2001 -

3000 重新发送；

③.这个时候接收端收到了 2001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；

 ♫流量控制

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

①.接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端；

②.窗口大小字段越大，说明网络的吞吐量越高；

③.接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接受到这个窗口之后，就会减慢自己的发送速度；

④.如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

注：接收端通过TCP首部中的16位窗口字段把窗口大小告诉发送端，虽然该字段只有16位，但是TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是 窗口字段的值左移 M 位；

 ♫拥塞控制

虽然流量控制可以避免接受端处理能力导致的丢包问题，如果当前的网络状态就已经比较拥堵的情况下，仍然可能引发问题。

TCP引入了慢启动机制来避免在网络拥堵的情况下发送大量数据。慢启动算法的基本思想是在开始阶段发送少量的数据包，然后根据接收到的确认信息逐渐增加发送速率，直到达到一个稳定的传输速率。具体来说，当TCP连接建立后，初始的拥塞窗口大小（cwnd）设置为一个较小的值，通常是1或2个最大段大小（MSS）。然后，每当收到一个确认报文时，拥塞窗口的大小就会翻倍，即cwnd = cwnd * 2。这样，发送方可以快速地探测网络的容量，并逐步增加发送速率。然而，如果网络出现拥塞，即丢包率上升，那么发送方会减小拥塞窗口的大小，通常将cwnd设置为原来的一半，即cwnd = cwnd / 2。这样做是为了减少发送速率，避免进一步加剧网络拥塞。此外，TCP还引入了慢启动阈值（ssthresh），它是一个拥塞窗口大小的阈值。当拥塞窗口大小小于这个阈值时，TCP使用慢启动算法；而当拥塞窗口大小大于等于这个阈值时，TCP使用拥塞避免算法。拥塞避免算法通过线性增长的方式增加拥塞窗口的大小，以避免过度增长导致网络拥塞。通过慢启动和拥塞避免算法的结合，TCP能够在网络状况良好时快速传输数据，而在网络拥塞时能够适应并调整传输速率，从而保持数据传输的稳定性和可靠性。

 ♫延迟应答

滑动窗口的关键在于窗口大小，所以在接收方处理的了的情况下，可以尽可能让窗口更大一些。延迟应答就是收到数据后不立刻返回 ACK，而是等待一段时间后再返回，这里在等待的时间里接收方的就能把缓冲区的数据处理一部分，这样 ACK 返回时的窗口大小就更大一些了：

 ♫捎带应答

捎带应答是TCP协议中的一种优化机制，它允许在数据传输过程中减少确认报文的数量，从而提高传输效率。

在TCP中，ACK 用于确认已成功接收到数据。通常情况下，每接收到一个数据报文段，接收方都会发送一个ACK报文作为回应。然而，在某些情况下，这种一一对应的确认方式可能会增加网络负担和传输延迟。为了解决这个问题，TCP引入了捎带应答机制。

当接收方有数据需要发送给发送方时，在延迟应答的机制下，它可以将ACK报文与数据报文一起发送，这种方式称为“捎带应答”。这样，接收方就不需要单独发送ACK报文，从而减少了网络中的报文数量和传输延迟。