AWS SRD 可擴展可靠資料包 (Scalable Reliable Datagram)

Published:
  Lastmod: 2025-07-19
拆解關鍵字
by Ernest Chiang

(圖說：美味的背後有多少辛苦的前置準備？ 拍攝於 Le Bouchon Ogasawara 餐廳，渋谷，東京。圖片來源：Ernest。)

tl;dr 重點摘要

  • 概念：AWS 可擴展可靠資料包 (SRD) 採用可靠但允許亂序的資料包傳遞模式，保證訊息的可靠傳遞，但將「訊息」間的順序控制權交給應用程式，避免了 佇列前端阻塞 1 問題，提供以訊息為中心的網路抽象。

  • 優勢：透過智慧型多路徑傳輸將單一流量分散到多達 64 條平行路徑，在 AWS Nitro System 硬體中實現次毫秒級 2 重傳和壅塞控制。效能表現：P99.9 延遲降低 85%，單流頻寬達 25 Gbps 3。

  • 整合：已經無縫整合至三大場景——EFA (HPC/ML 專用加速)、EBS io2 Block Express (儲存服務) 和 ENA Express (通用網路加速)，客戶無需額外付費或修改軟體。對於 HPC 和 ML 客戶相當有感，使用看起來相同規格的硬體，但因為通訊減少壅塞，而達成更多產出，等於相對降價。

內容

1. 基本概念與設計理念

AWS SRD 可擴展可靠資料包 (Scalable Reliable Datagram, SRD) 是 Amazon 為（自家？）資料中心專門設計的通訊協定，解決傳統 TCP 在現代超大規模、多路徑豐富的資料中心環境中的天花板限制。

設計哲學

可靠但允許亂序 (Reliable but Out-of-Order) 的資料封包傳遞

SRD 將 可靠性 與 有序性 解耦 (decouple)：

  • 在傳輸層保證資料包可靠到達，
  • 但不保證按發送順序抵達，
  • 將封包排序責任上移至應用層。（好好協調 vs 好好甩鍋 XDD）

研發動機

AWS 開發 SRD 是為了支援 HPC 和 ML 工作負載，這些應用採用 批次同步平行 (BSP) 計算模型，整個叢集效能取決於最慢節點，使 長尾延遲 (tail latency) 4 成為關鍵因素。

重新定義

傳統 TCP 的限制：

  • 佇列前端阻塞 1：封包遺失時阻塞後續封包處理
  • 單一路徑：傳統 TCP 採用單一路徑傳輸，雖然 MPTCP 已存在但部署有限 5
  • 重傳逾時過長： 毫秒級 6 RTO 在微秒級 7 資料中心環境過於保守

SRD 的創新：

  • 提供以訊息為中心的網路抽象，允許多個獨立訊息平行傳輸，單一訊息的封包遺失不影響其他訊息處理。
  • 展現了 AWS 垂直整合 的技術創新價值 — 同時掌控硬體、網路拓撲和虛擬化的公司得以進行如此跨領域層級的通訊協定創新。

2. 技術架構與實現

2.1 四大核心技術

SRD 的技術架構建立在四個核心支柱之上：

  • 智慧型多路徑機制、
  • 可靠性保證、
  • 主動式壅塞控制和
  • 硬體處理，

這些元素協同構成高效能、低延遲的傳輸系統。

2.2 智慧型多路徑機制

SRD 採用 封包噴灑 (Packet Spraying) 策略，將單一邏輯流量從數百甚至數千條可用路徑中，一次動態選擇多達 64 條平行路徑進行分散傳輸 8。使得 SRD 有能力超越傳統 ECMP (Equal-cost multi-path routing) 9 的靜態負載分散概念。

動態路徑選擇：

  • 持續監控各路徑的 RTT (round-trip time) 10，感知壅塞狀況
  • 次毫秒級 2 偵測和轉移，從「較慢」路徑動態切換至「較快」路徑
  • 透過操縱 封裝欄位（如 UDP 來源埠號）影響 ECMP 9 交換機決策

優勢：

  • 天然負載分散，降低單一鏈路熱點機率
  • 提高容錯能力，單一鏈路故障不會中斷整個訊息傳輸
graph LR
    %% 發送端（左側）
    subgraph sender ["🚀 SRD 發送端"]
        A[應用程式
訊息處理]
        subgraph srd_sender ["SRD 協定層 (Nitro 硬體處理)"]
            B[封包噴灑引擎]
            J[RTT 監控]
            K[動態路徑調整]
            L[可靠性管理
重傳機制]
            
            J --> K
            K --> B
            L --> B
        end
        A --> B
    end

    %% 中間路徑區域
    subgraph paths ["🌐 多路徑網路"]
        C[路徑 1
RTT: 動態]
        D[路徑 2
RTT: 動態]  
        E[路徑 3
RTT: 動態]
        F[路徑 4
RTT: 動態]
    end

    %% 接收端（右側）
    subgraph receiver ["📥 SRD 接收端"]
        subgraph srd_receiver ["SRD 協定層 (Nitro 硬體處理)"]
            G[封包接收]
            H[無序封包重組
可靠性確認]
            M[ACK 生成]
            
            G --> H
            H --> M
        end
        I[應用程式
訊息重組]
        H --> I
    end

    %% 強制左右排列的連接
    sender ~~~ paths
    paths ~~~ receiver

    %% 數據流連接
    B --> C
    B --> D
    B --> E
    B --> F

    C --> G
    D --> G
    E --> G
    F --> G

    %% RTT 回饋和 ACK 回傳
    M -.-> J
    M -.-> L

    %% 樣式設定
    style sender fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style receiver fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style paths fill:#f1f8e9,stroke:#388e3c,stroke-width:2px
    style A fill:#e1f5fe
    style I fill:#e1f5fe
    style B fill:#fff3e0
    style H fill:#fff3e0
    style J fill:#e8f5e8
    style K fill:#e8f5e8
    style L fill:#ffebee
    style M fill:#ffebee
    style C fill:#fff8e1
    style D fill:#fff8e1
    style E fill:#fff8e1
    style F fill:#fff8e1

