隨著大模型的廣泛流行，GPU集群計算的規模越來越大（單芯片算力提升有限，只能通過擴規模的方式來提升整體算力），千卡、萬卡已經成為主流，十萬卡、百萬卡也都在未來3-5年的規劃中。

集群計算的網絡可以分為兩類：南北向流量，也就是俗稱的外網流量；東西向流量，也就是俗稱的內網流量。集群計算的網絡連接數 S = N x (N-1)（N為節點數）。這也是為什么現在數據中心中東西向流量占比超過90%的原因所在。再加上系統規模擴大導致的南北向網絡流量的增加，這使得數據中心所需的網絡帶寬呈指數級增長趨勢。

2019年，NVIDIA收購Mellanox，憑借著在InfiniBand和ROCEv2領域的領先優勢，NVIDIA成為了高性能網絡的霸主。各大競爭對手不甘示弱，特別是AWS、阿里云等云計算廠家，都陸續推出了自己的高性能網絡協議和對應的產品，行業呈現百家爭鳴之象。高性能網絡，兵家必爭之地；未來誰主沉浮，我們拭目以待。

本篇文章，從軟硬件融合視角，對高性能網絡相關技術進行介紹并進行分析，讓大家一文看透高性能網絡。

1 高性能網絡綜述

1.1 網絡性能參數

網絡性能主要關心三個參數，帶寬、吞吐量和延遲：

帶寬：指特定時間段內可以傳輸的數據量。高帶寬并不一定保證最佳的網絡性能。例如，網絡吞吐量受到數據包丟失、抖動或延遲的影響，可能會遇到延遲問題。

吞吐量：指在特定時間段內能夠發送和接收的數據量。網絡上數據的平均吞吐量使用戶能夠深入了解成功到達正確目的地的數據包數量。為了高性能，數據包必須能夠到達正確目的地。如果在傳輸過程中丟失了太多數據包，則網絡性能可能不足。

延遲：數據包在發送后到達目的地所用的時間。我們將網絡延遲測量為往返行程。延遲的結果通常是不穩定和滯后的服務。例如視頻會議等，對延遲非常敏感。

除此之外，還有一個非常重要的指標，PPS（Packet Per Second，每秒傳輸數據包數）。許多網絡設備，在大包的時候，可以做到線速，但在小包（64字節）的情況下，其性能降低的非常嚴重，主要就是PPS能力不足引起的。所以，理想的情況是，在最小包的情況下，仍然能夠達到線速。

高性能網絡，就是要在低延遲（越低越好）、低抖動的情況下，（不管大包小包，任意網絡節點，都要）實現最高的吞吐量（無限接近于網絡帶寬）。當然了，這些參數是相互影響的，實際的系統是在這些參數之間取得的平衡。

1.2 復雜的網絡分層

OSI定義了七層網絡協議，實際工程應用的TCP/IP網絡協議一般為五層：

從下到上依次為：物理層、數據鏈路層、網絡層、傳輸層和應用層。

通常情況下，物理層、數據鏈層在硬件實現，而網絡層、傳輸層和應用層在軟件實現。

TCP/IP協議族是計算機網絡中使用的一組通信協議。包括的基礎協議有傳輸控制協議(TCP) 、互聯網協議(IP)，以及用戶數據報協議(UDP)。

以太網（Ethernet）是為了實現局域網通信而設計的一種技術，它規定了包括物理層的連線、電子信號和介質訪問層協議的內容。以太網是目前應用最普遍的網絡技術。

數據中心網絡要更加復雜，會分為Overlay網絡和Underlay網絡。如果按照功能邏輯把網絡分層，云計算數據中心網絡可以分成三層：

第一層，物理的基礎網絡連接，也就是我們通常所理解的Underlay底層承載網；

第二層，基于基礎的物理網絡構建的虛擬網絡，也就是我們通常理解的基于隧道的Overlay網絡；

第三層，各種用戶可見的應用級的網絡服務，比如接入網關、負載均衡等。也可以是其他需要用到網絡的普通應用。

物理的數據中心是一個局域網，通過Overlay網絡分割成數以萬計的虛擬私有網；域間隔離后，再需要一定的網絡安全機制實現高性能的跨域訪問。

依據網絡處理邏輯，網絡可以分為三部分：

第一階段，業務數據的封包/解包。Tx向的時候，把業務的數據按照既定的網絡格式進行封包；Rx向，則是把收到的數據包進行解包。

