• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            陳碩的Blog

            關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn)

            陳碩 (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)銷?理論上最小的開(kāi)銷是多少?考慮兩個(gè)場(chǎng)景:

            1. 假設(shè)有一個(gè) TCP 服務(wù)程序,向這個(gè)程序成功發(fā)起連接需要做哪些事情?換句話說(shuō),如何才能讓這個(gè) TCP 服務(wù)程序認(rèn)為有客戶連接到了它(讓它的 accept() 調(diào)用正常返回)?

            2. 假設(shè)有一個(gè) TCP 客戶端程序,讓這個(gè)程序成功建立到服務(wù)器的連接需要做哪些事情?換句話說(shuō),如何才能讓這個(gè) TCP 客戶端程序認(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è)連接,客戶端(為明白起見(jiàn),以下稱為 faketcp 客戶端)只需要做三件事情(三路握手):

            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)為連接已建立。而做這三件事情并不占用客戶端的資源(?),如果faketcp 客戶端程序可以繞開(kāi)操作系統(tǒng)的 TCP/IP 協(xié)議棧,自己直接發(fā)送并接收 IP packet 或 Ethernet frame 的話。換句話說(shuō),faketcp 客戶端可以一直重復(fù)做這三件事件,每次用一個(gè)不同的 IP:PORT,在服務(wù)端創(chuàng)建不計(jì)其數(shù)的 TCP 連接,而 faketcp 客戶端自己毫發(fā)無(wú)損。很快我們將看到如何用程序來(lái)實(shí)現(xiàn)這一點(diǎn)。

            對(duì)于問(wèn)題 2,為了讓一個(gè) TCP 客戶端程序認(rèn)為連接已建立,faketcp 服務(wù)端只需要做兩件事情:

            2a. 等待客戶端發(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 客戶端程序會(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ā)客戶”等等。

            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ò)配置是:

            net

            陳碩在《談一談網(wǎng)絡(luò)編程學(xué)習(xí)經(jīng)驗(yàn)》中曾提到“可以用 TUN/TAP 設(shè)備在用戶態(tài)實(shí)現(xiàn)一個(gè)能與本機(jī)點(diǎn)對(duì)點(diǎn)通信的 TCP/IP 協(xié)議棧”,這次的試驗(yàn)正好可以用上這個(gè)辦法。

            試驗(yàn)的網(wǎng)絡(luò)配置是:

            tun

            具體做法是:在 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,扮演客戶端向 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è)窗口中敲回車,然后在第 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。客戶端 IP 的上限是 2**32 個(gè),每個(gè)客戶端IP發(fā)起連接的上限是 2**16,乘到一起得理論上限。

            即便客戶端使用 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

             

            (.完.)

            posted on 2011-07-01 12:50 陳碩 閱讀(6735) 評(píng)論(7)  編輯 收藏 引用 所屬分類: muduo

            評(píng)論

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn) 2011-07-01 22:38 lijsf

            你好,我有個(gè)問(wèn)題想問(wèn)一下,像這樣的并發(fā)連接,在UDP上是否可以實(shí)現(xiàn)呢?  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn) 2011-07-02 10:32 陳碩

            @lijsf
            UDP ?!  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn) 2011-07-02 18:38 xLight

            恩,理論題  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn) 2011-07-07 22:26 放屁阿狗

            ulimit一下,即使百萬(wàn)也是沒(méi)有意義的,導(dǎo)致的結(jié)果就是每個(gè)fdset檢測(cè)時(shí)效率極低  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn)[未登錄](méi) 2012-05-13 12:03 lee

            2**48是2的48次方,還是20048?  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn) 2012-05-13 12:29 Solstice

            @lee
            前者  回復(fù)  更多評(píng)論   

            # re: 關(guān)于 TCP 并發(fā)連接的幾個(gè)思考題與試驗(yàn)[未登錄](méi) 2012-05-13 14:16 lee

            2的48次方,天文數(shù)字!!!@Solstice
              回復(fù)  更多評(píng)論   

            <2011年4月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊(cè)

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            久久99精品久久久久久野外| 欧美日韩中文字幕久久久不卡| 国产69精品久久久久观看软件| 亚洲国产精品综合久久网络| 久久久国产打桩机| 久久久久久久精品成人热色戒| 久久久久久国产精品美女| 久久99国产乱子伦精品免费| 韩国无遮挡三级久久| 伊色综合久久之综合久久| 中文精品久久久久人妻不卡| 国产日韩久久久精品影院首页| 噜噜噜色噜噜噜久久| 91亚洲国产成人久久精品| 国产精品久久久久蜜芽| 久久国产免费观看精品| 狠狠色综合网站久久久久久久高清 | 久久精品国产免费观看| 伊人色综合久久| 久久国产色AV免费观看| 亚洲午夜福利精品久久| 国产精品综合久久第一页| 久久er99热精品一区二区| 2020久久精品亚洲热综合一本| 99久久精品免费看国产免费| 久久精品国产亚洲AV麻豆网站| 久久只这里是精品66| 狠狠久久综合伊人不卡| 欧美久久精品一级c片片| 久久精品aⅴ无码中文字字幕重口| 日韩欧美亚洲综合久久影院Ds| 久久亚洲高清观看| 亚洲国产精品久久久久久| 精品久久久久久综合日本| 无码日韩人妻精品久久蜜桃| 久久久久波多野结衣高潮| 亚洲?V乱码久久精品蜜桃 | 久久精品蜜芽亚洲国产AV| 久久ZYZ资源站无码中文动漫| 人妻精品久久久久中文字幕一冢本| 久久亚洲sm情趣捆绑调教|