關(guān)于 TCP 與 100Gbps+ 場(chǎng)景的細(xì)說(shuō)，參見(jiàn)：單流 TCP 100Gbps+ 難題的直觀解釋

400Gbps 網(wǎng)絡(luò)將又是一個(gè) “硬件準(zhǔn)備好了，可軟件沒(méi)跟上” 的場(chǎng)景。

把一條 TCP Flow 看作一個(gè)操作系統(tǒng)進(jìn)程，多條 Flow 共享 10Gbps 帶寬和多進(jìn)程被同一個(gè) CPU 調(diào)度一樣。
我們知道，SMP 場(chǎng)景下，應(yīng)用程序和操作系統(tǒng)需要重新設(shè)計(jì)，將原來(lái)的大塊邏輯拆得粒度更細(xì)，以便并行，同時(shí)，操作系統(tǒng)盡量避免爭(zhēng)鎖，比如 Linux 內(nèi)核大量采用 per-cpu 變量。數(shù)據(jù)結(jié)構(gòu)互不依賴(lài)，細(xì)邏輯便可自由在多個(gè)核心并行亂序執(zhí)行。

但以上這段話發(fā)生地極其緩慢，從我記憶中的 2006 年開(kāi)始，直到今天很多邏輯依然沒(méi)有完成改造，這是 “硬件準(zhǔn)備好了，軟件沒(méi)跟上” 的典型一例。

400Gbps 網(wǎng)絡(luò)將是另外一例，不管廠商叫得多歡，軟件難題依然改變不了挑戰(zhàn)。

我來(lái)用 400Gbps 場(chǎng)景重寫(xiě)上面那段話。

我們知道，400Gbps 場(chǎng)景下，端到端傳輸協(xié)議和交換機(jī)需要重新設(shè)計(jì)，將流拆得粒度更細(xì)，以便并行傳輸和處理，同時(shí)，交換機(jī)盡量避免將多個(gè)流安排到同一個(gè)隊(duì)列，避免 HoL。數(shù)據(jù)包 or subflow/flowlet 前后互不依賴(lài)，便可自由在多條路徑亂序傳輸并被端主機(jī)多核資源負(fù)載均衡處理。
就差指名道姓了，說(shuō)的就是傳統(tǒng) TCP。

先看端能力的問(wèn)題。

TCP 的保序性約束同一個(gè)流不能并行傳輸和處理。簡(jiǎn)單算一筆賬，單流 400Gbps 吞吐需要每秒收發(fā) (400/8)10001000*1000/1460 個(gè)數(shù)據(jù)包，大致 34246575 個(gè)，即每微秒處理 34 個(gè)數(shù)據(jù)包。

大致估算一下 25Gbps 場(chǎng)景下 Intel? Xeon? Platinum 8260 CPU @ 2.40GHz 的收包能力，關(guān)閉 GRO/LRO，下圖三欄分別為 top/iperf -s -i 1/funclantency tcp_v4_rcv 的結(jié)果：

一款不錯(cuò)的 CPU 單核極限能力不到 10Gbps，發(fā)送端關(guān)閉 TSO/GSO，接收端 CPU 下降，但 tcp_v4_rcv 的執(zhí)行能力已達(dá)上限，接收端打開(kāi) GRO/LRO，tcp_v4_rcv 開(kāi)銷(xiāo)變大，達(dá)到 1500us 以上。

雙邊啟用硬件卸載，志強(qiáng) CPU 的 TCP 單流處理極限大約在 60～80Gbps。

TCP 協(xié)議邏輯過(guò)于復(fù)雜，這意味著更多的 CPU 指令周期，難有 CPU 能支撐 20ns～30ns 處理一個(gè) 1460 字節(jié)的數(shù)據(jù)包(或者 80ns～200ns 處理一個(gè)更大的 LRO 聚合數(shù)據(jù)包)。

既然單個(gè) CPU 不行，多個(gè)總可以。32 個(gè) CPU 并行，妥妥 1us 處理 30+ 個(gè)數(shù)據(jù)包。但 TCP 需要保序，不允許并行處理同一條流。這便是一個(gè)簡(jiǎn)單的障礙。

如果允許亂序傳輸，上述瓶頸即可被打破。我說(shuō) TCP 不適合 400Gbps 網(wǎng)絡(luò)，這話并不過(guò)分。一定是便于并行處理的亂序傳輸協(xié)議才更適配 400Gbps。

對(duì)于非 TCP 協(xié)議，仍然受限于 CPU 的指令周期處理極限以及內(nèi)存帶寬極限，越復(fù)雜的協(xié)議邏輯有效吞吐越低，雖然通過(guò)堆 CPU 核數(shù)能有所優(yōu)化，但專(zhuān)用硬件顯然更適合適配 400Gbps。

