拳頭長文回應MSI爭議：釜山選手Ping值比實際低

拳頭游戲官方發長文回應本次2022季中冠軍賽出現的一系列技術問題。

長文總結：

1.在上海的選手屏幕顯示的 ping值是正確的

2.在釜山的選手屏幕顯示的 ping值不正確，并且比實際延遲低約13ms

3.未能及時發現的漏洞影響了比賽，對ping值顯示錯誤問題的溝通也不夠及時透明。再次對此造成的問題和困擾致以深深的歉意。

概述

在過去的幾天，拳頭游戲電競技術團隊在努力解決圍繞著2022季中冠軍賽的一系列技術問題，尤其在我們用來為線下選手和遠程參賽選手平衡ping值的工具上。

我們初次發現的問題是一個存在于我們稱之為“延遲服務工具”中的錯誤 -這個工具是用來將所有參賽選手的延遲(ping值)調整到 35ms范圍， 而該錯誤會使在釜山場館中的選手在比賽時產生額外的延遲，并使得其實際延遲高于場館現場電腦屏幕上顯示的延遲(35ms)。因此，在遠程對局中，在中國的選手是在 35ms ping值區間進行比賽的，但在釜山的選手ping值則較之更高。很不幸，我們并沒有在季中冠軍賽開始之前發現這個問題，其根本原因是一個代碼漏洞錯誤計算了延遲，導致該數值在日志中也是錯誤的。因此，即使我們的監控顯示一切正常，而實際上卻存在著錯誤。

我們在5月13日對該延遲服務工具進行了配置修改，以解決這個漏洞?？紤]到之前實際網絡延遲增加對釜山場館中的比賽造成的影響，我們做出了艱難但是必要的決定：對B組對局ping值不相同的三場比賽進行重賽。

然而，5月13日這一配置修改帶來的另一個問題是，現在在釜山選手電腦屏幕上顯示的是錯誤的、低于實際 ping值的數字 ——盡管實際ping值現在已被修正并確保對等。 其后果是，當我們播放選手屏幕畫面時，屏幕上會呈現一個錯誤的較低的 ping值。同時，由于我們團隊沒能及時將這個外顯誤差進行有效溝通，故而觀眾會認為在場館里的選手正在以低于他們實際延遲的ping值進行比賽。

本篇文章將從技術角度復盤從賽前到現在(小組賽結束)發生的整個情況。

賽前階段

當我們開始計劃今年季中冠軍賽最后階段的技術設置時，新冠疫情帶來的持續挑戰擺在了我們面前。LPL賽區代表隊，Royal Never Give Up (RNG) 不會從上海前往釜山，而會遠程參賽。

表面上看，簡單的解決方案是讓遠程參賽的隊伍連到季中冠軍賽比賽服務器就行，其他隊伍在線下進行比賽。然而這樣的解決方案也并不理想，存在諸多問題。

問題之一就是釜山和上海之間相隔大概 850 公里(中間隔著黃海)。這意味著，網絡通信需要在上海和韓國的季中冠軍賽比賽服務器之間來回傳輸。

數據在客戶端和服務器間往返傳輸所需的時間就是我們常說的“ping值”(又稱為延遲)。從 RNG 俱樂部所在地到季中冠軍賽的比賽服務器，大約自然延遲是 35毫秒(ms) 。 而且其他十支參賽隊伍會在釜山的比賽場館里參賽，他們的延遲會低很多，大約在 15ms左右。請注意，我們本文里的ping值通常都指一個范圍，因為ping值常會在+/-5ms的極小范圍內波動。

如果是一名普通《英雄聯盟》玩家，35ms 到 15ms 之間的差異或許是很難察覺到的。但對職業選手來說，這足以改變比賽手感，產生細微但仍能察覺到的差異。拳頭游戲電競賽事核心原則中的一條，就是保證競賽公平性。我們希望讓所有參賽的隊伍，能夠在平等競技條件下競賽。

既然說到平等競賽環境，那我們說明一下ping值差異問題。

讓遠程參賽成為可能

因為電競賽事是在網絡上進行的，我們希望能尋找一些遠程參賽的辦法。

但隨之而來的兩個問題是：

1)上海和釜山之間 35ms 的延遲是否能夠保證最高水準的競技發揮?

