UDP

3 秒看懂

UDP = 網際網路的”明信片”——寫完地址就扔進郵筒，不簽收、不回執、不保證送達，但快、輕、便宜。AI時代它是資料中心內部”RDMA over Ethernet”的封裝基礎，也是即時推論、流式傳輸的底層通道。

3 分鐘產業解釋

核心定義

UDP（User Datagram Protocol）是TCP/IP協議棧傳輸層的兩大協議之一（RFC 768, 1980）。與TCP相反，它無連線、不可靠、無流控，但換來的是極低開銷和極低延遲。

為什麼AI產業關心一個1980年的協議？

AI場景	UDP的角色
資料中心分散式訓練	RoCE v2（RDMA over Converged Ethernet v2）使用UDP封裝InfiniBand語義，已成為萬卡叢集的事實標準傳輸層
即時推論服務	LLM流式輸出（SSE/WebSocket底層）、語音/影片AI的即時傳輸
邊緣AI/IoT	感測器資料採集、車聯網V2X訊息
AI生成內容分發	直播推流（RTP/RTCP基於UDP）、雲端遊戲
新興協議QUIC	HTTP/3的底層基於UDP，Google/OpenAI API已大規模部署

關鍵認知：UDP本身簡單，但它是現代高效能網路協議棧的”地基層”——越上層的AI應用對延遲敏感，越可能繞過TCP轉向UDP系方案。

15 分鐘專家深入

一、協議本質：為什麼”少即是多”

UDP頭部僅8位元組（Source Port 2B + Dest Port 2B + Length 2B + Checksum 2B），對比TCP頭部20-60位元組。這意味著：

┌─────────────────────────────────────────────┐
│            UDP 資料包（Datagram）            │
├─────────────┬──────────────┬──────┬─────────┤
│ 源埠 (16b) │ 目的埠 (16b) │長度16b│校驗和16b │  ← 僅8位元組頭部
├─────────────┴──────────────┴──────┴─────────┤
│                                             │
│              應用層資料（Payload）            │
│                                             │
└─────────────────────────────────────────────┘

不做之事清單（對比TCP）：

❌ 三次握手建立連線
❌ 序列號/確認號（無重傳）
❌ 滑動視窗流控
❌ 擁塞控制（無慢啟動、無AIMD）
❌ 有序交付保證

二、RoCE v2：AI叢集的UDP應用主戰場

RoCE v2（RDMA over Converged Ethernet v2） 是當前AI訓練叢集最重要的UDP應用載體：

┌──────────────────────────────────────┐
│         應用層（NCCL/MPI集合通訊）      │
├──────────────────────────────────────┤
│        RDMA 層（Verbs語義）            │  ← 零複製、核心旁路
├──────────────────────────────────────┤
│      InfiniBand Transport Header      │
├──────────────────────────────────────┤
│     ★ UDP Header（DST Port 4791）★    │  ← UDP封裝，允許標準乙太網路轉發
├──────────────────────────────────────┤
│           IPv4/IPv6 Header            │
├──────────────────────────────────────┤
│           Ethernet Frame              │
└──────────────────────────────────────┘

為什麼選UDP而非TCP做RDMA封裝？

核心旁路（Kernel Bypass）：TCP需要核心協議棧處理連線狀態，RDMA的目標是繞過核心；UDP無狀態，更容易實現使用者態直接操作
無重傳延遲：TCP的重傳超時（RTO）通常數百毫秒級，對分散式訓練AllReduce是災難；RoCE v2的丟包由上層（如DCQCN擁塞控制）或應用層處理
硬體解除安裝友好：網絡卡（RNIC）可以更簡單地解析無狀態的UDP頭部

三、QUIC：基於UDP的”新TCP”

Google主導的QUIC協議（RFC 9000）將TCP的可靠性語義”上移”到使用者態UDP之上：

傳統：  HTTP/2 ──→ TCP ──→ TLS ──→ IP
QUIC：  HTTP/3 ──→ QUIC（含TLS 1.3）──→ UDP ──→ IP

