TCP協議中有四種計時器（Timer），分別是：

　　1.重傳計時器：Retransmission Timer

　　2.堅持計時器：Persistent Timer

　　3.保活計時器：Keeplive Timer

　　4.時間等待計時器：Timer_Wait Timer

1 重傳計時器

　　RTT：傳送一個數據包到收到對應的 ACK，所花費的時間。

　　RTO：定時器，重傳時間間隔，沒有迴應 ACK 則等到 RTO 到期進行重傳，根據 RTT 計算出來。

　　帶確認的重傳機制可以保證TCP資料的可靠傳輸。在滑動視窗協議中，接受視窗會在連續收到的包序列中的最後一個包向接收端傳送一個ACK，當網路擁堵的時候，傳送端的資料包和接收端的ACK包都有可能丟失。TCP為了保證資料可靠傳輸，就規定在重傳的“時間片”到了以後，如果還沒有收到對方的ACK，就重發此包

　　當TCP傳送報文段時，就建立該特定報文的重傳計時器。可能發生兩種情況：

　　1）若在計時器截止時間到之前收到了對此特定報文段的確認，則撤銷此計時器。

　　2）若在收到了對此特定報文段的確認之前計時器截止時間到，則重傳此報文段，並將計時器復位。

2 堅持計時器

　　先來考慮一下情景：傳送端向接收端傳送資料包知道接受視窗填滿了，然後接受視窗告訴傳送方接受視窗填滿了停止傳送資料。此時的狀態稱為“零視窗”狀態，傳送端和接收端視窗大小均為0。直到接受TCP傳送確認並宣佈一個非零的視窗大小。但這個確認會丟失。在TCP中，對確認是不需要傳送確認的。若確認丟失了，接受TCP並不知道，而是會認為他已經完成了任務，並等待著傳送TCP接著會發送更多的報文段。但傳送TCP由於沒有收到確認，就等待對方傳送確認來通知視窗大小。雙方的TCP都在永遠的等待著對方。

　　要開啟這種死鎖，TCP為每一個連結使用一個持久計時器。當傳送TCP收到視窗大小為0的確認時，就啟動堅持計時器。當堅持計時器期限到時，傳送TCP就傳送一個特殊的報文段，叫做探測報文。這個報文段只有一個位元組的資料。他有一個序號，但他的序號永遠不需要確認；甚至在計算機對其他部分的資料的確認時該序號也被忽略。探測報文段提醒接受TCP：確認已丟失，必須重傳。

　　堅持計時器的值設定為重傳時間的數值。但是，若沒有收到從接收端來的響應，則需傳送另一個探測報文段，並將堅持計時器的值加倍和復位。傳送端繼續傳送探測報文段，將堅持計時器設定的值加倍和復位，直到這個值增大到門限值（通常是60秒）為止。在這以後，傳送端每個60秒就傳送一個探測報文，直到視窗重新開啟。

3 保活計時器

　　保活計時器使用在某些實現中，用來防止在兩個TCP之間的連接出現長時間的空閒。假定客戶打開了到伺服器的連線，傳送了一些資料，然後就保持靜默了。也許這個客戶出故障了。在這種情況下，這個連線將永遠的處理開啟狀態。

　　要解決這種問題，在大多數的實現中都是使伺服器設定保活計時器。每當伺服器收到客戶的資訊，就將計時器復位。通常設定為兩小時。若伺服器過了兩小時還沒有收到客戶的資訊，他就傳送探測報文段。若傳送了10個探測報文段（每一個像個75秒）還沒有響應，就假定客戶除了故障，因而就終止了該連線。

　　這種連線的斷開當然不會使用四次握手，而是直接硬性的中斷和客戶端的TCP連線。

4 時間等待計時器

　　時間等待計時器是在四次揮手的時候使用的。四次握手的簡單過程是這樣的：假設客戶端準備中斷連線，首先向伺服器端傳送一個FIN的請求關閉包（FIN=final），然後由established過渡到FIN-WAIT1狀態。伺服器收到FIN包以後會發送一個ACK，然後自己有established進入CLOSE-WAIT。此時通訊進入半雙工狀態，即留給伺服器一個機會將剩餘資料傳遞給客戶端，傳遞完後伺服器傳送一個FIN+ACK的包，表示我已經發送完資料可以斷開連線了，就這便進入LAST_ACK階段。客戶端收到以後，傳送一個ACK表示收到並同意請求，接著由FIN-WAIT2進入TIME-WAIT階段。伺服器收到ACK，結束連線。此時（即客戶端傳送完ACK包之後），客戶端還要等待2MSL（MSL=maxinum segment lifetime最長報文生存時間，2MSL就是兩倍的MSL）才能真正的關閉連線。

參考：https://www.cnblogs.com/duan2/p/9180861.html

本文來自部落格園，作者：Jcpeng_std，轉載請註明原文連結：https://www.cnblogs.com/JCpeng/p/15135142.html