2)我們是否能提供同等競賽環境，讓所有選手都有相同的延遲?

對于第一個問題的回答是：“是”。對于英雄聯盟電競賽事來說，在最高級別的比賽中，我們認為最高可忍受的延遲極限為 40ms(上下浮動5ms)。 通過與內部和外部合作伙伴，包括我們內部的游戲分析和設計團隊的深入討論和分析，我們在2020年中確認了這個范圍。當ping值超過40ms范圍時，大部分職業選手會開始注意到延遲，它也開始影響諸如英雄選擇、技能釋放以及對對手的操作做出快速反應的能力。

對于第二個問題的回答，我們考慮了以下幾個方案：

方案一：每支隊伍都在自然延遲下進行比賽

該方案建議，遠程參賽隊可自行選擇所擁有的最快速網絡，直連到季中冠軍賽比賽服務器。這意味著現場參賽隊伍會在低 ping值(~15ms)下比賽，而遠程參賽隊伍(以RNG為例)則要在其自然延遲下比賽。從中國連接到釜山的自然延遲約為 35ms。

我們考慮過，但還是否決了這個方案。因為基于競賽公平性的原則，我們希望保證對每個參賽隊伍的公平。

方案二：將服務器架設于韓國和中國的中間點

還有一種解決方案是，如果中韓兩國之間的ping值是 35ms，直接把服務器放在兩地中心點，延遲均分，不就各自只有 17.5ms 了嗎?實際上這個方案的實施仍然具有諸多挑戰…其中一個最大的問題是，要在汪洋大海中間架設服務器。

方案三：使用人工延遲

所以如果在韓國參賽的隊伍ping值很低，而在中國參賽的隊伍ping值又相對較高，那給韓國那邊加上一些延遲使兩邊對等，這可行嗎?我們能做到嗎?

事實證明，《英雄聯盟》的開發團隊已經有了一種引入人工延遲的方法，即延遲服務(Latency Service)。也有人叫它：“假ping”。這是一種客戶端/服務器功能，旨在解決疫情下，遠程競賽需要公平競賽環境的需求。延遲服務允許我們設置一個目標值(如 35ms)，它會在客戶端和服務器上為每個玩家加入延遲，使大家保持基本相同的延遲水平。

我們曾成功地在過去一些英雄聯盟電競賽事里運用了該工具，當時的比賽都是遠程進行的。但這次是首次在全球性賽事上使用這一工具，并且其中部分選手還在釜山本地場館進行對局。雖然我們之前使用過，但環境中的部分細微差異總有可能造成我們無法預見的錯誤。在訓練賽服務器上的人工延遲應用效果比較理想，再加上我們長期使用的可靠網絡基礎設施和測試方法，我們當時認為已經有足夠多的應用實例，能在小組賽階段之前發現所有的重大問題。

我們的選擇

再三衡量各種方案后，我們認為最重要的是保證競賽公平性，那么使用方案三 - 人工延遲便是最好的解決方案。

了解人工延遲：它的工作原理

延遲服務工具內置在《英雄聯盟》的本地客戶端/服務器端的網絡協議棧中。它會持續測量每個玩家和服務器之間的實際網絡延遲，根據需要，通過添加延遲進行調整，以達到目標延遲值。這是一種客戶端/服務器端解決方案，目的是通過引入延遲來保證雙方的延遲均等。

上圖顯示了系統的各個組件。圖片頂部是游戲服務器組件，底部是游戲客戶端(選手的電腦)。在目前這種情況下，延遲服務的目標延遲值為 35ms。圖中的紅色箭頭表示存在的實際網絡延遲。正如所看到的，釜山的選手 1 和選手 2 顯示為 15ms 的“真實”ping值，而上海的選手 10 顯示為 35ms的ping值。黃色框表示在客戶端和服務器端人為添加了多少延遲。在這種情況下，選手 1 和選手 2 分別向客戶端和服務器端添加了 10ms 的延遲，達到了目標延遲 35 ms。選手 10 已經具有等于目標延遲 35 ms 的實際延遲，因此沒有添加延遲(0ms)。

同等競賽環境還是兩個不同的競賽環境?

想要深入了解這一話題，可能要提起我們曾經對于遠程環境和本地環境所做的一個決定。

