原文由碧曉寒楓發(fā)表于TesterHome社區(qū)项钮，點擊原文鏈接可與作者直接交流渣叛。

什么是游戲協(xié)議丈秩？

協(xié)議是網(wǎng)絡(luò)游戲前后端交互的實現(xiàn)方式。

游戲中協(xié)議的收發(fā)過程是怎樣的淳衙？

當(dāng)我們在進行游戲的時候蘑秽，我們點擊了某個按鈕進行某一種游戲行為饺著，這個時候，客戶端會按照跟服務(wù)器約定好的一些規(guī)則肠牲，將我們的游戲行為對應(yīng)的請求和參數(shù)通過網(wǎng)絡(luò)封包發(fā)送給服務(wù)器幼衰，服務(wù)端在收到這個請求后會對請求內(nèi)容進行解析，以確定客戶端進行的是什么游戲行為缀雳，并獲取到對應(yīng)的請求參數(shù)渡嚣，之后服務(wù)端會根據(jù)代碼邏輯來對這些數(shù)據(jù)進行相應(yīng)的處理，并將處理結(jié)果同樣以封包的形式返回給客戶端肥印，客戶端在接收到封包之后严拒，也會按照約定好的規(guī)則進行解析，并將解析后的結(jié)果展示給玩家竖独。

常見協(xié)議

1.TCP協(xié)議（傳輸控制協(xié)議）
　市面上大部分的游戲都是使用的TCP協(xié)議莹痢，當(dāng)游戲不需要非常強的實時性，能夠容忍一定程度延遲的時候墓赴，推薦使用TCP協(xié)議竞膳，但如果是強實時性的游戲（如moba和fps類型的游戲），就需要使用UDP協(xié)議來盡量減少延遲
　優(yōu)點：面向連接（一對一诫硕，類似于打電話）坦辟，傳輸可靠（能夠保證數(shù)據(jù)的正確性），有序（能保證數(shù)據(jù)的順序）章办，可以傳輸大量數(shù)據(jù)（流模式）锉走，簡單直接，無需再次開發(fā)
　缺點：對系統(tǒng)資源的要求多藕届，程序結(jié)構(gòu)較復(fù)雜挪蹭，丟包重傳時延遲較大

2.UDP協(xié)議（用戶數(shù)據(jù)報協(xié)議）
　上面講到了，一些實時性強的競技類游戲休偶，一般是使用UDP協(xié)議
　優(yōu)點：速度快梁厉，對系統(tǒng)資源的要求少，程序結(jié)構(gòu)簡單踏兜，支持一對一词顾，一對多和多對多的交互通信
　缺點：傳輸不可靠（可能丟包）、無序（不能保證數(shù)據(jù)的順序）碱妆，傳輸數(shù)據(jù)量小肉盹，可能需要二次開發(fā)來保證實時性

3.websocket協(xié)議
　websocket是基于HTML5語言而誕生的一種協(xié)議，websocket跟socket不同山橄，websocket是一個完整的應(yīng)用層協(xié)議垮媒，包含一套標準的API舍悯，多應(yīng)用于H5和微信小游戲
　而socket是對TCP/IP協(xié)議的封裝和應(yīng)用，它并不是一種協(xié)議睡雇，而是為了方便大家直接使用更底層協(xié)議而存在的一個抽象層萌衬，將應(yīng)用層之間的網(wǎng)絡(luò)通信簡單化，當(dāng)socket連接創(chuàng)建時它抱，通過參數(shù)指定使用的傳輸層協(xié)議類型秕豫，當(dāng)使用TCP協(xié)議進行連接時，該socket就是一個TCP連接
　在websocket中观蓄，需要服務(wù)器和客戶端（或瀏覽器）通過http協(xié)議進行一次握手動作混移，然后單獨創(chuàng)建一條TCP通信通道進行數(shù)據(jù)傳輸

