第23章 TCP的保活定時器
23.3 保活舉例
現在詳細讨論前一節提到的第 2、3和4種情況。我們将在使用這個選項的情況下檢查所交換的分組。
23.3.1 另一端崩潰
首先觀察另一端崩潰且沒有重新啟動的情況下所發生的現象。為模拟這種情況，我們采用如下步驟：
• 在客戶（主機b s d i上運作的s o c k程式）和主機s v r 4上的标準回顯伺服器之間建立一個連接配接。客戶使用- K選項使能保活功能。
• 驗證資料可以通過該連接配接。
• 觀察客戶T C P每隔2小時發送保活分組，并觀察被伺服器的 T C P确認。
• 将以太網電纜從伺服器上拔掉直到這個例子完成，這會使客戶認為伺服器主機已經崩潰。
• 我們預期伺服器在斷定連接配接已中斷前發送 1 0個間隔為7 5秒的保活探查。
這裡是用戶端的互動輸出結果：
圖2 3 - 1顯示的是t c p d u m p的輸出結果（已經去掉了連接配接建立和視窗通告）。
客戶在第1、2和3行向伺服器發送“Hello, world”并得到回顯。第4行是第一個保活探查，發生在兩個小時以後（ 7 2 0 0秒）。在第6行的T C P封包段能夠發送之前，首先觀察到的是一個A R P請求和一個A R P應答。第6行的保活探查引出來自另一端的響應（第 7行）。兩個小時以後，在第7和8行發生了同樣的分組交換過程。
如果能夠觀察到第6和第1 0行的保活探查中的所有字段，我們就會發現序号字段比下一個将要發送的序号字段小 1（在本例中，當下一個為 1 4時，它就是1 3）。但是因為封包段中沒有資料，t c p d u m p不能列印出序号字段（它僅能夠列印出設定了 S Y N、F I N或R S T标志的空資料的序号）。正是接收到這個不正确的序号，才導緻伺服器的 T C P對保活探查進行響應。這個響應告訴客戶，伺服器下一個期望的序号是 1 4。
一些基于4 . 2 B S D的舊的實作不能夠對這些保活探查進行響應，除非封包段中包含資料。某些系統可以配置成發送一個位元組的無用資料來引出響應。這個無用資料是無害的，因為它不是所期望的資料（這是接收方前一次接收并确認的資料），是以它會被
接收方丢棄。其他一些系統在探查的前半部分發送4.3BSD格式的封包段（不包含資料），如果沒有收到響應，在後半部分則切換為4.2BSD格式的封包段。
接着我們拔掉電纜，并期望兩個小時的再一次探查失敗。當這下一個探查發生時，注意到從來沒有看到電纜上出現 T C P封包段，這是因為主機沒有響應 A R P請求。在放棄之前，我們仍可以觀察到客戶每隔 7 5秒發送一個探查，一共發送了 1 0次。從互動式腳本可以看到傳回給客戶程序的差錯碼被T C P轉換為“連接配接逾時”，這正是實際所發生的。
23.3.2 另一端崩潰并重新啟動
在這個例子中，我們可以觀察到當客戶崩潰并重新啟動時發生的情況。最初的環境與前一個例子相似，但是在我們驗證連接配接有效之後，我們将伺服器從以太網上斷開，重新啟動，然後再連接配接到網絡上。我們希望看到下一個保活探查産生一個來自伺服器的複位，因為現在伺服器不知道關于這個連接配接的任何資訊。這是互動會話的過程：
圖2 3 - 2顯示的是t c p d u m p的輸出結果（已經去掉了連接配接建立和視窗通告）。
我們建立了連接配接，并從客戶發送 9個位元組的資料到伺服器（第 1 ~ 3行）。兩個小時之後，客戶發送第1個保活探查，其響應是一個來自伺服器的複位。客戶應用程序列印出“連接配接被對端複位”的差錯，這是有意義的。
23.3.3 另一端不可達
在這個例子中，客戶沒有崩潰，但是在保活探查發送後的 1 0分鐘内無法到達，可能是一個中間路由器已經崩潰，或一條電話線臨時出現故障，或發生了其他一些類似的情況。
為了仿真這個例子，我們從主機 s l i p經過一個撥号 S L I P鍊路與主機 v a n g o g h . c s . b e r k e l e y . e d u建立一個連接配接，然後斷掉鍊路。這裡是互動輸出的結果：
圖2 3 - 3顯示了在路由器b s d i上收集到的t c p d u m p輸出結果（已經去掉了連接配接建立和視窗通告）。