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

阻塞 I/O 模型 Blocking I/O model

原因 ID sk-blocking-io · 主责 研发团队·服务器开发

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

等一个 socket 时线程就干不了别的事，这种结构下人越多，整体就越慢。

起因 每个连接都要等待读写的方式 → 结果 一个连接的延迟蔓延到同一线程的其他连接 → 画面表现 同时在线人数越多，整体越慢，表现为慢动作、操作延迟

症状

慢动作, 操作延迟

因素

停顿

谁会遇到

全服

何时出现

人多的时候, 晚高峰

负责方

主责 研发团队·服务器开发

研发团队要做的事

改为基于 epoll、IOCP、io_uring 的异步 I/O。

监控图上

随人数/负载上升 · 响应时间、线程数

查看位置

用 pidstat -w -t 看游戏服务器的线程数和各线程的自愿上下文切换（cswch/s，等待资源而停住的次数），与随同时在线人数变化的响应时间对比

确认依据

同时在线人数越多，响应时间上升越陡；线程数随连接数一起增加，其中大多数只有自愿切换多、几乎不用 CPU（在等 socket）

排除依据

线程一直在用 CPU、没有等待，是计算过载（“Tick 超出预算”）

确认手段

运维工具即可确认（无需游戏代码）

出处

1. epoll(7) — Linux manual page Linux man-pages
   能扩展到同时监视大量 fd 的 I/O 事件通知机制
2. I/O Completion Ports Microsoft
   用预先创建的线程池处理大量异步 I/O 的 Windows 方式
3. pidstat(1) — Linux manual page sysstat
   -w 的 cswch/s：等待资源时主动停住的自愿上下文切换；-t 按线程显示

相关原因

同一层：L8 Socket 与协议

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

其他层中同样导致“慢动作”的原因

• 固定时间步长追赶失控 L1 客户端游戏进程
• 负载均衡倾斜/健康检查误判 L5 数据中心网络设备
• 线程过多与上下文切换 L7 服务器操作系统（内核）
• 容器 CPU 限流（CFS 配额） L7 服务器操作系统（内核）
• 服务器电源管理（C-state/调频）导致延迟跳变 L7 服务器操作系统（内核）
• 定时任务 L7 服务器操作系统（内核）
• OS/内核/驱动/固件更新后的性能变化 L7 服务器操作系统（内核）
• Tick 超出预算 L9 服务器游戏进程

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