[译] 你应该升级 MQTT3.1.1 的 6 个理由

原文 6 facts why it’s worth upgrading to the brand new MQTT 3.1.1 version

摘要：新版 MQTT 3.1.1 终于在 2014 年 10 月 30 日推出了。尽管大部分改动看着不明显，其实性能已经向前迈进一大步。本文将对比 MQTT 3.1和 3.1.1 的区别并详细介绍。

1. 会话表示标识

如果一个终端与服务器之间建立一个持久会话连接(假设这个终端没有使用到 clean session 来清除已有会话标识)，那么会在CONNACK中引入额外的标识 Session Present Flag。

表明MQTT服务器已经拥有当前客户端上次连接会话信息，例如 订阅的主题，排队信息以及其他信息。

逻辑值分为true 和 false。若为true， 客户端可以减少一次发送订阅Subscribe的交互步骤，更有效率的通信，若为false， 客户端需要再次发送Subscribe信息

2. 订阅失败代码反馈

之前的几个版本，客户端无法知道其发送的订阅主题是否被MQTT broker 接受。 这个特性的加入使得MQTT主题管理的权限更加精细化。若无授权，服务器会将错误代码（0x80）附加在SUBACK中，这样客户端就知道订阅失败了。

3. 匿名MQTT客户端

如果你的案例需要临时的或者匿名的MQTT客户端，现在也可以做到了。客户端现在仅仅需要在发送CONNECT的时候将客户端标识符置空即可。MQTT 服务器会随机分配一个客户端标识符。 这对于一些只要Publish的客户端非常有用。

4. 快速发布，无须等待

一个非常有趣的新特性，客户端能够在等到MQTT服务器发回CONACK之前发布消息。

这让一些小型的紧凑型的MQTT客户端可以CONNECT，PUBLISH 和 DISCONNECT，而无须等待MQTT服务器返回的确认码。这一特性对于突发模式的客户端（只关心数据尽快发出，而不是担心是否要维护一个长连接）同样适用。

当然，这需要MQTT服务器实现在分发消息之前检查客户端是否有权限发布到这些主题上。

5. 更长的客户端标识符

MQTT 3.1 的版本，对于客户端标识符的限制是23字节，十分不方便也带来不少麻烦。
MQTT 3.1.1 中，将客户端标识符的上限设为65535 字节。

其他小的改动

• CONNECT消息可变头部协议名称MQIsdp被改为MQTT，花销两个字节使得整个协议名更好读。
• 所有字符串使用UTF-8编码
• 协议级别 由3字节增加到4字节
• MQTT over websockets 被定义，IANA分配标识符为mqtt

---

关于译者

左昱骐，云巴工程师，南安普顿大学硕士。云巴是基于 MQTT 的实时消息系统。