在tcp協議中有的時候需要定期或者按照某個演算法對某個事件進行觸發，那麼這個時候，tcp協議是使用定時器進行實現的。在tcp中，會有四種定時器：
這四個定時器都有各自的具體作用。
tcp是可靠的，因此，它對於發出去的資訊，沒有得到正常ack反饋的，都會啟動乙個重傳機制。這個重傳機制使用乙個重傳定時器，當發現在規定時間內，沒有收到ack，那麼，重新傳送訊息，如果還沒有收到ack，繼續重新傳送訊息...當然，這每次繼續重新傳送訊息的時間間隔是不一樣的。一般預設，第一次重傳是發現超時後1s，第二次重傳是第一次重傳後3s，第三次是6s...
說回術語，重傳定時器最重要的計算數值叫rto(retransmission timeout, 重傳超時時間)。這個重傳超時時間又是根據rtt(round trip time, 連線往返時間)計算出來的。然後呢，這個rtt不是固定設定的，是計算機根據不同的網路情況和機器情況測量出來的。在rfc中，對rtt，rto的演算法有詳細的說明。
堅持定時器是使用在一方滑動視窗為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的各個指標設定。參考大話keepalive
這個定時器用在tcp四次揮手之後，主動發起tcp斷開的一方需要保持2msl的time_wait的狀態。這個保持的一方就會開啟2msl定時器來計算time_wait的狀態保持時間。
至於為什麼會有2msl的time_wait，主要是考慮到四次揮手的最後乙個ack包對方沒有收到，那麼對方會重發fin包，這麼一來一回就是2倍的msl時長。具體參考再敘time_wait
TCP的定時器
建立連線定時器 connection establishment timer 重傳定時器 retransmission timer 延遲應答定時器 delayed ack timer 堅持定時器 persist timer 保活定時器 keepalive timer fin wait 2定時器 fi...
TCP的定時器
在tcp協議中有的時候需要定期或者按照某個演算法對某個事件進行觸發，那麼這個時候，tcp協議是使用定時器進行實現的。在tcp中，會有四種定時器 這四個定時器都有各自的具體作用。tcp是可靠的，因此，它對於發出去的資訊，沒有得到正常ack反饋的，都會啟動乙個重傳機制。這個重傳機制使用乙個重傳定時器，當...
TCP定時器詳解
tcp使用四種定時器 timer，也稱為 計時器 重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 keeplive timer 時間等待計時器 time wait timer。當傳送端收到零視窗的確認時，就啟動堅持計時器，當堅持計時器截...