第二階段，網絡包的處理。比如Overlay網絡，需要將數據包再次進行封裝；比如防火墻，要對網絡包進行鑒別，是否允許傳輸（輸入輸出雙向）；比如網絡包加解密。

第三階段，網絡包的傳輸（Tx/Rx）。也即是高性能網絡關注的部分。

1.3 為什么需要高性能網絡

為什么需要高性能網絡？

原因一，網絡的極端重要性。

網絡連接的重要性：網絡連接所有節點，各類服務都通過網絡鏈接，用戶通過網絡遠程操作。沒有網絡，一切都是空的。

網絡的復雜性：業務系統，要么是單服務器級別的或者集群級別；網絡系統基本上都是數據中心級別，在整個數據中心的規模上，構建各種復雜的網絡業務邏輯，整個系統復雜度非常高，影響面也大。

網絡故障的嚴重性：計算服務器故障、存儲服務器故障都是局部的故障，而網絡故障則牽一發而動全身。任何一個微小的網絡故障，都可能會引起整個數據中心不可用。網絡故障一旦發生，必然是重大故障。

原因二，超大規模集群計算，東西向流量激增。數據中心復雜計算場景，系統持續解構，東西向流量激增，網絡帶寬要求迅速的從10G、25G升級到100G，甚至200G。

原因三，短距離傳輸，系統堆棧延遲凸顯。相比城域網或者全球互聯網絡，數據中心網絡傳輸距離很短，服務器系統堆棧的延遲凸顯。

原因四，CPU性能瓶頸，網絡處理延遲進一步加大。網絡帶寬快速增加，而CPU的性能已經瓶頸。網絡堆棧處理的CPU資源消耗快速增加，并且延遲還進一步增大。

原因五，跨服務器調用延遲敏感。而軟件服務之間的調用，要求跨服務器的遠程調用能夠低延遲，接近于本地調用的延遲。

1.4 網絡擁塞控制

網絡中如果存在太多的數據包，會導致包延遲，并且會因為超時而丟棄，從而降低傳輸性能，這稱為擁塞。高性能網絡，就是要充分利用網絡容量，提供低延遲網絡傳輸的同時，盡可能的避免網絡擁塞。

當主機發送的數據包數量在網絡的承載范圍之內時，送達與發送的數據包成正比例增長。但隨著負載接近網絡承載極限，偶爾突發的網絡流量會導致擁塞崩潰；當加載的數據包接近承載上限的時候，延遲會急劇上升，這就是網絡擁塞。

擁塞控制（Congestion Control，CC）和流量控制有什么區別？擁塞控制，確保網絡能夠承載所有到達的流量，是一個全局問題；流量控制，則是確保快速的發送方不會持續地以超過接收方接收能力的速率傳輸，是端到端傳輸的問題。

根據效果從慢到快，處理擁塞的辦法可以分為：

更高帶寬的網絡；

根據流量模式定制流量感知路由；

降低負載，如準入控制；

給源端傳遞反饋信息，要求源端抑制流量；

一切努力失敗，網絡丟棄無法傳遞的數據包。

擁塞控制算法的基本原則如下：

優化的帶寬分配方法，既能充分利用所有的可用帶寬卻能避免擁塞；

帶寬分配算法對所有傳輸是公平的，既保證大象流，也保證老鼠流；

擁塞控制算法能夠快速收斂。

1.5 等價多路徑路由ECMP

CLOS架構是一種用于構建高性能、高可靠性數據中心網絡的拓撲結構。受東西向流量激增等原因影響，數據中心為滿足大通量網絡流量的需求，網絡拓撲通常采用CLOS結構。CLOS架構會使得主機和主機之間就存在多條網絡路徑，而“多路徑”是實現高性能和高可靠網絡的基礎。

如何利用數據中心網絡拓撲、路徑資源、帶寬資源等，更好的實現網絡流量的負載均衡，將數據流分布到不同路徑上進行數據傳輸，避免擁塞，提高數據中心內的資源利用率，就變得越來越重要。

ECMP（Equal-Cost Multi-Path routing，等價多路徑路由）是一個逐跳的基于流的負載均衡策略，當路由器發現同一目的地址出現多個最優路徑時，會更新路由表，為此目的地址添加多條規則，對應于多個下一跳?？赏瑫r利用這些路徑轉發數據，增加帶寬。

ECMP常見的路徑選擇策略有多種方法：

哈希，例如根據源IP地址的哈希為流選擇路徑。

輪詢，各個流在多條路徑之間輪詢傳輸。

基于路徑權重，根據路徑的權重分配流，權重大的路徑分配的流數量更多。

