1. TCP中7種定時器
?TCP中有7中定時器
（1）建立連接定時器(connection-establishment timer)
（2）重傳定時器(retransmission timer)
（3）延遲應答定時器(delayed ACK timer)
（4）堅持定時器(persist timer)
（5）保活定時器(keepalive timers)
（6）FIN_WAIT_2定時器(FIN_WAIT_2 timer)
（7）TIME_WAIT定時器(TIME_WAIT timer，也叫2MSL timer)
2. 建立連接定時器（connection-establishment timer）
這個定時器是在建立連接的時候使用的，TCP建立連接需要3次握手，如圖：
?
建立連接的過程中，在發送SYN時，會啟動一個定時器（默認應該是3秒），如果SYN包丟失了，那么3秒以后會重新發送SYN包（當然還會啟動一個新的定時器，設置成6秒超時），當然也不會一直沒完沒了的發SYN包，在/proc/sys/net/ipv4/tcp_syn_retries可以設置到底要重新發送幾次SYN包。如圖：
3. 重傳定時器（retransmission timer）
重傳定時器在TCP發送數據時設定，在計時器超時后沒有收到返回的確認ACK，發送端就會重新發送隊列中需要重傳的報文段。使用RTO重傳計時器一般有如下規則：
（1）當TCP發送了位于發送隊列最前端的報文段后就啟動這個RTO計時器
（2）如果隊列為空則停止計時器，否則重啟定時器
（3）當計時器超時后，TCP會重傳發送隊列最前端的報文段
（4）當一個或多個報文段被累計確認后，這個貨這些報文段會被清除出隊列
重傳計時器保證了接收端能夠接收到丟失的報文段，繼而保證了接收端交付給接收進程的數據始終是有序完整的。因為接收端永遠不會把一個失序不完整的報文段交付給接收進程。
4. 延遲應答定時器（delayed ACK timer）
延遲應答也被稱為捎帶ACK，這個定時器是在延遲應答的時候使用的。為什么要延遲應答呢？延遲應答是為了提供網絡傳輸的效率。
舉例說明，比如服務端收到客戶端的數據后，不是立刻回ACK給客戶端，而是等一段時間（一般最大200ms），這樣如果服務端要是有數據需要發給客戶端，那么這個ACK就和服務端的數據一起發給客戶端了，這樣比立即給客戶端一個ACK節省了一個數據包。
5. 堅持定時器（persist timer）
TCP通過讓接收方指明希望從發送方接收的數據字節數（即窗口大小）來進行流量控制。如果窗口大小為0會發生什么情況呢？這將有效地阻止發送方傳送數據，直到窗口變為非0為止。接收端窗口變為非0后，就會發送一個確認ACK指明需要的報文段序號以及窗口大小。
如果這個確認ACK丟失了，則雙方就有可能因為等待對方而使連接終止：接收方等待接收數據（因為它已經向發送方通告了一個非0的窗口），而發送方在等待允許它繼續發送數據的窗口更新。為防止這種死鎖情況的發生，發送方使用一個堅持定時器（persist timer）來周期性地向接收方查詢，以便發現窗口是否已增大。這些從發送方發出的報文段稱為窗口探查（window probe）。
6. 保活定時器（keepalive timer）
許多TCP/IP的初學者會很驚奇地發現可以沒有任何數據流通過一個空閑的TCP連接，也就是說，如果TCP連接的雙方都沒有向對方發送數據，則在兩個TCP模塊之間不交換任何信息。
兩個應用進程--客戶進程或服務器進程都沒有使用應用級的定時器來檢測非活動狀態，而這種非活動狀態可以導致應用進程中的任何一個終止其活動。
許多時候服務器希望知道客戶主機是否崩潰并關機或崩潰又重新啟動，許多實現提供的保活定時器可以提供這種能力。
保活功能主要是為服務器應用程序提供的，服務器應用希望知道客戶主機是否崩潰。保活功能試圖在服務器端檢測到這種半開放的連接。
如果一個給定的連接在兩個小時之內沒有任何動作，則服務器就向客戶發送一個探查報文段，客戶主機必須處于一下4個狀態之一：
（1）客戶主機依然正常運行，并從服務器可達。客戶端TCP響應正常，而服務器也知道對方是正常工作的。服務器在兩個時以后將保活定時器復位。如果在兩個小時定時器到時間之前有應用程序的通信量通過此鏈接，則定時器在交換數據后的未來2小時再復位
（2）客戶主機已經崩潰，并且關閉或正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應，服務器將不能夠收到探查的響應。--會返回諸如“連接超時”之類的信息。
（3）客戶主機崩潰并已經重新啟動。這時服務器將收到一個對其保活探查的響應，但是這個響應是一個復位，使得服務器終止這個連接。 -- 會返回諸如“連接被對方復位”
（4）客戶主機正常運行，但是從服務器不可達。與（2）相同。
在TCP連接建立的時候指定了SO_KEEPALIVE，保活定時器才會有效。如果客戶端和服務端長時間沒有數據交互，那么需要保活定時器來判斷是否對端還活著，但是這個其實很不實用，因為默認是2小時沒有數據交互才探測，時間實在是太長了。如果你真的要確認對端是否活著，那么應該自己實現心跳包，而不是依賴于這個保活定時器。
7. FIN_WAIT_2定時器（FIN_WAIT_2 timer）
主動關閉的一段調用完close之后（即發FIN給被動關閉的一段，并且收到其對FIN的確認ACK）則進入FIN_WAIT_2狀態。如果這個時候因為網絡突然斷掉，被動關閉的一段宕機等原因，導致主動關閉的一段不能收到被動關閉的一段發來的FIN，主動關閉的一端總不能一直等著，占用資源不釋放吧。這個時候就需要FIN_WAIT_2定時器出馬了，如果在該定時器超時的時候，還是沒收到被動關閉一端發來的FIN，那么不好意思，不等了，直接釋放這個連接。FIN_WAIT_2定時器的時間可以從/proc/sys/net/ipv4/tcp_fin_timeout中查看和設置。如圖：
8. TIME_WAIT定時器（TIME_WAIT timer，也叫2MSL timer）
TIME_WAIT是主動關閉連接的一端之后進入的狀態，而不是直接變成CLOSED的狀態，為什么呢？
（1）萬一被動關閉的一端在超時時間內沒有收到最后一個ACK，則會重發最后的FIN，2MSL（報文段最大生存時間）等待時間保證了重發的FIN會被主動關閉的一端收到且重新發送最后一個ACK
（2）另一個原因是在2MSL等待時間內，任何遲到的報文段會被接收并丟棄，防止老的TCP連接的包在新的TCP連接里出現。不可避免，在這個2MSL等待時間呢，不會建立同樣（源IP、源端口、目的IP、目的端口）的連接。
?
