詳解TCP的四種定時器

在TCP協議中有的時候需要定期或者按照某個算法對某個事件進行觸發，那么這個時候，TCP協議是使用定時器進行實現的。在TCP中，會有四種定時器：

(1)重傳定時器
(2)堅持定時器
(3)保活定時器
(4) 時間等待計時器

這四個定時器都有各自的具體作用。

一:重傳定時器

重傳定時器：為了控制丟失的報文段或丟棄的報文段，也就是對報文段確認的等待時間。當TCP發送報文段時，就創建這個特定報文段的重傳計時器，可能發生兩種情況：若在計時器超時之前收到對報文段的確認，則撤銷計時器；若在收到對特定報文段的確認之前計時器超時，則重傳該報文，并把計時器復位；
重傳時間=2*RTT；

RTT的值應該動態計算。常用的公式是：RTT=previous RTT*i + （1-i）*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上當前RTT值的10%.

Karn算法：對重傳報文，在計算新的RTT時，不考慮重傳報文的RTT。因為無法推理出：發送端所收到的確認是對上一次報文段的確認還是對重傳報文段的確認。干脆不計入。

二:堅持定時器

堅持定時器是使用在一方滑動窗口為0之后，另外一方停止傳輸數據，進入堅持定時器的輪詢，直到滑動窗口不再為0了。
說說術語，首先是滑動窗口，可以簡單理解為緩沖區剩余空間大小。不管是寫緩沖還是讀緩沖，一旦一方通告了自己的滑動窗口大小，另外一方就會根據滑動窗口大小傳遞窗口大小的數據了。但是，當被通告，一方的滑動窗口大小為0的時候，另外一方就會啟動堅持定時器，基本也是使用TCP指數退避方法，第一次1.5秒，第二次1.5x2秒，第三次1.5x4…
其次是糊涂窗口綜合癥。這個癥狀是滑動窗口引起的。病因是發送方和接收方在一個很小的滑動窗口的時候就開始數據傳輸，傳輸結束之后，讀寫的消費速度也并沒有那么快，導致下次傳輸的時候，滑動窗口還是那么小。然后現象就是每次傳輸的數據都非常小。就好比每次開出去的火車載貨量只有一節車廂，其實我們是希望能攢夠n節車廂才開始傳輸。
糊涂窗口綜合癥有解決辦法，還不止一種，在接收方或者發送方都可以解決。大致就是如果接收方解決，那么接收方在接收窗口小于一定大小的時候，對所有的接收請求都返回窗口為0的包，來觸發另外一方的堅持定時器。同樣發送方也是，在可以發送的數據大于一定窗口的時候才發送。

三:保活定時器

這個就是我們經常說的tcp的keepalive了。實際使用場景是在應用層沒有數據進行傳輸的時候，一定時間（tcp_keepalive_time，默認每2個小時）發送一次保持心跳的包，如果發送成功，則繼續保持端口活躍，如果沒有正常返回，則在指定次數內（tcp_keepalive_probes，默認是9次），指定間隔（tcp_keepalive_intvl，默認是17s）發送心跳包。如果最后都沒有獲得正常的ACK，那么才算連接失敗。

當然，tcp是否需要提供keepalive機制，是有爭議的，我們可以為每個tcp連接設置是否啟用keepalive和啟用keepalive的各個指標設置。

四:時間等待定時器

在連接終止期使用，當TCP關閉連接時，并不認為這個連接就真正關閉了，在時間等待期間，連接還處于一種中間過度狀態。這樣就可以時重復的fin報文段在到達終點后被丟棄，這個計時器的值通常設置為一格報文段壽命期望值的兩倍。

補充：

2MSL定時器：MSL是報文段做大生存時間(Maximum Segment Lifetime),設置這個定時器有兩個目的：

其一是為了測量連接處于TIME_WAIT狀態的時間.這樣可以讓TCP再次發送最后的ACK以防止這個ACK丟失(如果丟失，另一端會重傳FIN)。

其二，為允許老的重復分節在網絡中消逝。具體可以解釋為，如果一個TCP連接在斷開之前有迷途分節尚未消逝，在斷開該TCP連接之后立刻重啟一個同樣的連接(雙方的IP地址和端口port相同)，這時之前的迷途的老分節可能對新的新的TCP連接接收，從而造成未定義的錯誤。為了避免這種情況，TCP規定在TIME_WAIT狀態，不能啟動一個連接的化身。既然TIME_WAIT狀態維持2MSL，這就保證了一個連接上的分組及其應該在 2MSL內都會消失。

以上就是關于 TCP 的四種定時器的講解，如果大家有疑問可以留言或者到本站社區討論，感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！