需要注意的是，在數據中心這種突發性流量多，大象流與老鼠流并存的環境中，需要慎重考慮選擇的負載均衡策略，ECMP雖然簡單易部署，但也存在較多問題需要注意。

2 TCP/IP高性能網絡

TCP/IP協議棧主要指Ethernet+TCP/IP+Socket的整個系統棧。

2.1 TCP/IP協議棧硬件卸載

第一類，TCP的部分特征卸載

TSO，TCP Segmentation Offload，利用網卡硬件能力對TCP數據包分段。

UFO，UDP Fragmentation Offload ，支持UDP發大包，硬件會進行分片。

LRO，Large Receive Offload，網卡硬件將接收到的多個TCP數據聚合成一個大的數據包。

RSS，Receive Side Scaling，將網絡流分成不同的隊列，再分別將這些隊列分配到多個CPU核處理。

CRC 卸載，由硬件完成CRC計算和封包。

第二類，TCP/IP協議棧卸載（TCP/IP Offload Engine，TOE）

傳統軟件網絡棧的處理開銷很大，把整個TCP/IP協議棧卸載到硬件，可以提升網絡處理的性能，顯著降低CPU代價。

Linux 標準內核不支持 TOE網卡，原因主要是：

安全性。TOE硬件實現，與OS中的經過良好測試的軟件TCP/IP棧相比，硬件的安全風險很大。

硬件約束。因為網絡連接在TOE芯片上進行緩沖和處理，與軟件可用的大量CPU和內存相比，資源匱乏更容易發生。

復雜性。TOE打破了kernel始終可以訪問所有資源的假設，還需要對網絡堆棧進行非常大的更改，即便如此，QoS和包過濾等功能也可能無法工作。

定制性。每個Vendor都是定制的TOE，這意味著必須重寫更多代碼來處理各種TOE實現，代價是方案的復雜性和可能的安全風險。此外，TOE固件閉源，軟件人員無法修改。

過時。TOE NIC使用壽命有限：CPU性能會迅速趕上并超過TOE性能；軟件系統棧的迭代會顯著快于硬件協議棧。

因此，受上述原因影響，TOE并沒有大規模使用起來。

2.2 應用層TCP/IP協議棧Onload

Onload是Solarflare（Solarflare已被Xilinx收購，Xilinx又被AMD收購）加速網絡中間件。主要特征包括：

基于IP的TCP/UDP實現，動態鏈接到用戶模式應用程序的地址空間，應用程序可以直接從網絡收發數據，而無需OS參與。

Onload實現的內核繞過（Kernel Bypass）可避免系統調用、上下文切換和中斷等破壞性事件，從而提高處理器執行應用程序代碼的效率。

Onload庫在運行時使用標準Socket API與應用程序動態鏈接，這意味著不需要對應用程序進行任何修改。

Onload通過減少CPU開銷、改善延遲和帶寬，以及提高應用的可擴展性，來顯著降低網絡成本。

Onload核心技術可以總結為：硬件虛擬化SR-IOV，內核bypass，以及應用SocketAPI。

2.3 傳輸協議優化：從TCP到QUIC

QUIC（Quick UDP Internet Connections，快速UDP互聯網連接）是一種新的互聯網傳輸協議，對L4、L5（安全）、L7進行部分或全部的優化和替代。

QUIC是一個應用自包含的協議，允許創新。這在現有協議中不可能實現，受遺留的客戶端和系統中間件的阻礙。

與TCP+TLS+HTTP2相比，QUIC的主要優點包括:

連接建立的延遲。簡單地說，QUIC握手在發送有效載荷之前需要0次往返，而TCP+TLS則需要1-3次往返。

改進的擁塞控制。QUIC主要實現并優化了TCP的慢啟動、擁塞避免、快重傳、快恢復，可以根據情況選擇不同的擁塞控制算法；避免TCP重傳歧義問題；允許精確的往返時間計算；等等。

無前端阻塞的多路復用。TCP存在行首阻塞問題，QUIC為多路復用操作設計，沒有損失的流可以繼續推進。

前向糾錯。為了在不等待重傳的情況下恢復丟失的數據包，QUIC可以用一個FEC數據包補充一組數據包。

連接遷移。TCP連接由四元組標識，QUIC連接由64位連接ID標識。如果客戶端更改了IP地址或端口，則TCP連接不再有效；而QUIC可以使用舊的連接ID，而不會中斷任何正在進行的請求。

3 高性能網絡協議棧綜述，以IB為例

