MQTT 协议学习：000-有关概念入门

--- title: protocol-app-mqtt-0-about date: 2020-02-03 11:22:51 categories: tags: - mqtt - protocol ---

背景

从本章开始，在没有特殊说明的情况下，文章中的MQTT版本均为 3.1.1。

MQTT 协议是物联网中常见的协议之一，"轻量级物联网消息推送协议"，MQTT同HTTP属于第七层（应用层）。

对于网络分层还不太熟悉的朋友请点击：《网络OSI七层模型及各层作用 与 TCP/IP》
参考：《物联网网关中MQTT和Modbus之间有何区别 》、《MQTT 入门介绍》
文档资料：《MQTT协议中文版资料》、《MQTT协议英文版资料》

MQTT 的发展历史

在物联网中，开源和开放标准是基本的要素。MQTT 的发展历史大致如下：

• 1999 年，IBM 和合作伙伴共同发明了 MQTT 协议。
• 2004 年， MQTT.org 开放了论坛，供大家广泛参与。
• 2011 年，IBM 建立了 Eclipse 开源项目 Paho ，并贡献了代码。Eclipse Paho 是 MQTT 的 Java 实现版本。
• 2013 年， OASIS MQTT 技术规范委员会成立。
• 2014 年，MQTT 正式成为推荐的物联网传输协议标准。

概念

MQTT是机器对机器(M2M)/物联网(IoT)连接协议。它被设计为一个极其轻量级的发布/订阅消息传输协议。对于需要较小代码占用空间和/或网络带宽非常宝贵的远程连接非常有用，是专为受限设备和低带宽、高延迟或不可靠的网络而设计。这些原则也使该协议成为新兴的“机器到机器”(M2M)或物联网(IoT)世界的连接设备，以及带宽和电池功率非常高的移动应用的理想选择。例如，它已被用于通过卫星链路与代理通信的传感器、与医疗服务提供者的拨号连接，以及一系列家庭自动化和小型设备场景。它也是移动应用的理想选择，因为它体积小，功耗低，数据包最小，并且可以有效地将信息分配给一个或多个接收器。

为什么不选择其他众多网络协议 ？

大多数开发人员已经熟悉 HTTP Web 服务。那么为什么不让 IoT 设备连接到 Web 服务？设备可采用 HTTP 请求的形式发送其数据，并采用 HTTP 响应的形式从系统接收更新。这种请求和响应模式存在一些严重的局限性：

1. HTTP 是一种同步协议。客户端需要等待服务器响应。Web 浏览器具有这样的要求，但它的代价是牺牲了可伸缩性。在 IoT 领域，大量设备以及很可能不可靠或高延迟的网络使得同步通信成为问题。异步消息协议更适合 IoT 应用程序。 传感器发送读数，让网络确定将其传送到目标设备和服务的最佳路线和时间。

2. HTTP 是单向的。客户端必须发起连接。在 IoT 应用程序中，设备或传感器通常是客户端，这意味着它们无法被动地接收来自网络的命令。

HTTP 是一种 1-1 协议。客户端发出请求，服务器进行响应。将消息传送到网络上的所有设备上，不但很困难，而且成本很高，而这是 IoT 应用程序中的一种常见使用情况。

3. HTTP 是一种有许多标头和规则的重量级协议。它不适合受限的网络。

出于上述原因，大部分高性能、可扩展的系统都使用异步消息总线来进行内部数据交换，而不使用 Web 服务。事实上，企业中间件系统中使用的最流行的消息协议被称为 AMQP（高级消息排队协议）。但是，在高性能环境中，计算能力和网络延迟通常不是问题。AMQP 致力于在企业应用程序中实现可靠性和互操作性。它拥有庞大的特性集，但不适合资源受限的 IoT 应用程序。

除了 AMQP 之外，还有其他流行的消息协议。例如，XMPP（Extensible Messaging and Presence Protocol，可扩展消息和状态协议）是一种对等即时消息 （IM） 协议。它高度依赖于支持 IM 用例的特性，比如存在状态和介质连接。与 MQTT 相比，它在设备和网络上需要的资源都要多得多。

那么，MQTT 为什么如此轻量且灵活？因为MQTT 协议的一个关键特性是发布和订阅模型。与所有消息协议一样，它将数据的发布者与使用者分离。

我们先来看看一个典型的MQTT网络拓扑结构长什么样子，再来介绍有关概念。

角色

实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。应用消息通过MQTT传输时，它们有关联的服务质量（QoS）和主题（Topic）。

完整流程

• 1） 启动服务器代理。
• 2） 订阅者向服务器代理订阅相关主题。
• 3） 发布者向服务器代理发布主题信息。
• 4） 服务器代理想所有订阅该主题的订阅者推送消息。

