怎么自定義協議

本篇內容介紹了“怎么自定義協議”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

為什么要自定義協議

直接使用標準的協議好處是顯而易見的，我個人理解的幾點優點：

• 既然是標準協議說明已經成為了標準，這樣很多系統就可以直接對接，無縫集成；

• 協議最重要的一點就是編碼解碼，標準協議往往有現成的編碼解碼包，直接拿來使用，減少開發時間；

• 有很多圍繞標準協議的第三方測試工具，可以很方便的進行測試；

既然有這么多優點那我們為什么還要去自定義協議，大致出于以下幾點考慮：

• 既然是標準協議，往往兼顧的東西比較多，導致協議數據相對來說比較大，這樣可能在一些追求性能，流量的系統中不能容忍；

• 標準協議有很多，沒有哪一種協議可以適用任何場景中，所以如果在某個場景中還沒有既定的標準協議，這時候會有各種私有協議；

• 自定義協議只要雙方約定好數據結構就行，不具有通用性，理論上來說會更加安全一點，當然現在很多標準協議都有安全版本，比如https，sftp等等；

以上只是個人的一點理解，歡迎大家補充；關于如何去自定義協議，其實可以去多參考一些主流的標準協議或者私有協議，其實有很多共同點可以去借鑒；下面先簡單看看那些主流的協議；

主流協議

下面分別看看一些主流的標準協議或者私有協議都是如何去定義自己的數據結構的，對我們有非常好的借鑒意義；

http協議

http協議大家最熟悉不過了，全稱叫超文本傳輸協議，整個請求報文可以分為三個部分分別是：請求行，請求報頭，請求正文；

• 請求行

GET /test.html HTTP/1.1 (CRLF換行)

• 請求報頭

Accept-Encoding: gzip, deflateContent-Length: 38 Content-Encoding: gzip...

請求包頭有很多，每一個代表了各自的含義，這邊就不一一列出，我們這里更加關注整個報文的結構；

• 請求正文

這個只有在POST請求的時候才有正文，里面存放業務數據，比如常見的json文本串；具體正文的長度可以根據消息頭中的Content-Length來決定；

dubbo協議

dubbo協議格式可以直接參考官網提供的如下圖片：

看上圖其實整個協議數據包也大致分為兩個部分：固定部分和可變部分，或者叫消息頭和消息體；
固定部分一共是4+8+4=16個字節，具體如下所示：

header{Magic High       = 8bit;  //魔數高位Magic Low        = 8bit;  //魔數低位Req/Res          = 1bit;  //標識是請求或響應2 Way            = 1bit;  //標記是否期望從服務器返回值Event            = 1bit;  //標識是否是事件消息Serialization ID = 5bit;  //標識序列化類型Status           = 8bit;  //標識響應的狀態Request ID       = 64bit; //標識唯一請求Data Length      = 32bit; //序列化后的內容長度}

可變部分根據固定部分中的Data Length來確定長度；

redis協議

Redis的客戶端與服務端采用叫做 RESP(Redis Serialization Protocol)的網絡通信協議交換數據，相對來說還是比較簡單的，以下是這個協議的一般形式：

*< 參數數量 > CR LF
$< 參數 1 的字節數量 > CR LF< 參數 1 的數據 > CR LF
...
$< 參數 N 的字節數量 > CR LF< 參數 N 的數據 > CR LF

以上大致介紹了三種比較有代表性的協議，雖然說每種協議都有各自的使用場景，但是如果我們自己去定義協議，還是有一些相通的東西；

如何自定義協議

下面我們重點看看去自定義協議有哪些需要我們關注的點，以下是本人根據自己的理解整理了如下關注點：

• 完整的數據包

• 協議號

• 消息頭標識

• 業務數據

• 預留字段

下面分別逐一詳細介紹：

完整的數據包

我們平時經常講數據包，但是TCP其實只有流的概念，并沒有數據包的概念；那很重要的一點就是我們的程序怎么知道現在的業務數據已經接受全部接收完了，可以作為一個完整的數據包去處理了，如果不去做處理的話就會出現我們常說的半包和粘包問題；主流的的處理方式大致有這么兩種：

• 在消息頭部加上數據包長度描述，比如在http協議和dubbo協議中出現的dataLength字段；

• 用特殊的字符串作為數據包的結尾，這樣我們在接受數據的時候接受到預定的特殊字符串就表示數據包完整了；

協議號

可能不同的協議有不同的叫法，我這里把它叫做協議號，個人理解就是根據這個協議號，服務器端知道去執行什么邏輯；比如http協議請求行中的/test.html，dubbo協議中的服務名+版本號，redis中的具體要執行什么key；

消息頭標識

這個是否需要還是要看各自的場景，比如redis協議足夠簡單，無需任何標識，所有的東西都是雙端約定好的；但是其他很多協議還是有一些需要的，除了上面說到的可以在消息頭中指定dataLength，其實還有很多其他的東西可以指定比如：

• 業務數據格式：文本格式，json格式，html格式等等；

• 壓縮格式：可能為了追求流量包大小對數據包進行壓縮，gzip、deflater、snappy等；

• 加密算法：可能需要對我的業務數據進行加密處理，保證業務數據的安全性AES、DES等；

業務數據

業務數據往往在整個數據包中是最大的，同時也是大小可變的部分；我們上面所做的這些其實都是在為業務數據服務，業務數據需要在網絡傳輸，最重要的一點就是序列化，一般就以下兩種方式：

• 文本方式：序列化文本文檔text，或者json串，xml格式等；

• 二進制方式：常見的比如protobuf，thrift，kyro等；

預留字段

是否需要預留字段這個得看情況，比如http協議整個消息頭是可變的，每一行一個標識，知道讀取到空行，表示消息頭結束下面就是正文了，可以理解為http使用了兩種方式來保證完整包，消息頭使用特殊字符結尾，正文使用在消息頭中指定dataLength；這種方式其實它的整個擴展性是非常好的；
另外一種像dubbo這樣，其實它的頭部相當于已經固定好了16個字節，這種情況下是否可以預留幾個字節防止后面的變更；

“怎么自定義協議”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！