AI產業影響：

OpenAI API、Claude API的流式傳輸逐步遷移至HTTP/3/QUIC
邊緣推論場景中，QUIC的連線遷移（Connection ID而非IP:Port標識）適合移動裝置

技術原理（最深一層）

一、協議狀態機：無狀態的簡潔

              ┌─────────────────┐
              │    UDP 處理      │
              │   （無狀態機）    │
              └────────┬────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
     ┌─────────┐ ┌──────────┐ ┌──────────┐
     │ 傳送路徑  │ │ 接收路徑  │ │ 差錯處理  │
     │         │ │          │ │          │
     │·構造頭部 │ │·校驗和檢查│ │·校驗和錯  │
     │·校驗和(可│ │·埠匹配  │ │ → 靜默丟棄│
     │ 選計算)  │ │·遞交套接字│ │·埠不可達│
     │·遞交IP層 │ │          │ │ → 返回ICMP│
     └─────────┘ └──────────┘ └──────────┘

關鍵引數：

校驗和：IPv4中可選（設為0x0000表示不計算），IPv6中強制[RFC 8200]
最大報文長度：理論65,535位元組（16b長度欄位），實際受MTU限制（乙太網路通常≤1472位元組有效載荷，即1500 MTU - 20 IP頭 - 8 UDP頭）
埠號空間：0-65535，與TCP埠空間獨立

二、UDP在高效能網路中的協議棧分層

┌─────────────────────────────────────────────────────────────────┐
│                        應用層                                    │
│  NCCL AllReduce / gRPC Streaming / RTP / QUIC                  │
├─────────────────────────────────────────────────────────────────┤
│                     可靠性/有序性層                               │
│  RDMA (IB Transport) / QUIC Transport / 應用層重傳               │
├─────────────────────────────────────────────────────────────────┤
│                    ★ UDP 傳輸層 ★                                │
│  無狀態封裝、埠複用、最小開銷                                    │
├─────────────────────────────────────────────────────────────────┤
│                     網路層                                       │
│  IPv4/IPv6 + ECMP（等價多路徑，依賴UDP五元組雜湊）                │
├─────────────────────────────────────────────────────────────────┤
│                    資料鏈路層                                     │
│  Ethernet + PFC/ECN（資料中心無損/低損網路）                     │
├─────────────────────────────────────────────────────────────────┤
│                      物理層                                      │
│  25G/50G/100G/400G/800G SerDes                                  │
└─────────────────────────────────────────────────────────────────┘

三、UDP與ECMP的協同：為什麼AI網路愛UDP

資料中心交換器使用ECMP（Equal-Cost Multi-Path） 做負載均衡，雜湊鍵通常包含五元組（Src IP, Dst IP, Protocol, Src Port, Dst Port）。

TCP的長連線導致雜湊結果固定，易造成鏈路擁塞
UDP無連線狀態，應用層可靈活控制源埠（如輪流遞增），實現更均勻的流量分佈
在萬卡叢集的All-to-All通訊中，這一特性對網路利用率至關重要

技術演進史

年份	里程碑	意義
1980	RFC 768釋出（Jon Postel）	UDP誕生，僅3頁規範，可能是最簡潔的RFC之一
1981	RFC 791/793	IPv4/TCP同期定義，TCP/IP協議棧基本成型
1998	RFC 2460	IPv6規範中UDP校驗和變為強制（因IPv6取消了IP層校驗和）
2003	RTP（RFC 3550）	即時音影片傳輸基於UDP標準化，網際網路流媒體時代開啟
2002	iWARP提出	RDMA over TCP，但核心協議棧開銷成為瓶頸
2010	RoCE v1釋出	IBTA提出，RDMA直接封裝乙太網路幀，但不支援L3路由
2014	RoCE v2釋出	★用UDP封裝RDMA，支援L3路由+ECMP，奠定AI叢集網路基礎
2016	QUIC（Google私有版）	基於UDP的傳輸協議，HTTP/3前身
2021	QUIC成為RFC 9000	IETF標準化，HTTP/3時代開啟
2023-2024	Ultra Ethernet Consortium成立	面向AI/HPC的乙太網路演進，UDP/RDMA是核心討論點

