TCP 心跳

TCP Keepalive 是一種用于檢測 TCP 連接是否活躍的機制，通過定期發送探測數據包來確定連接的狀態，主要用于檢測空閑 (僵尸) 連接、保持 NAT 映射 (NAT 設備、防火墻設備) 等。

1.原理簡述

• 要啟用 TCP Keepalive 自動檢測機制，需要通信雙方都開啟 Keepalive 選項
• 如果在一定時間(默認 2 小時)內沒有數據傳輸，TCP 會發送一個 Keepalive 探測數據包
• 如果通信的對方仍然活躍，就會對該探測數據包進行響應，如果對方沒有響應，TCP 將重試發送探測數據包
• 在達到最大重試次數(默認 10 次)后，如果仍然未收到響應，TCP 將認為連接已斷開，關閉連接

下面是根據 TCP Keepalive 工作原理，轉換后的邏輯偽代碼 (針對單個 TCP 連接)。

# TCP Keepalive 控制參數
KEEPALIVE_INTERVAL = 7200  # 默認 2 小時
KEEPALIVE_PROBES = 10   # 默認 10 次
KEEPALIVE_TIMEOUT = 75  # 默認 75 秒

# 開啟 TCP Keepalive 機制
# 初始化各項控制參數
def enable_keepalive(socket):
    socket.setsockopt(..., socket.SO_KEEPALIVE, 1)

    socket.setsockopt(..., KEEPALIVE_INTERVAL)
    socket.setsockopt(..., KEEPALIVE_PROBES)
    socket.setsockopt(... KEEPALIVE_TIMEOUT)

# 如果連接在 Keepalive 間隔時間內處于空閑狀態
# 發送 Keepalive 探測包并啟動探測計時器
def send_keepalive_probe(socket):
    if is_idle(socket, KEEPALIVE_INTERVAL):
        send_probe_packet(socket)
        start_probe_timer(socket)

# 處理 Keepalive 響應
# 如果收到探測包的 ACK 確認，則重置空閑計時器
# 否則增加探測次數
#   如果超過最大探測次數，則關閉連接
# Function to handle keepalive response
def handle_keepalive_response(socket):
    if received_probe_ack(socket):
        reset_idle_timer(socket)
    else:
        increment_probe_count(socket)
        
        if probe_count(socket) > KEEPALIVE_PROBES:
            close_connection(socket)

# 檢查Keepalive超時
# 如果探測計時器過期，則處理 Keepalive 響應
def check_keepalive_timeout(socket):
    if probe_timer_expired(socket):
        handle_keepalive_response(socket)

# 核心主循環管理 Keepalive
# 1. 啟用 Keepalive 選項
# 2. 在連接打開時定期發送探測包和檢查超時
# Main loop to manage keepalive
def manage_keepalive(socket):
    enable_keepalive(socket)
    
    while is_open(socket):
        send_keepalive_probe(socket)
        check_keepalive_timeout(socket)
        time.sleep(KEEPALIVE_TIMEOUT) 

...
...

2.相關參數

Linux 內核中和 TCP Keepalive 機制相關的幾個參數如下:

• tcp_keepalive_time：首次探測之前的空閑時間(默認 2 小時)
• tcp_keepalive_intvl：重試探測的時間間隔(默認 75 秒)
• tcp_keepalive_probes：最大重試次數(默認 10 次)

當然，這些參數都可以通過修改系統配置文件進行修改，尤其在優化高并發場景和移動場景為主的后端服務器時，這幾個參數需要著重優化一下:

# 設置首次探測之前的空閑時間為 10 分鐘
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

# 設置重試探測的時間間隔為 15 秒
echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl

# 設置最大重試次數為 3 次
echo 3 > /proc/sys/net/ipv4/tcp_keepalive_probes

運行 sysctl -p 命令生效，重啟之后仍然有效。

3.局限性

TCP Keepalive 機制由內核 (操作系統) 負責執行，當進程退出后，內核會針對進程中未關閉的連接逐個進行關閉 (向連接的通信對方發送 FIN 報文)，這樣就保證了每個連接的通信雙方都可以知道通信的狀態，并根據狀態來完成不同的具體業務邏輯。

表面上看，不論進程是運行還是退出，TCP Keepalive 機制都可以通過內核很好地完成，但是在一些極端場景中，內核無法保證 TCP 協議棧正常工作，例如：

• 操作系統異常導致重啟，TCP 協議棧沒有機會發送 FIN 報文
• 服務器硬件故障、基礎設置故障 (如斷電、斷網、地理不可抗力因素)，TCP 協議棧同樣沒有機會發送 FIN 報文
• 海量并發連接數，操作系統或進程重啟時，TCP 協議?？赡軣o法斷開所有連接，也就是 FIN 報文出現丟包后，沒有更多的時間進行重試
• 網絡鏈路故障，只能等到 TCP Keepalive 檢測超時，通信雙方才能確認這種情況，此時距離發生故障可能已經過去了一段時間

應用層心跳

1.必要性

前文中講到了 TCP Keepalive 機制 (內核實現) 的局限性，除此之外，結合到應用層一起來看的話，TCP Keepalive 機制無法確認應用層的心跳檢測目標：應用程序還在正常工作。具體來說，TCP Keepalive 檢測結果正常，只能說明兩件事情：

• 應用程序 (進程) 還存在
• 網絡鏈路正常

但是 當應用程序進程運行中發生異常時，例如死鎖、Bug 導致的無限循環、無限阻塞 等，雖然此時操作系統依然可以正常執行 TCP Keepalive 機制，但是對于應用程序的異常情況，通信對方是無法得知的。

此外，應用層心跳檢測具有更好的靈活性，例如可以控制檢測時間、間隔、異常處理機制、附加額外數據等。

綜上所述，應用層心跳檢測是必須實現的。

2.實現方式

常見的應用層心跳實現方式有:

• HTTP: 訪問指定 URL, 根據響應碼或者響應數據來判定應用是否正常
• Exec: 執行指定 (Shell) 命令 (例如文件檢查、網絡檢查)，并檢查命令的退出狀態碼，如果狀態碼為 0，說明應用正常運行
• WebSocket: 和 HTTP 檢測方式類似
• 其他自定義檢測方式

其中業界主流的檢測方式是 HTTP (長連接方式), 主要是因為:

• HTTP 實現簡單，基于長連接的方式避免了連接的建立和釋放帶來的開銷
• HTTP 對于 (異構) 環境的要求很低，而且大多數應用中都使用 HTTP 作為 API 主要通信協議，心跳檢測并不會帶來多少額外的工作量

3.實現細節

(1) 不要單獨實現 “心跳線程”

使用單獨的線程來實現 “心跳檢測”，雖然可以將心跳檢測應用代碼和具體的業務邏輯代碼隔離，但是當 “業務線程” 發生死鎖或者 Bug 崩潰時，心跳線程檢測不到。

所以應該將心跳檢測直接實現在 “業務線程” 中。

(2) 不要單獨實現 “心跳連接”

對于網絡 (例如 TCP) 編程的場景，心跳檢測應該在 “業務連接” 直接實現，而不是使用單獨的連接，這樣當業務連接出現異常時，通信對方可以第一時間感知到 (沒有及時收到心跳響應)。

此外，大多數網絡防火墻會定時監測空閑 (僵尸) 連接并清除，如果心跳檢測使用額外的連接，那么當 “業務連接” 長時間沒有要發送的數據時，就已經被防火墻斷開了，但是此時心跳檢測連接還在正常工作，這會影響通信對方的判斷，以為 “業務連接” 還在正常工作。

所以應該將心跳檢測直接實現在 “業務連接” 中。