協(xié)議設(shè)計，據(jù)說現(xiàn)代架構(gòu)不再需要了？
系統(tǒng)設(shè)計，協(xié)議先行。
大部分人不了解協(xié)議的設(shè)計細(xì)節(jié)，更多使用已有協(xié)議進(jìn)行應(yīng)用層設(shè)計，例如：
- 使用HTTP，設(shè)計 get/post/cookie 參數(shù)，以及json包格式；
- 使用dubbo，而不用去深究內(nèi)部的二進(jìn)制包頭包體細(xì)節(jié)；
無論如何，了解協(xié)議設(shè)計的原則，對深入理解系統(tǒng)通信非常有幫助。
一、協(xié)議的分層設(shè)計
所謂“協(xié)議”，是雙方共同遵守的規(guī)則，例如：離婚協(xié)議，停戰(zhàn)協(xié)議。協(xié)議有語法、語義、時序三要素：
- 語法，即數(shù)據(jù)與控制信息的結(jié)構(gòu)或格式；
- 語義，即需要發(fā)出何種控制信息，完成何種動作以及做出何種響應(yīng)；
- 時序，即事件實(shí)現(xiàn)順序的詳細(xì)說明；
畫外音：后文主要講語法設(shè)計。
協(xié)議設(shè)計通常分為三層：應(yīng)用層協(xié)議、安全層協(xié)議、傳輸層協(xié)議。
下面分別看下這三層的協(xié)議應(yīng)該如何選型。
二、應(yīng)用層協(xié)議設(shè)計
應(yīng)用層協(xié)議選型，常見的有三種：文本協(xié)議、二進(jìn)制協(xié)議、流式XML協(xié)議。
1. 文本協(xié)議
文本協(xié)議是指“貼近人類書面語言表達(dá)”的通訊傳輸協(xié)議，典型的協(xié)議是HTTP協(xié)議，一個HTTP協(xié)議的請求報文樣例如下：
GET / HTTP/1.1
User-Agent: curl
Host: shenjian.com
Accept: */*文本協(xié)議的特點(diǎn)是：
- 可讀性好，便于調(diào)試；
- 擴(kuò)展性較好，能通過key:value擴(kuò)展；
- 解析效率不高，一行一行讀入，按照冒號分割，解析key和value；
- 對二進(jìn)制不友好 ，比如語音/視頻等；
二進(jìn)制協(xié)議二進(jìn)制協(xié)議即binary協(xié)議，典型是IP協(xié)議，以下是IP協(xié)議的一個圖示：
二進(jìn)制協(xié)議一般包含：
- 定長包頭；
- 可擴(kuò)展變長包體；
- 一般每個字段有固定的含義，以IP協(xié)議為例，前4個bit表示協(xié)議版本號（Version）；
二進(jìn)制協(xié)議的特點(diǎn)是：
(1) 可讀性差，難于調(diào)試；
畫外音：打日志一般需要一個toString()函數(shù)增強(qiáng)可讀性。
(2) 擴(kuò)展性不好，如果要擴(kuò)展字段，舊版協(xié)議就不兼容了，所以設(shè)計時一般會有一個Version字段；
(3) 解析效率超高，幾乎沒有解析代價，二進(jìn)制流的每個字段表示固定含義；
(4) 天然支持二進(jìn)制流 ，比如語音/視頻；
這是一個典型的16字節(jié)二進(jìn)制定長包頭的例子：
//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));其中：
(1) 前4個字節(jié)表示版本號version；
(2) 接下來4個字節(jié)表示魔法數(shù)字magic_num，用來解決數(shù)據(jù)錯位或丟包問題；
畫外音：例如，約定好魔法數(shù)字是0x01020304，收到的報文，魔法數(shù)字匹配，認(rèn)為是正常報文，否則認(rèn)為是報文異常，斷開連接。
(3) 接下來4個字節(jié)表示命令號command，不同的命令號對應(yīng)不同的變長包體；
(4) 最后4個字節(jié)表示包體長度length，以確定變長包體有多少字節(jié)；
這是一個實(shí)際的二進(jìn)制變長包體：
message CUserLoginReq {
optional string username = 1;
optional string passwd = 2;
}
message CUserLoginResp {
optional uint64 uid =1;
}它使用的是Google的Protobuf協(xié)議，容易看到：
- 請求報文傳入的是用戶名與密碼；
- 響應(yīng)包返回的是用戶的uid；
PB是很流行的二進(jìn)制變長包體協(xié)議，其優(yōu)點(diǎn)為：
- 通用，可以生成C++、Java、PHP等多語言代碼；
- 自帶壓縮功能；
- 對二進(jìn)制友好；
- 在工業(yè)界已廣泛應(yīng)用；
畫外音：Google出品，必屬精品。
2. 流式XML協(xié)議
流式XML似乎是文本協(xié)議的一個特例，亦可以單獨(dú)作為一類。例如：xmpp就是典型的流式XML協(xié)議，下面是xmpp協(xié)議的一個典型報文：
<message
to=’romeo@example.net’
from=’juliet@example.com’
type=’chat’
xml : lang=’en’>
<body>Wherefore art thou, Romeo?</body>
</message>從xml標(biāo)簽中大致可以判斷這是一個romeo發(fā)給juliet的聊天消息。
XML協(xié)議有幾個特點(diǎn)：
- 可讀性好，擴(kuò)展性好，這是XML的特性；
- 解析代價超高，需要進(jìn)行dom樹分析；
- 有效數(shù)據(jù)傳輸率超低，有大量的標(biāo)簽；
- 對二進(jìn)制不友好 ，比如語音/視頻等；
三、安全層協(xié)議設(shè)計
安全層協(xié)議設(shè)計，除了使用SSL，自行實(shí)現(xiàn)的話，常見的又有以下三種方案。
畫外音：SSL密鑰管理是個問題。
1. 固定密鑰
服務(wù)端和客戶端約定好一個密鑰，同時約定好一個加密算法（例如：AES），每次客戶端發(fā)送報文前，就用約定好的算法，以及約定好的密鑰加密再傳輸，服務(wù)端收到報文后，用約定好的算法，約定好的密鑰再解密。
畫外音：安全性低，安全性基于程序員的職業(yè)操守。
2. 一人一密
簡單來說，就是一個人的密鑰是固定的，但是每個人之間又不同。常見的實(shí)現(xiàn)方式是：
- 固定加密算法；
- 加密秘鑰使用“用戶的某一特殊屬性”，比如用戶uid、手機(jī)號、qq號、用戶密碼等；
3. 一次一密
即動態(tài)密鑰，一Session一密鑰的安全性更高，每次會話前協(xié)商密鑰。密鑰協(xié)商的過程要經(jīng)過2次非對稱密鑰的隨機(jī)生成，1次對稱加密密鑰的隨機(jī)生成，具體詳情這里不展開。
四、傳輸層協(xié)議設(shè)計
可選的協(xié)議有TCP和UDP，現(xiàn)在基本都是使用TCP，有了epoll等技術(shù)后，多連接就不是瓶頸了，單機(jī)幾十萬鏈接沒什么問題。
知其然，知其所以然。
思路比結(jié)論更重要。
