理论联系实际：一套典型的IM通信协议设计详解

JackJiang · 8 年前

前言

本文要谈的IM通信协议指的是应用层通信“语言”，并非指传输层协议（如TCP、UDP）。IM通信协议的制定是IM开发中起点，也是贯穿设计、开发、运维始终的核心所在，通信协议设计的好坏，直接影响后绪环节的用户体验（数据流量、耗电量、通信速度）、兼容性（新老版本的无缝融合）、扩展性（后绪的版本升级怎么办）等，是个基础且极其重要的工作之一。

本文将以理论联系实际的方式，详细讲解一套典型IM的通信协议设计的方方面面。

本文原作者是58同城网的沈剑：58同城技术委员会主席、高级架构师、优秀讲师。前百度hi团队成员，负责过58同城im系统的架构设计。

IM通信协议的分层设计

所谓“协议”是双方共同遵守的规则，例如：离婚协议，停战协议。

协议有语法、语义、时序三要素：

（1）语法：即数据与控制信息的结构或格式
（2）语义：即需要发出何种控制信息，完成何种动作以及做出何种响应
（3）时序：即事件实现顺序的详细说明

一套典型的IM通信协议设计分为三层：应用层、安全层、传输层。

理论联系实际：一套典型的IM通信协议设计详解_b.jpeg

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协议的一个图示：

理论联系实际：一套典型的IM通信协议设计详解_a.jpeg

二进制协议一般定长包头和可扩展变长包体，每个字段固定了含义，例如IP协议的前4个bit表示协议版本号（Version）（详情请参见《TCP/IP详解》第3章）。

二进制协议有这样一些特点：

a. 可读性差，难于调试
b. 扩展性不好，如果要扩展字段，旧版协议就不兼容了，所以一般设计时会有一个Version字段
c. 解析效率超高（几乎没有解析代价）
d. 对二进制的支持不好，比如语音／视频

IM中，QQ使用的时二进制协议。

3流式XML协议

IM的准标准协议xmpp就是使用流式XML，像gtalk，校内通这些im都是基于xmpp的。让我们来看一个xmpp协议的例子：

<message
to=’[url=mailto:romeo@example.net]romeo@example.net[/url]’
from=’[url=mailto:juliet@example.com]juliet@example.com[/url]’
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.XML的优点，可读性好，扩展性好
c.解析代价超高（dom解析）
d.有效数据传输率超低（大量的标签）

个人旗帜鲜明的强烈不建议使用xmpp，特别是无线端im，如果要用，一定要自己做压缩，减少网络流量（用过xmpp的同学都清楚，发一个登录包需要多少交互，要浪费多少流量）。

4实际的例子

下面来看一个im协议的实际例子。一般常见的做法是：定长二进制包头，可扩展变长包体。包体可以使用用文本、XML等扩展性好的协议。包头负责传输和解析效率，与业务无关。包体保证扩展性，与业务相关。

这是一个实际的16字节im二进制定长包头：

//sizeof(cs_essay-header)=16
struct cs_essay-header
{
    uint32_t version;
    uint32_t magic_num;
    uint32_t cmd;
    uint32_t len;
    uint8_t data[];
}__attribute__((packed));

- a. 前4个字节是version；
- b. 接下来的4个字节是个“魔法数字（magic_num）“，用来保证数据错位或丢包问题，常见的做法是，包头放几个约定好的特殊字符，包尾放几个约定好的特殊字符约定好，发给你的协议，某几个字节位置，是0x 01020304 ，才是正常报文；
- c. 接下来是command（命令号），用来区分是keepalive报文、业务报文、密钥交换报文等；
- d. 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的文章请见《强列建议将Protobuf作为你的即时通讯应用数据传输格式》：http://www.52im.net/thread-277-1-1.html，更多IM的协议方面的文章请见：http://www.52im.net/forum.php?mod=collection&action=view&ctid=18）

个人旗帜鲜明的推荐使用Protobuf，主要有几个原因：

a. 现成的解析库种类多，可以生成C++、Java、php等10余种语言代码（详见请点击：http://www.52im.net/thread-277-1-1.html）
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等技术后，多连接就不是瓶颈了，单机几十万链接没什么问题。58同城现在线上单机连接好像是10w？（可能单机性能测试可以到百万，线上一般跑到几十万）

关于QQ使用UDP的问题（请见《为什么QQ用的是UDP协议而不是TCP协议？》帖子中的讨论）。个人不清楚QQ使用UPD作为传输层协议的初衷，但猜测是因为10多年前Client 10K问题没有得到很好解决，一台服务器支撑不了1W个TCP连接，腾讯的同时在线量高，没办法，只有用UDP了，但UDP又不可靠，故只能在UDP上实现TCP的超时／重传／确认等机制啦。

结语

关于QQ使用UDP协议，在讨论的过程中，有同学提出了一个非常好的问题“无线环境下，UDP更好，可以做到状态无关，而TCP不稳定，进出电梯就要断线，用户体验不好”。

其实吧，“用户状态可以设计的与连接状态无关”，如果大家感兴趣，后续我可以撰文和大家聊一聊，传输层使用TCP，怎么做到在线状态与底层连接无关。

附录：更多相关精华文章

2 楼: 只是路过 · 8 年前

说的很不错，牛逼哄哄高大上的架构文章也比不上几行实用的文字和代码有意义，收藏了

3 楼: mo_mean · 8 年前

收藏·

4 楼: otnp · 8 年前

感谢，已收藏

5 楼: ayuan9900 · 8 年前

赞一个

6 楼: 石头 · 7 年前

不错不错，简单明了

7 楼: jituijiaqiezi · 7 年前

收藏收藏

8 楼: zjjishitongxun · 7 年前

很实用，不错

9 楼: Sands_Lee · 7 年前

实用，Mark

10 楼: Sands_Lee · 7 年前

要做IMSDK真是件头大的事情啊

11 楼: JackJiang · 7 年前

引用：Sands_Lee 发表于 2017-08-31 18:15
要做IMSDK真是件头大的事情啊

慢慢撸

12 楼: dusuijiang · 7 年前

收藏了。

13 楼: xy521174 · 7 年前

学习了

14 楼: x931609201 · 7 年前

58的单机是10w链接？那么厉害，我们现在才一万啊

15 楼: 1924458916 · 7 年前

感谢，已收藏

16 楼: cndragonsoft · 6 年前

感谢，已收藏楼主一直在用心整理供我们学习辛苦了！

17 楼: toocruel · 6 年前

学习

18 楼: zhangyilife · 6 年前

学习了

19 楼: 南城东就 · 6 年前

学习了

20 楼: zhouhoumian · 6 年前

学习了

本文目录

前言

IM通信协议的分层设计

IM应用层协议设计

1文本协议

2二进制协议

3流式XML协议

4实际的例子

IM安全层协议设计

1使用SSL

2自行加解密

IM传输层协议设计

结语

更多类似文章

附录：更多相关精华文章

本帖已收录至以下技术专辑

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

精华之王

白金版主

终身成就

青铜版主

推广达人

即时通讯网

友情链接[友链交换]

关于

微信公众号new

本文目录

前言

IM通信协议的分层设计

IM应用层协议设计

1文本协议

2二进制协议

3流式XML协议

4实际的例子

IM安全层协议设计

1使用SSL

2自行加解密

IM传输层协议设计

结语

更多类似文章

附录：更多相关精华文章

本帖已收录至以下技术专辑

MobileIMSDK(v6.5精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

精华之王

白金版主

终身成就

青铜版主

推广达人

即时通讯网

友情链接[友链交换]

关于

微信公众号new

IM传输层协议设计

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　