【网络协议】TCP协议常用机制——延迟应答、捎带应答、面向字节流、异常处理，保姆级详解，建议收藏
📚相关专栏：计算机网络那些事
前几篇文章，博主带大家梳理了一下TCP协议的几个核心机制，比如保证可靠性的 确认应答、超时重传 机制，和提高传输效率的 滑动窗口及其相关优化机制。除此之外，TCP还有一些非常重要的核心机制，就让博主在本篇文章带着大家学习一下吧
一、延迟应答
TCP协议中的延时应答（Delayed Acknowledgment）机制是一种优化技术，旨在减少网络中的确认（ACK）消息数量，从而提高网络带宽利用率和减少网络拥塞。
试想一下，如果接收端在收到数据时就立马返回ACK应答可能会出现什么问题？
这时返回的窗口可能会比较小
- 假设接收端缓冲区为1M，⼀次收到了500K的数据，如果⽴刻应答，返回的窗⼝就是500K
- 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了
- 在这种情况下，接收端处理还远没有达到⾃⼰的极限，即使窗⼝再放⼤⼀些, 也能处理过来
- 如果接收端稍微等⼀会再应答，⽐如等待200ms再应答，那么这个时候返回的窗⼝⼤⼩就是1M
主要原理是接收端在接收数据的时候，应用程序也在源源不断地消费接受缓冲区内的数据。
在收到数据时，先等一小会儿，缓冲区内的数据可能就会被消费而少掉很多，此时再返回给发送端 ACK时，返回的窗口大小就大概率会比立即返回更大。
而窗口越大，网络吞吐量就越大，传输效率也越高。因此延迟应答在一定程度上就能提高网络传输的效率。
但难道能一直延迟下去吗？延迟的时间过久也是会导致接受缓冲区爆满，引发丢包等一系列问题的。因此TCP会对延迟时间做出一些限制：
- 数量限制：每隔N个包就应答⼀次
- 时间限制：超过最⼤延迟时间就应答⼀次
这样就能很好地控制应答报文的返回密度，在不影响传输可靠性的条件下，尽可能提高网络传输的效率
二、捎带应答
在 延迟应答 的基础上，我们发现，实际网络通信中，大多数情况下都是“一问一答”的形式：
- 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”，接着设置好窗口大小、确认序号即可。这并不会与正常的响应报文产生冲突
三、面向字节流
- 调⽤write时，数据会先写⼊发送缓冲区中
- 如果发送的字节数太⻓，会被拆分成多个TCP的数据包发出
- 如果发送的字节数太短，就会先在发送缓冲区⾥等待，等到缓冲区⻓度差不多了，或者其他合适的时机发送出去
- 接收数据的时候，数据也是从⽹卡驱动程序到达内核的接收缓冲区
- 然后应⽤程序可以调⽤read从接收缓冲区拿数据
- 另⼀⽅⾯，TCP的⼀个连接，既有发送缓冲区，也有接收缓冲区
对于这⼀个连接，既可以读数据，也可以写数据。这个概念叫做 全双⼯
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 忽然没有反应了。发多次心跳包也没有回应，最后也会单方面释放连接
这样，虽然过程曲折，但最后的结果还是成功让双方断开连接了。这样的处理还是能够让人接受的
总结
那么本篇文章就到此为止了，如果觉得这篇文章对你有帮助的话，可以点一下关注和点赞来支持作者哦。如果有什么讲的不对的地方欢迎在评论区指出，希望能够和你们一起进步✊
原文地址：https://blog.csdn.net/acm_pn/article/details/142870908
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！