dw织梦做网站soe搜索优化
目录
一. 延时应答
二. 捎带应答
一. 延时应答
延时应答也是基于滑动窗口的一种提升传输效率的方式（减少ACK数量）
接收方收到数据之后，不会立刻返回一个ACK确认报文，而是等一会再返回ACK报文
这样做的好处？
1）减少窗口大小的变化频率
在发送方中，存在接收缓冲区，发送方发送的数据会先存储在接受缓冲区中，如果发送方不停发送数据，接收方不断的取出数据，并返回ACK确认报文，这样会导致ACK返回的窗口大小不停的变动
2）增大返回的窗口大小
在延迟的过程中，接收方会不断的从缓冲区取出数据，最后导致缓冲区中的空余空间会变大，返回的ACK报文中的窗口大小也会变大
3）减少网络堵塞，节省开销
将多个ACK应答报文合并成一个ACK应答报文，返回一个较大值的序号（表示这个序号之前的数据已经全部收到了）
二. 捎带应答
如果说延时应答是通过减少ACK报文的数量提高效率，那么捎带应答就是增大报文数据提高效率
捎带应答是基于延时应答，扩展的机制
- 正常情况下，客户端和服务器的交互方式都是一问一答，发送方发送数据，接收方返回ACK，接收方发送响应，发送方返回ACK
- 接受方收到数据之后，会花费一定的时间计算响应
- 由于延时应答的机制，很有可以会出现返回ACK报文和发送响应的时间间隔很短
既然间隔时间很短，那自然而然就将ACK报文和响应数据进行了合并
- ACK报文中，本身也不携带载荷部分，所以合并不会出现冲突问题
- ACK报文中的确认序号和窗口大小，respond数据也不会涉及到，所以也不会出现冲突
捎带应答是不是一直存在？
- 捎带应答并不是一直存在的，只有ACK报文和数据报文之间的发送间隔很小（甚至重合），才会触发捎带应答
- 不管是短连接还是长连接都可能会出现捎带应答，取决于发送时间间隔
故因为延时应答和捎带应答机制的存在，可能会使四次挥手，合并为三次挥手