當時的具體定位過程如下：先試圖用strace跟蹤客戶端進程，但奇怪的是：一旦strace attach上進程，所有收發又都正常，不會有阻塞現象，一旦退出strace，問題重現。經同事提醒，很可能是strace改變了程序或系統的某些東西(這個問題現在也還沒搞清楚)，於是再用tcpdump抓包分析，發現Server後端在回現應答包後，Client端並沒有立即對該數據進行ACK確認，而是等待了近40毫秒後才確認。經過Google，並查閱《TCP/IP詳解卷一:協議》得知，此即TCP的延遲確認(Delayed Ack)機制。

其解決辦法如下：在recv系統調用後，調用一次setsockopt函數，設置TCP_QUICKACK。最終代碼如下：

char sndBuf[132];

char rcvBuf[132];

while (1) {

for (int i = 0; i < N; i++) {

    send(fd, sndBuf, 132, 0);

    ...    

}

for (int i = 0; i < N; i++) {

    recv(fd, rcvBuf, 132, 0); 

    setsockopt(fd, IPPROTO_TCP, TCP_QUICKACK, (int[]){1}, sizeof(int)); 

}

sleep(1);
 

}
案例二：在營銷平臺內存化CDKEY版本做性能測試時，發現請求時耗分布異常：90%的請求均在2ms以內，而10%左右時耗始終在38-42ms之間，這是一個很有規律的數字：40ms。因為之前經歷過案例一，所以猜測同樣是因為延遲確認機制引起的時耗問題，經過簡單的抓包驗證後，通過設置TCP_QUICKACK選項，得以解決時延問題。

延遲確認機制
在《TCP/IP詳解卷一：協議》第19章對其進行原理進行了詳細描述：TCP在處理交互數據流(即Interactive Data Flow，區別於Bulk Data Flow，即成塊數據流，典型的交互數據流如telnet、rlogin等)時，采用了Delayed Ack機制以及Nagle算法來減少小分組數目。

書上已經對這兩種機制的原理講的很清晰，這裏不再做復述。本文後續部分將通過分析TCP/IP在Linux下的實現，來解釋一下TCP的延遲確認機制。

1.為什麽TCP延遲確認會導致延遲？
其實僅有延遲確認機制，是不會導致請求延遲的(初以為是必須等到ACK包發出去，recv系統調用才會返回)。一般來說，只有當該機制與Nagle算法或擁塞控制(慢啟動或擁塞避免)混合作用時，才可能會導致時耗增長。我們下面來詳細看看是如何相互作用重慶×××源碼下載聯系方式：QQ：2747044651 網址【http://zhengtuwl.com】

Linux下TCP延遲重慶時 時 彩源碼下載確認(Delayed Ack)機制導致的時延問題分析