移动客户端中的长连接技术

在移动互联网的App开发中，我们经常遇到这样的场景：
1) IM类应用。当A用户与B用户聊天时，A用户向对方发送消息时，需要将A用户发送的消息推送至B用户。
2) App的配置信息。以滴滴打车为例，用户在不支持滴滴打车的城市打开app，它会提示当前城市暂不支持打车，一般的原理就是，app会维护一份当前支持打车的城市列表，每新上线一个城市就会更新这份列表。
以上两类场景本质上是相似的，即数据在服务端，并且随时可能更新，那么客户端如何获取更新的数据呢，最简单直接的我们会想到客户端定时向服务端询问有没有最新的数据，如果有就拉取，即最为常见的轮询方案。
轮询(pull)：
事实上很多时候我们都在这么做，对于简单的小应用来说，也是简单快捷的实现方案。假设App中有个样式资源文件，改变这个文件可以在不重新安装app的情况下实现产品视觉效果的极大改善，如果能够在不重新安装App的情况下，动态的升级文件，改善完美我们的产品效果是不是很酷？那该怎么实现呢？

App启动时检查一下，OK，搞定。
但是对于IM类场景呢，我们能频繁的发起数据查询请求么？

如果真的这么实现了，那估计你就距离失业不远了，因为完全没有考虑移动产品的特性：
耗电量：移动设备的一天一充电的电池续航能力本就广为诟病，如果你在后台不断的轮询，可能很快用户的手机变成了冬天的暖宝宝。当然如果是我，会毫不犹豫的干掉你的应用。
流量：目前的移动网络还远远没有达到用户对流量无视的境况，尤其是2G/3G/4G用户，你耗费的那都是用户的真金白银。
如果能够采用某种方法，在服务端数据变化时，将数据主动通知到客户端，那这个问题是不是就迎刃而解。不错，这就找到了问题的关键。
Push机制
就像搞公司面试一样，你不用打电话一直询问我有没有通过，如果通过了我会打电话通知你。
但是通知的前提是你面试的时候的简历上得有电话号码，对，这个很重要。没有电话号码等多久都白费。
我们有电话号码么？很遗憾，No，我们没有。
我们的网络协议都是基于HTTP的，目前普遍使用的是Http 1.1,还有Http1.0，HTTP协议是无状态的，是请求/应答范式的。显然服务器是无法向客户端发起请求的，因为服务器不知道客户端的地址，也不了解客户端的App是打开关闭。服务端和客户端通信的前提是，客户端需要向服务端发送请求，通知服务端我的地址是多少，我要什么东西。
目前看来似乎很悲伤，Http协议不支持服务器主动向客户端推送消息(至少目前不支持)，并且所有的请求必须要客户端先发起请求。那服务器就没有主动向客户端Push的机会。
基于socket的请求也是一样的结论。
是的，结论就是这样。必须要客户端先发起请求。
转机
既然无法由服务端主动向客户端Push消息，那就要考虑在现有的架构体系中解决这个问题，我们可以在App启动的时候跟服务器建立起一条链接，在App退出的时候关闭。这样所有的问题都迎刃而解：
 请求由客户端发起。
 服务端随时可以向客户端push数据
在具体的实现上，大家见仁见智，我们采用的是通过socket自定义协议的方案。目前在多项业务上也得到了充分的实践，具体如何实现，下节继续讨论。