tcp在建立連線後會啟動四個定時器：
重傳計時器：retransmission timer
堅持計時器：persistent timer
保活計時器：keeplive timer
時間等待計時器：time_wait timer
tcp採用了一種自適應演算法，它記錄每乙個報文段發出的時間，以及收到相應的確認的時間，這兩個時間差就是報文的往返時間rtt。
重傳時間 = 2*rtt；
rtt是動態計算的：
rtt=舊的 rtt*i + (1-i)*當前rtt。i的值通常取90%，即新的rtt是以前的rtt值的90%加上當前rtt值的10%
karn演算法：
對重傳報文，在計算新的rtt時，不考慮重傳報文的rtt。因為無法推理出：傳送端所收到的確認是對上一次報文段的確認還是對重傳報文段的確認。乾脆不計入。在計算加權平均rtts時，只要報文重傳了，就不在採用其往返時間樣本。
專門為對付零視窗通知而設立的。
首先是滑動視窗，可以簡單理解為緩衝區剩餘空間大小。不管是寫緩衝還是讀緩衝，一旦一方通告了自己的滑動視窗大小，另外一方就會根據滑動視窗大小傳遞視窗大小的資料了。但是，當被通告，一方的滑動視窗大小為0的時候，另外一方就會啟動堅持定時器。
當傳送端收到零視窗的確認時，就啟動堅持計時器，當堅持計時器截止期到時，傳送端tcp就傳送乙個特殊的報文段，叫探測報文段，這個報文段只有乙個 位元組的資料。探測報文段有序號，但序號永遠不需要確認，甚至在計算對其他部分資料的確認時這個序號也被忽略。探測報文段提醒接收端tcp，確認已丟失，必須重傳。 堅持計時器的截止期設定為重傳時間的值，但若沒有收到從接收端來的響應，則傳送另乙個探測報文段，並將堅持計時器的值加倍和並復位，傳送端繼續傳送 探測報文段，將堅持計時器的值加倍和復位，知道這個值增大到閾值為止(通常為60秒)。之後，傳送端每隔60s就傳送乙個報文段，直到視窗重新開啟為止; 補充： 堅持定時器的原理是簡單的，當tcp伺服器收到了客戶端的0滑動視窗報文的時候，就啟動乙個定時器來計時，並在定時器溢位的時候向客戶端查詢視窗 是否已經增大，如果得到非零的視窗就重新開始傳送資料，如果得到0視窗就再開乙個新的定時器準備下一次查詢。通過觀察可以得知，tcp的堅持定時器使用 1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢位時間。
其次是糊塗視窗綜合症。這個症狀是滑動視窗引起的。**是傳送方和接收方在乙個很小的滑動視窗的時候就開始資料傳輸，傳輸結束之後，讀寫的消費速度也並沒有那麼快，導致下次傳輸的時候，滑動視窗還是那麼小。然後現象就是每次傳輸的資料都非常小。就好比每次開出去的火車載貨量只有一節車廂，其實我們是希望能攢夠n節車廂才開始傳輸。從而影響網路利用率。
糊塗視窗綜合症有解決辦法，還不止一種，在接收方或者傳送方都可以解決。大致就是如果接收方解決，那麼接收方在接收視窗小於一定大小的時候，對所有的接收請求都返回視窗為0的包，來觸發另外一方的堅持定時器。同樣傳送方也是，在可以傳送的資料大於一定視窗的時候才傳送。
再次補充： tcp通過讓接收方指明希望從傳送方接收的資料位元組數(即視窗大小)來進行流量控制。如果視窗大小為 0會發生什麼情況呢?這將有效地阻止傳送方傳送資料，直到視窗變為非0為止。 tcp不對ack報文段進行確認， tcp只確認那些包含有資料的ack報文段。 如果乙個確認丟失了(這個確認是」接收方「向」傳送方「傳送的ack，通知」傳送方「自己的視窗已經非0了)，則雙方就有可能因為等待對方而使連線 終止：接收方等待接收資料(因為它已經向傳送方通告了乙個非 0的視窗)，而傳送方在等待允許它繼續傳送資料的視窗更新。為防止這種死鎖情況的發生，傳送方使用乙個堅持定時器 (persist timer)來周期性地向接收方查詢，以便發現視窗是否已增大。這些從傳送方發出的報文段稱為視窗探查 (window probe)。
keeplive timer 每當伺服器收到客戶的資訊，就將keeplive timer復位，超時通常設定2小時，若伺服器超過2小時還沒有收到來自客戶的資訊，就傳送探測報文段，若傳送了10個探測報文段(每75秒傳送乙個)還沒收到響應，則終止連線。 補充： 保活定時器更加的簡單，還記得ftp或者http伺服器都有sesstion time機制麼?因為tcp是面向連線的，所以就會出現只連線不傳送資料的「半開放連線」，伺服器當然要檢測到這種連線並且在某些情況下釋放這種連線，這 就是保活定時器的作用。其實現根據伺服器的實現不同而不同。另外要提到的是，當其中一端如果崩潰並重新啟動的情況下，如果收到該端「前生」的保活探察，則 要傳送乙個rst資料報文幫助另一端結束連線。
time_wait timer 在連線終止期使用，當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四種定時器
定時器在tcp可靠傳輸的過程中起著舉足輕重的作用。tcp在建立連線之後可能 保活keep alive定時器是可選的 會 啟動四個定時器。tcp使用四種定時器 timer，也稱為 計時器 重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 k...
tcp四種定時器
tcp使用四種定時器 timer，也稱為 計時器 重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 keeplive timer 時間等待計時器 time wait timer。1 重傳計時器 重傳定時器 為了控制丟失的報文段或丟棄的報文...
TCP的四種定時器
tcp在建立連線後會啟動四個定時器 重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 keeplive timer 2msl定時器 time wait timer 1 重傳計時器 tcp的傳送方沒有在規定的時間內收到確認就要重傳已傳送的報...