TCP保活功能KEEPALIVE

TCP保活功能KEEPALIVE

轉載：http://www.vants.org/?post=162

TCP保活（TCP keepalive）

做者：易隱者 發佈於：2012-10-15 11:30 Monday 分類：網絡分析

 

TCP保活的緣起

 雙方創建交互的鏈接，可是並非一直存在數據交互，有些鏈接會在數據交互完畢後，主動釋放鏈接，而有些不會，那麼在長時間無數據交互的時間段內，交互雙方都有可能出現掉電、死機、異常重啓等各類意外，當這些意外發生以後，這些TCP鏈接並將來得及正常釋放，那麼，鏈接的另外一方並不知道對端的狀況，它會一直維護這個鏈接，長時間的積累會致使很是多的半打開鏈接，形成端系統資源的消耗和浪費，爲了解決這個問題，在傳輸層能夠利用TCP的保活報文來實現。

 

TCP保活的做用

1， 探測鏈接的對端是否存活

        在應用交互的過程當中，可能存在如下幾種狀況：

（1）客戶端或服務器端意外斷電、死機、崩潰、重啓

（2）中間網絡已經中斷，而客戶端與服務器端並不知道

        利用保活探測功能，能夠探知這種對端的意外狀況，從而保證在乎外發生時，能夠釋放半打開的TCP鏈接。

2， 防止中間設備因超時刪除鏈接相關的鏈接表

       中間設備如防火牆等，會爲通過它的數據報文創建相關的鏈接信息表，併爲其設置一個超時時間的定時器，若是超出預約時間，某鏈接無任何報文交互的話，中間設備會將該鏈接信息從表中刪除，在刪除後，再有應用報文過來時，中間設備將丟棄該報文，從而致使應用出現異常，這個交互的過程大體以下圖所示：

這種狀況在有防火牆的應用環境下很是常見，這會給某些長時間無數據交互可是又要長時間維持鏈接的應用（如數據庫）帶來很大的影響，爲了解決這個問題，應用自己或TCP能夠經過保活報文來維持中間設備中該鏈接的信息，（也能夠在中間設備上開啓長鏈接屬性或調高鏈接表的釋放時間來解決，可是，這個影響可能較大，有機會再針對這個作詳細的描述，在此很少說）。

 

常見應用故障場景

某財務應用，在客戶端須要填寫大量的表單數據，在客戶端與服務器端創建TCP鏈接後，客戶端終端使用者將花費幾分鐘甚至幾十分鐘填寫表單相關信息，終端使用者終於填好表單所需信息後，點擊「提交」按鈕，結果，這個時候因爲中間設備早已經將這個TCP鏈接從鏈接表中刪除了，其將直接丟棄這個報文或者給客戶端發送RST報文，應用故障產生，這將致使客戶端終端使用者全部的工做將須要從新來過，給使用者帶來極大的不便和損失。

 

TCP保活報文格式

TCP keepalive probe報文

1.咱們看到，TCP保活探測報文是將以前TCP報文的序列號減1，並設置1個字節，內容爲「00」的應用層數據 ，以下圖所示：

發送keepalive probe報文以前的TCP報文

2.TCP keepalive ACK報文

TCP保活探測確認報文就是對保活探測報文的確認， 其報文格式以下：

TCP keepalive ACK報文

 

TCP保活報文交互過程

TCP保活的交互過程大體以下圖所示：

 

TCP保活可能帶來的問題

1. 中間設備因大量保活鏈接，致使其鏈接表滿

   網關設備因爲保活問題，致使其鏈接表滿，沒法新建鏈接（XX局網閘故障案例）或性能降低嚴重

2. 正常鏈接被釋放

   當鏈接一端在發送保活探測報文時，中間網絡正好因爲各類異常（如鏈路中斷、中間設備重啓等）而沒法將該保活探測報文正確轉發至對端時，可能會致使探測的一方釋放原本正常的鏈接，可是這種可能狀況發生的機率較小，另外，通常也能夠增長保活探測報文發生的次數來減少這種狀況發生的機率和影響。

 

TCP保活的設置

通常而言，保活探測主要在服務器端實現，若是應用層有相應的保活機制時，傳輸層的TCP保活就能夠不用。

=========END=========