javaEE 初阶 — 传输层 TCP 协议中的延迟应答与捎带应答

淡淡的烟草味﹌ 2023-10-04 21:26 43阅读 0赞

#### 文章目录 ####

*  1. 延迟应答
 *  2. 捎带应答

**TCP 工作机制**：

[确认应答机制][Link 1]

[超时重传机制][Link 2]

[连接管理机制][Link 3]

[滑动窗口][Link 4]

[流量控制与拥塞控制][Link 5]

## 1. 延迟应答 ##

**延时应答** 也是提升效率的机制，也是在滑动窗口基础上搞点事情。

滑动窗口的关键是让窗口大小大一点，传输的速度就会快一点。因此，延时应答要做的就是，  
在接收方能够处理的情况下，尽可能的把窗口大小放大一点。

延时应答 在收到数据后，不是立即返回 ACK ，而是会稍微等待一会儿再返回。  
在这等待的时间里，接收方的应用程序，就能够把接收缓冲区的数据给消费一波，此时接收缓冲区里的剩余空间就更大了。  
  
剩余空间更大了，这个时候可以把窗口大小进一步的扩大，传输的速率进一步提高了。  
  
![41d066299e9141dfbf6f7d475335f7a3.png_pic_center][]  
实际上延时应答采取的方式，就是在滑动窗口下， ACK 不再每一条数据都返回了，比如是此处是隔一条返回一次ACK。

实际上的剩余空间大小，变化是一个复杂的过程，既取决于发送方的发送也取决于接收方的处理。

## 2. 捎带应答 ##

捎带应答也是提高效率的方式，是在延时应答的基础上引入的。

服务器客户端程序，最典型的模型就是 “一问一答”，也就是业务上的请求和响应。

![6f24dedf56a646fdad3d34ea38eba031.png_pic_center][]  
  
这里的 “我看看” ACK 是内核立即返回的，而 “11:30” 这个 ACK 是业务上的响应，是在李四的应用程序里发送的。

这两个本来是不同的时机，但是 TCP 存在着 延时应答。  
由于延时应答机制，导致等待 ACK 的过程中，李四就要给 张三 发送业务数据了，  
就可以让业务数据捎带上 “我看看” 这个 ACK 一起发送过去了。

效果如下图。  
  
![b159a329342c4cf5ace5d1984c01b4c7.png_pic_center][]  
  
**与三次握手的的区别**  
  
不来是不同的时机，在延时应答下可能成为相同的时机，如果时机是相同的就可以合二为一，而三次握手本来就是相同的时机，

换句话就是，三次握手一定会合二为一，但捎带应答只是有一定的概率，而延时应答提高了这个概率。  
  
这个捎带应答比较像中午吃饭的时候，自己突然有一点事要解决，然后就要等待一会儿。  
这个时候，看到张三要去吃饭，那么就让他帮忙带一份。

[Link 1]: https://blog.csdn.net/m0_63033419/article/details/128970343?spm=1001.2014.3001.5501
[Link 2]: https://blog.csdn.net/m0_63033419/article/details/128981959?spm=1001.2014.3001.5501
[Link 3]: https://blog.csdn.net/m0_63033419/article/details/129016700?spm=1001.2014.3001.5501
[Link 4]: https://blog.csdn.net/m0_63033419/article/details/129032826?spm=1001.2014.3001.5501
[Link 5]: https://blog.csdn.net/m0_63033419/article/details/129032948?spm=1001.2014.3001.5501
[41d066299e9141dfbf6f7d475335f7a3.png_pic_center]: https://img-blog.csdnimg.cn/41d066299e9141dfbf6f7d475335f7a3.png#pic_center
[6f24dedf56a646fdad3d34ea38eba031.png_pic_center]: https://img-blog.csdnimg.cn/6f24dedf56a646fdad3d34ea38eba031.png#pic_center
[b159a329342c4cf5ace5d1984c01b4c7.png_pic_center]: https://img-blog.csdnimg.cn/b159a329342c4cf5ace5d1984c01b4c7.png#pic_center