軟硬件融合視角：一文看懂高性能網(wǎng)絡(luò)

編者按

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

集群計(jì)算的網(wǎng)絡(luò)可以分為兩類(lèi)：南北向流量，也就是俗稱(chēng)的外網(wǎng)流量；東西向流量，也就是俗稱(chēng)的內(nèi)網(wǎng)流量。集群計(jì)算的網(wǎng)絡(luò)連接數(shù) S = N x (N-1)（N為節(jié)點(diǎn)數(shù)）。這也是為什么現(xiàn)在數(shù)據(jù)中心中東西向流量占比超過(guò)90%的原因所在。再加上系統(tǒng)規(guī)模擴(kuò)大導(dǎo)致的南北向網(wǎng)絡(luò)流量的增加，這使得數(shù)據(jù)中心所需的網(wǎng)絡(luò)帶寬呈指數(shù)級(jí)增長(zhǎng)趨勢(shì)。

2019年，NVIDIA收購(gòu)Mellanox，憑借著在InfiniBand和ROCEv2領(lǐng)域的領(lǐng)先優(yōu)勢(shì)，NVIDIA成為了高性能網(wǎng)絡(luò)的霸主。各大競(jìng)爭(zhēng)對(duì)手不甘示弱，特別是AWS、阿里云等云計(jì)算廠(chǎng)家，都陸續(xù)推出了自己的高性能網(wǎng)絡(luò)協(xié)議和對(duì)應(yīng)的產(chǎn)品，行業(yè)呈現(xiàn)百家爭(zhēng)鳴之象。高性能網(wǎng)絡(luò)，兵家必爭(zhēng)之地；未來(lái)誰(shuí)主沉浮，我們拭目以待。

本篇文章，從軟硬件融合視角，對(duì)高性能網(wǎng)絡(luò)相關(guān)技術(shù)進(jìn)行介紹并進(jìn)行分析，讓大家一文看透高性能網(wǎng)絡(luò)。

1、高性能網(wǎng)絡(luò)綜述

1.1 網(wǎng)絡(luò)性能參數(shù)

網(wǎng)絡(luò)性能主要關(guān)心三個(gè)參數(shù)，帶寬、吞吐量和延遲：

• 帶寬：指特定時(shí)間段內(nèi)可以傳輸?shù)臄?shù)據(jù)量。高帶寬并不一定保證最佳的網(wǎng)絡(luò)性能。例如，網(wǎng)絡(luò)吞吐量受到數(shù)據(jù)包丟失、抖動(dòng)或延遲的影響，可能會(huì)遇到延遲問(wèn)題。吞吐量：指在特定時(shí)間段內(nèi)能夠發(fā)送和接收的數(shù)據(jù)量。網(wǎng)絡(luò)上數(shù)據(jù)的平均吞吐量使用戶(hù)能夠深入了解成功到達(dá)正確目的地的數(shù)據(jù)包數(shù)量。為了高性能，數(shù)據(jù)包必須能夠到達(dá)正確目的地。如果在傳輸過(guò)程中丟失了太多數(shù)據(jù)包，則網(wǎng)絡(luò)性能可能不足。

延遲：數(shù)據(jù)包在發(fā)送后到達(dá)目的地所用的時(shí)間。我們將網(wǎng)絡(luò)延遲測(cè)量為往返行程。延遲的結(jié)果通常是不穩(wěn)定和滯后的服務(wù)。例如視頻會(huì)議等，對(duì)延遲非常敏感。

除此之外，還有一個(gè)非常重要的指標(biāo)，PPS（Packet Per Second，每秒傳輸數(shù)據(jù)包數(shù)）。許多網(wǎng)絡(luò)設(shè)備，在大包的時(shí)候，可以做到線(xiàn)速，但在小包（64字節(jié)）的情況下，其性能降低的非常嚴(yán)重，主要就是PPS能力不足引起的。所以，理想的情況是，在最小包的情況下，仍然能夠達(dá)到線(xiàn)速。

高性能網(wǎng)絡(luò)，就是要在低延遲（越低越好）、低抖動(dòng)的情況下，（不管大包小包，任意網(wǎng)絡(luò)節(jié)點(diǎn)，都要）實(shí)現(xiàn)最高的吞吐量（無(wú)限接近于網(wǎng)絡(luò)帶寬）。當(dāng)然了，這些參數(shù)是相互影響的，實(shí)際的系統(tǒng)是在這些參數(shù)之間取得的平衡。

1.2 復(fù)雜的網(wǎng)絡(luò)分層

OSI定義了七層網(wǎng)絡(luò)協(xié)議，實(shí)際工程應(yīng)用的TCP/IP網(wǎng)絡(luò)協(xié)議一般為五層：

從下到上依次為：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。通常情況下，物理層、數(shù)據(jù)鏈層在硬件實(shí)現(xiàn)，而網(wǎng)絡(luò)層、傳輸層和應(yīng)用層在軟件實(shí)現(xiàn)。TCP/IP協(xié)議族是計(jì)算機(jī)網(wǎng)絡(luò)中使用的一組通信協(xié)議。包括的基礎(chǔ)協(xié)議有傳輸控制協(xié)議(TCP) 、互聯(lián)網(wǎng)協(xié)議(IP)，以及用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)。以太網(wǎng)（Ethernet）是為了實(shí)現(xiàn)局域網(wǎng)通信而設(shè)計(jì)的一種技術(shù)，它規(guī)定了包括物理層的連線(xiàn)、電子信號(hào)和介質(zhì)訪(fǎng)問(wèn)層協(xié)議的內(nèi)容。以太網(wǎng)是目前應(yīng)用最普遍的網(wǎng)絡(luò)技術(shù)。

數(shù)據(jù)中心網(wǎng)絡(luò)要更加復(fù)雜，會(huì)分為Overlay網(wǎng)絡(luò)和Underlay網(wǎng)絡(luò)。如果按照功能邏輯把網(wǎng)絡(luò)分層，云計(jì)算數(shù)據(jù)中心網(wǎng)絡(luò)可以分成三層：

第一層，物理的基礎(chǔ)網(wǎng)絡(luò)連接，也就是我們通常所理解的Underlay底層承載網(wǎng)；第二層，基于基礎(chǔ)的物理網(wǎng)絡(luò)構(gòu)建的虛擬網(wǎng)絡(luò)，也就是我們通常理解的基于隧道的Overlay網(wǎng)絡(luò)；第三層，各種用戶(hù)可見(jiàn)的應(yīng)用級(jí)的網(wǎng)絡(luò)服務(wù)，比如接入網(wǎng)關(guān)、負(fù)載均衡等。也可以是其他需要用到網(wǎng)絡(luò)的普通應(yīng)用。

物理的數(shù)據(jù)中心是一個(gè)局域網(wǎng)，通過(guò)Overlay網(wǎng)絡(luò)分割成數(shù)以萬(wàn)計(jì)的虛擬私有網(wǎng)；域間隔離后，再需要一定的網(wǎng)絡(luò)安全機(jī)制實(shí)現(xiàn)高性能的跨域訪(fǎng)問(wèn)。

依據(jù)網(wǎng)絡(luò)處理邏輯，網(wǎng)絡(luò)可以分為三部分：

