TCP 中的兩個細節點

時間 2021-05-25

標籤程序員算法 shell 微信網絡 tcp 優化 spa 操作系統 code 欄目系統網絡简体版

原文原文鏈接

文章來源 cxuan 的本身公衆號：TCP 的兩個細節點程序員

公衆號不少硬核文章，求你們關注下呀～下面開始咱們本篇文章。算法

TCP 超時和重傳

沒有永遠不出錯誤的通訊，這句話代表着無論外部條件多麼完備，永遠都會有出錯的可能。因此，在 TCP 的正常通訊過程當中，也會出現錯誤，這種錯誤多是因爲數據包丟失引發的，也多是因爲數據包重複引發的，甚至多是因爲數據包失序 引發的。shell

TCP 的通訊過程當中，會由 TCP 的接收端返回一系列的確認信息來判斷是否出現錯誤，一旦出現丟包等狀況，TCP 就會啓動重傳操做，重傳還沒有確認的數據。微信

TCP 的重傳有兩種方式，一種是基於時間，一種是基於確認信息，通常經過確認信息要比經過時間更加高效。網絡

因此從這點就能夠看出，TCP 的確認和重傳，都是基於數據包是否被確認爲前提的。

TCP 在發送數據時會設置一個定時器，若是在定時器指定的時間內未收到確認信息，那麼就會觸發相應的超時或者基於計時器的重傳操做，計時器超時一般被稱爲重傳超時(RTO)。tcp

可是有另一種不會引發延遲的方式，這就是快速重傳。優化

TCP 在每次重傳一次報文後，其重傳時間都會加倍，這種"間隔時間加倍"被稱爲二進制指數補償(binary exponential backoff) 。等到間隔時間加倍到 15.5 min 後，客戶端會顯示spa

Connection closed by foreign host.

TCP 擁有兩個閾值來決定如何重傳一個報文段，這兩個閾值被定義在 RFC[RCF1122] 中，第一個閾值是 R1，它表示願意嘗試重傳的次數，閾值 R2 表示 TCP 應該放棄鏈接的時間。R1 和 R2 應至少設爲三次重傳和 100 秒放棄 TCP 鏈接。操作系統

這裏須要注意下，對鏈接創建報文 SYN 來講，它的 R2 至少應該設置爲 3 分鐘，可是在不一樣的系統中，R1 和 R2 值的設置方式也不一樣。

在 Linux 系統中，R1 和 R2 的值能夠經過應用程序來設置，或者是修改 net.ipv4.tcp_retries1 和 net.ipv4.tcp_retries2 的值來設置。變量值就是重傳次數。code

tcp_retries2 的默認值是 15，這個充實次數的耗時大約是 13 - 30 分鐘，這只是一個大概值，最終耗時時間還要取決於 RTO ，也就是重傳超時時間。tcp_retries1 的默認值是 3 。

對於 SYN 段來講，net.ipv4.tcp_syn_retries 和 net.ipv4.tcp_synack_retries 這兩個值限制了 SYN 的重傳次數，默認是 5，大約是 180 秒。

Windows 操做系統下也有 R1 和 R2 變量，它們的值被定義在下方的註冊表中

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters

其中有一個很是重要的變量就是 TcpMaxDataRetransmissions，這個 TcpMaxDataRetransmissions 對應 Linux 中的 tcp_retries2 變量，默認值是 5。這個值的意思表示的是 TCP 在現有鏈接上未確認數據段的次數。

快速重傳

咱們上面提到了快速重傳，實際上快速重傳機制是基於接收端的反饋信息來觸發的，它並不受重傳計時器的影響。因此與超時重傳相比，快速重傳可以有效的修復丟包狀況。當 TCP 鏈接的過程當中接收端出現亂序的報文（好比 2 - 4 - 3）到達時，TCP 須要馬上生成確認消息，這種確認消息也被稱爲重複 ACK。

當失序報文到達時，重複 ACK 要作到馬上返回，不容許延遲發送，此舉的目的是要告訴發送方某段報文失序到達了，但願發送方指出失序報文段的序列號。

還有一種狀況也會致使重複 ACK 發給發送方，那就是當前報文段的後續報文發送至接收端，由此能夠判斷當前發送方的報文段丟失或者延遲到達。由於這兩種狀況致使的後果都是接收方沒有收到報文，可是咱們卻沒法判斷究竟是報文段丟失仍是報文段沒有送達。所以 TCP 發送端會等待必定數目的重複 ACK 被接受來決定數據是否丟失並觸發快速重傳。通常這個判斷的數量是 3，這段文字表述可能沒法清晰理解，咱們舉個例子。