技術路線對比

UDP vs TCP vs RDMA語義對比

特性	UDP	TCP	RDMA (InfiniBand原生)
連線狀態	無	有（三次握手）	有（Queue Pair建立）
可靠性	不保證	保證（重傳+確認）	保證（硬體級）
有序性	不保證	保證	可選（可靠/不可靠）
頭部開銷	8位元組	20-60位元組	IB: ~16位元組
延遲	極低	中（擁塞控制+重傳）	極低（硬體解除安裝）
CPU佔用	低	高（核心協議棧）	極低（核心旁路）
擁塞控制	無（應用自理）	內建（如CUBIC/BBR）	DCQCN/ECN
典型AI用途	RoCE v2封裝、流媒體	模型下載、引數儲存	集合通訊（AllReduce）
萬卡叢集適配	★★★★★	★★☆☆☆	★★★★★（但需乙太網路+UDP封裝）

UDP上層可靠性方案對比

方案	可靠性機制	延遲開銷	AI場景適用性
應用層重傳	自定義超時+重傳邏輯	取決於實現	小規模/特定場景
RoCE v2 + DCQCN	ECN標記+速率調節，依賴無損/低損網路	極低	★萬卡訓練叢集主流
QUIC	使用者態可靠傳輸+TLS整合	中	LLM API流式服務
SCTP	核心級多流可靠UDP替代	中	電信領域，AI領域少用

上下游

上游（UDP依賴什麼）

┌─────────────────────────────────────────────────────┐
│                   硬體層                             │
│  · 網絡卡/RNIC：NVIDIA ConnectX/Mellanox、Intel E810  │
│  · 交換晶片：Broadcom Memory、NVIDIA Spectrum        │
│  · 光模組/銅纜：25G→100G→400G→800G                  │
├─────────────────────────────────────────────────────┤
│                   核心/驅動層                         │
│  · OS核心網路棧（Linux: ksoftirqd/netfilter）        │
│  · DPDK（使用者態資料平面開發套件，繞過核心）           │
│  · RDMA驅動（mlx5_core, bnxt_re）                   │
├─────────────────────────────────────────────────────┤
│                   協議標準層                          │
│  · IETF RFC 768/8085                                │
│  · IEEE 802.3 (Ethernet)                            │
│  · IBTA RoCE v2規範                                 │
└─────────────────────────────────────────────────────┘

下游（UDP服務什麼）

┌─────────────────────────────────────────────────────┐
│                   AI基礎設施                         │
│  · 集合通訊庫：NCCL (NVIDIA)、Gloo (Meta)           │
│  · 分散式架構：PyTorch DDP、DeepSpeed、Megatron     │
│  · 推論架構：vLLM、TensorRT-LLM、TGI               │
├─────────────────────────────────────────────────────┤
│                   應用層協議                         │
│  · 流媒體：RTP/RTCP、HLS/DASH分發                   │
│  · API服務：gRPC（可用UDP模式）、HTTP/3 (QUIC)      │
│  · 物聯網：MQTT-SN（基於UDP的輕量訊息協議）          │
├─────────────────────────────────────────────────────┤
│                   端側應用                           │
│  · 雲端遊戲/雲端渲染（即時互動）                         │
│  · 自動駕駛V2X通訊（低延遲要求）                     │
│  · AR/VR即時渲染流傳輸                              │
└─────────────────────────────────────────────────────┘

關鍵指標

指標	典型值/範圍	備註
頭部大小	8位元組（固定）	TCP為20-60位元組
最大有效載荷	65,507位元組（理論）	實際受MTU限制，乙太網路通常1472位元組
埠範圍	0-65535	與TCP埠空間獨立
RoCE v2標準埠	4791	IBTA分配的UDP目標埠
校驗和覆蓋	偽首部+UDP頭+資料	IPv4可選，IPv6強制
典型資料中心UDP流量佔比	30-60%[估算]	在RDMA叢集中可能更高
UDP單跳轉發延遲	<1μs（現代交換器）	對比TCP核心棧處理可達數十μs

