斷線卡頓怎麼辦？騰訊遊戲學院專家談網路遊戲同步技術

編者按：網路遊戲同步技術影響著玩家的體驗，如果沒有做好，可能會使玩家大量流失。騰訊遊戲學院專家Donald，在本文對網路遊戲同步技術進行了系統性的介紹，希望對大家有所幫助。

本文會就網路遊戲同步技術進行概述，包括如下內容：著名遊戲網路同步方案彙總、網路傳輸協議（Network Transport Protocol）、網路同步模型（Network Model）、網路拓撲結構（Network Topology）、網路環境質量。

著名遊戲網路同步方案彙總

下表為本人彙總的各著名遊戲的網路同步方案，已盡力新增引用來源。

通過該表，讀者可嘗試思考：為什麼他們會採取這樣的方案？找找看有否什麼規律？相信看完下文，應該可以找出答案。

注：本文的鎖步同步（Lockstep）特指只同步操作的確定性鎖步同步（Deterministic Lockstep）。本文不討論快照同步（Snapshot Synchronization、Snapshot Interpolation），認為其等同於狀態同步（State Synchronization）。


網路傳輸協議（Network Transport Protocol）

本文中的網路傳輸協議（Network Transport Protocol），主要是指UDP協議和TCP協議。

在TCP/IP協議族（網際網路協議套件，Internet Protocol Suite）中，UDP和TCP位於傳輸層（Transport Layer），它倆都獨立依賴於更底一層網路互連層（Internet Layer）中的IP協議（網際協議，Internet Protocol）。

Berkeley套接字（Berkeley Sockets）是進行UDP或TCP通訊的標準API，屬於POSIX標準，所以Socket、Berkeley Socket、POSIX Socket、BSD Socket，都指同一個東西。

通過Socket這個類及其方法，很簡單就能進行UDP或TCP通訊。

通過分析協議報頭（Header），可快速精確知道該協議增加了哪些功能。

UDP報頭如下：


UDP在IP之上，增加了埠（Port）的概念，收發雙方從而能通過約定好的幾個埠來進行不同功能的通訊；增加了校驗和以增加了一定的校驗能力。

所以也能看到UDP其對於網路遊戲來說，和IP幾乎有很相似的特性：

不可靠不保序傳輸（Unsequenced Unreliable Transmission），即傳輸不保序，也不確保可達，某個具體資料包在傳輸的過程中，是可能丟失的；也可能資料包到達了，但資料出錯從而校驗失敗，也被Socket丟棄掉；
傳輸快，多虧了不可靠，所以Socket不會浪費時間和頻寬，對丟失的資料包進行重傳；
應用通過Socket成功拿到的UDP資料包保證是正確的；
連線快，因為根本就無連線。多虧了不可靠，所以收發雙方每次通訊都是無狀態的，所以通訊前不需建立連線；
簡單，上層應用能按需實現額外的傳輸特性（QoS），比如保序不可靠、可靠不保序、可靠保序、最新狀態傳輸（Most Recent State）、快速冗餘傳輸（Quickest Possible Delivery），等；
報頭小，節省頻寬。

TCP則複雜很多，TCP的報頭如下：


除了也有埠、校驗外，TCP主要額外提供了：

• 保序可靠傳輸（Sequenced Reliable Transmission），通過報頭Sequence number、Acknowledgement Number、Window Size等欄位來實現；
• 流量控制（Flow Control），通過報頭的Window Size實現，接受者把自己的期待流量提示給傳送者，防止傳送方以過快的速度傳送資料給接收方；
• 擁塞控制（Congestion Control），通過報頭的Sequence number、Acknowledgement number等欄位，以及通過Timer機制實現，據此收發雙方可判斷資料包丟包，而推斷出當前網路是否擁塞，並採取一些措施來減緩資料傳送。
  

TCP本身足夠複雜，本文並不能細究他們的具體原理，僅簡述和網路遊戲同步相關的特性：

