移动IM开发之技术选型

移动IM开发那些事

两年都在做Android IMSDK。今天突然心血来潮，想对现在的IM即时通讯技术做个总结，文章大部分内容应用其他博客，请谅解。

IM传输层协议

目前我所知道的IM传输时使用的是UDP、TCP、基于TCP的Http协议。

UDP

UDP:用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
目前使用该协议的应该只有QQ吧。
关于QQ使用UDP的问题（请见《为什么QQ用的是UDP协议而不是TCP协议？》帖子中的讨论）。个人不清楚QQ使用UPD作为传输层协议的初衷，但猜测是因为10多年前Client 10K问题没有得到很好解决，一台服务器支撑不了1W个TCP连接 ，腾讯的同时在线量高，没办法，只有用UDP了，但UDP又不可靠，故只能在UDP上实现TCP的超时／重传／确认等机制啦。

TCP

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
目前大部分IM都是该协议。如蘑菇街IM、陌陌、微信
基于TCP长连接则能够更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。

基于TCP的HTTP协议

该协议主要用于Web IM。目前大多数WebIM都使用WebSocket。它的优点是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性无法很好地保证，对大规模的用户量支持不够，比较适合小型的IM系统,如小网站的客户系统。
参考基于web的IM软件通信原理分析

IM应用层协议

数据格式的选定可以从以下方面进行考虑

1. 网络数据大小——占用带宽，传输效率：虽然对单个用户来说，数据量传输很小，但是对于服务器端要承受众多的高并发数据传输，必须要考虑到数据占用带宽，尽量不要有冗余数据，这样才能够少占用带宽，少占用资源，少网络IO，提高传输效率；

2. 网络数据安全性——敏感数据的网络安全：对于相关业务的部分数据传输都是敏感数据，所以必须考虑对部分传输数据进行加密；

3. 编码复杂度——序列化和反序列化复杂度，效率，数据结构的可扩展性，可维护性：对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性，可维护性，人力成本和实施复杂度也必须考虑在内；

4. 协议通用性——大众规范：数据类型必须是跨平台，数据格式是通用的，大家普遍能接受上手的；

可以参考：
如何选择即时通讯应用的数据传输格式

---

通过以上方面，对下面的几种数据格式进行分析：

| 优点 | 缺点 ｜
---- | --- | --- | ---
xmpp协议： | 基于xml协议，容易理解，使用广泛，易于扩展。 |流量大，在移动终端也耗电。交互过程复杂。多被pc时代的产品使用，不适合移动时代的IM产品，即使我们基于xmpp进行改进，简化握手过程，改进文件传输机制，但是它的基因决定了如何改进，他都不适合移动互联网时代的IM产品。
mqtt协议 | 适配多平台，IBM开发的即时通信协议 |协议简单，需要自己扩展好友，群组等功能
私有协议 | 随心所欲，自己定义，流量小。 |工作量巨大，扩展性差，需要考虑全面。

后续会对XMPP进行分析,XMPP至少是一个时代。虽然老旧，但是对于深入IM研究很有价值
现在市面上IM的协议使用私有协议,方便扩展业务

私有协议

私有协议的数据格式一般是基于二进制流协议。常见的二进制序列化有Protobuf和MessagePack。或者你可以自己写序列化过程（这是个痛苦的过程~）
建议使用probuf,在实际使用中较为方便，并且具有自动生成Java,OC,C++代码功能。

特别注明：
我们团队在刚开始是使用自定义协议，通过读取字节流的方式读取内容。
非常不适合扩展,每次新增功能都要改动很多。
现在已经切换到protobuf,使用的还是挺溜的，不用关心如何读取返回的字节流

大家可以看下这篇文章强列建议将Protobuf作为你的即时通讯应用数据传输格式

---

其他

后续的计划，会间歇性的发布关于IM的文章

移动IM开发之XMPP MQTT分析   
移动IM开发之IM功能定位
移动IM开发之心跳  
移动IM开发之登录优化     
移动IM开发之消息     
移动IM开发之IMSDK竞品比较   
移动IM开发之IM App竞品对比  
移动IM开发之安全协议涉及与考虑  

IM相关的文章

即时通讯网 http://www.52im.net/

---

专注在一滴水上，或许能够得到整片大海