1.1概念
MQTT(MQ Telemetry Transport) 消息队列遥测传输协议是IBM开发的一种网络应用层的协议，提供轻量级的，支持可发布/可订阅的的消息推送模式，使设备对设备之间的短消息通信变得简单，比如现在应用广泛的低功耗传感器，手机、嵌入式计算机、微型控制器，卫星等移动设备。
1.2优点
1.2.1非常低的通信开销
MQTT 的独特之处在于，它的每消息标题可以短至 2 个byte。MQ 和 HTTP 都拥有高得多的每消息开销。对于 HTTP，为每个新请求消息重新建立 HTTP 连接会导致重大的开销。MQ 和 MQTT 所使用的永久连接显著减少了这一开销。
1.2.2低功耗，省电
您需要能够及时地将通知传递给客户。为此，必须采用某种定期轮询或推送方法；从电池、系统负载和带宽角度讲，推送是最佳解决方案。MQTT 是专门针对低功耗目标而设计的。HTTP 的设计没有考虑此因素，因此增加了功耗。
1.2.3单机百万级并发
在 HTTP 堆栈上，维护数百万个并发连接，需要做许多的工作来提供支持。尽管可以实现此支持，但大多数商业产品都为处理这一数量级的永久连接而进行了优化。IBM 提供了 IBM MessageSight，这是一个单机架装载服务器，经过测试能处理多达 100 万个通过 MQTT 并发连接的设备。相反，MQ 不是为大量并发客户端而设计的。
1.2.4对网络环境的容忍度
MQTT提供三种不同消息传递等级，让消息能按需到达目的地，适应在不稳定工作的网络传输需求。MQTT 和 MQ 能够从断开等故障中恢复，而且没有进一步的代码需求。但是，HTTP 无法原生地实现此目的，需要客户端重试编码，这可能增加幂等性问题。
1.2.5客户端多平台支持
支持各种流行编程语言（包括C，Java，Ruby，Python 等等）且易于使用的客户端。
1.2.6发布/订阅模式，开发简易
支持发布 / 订阅模型，简化应用程序的开发。
1.2.7推送通知
企业可能需要在没有第三方中介的情况下发送敏感的信息。这降低了特定于操作系统的解决方案（比如 Apple iOS、Google Play 通知）作为主要传输机制的价值。
HTTP 只允许使用一种称为COMET 的方法，使用持久的 HTTP 请求来执行推送。从客户端和服务器的角度讲，此方法都很昂贵。MQ 和 MQTT 都支持推送，这是它们的一个基本特性。
1.2.8防火墙容错
一些企业防火墙将出站连接限制到一些已定义的端口。这些端口通常被限制为 HTTP（80 端口）、HTTPS（443 端口）等。HTTP 显然可以在这些情况下运行。MQTT 可封装在一个 WebSockets 连接中，显示为一个 HTTP 升级请求，从而允许在这些情况下运行。MQ 不允许采用这种模式。
1.3缺点
由于MQTT本身的各项技术优势，越来越多的企业倾向于选用MQTT作为物联网产品通讯的标准协议，也因此，工程师们渐渐发现MQTT协议要想大规模商用，也有一些有待完善的功能。比如：
1.3.1没有齐备的SDK
不同的异构终端，需要有对应的与MQTT服务器通信的软件SDK包，比如MCU、Linux、Android、IOS、WEB等之间要实现互联互通必然需要不同的SDK包。
1.3.2不支持File和AV
有些应用场景，需要传输的信息可能不仅仅限于指令，比如声音信号和视频信号，这些需要通过File和AV来实现通信。
1.3.3不支持与第三方的HTTP集成
虽然MQTT协议优于普通的HTTP协议，但是基于传统的HTTP协议的WEB服务器仍然占主流市场，那么这些服务器要实现与MQTT协议的互联互通，以降低升级成本也尤为关键。
1.3.4不支持用户管理接口
用户在进行设备的行为数据分析的时候，显得尤为重要，这又是工业4.0、大数据时代的必然需求。
1.3.5原生不支持离线
消息弥补设备离线以后，MQTT服务器对设备的控制信息丢失的问题。
（解决方案：https://helpcdn.aliyun.com/document_detail/59914.html）
1.3.6不支持点对点通信
采用标准的MQTT协议，理论上可以通过相互订阅的方式实现点对点通信，但是逻辑相对复杂，并且对设备的安全性方面存在担忧。当设备B和设备C在同一主题的情况下，设备A无法知道是设备B还是设备C发送的消息，也有可能消息被设备D窃听。
1.3.7不支持群通信和群管理
实现了对群组成员的管理，群组成员之间能互通消息，这在一个设备被多人控制，或者多个设备被一人控制的这种场景下，尤为有用。
1.4实现
1.4.1 交互图
怎么样，是不是一目了然，非常简单