[分享] IM 协议设计选型

融云布道师 发布于 2015/11/16 15:02
阅读 1K+
收藏 8

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 协议选型,欢迎大家留言吐槽哦~!

加载中
0
uller
uller
有比较好的克服动态nat的思路否?广域对等网是否可实现?
0
s
shawngespan
最后一点,大家都觉得TCP可靠。有没有想过,网络不好的时候,UDP会丢包,TCP会怎么样,会保证消息一定传递到吗,网络不好的时候,TCP只会不断的去建立连接,通信环境不够,连接都建立不了,哪来的消息送达保障呢。如果这样,TCP负载又低,还会选TCP吗
s
shawngespan
@IT民工-南京     只是针对原文最后的疑问,就是这个意思
fagongzi
fagongzi
即时通讯的消息可靠性不是依靠TCP来实现的。都是靠私有协议来解决。
0
宏哥
宏哥

理论上, UDP最好

但是, UDP需要大量的额外工作。

要简化, 就用http, 最简单,进行轮询

0
乌龟壳
乌龟壳

这里连p2p都木有提到

QQ可以udp也可以tcp

0
k
kidding

IM需要的及时性把

HTTP不是全双工的,long poll的方式可以做到,但是有点麻烦,大量的长连接比较耗费资源

当然还需要控制心跳

0
lmlion
lmlion
Swoole可以考虑,我比较在乎移动IM在网络环境不稳定的情况下怎么给用户保持恢复链接的机制。
0
土卫十六
土卫十六

QQ使用UDP就是楼主说的原因,这都是老生常谈的问题了。

另外,“即时通讯的消息可靠性不是依靠TCP来实现的。都是靠私有协议来解决。”是指什么意思呢?

0
土卫十六
土卫十六
上次分享的关于 IM 底层协议的知识——没见到啊,可否再次分享一下?
0
回去干活
回去干活
websocket,基于wss
0
g
gglinux

写的不错,挺赞的!可以参考下这个哈

http://gglinux.com/2017/04/15/IM_design/

返回顶部
顶部