各類(lèi) Hardware offloading 方案，RDMA/RoCEv2 只是開(kāi)端。

再說(shuō)擁塞控制。

范雅各布森管道理論，瓶頸 buffer 等于 BDP 可在 AIMD 策略下獲得最佳帶寬利用率，buffer 小于 BDP - alpha 為淺隊(duì)列，buffer 大于 BDP + alpha 屬深隊(duì)列。各類(lèi)端到端擁塞控制算法孰優(yōu)孰劣便圍繞著 buffer 大小展開(kāi)。

400Gbps，40us 鏈路，BDP 達(dá) 2MB，需更大 buffer 平滑統(tǒng)計(jì)突發(fā)，但更大 buffer 承受更大突發(fā)的同時(shí)，在大收斂比節(jié)點(diǎn)也要承受更大扇入，引入更大延遲，影響公平性。同時(shí)，更大的 buffer 意味著更大的成本。

雖然 PFC，ECN 機(jī)制已經(jīng)可逐跳或者端到端反饋擁塞，但卻不得不以額外延時(shí)為代價(jià)。即便如此，絕大多數(shù)數(shù)據(jù)都可在 1 個(gè) RTT 無(wú)反饋傳輸完畢(400Gbps BDP 約 MB 級(jí)別)而無(wú)緣 ECN 之惠。

說(shuō)到底，如今的擁塞控制機(jī)制幾乎全依賴(lài)反饋到端執(zhí)行，中間節(jié)點(diǎn)沒(méi)有一種簡(jiǎn)單的分流能力。

比方說(shuō)，一個(gè)端口發(fā)生擁塞，交換機(jī)立即將流量引導(dǎo)到稍微空閑的等價(jià)路徑。而該機(jī)制需要不同于傳統(tǒng)最短路徑路由的新基礎(chǔ)設(shè)施來(lái)支撐。雖然 SDN 控制器可提供支撐，但分布式方案目前尚未存在。

Google 的 PLB 提供了重新選路的思路，但依然需要將擁塞反饋到端后由端執(zhí)行 re-path，考慮流的 Multi-Path，亂序傳輸，需要由端來(lái)綜合調(diào)度擁塞信息。

由于收斂比，扇入的存在，擁塞不可避免，高吞吐與低延時(shí)看似不可兼得。但該結(jié)論顯然來(lái)自傳統(tǒng)的假設(shè)，端到端傳輸協(xié)議控制數(shù)據(jù)流沿著最短路徑到達(dá)對(duì)端。在 400Gbps 場(chǎng)景，反過(guò)來(lái)更合適，即啞端專(zhuān)用硬件盲發(fā)數(shù)據(jù)包，數(shù)據(jù)包沿著多條路徑亂序傳輸，轉(zhuǎn)發(fā)節(jié)點(diǎn)以分流，反壓的方式進(jìn)行擁塞控制，可同時(shí)獲得高吞吐和低延時(shí)。

簡(jiǎn)單舉一例，一服務(wù)器網(wǎng)卡按照 400Gbps 發(fā)送(而不是傳統(tǒng)單流)，其中一個(gè)或幾個(gè)數(shù)據(jù)包屬于某類(lèi)低延時(shí)敏感業(yè)務(wù)，由于途中交換機(jī)某端口擁塞，這些數(shù)據(jù)包不得不忍受排隊(duì)，而對(duì)它們標(biāo)記 ECN 毫無(wú)意義，因?yàn)樗鼈儗儆趩螖?shù)據(jù)包(此類(lèi)數(shù)據(jù)包非常多)。

無(wú)論對(duì)于短消息還是長(zhǎng)流，即時(shí)處理?yè)砣偸堑脱訒r(shí)的最佳選擇：
與端到端原則的 TCP/IP 協(xié)議棧相反，400Gbps 場(chǎng)景的傳輸控制協(xié)議族，復(fù)雜性從端移到了中心，第一時(shí)間處理?yè)砣娣答亾砣?#xff0c;這是低延時(shí)的核心。連帶效果，端在傳輸邏輯方面的弱化也將更多資源留給了計(jì)算，端資源給計(jì)算，中心資源給傳輸。

