TCP/IP的TCP調優優化

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/