【网络】详解TCP协议的延时应答和捎带应答
- 一. 延时应答
- 模型
- 二. 捎带应答
- 模型
- 再谈四次挥手
- 三. 异常处理
- 1.一方出现进程崩溃
- 2.一方出现关机（正常流程关机）
- 3.一方出现断电
- 4.网线断开
一. 延时应答
也是基于滑动窗口，想要尽可能的去提高效率。延时应答就是说，接收方收到数据之后，不立即返回ACK，而是要有一定的延迟。主要目的是为了给程序一些消耗数据的时间，使得返回的窗口尽可能大。
延时应答也不仅仅以时间为唯一的判断标准：
- 数量限制：每隔N个包就应答⼀次（可以减少返回ACK的次数，提高效率）;
- 时间限制：超过最⼤延迟时间就应答⼀次;
具体的数量和时间可以自己进行定义。
模型
这个模型展示了每两个数据包返回一个ACK的延时应答。
二. 捎带应答
基于延时应答，为了进一步的提高效率，引入了捎带应答的机制。不同于延时应答要增大窗口的目的，延时应答主要是去尽可能的合并一些能合并的数据包，从而提高效率。
模型
正常来说，服务器收到request之后会立即返回ACK，而response需要经过计算才能返回。但因为TCP有延时应答的特征，正好弥补了这个时间空隙。从而可以合并这两个数据包一起返回（合并只需要将response报文中的ACK标志位设置为1）。
再谈四次挥手
之前谈到四次挥手的中间两次有可能会合并，那什么时候会合并呢？在了解了延时应答和捎带应答这样的机制后，我们就应该知道，如果ACK（系统内核控制）和FIN（socket.close()控制）时间相差较短，满足了延时应答以及捎带应答合并两个报文的条件，就可以合并。
三. 异常处理
1.一方出现进程崩溃
TCP连接的生命周期，可以比进程长一些，即使出现进程崩溃，也能完成四次挥手断开连接。
2.一方出现关机（正常流程关机）
当主机触发关机操作时，会强制结束所有的进程，也会触发四次挥手，断开连接。关机的一方会向对方发送FIN，对端也会向关机的一方发送FIN，如果这个过程进行的比较快，就能正常完成。但是如果不快，对端发送的FIN就收不到ACK了（已经关机）。此时就会超时重传，重传几次没有结果，就会单方面释放连接。
3.一方出现断电
- 接收方断电：发送方就会 发现突然没有ACK了，就要重传，重传几次还是不行，就会尝试“复位”连接（RST），此时的RST也不会有回应，单方面断开连接。
- 发送方断电：接收方在阻塞等待发送方的信息，但是发送方断电了，那接收方就一直在等待吗？其实不然，接收方会周期性的发送“心跳包”（不携带数据的特殊的包）来确认发送方是否还存活。如果意识到对方挂了，也会单方面的释放连接。
4.网线断开
这就是 3 中 1 和 2 的结合了。
