摘要：一引言在中，通常有類似于心跳一樣的定時器來保證傳輸?shù)恼！τ诿恳粋€連接，管理了個不同的定時器。二定時重傳定時器提供可靠的運(yùn)輸層。通過在發(fā)送時設(shè)置一個定時器來解決這種問題。當(dāng)收到一個包含這個序號的確認(rèn)后，該定時器就被關(guān)閉。這就是?；疃〞r器。

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

定時重傳；

持久定時器（persist）；

?；疃〞r器（keepalive）;

2MSL定時器，用來測量處于TIME_WAIT狀態(tài)的連接。

這里介紹三種。

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

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

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

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

它們耗費(fèi)不必要的帶寬；

在按分組計費(fèi)的情況下會在互聯(lián)網(wǎng)上花掉更多的錢。

?；罟δ苤饕菫榉?wù)器應(yīng)用程序提供的。服務(wù)器應(yīng)用程序希望知道客戶主機(jī)是否崩潰，從而可以代表客戶使用資源。 ??一句話，keepalive timer就是我們經(jīng)常遇到的心跳包，在需要的時候可以在應(yīng)用層實(shí)現(xiàn)。

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