即时通讯(IM)功能是APP的重要功能之一，而开发好移动IM却绝非易事。通常来说，IM技术选型至少要解决以下问题：1. 协议选型 2. IM服务器选型 3. 对协议和服务器做相应修改，通常来说直接拿个标准协议和开源服务器是一定不能用到生产环境的 4. 保证消息到达率，绝不丢消息。 以上4点搞定后基本就有了一个可用的IM平台上。想更上一层楼，可以对电量和流量等做进一步优化，或者研究怎样支持百万级以上的用户，话说 你可以吗？
   1、IM协议选型：IM协议的前生今世以及协议各自的优缺点常用作IM的协议包括XMPP，MQTT，SIP以及自行开发的私有协议。它们各自优缺点是什么。2、标准XMPP协议的问题与改进方法XMPP协议是目前大多数开发者的主流选择，但XMPP协议本身并不是一个为移动设备设计的协议。它的问题是什么，怎么改进。3、IM服务器的选择：IM服务器各自的优缺点及改进方案常用的开源IM服务器包括OpenFire，Tigase，Prosody，Mosquitto，ejabberd等，它们各自的优缺点是什么。以openfire为例，需对openfire服务器源代码做哪些修改。4、 保证消息到达率：在任何情况下消息绝不丢失，是移动IM的基本需求，但也是一个主要的技术难点。5、移动终端耗电量优化和流量优化：如心跳包优化，协议优化等6. 支持百万以上同时在线用户：集群方案的选择和坑点
   这些 你中心有能力做到吗？大忽悠了吧，想着怎么收尾吧，大数据 是你等草包能所为？

作者简介： 陈宜龙（），iOS 开发工程师，现任职于 LeanCloud，热爱开源与分享， 获得的 Star 数过万，也是多个开源项目的维护者，比如 、 等。

IM 已经成为当下 App 的必备模块，在不同垂直领域，技术实现不尽相同。究竟该如何选型？技术实现过程中，又该如何进行性能调优？本篇文章分为应用场景、技术实现细节、针对移动网络特点的性能调优三个部分，具体讲解IM即时通讯技术在社交、直播、红包等不同场景下的技术实现与性能调优。

需要注意，本文中所涉及到的所有 iOS 相关代码，均已 100% 开源（不存在 framework ），便于学习参考；本文侧重移动端的设计与实现，会展开讲，服务端仅仅属于概述，不展开；本文还将为大家在设计或改造优化 IM 模块，提供一些参考。

大规模即时通讯的技术难点

• 如何在移动网络环境下优化电量、流量及长连接的健壮性？现在移动网络有 2G、3G、4G 各种制式，且随时可能切换和中断，移动网络优化可以说是面向移动服务的共同问题。
• 如何确保IM系统的整体安全？因为用户的消息是个人隐私，所以要从多个层面来保证。
• 如何降低开发者集成门槛？
• 如何应对新iOS生态下的政策并结合新技术，比如 HTTP/2、IPv6、新的 APNs 协议等。

IM 服务的最大价值在于什么？可复用的长连接。一切高实时性的场景，都适合使用 IM 来做，比如：视频会议、聊天、私信、弹幕、抽奖、互动游戏、协同编辑、股票基金实时报价、体育实况更新；基于位置的应用（Uber、滴滴司机位置）、在线教育、智能家居等。

接下来，我们会挑一些典型场景进行介绍，并分析其中具体的技术细节。

IM 基本的发展历程是：轮询、长轮询、长连接。

下面挑选一些代表性的技术进行介绍：

• 一般的网络请求：一问一答，如图1所示。
• 轮询：频繁的一问一答，见图2。
• 长轮询：耐心地一问一答，见图3，曾被Facebook早期版本采纳。

一种轮询方式是否为长轮询，是根据服务端的处理方式来决定的，与客户端没有关系。

短轮询很容易理解，那么，什么叫长轮询？与短轮询有何区别？长轮询和短轮询最大的区别是，短轮询去服务端查询时，不管服务端有没有变化，服务器就立即返回结果了。而在长轮询中，服务器如果检测到库存量没有变化话，将会把当前请求挂起一段时间（这个时间也叫作超时时间，一般是几十秒）。在这个时间内，服务器会检测库存量有没有变化，变化就立即返回，否则就等到超时为止。

我们可以看到，发展历史是这样：从长短轮询与长短连接，使用 WebSocket 来替代 HTTP。长短轮询到长短连接的区别主要有：

1. 概念范畴不同：长短轮询是应用层概念，长短连接是传输层概念；
2. 协商方式不同：一个 TCP 连接是否为长连接，是通过设置 HTTP 的 Connection Header 来决定的，且需要两边都设置才有效。
3. 实现方式不同：连接的长短是通过协议来规定和实现的。而轮询的长短，是服务器通过编程的方式手动挂起请求实现的。

在移动端上长连接是趋势，其最大的特点是节省 Header。对比轮询与 WebSocket 所花费的 Header 流量即可窥其一二。

假设 Header 是 871 字节，我们以相同的频率 10W/s 去做网络请求，对比轮询与 WebSocket 所花费的 Header 流量。其中，Header 包括请求和响应头信息。出于兼容性考虑，一般建立 WebSocket 连接也采用 HTTP 请求的方式，从这个角度讲，无论请求如何频繁，都只需要一个 Header。

相同的每秒客户端轮询的次数，当次数高达 10W/s 的高频率时，Polling 轮询需要消耗 665Mbps，而 WebSocket 仅仅只花费了 ，网址