2.3 可靠性與壅塞控制

SRD 雖允許封包亂序到達，但在可靠性方面沒有妥協，也主動控制壅塞。很久以前剛發明網路的時候，網路頻寬很珍貴，現在不一樣了，相對便宜許多，可以在合理浪費的情況下，達成節省時間的目的。完成相同任務，但是節省時間，就是效率提升。

可靠性機制：

  • 次毫秒級重傳：利用 Nitro 硬體 避免 作業系統 調度延遲，實現次毫秒級 2 封包重傳
  • 路徑多樣化重傳：重傳封包選擇不同路徑，提高重傳成功機率
  • 平行未完成訊息：允許網路上存在多個未完成訊息，提高鏈路利用率

主動式壅塞控制：

  • 採用「預防勝於治療」的設計哲學，核心目標是維持交換機 佇列長度 最低水準，避免佇列膨脹導致延遲增加。
  • 結合 動態速率限制 和 在途封包總量 精確控制，持續估算可用頻寬和 RTT，提前調降發送速率。

2.4 硬體處理與 EFA 介面

真要說作弊的話，這套 SRD 通訊協定的實際實作是牽涉到物理層面的實體拆解，SRD 核心邏輯使用了 AWS Nitro 專用硬體實現，帶來某種程度護城河等級的優勢。如果是採購現成品的機房，應該就直接沒得學這一招了，得要等現成品市場推出類似架構實作的硬體才能追上 AWS 機房。這可以聊到國際標準與私有標準之間所帶來的市場時間差，未來找時間來聊聊 🚩。

AWS Nitro System 整合：

  • 確定性執行環境：避免 CPU 和作業系統調度影響，消除效能抖動
  • 次毫秒級精確計時：硬體計時器精度遠超軟體實現
  • 降低 CPU 開銷：網路處理交由外部硬體完成，釋放 CPU 資源

EFA 介面：

  • 透過 Elastic Fabric Adapter (EFA) 暴露 SRD 能力，提供 作業系統旁路 功能。
  • HPC 和 ML 應用程式透過 Libfabric API 和 MPI 介面直接與 EFA 硬體通訊，繞過核心網路堆疊，實現極低延遲。

3. 核心問題解決與效能提升

SRD 針對性地解決了傳統 TCP 在資料中心環境中的四大核心問題：

3.1 四大問題與解決方案

長尾延遲 (Tail Latency)：

  • 問題：TCP 的 RTO (Retransmission Timeout) 11 機制在微秒級 7 RTT 環境中過於保守，觸發 RTO 時延遲從微秒級 7 躍升至 毫秒級 6
  • 解決：次毫秒級 2 重傳 + 多路徑重傳，避免在已壅塞路徑上繼續嘗試

佇列前端阻塞 (Head-of-Line Blocking) 1：

  • 問題：單一封包丟失阻塞整個 TCP 視窗內的後續封包處理
  • 解決：可靠但允許亂序設計，多個獨立訊息平行傳輸互不干擾

ECMP 雜湊碰撞 9：

  • 問題：靜態雜湊分配造成網路熱點，TCP 被「鎖定」在壅塞路徑上
  • 解決：主動路徑控制，動態感知路徑狀態並智慧分配封包

CPU 效能開銷：

  • 問題：傳統 TCP/IP 協定堆疊的軟體處理造成系統呼叫、中斷處理等開銷
  • 解決：交由硬體處理，零 CPU 開銷 + 確定性效能 + OS-bypass

3.2 效能對比總覽

以下比較基於雲端虛擬化環境的網路性能

指標虛擬化 + TCP虛擬化 + AWS SRD (Nitro)備註
P99.9 延遲數毫秒 6數十微秒 7降低 85% 3
多路徑利用單一路徑64 條路徑質的突破 8
虛擬化開銷軟體協定堆疊處理，仍有 CPU 負擔（中斷、上下文切換） 12網路協定完整硬體運算，主機 CPU 負擔 <1% 13硬體處理
重傳機制毫秒級 6 RTO次毫秒級 (sub-millisecond) 2 硬體重傳數量級提升 14
壅塞控制反應式 15預防式 16主動優化

4. 應用場景與效能數據

graph TD
    A[SRD 技術核心] --> B[EFA: HPC/ML 專用]
    A --> C[EBS: 儲存服務整合]
    A --> D[ENA Express: 通用加速]
    
    B --> E[CFD 模擬]
    B --> F[ML 訓練]
    B --> G[基因組學]
    
    C --> H[io2 Block Express]
    C --> I[資料庫加速]
    
    D --> J[微服務通訊]
    D --> K[大數據分析]
    D --> L[透明化加速]
    
    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#e8f5e8

4.1 HPC/ML 專用加速：EFA

Elastic Fabric Adapter (EFA) 是 SRD 技術的首個主戰場，讓 AWS 資料中心能承載超級電腦工作負載。

