通常TCP在接收到數據時並不立即發送ACK，相反，它推遲發送，以便將ACK與需要沿該方向發送的數據一起發送（有時稱這種現象爲數據捎帶ACK），這樣做的目的是儘量減少發往網絡的報文，以提高傳輸的效率，節省網絡資源。
捎帶ACK的意思是，當接收端接收到TCP報文段後，並不立即發送ACK報文，而是等上一段時間，如果這段時間裏該主機有數據要發送到遠程主機，就將該數據捎帶上ACK一起發送過去，很明顯，這樣可以減少傳輸開銷。爲了防止產生超時重傳，絕大多數情況下，這個等待時間爲200ms，超過了200ms，如果沒有數據要一起發送，就直接發送ACK報文。
捎帶ACK的策略一般也只有在交互性比較高的應用中才會使用，對於成塊數據流，一般大多數應用程序不會同時在兩個方向上發送數據。
下圖清晰的展示了Delay ACK的工作過程：
我們一起來看一個實際環境中的Delay ACK實例：
在實際工作環境下，我們做應用性能分析時，有時會遇到應用程序處理時間較長（一般超過200ms）時，我們經常會看到服務器先向對端發送了TCP ACK報文（無應用層數據），這個確認的報文一般就是TCP的Delay ACK，如下圖所示：
我們在遇到此類現象時，千萬不能簡單的將此處的Delay ACK當成應用響應時間。
Delay ACK的可能影響
另外需要注意的是，Delay ACK雖然能夠提高傳輸效率，節約網絡資源，但是在某些情況下，其會給應用帶來難以想象的延時問題（假想一下這樣的場景：服務器單向向客戶端間歇發送一些數據，但是客戶端無應用數據需要提交給對方，此時，如果客戶端每收到對端包含有應用字段的報文時，都等待200ms纔對其進行確認，那麼如果服務器與客戶端的交互次數爲1000的話，那麼整個應用交易或應用會話將要持續1000*200=200S，而200秒對於絕大多數的應用來說是不可接受的）。
Delay ACK補充
1，絕大多數實現採用的時延爲200ms，也就是說，TCP將以最大200ms的時延等待是否有數據一起發送，但是這個200ms的值並不是必須的，開發者可以根據自己的需要來設定這個數值，因此，我們在實際工作過程如果發現非200ms但是工作機制與Delay ACK一致的TCP交互過程，那基本上就是Delay ACK機制了。
2，如果連續收到對端兩個數據段，則一般立即迴應ACK數據包，如下圖所示：
如下圖所示：
報文3,6,9，叫做經受時延的ACK，經受時延的ACK通常定時器被設計位200ms，所有6報文的發生時間-3報文的發生時間，大約是200ms，這是bsdi端的，另一端的數據，爲什麼沒有經受時延的ACK，因爲在定時器到時的之前，正好有發送的數據需要發送，因此沒有單獨的經受時延的ACK發送
總結：
經受時延的確認的思想就是，如果A端接收到B端的數據，A端先等待一段時間。下面就要分幾種情況：
1.如果在等待的這段時間內，A端突然有數據要發送給B端，則A端立刻將數據連同之前的ACK一起發給B端。
2.如果在等待的這段時間內，A端又接收到B端發過來的數據了，則A端也是立刻發送ACK給B端，注意此時是只發送一個ACK。“如果連續收到對端兩個數據段，則一般立即迴應ACK數據包”這句話就是這個意思。
3.如果等待的這段時間超出了內核的時延定時器200ms，也就是發生了定時器的溢出，則立刻發送一個ACK給B端，注意此時是隻發送一個ACK。其中200ms的算法，是這次溢出與上次溢出的時間間隔爲200ms的倍數。
