詳解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，那么才算連接失敗。