IM软件设计注意事项

原创

mb644789379f291 2023-04-26 01:50:51 ©著作权

©著作权归作者所有：来自51CTO博客作者mb644789379f291的原创作品，请联系作者获取转载授权，否则将追究法律责任

a,xmpp:报文大，调用次数多
b，微信用了长链接和短链接相结合，微信划分了http模式（short链接）和 tcp 模式（long 链接），分别应对状态协议和数据传输协议
c，
1 、两个域名

微信划分了http模式（short链接）和 tcp 模式（long 链接），分别应对状态协议和数据传输协议

long.weixin.qq.com dns check （112.64.237.188 112.64.200.218）
short.weixin.qq.com dns check ( 112.64.237.186 112.64.200.240)

2、说明

2.1 short.weixin.qq.com
是HTTP协议扩展，运行8080 端口，http body为二进制（protobuf）。
主要用途（接口）：
用户登录验证;
好友关系（获取，添加）；
消息sync (newsync)，自有sync机制；
获取用户图像；
用户注销；
行为日志上报。
朋友圈发表刷新

2.2 long.weixin.qq.com
tcp 长连接，端口为8080，类似微软activesync的二进制协议。
主要用途（接口）：
接受/发送文本消息；
接受/发送语音；
接受/发送图片；
接受/发送视频文件等。

所有上面请求都是基于tcp长连接。在发送图片和视频文件等时，分为两个请求；第一个请求是缩略图的方式，第二个请求是全数据的方式。

2.2.1 数据报文方面
增量上传策略：
每次8k左右大小数据上传，服务器确认；在继续传输。

图片上传：
先传缩略图，传文本消息，再传具体文件

下载：
先下载缩略图，在下载原图
下载的时候，全部一次推送。

3 、附录
3.1 用户登录验证
POST /cgi-bin/micromsg-bin/auth HTTP/1.1
Accept: **
User-Agent: Mozilla/4.0
Content-Type: application/x-www-form-urlencoded
Host: short.weixin.qq.com
Content-Length: 174

3.3 消息sync (newsync)
POST /cgi-bin/micromsg-bin/newsync HTTP/1.1
Host: short.weixin.qq.com
User-Agent: Android QQMail HTTP Client
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: application/octet-stream
accept: **
Content-Length: 206

3.5 用户注销
POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0
Cotent-Type: application/x-www-form-urlencoded
Host: short.weixin.qq.com
Content-Length: 271

3.6 行为日志上报
POST

/cgi-bin/stackreport?version=240000a7&filelength=1258&sum=7eda777ee26a76a5c93b233eed504c7d&reporttype=1&username=jolestar
HTTP/1.1
Content-Length: 736
Content-Type: binary/octet-stream
Host: weixin.qq.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

d,XMPP并不能很好地做到业务逻辑独立开来。从IM的本质来看，IM其实就是将一条消息从一个地方传输到另外一个地方，这个和TCP很像，为什么不
实现一个高级点的TCP协议了，只是将TCP/IP里面的IP地址换成了一个类似XMPP的唯一ID而已，其他的很多细节都可以照搬TCP协议。有了这个
协议之后，将业务逻辑在现有HTTP
server的基础上做，例如发送语音和图片就相当于上传一个文件，服务器在处理完这个文件后就发一条特殊的IM消息。客户端收到这个IM消息后，按照
IM消息里面url去HTTP server取语音文件和图片文件。将HTTP server和IM
server打通之后，可以做很多事情。但将这个两个server合并在一块并不是一个好
e,应用除了游戏，都没怎么赚钱，现在能够承载赚钱业务的还是以web为主。IM不可以赚钱，但没有却是不行的，就像一个地方要致富，不修路是不行的道理
f,XMPP的缺点：流量大（基于XML），不可
靠（为传统固定网络设计，没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景），交互复杂（登陆需5-6次，尤其是TLS握手）；XMPP丢消息的
根本原因：服务端和客户端处于“半关闭”状态，客户端假连接状态，服务端有收不到回执；Server端连接层和逻辑层代码没有解耦分离，常常重启导致不可

f,xmpp:三四十万连接数，
g,netty自己实现
连接层（参见通讯服务器组成）：只做消息转发，允许随时重启更新，设计原则简单/异步；单台压测试连接数70W；现状：1.5亿用户，月活5000W+，连接数1200W+；
h,核心的长连接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP连接；一切就绪后，最重要的就是监控，写一个APP查看所有的运营状态，每天观察；
i,智能路由、连接策略：
多端口、双协议支持
应对移动网关代理的端口限制
支持TCP、HTTP两种协议
根据备选IP列表进行并发测速（IP+端口+协议）
后端根据终端连接情况，定时更新终端的备选IP列表
终端在连接空闲时上报测速数据，便于后端决策
TCP协议不通，自动切换到http
优先使用最近可用IP
并发测速，根据终端所处的位置下发多组IP、PORT，只用IP，不用域名，手机上的DNS50%不准
负载均衡器(LVS...)的问题– 单点失效
单点性能瓶颈
负载均衡从客户端开始做起• 域名负载的问题
域名系统不可靠– 更新延迟大