第一階段，業(yè)務(wù)數(shù)據(jù)的封包/解包。Tx向的時(shí)候，把業(yè)務(wù)的數(shù)據(jù)按照既定的網(wǎng)絡(luò)格式進(jìn)行封包；Rx向，則是把收到的數(shù)據(jù)包進(jìn)行解包。第二階段，網(wǎng)絡(luò)包的處理。比如Overlay網(wǎng)絡(luò)，需要將數(shù)據(jù)包再次進(jìn)行封裝；比如防火墻，要對(duì)網(wǎng)絡(luò)包進(jìn)行鑒別，是否允許傳輸（輸入輸出雙向）；比如網(wǎng)絡(luò)包加解密。第三階段，網(wǎng)絡(luò)包的傳輸（Tx/Rx）。也即是高性能網(wǎng)絡(luò)關(guān)注的部分。

1.3 為什么需要高性能網(wǎng)絡(luò)

為什么需要高性能網(wǎng)絡(luò)？

原因一，網(wǎng)絡(luò)的極端重要性。

1. 網(wǎng)絡(luò)連接的重要性：網(wǎng)絡(luò)連接所有節(jié)點(diǎn)，各類(lèi)服務(wù)都通過(guò)網(wǎng)絡(luò)鏈接，用戶(hù)通過(guò)網(wǎng)絡(luò)遠(yuǎn)程操作。沒(méi)有網(wǎng)絡(luò)，一切都是空的。網(wǎng)絡(luò)的復(fù)雜性：業(yè)務(wù)系統(tǒng)，要么是單服務(wù)器級(jí)別的或者集群級(jí)別；網(wǎng)絡(luò)系統(tǒng)基本上都是數(shù)據(jù)中心級(jí)別，在整個(gè)數(shù)據(jù)中心的規(guī)模上，構(gòu)建各種復(fù)雜的網(wǎng)絡(luò)業(yè)務(wù)邏輯，整個(gè)系統(tǒng)復(fù)雜度非常高，影響面也大。網(wǎng)絡(luò)故障的嚴(yán)重性：計(jì)算服務(wù)器故障、存儲(chǔ)服務(wù)器故障都是局部的故障，而網(wǎng)絡(luò)故障則牽一發(fā)而動(dòng)全身。任何一個(gè)微小的網(wǎng)絡(luò)故障，都可能會(huì)引起整個(gè)數(shù)據(jù)中心不可用。網(wǎng)絡(luò)故障一旦發(fā)生，必然是重大故障。

• 原因二，超大規(guī)模集群計(jì)算，東西向流量激增。數(shù)據(jù)中心復(fù)雜計(jì)算場(chǎng)景，系統(tǒng)持續(xù)解構(gòu)，東西向流量激增，網(wǎng)絡(luò)帶寬要求迅速的從10G、25G升級(jí)到100G，甚至200G。原因三，短距離傳輸，系統(tǒng)堆棧延遲凸顯。相比城域網(wǎng)或者全球互聯(lián)網(wǎng)絡(luò)，數(shù)據(jù)中心網(wǎng)絡(luò)傳輸距離很短，服務(wù)器系統(tǒng)堆棧的延遲凸顯。原因四，CPU性能瓶頸，網(wǎng)絡(luò)處理延遲進(jìn)一步加大。網(wǎng)絡(luò)帶寬快速增加，而CPU的性能已經(jīng)瓶頸。網(wǎng)絡(luò)堆棧處理的CPU資源消耗快速增加，并且延遲還進(jìn)一步增大。

原因五，跨服務(wù)器調(diào)用延遲敏感。而軟件服務(wù)之間的調(diào)用，要求跨服務(wù)器的遠(yuǎn)程調(diào)用能夠低延遲，接近于本地調(diào)用的延遲。

1.4 網(wǎng)絡(luò)擁塞控制

網(wǎng)絡(luò)中如果存在太多的數(shù)據(jù)包，會(huì)導(dǎo)致包延遲，并且會(huì)因?yàn)槌瑫r(shí)而丟棄，從而降低傳輸性能，這稱(chēng)為擁塞。高性能網(wǎng)絡(luò)，就是要充分利用網(wǎng)絡(luò)容量，提供低延遲網(wǎng)絡(luò)傳輸?shù)耐瑫r(shí)，盡可能的避免網(wǎng)絡(luò)擁塞。

當(dāng)主機(jī)發(fā)送的數(shù)據(jù)包數(shù)量在網(wǎng)絡(luò)的承載范圍之內(nèi)時(shí)，送達(dá)與發(fā)送的數(shù)據(jù)包成正比例增長(zhǎng)。但隨著負(fù)載接近網(wǎng)絡(luò)承載極限，偶爾突發(fā)的網(wǎng)絡(luò)流量會(huì)導(dǎo)致?lián)砣罎ⅲ划?dāng)加載的數(shù)據(jù)包接近承載上限的時(shí)候，延遲會(huì)急劇上升，這就是網(wǎng)絡(luò)擁塞。

擁塞控制（Congestion Control，CC）和流量控制有什么區(qū)別？擁塞控制，確保網(wǎng)絡(luò)能夠承載所有到達(dá)的流量，是一個(gè)全局問(wèn)題；流量控制，則是確?？焖俚陌l(fā)送方不會(huì)持續(xù)地以超過(guò)接收方接收能力的速率傳輸，是端到端傳輸?shù)膯?wèn)題。

根據(jù)效果從慢到快，處理?yè)砣霓k法可以分為：

更高帶寬的網(wǎng)絡(luò)；根據(jù)流量模式定制流量感知路由；降低負(fù)載，如準(zhǔn)入控制；給源端傳遞反饋信息，要求源端抑制流量；一切努力失敗，網(wǎng)絡(luò)丟棄無(wú)法傳遞的數(shù)據(jù)包。

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

優(yōu)化的帶寬分配方法，既能充分利用所有的可用帶寬卻能避免擁塞；帶寬分配算法對(duì)所有傳輸是公平的，既保證大象流，也保證老鼠流；擁塞控制算法能夠快速收斂。

1.5 等價(jià)多路徑路由ECMP

CLOS架構(gòu)是一種用于構(gòu)建高性能、高可靠性數(shù)據(jù)中心網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)。受東西向流量激增等原因影響，數(shù)據(jù)中心為滿(mǎn)足大通量網(wǎng)絡(luò)流量的需求，網(wǎng)絡(luò)拓?fù)?/a>通常采用CLOS結(jié)構(gòu)。CLOS架構(gòu)會(huì)使得主機(jī)和主機(jī)之間就存在多條網(wǎng)絡(luò)路徑，而“多路徑”是實(shí)現(xiàn)高性能和高可靠網(wǎng)絡(luò)的基礎(chǔ)。

如何利用數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)?、路徑資源、帶寬資源等，更好的實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡，將數(shù)據(jù)流分布到不同路徑上進(jìn)行數(shù)據(jù)傳輸，避免擁塞，提高數(shù)據(jù)中心內(nèi)的資源利用率，就變得越來(lái)越重要。

