【计算机网络】TCP原理 | 可靠性机制分析（四）

个人主页：兜里有颗棉花糖
欢迎点赞👍 收藏✨ 留言✉ 加关注💓本文由兜里有颗棉花糖原创
收录于专栏【网络编程】
本专栏旨在分享学习计算机网络的一点学习心得，欢迎大家在评论区交流讨论💌

这里写目录标题

🐬一、延时应答
🐬二、捎带应答
🐬三、面向字节流
- 🏀粘包问题
🐬四、TCP异常情况的处理

🐬一、延时应答

接收方在接收到数据后并不立即发送ACK报文，而是等待一定的延迟时间，以查看是否有更多的数据到达。如果在延迟时间内收到了更多的数据，接收方可以将多个ACK合并为一个ACK，从而减少ACK报文的发送次数。另外，这种延迟的时间可以给应用程序更多的空间来消费数据，从而避免数据积压和溢出的问题。

举个例子：比如说现在接收方接收数据后，接受区缓存（一共10kb）使用了6kb，所以剩余空间大小就是4kb，此时如果立即返回ACK的话，窗口大小就是4kb；但是如果延时返回ACK的话，假设延时500ms的话，那么应用程序就可以利用这延时的500ms来进行数据的消费，假设又消费了2kb数据的话，返回ACK后窗口大小就是6kb。接收方通过延时应答机制能为数据传输提高多少效率还是要取决于接收方处理数据的能力。

简单来说TCP延时应答可以让ACK的反馈时机变迟。

🐬二、捎带应答

捎带应答则是基于延时应答的基础上让数据进行合并。

下面捎带应答的控制图，请看

在这里插入图片描述

很多情况下，客户端服务器在应用层也是 “一发一收” 的。

如上图：四次挥手也有可能是三次挥手，其实就是延时应答和捎带应答起到的作用。中间的两个数据包合并成一个数据包之后，数据传输的效率就会提高，因为每次数据的传输都是需要封装分用的。
为什么中间的两次挥手能够进行合并：一方面是延时应答中的延时时间允许ACK和响应合并在一起发送出去；另一方面就是ACK数据本身不需要携带载荷，同时不和其它数据发送冲突。所以我们可以让一个数据包既携带载荷数据，又能带有ACK的信息（有ACK标志位、窗口大小、确认序号其实就够了）。

🐬三、面向字节流

TCP使用了多种机制来保证数据的可靠性，其中之一就是面向字节流。通过将数据拆分成字节流，TCP可以跟踪和管理每个字节的传输状态。TCP会对每个字节进行编号，以便在传输过程中检测和纠正任何丢失、重复、失序或损坏的字节。
面向字节流的特性使得TCP能够提供可靠的数据传输，确保数据按照发送的顺序和准确的内容被接收方接收到。

🏀粘包问题

面向字节流的情况下可能出现粘包问题：粘包粘的是应用层数据包

通过TCP的read/write的数据，都是TCP报文的载荷（也就是应用层数据），发送方一次性是可以发送多个应用层数据的。但是在接收的时候，是要对这些应用层数据进行区分，区分从哪里到哪里是一个数据报。如果我们没有设计到的就就有可能出现发送了2个包，但是只读取了1.5个包的bug。

针对上述的问题在传输层中并没有很好的解决办法；我们只能通过合理地设计应用层协议来解决上述问题。

应用层的解决方式：

引用分隔符来区分包和包之间的边界。
引用包长度来区分包和包之间的边界。

方式一：使用分隔符来区分
接收方的应用程序就可以通过\n来对数据包进行区分。
关于之前写的EchoServer回显服务器就是这样来进行设定的：
发送数据报的时候使用println来进行发送。接收数据报的时候使用scanner.next进行解析，遇到\n就返回。如下图所示：

方式二：使用包长度来进行区分

补充一点：粘包问题不仅仅是在TCP协议中存在，只要是面向字节流的机制（比如说文件）都存在粘包这样的问题。解决方式可以是使用分隔符的方式，也可以是使用长度的方式，无论是哪种方式，本质上都是为了区分包和包之间的边界。我们在自定义应用层协议的时候可以使用这样的思想来解决问题。

🐬四、TCP异常情况的处理

网络有时候不稳定，会有很多种情况导致网络出现故障，这很有可能会导致TCP连接不能正常工作。

情况一：进程崩溃

如果进程崩溃或异常终止，操作系统会检测到该进程的退出，并释放该进程相关的资源，包括进程控制块（PCB）和文件描述符（这相当于调用了socket.close()，注意socket在系统内核中也是一个文件，也会被放到文件描述符表中），崩溃这一方就会发送FIN，然后进一步三次握手四次挥手，之后连接就正常释放了。此时TCP的处理和进程正常退出没有什么太大区别。