TCP（Transmission Control Protocol）

3 秒看懂

TCP 是互联网最核心的传输层协议——提供可靠、有序、面向连接的字节流交付，是 Web、数据库、文件传输等一切需要”数据不丢不错不乱”场景的基座协议。在 AI 基础设施领域，TCP 正是 GPU 集群间通信需要”绕过”或”优化”的那道性能瓶颈。

3 分钟产业解释

TCP 在 AI 产业链中的位置

当大模型训练从单卡扩展到数千张 GPU 协同并行时，GPU 之间需要高频交换梯度、激活值等海量数据。这些通信发生在网络传输层，而 TCP 正是传输层的默认协议。

但问题是：TCP 为”通用互联网”设计，其核心设计假设（可靠交付、拥塞控制、内核协议栈处理）在 AI 集群内部环境中产生了严重的性能开销：

正因如此，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 的五大核心保障：

1. 面向连接（Connection-oriented）：通信前必须通过三次握手建立连接
2. 可靠交付（Reliable delivery）：通过序列号 + 确认应答 + 超时重传保证数据不丢失
3. 有序传输（Ordered delivery）：接收端根据序列号重组报文段，保证字节流顺序
4. 流量控制（Flow control）：接收端通过通告窗口（Advertised Window）告知发送端自己的接收能力
5. 拥塞控制（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 吞吐量上限估算（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 [行业估算]

技术演进史

技术路线对比

传输层方案在 AI 集群中的对比

⚠️ 延迟数字为行业常见估算范围，实际取决于具体硬件、拓扑、消息大小、网络负载等因素，非精确基准测试数据。

上下游

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 加速

关键指标

供需与市场数据

TCP 本身的市场——嵌入在操作系统中

TCP 不是一个独立的”产品”，而是操作系统内核的标准组件。全球每一台联网设备、每一台服务器都内含 TCP 协议栈实现。 因此 TCP 的”市场”几乎等同于全球网络设备/服务器/终端市场的规模。

TCP “被替代”带来的市场——AI 专用网络

TCP 在 AI 数据中心被 RDMA/RoCE 替代，催生了一个快速增长的专用网络市场：

关键数据点（需注意数据时效性）：

• InfiniBand Trade Association 数据显示 InfiniBand 在全球 Top 500 超算中占比超过一半 [需查阅最新 Top500 列表确认]
• AI 训练集群网络支出占整体集群成本的约 10-20% [行业估算，视集群规模和配置差异较大]
• NVIDIA 网络业务（含 InfiniBand + Spectrum Ethernet）已成为其重要收入板块 [基于 NVIDIA 财报，具体数字请查阅最新季度报告]

代表公司与资本映射

A 股/港股关联映射（AI 网络主题）：

• 光模块：中际旭创、新易盛、天孚通信等（物理层，与传输层相关但不直接对应 TCP）
• 交换机/网络设备：华为（非上市）、中兴通讯、锐捷网络
• 智能网卡/DPU：国内尚处早期，部分创业公司探索中

投资逻辑

为什么”理解 TCP”对投资 AI 产业链有价值？

逻辑链：

理解 TCP 的瓶颈
    ↓
理解为什么 AI 训练集群需要专用网络（而非通用 TCP/IP）
    ↓
理解 RDMA / InfiniBand / RoCE / DPU 的技术价值
    ↓
理解为什么 NVIDIA 收购 Mellanox（网络）是战略级决策
    ↓
识别 AI 网络基础设施的上游产业链观察点

核心投资命题：

1. AI 集群网络是”卖铲子”逻辑的延伸——算力不只靠 GPU，通信带宽和延迟决定了 GPU 集群的实际利用率
2. TCP 的局限性 = RDMA/DPU 的市场空间——越大规模的集群、越大的模型，TCP 的瓶颈越明显，专用网络方案的需求越刚性
3. “网络即瓶颈” 正在被量化——在万卡训练中，通信开销可占训练时间的 20-50%（视模型架构和并行策略而异 [行业估算]），这意味着网络性能每提升 1%，等效于节省数千万元的 GPU 算力成本
4. 长期看，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 集群需要的是”根本不要经过内核栈”——这是不同维度的问题。

学习路径

入门级

1. 理解网络分层模型（OSI 七层或 TCP/IP 四层）
2. 学习 TCP 三次握手、四次挥手的流程（画状态机图）
3. 了解序列号、确认号、窗口的作用
4. 推荐：《计算机网络：自顶向下方法》（Kurose & Ross）第 3 章

进阶级

5. 深入 TCP 拥塞控制（从 Tahoe → Reno → NewReno → CUBIC 的演进）
6. 学习 BBR 论文《BBR: Congestion-Based Congestion Control》（Cardwell et al., 2016）
7. 理解 SACK、窗口缩放、时间戳等 RFC 扩展
8. 推荐：RFC 793, RFC 5681 (Congestion Control), RFC 8312 (CUBIC)

专家级（AI 通信方向）

9. 理解 RDMA 原理：Send/Receive vs. RDMA Read/Write
10. 学习 RoCE v2 协议栈和无损以太网要求（PFC、ECN、DCQCN）
11. 对比 TCP vs. RDMA 在 AllReduce/AllGather 中的实际性能差异
12. 研究 NVIDIA NCCL 的通信后端选择逻辑
13. 了解 DPU/SmartNIC 对 TCP/RDMA 卸载的实现
14. 推荐：Dally et al., “Efficient Col