ECMP（Equal-Cost Multi-Path routing，等價(jià)多路徑路由）是一個(gè)逐跳的基于流的負(fù)載均衡策略，當(dāng)路由器發(fā)現(xiàn)同一目的地址出現(xiàn)多個(gè)最優(yōu)路徑時(shí)，會(huì)更新路由表，為此目的地址添加多條規(guī)則，對(duì)應(yīng)于多個(gè)下一跳。可同時(shí)利用這些路徑轉(zhuǎn)發(fā)數(shù)據(jù)，增加帶寬。

ECMP常見(jiàn)的路徑選擇策略有多種方法：

• 哈希，例如根據(jù)源IP地址的哈希為流選擇路徑。輪詢(xún)，各個(gè)流在多條路徑之間輪詢(xún)傳輸。

基于路徑權(quán)重，根據(jù)路徑的權(quán)重分配流，權(quán)重大的路徑分配的流數(shù)量更多。

需要注意的是，在數(shù)據(jù)中心這種突發(fā)性流量多，大象流與老鼠流并存的環(huán)境中，需要慎重考慮選擇的負(fù)載均衡策略，ECMP雖然簡(jiǎn)單易部署，但也存在較多問(wèn)題需要注意。

2、TCP/IP高性能網(wǎng)絡(luò)

TCP/IP協(xié)議棧主要指Ethernet+TCP/IP+Socket的整個(gè)系統(tǒng)棧。

2.1 TCP/IP協(xié)議棧硬件卸載

第一類(lèi)，TCP的部分特征卸載

TSO，TCP Segmentation Offload，利用網(wǎng)卡硬件能力對(duì)TCP數(shù)據(jù)包分段。UFO，UDP Fragmentation Offload ，支持UDP發(fā)大包，硬件會(huì)進(jìn)行分片。LRO，Large Receive Offload，網(wǎng)卡硬件將接收到的多個(gè)TCP數(shù)據(jù)聚合成一個(gè)大的數(shù)據(jù)包。RSS，Receive Side Scaling，將網(wǎng)絡(luò)流分成不同的隊(duì)列，再分別將這些隊(duì)列分配到多個(gè)CPU核處理。CRC 卸載，由硬件完成CRC計(jì)算和封包。

第二類(lèi)，TCP/IP協(xié)議棧卸載（TCP/IP Offload Engine，TOE）

傳統(tǒng)軟件網(wǎng)絡(luò)棧的處理開(kāi)銷(xiāo)很大，把整個(gè)TCP/IP協(xié)議棧卸載到硬件，可以提升網(wǎng)絡(luò)處理的性能，顯著降低CPU代價(jià)。

Linux 標(biāo)準(zhǔn)內(nèi)核不支持 TOE網(wǎng)卡，原因主要是：

安全性。TOE硬件實(shí)現(xiàn)，與OS中的經(jīng)過(guò)良好測(cè)試的軟件TCP/IP棧相比，硬件的安全風(fēng)險(xiǎn)很大。硬件約束。因?yàn)榫W(wǎng)絡(luò)連接在TOE芯片上進(jìn)行緩沖和處理，與軟件可用的大量CPU和內(nèi)存相比，資源匱乏更容易發(fā)生。復(fù)雜性。TOE打破了kernel始終可以訪(fǎng)問(wèn)所有資源的假設(shè)，還需要對(duì)網(wǎng)絡(luò)堆棧進(jìn)行非常大的更改，即便如此，QoS和包過(guò)濾等功能也可能無(wú)法工作。定制性。每個(gè)Vendor都是定制的TOE，這意味著必須重寫(xiě)更多代碼來(lái)處理各種TOE實(shí)現(xiàn)，代價(jià)是方案的復(fù)雜性和可能的安全風(fēng)險(xiǎn)。此外，TOE固件閉源，軟件人員無(wú)法修改。過(guò)時(shí)。TOE NIC使用壽命有限：CPU性能會(huì)迅速趕上并超過(guò)TOE性能；軟件系統(tǒng)棧的迭代會(huì)顯著快于硬件協(xié)議棧。

因此，受上述原因影響，TOE并沒(méi)有大規(guī)模使用起來(lái)。

2.2 應(yīng)用層TCP/IP協(xié)議棧Onload

Onload是Solarflare（Solarflare已被Xilinx收購(gòu)，Xilinx又被AMD收購(gòu)）加速網(wǎng)絡(luò)中間件。主要特征包括：

基于IP的TCP/UDP實(shí)現(xiàn)，動(dòng)態(tài)鏈接到用戶(hù)模式應(yīng)用程序的地址空間，應(yīng)用程序可以直接從網(wǎng)絡(luò)收發(fā)數(shù)據(jù)，而無(wú)需OS參與。

Onload實(shí)現(xiàn)的內(nèi)核繞過(guò)（Kernel Bypass）可避免系統(tǒng)調(diào)用、上下文切換和中斷等破壞性事件，從而提高處理器執(zhí)行應(yīng)用程序代碼的效率。

Onload庫(kù)在運(yùn)行時(shí)使用標(biāo)準(zhǔn)Socket API與應(yīng)用程序動(dòng)態(tài)鏈接，這意味著不需要對(duì)應(yīng)用程序進(jìn)行任何修改。

Onload通過(guò)減少CPU開(kāi)銷(xiāo)、改善延遲和帶寬，以及提高應(yīng)用的可擴(kuò)展性，來(lái)顯著降低網(wǎng)絡(luò)成本。

Onload核心技術(shù)可以總結(jié)為：硬件虛擬化SR-IOV，內(nèi)核bypass，以及應(yīng)用SocketAPI。

2.3 傳輸協(xié)議優(yōu)化：從TCP到QUIC

QUIC（Quick UDP Internet Connections，快速UDP互聯(lián)網(wǎng)連接）是一種新的互聯(lián)網(wǎng)傳輸協(xié)議，對(duì)L4、L5（安全）、L7進(jìn)行部分或全部的優(yōu)化和替代。

QUIC是一個(gè)應(yīng)用自包含的協(xié)議，允許創(chuàng)新。這在現(xiàn)有協(xié)議中不可能實(shí)現(xiàn)，受遺留的客戶(hù)端和系統(tǒng)中間件的阻礙。

與TCP+TLS+HTTP2相比，QUIC的主要優(yōu)點(diǎn)包括:

連接建立的延遲。簡(jiǎn)單地說(shuō)，QUIC握手在發(fā)送有效載荷之前需要0次往返，而TCP+TLS則需要1-3次往返。改進(jìn)的擁塞控制。QUIC主要實(shí)現(xiàn)并優(yōu)化了TCP的慢啟動(dòng)、擁塞避免、快重傳、快恢復(fù)，可以根據(jù)情況選擇不同的擁塞控制算法；避免TCP重傳歧義問(wèn)題；允許精確的往返時(shí)間計(jì)算；等等。無(wú)前端阻塞的多路復(fù)用。TCP存在行首阻塞問(wèn)題，QUIC為多路復(fù)用操作設(shè)計(jì)，沒(méi)有損失的流可以繼續(xù)推進(jìn)。前向糾錯(cuò)。為了在不等待重傳的情況下恢復(fù)丟失的數(shù)據(jù)包，QUIC可以用一個(gè)FEC數(shù)據(jù)包補(bǔ)充一組數(shù)據(jù)包。連接遷移。TCP連接由四元組標(biāo)識(shí)，QUIC連接由64位連接ID標(biāo)識(shí)。如果客戶(hù)端更改了IP地址或端口，則TCP連接不再有效；而QUIC可以使用舊的連接ID，而不會(huì)中斷任何正在進(jìn)行的請(qǐng)求。

