TCP、UDP 与实时通信的延迟取舍

讨论实时通信时，经常会看到“TCP 可靠、UDP 快”的概括。前半句描述了 TCP 提供的重要能力，后半句却过于简单。应用实际延迟取决于网络路径、丢包、拥塞、消息设计与重传策略，不能只看协议名字。

字节流与数据报的区别

TCP 为应用提供可靠、有序的字节流。应用发送的数据会被传输层拆分、重传和重组，但接收方看到的是字节序列，不会自动保留每次发送调用对应的业务消息边界。因此，应用协议通常需要长度字段、分隔符或其他明确的组帧规则。

UDP 提供数据报服务，消息边界得以保留，但协议自身不保证交付、顺序或去重。发送一次不代表对端必然收到一次，应用需要处理丢失、重复和乱序。UDP 也不是“无限大的一条消息通道”：报文太大可能引发 IP 分片，降低在真实网络上的稳健性。

实时状态更在意新鲜度

假设一条消息描述角色 300 毫秒前的位置。在高速运动的游戏里，即使这条消息最终可靠到达，它也可能已经过时。TCP 的有序交付意味着后续字节可能需要等待缺失字节补齐，应用侧的读取会受这种顺序约束影响。

在某些状态同步设计中，应用宁愿接受下一份更新的位置，也不希望为旧状态长时间等待。基于 UDP 的设计可以给状态快照加上递增序号，丢弃过时更新，并用插值让显示更平滑。但角色位置、购买结果、背包变化等信息具有不同的业务要求，不应把所有消息都按同一种交付策略处理。

游戏同步需要哪些配套机制

• 序列号：区分新旧状态，识别重复或乱序报文。
• 时间与缓冲：根据实际网络波动安排插值缓冲，避免每个包一到就立即改变画面。
• 消息分类：对关键事件考虑确认、幂等和适当重传，对高频状态避免无限积压旧数据。
• 拥塞控制：限制发送速率并根据反馈调整，持续加大发送量可能让丢包和延迟一起增加。
• 可观测指标：记录往返时延、抖动、丢包和消息队列长度，而不只看平均带宽。

协议选择还受网络环境影响，例如 NAT、防火墙、平台 API 与服务端架构。开发者应在真实网络和目标设备上测试，覆盖弱网、短时断连以及高延迟场景。

QUIC 为什么基于 UDP 仍能可靠传输

QUIC 把可靠流、连接管理、拥塞控制和安全能力建立在 UDP 之上。UDP 是它承载报文的底层方式，并不意味着 QUIC 应用拿到的服务就是不可靠的。HTTP/3 运行于 QUIC，这也说明“HTTPS 必然使用 TCP”不是适用于所有现代 Web 连接的结论。

QUIC 的多个流可以减少一个流的丢包对其他流交付的直接阻塞，但同一可靠流内仍有顺序要求，连接还会受到共享拥塞控制和网络容量影响。选择传输方案时，应看应用最终获得的语义和实际测试结果。