UDP与TCP对游戏有什么影响？为什么竞技游戏几乎全部基于UDP通信？

引言：两大底层协议的本质差异

在互联网的世界里，数据包在传输层主要依赖两种协议运送：

1. TCP（Transmission Control Protocol，传输控制协议）： 面向连接、保证可靠交付、保证顺序不变的“精密快递”；
2. UDP（User Datagram Protocol，用户数据报协议）： 无连接、不可靠、尽力而为交付的“飞鸽传书”。

直觉上，网络游戏作为严密交互的程序，似乎更应该选择“绝不丢数据、绝对可靠”的 TCP。然而残酷的工程实践告诉我们：绝大多数对实时性有要求的游戏（射击、MOBA、格斗、赛车），其核心战斗网络同步 100% 运行在 UDP 之上！

为什么？因为 TCP 的“可靠”，在游戏中恰恰是导致致命卡顿的罪魁祸首。

核心机理：TCP 为什么不适合竞技游戏？

1. 致命的“队头阻塞”（Head-of-Line Blocking）

TCP 保证接收端收到的数据流必须与发送端顺序完全一致。

• 假设在 100 毫秒内，你的游戏向服务器发送了 5 个角色移动位置包： [包1: (10, 20)] ➔ [包2: (10, 21)] ➔ [包3: (10, 22)] ➔ [包4: (10, 23)] ➔ [包5: (10, 24)]
• 如果由于微小网络波动，包2 在中途丢失了：
  • 在 TCP 协议栈 下，哪怕 包3、包4、包5 都已经安全到达服务器内存，操作系统内核也绝对不允许把它们交给游戏进程！操作系统必须挂起后续所有数据，等待向客户端请求重传 包2；
  • 客户端收到 ACK 缺失 ➔ 触发超时重传 ➔ 重新发出 包2 ➔ 服务器确认收到 包2 ➔ 此时才把积压的 包3/4/5 一口气打包提交给游戏！
• 玩家屏幕上的体感： 整个画面卡住停滞 200 毫秒，然后所有画面突然像快进一样飞速抽搐。
• 但对于游戏来说： 包2（0.2 秒前你的旧坐标）早就没有意义了！游戏只需要知道你最新在 包5 的位置即可。为了一个已经过期的历史垃圾数据，挂起所有最新的实时状态，这是不可接受的。

2. 三次握手与慢启动（Slow Start）的额外开销

• TCP 在传输数据前必须经历经典的 SYN ➔ SYN-ACK ➔ ACK 往返握手，这直接增加了初始时延；
• TCP 内置拥塞控制算法。一旦检测到轻微丢包，TCP 会立刻将拥塞窗口（CWND）砍半，并进入“慢启动 / 拥塞避免”状态，主动降低发包速率。然而游戏产生的数据量本来就极小，却被限流机制人为拖慢。

UDP 的优势：轻装上阵与极限低时延

UDP 的头部开销仅有区区 8 字节（TCP 则需要 20-60 字节），没有连接状态、不维护序列号同步、不强制重传：

1. 尽力而为（Best-effort）： 数据生成瞬间直接扔进网卡封包发出；
2. 新数据覆盖旧数据： 如果上一个坐标包丢了，游戏引擎根本不在乎，因为下一个毫秒的新坐标包已经在路上。只要下一个包到了，画面就能平滑过渡；
3. 零队头阻塞： 永远只处理最新到达的有效数据，延迟保持在物理最低极限。

现代游戏如何兼顾可靠性？—— 可靠 UDP（R-UDP / Custom UDP）

游戏里难道所有数据都能丢吗？当然不是！

• 移动位置、视角旋转： 频繁高刷，丢了无所谓 ➔ 使用 纯不可靠 UDP 通道；
• 玩家开火、拾取物品、聊天文字、购买装备： 绝对不能丢 ➔ 使用 上层应用自实现的可靠 UDP（Reliable UDP）。

像 Valve 的 Source 引擎网络库、Epic 的 Unreal Engine Replication、Photon、ENet 以及新一代 QUIC 协议：

• 底层依然是 UDP 端口；
• 由游戏引擎自身在应用层决定：哪些数据包需要携带自定义的 ACK 机制？哪些数据包需要超时重发？
• 当发生丢包时，引擎只针对该关键事件进行轻量补发，而绝对不会阻塞周围其他实时坐标位置的正常流转！

对玩家本地环境与排障的启示

理解了 TCP 与 UDP 的区别，玩家在排查游戏网络时就能少走很多弯路：

1. 网页打得开，不代表游戏能联机： 网页使用的是 TCP 80/443 端口，家庭路由器或防火墙通常对 TCP 敞开；但如果路由器对 UDP 碎片过滤过激，或者某些老旧小运营商对 UDP 协议进行了恶意限速/封锁，就会出现“浏览网页飞快，一进游戏就掉线”的典型症状。
2. 加速器的本质： 游戏加速器在玩家电脑上通过虚拟网卡接管游戏发出的 UDP 数据流，将其通过自建的稳定专线隧道打包传输，彻底规避公网路由器对散乱 UDP 小包的随机丢弃。