[TOC] ## im協議的分層設計 1. 語法：即數據與控制信息的結構或格式 2. 語義：即需要發出何種控制信息，完成何種動作以及做出何種響應 3. 時序：即事件實現順序的詳細說明  ## im應用層協議設計 ### 文本協議 http 就是典型的文本協議 ``` GET / HTTP/1.1 User-Agent: curl Host: musicml.net Accept: */* ``` 特點： 1. 可讀性好，便于調試 2. 擴展性也好（通過key:value擴展） 3. 解析效率一般（一行一行讀入，按照冒號分割，解析key和value） 3. 對二進制的支持不好 ，比如語音／視頻 im中，msn使用的是文本協議。 ### 二進制協議 二進制協議是指binary協議，典型是ip協議  二進制協議一般定長包頭和可擴展變長包體 ，每個字段固定了含義 ，例如IP協議的前4個bit表示協議版本號 （Version）。 二進制協議有這樣一些特點： 1. 可讀性差，難于調試 2. 擴展性不好 ，如果要擴展字段，舊版協議就不兼容了，所以一般設計時會有一個Version字段 3. 解析效率超高（幾乎沒有解析代價） 4. 對二進制的支持不好 ，比如語音／視頻 im中，QQ使用的時二進制協議。 #### 實例例子 一般常見的做法是：定長二進制包頭，可擴展變長包體。 包體: 可以使用用文本、XML等擴展性好的協議。 包頭: 負責傳輸和解析效率，與業務無關。包體保證擴展性，與業務相關。 一個 16位的包頭 ``` 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)); ``` 1. 前4個字節是version； 2. 接下來的4個字節是個“魔法數字（magic_num）“，用來保證數據錯位或丟包問題，常見的做法是，包頭放幾個約定好的特殊字符，包尾放幾個約定好的特殊字符 約定好，發給你的協議，某幾個字節位置，是0x 01020304 ，才是正常報文； 3. 接下來是command（命令號），用來區分是keepalive報文、業務報文、密鑰交換報文等； 4. len（包體長度），告知服務端要接收多長的包體。 實際的可擴展im變長包體,使用的是google的Protobuf協議 ``` message CUserLoginReq { optional string username = 1; optional string passwd = 2; } message CUserLoginResp { optional uint64 uid =1; } ``` > 除了Protobuf，可選擇的可擴展包體協議還有xml、json、mcpack 推薦protobuf 1. 現成的解析庫種類多，可以生成C++、Java、php等代碼 1. 自帶壓縮功能 1. 在工業界已廣泛應用 1. google制造 ### 流式XML協議(不推薦) 不提也罷 ## im安全層協議設計 1. SSL 證書管理微微復雜，代價有點高。 2. 自行加解密 自己來搞加解密，核心在于密鑰的生成與管理，密鑰管理方式有多種，主要有這么三種： 1. **固定密鑰** 服務端和客戶端約定好一個密鑰，同時約定好一個加密算法（eg：AES ），每次客戶端im在發送前，就用約定好的算法，以及約定好的密鑰加密再傳輸，服務端收到報文后，用約定好的算法，約定好的密鑰再解密。這種方式，密鑰和算法對程序員都是透明的。 2. **一人一密鑰** 簡單說來就是每個人的密鑰是固定的，但是每個人之間又不同，其實就是在固定密鑰的算法中包含用戶的某一特殊屬性，比如用戶uid、手機號、qq號等。 3. 動態密鑰（一session一密鑰） 密鑰協商的過程要經過2次非對稱密鑰的隨機生成，1次對稱加密密鑰的隨機生成，具體詳情這里不展開，有興趣的同學可以看下SSL密鑰協商額過程 ## im傳輸層協議設計 可選的協議有TCP和UDP 現在的im傳輸層基本都是使用TCP，有了epoll等技術后，多連接就不是瓶頸了，單機幾十萬鏈接沒什么問題。