TCP 半開連接成因與解決方案：從 SO_KEEPALIVE 到應用層心跳機制

在高併發、長連接的 Linux 服務端開發中，文件描述符（FD）是極其寶貴的資源。若大量 FD 被「半開連接」佔用，將直接導致服務器無法接受新連接，嚴重影響可用性。本文剖析半開連接的產生機制，並對比內核級與應用級兩種解決方案的優劣。

什麼是 TCP 半開連接？

當客戶端與服務端建立正常 TCP 連接後，若客戶端發生斷網、掉電、系統崩潰等異常情況，且未發送 FIN/RST 包，服務端的 TCP 協議棧將永遠不知道連接已失效。此時：

• 服務端調用 select/epoll 監測不到可讀/錯誤事件。
• 連接在服務端看來仍處於 ESTABLISHED 狀態。
• 對應的文件描述符長期佔用不釋放。

這種「一邊以為連接正常，另一邊已消失」的狀態，即為半開連接。

方案一：內核級 SO_KEEPALIVE 選項

TCP 協議棧提供 SO_KEEPALIVE 選項，機制如下：

1. 連接雙向無數據交換達到閾值（默認 2 小時），內核自動發送保活探測包（ACK）。
2. 對端響應 RST → 連接重置，錯誤碼 ECONNRESET，Socket 關閉。
3. 對端無響應（超時/丟包）→ 重試若干次後，錯誤碼 ETIMEDOUT，Socket 關閉。

致命缺陷：全局參數不可單獨調整

大多數內核將保活時間（tcp_keepalive_time）、間隔（tcp_keepalive_intvl）、重試次數（tcp_keepalive_probes）作為全局參數維護，而非針對單個 Socket。若將無活動周期從 2 小時改為 2 分鐘，將影響該主機上所有啟用該選項的連接，引入不可控的網絡開銷與誤判風險，生產環境極少直接修改內核參數。

方案二：應用層心跳包（推薦做法）

在應用協議層面模擬保活機制，彈性可控，不依賴內核全局參數：

• 客戶端主動發送心跳：定期發送自定義心跳包，連續 N 次無響應則主動關閉連接。
• 服務端被動檢測：維護每個連接的「最後收包時間」，定時掃描，超過閾值（如 60 秒）未收到心跳則主動關閉 Socket。

優勢

1. 精確控制：每個業務模塊可自定義心跳間隔、超時閾值、重試策略。
2. 跨平台：不依賴特定 OS 內核參數，遷移成本低。
3. 業務感知：心跳包可攜帶業務狀態（如會話版本、負載信息），實現「保活+狀態同步」雙重效果。

工程落地建議

• 心跳間隔建議 20~30 秒，超時判定 2~3 個間隔（60~90 秒）。
• 服務端使用時間輪或最小堆管理定時器，避免 O(N) 掃描。
• 關閉連接時務必調用 shutdown(fd, SHUT_RDWR) 再 close(fd)，確保發送 FIN 包，讓對端正常感知。
• 結合業務層「應答機制」：心跳請求需對端回應心跳響應，單向發送無法檢測對端接收鏈路故障。

總結：SO_KEEPALIVE 適合無法修改應用協議的存量系統；新建系統強烈建議在應用層實現心跳，掌握連接生命周期的完全控制權。