3.1 IB網絡協議簡介

InfiniBand (IB)是一種用于高性能計算的網絡通信標準，具有極高的吞吐量和極低的延遲。

IB用于計算機之間和計算機內部的數據互連，還可以用作服務器和存儲系統之間的直接或交換互連，以及存儲系統之間的互連。

IB的設計目標：綜合考慮計算、網絡和存儲技術，設計一個可擴展的、高性能的通信和I/O體系結構。

IB的主要優點：

高性能，超算TOP500中一半左右采用IB；

低延遲，IB端到端測量延遲為1μs；

高效率，IB原生支持RDMA等協議，幫助客戶提高工作負載處理效率。

IB也是五層網絡分層：物理層、鏈路層、網絡層、傳輸層和應用層。傳統網絡的L1&L2硬件實現，而L3/L4軟件實現；而IB則是L1-L4均在硬件實現。IB傳輸層API即HCA網卡和CPU之間的軟硬件接口。Socket API是傳統TCP/IP網絡的應用網絡接口，而Verbs API是IB的應用網絡接口。MPI是一種通過提供并行庫來實現并行化的方法庫，MPI可以基于OFA Verbs API，也可以基于TCP/IP Socket。

3.2 IB為什么能夠高性能？

傳統網絡協議棧的問題：

長路徑，應用需要通過系統層連接到網卡；

多拷貝，很多拷貝是沒有必要的；

彈性能力不足，協議棧經過內核，這樣用戶就很難去優化協議功能。

通過網絡協議棧性能優化的四個方面，來總結IB全棧所采用的主要優化技術：

優化協議棧：簡化、輕量、解耦的系統堆棧。

加速協議處理：協議硬件加速處理， L2-L4多個協議層卸載；

減少中間環節：如RDMA kernel Bypass，IB網絡原生支持RDMA；

優化接口交互：如軟硬件交互機制，Send/Rcv Queue Pair、Work/Completion Queues。

3.3 InfiniBand vs Ethernet

Infiniband和Ethernet從多種方面的比較：

設計目標。Eth考慮多個系統如何流暢的信息交換，優先考慮兼容性與分布式；IB則是為了解決HPC場景數據傳輸瓶頸。

帶寬。IB的網絡速率通常快于Eth，主要原因是IB應用于HPC場景的服務器互聯，而Eth更多的是面向終端設備互聯。

延遲。Eth交換機處理的任務比較復雜，導致其延遲較大（>200ns）。而IB交換機處理非常簡單，遠快于Eth交換機（<100ns）。采用RDMA+IB的網絡收發延遲在600ns，而Eth+TCP/IP的收發延遲高達10us，相差10倍以上。

可靠性。丟包重傳對性能的影響非常大。IB基于端到端的流控，保證報文全程不擁塞，時延抖動控制到最小。Eth沒有基于調度的流控，極端情況會出現擁塞而導致丟包，使得數據轉發性能大幅波動。

組網方式。Eth網絡內節點的增刪都要通知到每一個節點，當節點數量增加到一定數量時，會產生廣播風暴。IB二層網絡內有子網管理器來配置LocalID，然后統一計算轉發路徑信息，可以輕松部署一個規模幾萬臺服務器的超大二層網絡。

4 RDMA高性能網絡

4.1 RDMA綜述

RDMA，是一種高帶寬、低延遲、低CPU消耗的網絡互聯技術，克服了傳統TCP/IP網絡的許多問題。RDMA技術特點：

遠程，數據在兩個節點之間傳輸；

直接，不需要內核參與，傳輸的處理都卸載到NIC硬件完成；

內存，數據在兩個節點的應用虛擬內存間傳輸，不需要額外的復制；

訪問，訪問操作有send/receive、read/write等。

RDMA的其他一些特征：

RDMA和IB是原生一體；

RoCEv1是基于標準Eth的RDMA；

RoCEv2基于標準Eth、IP和UDP，支持標準L3路由器。

4.2 RDMA/RoCEv2系統棧分層

RoCEv2是當前數據中心比較流行的RDMA技術，我們以RoCEv2為例，介紹RoCE的系統分層：

以太網層：標準以太網層，即網絡五層協議物理層和數據鏈路層。

網絡層IP：網絡五層協議中的網絡層。

傳輸層UDP：網絡五層協議中的傳輸層（UDP而不是TCP）。

IB傳輸層：負責數據包的分發、分割、通道復用和傳輸服務。

