地址：山西省太原市综改示范区唐槐路96号
电话：0351-2872595 18636654267
邮件：flh7098520@hnphk.com
网站：www.hnphk.com
上个月有个读者问我物联网 MQTT 协议实战相关的问题，我说后边会搞，没想到不知不觉一个月了，太忙了，再怎样忙容许的工作仍是要给读者一个告知，所以就有了此文。
MQTT（Message Queuing Telemetry Transport，音讯行列遥测传输协议），是一种依据发布/订阅（publish/subscribe）方式的“轻量级”通讯协议，该协议构建于 TCP/IP 协议上，由 IBM 于 1999 年创造。MQTT 协议的主要特征是敞开、简略、轻量级和易于完成，这些特征使得它适用于受约束的运用环境，如：
经过 MQTT 协议，现在现已扩展出了数十种 MQTT 服务器端程序，能够经过 PHP、Java、Python、C、C# 等言语向 MQTT 发送音讯。由于敞开源代码、耗电量小等特色，MQTT 十分适用于物联网范畴，如传感器与服务器的通讯、传感器信息收集等。
发布/订阅方式并不是 MQTT 协议特有的方式，像咱们许多音讯中间件都有运用发布/订阅方式，这儿你是不是想说，这不便是咱们所说的观察者方式嘛，还真不是，这两个方式很简略混杂。观察者方式只要 观察者 + 被观察者两个人物，而发布/订阅方式还有一个经纪人 Broker；往更深层次的讲观察者和被观察者，是松耦合的联系，而发布者和订阅者，则彻底不存在耦合。
在客户端/服务器模型中，客户端直接与服务器端点通讯。而发布/订阅方式 pub/sub 就不相同了，发布/订阅方式会将发送音讯的发布者 publisher 与接纳音讯的订阅者 subscribers 进行别离，publisher 与 subscribers 并不会直接通讯，他们甚至都不清楚对方是否存在，他们之间的沟通由第三方组件 broker 署理。
pub/sub 最重要的方面是音讯的发布者与接纳者（订阅者）的解耦。这种解耦有几个维度：
总归，发布/订阅方式消除了传统客户端/服务器之间的直接通讯，把通讯这个操作交给了 broker 进行署理，并在空间、时刻、同步三个维度进步行了解藕。
pub/sub 比传统的客户端/服务器方式有了更好的拓宽，这是由于 broker 的高度并行化，而且是依据事情驱动的方式。可扩展性还体现在音讯的缓存和音讯的智能路由，还能够经过集群署理来完成数百万的衔接，运用负载均衡器将负载分配到更多的单个服务器上，这便是 MQTT 的深度运用了。
很明显，broker 在 pub/sub 过程中起着无足轻重的效果。可是署理怎么过滤一切音讯，以便每个订阅者只接纳感兴趣的音讯？broker 有几个能够过滤的选项：
此过滤依据归于每条音讯的主题。接纳客户端向署理订阅感兴趣的主题，订阅后，broker 就会确保客户端收到发布到 topic 中的音讯。
在依据内容的过滤中，broker 会依据特定的内容过滤音讯，承受客户端会经过过滤他们感兴趣的内容。这种办法的一个明显的缺陷便是有必要事前知道音讯的内容，不能加密或许容易修正。
当运用面向对象的言语时，依据音讯（事情）的类型/类进行过滤是一种常见做法。例如，订阅者能够收听一切类型为 Exception 或任何子类型的音讯。
这儿你又会说了，已然 MQTT 与干流的音讯的行列都选用发布/订阅方式，那他们便是相同的。这儿老周得再提一嘴，的确和音讯行列许多类似的当地，但还有有些差异的，下面就来说道说道：
音讯行列存储音讯直到音讯被消费 运用音讯行列时，每条传入音讯都存储在行列中，直到被客户端（一般称为顾客）接纳。假如没有客户端接纳到音讯，音讯将坚持在行列中并等候被消费。在音讯行列中，不会存在音讯没有客户端消费的状况，可是在 MQTT 中，却存在 topic 无 subscriber 订阅的状况。
一条音讯只被一个客户端消费 另一个很大的区别是，在传统的音讯行列中，一条音讯只能被一个顾客处理。负载散布在行列的一切顾客之间。在 MQTT 中，行为彻底相反：订阅主题的每个订阅者都会收到音讯，每个订阅者有相同的负载。
行列是命名的，有必要显式创立 行列比主题严厉得多。在运用行列之前，有必要运用独自的指令显式创立行列。只要在行列命名和创立之后，才能够发布或消费音讯。比较之下，MQTT 主题十分灵敏，能够即时创立。
publisher 和 subscriber 都归于 MQTT Client，之所以有发布者和订阅者这个概念，其实是一种相对的概念，便是指当时客户端是在发布音讯仍是在接纳音讯，发布和订阅的功用也能够由同一个 MQTT Client 完成。
MQTT 客户端是运转 MQTT 库并经过网络衔接到 MQTT 署理的任何设备（从微控制器到老练的服务器）。例如，MQTT 客户端能够是一个十分小的、资源受限的设备，它经过无线网络进行衔接并具有一个最低极限的库。基本上，任何运用 TCP/IP 协议运用 MQTT 设备的都能够称之为 MQTT Client。MQTT 协议的客户端完成十分简略直接，易于施行是 MQTT 十分合适小型设备的原因之一。MQTT 客户端库可用于多种编程言语。例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和
Broker 担任接纳一切音讯，过滤音讯，承认是哪个Client 订阅了每条音讯，并将音讯发送给对应的 Client，Broker 还担任保存会话数据，这些数据包括订阅的和错失的音讯。Broker 还担任客户端的身份验证和授权。
MQTT 协议依据 TCP/IP。客户端和署理都需求有一个 TCP/IP 协议支撑。
MQTT 衔接一直坐落一个客户端和署理之间。客户端从不直接相互衔接。要主张衔接，客户端向署理发送 CONNECT 音讯。署理运用 CONNACK 音讯和状况代码进行呼应。树立衔接后，署理将坚持翻开状况，直到客户端发送断开衔接指令或衔接中止。
为了创立衔接，客户端向署理发送指令音讯。假如此 CONNECT 音讯格局过错（依据 MQTT 标准）或翻开网络套接字和发送衔接音讯之间的时刻过长，署理将封闭衔接。
一个 MQTT 客户端发送一条 CONNECT 衔接，这条 CONNECT 衔接可能会包括下面这些信息：
ClientId：ClientId 的长度能够是 1-23 个字符，在一个服务器上 ClientId 不能重复。假如超越 23 个字符，则服务器回来 CONNACK 音讯中的回来码为 Identifier Rejected。在 MQTT 3.1.1 中，假如您不需求署理持有状况，您能够发送一个空的 ClientId。空的 ClientId 导致衔接没有任何状况。在这种状况下，clean session 标志有必要设置为 true，不然署理将回绝衔接。
Clean Session：Clean Session 标志告知署理客户端是否要树立耐久会话。在耐久会话 (CleanSession = false) 中，署理存储客户端的一切订阅以及以服务质量（QoS）等级 1 或 2 订阅的客户端的一切丢掉音讯。 假如会话不是耐久的 (CleanSession = true )，署理不为客户端存储任何内容，并铲除任何从前耐久会话中的一切信息。
Username/Password：MQTT 能够发送用户名和暗码进行客户端认证和授权。可是，假如此信息未加密或散列，则暗码将以纯文本方式发送。咱们强烈主张将用户名和暗码与安全传输一同运用。像 HiveMQ 这样的署理能够运用 SSL 证书对客户端进行身份验证，因而不需求用户名和暗码。
Will Message：LastWillxxx 标明的是遗愿，client 在衔接 broker 的时分将会建立一个遗愿，这个遗愿会保存在 broker 中，当 client 由于非正常原因断开与 broker 的衔接时，broker 会将遗愿发送给订阅了这个 topic（订阅遗愿的 topic）的 client。
KeepAlive：keepAlive 是 client 在衔接树立时与 broker 通讯的时刻距离，一般以秒为单位。这个时刻指的是 client 与 broker 在不发送音讯下所能承受的最大时长。
CONNACK 音讯中的第二个标志是衔接承认标志。这个标志包括一个回来码，告知客户端衔接测验是否成功。衔接承认标志有下面这些选项：
MQTT 客户端能够在衔接到 broker 后当即发布音讯，MQTT 运用的是依据 topic 主题的过滤。每条音讯都有必要包括一个主题，broker 能够运用该主题将音讯转发给感兴趣的客户端。一般，每条音讯都有一个负载（Payload），其间包括要以字节格局传输的数据。MQTT 是数据无关性的，也便是说数据是由发布者 - publisher 决议要发送的是 XML 、JSON 仍是二进制数据、文本数据。
Topic Name：主题名称是一个简略的字符串，它以正斜杠作为分隔符进行分层结构。例如，“我的家/客厅/温度”或“德国/慕尼黑/十月节/人”。
QoS：此数字标明音讯的服务质量 (QoS)。有三个等级：0、1 和 2。服务等级决议了音讯抵达预期接纳者（客户端或署理）的确保类型。
Retain Flag：此标志标明 broker 将最近收到的一条 RETAIN 标志位为 true 的音讯保存在服务器端（内存或许文件）。
Payload：这个是每条音讯的实践内容。MQTT 是数据无关性的。能够发送任何文本、图画、加密数据以及二进制数据。
Packet Identifier：这个 packetId 标识在 client 和 broker 之间仅有的音讯标识。packetId 仅与大于零的 QoS 等级相关。
DUP flag： 该标志标明该音讯是重复的而且由于预期的接纳者（客户端或署理）没有承认原始音讯而被从头发送。这仅与 QoS 大于 0 相关。
当客户端向 MQTT broker 发送音讯进行发布时，broker 读取音讯、承认音讯（依据 QoS 等级）并处理音讯。broker 的处理包括承认哪些客户端订阅了主题并将音讯发送给他们。
开始发布音讯的客户端只关怀将 PUBLISH 音讯传递给 broker。一旦 broker 收到 PUBLISH 音讯，broker 就有职责将音讯传递给一切订阅者。发布客户端不会得到关于是否有人对发布的音讯感兴趣或有多少客户端从 broker 收到音讯的任何反应。
client 会向 broker 发送 SUBSCRIBE 音讯来接纳有关感兴趣的 topic，这个 SUBSCRIBE 音讯十分简略，它包括了一个仅有的数据包标识和一个订阅列表。
Packet Identifier：这个 PacketId 和上面的 PacketId 相同，都标明音讯的仅有标识符。
List of Subscriptions：一个 SUBSCRIBE 音讯能够包括一个客户端的多个订阅。每个订阅由一个主题和一个 QoS 等级组成。订阅音讯中的主题能够包括通配符，使订阅主题方式而不是特定主题成为可能。假如一个客户端存在堆叠订阅，则署理会传送该主题具有最高 QoS 等级的音讯。
为了承认每个订阅，broker 向客户端发送一个 SUBACK 承认音讯。该音讯包括原始 Subscribe 音讯的数据包标识符（以清晰标识该音讯）和回来码列表。
Packet Identifier：包标识符是用于标识音讯的仅有标识符。它与 SUBSCRIBE 音讯中的相同。
Return Code：broker 为它在 SUBSCRIBE 音讯中收到的每个主题/QoS 对发送一个回来代码。例如，假如 SUBSCRIBE 音讯有五个订阅，则 SUBACK 音讯包括五个回来码。回来码承认每个主题并显现 broker 颁发的 QoS 等级。假如 broker 回绝订阅，则 SUBACK 音讯包括该特定主题的失利回来代码。例如，假如客户端没有满足的权限订阅主题或主题格局过错。
客户端成功发送 SUBSCRIBE 音讯并收到 SUBACK 音讯后，它会获取与 SUBSCRIBE 音讯包括的订阅中的主题匹配的每条已发布音讯。
为了承认撤销订阅，broker 向客户端发送一个 UNSUBACK 承认音讯。此音讯仅包括原始 UNSUBSCRIBE 音讯的数据包标识符（以清晰标识该音讯）。
前面咱们说了许多 MQTT 协议的格局以及音讯列表，这一节咱们来说下 Topics 主题。主题在 MQTT 中很重要，由于咱们写代码的时分往往都是需求先承认好 MQTT 的 Topics。
在 MQTT 中，主题一词是指 broker 用于为每个衔接的客户端过滤音讯的 UTF-8 字符串。主题由一个或多个主题等级组成。每个主题等级由正斜杠（主题等级分隔符）分隔。
与音讯行列比较，MQTT 主题十分轻量级。客户端在发布或订阅它之前不需求创立所需的主题。broker 承受每个有用主题而无需任何事前初始化。
当客户端订阅主题时，它能够订阅已发布音讯的切当主题，也能够运用通配符一起订阅多个主题。通配符只能用于订阅主题，不能用于发布音讯。有两种不同类型的通配符：单级和多级。
假如主题包括恣意字符串而不是通配符，则任何主题都与具有单级通配符的主题匹配。例如，订阅myhome/groundfloor/+/temperature能够发生以下成果：
当客户端订阅带有多级通配符的主题时，不管主题多长或多深，它都会收到以通配符之前的方式最初的主题的一切音讯。假如您仅将多级通配符指定为主题 ( # )，您将收到发送到 MQTT 署理的一切音讯。假如您希望高吞吐量，独自运用多级通配符订阅是一种反方式（请参阅下面的最佳实践）。
一般，您能够依据需求命名 MQTT 主题。可是，有一个破例：以 最初的主题∗∗一般，您能够依据需求命名MQTT主题。可是，有一个破例：以 符号最初的主题具有不同的意图。当您将多级通配符作为主题 (#) 订阅时，这些主题不是订阅的一部分。$-symbol 主题保存用于 MQTT 署理的内部计算信息。客户端无法向这些主题发布音讯。现在，此类主题尚无官方标准化。一般，$SYS/用于一切以下信息，但署理完成各不相同。MQTT GitHub wiki 中供给了对 $SYS-topics 的一项主张 。这儿有些比如：
能够呀，看到了最后边。授人以鱼不如授人以渔，下面是一个关于 MQTT Version 3.1.1 的介绍，有些协议格局具体的能够前往检查。
本文分根底特性篇与实战篇来讲，下一篇老周会带你建立一个 MQTT 服务器，让其他厂商的设备接入进来，纵情等待~
