游戏卡顿白皮书 › 同步设计
过于严格的服务器校验 Over-strict server validation
原因 ID sy-strict-check · 主责 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
服务器对移动速度、冷却、射程检查得过于严格时，连因抖动扎堆到达的正常输入也会被拒绝。
起因 “一个 tick 内可移动的距离”“冷却容差 0 ms”这类严格标准 → 结果 因抖动，两条指令挤在同一个 tick 到达，被判为违规 → 画面表现 拉回，冷却好了技能却被拒绝
- 症状
- 拉回, 吞操作/回档
- 因素
- 抖动
- 谁会遇到
- 只有我
- 何时出现
- 偶尔随机, 移动中/切换地图时
- 负责方
- 主责 研发团队·服务器开发
- 研发团队要做的事
- 改用累积额度（令牌桶）方式检查，按 ping 和抖动留出余量。
- 监控图上
- 偶发随机尖峰 · 服务器校验拒绝、位置校正次数
- 查看位置
- 在服务器日志中为每次校验拒绝、位置校正记录原因、该玩家在那个 tick 到达的指令数、与上一条指令的到达间隔
- 确认依据
- 拒绝、校正集中在一个 tick 内挤进 2 条以上指令的时刻，而按几秒合计的移动量、使用次数都在规则之内
- 排除依据
- 按几秒合计仍超出规则，可能是真的超速或作弊。拒绝集中在特定运营商和晚间时段，看“集中在特定运营商玩家身上的校验误判”
- 确认手段
- 需要游戏服务器/客户端的日志和指标
出处
- Source SDK 2013: player.cpp Valve
用每个 tick 累积的指令处理预算（最多 sv_maxusrcmdprocessticks 24 tick）允许扎堆到达的指令。开发注释中提到，拦得更严时正常玩家也会一卡一卡 - RFC 2697: A Single Rate Three Color Marker IETF
令牌桶：按平均速率（CIR）和一次允许的突发量（CBS）判定
相关原因
同一层：同步设计
其他层中同样导致“拉回”的原因
查看含图示和实验的原卡片