陳碩 (giantchen AT gmail)
blog.csdn.net/Solstice
前幾天我在新浪微博上出了兩道有關 TCP 的思考題，引發了一場討論 http://weibo.com/1701018393/eCuxDrta0Nn 。
第一道初級題目是：
有一臺機器，它有一個 IP，上面運行了一個 TCP 服務程序，程序只偵聽一個端口，問：從理論上講（只考慮 TCP/IP 這一層面，不考慮IPv6）這個服務程序可以支持多少并發 TCP 連接？答 65536 上下的直接刷掉。
具體來說，這個問題等價于：有一個 TCP 服務程序的地址是 1.2.3.4:8765，問它從理論上能接受多少個并發連接？
第二道進階題目是：
一臺被測機器 A，功能同上，同一交換機上還接有一臺機器 B，如果允許 B 的程序直接收發以太網 frame，問：讓 A 承擔 10 萬個并發 TCP 連接需要用多少 B 的資源？100萬個呢？
從討論的結果看，很多人做出了第一道題，而第二道題幾乎無人問津。
這里先不公布答案（第一題答案見文末），讓我們繼續思考一個本質的問題：一個 TCP 連接要占用多少系統資源。
在現在的 Linux 操作系統上，如果用 socket()/connect() 或 accept() 來創建 TCP 連接，那么每個連接至少要占用一個文件描述符(file descriptor)。為什么說“至少”？因為文件描述符可以復制，比如 dup()；也可以被繼承，比如 fork()；這樣可能出現系統里邊同一個 TCP 連接有多個文件描述符與之對應。據此，很多人給出的第一題答案是：并發連接數受限于系統能同時打開的文件數目的最大值。這個答案在實踐中是正確的，卻不符合原題意。
如果拋開操作系統層面，只考慮 TCP/IP 層面，建立一個 TCP 連接有哪些開銷？理論上最小的開銷是多少？考慮兩個場景：
1. 假設有一個 TCP 服務程序，向這個程序成功發起連接需要做哪些事情？換句話說，如何才能讓這個 TCP 服務程序認為有客戶連接到了它（讓它的 accept() 調用正常返回）？
2. 假設有一個 TCP 客戶端程序，讓這個程序成功建立到服務器的連接需要做哪些事情？換句話說，如何才能讓這個 TCP 客戶端程序認為它自己已經連接到服務器了（讓它的 connect() 調用正常返回）？
以上這兩個問題問的不是如何編程，如何調用 Sockets API，而是問如何讓操作系統的 TCP/IP 協議棧認為任務已經成功完成，連接已經成功建立。
學過 TCP/IP 協議，理解三路握手的同學明白，TCP 連接是虛擬的連接，不是電路連接，維持 TCP 連接理論上不占用網絡資源（會占用兩頭程序的系統資源）。只要連接的雙方認為 TCP 連接存在，并且可以互相發送 IP packet，那么 TCP 連接就一直存在。
對于問題 1，向一個 TCP 服務程序發起一個連接，客戶端（為明白起見，以下稱為 faketcp 客戶端）只需要做三件事情（三路握手）：
1a. 向 TCP 服務程序發一個 IP packet，包含 SYN 的 TCP segment
1b. 等待對方返回一個包含 SYN 和 ACK 的 TCP segment
1c. 向對方發送一個包含 ACK 的 segment
在做完這三件事情之后，TCP 服務器程序會認為連接已建立。而做這三件事情并不占用客戶端的資源（？），如果faketcp 客戶端程序可以繞開操作系統的 TCP/IP 協議棧，自己直接發送并接收 IP packet 或 Ethernet frame 的話。換句話說，faketcp 客戶端可以一直重復做這三件事件，每次用一個不同的 IP:PORT，在服務端創建不計其數的 TCP 連接，而 faketcp 客戶端自己毫發無損。很快我們將看到如何用程序來實現這一點。
對于問題 2，為了讓一個 TCP 客戶端程序認為連接已建立，faketcp 服務端只需要做兩件事情：
2a. 等待客戶端發來的 SYN TCP segment
2b. 發送一個包含 SYN 和 ACK 的 TCP segment
2c. 忽視對方發來的包含 ACK 的 segment
在做完這兩件事情（收一個 SYN、發一個 SYN+ACK）之后，TCP 客戶端程序會認為連接已建立。而做這三件事情并不占用 faketcp 服務端的資源（？）換句話說，faketcp 服務端可以一直重復做這兩件事件，接受不計其數的 TCP 連接，而 faketcp 服務端自己毫發無損。很快我們將看到如何用程序來實現這一點。
基于對以上兩個問題的分析，說明單獨談論“TCP 并發連接數”是沒有意義的，因為連接數基本上是要多少有多少。更有意義的性能指標或許是：“每秒鐘收發多少條消息”、“每秒鐘收發多少字節的數據”、“支持多少個活動的并發客戶”等等。
faketcp 的程序實現
代碼見： https://github.com/chenshuo/recipes/tree/master/faketcp 可以直接用 make 編譯
為了驗證我上面的說法，我寫了幾個小程序來實現 faketcp，這幾個程序可以發起或接受不計其數的 TCP 并發連接，并且不消耗操作系統資源，連動態內存分配都不會用到。
我家里有一臺運行 Ubuntu Linux 10.04 的 PC 機，hostname 是 atom，所有的試驗都在這上面進行。
家里試驗環境的網絡配置是：
陳碩在《談一談網絡編程學習經驗》中曾提到“可以用 TUN/TAP 設備在用戶態實現一個能與本機點對點通信的 TCP/IP 協議棧”，這次的試驗正好可以用上這個辦法。
試驗的網絡配置是：
具體做法是：在 atom 上通過打開 /dev/net/tun 設備來創建一個 tun0 虛擬網卡，然后把這個網卡的地址設為 192.168.0.1/24，這樣 faketcp 程序就扮演了 192.168.0.0/24 這個網段上的所有機器。atom 發給 192.168.0.2~192.168.0.254 的 IP packet 都會發給 faketcp 程序，faketcp 程序可以模擬其中任何一個 IP 給 atom 發 IP packet。
程序分成幾步來實現。
第一步：實現 icmp echo 協議，這樣就能 ping 通 faketcp 了。
代碼見 https://github.com/chenshuo/recipes/blob/master/faketcp/icmpecho.cc
其中響應 icmp echo request 的函數在 https://github.com/chenshuo/recipes/blob/master/faketcp/faketcp.cc#L57 這個函數在后面的程序中也會用到。
運行方法，打開 3 個命令行窗口：
1. 在第 1 個窗口運行 sudo ./icmpecho ，程序顯示
allocted tunnel interface tun0
2. 在第 2 個窗口運行
$ sudo ifconfig tun0 192.168.0.1/24
$ sudo tcpdump -i tun0
3. 在第 3 個窗口運行
$ ping 192.168.0.2
$ ping 192.168.0.3
$ ping 192.168.0.234
發現每個 192.168.0.X 的 IP 都能 ping 通。
第二步：實現拒絕 TCP 連接的功能，即在收到 SYN TCP segment 的時候發送 RST segment。
代碼見 https://github.com/chenshuo/recipes/blob/master/faketcp/rejectall.cc
運行方法，打開 3 個命令行窗口，頭兩個窗口的操作與前面相同，運行的 faketcp 程序是 ./rejectall
3. 在第 3 個窗口運行
$ nc 192.168.0.2 2000
$ nc 192.168.0.2 3333
$ nc 192.168.0.7 5555
發現向其中任意一個 IP 發起的 TCP 連接都被拒接了。
第三步：實現接受 TCP 連接的功能，即在收到SYN TCP segment 的時候發回 SYN+ACK。這個程序同時處理了連接斷開的情況，即在收到 FIN segment 的時候發回 FIN+ACK。
代碼見 https://github.com/chenshuo/recipes/blob/master/faketcp/acceptall.cc
運行方法，打開 3 個命令行窗口，步驟與前面相同，運行的 faketcp 程序是 ./acceptall。這次會發現 nc 能和 192.168.0.X 中的每一個 IP 每一個 PORT 都能連通。還可以在第 4 個窗口中運行 netstat –tpn ，以確認連接確實建立起來了。如果在 nc 中輸入數據，數據會堆積在操作系統中，表現為 netstat 顯示的發送隊列（Send-Q）的長度增加。
第四步：在第三步接受 TCP 連接的基礎上，實現接收數據，即在收到包含 payload 數據 的 TCP segment 時發回 ACK。
代碼見 https://github.com/chenshuo/recipes/blob/master/faketcp/discardall.cc
運行方法，打開 3 個命令行窗口，步驟與前面相同，運行的 faketcp 程序是 ./acceptall。這次會發現 nc 能和 192.168.0.X 中的每一個 IP 每一個 PORT 都能連通，數據也能發出去。還可以在第 4 個窗口中運行 netstat –tpn ，以確認連接確實建立起來了，并且發送隊列的長度為 0。
這一步已經解決了前面的問題 2，扮演任意 TCP 服務端。
第五步：解決前面的問題 1，扮演客戶端向 atom 發起任意多的連接。
代碼見 https://github.com/chenshuo/recipes/blob/master/faketcp/connectmany.cc
這一步的運行方法與前面不同，打開 4 個命令行窗口。
1. 在第 1 個窗口運行 sudo ./connectmany 192.168.0.1 2007 1000 ，表示將向 192.168.0.1:2007 發起 1000 個并發連接。
程序顯示
allocted tunnel interface tun0
press enter key to start connecting 192.168.0.1:2007
2. 在第 2 個窗口運行
$ sudo ifconfig tun0 192.168.0.1/24
$ sudo tcpdump -i tun0
3. 在第 3 個窗口運行一個能接收并發 TCP 連接的服務程序，可以是 httpd，也可以是 muduo 的 echo 或 discard 示例，程序應 listen 2007 端口。
4. 回到第 1 個窗口中敲回車，然后在第 4 個窗口中用 netstat -tpn 來觀察并發連接。
有興趣的話，還可以繼續擴展，做更多的有關 TCP 的試驗，以進一步加深理解，驗證操作系統 TCP/IP 協議棧面對不同輸入的行為。甚至可以按我在《談一談網絡編程學習經驗》中提議的那樣，實現完整的 TCP 狀態機，做出一個簡單的 mini tcp stack。
第一道題的答案：
在只考慮 IPv4 的情況下，并發數的理論上限是 2**48。考慮某些 IP 段被保留了，這個上界可適當縮小，但數量級不變。實際的限制是操作系統全局文件描述符的數量，以及內存大小。
一個 TCP 連接有兩個 end points，每個 end point 是 {ip, port}，題目說其中一個 end point 已經固定，那么留下一個 end point 的自由度，即 2 ** 48。客戶端 IP 的上限是 2**32 個，每個客戶端IP發起連接的上限是 2**16，乘到一起得理論上限。
即便客戶端使用 NAT，也不影響這個理論上限。（為什么？）
在真實的 Linux 系統中，可以通過調整內核參數來支持上百萬并發連接，具體做法見：
http://urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
(.完.)