HPC 應用效能：

  • 計算流體力學 (CFD)：雲端機房擴展到數千核心，效能直逼 InfiniBand 叢集
  • 天氣預報模型：低延遲特性使預報模型可使用更精細網格
  • 基因組學計算：大幅縮短序列比對和基因組組裝時間

ML 訓練改善 17：

  • 端點延遲降低 30%
  • 小訊息 Allreduce 操作效能提升 50%
  • PyTorch FSDP 訓練框架效能提升 18%
  • Megatron-LM 效能提升 8%

4.2 儲存服務加速：EBS io2 Block Express

SRD 整合至 Amazon EBS 的最高效能磁碟區類型，帶來顯著效果 18：

  • 延遲改善：相較傳統 EBS 提供 2.5x~3.5x 倍延遲降低
  • 穩定性：一致的次 毫秒級 6 I/O 回應時間
  • 實際效益：客戶案例顯示 30% SQL 查詢時間縮短、20% TPS 提升

4.3 通用網路加速：ENA Express

2022 年推出的 ENA Express 實現技術普及化，提供透明的應用程式加速 19：

透明化特性：

  • 無需修改應用程式程式碼或安裝特殊驅動
  • 只需在 EC2 實例網路設定中啟用該功能
  • 所有 TCP/UDP 流量自動透過 SRD 傳輸

效能提升：

  • P99.9 延遲最多降低 85%
  • 單一 TCP 流量頻寬從 5 Gbps 提升到 25 Gbps

應用場景：

  • 大數據分析、
  • 微服務架構、
  • 資料庫複製、
  • 內容傳輸等

5. 技術比較與市場影響

5.1 與傳統協定的比較

協定發表年份可靠性多路徑延遲Max FCT (Long Flows)部署複雜度備註
TCP1974可靠有序單一路徑 5數十微秒級毫秒級
50–160 ms in incast for 2–32 MB flows (worst-case ≈3–20× ideal time) 20		軟體實現- 網路通訊基礎協定
- 廣泛應用支援
UDP1980不保證依賴應用微秒級依應用層簡單- 簡單快速的資料包協定
- 應用層負責可靠性
InfiniBand RC1999可靠有序連線 21硬體多路徑 22微秒級毫秒級
理想條件下接近理想值 (例如: 數十 MB 約 5–10 ms) 23		需 HCA/TCA 硬體 24- 只討論 RC 模式 25
- 當年 HPC 生態系統標準
- 需要專用硬體
RoCE2010依賴網路層級 26硬體多路徑 27微秒級毫秒級
無損失場景下約比理想值高 10% (毫秒級) 28		需無損失乙太網 29- RDMA over Ethernet 實現 30
- v1 限單一廣播域，v2 支援路由
- 需要專門網路配置
SRD2020可靠但亂序64 條路徑微秒級毫秒級
≈8–9 ms for 2 MB incast flow (vs 8 ms ideal; virtually no penalty) 31		需 AWS Nitro- AWS 專有協定 32
- 提供類似 RDMA 功能
- 無需升級既有 Ethernet 設備
Falcon2023可靠傳輸 33硬體多路徑微秒級Unknown需 Intel IPU- Google 專有協定 34
- 支援 RDMA 和 NVMe 上層協定
  • 此表格展現網路傳輸協定的技術演進，按發表年代排序 35。
  • 從 InfiniBand (1999) 到 RoCE (2010) 再到雲端專用協定 (SRD/Falcon)，展現了 RDMA 技術從專用硬體到標準乙太網的演進軌跡。
  • SRD 使用既有 Ethernet 設備實現毫秒級的 Max FCT (Flow Completion Time)。
  • Max FCT (Maximum Flow Completion Time)：單一資料流從開始傳輸到完全接收完成所需的最長時間
  • 延遲 vs FCT：延遲測量單一封包往返時間，FCT 測量整個資料流的完成時間，更能反映實際應用效能

5.2 雲端廠商機房內部網路架構

OSI 層級AWSGoogle CloudMicrosoft AzureNebiusCoreWeave
L7 應用層EFA API 36Cloud RDMA API 37InfiniBand Verbs API 38InfiniBand Verbs APIInfiniBand Verbs API
L6 表示層Nitro 內部編碼ALTS 內部加密 (L4-L7) 39Azure Boost 編碼(Native)BlueField DPU 加密 40
L5 會話層Nitro 會話管理內部 RPC (gRPC)MANA 會話管理(Native)(Native)
L4 傳輸層SRD 41Falcon 42RoCE v2 + InfiniBand (依實例種類) 43InfiniBand Transport (RC/UD) 44InfiniBand Transport (RC/UD) 45
L3 網路層VPC + ENA Express 46Andromeda 2.1 47AccelNet/MANA 48Virtual Private Cloud 49IP / VLAN/VXLAN Overlay
L2 資料鏈路層EthernetEthernetEthernet / InfiniBandInfiniBand 50InfiniBand 51
L1 實體層QSFP-DD + PAM4 編碼標準光纖 + 封包交換 (主流)，結合光學電路交換 (OCS) 用於拓撲重構 52標準光纖 + PAM4 編碼 (主流)，部分部署中空核心光纖 (HCF) 53InfiniBand HDR/NDR (200/400G), OSFP/QSFP-DD 連接器InfiniBand NDR (400G), OSFP 連接器 54
硬體加速單元Nitro v5 DPU 55Intel IPU E2000 56Azure Boost + MANA 57NVIDIA ConnectX HCA 50BlueField-3 DPU 51

