版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/weixin_41572450/article/details/82465671
1.前言
先来看下这种应用场景，如下图：
这张图是从阿里云网站上找到的，体现了下面内容：
- 数据采集
大量的车辆连接，几十万甚至上百万量车，数据要实时双向互通，数据有上传，也有下推数据，需要保证实时高并发可靠传输。 - 数据处理和数据存储
收集的数据要进行数据处理和存储。例如，要实时存储单车辆运行时的数据、电池用量、状态信息等，还需要对总体的车辆的数据进行计算和统计。
MQTT就比较适合做这种应用，其实我感觉那些社交聊天软件也是MQTT的思想。
MQTT–消息队列遥测传输协议，建立在TCP之上，基于发布Publish/订阅Subscribe模式，二进制传输的轻量级消息协议。
2.拓扑结构如下
从图中可以看到有3中角色，发布者Publisher -> 代理Broker -> 订阅者Subscriber
发布和订阅者可以是同一个设备，也可以是不同设备，发布者比较典型的代表就是散落在各地的传感器，比如温度传感器，订阅者可以是手机、电脑、数据库等，订阅者先要订阅相关主题，Broker就会把订阅者订阅的主题发给订阅者。
这种结构替代传统的客户端/服务器模型，可以实现以下解耦
- 空间解耦 :发布者和订阅者不需要知道对方
- 时间解耦 :发布者和订阅者不需要同时运行（离线消息）
- 同步解耦 :发布和接收都是异步通讯，无需停止任何处理
3.基本概念
- 报文结构
- 报文类型
MQTT固定报头的第一个字节的高4bit表示报文类型
MQTT固定报头的第一个字节的低4bit表示报文类型对应的标志位
上表中的 DUP,QoS,RETAIN 是在 MQTT V3.1.1 协议里用的， 用于描述发布的这一帧消息的属性。
综上可以得到固定报头第一个字节
可以分成这几类
连接Connect / disconnect
发布Publish
订阅Subscribe / unsubscribe
保活Pingreq - 特性
服务质量QoS（Quality of Service）
最多一次：发送一次，无需回复，消息有可能丢失。（传感器数据）
至少一次：发送者没有收到接收者的PUBACK，过一段时间会重新发送，消息可能重复。
只有一次：发送过程经过 PUBREC、PUBREL、PUBCOMP，保证一个包只收到一次
保留消息Retained Messages
持续会话Persistent Session
最后遗嘱Last Will and Testament
基于主题，具有主题过滤器
