1 優化目標
降低網路擁塞，總是有效嗎？并不是，它們有特定的使用場景，
2 Nagle演算法和Delayed ACK演算法
在TCP/IP協議中，每一個報文都是由報文頭（header）和報文體（payload）組成，就像我們網上買的書到了，書是裝在一個袋子里，然后會貼一個標簽，上面包含了一些關鍵資訊，比如：發件人姓名、發件人電話、發件人地址、收件人姓名、收件人電話、收件人地址、物品簡介，這里書類似報文體，標簽上的關鍵資訊類似報文頭，
如果一個報文的報文體尺寸非常小，甚至比報文頭還小，沒有有效利用帶寬，在網路流量很大是，這種報文會給網路帶來更多的負擔，比如你在同一家網店買30本書，如果分為30個快遞郵寄給你，那么店家會下單30次，快遞員會分揀送貨30次，你也會拆30次快遞，整個流程就會很低效，快遞成本也會增加很多，因此最好將這30本書合并為一個快遞郵寄給你，TCP報文頭最多可占用40 Byte，每次只發送1 Byte的資料的程式是很常見的，如果系統立刻發送這種報文，那么一個報文總共有41 Byte，但是只有1 Byte是應用要發送的資料，我們的卡車本次只運輸了一雙拖鞋，這太低效了，會增加交通擁堵，發送報文時，Nagle演算法會合并同一TCP流中的多個報文，保證合并后報文的報文頭與報文體的比例處于合理范圍，提高帶寬利用效率，降低網路擁塞，Nagle演算法延遲了報文的發送，增加了延遲，對于一些強調互動的場景，會降低用戶體驗，
延遲ACK（Delayed ACK）是降低擁塞的另一種方案，在TCP協議中，報文接收方會對收到的每個bit發送確認，就像我們在淘寶上確認識訓一樣，發送方才會繼續發送后續的報文，如下圖，ACK報文只有報文頭，報文體為0 Byte，如果報文特別多，頻繁進行確認，大量的ACK報文占用了帶寬，造成網路擁塞，延遲ACK的策略就是設定一個定時器（200~500ms），延遲ACK收到的報文，待定時器超時后對這些報文一次性進行批量ACK，有缺點，有些場景下會增加程式網路延遲，比如這條TCP流中報文不是很多，這個策略我們收快遞時也會使用，雙11買了很多東西，一般不會收到一個后立馬就確認識訓，而是等差不多都收到后的某一天集中確認識訓，省事兒，
然而這兩種演算法并不適合一起協作，延遲ACK演算法延遲了ACK的發送，但是Nagle演算法卻在等待ACK報文，以便繼續發送其他報文，
3 Socket選項
配置TCP_NODELAY選項可以關閉Negal演算法，內核就會立刻將Socket快取中的資料交給網卡，配置TCP_QUICKACK選項可以關閉延遲ACK機制，收到報文后，會立刻發送ACK報文，
4 如何確定是否需要打開TCP_NODELAY選項（關閉Negal演算法）？
對于一些強調吞吐量而不是延遲的非互動式場景，比如大檔案傳輸，關閉TCP_NODELAY選項，即使用Negle演算法可能是一個好的選擇，
像網路游戲、即時聊天、流媒體等高度互動式的場景，延遲是衡量服務質量的一個重要指標，因此打開TCP_NODELAY選項對提升用戶體驗可能會更有幫助，
總的來說，沒有一個非常有效的規則來判斷是否需要打開TCP_NODELAY選項，最好在做出決定前有一些基準測驗資料（打開vs關閉），
5 參考資料
https://www.extrahop.com/company/blog/2016/tcp-nodelay-nagle-quickack-best-practices/
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/259905.html
標籤：Linux