系列TCP/IP協議-定時器（014完）

1、引言

在TCP中，一般有相似於心跳同樣的定時器來保證傳輸的正常。對於每個鏈接，TCP管理了4個不一樣的定時器。

• 定時重傳；
• 持久定時器（persist）；
• 保活定時器（keepalive）;
• 2MSL定時器，用來測量處於TIME_WAIT狀態的鏈接。

這裏介紹三種。

2、定時重傳定時器

TCP提供可靠的運輸層。它使用的方法之一就是確認從另外一端收到的數據。但數據和確認都有可能會丟失。TCP經過在發送時設置一個定時器來解決這種問題。若是當定時器溢出時尚未收到確認，它就重傳該數據。   對每一個鏈接而言，報文段中數據的起始序號也被記錄下來。當收到一個包含這個序號的確認後，該定時器就被關閉。若是ACK到達時數據沒有被重傳，則被平滑的RTT和被平滑的均值誤差將基於這個新測量進行更新。

3、持久定時器（persist timer）

咱們已經看到TCP經過讓接收方指明窗口大小來對發送方進行流量控制的。當窗口大小爲0，發送方將不會發送數據，直到接收方發送ack通知非0窗口大小。   可是當這個ack丟失了呢，又是什麼狀況？發送方窗口大小爲0，接收方又認爲發送方的發送窗口不爲0。兩個就這麼僵持着，直到關閉鏈接。   這是個問題！爲了防止這種死鎖狀況的發生，在每個TCP鏈接中，發送方都使用一個叫持久定時器（persist timer）來週期性的向接收方查詢，以便發現窗口是否變大了。

4、保活定時器(keepalive timer)

咱們會很驚奇地發現能夠沒有任何數據流經過一個空閒的TCP鏈接。也就是說， 若是TCP鏈接的雙方都沒有向對方發送數據， 則在兩個TCP模塊之間不交換任何信息。例如，沒有能夠在其餘網絡協議中發現的輪詢。這意味着咱們能夠啓動一個客戶與服務器創建一個鏈接，而後離去數小時、數天、數個星期或者數月，而鏈接依然保持。然而，許多時候一個服務器但願知道客戶主機是否崩潰並關機或者崩潰又從新啓動。許多實現提供的保活定時器能夠提供這種能力。這就是保活定時器。   事實上，keepalive timer 在RPC中是不被推薦的， 許多人認爲若是須要，這個功能不該該在 TCP中提供，而應該由應用程序來完成。在大部分的協議中，也是關閉了這個的，緣由以下：

• 在出現短暫差錯的狀況下，這可能會使一個很是好的鏈接釋放掉；
• 它們耗費沒必要要的帶寬；
• 在按分組計費的狀況下會在互聯網上花掉更多的錢。

保活功能主要是爲服務器應用程序提供的。服務器應用程序但願知道客戶主機是否崩潰，從而能夠表明客戶使用資源。   一句話，keepalive timer就是咱們常常遇到的心跳包，在須要的時候能夠在應用層實現。

都看到這裏了，要不要掃二維碼關注一下微信公衆號林灣村龍貓。