TCP（Transmission Control Protocol）
3 秒看懂
TCP 是網際網路最核心的傳輸層協議——提供可靠、有序、面向連線的位元組流交付，是 Web、資料庫、檔案傳輸等一切需要”資料不丟不錯不亂”場景的基座協議。在 AI 基礎設施領域，TCP 正是 GPU 叢集間通訊需要”繞過”或”最佳化”的那道效能瓶頸。
3 分鐘產業解釋
TCP 在 AI 產業鏈中的位置
當大型模型訓練從單卡擴充套件到數千張 GPU 協同並行時，GPU 之間需要高頻交換梯度、啟用值等海量資料。這些通訊發生在網路傳輸層，而 TCP 正是傳輸層的預設協議。
但問題是：TCP 為”通用網際網路”設計，其核心設計假設（可靠交付、擁塞控制、核心協議棧處理）在 AI 叢集內部環境中產生了嚴重的效能開銷：
| 開銷來源 | 本質 | 對 AI 訓練的影響 |
|---|---|---|
| 核心態協議棧處理 | 每個包都經過核心 TCP 棧，涉及多次記憶體複製 | 增加微秒級延遲，降低吞吐 |
| 擁塞控制演算法 | TCP 為公平共享頻寬而設計，會主動降速 | 大型模型 AllReduce 通訊被節流 |
| 可靠性機制 | 重傳、確認、排序——在已部署無損乙太網路的叢集中冗餘 | CPU 開銷、尾延遲抖動 |
| 流控視窗 | 受接收端緩衝區限制 | 大訊息傳輸受限 |
正因如此，AI 資料中心正在大規模部署 RDMA（遠端直接記憶體訪問）+ RoCE v2（RDMA over Converged Ethernet）來替代 TCP，實現核心旁路（kernel bypass）和零複製傳輸。TCP 並沒有”死”，但在 AI 訓練的 HPC 通訊路徑上，它正被邊緣化。
關鍵投資認知：理解 TCP 的瓶頸 → 理解為什麼 AI 叢集需要專用網路方案 → 理解 InfiniBand / RoCE / 智慧網絡卡（DPU/SmartNIC）的市場邏輯。
15 分鐘專家深入
TCP 的核心機制概覽
TCP（Transmission Control Protocol）由 RFC 793（1981年9月）定義，最初由 Vint Cerf 和 Bob Kahn 在 1974 年提出的分組網互聯協議演化而來（早期 TCP/IP 未分層，後將 IP 層拆分）。它是 OSI 模型**第四層（傳輸層）**協議，與 UDP 並列為網際網路兩大傳輸層協議。
TCP 的五大核心保障：
- 面向連線（Connection-oriented）：通訊前必須通過三次握手建立連線
- 可靠交付（Reliable delivery）：通過序列號 + 確認應答 + 超時重傳保證資料不丟失
- 有序傳輸（Ordered delivery）：接收端根據序列號重組報文段，保證位元組流順序
- 流量控制（Flow control）：接收端通過通告視窗（Advertised Window）告知傳送端自己的接收能力
- 擁塞控制（Congestion control）：避免傳送端將網路”灌爆”，動態調整發送速率
AI 叢集語境下的核心矛盾
在一個典型的萬卡 AI 叢集中（如訓練 LLM），通訊模式主要是：
- 集合通訊（Collective Communication）：AllReduce、AllGather、ReduceScatter 等，涉及大量 GPU 同時交換資料
- 延遲敏感：同步並行訓練中，最慢的通訊決定了整體迭代速度（木桶效應）
- 流量突發性強：梯度同步時瞬間產生海量資料
TCP 在這種場景下的三個致命短板：
GPU ──→ [使用者態緩衝] ──→ [核心 TCP 協議棧] ──→ [網絡卡驅動] ──→ 網路
↑
多次記憶體複製
協議處理開銷
上下文切換而 RDMA/RoCE 的路徑：
GPU ──→ [RDMA 網絡卡直接讀寫遠端記憶體] ──→ 網路
↑
零複製、核心旁路、硬體級可靠性這解釋了為什麼 NVIDIA 的 InfiniBand 和 RoCE v2 + 智慧網絡卡 成為 AI 叢集網路的核心選擇，也解釋了為什麼 NVIDIA 以 69 億美元收購 Mellanox（2020年完成）。
技術原理
1. TCP 報文段結構
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |C|E|U|A|P|R|S|F| |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window |
| | |R|E|G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 最小頭部長度：20 位元組（無選項）
- 最大頭部長度：60 位元組（Data Offset 欄位 4 bit，單位為 32-bit word，最大值 15 × 4 = 60）
- 序列號（Sequence Number）：標識本報文段資料的第一個位元組在整個位元組流中的位置，初始序列號（ISN）在握手時隨機生成
- 確認號（Acknowledgment Number）：期望收到的下一個位元組的序列號
- 視窗欄位（Window）：16 bit，配合視窗縮放選項（RFC 1323，視窗縮放因子最大 14，即視窗最大約 2³⁰ ≈ 1 GB[基於 RFC 1323 規範]）
- 校驗和（Checksum）：覆蓋偽首部 + TCP 首部 + 資料
2. 三次握手（Three-Way Handshake）
Client Server
| |
|--- SYN (seq=x) ------------------>| [第一次握手]
| |
|<-- SYN-ACK (seq=y, ack=x+1) -----| [第二次握手]
| |
|--- ACK (seq=x+1, ack=y+1) ------>| [第三次握手]
| |
|======== 資料傳輸 ================|- 三次握手的核心目的是雙向確認雙方的收發能力並協商初始序列號
- SYN Flood 攻擊正是利用第一次握手後 Server 需維持半連線狀態的特性
3. 四次揮手（Connection Termination）
Client Server
|--- FIN (seq=u) ------------------>| [客戶端請求關閉]
|<-- ACK (ack=u+1) ----------------| [服務端確認]
| | (服務端可能還有資料要發)
|<-- FIN (seq=w) ------------------| [服務端請求關閉]
|--- ACK (ack=w+1) ---------------->| [客戶端確認]
| |
[TIME_WAIT 等待 2×MSL] |- TIME_WAIT 狀態持續 2 × MSL（Maximum Segment Lifetime），在 Linux 中 MSL 通常為 30 秒，TIME_WAIT 因此約 60 秒，目的是確保最後的 ACK 能到達以及舊連線的殘餘報文在網路中消散
4. 擁塞控制——TCP 效能的核心博弈
TCP 擁塞控制是幾十年來持續演進的領域，直接決定 TCP 的吞吐能力。主要演算法：
擁塞控制狀態機（經典 Reno/NewReno 概念模型）：
Slow Start
(指數增長)
│
│ cwnd ≥ ssthresh
▼
Congestion Avoidance
(線性增長, +1 MSS/RTT)
│
┌──────┴──────┐
│ │
3× DupACK Timeout
│ │
▼ ▼
Fast Recovery ssthresh = cwnd/2
ssthresh=cwnd/2 cwnd = 1 MSS
cwnd = ssthresh 回到 Slow Start
(NewReno: 繼續
Fast Recovery)主流擁塞控制演算法演進：
| 演算法 | 核心策略 | 特點 |
|---|---|---|
| TCP Tahoe（1988） | 慢啟動 + 擁塞避免 | 丟包後 cwnd 重置為 1 MSS |
| TCP Reno（1990） | 增加快速恢復 | 3 個 DupACK 觸發快恢復而非慢啟動 |
| TCP NewReno（RFC 3782, 2004） | 改進 Reno 的快速恢復 | 處理多個丟包場景更魯棒 |
| TCP CUBIC（RFC 8312, 2017 標準化） | 三次函式增長 | Linux 預設演算法（自 2.6.32 版本起作為預設選項）[具體預設版本基於 Linux 發行版確認] |
| BBR（Google, 2016） | 基於頻寬和 RTT 測量建模 | 不依賴丟包訊號，主動探測瓶頸頻寬 |
| BBRv2 | 改進 BBR 的公平性和丟包響應 | 仍在演進中 |
關鍵公式——TCP 吞吐量上限估算（Mathis 公式）：
Throughput ≤ (MSS / RTT) × C / √p
其中:
MSS = 最大報文段長度 (Maximum Segment Size)
RTT = 往返時延
C ≈ 1.22 (常數，基於 Reno/NewReno 的假設)
p = 丟包率⚠️ 注意：Mathis 公式是對 Reno/NewReno 系列的近似估算，CUBIC 和 BBR 的實際行為與此偏差較大。該公式說明：TCP 吞吐與 RTT 成反比，與 √(1/p) 成正比——高延遲或高丟包環境下 TCP 吞吐急劇下降。
5. TCP 與 AI 訓練網路的關鍵引數對比
TCP 核心棧路徑
┌──────────┐ ┌─────────────┐ ┌────────┐
│ 應用層 │───→│ 核心 TCP/IP │───→│ 網絡卡 │───→ 網路
│ (GPU) │ │ 協議棧 │ │ │
└──────────┘ └─────────────┘ └────────┘
↑ 多次 memcpy
↑ 軟中斷處理
↑ 協議狀態機
典型單向延遲: ~50-100 μs [行業估算]
RDMA/RoCE 路徑
┌──────────┐ ┌─────────────────────┐
│ 應用層 │───→│ RDMA 網絡卡 (硬體處理)│───→ 網路
│ (GPU) │ │ 零複製、核心旁路 │
└──────────┘ └─────────────────────┘
典型單向延遲: ~1-2 μs [行業估算]技術演進史
| 時間 | 里程碑 | 意義 |
|---|---|---|
| 1974 | Vint Cerf & Bob Kahn 發表《A Protocol for Packet Network Intercommunication》 | TCP/IP 原始論文 |
| 1981 | RFC 793 釋出 | TCP 協議正式規範（至今仍為基準文件） |
| 1983 | ARPANET 從 NCP 切換到 TCP/IP | TCP/IP 成為 ARPANET 標準 |
| 1988 | Van Jacobson 提出 TCP Tahoe | 首次引入擁塞控制機制 |
| 1990 | TCP Reno | 增加快速恢復 |
| 1992 | RFC 1323: TCP Extensions for High Performance | 視窗縮放、時間戳、PAWS——提升高頻寬高延遲鏈路效能 |
| 1993 | TCP Vegas（Brakmo & Peterson） | 基於 RTT 的擁塞控制思想，先驅性工作 |
| 1994 | SACK（選擇性確認）提案 | 僅重傳丟失段而非全部，後於 RFC 2018（1996） 標準化 |
| 1996 | TCP 大規模部署，網際網路爆發 | 成為全球通訊基礎設施 |
| 2004 | RFC 3782: TCP NewReno | 改進多丟包場景的快速恢復 |
| 2006 | InfiniBand 開始在 HPC 領域替代 TCP | 專用高效能通訊路線興起 |
| 2008 | Data Center TCP (DCTCP) 提出（Alizadeh et al.） | 利用 ECN 標記精細感知資料中心擁塞 |
| 2013 | MPTCP（Multipath TCP, RFC 6824） | 允許單連線多路徑傳輸 |
| 2016 | Google 釋出 BBR 擁塞控制演算法 | 基於模型的擁塞控制，突破丟包訊號的侷限 |
| 2017 | RFC 8312: TCP CUBIC 標準化 | 確認 Linux 長期預設演算法的地位 |
| 2018 | RDMA/RoCE v2 在 AI 訓練叢集中大規模應用 | TCP 在 AI 資料中心內被繞過 |
| 2020 | NVIDIA 收購 Mellanox（69 億美元） | 標誌著 AI 專用網路棧的戰略價值 |
| 2020s | DPU/智慧網絡卡興起 | 解除安裝 TCP/RDMA 處理到專用硬體 |
技術路線對比
傳輸層方案在 AI 叢集中的對比
| 維度 | TCP (核心棧) | TCP + DPDK (使用者態) | RoCE v2 (RDMA over Ethernet) | InfiniBand (RDMA 原生) |
|---|---|---|---|---|
| 典型單向延遲 | ~50-100 μs [行業估算] | ~10-30 μs [行業估算] | ~1-3 μs [行業估算] | ~0.6-1.5 μs [行業估算] |
| CPU 開銷 | 高（核心協議棧） | 中（使用者態輪詢） | 低（硬體解除安裝） | 極低（硬體解除安裝） |
| 可靠性機制 | 軟體（重傳/確認） | 軟體（使用者態實現） | 硬體解除安裝（基於 PSN 的按序交付，典型重傳為 Go-Back-N 或訊息級回退） | 硬體原生 |
| 擁塞控制 | 核心演算法（CUBIC/BBR等） | 使用者態演算法 | DCQCN / ECN | 自適應路由 + Credit-based |
| 網路要求 | 標準乙太網路 | 標準乙太網路 | 無損/低損乙太網路（PFC/ECN） | 專用 IB Fabric |
| 生態成熟度 | 極高 | 中等 | 高且快速增長 | 高（HPC/AI 標配） |
| AI 叢集適用性 | 低（內網訓練） | 中等 | 高 | 最高 |
| 成本 | 最低（純軟體） | 低（需 SmartNIC 支援） | 中（需支援 RoCE 的 NIC + 無損乙太網路交換器） | 高（需 IB HCA + IB 交換器） |
| 主要供應商 | 通用 | Intel DPDK 社群 | Broadcom / NVIDIA / Marvell | NVIDIA (Mellanox) |
⚠️ 延遲數字為行業常見估算範圍，實際取決於具體硬體、拓撲、訊息大小、網路負載等因素，非精確基準測試資料。
上下游
TCP 的”上游”——使能技術層
┌─────────────────────────────────────────────────────┐
│ 應用層協議 │
│ HTTP/HTTPS, gRPC, FTP, SMTP, SSH, 資料庫協議... │
├─────────────────────────────────────────────────────┤
│ ★ TCP / UDP（傳輸層） │
├─────────────────────────────────────────────────────┤
│ IP / IPv6（網路層） │
├─────────────────────────────────────────────────────┤
│ Ethernet / Wi-Fi / InfiniBand（資料鏈路層） │
├─────────────────────────────────────────────────────┤
│ 光纖 / 銅纜 / 無線通道（物理層） │
└─────────────────────────────────────────────────────┘上游使能要素：
- 作業系統核心：Linux 核心 TCP 棧是最廣泛部署的實現，Windows 核心棧次之
- 網絡卡硬體：支援 TCP Offload Engine（TOE）的網絡卡可解除安裝校驗和、分段等
- 擁塞控制演算法實現：作為核心模組（如 Linux 的 tcp_cubic.ko、tcp_bbr.ko）
TCP 的”下游”——TCP 支撐了什麼
- 幾乎所有網際網路應用：Web（HTTP/1.1、HTTP/2、HTTP/3 正在轉向 QUIC/UDP）、郵件、SSH、資料庫遠端訪問
- AI 訓練架構的通訊（正在被替代）：PyTorch Distributed、Horovod 等可基於 TCP Gloo 後端通訊
- 雲端服務 API 通訊：RESTful API、gRPC 底層通常基於 TCP
- 金融交易系統：對延遲敏感的場景正轉向專用協議/FPGA 加速
關鍵指標
| 指標 | 說明 | 參考範圍 |
|---|---|---|
| MSS（Maximum Segment Size） | TCP 資料段最大載荷 | 乙太網路典型 1460 位元組（1500 MTU - 20 IP 頭 - 20 TCP 頭） |
| 視窗大小 | 傳送端可傳送未確認資料量 | 未縮放時最大 65535 位元組；視窗縮放後可達約 1 GB[基於 RFC 1323] |
| RTT（Round-Trip Time） | 往返時延 | 資料中心內：< 1ms；跨城：< 10ms；跨洲：100-300ms [典型值] |
| BDP（Bandwidth-Delay Product） | 頻寬 × RTT = 管道容量 | 100Gbps × 1ms = 12.5 MB [計算值] |
| 初始視窗（IW） | 慢啟動初始視窗 | RFC 6928 推薦 IW=10 MSS（約 14.6 KB） |
| TIME_WAIT 持續時間 | 連線關閉後等待 | 2 × MSL，Linux 預設通常約 60 秒[基於 Linux 核心預設配置] |
| 連線建立延遲 | 三次握手完成 | 1 個 RTT（不含資料） |
| 擁塞控制 cwnd 起點 | 慢啟動視窗 | 初始 10 MSS（現代核心） |
供需與市場資料
TCP 本身的市場——嵌入在作業系統中
TCP 不是一個獨立的”產品”，而是作業系統核心的標準組件。全球每一臺聯網裝置、每一臺伺服器都內含 TCP 協議棧實現。 因此 TCP 的”市場”幾乎等同於全球網路裝置/伺服器/終端市場的規模。
TCP “被替代”帶來的市場——AI 專用網路
TCP 在 AI 資料中心被 RDMA/RoCE 替代，催生了一個快速增長的專用網路市場：
| 細分市場 | 代表產品 | 市場趨勢 |
|---|---|---|
| InfiniBand HCA（主機通道介面卡） | NVIDIA ConnectX 系列 | AI 叢集標配 |
| RoCE/智慧網絡卡（SmartNIC/DPU） | NVIDIA BlueField, Intel IPU, Broadcom | 快速增長 |
| InfiniBand 交換器 | NVIDIA Quantum 系列 | AI 叢集組網核心 |
| 無損乙太網路交換器（支援 PFC/ECN） | Arista, Cisco, H3C, 華為 | 資料中心升級需求 |
關鍵資料點（需注意資料時效性）：
- InfiniBand Trade Association 資料顯示 InfiniBand 在全球 Top 500 超算中佔比超過一半 [需查閱最新 Top500 列表確認]
- AI 訓練叢集網路支出佔整體叢集成本的約 10-20% [行業估算，視叢集規模和配置差異較大]
- NVIDIA 網路業務（含 InfiniBand + Spectrum Ethernet）已成為其重要營收板塊 [基於 NVIDIA 財報，具體數字請查閱最新季度報告]
代表公司與資本對映
| 角色 | 公司 | 與 TCP 的關係 |
|---|---|---|
| 作業系統 TCP 棧提供者 | Microsoft（Windows）、Red Hat/IBM（Linux）、Google（Android/Linux） | 核心 TCP 實現 |
| TCP 替代方案（InfiniBand） | NVIDIA（通過 Mellanox 收購） | IB HCA、IB 交換器的絕對龍頭 |
| TCP 替代方案（RoCE/SmartNIC） | NVIDIA（BlueField DPU）、Broadcom、Intel（IPU 系列） | 智慧網絡卡/DPU 市場競爭 |
| 無損乙太網路交換器 | Arista Networks、Cisco、華為、H3C | 支援 DCQCN/PFC 的資料中心交換器 |
| TCP 擁塞控制演算法 | Google（BBR）、學術界（DCTCP 等） | 演算法創新推動 TCP 效能演進 |
| 使用者態 TCP 棧/加速 | DPDK 社群（Linux Foundation）、F-stack 等 | 繞過核心的 TCP 效能最佳化 |
A 股/港股關聯對映（AI 網路主題）：
- 光模組：中際旭創、新易盛、天孚通訊等（物理層，與傳輸層相關但不直接對應 TCP）
- 交換器/網路裝置：華為（非上市）、中興通訊、銳捷網路
- 智慧網絡卡/DPU：國內尚處早期，部分創業公司探索中
投資邏輯
為什麼”理解 TCP”對投資 AI 產業鏈有價值？
邏輯鏈：
理解 TCP 的瓶頸
↓
理解為什麼 AI 訓練叢集需要專用網路（而非通用 TCP/IP）
↓
理解 RDMA / InfiniBand / RoCE / DPU 的技術價值
↓
理解為什麼 NVIDIA 收購 Mellanox（網路）是戰略級決策
↓
識別 AI 網路基礎設施的上游產業鏈觀察點核心投資命題：
- AI 叢集網路是”賣鏟子”邏輯的延伸——算力不只靠 GPU，通訊頻寬和延遲決定了 GPU 叢集的實際利用率
- TCP 的侷限性 = RDMA/DPU 的市場空間——越大規模的叢集、越大的模型，TCP 的瓶頸越明顯，專用網路方案的需求越剛性
- “網路即瓶頸” 正在被量化——在萬卡訓練中，通訊開銷可佔訓練時間的 20-50%（視模型架構和並行策略而異 [行業估算]），這意味著網路效能每提升 1%，等效於節省數千萬元的 GPU 算力成本
- 長期看，TCP 可能在資料中心內部進一步邊緣化，但 WAN（廣域網）和網際網路場景仍是 TCP 的天下——兩者並不矛盾
常見誤讀糾偏
❌ 誤讀 1：“TCP 已經被淘汰了 / 會被 UDP 取代”
✅ 糾正： TCP 在網際網路通訊中仍然是絕對主導協議。HTTP/1.1 和 HTTP/2 均基於 TCP。雖然 HTTP/3 轉向了基於 UDP 的 QUIC，但 QUIC 在應用層實現了類 TCP 的可靠性機制——本質上是把 TCP 的功能搬到了使用者態 UDP 上，而非否定可靠性交付的需求。 TCP 被”繞過”主要發生在資料中心內部的 HPC/AI 叢集通訊場景，而非通用網際網路。
❌ 誤讀 2：“AI 叢集完全不用 TCP”
✅ 糾正： AI 叢集中 控制面通訊、任務排程、引數伺服器後設資料交換 等仍然大量使用 TCP。被替代的是資料面的高吞吐低延遲通訊路徑（如梯度同步的 AllReduce）。叢集的管理面、儲存訪問（如 NFS、S3）、日誌傳輸等依然依賴 TCP/IP。
❌ 誤讀 3：“TCP 的效能問題是因為乙太網路不好”
✅ 糾正： TCP 的效能瓶頸主要在端側協議處理（核心棧開銷、記憶體複製、擁塞控制策略），而非乙太網路本身。乙太網路的物理層和鏈路層完全可以承載 RDMA 流量（RoCE v2 就是在乙太網路上跑 RDMA）。關鍵在於是否繞過 TCP 協議棧，而不在於底層是 Ethernet 還是 InfiniBand。
❌ 誤讀 4：“BBR 讓 TCP 的效能問題都解決了”
✅ 糾正： BBR 在 WAN 環境（尤其是有 bufferbloat 或隨機丟包的鏈路）表現優異，但在資料中心內部的 AI 訓練場景，BBR 仍受限於核心棧的固有開銷（記憶體複製、軟中斷、上下文切換）。擁塞控制演算法最佳化的是”何時發多少”，而 AI 叢集需要的是”根本不要經過核心棧”——這是不同維度的問題。
學習路徑
入門級
- 理解網路分層模型（OSI 七層或 TCP/IP 四層）
- 學習 TCP 三次握手、四次揮手的流程（畫狀態機圖）
- 瞭解序列號、確認號、視窗的作用
- 推薦：《計算機網路：自頂向下方法》（Kurose & Ross）第 3 章
進階級
- 深入 TCP 擁塞控制（從 Tahoe → Reno → NewReno → CUBIC 的演進）
- 學習 BBR 論文《BBR: Congestion-Based Congestion Control》（Cardwell et al., 2016）
- 理解 SACK、視窗縮放、時間戳等 RFC 擴充套件
- 推薦：RFC 793, RFC 5681 (Congestion Control), RFC 8312 (CUBIC)
專家級（AI 通訊方向）
- 理解 RDMA 原理：Send/Receive vs. RDMA Read/Write
- 學習 RoCE v2 協議棧和無損乙太網路要求（PFC、ECN、DCQCN）
- 對比 TCP vs. RDMA 在 AllReduce/AllGather 中的實際效能差異
- 研究 NVIDIA NCCL 的通訊後端選擇邏輯
- 瞭解 DPU/SmartNIC 對 TCP/RDMA 解除安裝的實現
- 推薦：Dally et al., “Efficient Col