[轉帖]【tcp】關於tcp 超時重傳次數

https://www.jianshu.com/p/3e59128a1dbd

TCP重傳間隔時間和TCP重傳次數

一般TCP報文的重傳超時時間

TCP重傳時間間隔有著多種不同的演算法，最常見的就是《TCP/IP詳解卷1》中關於超時重傳的演算法。

具體演算法不再贅述，請大家參考《TCP/IP詳解卷1》第21章《TCP的超時與重傳》。

SYN報文重傳間隔時間

在實際情況下，由於SYN報文是TCP連線的第一個報文，如果該報文在傳輸的過程中丟棄了，那麼傳送方則無法測量RTT，也就無法根據RTT來計算RTO。

因此，SYN重傳的演算法就要簡單一些，SYN重傳時間間隔一般根據系統實現的不同稍有差別，Windows系統一般將第一次重傳超時設為3秒，以後每次超時重傳時間為上一次的2倍，如下圖所示：

報文重傳的次數

TCP報文重傳的次數也根據系統設定的不同而有區分，有些系統，一個報文只會被重傳3次，如果重傳三次後還未收到該報文的確認，那麼就不再嘗試重傳，直接reset重置該TCP連線，但有些要求很高的業務應用系統，則會不斷的重傳被丟棄的報文，以盡最大可能保證業務資料的正常互動。

資料被重發以後若還是收不到應答，則進行再次傳送。此時等待確認應答時間會以2倍、4倍的指數函式延長。

此外，資料也不會被無限、反覆的重發。達到一定的重發次數之後，如果仍然沒有任何確認應答返回，就會判斷為網路或者對端主機發生了異常，強制關閉連線。

Linux 的設定

最小重傳時間是 200ms

最大重傳時間是 120s

重傳次數為 15

重傳對業務應用的影響

1 保障了業務的可靠性

TCP的重傳存在原因就是為了保障TCP的可靠性，正是由於TCP存在重傳的機制，那些基於TCP的業務應用在網路互動的過程中，不再擔心由於丟包、包損壞等導致的一系列應用問題了。

2 反映網路通訊的狀況

由於IP協議的不可靠性和網路系統的複雜性，少量的報文丟失和TCP重傳是正常的，但是如果業務互動過程中，存在大量的TCP重傳，會嚴重影響業務系統互動的效率，導致業務系統出現緩慢甚至無響應的情況發生。

一般而言，出現大量TCP重傳說明網路通訊的狀況非常糟糕，需要站在網路層的角度分析丟包和重傳的原因。

在實際的分析過程中，我們如何確認一個TCP報文是重傳報文？

在實際的資料互動過程中，重傳報文一般具有以下兩個特徵：

一是TCP互動序列號突然下降；

二是其在TCP報頭中的序列號、資料長度、應用資料等引數跟前面某TCP報文一致。

1 序列號突然下降（一般是TCP重傳）

在TCP報文傳輸的過程中，因為其需要不斷的互動應用資料，因此，TCP報文的序列號會不斷的變大。

正常情況下，TCP序列號不會出現下降的情況，出現序列號下降，一般都是TCP的重傳報文導致的。

如下圖所示：

在上圖中，伺服器端互動的TCP報文序列號從24481開始一直處於不斷上升的趨勢，但是伺服器的第六個TCP報文序列號卻突然下降為20161，這個情形，基本上可以肯定這第六個TCP報文是前面某個報文的重傳報文。

2 根據序列號、長度甚至應用資料等確認是哪一個報文的重傳。

在資料互動過程中，一般情況下，TCP重傳的報文跟傳輸中被丟棄的報文在序列號、資料長度、應用欄位值上都是一樣的，我們可以利用這個特徵來確定某個具體的TCP報文是否是前面某個報文的重傳。

下圖是一個客戶端存在重傳的資料流圖：

在上圖中，我們看到客戶端第三個報文和第四個報文的序列號（Seq）、下一個序列號（Next Seq）以及載荷長度都是一樣的，那麼我們可以肯定客戶端的第四個報文是客戶端第三個報文的重傳。

現在很多的網路分析工具的專家診斷系統基本上都可以針對TCP重傳直接告警，我們不需要在去深入分析這個過程了，為我們節省了大量的分析時間。

參考

為什麼TCP存在重傳

https://blog.51cto.com/woniu421/900010

基礎篇 | TCP連線的建立和斷開受哪些系統配置影響？

https://time.geekbang.org/column/article/284912?utm_source=related_read&utm_medium=article&utm_term=related_read

Linux TCP_RTO_MIN, TCP_RTO_MAX and the tcp_retries2 sysctl

https://pracucci.com/linux-tcp-rto-min-max-and-tcp-retries2.html

聊一聊重傳次數

https://perthcharles.github.io/2015/09/07/wiki-tcp-retries

TCP重傳機制

https://www.dazhuanlan.com/mofeia/topics/1357902

TCP網路關閉的狀態變換時序圖

https://coolshell.cn/articles/1484.html

TCP 的那些事兒（上）

https://coolshell.cn/articles/11564.html

TCP 的那些事兒（下）

https://coolshell.cn/articles/11609.html