關于 TCP 與 100Gbps+ 場景的細說，參見：單流 TCP 100Gbps+ 難題的直觀解釋

400Gbps 網絡將又是一個 “硬件準備好了，可軟件沒跟上” 的場景。

把一條 TCP Flow 看作一個操作系統進程，多條 Flow 共享 10Gbps 帶寬和多進程被同一個 CPU 調度一樣。
我們知道，SMP 場景下，應用程序和操作系統需要重新設計，將原來的大塊邏輯拆得粒度更細，以便并行，同時，操作系統盡量避免爭鎖，比如 Linux 內核大量采用 per-cpu 變量。數據結構互不依賴，細邏輯便可自由在多個核心并行亂序執行。

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

400Gbps 網絡將是另外一例，不管廠商叫得多歡，軟件難題依然改變不了挑戰。

我來用 400Gbps 場景重寫上面那段話。

我們知道，400Gbps 場景下，端到端傳輸協議和交換機需要重新設計，將流拆得粒度更細，以便并行傳輸和處理，同時，交換機盡量避免將多個流安排到同一個隊列，避免 HoL。數據包 or subflow/flowlet 前后互不依賴，便可自由在多條路徑亂序傳輸并被端主機多核資源負載均衡處理。
就差指名道姓了，說的就是傳統 TCP。

先看端能力的問題。

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

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

一款不錯的 CPU 單核極限能力不到 10Gbps，發送端關閉 TSO/GSO，接收端 CPU 下降，但 tcp_v4_rcv 的執行能力已達上限，接收端打開 GRO/LRO，tcp_v4_rcv 開銷變大，達到 1500us 以上。

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

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

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

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

對于非 TCP 協議，仍然受限于 CPU 的指令周期處理極限以及內存帶寬極限，越復雜的協議邏輯有效吞吐越低，雖然通過堆 CPU 核數能有所優化，但專用硬件顯然更適合適配 400Gbps。

各類 Hardware offloading 方案，RDMA/RoCEv2 只是開端。

再說擁塞控制。

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

400Gbps，40us 鏈路，BDP 達 2MB，需更大 buffer 平滑統計突發，但更大 buffer 承受更大突發的同時，在大收斂比節點也要承受更大扇入，引入更大延遲，影響公平性。同時，更大的 buffer 意味著更大的成本。

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

說到底，如今的擁塞控制機制幾乎全依賴反饋到端執行，中間節點沒有一種簡單的分流能力。

比方說，一個端口發生擁塞，交換機立即將流量引導到稍微空閑的等價路徑。而該機制需要不同于傳統最短路徑路由的新基礎設施來支撐。雖然 SDN 控制器可提供支撐，但分布式方案目前尚未存在。

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

由于收斂比，扇入的存在，擁塞不可避免，高吞吐與低延時看似不可兼得。但該結論顯然來自傳統的假設，端到端傳輸協議控制數據流沿著最短路徑到達對端。在 400Gbps 場景，反過來更合適，即啞端專用硬件盲發數據包，數據包沿著多條路徑亂序傳輸，轉發節點以分流，反壓的方式進行擁塞控制，可同時獲得高吞吐和低延時。

簡單舉一例，一服務器網卡按照 400Gbps 發送(而不是傳統單流)，其中一個或幾個數據包屬于某類低延時敏感業務，由于途中交換機某端口擁塞，這些數據包不得不忍受排隊，而對它們標記 ECN 毫無意義，因為它們屬于單數據包(此類數據包非常多)。

無論對于短消息還是長流，即時處理擁塞總是低延時的最佳選擇：
與端到端原則的 TCP/IP 協議棧相反，400Gbps 場景的傳輸控制協議族，復雜性從端移到了中心，第一時間處理擁塞代替反饋擁塞，這是低延時的核心。連帶效果，端在傳輸邏輯方面的弱化也將更多資源留給了計算，端資源給計算，中心資源給傳輸。

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

或者說就問一句，如果不依賴反饋，如何進行擁塞控制。端到端算法可榨取的收益早已捉襟見肘，需修改中心的算法才能有所改變。

400Gbps 準備好了，人們依然指望 TCP 可適配，一個進程無法充分利用 SMP，一條 TCP 也無法跑 400Gbps，人們一開始用多個進程去跑 SMP，現在人們用多條 TCP 跑滿 400Gbps，顯然，后者粒度太粗，正如進程粒度太粗一樣。核心還是分割可并行單元，進程之外可調度更細粒度的線程，協程。同理，重寫傳輸協議可實現消息粒度(介于數據包和傳統數據流之間)并行傳輸和處理，當 “X程” 在多核上無阻塞調度時，消息也在網絡無排隊分流。

總之，無論從端能力還是擁塞控制來看，400Gbps 網絡受上層邏輯約束越少越好(與直覺相反，比如，如果網卡不認識五元組，便可將每個數據包分發到不同的 CPU)：

• 消息短小則數據包之間無依賴，可有效利用端主機資源并行處理。
• 消息短小則數據包之間無依賴，可有效利用多等價路徑亂序傳輸。
• 不存在長流，交換機更看不到長流，長流要切成短消息亂序傳輸。
• 400Gbps 網絡只管傳輸，不管協議邏輯。

顯然，硬件準備好了，可軟件還沒跟上。但早晚會跟上，各類 RDMA，Homa，以及 AWS 的 SRD 已經在路上，拭目以待。

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

浙江溫州皮鞋濕，下雨進水不會胖。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。