wen MQTT基础知识(摘抄自官网)
前言：
MQTT中文官网地址：http://mqtt.p2hp.com/mqtt-5-0
一：什么是Mqtt
答：MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，因此易于实现。这些特点使得它对很多场景来说都是很好的选择，包括受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT），这些场景要求很小的代码封装或者网络带宽非常昂贵。
本协议运行在TCP/IP，或其它提供了有序、可靠、双向连接的网络连接上。它有以下特点：
1.使用发布/订阅消息模式，提供了一对多的消息分发和应用之间的解耦。
2.消息传输不需要知道负载内容。
3。提供三种等级的服务质量：
（1）“最多一次”，尽操作环境所能提供的最大努力分发消息。消息可能会丢失。例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久之后会再次发送。
（2）“至少一次”，保证消息可以到达，但是可能会重复。
（3）“仅一次”，保证消息只到达一次。例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致不正确的收费。
4.很小的传输消耗和协议数据交换，最大限度减少网络流量。
5.异常连接断开发生时，能通知到相关各方。
二：Mqtt中的关键字
答：本规范中用到的关键字 必须 MUST，不能 MUST NOT，要求 REQUIRED，将会 SHALL，不会 SHALL NOT，应该 SHOULD，不应该 SHOULD NOT，推荐 RECOMMENDED，可以 MAY，可选 OPTIONAL 都是按照 IETF RFC 2119 [RFC2119] 中的描述解释。
三：Mqtt术语
答：应用消息 Application Message MQTT协议通过网络传输应用数据。应用消息通过MQTT传输时，它们有关联的服务质量（QoS）和主题（Topic）。
客户端 Client
使用MQTT的程序或设备。客户端总是通过网络连接到服务端。它可以
- 打开连接到服务端的网络连接
- 发布应用消息给其它相关的客户端
- 订阅以请求接受相关的应用消息
- 取消订阅以移除接受应用消息的请求
- 关闭连接到服务端的网络连接
服务端 Server
一个程序或设备，作为发送消息的客户端和请求订阅的客户端之间的中介。服务端
- 接受来自客户端的网络连接
- 接受客户端发布的应用消息
- 处理客户端的订阅和取消订阅请求
- 转发应用消息给符合条件的已订阅客户端
- 关闭来自客户端的网络连接
会话 Subscription
客户端和服务端之间的状态交互。一些会话持续时长与网络连接一样，另一些可以在客户端和服务端的多个连续网络连接间扩展。
订阅 Subscription
订阅包含一个主题过滤器（Topic Filter）和一个最大的服务质量（QoS）等级。订阅与单个会话（Session）关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。
共享订阅 Shared Subscription
一个共享订阅包含一个主题过滤器（Topic
Filter）和一个最大的服务质量（QoS）等级。一个共享订阅可以与多个订阅会话相关联，便于支持大范围消息交换模式。一条主题匹配的应用消息只发送给关联到此共享订阅的多个会话中的一个会话。一个会话可以包括多个共享订阅，可以同时包含共享订阅与非共享订阅。
通配符订阅 Wildcard Subscription
通配符订阅是指主题过滤器（Topic Filter）包含一个或多个通配符的订阅。通配符订阅使得一次订阅匹配多个主题名（Topic Name）。4.7节 描述了主题过滤器中的通配符。
主题名 Topic Name
附加在应用消息上的一个标签，服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户端订阅。
主题过滤器 Topic Filter
订阅中包含的一个表达式，用于表示相关的一个或多个主题。主题过滤器可以使用通配符。
MQTT控制报文 MQTT Control Packet
通过网络连接发送的信息数据包。MQTT 规范定义了十四种不同类型的MQTT控制报文，其中一个（PUBLISH 报文）用于传输应用消息。
无效报文 Malformed Packet
根据规范不能被正确解析的控制报文。4.13节 描述了如何进行相应的错误处理。
协议错误 Protocol Error
在报文解析之后发现包含协议不允许或与客户端或服务端当前状态不一致的数据的错误。4.13节 描述了如何进行相应的错误处理。
遗嘱消息 Will Message
在网络连接非正常关闭的情况下，由服务端发布的应用消息
四：Mqtt 控制报文格式
答：MQTT协议通过交换预定义的MQTT控制报文来通信。这一节描述这些报文的格式。
MQTT控制报文由三部分组成，按照下图描述的顺序：
（1）控制报文的结构
|
Fixed Header固定报头，所有控制报文都包含 |
| Variable Header 可变报头，部分控制报文包含 |
| Payload 有效载荷，部分控制报文包含 |
解析：固定报头：每个MQTT控制报文都包含一个固定报头，固定报头格式如下：
| 比特位 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|
| byte 1 | MQTT控制报文的类型 | 用于指定控制报文类型的标志位 | ||||||
| byte 2… | 剩余长度 | |||||||
Mqtt控制报文的类型：
| 名字 | 值 | 报文流动方向 | 描述 |
|---|---|---|---|
| Reserved | 0 | 禁止 | 保留 |
| CONNECT | 1 | 客户端到服务端 | 客户端请求连接服务端 |
| CONNACK | 2 | 服务端到客户端 | 连接报文确认 |
| PUBLISH | 3 | 两个方向都允许 | 发布消息 |
| PUBACK | 4 | 两个方向都允许 | QoS 1消息发布收到确认 |
| PUBREC | 5 | 两个方向都允许 | 发布收到（保证交付第一步） |
| PUBREL | 6 | 两个方向都允许 | 发布释放（保证交付第二步） |
| PUBCOMP | 7 | 两个方向都允许 | QoS 2消息发布完成（保证交互第三步） |
| SUBSCRIBE | 8 | 客户端到服务端 | 客户端订阅请求 |
| SUBACK | 9 | 服务端到客户端 | 订阅请求报文确认 |
| UNSUBSCRIBE | 10 | 客户端到服务端 | 客户端取消订阅请求 |
| UNSUBACK | 11 | 服务端到客户端 | 取消订阅报文确认 |
| PINGREQ | 12 | 客户端到服务端 | 心跳请求 |
| PINGRESP | 13 | 服务端到客户端 | 心跳响应 |
| DISCONNECT | 14 | 两个方向都允许 | 断开连接通知 |
| AUTH | 15 | 两个方向都允许 | 认证信息交换 |
可变报头：某些 MQTT 控制报文包含一个可变报头部分。它在固定报头和有效载荷之间。可变报头的内容根据报文类型的不同而不同。可变报头的报文标识符（Packet Identifier）字段存在于在多个类型的报文里。
报文标识符：部分类型MQTT控制报文的可变报头部分包含了2个字节的报文标识符字段。这些MQTT控制报文类型为：PUBLISH报文（当QoS>0时），PUBACK，PUBREC，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE，SUBACK，UNSUBSCRIBE，UNSUBACK。
需要报文标识符的MQTT控制报文如下表所示。
报文
| 名字 | 值 |
|---|---|
| CONNECT | 不需要 |
| CONNACK | 不需要 |
| PUBLISH | 需要（如果QoS>0） |
| PUBACK | 需要 |
| PUBREC | 需要 |
| PUBREL | 需要 |
| PUBCOMP | 需要 |
| SUBSCRIBE | 需要 |
| SUBACK | 需要 |
| UNSUBSCRIBE | 需要 |
| UNSUBACK | 需要 |
| PINGREQ | 不需要 |
| PINGRESP | 不需要 |
| DISCONNECT | 不需要 |
| AUTH | 不需要 |
（未完待续。。。）