對于電競賽事技術團隊來說，我們一直追求把現場賽事的風險降到最低。2012年洛杉磯，第二屆全球總決賽比賽因網絡問題被迫中斷。這段回憶，將永遠烙刻在所有拳頭電競人心中。

在決定2022 季中冠軍賽的網絡架構設計時，我們意識到必須在兩種不同的策略之間做出決定。

策略一：所有場景下使用同等種網絡架構設計

在國際比賽中，我們的競技比賽都是在使用場館內的線下服務器上。這為我們提供了高度的可靠性，因為它允許我們直接控制網絡和服務器硬件。考慮到有一支隊伍遠程參賽，那么就必須構筑這樣一個場景：至少會有一支隊伍將通過互聯網服務器進行比賽。那么如果有一支隊伍需要通過互聯網服務器參賽，一個策略就是徹底放棄我們的本地部署，轉而讓所有隊伍都通過互聯網服務器進行比賽。

鑒于穩定性原則，我們知道如果必須架設互聯網比賽服務器，那就要選擇十分信得過的部署方案。很顯然，韓國的比賽服務器是值得考慮的選擇。這是一個僅供職業比賽使用的環境，和韓國公共服務器位于同一數據中心，并常用于LCK韓國聯賽。同樣這也意味著這個服務器有無數小時的運行數據來驗證其網絡的良好連通性和架構的可信賴性。所以當至少有一支隊伍需要遠程參賽時，用這個節點是合理的。但接下來的問題是，是應該在所有比賽中使用它，還是只針對遠程比賽使用。這便引出了策略二：最小化網絡風險。

策略二：僅在必要時使用遠程參賽，最小化網絡風險

在之前的策略中，考慮到某些比賽需要在互聯網環境中進行，那么問題就變成了：“何不統統放在這個環境下呢?”這個答案很簡單：互聯網的可靠性?；ヂ摼W有時候風平浪靜，有時候則未必。如果所有季中冠軍賽比賽都在互聯網服務器上進行，那么任何網絡問題都可能導致比賽在進行中出現問題。如果只是遠程比賽通過互聯網進行，那網絡出現問題的概率就會大大降低。我們相信通過我們的計劃，能夠將風險降到最低。由于我們相信我們有能力通過使用人工延遲來實現ping值在同等競賽環境，所以這只是一個復雜性與可靠性的簡單問題。為了實現更低的風險(減少互聯網的不可靠性)，我們增加了一點復雜性(兩種網絡架構設計)。

考慮到這兩種選項，并基于我們的評估，我們決定采用策略二，它能夠為賽事的可靠性和競賽公平性帶來最低的風險。

下方的圖表就是我們所選擇的網絡架構設計，展示了在不同情況下網絡是如何鏈接運行的。

最合理方案

考慮到以上種種因素，我們決定在使用人工延遲服務并維持競賽公平性的情況下支持兩種不同的網絡架構設計。兩支都在場館的隊伍比賽時，將使用架設在季中冠軍賽場地內的本地服務器。而對上遠程參賽隊伍時，對戰雙方均在韓國數據中心的比賽服務器上進行比賽。拳頭游戲電競技術團隊設置了系統并進行了基礎架構測試，以確保一切運轉正常。其中包括了各種測量和監控，如 ping值、網絡抖動，以及對丟包的仔細檢查。我們也讓隊伍在這個比賽服務器上進行訓練賽，并讓他們來到現場，進行技術測試。

但在第一比賽日結束后，選手告訴我們，比賽的時候感覺很卡。部分選手表示，即便游戲屏幕上顯示 35ms，但實際體感卻高于 35ms。當時我們所有的日志和基礎架構監控顯示一切正確，但我們決定繼續調查，找出問題的原因。

找尋漏洞

引起這些問題的原因還是不清楚。由于架構監控工具并沒有匯報錯誤，但我們卻收到報告說比賽很卡。我們缺少特定漏洞或特定游戲內情況來定性。于是我們又回到了基礎問題上。哪些數據是可用的?我們手里都有哪些日志?我們能收集到什么信息?

對此我們采取了兩步走的做法。首先是向參賽的職業隊伍收集問題，幫我們理解情況，到底哪里出了岔子。你們是在哪兒發現問題的?是場館服務器還是比賽服務器?是場館網絡環境還是訓練賽環境?是所有對局都這樣?還是只是個別情況?與此同時，因為標準報告沒有顯示任何錯誤，所以我們開始查看其他日志和指標，尋找任何可能的差異。我們也提取了賽事客戶端和服務器端的日志，并開始深入研究。

