陌陌通讯协议的学习

陌陌发展刚开始由于规模小，30-40W的连接数（包括Android后台长连接用户），也使用XMPP；由于XMPP的缺点：流量大（基于XML），不可靠（为传统固定网络设计，没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景），交互复杂（登陆需5-6次，尤其是TLS握手）；XMPP丢消息的根本原因：服务端和客户端处于“半关闭”状态，客户端假连接状态，服务端有收不到回执；Server端连接层和逻辑层代码没有解耦分离，常常重启导致不可用。

消息中转：

连接层（Connector链接集群）

• 连接层的作用：只做消息转发
• 设计原则简单/异步
• 允许随时重启更新/只允许晚上重启/不允许重启断线
• 单台压测试连接数70W；现状：5亿用户，月活5000W+，连接数1200W+；

逻辑层（Logic逻辑集群）

• 用户会话验证
• 消息存取
• 异步队列
• 随时重启

通讯协议设计：

• 安全性要求
• 流量要求
• 传输要求可靠（不会丢消息）
• 高效（弱网络快速的收发）
• 易于扩展

通讯协议：

• 常见协议XMPP/SIP
• 缺点：流量大，不可靠，交互复杂

采用私有通讯协议，目标：

• 高效，弱网络快速收发；
• 可靠,不会丢消息；
• 易于扩展；
• 参考协议格式：REDIS协议；

Redis协议：

下面都是用Redis协议来描述逻辑

Read Redis Command

基于队列的消息协议

基于队列的交互

• 传统的IM协议
• 前提是基于网线、WiFI，网络延迟极小
• 移动网络下，交互及其费时，服务器要维护每个状态容易出错

基于版本号的消息协议

基于版本号的交互

针对弱网络的优化协议

• 消息通过版本号维护顺序
• 新消息到达，Server只负责push通知
• Client收到轻量的msg-psh后发生同步请求
• Server按照版本号连续发送msg
• Client告诉Server收到的最后的版本

监控

• 核心的长连接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP连接；一切就绪后，最重要的就是监控，写一个APP查看所有的运营状态，每天观察；

如何选择最优路线智能路由、连接策略：

多端口、双协议支持，应对移动网关代理的端口限制

• 支持TCP、HTTP两种协议
• 根据备选IP列表进行并发测速（IP+端口+协议）
• 后端根据终端连接情况，定时更新终端的备选IP列表
• 终端在连接空闲时上报测速数据，便于后端决策
• TCP协议不通，自动切换到http
• 优先使用最近可用IP
• 并发测速，根据终端所处的位置下发多组IP、PORT，只用IP，不用域名，手机上的DNS50%不准