reference:
[1]
tcp為了提高頻寬利用率和吞吐量，做了各種優化。比如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，第二個包就不會立即傳送出去。兩邊相互等。這就是效能問題的核心原因。
TCP效能優化
在講這個tcp傳輸資料優化這塊前，希望大家對tcp協議的三次握手要很熟悉哈，如果不熟悉，可以看我之前寫的這篇部落格 如果我們都很清楚三次握手過程，我就可以開始講第乙個優化方案 有一點我們必須清楚，就是在tcp是在三次握手之後才開始真正傳輸資料的 tcp的每次握手都需要耗費1.5個rtt時間，即1.5...
TCP與效能優化
tcp的可優化點 1.tcp三次握手增加了整整一次的往返時間 2.tcp慢啟動將被應用到每乙個新連線 3.tcp流量及擁塞控制會影響所有的連線吞吐量 4.tcp的吞吐量由當前擁塞視窗大小控制 結論 現代tcp連線的資料傳輸速度,往往受到接收端和傳送端之間往返時間的限制,在大多數情況下tcp的瓶頸是延...
Web 效能優化 TCP
原文 tcp 負責在不可靠的傳輸通道之上提供可靠的抽象層，向應用層隱藏了大多數網路通訊的複雜性能，比如丟包重發 按需傳送 擁塞控制及避免 資料完整，等等。採用 tcp 資料流可以確保傳送的所有位元組能夠完整地被接收到，而且客戶端的順序也一樣。但是 tcp 設計並未過多顧及時間，由此給瀏覽器 web ...