引言
如果T C P連接的雙方都沒有向對方發送數據，則在兩個T C P模塊之間不交換任何信息。這意味着我們可以啓動一個客戶與服務器建立一個連接，然後離去數小時、數天、數個星期或者數月，而連接依然保持。中間路由器可以崩潰和重啓，電話線可以被掛斷再連通，但是隻要兩端的主機沒有被重啓，則連接依然保持建立。
該情況容易出現半打開連接，即連接正常建立後，一方突然崩潰，而另一方無法得知。
保活並不是T C P規範中的一部分。 Host Requirements RFC提供了3個不使用保活定時器的理由：
(1) 在出現短暫差錯的情況下，這可能會使一個非常好的連接釋放掉；
(2) 它們耗費不必要的帶寬；
(3) 在按分組計費的情況下會在互聯網上花掉更多的錢。
然而，許多實現提供了保活定時器。保活定時器是一個有爭論的功能。許多人認爲如果需要，這個功能不應該在 T C P中提供，而應該由應用程序來完成。
描述
保活功能就是試圖在服務器端檢測到這種半開放的連接。
保活功能主要是爲服務器應用程序提供的。服務器應用程序希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。
我們稱使用保活選項的一端爲服務器，而另一端則爲客戶。並沒有什麼使客戶不能使用這個選項，但通常都是服務器設置這個功能。如果雙方都特別需要了解對方是否已經消失，則雙方都可以使用這個選項。即，根據需要，通信雙方都可以使用保活選項，以啓動保活定時器。
如果一個給定的連接在兩個小時之內沒有任何動作，則服務器就向客戶發送一個探查報文段（我們將在隨後的例子中看到這個探查報文段看起來像什麼）。客戶主機必須處於以下 4個狀態之一。
(1) 客戶主機依然正常運行，並從服務器可達。客戶的 T C P響應正常，而服務器也知道對方是正常工作的。服務器在兩小時以後將保活定時器復位。如果在兩個小時定時器到時間之前有應用程序的通信量通過此連接，則定時器在交換數據後的未來 2小時再復位。
(2) 客戶主機已經崩潰，並且關閉或者正在重新啓動。在任何一種情況下，客戶的 T C P都沒有響應。服務器將不能夠收到對探查的響應，並在 7 5秒後超時。服務器總共發送 1 0個這樣的探查，每個間隔 7 5秒。如果服務器沒有收到一個響應，它就認爲客戶主機已經關閉並終止連接。
(3) 客戶主機崩潰並已經重新啓動。這時服務器將收到一個對其保活探查的響應，但是這個響應是一個復位，使得服務器終止這個連接。
(4) 客戶主機正常運行，但是從服務器不可達。這與狀態 2相同，因爲T C P不能夠區分狀態4與狀態2之間的區別，它所能發現的就是沒有收到探查的響應。
在第1種情況下，服務器的應用程序沒有感覺到保活探查的發生。 T C P層負責一切。這個過程對應用程序都是透明的，直至第 2、 3或4種情況發生。在這三種情況下，服務器應用程序將收到來自它的 T C P的差錯報告（通常服務器已經向網絡發出了讀操作請求，然後等待來自客戶的數據。如果保活功能返回一個差錯，則該差錯將作爲讀操作的返回值返回給服務器）。在第2種情況下，差錯是諸如“連接超時”之類的信息，而在第 3種情況則爲“連接被對方復位”。第4種情況看起來像是連接超時，也可根據是否收到與連接有關的 I C M P差錯來返回其他的差錯。在下一節中我們將觀察這 4種情況。
四種情況
另一端崩潰
第一個框中，客戶在第1、 2和3行向服務器發送“Hello, world”並得到回顯；
第二個框中，是建立連接一直沒有數據往來，兩個小時後，接收端的保活定時器，發起探查報文，收到回覆說明連接完好。由於一直無數據往來，ARP表項中並無相關記錄，因此先發了一個ARP請求，然後將探測報文發出。又過了兩個小時，再次發起探測（Keep-Alive報文），連接仍完好。
第三個框中，又過了兩個小時，接收端發起探測，但這時連接不行了，發起ARP沒有響應，查不到IP，也就發不出探測報文。但保活定時器仍正常工作，連續執行了10次探測。
另一端崩潰並重新啓動
我們建立了連接，並從客戶發送 9個字節的數據到服務器（第 1 ~ 3行）。兩個小時之後，客戶發送第1個保活探查，其響應是一個來自服務器的復位。客戶應用進程打印出“連接被對端復位”的差錯，這是有意義的。
另一端不可達
第 1 ~ 3行證實連接是有效的。兩個小時之後的第 1個保活探查是正常的（第 4、 5行），但是在兩個小時後發生下一個探查之前，我們斷開在路由器s u n和n e t b之間的S L I P連接（拓撲結構參見封）。
第6行的保活探查引發一個來自路由器 s u n的I C M P網絡不可達的差錯。正如我們在第2 1 . 1 0節描述的那樣，對於主機 s l i p上接收的T C P而言，這只是一個軟差錯（TCP會忽略該錯誤，並進行超時重傳，直到嘗試最多次數。但該差錯會被記錄下來，在嘗試最多次數後，將該差錯報告給應用程序）。它報告收到了一個I C M P差錯，但是差錯的接收者並沒有終止這個連接。在發送主機最終放棄之前，一共發送了9個保活探查，間隔爲 7 5秒。這時返回給應用進程的差錯產生了一個不同的報文：“沒有到達主機的路由”。我們在圖6 - 1 2看到這對應於I C M P網絡不可達的差錯。
注意
對於一條TCP連接，如果一個中間設備給發送方回覆了遠端主機不可達，那麼發送方會忽略掉該報文，認爲網絡只是暫時的不可達，而不是將TCP連接關閉。
如果是對於目標主機發來的主機不可達或端口不可達的處理，TCP會關閉該連接。
