UU 加速器（主机加速）的部分节点， UDP 包会在约三分钟之后回程全丢

[MossFox]

概述

昨晚和今天（ 2023-03-30 ~ 31 ）和日常一样想摸个鱼，上线打几把大乱斗练练手，但出现了平时所没有的卡顿和断连（发生连接错误）。 30 号晚上和 31 日上午 (尤其后者)，都有出现开一把 中途必掉线 的情况，很令人难过（主要是对于对手太不礼貌了，弄得像是打不过就拔网线一样）。中途掉线率几乎是 100%，不是所有节点都如此 (不过，三个“最优节点”似乎都有此问题，至少丢包卡顿是有的)。

注：丢包会造成卡顿的原因在于《任天堂明星大乱斗：特别版》的线上联机同步机制是 delay-based ，有一篇非常详细的文章，介绍了两种常见的格斗游戏线上模式的同步机制 (delay-based netcode and rollback netcode)，可以看这里：https://arstechnica.com/gaming/2019/10/explaining-how-fighting-games-use-delay-based-and-rollback-netcode/

网络环境：江苏南京电信，有线网。

症状复现

之前测试 UDP 代理转发的时候，整过一个发 UDP 包测试的脚本，就刚好借此来测试一下。测试脚本很简单：本地发出带序号的小 UDP 包到目标主机的高位端口，然后记录收到回应的时间间隔。超时丢包的包序号会被记录。

用来测试的脚本: Gist 链接 (写得很草率，别太较真)

这里 UU 加速器用的是路由器插件。选好加速节点之后，____ (防止服务被滥用，将主机加速的代理转移到电脑的过程略)。接下来在电脑端尝试测试连接稳定性。

下面是对于匹配的“最优节点”的发包测试结果。其中，第二轮测试使用的 15 ms 间隔是为了模拟真实游戏时的发包频率 (任天堂明星大乱斗特别版，P2P 联机，发包频率 1/60 s)。

图片解释

单看第一轮测试的丢包率，似乎还可以接受，没有出现集中丢包的情况。

但是，图中的第二轮测试在大约第三分钟时，出现了所有的回程包全部丢失的情况（服务端正常收到）。

这个现象在稍后又尝试测试了一下，没能复现，节点还是东京电信 6762 (服务端收到的 IP 与端口号: 103.140.240.179:23712)，倒是成就了梦寐以求的 0 丢包。但我的摸鱼时间已经没了啊（大悲）。

另一组测试

下图是另一组测试，测试时间是 2023-03-31 早晨 9:20 前后，是最早发现服务端可以正常收到包、回程包丢失现象的一次测试。这个测试中在回程包丢失之外，还有出现的就是较为严重的抖动。

其他节点

有一些高延迟节点，似乎没有出现这种故障。但，由于任天堂大乱斗使用的是 delay-based netcode ，网络延迟会直接反映到操作输入延迟上，游玩体验大大降低。

高延迟但是表现正常的节点

解决方案？

等官方修吧。

现在想打游戏的话，看样子得再开始之前甩个五分钟的 UDP 包看看。确定不掉线再去打线上。

裸连是不行的。国人玩家少，而且如果匹配到日本玩家，上面同样的目标 IP 的 UDP Ping 平均延迟在直连的情况下是 100 ms ，丢包 3%，你敢联机玩吗。

这个问题疑似只在路由器插件上出现过。没有做完全的测试，但目前已观察的现象大概是这样：

• 路由器插件显示的节点列表与 PC 端主机加速器的节点列表不同（因此无法使用相同节点来做对比测试）；
• PC 端主机加速器暂时没有发现过这种问题（测试时间跨度并不长）；
• 此问题每次出现，均是集中在路由器插件的某些节点（非全部节点）。

考虑到路由器用的是老毛子固件、UU 插件是 openwrt 的脚本改了网络接口名称硬给装上去的，是否有未知的兼容性问题也没测试过。但毕竟正常使用有相当长的时间，此问题截至此附言发布，只出现过两次。

依然无法确定到底哪里出了问题。由于暂时没有太多多余的时间摸鱼打游戏，暂且也就不去测试了。

最终的建议是，使用路由器插件的话，路由器使用官方支持的型号比较靠谱。另外一个选择就是局域网内用 PC 端端主机加速器，因为看上去它是会全面测试可用节点延迟的，而且不会受到路由器固件和硬件性能影响而产生未知的问题。

[MossFox]

帖子末尾纠错：裸连丢包是 30%

[MeteorVIP]

看完了，我想测喷 3 。想测裸联和机场节点 ssr+那个延迟低，丢包少。这个工具要怎么用？

[MossFox]

@MeteorVIP
啊这个，脚本本身是随手写的一个发 UDP 包的工具，会需要一个有运行此脚本的服务端。首先要确保是 NAT A 才可以，否则的话联机还是不行的。

我自己有一个挂着的服务端，如果不会崩掉的话，可以直接用稍后下面写的命令测一下。电脑需要安装有 Node.js ，然后，测试服务器是日本 Vultr 。

准备步骤大概就是对电脑端启用透明代理：
- 因为 Node.js 脚本不会走系统代理，所以要像配置 Switch 加速一样，让代理服务接管电脑这边的全局路由，方法大概就两种：
> 路由器透明代理（需要也代理 UDP 流量），这个最直接；
> 对于需要配置客户端 IP 、网关和掩码的那种 加速器服务，可以局域网内 **另一台电脑** 开启主机加速器、然后本机按照加速器提示完成网络配置，相当于将用于 Switch 的网络环境配置给电脑，以便稍后测试。如果要将已有的 Socks5 转为透明代理，可以参考这个文章： https://zankyo.cc/3389/ ，大概适用于一些启用 UDP 的机场。（不过，SS 协议似乎会因为流量加密解密运算导致带来额外的延迟，据那个文章评论描述，似乎不是很适合用于游戏联机加速）

然后拿这个脚本来简单测一下：
- 电脑端可以试一下 DNS 查询正不正常，以测试 UDP 包能不能正常发出去。然后，对于上面 Gist 的那个脚本，随便存到一个文件夹，在当前目录打开命令行：

node ./udp_ping_pong.mjs --client 202.182.99.158:8999 -i 15

202.182.99.158:8999 是我的测试服务器，不一定稳定，但短期内应该不至于炸掉。

-i 指定的是发包间隔 (ms)，15 ms 约等于游戏内一帧 (1 / 60 s)，Splatoon 不确定发包间隔是不是这么短，不过大乱斗那种是确实一帧一个包的。不指定的话，默认是 100 ms 。


如果要在自己的服务器上运行一个服务端，假设要监听的端口是 8999：

node ./udp_ping_pong.mjs --server --port 8999

服务端收到包会打印输出来源 IP 和端口。


对于测试的 UU 加速器，好像是会把日本 IP 直接全端口代理，我看 SSH 都给我代理过去了。延迟变化的话，是 100 ms -> 34 ms ，很给力。目前的话看样子是修好了，但因为整过这么一出，以后打游戏之前可能还是得测一遍丢包情况才敢玩线上。

[MeteorVIP]

@MossFox #3 很详细，谢谢大佬。测试好后我会来反馈。