RDMA數據引擎層（Data Engine Layer）：負責內存隊列和RDMA硬件之間工作/完成請求的數據傳輸等。

RDMA接口驅動層：負責RDMA硬件的配置管理、隊列和內存管理，負責工作請求添加到工作隊列中，負責完成請求的處理等。接口驅動層和數據引擎層共同組成RDMA軟硬件接口。

Verbs API層：接口驅動Verbs封裝，管理連接狀態、管理內存和隊列訪問、提交工作給RDMA硬件、從RDMA硬件獲取工作和事件。

ULP層：OFED ULP（上層協議）庫，提供了各種軟件協議的RDMA verbs支持，讓上層應用可以無縫移植到RDMA平臺。

應用層：RDMA原生的應用，基于RDMA verbs API開發；OFA還提供OFED協議棧，讓已有應用可以無縫使用RDMA功能。

4.3 RDMA工作隊列

RDMA并沒有約束嚴格的軟硬件接口，各家的實現可以有所不同，只需要支持RDMA的隊列機制即可。

軟件驅動和硬件設備的交互通?；谏a者消費者模型，這樣能夠實現軟件和硬件交互的異步解耦。RDMA軟硬件共享的隊列數據結構稱為工作隊列（Work Queue）。

驅動負責把工作請求（Work Request）添加到工作隊列，成為工作隊列中的一項，稱為工作隊列項WQE。RDMA硬件設備會負責WQE在內存和硬件之間的傳輸，并且通過RDMA網絡最終把WQE送到接收方的工作隊列中去。

接收方RDMA硬件會反饋確認信息給到發送方RDMA硬件，發送方RDMA硬件會根據確認信息生成完成隊列項CQE發送到內存的完成隊列。

RDMA Queue類型有：發送隊列、接收隊列、完成隊列以及隊列對。發送隊列和接收隊列組成一組隊列對。SRQ，共享接收隊列。把一個RQ共享給所有關聯的QP使用，這個公用的RQ就稱為SRQ。

4.4 RDMA Verbs API

RDMA Verbs是提供給應用使用的RDMA功能和動作抽象。Verbs API則是Verbs具體實現，提供標準接口供應用調用。

RoCEv2中的Verbs操作主要有兩類：

Send/Recv。類似于Client/Server結構，發送操作和接收操作協作完成，在發送方連接之前，接收方必須處于偵聽狀態；發送方不知道接收方的虛擬內存位置，接收方也不知道發送方的虛擬內存地址。RDMA Send/Recv因為是直接對內存操作，需要提前注冊用于傳輸的內存區域。

Write/Read。與Client/Server架構不同，Write/Read是請求方處于主動，響應方處于被動。請求方執行Write/Read操作，響應方不需要做任何操作。為了能夠操作響應方的內存，請求方需要提前獲得響應方的地址和鍵值。

5 AWS SRD高性能網絡

5.1 AWS SRD和EFA綜述

SRD（Scalable Reliable Datagram，可擴展可靠數據報），是AWS設計的可靠的、高性能的、低延遲的網絡傳輸協議；EFA（Elastic Fabric Adapter，彈性互聯適配器），是AWS EC2實例提供的一種高性能網絡接口。 AWS的SRD和EFA技術主要有如下特征：

SRD基于標準的以太網，用于優化傳輸層協議。

SRD受IB可靠數據報的啟發，與此同時，考慮到大規模的云計算場景下的工作負載，利用了云計算的資源和特點（例如AWS的復雜多路徑主干網絡）來支持新的傳輸策略，為其在緊耦合的工作負載中發揮價值。

借助EFA，使用消息傳遞接口MPI的HPC應用，以及使用NVIDIA集體通信庫（NCCL）的ML應用，可以輕松擴展到數千個CPU或GPU。

EFA用戶空間軟件有兩個：基本驅動，暴露EFA硬件的可靠亂序交付能力；而在其之上的libfabric實現了包的重排序。

EFA類似于IB Verbs。所有EFA數據通信都通過發送/接收隊列對完成。依靠共享隊列機制，可顯著降低所需的QPs數量。

由消息傳遞層完成的緩沖區管理和流控制，與應用程序是緊密耦合的。

5.2 AWS為什么不選擇TCP或RoCE

AWS認為：

TCP是可靠數據傳輸的主要手段，但不適合對延遲敏感的處理。TCP的最優往返延遲大約25us，因擁塞等引起的等待時間可以到50ms，甚至數秒。主要原因是丟包重傳。