客户端 Client
使用MQTT的程序或设备。客户端总是通过网络连接到服务端。它可以

• 1） 发布应用消息给其它相关的客户端。
• 2） 订阅以请求接受相关的应用消息
• 3） 取消订阅以移除接受应用消息的请求。
• 4） 从服务端断开连接。

服务端 Server
一个程序或设备，作为发送消息的客户端和请求订阅的客户端之间的中介。服务端

• 1） 接受来自客户端的网络连接
• 2） 接受客户端发布的应用消息
• 3） 处理客户端的订阅和取消订阅请求。
• 4） 转发应用消息给符合条件的客户端订阅。

有关术语

订阅 Subscription
订阅包含一个主题过滤器（Topic Filter）和一个最大的服务质量（QoS）等级。订阅与单个会话（Session）关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。

主题名 Topic Name
附加在应用消息上的一个标签，服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户端订阅。
主题名称（Topic name）用来标识已发布消息的信息的渠道。订阅者用它来确定接收到所关心的信息。它是一个分层的结构，用斜线“/”作为分隔符（这个有点类似于restful风格）。

主题过滤器 Topic Filter
订阅中包含的一个表达式，用于表示相关的一个或多个主题。主题过滤器可以使用通配符。

主题还可以通过通配符进行过滤。其中，+可以过滤一个层级，而#只能出现在主题最后表示过滤任意级别的层级。
值得注意的是MQTT允许使用通配符订阅主题，但是并不允许使用通配符广播。

举个例子：

building-b/floor-5：代表B楼5层的设备。

+/floor-5：代表任何一个楼的5层的设备。

building-b/#：代表B楼所有的设备。

会话 Session
客户端和服务端之间的状态交互。一些会话持续时长与网络连接一样，另一些可以在客户端和服务端的多个连续网络连接间扩展。

控制报文 MQTT Control Packet
通过网络连接发送的信息数据包。MQTT规范定义了十四种不同类型的控制报文，其中一个（PUBLISH报文）用于传输应用消息。

MQTT传输的消息分为：主题（Topic）和负载（payload）两部分：

• （1）Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）；
• （2）payload，可以理解为消息的内容，是指订阅者具体要使用的内容。

网络结构

设计规范

由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

• （1）精简，不添加可有可无的功能；
• （2）发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递，一对多消息发布；
• （3）允许用户动态创建主题，零运维成本；
• （4）把传输量降到最低以提高传输效率；
• （5）把低带宽、高延迟、不稳定的网络等因素考虑在内；
• （6）支持连续的会话控制；
• （7）理解客户端计算能力可能很低；
• （8）提供服务质量管理；
• （9）假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

特点

• 开放消息协议，简单易实现
• 发布订阅模式，一对多消息发布
• 基于TCP/IP网络连接,提供有序，无损，双向连接。
• 1字节固定报头，2字节心跳报文，最小化传输开销和协议交换，有效减少网络流量。
• 消息QoS支持，可靠传输保证

应用

MQTT协议广泛应用于物联网、移动互联网、智能硬件、车联网、电力能源等领域。

• 物联网M2M通信，物联网大数据采集
• Android消息推送，WEB消息推送
• 移动即时消息，例如Facebook Messenger
• 智能硬件、智能家具、智能电器
• 车联网通信，电动车站桩采集
• 智慧城市、远程医疗、远程教育
• 电力、石油与能源等行业市场

MQTT协议中的订阅、主题、会话

一、订阅（Subscription）

订阅包含主题筛选器（Topic Filter）和最大服务质量（QoS）。订阅会与一个会话（Session）关联。一个会话可以包含多个订阅。每一个会话中的每个订阅都有一个不同的主题筛选器。

二、会话（Session）

每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间有状态交互。会话存在于一个网络之间，也可能在客户端和服务器之间跨越多个连续的网络连接。

三、主题名（Topic Name）

连接到一个应用程序消息的标签，该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。

四、主题筛选器（Topic Filter）

一个对主题名通配符筛选器，在订阅表达式中使用，表示订阅所匹配到的多个主题。

五、负载（Payload）

消息订阅者所具体接收的内容。

MQTT-SN协议简要介绍

这一章是在下载 MQTT代码源码中发现，并查阅资料后进行补充的。

MQTT-SN（Sensor Networks）是MQTT协议的传感器版本，基于TCP协议的MQTT对有些传感器来说还是负载太重了，这些传感器可能只有几十个字节的内存，无法运行TCP协议。MQTT-SN对MQTT对内存受限的微处理器做了适当的优化，使之能够跑在这种处理器上。

