應用層/安全層/傳輸層如何進行協(xié)議選型？

2018-09-06 17:49 更新

系統(tǒng)設計，協(xié)議先行。

大部分技術人沒有接觸協(xié)議的設計細節(jié)，更多的是使用已有協(xié)議進行應用層的編碼，例如：

（1）使用http作為載體，設計get/post/cookie參數(shù)

（2）使用dubbo框架，而不用去深究內(nèi)部的二進制包頭包體，以及序列號反序列化的細節(jié)


無論如何，了解協(xié)議設計的原則，對深入理解系統(tǒng)通信非常有幫助。今天就以即時通訊（后稱im）為例，講講應用層的協(xié)議選型。

一、im協(xié)議的分層設計

所謂“協(xié)議”是雙方共同遵守的規(guī)則，例如：離婚協(xié)議，停戰(zhàn)協(xié)議。協(xié)議有語法、語義、時序三要素。

（1）語法：即數(shù)據(jù)與控制信息的結(jié)構或格式

（2）語義：即需要發(fā)出何種控制信息，完成何種動作以及做出何種響應

（3）時序：即事件實現(xiàn)順序的詳細說明


im協(xié)議設計分為三層：應用層、安全層、傳輸層。
應用層、安全層、傳輸層
分別看下這三層的協(xié)議應該如何選型。

二、im應用層協(xié)議設計

應用層協(xié)議選型，常見的有三種：文本協(xié)議、二進制協(xié)議、流式XML協(xié)議。

（1）文本協(xié)議

文本協(xié)議是指 “貼近人類書面語言表達”的通訊傳輸協(xié)議，典型的協(xié)議是http協(xié)議，一個http協(xié)議大致長成這樣：

GET / HTTP/1.1
User-Agent: curl
Host: musicml.net
Accept: */*

文本協(xié)議的特點是：

a.可讀性好，便于調(diào)試

b.擴展性也好（通過key:value擴展）

c.解析效率一般（一行一行讀入，按照冒號分割，解析key和value）

d.對二進制的支持不好 ，比如語音／視頻

im中，msn使用的是文本協(xié)議。


（2）二進制協(xié)議

二進制協(xié)議是指binary協(xié)議，典型是ip協(xié)議，以下是ip協(xié)議的一個圖示：

ip協(xié)議

二進制協(xié)議一般定長包頭和可擴展變長包體 ，每個字段固定了含義 ，例如IP協(xié)議的前4個bit表示協(xié)議版本號 （Version）。

二進制協(xié)議有這樣一些特點：

a.可讀性差，難于調(diào)試

b.擴展性不好 ，如果要擴展字段，舊版協(xié)議就不兼容了，所以一般設計時會有一個Version字段

c.解析效率超高（幾乎沒有解析代價）

對二進制的支持不好 ，比如語音／視頻

im中，QQ使用的時二進制協(xié)議。


（3）流式XML協(xié)議

im的準標準協(xié)議xmpp就是使用流式XML，像gtalk，校內(nèi)通這些im都是基于xmpp的，讓我們來看一個xmpp協(xié)議的例子：

<message
to=’romeo@example.net’
from=’juliet@example.com’
type=’chat’
xml : lang=’en’>
<body>Wherefore art thou, Romeo?</body>
</message>

從xml標簽中大致可以判斷這是一個romeo發(fā)給juliet的聊天消息。

xmpp協(xié)議可以實現(xiàn)跨域的互通。例如gtalk和校內(nèi)通用戶聊天。只要服務端實現(xiàn)了s2s服務（server to server） ，不過現(xiàn)在的im基本沒有互通需求 ，所以這個服務基本沒有人實現(xiàn)。

Xmpp協(xié)議有幾個特點：

a.它是準標準協(xié)議，可以跨域互通

b.XML的優(yōu)點，可讀性好，擴展性好

c.解析代價超高（dom解析）

d.有效數(shù)據(jù)傳輸率超低（大量的標簽）

個人旗幟鮮明的強烈不建議使用xmpp，特別是無線端im，如果要用，一定要自己做壓縮 ，減少網(wǎng)絡流量（用過xmpp的同學都清楚，發(fā)一個登錄包需要多少交互，要浪費多少流量）。


實際的栗子

下面來看一個im協(xié)議的實際例子 ，一般常見的做法是：定長二進制包頭，可擴展變長包體。

包體可以使用用文本、XML等擴展性好的協(xié)議。

包頭負責傳輸和解析效率，與業(yè)務無關。包體保證擴展性，與業(yè)務相關。

這是一個實際的16字節(jié)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個字節(jié)是version；

b.接下來的4個字節(jié)是個“魔法數(shù)字（magic_num）“，用來保證數(shù)據(jù)錯位或丟包問題，常見的做法是，包頭放幾個約定好的特殊字符，包尾放幾個約定好的特殊字符 約定好，發(fā)給你的協(xié)議，某幾個字節(jié)位置，是0x 01020304 ，才是正常報文；

c.接下來是command（命令號），用來區(qū)分是keepalive報文、業(yè)務報文、密鑰交換報文等；

d.len（包體長度），告知服務端要接收多長的包體。

這是一個實際的可擴展im變長包體

message CUserLoginReq
{
optional string username = 1;
optional string passwd = 2;
}
message CUserLoginResp
{
optional uint64 uid =1;
}

使用的是google的Protobuf協(xié)議，可以看到，登錄請求包傳入的是用戶名與密碼，登錄響應包返回的是用戶的uid。

當然，除了Protobuf，可選擇的可擴展包體協(xié)議還有xml、json、mcpack（這...）等。

個人旗幟鮮明的推薦使用Protobuf，主要有幾個原因：

a.現(xiàn)成的解析庫種類多，可以生成C++、Java、php等代碼

b.自帶壓縮功能

c.在工業(yè)界已廣泛應用

d.google制造


三、im安全層協(xié)議設計

im協(xié)議，消息的保密性非常重要 ，誰都不希望自己聊天內(nèi)容被看到，所以安全層是必不可少的。

1、SSL

證書管理微微復雜，代價有點高。

2、自行加解密

自己來搞加解密，核心在于密鑰的生成與管理，密鑰管理方式有多種，主要有這么三種：

（1）固定密鑰

服務端和客戶端約定好一個密鑰，同時約定好一個加密算法（eg：AES ），每次客戶端im在發(fā)送前，就用約定好的算法，以及約定好的密鑰加密再傳輸，服務端收到報文后，用約定好的算法，約定好的密鑰再解密。這種方式，密鑰和算法對程序員都是透明的。

（2）一人一密鑰

簡單說來就是每個人的密鑰是固定的，但是每個人之間又不同，其實就是在固定密鑰的算法中包含用戶的某一特殊屬性，比如用戶uid、手機號、qq號等。

（3）動態(tài)密鑰（一session一密鑰）

動態(tài)密鑰，一Session一密鑰的安全性更高，每次會話前協(xié)商密鑰。

密鑰協(xié)商的過程要經(jīng)過2次非對稱密鑰的隨機生成，1次對稱加密密鑰的隨機生成，具體詳情這里不展開，有興趣的同學可以看下SSL密鑰協(xié)商額過程。


四、im傳輸層協(xié)議設計

可選的協(xié)議有TCP和UDP

現(xiàn)在的im傳輸層基本都是使用TCP，有了epoll等技術后，多連接就不是瓶頸了，單機幾十萬鏈接沒什么問題。


先聊這么多，希望對大伙進行應用/安全/傳輸層協(xié)議選型有幫助。


以上內(nèi)容是否對您有幫助：
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號