一、消息模型：
MQTT是一种基于代理的发布/订阅的消息协议。提供一对多的消息分发，解除应用程序耦合。一个发布者能够对应多个订阅者，当发布者发生变化的时候，他能够将消息一一通知给全部的订阅者。这种模式提供了更大的网络扩展性和更动态的网络拓扑。 
git
二、消息质量
MQTT提供三种质量的服务：
1）至多一次，可能会出现丢包的现象。使用在对实时性要求不高的状况。这一级别可应用于以下情景，如环境传感器数据，丢失一次读记录无所谓，由于很快下一次读记录就会产生。github
2）至少一次，保证包会到达目的地，可是可能出现重包。服务器
3）正好一次，保证包会到达目的地，且不会出现重包的现象。这一级别可用于如计费系统等场景，在计费系统中，消息丢失或重复可能会致使生成错误的费用。网络
三、主题名称
主题名称（Topic name）用来标识已发布消息的信息的渠道。订阅者用它来肯定接收到所关心的信息。它是一个分层的结构，用斜线“/”做为分隔符。有两种通配符能够在主题发布、订阅时使用：“#”和“+”。前者能够通配多层结构，然后者只能通配一层结构。例如一个topic ： “a/b/c”,则“a/+/c”和“a/#”均可以和它相等。发布不支持模糊匹配，必须是肯定的主题。spa
四、遗属代理
当一个客户端断开链接的时候，它但愿客户端能够发送它指定的消息。该消息和普通消息的结构相同。经过设置该位并填入和信息相关的内容便可。server
六、消息类型blog
| 名字 | 值 | 流动方向 | 描述 |
|---|---|---|---|
| Reserved | 0 | 禁止 | 保留 |
| Connect | 1 | 客户端到服务端 | 客户端到服务端的链接请求 |
| ConnACK | 2 | 服务端到客户端 | 服务端对链接请求的响应 |
| Publish | 3 | 两个方向都容许 | 发布消息（QoS0） |
| puback | 4 | 两个方向都容许 | 对QoS1发布消息的回应 |
| pubRec | 5 | 两个方向都容许 | 收到发布消息（QoS2保证传输第一步） |
| pubRel | 6 | 两个方向都容许 | 释放发布消息（QoS2保证传输第二步） |
| pubComp | 7 | 两个方向都容许 | 完成发布消息（QoS2保证传输第三步） |
| subscribe | 8 | 客户端到服务端 | 客户端订阅请求 |
| subBack | 9 | 服务端到客户端 | 订阅请求的确认 |
| unsubscribe | 10 | 客户端到服务端 | 客户端取消订阅请求 |
| unsubBack | 11 | 服务端到客户端 | 取消订阅请求确认 |
| pingReq | 12 | 客户端到服务端 | Ping（心跳）请求（保持链接） |
| pingResp | 13 | 服务端到客户端 | Ping（心跳）响应 |
| disconnect | 14 | 客户端到服务端 | 客户端断开链接 |
| reserved | 15 | 禁止 | 保留 |
开发一个MQTT库须要提供以下命令：开发
Connect ：当一个TCP/IP套接字在服务器端和客户端链接创建时须要使用的命令。get
publish ： 是由客户端向服务端发送，告诉服务器端本身感兴趣的Topic。每个publishMessage 都会与一个Topic的名字联系在一块儿。
pubRec: 是publish命令的响应，只不过使用了2级QoS协议。它是2级QoS协议的第二条消息
pubRel: 是2级QoS协议的第三条消息
publComp: 是2级QoS协议的第四条消息
subscribe： 容许一个客户端注册自已感兴趣的Topic 名字，发布到这些Topic的消息会以publish Message的形式由服务器端发送给客户端。
unsubscribe: 从客户端到服务器端，退订一个Topic。
Ping： 有客户端向服务器端发送的“are you alive”的消息。
disconnect：断开这个TCP/IP协议
三、MQTT服务端和客户端