只要 TCP 深刻在你心里，你可能就不明白我說(shuō)的 “依賴(lài)反饋” 到底意味著什么。再舉一例，假設(shè)瓶頸帶寬達(dá) 400Tbps (而不是 400Gbps)，你要在 40us 的鏈路傳輸 100MB。簡(jiǎn)單算一下，100MB 大概需要 68493 個(gè) 1460 字節(jié)的數(shù)據(jù)包，仍假設(shè)初始窗口 10(很不合理)，慢啟動(dòng)階段，窗口隨 RTT 倍增，大概不到 12 個(gè) RTT 就能傳完 100MB，而慢啟動(dòng)尚未結(jié)束，諸如 BBR 復(fù)雜的邏輯不起作用。如果初始窗口因大帶寬改為 100000(很合理)，一個(gè)初始窗口即可完成傳輸，甚至慢啟動(dòng)也不需要，至多一次丟包反饋后重傳。

或者說(shuō)就問(wèn)一句，如果不依賴(lài)反饋，如何進(jìn)行擁塞控制。端到端算法可榨取的收益早已捉襟見(jiàn)肘，需修改中心的算法才能有所改變。

400Gbps 準(zhǔn)備好了，人們依然指望 TCP 可適配，一個(gè)進(jìn)程無(wú)法充分利用 SMP，一條 TCP 也無(wú)法跑 400Gbps，人們一開(kāi)始用多個(gè)進(jìn)程去跑 SMP，現(xiàn)在人們用多條 TCP 跑滿(mǎn) 400Gbps，顯然，后者粒度太粗，正如進(jìn)程粒度太粗一樣。核心還是分割可并行單元，進(jìn)程之外可調(diào)度更細(xì)粒度的線程，協(xié)程。同理，重寫(xiě)傳輸協(xié)議可實(shí)現(xiàn)消息粒度(介于數(shù)據(jù)包和傳統(tǒng)數(shù)據(jù)流之間)并行傳輸和處理，當(dāng) “X程” 在多核上無(wú)阻塞調(diào)度時(shí)，消息也在網(wǎng)絡(luò)無(wú)排隊(duì)分流。

總之，無(wú)論從端能力還是擁塞控制來(lái)看，400Gbps 網(wǎng)絡(luò)受上層邏輯約束越少越好(與直覺(jué)相反，比如，如果網(wǎng)卡不認(rèn)識(shí)五元組，便可將每個(gè)數(shù)據(jù)包分發(fā)到不同的 CPU)：

• 消息短小則數(shù)據(jù)包之間無(wú)依賴(lài)，可有效利用端主機(jī)資源并行處理。
• 消息短小則數(shù)據(jù)包之間無(wú)依賴(lài)，可有效利用多等價(jià)路徑亂序傳輸。
• 不存在長(zhǎng)流，交換機(jī)更看不到長(zhǎng)流，長(zhǎng)流要切成短消息亂序傳輸。
• 400Gbps 網(wǎng)絡(luò)只管傳輸，不管協(xié)議邏輯。

顯然，硬件準(zhǔn)備好了，可軟件還沒(méi)跟上。但早晚會(huì)跟上，各類(lèi) RDMA，Homa，以及 AWS 的 SRD 已經(jīng)在路上，拭目以待。

最近跟朋友聊起 100Gbps，200Gbps，400Gbps 網(wǎng)絡(luò)，總覺(jué)得這玩意兒能跑起來(lái)嗎，在協(xié)議層面尚未 ready 時(shí)，會(huì)不會(huì)造成浪費(fèi)。聯(lián)想修高速公路，一般雙向 8 車(chē)道就頂配了，剩下的就是提升限速和提升安全車(chē)速，而不是增加車(chē)道，所以我覺(jué)得為什么不去研究空心光纖呢，將光纖傳輸速率提升到光速的 80%+(不細(xì)說(shuō)，容易被民科)。… 想到 TCP 誕生的 1970s，網(wǎng)速遠(yuǎn)小于主機(jī)處理速度，它的一切協(xié)議邏輯都是合理的，適應(yīng)彼時(shí)硬件的，一路發(fā)展到網(wǎng)卡將要逆襲 CPU，CPU 反而成了外設(shè)的當(dāng)今，TCP 反而成了雞肋，還是有點(diǎn)適者生存的進(jìn)化理念的，什么樣架構(gòu)的硬件，就需要什么樣的軟件與之搭伴，否則硬件就是沒(méi)有競(jìng)爭(zhēng)力的。正如 CSMA/CD 搭伴了同軸電纜，迅速以簡(jiǎn)單易部署占領(lǐng)了市場(chǎng)，才發(fā)展到如今的百Gbps，軟件伴隨硬件的強(qiáng)化而升級(jí)，比較有趣，寫(xiě)篇隨筆。

浙江溫州皮鞋濕，下雨進(jìn)水不會(huì)胖。

總結(jié)

以上是生活随笔為你收集整理的400Gbps 网络面临的挑战的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。