一、現象
在一次訪問請求nginx中，通常只需要幾毫秒的rt，但當請求資料達到某乙個數值時，rt明顯提高，甚至超過了300毫秒。
二、問題的原因
大家都知道，tcp為了提高頻寬利用率和吞吐量，做了各種優化。比如delay ack和nagle演算法。就是這樣的一些優化使用不慎，導致陷入效能問題。接下來就先分別說說delay ack和nagle演算法。
就以我們的nginx為例吧。nginx收到請求後，立即返回乙個ack收到確認包。這個包沒有只有訊息頭沒有任何資料內容。這就導致乙個明顯的問題：頻寬利用率比較低效。那有沒有辦法可以優化呢？有，就是delay ack。怎麼做呢？就是nginx收到資料不要著急傳送ack包，而是等一段時間比如40毫秒，如果這40毫秒內有資料要傳送給client。那麼這個ack就可以打這趟順風車了，從而節省資源。如果40毫秒內沒資料傳送給client呢，沒辦法，到了40毫秒也必須傳送ack包。因為client以為丟包重傳的代價更大。
還有一種情況就是，nginx收到資料在延緩等待傳送ack包時，又收到client的乙個資料報。這時nginx會把兩個ack包合併為乙個ack包回覆給client。
在傳送資料報時，如果資料報小於mss(最大分段大小)，則會去判斷是否有已發出去的包還沒有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，第二個包就不會立即傳送出去。兩邊相互等。這就是效能問題的核心原因。
一不小心實現了RPC
隨著最近關注 cim 專案的人越發增多，導致提的問題以及 bug 也在增加，在修復問題的過程中難免 潔癖又上來了。看著一兩年前寫的東西總是懷疑這真的是出自自己手裡嘛？有些地方實在忍不住了便開始了漫漫重構之路。在開始之前先簡單介紹一下cim這個專案，下面是它的架構圖 簡單來說就是乙個 im 即時通訊系...
一不小心走上IT這條不歸路
博主已是畢業四年的工作者，回頭想想走過的路，感覺更多的是迷茫和漫無目的。現在是時候該認真考慮以後的路怎麼走，怎麼規劃了。踏進校園的第一天就開始迷茫了，大學的生活想必大多數人都深有體會吧 猶如高考之前煉獄般 缺少自由的困獸一下子脫了韁，回歸大自然。肆意的放縱，揮霍青春，好似對高考的報復。再加上對計算機...
一不小心，老司機又翻車了
這幾天一直忙著往proxmox集群裡邊遷移服務，進展還是比較順利。通過整合資源，兩個機櫃的伺服器，下架以後，就剩乙個櫃子了，後邊再遷移一下，還能下架一些舊的配置低的伺服器。因為機櫃電源的限制，迫不得已還得下架一台有公網ip的舊伺服器。為了保證可用性，臨時在一台有redis應用的伺服器上繫結了乙個公網...