• 本身提供保序可靠傳輸，不需遊戲作額外工作，很適用於回合制遊戲、RPG等通訊頻率不高的遊戲型別；
• 傳輸慢，正因TCP本身對所有發出的資料包，都考慮保序可靠、流量控制、擁塞控制（包含了慢啟動（Slow-Start），而這些功能對於大部分遊戲型別，特別是快節奏（Fast Paced）遊戲是不適用的，因為這類遊戲通訊頻率高，要求低通訊時延，新發的資料包可能比已傳送的資料包更重要（比如遊戲狀態資料包，遊戲狀態經常改變，與其重傳舊狀態資料包，倒不如將其拋棄，趕快傳輸新的狀態資料包）；
• 連線慢，首次通訊需要進行著名的三次握手連線；
• 複雜且黑盒，難擴充套件；
• 報頭大，不適用於資料包數量多的情況。
  

綜上所述，大多網路遊戲採用UDP。

TCP更加適用於回合制等慢節奏遊戲。
另魔獸世界使用了TCP，且取得了輝煌的商業成功，故也有不少MMORPG也使用TCP，儘管如此，未見得TCP是最好的選擇。[9]

網路同步模型（Network Model）

最主要的網路模型是：鎖步同步（Lockstep）和狀態同步（State Synchronization）。

本文針對“幀”有以下兩種術語定義：

邏輯幀，在本文會被稱為Tick，遊戲在邏輯層面是離散的過程，即可以認為是一個邏輯幀一個邏輯幀地進行邏輯運算，邏輯幀號是指遊戲邏輯層面當前處於第幾幀；

渲染幀，在本文會被稱為Frame，遊戲在畫面呈現層面也是離散的過程，即可以認為是一幅畫面一幅畫面地呈現給玩家的，渲染幀號是指遊戲當前呈現的是第幾幅畫面；

遊戲的邏輯幀率和渲染幀率是互相獨立的，比如一個遊戲可以是20幀每秒的邏輯幀率、60幀每秒的渲染幀率。

遊戲邏輯是一個邏輯幀一個邏輯幀地持續離散進行的，可以抽象為：


遊戲在第0個邏輯幀時，根據玩家資訊P和遊戲配置C，進行初始化運算g，得出初始化狀態集合S0；遊戲在第k個邏輯幀時，根據前一個狀態集合Sk-1和遊戲配置C，根據第k幀收到的外部變化原因集合Ik，進行邏輯t運算，得出第k個邏輯幀新的遊戲狀態集合Sk。

I是遊戲狀態變化的根本原因的集合，往往是各個玩家操作。

S是遊戲狀態的集合，由眾多狀態子集組成，其中有以下2個重要子集定義：


其中O為一些能被玩家所明顯觀察到的物件的狀態集合，M為一些可用於推導最終狀態的中間狀態集合。

在網路同步時，稱從客戶端發出資訊進行網路傳輸的過程為上行，稱客戶端經過網路傳輸收到資訊的過程為下行，則鎖步同步的本質是，上下行都僅包含遊戲外部變化原因集合Ik；狀態同步的本質是，下行僅包含遊戲運算得出的結果狀態子集Ok，上行包含Ik和/或狀態子集Mk。

注：本文的鎖步同步特指只同步操作的確定性鎖步同步（Deterministic Lockstep）。本文不討論快照同步（Snapshot Synchronization、Snapshot Interpolation），認為其等同於狀態同步。

網路同步模型簡史

1990年代便已有針對每一步（step、turn）進行停止等待（stop-and-wait-type）的網路同步方式，即客戶端一步一步地把自己的資訊發給其他客戶端，這些資訊可以是客戶端的本地網路物件的狀態，也可以是玩家操作[13][14]。

