1、消息模型：
MQTT是一种基于代理的发布/订阅的消息协议。提供一对多的消息分发，解除应用程序耦合。一个发布者可以对应多个订阅者，当发布者发生变化的时候，他可以将消息一一通知给所有的订阅者。这种模式提供了更大的网络扩展性和更动态的网络拓扑。 
2、消息质量
MQTT提供三种质量的服务：
1）至多一次，可能会出现丢包的现象。使用在对实时性要求不高的情况。这一级别可应用于如下情景，如环境传感器数据，丢失一次读记录无所谓，因为很快下一次读记录就会产生。
2）至少一次，保证包会到达目的地，但是可能出现重包。
3）正好一次，保证包会到达目的地，且不会出现重包的现象。这一级别可用于如计费系统等场景，在计费系统中，消息丢失或重复可能会导致生成错误的费用。
3、主题名称
主题名称（Topic name）用来标识已发布消息的信息的渠道。订阅者用它来确定接收到所关心的信息。它是一个分层的结构，用斜线“/”作为分隔符。有两种通配符可以在主题发布、订阅时使用：“#”和“+”。前者可以通配多层结构，而后者只能通配一层结构。例如一个topic ： “a/b/c”,则“a/+/c”和“a/#”都可以和它相等。发布不支持模糊匹配，必须是确定的主题。
4、遗属
当一个客户端断开连接的时候，它希望客户端可以发送它指定的消息。该消息和普通消息的结构相同。通过设置该位并填入和信息相关的内容即可。
6、消息类型
| 名字 | 值 | 流动方向 | 描述 |
|---|---|---|---|
| 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套接字在服务器端和客户端连接建立时需要使用的命令。
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协议
3、MQTT服务端和客户端