聯(lián)機游戲網(wǎng)絡(luò)相關(guān)內(nèi)容總結(jié)
作者：ProcessCA
本篇難度：★★★☆☆
（請注意，本文是一次技術(shù)總結(jié)，對網(wǎng)絡(luò)不太熟悉的童鞋食用前請做好心理準備）
大渣好。
最近整理了一下網(wǎng)絡(luò)游戲相關(guān)的技術(shù)，主要由三個部分構(gòu)成：
1.網(wǎng)絡(luò)傳輸協(xié)議：HTTP，UDP，TCP
2.同步策略：狀態(tài)同步，幀同步，還有介于兩者之間的同步策略
3.序列化工具：Protobuf，自制工具
正是以上技術(shù)構(gòu)成了網(wǎng)絡(luò)游戲開發(fā)的基礎(chǔ)，水平有限，歡迎指正。
在宏觀的網(wǎng)絡(luò)世界中，不同地區(qū)的電腦依靠互聯(lián)網(wǎng)設(shè)施與自帶的網(wǎng)卡就可以進行網(wǎng)絡(luò)通信，因為互聯(lián)網(wǎng)本身就由一系列協(xié)議組成，在OSI（開放系統(tǒng)互聯(lián)）模型的基礎(chǔ)上，TCP/IP精簡了不少東西，從7層模型變?yōu)?層模型，遵循這套協(xié)議的機器就可以實現(xiàn)網(wǎng)絡(luò)通信。
網(wǎng)絡(luò)傳輸協(xié)議
游戲開發(fā)中我們只需要關(guān)注TCP/IP協(xié)議族中的應(yīng)用層與傳輸層。
應(yīng)用層提供了許多協(xié)議支持不同應(yīng)用的開發(fā)，比如通過瀏覽器訪問知乎用到了HTTPS協(xié)議，HTTPS是在HTTP基礎(chǔ)上加入了一層加密的協(xié)議。
在卡牌，跑酷這種弱交互游戲中，一般沒有實時對戰(zhàn)，偶爾請求服務(wù)器進行抽卡或者查看排行榜。可以借助應(yīng)用層的HTTP協(xié)議進行通信，HTTP協(xié)議基于請求-相應(yīng)模型，較為簡單，方便調(diào)試。
舉個HTTP協(xié)議在卡牌游戲中抽卡的例子：
1.客戶端向服務(wù)器發(fā)送Get或Post請求。
2.服務(wù)器接受到消息后進行抽卡邏輯。
3.服務(wù)器向客戶端發(fā)送請求的相應(yīng)。
4.客戶端接收到回應(yīng)消息后進行顯示操作。
然后就抽中了：
如果涉及到了實時交互的游戲，如RPG，MMO這種往往會使用傳輸層的TCP，UDP協(xié)議保證實時交互。具體選擇什么協(xié)議得看具體的項目，對傳輸帶寬與速度有嚴格要求推薦使用UDP，否則推薦使用TCP確?？煽啃?，降低開發(fā)成本。兩種協(xié)議搭配實現(xiàn)游戲中的不同網(wǎng)絡(luò)模塊也是十分常見的解決方案。
以下是兩種協(xié)議的對比：
同步策略
同步策略可分為狀態(tài)同步，幀同步與介于兩者之間的同步，關(guān)于狀態(tài)同步與幀同步，網(wǎng)上有大量的文章介紹，大家也有不同的理解。下面說說我的看法：
狀態(tài)同步：從字面意思上理解就是客戶端通過服務(wù)器同步自己的狀態(tài)。這個狀態(tài)指的是具體的數(shù)值。比如向服務(wù)器發(fā)送：我的旋轉(zhuǎn)角度改為(0, 90, 0)，我的坐標更新為(100, 100, 0)，這個過程服務(wù)器可以不進行邏輯判斷。
但是基于這種純粹的方式無法直接檢測客戶端發(fā)送數(shù)據(jù)的真實性，為了防止嚴重的作弊，可以對每次客戶端發(fā)送的數(shù)據(jù)進行范圍限制，確保結(jié)果在一個可接受范圍內(nèi)。
在利用UnityNetworking進行原型開發(fā)時用到的[SyncVar]特性，它的作用就是在網(wǎng)絡(luò)中同步指定字段的值。不得不說利用這種策略去堆疊游戲的原型的時候開發(fā)效率非常高。
幀同步：指每個客戶端只同步自己的操作。操作可以是：Q, W, E, R這種按鍵，也可以是鼠標滑動后產(chǎn)生的向量。操作上傳給服務(wù)器后，服務(wù)器直接轉(zhuǎn)發(fā)給其他的客戶端，在每個客戶端上進行邏輯運算，通過確保不同客戶端在相同的時間接受輸入，在相同時間得到相同的結(jié)果。
關(guān)于確保幀同步的準確性有兩種常用的方式：LockStep（鎖步）與樂觀的幀同步。
為了確保比賽結(jié)果的準確性，幀同步服務(wù)器上可以運行一套客戶端參與運算，結(jié)果以其為準。但是一個無法解決的問題是：邏輯運算變成了客戶端的事，我們完全可以通過修改客戶端本身實現(xiàn)作弊，比如開啟全圖視野，這種外掛服務(wù)器是無法預(yù)料的。
一般對于這種情況會依賴一些其他的工具驗證客戶端程序的完整性，內(nèi)存監(jiān)控等方式彌補這一點缺陷。但是無法根本上杜絕作弊，所以我們會在FPS，RTS這些應(yīng)用幀同步比較廣泛的游戲類型中看到各種全圖掛，透視掛層出不窮。
但是對于格斗游戲，采取幀同步算是最正確的做法。
格斗游戲?qū)ρ舆t敏感，一局游戲的所有信息對雙方的完全透明。所以基本上聯(lián)機格斗游戲都會選擇幀同步。
基于兩者之間：現(xiàn)實的網(wǎng)絡(luò)游戲中情況比較復(fù)雜，要防止客戶端作弊，最簡單有效的辦法是把游戲的大部分邏輯放在服務(wù)器上面。這時就不是客戶端說了算，客戶端只能發(fā)送一些操作指令比如：我要向左轉(zhuǎn)90度，跑向一個目標點。
服務(wù)器收后客戶端的指令后進行邏輯運算，然后把結(jié)果同步給所有客戶端。這樣的好處顯而易見，客戶端沒有辦法直接修改數(shù)據(jù)，基本上防止了作弊。
但是缺點也明顯：就是服務(wù)器壓力大，流量消耗大。特別是針對大型網(wǎng)游，會采取一系列優(yōu)化措施保障服務(wù)器的穩(wěn)定。
比如魔獸世界主要采用這種方式進行同步：
序列化工具
在這里要說的一點是關(guān)于序列化工具首推的是Protobuf，因為其序列化效率高，易用，跨語言的特性使得protobuf在游戲開發(fā)中有著十分廣泛的應(yīng)用。如果有能力自己實現(xiàn)一套序列化工具也是可以的，用C#的API就可以做到：
using?System.Net;using?System.Net.Sockets;using?System.IO;using?System.Runtime.Serialization.Formatters.Binary;using?System.Text;/// <summary>/// 網(wǎng)絡(luò)工具類 <see langword="static"/>/// </summary>public?static?class?NetworkUtils{
????//序列化：obj -> byte[]
????public?static?byte[]?Serialize(object?obj)
????{
????????//對象必須被標記為Serializable
????????if?(obj?==?null?||?!obj.GetType().IsSerializable)
????????????return?null;
????????BinaryFormatter?formatter?=?new?BinaryFormatter();
????????using?(MemoryStream?stream?=?new?MemoryStream())
????????{
????????????formatter.Serialize(stream,?obj);
????????????byte[]?data?=?stream.ToArray();
????????????return?data;
????????}
????}
?
????//反序列化：byte[] -> obj
????public?static?T?Deserialize<T>(byte[]?data)?where?T?:?class
????{
????????//T必須是可序列化的類型
????????if?(data?==?null?||?!typeof(T).IsSerializable)
????????????return?null;
????????BinaryFormatter?formatter?=?new?BinaryFormatter();
????????using?(MemoryStream?stream?=?new?MemoryStream(data))
????????{
????????????object?obj?=?formatter.Deserialize(stream);
????????????return?obj?as?T;
????????}
????}}
?
在之前的文章中有對Protobuf與C#序列化工具詳細的介紹，這里放出連接：
OK，關(guān)于網(wǎng)絡(luò)游戲的簡單總結(jié)就到這里，希望本文對在游戲開發(fā)的道路上的你有所啟發(fā)。
（順便說一下，之后的文章還是會搭配具體的游戲。）
想系統(tǒng)學(xué)習(xí)游戲開發(fā)的童鞋，歡迎訪問?http://levelpp.com/? ? ? ???????
游戲開發(fā)攪基QQ群：869551769? ? ? ? ?????
微信公眾號：皮皮關(guān)
