延迟应答
在TCP中，有确认应答机制以保证数据的可靠传输，但是是不是接收方收到数据就立即返回ACK应答呢，如果是这样，这时候的缓冲区中接受的数据还没能够处理，缓冲区的剩余大小就是窗口大小。
在收到数据以后并不立即返回确认应答，延迟一会，等待缓冲区中数据被处理，那么剩余的缓冲区就会大些——这是延迟应答。
如果接受数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。那是因为刚接受完数据，缓冲区已满。当某个接收端收到这个小窗口的通知以后，会以它为上限发送数据，从而又降低了网络的利用率，为此引入了延迟应答机制。
- 假设接受端缓冲区为1M，一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；
- 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
- 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
- 如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；
一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高，我们的目标是在保证网络不拥堵的情况下尽量提高传输效率；
那么所有的包都可以延迟应答吗？
不是的，与以下有关：
- 数量限制：每隔N个包就应答一次；
- 时间限制：超过最大延迟时间就应答一次；
具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms;
在系统中，有一个固定的定时器每隔200ms会来检查是否需要发送ACK包，这样做有两个目的。
- 1.这样做的目的是ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了，可以降低网络流量；
- 2.如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息，这样做，可以避免大量的ACK以一个单独的TCP包发送，减少了网络流量。
捎带应答
根据应用层协议，发送出去的消息到达对端，对端进行处理之后，会返回一个回执。即在很多情况下，客户端服务器在应用层也是“一发一收”的，意味着客户端给服务器说了“How are you”，服务器也会给客户端回一个“Fine，thank you”；
例子有：电子邮件协议的AMTP或POP、文件传输协议FTP中的连接控制部分等，例如远程登录中针对输入的字符进行回送校验也是对发送消息的一种回执。在此类通信中，TCP的确认应答和回执数据可以通过一个包发送，这种方式叫做捎带应答。通过这种机制，可以使收发的数据量较减少。
另外接受数据以后如果立刻返回数据，就无法实现捎带应答，所以是在延迟应答的基础上，进行的捎带应答。延迟确认应该是能够提高网络利用率从而降低计算机处理负荷的一种较优的处理机制。
那么这个时候ACK就可以搭顺风车了，和服务器回应的“Fine，thank you”一起回给客户端。
捎带应答是指在同一个TCP包中即发送数据又发送确认应答的一种机制。由此，网络的利用率会提高，计算机的负荷也会减轻。不过，确认应答必须等到应用处理完数据并将作为回执的数据返回为止，才能进行捎带应答。