游戏卡顿白皮书 › L5 数据中心网络设备
DDoS 防护引流/误判 DDoS scrubbing latency, false positives
原因 ID dc-ddos · 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
为防御攻击把流量牵引到清洗中心后，路径会变长，还可能把正常用户误判为攻击而拦截。
起因 检测到攻击后（或常态）把入向流量牵引到清洗中心 → 结果 路径变长，部分正常数据包被判为攻击 → 画面表现 整体 ping 升高，只有特定地区或运营商连不上
- 症状
- 操作延迟, 连不上/无限加载, 瞬移
- 因素
- 延迟, 丢包
- 谁会遇到
- 全服, 特定地区/运营商
- 何时出现
- 人多的时候, 偶尔随机
- 负责方
- 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
- 研发团队要做的事
- 整理游戏流量特征（端口、包大小、每秒包数）并提供给运维团队；UDP 包保持在 1,200 字节以内。
- 运维团队要做的事
- 按游戏流量特征定制防护规则；按地区部署清洗节点；在隧道段调小 TCP 包大小（MSS 调整）；通过各地区、运营商的连接失败率确认误判。
- 数值参考
- 清洗节点在同一国家时增加几 ms，经过其他国家的节点会增加 30~100 ms 以上。通常只有入向流量绕行，服务器的响应直接发出。清洗后的流量通过隧道回注时，一次能发送的大小（MTU）也会变小，可能引发只有大包丢失的问题。
- 监控图上
- 某一时刻起台阶式上升 · RTT（ping）、按地区/运营商的连接失败率
- 查看位置
- 把防护设备或服务的牵引（清洗）开始、结束记录和拦截日志，与 RTT 曲线、各地区/运营商的连接失败率放在同一时间轴上看。在出问题的地区用 mtr、traceroute 确认路径中是否夹入了清洗节点
- 确认依据
- 开启牵引的时刻 RTT 台阶式上升并保持，关闭后恢复。或者拦截日志里有正常玩家的地址，且只有该地区/运营商的连接失败率上升
- 排除依据
- 没有牵引、拦截记录的时刻 RTT 上升，看“路由绕行”或“BGP 路由变更/收敛”。只有大包丢失，看“MTU 不匹配（只有大包丢失）”
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- Maximum transmission unit and maximum segment size Cloudflare
入向流量清洗后经 GRE 隧道（MTU 1,476）转发，出向响应直接走互联网（DSR）；建议把 TCP MSS 限制在 1,436 以下，不调整则大包会被丢弃或分片 - Azure network round-trip latency statistics Microsoft Azure
不同节点位置的往返延迟量级：首尔–釜山地区 8 ms，首尔–东京 30 ms，首尔–新加坡 68 ms
相关原因
同一层：L5 数据中心网络设备
其他层中同样导致“操作延迟”的原因
查看含图示和实验的原卡片