3、高性能網(wǎng)絡(luò)協(xié)議棧綜述，以IB為例

3.1 IB網(wǎng)絡(luò)協(xié)議簡(jiǎn)介

InfiniBand (IB)是一種用于高性能計(jì)算的網(wǎng)絡(luò)通信標(biāo)準(zhǔn)，具有極高的吞吐量和極低的延遲。

IB用于計(jì)算機(jī)之間和計(jì)算機(jī)內(nèi)部的數(shù)據(jù)互連，還可以用作服務(wù)器和存儲(chǔ)系統(tǒng)之間的直接或交換互連，以及存儲(chǔ)系統(tǒng)之間的互連。

IB的設(shè)計(jì)目標(biāo)：綜合考慮計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)技術(shù)，設(shè)計(jì)一個(gè)可擴(kuò)展的、高性能的通信和I/O體系結(jié)構(gòu)。

IB的主要優(yōu)點(diǎn)：

高性能，超算TOP500中一半左右采用IB；低延遲，IB端到端測(cè)量延遲為1μs；? ?高效率，IB原生支持RDMA等協(xié)議，幫助客戶(hù)提高工作負(fù)載處理效率。

IB也是五層網(wǎng)絡(luò)分層：物理層、鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。傳統(tǒng)網(wǎng)絡(luò)的L1&L2硬件實(shí)現(xiàn)，而L3/L4軟件實(shí)現(xiàn)；而IB則是L1-L4均在硬件實(shí)現(xiàn)。IB傳輸層API即HCA網(wǎng)卡和CPU之間的軟硬件接口。Socket API是傳統(tǒng)TCP/IP網(wǎng)絡(luò)的應(yīng)用網(wǎng)絡(luò)接口，而Verbs API是IB的應(yīng)用網(wǎng)絡(luò)接口。MPI是一種通過(guò)提供并行庫(kù)來(lái)實(shí)現(xiàn)并行化的方法庫(kù)，MPI可以基于OFA Verbs API，也可以基于TCP/IP Socket。

3.2 IB為什么能夠高性能？

傳統(tǒng)網(wǎng)絡(luò)協(xié)議棧的問(wèn)題：

長(zhǎng)路徑，應(yīng)用需要通過(guò)系統(tǒng)層連接到網(wǎng)卡；

多拷貝，很多拷貝是沒(méi)有必要的；

彈性能力不足，協(xié)議棧經(jīng)過(guò)內(nèi)核，這樣用戶(hù)就很難去優(yōu)化協(xié)議功能。

通過(guò)網(wǎng)絡(luò)協(xié)議棧性能優(yōu)化的四個(gè)方面，來(lái)總結(jié)IB全棧所采用的主要優(yōu)化技術(shù)：

優(yōu)化協(xié)議棧：簡(jiǎn)化、輕量、解耦的系統(tǒng)堆棧。

加速協(xié)議處理：協(xié)議硬件加速處理， L2-L4多個(gè)協(xié)議層卸載；

減少中間環(huán)節(jié)：如RDMA kernel Bypass，IB網(wǎng)絡(luò)原生支持RDMA；

優(yōu)化接口交互：如軟硬件交互機(jī)制，Send/Rcv Queue Pair、Work/Completion Queues。

3.3 InfiniBand vs Ethernet?

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

設(shè)計(jì)目標(biāo)。Eth考慮多個(gè)系統(tǒng)如何流暢的信息交換，優(yōu)先考慮兼容性與分布式；IB則是為了解決HPC場(chǎng)景數(shù)據(jù)傳輸瓶頸。帶寬。IB的網(wǎng)絡(luò)速率通?？煊贓th，主要原因是IB應(yīng)用于HPC場(chǎng)景的服務(wù)器互聯(lián)，而Eth更多的是面向終端設(shè)備互聯(lián)。延遲。Eth交換機(jī)處理的任務(wù)比較復(fù)雜，導(dǎo)致其延遲較大（>200ns）。而IB交換機(jī)處理非常簡(jiǎn)單，遠(yuǎn)快于Eth交換機(jī)（<100ns）。采用RDMA+IB的網(wǎng)絡(luò)收發(fā)延遲在600ns，而Eth+TCP/IP的收發(fā)延遲高達(dá)10us，相差10倍以上?？煽啃?。丟包重傳對(duì)性能的影響非常大。IB基于端到端的流控，保證報(bào)文全程不擁塞，時(shí)延抖動(dòng)控制到最小。Eth沒(méi)有基于調(diào)度的流控，極端情況會(huì)出現(xiàn)擁塞而導(dǎo)致丟包，使得數(shù)據(jù)轉(zhuǎn)發(fā)性能大幅波動(dòng)。組網(wǎng)方式。Eth網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)的增刪都要通知到每一個(gè)節(jié)點(diǎn)，當(dāng)節(jié)點(diǎn)數(shù)量增加到一定數(shù)量時(shí)，會(huì)產(chǎn)生廣播風(fēng)暴。IB二層網(wǎng)絡(luò)內(nèi)有子網(wǎng)管理器來(lái)配置LocalID，然后統(tǒng)一計(jì)算轉(zhuǎn)發(fā)路徑信息，可以輕松部署一個(gè)規(guī)模幾萬(wàn)臺(tái)服務(wù)器的超大二層網(wǎng)絡(luò)。

4、RDMA高性能網(wǎng)絡(luò)

4.1 RDMA綜述

RDMA，是一種高帶寬、低延遲、低CPU消耗的網(wǎng)絡(luò)互聯(lián)技術(shù)，克服了傳統(tǒng)TCP/IP網(wǎng)絡(luò)的許多問(wèn)題。RDMA技術(shù)特點(diǎn)：

• 遠(yuǎn)程，數(shù)據(jù)在兩個(gè)節(jié)點(diǎn)之間傳輸；直接，不需要內(nèi)核參與，傳輸?shù)奶幚矶夹遁d到NIC硬件完成；內(nèi)存，數(shù)據(jù)在兩個(gè)節(jié)點(diǎn)的應(yīng)用虛擬內(nèi)存間傳輸，不需要額外的復(fù)制；

訪(fǎng)問(wèn)，訪(fǎng)問(wèn)操作有send/receive、read/write等。

RDMA的其他一些特征：

RDMA和IB是原生一體；RoCEv1是基于標(biāo)準(zhǔn)Eth的RDMA；RoCEv2基于標(biāo)準(zhǔn)Eth、IP和UDP，支持標(biāo)準(zhǔn)L3路由器。

4.2 RDMA/RoCEv2系統(tǒng)棧分層

RoCEv2是當(dāng)前數(shù)據(jù)中心比較流行的RDMA技術(shù)，我們以RoCEv2為例，介紹RoCE的系統(tǒng)分層：

