TCP保活的緣起
雙方建立互動的連接配接，但是并不是一直存在資料互動，有些連接配接會在資料互動完畢後，主動釋放連接配接，而有些不會，那麼在長時間無資料互動的時間段内，互動雙方都有可能出現掉電、當機、異常重新開機等各種意外，當這些意外發生之後，這些TCP連接配接并未來得及正常釋放，那麼，連接配接的另一方并不知道對端的情況，它會一直維護這個連接配接，長時間的積累會導緻非常多的半打開連接配接，造成端系統資源的消耗和浪費，為了解決這個問題，在傳輸層可以利用TCP的保活封包來實作。
TCP保活的作用
1， 探測連接配接的對端是否存活
在應用互動的過程中，可能存在以下幾種情況：
（1）， 用戶端或伺服器端意外斷電、當機、崩潰、重新開機
（2）， 中間網絡已經中斷，而用戶端與伺服器端并不知道
利用保活探測功能，可以探知這種對端的意外情況，進而保證在意外發生時，可以釋放半打開的TCP連接配接。
2， 防止中間裝置因逾時删除連接配接相關的連接配接表
中間裝置如防火牆等，會為經過它的資料封包建立相關的連接配接資訊表，并為其設定一個逾時時間的定時器，如果超出預定時間，某連接配接無任何封包互動的話，中間裝置會将該連接配接資訊從表中删除，在删除後，再有應用封包過來時，中間裝置将丢棄該封包，進而導緻應用出現異常，這個互動的過程大緻如下圖所示：
這種情況在有防火牆的應用環境下非常常見，這會給某些長時間無資料互動但是又要長時間維持連接配接的應用（如資料庫）帶來很大的影響，為了解決這個問題，應用本身或TCP可以通過保活封包來維持中間裝置中該連接配接的資訊，（也可以在中間裝置上開啟長連接配接屬性或調高連接配接表的釋放時間來解決，但是，這個影響可能較大，有機會再針對這個做詳細的描述，在此不多說）。
常見應用故障場景：
某财務應用，在用戶端需要填寫大量的表單資料，在用戶端與伺服器端建立TCP連接配接後，用戶端終端使用者将花費幾分鐘甚至幾十分鐘填寫表單相關資訊，終端使用者終于填好表單所需資訊後，點選“送出”按鈕，結果，這個時候由于中間裝置早已經将這個TCP連接配接從連接配接表中删除了，其将直接丢棄這個封包或者給用戶端發送RST封包，應用故障産生，這将導緻用戶端終端使用者所有的工作将需要重新來過，給使用者帶來極大的不便和損失。
TCP保活封包格式：
1， TCP keepalive probe封包
我們看到，TCP保活探測封包是将之前TCP封包的序列号減1，并設定1個位元組，内容為“00”的應用層資料，如下圖所示：
發送keepalive probe封包之前的TCP封包
TCP keepalive probe封包
2， TCP keepalive ACK封包
TCP保活探測确認封包就是對保活探測封包的确認， 其封包格式如下：
TCP keepalive ACK封包
TCP保活封包互動過程
TCP保活的互動過程大緻如下圖所示：
TCP保活可能帶來的問題
1， 中間裝置因大量保活連接配接，導緻其連接配接表滿
網關裝置由于保活問題，導緻其連接配接表滿，無法建立連接配接（XX局網閘故障案例）或性能下降嚴重
2， 正常連接配接被釋放
當連接配接一端在發送保活探測封包時，中間網絡正好由于各種異常（如鍊路中斷、中間裝置重新開機等）而無法将該保活探測封包正确轉發至對端時，可能會導緻探測的一方釋放本來正常的連接配接，但是這種可能情況發生的機率較小，另外，一般也可以增加保活探測封包發生的次數來減小這種情況發生的機率和影響。
TCP保活的設定
一般而言，保活探測主要在伺服器端實作，如果應用層有相應的保活機制時，傳輸層的TCP保活就可以不用。
在windows系統中，我們可以通過修改系統資料庫等來達到開啟、調整保活相關
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
KeepAliveInterval
項：Tcpip\Parameters
數值類型：REG_DWORD - 時間（以毫秒為機關）
有效範圍：1 - 0xFFFFFFFF
預設值：1000（1 秒）
說明：此參數确定在收到響應之前，保活重傳之間的時間間隔。一旦收到一個響應，将由 KeepAliveTime 值重新控制在下一次保活傳輸之前的延遲。如果經過 TcpMaxDataRetransmissions 指定的重新傳輸次數後仍無響應，将放棄連接配接。
KeepAliveTime
預設值：7,200,000（兩個小時）
說明：此參數控制 TCP 試圖通過發送保活資料包來驗證空閑連接配接是否仍然保持的次數。如果遠端系統仍然可以連接配接并且正在運作，它就會響應保活傳輸。預設情況下不發送保活資料包。應用程式可以在連接配接上啟用此功能。
關于Linux、HP UNIX、IBM AIX、SUN solaris等系統keepalive參數的設定和修改，請大家自行百度谷歌，在此我就不做簡單搬磚的事情了。
本文轉自1清風攬月1 51CTO部落格，原文連結：http://blog.51cto.com/watchmen/1975587，如需轉載請自行聯系原作者