【网络协议】TCP协议常用机制——延迟应答、捎带应答、面向字节流、异常处理，保姆级详解，建议收藏

💐个人主页：初晴~

📚相关专栏：计算机网络那些事

---

        前几篇文章，博主带大家梳理了一下TCP协议的几个核心机制，比如保证可靠性的 确认应答、超时重传 机制，和提高传输效率的 滑动窗口及其相关优化机制。除此之外，TCP还有一些非常重要的核心机制，就让博主在本篇文章带着大家学习一下吧

一、延迟应答

TCP协议中的延时应答（Delayed Acknowledgment）机制是一种优化技术，旨在减少网络中的确认（ACK）消息数量，从而提高网络带宽利用率和减少网络拥塞。

试想一下，如果接收端在收到数据时就立马返回ACK应答可能会出现什么问题？

这时返回的窗口可能会比较小

• 假设接收端缓冲区为1M，⼀次收到了500K的数据，如果⽴刻应答，返回的窗⼝就是500K
• 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了
• 在这种情况下，接收端处理还远没有达到⾃⼰的极限，即使窗⼝再放⼤⼀些, 也能处理过来
• 如果接收端稍微等⼀会再应答，⽐如等待200ms再应答，那么这个时候返回的窗⼝⼤⼩就是1M

主要原理是接收端在接收数据的时候，应用程序也在源源不断地消费接受缓冲区内的数据。

在收到数据时，先等一小会儿，缓冲区内的数据可能就会被消费而少掉很多，此时再返回给发送端 ACK时，返回的窗口大小就大概率会比立即返回更大。

而窗口越大，网络吞吐量就越大，传输效率也越高。因此延迟应答在一定程度上就能提高网络传输的效率。

但难道能一直延迟下去吗？延迟的时间过久也是会导致接受缓冲区爆满，引发丢包等一系列问题的。因此TCP会对延迟时间做出一些限制：

• 数量限制：每隔N个包就应答⼀次
• 时间限制：超过最⼤延迟时间就应答⼀次

具体的数量和超时时间，依操作系统不同也有差异。⼀般N取2，超时时间取200ms

这样就能很好地控制应答报文的返回密度，在不影响传输可靠性的条件下，尽可能提高网络传输的效率

---

二、捎带应答

在 延迟应答 的基础上，我们发现，实际网络通信中，大多数情况下都是“一问一答”的形式：

• ack ，是系统内核返回的，在收到请求后就立即返回ack
• 响应，是应用程序返回的，在代码中，根据请求计算得到响应，然后再返回给发送端

正常情况下，ack与响应 返回的时机不同，无法进行合并。

但别忘了，ack涉及“延时应答”机制，会让ack返回时间推迟。这一推迟，ack 就有机会等到 响应 报文生成的时候了，于是就可以再发送响应的时候，捎带上ack数据。

就好比说 客⼾端 给服务器说了 "How are you"，服务器也会给客⼾端回⼀个 "Fine, thank you"，而这个时候ack就等了一会儿，搭上顺风车，和服务器回应的 "Fine, thank you" 一起返回给客户端

还记得之前在 TCP协议“三次握手，四次挥手” 一文中我们研究过的四次挥手吗？

当时我们介绍过，ack是系统内核返回的，fin是应用程序返回的，理论上来说这俩发送时机并不同，是无法合并的。这也是“四次挥手”说法的由来。

但是，在延时应答的机制下，ack的返回时间可能会推迟，就有可能会和 FIN 合并，一起返回了。这时，“四次挥手” 就变成 “三次挥手” 了。

 之所以ack可以和响应报文合并，是因为 ack 报文本身不需要载荷，只需在报头中将 ack字段设为“1”，接着设置好窗口大小、确认序号即可。这并不会与正常的响应报文产生冲突

 

---

三、面向字节流

创建⼀个TCP的socket, 同时在内核中创建⼀个 发送缓冲区 和⼀个 接收缓冲区;

• 调⽤write时，数据会先写⼊发送缓冲区中
• 如果发送的字节数太⻓，会被拆分成多个TCP的数据包发出
• 如果发送的字节数太短，就会先在发送缓冲区⾥等待，等到缓冲区⻓度差不多了，或者其他合适的时机发送出去
• 接收数据的时候，数据也是从⽹卡驱动程序到达内核的接收缓冲区
• 然后应⽤程序可以调⽤read从接收缓冲区拿数据
• 另⼀⽅⾯，TCP的⼀个连接，既有发送缓冲区，也有接收缓冲区

对于这⼀个连接，既可以读数据，也可以写数据。这个概念叫做 全双⼯

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

读写100个字节的数据时：

