摘要：一引言在中，通常有類似于心跳一樣的定時器來保證傳輸的正常。對于每一個連接，管理了個不同的定時器。二定時重傳定時器提供可靠的運輸層。通過在發送時設置一個定時器來解決這種問題。當收到一個包含這個序號的確認后，該定時器就被關閉。這就是保活定時器。

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

定時重傳；

持久定時器（persist）；

保活定時器（keepalive）;

2MSL定時器，用來測量處于TIME_WAIT狀態的連接。

這里介紹三種。

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

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

我們會很驚奇地發現可以沒有任何數據流通過一個空閑的TCP連接。也就是說， 如果TCP連接的雙方都沒有向對方發送數據， 則在兩個TCP模塊之間不交換任何信息。例如，沒有可以在其他網絡協議中發現的輪詢。這意味著我們可以啟動一個客戶與服務器建立一個連接，然后離去數小時、數天、數個星期或者數月，而連接依然保持。然而，許多時候一個服務器希望知道客戶主機是否崩潰并關機或者崩潰又重新啟動。許多實現提供的保活定時器可以提供這種能力。這就是保活定時器。 ??事實上，keepalive timer 在RPC中是不被推薦的， 許多人認為如果需要，這個功能不應該在 TCP中提供，而應該由應用程序來完成。在大部分的協議中，也是關閉了這個的，原因如下：

在出現短暫差錯的情況下，這可能會使一個非常好的連接釋放掉；

它們耗費不必要的帶寬；

在按分組計費的情況下會在互聯網上花掉更多的錢。

保活功能主要是為服務器應用程序提供的。服務器應用程序希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。 ??一句話，keepalive timer就是我們經常遇到的心跳包，在需要的時候可以在應用層實現。

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