此表格展現主要雲端廠商在資料中心內部的網路虛擬化技術堆疊，聚焦機房內部架構而非客戶對外服務。分層不一定精準對應，有些技術跨越多層。 58。

五家雲端廠商展現不同的技術路線：AWS 憑藉自研 SRD 協定在標準乙太網上創新；Google Cloud 與 Intel 共同設計 IPU 59 E2000 實現 Falcon 協定；Microsoft Azure 採用混合策略結合自製與標準；Nebius 和 CoreWeave 則專注於 NVIDIA InfiniBand 生態系統，為 HPC/AI 工作負載提供高效能網路解決方案。

由此可以略微從旁看出各家廠商對於技術發展路線的取捨與決策思路，以及對於需求了解的深度，是否探究根本原因。我們不在現場，所以只能略為推論與觀察。

影片觀看

(請跳轉到 23:01 開始看。)

參考資料

AWS 官方技術資料

Google Cloud 技術資料

Microsoft Azure 技術資料

其他雲端廠商技術資料

網路協定與標準規範

學術論文與研究資料

產業分析與市場趨勢

技術定義與背景知識

  • Message Passing Interface (MPI) - MPI 標準文件
  • Network Latency and Throughput Testing - Libfabric 效能測試工具
  • 微秒 (μs, microsecond, 0.000001 秒) - 時間單位定義 (7)
  • 毫秒 (ms, millisecond, 0.001 秒) - 時間單位定義 (6)
  • IPU (Infrastructure Processing Unit) - 基礎設施處理單元，專為資料中心網路、儲存和安全處理設計的專用處理器 (59)