1、可以一次读写一个字节，分 100 次读写

2、可以一次读写十个字节，分 10 次读写

3、可以一次读写50个字节，分 2 次读写

4、可以一次读写100个字节，一次读写完

……

这样读写虽然十分自由，但也会带来一些问题。相比于面向数据报的传输方式，通过面向字节流的方式每次传输的界限没有那么分明了。容易导致粘包问题：

即应用层数据包在TCP的接收缓冲区内连成一片，粘在一起

站在应⽤层的⻆度, 看到的只是⼀串连续的字节数据。当应用程序需要读取接收缓冲区内的数据时，由于TCP是面向字节流的，因此缓冲区内数据怎么读都有可能。

可能会读出 a，a，a，b，b，b，c，c，c

也可能读出 aaa，bbb，ccc

还可能读出 aaabbbccc

……

这样肯定是不利于正确读取数据包意义的。想要解决粘包问题，关键就是要明确“包之间的边界”

• 方案一：指定分隔符

比如我们可以约定，请求响应都以 “\n” 结尾。这样在发送读取的时候都用 “\n” 作为分隔符，每当读写到 “\n” 时，就意味着一个数据包已经结束了，应用端就可以正常对这个数据包进行解析了。

不过，采用这种方案时一定要注意避免数据内容的正文中也会出现分隔符。比如采用ASCII中靠前的目前已不再使用的一些“控制字符”作为分隔符就比较合适。

常见的几种协议有xml、yml、json等，一般适用于文本类的数据的传输。

• 方案二：指定数据的长度

比如，约定在每个应用层数据包的开头2~4个字节，表示数据包的长度

UDP协议采用的就是这种方案。因此UDP传输是不会出现粘包问题的

---

四、异常情况处理

现实的网络通信中，不是每一次通信都能够正常完成“四次挥手”断开连接的，可能会遇到各种各样的异常情况。

1、进程崩溃

进程崩溃，听起来很严重，实际上操作系统会做好善后。当进程崩溃时，进程中的PCB就会被回收了，PCB中的⽂件描述符中的所有文件都会被操作系统自动关闭，仍然可以发送FIN。和正常关闭没有什么区别

2、主机关机（正常关机）

正常点击关机键关机时，操作系统会先终止所有进程，同时也会触发“四次挥手”机制。而这时就可能会出现两种情况：

（1）四次挥手完成后，关机才真正完成

这种情况不会有什么问题，通信会正常断开

（2）四次挥手还没有挥完，就已经关机完毕了

这时就有可能收不到 B 发来的 FIN 请求，也就无法像其返回ack，而 B 并不知道 A 已经关机了，接收不到 ack 就会导致四次挥手迟迟不能完成，通信也就无法正常断开了。

 由于 B 接收不到 A 的ACK应答报文，等待一定时间就会触发“超时重传”机制重新发送 FIN报文。当 B 重传一定次数还没有响应时，就会主动断开连接（把保存的 A 的信息删掉了）。虽然过程有些曲折，但最终也能成功让通信断开

3、主机断电（异常关机）

（1）接收方断电

 这时 A 给 B 发送数据，就不会再返回 ACK 了。

A 就会触发超时重传，当多次重传都没有得到 ACK 时，A就会尝试重置连接（reset）。如果重置操作也没有 ACK，A 就会单方面的释放连接（把 B 的信息删掉）

（2）发送方断电

 A  发着发着没声了。在 B 的视角看来，并不确定 A 是终止了，还是说就是这段时间没有请求而已。此时，B 就会给 A 发送一个数据包，询问 A 是否还在。

如果发了探测报文后，A 返回了 ACK，就说明 A 只是暂时没有请求而已。但如果连续发了多个探测报文，A 都没有返回 ACK，就可以认为 A 是异常终止了。就会单方面释放连接。

TCP内置了⼀个保活定时器，会定时发送这样的探测报文。因为这样的报文是用来探测对方“生死”的，因此也会被称之为“心跳包”

4、网线断开

与主机断电类似。只不过是通信双方都感知不到对方的存在了。

• A 的视角：A 收不到 ACK ，触发多次超时重传，然后尝试重置连接，最后会单方面释放连接
• B的视角：A 忽然没有反应了。发多次心跳包也没有回应，最后也会单方面释放连接

这样，虽然过程曲折，但最后的结果还是成功让双方断开连接了。这样的处理还是能够让人接受的

总结

---

那么本篇文章就到此为止了，如果觉得这篇文章对你有帮助的话，可以点一下关注和点赞来支持作者哦。如果有什么讲的不对的地方欢迎在评论区指出，希望能够和你们一起进步✊