轉發用於收藏學習：https://blog.csdn.net/zx714311728/article/details/53997508/

通常TCP在接收到資料時並不立即傳送ACK，相反，它推遲傳送，以便將ACK與需要沿該方向傳送的資料一起傳送（有時稱這種現象為資料捎帶ACK），這樣做的目的是儘量減少發往網路的報文，以提高傳輸的效率，節省網路資源。

捎帶ACK的意思是，當接收端接收到TCP報文段後，並不立即傳送ACK報文，而是等上一段時間，如果這段時間裡該主機有資料要傳送到遠端主機，就將該資料捎帶上ACK一起傳送過去，很明顯，這樣可以減少傳輸開銷。為了防止產生超時重傳，絕大多數情況下，這個等待時間為200ms，超過了200ms，如果沒有資料要一起傳送，就直接傳送ACK報文。

捎帶ACK的策略一般也只有在互動性比較高的應用中才會使用，對於成塊資料流，一般大多數應用程式不會同時在兩個方向上傳送資料。

經受時延的確認工作過程

下圖清晰的展示了Delay 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的倍數。

————————————————
版權宣告：本文為CSDN博主「A_YT」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/zx714311728/article/details/53997508/