nagle算法發現的問題200ms延遲問題

TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。爲了儘可能的利用網絡帶寬，TCP總是希望儘可能的發送足夠大的數據。（一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據）。Nagle算法就是爲了儘可能發送大塊數據，避免網絡中充斥着許多小數據塊。
　　Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。 所謂“小段”，指的是小於MSS尺寸的數據塊，所謂“未被確認”，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。
　　Nagle算法的規則（可參考tcp_output.c文件裏tcp_nagle_check函數註釋）：

（1）如果包長度達到MSS，則允許發送；

（2）如果該包含有FIN，則允許發送；

（3）設置了TCP_NODELAY選項，則允許發送；

（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小於MSS）均被確認，則允許發送；

（5）上述條件都未滿足，但發生了超時（一般爲200ms），則立即發送。

以上來自百度；

上週組內分享的時候發現，對於一個很小的http請求（返回值只有10字節以內），耗時始終都在200ms以上，而且是每次都出現的問題。經過定位最後發現是nagle算法引致的。

HTTP/TCP：

默認情況下，發送數據採用Nagle 算法。這樣雖然提高了網絡吞吐量，但是實時性卻降低了，在一些交互性很強的應用程序來說是不允許的，使用TCP_NODELAY選項可以禁止Nagle 算法。

此時，應用程序向內核遞交的每個數據包都會立即發送出去。需要注意的是，雖然禁止了Nagle 算法，但網絡的傳輸仍然受到TCP確認延遲機制的影響。

通過設置TCP_NODELAY參數，就能避免發送小包出現200ms的延遲。是否啓用nagle算法，這個就要根據具體的業務去選擇了，很多公司會選擇搭建多套服務器，提供不同的服務，各個服務器根據業務需求確定是否採用nagle算法