一不當心，陷入TCP的性能問題

1、現象

　　在一次訪問請求nginx中，一般只須要幾毫秒的RT，但當請求數據達到某一個數值時，rt明顯提升，甚至超過了300毫秒。　

2、問題的緣由

　 你們都知道，TCP爲了提升帶寬利用率和吞吐量，作了各類優化。好比delay ack和Nagle算法。就是這樣的一些優化使用不慎，致使陷入性能問題。接下來就先分別說說delay ack和Nagle算法。

• 什麼是delay ack

　　就以咱們的Nginx爲例吧。nginx收到請求後，當即返回一個ack收到確認包。這個包沒有隻有消息頭沒有任何數據內容。這就致使一個明顯的問題：帶寬利用率比較低效。那有沒有辦法能夠優化呢？有，就是delay ack。怎麼作呢？就是Nginx收到數據不要着急發送ack包，而是等一段時間好比40毫秒，若是這40毫秒內有數據要發送給client。那麼這個ack就能夠打這趟順風車了，從而節省資源。若是40毫秒內沒數據發送給client呢，沒辦法，到了40毫秒也必須發送ack包。由於client覺得丟包重傳的代價更大。

　　還有一種狀況就是，nginx收到數據在延緩等待發送ack包時，又收到client的一個數據包。這時nginx會把兩個ack包合併爲一個ack包回覆給client。

• 什麼是Nagle算法

　　在發送數據包時，若是數據包小於MSS(最大分段大小)，則會去判斷是否有已發出去的包尚未ack，若是有則不着急發送，等等前面的包收到回覆再發送。

• 性能問題關鍵點，client端啓動Nagle，server端啓動delay ack

　　假如client發送一個http請求個server。這個請求時1600byte，MSS是1460byte。那麼就會分紅兩個tcp包，第一個1460byte，剩下的140byte放在第二個包。第一個包發送到server時，因爲server開啓了delay ack，因此沒有當即ack，又由於server沒有收到完整的http請求包，因此也沒有當即進行http response，這就致使ack會一直等到40毫秒的delay時間。其實若是client當即發送第二個包，server收到後當即作出http response也不會有問題。問題時client啓動了Nagle算法，第一個包沒有收到ack，第二個包就不會當即發送出去。兩邊相互等。這就是性能問題的核心緣由。