IM通信相关协议调研

传输层 应该使用什么协议？

目前常用的传输层协议中有TCP与UDP：

1. 早期的IM因为服务端资源（服务器硬件、网络带宽等）比较昂贵且没有更好的办法来分担性能负载，所以很多时候会考虑使用UDP，这其中主要是早期的QQ为代表。
2. 时至今日，TCP的服务端负载已经有了很好的解决方案，加之服务器资源成本的下降，目前很多IM、消息推送解决方案也都在使用TCP作为传输层协议。不过，UDP也并未排除在IM、消息推送的解决方案之外，比如：弱网络通信（包括跨国的高延迟网络环境）、物联网通信、IM中的实时音视频通信等等场景下，UDP依然是首选项。

所以目前比较适合的方案就是IM项目中的消息发送（包含文字、语音、表情、图片等）采用TCP协议，即时音视频服务采用UDP协议能更好的保证消息的即时性和有效性。

应用层 到底该使用什么协议？

目前基于TCP且可用于即时通讯的应用层协议有HTTP，XMPP，websocket协议。

1. HTTP仅支持客户端向服务端发送请求，如果在IM项目中使用HTTP来实现即时通讯，比较常用的方式是采用轮询 (polling)和comet，其中轮询 (polling)会持续消耗客户端的资源和设备电量，并且无法保证消息的实时性。而使用comet会在服务端产生阻塞，由于长期占用连接，让web丧失了无状态高并发的特点，大量消耗了服务器带宽和资源。
2. XMPP使用TCP传递xml流。使用xml承载数据拥有很强的可拓展性和可读性，但是在服务端没有必要兼容其他公司IM服务的前提下 而去xml格式的文件的传输一样会带来不必要的带宽占用和资源消耗。 关于更多的XMPP协议的分析见 https://blog.csdn.net/xlikec/article/details/87930748
3. websocket相比HTTP协议的comet技术，不仅节约了header的问题（websocket的head信息只有短短的2个字节）。更加重要的是是通信的稳定性，comet在遇到网络问题之后，想要在不刷新页面的情况下恢复通信，非常困难，而websocket中提供了onclose函数来处理断开网络后的情况，这为我们与服务器的通信提供了可靠的保障。在github上有一个js库（https://github.com/joewalnes/reconnecting-websocket） 就是通过这种方式来处理websocket断网重连。 关于更多websocket的分析可见https://blog.csdn.net/xlikec/article/details/88061586

所以在当前的时间节点下，移动即时通讯程序采用websocket协议作为的应用层协议是一个合适的选择。