初始 MQTT
物联网 (internet of thing) ，表示的是可以把一些带某些传感器的设备(终端)，接入到互联网的行为。
通过互联网连接这些设备，这些设备就能够互相协作。
而MQTT就是这些设备之间数据通信的一个基于 TCP/IP 的协议。
每个终端都和实现了 MQTT 协议的代理/服务器相连。
通过 published MQTT 代理服务器的某个主题 发送数据。
通过 subscription 从 MQTT 代理服务器获取自己订阅的 主题 数据。
代理服务器本身不产生数据，数据全是由链接到这个代理服务器的终端产生。
终端往服务器发送数据，在服务器订阅了主题的终端，接受另外一个终端发送到服务器，并通过服务器转发到自己。
为何选择 MQTT 协议？
MQTT 协议是一种轻量级的、灵活的网络协议。并且非常适合 IOT 的场景。
- 首先 IOT 协议的定义非常小巧，不会像 HTTP、HTTPS 那么重量级。
- 一般支持 IOT 的设备的网络传输环境和自身的计算能力都比价薄弱。正好合适MQTT 对网络和数据要求不高的轻量级协议。
为什么不选择其他的网络协议？
大多数开发人员已经熟悉了 HTTP WEB 协议。那么为什么不让 IOT 设置链接到 WEB 服务？
设备可以采用 HTTP 请求的形式发送数据，并采用 HTTP 响应的形式从服务器获取数据，接受更新。
因为对于 IOT 的设备来说，这种主动请求--> 被动等待应答的 数据传输模型存在严重的局限性：
HTTP 是一种同步协议。客户端需要等待服务器的响应。Web 浏览器具有这样的要求，但它的代价是牺牲了可伸缩性。 在 IoT 领域，大量的设备以及很可能不可靠或者高延迟的网络使得同步通信成为问题。异步消息协议更适合 IoT 应用程序。传感器只负责发送数据，让网络确定将其传送到目标设备和服务器的最佳路线和时间。
HTTP 是单向的。客户端必须主动的发起请求。在 IoT 应用程序中，设备或传感器通常是客户端，就意味着，除非用户或应用程序主动请求，否则无法接受来自服务器的数据。
HTTP 是一个 1-1 的协议。客户端发出请求，服务器进行相应。它们是一对一的对应关系。但是需要把 HTTP 这种 1-1的关系，改进程 IOT 中很常见的 1 对多的关系，实现起来很困难，而且成本也很高。而 1 对多在 IoT 中很常见。
HTTP 相对于 MQTT 来说，是一个比较重的协议，它不适合IOT 终端设备受限的网络和较差的计算能力。
那么，MQTT 为什么如此轻便且灵活？MQTT 协议的一个关键的特性是 发布/订阅模型。它将数据的发布者和接受者分离。
一个设备终端既可以是数据的发布者(published) 也可以是数据的订阅者(subscription)。
一个设备如果要发布数据，只需要往代理服务器中相应的主题发布数据内容即可。
一个设备如果需要接受到数据，只需要在代理服务器中，提前订阅自己需要关注的主题即可。
MQTT 的基本体验
MQTT 最基本的体验，就是使用 mosquitto。
Mosquitto是一款实现了 MQTT v3.1 协议的开源消息代理软件，提供轻量级的，支持发布/订阅的的消息推送模式，使设备对设备之间的短消息通信简单易用。
它可以理解成一个 MQTT 的代理服务器。
基本步骤如下：
- 首先使用
brew install
brew install mosquitto
安装成功截图
使用 brew services start mosquitto 启动 MQTT 服务
运行截图
然后再打开另外两个终端窗口，模拟两个IOT设备。A 订阅 MQTT 服务。B 向 MQTT 的服务发送数据。
A订阅当前MQTT的某个服务。
mosquitto_sub -t "dw/demo"
B向 MQTT 服务器发布(published) 数据。
mosquitto_pub -t "dw/demo" -m "hello MQTT"
然后，我们就可以在A控制台里看到由 B 通过 MQTT 服务发送的数据了。
基本流程图
控制台 A 向 MQTT 服务器订阅 dw/demo 服务，并被动的等待 MQTT 服务器返回数据。
控制台 B 主动的向 MQTT 服务器的 dw/demo 服务发送 published 数据，之后。服务器会主动向事先订阅了 dw/demo 的终端分发此消息。
了解 MQTT 协议
MQTT 是一种链接协议，它指定了如何组织数据字节并通过 TCP/IP 网络传输它们。但实际上，开发人员并不需要链接这个链接协议的具体细节。我们只需要知道，每条消息都有一个命令和数据有效负载。该命令定义消息类型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 库和工具都提供了直接处理这些消息的基本方法，并且能自动填充一些必要的字段(在数据包的对应字节填充)，比如消息和客户端 ID。
首先客户端发送一条CONNECT消息来链接代理。CONNECT 消息要求建立从客户端到代理服务器的链接。
CONNECT 命令的基本参数
-
cleanSession: 此标志指定是否是持久链接。持久会话会将所有的订阅和可能丢失的消息(具体取决于 QoS)都存储在代理(服务器)中。 -
username: 链接代理服务器的用户名。(对，代理服务器不是谁想连，想连就能连) -
password: 链接代理服务器的密码。(对，代理服务器不是谁想连，想连就能连) -
lasWillTopic: 链接意外中断，代理服务器会像某个主题发送一条last will消息。 -
lastWillQos:last will消息的 QoS。 -
lastWillMessage:last will消息本身。 -
KeepAlive: 这是客户端通过 ping 服务器来保持链接有效所需的时间间隔。
当客户端向代理服务器发送一条 CONNECT 命令之后，服务器会调用 CONNACK命令，告知服务链接的状态。
CONNACK 命令的基本参数
-
sessionPresent: 此参数表明链接是否已有一个持久会话。也就是说，连接了订阅的主题，而且会接受丢失的消息？？？ -
returnCode: 0 表示成功。otherwise 失败。
当客户端和服务器建立连接之后，客户端就可以向服务器订阅某些主题的。(发送一条或多条 SUBSCRIBE消息)。
表明当服务器接受到其他终端推送的此主题数据时，服务器会默认发送给它。
SUBSCRIBE 参数列表
-
QoS: 服务质量 (quality of services)。一般有3个枚举值。- 0 ： 表示不可靠服务，消息仅推送一次，如果当前客户端在线，或者因为网络原因，没有收到就没有收到。
- 1 ： 消息至少传递 1 次。一次不成功，传递第二次，第 N 次。可能会出现重复数据的情况。
- 2 ： 消息恰好传递 1 次。双方通过 4 次握手，保证消息能准确的从服务器传递给客户端，而且只传一次。
d
QoS 参数虽然在客户端指定，但规定的是服务器传递数据的模式。所以，QOS 是用来约束服务器，而不是客户端本身。
-
topic: 客户端要订阅的主题。
一个主题可以有多个级别，级别之间用斜杠字符分隔。例如 ,
"dw/demo"和"/ibm/bluemix/qmqt"都是有效主题。
当客户端成功的向服务器订阅某个主题之后，服务器会返回一条 SUBACK 的消息，其中包含一个或者多个 returnCode 参数。
SUBACK消息参数
returnCode : 值 0 - 2 ，表示成功订阅，并返回这个订阅消息的 QOS。值 128 ： 订阅失败。
既然客户端可以向服务器订阅某个主题，当然也可以取消订阅。
与SUBSCRIBE订阅命令相反的命令是UNSUBSCRIBE取消订阅命令。
此命令非常简单。只有一个topic(主题)参数。
-
topic: 此参数就是客户端取消订阅的主题。
上面讲的是订阅，订阅是需要有消息从服务器发送过来的。但是服务器本身基本不产生数据，那数据从何而来呢？
通过另外一个客户端执行PUBLISH命令，往代理服务器发送数据。并最终通过代理服务器将数据传递给订阅了此服务的客户端。
PUBLISH 消息参数
-
topicName: 发布消息的相关主题。 -
qos: 消息传递的质量水平。（约束服务器) -
retainFlag: 此标志表明服务器是否保留该消息作为针对此主题的最后一条已知消息。 -
payload: 消息中的实际数据。它可以是文本字符串或者二进制大对象数据（图片)
对于 MQTT 的一张基本理解图
基本流程图：
最后总结
- MQTT 是一个轻量级，用于计算能力弱，网络环境差的终端设备之间的数据传输。
- MQQ 是基于一个 发布/订阅 的基本模式。
- 每个终端都可以从服务器订阅某些主题，也可以往代理服务器发布某些主题。
- 当服务器接受到了某些终端发送过来的数据之后，会向订阅了这个服务的终端推送这些数据。
参考资料：初识 MQTT