背景
从本章开始，在没有特殊说明的情况下，文章中的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 响应的形式从系统接收更新。这种请求和响应模式存在一些严重的局限性：
HTTP 是一种同步协议。客户端需要等待服务器响应。Web 浏览器具有这样的要求，但它的代价是牺牲了可伸缩性。在 IoT 领域，大量设备以及很可能不可靠或高延迟的网络使得同步通信成为问题。异步消息协议更适合 IoT 应用程序。 传感器发送读数，让网络确定将其传送到目标设备和服务的最佳路线和时间。
HTTP 是单向的。客户端必须发起连接。在 IoT 应用程序中，设备或传感器通常是客户端，这意味着它们无法被动地接收来自网络的命令。
HTTP 是一种 1-1 协议。客户端发出请求，服务器进行响应。将消息传送到网络上的所有设备上，不但很困难，而且成本很高，而这是 IoT 应用程序中的一种常见使用情况。
- 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字节。文档提出了以下不同点：
- CONNECT消息被拆分成三个消息（CONNECT，WILLTIPIC，WILLMSG），后两者用于客户端传递遗嘱主题和遗嘱消息等
- 在PUBLISH消息中主题（topic name）被替换成两个字节长度自然数（topic id），这个需要客户端通过注册流程进行获取对应的topic id
- 预定义（提前定义）topic id和topic name，省去中间注册流程，客户端和网关要求提前在其固件中指定
- 协议引入的自动发现机制可帮助客户端发现潜在的网关。若存在多个网关，彼此可协调是为主从互备或者负载均衡
- “clean session”即可作用于订阅持久化，也被扩展作用于遗嘱特性（遗嘱主题和遗嘱消息）
- 针对休眠设备增加离线保活机制支持，当有消息时代理需要缓存，客户端被唤醒时再发送
MQTT-SN架构示意
在MQTT-SN架构图中，存在三种组件：
- MQTT-SN 客户端
- MQTT-SN 网关，可单独存在，也可以被集成到MQTT服务器中。需要承担MQTT-SN和MQTT协议之间的转换工作
- MQTT-SN 转发器，负责转发当前客户端数据到不可直接访问的网关上去，针对客户端而言网关不可直接访问时，转发器作用就凸显。转发器封装MQTT-SN消息转发给网关，解封来自网关的消息发送给客户端。网关不能够篡改原始数据。
MQTT-SN传输网关
MQTT-SN网关传输方式，下面的图片一目了然。 
- 透明网关，会为每一个客户端都建立一个TCP连接到MQTT服务器的通道，这样会较为耗费网关网络资源，但模型简单
- 聚合网关，只建立一条TCP连接通道到MQTT服务器上，所有的客户端共享一个通道，很经济的说。
网关需要抉择哪些消息需要和远程的MQTT Server进行交互，比如只选择客户端发送的PUBLISH、SUBSCRIBLE消息等。