設想這種情況，tcp連線建立後，在一段時間範圍內雙發沒有互相傳送任何資料。思考以下兩個問題：
長時間沒有任何資料傳送，連線可能會被中斷。這是因為，網路連線中間可能會經過路由器、防火牆等裝置，而這些有可能會對長時間沒有活動的連線斷掉。
基於上面兩點考慮，需要保活機制。
保活機制是由乙個保活計時器實現的。當計時器被激發，連線一段將傳送乙個保活探測報文，另一端接收報文的同時會傳送乙個ack作為響應。
1、相關配置
保活時間間隔：預設75秒
保活探測數：預設9次
檢視linux系統中tcp保活機制對應的系統配置如下（不同系統實現可能不同）：
sl@li:/proc/sys/net/ipv4$ cat tcp_keepalive_time
7200
sl@li:/proc/sys/net/ipv4$ cat tcp_keepalive_intvl
75sl@li:/proc/sys/net/ipv4$ cat tcp_keepalive_probes
9
連線中啟動保活功能的一端，在保活時間內連線處於非活動狀態，則向對方傳送乙個保活探測報文，如果收到響應，則重置保活計時器，如果沒有收到響應報文，則經過乙個保活時間間隔後再次向對方傳送乙個保活探測報文，如果還沒有收到響應報文，則繼續，直到傳送次數到達保活探測數，此時，對方主機將被確認為不可到達，連線被中斷。
tcp保活功能工作過程中，開啟該功能的一端會發現對方處於以下四種狀態之一：
對方主機仍在工作，並且可以到達。此時請求端將保活計時器重置。如果在計時器超時之前應用程式通過該連線傳輸資料，計時器再次被設定為保活時間值。
對方主機已經崩潰，包括已經關閉或者正在重新啟動。這時對方的tcp將不會響應。請求端不會接收到響應報文，並在經過保活時間間隔指定的時間後超時。超時前，請求端會持續傳送探測報文，一共傳送保活探測數指定次數的探測報文，如果請求端沒有收到任何探測報文的響應，那麼它將認為對方主機已經關閉，連線也將被斷開。
客戶主機崩潰並且已重啟。在這種情況下，請求端會收到乙個對其保活探測報文的響應，但這個響應是乙個重置報文段rst，請求端將會斷開連線。
對方主機仍在工作，但是由於某些原因不能到達請求端（例如網路無法傳輸，而且可能使用icmp通知也可能不通知對方這一事實）。這種情況與狀態2相同，因為tcp不能區分狀態2與狀態4，結果是都沒有收到探測報文的響應。
三、保活機制的弊端
理解了上面的實現，就可以發現其存在以下兩點主要弊端：
在出現短暫的網路錯誤的時候，保活機制會使乙個好的連線斷開；
保活機制會占用不必要的頻寬；
所以，保活機制是存在爭議的，主要爭議之處在於是否應在tcp協議層實現，有兩種主要觀點：其一，保活機制不必在tcp協議中提供，而應該有應用層實現；其二，認為大多數應用都需要保活機制，應該在tcp協議層實現。
保活功能在預設情況下是關閉的。沒有經過應用層的請求，linux系統不會提供保活功能。
保活 心跳機制
英文 heartbeat mechanism 中文 保活機制 心跳機制 介紹 雙方建立互動的連線，但是並不是一直存在資料互動，有些連線會在資料互動完畢後，主動釋放連線，而有些不會，那麼在長時間無資料互動的時間段內，互動雙方都有可能出現掉電 宕機 異常重啟等各種意外，當這些意外發生之後，這些tcp連線...
TCP保活定時器
tcp有keepalive功能，它和http的keepalive功能目的不一樣。tcp伺服器希望知道客戶端是否崩潰 重新啟動或者中間路由不通。保活定時器就提供這種功能。在進一步介紹tcp的保活定時器前，先了解乙個概念 長連線和短連線。tcp是長連線 長連線 建立乙個連線，多個請求復用這個連線，最後再...
長連線 心跳保活機制
而在實現長連線方式時，存在很多效能問題，如 長連線保活 今天，我將 手把手教大家實現自適應的心跳保活機制，從而能高效維持長連線 確保實時性 避免短時間內重複連線所造成的通道資源 網路資源的浪費 可是，長連線會存在斷開的情況，而 斷開原因 主要是 長連線所在程序被殺死 nat超時 網路狀態發生變化 其...