也就是说，MQTT与MQTT-SN 之间需要转换才能够互通。转换的操作由MQTT-SN的网关完成。

MQTT-SN名称由来

原名是MQTT-S，但会引起人们的误解，因此更名成MQTT-SN：

As part of the job of applying the same or similar license terms to the MQTT-S specification as those on the MQTT specification, we are proposing a small name change. The new name would be MQTT-SN, standing for exactly the same long name, MQTT for Sensor Networks. Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion. – Ian Craggs

MQTT-SN存在目的

MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP networks, such as Zigbee. MQTT-SN is a publish/subscribe messaging protocol for wireless sensor networks (WSN), with the aim of extending the MQTT protocol beyond the reach of TCP/IP infrastructure for Sensor and Actuator solutions.

针对适配传感装置（缩写为SA）的特定版MQTT协议，一般运行在嵌入式电池驱动的电子元件中，传输通过基于IEEE 802.15.4规范无线低速网络构成的无线传感网络（WSN），同样具有企业级别特性具有以数据为核心的（data-centric）订阅/发布特性。

总之，针对低功耗、电池驱动、处理存储受限的设备、不支持TCP/IP协议栈网络的电子器件而定制，比如常见的ZigBee（或XBee），对所依赖的底层传输网络不可知，但只要网络支持双向数据传输和网关，都是可以支持较为上层的MQTT-SN协议传输。比如简单数据报服务，只要支持一个源端点发送数据到一个特定目的地端点，这对支持MQTT-SN协议，就足够了。广播数据报传输服务也是必须的用于网关和终端的自动发现流程。为了降低广播风暴，MQTT-SN定义了广播路径深度（广播范围或广播半径）。

一些名词和术语

• topic id，主题标识符，两个字节16位表示的自然数（java语言short类型，0-65535范围），对应于主题topic name
• 网关/服务器（gateway/server），在MQTT-SN中统一称之为网关，主要处理和MQTT-SN客户端的交互，缩写为网关
• MQTT-SN终端和客户端（client），统一称之为客户端，其实也是嵌入式传感设备，或电子元件，资源受限，在无线区域个人网中运行
• IEEE 802.15.4，完整栈的整个数据上限为128个字节，一般选择UDP（相比20个字节的TCP协议，UDP报文头部仅仅需要8个字节）协议传输数据
• 低速网络/当前网络，指的是LR-WPAN（low-rate wireless personal area network,），低速无线个人区域网络

MQTT-SN VS MQTT

尽管MQTT-SN被设计成尽可能接近于MQTT，但那些低功耗、电池驱动、资源受限的设备所在网络场景为低速带宽、高连接失败、物理层数据包上线为128字节。文档提出了以下不同点：

1. CONNECT消息被拆分成三个消息（CONNECT，WILLTIPIC，WILLMSG），后两者用于客户端传递遗嘱主题和遗嘱消息等
2. 在PUBLISH消息中主题（topic name）被替换成两个字节长度自然数（topic id），这个需要客户端通过注册流程进行获取对应的topic id
3. 预定义（提前定义）topic id和topic name，省去中间注册流程，客户端和网关要求提前在其固件中指定
4. 协议引入的自动发现机制可帮助客户端发现潜在的网关。若存在多个网关，彼此可协调是为主从互备或者负载均衡
5. “clean session”即可作用于订阅持久化，也被扩展作用于遗嘱特性（遗嘱主题和遗嘱消息）
6. 针对休眠设备增加离线保活机制支持，当有消息时代理需要缓存，客户端被唤醒时再发送

MQTT-SN架构示意

在MQTT-SN架构图中，存在三种组件：

1. MQTT-SN 客户端
2. MQTT-SN 网关，可单独存在，也可以被集成到MQTT服务器中。需要承担MQTT-SN和MQTT协议之间的转换工作
3. MQTT-SN 转发器，负责转发当前客户端数据到不可直接访问的网关上去，针对客户端而言网关不可直接访问时，转发器作用就凸显。转发器封装MQTT-SN消息转发给网关，解封来自网关的消息发送给客户端。网关不能够篡改原始数据。

MQTT-SN传输网关

MQTT-SN网关传输方式，下面的图片一目了然。

1. 透明网关，会为每一个客户端都建立一个TCP连接到MQTT服务器的通道，这样会较为耗费网关网络资源，但模型简单
2. 聚合网关，只建立一条TCP连接通道到MQTT服务器上，所有的客户端共享一个通道，很经济的说。

网关需要抉择哪些消息需要和远程的MQTT Server进行交互，比如只选择客户端发送的PUBLISH、SUBSCRIBLE消息等。