同期，P2P（見下網路拓撲結構一節）是更為盛行的網路連線拓撲結構。但P2P的停止等待同步方案有lookahead-cheating型別的外掛，比如使用外掛的客戶端A在第k步時故意等到別人的第k步資訊都到達了之後，才進行邏輯運算併傳送自己的第k步資訊，等於客戶端A總是偷窺別人的遊戲決策之後才作出自己的決策，從中獲取到不公平的先手利益。

所以，2001年，Nathaniel Baughman和Brian Neil Levine在此基礎上，提出鎖步同步（Lockstep）[14]以對抗該外掛。每個客戶端在傳送第k步的明文資訊之前，先針對明文資訊進行加密計算生成“預提交雜湊值（commitment hash）”併傳送給其他客戶端，待客戶端接收到第k步的所有客戶端的預提交雜湊值之後，才傳送自己第k步的明文資訊給其他客戶端，等到收到所有其他客戶端的第k步明文資訊後，本客戶端為這些明文資訊逐一生成明文雜湊值並和預提交雜湊值對比，如果發現客戶端B的明文雜湊值和預提交雜湊值不等，則代表客戶端B是外掛。

至此，鎖步同步是既可以同步客戶端玩家操作、也可以同步客戶端權威網路物件的狀態。所以也並不要求確定性。

然後，同樣也是2001年，Mark Terrano和Paul Bettner在帝國時代（Age of Empire）遊戲中為了解決遊戲中海量網路實體的問題，基於鎖步同步，方提出了確定性鎖步同步（Deterministic Lockstep）[15]，即每一步同步的，僅僅只有玩家運算元據，而不包含網路物件資料。

另外，1999年，Christophe Diot和Laurent Gautier提出了Bucket Synchronization[13]，即把時間按固定時長（約40ms）劃分為Bucket，該時長內的資料歸屬於該Bucket。在一開始時有一個較長的播放時延（Playout Delay，約100ms），用於等待其他客戶端的Bucket資料傳輸到達。沒及時到達的資料不會被直接應用，但也可以儲存起來用於可能發生的外插（Extrapolation）比如航位推測（Dead Reckoning）。

其Bucket，事實上即邏輯幀（Tick）的概念。


最後，2003年，Ho Lee等人針對上述鎖步同步的每一步的時延都較大的缺點進行優化，借鑑Bucket Synchronization，提出了Pipelined Lockstep[16]。

至此，現在為大家所理解的：操作同步、不等待超時玩家的操作的確定性鎖步同步，終於成型。

總而言之，每一步都停止等待的網路同步很早就有，卻缺個簡短的名字。為了安全性提出的“Lockstep”方案使用廣泛，逐漸成為停止等待同步的代名詞。翻譯成中文時，引入了時間幀的概念Bucket Synchronization也和Lockstep已經結合起來使用，便將“step”譯為幀，稱為“幀同步”。然後更狹義的確定性鎖步同步用得越來越多，大家也逐漸把“Deterministic Lockstep”簡稱為“Lockstep”，所以，確定性鎖步同步口頭交流中更常被簡稱為“幀同步”，有時也會被稱為“操作同步”。

所以，本文也把確定性鎖步同步簡稱為鎖步同步。

鎖步同步（Lockstep）

因為鎖步同步只同步變化的原因Ik，所以要求各個客戶端的運算邏輯g、t是嚴格確定性（Deterministic）的，所有客戶端才能算出嚴格一致的結果Sk。如果在計算過程中包含了一絲不確定的因素，即會導致各個客戶端運算Sk時有一絲的誤差，那麼接下來的邏輯幀誤差會越來越大，導致蝴蝶效應，從而最終各個客戶端看到的結果狀態完全不一樣了。

以著名鎖步遊戲王者榮耀為例，假設你的客戶端和其他正確客戶端已經發生不一致，其他玩家在正確客戶端作出的合理操作，到達你已經狀態不一致的客戶端做邏輯演算時，卻變得不一樣的狀態結果，這個結果很可能是不合理的，所以你很可能會看到其他玩家英雄都奇怪地亂跑，甚至跑到塔下送死，或者對著空氣放技能，等。

