對於很多裝置之間的通訊，經常需要自己設計一套通訊協議。當然此處的通訊協議一般都是建立在tcpip協議等協議基礎之上的協議，也就是在已有協議的基礎之上，在定義一套協議。例如：有一套檢測降雨量的裝置（一般為簡單的嵌入式裝置）需要把採集到的的資料上報給中心伺服器（一般為一台效能特別好的計算機）。就需要一套通訊協議。以保證，嵌入式裝置上發的資料，可以被中心伺服器正確的理解和處理。再例如：在橋梁檢測的專案中，會檢測很多橋梁的資料，應力，索力，溫度等，這些檢測裝置一般都是由簡單的感測器組成的嵌入式裝置 ，需要通過各種方式把採集到的的資料上報給中心伺服器，中心伺服器經過分析處理後，再進一步判斷橋梁的各種狀態。這些都涉及到自定義通訊協議。
但這些自定義通訊協議如何設計？有設計到那些方面？
協議的設計，是為了保證雙方能夠正常的通訊，由於上位裝置和下位裝置一般是不同的裝置，處理能力有很大差異，這些都是設計協議必須考慮的問題。
一套完整的協議，通常包含很多命令，每乙個命令都會規定乙個完整的命令（也就是乙個完整的資料幀）包含哪些部分，一般包含以下幾部分：
1資料幀的組成的形式
一般形式有位元組流（有的地方也叫做二進位制協議）和字元流。位元組流一般會規定每乙個位元組表示的含義，而字元流由於都是可見的字元，一般會規定，字元的含義。
2資料幀頭和尾
資料幀頭和尾其實是為了解析資料而設計的，主要是為了獲取乙個完整的幀。由於網路的不確定性，無法保證一條完整的資料幀的一次性就傳送給對方。一般選擇用很少出現的位元組或者字元作為資料幀頭和尾。
例如我曾經解析過得mode 04 protocol的一套協議，就是以0x03，0x14開頭的，由於mode 04 protocol是位元組流協議，因此規定了命令的開頭兩個位元組是0x03，0x14，還曾經解析過字元流的協議，命令是以##開頭。資料幀尾有時會有，有時沒有，例如mode 04 protocol就沒有協議尾，因為它有兩個位元組表示本條資料幀的長度，所以沒必要規定資料幀尾。相反，如果無法判斷一條命令的長度，就會規定資料幀如何結束。如果資料幀長度都是一樣的，也沒有必要規定，但實際中很少遇到資料幀長度是固定的情況。
3資料幀的驗證部分
對於位元組流的協議，一般會規定驗證資料幀的驗證部分，例如mode 04 protocol就規定了資料幀最後兩個位元組是crc驗證部分。
對於字元流的也可以加驗證字段，但因為每一部分都都是可視的字元，也可以不加。
4轉義字元
再少出現的字元由於資料幀內容的不確定性，也有可能在資料幀內部出現，例如：mode 04 protocol協議當資料幀內部出現了0x03，0x14，也就是資料幀規定的開始部分，就必須轉義，否則就會解析出錯。導致乙個資料幀變成兩部分不完整無法理解的資料幀。
5命令字及其他
命令字就是標示此資料幀，需要完成的命令，例如：讀取時間命令資料幀，就有一部分標示此資料幀是讀取時間，設定時間命令資料幀就有一部分標示此資料幀是用來設定時間的，當然會有命令內容例如把時間調整到多少。
6心跳包
心跳包作為一條很特殊的資料幀，作用其實和人的心跳類似。每隔一段時間，就會傳送一條很特殊的資料幀心跳包。作用就是表明此裝置還在工作。
對比：位元組流協議難度顯然比字元流大很多，解析過程也更複雜，如果沒有協議文件，幾乎不能解析，因為收到的就是一串毫無意思的數字，乙個位元組處理錯誤就完全可能導致整條資料解析錯誤，此外位元組流還需要規定大端模式和小端模式等。當然好處就是，傳輸同樣的資訊，資料量明顯少很多。
字元流就簡單很多，解析的過程可能就是乙個正規表示式。
一般來說，乙個基本的資料報協議需要以下部分
1. 協議的標識
2. 協議版本號
3. 協議包的序號
4. 協議包的發出時間
5. 協議包的型別
6. 協議包的資料長度
7. 資料
8. 校驗碼
9. 結束符
上面的9點中，第乙個橫線上的是包頭部分，對於每個資料報都是 一樣的，但對於後面的6,7跟具體的包有關，這部分是不同的。 下面的8.9也是相同的。
下面繼續說明6, 7兩點的設計辦法。
如果協議包的每種型別下面沒有更多的分類，那麼，資料這部分無需再設計 只要乙個值即可，但情況往往不是那麼簡單，情況如下 (1)如果資料也有多種型別，那麼資料部分得再加上乙個型別標號， (2)如果資料同時有多個，那麼資料部分必須分成二部分，一部分表明其資料 個數，後面再跟多個資料個體。
使用者驗證的例子比如. 將登入名計算成乙個md5大整數， 當使用者登入時，將此時的登入名用md5演算法運算一下，看其值與md5是否相等。
例子:設計乙個傳遞室內溫度，與 空氣含氧量的協議
首先 1, 2, 3, 4, 點好設計，照搬即可， 那麼5的型別，此處有二個，即溫度或 者空氣含氧量, 其型別有二種0xc1, 0xc2
6資料的長度與7資料內容有關，7資料內容可以是獲取溫度時間與溫度值， 也可以是獲取時間與空氣含氧量。
8, 9 照搬即可。
Arduino通訊協議設計
最近在一直在研究arduino 硬體平台的東西，先從做乙個簡單的東西入手，比如說，我通過android端向arduino硬體傳送指令，控制電機的正轉 反轉。其中乙個必不可少的問題就是這兩個端裝置之間的通訊問題。它們之間的通訊可以通過藍芽模組來完成，此外，還需要自己設計通訊協議。從最簡單的模組開始，需...
網路通訊 協議設計
2 tlv 2.5 解析步驟 3 上下位機常用自定義協議 4 socket常用自定義協議 參考應用層的資料解析，目前博主涉及工業領域的上下位機串列埠通訊和客戶端服務端socket通訊，都是資料量不大的場景。在串列埠傳輸不穩定時，需要加上crc進行校驗。在socket通訊中，目前通訊丟包的可能性很小，...
通訊協議設計分析
幾乎任何專案都會涉及到通訊，那麼通訊協議的設計就顯得十分關鍵，目前就我個人來說串列埠 網口為從位元組流中取到正確的資料必須要開始通訊協議的設計。轉義字元 幾乎能保證99 的傳輸正確，除非硬體丟包太嚴重。對於很多裝置之間的通訊，經常需要自己設計一套通訊協議。當然此處的通訊協議一般都是建立在tcpip協...