物联网及MQTT协议概述
一、概述
1. 什么是IoT
IoT全称The Internet of Things，直译过来就是：物体的Internet网络，也就是物联网。
关于物联网的百度百科定义如下：
物联网是指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、 连接、互动的物体或过程，采集其声、光、热、电、力学、化 学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。
物联网是一个基于互联网、传统电信网等的信息承载体，它让所有能够被独立寻址的普通物理对象形成互联互通的网络。
2. 物联网发展的问题与瓶颈：
①、技术标准的统一与协调
目前，传统互联网的标准并不适合物联网。物联网感知层的数据多源异构，不同的设备有不同的接口，不同的技术标准；网络层、应用层也由于使用的网络类型不同、行业的应用方向不同而存在不同的网络协议和体系结构。建立的统一的物联网体系架构，统一的技术标准是物联网现在正在面对的难题
②、碎片化
由于终端设备的多样化，物联网的开发和应用存在较严重的碎片化问题，主要体现在以下几个方面：
（1）电气接口的碎片化
传统电气接口分为模拟信号、数字信号的传输模式，数字信号又有无数种通讯协议，所以电器接口访问问题给处理器编程带来了繁重任务，集成化的通讯模块的电气接口也同样存在问题；
（2）终端传感器的访问协议碎片化
每个传感器的配置、访问方式和通讯协议均不同，也需要进行重复的编程和配置；
（3）终端通讯接入方式碎片化
物联网终端可能是有线网络接入或者总线接入，也可能无线网络接入，而无线网络接入协议众多，如近距离的蓝牙、超宽带，中距离的zigbee WIFI，还有传统广域的2G 4G接入。还有近年来兴起的Lora、NB-IoT等；
（4）处理器碎片化
处理器纷繁复杂，对应不同的处理器，需要进行不同的板级配置，没有统一标准的板级硬件；
（5）物联网平台的碎片化
由于物联网到终端的通讯协议没有统一，物联网平台传输协议各不相同，传入不同的云服务器需要进行重复的编程工作。
3、物联网分层结构
STM32硬件开发属于节点层的开发，属于物联网硬件开发；
开发物联网硬件的“物”的特性：
（1）低成本
（2）资源受限
（3）电池与能耗
（4）网络环境不稳定
（5）网络安全不稳定
（6）工作环境不稳定
（7）传递数据量小
如何实现上述“物”的特性：
（1）新型物联网通讯协议
（2）轻量级协议栈
（3）硬件低功耗设计
（4）一定的安全性
4、目前物联网三大通讯协议：
5、物联网安全
物联网被劫持的几种情况,这些情况就要求我们：
a、在云端方面应该做好设备的认证、授权，同时做好用户认证及用户权限管理；
b、在传输过程中应该建立好具有安全认证的数据通道，数据校验及服务器认证，如有必要，需加设**证书等验证方式
b、在硬件方面STM32读保护、MPU、防火墙等功能的应用
二、MQTT通讯协议
MQTT全称Message Queuing Telemetry Transport，直译过来是消息队列遥测传输的意思
百度百科对于MQTT协议的定义如下：
MQTT(消息队列遥测传输)是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议。它工作在 TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个消息中间件 。
1、发布/订阅的工作模式：
举例如下：温度传感器发布温度值到温度的主题，如果有终端订阅看温度这个主题，他就会收到代理转发的温度值
这种模式取消了硬件、客户端、服务器的概念，服务器成为了一个消息转发的代理，终端硬件和消息接收者都称之为客户端，他们都可以发布或订阅主题。如终端硬件可以发布“温度”主题下的消息，所有订阅了此主题的客户端都可以收到此消息推送，再如终端硬件订阅了“空中升级”的主题，如果有硬件驱动升级的推送，硬件就可以收到此消息，然后进行升级。
这种模式的优点：
A、空间上去耦合：信息发布者和信息接收者不需要建立直接联系，不需要知道对方的IP地址，端口等信息
B、时间上去耦合：发布者和接收者不需要同时在线。
这种模式的缺点：
A、发布者、接收者必须订阅相同的主题，
B、发布者并不确定接收者是否接受到了推送
2、客户端和服务器的角色和职责
3、主题
主题通配符：（订阅消息时使用）
单级通配符 +：+可以匹配单级，表示该级可以是任意主题不受限定；
多级通配符 #：#可以匹配多级，通常出现在主题末尾，表示某一类主题下的所有子主题
系统保留topic $：以$开头的是服务器保留的主题
4、消息质量级别QoS
（1）QS0 至多发一次。不管消息有没有收到，都不会重发。这是比较常用的质量级别，适用于很多不需要太严谨数据的场景
（2）QS1 至少发一次。带有标志位，确保消息肯定被接收到，但有可能接受到重复消息。
（3）QS2 只接受一次。具有严谨的信息确认，可以确保消息发送有且仅有一次 ，但对数据量的消耗较大，实现过程更复杂，适应于对数据有严格要求的场景。
三、MQTT数据格式
1、MQTT消息组成
一个MQTT消息由三个部分组成：固定头、可变头、负载。
（1）、固定头
固定头共2个字节,含义如下：
第一个字节的高4位定义了此消息的类型，
第一个字节的低4位根据消息的类型，含有不同的含义
第二个字节声明接下来的可变头及负载的数据长度
（2） 可变头
第二部分也根据不同的消息类型有不同的格式
（3）负载部分
根据消息类型和内容的不同变化。
2、建立连接过程
（1）客户端发送的CONNECT消息的内容：
A、ClientID：每个客户端的唯一ID，如果有重复则连接不成功
B、Username，password：由服务器分配的用户名和密码，
C、CleanSession（持久化会话）：客户端断线重连时，服务器需不需要将掉线期间的消息保留并重发
持久化会话举例：
正常状态下，客户端订阅了相同的主题，所以信息可以流畅的发送与接收
如果设备1掉线了，控制设备和云服务器之间仍旧会保持主题的发布，但掉线设备不会收到
虽然云服务器内由缓存的002消息，但不会发送给设备2。但设备2可接收到新消息3，同时新消息3也会为了掉线的设备1缓存下来。
D、WillTopic、WillQoS、WillMessage、WillRetain遗愿，连接时就在服务器处发布一条信息，服务器会存储此遗愿，但不会发送给订阅了该设备主题的订阅者，如果发布者自己掉线了，服务器会把发布者的遗愿推送给订阅者，订阅者可以借此得知发布者掉线了，并可以进行相应的处理。
E、KeepAlive 服务器与客户端保持长效连接，心跳连接，此心跳由客户端自己定义，当客户端没有消息发送给服务器时，会发送心跳信号给服务器，如果服务器没有收到客户端的心跳信号，会认为客户端掉线了。
Connect报文举例：
（2）服务器发回给客户端的CONNAC报文
3、消息的发布：
消息的发布分为客户端向服务器发布消息及服务器向订阅者推送消息，他们都用到了PUBLISH消息包
（1）PUBLISH消息包内容：
①、PacketID 数据包名，每一条消息都有一个唯一的数据包名；（只有QoS1及QoS2质量下才会有此ID，QoS0没有此ID）
②、TopicName 主题名称，主题信息
③、QoS主题的信息传输质量等级
④、retainFlag保留消息，就是发布者两条消息之间的时间间隔内，如果由新的订阅者连接，服务器会发给它其连接前的上一条消息（最新最近的消息），这样保证订阅者连接后能立即得到一条信息，而不是在等待发送间隔的过程中没有信息可显示。同时，也保证了新接入的设备与前面的设备保持同步。
举例如下：
（2）PUBLISH报文格式
（3）PUBACK数据包，
只有在QoS1、QoS2质量下才会有puback响应包。主要是返回packetID，用来确认消息的接收情况。
4. 消息订阅：
客户端通过SUBSCRIBE消息包向服务器订阅若干主题（带传输质量），服务器向客户端发送SUBACK消息包返回订阅情况。
同时客户端也可以向服务器发送UNSUBSCRIBE消息包来取消订阅主题，而服务器也会发送UNSUBACK消息包并将其请求的结果返回给客户端
消息的订阅与取消不管主题的QoS等级，均会带有packetID。
（1）SUBSCRIBE消息报文格式：（客户端向服务器发送的订阅主题的请求）
（2）SUBACK报文格式 （服务器向客户端返回他订阅成功与否的信息）
（3）UNSUBSCRIBE报文格式：（客户端向服务器发送的取消订阅请求）
（4）UNSUBACK报文格式：（服务器回应客户端的取消订阅请求）
四、MQTT开源框架
1. MQTT服务器构建的开源框架：Mosquitto
GitHub开源页面：https://github.com/eclipse/mosquitto
2. MQTT客户端设计软件：paho
GitHub开源页面：
https://github.com/eclipse/paho.mqtt.python（python）
https://github.com/eclipse/paho.mqtt.android (安卓)
https://github.com/eclipse/paho.mqtt.java （Java）
https://github.com/eclipse/paho.mqtt.javascript（JavaScript）
3. MQTT客户端模拟： MQTT.fx
五、MQTT的安全
前面我们了解了，MQTT发送数据时是明文发送的，而且还包含了clientID，username和password，所以应该对其进行加密。