移动 IM 学习笔记[转]

转: http://ruby-china.org/topics/22530

最近在看移动IM相关的资料， 而后发现网上有不少的资料，因此在学习过程当中，整理了一些笔记， 供那些 想了解 移动IM的童鞋一些参考。

移动IM技术选型要点

一、协议选型
二、IM 服务器选型
三、协议和IM服务器改造
四、移动IM常见问题以及一些解决方案 
五、一些第三方服务

1、经常使用的IM协议

 

2、IM 服务器的选择

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

 

备注: 
详解Zoosk千万用户实时通讯背后的开源技术

3、XMPP协议的问题及改进

一、登陆握手部分改进

Xmpp QuickStart

二、心跳改进

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

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

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

- 语音、视频压缩上传

- 图片默认下载缩略图

四、Presense

移动互联网环境下，无论用户是否在线， 都会假设 用户永远在线。

这是由于移动网络环境致使， 好比从wifi 切换到 3G、处于地铁、WIFI边缘地带等， 若是还采用PC端 相似QQ那种方式， 极可能会形成重连风暴。

五、Muc 聊天室

Muc 是聊天室协议，在业务层面进行改进， 发送消息时 发送给全部用户，无论他在不在线

4、基于Openfire 服务器的改进

一、发送消息回执

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

二、性能改进

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

三、若是是消息量很大的话, 消息存储可使用Kafka（和数据库集群之间存定时拉取关系），分布式锁基于Zookeeper，前端LVS作负载均衡。

5、移动IM的那些坑点

一、长链接

android 平台 维护client 到server的长链接

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

二、心跳包 GGSN

维护移动网GGSN

三、消息回执处理Ack

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

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

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

6、第三方的IM服务

一、环信(我的感受选他不错), 大概是从2013年4月创立， 到目前为止号称 有6000万注册用户， 有1000+ app使用

 

二、leancloud 2013 年 9 月发布以来，已经吸引了近万移动应用和开发者加入。

 

7、结论

若是说本身搭建一套IM框架的:
- 基本能用须要3个月
- 作的比较好须要9月到1年时间
- 作的像微信同样，那么须要2年时间

若是说基于现有的IM服务器搭建的话， 我的以为 从IMserver性能以及后期维护和招人成本上来看， 应该是 Tigase > Openfire > Ejabberd

8、写在最后

若是你也对IM感兴趣的话，能够看一看 环信的一个讲座, 对应的ppt。

固然了， 因为我本人接触IM 这块也不过久， 因此确定会有一些遗漏， 欢迎你们提意见呀...

---纯文章的搬运工！