自研分布式IM RFC草案

HubuIM RFC草案

消息协议设计

基本协议

评估标准
  1. 【性能】协议传输效率,尽可能降低端到端的延迟,延迟高于200ms用户侧就会有所感知

  2. 【兼容】既要向前兼容也要向后兼容

  3. 【存储】减少消息包的大小,降低空间占用率,一个字节在亿级别并发之下也是一亿个字节

  4. 【计算】减少编解码时造成的CPU使用率的权衡

  5. 【网络】尽可能减少网络带宽消耗

  6. 【安全】协议安全性

  7. 【迭代】要能够快速迭代,灵活拓展

  8. 【通用】可跨平台接入,H5,IoT设备等等

  9. 【可读】

基本结构

IM协议的设计从纵向来看分为三个层次,应用层/安全层/传输层。

应用层

有很多开源协议,例如MQTT,websocket等等。但是这些协议冗余的字段比较多,在大型IM的场景下一般都是自定义协议的。

因此HubuIM采用自定义协议

序列化方式使用protobuf,这个是无可争议的。

安全层

基于密钥的生命周期可以分为

  • TLS/SSL:加密效果好,证书的管理比较复杂

  • 固定加密:通信前客户端和服务端约定好密钥和加密算法(会被黑客逆向)

  • 一人一密:使用用户特定的属性进行加密,例如密码

  • 一次一密:这个是最安全的,创建连接建立一次会话,双方进行加密三次握手(非对称),对称加密传输。

加密消耗的是CPU资源,是CPU密集型操作。如果放到接入层或者业务逻辑层来做的话,会影响到他们的正常运行。因此应该在四层网络负载或者七层网络负载的地方去解密,内网环境默认是安全的。

因此HubuIM采用的方式是TLS3.0+网关终止

在Nginx处就进行解密,Nginx所在的机器可以使用硬件来进行优化,例如用GPU加速,用Intel加速器等等。

那么为什么不在LVS(四层网络负载均衡器)上面去做加密解密,然后直接发到IM网关,这样可以让网络通信少跳一次。

这个问题是因为Nginx这个七层负载均衡的地方相当于是公司的一个基础架构层,是要做很多事情的,不方便去掉的。

传输层

可以使用UDP或者TCP协议。微信这种很定义的可能使用UDP+QUIC这种保证可靠性。因为UDP是无状态的传输协议,不会存储连接的状态,在弱网环境下更优,消息风暴发生的可能性更小。

UDP的话需要在应用层写大量的代码来保证可靠性,难度非常大,因此HubuIM使用TCP协议。弱网环境在应用层来进行优化。

总结

HubuIM协议

对于传输层使用TCP,安全层使用TLS,应用层使用自研二进制协议+开源序列化协议。

既然使用了TCP协议,那么我们面临的一个问题就是TCP的粘包,拆包问题。具体解决方法我们在后面讲解。

消息可用性

基本概念

  • 长链接 vs 短链接。我们才用的是长链接和短链接共同作用,短链接作为旁路。

  • 各种ID

    • connID:代表的是一个TCP链接

    • clientID:代表的是client发送给IM Server的用来标识本客户端消息发送顺序的ID,仅仅是本客户端,该ID并不代表消息的全局一致。需要有递增性质。

    • seqID:当IM Server收到clientID之后生成的会话内消息顺序一致的seqID。需要有递增性质。

    • sessionID:会话ID

    • msgID:代表的是一个消息的ID

  • PULL 与 PUSH 模式。PULL就是client向IM Server拉取消息,使用短链接减少TCP链接的压力。PUSH就是IM Server通过TCP长链接推送消息。

  • 通信复杂度:网络传输过程中经过的节点可以说是一个性能瓶颈,不能经过太多节点。消息风暴就是网络中有太多的报文,会压垮IDC。常见于弱网环境,弱网下消息丢失严重,TCP的可靠性反而成为延迟,让网络中有大量的报文。

背景介绍

对于IM来说,消息的可靠与一致就是:可达有序,不重不漏。

有人会问:TCP已经保证一致性了,那么为什么IM还有保证一致。

其实答案很简单:TCP只能保证到内核传输层为止的可靠性,但是应用层的可靠性你是没有办法保证的。

设计IM必须有端到端的设计思维:底层可靠不等于上层可靠,底层一致不等于上层一致

方案选型

技术挑战是什么?

  • 三方通信,网络层面无法保证消息必达

  • 没有全局时钟,确定唯一顺序,并且是符合因果顺序的

  • 多客户发送/多服务端接收/多线程多协程处理,顺序难以确定。

解决方案是学习TCP:

  • 消息及时:服务端实时接收消息并实时在线发送

  • 消息可达:超时重试,ACK确认

  • 消息幂等:分配seqID,服务端存储seqID

  • 消息有序:seqID可以比较。

上行消息

clientID严格递增

弱网问题是传输层的问题,可以优化传输层协议,例如升级成Quic来优化,长连接不适合在弱网环境下工作。

消息转发
  • seqID在会话内有序就行,这样就可以解决redis的单点问题。

  • seqID需要在ACK之前分配,否则ACK成功发出去之后,服务器宕机了,这样seqID就等于没有分配,会出现问题。

  • 如果服务端在存储消息,业务处理,接入层路由的时候失败怎么办?

    • 消息存储之后再回复ACK,如果ACK失败则客户端重试时再次幂等的回复ACK。

    • 一旦消息存储,如果服务崩溃导致长连接断开,客户端重新建立连接时可以发送一个pull信令,拉去历史消息进行消息补洞,保证可靠性。

  • 消息存储可以交给MQ异步的进行。

下行消息

分配seqID的时候针对redis的单点使用lua脚本来进行一个ID的跳变。

客户端发现消息不连续的时候可能是因为消息跳变了,但是他无法确认,因此不能直接拒绝,而是发送pull信令来进行增补,如果拉去不到新消息则说明是跳变导致。

推拉结合+长短连接结合+服务端打包整流:假如是一个群聊,一下子有100M信息,我会把这些信息放在一个窗口里面,不会一个一个发送,这样的批处理可以提高效率。然后窗口大了之后服务端向客户端发送一个pull信令,让客户端发起一个请求来用短链接拉取这个窗口里面的数据。

  • 23
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

胡桃姓胡,蝴蝶也姓胡

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值