TCP 並發連接數理論極限與 faketcp 實驗驗證

先前在微博發起兩道 TCP 思考題引發熱烈討論。本文深入分析 TCP 連接資源佔用本質，並以 faketcp 實驗驗證理論推論。

兩道思考題

初級題

單 IP、單埠 TCP 服務程式，理論上可支援多少並發連接？答案 65536 直接刷掉。

進階題

被測機 A 跑同樣服務，同交換機有機器 B 可直接收發乙太網框架。讓 A 承擔 10 萬/100 萬並發連接，需要多少 B 的資源？

核心分析：TCP 連接的真實開銷

拋開作業系統層面，僅從 TCP/IP 協議棧角度：

場景 1：向 TCP 服務發起連接（客戶端視角）

faketcp 客戶端只需完成三次交握：

1. 發送 SYN 封包
2. 等待 SYN+ACK 回應
3. 發送 ACK 確認

完成後服務端認為連接已建立。若 faketcp 繞過核心協議棧直接收發 IP 封包，可用不同 IP:PORT 無限建立連接，自身不佔用資源。

場景 2：讓 TCP 客戶端認為連接已建立（服務端視角）

faketcp 服務端只需：

1. 等待客戶端 SYN
2. 回送 SYN+ACK
3. 忽略客戶端 ACK

同理可無限接受連接而不佔用自身資源。

結論：並發連接數理論上限

單獨談「TCP 並發連接數」無意義，因為基本上要多少有多少。更有意義的指標：每秒訊息數、每秒位元組數、活躍並發客戶數。

理論上限計算： IPv4 下，連接由兩端點 {IP, PORT} 定義。伺服器端點固定，客戶端端點自由度為 2^32 (IP) × 2^16 (PORT) = 2^48。扣除保留 IP 段後數量級不變。NAT 不影響此理論上限。

faketcp 實驗實作與驗證

程式碼：GitHub faketcp 專案，可直接 make 編譯。

實驗環境

• Ubuntu Linux 10.04，hostname atom
• 建立 tun0 虛擬網卡 (/dev/net/tun)，IP 設為 192.168.0.1/24
• faketcp 模擬整個 192.168.0.0/24 網段機器

五步驟驗證流程

1. ICMP Echo 回應： icmpecho.cc，驗證 ping 192.168.0.x 全通
2. 拒絕所有 TCP 連接： rejectall.cc，收到 SYN 回 RST
3. 接受所有 TCP 連接： acceptall.cc，回 SYN+ACK，處理 FIN 斷開
4. 接收資料並回 ACK： discardall.cc，解決「扮演任意 TCP 服務端」
5. 主動發起大量連接： connectmany.cc，解決「扮演客戶端向 atom 發起任意多連接」

實驗結果

成功驗證：單一 faketcp 程式可建立/接受數萬連接，不消耗作業系統資源（甚至無動態記憶體配置），證明 TCP 連接本質是雙端點狀態協議，而非實體電路連接。

實務參考：Linux 核心調校支援百萬連接

• Linux Kernel Tuning for 500k Connections
• Million User Comet Application