随着 5G 时代的来临，万物互联的伟大构想正在成为现实。联网的 物联网设备 在 2018 年已经达到了 70 亿，在未来两年，仅智能水电气表就将超过10亿。
海量的设备接入和设备管理对网络带宽、通信协议以及平台服务架构都带来了很大挑战。对于 物联网协议 来说，必须针对性地解决物联网设备通信的几个关键问题：其网络环境复杂而不可靠、其内存和闪存容量小、其处理器能力有限。
MQTT 协议 是基于发布/订阅模式的物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山：
MQTT was created by Andy Stanford-Clark of IBM, and Arlen Nipper (then of Arcom Systems, later CTO of Eurotech).3
据 Arlen Nipper 在一 IBM Podcast 上的自述，MQTT 原名是 MQ TT， 注意 MQ 与 TT之间的空格，其全称为: MQ Telemetry Transport，是九十年代早期，他在参与 Conoco Phillips 公司的一个原油管道数据采集监控系统(pipeline SCADA system)时，开发的一个实时数据传输协议。它的目的在于让传感器通过带宽有限的 VSAT ，与 IBM 的 MQ Integrator 通信。由于 Nipper 是遥感和数据采集监控专业出身，所以按业内惯例给了个 MQ TT 的名字。
按照 Nipper 的介绍，MQTT 必须简单容易实现，必须支持 QoS(设备网络环境复杂)，必须轻量且省带宽(因为那时候带宽很贵)，必须数据无关(不关心 Payload 数据格式)，必须有持续地会话感知能力(时刻知道设备是否在线)。下面将介绍 MQTT (3.1.1 版本) 的几个核心特色，分别对应了这几个设计原则的实现。
发布订阅模式是传统 Client/Server 模式的一种解耦方案。发布者通过 Broker 与消费者之间通信，Broker 的作用是将收到的消息通过某种过滤规则，正确地发送给消费者。发布/订阅模式 相对于 客户端/服务器模式 的好处在于： ● 发布者和消费者之间不必预先知道对方的存在，比如不需要预先沟通对方的 IP Address 和 Port ● 发布者和消费者之间不必同时运行。因为 Broker 是一直运行的。 在 MQTT 协议里，上面提到的 过滤规则 是 Topic。比如：所有发布到 news 这个 Topic 的消息，都会被 Broker 转发给已经订阅了 news 的订阅者:
上图中订阅者预先订阅了 news，然后发布者向 Broker 发布了一条消息 "some msg" 并指定发布到 news 主题，Broker 通过 Topic 匹配，决定将这条消息转发给订阅者。
MQTT 的 Topic 有层级结构，并且支持通配符 + 和 #: ● + 是匹配单层的通配符。比如 news/+ 可以匹配 news/sports，news/+/basketball 可匹配到 news/sports/basketball。 ● # 是一到多层的通配符。比如 news/# 可以匹配 news、 news/sports、news/sports/basketball 以及 news/sports/basketball/x 等等。 MQTT 的主题是不要预先创建的，发布者发送消息到某个主题、或者订阅者订阅某个主题的时候，Broker 就会自动创建这个主题。
MQTT 协议将协议本身占用的额外消耗最小化，消息头部最小只需要占用 2 个字节。 MQTT 的消息格式分三部分：
固定长度头部，2 个字节，所有消息类型里都有
可变长度头部，只有某些消息类型里有
Payload，只有某些消息类型里有
MQTT 的主要消息类型有： ● CONNECT / CONNACK ● PUBLISH / PUBACK ● SUBSCRIBE / SUBACK ● UNSUBSCRIBE / UNSUBACK ● PINGREQ / PINGRESP ● DISCONNECT 其中 PINGREQ / PINGRESP 和 DISCONNECT 报文是不需要可变头部的，也没有 Payload，也就是说它们的报文大小仅仅消耗 2 个字节。 在 CONNECT 报文的可变长度头部里，有个 Protocol Version 的字段。为了节省空间，只有一个字节。所以版本号不是按照字符串 "3.1.1" 存放的，而是使用数字 4 来表示 3.1.1 版本。
为适应设备不同的网络环境，MQTT 设计了 3 个 QoS 等级，0, 1, 2: ● At most once (0) ● At least once (1) ● Exactly once (2) QoS 0 是一种 "fire and forget" 的消息发送模式：Sender (可能是 Publisher 或者 Broker) 发送一条消息之后，就不再关心它有没有发送到对方，也不设置任何重发机制。 QoS 1 包含了简单的重发机制，Sender 发送消息之后等待接收者的 ACK，如果没收到 ACK 则重新发送消息。这种模式能保证消息至少能到达一次，但无法保证消息重复。 QoS 2 设计了略微复杂的重发和重复消息发现机制，保证消息到达对方并且严格只到达一次。
QoS（Quality of Service，服务质量）指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，
是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。QoS的保证对于容量有限的网络来说是十分重要的，
特别是对于流多媒体应用，例如VoIP和IPTV等，因为这些应用常常需要固定的传输率，对延时也比较敏感。
MQTT 没有假设设备或 Broker 使用了 TCP 的保活机制4，而是设计了协议层的保活机制：在 CONNECT 报文里可设置 Keepalive 字段，来设置保活心跳包 PINGREQ/PINGRESP 的发送时间间隔。当长时间无法收到设备的 PINGREQ 的时候，Broker 就会认为设备已经下线。 总的来说，Keepalive 有两个作用： ● 发现对端死亡或者网络中断 ● 在长时间无消息交互的情况下，保持连接不被网络设备断开 对于那些想要在重新上线后，重新收到离线期间错过的消息的设备，MQTT 设计了持久化连接：在 CONNECT 报文里可设置 CleanSession 字段为 False，则 Broker 会为终端存储： ● 设备所有的订阅 ● 还未被设备确认的 QoS1 和 QoS 消息 ● 设备离线时错过的消息
MQTT 设计了遗愿(Last Will) 消息，让 Broker 在发现设备异常下线的情况下，帮助设备发布一条遗愿消息到指定的主题。 实际上在某些 MQTT 服务器的实现里 (比如 EMQX)，设备上线或下线的时候 Broker 会通过某些系统主题发布设备状态更新，更符合实际应用场景。
到目前为止，比较流行的开源 MQTT 服务器有几个：
- Eclipse Mosquitto使用 C 语言实现的 MQTT 服务器。Eclipse 组织还还包含了大量的 MQTT 客户端项目：https://www.eclipse.org/paho/#
- EMQX使用 Erlang 语言开发的 MQTT 服务器，内置强大的规则引擎，支持许多其他 IoT 协议比如 MQTT-SN、 CoAP、LwM2M 等。
- Mosca使用 Node.JS 开发的 MQTT 服务器，简单易用。
- VerneMQ同样使用 Erlang 开发的 MQTT 服务器. 从支持 MQTT 5.0、稳定性、扩展性、集群能力等方面考虑，EMQX 的表现应该是最好的： ● 使用 Erlang OTP 开发，容错能力好 (电信领域久经考验的语言，曾经做出过 99.9999999% 可用性的交换机设备5) ● 官方有大量的扩展插件可供扩展。有很多认证插件，数据存储(backend)插件可供选择。可支持各种关系型数据库，NoSQL 数据库，以及常见消息队列如 Kafka，RabbitMQ，Pulsar 等 ● 支持集群，支持节点水平扩展 ● 单节点支持 2000K 并发连接 ● 支持规则引擎和编解码
MQTT 协议是基于发布/订阅模式的轻量级物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。
MQTT 报文紧凑，可在严重受限的硬件设备和低带宽、高延迟的网络上实现稳定传输。
覆盖全语言平台的客户端和 SDK， AWS IoT Core、 Azure IoT Hub 等顶级云厂商物联网平台标准通信协议，物联网事实标准
基于发布/订阅模式，发布订阅模式的优点在于发布者与订阅者的解耦：订阅者与发布者不需要建立直接连接、也不需要同时在线。
提供心跳机制、遗嘱消息、QoS 质量等级+离线消息、主题和安全管理等全面的物联网应用特性。
开源地址：https://github.com/emqx/emqx/blob/master/README-CN.md EMQX 开源版文档：www.emqx.io/docs/zh/latest/ MQTT 入门及进阶
补充知识
客户端和服务器需要了解什么时候终止进程或者与对方断开连接。 应用进程之间没有任何数据交换,但仍然需要通过连接保持一个最小的数据流。 keepAlive是由一个保活计时器实现的。当计时器被激发,连接一端 将发送一个保活探测(简称保活)报文,另一端接收报文的同时会发送一个ACK作为响应。
TCP协议中实现KeepAlive但是保活机制存在争议。许多人认为,如果需要,这一功能也不应在TCP协议中提供, 而应在应用程序中实现。另一种观点认为,如果许多应用程序中都需要这一功能,那么在 TCP协议中提供的话就可以使所有的实现都包含这一功能。
保活功能在默认情况下是关闭的。TCP连接的任何一端都可以请求打开这一功能。保活功能可以被设置在连接的一端、两端,或者两端都没有。有几个配置参数可以用来控制保活 功能的操作。如果在一段时间(称为保活时间, keepalive time)内连接处于非活动状态,开启保活功能的一端将向对方发送一个保活探测报文。如果发送端没有收到响应报文,那么经过一个已经提前配置好的保活时间间隔(keepalive interval),将继续发送保活探测报文,直到发送探测报文的次数达到保活探测数(keepalive probe),这时对方主机将被确认为不可到达,连接也将被中断。 保活探测报文为一个空报文段(或只包含1字节)。它的序列号等于对方主机发送的 ACK报文的最大序列号减1。因为这一序列号的数据段已经被成功接收,所以不会对到达的报文段造成影响,但探测报文返回的响应可以确定连接是否仍在工作。探测及其响应报文都不包含任何新的有效数据(它是“垃圾”数据),当它们丢失时也不会进行重传。
TCP保活功能工作过程中,开启该功能的一端会发现对方处于以下四种状态之一：
对方主机仍在工作,并且可以到达。对方的TCP响应正常,并且请求端也知道对方 在正常工作。请求端将保活计时器重置(重新设定为保活时间值)。如果在计时器超时之前有应用程序通过该连接传输数据,那么计时器将再次被设定为保活时间值。 对方主机已经崩溃,包括已经关闭或者正在重新启动。这时对方的TCP将不会响应。 请求端不会接收到响应报文,并在经过保活时间间隔指定的时间后超时。超时前,请求端会 持续发送探测报文,一共发送保活探测数指定次数的探测报文,如果请求端没有收到任何探 测报文的响应,那么它将认为对方主机已经关闭,连接也将被断开。 客户主机崩溃并且已重启。在这种情况下,请求端会收到一个对其保活探测报文的响应,但这个响应是一个重置报文段,请求端将会断开连接。 对方主机仍在工作,但是由于某些原因不能到达请求端(例如网络无法传输,而且可 圃 能使用ICMP通知也可能不通知对方这一事实)。这种情况与状态2相同,因为TCP不能区 分状态2与状态4,结果都是没有收到探测报文的响应。 请求端不必担心对方主机正常关闭然后重启(不同于主机崩溃)的情况。当系统关机时, 所有的应用进程也会终止(即对方的进程),这会使对方的TCP发送一个FIN。请求端接收 到FIN后,会向请求端进程报告文件结束,并在检测到该状态后退出。
在出现短暂的网络错误的时候，保活机制有可能会使一个好的连接断开； 保活机制会占用不必要的带宽； 与TCP保活机制相关的攻击 使系统长时间地维护不必要的会话资源 是获得端系统隐藏的一些信息(虽然这些信息对于攻击者而言可能实用性有限)。 由于默认情况下TCP不会对保活报文进行加密,所以保活探测报文和确认报文都有可能被利用。然而,对于应用层的保活机制(例如ssh),这些报文都会被加密,所以也就不会出现上述情况。