遊戲要做到嚴格確定性，須做好一些事情：

• 不使用浮點數而使用定點數，或限定各客戶端所執行的硬體及作業系統從而浮點數的運算是一致的；
• 確定性的隨機數機制；
• 確定性的容器及演算法（增加、移除、排序等）；
• 隔離和封裝邏輯層，以防止其他不確定性的呼叫；
• 如需，則也須做到確定性的物理機制、導航機制、動畫骨骼機制等；
• 排查所有引起異常（exception）的邏輯。
• 對鎖步同步遊戲來說，不同步造成的遊戲體驗是極差的，偶現的不同步問題是極為頭痛的， 因此制定檢測不同步的管線流程對鎖步同步遊戲來說是至關重要的，比如幀狀態雜湊對比、靜態程式碼掃描分析、幀級別甚至函式級別的高效能日誌、外網不同步率統計，等。
  

狀態同步（State Synchronization）

因為狀態同步只同步遊戲運算得出的結果狀態Sk，所以需要有機器來進行權威（Authoritative）的狀態計算，並傳輸給其他機器，其他機器都將採納接收到的狀態。

本文只討論權威機器只有一部的情況。視乎具體網路拓撲結構，這部權威機器會被稱為伺服器（Server）或主機（Host），其他沒有權威的機器稱為客戶端（Client）。

所以，狀態同步，口頭交流中也常不太精確地被稱為“CS同步（Client-Server）”。
包括Halo、Unreal、Unity、Overwatch等，幾乎所有著名狀態同步的技術實現，都最終參考了Mark Frohnmayer和Tim Gift於1998年釋出的The TRIBES Engine Networking Model[1]一文進行實現。

狀態同步開發過程中最基礎也最重要的是，不管客戶端網路物件當前處於什麼狀態，它都要做到能正確地完全退出舊狀態，退出後不能殘留舊狀態的邏輯層效果，並正確地進入伺服器告知的新權威狀態，從而帶來新狀態的邏輯層效果。

也要避免以非狀態同步的方式同步權威狀態，比如伺服器只傳輸Ik給客戶端（而不傳輸Sk），讓客戶端在本地計算出網路物件的新狀態Sk。這可能會帶來伺服器客戶端之間狀態不一致。比如某個網路物件在第k個邏輯幀發生了Ik從而進入Sk，且之後S都不再改變，那麼伺服器只會在第k幀才會傳送Ik；之後若客戶端因斷線重連或實時死亡重播等原因導致該網路物件狀態在客戶端被重置為S0，但當前伺服器邏輯幀已大於k，伺服器不會再傳輸Ik給客戶端，那麼該網路物件在客戶端裡就錯誤地一直停留在S0了。

之前在鎖步同步討論到的確定性指的是“嚴格的”確定性。在討論狀態同步時，偶爾也會提及“不嚴格的”確定性（比如[4]的Q/A階段最後一個問題），此類確定性只要求客戶端伺服器之間滿足“足夠的”確定性，以便客戶端能夠比較準確地進行預表現即可，因為客戶端最終會採納伺服器的狀態，修正累計的誤差。

鎖步同步和狀態同步的對比


網路拓撲結構（Network Topology）

網路拓撲結構，是指參與遊戲的機器的網路連線方式，主要包括對等結構（Peer-to-Peer，P2P結構）和主從結構（Client-Server，CS結構）。

P2P結構是網狀結構（Mesh Topology），遊戲中的P2P一般是全連線（Full Connected）的網狀結構，如下所示。P2P結構中所有客戶端兩兩相連，連線數為O(n2)，地位平等，功能一致。


CS結構是星狀結構（Star Topology），如下所示。CS結構有至少一部機器為伺服器（Server），本文只討論只有一部伺服器或主機的情況，其和其他客戶端為主從關係，客戶端只和伺服器連線，客戶端之間不會相連，連線數為O(n)。

