我在互联网从业7年，现在是一家创业公司的架构师，负责平台工程搭建和运维，自认为有能力帮大家解读一下拳头的这份技术报告，以及对这份技术报告的做一些评价，提出一些疑问。这篇文章详细解释了拳头技术报告的各种细节，希望大家不要盲目喷拳头，分散了注意力，要有重点的喷。
叠甲：这篇文章只针对拳头发布的技术报告进行解读和评价，不对任何拳头的媒体行为进行讨论。
缩略版本
从技术上说，拳头选择了一个本身就具有风险的环境架构。从报告上来说，这份技术报告在最重要的时间线上非常模糊，无论是图还是数据都很不专业，在关键问题上模糊处理，所有的补丁缺乏验证手段。
技术解读
先来大致总结一下拳头的这个技术报告大致的流程：
为何允许RNG远程参赛
为何选择人工增加延迟
人工延迟工作机理
整体比赛环境介绍
如何确认延迟工具存在问题
如何修复以及为何出现显示问题（重点问题，有对bug和修复的解释）
为何要求重赛
下面我会对每一个环节进行简单的复述，以及我自己的评价。
为何允许RNG远程参赛
复述：经过测试，职业选手最高能接受的延迟是40ms（+/- 5ms），超出这个范围就会有明显的操作问题。RNG连接韩服的延迟是35ms（+/- 5ms），仍在接受范围内。
评价：为数不多的人话，都闭嘴。
为何选择人工增加延迟
复述：两个原因：1. 目前拳头并没有能够让釜山和上海达成相同延迟的数据中心；2. 由于2020年开始陆续都有线上比赛的需求，所以客户端和服务器端都已经部署了增加延迟的模块，可以用来增加额外延迟。
评价：第一点就先不讨论了，这涉及到物理层光纤部署的问题，我对这块不了解就不多说了。第二点其实是意料之内的，因为如果要使用第三方网络工具，必须对网络工具进行代码审核，确保其中代码不包含恶意代码或者外挂代码，还可能需要进行一定的定制化，这就很蛋疼。所以把自研的网络工具部署进客户/服务端，先不讨论这个架构是否合理，“使用自研模块”这个决策是没啥问题的。然而，这个模块是2020年引入的，现在都快2年了，都迭代了两个大版本，这个工具还在维护么？如果没有维护，谁给你的胆量直接启用😂
整体比赛环境介绍
复述：如果两队都在现场，就用现场服务器；如果有一队在线上，就用线上服务器；所有队伍的训练赛都使用线上服务器。不论两队身处何地，都会在客户端和服务端开启人工延迟模块。线上服务器就是现在的韩服，以及LCK比赛使用的服务器。这么做的原因是为了降低不必要的网络波动风险，因为这样“只会影响线上参赛的队伍，而不会导致所有的比赛受到影响”。
评价：啊？你自己看看你说的是人话吗。线上赛的队伍风险就不叫风险是吧。不去考虑如何正确的预防和降低风险，直接舍小保大，真有你的。另外，我还是第一次看到有人能做出维护两套在线系统的决定的，但凡有点运维经验的都知道维持两个环境一致有多困难。在一个环境下的测试结果很难真实反映另一个环境的实际效果，这种架构出事就是迟早的事。
如何确认延迟工具存在问题
复述：第一天结束后，选手开始反映体感延迟过高，但是从网络层的日志和数据监控来看一切正常。在后续的调查中，拳头发现选手们普遍反映在场馆的体感延迟比在训练赛的体感延迟高。于是拳头开发了一个新的测试工具用来测试从发出指令到指令渲染的端到端延迟，发现在不同的人工延迟下，端到端的延迟有明显的区别。至此确认了选手们反映的问题确有其事。
评价：前文提过了维护两套系统的风险，看到“在场馆的体感延迟比在训练赛的体感延迟高”真的一点都不意外。不过说实在话，当日志和数据监控没问题但是用户反映有问题的时候，第一反应为什么不是去复现问题并且增加更多的断点日志，而是在这无头苍蝇一般的“捉鬼”（文章原话用的就是捉鬼）。
如何修复以及为何出现显示问题
复述：在确认了问题之后，拳头检查了代码，发现了一个计算错误，导致在实际延迟远低于目标延迟时，增加了错误的延迟然而代码仍认为补正是正确的。所以我们额外引入了一个偏移量来补偿错误计算的延迟，然而这导致了显示上的错误。
在进行评价之前，我先翻译翻译。拳头的这个bug就有点像在使用一个标注有问题的尺子，假设这个尺子是15cm，然而前10cm只有5个刻度，后5cm有10个刻度。现在我需要用这个尺子测量一些长度，并且把这些长度补齐15cm。那么问题就出现了：如果一个长度有10cm，但是用这个尺子测量出来的只有5个刻度，也就是5cm，那么尺子的使用者就会认为需要补正10cm才能到达15cm。然而实际上在补正了10cm之后，实际长度达到了20cm。但是，如果这个长度本身就接近15cm，就算用这个有问题的尺子量，长度也不会出现太多的问题了，计算出来的补正就相对正确了。那么解决这个尺子问题的办法，拳头相当简单粗暴：既然小数值的时候会加的更多，我额外再给你减掉就好了。然而这个额外的减法会显示尺子的读数，所以尺子的读数变小了。当然由于拳头没有公布具体的bug，所以以上都只是一个演示，并不代表实际情况。
2022-05-18更新：有些JR对上面这样的描述还是不太理解，我画个图弄的更直观点。
正常的尺子一格是5ms，用来测量15ms的时候就是3格，30ms的时候是6格。但是由于某种原因出了bug，导致尺子越靠左端每一格变的越大，变成了下图中的bug尺子。这时候用bug尺子来测量15ms的时候，只剩1格了，测量30ms的时候大概是5.2格。由于一格=5ms，所以由bug尺子测出来的15ms变成了5ms，30ms变成了26ms。那么如果目标延迟是35ms的话，实际延迟15ms在bug尺子的作用下，需要补正35-5=30ms，那么最终的实际延迟就是30+15=45ms，而在bug尺子的标度下，5ms加上补正之后就是35ms；实际延迟30ms需要补正35-26=9ms，那么最终的实际延迟就是9+30=39ms，在bug尺子的标度下，补正之后还是35ms。客户端上显示的值是在bug尺子作用下补正之后的最终延迟，也就是35ms。
拳头公布的补丁方案是额外增加一个补偿量，也就是在实际延迟偏小时，在bug尺子计算之后再做一次偏移。由于已知bug尺子会使得补正偏大，所以这个补偿量就是在补正的时候减掉一个数字，比如现在的-13ms。所以在增加了这个补偿量之后，再回头看一遍例子：15ms的实际延迟用bug尺子测量得到1格，也就是5ms，需要补正30ms，减去补偿量-13ms，所以最终需要补正17ms。那么真实的延迟就是15+17=32ms，在bug尺子的标度下就是5+17=22ms。所以客户端显示的是22ms。
当然由于拳头没有公布具体的bug，所以以上都只是我个人基于给出情况做的一个符合现状的猜测，并不代表实际情况。
评价：行吧。能理解。毕竟是两年前引入的模块，还不知道有没有维护，用黑盒的方式增加一个偏移量可能是最简单的做法。但是这个补丁的启用明显会出现副作用（显示bug），为什么这个副作用不能修复？为什么针对这个没有说明？就算不能修复，为什么没有公开说明？作为第三方，如何确认这个是显示bug，而不是还有其他实际问题？
为何要求重赛
复述：由于上文提到的问题，由于RNG方面和目标延迟差距小，补正正常，而现场方面和目标延迟差距大，补正错误，所以只有现场方和RNG方比赛时，导致双方延迟存在区别，所以重赛。
评价：看似公平合理，实际漏洞百出。虽然在现场双方都是顶着高延迟在打，看似公平，但实际上双方由于延迟做出的队伍选择和操作可能都存在问题，这对于系列赛来说是不利的。在系列赛中，每个队伍的每一场正式对局都会被纳入各个队伍的分析范围，那前面高延迟的那些比赛实际上都不算有效数据。然而就RNG重赛了，那么RNG的有效数据点就比其他队伍更多了，如果追求真正的公平，就应该所有队伍重赛。
报告中的欠缺及疑点
时间线
通过这份技术文档，我们无法清晰的看到时间线上几个关键的时间点：
何时确认了存在代码问题；
何时结束了补丁的开发；
何时结束了补丁的测试；
何时在比赛环境打上了补丁
不吻合的数据
根据官方公布的这张图，有两个问题：
RNG的第三场比赛已经应用了修改，为什么第三场仍然重赛了？
RNG一共有9场比赛，为什么有一场比赛没了？
不专业的作图
文档中的一些涉及延迟的图，纵轴都没有明确标注，并且也没有图例:
对于这三张图，我们无法得知纵轴的单位是什么，每个格子意味着什么，每个格子的大小又是什么意思。
未公布的细节
由于图表的不专业，我们至今无法得知，在错误的配置下，现场的实际延迟到底是多少。我们只能推测，这个延迟可能是线性的，当时显示35ms的时候，实际是35+13=48ms。但是如果是线性的，48ms已经超出了拳头认定的40ms （+/- 5ms）的可接受范围，为什么不重赛？如果不是线性的，为什么选用了-13ms的恒定补正？这个数字是怎么来的？计算过程呢？
附件
所有技术报告中提到的日志，自建的端到端网络测试工具以及作图工具全部不公开，我们甚至无法确认文中提到的数据是否属实，图像是否是由真实数据生成。
(转载注明出处)
我在互联网从业7年，现在是一家创业公司的架构师，负责平台工程搭建和运维，自认为有能力帮大家解读一下拳头的这份技术报告，以及对这份技术报告的做一些评价，提出一些疑问。这篇文章详细解释了拳头技术报告的各种细节，希望大家不要盲目喷拳头，分散了注意力，要有重点的喷。
叠甲：这篇文章只针对拳头发布的技术报告进行解读和评价，不对任何拳头的媒体行为进行讨论。
缩略版本
从技术上说，拳头选择了一个本身就具有风险的环境架构。从报告上来说，这份技术报告在最重要的时间线上非常模糊，无论是图还是数据都很不专业，在关键问题上模糊处理，所有的补丁缺乏验证手段。
技术解读
先来大致总结一下拳头的这个技术报告大致的流程：
为何允许RNG远程参赛
为何选择人工增加延迟
人工延迟工作机理
整体比赛环境介绍
如何确认延迟工具存在问题
如何修复以及为何出现显示问题（重点问题，有对bug和修复的解释）
为何要求重赛
下面我会对每一个环节进行简单的复述，以及我自己的评价。
为何允许RNG远程参赛
复述：经过测试，职业选手最高能接受的延迟是40ms（+/- 5ms），超出这个范围就会有明显的操作问题。RNG连接韩服的延迟是35ms（+/- 5ms），仍在接受范围内。
评价：为数不多的人话，都闭嘴。
为何选择人工增加延迟
复述：两个原因：1. 目前拳头并没有能够让釜山和上海达成相同延迟的数据中心；2. 由于2020年开始陆续都有线上比赛的需求，所以客户端和服务器端都已经部署了增加延迟的模块，可以用来增加额外延迟。
评价：第一点就先不讨论了，这涉及到物理层光纤部署的问题，我对这块不了解就不多说了。第二点其实是意料之内的，因为如果要使用第三方网络工具，必须对网络工具进行代码审核，确保其中代码不包含恶意代码或者外挂代码，还可能需要进行一定的定制化，这就很蛋疼。所以把自研的网络工具部署进客户/服务端，先不讨论这个架构是否合理，“使用自研模块”这个决策是没啥问题的。然而，这个模块是2020年引入的，现在都快2年了，都迭代了两个大版本，这个工具还在维护么？如果没有维护，谁给你的胆量直接启用😂
整体比赛环境介绍
复述：如果两队都在现场，就用现场服务器；如果有一队在线上，就用线上服务器；所有队伍的训练赛都使用线上服务器。不论两队身处何地，都会在客户端和服务端开启人工延迟模块。线上服务器就是现在的韩服，以及LCK比赛使用的服务器。这么做的原因是为了降低不必要的网络波动风险，因为这样“只会影响线上参赛的队伍，而不会导致所有的比赛受到影响”。
评价：啊？你自己看看你说的是人话吗。线上赛的队伍风险就不叫风险是吧。不去考虑如何正确的预防和降低风险，直接舍小保大，真有你的。另外，我还是第一次看到有人能做出维护两套在线系统的决定的，但凡有点运维经验的都知道维持两个环境一致有多困难。在一个环境下的测试结果很难真实反映另一个环境的实际效果，这种架构出事就是迟早的事。
如何确认延迟工具存在问题
复述：第一天结束后，选手开始反映体感延迟过高，但是从网络层的日志和数据监控来看一切正常。在后续的调查中，拳头发现选手们普遍反映在场馆的体感延迟比在训练赛的体感延迟高。于是拳头开发了一个新的测试工具用来测试从发出指令到指令渲染的端到端延迟，发现在不同的人工延迟下，端到端的延迟有明显的区别。至此确认了选手们反映的问题确有其事。
评价：前文提过了维护两套系统的风险，看到“在场馆的体感延迟比在训练赛的体感延迟高”真的一点都不意外。不过说实在话，当日志和数据监控没问题但是用户反映有问题的时候，第一反应为什么不是去复现问题并且增加更多的断点日志，而是在这无头苍蝇一般的“捉鬼”（文章原话用的就是捉鬼）。
如何修复以及为何出现显示问题
复述：在确认了问题之后，拳头检查了代码，发现了一个计算错误，导致在实际延迟远低于目标延迟时，增加了错误的延迟然而代码仍认为补正是正确的。所以我们额外引入了一个偏移量来补偿错误计算的延迟，然而这导致了显示上的错误。
在进行评价之前，我先翻译翻译。拳头的这个bug就有点像在使用一个标注有问题的尺子，假设这个尺子是15cm，然而前10cm只有5个刻度，后5cm有10个刻度。现在我需要用这个尺子测量一些长度，并且把这些长度补齐15cm。那么问题就出现了：如果一个长度有10cm，但是用这个尺子测量出来的只有5个刻度，也就是5cm，那么尺子的使用者就会认为需要补正10cm才能到达15cm。然而实际上在补正了10cm之后，实际长度达到了20cm。但是，如果这个长度本身就接近15cm，就算用这个有问题的尺子量，长度也不会出现太多的问题了，计算出来的补正就相对正确了。那么解决这个尺子问题的办法，拳头相当简单粗暴：既然小数值的时候会加的更多，我额外再给你减掉就好了。然而这个额外的减法会显示尺子的读数，所以尺子的读数变小了。当然由于拳头没有公布具体的bug，所以以上都只是一个演示，并不代表实际情况。
2022-05-18更新：有些JR对上面这样的描述还是不太理解，我画个图弄的更直观点。
正常的尺子一格是5ms，用来测量15ms的时候就是3格，30ms的时候是6格。但是由于某种原因出了bug，导致尺子越靠左端每一格变的越大，变成了下图中的bug尺子。这时候用bug尺子来测量15ms的时候，只剩1格了，测量30ms的时候大概是5.2格。由于一格=5ms，所以由bug尺子测出来的15ms变成了5ms，30ms变成了26ms。那么如果目标延迟是35ms的话，实际延迟15ms在bug尺子的作用下，需要补正35-5=30ms，那么最终的实际延迟就是30+15=45ms，而在bug尺子的标度下，5ms加上补正之后就是35ms；实际延迟30ms需要补正35-26=9ms，那么最终的实际延迟就是9+30=39ms，在bug尺子的标度下，补正之后还是35ms。客户端上显示的值是在bug尺子作用下补正之后的最终延迟，也就是35ms。
拳头公布的补丁方案是额外增加一个补偿量，也就是在实际延迟偏小时，在bug尺子计算之后再做一次偏移。由于已知bug尺子会使得补正偏大，所以这个补偿量就是在补正的时候减掉一个数字，比如现在的-13ms。所以在增加了这个补偿量之后，再回头看一遍例子：15ms的实际延迟用bug尺子测量得到1格，也就是5ms，需要补正30ms，减去补偿量-13ms，所以最终需要补正17ms。那么真实的延迟就是15+17=32ms，在bug尺子的标度下就是5+17=22ms。所以客户端显示的是22ms。
当然由于拳头没有公布具体的bug，所以以上都只是我个人基于给出情况做的一个符合现状的猜测，并不代表实际情况。
评价：行吧。能理解。毕竟是两年前引入的模块，还不知道有没有维护，用黑盒的方式增加一个偏移量可能是最简单的做法。但是这个补丁的启用明显会出现副作用（显示bug），为什么这个副作用不能修复？为什么针对这个没有说明？就算不能修复，为什么没有公开说明？作为第三方，如何确认这个是显示bug，而不是还有其他实际问题？
为何要求重赛
复述：由于上文提到的问题，由于RNG方面和目标延迟差距小，补正正常，而现场方面和目标延迟差距大，补正错误，所以只有现场方和RNG方比赛时，导致双方延迟存在区别，所以重赛。
评价：看似公平合理，实际漏洞百出。虽然在现场双方都是顶着高延迟在打，看似公平，但实际上双方由于延迟做出的队伍选择和操作可能都存在问题，这对于系列赛来说是不利的。在系列赛中，每个队伍的每一场正式对局都会被纳入各个队伍的分析范围，那前面高延迟的那些比赛实际上都不算有效数据。然而就RNG重赛了，那么RNG的有效数据点就比其他队伍更多了，如果追求真正的公平，就应该所有队伍重赛。
报告中的欠缺及疑点
时间线
通过这份技术文档，我们无法清晰的看到时间线上几个关键的时间点：
何时确认了存在代码问题；
何时结束了补丁的开发；
何时结束了补丁的测试；
何时在比赛环境打上了补丁
不吻合的数据
根据官方公布的这张图，有两个问题：
RNG的第三场比赛已经应用了修改，为什么第三场仍然重赛了？
RNG一共有9场比赛，为什么有一场比赛没了？
不专业的作图
文档中的一些涉及延迟的图，纵轴都没有明确标注，并且也没有图例:
对于这三张图，我们无法得知纵轴的单位是什么，每个格子意味着什么，每个格子的大小又是什么意思。
未公布的细节
由于图表的不专业，我们至今无法得知，在错误的配置下，现场的实际延迟到底是多少。我们只能推测，这个延迟可能是线性的，当时显示35ms的时候，实际是35+13=48ms。但是如果是线性的，48ms已经超出了拳头认定的40ms （+/- 5ms）的可接受范围，为什么不重赛？如果不是线性的，为什么选用了-13ms的恒定补正？这个数字是怎么来的？计算过程呢？
附件
所有技术报告中提到的日志，自建的端到端网络测试工具以及作图工具全部不公开，我们甚至无法确认文中提到的数据是否属实，图像是否是由真实数据生成。
(转载注明出处)
