HubuIM RFC草案

消息协议设计

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

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

因此HubuIM采用自定义协议

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

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

加密消耗的是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：

clientID严格递增

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

seqID在会话内有序就行，这样就可以解决redis的单点问题。
seqID需要在ACK之前分配，否则ACK成功发出去之后，服务器宕机了，这样seqID就等于没有分配，会出现问题。
如果服务端在存储消息，业务处理，接入层路由的时候失败怎么办？
- 消息存储之后再回复ACK，如果ACK失败则客户端重试时再次幂等的回复ACK。
- 一旦消息存储，如果服务崩溃导致长连接断开，客户端重新建立连接时可以发送一个pull信令，拉去历史消息进行消息补洞，保证可靠性。
消息存储可以交给MQ异步的进行。