快照发送频率低 Low snapshot / update rate

原因 ID sy-low-send-rate · 主责 研发团队·服务器开发 · 配合研发团队·客户端开发

服务器每秒只发几次位置更新（快照）时，插值缓冲就得相应拉长，看到的其他角色也就是更久以前的状态。

起因为节省流量，位置更新每秒只发 5~10 次 → 结果要画得流畅，缓冲需设为包间隔的 2 倍（200~400 ms）；设得短，只要漏掉一个包就会卡住 → 画面表现 对手转向看起来很晚，与判定对不上。缓冲短时一卡一卡，丢包时瞬移

症状: 一卡一卡, 瞬移, 吞操作/回档
因素: 延迟, 丢包
谁会遇到: 全服
何时出现: 一直
负责方: 主责 研发团队·服务器开发 · 配合研发团队·客户端开发
研发团队要做的事: 服务器：近处或战斗中的目标多发，远处目标少发；只发变化的部分（增量压缩），减小单次数据量，提高发送频率。客户端：按包间隔自动调整插值缓冲长度。
数值参考: 每秒 10 次时包间隔 100 ms，缓冲 200 ms。再加上 ping 150 ms 的单向延迟 75 ms，看到的对手约是 0.3 秒前的状态。
监控图上: 一直偏高 · 各客户端的包到达间隔，插值缓冲长度
查看位置: 在服务器侧抓包，只过滤发往某个玩家的流，用 Wireshark 的 I/O Graphs 看每秒包数和间隔。有游戏侧日志时，一并看各实体的更新间隔和客户端插值缓冲余量（距离下一个快照到达还剩的时间）
确认依据: 位置更新一直很稀，每秒 5~10 次（间隔 100~200 ms），插值缓冲设得超过 200 ms，或缓冲余量经常降到 0
排除依据: 更新发得很密，只有到达间隔在波动，看抖动、丢包。人多时只有远处实体收得稀，看“按连接分配的发送预算/优先级”
确认手段: 运维工具即可确认（无需游戏代码）

出处

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
每秒更新 10 次时，插值 200 ms 能扛住一次丢失。Half-Life 默认每秒 20 次、插值 100 ms
Snapshot Interpolation Gaffer On Games
每秒 10 个包时，要扛住连续丢两个包需要 350 ms 延迟；每秒 30 个包时减少到 150 ms
State Synchronization Gaffer On Games
用优先级累积让重要实体发得更频繁，在带宽上限内轮流发送其余实体
8.8. The “I/O Graphs” Window Wireshark
把符合显示过滤器的包数、字节数按时间区间画成图