舉個例子，我們曾假設問題是，也許游戲服務器沒有保持穩定的幀率。于是我們提取了日志，并將數據放入一個查看工具中，把數據可視化為上面的圖表(如上示意)。它顯示了我們在每場比賽中都有非常穩定的幀率。所以這并不是職業選手報告的問題原因。

查閱日志是一項極其細致而艱巨的工作。數據本身看起來就像一頁又一頁看似隨機的數字流，必須通過各種工具進行編譯，將其可視化，使其有意義。每一輪的徹查，我們都沒有發現異常。

在我們查看日志和代碼時，我們逐漸收到了來自各方隊伍的更多反饋。大家對季中冠軍賽場地環境的抱怨比其他任何環境都多。這和我們的理解有所相背。畢竟，線下比賽和選手在同一建筑里的硬件上進行的。在擁有完美可控的網絡環境下怎么會比通過在韓國互聯網服務器上進行比賽感覺更糟糕?

這引發了另一個設想…如果日志的延遲測量顯示良好，但體驗相反，那會不會是日志出了問題?會不會是我們測量延遲的方式有問題?

開發團隊隨即寫了幾段代碼來驗證這個猜想。一般情況下，日志是根據游戲數據包在服務器的網絡層和客戶端的網絡層之間的往返產生的。這些日志沒有發現任何錯誤。所以我們換了一種方式用新工具來測試延遲。不再測試網絡層的流量延遲，改為測試整個“端到端”的循環，從用戶點擊，再到看到該點擊響應。換句話說，測量的不再只是網絡表現，只要游戲中任何系統之間的互動會被選手接觸到，就都會去測量。

可以參考以上的圖表了解這個概念?，F有的網絡監控測量的是包括網絡層延遲和延遲服務時延，這一點會通過綠色箭頭展示在上圖中。但是新的工具模擬了輸入層的輸入，然后測量在該輸入和服務器響應之間發生的全棧延遲。紅色箭頭展示了新工具的監測軌跡。

有了這個新工具，我們就能在實驗室中進行測試，看看能不能重現選手們的問題。

我們做的第一件事，就是在不運行延遲服務下，設置一個基準線。因為我們有來自公共服務器上無數小時的玩家數據，我們相信服務器沒有任何漏洞，因此我們以它們來做參照組。 第一個設置基準線的實驗模擬了在韓國參賽的隊伍和在中國參賽的隊伍均從互聯網接入服務器的場景。

實驗一：關閉延遲服務工具，對比韓國和中國的網絡

這類實驗的數據十分復雜，這里我們將其整理之后用圖表的形式展現出來，可以幫助大家理解我們所看到的情況。

如果你沿著橫軸(游戲時間)看，會發現一開始(圖表左側)的延遲值很低。幾分鐘后(圖中從左到右的中間部分)，我們開始模擬較高ping值的網絡(例如：上海)。我們可以看到，豎軸上的延遲在上升。這和預想的完全一樣。在低ping值網絡下，延遲較低;在高ping值網絡下，延遲較高。

第一個實驗，作為參照組，說明用新工具測量的結果是符合我們預期的。這是個好的開始。

下一個實驗，我們會用相同的步驟進行檢測，但這次我們開啟延遲服務工具。

實驗二：開啟延遲服務工具，對比韓國和中國的網絡

我們需要記住的是，人工延遲服務的目的就是無條件平衡網絡 ping值。所以如果我們更改了實驗室中的網絡ping值特性，那么我們的預期就是延遲服務將加入延遲，使得測量值保持相同。然而，數據卻表明不是這樣的。正如所看到的，上海的模擬網絡所顯示的延遲比韓國模擬網絡所顯示的延遲要低。這是在我們意料之外的，這也展示了延遲服務為韓國網絡環境帶來了比上海網絡環境更高的延遲。

從這份報告我們可以確定三件事：

1)問題是真實存在的，且確實與選手們報告的情況相符

2)我們自己可以在實驗室重現這個問題

3)問題很可能就出現在人工延遲工具上

