在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的定時器
在tcp協議中有的時候需要定期或者按照某個演算法對某個事件進行觸發，那麼這個時候，tcp協議是使用定時器進行實現的。在tcp中，會有四種定時器 這四個定時器都有各自的具體作用。tcp是可靠的，因此，它對於發出去的資訊，沒有得到正常ack反饋的，都會啟動乙個重傳機制。這個重傳機制使用乙個重傳定時器，當...
TCP的定時器
建立連線定時器 connection establishment timer 重傳定時器 retransmission timer 延遲應答定時器 delayed ack timer 堅持定時器 persist timer 保活定時器 keepalive timer fin wait 2定時器 fi...
TCP定時器詳解
tcp使用四種定時器 timer，也稱為 計時器 重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 keeplive timer 時間等待計時器 time wait timer。當傳送端收到零視窗的確認時，就啟動堅持計時器，當堅持計時器截...