流水不争先,争的是滔滔不绝

移动IM开源框架对比

Tigase 云聊IM 3849℃

移动IM技术选型要点

1、协议选型

2、IM 服务器选型

3、协议和IM服务器改造

4、移动IM常见问题以及一些解决方案

5、一些第三方服务

一、常用的IM协议

二、IM 服务器的选择

经过这几天在网上的调研, 发现目前比较流行的几个IM 服务器 也就是 Openfire、Tigase, Ejabberd:

三、XMPP协议的问题及改进

1、登录握手部分改进

Xmpp QuickStart

2、心跳改进

原先Xmpp使用的Ping/Pong 40+字节, 改进为单向 white space ping, 4字节。

备注: 心跳单向四个字节,在Xmpp协议下,估计应该是极限了吧。在私有协议协议下,一来一往两个字节足够。

3、文件传输

– Xmpp 的文件传输采用的点对点的传输; 改进为http 上传到server

– 语音、视频压缩上传

– 图片默认下载缩略图

4、Presense

移动互联网环境下,不管用户是否在线, 都会假设 用户永远在线。

这是因为移动网络环境导致, 比如从wifi 切换到 3G、处于地铁、WIFI边缘地带等, 如果还采用PC端 类似QQ那种方式, 很可能会造成重连风暴。

5、Muc 聊天室

Muc 是聊天室协议,在业务层面进行改进, 发送消息时 发送给所有用户,不管他在不在线

四、基于Openfire 服务器的改进

1、发送消息回执

在server端维护一个消息队列, 当收到client发送会的消息回执时, 将这个消息删掉

2、性能改进

不要使用内置的数据库, 对于Vcard或者好友列表信息 可以考虑放到Redis

3、海量消息

如果是消息量很大的话, 消息存储可以使用Kafka(和数据库集群之间存定时拉取关系),分布式锁基于Zookeeper,前端LVS做负载均衡。

五、移动IM的那些坑点

1、长连接

Android 平台 维护client 到server的长连接

IM或推送,建立长连接是必须的,可以节省TCP来回创建的开销,但断线之后,是否需要即刻重连,尤其是处于地铁、WIFI边缘地带,可能会造成重连风暴,需要添加稍加延迟连接机制。

2、心跳包 GGSN

维护移动网GGSN

3、消息回执处理Ack

移动网络很容易丢包, 发送、接受应加入回执处理

4、语音、图片的收发优化

大数据拆分成多个包, 一个包大概10字节

六、第三方的IM服务

现在第三方的IM云服务很多,如环信,融云,网易云信,leancloud等,可以参看这篇文章3款IM云服务产品对比

七、结论

如果说自己搭建一套IM框架的:

– 基本能用 需要3个月

– 做的比较好 需要9月到1年时间

– 做的像微信一样,那么需要2年时间

如果说基于现有的IM服务器搭建的话, 个人觉得 从IMserver性能以及后期维护和招人成本上来看, 应该是 Tigase > Openfire > Ejabberd

版权声明:部分文章、图片等内容为用户发布或互联网整理而来,仅供学习参考。如有侵犯您的版权,请联系我们,将立刻删除。
点击这里给我发消息