如果觉得我写的还不错，请关注我的新浪微博@杨浩宇-小橘爷，最新文章即时推送~
MQTT协议（一）：理论篇
MQTT协议（三）：实战篇
主流推送方案：
APNS（Apple Push Notification Service）和GCM（Google Cloud Messaging）
APNS和GCM是iOS和Android两大阵营提出的官方推送方案，这两者的技术架构较为相似。都是由系统来统一的维护一个长连接，所有的APP统一发送心跳和接收推送。
APNS使用的方便性毋庸置疑，但是GCM却在国内举步维艰，具体原因有以下三个：
1、Google与我国政府交恶，导致GMS（Google Mobile Service）在国内无法正常使用，而GCM是依赖于GMS的，所以无法顺利使用。
2、由于国内2G和移动3G的NAT超时时间都小于GCM心跳时间(28分钟)，TCP长连接必然无法保活，每次都要等28分钟心跳失败重连后才能收到Push。
3、某些运营商可能限制了5228端口，移动3G/2G下，发现几乎无法连接上GCM服务器，也就无法获得GCM通知，WhatsApp放后台10分钟后，经常很长时间都收不到Push消息。
XMPP
XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
XMPP的优点是：协议成熟，强大，可扩展性强，并且有成熟的开源方案。
XMPP的缺点是：信息冗余量大（信息的格式是 XML），因而费流量，费电。
MQTT
MQTT的具体概念已经在上一篇博客中详细的介绍了：MQTT协议（一）：理论篇 。
MQTT的优点是：协议简洁轻巧，数据冗余量低。并且支持的设备从智能硬件到智能手机无所不包。
MQTT的缺点是：服务器端实现难度大，虽然已经有了C++版本的服务端组件，但是并不开源。而且在推送数量较大时如何处理并发是十分考验后台人员的技术水平的。
HTTP轮询
HTTP轮询就是在一个给定的时间间隔后，定时向服务器发送请求，查看是否有新的数据。
HTTP轮询的优点是：实现简单、可控性强，部署硬件成本低。
HTTP轮询的缺点是：实时性差，只有时间到了才会向服务器查看是否有新的数据。两次请求之间的时间间隔过大，则失去了即时推送的意义。但如果设置的时间间隔较短的，又会费电费流量。
第三方推送
在推送这一分支领域有许许多多的第三方推送服务，例如：极光，个推等。
优点是集成方便。
缺点是大量推送数据后，付费服务是在所难免。
林林总总的推送方案大体就这些了，但是对于iOS开发者而言，后台保持长连接的权限极其难以获取，如果处理不当甚至会被APP Store的审核人员打回原形。所以，还是老老实实的使用APNS或第三方推送的服务吧~
4381
到【灌水乐园】发言
Yunba云巴官博
我们云巴是基于 MQTT 协议实现的实时通信系统，消息推送是我们其中的一项产品服务。说下我们做消息推送的一点心得以及 MQTT 的一些要点吧。
一、消息推送机制
1、频道（Topic）
在 MQTT 3.1 协议中，对 Topic Name（又叫 Subject 或 Channel）是这样描述的：The topic name is the key that identifies the information channel to which payload data is published. Subscribers use the key to identify the information channels on which they want to receive published information.
简而言之，频道名称 是用来让发布者和订阅者区分不同频道的标识符。云巴的 频道名称 支持英文、数字、正斜杠（频道分级符）和下划线，长度不超过 128 个字符。
2、通过“频道”进行一对多的消息发布
3、别名（Alias）
客户端连到云巴服务器后，会被分配一个唯一的 UID，云巴内部用 UID 来标识 AppKey 下的不同客户端。由于 UID 是一串毫无规律的字符串，在实际应用中难以辨识，于是我们引入了 别名 的概念。用户可以为每个客户端设置一个有意义的名字——别名，我们会将客户端的 别名 与客户端的 UID 进行绑定，让用户可以通过 别名 来标识客户端，进行一对一通信。
4、通过“别名”进行一对一通信
二、云巴 Android 消息推送
客户端集成了云巴的 Android SDK，服务端可通过云巴的 SDK 或使用 RESTful API，向 Android 客户端发消息。（目前Android消息推送已支持一键集成第三方推送https://yunba.io/docs/android_sdk_third_part_push）
1、后台保持长连接
Android SDK 会启动一个后台的 Service，创建并保持到云巴服务器的长连接，从而保证了消息推送的实时性。
2、确保消息的送达
云巴 SDK 支持 离线消息 的功能，可保证消息送达客户端。
三、云巴 iOS 消息推送
客户端集成了云巴的 iOS SDK， 服务端通过云巴的 SDK 向 iOS 设备发消息。
一方面，云巴的服务器会负责向苹果的服务器发送 APNs 的消息； 另一方面，当应用在前台运行时，云巴会通过与 App 建立的长连接，直接推送内部消息。
1、集成 APNs
云巴 SDK 集成了 APNs，开发者无需开发与 APNs 对接的模块，也不必自己负责 Device Token 的更新，一切交给云巴。
2、确保消息的送达
众所周知，APNs 并不保证消息的送达。 而云巴 SDK 支持 离线消息 的功能，可保证消息送达客户端。
四、QoS
云巴兼容标准的 MQTT 3.1 协议，本文介绍一下协议中的 QoS。
1、QoS 定义
QoS，全称为 Quality of Service，即服务质量。在 MQTT 协议中，QoS 可分为以下三个等级：
“QoS = 0”: At most once. Fire and Forget. （至多一次，发完即删，不保证送达。）
“QoS = 1”: At least once. Acknowledged delivery. （保证至少送达一次。）
“QoS = 2”: Exactly once. Assured delivery. （保证送达，且仅送达一次。）