如上圖所示，報文段 1 成功接收並被確認爲 ACK 2，接收端的期待序號爲 2，當報文段 2 丟失後，報文段 3。失序到達，可是與接收端的指望不匹配，因此接收端會重複發送冗餘 ACK 2。

這樣，在超時重傳定時器到期以前，接收收到連續三個相同的 ACK 後，發送端就知道哪一個報文段丟失了，因而發送方會重發這個丟失的報文段，這樣就不用等待重傳定時器的到期，大大提升了效率。

SACK

在標準的 TCP 確認機制中，若是發送方發送了 0 - 10000 序號之間的數據，可是接收方只接收到了 0 -1000, 3000 - 10000 之間的數據，而 1000 - 3000 之間的數據沒有到達接收端，此時發送方會重傳 1000 - 10000 之間的數據，實際上這是沒有必要的，由於 3000 後面的數據已經被接收了。可是發送方沒法感知這種狀況的存在。

如何避免或者說解決這種問題呢？

爲了優化這種狀況，咱們有必要讓客戶端知道更多的消息，在 TCP 報文段中，有一個 SACK 選項字段，這個字段是一種選擇性確認(selective acknowledgment)機制，這個機制能告訴 TCP 客戶端，用咱們的俗語來解釋就是：「我這裏最多容許接收 1000 以後的報文段，可是我卻收到了 3000 - 10000 的報文段，請給我 1000 - 3000 之間的報文段」。

可是，這個選擇性確認機制的是否開啓還受一個字段的影響，這個字段就是 SACK 容許選項字段，通訊雙方在 SYN 段或者 SYN + ACK 段中添加 SACK 容許選項字段來通知對端主機是否支持 SACK，若是雙方都支持的話，後續在 SYN 段中就可使用 SACK 選項了。

這裏須要注意下：SACK 選項字段只能出如今 SYN 段中。

僞超時和重傳

在某些狀況下，即便沒有出現報文段的丟失也可能會引起報文重傳。這種重傳行爲被稱爲 僞重傳(spurious retransmission) ，這種重傳是沒有必要的，形成這種狀況的因素多是因爲僞超時(spurious timeout)，僞超時的意思就是過早的斷定超時發生。形成僞超時的因素有不少，好比報文段失序到達，報文段重複，ACK 丟失等狀況。

檢測和處理僞超時的方法有不少，這些方法統稱爲檢測算法和響應算法。檢測算法用於判斷是否出現了超時現象或出現了計時器的重傳現象。一旦出現了超時或者重傳的狀況，就會執行響應算法撤銷或者減輕超時帶來的影響，下面是幾種算法，此篇文章暫不深刻這些實現細節

重複 SACK 擴展- DSACK
Eifel 檢測算法
前移 RTO 恢復 - F-RTO
Eifel 響應算法

包失序和包重複

上面咱們討論的都是 TCP 如何處理丟包的問題，咱們下面來討論一下包失序和包重複的問題。

包失序

數據包的失序到達是互聯網中極其容易出現的一種狀況，因爲 IP 層並不能保證數據包的有序性，每一個數據包的發送均可能會選擇當前狀況傳輸速度最快的鏈路，因此頗有可能出現發送了 A - > B -> C 的三個數據包，到達接收端的數據包順序是 C -> A -> B 或者 B -> C -> A 等等。這就是包失序的一種現象。

在包傳輸中，主要分爲兩種鏈路：正向鏈路（SYN）和反向鏈路（ACK）

若是失序發生在正向鏈路，TCP 是沒法正確判斷數據包是否丟失的，數據的丟失和失序都會致使接收端收到無序的數據包，形成數據之間的空缺。若是這種空缺不夠大的話，這種狀況影響不大；可是若是空缺比較大的話，可能會致使僞重傳。

若是失序發生在反向鏈路，就會使 TCP 的窗口前移，而後收到重複而應該被丟棄的 ACK，致使發送端出現沒必要要的流量突發，影響可用網絡帶寬。

回到咱們上面討論的快速重傳，因爲快速重傳是根據重複 ACK 推斷出現丟包而啓動的，它不用等到重傳計時器超時。因爲 TCP 接收端會對接收到的失序報文馬上返回 ACK，因此網絡中任何一個失序到達的報文均可能會形成重複 ACK。假設一旦收到 ACK，就會啓動快速重傳機制，當 ACK 數量激增，就會致使大量沒必要要的重傳發生，因此快速重傳應該達到重複閾值(dupthresh) 再觸發。可是在互聯網中，嚴重的失序並不常見，所以 dupthresh 的值能夠設置的儘可能小，通常來講 3 就能處理絕大部分狀況。