拳頭游戲發(fā)文正式回應(yīng)2022季中冠軍賽中Ping值問題！

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

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

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

　　這引發(fā)了另一個設(shè)想…如果日志的延遲測量顯示良好，但體驗(yàn)相反，那會不會是日志出了問題？會不會是我們測量延遲的方式有問題？

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

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

　　有了這個新工具，我們就能在實(shí)驗(yàn)室中進(jìn)行測試，看看能不能重現(xiàn)選手們的問題。

　　我們做的第一件事，就是在不運(yùn)行延遲服務(wù)下，設(shè)置一個基準(zhǔn)線。因?yàn)槲覀冇衼碜怨卜?wù)器上無數(shù)小時的玩家數(shù)據(jù)，我們相信服務(wù)器沒有任何漏洞，因此我們以它們來做參照組。  第一個設(shè)置基準(zhǔn)線的實(shí)驗(yàn)?zāi)M了在韓國參賽的隊伍和在中國參賽的隊伍均從互聯(lián)網(wǎng)接入服務(wù)器的場景。

實(shí)驗(yàn)一：關(guān)閉延遲服務(wù)工具，對比韓國和中國的網(wǎng)絡(luò)

　　這類實(shí)驗(yàn)的數(shù)據(jù)十分復(fù)雜，這里我們將其整理之后用圖表的形式展現(xiàn)出來，可以幫助大家理解我們所看到的情況。

　　如果你沿著橫軸（游戲時間）看，會發(fā)現(xiàn)一開始（圖表左側(cè)）的延遲值很低。幾分鐘后（圖中從左到右的中間部分），我們開始模擬較高ping值的網(wǎng)絡(luò)（例如：上海）。我們可以看到，豎軸上的延遲在上升。這和預(yù)想的完全一樣。在低ping值網(wǎng)絡(luò)下，延遲較低；在高ping值網(wǎng)絡(luò)下，延遲較高。

　　第一個實(shí)驗(yàn)，作為參照組，說明用新工具測量的結(jié)果是符合我們預(yù)期的。這是個好的開始。

　　下一個實(shí)驗(yàn)，我們會用相同的步驟進(jìn)行檢測，但這次我們開啟延遲服務(wù)工具。

實(shí)驗(yàn)二：開啟延遲服務(wù)工具，對比韓國和中國的網(wǎng)絡(luò)

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

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

　?。?)問題是真實(shí)存在的，且確實(shí)與選手們報告的情況相符

　　（2)我們自己可以在實(shí)驗(yàn)室重現(xiàn)這個問題

　?。?)問題很可能就出現(xiàn)在人工延遲工具上

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

　　這便解釋了目前的一系列問題。為什么日志不顯示這些問題：因?yàn)檫\(yùn)算錯了。為什么場館比網(wǎng)絡(luò)服務(wù)器體感還差：因?yàn)榄h(huán)境 ping值越低，這個漏洞就越明顯。這也解釋了為什么在釜山現(xiàn)場的選手覺得比賽體感延遲比屏幕上顯示的約 35ms差多了：因?yàn)閷?shí)際延遲確實(shí)高于 35ms。

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

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

　　既然我們有了辦法來模擬環(huán)境，也有了辦法來使用自研工具測試實(shí)際延遲，那么就可以通過調(diào)節(jié)配置，得到我們想要的結(jié)果。

　　以下圖表顯示了與兩個實(shí)驗(yàn)相同的網(wǎng)絡(luò)環(huán)境，但這一次使用了將錯誤修正后的配置文件。

實(shí)驗(yàn)三：在正確的配置下啟用延遲服務(wù)工具