以太網(wǎng)層：標(biāo)準(zhǔn)以太網(wǎng)層，即網(wǎng)絡(luò)五層協(xié)議物理層和數(shù)據(jù)鏈路層。網(wǎng)絡(luò)層IP：網(wǎng)絡(luò)五層協(xié)議中的網(wǎng)絡(luò)層。傳輸層UDP：網(wǎng)絡(luò)五層協(xié)議中的傳輸層（UDP而不是TCP）。IB傳輸層：負(fù)責(zé)數(shù)據(jù)包的分發(fā)、分割、通道復(fù)用和傳輸服務(wù)。RDMA數(shù)據(jù)引擎層（Data Engine Layer）：負(fù)責(zé)內(nèi)存隊(duì)列和RDMA硬件之間工作/完成請(qǐng)求的數(shù)據(jù)傳輸?shù)?。RDMA接口驅(qū)動(dòng)層：負(fù)責(zé)RDMA硬件的配置管理、隊(duì)列和內(nèi)存管理，負(fù)責(zé)工作請(qǐng)求添加到工作隊(duì)列中，負(fù)責(zé)完成請(qǐng)求的處理等。接口驅(qū)動(dòng)層和數(shù)據(jù)引擎層共同組成RDMA軟硬件接口。Verbs API層：接口驅(qū)動(dòng)Verbs封裝，管理連接狀態(tài)、管理內(nèi)存和隊(duì)列訪(fǎng)問(wèn)、提交工作給RDMA硬件、從RDMA硬件獲取工作和事件。ULP層：OFED ULP（上層協(xié)議）庫(kù)，提供了各種軟件協(xié)議的RDMA verbs支持，讓上層應(yīng)用可以無(wú)縫移植到RDMA平臺(tái)。? ?應(yīng)用層：RDMA原生的應(yīng)用，基于RDMA verbs API開(kāi)發(fā)；OFA還提供OFED協(xié)議棧，讓已有應(yīng)用可以無(wú)縫使用RDMA功能。

4.3 RDMA工作隊(duì)列

RDMA并沒(méi)有約束嚴(yán)格的軟硬件接口，各家的實(shí)現(xiàn)可以有所不同，只需要支持RDMA的隊(duì)列機(jī)制即可。

軟件驅(qū)動(dòng)和硬件設(shè)備的交互通?；谏a(chǎn)者消費(fèi)者模型，這樣能夠?qū)崿F(xiàn)軟件和硬件交互的異步解耦。RDMA軟硬件共享的隊(duì)列數(shù)據(jù)結(jié)構(gòu)稱(chēng)為工作隊(duì)列（Work Queue）。

驅(qū)動(dòng)負(fù)責(zé)把工作請(qǐng)求（Work Request）添加到工作隊(duì)列，成為工作隊(duì)列中的一項(xiàng)，稱(chēng)為工作隊(duì)列項(xiàng)WQE。RDMA硬件設(shè)備會(huì)負(fù)責(zé)WQE在內(nèi)存和硬件之間的傳輸，并且通過(guò)RDMA網(wǎng)絡(luò)最終把WQE送到接收方的工作隊(duì)列中去。

接收方RDMA硬件會(huì)反饋確認(rèn)信息給到發(fā)送方RDMA硬件，發(fā)送方RDMA硬件會(huì)根據(jù)確認(rèn)信息生成完成隊(duì)列項(xiàng)CQE發(fā)送到內(nèi)存的完成隊(duì)列。

RDMA Queue類(lèi)型有：發(fā)送隊(duì)列、接收隊(duì)列、完成隊(duì)列以及隊(duì)列對(duì)。發(fā)送隊(duì)列和接收隊(duì)列組成一組隊(duì)列對(duì)。SRQ，共享接收隊(duì)列。把一個(gè)RQ共享給所有關(guān)聯(lián)的QP使用，這個(gè)公用的RQ就稱(chēng)為SRQ。

4.4 RDMA Verbs API

RDMA Verbs是提供給應(yīng)用使用的RDMA功能和動(dòng)作抽象。Verbs API則是Verbs具體實(shí)現(xiàn)，提供標(biāo)準(zhǔn)接口供應(yīng)用調(diào)用。

RoCEv2中的Verbs操作主要有兩類(lèi)：

Send/Recv。類(lèi)似于Client/Server結(jié)構(gòu)，發(fā)送操作和接收操作協(xié)作完成，在發(fā)送方連接之前，接收方必須處于偵聽(tīng)狀態(tài)；發(fā)送方不知道接收方的虛擬內(nèi)存位置，接收方也不知道發(fā)送方的虛擬內(nèi)存地址。RDMA Send/Recv因?yàn)槭侵苯訉?duì)內(nèi)存操作，需要提前注冊(cè)用于傳輸?shù)膬?nèi)存區(qū)域。Write/Read。與Client/Server架構(gòu)不同，Write/Read是請(qǐng)求方處于主動(dòng)，響應(yīng)方處于被動(dòng)。請(qǐng)求方執(zhí)行Write/Read操作，響應(yīng)方不需要做任何操作。為了能夠操作響應(yīng)方的內(nèi)存，請(qǐng)求方需要提前獲得響應(yīng)方的地址和鍵值。

5、AWS SRD高性能網(wǎng)絡(luò)

5.1 AWS SRD和EFA綜述

SRD（Scalable Reliable Datagram，可擴(kuò)展可靠數(shù)據(jù)報(bào)），是AWS設(shè)計(jì)的可靠的、高性能的、低延遲的網(wǎng)絡(luò)傳輸協(xié)議；EFA（Elastic Fabric Adapter，彈性互聯(lián)適配器），是AWS EC2實(shí)例提供的一種高性能網(wǎng)絡(luò)接口。AWS的SRD和EFA技術(shù)主要有如下特征：

SRD基于標(biāo)準(zhǔn)的以太網(wǎng)，用于優(yōu)化傳輸層協(xié)議。SRD受IB可靠數(shù)據(jù)報(bào)的啟發(fā)，與此同時(shí)，考慮到大規(guī)模的云計(jì)算場(chǎng)景下的工作負(fù)載，利用了云計(jì)算的資源和特點(diǎn)（例如AWS的復(fù)雜多路徑主干網(wǎng)絡(luò)）來(lái)支持新的傳輸策略，為其在緊耦合的工作負(fù)載中發(fā)揮價(jià)值。借助EFA，使用消息傳遞接口MPI的HPC應(yīng)用，以及使用NVIDIA集體通信庫(kù)（NCCL）的ML應(yīng)用，可以輕松擴(kuò)展到數(shù)千個(gè)CPU或GPU。EFA用戶(hù)空間軟件有兩個(gè)：基本驅(qū)動(dòng)，暴露EFA硬件的可靠亂序交付能力；而在其之上的libfabric實(shí)現(xiàn)了包的重排序。? ?EFA類(lèi)似于IB Verbs。所有EFA數(shù)據(jù)通信都通過(guò)發(fā)送/接收隊(duì)列對(duì)完成。依靠共享隊(duì)列機(jī)制，可顯著降低所需的QPs數(shù)量。由消息傳遞層完成的緩沖區(qū)管理和流控制，與應(yīng)用程序是緊密耦合的。

5.2 AWS為什么不選擇TCP或RoCE

