[TOC] ## im协议的分层设计 1. 语法:即数据与控制信息的结构或格式 2. 语义:即需要发出何种控制信息,完成何种动作以及做出何种响应 3. 时序:即事件实现顺序的详细说明 ![UTOOLS1577453271335.png](http://yanxuan.nosdn.127.net/6461e9605adc8ec4b5f848fb0f04b914.png) ## 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协议 ![UTOOLS1577452724647.png](http://yanxuan.nosdn.127.net/abc67a701e117988b220f45d65d17b63.png) 二进制协议一般定长包头和可扩展变长包体 ,每个字段固定了含义 ,例如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等技术后,多连接就不是瓶颈了,单机几十万链接没什么问题。