Hi ，各位小伙伴们，又见面啦，有木有很想念呀。不知道上次分享的关于 IM 底层协议的知识对大家有木有帮助，今天俺要就 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.解析代价超高（ dom 解析）
c.有效数据传输率超低（大量的标签）
个人旗帜鲜明的强烈不建议使用 xmpp ，特别是无线端 im ，如果要用，一定要自己做压缩 ，减少网络流量（用过 xmpp 的同学都清楚，发一个登录包需要多少交互，要浪费多少流量）。
实际的栗子
下面来看一个 im 协议的实际例子 ，一般常见的做法是：定长二进制包头，可扩展变长包体。
包体可以使用用文本、 XML 等扩展性好的协议。
包头负责传输和解析效率，与业务无关。包体保证扩展性，与业务相关。
这是一个实际的 16 字节 im 二进制定长包头：
//sizeof(csheader)=16
struct cs_header
{
uint32_t version;
uint32_t magic_num;
uint32_t cmd;
uint32_t len;
uint8_t data[];
}attribute_((packed));
前 4 个字节是 version ；
接下来的 4 个字节是个“魔法数字（ magic_num ）“，用来保证数据错位或丢包问题，常见的做法是，包头放几个约定好的特殊字符，包尾放几个约定好的特殊字符 约定好，发给你的协议，某几个字节位置，是 0x 01020304 ，才是正常报文；
接下来是 command （命令号），用来区分是 keepalive 报文、业务报文、密钥交换报文等；
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 等技术后，多连接就不是瓶颈了，单机几十万链接没什么问题。）
关于 QQ 使用 UDP 的问题
个人不清楚 QQ 使用 UPD 的初衷，但猜测是因为 10 多年前 C10K 问题没有得到很好解决，一台服务器支撑不了 1W 个 TCP 连接 ，腾讯的同时在线量高，没办法，只有用 UDP 了 ，但 UDP 又不可靠，故只能在 UDP 上实现 TCP 的超时／重传／确认等机制
好了，这次只介绍了 im 协议选型，欢迎大家留言吐槽哦~！
