MQTT基础——Part 1. 认识MQTT

共计 2612 个字符，预计需要花费 7 分钟才能阅读完成。

本文是《MQTT 基础》系列文章的第一部分，这个系列会详述 MQTT 协议的方方面面，包括 MQTT 协议的核心功能和概念，以及协议的一些基本信息和背景。

我不仅会探讨 MQTT 协议本身，还会介绍 MQTT 的安全或客户端库。因此，如果你对 MQTT 感兴趣，那么请订阅我的博客。

MQTT 是一个开放协议，我会介绍 MQTT 的基本概念（发布 / 订阅、客户端 / 经纪人）和基本功能（连接、发布 / 订阅）。随后，你需要逐一了解 MQTT 的特性，比如服务质量 QoS、消息的保存、持续的会话、最后遗嘱以及 SYS 主题。MQTT 安全没有放入《MQTT 基础》这个系列，因为它非常重要，所以单独阐述。
使用 Last Will 和 Testament 特性通知有关各个客户端异常中断的机制。

一、介绍 MQTT

MQTT 是一个支持客户端 - 服务器的发布 / 订阅消息传输的标准通信协议。MQTT 是轻量级的、开放的、简单的、在设计上是易于实现的。这些特性使得 MQTT 非常适合于许多场景，包括受限的环境，比如 M2M 的通信和物联网 IoT 通信，只需一点点计算资源和一点网络带宽就可以实现。

引用官方 MQTT3.1.1 规范的描述：
MQTT 规范中的摘要说的很好，描述了 MQTT 是怎么一回事。它是轻量级的、二进制的通信协议，在传输数据方面优于 HTTP 协议，因为它有最小的数据包开销。另一个重要的方面是，MQTT 极其容易在客户端实现。这完全满足资源受限的设备的需求。事实上，这也是 MQTT 发明的目标之一。

二、MQTT 的历史

MQTT 是 IBM 公司的安迪·斯坦福·克拉克和 Arcom 公司的阿伦·尼珀于 1999 年创建的协议，其目标是创建一个支持低电量、低带宽消耗的通信协议，主要用于通过卫星通信连接石油管道。他们指定了以下的目标：

1）简单、易实现
2）提供了数据交付 QoS
3）轻量级、高效的带宽利用
4）数据不可知
5）连续的会话感知

这些目标到目前仍然是 MQTT 的核心，但是 MQTT 的焦点已经从专有的嵌入式系统转移到了物联网 IoT。另一个比较困惑的是 MQTT 术语的缩写，原先是 Message Queuing Telemetry Transport，消息队列遥测传输，现在则没有缩写的说法，MQTT 就是 MQTT。其次，MQTT 不是消息队列相关的协议，也不是消息队列的解决方案，尽管它在某些场景下也需要消息队列，但一定要认清这一点。IBM 在内部使用 MQTT 很久，在 2010 年终于对外免费开放，任何人都可以实现它、使用它。

三、OASIS 标准和 MQTT 当前版本

MQTT 大约发布 3 年后，IBM 宣布 MQTT 应该被 OASIS 标准化，就像 AMQP、SAML、DocBook 标准化那样。整个标准化历时约 1 年，在 2014 年 10 月 29 日 MQTT 正式成为 OASIS 的官方标准，发布了最新的 MQTT 协议标准 3.1.1 版。MQTT 从 3.1 版到 3.1.1 版只是小版本的迭代，变化极小。总的来说，MQTT 3.1.1 是对 3.1 规范进行了改善，澄清了模糊之处，并尽可能使之向后兼容。而且一些最需要的新功能也包含进这个版本，所以 3.1.1 版不仅是维护版本。

四、MQTT 3.1 和 3.1.1 版的区别

在 3.1.1 版中，主要的改变有 6 个：

1）Session Present Flag

如果客户端使用持久会话进行连接（这意味着客户端不使用干净的会话），那么在 CONNACK 消息会引入一个额外的标志，以指示该 Broker 代理已经有了与客户端早先的会话信息（比如客户端订阅信息、队列消息活其他信息）。这是一个重要的新功能，它可以实现更高效的通信。现在，客户端得到反馈，如果 Broker 经纪人已经有了客户端的订阅，如果标志设置为 false，那么客户端只需订阅新主题。

2）失败订阅的附加错误码

在 MQTT 3.1.1 之前，客户端要查询自己的订阅是否被 Broker 经纪人批准，这是不可能的。这种情况在采用细粒度权限的 MQTT 主题管理时就可能出现。在 3.1.1 版新规范中，在 MQTT SUBACK 消息中新增了一个错误码 0x80，让​​客户端知道自己的订阅是否被禁止。

3）匿名 MQTT 客户端

如果使用场景需要临时的或匿名的 MQTT 客户端，在 3.1.1 版得到支持，可以设置 MQTT 客户端标识符为零字节长度。那么 MQTT 的 Broker 会自动分配给客户端一个临时的随机标识符。这一个特性非常有用，尤其是当客户端只需做发布、不需要订阅的情况，此时客户端无需做基于客户端 ID 的授权。

4）即时发布或不等待响应的突发 MQTT 消息

3.1.1 版为 MQTT 客户端设计了一个非常有趣的新功能，那就是客户端可以直接发送 MQTT PUBLISH 消息而无需等待 Broker 的 CONNACK 响应。这非常适用于微型、受限的 MQTT 客户端做连接 CONNECT、发布 PUBLISH、断开 DISCONNECT，而不需要处理来自 Broker 的响应的情况。这也适用于只关心尽可能发送数据而不维持长时间 TCP 连接的处于突发模式的客户端。当然，成熟的 Broker 在检查客户端是否被允许发布到这些主题之前，是不会发布消息的。

5）客户端 ID 可以很长

在 MQTT 3.1 版，每个客户 ID 不能超过 23 字节，这一点非常不方便，并能导致许多麻烦，例如客户端标识符要使用 UUID 的场景。在 3.1.1 版，Broker 可以使用 65535 字节的客户端 ID。

6）其他低级别的更改

• 在 CONNECT 的 Header 报头中，协议名从 MQIsdp 改为 MQTT。这节省了两字节的开销，并使得协议名称更易读。
• 所有的字符串编码现在统一为 UTF-8。
• 协议级字节从 3 字节增加到 4 字节。
• 在 WebSockets 上的 MQTT 通信（MQTT over WebSockets）现在终于确定。在 IANA 的标识符是 mqtt。

注：IANA（The Internet Assigned Numbers Authority，互联网数字分配机构）是负责协调一些使 Internet 正常运作的机构。由于 Internet 已经成为一个全球范围的不受集权控制的网络，为了使网络在全球范围内协调一致，有对互联网一些关键的部分达成技术共识的需要，这就是 IANA 的任务。
推荐使用 MQTT 3.1.1。

MQTT 基础——Part 2. 发布 / 订阅模式  http://www.linuxidc.com/Linux/2016-10/136404.htm

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-10/136408.htm