IB是用于HPC的高吞吐量、低延遲網絡，但IB不適合可擴展性要求。原因之一是RoCEv2的優先級流量控制(PFC)，在大型網絡上不可行。會造成隊頭阻塞、擁塞擴散和偶爾的死鎖。即使PFC可用，RoCE在擁塞和次優擁塞控制下仍會遭受ECMP（Equal-Cost Multi-Path routing，等價多路徑路由）沖突。

SRD針對超大規模數據中心進行了優化：跨多個路徑的負載平衡、快速恢復、發送方控制ECMP、專門的擁塞控制算法、可靠但亂序的交付等。

SRD是在AWS Nitro卡中實現。讓SRD盡可能靠近物理網絡層，避免OS和Hypervisor性能噪音注入?？煽焖僦貍鞑⒀杆贉p速以響應隊列建立。SRD作為EFA設備公開給主機，EFA是Amazon EC2實例的網絡接口。

5.3 SRD特征之一：多路負載均衡

為了更好的多路負載均衡，AWS的SRD遵循如下原則：

為了減少丟包的幾率，流量應該在可用路徑上均勻分布。

SRD發送方需要在多個路徑上Spray（噴灑）數據包（即使是單個應用程序流），特別是大象流。以最小化熱點出現的可能性，并檢測次優路徑。

為了與未啟用多路徑的傳統流量共享網絡，因此隨機Spray流量是不合適的，SRD避免使用過載路徑。

因為規模的原因，偶爾的硬件故障不可避免。為了讓網絡從鏈路故障中快速恢復，如果原始傳輸路徑不可用，SRD能夠重新路由重傳的數據包，而無需等待路由更新收斂。

5.4 SRD特征之二：亂序交付

在網絡傳輸中，平衡多條可用路徑上的流量有助于減少排隊延遲并防止數據包丟失；但不可避免地會導致數據包的無序到達。

與此同時，眾所周知，恢復網卡中的數據包排序代價昂貴，網卡通常具有有限的資源（內存帶寬、重排序緩沖容量或開放排序上下文的數量）。

如果按順序發送接收消息，將限制可伸縮性或在出現丟包時增加平均延遲。如果推遲向主機軟件發送亂序數據包，將需要一個非常大的緩沖區，并且將大大增加平均延遲。并且許多數據包會因為延遲可能被丟棄，重傳增加了無謂的網絡帶寬消耗。

SRD設計為：將可能亂序的數據包，不做處理，直接傳送到主機。

應用程序處理亂序數據包，在字節流協議，如TCP，是不可行的，但在基于消息的語義時很容易。每個流的排序或其他類型的依賴追蹤由SRD之上的消息傳遞層完成；消息層排序信息與數據包一起傳輸到另一端，SRD是不可見的。

5.5 SRD特征之三：擁塞控制

Incast，是一種流量模式，許多流量匯聚到交換機的同一接口，耗盡該接口的緩沖空間，導致數據包丟失。

多路徑Spray減少了中間交換機的負載，但其本身并不能緩解Incast擁塞問題。Spray可能會使Incast問題變得更糟：即使發送方受自身鏈路帶寬限制，來自發送方不同時刻的流量，也可能通過不同的路徑同時到達。對于多路徑傳輸來說，擁塞控制將所有路徑上的聚合隊列保持在最小值至關重要。

因此，SRD CC的目標是：用最少的飛行中的數據量，獲得最公平的帶寬共享，防止隊列堆積和數據包丟失。發送方需要根據速率估計調整其每個連接的傳輸速率，速率估計依據確認包的時間提示，同時需要考慮最近的傳輸速率和RTT的變化。

6 其他高性能網絡技術

6.1 微軟Fungible的Truefabric

TrueFabric是開放標準的網絡技術，提高數據中心的性能、經濟性、可靠性和安全性，單集群規模從幾個到數千機架。

橫向擴展數據中心，所有服務器節點都通過可靠的高性能局域網連接。目前，大多數數據中心仍構建在Eth+TCP/IP之上。

局域網比廣域網速度快三個數量級或更多，TCP/IP成為性能的瓶頸。TCP卸載并不成功，很難在CPU和卸載引擎之間清晰拆分TCP。

網絡接口和SSD設備的性能比通用CPU提高得更快；系統持續解構，東西向流量激增。I/O技術和業務應用的發展，給網絡棧帶來了巨大的壓力。

TrueFabric的所有特性，都是通過基于標準UDP/ IP以太網的新型Fabric控制協議(FCP)實現。