AWS認(rèn)為：

TCP是可靠數(shù)據(jù)傳輸?shù)闹饕侄?，但不適合對(duì)延遲敏感的處理。TCP的最優(yōu)往返延遲大約25us，因擁塞等引起的等待時(shí)間可以到50ms，甚至數(shù)秒。主要原因是丟包重傳。IB是用于HPC的高吞吐量、低延遲網(wǎng)絡(luò)，但I(xiàn)B不適合可擴(kuò)展性要求。原因之一是RoCEv2的優(yōu)先級(jí)流量控制(PFC)，在大型網(wǎng)絡(luò)上不可行。會(huì)造成隊(duì)頭阻塞、擁塞擴(kuò)散和偶爾的死鎖。即使PFC可用，RoCE在擁塞和次優(yōu)擁塞控制下仍會(huì)遭受ECMP（Equal-Cost Multi-Path routing，等價(jià)多路徑路由）沖突。SRD針對(duì)超大規(guī)模數(shù)據(jù)中心進(jìn)行了優(yōu)化：跨多個(gè)路徑的負(fù)載平衡、快速恢復(fù)、發(fā)送方控制ECMP、專(zhuān)門(mén)的擁塞控制算法、可靠但亂序的交付等。SRD是在AWS Nitro卡中實(shí)現(xiàn)。讓SRD盡可能靠近物理網(wǎng)絡(luò)層，避免OS和Hypervisor性能噪音注入?？煽焖僦貍鞑⒀杆贉p速以響應(yīng)隊(duì)列建立。SRD作為EFA設(shè)備公開(kāi)給主機(jī)，EFA是Amazon EC2實(shí)例的網(wǎng)絡(luò)接口。

5.3 SRD特征之一：多路負(fù)載均衡

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

為了減少丟包的幾率，流量應(yīng)該在可用路徑上均勻分布。SRD發(fā)送方需要在多個(gè)路徑上Spray（噴灑）數(shù)據(jù)包（即使是單個(gè)應(yīng)用程序流），特別是大象流。以最小化熱點(diǎn)出現(xiàn)的可能性，并檢測(cè)次優(yōu)路徑。為了與未啟用多路徑的傳統(tǒng)流量共享網(wǎng)絡(luò)，因此隨機(jī)Spray流量是不合適的，SRD避免使用過(guò)載路徑。因?yàn)橐?guī)模的原因，偶爾的硬件故障不可避免。為了讓網(wǎng)絡(luò)從鏈路故障中快速恢復(fù)，如果原始傳輸路徑不可用，SRD能夠重新路由重傳的數(shù)據(jù)包，而無(wú)需等待路由更新收斂。

5.4 SRD特征之二：亂序交付

在網(wǎng)絡(luò)傳輸中，平衡多條可用路徑上的流量有助于減少排隊(duì)延遲并防止數(shù)據(jù)包丟失；但不可避免地會(huì)導(dǎo)致數(shù)據(jù)包的無(wú)序到達(dá)。

與此同時(shí)，眾所周知，恢復(fù)網(wǎng)卡中的數(shù)據(jù)包排序代價(jià)昂貴，網(wǎng)卡通常具有有限的資源（內(nèi)存帶寬、重排序緩沖容量或開(kāi)放排序上下文的數(shù)量）。

如果按順序發(fā)送接收消息，將限制可伸縮性或在出現(xiàn)丟包時(shí)增加平均延遲。如果推遲向主機(jī)軟件發(fā)送亂序數(shù)據(jù)包，將需要一個(gè)非常大的緩沖區(qū)，并且將大大增加平均延遲。并且許多數(shù)據(jù)包會(huì)因?yàn)檠舆t可能被丟棄，重傳增加了無(wú)謂的網(wǎng)絡(luò)帶寬消耗。

SRD設(shè)計(jì)為：將可能亂序的數(shù)據(jù)包，不做處理，直接傳送到主機(jī)。

應(yīng)用程序處理亂序數(shù)據(jù)包，在字節(jié)流協(xié)議，如TCP，是不可行的，但在基于消息的語(yǔ)義時(shí)很容易。每個(gè)流的排序或其他類(lèi)型的依賴(lài)追蹤由SRD之上的消息傳遞層完成；消息層排序信息與數(shù)據(jù)包一起傳輸?shù)搅硪欢耍琒RD是不可見(jiàn)的。

5.5 SRD特征之三：擁塞控制

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

多路徑Spray減少了中間交換機(jī)的負(fù)載，但其本身并不能緩解Incast擁塞問(wèn)題。Spray可能會(huì)使Incast問(wèn)題變得更糟：即使發(fā)送方受自身鏈路帶寬限制，來(lái)自發(fā)送方不同時(shí)刻的流量，也可能通過(guò)不同的路徑同時(shí)到達(dá)。對(duì)于多路徑傳輸來(lái)說(shuō)，擁塞控制將所有路徑上的聚合隊(duì)列保持在最小值至關(guān)重要。

因此，SRD CC的目標(biāo)是：用最少的飛行中的數(shù)據(jù)量，獲得最公平的帶寬共享，防止隊(duì)列堆積和數(shù)據(jù)包丟失。發(fā)送方需要根據(jù)速率估計(jì)調(diào)整其每個(gè)連接的傳輸速率，速率估計(jì)依據(jù)確認(rèn)包的時(shí)間提示，同時(shí)需要考慮最近的傳輸速率和RTT的變化。

6、其他高性能網(wǎng)絡(luò)技術(shù)

6.1 微軟Fungible的Truefabric

TrueFabric是開(kāi)放標(biāo)準(zhǔn)的網(wǎng)絡(luò)技術(shù)，提高數(shù)據(jù)中心的性能、經(jīng)濟(jì)性、可靠性和安全性，單集群規(guī)模從幾個(gè)到數(shù)千機(jī)架。

橫向擴(kuò)展數(shù)據(jù)中心，所有服務(wù)器節(jié)點(diǎn)都通過(guò)可靠的高性能局域網(wǎng)連接。目前，大多數(shù)數(shù)據(jù)中心仍構(gòu)建在Eth+TCP/IP之上。局域網(wǎng)比廣域網(wǎng)速度快三個(gè)數(shù)量級(jí)或更多，TCP/IP成為性能的瓶頸。TCP卸載并不成功，很難在CPU和卸載引擎之間清晰拆分TCP。網(wǎng)絡(luò)接口和SSD設(shè)備的性能比通用CPU提高得更快；系統(tǒng)持續(xù)解構(gòu)，東西向流量激增。I/O技術(shù)和業(yè)務(wù)應(yīng)用的發(fā)展，給網(wǎng)絡(luò)棧帶來(lái)了巨大的壓力。? ?TrueFabric的所有特性，都是通過(guò)基于標(biāo)準(zhǔn)UDP/ IP以太網(wǎng)的新型Fabric控制協(xié)議(FCP)實(shí)現(xiàn)。TrueFabric支持：中小規(guī)模，服務(wù)器節(jié)點(diǎn)直連Spine交換機(jī)；大規(guī)模，兩層拓?fù)洌琒pine和Leaf交換機(jī)；FCP還可以支持三層或更多層交換機(jī)的更大規(guī)模網(wǎng)絡(luò)。右圖為T(mén)rueFabric網(wǎng)絡(luò)部署的抽象視圖，有四種服務(wù)器類(lèi)型：CPU服務(wù)器、AI/數(shù)據(jù)分析服務(wù)器、SSD服務(wù)器和HDD服務(wù)器。每個(gè)服務(wù)器實(shí)例包含一個(gè)Fungible DPU。

