Waiting for Server 背后的真相

随着 TeaCon 2020 落下帷幕,奖项颁发结果也已公布。其中,模因污染奖项的结果格外引人注目——模因污染奖的第 0 名颁发给了 McJty 的 TOP(The One Probe) 模组,因为其 Waiting for Server 直观地体现了 TeaCon 服务器的几次卡顿。然而,服务器卡顿究竟是何物?

何为卡顿

帧数低不是服务器卡顿

客户端渲染的帧数与运行客户端电脑的性能有密切的关系,而和服务器性能并无关联。如果你的游戏帧数很低,那么只能说明你的电脑性能不足以满足游戏的需求,与服务器性能并无任何关系。

卡顿不是崩溃

我们总能听到诸如 “服务器卡崩了” 之类的说法。然而,崩溃意味着程序的执行出现了异常,而卡顿往往只是服务性能不够高或代码效率较低而造成的处理时间延长,两者之间并没有必然的关系。只有唯一一种契合 “卡崩了” 说法的情况:服务器单个 tick 耗时超过 server.properties 中设定的阈值后被 WatchDog 所中断并崩溃。

服务器卡顿通常指游戏刻耗时过长

我们通常说的 “服务器卡” 都是指单个游戏刻耗时过长,即 MSPT 较高。当 MSPT 超过 50ms 时,服务器便不再能维持 tps 等于 20,导致玩家吃东西变慢、挖东西掉不下来、机器处理变慢等等负面影响。

网络也是卡顿的因素之一

当然了,如果你与服务器的连接延迟高达数千毫秒,亦或者是丢包率在 50% 以上,当然也不会感觉游戏流畅。

TeaCon 服务器卡顿背后的真相

TeaCon 的公开场馆所使用的服务器为 8 核 32G 内存,所以性能当然不是问题。那么问题出在哪呢?

神必人士对服务器的 DDoS/CC 攻击

在 TeaCon 举办的过程中,包括场馆服、官网在内的多个服务器均受到不同程度的 DDoS/CC 攻击,不过这些攻击在我们转移到高防服务器以及 CDN 之后已经得到了解决。

神必人士对模组漏洞的利用

之后的几次卡顿是导致 TOP 荣获 “模因污染” 的直接原因——服务器并没有崩溃,并且可以正常 ping 通,只是游戏内的玩家一段时间后集体掉线,而未进入游戏的玩家则无限卡在 “登入中” 界面。

经过排查,服务端的 Server Thread 线程已经失去了响应,无法再进行实体的更新、玩家登入的请求、游戏刻的执行。经过进一步排查,我们发现攻击者利用了 TOP 模组中的一个漏洞大量加载边界外的区块,导致 Server Thread 只能等待这上万个区块生成完毕,从而失去响应。

在 TOP 模组的漏洞修复之后,攻击者又在 Vida 模组中找到了相似的漏洞,并进行了第二次 “区块加载” 攻击,不过很快就被解决了。

相关链接