感謝所有在 AWS SRD 等相關技術發展過程中貢獻智慧的研究者和工程師們。

  1. Head-of-line blocking - Wikipedia ↩︎ ↩︎ ↩︎ ↩︎

  2. 次毫秒級, sub-millisecond, 少於 1 毫秒但通常為數百微秒級 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. 此性能數據基於 AWS ENA Express 在同一可用區 (AZ) 內支援的 EC2 實例類型上的測試結果。 AWS re:Invent 2022: CMP333: Scaling network performance on next generation EC2 network optimized instances (page 37) ↩︎ ↩︎ ↩︎

  4. Tail Latency: Key in Large-Scale Distributed Systems | Last9, The Tail at Scale – Communications of the ACM ↩︎ ↩︎ ↩︎

  5. 標準 TCP 採用單一路徑傳輸，每個 TCP 連接由四元組（來源和目的地址及埠號）唯一識別。雖然存在 Multipath TCP (MPTCP) 擴展標準 (RFC 6824, RFC 8684)，但主流部署仍以單一路徑為主。MPTCP 透過建立多個子流 (subflows) 實現多路徑，但需要額外的協定支援。Multipath TCP - Wikipedia。Multipath TCP 已在 Linux 5.6、iOS 7（Siri）等商用部署多年。 ↩︎ ↩︎ ↩︎

  6. 毫秒, ms, millisecond, 0.001 秒 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. 微秒, μs, microsecond, 0.000001 秒 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. AWS HPC Blog: “in practice, for memory reasons, they choose 64 paths at a time from the hundreds or even thousands available” In the search for performance, there’s more than one way to build a network ↩︎ ↩︎ ↩︎

  9. Equal-cost multi-path routing - Wikipedia ↩︎ ↩︎ ↩︎ ↩︎

  10. Round-trip delay - Wikipedia ↩︎ ↩︎

  11. TCP Retransmission Timeout (RTO): Causes & Performance — Extrahop ↩︎ ↩︎

  12. 傳統雲端虛擬化的網路處理在 CPU 密集：AWS 早期 Xen 高達 30% 資源分配給 hypervisor，Azure 傳統虛擬網路功能造成 guest VM 和 hypervisor 雙重 CPU 負載。Reinventing virtualization with the AWS Nitro System, TCP/IP performance tuning for Azure VMs。這是回顧當年的數據，已經不是當下 Nitro 環境的普遍情況。 ↩︎ ↩︎

  13. AWS Nitro System 透過硬體處理實現接近裸機性能，Netflix 基準測試顯示開銷少於 1%。Bare metal performance with the AWS Nitro System | Amazon Web Services ↩︎ ↩︎

  14. SRD 在數百至數千微秒內偵測和重傳封包，而 RFC 6298 與 Linux TCP 實作皆規定最小 RTO 為 200 ms，性能差距約 100 倍。In the search for performance, there’s more than one way to build a network | AWS HPC Blog, TCP Retransmission May Be Misleading (2023) ↩︎ ↩︎

  15. TCP 採用反應式壅塞控制，在偵測到壅塞訊號（如封包遺失、ECN）後才調整發送速率。TCP congestion control - Wikipedia ↩︎ ↩︎

  16. SRD 採用主動式壅塞控制，在預估網路管道有足夠容量時才發送封包，p99 尾端延遲降低約 10 倍。A Comprehensive Review on Congestion Control Techniques in Networking ↩︎ ↩︎

  17. AWS EFA 第二代在相同 P4d 硬體上，小型和中型訊息效能提升高達 50%，大型訊息效能提升 10%。在 128 GPU (16 實例) 叢集測試中，PyTorch FSDP 訓練效能提升 18%，Megatron-LM 效能提升 8%，加速器小型集體操作的通訊時間改善 50%。Second generation EFA: improving HPC and ML application performance in the cloud ↩︎ ↩︎

  18. EBS io2 Block Express 透過 SRD 協定提供次毫秒級延遲，相較傳統 EBS 提供顯著的延遲改善。在實際案例中，PostgreSQL 測試顯示 3.47 倍寫入延遲降低和 3.13 倍 OLAP 延遲降低，時尚電商零售商實現 30% SQL 查詢時間縮短和 20% TPS 提升。Global fashion e-commerce retailer shortens SQL query time by 30% using Amazon EBS io2 Block Express, Running I/O intensive workloads on PostgreSQL with Amazon EBS io2 Block Express ↩︎ ↩︎

  19. ENA Express 透明加速需要同一可用區 (AZ) 內的兩個支援實例類型，且網路路徑不能包含中介設備。自動使用 SRD 協定將單流頻寬從 5 Gbps 提升至 25 Gbps，P99.9 延遲改善高達 85%，完全免費且無需修改應用程式。Improve network performance between EC2 instances with ENA Express ↩︎ ↩︎

  20. TCP 的 Flow Completion Time 主要受限於壅塞控制算法和重傳逾時機制。在高延遲或封包遺失情況下，TCP 的 RTO (Retransmission Timeout) 可能導致數十到數百毫秒的完成時間，特別是在 incast 情況下。現代壅塞控制算法如 Cubic 和 BBR 在一定程度上改善了這個問題。TCP congestion control - Wikipedia ↩︎ ↩︎

  21. InfiniBand Reliable Connection (RC) 提供可靠有序傳輸，類似 TCP 連接，保證封包的可靠性和有序性。透過硬體層面的確認機制、重傳和流量控制實現零封包遺失的可靠傳輸，確保資料完整性和傳輸順序。NVIDIA HPC-X Software Toolkit Documentation ↩︎ ↩︎ ↩︎

  22. InfiniBand 支援多種鏈路配置（1x, 4x, 8x, 12x）以及交換織架構拓撲，提供多條平行路徑減少網路瓶頸。採用可擴展的互連技術，可以聚合鏈路以增加頻寬，實現最佳化的負載分散。在 2014-2016 年間，InfiniBand 是 TOP500 超級電腦列表中最常用的互連技術。InfiniBand - Wikipedia ↩︎ ↩︎

  23. InfiniBand RC 模式的 Flow Completion Time 在理想條件下通常能接近理論最佳值，得益於硬體層面的快速重傳機制和低延遲互連。在大型 HPC 叢集中，InfiniBand 的集體通訊操作（如 Allreduce）能夠有效降低整體任務完成時間。InfiniBand Trade Association Performance Metrics ↩︎ ↩︎

  24. InfiniBand 需要專用硬體支援：(1) HCA (Host Channel Adapter) 連接主機到 InfiniBand 網路，提供 RDMA 功能和硬體處理；(2) TCA (Target Channel Adapter) 連接儲存設備和 I/O 裝置；(3) InfiniBand 交換機建立高效能網路拓撲。主要供應商包括 NVIDIA/Mellanox 的 ConnectX 系列 HCA 和 Quantum 系列交換機。InfiniBand - Wikipedia ↩︎ ↩︎

  25. InfiniBand 是 RDMA 的原生實現，提供遠端直接記憶體存取功能，包括讀/寫、發送/接收、多播和原子操作等多種訊息類型。與傳統 TCP/IP 通訊不同，RDMA 通訊繞過核心介入，減少 CPU 開銷，讓主機適配器直接將封包內容放入應用程式緩衝區。InfiniBand - Wikipedia ↩︎ ↩︎

  26. RoCE 的可靠性依賴網路基礎設施而非協定本身。需要 Priority Flow Control (PFC) 確保無損失傳輸，並使用 IP ECN 位元和 CNP (Congestion Notification Packet) 框架進行壅塞控制。與 InfiniBand 不同，RoCE 不提供內建的端到端可靠性保證。RDMA over Converged Ethernet - Wikipedia ↩︎ ↩︎

  27. RoCE 透過標準乙太網交換架構提供多路徑支援，利用 ECMP (Equal-Cost Multi-Path) 路由和鏈路聚合技術實現負載分散。相較於 InfiniBand 的專用交換織架構，RoCE 可在現有的融合乙太網基礎設施上部署，降低硬體成本。RDMA over Converged Ethernet - Wikipedia ↩︎ ↩︎

  28. RoCE 的 Flow Completion Time 與底層乙太網配置密切相關，在理想的無損失環境中通常比理論最佳值高約 10%。然而，RoCE 對網路壅塞較為敏感，Priority Flow Control (PFC) 的配置直接影響 FCT 表現。RDMA over Converged Ethernet - Wikipedia ↩︎ ↩︎

  29. RoCE 部署需要無損失乙太網 (Lossless Ethernet) 環境，要求所有網路端點和交換機支援 Priority Flow Control (PFC)。網路配置必須確保一致性，包括 QoS 設定、緩衝區管理和壅塞控制機制。相對於 InfiniBand 的即插即用，RoCE 需要更仔細的網路規劃。InfiniBand and RoCE Documentation - Red Hat ↩︎ ↩︎

  30. RoCE 有兩個主要版本：(1) RoCE v1 使用專用的 Ethernet type (0x8915)，限制在單一 Ethernet 廣播域內；(2) RoCE v2 使用 UDP 封裝 (port 4791)，支援 IPv4/IPv6 路由，可跨越第三層網路。RoCE v2 為主流部署版本，解決了 v1 的路由限制。RDMA over Converged Ethernet - Wikipedia ↩︎ ↩︎

  31. SRD 的 Flow Completion Time 受益於多路徑負載分散和次毫秒級重傳機制，偵測＋重傳時間為「數百至數千 µs」。在 2 MB incast flow 測試中，SRD 實現約 8-9 ms 的 FCT，與 8 ms 理論最佳值幾乎相等，展現幾乎零效能損失。In the search for performance, there’s more than one way to build a network ↩︎ ↩︎

  32. AWS SRD 採用乙太網基礎傳輸，放寬了封包順序要求，認為如果必要可以在較高層重新斷言順序。這種設計選擇帶來顯著效能優勢：p99 尾端延遲大幅降低（約 10 倍）。SRD 能夠將組成資料塊的所有封包一次性推送到所有可能的路徑上，實踐中選擇 64 條路徑。In the search for performance, there’s more than one way to build a network ↩︎ ↩︎

  33. Google Cloud Falcon 是硬體輔助的傳輸層協定，於 2023 年 10 月 18 日發表，並於 2024 年透過 Open Compute Project 開源。採用細粒度硬體輔助 RTT 測量、流量整形和快速封包重傳技術，支援 RDMA 和 NVMe 上層協定。首次在 Intel IPU E2000 產品中實現，專為高爆發頻寬、高訊息率和低延遲的 AI/ML 訓練與 HPC 工作負載設計。Introducing Falcon: a reliable low-latency hardware transport ↩︎ ↩︎

  34. Google Cloud Falcon 協定支援 RDMA 和 NVMe 等上層協定 (ULP)，提供與 InfiniBand Verbs RDMA 的開箱即用相容性。Cloud RDMA 在底層使用 Google 創新的 Falcon 硬體傳輸，在基於乙太網的資料中心網路上提供可靠、低延遲通訊，有效解決傳統 RDMA over Ethernet 的挑戰。Introducing Falcon: a reliable low-latency hardware transport ↩︎ ↩︎

  35. 網路傳輸協定比較涵蓋可靠性、多路徑支援、部署複雜度和應用整合等面向。TCP 提供可靠有序傳輸但傳統上限於單一路徑；UDP 簡單快速但不保證可靠性；InfiniBand 提供超低延遲和高吞吐量但需要特殊硬體；SRD 結合可靠性和多路徑特性，專為資料中心環境設計。Multi-Path Transport for RDMA in Datacenters ↩︎ ↩︎

  36. AWS EFA 專為 MPI 工作負載最佳化，提供 15.5 微秒的 MPI ping-pong 延遲，透過 OS-bypass 功能和 SRD 協定實現超低延遲通訊。第二代 EFA 較第一代延遲降低約 50%，為雲端 HPC 和 ML 工作負載提供接近裸機的網路效能。Now Available – Elastic Fabric Adapter (EFA) for Tightly-Coupled HPC Workloads ↩︎ ↩︎

  37. Google Cloud RDMA 專為 AI 工作負載最佳化，採用 Falcon 硬體傳輸技術，透過硬體輔助的 RTT 測量、流量整形和快速封包重傳實現超低延遲。A3 Ultra VM 提供高達 3.2 Tbps 非阻塞 GPU 間通訊，Cloud RDMA 在 CFD 模擬中相較 TCP 提供高達 3.4 倍效能提升。Introducing Falcon: a reliable low-latency hardware transport ↩︎ ↩︎

  38. Azure InfiniBand 專為 HPC 工作負載最佳化，HBv3 系列配備 200 Gb/s HDR InfiniBand，HBv4 系列配備 400 Gb/s NDR InfiniBand，採用非阻塞胖樹拓撲實現一致的亞微秒延遲效能。InfiniBand 網路具備自適應路由、硬體加速 MPI 集體操作和增強的壅塞控制能力，支援最大 80,000 核心 MPI 工作負載。HBv3-series VM sizes performance and scalability ↩︎ ↩︎

  39. Google Cloud 使用 Application Layer Transport Security (ALTS) 進行內部 RPC 通訊的相互驗證和傳輸加密，專為 Google 資料中心環境最佳化。ALTS 類似於相互驗證的 TLS，但針對內部微服務通訊設計，提供認證、完整性和加密功能，是 Google 機房內部網路安全的核心組件。Application Layer Transport Security ↩︎ ↩︎

  40. CoreWeave 透過 NVIDIA BlueField-3 DPU 提供硬體級加密和安全處理功能，包括 TLS/SSL 處理、IPSec 加速和資料路徑加密。BlueField DPU 整合 ARM 核心和可程式化網路處理器，為多租戶雲端環境提供零信任安全架構。NVIDIA BlueField-3 Data Processing Unit ↩︎ ↩︎

  41. AWS 在 L4 傳輸層採用混合架構：TCP 處理一般網路流量，SRD 協定用於 HPC/ML 工作負載（透過 EFA）和網路加速（透過 ENA Express）。ENA Express 能夠透明地將 TCP 流量處理到 SRD，在同一可用區內實現高達 25 Gbps 單流頻寬和 85% 延遲降低。Elastic Network Adapter (ENA) Express, Elastic Fabric Adapter (EFA) ↩︎

  42. Google Cloud 在 L4 傳輸層主要使用 TCP 處理一般流量，並透過 Falcon 硬體傳輸協定為 AI/ML 工作負載提供超低延遲通訊。Cloud RDMA 建立在 Falcon 之上，提供高頻寬的 GPU 間通訊。內部服務間通訊大量使用 gRPC over HTTP/2 (基於 TCP)。Introducing Falcon: a reliable low-latency hardware transport ↩︎ ↩︎

  43. Microsoft Azure 提供多種虛擬機器類型以支援不同工作負載，包括專為高效能運算設計的 HBv3 和 HBv4 系列。這些 HPC 實例配備 InfiniBand 網路連接，HBv3 系列使用 200 Gb/s HDR InfiniBand，HBv4 系列使用 400 Gb/s NDR InfiniBand，為要求低延遲高頻寬通訊的科學運算應用提供網路支援。HBv3-series VM sizes ↩︎ ↩︎

  44. Nebius 部署 NVIDIA Quantum-2 InfiniBand 網路，提供 HDR (High Data Rate) 400 Gb/s 連接能力。每個 GPU 主機配備高達 3.2 Tbps 總網路頻寬，透過非阻塞胖樹拓撲實現超低延遲通訊，專為大規模 AI 訓練和 HPC 工作負載最佳化。GPU clusters with NVIDIA Quantum-2 InfiniBand ↩︎ ↩︎

  45. CoreWeave 部署 RDMA over InfiniBand 提供超低延遲 GPU 間通訊，支援 NVIDIA NCCL (NVIDIA Collective Communication Library) 最佳化的集體通訊操作。RDMA 實現零拷貝資料傳輸和 OS-bypass 功能，為大規模分散式機器學習訓練提供高效率網路通訊。RDMA and InfiniBand | CoreWeave ↩︎ ↩︎

  46. AWS 在 L3 網路層透過 Virtual Private Cloud (VPC) 提供軟體定義網路功能，並透過 ENA Express 技術在網路層實現流量加速。VPC 支援多可用區域、子網分割、路由表和安全群組等功能。ENA Express 在網路層提供智慧型多路徑路由和動態壅塞控制，將 SRD 協定的優勢延伸到整個網路堆疊。Amazon VPC User Guide, Improve network performance between EC2 instances with ENA Express ↩︎ ↩︎

  47. Google Cloud 使用 Andromeda 軟體定義網路系統作為其網路虛擬化控制平面，負責虛擬網路的配置、管理和監控。Andromeda 支援 VPC、防火牆規則、負載平衡和 Cloud NAT 等功能，為 Google Cloud 提供可擴展的網路虛擬化服務。Virtual Private Cloud (VPC) overview ↩︎ ↩︎

  48. Microsoft Azure 使用軟體定義網路技術提供虛擬網路服務，包括虛擬網路 (VNet)、子網、路由表和網路安全群組等功能。Azure 的網路架構支援多種高效能運算和 AI 工作負載，透過 AccelNet 技術最佳化網路效能。Azure Virtual Network documentation ↩︎ ↩︎

  49. Nebius Virtual Private Cloud 提供軟體定義網路功能，包括子網分割、路由控制、安全群組和網路 ACL。VPC 整合負載平衡器、NAT 閘道和 VPN 連接，支援多可用區架構和跨區域網路連接，為雲端資源提供隔離的網路環境。Nebius VPC Documentation ↩︎ ↩︎

  50. Nebius 採用 NVIDIA Quantum-2 InfiniBand 交換架構，提供 64 埠 400Gb/s 或 128 埠 200Gb/s 的交換能力。Quantum-2 平台支援自適應路由、硬體加速的集體通訊操作和增強的壅塞控制，為高效能運算叢集提供無阻塞網路拓撲。GPU clusters with NVIDIA Quantum-2 InfiniBand ↩︎ ↩︎ ↩︎

  51. CoreWeave 部署 NVIDIA BlueField-3 DPU 提供 400 Gb/s 網路處理能力，整合 16 個 ARM Cortex-A78 核心和可程式化封包處理引擎。BlueField-3 支援硬體加速的虛擬交換、SDN 處理和安全功能，為雲端原生工作負載提供高效能資料路徑處理。NVIDIA BlueField-3 Data Processing Unit ↩︎ ↩︎ ↩︎

  52. Google Cloud 採用光學電路交換 (OCS) 技術作為 Jupiter 資料中心網路的核心組件，使用 MEMS 鏡面進行動態端口映射和頻寬分配。OCS 技術結合波分多工 (WDM) 實現高容量資料傳輸，並支援動態網路重配置以最佳化應用效能和資源利用率。The evolution of Google’s Jupiter data center network ↩︎ ↩︎

  53. Microsoft Azure 在全球網路基礎設施中部署中空核心光纖 (Hollow Core Fiber, HCF) 技術，相較傳統光纖提供更低的延遲和損耗特性。HCF 技術在 1550nm 波長下實現比標準單模光纖更優異的信號傳輸品質，為雲端服務提供更快速的全球連接能力。The deployment of Hollow Core Fiber in Azure’s network ↩︎ ↩︎

  54. CoreWeave 實體網路採用 OSFP (Octal Small Form-factor Pluggable) 連接器，NVIDIA Quantum-2 InfiniBand 交換機透過 32 個 OSFP 端口提供 64 個 400Gb/s 連接。網路支援多種實體介面選項，包括 APC 光纖連接器、MPO 多芯光纖連接器、主動銅纜和直連電纜，為高效能運算叢集提供靈活的連接解決方案。NVIDIA InfiniBand Networking Products ↩︎ ↩︎

  55. AWS Nitro System 是專為雲端運算設計的資料處理單元 (DPU)，整合網路、儲存和安全處理功能到專用硬體中。Nitro System 提供高效能網路處理，支援 SR-IOV 虛擬化、硬體級加密和 SRD 協定處理。Nitro DPU 將網路虛擬化移到硬體處理，釋放主機 CPU 資源用於客戶工作負載，實現接近裸機的效能。AWS Nitro System ↩︎ ↩︎

  56. Intel IPU E2000 是 Intel 首款 ASIC 型基礎設施處理單元，採用 TSMC 7nm 製程，搭載 ARM Neoverse 計算複合體，提供 200Gbps 可程式封包處理能力。E2000 與 Google Cloud 共同設計，首次實現 Falcon 硬體傳輸協定，具備 NVMe 處理、線速加密、進階壓縮加速等功能。專為 AI/ML 訓練、HPC 工作負載和雲端基礎設施設計，現已部署於 Google Cloud C3 機器系列。Intel IPU E2000: A collaborative achievement with Google Cloud ↩︎ ↩︎

  57. Microsoft Azure 使用專門的硬體加速技術提供資料鏈路層最佳化，包括 Azure Boost 和 MANA (Microsoft Azure Network Adapter) 等技術。這些技術處理網路虛擬化、儲存和加速運算功能，提供 SR-IOV 虛擬化和 RDMA 支援，使雲端虛擬機能夠達到接近裸機的網路效能。Azure networking services overview ↩︎ ↩︎

  58. 雲端廠商採用多層次網路堆疊優化策略：AWS 以 Nitro DPU + SRD 協定實現完整硬體處理；Google Cloud 以 Titanium IPU + Falcon 傳輸提供 200 Gbps 低延遲網路；Azure 以 Boost + MANA SmartNIC 結合 InfiniBand 提供亞微秒延遲。各廠商均採用專用硬體加速、SDN 技術和工作負載最佳化策略。AWS Nitro v5 Ups the Cloud DPU Game Again ↩︎ ↩︎

  59. IPU (Infrastructure Processing Unit)：基礎設施處理單元，專為資料中心網路、儲存和安全處理設計的專用處理器 ↩︎ ↩︎

  60. AWS 在網路最佳化 EC2 實例中採用先進的實體層技術，包括 QSFP-DD 連接器和 400 GbE PAM4 編碼。透過 ENA Express 技術，AWS 實現單流頻寬從 5 Gbps 提升至 25 Gbps，P99.9 延遲改善達 85%，這些改善建立在底層硬體最佳化的基礎上。Using ENA Express to improve workload performance on AWS ↩︎

  61. AWS SRD 總體頻寬 3200 Gbps 基於 P5 實例的網路規格，其中最多 800 Gbps 可用於 IP 網路流量。EFA 和 IP 網路流量共享相同的底層資源，頻寬可在兩者間任意分配，但總頻寬不得超過 3200 Gbps。SRD 透過第二代 Elastic Fabric Adapter (EFA) 技術實現。Maximize network bandwidth on Amazon EC2 instances with multiple network cards ↩︎

  62. Google Cloud Falcon 協定的 200 Gbps 總體頻寬規格基於 Intel IPU E2000 的可程式封包處理能力。Intel IPU E2000 提供線速 200 Gbps 的低延遲網路處理，並支援硬體級加密。C3 機器透過這項技術相較前代 C2 機器實現高達 20% 的效能提升。Intel IPU E2000: A collaborative achievement with Google Cloud ↩︎

  63. Nebius 提供配備 NVIDIA Quantum-2 InfiniBand 的 GPU 叢集，每個主機 8 個 GPU，每 GPU 高達 400 Gbps 連線，主機總網路頻寬達 3.2 Tbps。採用 NVIDIA Quantum-2 平台的 400Gbps InfiniBand 交換機，提供 64 埠 400Gb/s 或 128 埠 200Gb/s 連接能力。GPU clusters with NVIDIA Quantum-2 InfiniBand ↩︎

  64. CoreWeave 部署 NVIDIA HGX H100/H200 GPU 叢集，配備 NVIDIA Quantum-2 InfiniBand NDR 網路 (3200Gbps)、Intel 第五代 Xeon CPU、NVIDIA BlueField-3 DPU。H200 提供 4.8 TB/s 記憶體頻寬和 141 GB HBM3e，相較 H100 推理效能提升 1.9 倍。叢集規模高達 42,000 GPU。NVIDIA HGX H100/H200 ↩︎

  65. CoreWeave 網路基礎設施採用 NVIDIA Cumulus Linux 作為網路作業系統，提供開放式網路架構和標準化的交換機管理。Cumulus Linux 支援 BGP、OSPF、EVPN-VXLAN 等現代資料中心協定，實現可擴展的脊葉式網路拓撲。NVIDIA Cumulus Linux ↩︎

  66. SRD 與 QUIC 都基於 UDP 解決 TCP 問題但目標不同：QUIC 針對 web 應用和 HTTP/3，軟體實現於用戶空間，內建 TLS 加密；SRD 針對 HPC/AI 計算，硬體實現於 Nitro DPU，強調超低延遲高吞吐。QUIC 採用零往返連線建立和多工傳輸，SRD 採用可靠亂序傳遞和 64 路徑多路傳輸。Comparing TCP and QUIC ↩︎

  67. InfiniBand 主要用於高效能運算環境中的伺服器和儲存系統互連。支援 RDMA 功能，包括遠端直接記憶體存取讀/寫、通道發送/接收、交易式操作、多播傳輸和原子操作等多種訊息類型。在 2014-2016 年間，InfiniBand 是 TOP500 超級電腦列表中最常用的互連技術。InfiniBand - Wikipedia ↩︎

  68. DPU SmartNIC 市場以 15-25% CAGR 增長，產業趨向專門化、工作負載特定最佳化的網路解決方案。Data Processing Unit Market Size Growth Analysis Report 2031 ↩︎