延迟应答

当发送端发送数据给接收端了以后，按道理接收端的内核会立即返回ACK（应答报文）给发送端，而且ACK（应答报文）中不仅含有确认序号，还有接收端接收缓冲区的剩余空间大小，当发送端收到ACK（应答报文）后便可以根据接收端接收缓冲区的剩余空间大小来决定下一轮的窗口大小

要是接收端一收到请求就返回ACK（应答报文）的话，此时接收端接收缓冲区的剩余空间大小就比较小，此时发送端下一轮的窗口大小也会比较小，效率就比较低，但是实际上在数据传输的这段过程中，接收端接收缓冲区的剩余空间大小可能会被释放一部分，发送端的窗口大小理应比较大。

所以就有延迟应答的机制，在接收端收到传来的请求以后，并不立即就返回ACK（应答报文）给发送端，而是等待一端时间（程序员规定的时间）再返回ACK（应答报文）给发送端，在等待的这段时间中，接收端接收缓冲区的剩余空间就可能被释放了一部分，此时返回给发送端就可以让发送端下一轮的窗口大小更大一些，效率就更高一些

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高，我们的目标是在保证网络不拥塞的情况下尽量的提高传输效率

所有的包都能延时应答吗？

肯定不是，延迟应答有对应的限制

1.数量限制（主要针对滑动窗口）：每隔N个包就应答一次（因为滑动窗口是批量传输数据，所以在接收ACK应答报文时，后面接收的ACK应答报文能够确认前面发送的数据是成功接收的，所以即使少发几个ACK应答报文也可以，这样的话返回ACK应答报文的频率变低，给了接收端更多处理数据的时间，每次发送端的端口都能更大一些）

2.时间限制（普通一问一答的发送数据）：超过最大的延迟时间就回应一次（在等待的这段时间就给了接收端更多处理数据的时间，这样下一轮发送端的窗口就更大一些，效率就更高一些）