转: http://ruby-china.org/topics/22530
最近在看移动IM相关的资料， 然后发现网上有很多的资料，所以在学习过程中，整理了一些笔记， 供那些 想了解 移动IM的童鞋一些参考。
移动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服务
1、环信(个人感觉选他不错), 大概是从2013年4月创立， 到目前为止号称 有6000万注册用户， 有1000+ app使用
2、leancloud 2013 年 9 月发布以来，已经吸引了近万移动应用和开发者加入。
七、结论
如果说自己搭建一套IM框架的:
- 基本能用需要3个月
- 做的比较好需要9月到1年时间
- 做的像微信一样，那么需要2年时间
如果说基于现有的IM服务器搭建的话， 个人觉得 从IMserver性能以及后期维护和招人成本上来看， 应该是 Tigase > Openfire > Ejabberd
八、写在最后
如果你也对IM感兴趣的话，可以看一看 环信的一个讲座, 对应的ppt。
当然了， 由于我本人接触IM 这块也不太久， 所以肯定会有一些遗漏， 欢迎大家提意见呀...
---纯文章的搬运工！
来源：oschina
链接：https://my.oschina.net/u/1382024/blog/681133