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