MQTT 什么是协议？
随着 5G 随着时代的到来，万物互联的伟大理念正在成为现实。 物联网设备 在 2018 年已达 70 未来两年，仅智能水电表就将超过10亿。
大量的设备接入和设备管理给网络带宽、通信协议和平台服务架构带来了巨大的挑战。 物联网协议 来说，必须针对性地解决物联网设备通信的几个关键问题：其网络环境复杂而不可靠、其内存和闪存容量小、其处理器能力有限。
MQTT 协议 是基于发布/订阅模式的物联网通信协议，易于实现和支持 QoS、小报文占据了物联网协议的一半:
MQTT 协议的诞生
MQTT was created by Andy Stanford－Clark of IBM， and Arlen Nipper （then of Arcom Systems， later CTO of Eurotech）．
据 Arlen Nipper 在一 IBM Podcast 上的自述，MQTT 原名是 MQ TT， 注意 MQ 与 TT两者之间的空间，全称为： MQ Telemetry Transport，九十年代初，他在参与 Conoco Phillips 公司原油管道数据采集监控系统（pipeline SCADA system）实时数据传输协议的开发。其目的是使传感器通过带宽有限 VSAT ，与 IBM 的 MQ Integrator 通信。其目的是使传感器通过带宽有限 VSAT ，与 IBM 的 MQ Integrator 通信。由于 Nipper 它来自遥感和数据采集监控专业，所以根据行业惯例给出了一个 MQ TT 的名字。
MQTT 协议设计原则
按照 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 版本。
三个可选的 QoS 等级
为适应设备不同的网络环境，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 设计了稍微复杂的重新发送和重复新闻发现机制，确保新闻到达对方，严格只到达一次。
会话保持
MQTT 没有假设设备或 Broker 使用了 TCP 协议层的保存机制是设计的 CONNECT 可在报文中设置 Keepalive 设置保存心跳包 PINGREQ／PINGRESP 发送时间间隔。当设备长时间无法收到时 PINGREQ 的时候，Broker 设备已下线。
总的来说，Keepalive 有两个功能：
发现对端死亡或网络中断
长时间无信息交互时，保持连接不被网络设备断开
对于那些想在离线期间重新上线后再次收到错过消息的设备，MQTT 持久连接的设计： CONNECT 可在报文中设置 CleanSession 字段为 False，则 Broker 会为终端存储：
所有订阅设备
该设备尚未确认 QoS1 和 QoS 消息
设备离线时错过的消息
在线状态感知
MQTT 设计了遗愿（Last Will） 消息，让 Broker 在发现设备异常下线时，帮助设备向指定主题发布遗愿信息。
其实在某些方面 MQTT 实现服务器 （比如 EMQX），当设备上线或下线时， Broker 设备状态更新将通过一些系统主题发布，更符合实际应用场景。
开源 MQTT 如何选择服务器？
到目前为止，开源更受欢迎 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 考虑稳定性、扩展性、集群能力等方面，EMQX 性能应该是最好的：
使用 Erlang OTP 发展，容错能力好 (电信领域经过长期考验的语言，曾经做过 99．9999999％ 可用交换设备)
有大量的官方扩展插件可以扩展。有许多认证插件，数据存储（backend）插件可供选择。可支持各种关系型数据库，NoSQL 数据库和常见消息队列，如 Kafka，RabbitMQ，Pulsar 等
支持集群，支持节点水平扩展
单节点支持 2000K 并发连接
支持规则引擎和编解码
MQTT 协议快速体验
MQTT 在线服务器
EMQX MQTT 物联网云服务 提供了一个在线的公共 MQTT 5．0 不需要任何安装就可以快速开始服务器 MQTT 协议的学习、测试或原型制作。
该 MQTT 请参阅服务器的详细访问信息 EMQ 官网页面：免费在线 MQTT 服务器。
MQTT 在线客户端
EMQ 它还提供了支持浏览器访问的支持 MQTT 支持普通或加密的在线客户端工具 WebSocket 端口连接至 MQTT 服务器还支持缓存连接，方便下次访问。
作者：原创文章：EMQ，如果转载，请注明出处
原文标题 : EMQ帮助开发者快速理解 MQTT 协议及其相关特征
