簡述

互聯網上充斥著各種各樣的網絡服務，在對外提供網絡服務時，服務端和客戶端需要遵循同一套數據通訊協議，才能正常的進行通訊；就好像你跟臺灣人溝通用閩南語，跟廣東人溝通就用粵語一樣。

實現自己的應用功能時，已知的知名協議（http，smtp，ftp等）在安全性、可擴展性等方面不能滿足需求，從而需要設計并實現自己的應用層協議。

2.協議分類

2.1按編碼方式

二進制協議比如網絡通信運輸層中的tcp協議。

明文的文本協議比如應用層的http、redis協議。

混合協議（二進制+明文）比如蘋果公司早期的APNs推送協議。

2.2按協議邊界

固定邊界協議能夠明確得知一個協議報文的長度，這樣的協議易于解析，比如tcp協議。

模糊邊界協議無法明確得知一個協議報文的長度，這樣的協議解析較為復雜，通常需要通過某些特定的字節來界定報文是否結束，比如http協議。

3.協議優劣的基本評判標準

高效的快速的打包解包減少對cpu的占用，高數據壓縮率降低對網絡帶寬的占用。

簡單的易于人的理解、程序的解析。

易于擴展的對可預知的變更，有足夠的彈性用于擴展。

容易兼容的

向前兼容，對于舊協議發出的報文，能使用新協議進行解析，只是新協議支持的新功能不能使用。

向后兼容，對于新協議發出的報文，能使用舊協議進行解析，只是新協議支持的新功能不能使用。

4.自定義應用層協議的優缺點

4.1優點

非知名協議，數據通信更安全，黑客如果要分析協議的漏洞就必須先破譯你的通訊協議。

擴展性更好，可以根據業務需求和發展擴展自己的協議，而已知的知名協議不好擴展。

4.2缺點

設計難度高，協議需要易擴展，最好能向后向前兼容。

實現繁瑣，需要自己實現序列化和反序列化。

5.動手前的預備知識

5.1大小端

計算機系統在存儲數據時起始地址是高地址還是低地址。

大端從高地址開始存儲。

小端從低地址開始存儲。

圖解

判斷這里以c/c++語言代碼為例，使用了c語言中聯合體的特性。

5.2網絡字節序

顧名思義就是數據在網絡傳送的字節流中的起始地址的高低，為了避免在網絡通信中引入其他復雜性，網絡字節序統一是大端的。

5.3本地字節序

本地操作系統的大小端，不同操作系統可能采用不同的字節序。

5.4內存對象與布局

任何變量，不管是堆變量還是棧變量都對應著操作系統中的一塊內存，由于內存對齊的要求程序中的變量并不是緊湊存儲的，例如一個c語言的結構體Test在內存中的布局可能如下圖所示。

5.5序列化與反序列化

將計算機語言中的內存對象轉換為網絡字節流，例如把c語言中的結構體Test轉化成uint8_t data[6]字節流。

將網絡字節流轉換為計算機語言中的內存對象，例如把uint8_t data[6]字節流轉化成c語言中的結構體Test。

6.一個例子

6.1 協議設計

本協議采用固定邊界+混合編碼策略。

協議頭8字節的定長協議頭。支持版本號，基于魔數的快速校驗，不同服務的復用。定長協議頭使協議易于解析且高效。

協議體變長json作為協議體。json使用明文文本編碼，可讀性強、易于擴展、前后兼容、通用的編解碼算法。json協議體為協議提供了良好的擴展性和兼容性。

協議可視化圖

6.2 協議實現

talk is easy，just code it，使用c/c++語言來實現。

6.2.1c/c++語言實現

使用結構體MyProtoHead來存儲協議頭

6.2.2打包（序列化）

6.2.3解包（反序列化）

7.完整源碼與測試

code is easy，just run it.

7.1源碼

7.2運行測試

8.總結

不到350行的代碼向我們展示了一個自定義的應用層協議該如何實現，當然這個協議是不夠完善的，還可以對其完善，比如對協議體進行加密加強協議的安全性等。

審核編輯：劉清