PS：如果不需要寫機器人的話，其實不太需要關(guān)心協(xié)議的實現(xiàn)方式侮穿，不管是TCP協(xié)議歌径，還是websocket等等，我們需要關(guān)注的其實是服務(wù)器對協(xié)議參數(shù)的驗證亲茅。

常見的游戲協(xié)議封包構(gòu)成

包長：當(dāng)前封包的字節(jié)流長度验残，用來判斷收到的字節(jié)流是否是一個完整的封包
　協(xié)議號：客戶端與服務(wù)端之間定義的具體的事件編號，通過協(xié)議號巾乳，我們可以知道客戶端是進行了哪種操作
　驗證碼：客戶端跟服務(wù)端之間定義的一套封包有效性驗證機制
　協(xié)議參數(shù)：客戶端與服務(wù)端進行協(xié)議傳輸?shù)臅r候附帶的實際協(xié)議內(nèi)容您没，是某種游戲行為的具體實現(xiàn)，協(xié)議參數(shù)又分為多種類型胆绊，有int型紊婉，str型，list型辑舷，甚至是某種自定義的對象喻犁，這個一般需要參照具體的游戲協(xié)議文檔。

ps：由于TCP特殊的流模式何缓，某些情況下肢础，我們收到的封包可能是由多個封包黏連在一起的，那么在進行封包處理的時候如何判斷是否是一個完整的封包呢碌廓？就需要通過包長來判斷传轰，如果當(dāng)前封包的長度等于包長的值，那么就是一個完整的封包谷婆，否則就需要對封包進行截取拆分

為什么要測協(xié)議慨蛙？

游戲中很多行為限制辽聊，是在客戶端層面的，在我們進行某些非正常游戲行為的時候期贫，客戶端已經(jīng)在邏輯層面阻止了我們的這種行為（比如跟匆，在金錢不足的時候我去買一件物品，客戶端會判斷你的錢是否足夠買這件物品通砍，如果不足則會提示金錢不足玛臂，并阻止你這次行為），但之前我們講了封孙，客戶端與服務(wù)端之間是通過協(xié)議封包來進行交互的迹冤，客戶端阻止你的行為，只是阻止客戶端自己來發(fā)送這個行為封包虎忌，那么服務(wù)端對于這種非正常情況是否有做判斷呢泡徙？如果我偽造一個這樣的封包，或者在網(wǎng)絡(luò)不順暢的時候膜蠢，多次點擊購買來重復(fù)發(fā)送封包锋勺，是否可以在金錢不足的時候購買成功呢？是否存在刷錢刷道具的漏洞呢狡蝶？
　這個就是我們進行協(xié)議測試的目的：驗證服務(wù)器邏輯的正確性！

抓包和發(fā)包

1.抓包
　既然要分析協(xié)議贮勃，那么首先就需要看到協(xié)議贪惹，看到協(xié)議那么就需要監(jiān)聽服務(wù)端與客戶端之間的通信，并抓取游戲封包
　市面上目前有很多抓包工具寂嘉，常用的游戲抓包神器WPE奏瞬、其他的還有fiddler、wireshark等泉孩，使用方法這里不做過多介紹硼端，網(wǎng)上很多使用教程。

2.發(fā)包
　以WPE為例寓搬，在我們抓到包之后珍昨，右鍵其中的一條封包選擇發(fā)送，就可以在新彈出來的界面修改封包內(nèi)容句喷，在修改好對應(yīng)的參數(shù)之后镣典，點擊發(fā)送按鈕，這條修改后的封包就會發(fā)送給服務(wù)端了唾琼。

開發(fā)人員一般也會留一個GM指令的接口或者其他的發(fā)包方式兄春，通過預(yù)留接口也可以實現(xiàn)對服務(wù)器進行發(fā)包測試。

如何分析協(xié)議？

