前戏

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的 通信协议 。

MQTT是轻量级基于代理的发布/订阅的消息传输协议，它可以通过很少的代码和 带宽 和远程设备连接。例如通过卫星和代理连接，通过拨号和医疗保健提供者连接，以及在一些自动化或小型设备上，而且由于小巧，省电，协议开销小和能高效的向一和多个接收者传递信息，故同样适用于称动应用设备上。

相信在想深入学习这个协议必是奔着解决某个问题而来的，上面给出了适用的场景，我之所以想深入的学习和了解这个协议，理由如下：

• 可以实现手机消息推送（PUSH）
• 协议简单，最小的头部只需2个字节，特别适合于嵌入式设备场景中。
• 这是个了解什么是协议绝好的例子。相比于其它复杂的协议例如 TCP 、http协议，至少说明文档看的下去。

MQTT简介

早在1999年，IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士发明了MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）技术 。

MQTT的话题是他们在谈论开源物联网平台Pachube时提到的。Stanford-Clark认为Pachube很酷，其不足之处是不具备真正的推送功能。你需要不断的进行 轮询 才能得到即时数据。这正是MQTT能够实现的，他提到了使用推送通信系统的石油管道检测系统。

MQTT应用现状

IBM和St. Jude 医疗中心通过MQTT开发了一套Merlin系统，该系统使用了用于家庭保健的传感器。St. Jude医疗中心设计了一个叫做Merlin@home的心脏装置，这种无线发射器可以用来监控那些已经植入复律-除颤器和起搏器（两者都是基本的传感器）的心脏病人。

该产品利用MQTT把病人的即时更新信息传给医生/医院，然后医院进行保存。这样的话，病人就不用亲自去医院检查心脏仪器了，医生可以随时查看病人的数据，给出建议，病人在家里就可以自行检查。

IBM称该发射器包括一个大型触摸屏，一个嵌入式键盘平台，以及一个Linux操作系统。

在未来几年，MQTT的应用会越来越广，值得关注。

通过MQTT协议，目前已经扩展出了数十个MQTT服务器端程序，可以通过PHP，JAVA，Python，C，C#等系统语言来向MQTT发送相关消息。

此外，国内很多企业都广泛使用MQTT作为Android手机客户端与服务器端推送消息的协议。其中Sohu，Cmstop手机客户端中均有使用到MQTT作为消息推送协议。随着移动互联网的发展，MQTT由于开放源代码，耗电量小等特点，将会在移动消息推送领域有更多的贡献，在物联网领域，传感器与服务器的通信，信息的收集，MQTT都可以作为考虑的方案之一。在未来MQTT会进入到我们生活的各各方面。

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 。

市面上的主流推送方案应用比较

1，APNS（Apple Push Notification Service）和GCM（ Google Cloud Messaging）

APNS和GCM是iOS和Android两大阵营提出的官方推送方案，这两者的技术架构较为相似。都是由系统来统一的维护一个 长连接 ，所有的APP统一发送心跳和接收推送。

APNS使用的方便性毋庸置疑，但是GCM却在国内举步维艰，具体原因有以下三个：

• Google与我国政府交恶，导致 GMS （Google Mobile Service）在国内无法正常使用，而GCM是依赖于GMS的，所以无法顺利使用。
• 由于国内2G和移动3G的NAT超时时间都小于GCM心跳时间(28分钟)，TCP长连接必然无法保活，每次都要等28分钟心跳失败重连后才能收到Push。
• 某些运营商可能限制了5228端口，移动3G/2G下，发现几乎无法连接上GCM服务器，也就无法获得GCM通知，WhatsApp放后台10分钟后，经常很长时间都收不到Push消息。

2，XMPP

XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

XMPP的优点是： 协议成熟，强大，可扩展性强，并且有成熟的开源方案。

XMPP的缺点是： 信息冗余量大（信息的格式是 XML），因而费流量，费电。

3，MQTT

MQTT的具体概念已经在上面的文字中介绍过了，总结如下：

MQTT的优点是： 协议简洁轻巧，数据冗余量低。并且支持的设备从智能硬件到智能手机无所不包。

MQTT的缺点是： 服务器端实现难度大，虽然已经有了C++版本的服务端组件，但是并不开源。而且在推送数量较大时如何处理并发是十分考验后台人员的技术水平的。

4，HTTP轮询

HTTP轮询就是在一个给定的时间间隔后，定时向服务器发送请求，查看是否有新的数据。

HTTP轮询的优点是： 实现简单、可控性强，部署硬件成本低。

HTTP轮询的缺点是： 实时性差，只有时间到了才会向服务器查看是否有新的数据。两次请求之间的时间间隔过大，则失去了即时推送的意义。但如果设置的时间间隔较短的，又会费电费流量。

5，第三方推送

在推送这一分支领域有许许多多的第三方推送服务，例如：极光，个推等。

优点是： 集成方便。

缺点是： 大量推送数据后，付费服务是在所难免。而且因为是通用共享云，所以你的服务质量是否有保证，也就不能要求太多了，必竟你一毛钱也没出或者也不打算出。

结语

目前各大公司采用的方案中，不外乎上面描述的几种。

在本头条号的主页置顶文章中有【文章分类】包含:

[数据库系列]

[数据结构和算法系列]

[高级网络编程篇系列]

[Linux系统篇系列]

[C++进阶篇系列]

[C++基础知识篇系列]

[协议篇系列]

[设计模式系列]

不要只收藏和转发哦，点击屏幕右上角的【关注】每天文章不落下。

本头条号文章分类目录（精心整理）