🐬一、延时应答
接收方在接收到数据后并不立即发送ACK报文，而是等待一定的延迟时间，以查看是否有更多的数据到达。如果在延迟时间内收到了更多的数据，接收方可以将多个ACK合并为一个ACK，从而减少ACK报文的发送次数。另外，这种延迟的时间可以给应用程序更多的空间来消费数据，从而避免数据积压和溢出的问题。
举个例子：比如说现在接收方接收数据后，接受区缓存（一共10kb）使用了6kb，所以剩余空间大小就是4kb，此时如果立即返回ACK的话，窗口大小就是4kb；但是如果延时返回ACK的话，假设延时500ms的话，那么应用程序就可以利用这延时的500ms来进行数据的消费，假设又消费了2kb数据的话，返回ACK后窗口大小就是6kb。接收方通过延时应答机制能为数据传输提高多少效率还是要取决于接收方处理数据的能力。
简单来说TCP延时应答可以让ACK的反馈时机变迟。
🐬二、捎带应答
捎带应答则是基于延时应答的基础上让数据进行合并。
下面捎带应答的控制图，请看
很多情况下，客户端服务器在应用层也是 “一发一收” 的。
🐬三、面向字节流
TCP使用了多种机制来保证数据的可靠性，其中之一就是面向字节流。通过将数据拆分成字节流，TCP可以跟踪和管理每个字节的传输状态。TCP会对每个字节进行编号，以便在传输过程中检测和纠正任何丢失、重复、失序或损坏的字节。
面向字节流的特性使得TCP能够提供可靠的数据传输，确保数据按照发送的顺序和准确的内容被接收方接收到。
🏀粘包问题
面向字节流的情况下可能出现粘包问题：粘包粘的是应用层数据包
通过TCP的read/write的数据，都是TCP报文的载荷（也就是应用层数据），发送方一次性是可以发送多个应用层数据的。但是在接收的时候，是要对这些应用层数据进行区分，区分从哪里到哪里是一个数据报。如果我们没有设计到的就就有可能出现发送了2个包，但是只读取了1.5个包的bug。
应用层的解决方式：
- 引用分隔符来区分包和包之间的边界。
- 引用包长度来区分包和包之间的边界。
补充一点：粘包问题不仅仅是在TCP协议中存在，只要是面向字节流的机制（比如说文件）都存在粘包这样的问题。解决方式可以是使用分隔符的方式，也可以是使用长度的方式，无论是哪种方式，本质上都是为了区分包和包之间的边界。我们在自定义应用层协议的时候可以使用这样的思想来解决问题。
🐬四、TCP异常情况的处理
网络有时候不稳定，会有很多种情况导致网络出现故障，这很有可能会导致TCP连接不能正常工作。
- 情况一：进程崩溃
如果进程崩溃或异常终止，操作系统会检测到该进程的退出，并释放该进程相关的资源，包括进程控制块（PCB）和文件描述符（这相当于调用了socket.close()，注意socket在系统内核中也是一个文件，也会被放到文件描述符表中），崩溃这一方就会发送FIN，然后进一步三次握手四次挥手，之后连接就正常释放了。此时TCP的处理和进程正常退出没有什么太大区别。
- 情况二：主机关机（正常步骤的关机）
主机正常关机的话就会尝试终止所有进程（这是一个强制终止进程的过程），这和情况一的进程崩溃处理方式是一样的。当然主机关机的时候，会有一定的关机时间，在这个时间内，四次挥手有没有完成我们是不确定的，可能挥完也可能没有挥完，如果四次挥手没有完成的话也没关系。（如下图：）
- 情况三：主机掉电（突发的，比如说拔电源，根本没有反应时间）
TCP协议中虽然已经有了心跳包的支持，但是我们作为开发者往往需要在应用程中重新实现心跳包。因为TCP协议中的心跳包周期太长了，在高并发的场景下我们甚至是需要毫秒级别的心跳包，以便我们能够在更短的时间内发现某个服务器的问题。
- 情况四：网线断开
这里发生的情况和情况三（即主机掉电）是类似的。网线断开之后，这里假设A是发送方的话，A发生的情况和上述主机掉电的第一种情况（即没有ACK->超时重传->复位报文以重置连接->释放连接）；而B发生的情况是主机掉电的第二种情况（B这边会通过发送心跳包发现A已经没法建立通信了，进一步的就会释放连接）。
本文到这里就结束了，希望友友们可以支持一下一键三连哈。嗯，就到这里吧，再见啦！！！