TrueFabric支持：中小規模，服務器節點直連Spine交換機；大規模，兩層拓撲，Spine和Leaf交換機；FCP還可以支持三層或更多層交換機的更大規模網絡。

右圖為TrueFabric網絡部署的抽象視圖，有四種服務器類型：CPU服務器、AI/數據分析服務器、SSD服務器和HDD服務器。每個服務器實例包含一個Fungible DPU。

TrueFabric/FCP的特性

可擴展性：可以從使用100GE接口的小規模部署，擴展到使用200/400GE接口的數十萬臺服務器的大規模署。

全截面帶寬：支持端到端的全截面帶寬，適用于標準IP的以太網數據包大小。TrueFabric支持短的、低延遲消息的高效交換。

低延遲和低抖動：提供節點之間的最小延遲，以及非常嚴格的長尾延遲控制。

公平性：在競爭節點之間以微秒粒度公平分配網絡帶寬。

擁塞避免：內置的主動擁塞避免，這意味著數據包基本上不會因為擁塞而丟失。并且，擁塞避免技術并不依賴于核心網絡交換機的特性。

容錯：內置的數據包丟失檢測和恢復，錯誤恢復比依賴于路由協議的傳統恢復技術快五個數量級。

軟件定義的安全和策略：支持基于AES的端到端加密。可以通過配置將特定的部署劃分為單獨加密域。

開放標準：FCP建立在基于以太網的標準IP之上，可以與以太網上的標準TCP/IP完全互操作。

上圖是TrueFabric和RoCEv2在10:1 Incast下的性能比較。右上圖可以看到，Truefabric在P99長尾延遲方面，相比ROCEv2有非常顯著的提升。從下面兩張圖的RoCEv2和Truefabric性能抖動對比來看，Truefabric的性能穩定性要顯著優于RoCEv2。

6.2 阿里云HPCC和eRDMA

阿里云的HPCC（High Precision Congestion Control，高精度擁塞控制），其關鍵方法是利用INT（In-Network Telemetry，網絡內遙測）提供的精確的鏈路負載信息來計算準確的流量更新。

大規模RDMA網絡在平衡低延遲、高帶寬利用率和高穩定性方面面臨挑戰。經典的RDMA擁塞機制，例如DCQCN和TIMELY算法，具有一些局限性：收斂緩慢、不可避免的數據包排隊、復雜的調參參數。

HPCC發送方可以快速提高流量以實現高利用率，或者快速降低流量以避免擁塞；HPCC發送者可以快速調整流量，以使每個鏈接的輸入速率略低于鏈接的容量，保持高鏈接利用率；由于發送速率是根據交換機直接測量的結果精確計算得出的，HPCC僅需要3個獨立參數即可調整公平性和效率。

與DCQCN、TIMELY等方案相比，HPCC對可用帶寬和擁塞的反應更快，并保持接近零的隊列。

彈性RDMA（Elastic Remote Direct Memory Access，簡稱eRDMA）是阿里云自研的云上彈性RDMA網絡，底層鏈路復用VPC網絡，采用全棧自研的擁塞控制CC（Congestion Control，HPCC）算法，享有傳統RDMA網絡高吞吐、低延遲特性的同時，可支持秒級的大規模RDMA組網。可兼容傳統HPC應用，以及傳統TCP/IP應用。

eRDMA能力主要具有以下產品優勢：

高性能。RDMA繞過內核協議棧，將數據直接從用戶態程序轉移到HCA中進行網絡傳輸，極大地降低了CPU負載和延遲。eRDMA具有傳統RDMA網卡的優點，同時將傳統的RDMA技術應用到VPC網絡下。

規模部署。傳統的RDMA依賴于網絡的無損特性，規模部署成本高、規模部署困難。而eRDMA在實現中采用了自研的擁塞控制CC算法，容忍VPC網絡中的傳輸質量變化（延遲、丟包等），在有損的網絡環境中依然擁有良好的性能表現。

彈性擴展。不同于傳統的RDMA網卡需要單獨一個硬件網卡，eRDMA可以在使用ECS的過程中動態添加設備，支持熱遷移，部署靈活。

共享VPC網絡。eRDMA依附于彈性網卡（ENI），網絡完全復用，可以在不改變業務組網的情況下，即可在原來的網絡下激活RDMA功能，體驗到RDMA。

6.3 新興的Ultra-Ethernet

