斯普拉遁3打工模式联机网络过程分析
引入 今天打工，又被掉线的队友气到了。正好之前根据Nintendo Clients写了一个Wireshark的P2P协议解析插件，又抓过一些打工的网络数据，大概将打工模式的网络交互做了记录，可以做一些简单的分析。 整个打工的交互过程都是通过任天堂的SSL证书，和任天堂服务器分发的密钥进行加密的。想要拿到、或者修改具体在联机中传输了什么样的内容，必须破解Switch以绕过证书的验证，而这就违反了使用协议，会被封禁。我们在本文中使用的工具和方法，仅仅从公开内容出发，不涉及对Switch本身的破解。 这篇文章也是基于本人就网络流量观察的猜测，与任天堂没有任何关联，也不对其中的正确性做任何保证。读完这篇文章，你只能大概知道为什么你的队友/你会掉线，既不能解决队友/你掉线的问题，也不能让你上传说。 我们就游戏的几个阶段进行描述。 匹配 任天堂在本代采用了和怪物猎人相同的新一代NPLN服务器架构。据说是引入了微服务的概念，在各种效果上都有所提升。但很遗憾，除了一些少见的情形外，这对打工几乎没有任何帮助。 打洞与NAT类型检测 目前的网络基础架构使得设备往往都隐藏在路由器的NAT背后。在进行P2P联机之前，需要进行NAT打洞。 一个关于NAT打洞的比喻是，你告诉路由器，我现在去一个住东川路800号（IP地址）202室（端口号）的客人家里串门，他一会儿也来，帮我留个门。路由器里面的NAT表就是看门人，有的NAT啥也不管，有的NAT只放住东川路800号的人进来，有的NAT不仅要检查是不是住东川路800号，还要看房间号是不是202室才让进来。 A，B，C类型的网络，就对应了这三种看门人。两个人要联机，实际上是一个双向的交互过程。比如说，A要和C互相串门，作为中间人的任天堂只需要告诉C A住在哪一号哪一室，C去A那里串门之后，C家里的看门人就会给A留门。读者可以自己想一想A，B，C网络之间哪些可以互联，哪些不能互联。如果感兴趣的读者，可以进一步阅读NAT 类型。 网络活动 游戏向nncs[1,2]-lp1.n.n.srv.nintendo.net所指向的几个服务器发三次三个内容分别为e,f或g的UDP包。服务器会返回9个包，但收得到几个取决于你的网络。包中记录了： 这是在测试哪种类型的连接 你的IP地址和端口号是什么 例如我是B类网络，只收回了6个包。 向游戏服务器发送你收到的IP地址和端口号，通知你准备参加打工了。 在匹配过程中，服务器会推送你的队友的IP地址和端口号信息。此时取决于你的网络，会使用Pia v11协议，发送目标变量ID、源变量ID、包ID均为0的一个握手包。这一过程也进行NAT打洞。 当收到这样的握手包之后，会回复一个只写入源变量ID，其他均为0的一个握手确认包。源变量ID和目标变量ID为随机变量，可能是匹配系统分配的编号。这个编号在一次匹配（就是排到的一组队友，包含“以相同队伍继续”的游戏）中是不变的，但在不同的匹配中不同。 当收到握手确认包之后，意味着握手方到被握手方建立了一个单向的连接。此后就会开始交换加密的游戏信息，表现为目标变量ID和源变量ID对应握手方和被握手方的变量ID，包ID从一个随机数递增。 如果没有收到握手确认，游戏会通知服务器无法连接到对方，此时可能匹配系统会重新匹配其他玩家，并告知对方无法匹配，不再发出对应的包。循环这一步骤，直到都能够互相连接。 这是一个传输过程的例子： 注意图中标为橙黄色，我与波兰IP的玩家联机的三个包。这就是一个握手，握手确认，开始传输加密信息的流程。黑底的三个ICMP包，则表明我的上级路由告诉我，无法连接到俄罗斯玩家，因此通知服务器，也不再向俄罗斯玩家发包了。 有一种情况，双方有一方无法连接到另一方，但运气好（我猜是你俩排位的契合程度，减去可能的延迟，再减去不能连接的扣分项，还是比重新找一个队友的代价高），任天堂会提供TURN协议的中转服务器。TURN协议原封不动地包装了待发送的Pia协议包，由任天堂的服务器提供中转，转发给对方。 TURN协议对于接收的一端是透明的。具体通讯模式可以参考下图。游戏仅会对一对用户某一个方向建立信道，数据在信道中是单向的。 注意下图中TURN包的的数据部分，以幻数32 ab 98 64开始，表明这是一个Pia协议包，也就是任天堂P2P协议包。 当所有队友均准备好之后，便会显示“打工的时间到了”，这时会与游戏服务器进行通信，开始本局打工。 常见问题 这一步常出现的问题，大多是报错。有两种报错形式：游戏界面内的黑色错误框，和游戏模糊化作为背景，Switch系统的错误框。以下记为游戏框和系统框。 游戏框说发生连接错误。 这一步通常不是我方出现的P2P的网络错误。这种情况我猜测是任天堂服务器推送给你的，比如一个队友和另一个队友之间连不上了，但他们都能连上你，你得重新匹配。 系统框说无法连接到服务器/连接错误。 这种情况通常是与你和任天堂的服务器间的连接相关，比如你的连接不稳定，或者任天堂的服务器欠修了。 游戏框说“连接已中断”，一共四行（即封面图）。 这种情况有可能是上面两种的集合。与上述游戏框的区别是系统框的无法连接错误可能通常发生在收到TCP（即你与服务器的连接）错误包、重复包上，而游戏框通常发生在连接断开上。 系统框说无法与对方的游戏机进行连接。 这种情况通常是偶发的，发生于你与队友的UDP连接故障。比如网络不稳定导致的UDP传输发生了多次错误。如果频繁出现，可能需要注意路由器或者加速器的质量，或许存在错误判断NAT类型的情况。 游戏框说未在规定时间内凑齐人数。 这种情况如果频繁出现，需要先检查你的NAT类型。上文介绍了NAT类型，类型越差排到的人就越少。如果NAT类型很好，但仍然很难匹配到人的话，可能需要注意加速器质量，或者你的网络服务提供商是否存在连接阻断的情形。 如果有任意一个队友与任天堂服务器间的网络连接较差，就会出现卡在“打工的时间到了”的界面。如果该队友此时与任天堂服务器断开连接，可能出现“发生连接错误”的游戏框，也有可能在直升机上蒸发。 游戏过程 网络活动 与服务器通信 在整个打工的过程中，只有少数的动作会与游戏服务器通信。因为我无法得到具体的通信内容，这一步可能包括： 投蛋进框 击杀、生成巨大鲑鱼 自己阵亡、复活队友 玩家间通信 其他的所有内容都是仅通过P2P通信完成的。每对玩家间的通信通过一来一回2个Pia协议的单向“通道”（表现为递增的包编号）进行，丢包不会重传。每秒钟向每个队友发送约15个包（和游戏的Tick Rate差不多），每个包的大小在约100B到约700B不等，结算时包的大小可能达到1KB。 P2P通信中分为普通事件和关键事件。移动、涂地等行为是普通事件，只要收到玩家发来的信息（比如移动），就会在游戏中发生。而成为游泳圈、复活、捡蛋是关键信息，只要整个游戏有一个人在关键事件上没有同步，就都认为关键事件未发生。 我根据游戏的掉线行为和向不同人发送的包的大小差别猜测，整局游戏中会按一定规则选取玩家作为同步基准（接下来称为房主），网络较好的玩家可能更容易被选为房主。 图中标为橙黄色的为一个通道，可以注意到包编号是递增的。另外也可以观察到，与一个人交换的数据普遍比其他玩家大，可能是负责同步的房主。图中粉色的条目则为与游戏服务器的通信。 掉线情况的处理有多种。 上述的通道总共有12条。如果某一个通道无法工作，游戏会试图挽救，向NPLN服务器请求建立一个中继（当然也可能直接少人）。需要注意的是，中继是单通道的。比如我收不到一个队友的包，我只会请求服务器中转队友到我方向上的包，同时NPLN服务器会通知这个队友，向我发送的包通过任天堂进行中转。 如果非房主玩家与任天堂服务器断开了连接，该玩家会显示“发生连接错误”的游戏内错误框，游戏服务器会通知所有玩家该玩家掉线了。 如果房主无法连接到某玩家，可能出现即使与任天堂的连接没有断开，也会导致该玩家被游戏服务器踢掉。 如果房主掉线，个人认为可能任天堂没有写重新选房主的代码，因此会结束所有人的游戏，对所有人弹出“发生连接错误”的游戏内错误框。 常见问题 蛋丢不进框：任天堂的服务器欠修了。这一点最近很少见。 队友傻站着，死了不复活：可能是你与该队友的连接出现了问题，但系统仍然在尝试通过TURN转发机制重连。通常运气不好的话，不超过10秒这个队友（或者你）就会掉线。 蛋捡不起来、蛋被队友抢走、队友见死不救：除了第三个可能跟队友的水平有关，产生的原因最有可能是你与房主玩家的延迟比较高。如果某局游戏一开始捡蛋顺畅，但突然开始捡蛋变卡，可能是房主的连接（或者你的连接）出现了重大变动，比如中间链路发生换路，你得准备好掉线了。 结算的时候发生连接错误：结算是由房主上传到任天堂服务器，再由任天堂服务器下载到你的设备上的。当房主上传完毕后，结算就已经记录了。因此如果查看历史，没有正确结束，说明房主掉线；如果有正常的结算，说明你与任天堂的服务器连接不稳定。