簡介
TCP延遲確認是由一些實現采用的技術，努力提高網絡性能的傳輸控制協議 。從本質上講，幾個應答響應可能結合在一起，成一個響應，減少協議開銷 。然而，在某些情況下，該技術可以降低應用程序的性能。
方法和優勢
RFC 1122中描述，主機可能延遲發送ACK響應到500毫秒。此外，收到一個完整大小的TCP報文段，就要發送ACK響應 。
延遲ACK可以給應用程序的機會，一起發送更新的TCP接收窗口，ACK和應用程序的即時響應。如某些協議，遠程登錄，通過合並ACK，tcp窗口更新和應用程序的響應為一個報文段，延遲ACK可以減少服務器發送的響應的數據為3倍
問題
在某些應用程序和配置交互時，延遲ACK引入額外的等待時間可能會導致進一步延誤。
如果Nagle算法是由發送方使用，數據將會排隊，直到收到一個ACK確認 。如果發件人不發送足夠的數據來填充最大的段大小（例如，如果它執行兩個小寫入一個阻塞讀），然后發件人的應用程序將會暫停，直到ACK延遲超時 。
例如，考慮一個情況，其中鮑勃是將數據發送到卡羅爾,鮑勃的套接字層中，要發送的有效數據不夠一個完整的數據包。根據Nagle算法，它不會被發送，直到收到一個ACK確認已發送的數據。同時，卡羅爾的應用層不會發送一個響應，直到它得到的所有數據。如果卡羅爾是使用延遲ACK，她套接字層將不會發送一個ACK，直到最后超時才會發送ACK。
如果應用程序是在較小的塊中傳輸數據，並期望定期確認回復，可能會出現這種負面的效果。為了防止這種延遲，應用層需要不斷發送數據，而無需等待確認回復。另外，發送端的應用程序可能會禁用Nagle算法。