供需與市場資料

UDP本身是開放協議，無直接市場營收——但其承載的基礎設施有明確市場

細分市場	規模估算	增長驅動
RDMA網絡卡（RNIC）	2024年約$30-50億[行業估算]	AI訓練叢集爆發，每萬卡需數千RNIC
資料中心交換器	2024年約$150-200億[行業估算]	400G/800G升級週期，UDP/ECMP是標配功能
QUIC/HTTP3 CDN	快速滲透中	主流雲端廠商（Cloudflare、AWS CloudFront）已全面支援
邊緣AI閘道器	早期市場	車聯網、工業IoT的UDP傳輸需求

RDMA部署趨勢

RDMA在AI叢集中的滲透率（估算）：

2020:  ██░░░░░░░░ 20%  ← 主要InfiniBand
2022:  ████░░░░░░ 40%  ← RoCE v2開始放量
2024:  ███████░░░ 70%  ← 萬卡叢集標配
2026E: █████████░ 85%+ ← Ultra Ethernet演進
       （資料為定性估算，基於公開報道趨勢）

代表公司與資本對映

直接關聯（生產UDP/RDMA核心硬體）

公司	產品/角色	與UDP的關聯
NVIDIA (NVDA)	ConnectX-7/8 RNIC、Spectrum-4交換器	RoCE v2 網絡卡供給側處於領先位置；未鎖定可複核第三方份額口徑前，不寫具體市佔率或排名
Broadcom (AVGO)	Memory系列交換晶片	資料中心交換器晶片龍頭，UDP/ECMP是基礎功能
Intel (INTC)	E810網絡卡、IPU	支援UDP RSS/RDMA，爭奪第二供應商地位
AMD (AMD)	Pensando DPU	智慧網絡卡中的UDP/RDMA加速

間接受益（使用UDP系基礎設施）

公司	場景
Microsoft/AWS/Google	自建AI叢集大量部署RoCE v2
Meta (META)	PyTorch+NCCL+自建RDMA網路
Cloudflare (NET)	QUIC/HTTP3全球部署先驅

中國關聯

公司	角色
中際旭創	800G光模組，支撐400G/800G UDP/RDMA網路
盛科通訊	交換晶片國產替代探索
銳捷網路	資料中心交換器，支援RoCE v2

投資邏輯

核心架構：UDP是”賣鏟子的鏟子”

AI模型越大 → 需要越多GPU → 需要越快的卡間/節點間通訊
                              ↓
                    RDMA over Ethernet (RoCE v2)
                              ↓
                     ★ UDP 封裝層 ★
                              ↓
                    需要更快的網絡卡/交換器/光模組
                              ↓
                    NVIDIA/Broadcom/中際旭創等

關鍵投資邏輯點

萬卡叢集是確定性趨勢：從GPT-4（~25K GPU）到下一代可能50K-100K GPU，RDMA/UDP基礎設施需求線性增長
頻寬升級週期：資料中心網路正從400G→800G→1.6T演進，每次升級是光模組/交換器的換代機會
Ultra Ethernet Consortium：2023年成立，目標是乙太網路原生支援AI/HPC工作負載，可能帶來新協議層（但仍基於UDP/IP）
邊緣AI + 即時傳輸：自動駕駛、機器人等場景對低延遲UDP通訊的需求剛起步

風險因素

InfiniBand與Ethernet路線之爭可能反覆
矽光子/CPO等新技術改變光模組格局
中美科技博弈影響高階網絡卡/交換晶片供應

常見誤讀糾偏

誤讀1：「UDP不可靠，所以不適合AI/關鍵任務」

糾偏：UDP的”不可靠”是協議層的選擇，不是系統層的結論。現代AI叢集的可靠性由多層機制保障：

