PUBCOMP报文是对PUBREL报文的响应。它是QoS 2等级协议交换的第四个也是最后一个报文。
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|
| byte 1 | MQTT控制报文类型 (7) | 保留位 | ||||||
| 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | |
| byte 2 | 剩余长度 (2) | |||||||
剩余长度字段
表示可变报头的长度，编码为变长字节整数。
PUBCOMP报文可变报头按顺序包含以下字段：所确认的PUBREL报文标识符，PUBCOMP原因码，属性。属性（Properties）编码规则如2.2.2节所述。
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|
| byte 1 | 报文标识符 MSB | |||||||
| byte 2 | 报文标识符 LSB | |||||||
| byte 3 | PUBCOMP原因码 | |||||||
| byte 4 | 属性长度 | |||||||
可变报头第3字节是PUBCOMP原因码。如果剩余长度为2，则表示使用原因码0x00（成功）。
| 值 | 16进制 | 原因码名称 | 说明 |
|---|---|---|---|
| 0 | 0x00 | 成功 | 报文标识符已释放。QoS 2消息已完成发布。 |
| 146 | 0x92 | 报文标识符未发现 | 未知的报文标识符。会话恢复阶段这并非错误，但其他时间这表明服务端和客户端的会话状态不匹配。 |
服务端或客户端发送PUBCOMP报文时必须设置一种PUBCOMP原因码 [MQTT-3.7.2-1]。当原因码为0x00（成功）且没有属性（Properties）时，原因码和属性长度可以被省略。在这种情况下，PUBCOMP剩余长度为2。
PUBCOMP报文可变报头中的属性长度被编码为变长字节整数。如果剩余长度小于4，则表示没有属性长度字段。
31 (0x1F) ，原因字符串（Reason String）标识符。
跟随其后的是UTF-8编码的字符串，表示此次响应相关的原因。此原因字符串（Reason String）是为诊断而设计的可读字符串，不应该被接收端所解析。
发送端使用此值向接收端提供附加信息。如果加上原因字符串之后的PUBCOMP报文长度超出了接收端指定的最大报文长度（Maximum Packet Size），则发送端不能发送此原因字符串 [MQTT-3.7.2-2]。包含多个原因字符串将造成协议错误（Protocol Error）。
38 (0x26) ，用户属性（User Property）标识符。 跟随其后的是UTF-8字符串对。此属性可用于提供诊断信息或关于其他信息。如果加上用户属性之后的PUBCOMP报文长度超出了接收端指定的最大报文长度（Maximum Packet Size），则发送端不能发送此属性 [MQTT-3.7.2-3]。用户属性（User Property）允许出现多次，以表示多个名字/值对，且相同的名字可以多次出现。
PUBCOMP报文没有有效载荷。
描述见4.3.3节。
- 3.0 Contents – MQTT控制报文
- 3.1 CONNECT – 连接服务端
- 3.2 CONNACK – 确认连接请求
- 3.3 PUBLISH – 发布消息
- 3.4 PUBACK –发布确认
- 3.5 PUBREC – 发布收到（QoS 2，第一步）
- 3.6 PUBREL – 发布释放（QoS 2，第二步）
- 3.7 PUBCOMP – 发布完成（QoS 2，第三步）
- 3.8 SUBSCRIBE - 订阅主题
- 3.9 SUBACK – 订阅确认
- 3.10 UNSUBSCRIBE –取消订阅
- 3.11 UNSUBACK – 取消订阅确认
- 3.12 PINGREQ – 心跳请求
- 3.13 PINGRESP – 心跳响应
- 3.14 DISCONNECT –断开连接
- 3.15 AUTH – 认证交换