V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MossFox
V2EX  ›  Nintendo Switch

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

  •  1
     
  •   MossFox · 2023-03-31 13:48:20 +08:00 · 1968 次点击
    这是一个创建于 613 天前的主题,其中的信息可能已经有所发展或是发生改变。

    概述

    昨晚和今天( 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)。

    UDP 丢包测试

    图片解释

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

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

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

    同一节点的 0 丢包

    另一组测试

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

    另一个“最优节点”的测试

    其他节点

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

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

    解决方案?

    等官方修吧。

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

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

    游戏截图

    第 1 条附言  ·  2023-04-29 16:38:54 +08:00

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

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

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

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

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

    MossFox
        1
    MossFox  
    OP
       2023-03-31 14:49:29 +08:00
    帖子末尾纠错:裸连丢包是 30%
    MeteorVIP
        2
    MeteorVIP  
       2023-04-01 00:04:48 +08:00 via iPhone
    看完了,我想测喷 3 。想测裸联和机场节点 ssr+那个延迟低,丢包少。这个工具要怎么用?
    MossFox
        3
    MossFox  
    OP
       2023-04-01 00:41:49 +08:00   ❤️ 1
    @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
        4
    MeteorVIP  
       2023-04-01 07:01:57 +08:00 via iPhone
    @MossFox #3 很详细,谢谢大佬。测试好后我会来反馈。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1096 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 22:37 · PVG 06:37 · LAX 14:37 · JFK 17:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.