MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT）。
Copy From MQTT协议（一）：理论篇
MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：
1.使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
这一点很类似于XMPP，但是MQTT的信息冗余远小于XMPP（因为XMPP使用的是XML这种格式来传递数据，你懂的）。
2.对负载内容屏蔽的消息传输。
3.使用TCP/IP提供网络连接。
主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。
4.有三种消息发布服务质量：
- “至多一次”，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。
- “至少一次”，确保消息到达，但消息重复可能会发生。这一种方式比较鸡肋，在我的想象中没能想到这种质量的发送在常规的APP开发中有什么用处。
- “只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。
5.小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。
这就是为什么在介绍里说它非常适合“在物联网领域，传感器与服务器的通信，信息的收集”，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。
6.使用Last Will和Testament特性通知有关各方客户端异常中断的机制。
- Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。
- Testament：遗嘱机制，功能类似于Last Will 。
本文来自MQTT协议（二）：推送篇
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是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
- XMPP的优点是：协议成熟，强大，可扩展性强，并且有成熟的开源方案。
- XMPP的缺点是：信息冗余量大（信息的格式是 XML），因而费流量，费电。
MQTT的具体概念已经在上一篇博客中详细的介绍了：MQTT协议（一）：理论篇 。
- MQTT的优点是：协议简洁轻巧，数据冗余量低。并且支持的设备从智能硬件到智能手机无所不包。
- MQTT的缺点是：服务器端实现难度大，虽然已经有了C++版本的服务端组件，但是并不开源。而且在推送数量较大时如何处理并发是十分考验后台人员的技术水平的。