TrueFabric/FCP的特性

可擴(kuò)展性：可以從使用100GE接口的小規(guī)模部署，擴(kuò)展到使用200/400GE接口的數(shù)十萬(wàn)臺(tái)服務(wù)器的大規(guī)模署。全截面帶寬：支持端到端的全截面帶寬，適用于標(biāo)準(zhǔn)IP的以太網(wǎng)數(shù)據(jù)包大小。TrueFabric支持短的、低延遲消息的高效交換。低延遲和低抖動(dòng)：提供節(jié)點(diǎn)之間的最小延遲，以及非常嚴(yán)格的長(zhǎng)尾延遲控制。公平性：在競(jìng)爭(zhēng)節(jié)點(diǎn)之間以微秒粒度公平分配網(wǎng)絡(luò)帶寬。擁塞避免：內(nèi)置的主動(dòng)擁塞避免，這意味著數(shù)據(jù)包基本上不會(huì)因?yàn)閾砣鴣G失。并且，擁塞避免技術(shù)并不依賴(lài)于核心網(wǎng)絡(luò)交換機(jī)的特性。容錯(cuò)：內(nèi)置的數(shù)據(jù)包丟失檢測(cè)和恢復(fù)，錯(cuò)誤恢復(fù)比依賴(lài)于路由協(xié)議的傳統(tǒng)恢復(fù)技術(shù)快五個(gè)數(shù)量級(jí)。軟件定義的安全和策略：支持基于AES的端到端加密?？梢酝ㄟ^(guò)配置將特定的部署劃分為單獨(dú)加密域。開(kāi)放標(biāo)準(zhǔn)：FCP建立在基于以太網(wǎng)的標(biāo)準(zhǔn)IP之上，可以與以太網(wǎng)上的標(biāo)準(zhǔn)TCP/IP完全互操作。

6.2 阿里云HPCC和eRDMA

阿里云的HPCC（High Precision Congestion Control，高精度擁塞控制），其關(guān)鍵方法是利用INT（In-Network Telemetry，網(wǎng)絡(luò)內(nèi)遙測(cè)）提供的精確的鏈路負(fù)載信息來(lái)計(jì)算準(zhǔn)確的流量更新。

大規(guī)模RDMA網(wǎng)絡(luò)在平衡低延遲、高帶寬利用率和高穩(wěn)定性方面面臨挑戰(zhàn)。經(jīng)典的RDMA擁塞機(jī)制，例如DCQCN和TIMELY算法，具有一些局限性：收斂緩慢、不可避免的數(shù)據(jù)包排隊(duì)、復(fù)雜的調(diào)參參數(shù)。? ?HPCC發(fā)送方可以快速提高流量以實(shí)現(xiàn)高利用率，或者快速降低流量以避免擁塞；HPCC發(fā)送者可以快速調(diào)整流量，以使每個(gè)鏈接的輸入速率略低于鏈接的容量，保持高鏈接利用率；由于發(fā)送速率是根據(jù)交換機(jī)直接測(cè)量的結(jié)果精確計(jì)算得出的，HPCC僅需要3個(gè)獨(dú)立參數(shù)即可調(diào)整公平性和效率。與DCQCN、TIMELY等方案相比，HPCC對(duì)可用帶寬和擁塞的反應(yīng)更快，并保持接近零的隊(duì)列。

彈性RDMA（Elastic Remote Direct Memory Access，簡(jiǎn)稱(chēng)eRDMA）是阿里云自研的云上彈性RDMA網(wǎng)絡(luò)，底層鏈路復(fù)用VPC網(wǎng)絡(luò)，采用全棧自研的擁塞控制CC（Congestion Control，HPCC）算法，享有傳統(tǒng)RDMA網(wǎng)絡(luò)高吞吐、低延遲特性的同時(shí)，可支持秒級(jí)的大規(guī)模RDMA組網(wǎng)?？杉嫒輦鹘y(tǒng)HPC應(yīng)用，以及傳統(tǒng)TCP/IP應(yīng)用。

eRDMA能力主要具有以下產(chǎn)品優(yōu)勢(shì)：

高性能。RDMA繞過(guò)內(nèi)核協(xié)議棧，將數(shù)據(jù)直接從用戶(hù)態(tài)程序轉(zhuǎn)移到HCA中進(jìn)行網(wǎng)絡(luò)傳輸，極大地降低了CPU負(fù)載和延遲。eRDMA具有傳統(tǒng)RDMA網(wǎng)卡的優(yōu)點(diǎn)，同時(shí)將傳統(tǒng)的RDMA技術(shù)應(yīng)用到VPC網(wǎng)絡(luò)下。規(guī)模部署。傳統(tǒng)的RDMA依賴(lài)于網(wǎng)絡(luò)的無(wú)損特性，規(guī)模部署成本高、規(guī)模部署困難。而eRDMA在實(shí)現(xiàn)中采用了自研的擁塞控制CC算法，容忍VPC網(wǎng)絡(luò)中的傳輸質(zhì)量變化（延遲、丟包等），在有損的網(wǎng)絡(luò)環(huán)境中依然擁有良好的性能表現(xiàn)。彈性擴(kuò)展。不同于傳統(tǒng)的RDMA網(wǎng)卡需要單獨(dú)一個(gè)硬件網(wǎng)卡，eRDMA可以在使用ECS的過(guò)程中動(dòng)態(tài)添加設(shè)備，支持熱遷移，部署靈活。共享VPC網(wǎng)絡(luò)。eRDMA依附于彈性網(wǎng)卡（ENI），網(wǎng)絡(luò)完全復(fù)用，可以在不改變業(yè)務(wù)組網(wǎng)的情況下，即可在原來(lái)的網(wǎng)絡(luò)下激活RDMA功能，體驗(yàn)到RDMA。

6.3 新興的Ultra-Ethernet

2023年7 月，超以太網(wǎng)聯(lián)盟 (Ultra Ethernet Consortium，UEC) 正式成立，它是一個(gè)由 Linux 基金會(huì)及其聯(lián)合開(kāi)發(fā)基金會(huì)倡議主辦的新組織。UEC 的目標(biāo)是超越現(xiàn)有的以太網(wǎng)功能，例如遠(yuǎn)程直接內(nèi)存訪(fǎng)問(wèn) ( RDMA ) 和融合以太網(wǎng)RDMA (RoCE)，提供針對(duì)高性能計(jì)算和人工智能進(jìn)行優(yōu)化的高性能、分布式和無(wú)損傳輸層，直接將矛頭對(duì)準(zhǔn)競(jìng)爭(zhēng)對(duì)手的傳輸協(xié)議 InfiniBand。