當執行伺服器的機器只用於邏輯運算遊戲狀態，只用於下發狀態給客戶端，和客戶端完全分離的“Headless”機器時，該伺服器稱為Dedicated Server；當執行伺服器的機器同時也在執行客戶端運算，也被玩家所控制時，該伺服器稱為Listen Server，也稱為Host。


兩種網路拓撲結構的對比如下：


網路同步模型和網路拓撲結構是不同的概念，所以它們的組合情況如下表所示：


網路環境質量

評估網路環境質量，主要包括時延（Latency）、丟包（Packet Loss）、頻寬（Bandwidth）。

針對日常各種主要使用環境，有以下網路環境質量統計。


網路時延主要有2種評估數值，Ping和RTT（Round Trip Time）。

Ping，指網路連線的兩個端之間的訊號在網路傳輸所花費的時間，Ping描述了“兩部機器之間的網路傳輸時延是多少？”。比如從A端作業系統發出訊號時開始計時，到達B端作業系統並立刻返回響應訊號，返回到A端作業系統後停止計時，該時長為Ping。

RTT，Round Trip Time，一般情況下可認為等於Ping，但在本文中，RTT = Ping + WaitTime + ProcessTime，即RTT包含了Ping、兩個端的處理訊號前的等待時間、兩個端處理訊號的時間，這樣的RTT描述了“玩家實際體驗到的遊戲時延是多少？”。比如從A端遊戲邏輯發出訊號開始計時，在A端可能等待一段時間後，也可能處理一些其他邏輯後，方呼叫作業系統發出訊號，經網路傳輸到達B端作業系統後，B端也可能有類似的等待時間和處理其他邏輯時間，也包括處理該訊號本身的時間，然後才發出響應訊號，響應訊號經過網路傳輸到A端作業系統後，再來一些類似的等待處理時間，最終A端遊戲邏輯接收到響應訊號方結束計時，該時長為RTT。

Ping值和RTT值，對一般網路遊戲而言，20ms為優秀，50ms為正常，100ms為一般，200ms為差。

4G網路自身時延約30ms~40ms，5G網路自身時延為6~10ms，骨幹網在大陸內部互連時延約20ms。即4G時代4G接入本身是網路時延瓶頸，5G時代骨幹網為網路時延瓶頸。

上海與各國際城市的骨幹網時延（ms）如下表，詳情可參閱[17]。


網路丟包直接原因主要是因為無線網路和/或擁塞控制，但根本原因比較多元和複雜，故統計略。

對一般網路遊戲而言，網路丟包率2%以下為優秀，5%為一般，10%以上為差。

對比傳統應用，網路同步涉及到的頻寬較小，正常情況下頻寬不會成為網路遊戲同步中的瓶頸（除非是雲遊戲:p）。

注意傳統網路中網路頻寬常見為b/s（Bit per Second），但本文采用B/s（Byte per Second）。

一般鎖步同步遊戲需要2~4KB/s，快節奏狀態同步遊戲需要5~10KB/s。

常見網路遊戲相關的網路頻寬如下表[18][19]：


結論

本文就網路傳輸協議（Network Transport Protocol）、網路同步模型（Network Model）、網路拓撲結構（Network Topology）進行了系統性的介紹，並列舉了一些網路遊戲所選方案的情況，及方案對比。也介紹了網路同步的一些歷史，和網路質量評估指標。

本文並未就實現原理進行細節介紹，未來將會以實際專案為例，介紹UDP、狀態同步、Client-Server的技術細節。

引用


