What？

SRD（Scalable Reliable Datagram，可擴展的可靠數據報文），是AWS年推出的協議，旨在解決亞馬遜的云性能挑戰。它是專為AWS數據中心網絡設計的、基于Nitro芯片、為提高HPC性能實現的一種高吞吐、低延遲的網絡傳輸協議。

SRD 不保留數據包順序，而是通過盡可能多的網絡路徑發送數據包，同時避免路徑過載。為了最大限度地減少抖動并確保對網絡擁塞波動的最快響應，在 AWS 自研的 Nitro chip 中實施 SRD。

SRD 由 EC2 主機上的 HPC/ML 框架通過 AWS EFA（Elastic Fabric Adapter，彈性結構適配器）內核旁路接口使用。

SRD的特點：

• 不保留數據包順序，交給上層消息傳遞層處理
• 通過盡可能多的網絡路徑發包，利用ECMP標準，發端控制數據包封裝來控制ECMP路徑選擇，實現多路徑的負載平衡
• 自有擁塞控制算法，基于每個連接動態速率限制，結合RTT（Round Trip Time）飛行時間來檢測擁塞，可快速從丟包或鏈路故障中恢復
• 由于無序發包以及不支持分段，SRD傳輸時所需要的QP（隊列對）顯著減少

Why?

為什么不是TCP？

TCP 是 IP 網絡中可靠數據傳輸的主要手段，自誕生以來一直很好地服務于 Internet，并且仍然是大多數通信的最佳協議。但是，它不適合對延遲敏感的處理，TCP 在數據中心最好的往返延遲差不多是 25us，因擁塞（或鏈路故障）等待導致的異常值可以是 50 ms，甚至數秒，帶來這些延遲的主要原因是TCP丟包之后的重傳機制。另外，TCP傳輸是一對一的連接，就算解決了時延的問題，也難在故障時重新快速連線。

TCP 是通用協議，沒有針對HPC場景進行優化，早在2020 年，AWS 已經提出需要移除TCP。

為什么不是RoCE？

InfiniBand 是一種用于高性能計算的流行的高吞吐量低延遲互連，它支持內核旁路和傳輸卸載。RoCE（RDMA over Converged Ethernet），也稱為 InfiniBand over Ethernet，允許在以太網上運行 InfiniBand 傳輸，理論上可以提供 AWS 數據中心中 TCP 的替代方案。

EFA 主機接口與 InfiniBand/RoCE 接口非常相似。但是 InfiniBand 傳輸不適合 AWS 可擴展性要求。原因之一是 RoCE 需要 PFC（優先級流量控制），這在大型網絡上是不可行的，因為它會造成隊頭阻塞、擁塞擴散和偶爾的死鎖。PFC 更適合比 AWS 規模小的數據中心。此外，即使使用 PFC，RoCE 在擁塞（類似于 TCP）和次優擁塞控制下仍會遭受 ECMP（等價多路徑路由）沖突。

為什么是SRD？

SRD是專為AWS設計的可靠的、高性能的、低延遲的網絡傳輸。這是數據中心網絡數據傳輸的一次重大改進。SRD受InfiniBand可靠數據報的啟發，結合大規模的云計算場景下的工作負載，SRD也經過了很多的更改和改進。SRD利用了云計算的資源和特點（例如AWS的復雜多路徑主干網絡）來支持新的傳輸策略，為其在緊耦合的工作負載中發揮價值。

任何真實的網絡中都會出現丟包、擁塞阻塞等一系列問題。這不是說每天會發生一次的事情，而是一直在發生。

大多數協議（如 TCP）是按順序發送數據包，這意味著單個數據包丟失會擾亂隊列中所有數據包的準時到達（這種效應稱為“隊頭阻塞”）。而這實際上會對丟包恢復和吞吐量產生巨大影響。

SRD 的創新在于有意通過多個路徑分別發包，雖然包到達后通常是亂序的，但AWS實現了在接收處以極快的速度進行重新排序，最終在充分利用網絡吞吐能力的基礎上，極大地降低了傳輸延遲。

SRD 可以一次性將構成數據塊的所有數據包推送到所有可能路徑，這意味著SRD不會受到隊頭阻塞的影響，可以更快地從丟包場景中恢復過來，保持高吞吐量。

眾所周知，P99尾部延遲代表著只有1％的請求被允許變慢，但這也恰恰反映了網絡中所有丟包、重傳和擁塞帶來的最終性能體現，更能夠說明“真實”的網絡情況。SRD能夠讓P99 尾延遲直線下降（大約 10 倍）。

SRD的主要功能包括：

• 亂序交付：取消按順序傳遞消息的約束，消除了隊頭阻塞，AWS在EFA用戶空間軟件堆棧中實現了數據包重排序處理引擎
• 等價多路徑路由（ECMP）:兩個EFA實例之間可能有數百條路徑，通過使用大型多路徑網絡的一致性流哈希的屬性和SRD對網絡狀況的快速反應能力，可以找到消息的最有效路徑。數據包噴涂（Packet Spraying）可防止出現擁塞熱點，并可以從網絡故障中快速無感地恢復
• 快速的丟包響應：SRD對丟包的響應比任何高層級的協議都快得多。偶爾的丟包，特別是對于長時間運行的HPC應用程序，是正常網絡操作的一部分，不是異常情況
• 可擴展的傳輸卸載：使用SRD，與其他可靠協議（如InfiniBand可靠連接IBRC）不同，一個進程可以創建并使用一個隊列對與任何數量的對等方進行通信

How

SRD 實際工作的關鍵不在于協議，而在于它在硬件中的實現方式。換種說法，就目前而言，SRD 僅在使用 AWS Nitro DPU 時才有效。

SRD亂序交付的數據包需要重新排序才能被操作系統讀取，而處理混亂的數據包流顯然不能指望“日理萬機”的 CPU。即便真通過CPU 來完全負責 SRD 協議并重新組裝數據包流，無疑是高射炮打蚊子——大材小用，那會使系統一直忙于處理不應該花費太多時間的事情，而根本無法真正做到性能的提升。

在SRD這一不尋常的“協議保證”下，當網絡中的并行導致數據包無序到達時，AWS將消息順序恢復留給上層，因為它對所需的排序語義有更好的理解，并選擇在AWS Nitro卡中實施SRD可靠性層。其目標是讓SRD盡可能靠近物理網絡層，并避免主機操作系統和管理程序注入的性能噪音。這允許快速適應網絡行為：快速重傳并迅速減速以響應隊列建立。

AWS說他們希望數據包在“棧上”重新組裝，他們實際上是在說希望 DPU 在將數據包返回給系統之前，完成將各個部分重新組合在一起的工作。系統本身并不知道數據包是亂序的。系統甚至不知道數據包是如何到達的。它只知道它在其他地方發送了數據并且沒有錯誤地到達。

這里的關鍵就是 DPU。AWS SRD 僅適用于 AWS 中配置了 Nitro 的系統。現在不少使用AWS的服務器都安裝和配置了這種額外的硬件，其價值在于啟用此功能將能夠提高性能。用戶需要在自己的服務器上專門啟用它，如果需要與未啟用 SRD 或未配置 Nitro DPU 的設備通信，就不會得到相應的性能提升。

至于很多人關心的SRD未來是否會開源，只能說讓我們拭目以待吧！