人工智能和高性能計(jì)算給網(wǎng)絡(luò)帶來(lái)了新的挑戰(zhàn)，比如需要更大規(guī)模、更高帶寬密度、多路徑、對(duì)擁塞的快速反應(yīng)以及對(duì)單個(gè)數(shù)據(jù)流執(zhí)行度的相互依賴(lài)（其中尾延遲是關(guān)鍵考量點(diǎn)）。UEC 規(guī)范的設(shè)計(jì)將彌補(bǔ)這些差距，并為這些工作任務(wù)提供所需的更大規(guī)模組網(wǎng)。UEC 的目標(biāo)是一個(gè)完整的通信棧，解決跨越多個(gè)協(xié)議層的技術(shù)問(wèn)題，并提供易于配置和管理的功能。

UEC將提供基于以太網(wǎng)的開(kāi)放、可互操作、高性能的全通信堆棧架構(gòu)，以滿(mǎn)足大規(guī)模人工智能和高性能計(jì)算不斷增長(zhǎng)的網(wǎng)絡(luò)需求。從物理層到軟件層，UEC計(jì)劃對(duì)以太網(wǎng)堆棧的多個(gè)層進(jìn)行更改。

UEC的技術(shù)目標(biāo)是開(kāi)發(fā)規(guī)范、API 和源代碼，UEC定義：

以太網(wǎng)通信的協(xié)議、電信號(hào)和光信號(hào)特征、應(yīng)用程序接口/數(shù)據(jù)結(jié)構(gòu)。鏈路級(jí)和端到端網(wǎng)絡(luò)傳輸協(xié)議，可擴(kuò)展或替換現(xiàn)有鏈路和傳輸協(xié)議。鏈路級(jí)和端到端擁塞、遙測(cè)和信令機(jī)制，均適用于人工智能、機(jī)器學(xué)習(xí)和高性能計(jì)算環(huán)境。支持各種工作負(fù)載和操作環(huán)境的軟件、存儲(chǔ)、管理和安全結(jié)構(gòu)。

UEC傳輸協(xié)議:

從一開(kāi)始就設(shè)計(jì)為在IP和以太網(wǎng)上運(yùn)行的開(kāi)放協(xié)議規(guī)范。? ?多路徑、包噴灑傳輸，充分利用AI網(wǎng)絡(luò)，不會(huì)造成擁塞或隊(duì)頭阻塞，無(wú)需集中式負(fù)載均衡算法和路由控制器。Incast管理機(jī)制，以最小的丟包控制到目標(biāo)主機(jī)的最終鏈接上的扇入。高效的速率控制算法，允許傳輸快速提升至線(xiàn)速，同時(shí)不會(huì)導(dǎo)致競(jìng)爭(zhēng)流的性能損失。用于無(wú)序數(shù)據(jù)包傳送的 API，可選擇按順序完成消息，最大限度地提高網(wǎng)絡(luò)和應(yīng)用程序的并發(fā)性，并最大限度地減少消息延遲。可擴(kuò)展未來(lái)網(wǎng)絡(luò)，支持1,000,000個(gè)端點(diǎn)。性能和最佳網(wǎng)絡(luò)利用率，無(wú)需針對(duì)網(wǎng)絡(luò)和工作負(fù)載進(jìn)行特定的擁塞算法參數(shù)調(diào)優(yōu)。旨在在商用硬件上實(shí)現(xiàn) 800G、1.6T 和未來(lái)更快以太網(wǎng)的線(xiàn)速性能。

7、全球互聯(lián)網(wǎng)絡(luò)的高性能

隨著5G通信基礎(chǔ)設(shè)施的大規(guī)模覆蓋，短視頻、視頻會(huì)議等多媒體應(yīng)用的大量使用，自動(dòng)駕駛和智能網(wǎng)聯(lián)汽車(chē)的廣泛落地，以及VR/AR元宇宙的快速發(fā)展，對(duì)整個(gè)全球互聯(lián)網(wǎng)絡(luò)的吞吐量、實(shí)時(shí)性、穩(wěn)定性等各個(gè)方面提出了更高的要求。

上圖為聲網(wǎng)通過(guò)基于SDN架構(gòu)的SD-RTN（軟件定義全球?qū)崟r(shí)網(wǎng)絡(luò)）技術(shù)，構(gòu)建全球?qū)崟r(shí)通信網(wǎng)絡(luò)，利用廉價(jià)的邊緣節(jié)點(diǎn)和獨(dú)特的智能路由加速技術(shù)，讓全球端到端延遲控制在400ms以?xún)?nèi)。

8、高性能網(wǎng)絡(luò)總結(jié)

8.1 高性能網(wǎng)絡(luò)優(yōu)化總結(jié)

高性能網(wǎng)絡(luò)優(yōu)化的主要手段：

• 網(wǎng)絡(luò)容量升級(jí)：例如網(wǎng)絡(luò)帶寬升級(jí)，把整個(gè)網(wǎng)絡(luò)從25Gbps升級(jí)到100Gbps；例如更多的網(wǎng)絡(luò)端口和連線(xiàn)。輕量協(xié)議棧：數(shù)據(jù)中心網(wǎng)絡(luò)跟互聯(lián)網(wǎng)不在一個(gè)層級(jí)，物理距離短，堆棧延遲敏感，可以不需要復(fù)雜的用于全球物理互聯(lián)的TCP/IP協(xié)議棧；網(wǎng)絡(luò)協(xié)議硬件加速處理；高性能軟硬件交互：高效交互協(xié)議 + PMD + PF/VF/MQ等，如AWS EFA；

高性能網(wǎng)絡(luò)優(yōu)化：通過(guò)①多路負(fù)載均衡、②亂序交付、③擁塞控制、④多路處理并行等技術(shù)（例如AWS SRD技術(shù)），實(shí)現(xiàn)①低延遲、②高可靠性（低性能抖動(dòng)）、③高網(wǎng)絡(luò)利用率。

8.2 從高性能網(wǎng)絡(luò)協(xié)議?？聪到y(tǒng)分層

從高性能網(wǎng)絡(luò)協(xié)議?？聪到y(tǒng)分層：

系統(tǒng)是由多個(gè)分層（layer）組成。

每個(gè)分層可以當(dāng)作獨(dú)立的組件模塊，根據(jù)需要，選擇不同分層，并對(duì)業(yè)務(wù)敏感的特定層進(jìn)行定制設(shè)計(jì)和優(yōu)化，組合出符合業(yè)務(wù)需求的個(gè)性化的系統(tǒng)解決方案。

即使分層間有很好的解耦，但每個(gè)分層仍不是孤立的；每個(gè)分層不宜是一個(gè)黑盒，這樣無(wú)法從系統(tǒng)層次對(duì)其進(jìn)行優(yōu)化；要想實(shí)現(xiàn)極致的性能，需要系統(tǒng)棧不同分層間的通力協(xié)作。

全棧優(yōu)化。系統(tǒng)需要不斷優(yōu)化，每個(gè)分層需要不斷優(yōu)化，上下分層間的交互接口也需要不斷優(yōu)化，分層的運(yùn)行平臺(tái)也需要不斷優(yōu)化。

每個(gè)分層、交互接口以及整個(gè)系統(tǒng)，都需要持續(xù)不斷的變化，來(lái)適應(yīng)業(yè)務(wù)需求的變化。