我們在協(xié)議測試的時候夕晓，主要是針對客戶端對服務(wù)端發(fā)送的協(xié)議進行測試宛乃，因為游戲數(shù)據(jù)的處理大部分都是在服務(wù)器上進行的，我們需要驗證的是服務(wù)器的邏輯處理環(huán)節(jié)蒸辆，而服務(wù)器返回的封包征炼，是已經(jīng)在服務(wù)器邏輯處理完成之后的，我們就算對這些封包進行了修改躬贡，也只是修改了客戶端的顯示而已谆奥，并不會對服務(wù)器的數(shù)據(jù)造成任何影響。

我們玩游戲時進行的游戲行為酸些，都是具有行為前置條件的，比如我們買東西檐蚜，那么就需要有足夠的錢魄懂，想要挑戰(zhàn)某個副本，就需要有足夠的等級和挑戰(zhàn)次數(shù)闯第，我們要做的市栗，就是推翻前置條件，在條件不滿足的情況下咳短，來發(fā)送一個正常的游戲封包填帽。前置條件大概整理了以下幾種類型：
1.等級無效
　對于某些具有等級限制的玩法，在等級不足的時候進行發(fā)包驗證
2.時間無效
　對于某些具有時效性的玩法咙好，在時間范圍之外進行發(fā)包驗證
3.貨幣無效
　對于需要消耗貨幣的玩法篡腌，在貨幣數(shù)量不足的時候發(fā)包驗證（這里的貨幣指的是廣義的貨幣，不單指金錢勾效，還包括副本次數(shù)等等）
4.次數(shù)無效
　這里指的是一些有次數(shù)限制的玩法嘹悼，在次數(shù)不足的時候發(fā)包驗證，如某個活動獎勵层宫，每個角色只能領(lǐng)取1次绘迁，那么在領(lǐng)取完獎勵之后，再發(fā)送一次領(lǐng)取獎勵的封包卒密，看服務(wù)器的處理邏輯
5.前置條件無效
　這個比較特殊缀台，舉個例子：幫派每日禮包，幫派成員每日可以領(lǐng)取1次哮奇，前置條件就是角色必須已經(jīng)加入幫派成為幫派成員膛腐，在角色未加入幫派的時候睛约，這個獎勵通過發(fā)包是否可以領(lǐng)取哲身？
6.參數(shù)范圍無效
　這個也有點特殊辩涝，還是通過一個例子來說明：游戲內(nèi)的7天登錄協(xié)議，協(xié)議參數(shù)為對應(yīng)獎勵的天數(shù)勘天，如玩家要領(lǐng)取第一天的獎勵怔揩，在發(fā)送協(xié)議的時候參數(shù)為1，第二天為2……第七天為7脯丝，那么0和8就是范圍外的無效參數(shù)
7.特殊限制
　未在上述條件中的可能存在的一些其他的限制商膊，如在跟NPC提交任務(wù)和領(lǐng)取獎勵的時候，需要在一個有效交互范圍之內(nèi)宠进，在這里特殊限制就是交互距離

協(xié)議測試用例設(shè)計

寫在最后

協(xié)議的分析與測試，到這里就講的差不多了堤器，不過還有一點需要關(guān)注的昆庇，就是協(xié)議的有效性和冗余性，這個不屬于單條協(xié)議測試的范疇闸溃，但卻是游戲體驗和性能方面很重要的一個方向整吆。
　我們游戲的協(xié)議是通過網(wǎng)絡(luò)形式發(fā)送的，網(wǎng)絡(luò)是有流量成本和傳輸壓力的圈暗，減少無效協(xié)議和重復(fù)協(xié)議、減少非必要的協(xié)議參數(shù)裕膀，在一定程度上能夠提高協(xié)議的傳輸效率员串，給游戲帶來更好的體驗。
　有些公司還需要負值校驗（將參數(shù)修改為負數(shù)）昼扛，以及不完整封包校驗（刪除部分字段）寸齐，因為我們公司后端在這塊驗證做的比較完善，所以我沒有寫抄谐，感興趣的同學(xué)可以跟后端開發(fā)人員確認一下渺鹦。

原文由碧曉寒楓發(fā)表于TesterHome社區(qū)，點擊原文鏈接可與作者直接交流蛹含。