從這些信息入手，我們就知道需要在代碼中的何處尋找問題。 在運行各種額外的測試以了解我們更改實驗室環境的特性時發生了什么后，我們意識到，只有在實際 ping顯著低于目標延遲的情況下才會出現計算錯誤。 在這種情況下，實際延遲將遠遠高于屏幕上顯示的延遲。

這便解釋了目前的一系列問題。為什么日志不顯示這些問題：因為運算錯了。為什么場館比網絡服務器體感還差：因為環境 ping值越低，這個漏洞就越明顯。這也解釋了為什么在釜山現場的選手覺得比賽體感延遲比屏幕上顯示的約 35ms差多了：因為實際延遲確實高于 35ms。

既然找到了問題，那下一步就是盡快解決它。

幸運的是，查閱代碼后，我們可以很好的理解這一問題。從這里出發，我們假設可以通過做一個配置改變，來補償這個計算錯誤。

既然我們有了辦法來模擬環境，也有了辦法來使用自研工具測試實際延遲，那么就可以通過調節配置，得到我們想要的結果。

以下圖表顯示了與兩個實驗相同的網絡環境，但這一次使用了將錯誤修正后的配置文件。

實驗三：在正確的配置下啟用延遲服務工具

和前兩次實驗一樣，先模擬一個低 ping值環境，幾分鐘后再模擬一個高 ping值環境。和之前實驗結果不同的是，在使用了更改的配置后，這次延遲服務的補償終于正確了。這張圖表顯示，即便 ping值從低切換到高，延遲都是基本相同的。

問題解決了嗎?

這個配置修正了一個游戲中 ping值計算的錯誤，卻也產生了一個副作用，即釜山場館內選手屏幕上的幀數和 ping值顯示(Ctl-V)會出現錯誤。顯示的 ping值會比實際 ping值低大約 13ms。這是因為，我們上述對延遲服務所做的配置更改，本質上是在目標值上直接添加了一個偏移量，以補償計算錯誤。這會對客戶端中記錄和顯示的 ping值應用偏移量產生下游效應(稍后我們會詳細分析這點)。其結果是外部客戶端顯示的數字將比實際 ping 低 13 ms左右。雖然這個結果不是完美的，但當時我們認為確保同等競賽環境里的對等延遲是一件更重要的事情，即便這意味著釜山場館外顯屏幕會顯示錯誤的數值。

下一步措施，以及一個困難的現實

既然我們已經知道如何準確測量真正的延遲，并找到了一個通過更改配置能夠補償這個計算錯誤的解決方法，我們馬上準備了一個計劃進行修正部署，并準備向選手和粉絲溝通，說明之前出現的問題。

但當我們明白了問題所在，我們卻面臨著一個困難的現實。

我們意識到，在場館內的選手之前都是在高于35ms范圍 的網絡下進行比賽的，但在上海遠程參賽的隊伍，卻是在實際的35ms范圍內進行比賽的——35ms左右是釜山至上海的自然網絡延遲 。我們沒有做到公平競爭原則下的延遲對等。

我們需要立即告知隊伍。唯一的問題是，這個差異是否大到足以需要重賽。這是一個賽事運營的決定。經過估算，由于計算錯誤，前三個比賽日中釜山和上海的真實延遲差值大約在15 - 20ms 之間。這也讓我們最終做出一個艱難的決定，即使用更新后的配置，將三場受影響的比賽進行重賽，以確保競賽公平性。

理解ping值的顯示數字

在我們決定重賽早期比賽之后，我們知道我們還有很多工作要做。這意味著重新制定賽程，并與隊伍聯系，以確保他們了解正在發生的事情和原因。 這還意味著我們準備對比賽場館的服務器和數據中心服務器的配置進行更改，并重新運行所有測試以驗證更改是否正確運行。 我們還邀請職業選手前往比賽現場測試新設置下的服務器，多次檢查我們是否解決了這個問題。 我們甚至進行了盲測，讓職業選手在不知情的情況下嘗試兩種配置，并讓我們知道哪一種感覺像 35ms 延遲，哪一種感覺不止于此。

很不幸的是，我們并沒有及時且清晰地將這個外顯誤差向各位玩家以及轉播團隊溝通。

