MQTT 协议是什么？
随着 时代的来临，万物互联的伟大构想正在成为现实。联网的 在 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 通讯。由于 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 服务器，内置壮大的规则引擎，支持许多其他 协议好比 MQTT－SN、 CoAP、Lw 等。
Mosca使用 Node．JS 开发的 MQTT 服务器，简朴易用。
VerneMQ同样使用 Erlang 开发的 MQTT 服务器．
从支持 MQTT 5．0、稳固性、扩展性、集群能力等方面思量，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 协议及其相关特征