問題描述
某個PHP服務通過Nginx將后面的tair封裝了一下，讓其他應用可以通過http協議訪問Nginx來get、set 操作tair
上線后測試一切正常，每次操作幾毫秒，但是有一次有個應用的value是300K，這個時候set一次需要300毫秒以上。 在沒有任何并發壓力單線程單次操作也需要這么久，這個延遲是沒有道理和無法接受的。
是因為TCP協議為了做一些帶寬利用率、性能方面的優化，而做了一些特殊處理。比如Delay Ack和Nagle算法。
這個原因對大家理解TCP基本的概念后能在實戰中了解一些TCP其它方面的性能和影響。
由我前面的TCP介紹文章大家都知道，TCP是可靠傳輸，可靠的核心是收到包后回復一個ack來告訴對方收到了。
來看一個例子：
image.png
截圖中的Nignx(8085端口），收到了一個http request請求，然后立即回復了一個ack包給client，接著又回復了一個http response 給client。大家注意回復的ack包長度66，實際內容長度為0，ack信息放在TCP包頭里面，也就是這里發了一個66字節的空包給客戶端來告訴客戶端我收到你的請求了。
這里沒毛病，邏輯很對，符合TCP的核心可靠傳輸的意義。但是帶來的一個問題是：帶寬效率不高。那能不能優化呢？
這里的優化就是delay ack。
delay ack是指收到包后不立即ack，而是等一小會（比如40毫秒）看看，如果這40毫秒以內正好有一個包（比如上面的http response）發給client，那么我這個ack包就跟著發過去（順風車，http reponse包不需要增加任何大小），這樣節省了資源。 當然如果超過這個時間還沒有包發給client（比如nginx處理需要40毫秒以上），那么這個ack也要發給client了（即使為空，要不client以為丟包了，又要重發http request，劃不來）。
假如這個時候ack包還在等待延遲發送的時候，又收到了client的一個包，那么這個時候server有兩個ack包要回復，那么os會把這兩個ack包合起來立即回復一個ack包給client，告訴client前兩個包都收到了。
也就是delay ack開啟的情況下：ack包有順風車就搭；如果湊兩個ack包自己包個車也立即發車；再如果等了40毫秒以上也沒順風車，那么自己打個車也發車。
截圖中Nginx沒有開delay ack，所以你看紅框中的ack是完全可以跟著綠框（http response）一起發給client的，但是沒有，紅框的ack立即打車跑了
if there is new data to send
if the window size >= MSS and available data is >= MSS
send complete MSS segment now
else
if there is unconfirmed data still in the pipe
enqueue data in the buffer until an acknowledge is received
else
send data immediately
end if
end if
end if
這段代碼的意思是如果要發送的數據大于 MSS的話，立即發送。
否則：
看看前面發出去的包是不是還有沒有ack的，如果有沒有ack的那么我這個小包不急著發送，等前面的ack回來再發送
我總結下Nagle算法邏輯就是：如果發送的包很小（不足MSS），又有包發給了對方對方還沒回復說收到了，那我也不急著發，等前面的包回復收到了再發。這樣可以優化帶寬利用率（早些年帶寬資源還是很寶貴的），Nagle算法也是用來優化改進tcp傳輸效率的。
如果client啟用Nagle，并且server端啟用了delay ack會有什么后果呢？
假如client要發送一個http請求給server，這個請求有1600個bytes，握手的MSS是1460，那么這1600個bytes就會分成2個TCP包，第一個包1460，剩下的140bytes放在第二個包。第一個包發出去后，server收到第一個包，因為delay ack所以沒有回復ack，同時因為server沒有收全這個HTTP請求，所以也沒法回復HTTP response（server等一個完整的HTTP請求，或者40毫秒的delay時間）。client這邊開啟了Nagle算法（默認開啟）第二個包比較小（140
這就是悲劇的核心原因。
這個案例來自：http://www.stuartcheshire.org/papers/nagledelayedack/
案例核心奇怪的問題是，如果傳輸的數據是 99,900 bytes，速度5.2M/秒；
如果傳輸的數據是 100,000 bytes 速度2.7M/秒，多了10個bytes，不至于傳輸速度差這么多。
原因就是：
99,900 bytes = 68 full-sized 1448-byte packets, plus 1436 bytes extra
100,000 bytes = 69 full-sized 1448-byte packets, plus? 88 bytes extra
99,900 bytes：
68個整包會立即發送（都是整包，不受Nagle算法的影響），因為68是偶數，對方收到最后兩個包后立即回復ack（delay ack湊夠兩個也立即ack），那么剩下的1436也很快發出去（根據Nagle算法，沒有沒ack的包了，立即發）
100,000 bytes:
前面68個整包很快發出去也收到ack回復了，然后發了第69個整包，剩下88bytes（不夠一個整包）根據Nagle算法要等一等，server收到第69個ack后，因為delay ack不回復（手里只攢下一個沒有回復的包），所以client、server兩邊等在等，一直等到server的delay ack超時了。
挺奇怪和挺有意思吧，作者還給出了傳輸數據的圖表：
這是有問題的傳輸圖，明顯有個平臺層，這個平臺層就是兩邊在互相等，整個速度肯定就上不去。
如果傳輸的都是99,900，那么整個圖形就很平整：
服務寫好后，開始測試都沒有問題，rt很正常（一般測試的都是小對象），沒有觸發這個問題。后來碰到一個300K的rt就到幾百毫秒了，就是因為這個原因。
另外有些http post會故意把包頭和包內容分成兩個包，再加一個Expect參數之類的，更容易觸發這個問題。
這是修改后的C代碼
struct curl_slist *list = NULL;
//合并post包
list = curl_slist_append(list, "Expect:");
CURLcode code(CURLE_FAILED_INIT);
if (CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_URL, oss.str().c_str())) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_TIMEOUT_MS, timeout)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, &write_callback)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_POST, 1L)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, pooh.sizeleft)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_READFUNCTION, read_callback)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_READDATA, &pooh)) &&
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L)) && //1000 ms curl bug
CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_HTTPHEADER, list))
) {
//這里如果是小包就不開delay ack，實際不科學
if (request.size() < 1024) {
code = curl_easy_setopt(curl, CURLOPT_TCP_NODELAY, 1L);
} else {
code = curl_easy_setopt(curl, CURLOPT_TCP_NODELAY, 0L);
}
if(CURLE_OK == code) {
code = curl_easy_perform(curl);
}
上面中文注釋的部分是后來的改進，然后經過測試同一個300K的對象也能在幾毫米以內完成get、set了。
尤其是在Post請求將HTTP Header和Body內容分成兩個包后，容易出現這種延遲問題。
這個問題確實經典，非常隱晦一般不容易碰到，碰到一次決不放過她。文中所有client、server的概念都是相對的，client也有delay ack的問題。 Nagle算法一般默認開啟的
參考文章:
https://access.redhat.com/solutions/407743
http://www.stuartcheshire.org/papers/nagledelayedack/
https://en.wikipedia.org/wiki/Nagle%27s_algorithm
https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
企業級互聯網架構Aliware，讓您的業務能力云化：https://www.aliyun.com/aliware
