游戏卡顿白皮书 › L4 公网链路
经由 VPN/游戏加速器 VPN / game accelerator detour
原因 ID isp-vpn · 主责 外部·外部 · 配合 运维团队·网络运维, 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
开启 VPN 或游戏加速器后，数据包会经过该公司的中转服务器。中转服务器远或拥挤时，反而会变慢。
起因 VPN、加速器把游戏数据包全部转到中转服务器 → 结果 叠加了到中转服务器的距离和拥塞；隧道报头还让 MTU（一次能发送的最大包长）变小 → 画面表现 ping 升高并丢包；与使用同一中转地址的人一起被封，连不上
- 症状
- 操作延迟, 瞬移, 连不上/无限加载
- 因素
- 延迟, 丢包
- 谁会遇到
- 只有我
- 何时出现
- 一直, 刚登录/维护结束后
- 负责方
- 主责 外部·外部 · 配合 运维团队·网络运维, 研发团队·服务器开发
- 研发团队要做的事
- UDP 包保持在 1,200 字节以内（隧道报头让 MTU 变小时也不会分片）；按 IP 封禁时要考虑 VPN、加速器的公共中转地址，结合账号、设备维度判断。
- 运维团队要做的事
- 海外玩家多的地区，自建就近的接入节点；“开了加速器就好了”这类反馈集中的运营商，要检查路由。
- 外部要做的事
- 引导玩家关掉 VPN、加速器对比一下。
- 数值参考
- 中转服务器近，只增加几 ms；绕经其他国家，会增加几十到 100 ms 以上。
- 监控图上
- 仅部分偏高 · RTT（按玩家）、接入 IP 所属服务商
- 查看位置
- 查接入 IP 的 ASN 是否属于 VPN、加速器或托管服务商，并让玩家关掉 VPN、加速器后对比 ping 和 traceroute
- 确认依据
- 只有开着 VPN、加速器时 RTT 和丢包增加或连接被拦，traceroute 里能看到经过中转服务器的一跳
- 排除依据
- 关和开都一样，是线路或运营商段的问题。开了反而更好，是原本的运营商路由（“路由绕行”“高峰时段对等互联链路拥塞”）有问题
- 确认手段
- 需在玩家侧环境确认
- 深入了解
- 反过来，运营商路由差的时候，加速器走更好的路径，ping 反而会降低。“开了加速器就好了”这类反馈，是路由绕行、晚间拥塞这类运营商路由问题的线索。
出处
- RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling IETF
网络中途的隧道封装报头让可发送的大小变小，由此引起的分片和路径 MTU 问题 - RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
建议以 1,200 字节作为 UDP 等数据报传输的基础安全大小（BASE_PLPMTU） - Azure network round-trip latency statistics Microsoft Azure
经过其他国家的节点时增加的往返延迟量级：首尔–东京 30 ms，首尔–香港 39 ms，首尔–新加坡 68 ms
相关原因
同一层：L4 公网链路
其他层中同样导致“操作延迟”的原因
查看含图示和实验的原卡片