應用層：  架構級容錯（PyTorch checkpoint、DeepSpeed elastic）
傳輸層：  RDMA可靠語義 + DCQCN擁塞控制
鏈路層：  PFC流控 + ECN標記
物理層：  FEC前向糾錯

UDP的角色是提供最輕量的封裝，將可靠性決策權交給上層——這恰恰是正確設計，因為上層（如RDMA硬體）可以比通用TCP核心棧做得更好。

誤讀2：「UDP沒有擁塞控制，會把網路打爆」

糾偏：

標準UDP確實沒有內建擁塞控制（RFC 8085建議應用層自行實現）
但在AI叢集中，RoCE v2使用DCQCN（Data Center Quantized Congestion Notification） 實現了硬體級擁塞控制
QUIC協議內建了類似TCP的擁塞控制（如CUBIC/BBR）
“裸UDP”（無擁塞控制）主要存在於低速率場景（如DNS查詢、IoT遙測），不足以影響網路

誤讀3：「TCP比UDP更安全」

糾偏：

TCP的”面向連線”提供的是可靠性，不是安全性
傳輸層安全由TLS/DTLS提供，與選擇TCP或UDP無關
QUIC在UDP之上原生整合TLS 1.3，實際上比傳統TCP+TLS更早完成加密握手（0-RTT）

誤讀4：「InfiniBand和UDP是對立的」

糾偏：

InfiniBand原生確實使用自己的傳輸層（不經過UDP）
但RoCE v2（RDMA over Converged Ethernet v2）將InfiniBand的傳輸層語義封裝在UDP之上，使其能在標準乙太網路上執行
當前AI叢集的主流選擇正是”RDMA語義 + 乙太網路物理層 + UDP封裝”，兩者是協同而非對立

學習路徑

入門級（1-3天）

RFC 768原文：僅1.5頁，必讀，體會協議設計的極簡美學
《Computer Networking: A Top-Down Approach》Ch3：Kurose經典教材傳輸層章節
動手實驗：用netcat -u（nc -u）傳送UDP包，用Wireshark抓包觀察

進階級（1-2周）

RFC 8085（UDP使用指南）：理解何時該/不該用UDP
RoCE v2技術白皮書（NVIDIA/Mellanox釋出）：理解RDMA如何使用UDP
QUIC RFC 9000概覽：理解UDP如何承載複雜傳輸語義
實驗：用iperf3對比TCP/UDP吞吐量，用sockperf測量UDP延遲

專家級（持續）

DCQCN論文：“Congestion Control for Large-Scale RDMA Deployments”（SIGCOMM 2015）
NCCL原始碼：觀察集合通訊庫如何與UDP/RDMA層互動
Ultra Ethernet Consortium規範進展：追蹤下一代AI網路協議演進
核心原始碼：Linux net/ipv4/udp.c，理解UDP在核心中的實現

一句話總結

UDP是網際網路協議棧中”做最少、讓上層做最多”的哲學典範；在AI時代，它通過RoCE v2封裝成為萬卡叢集RDMA通訊的基石——不是因為UDP本身多強大，而是因為它足夠”空”，讓整個棧可以做最正確的分層決策。

延伸閱讀與來源

資源	型別	說明
RFC 768	原始規範	UDP定義，僅1.5頁，必讀
RFC 8085	使用指南	UDP使用最佳實踐
RoCE v2 Specification	行業規範	IBTA釋出，RDMA over UDP的定義
QUIC RFC 9000	新興協議	UDP承載的現代傳輸協議
DCQCN (SIGCOMM 2015)	學術論文	資料中心RDMA擁塞控制
NVIDIA RoCE Best Practices	廠商文件	RDMA/UDP部署指南
Ultra Ethernet Consortium	行業組織	AI乙太網路演進方向
《UNIX Network Programming Vol.1》	經典書籍	W.Richard Stevens著，UDP程式設計權威參考

本頁撰寫日期：2025年。協議規格基於IETF RFC；市場資料標註為[行業估算]的為綜合公開資訊的定性判斷，非精確定量資料。