應用層/安全層/傳輸層如何進行協議選型？
系統設計，協議先行。
大部分技術人沒有接觸協議的設計細節，更多的是使用已有協議進行應用層的編碼，例如：
(1)使用http作為載體，設計get/post/cookie參數
(2)使用dubbo框架，而不用去深究內部的二進制包頭包體，以及序列號反序列化的細節
無論如何，了解協議設計的原則，對深入理解系統通信非常有幫助。今天就以即時通訊(后稱im)為例，講講應用層的協議選型。
一、im協議的分層設計
所謂“協議”是雙方共同遵守的規則，例如：離婚協議，停戰協議。協議有語法、語義、時序三要素。
(1)語法：即數據與控制信息的結構或格式
(2)語義：即需要發出何種控制信息，完成何種動作以及做出何種響應
(3)時序：即事件實現順序的詳細說明
im協議設計分為三層：應用層、安全層、傳輸層。
分別看下這三層的協議應該如何選型。
二、im應用層協議設計
應用層協議選型，常見的有三種：文本協議、二進制協議、流式XML協議。
(1)文本協議
文本協議是指 “貼近人類書面語言表達”的通訊傳輸協議，典型的協議是http協議，一個http協議大致長成這樣：
- GET / HTTP/1.1
- User-Agent: curl
- Host: musicml.net
- Accept: */*
文本協議的特點是：
a.可讀性好，便于調試
b.擴展性也好(通過key:value擴展)
c.解析效率一般(一行一行讀入，按照冒號分割，解析key和value)
d.對二進制的支持不好 ，比如語音/視頻
im中，msn使用的是文本協議。
(2)二進制協議
二進制協議是指binary協議，典型是ip協議，以下是ip協議的一個圖示：
二進制協議一般定長包頭和可擴展變長包體 ，每個字段固定了含義 ，例如IP協議的前4個bit表示協議版本號 (Version)。
二進制協議有這樣一些特點：
a.可讀性差，難于調試
b.擴展性不好 ，如果要擴展字段，舊版協議就不兼容了，所以一般設計時會有一個Version字段
c.解析效率超高(幾乎沒有解析代價)
對二進制的支持不好 ，比如語音/視頻
im中，QQ使用的時二進制協議。
(3)流式XML協議
im的準標準協議xmpp就是使用流式XML，像gtalk，校內通這些im都是基于xmpp的，讓我們來看一個xmpp協議的例子：
- <message
- to=’romeo@example.net’
- from=’juliet@example.com’
- type=’chat’
- xml : lang=’en’>
- <body>Wherefore art thou, Romeo?</body>
- </message>
從xml標簽中大致可以判斷這是一個romeo發給juliet的聊天消息。
xmpp協議可以實現跨域的互通。例如gtalk和校內通用戶聊天。只要服務端實現了s2s服務(server to server) ，不過現在的im基本沒有互通需求 ，所以這個服務基本沒有人實現。
Xmpp協議有幾個特點：
a.它是準標準協議，可以跨域互通
b.XML的優點，可讀性好，擴展性好
c.解析代價超高(dom解析)
d.有效數據傳輸率超低(大量的標簽)
個人旗幟鮮明的強烈不建議使用xmpp，特別是無線端im，如果要用，一定要自己做壓縮 ，減少網絡流量(用過xmpp的同學都清楚，發一個登錄包需要多少交互，要浪費多少流量)。
實際的栗子
下面來看一個im協議的實際例子 ，一般常見的做法是：定長二進制包頭，可擴展變長包體。
包體可以使用用文本、XML等擴展性好的協議。
包頭負責傳輸和解析效率，與業務無關。包體保證擴展性，與業務相關。
這是一個實際的16字節im二進制定長包頭
- //sizeof(cs_header)=16
- struct cs_header
- {
- uint32_t version;
- uint32_t magic_num;
- uint32_t cmd;
- uint32_t len;
- uint8_t data[];
- }__attribute__((packed));
a.前4個字節是version;
b.接下來的4個字節是個“魔法數字(magic_num)“，用來保證數據錯位或丟包問題，常見的做法是，包頭放幾個約定好的特殊字符，包尾放幾個約定好的特殊字符 約定好，發給你的協議，某幾個字節位置，是0x 01020304 ，才是正常報文;
c.接下來是command(命令號)，用來區分是keepalive報文、業務報文、密鑰交換報文等;
d.len(包體長度)，告知服務端要接收多長的包體。
這是一個實際的可擴展im變長包體
- message CUserLoginReq
- {
- optional string username = 1;
- optional string passwd = 2;
- }
- message CUserLoginResp
- {
- optional uint64 uid =1;
- }
使用的是google的Protobuf協議，可以看到，登錄請求包傳入的是用戶名與密碼，登錄響應包返回的是用戶的uid。
當然，除了Protobuf，可選擇的可擴展包體協議還有xml、json、mcpack(這...)等。
個人旗幟鮮明的推薦使用Protobuf，主要有幾個原因：
a.現成的解析庫種類多，可以生成C++、Java、php等代碼
b.自帶壓縮功能
c.在工業界已廣泛應用
d.google制造
三、im安全層協議設計
im協議，消息的保密性非常重要 ，誰都不希望自己聊天內容被看到，所以安全層是必不可少的。
1、SSL
證書管理微微復雜，代價有點高。
2、自行加解密
自己來搞加解密，核心在于密鑰的生成與管理，密鑰管理方式有多種，主要有這么三種：
(1)固定密鑰
服務端和客戶端約定好一個密鑰，同時約定好一個加密算法(eg：AES )，每次客戶端im在發送前，就用約定好的算法，以及約定好的密鑰加密再傳輸，服務端收到報文后，用約定好的算法，約定好的密鑰再解密。這種方式，密鑰和算法對程序員都是透明的。
(2)一人一密鑰
簡單說來就是每個人的密鑰是固定的，但是每個人之間又不同，其實就是在固定密鑰的算法中包含用戶的某一特殊屬性，比如用戶uid、手機號、qq號等。
(3)動態密鑰(一session一密鑰)
動態密鑰，一Session一密鑰的安全性更高，每次會話前協商密鑰。
密鑰協商的過程要經過2次非對稱密鑰的隨機生成，1次對稱加密密鑰的隨機生成，具體詳情這里不展開，有興趣的同學可以看下SSL密鑰協商額過程。
四、im傳輸層協議設計
可選的協議有TCP和UDP
現在的im傳輸層基本都是使用TCP，有了epoll等技術后，多連接就不是瓶頸了，單機幾十萬鏈接沒什么問題。
先聊這么多，希望對大伙進行應用/安全/傳輸層協議選型有幫助。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