[1] Mark Frohnmayer, Tim Gift, "The TRIBES Engine Networking Model or How to Make the Internet Rock for Multi player Games", 1998. Available: https://www.gamedevs.org/uploads/tribes-networking-model.pdf [Accessed: 2019-01-27]
[2] Glenn Fiedler, "State Synchronization Keeping simulations in sync by sending state", 2015, Available: https://gafferongames.com/post/state_synchronization/[Accessed: 2019-01-27]
[3] Joshua Glazer, Sanjay Madhav, "Multiplayer Game Programming", Addison-Wesley, 2015.
[4] Tim Ford, "Overwatch Gameplay Architecture and Netcode", GDC, 2017.
[5] Xavier Guilbeault, Frederic Doll, "Deterministic vs Replicated AI Building the Battlefield of For Honor", GDC, 2017.
[6] Matt Delbosc, "Replicating Chaos Vehicle Replication in Watch Dogs 2", GDC, 2017.
[7] Jared Cone, "It IS Rocket Science! The Physics of 'Rocket League' Detailed", GDC, 2018.
[8] Battle(non)sense, "Netcode & Input Lag Analyses", 2017. Available: https://www.youtube.com/playlist ... jhB63KMDTOT5sJ0vWy8[Accessed: 2019-02-08]
[9] Chen-Chi Wu, Kuan-Ta Chen, Chih-Ming Chen, Polly Huang, and Chin-Laung Lei, "On the Challenge and Design of Transport Protocols for MMORPGs". 2019. Available: http://www.iis.sinica.edu.tw/~swc/pub/tcp_mmorpg.html [Accessed: 2019-02-08]
[10] David Aldridge, "I Shot You First: Networking the Gameplay of HALO: REACH", GDC, 2011. Available: https://www.youtube.com/watch?v=h47zZrqjgLc [Accessed: 2016-07-02]
[11] Maksym Kurylovych, "Lockstep protocol", University of Tartu, 2008. Available: http://ds.cs.ut.ee/courses/course-files/Report%20-2.pdf [Accessed: 2019-02-11]
[12] Glenn Fiedler, "What Every Programmer Needs To Know About Game Networking A short history of game networking techniques", 2010. Available: https://gafferongames.com/post/w ... ut_game_networking/ [Accessed: 2019-02-11]
[13] Christophe DIOT, Laurent GAUTIER, "A Distributed Architecture for Multiplayer Interactive Applications on the Internet", IEEE, 1999. Available: https://www.cs.ubc.ca/~krasic/cp ... ot99distributed.pdf[Accessed: 2019-02-12]
[14]Nathaniel E. Baughman, Brian Neil Levine, "Cheat-Proof Playout for Centralized and Distributed Online Games", IEEE INFOCOM, 2001. Available: https://pdfs.semanticscholar.org ... 6056868791854fe.pdf[Accessed: 2019-02-12]
[15] Mark Terrano, Paul Bettner, "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond", 2001. Available: http://www.gamasutra.com/view/fe ... _a_288_network_.php[Accessed: 2019-02-12]
[16] Ho Lee, Eric Kozlowski, Scott Lenker, Sugih Jamin, "Multiplayer Game Cheating Prevention With Pipelined Lockstep Protocol", 2003. Available: http://www.ekozlowski.com/assets ... ting-prevention.pdf[Accessed: 2019-02-12]
[17] "Internet Backbone Network Latency". Available: https://www.dotcom-tools.com/internet-backbone-latency.aspx [Accessed: 2019-02-15]
[18] "List of interface bit rates". Available: https://en.wikipedia.org/wiki/List_of_interface_bit_rates [Accessed: 2019-02-15]
[19] "5G", Available: https://en.wikipedia.org/wiki/5G#Performance_targets[Accessed: 2019-02-15]

關於騰訊遊戲學院專家團


如果你的遊戲也富有想法充滿創意，如果你的團隊現在也遇到了一些開發瓶頸，那麼歡迎你來聯絡我們。騰訊遊戲學院聚集了騰訊及行業內策劃、美術、程式等領域的遊戲專家，我們將為全世界的創意遊戲團隊提供專業的技術指導和遊戲調優建議，解決團隊在開發過程中遇到的一系列問題。


專案指導合作請聯絡微信：18698874612