不久之后，我們的粉絲就指出了對韓國隊伍來說似乎是不公平的優勢。 我們開始看到粉絲發布一張顯示 22ms 延遲的屏幕截圖，而不是預期的約 35ms 的延遲。

這是我們必須回應的問題。

如之前提到的，延遲服務中漏洞的解決方法是添加到配置文件中的補償偏移值。 此偏移量對屏幕顯示的數值有副作用：

在上海的選手屏幕顯示的 ping值是正確的

在釜山的選手屏幕顯示的 ping值不正確，并且比實際延遲低約 13ms

這里重申一下原因，上海的屏幕顯示的ping值是正確的，因為當他們使用延遲工具時，他們已經達到了35 ms左右的延遲目標，因此延遲工具并不會為他們的體驗添加補償。而釜山的屏幕數字顯示不正確的原因是，在引擎中引入了延遲配置偏移量，它糾正了引擎中的延遲錯誤計算，讓實際延遲能夠達到35ms這個目標。但這將產生讓日志和ping值顯示偏移約 13 ms 的下游效應。

為了驗證這一點，我們從 30 多個進程中收集了客戶端日志，并繪制了屏幕上顯示的 ping/延遲數據圖表(如下示意)。

上圖只顯示了RNG相關的比賽，豎軸是顯示的ping值。 與上一個部分顯示數據的圖表不同，在這種情況下，橫軸代表離散的數據集，每個游戲都有一個數據集。 因此，每個綠色方塊都是報告的 ping值的直方圖，這些都是從客戶端日志中讀取一個選手的一場比賽的數據。 正如這里可以看到的，這些值存在一些波動，并且值都在 33 ms 和 39 ms 之間的范圍內。 這符合 RNG 的 35ms +/- 5ms 的已知自然延遲值。

下一個要查看的數據集是釜山選手在配置更改之前和配置更改之后的客戶端日志(如下示意)。

在上圖中，我們過濾了數據，僅顯示在釜山比賽場館進行的比賽。左側顯示的游戲是配置更改之前進行的比賽。正如這里可以看到的，顯示數值在 33 到 39ms 之間，范圍為 35ms +/- 5。我們也知道，通過更新“端到端”的監測工具進行檢驗以及結合選手報告，真正的延遲和所顯示的不同。

在圖表的右側，我們看到在使用能夠提供相同真正延遲的新配置后，顯示延遲數值介于 19 ms和25 ms之間-通常在22 ms +/- 5 ms的波動范圍以內。將這兩個值相減可以看出，顯示ping值中的偏移誤差是一致的，大約為13ms (35ms - 22ms = 13ms)。因此，在配置更改并解決實際延遲問題后，當釜山屏幕顯示ping值顯示 22 ms左右時，實際上真實延遲是 35 ms左右。

回到顯示 T1 與 SGB 比賽的屏幕截圖，這解釋了當時 Zeus 的屏幕顯示ping值為 22 ms左右，而在添加我們從實驗中得到的校正偏移值后，真正的延遲則是在 35ms左右。

結論

作為支持現場比賽的拳頭游戲電競技術團隊，我們一直竭盡所能地對比賽環境進行測試、檢查、再三檢查，以確保無虞。我們一直是以為職業選手創造同等競賽環境作為最高優先級。我們的目標是讓技術讓路，將舞臺留給運動和比賽本身。

我們也希望盡一切努力堅持競賽公平性，并為全世界的粉絲創造更好的觀賽體驗。任何計劃的修改，都可能帶來風險。但我們希望做到最好，來規避風險，并為選手和粉絲創造最好的體驗。

但在這次整件事情中，我們未能及時發現的漏洞影響了比賽，我們對ping值顯示錯誤問題的溝通也不夠及時透明。我們再次對此造成的問題和困擾致以深深的歉意。

我們深知這幾天對大家并不容易，因此我們正在進行額外的測試和驗證，以確保后面的對抗賽和淘汰賽階段順利無虞。我們還要感謝隊伍和選手們在此期間表現出的堅韌，盡管有諸多障礙，他們仍為我們解決這些問題提供了寶貴的反饋。雖然我們不敢妄言以后永遠不會再出現任何可能影響比賽的程序問題，但我們承諾一定從這次事件中吸取教訓，更及時地與隊伍和粉絲進行溝通，并持續地為良好的賽場環境做出不懈的自我監督和自我改進。

標簽：