游戏卡顿白皮书 › L8 Socket 与协议

可靠 UDP 重传配置 Reliable-UDP tuning (KCP, ENet…)

原因 ID sk-reliable-udp · 主责 研发团队·服务器开发 · 配合 研发团队·客户端开发

在含图示和实验的完整版中打开此卡片 →

在 UDP 之上自己实现的重传规则太保守，恢复就慢；太激进，又会让线路更堵。

起因 重传间隔、次数、窗口大小的设置与线路不匹配 → 结果 恢复迟缓，或重复发送加剧拥塞 → 画面表现 吞技能、快进，拥塞时卡顿更严重

症状

吞操作/回档, 快进

因素

丢包, 延迟

谁会遇到

只有我

何时出现

偶尔随机

负责方

主责 研发团队·服务器开发 · 配合 研发团队·客户端开发

研发团队要做的事

服务器：按实测往返时间重传；按重要程度分通道。客户端：采用与服务器相同的重传、通道设置。

监控图上

偶发随机尖峰 · 可靠 UDP 重传比例、游戏内 RTT

查看位置

在服务器和客户端记录所用库为每个连接维护的统计（重传次数、估算往返时间、重传等待时间），并与同一玩家的实际线路丢包率（用 mtr 测得的值）对比

确认依据

重传比例比实际线路丢包率高出好几倍，是设置太激进；重传等待时间是实测往返时间的好几倍，是设置太保守

排除依据

重传比例与线路丢包率相近、等待时间与往返时间相符，就不是设置问题。看线路丢包本身

确认手段

需要游戏服务器/客户端的日志和指标

出处

1. RFC 8085: UDP Usage Guidelines IETF
   重传可能加剧拥塞，因此要纳入拥塞控制；往返时间用多次测量的平均值（EWMA）估算；初始 1 秒；定时器超时时降低发送速率

相关原因

同一层：L8 Socket 与协议

• TCP 队头阻塞
• TCP RTO 与指数退避
• Nagle 算法 + 延迟 ACK
• 慢客户端导致的阻塞发送
• 慢客户端（slow consumer）处理策略
• keepalive 默认 2 小时
• UDP 数据包的 IP 分片
• 空闲后的慢启动
• 拥塞控制导致发送量骤降
• RST 强制关闭导致最后的数据丢失
• 阻塞 I/O 模型
• SO_REUSEPORT 分配不均
• Windows UDP socket 的 WSAECONNRESET 错误

其他层中同样导致“吞操作/回档”的原因

• 时钟同步误差 L1 客户端游戏进程
• 云 NAT 网关连接/端口上限 L5 数据中心网络设备
• 交换机微突发 L5 数据中心网络设备
• 环形缓冲区不足 L6 服务器网卡
• 超出云 PPS 上限 L6 服务器网卡
• OOM Killer L7 服务器操作系统（内核）
• 系统时钟跳变（NTP step） L7 服务器操作系统（内核）
• 服务器间连接的临时端口耗尽 L7 服务器操作系统（内核）

查看含图示和实验的原卡片