參考資料：
https://gafferongames.com/ Gaffer on games
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking 起源引擎網絡同步資料
http://fabiensanglard.net/quake3/network.php quake3網絡部分代碼分析
最近在嘗試在Unet的Reliable UDP的基礎上，配合Entitas做一個快節奏多人聯機游戲，熟悉一下相關的技術。
現在國內的資料指出，網絡同步可以分為兩大類，分別是幀同步和CS架構的各種同步
幀同步
幀同步大部分情況下應用於RTS游戲，各個客戶端基於p2p連接，沒有服務器。
幀同步中，客戶端與客戶端之間互相發送一幀中的“用戶輸入”。當一個客戶端收到其余客戶端的所有輸入之后，就會根據這些輸入進行這一幀的模擬。因此游戲中的延遲跟網絡狀況最差的那個玩家有關。
這樣一來，為了保證每個客戶端的游戲進程完全相同，每個客戶端中都要保存完整的游戲狀態。這也是為什么魔獸3、星際2、風暴英雄等一眾幀同步游戲的全圖掛無法從根本上禁止的原因。（Dota2是基於狀態同步的，所以干掉全圖掛是完全沒問題的）同時要保證不同的電腦上，同樣的輸入產生完全同樣的輸出。
在流量方面，幀同步需要每個客戶端之間兩兩發送指令，因此網絡流量隨着玩家人數提升增長的非常快。這也是為什么rts游戲中的玩家人數上限較低。
CS架構同步
CS架構引入了一個權威服務器作為各個客戶端連接的中心。服務器運行着最核心的邏輯，接收客戶端的命令，同步各個客戶端的表現。
Gaffer on games中講了兩種同步，分別是快照同步和狀態同步。在國內的資料中，一般都統一認為是狀態同步（只是同步的內容不同而已）。
快照(Snapshot)同步
快照同步是quake3和起源引擎采用的架構。特點是服務器進行游戲邏輯的模擬，客戶端只負責呈現畫面。（當引入客戶端預測后，就是另一回事了）
快照同步中，有一個用於模擬游戲的服務器和若干客戶端。
在客戶端上，客戶端每幀向服務器發送指令信息，如移動、開火等。服務器發回的則是當前游戲世界的所有實體的“快照”，即當前這一刻的狀態。
這樣的架構好處在於，每個客戶端的延遲情況只和自己的網絡情況有關，同時隨着玩家人數上升，網絡負載提升的只有服務器而已（以及多出來的那個玩家的實體）。
同時服務器也可以有選擇的發送快照的內容，比如不發送戰爭迷霧中的單位的信息，可以很大程度上避免玩家的作弊。
另外因為客戶端收到的是快照，如果直接根據快照去更新游戲的話，游戲會變得一卡一卡，除非快照的頻率非常高。
為了解決這個問題，可以引入客戶端的快照緩存。客戶端收到快照后並不立即渲染，而是將其放入一個緩存。通過設定一個延時值，比如0.1秒，客戶端的渲染會渲染當前客戶端時間減去0.1秒，獲取這個時間兩側的快照（一個快照早於這個時間，另一個晚於這個時間），去做內插值。（當因為丟包之類的原因找不到快照用於插值時會做外插值）。
快照同步有許多優化的點，比如狀態壓縮等，具體就不細講了。
狀態同步
狀態同步類似於快照同步，但是客戶端不再只負責畫面呈現，而是也會進行游戲邏輯的模擬。只在收到服務器發來的游戲狀態時對游戲進行糾正。
此時，因為客戶端本地也有一定的模擬邏輯，服務器可以只發送一些重要物體的快照，而將不重要的物體的信息交給客戶端自行去計算。