简介
TCP延迟确认是由一些实现采用的技术，努力提高网络性能的传输控制协议 。从本质上讲，几个应答响应可能结合在一起，成一个响应，减少协议开销 。然而，在某些情况下，该技术可以降低应用程序的性能。
方法和优势
RFC 1122中描述，主机可能延迟发送ACK响应到500毫秒。此外，收到一个完整大小的TCP报文段，就要发送ACK响应 。
延迟ACK可以给应用程序的机会，一起发送更新的TCP接收窗口，ACK和应用程序的即时响应。如某些协议，远程登录，通过合并ACK，tcp窗口更新和应用程序的响应为一个报文段，延迟ACK可以减少服务器发送的响应的数据为3倍
问题
在某些应用程序和配置交互时，延迟ACK引入额外的等待时间可能会导致进一步延误。
如果Nagle算法是由发送方使用，数据将会排队，直到收到一个ACK确认 。如果发件人不发送足够的数据来填充最大的段大小（例如，如果它执行两个小写入一个阻塞读），然后发件人的应用程序将会暂停，直到ACK延迟超时 。
例如，考虑一个情况，其中鲍勃是将数据发送到卡罗尔,鲍勃的套接字层中，要发送的有效数据不够一个完整的数据包。根据Nagle算法，它不会被发送，直到收到一个ACK确认已发送的数据。同时，卡罗尔的应用层不会发送一个响应，直到它得到的所有数据。如果卡罗尔是使用延迟ACK，她套接字层将不会发送一个ACK，直到最后超时才会发送ACK。
如果应用程序是在较小的块中传输数据，并期望定期确认回复，可能会出现这种负面的效果。为了防止这种延迟，应用层需要不断发送数据，而无需等待确认回复。另外，发送端的应用程序可能会禁用Nagle算法。