拳頭遊戲8000字長文回應：釜山選手電腦屏幕上顯示的是錯誤的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韓國聯賽。同樣這也意味着這個服務器有無數小時的運行數據來驗證其網絡的良好連通性和架構的可信賴性。所以當至少有一支隊伍需要遠程參賽時，用這個節點是合理的。但接下來的問題是，是應該在所有比賽中使用它，還是隻針對遠程比賽使用。這便引出了策略二：最小化網絡風險。 

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

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

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

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

最合理方案

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

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

找尋漏洞

引起這些問題的原因還是不清楚。由於架構監控工具並沒有彙報錯誤，但我們卻收到報告説比賽很卡。我們缺少特定漏洞或特定遊戲內情況來定性。於是我們又回到了基礎問題上。哪些數據是可用的？我們手裏都有哪些日誌？我們能收集到什麼信息？

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

 

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

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

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

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

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

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

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

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

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

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

如果你沿着橫軸（遊戲時間）看，會發現一開始（圖表左側）的延遲值很低。幾分鐘後（圖中從左到右的中間部分），我們開始模擬較高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值顯示錯誤問題的溝通也不夠及時透明。我們再次對此造成的問題和困擾致以深深的歉意。 

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