概述
在过去的几天，拳头游戏电竞技术团队在努力解决围绕着2022季中冠军赛的一系列技术问题，尤其在我们用来为线下选手和远程参赛选手平衡ping值的工具上。
我们初次发现的问题是一个存在于我们称之为“延迟服务工具”中的错误 -这个工具是用来将所有参赛选手的延迟（ping值）调整到 35ms范围， 而该错误会使在釜山场馆中的选手在比赛时产生额外的延迟，并使得其实际延迟高于场馆现场电脑屏幕上显示的延迟（35ms）。因此，在远程对局中，在中国的选手是在 35ms ping值区间进行比赛的，但在釜山的选手ping值则较之更高。很不幸，我们并没有在季中冠军赛开始之前发现这个问题，其根本原因是一个代码漏洞错误计算了延迟，导致该数值在日志中也是错误的。因此，即使我们的监控显示一切正常，而实际上却存在着错误。
我们在5月13日对该延迟服务工具进行了配置修改，以解决这个漏洞。考虑到之前实际网络延迟增加对釜山场馆中的比赛造成的影响，我们做出了艰难但是必要的决定：对B组对局ping值不相同的三场比赛进行重赛。
然而，5月13日这一配置修改带来的另一个问题是，现在在釜山选手电脑屏幕上显示的是错误的、低于实际 ping值的数字 ——尽管实际ping值现在已被修正并确保对等。 其后果是，当我们播放选手屏幕画面时，屏幕上会呈现一个错误的较低的 ping值。同时，由于我们团队没能及时将这个外显误差进行有效沟通，故而观众会认为在场馆里的选手正在以低于他们实际延迟的ping值进行比赛。
了解人工延迟：它的工作原理
延迟服务工具内置在《英雄联盟》的本地客户端/服务器端的网络协议栈中。它会持续测量每个玩家和服务器之间的实际网络延迟，根据需要，通过添加延迟进行调整，以达到目标延迟值。这是一种客户端/服务器端解决方案，目的是通过引入延迟来保证双方的延迟均等。
上图显示了系统的各个组件。图片顶部是游戏服务器组件，底部是游戏客户端（选手的电脑）。在目前这种情况下，延迟服务的目标延迟值为 35ms。图中的红色箭头表示存在的实际网络延迟。正如所看到的，釜山的选手 1 和选手 2 显示为 15ms 的“真实”ping值，而上海的选手 10 显示为 35ms的ping值。黄色框表示在客户端和服务器端人为添加了多少延迟。在这种情况下，选手 1 和选手 2 分别向客户端和服务器端添加了 10ms 的延迟，达到了目标延迟 35 ms。选手 10 已经具有等于目标延迟 35 ms 的实际延迟，因此没有添加延迟（0ms）。
最合理方案
考虑到以上种种因素，我们决定在使用人工延迟服务并维持竞赛公平性的情况下支持两种不同的网络架构设计。两支都在场馆的队伍比赛时，将使用架设在季中冠军赛场地内的本地服务器。而对上远程参赛队伍时，对战双方均在韩国数据中心的比赛服务器上进行比赛。拳头游戏电竞技术团队设置了系统并进行了基础架构测试，以确保一切运转正常。其中包括了各种测量和监控，如 ping值、网络抖动，以及对丢包的仔细检查。我们也让队伍在这个比赛服务器上进行训练赛，并让他们来到现场，进行技术测试。
但在第一比赛日结束后，选手告诉我们，比赛的时候感觉很卡。部分选手表示，即便游戏屏幕上显示 35ms，但实际体感却高于 35ms。当时我们所有的日志和基础架构监控显示一切正确，但我们决定继续调查，找出问题的原因。
找寻漏洞
引起这些问题的原因还是不清楚。由于架构监控工具并没有汇报错误，但我们却收到报告说比赛很卡。我们缺少特定漏洞或特定游戏内情况来定性。于是我们又回到了基础问题上。哪些数据是可用的？我们手里都有哪些日志？我们能收集到什么信息？
对此我们采取了两步走的做法。首先是向参赛的职业队伍收集问题，帮我们理解情况，到底哪里出了岔子。你们是在哪儿发现问题的？是场馆服务器还是比赛服务器？是场馆网络环境还是训练赛环境？是所有对局都这样？还是只是个别情况？与此同时，因为标准报告没有显示任何错误，所以我们开始查看其他日志和指标，寻找任何可能的差异。我们也提取了赛事客户端和服务器端的日志，并开始深入研究。
在过去的几天，拳头游戏电竞技术团队在努力解决围绕着2022季中冠军赛的一系列技术问题，尤其在我们用来为线下选手和远程参赛选手平衡ping值的工具上。
我们初次发现的问题是一个存在于我们称之为“延迟服务工具”中的错误 -这个工具是用来将所有参赛选手的延迟（ping值）调整到 35ms范围， 而该错误会使在釜山场馆中的选手在比赛时产生额外的延迟，并使得其实际延迟高于场馆现场电脑屏幕上显示的延迟（35ms）。因此，在远程对局中，在中国的选手是在 35ms ping值区间进行比赛的，但在釜山的选手ping值则较之更高。很不幸，我们并没有在季中冠军赛开始之前发现这个问题，其根本原因是一个代码漏洞错误计算了延迟，导致该数值在日志中也是错误的。因此，即使我们的监控显示一切正常，而实际上却存在着错误。
我们在5月13日对该延迟服务工具进行了配置修改，以解决这个漏洞。考虑到之前实际网络延迟增加对釜山场馆中的比赛造成的影响，我们做出了艰难但是必要的决定：对B组对局ping值不相同的三场比赛进行重赛。
然而，5月13日这一配置修改带来的另一个问题是，现在在釜山选手电脑屏幕上显示的是错误的、低于实际 ping值的数字 ——尽管实际ping值现在已被修正并确保对等。 其后果是，当我们播放选手屏幕画面时，屏幕上会呈现一个错误的较低的 ping值。同时，由于我们团队没能及时将这个外显误差进行有效沟通，故而观众会认为在场馆里的选手正在以低于他们实际延迟的ping值进行比赛。
了解人工延迟：它的工作原理
延迟服务工具内置在《英雄联盟》的本地客户端/服务器端的网络协议栈中。它会持续测量每个玩家和服务器之间的实际网络延迟，根据需要，通过添加延迟进行调整，以达到目标延迟值。这是一种客户端/服务器端解决方案，目的是通过引入延迟来保证双方的延迟均等。
上图显示了系统的各个组件。图片顶部是游戏服务器组件，底部是游戏客户端（选手的电脑）。在目前这种情况下，延迟服务的目标延迟值为 35ms。图中的红色箭头表示存在的实际网络延迟。正如所看到的，釜山的选手 1 和选手 2 显示为 15ms 的“真实”ping值，而上海的选手 10 显示为 35ms的ping值。黄色框表示在客户端和服务器端人为添加了多少延迟。在这种情况下，选手 1 和选手 2 分别向客户端和服务器端添加了 10ms 的延迟，达到了目标延迟 35 ms。选手 10 已经具有等于目标延迟 35 ms 的实际延迟，因此没有添加延迟（0ms）。
最合理方案
考虑到以上种种因素，我们决定在使用人工延迟服务并维持竞赛公平性的情况下支持两种不同的网络架构设计。两支都在场馆的队伍比赛时，将使用架设在季中冠军赛场地内的本地服务器。而对上远程参赛队伍时，对战双方均在韩国数据中心的比赛服务器上进行比赛。拳头游戏电竞技术团队设置了系统并进行了基础架构测试，以确保一切运转正常。其中包括了各种测量和监控，如 ping值、网络抖动，以及对丢包的仔细检查。我们也让队伍在这个比赛服务器上进行训练赛，并让他们来到现场，进行技术测试。
但在第一比赛日结束后，选手告诉我们，比赛的时候感觉很卡。部分选手表示，即便游戏屏幕上显示 35ms，但实际体感却高于 35ms。当时我们所有的日志和基础架构监控显示一切正确，但我们决定继续调查，找出问题的原因。
找寻漏洞
引起这些问题的原因还是不清楚。由于架构监控工具并没有汇报错误，但我们却收到报告说比赛很卡。我们缺少特定漏洞或特定游戏内情况来定性。于是我们又回到了基础问题上。哪些数据是可用的？我们手里都有哪些日志？我们能收集到什么信息？
对此我们采取了两步走的做法。首先是向参赛的职业队伍收集问题，帮我们理解情况，到底哪里出了岔子。你们是在哪儿发现问题的？是场馆服务器还是比赛服务器？是场馆网络环境还是训练赛环境？是所有对局都这样？还是只是个别情况？与此同时，因为标准报告没有显示任何错误，所以我们开始查看其他日志和指标，寻找任何可能的差异。我们也提取了赛事客户端和服务器端的日志，并开始深入研究。