2023年7 月，超以太網聯盟 (Ultra Ethernet Consortium，UEC) 正式成立，它是一個由 Linux 基金會及其聯合開發基金會倡議主辦的新組織。UEC 的目標是超越現有的以太網功能，例如遠程直接內存訪問 ( RDMA ) 和融合以太網RDMA (RoCE)，提供針對高性能計算和人工智能進行優化的高性能、分布式和無損傳輸層，直接將矛頭對準競爭對手的傳輸協議 InfiniBand。

人工智能和高性能計算給網絡帶來了新的挑戰，比如需要更大規模、更高帶寬密度、多路徑、對擁塞的快速反應以及對單個數據流執行度的相互依賴（其中尾延遲是關鍵考量點）。UEC 規范的設計將彌補這些差距，并為這些工作任務提供所需的更大規模組網。UEC 的目標是一個完整的通信棧，解決跨越多個協議層的技術問題，并提供易于配置和管理的功能。

UEC將提供基于以太網的開放、可互操作、高性能的全通信堆棧架構，以滿足大規模人工智能和高性能計算不斷增長的網絡需求。從物理層到軟件層，UEC計劃對以太網堆棧的多個層進行更改。

UEC的技術目標是開發規范、API 和源代碼，UEC定義：

以太網通信的協議、電信號和光信號特征、應用程序接口/數據結構。

鏈路級和端到端網絡傳輸協議，可擴展或替換現有鏈路和傳輸協議。

鏈路級和端到端擁塞、遙測和信令機制，均適用于人工智能、機器學習和高性能計算環境。

支持各種工作負載和操作環境的軟件、存儲、管理和安全結構。

UEC傳輸協議:

從一開始就設計為在IP和以太網上運行的開放協議規范。

多路徑、包噴灑傳輸，充分利用AI網絡，不會造成擁塞或隊頭阻塞，無需集中式負載均衡算法和路由控制器。

Incast管理機制，以最小的丟包控制到目標主機的最終鏈接上的扇入。

高效的速率控制算法，允許傳輸快速提升至線速，同時不會導致競爭流的性能損失。

用于無序數據包傳送的 API，可選擇按順序完成消息，最大限度地提高網絡和應用程序的并發性，并最大限度地減少消息延遲。

可擴展未來網絡，支持1,000,000個端點。

性能和最佳網絡利用率，無需針對網絡和工作負載進行特定的擁塞算法參數調優。

旨在在商用硬件上實現 800G、1.6T 和未來更快以太網的線速性能。

7 全球互聯網絡的高性能

隨著5G通信基礎設施的大規模覆蓋，短視頻、視頻會議等多媒體應用的大量使用，自動駕駛和智能網聯汽車的廣泛落地，以及VR/AR元宇宙的快速發展，對整個全球互聯網絡的吞吐量、實時性、穩定性等各個方面提出了更高的要求。

上圖為聲網通過基于SDN架構的SD-RTN（軟件定義全球實時網絡）技術，構建全球實時通信網絡，利用廉價的邊緣節點和獨特的智能路由加速技術，讓全球端到端延遲控制在400ms以內。

8 高性能網絡總結

8.1 高性能網絡優化總結

高性能網絡優化的主要手段：

網絡容量升級：例如網絡帶寬升級，把整個網絡從25Gbps升級到100Gbps；例如更多的網絡端口和連線。

輕量協議棧：數據中心網絡跟互聯網不在一個層級，物理距離短，堆棧延遲敏感，可以不需要復雜的用于全球物理互聯的TCP/IP協議棧；

網絡協議硬件加速處理；

高性能軟硬件交互：高效交互協議 + PMD + PF/VF/MQ等，如AWS EFA；

高性能網絡優化：通過①多路負載均衡、②亂序交付、③擁塞控制、④多路處理并行等技術（例如AWS SRD技術），實現①低延遲、②高可靠性（低性能抖動）、③高網絡利用率。

8.2 從高性能網絡協議?？聪到y分層

從高性能網絡協議棧看系統分層：

系統是由多個分層（layer）組成。

每個分層可以當作獨立的組件模塊，根據需要，選擇不同分層，并對業務敏感的特定層進行定制設計和優化，組合出符合業務需求的個性化的系統解決方案。

即使分層間有很好的解耦，但每個分層仍不是孤立的；每個分層不宜是一個黑盒，這樣無法從系統層次對其進行優化；要想實現極致的性能，需要系統棧不同分層間的通力協作。

全棧優化。系統需要不斷優化，每個分層需要不斷優化，上下分層間的交互接口也需要不斷優化，分層的運行平臺也需要不斷優化。

每個分層、交互接口以及整個系統，都需要持續不斷的變化，來適應業務需求的變化。