我是
靠谱客的博主
矮小流沙，最近开发中收集的这篇文章主要介绍
MQTT协议通俗讲解，觉得挺不错的，现在分享给大家，希望可以做个参考。
概述
参考 Reference
v3.1.1
其他资源
网站
测试工具
基本概念 Basic Conception
Session 会话
定义
- 定义：某个客户端（由ClientID作为标识）和某个服务器之间的逻辑层面的通信
ClientID
- 只能包含这些 大写字母，小写字母 和 数字（0-9a-zA-Z），23个字符以内
- 如果 ClientID 在多次 TCP连接中保持一致，客户端和服务器端会保留会话信息（Session）
- 同一时间内 Server 和同一个 ClientID 只能保持一个 TCP 连接，再次连接会踢掉前一个
CleanSession 标记
- 0 —— 开启会话重用机制。网络断开重连后，恢复之前的Session信息。需要客户端和服务器有相关Session持久化机制。
- 1 —— 关闭会话重用机制。每次Connect都是一个新Session，会话仅持续和网络连接同样长的时间。
客户端 Session
- 已经发送给服务端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息
- 已从服务端接收，但是还没有完成确认的 QoS 2 级别的消息
服务器端 Session
- 会话是否存在，即使会话状态的其它部分都是空 (SessionFlag)
- 客户端的订阅信息 (ClientSubcription)
- 已经发送给客户端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息
- 即将传输给客户端的 QoS 1 和 QoS 2 级别的消息
- 已从客户端接收，但是还没有完成确认的 QoS 2 级别的消息
- （可选）准备发送给客户端的 QoS 0 级别的消息
长连接维护与管理
Keep Alive 心跳
- 目的是保持长连接的可靠性，以及双方对彼此是否在线的确认。
- 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文，它必须断开客户端的网络连接
- Keep Alive 的值由具体应用指定，一般是几分钟。允许的最大值是 18 小时 12 分 15 秒
Will 遗嘱
- 遗嘱消息（Will Message）存储在服务端，当网络连接关闭时，服务端必须发布这个遗嘱消息，所以被形象地称之为遗嘱，可用于通知异常断线。
- 客户端发送 DISCONNECT 关闭链接，遗嘱失效并删除
- 客户端在保持连接（Keep Alive）的时间内未能通讯
- 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接
- 0 -- 关闭遗嘱功能，Will QoS 和 Will Retain 必须为 0
- 1 -- 开启遗嘱功能，需要设置 Will Retain 和 Will QoS
消息基本概念
报文标识 Packet
Identifier
- 存在报文的可变报头部分，非零两个字节整数 (0-65535]
- 一个流程中重复：这些报文包含 PacketID，而且在一次通信流程内保持一致：
- PUBLISH(QoS>0 时)，PUBACK，PUBREC，PUBREL，PUBCOMP
- 新的不重复：客户端每次发送一个新的这些类型的报文时都必须分配一个当前 未使用的PacketID
- 当客户端处理完这个报文对应的确认后，这个报文标识符就释放可重用。
- 独立维护：客户端和服务端彼此独立地分配报文标识符。因此，客户端服务端组合使用相同的报文标识符可以实现 并发 的消息交换。可能出现一下情况，并不算异常：
Payload 有效载荷，消息体
- Publish 的 Payload 允许为空。在很多场合下，代表将持久消息（或者遗嘱消息）清空。
Retain 持久消息（粘性消息）
- RETAIN 标记：每个Publish消息都需要指定的标记
- 0 —— 服务端不能存储这个消息，也不能移除或替换任何 现存的保留消息
- 1 —— 服务端必须存储这个应用消息和它的QoS等级，以便它可以被分发给未来的订阅者
- 每个Topic只会保留最多一个 Retain 持久消息
- 客户端订阅带有持久消息的Topic，会立即受到这条消息
- 服务器可以选择丢弃持久消息，比如内存或者存储吃紧的时候
- 如果客户端想要删除某个Topic 上面的持久消息，可以向这个Topic发送一个Payload为空的持久消息
QoS 服务等级（消息可靠性）
最多一次 At most Once（
QoS == 0）
- 没有回复，不需要存储。有可能丢失（网络异常断开，业务层繁忙或者错误）
至少一次 At least Once（
QoS == 1
）
- 发送者S 发送前需要做持久化存储，接受者R 不需要持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBACK，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 接受者R 发送 PUBACK 后，不需要知道对方是否收到，马上把消息交给上层业务。如果此时网络异常，会导致发送者重发。这样接受者收到多个消息（所以叫至少一次）。
有且仅有一次 Exactly Once（
QoS == 2 ）
- 发送者S 发送 PUBLISH 前，需要做持久化存储。接受者R 回复PUBREC 后，也需要做持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBREC，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 如果 接受者R 没有收到 发送者S 的回复 PUBREL，过一段时间 接受者R 会重新发送PUBREC。
- 发送者S 收到 PUBREC后，删除持久化消息，但是要保存 PacketID
- 接收者R 受到 PUBREL后，删除持久化PUBREC。然后将消息发给上层，同时回复 PUBCOMP。
- 发送者S 收到 PUBCOMP 后，删除 PacketID，通信完美结束。
- 这套流程可以 严格保证 一个包不管在什么情况下 接收者R 只收到一次 。
重传标记 DUP 与重传机制 (QoS > 0)
- 如果客户端或者服务器发送了一个 Publish 消息，一段时间内没收到 PublishAck 回复，则认为消息丢失，进行重传。
- 在一个Session内，进行重传的时候，头部的 DUP 重传标志 设置为1。
- 客户端有可能收到 DUP == 0 的重传包（Payload相同，PacketID不同）。因为可能因为网络问题，下次重传时间较久，Session已经释放，PacketID 已经变更。
- 客户端发给服务器的和服务器转发给别的客户端的 Publish 消息，DUP 重传标志不会传递
- 接收者收到一个 DUP 标志为 1 的控制报文时，并不能保证之前收到过相同的报文
消息
重传顺序
- 重发任何之前的 PUBLISH 报文时，必须按原始 PUBLISH 报文的发送顺序重发 (适用于QoS 1 和 QoS 2 消息)
- 必须按照对应的 PUBLISH 报文的顺序发送 PUBACK 报文 (QoS 1 消息)
- 必须按照对应的 PUBLISH 报文的顺序发送 PUBREC 报文 (QoS 2 消息)
- 必须按照对应的 PUBREC 报文的顺序发送 PUBREL 报文 (QoS 2 消息)
- QoS == 1 时，虽然是PUBLISH有序的，但是可能会重复。例如，发布者按顺序 1,2,3,4 发送消息，订阅者收到的顺序可能是 1,2,3,2,3,4。
- QoS == 1 时，如果限制 传输窗口 (in-flight window) ==1，即同一时刻只有一个包在传输，就可以保证乱序。例如，订阅者收到的顺序可能是 1,2,3,3,4，而不是 1,2,3,2,3,4
话题 与订阅机制
Topic & Subcribe
Topic 话题 和
TopicFilter 话题过滤器
- UTF-8 编码字符串，不能超过 65535 字节。层级数量没有限制
- 不能包含任何的下文中提到的特殊符号（/、+、#），必须至少包含一个字符
- 区分大小写，可以包含空格，不能包含空字符 (Unicode U+0000)
- 在收部或尾部增加 斜杠 “/”，会产生不同的Topic和TopicFilter。举例：
- 只包含斜杠 “/” 的 Topic 或 TopicFilter 是合法的
TopicFilter
中的特殊符号
- 主题层级分隔符可以出现在 Topic 或 TopicFilter 的任何位置
- 特例：相邻的主题层次分隔符表示一个零长度的主题层级
- 只能用于单个主题层级匹配的通配符。例如，“a/b/+” 匹配 “a/b/c1” 和 “a/b/c2” ，但是不匹配 “a/b/c/d”
- 可以匹配 任意层级，包括第一个和最后一个层级。例如，“+” 是有效的，“sport/+/player1” 也是有效的。
- 可以在多个层级中使用它，也可以和多层通配符一起使用。 例如，“+/tennis/#” 是有效的。
- 只能匹配本级不能匹配上级。例如，“sport/+” 不匹配 “sport” 但是却匹配“sport/”，“/finance” 匹配 “+/+” 和 “/+” ，但是不匹配 “+”。
- 匹配包含本身的层级和子层级。例如 “a/b/c/#" 可以匹配 “a/b/c”、“a/b/c/d” 和 “a/b/c/d/e”
- 必须是最后的结尾。例如“sport/tennis/#/ranking”是无效的
- “#”是有效的，会收到所有的应用消息。 （服务器端应将此类 TopicFilter禁掉 ）
以
$
开头的
，服务器保留
- 服务端不能将 $ 字符开头的 Topic 匹配通配符 (#或+) 开头的 TopicFilter
- 服务端应该阻止客户端使用这种 Topic 与其它客户端交换消息。服务端实现可以将 $ 开头的主题名用作其他目的。
- $SYS/ 被广泛用作包含服务器特定信息或控制接口的主题的前缀
- 客户端不特意订阅 $开头的 Topic，就不会收到对应的消息
- 订阅 “#” 的客户端不会收到任何发布到以 “$” 开头主题的消息
- 订阅 “+/A/B” 的客户端不会收到任何发布到 “$SYS/A/B” 的消息
- 订阅 “$SYS/#” 的客户端会收到发布到以 “$SYS/” 开头主题的消息
- 订阅 “$SYS/A/+” 的客户端会收到发布到 “$SYS/A/B” 主题的消息
- 如果客户端想同时接受以 “$SYS/” 开头主题的消息和不以 $ 开头主题的消息，它需要同时 订阅 “#” 和 “$SYS/#”
订阅
Subscribe
与 QoS降级
- 一个Subsribe请求 可订阅多个 Topic（节省带宽，多订阅尽量用一次请求）。取消订阅也同理
- 每一个订阅需要指定一个QoS，指定了客户端接收消息所允许的最大QoS级别。但是服务器端最终授权返回的QoS可能会小于等于客户端请求的QoS
- 对于高于QoS的消息（比如说订阅的QoS限制到1，消息的QoS指定到2），那么客户端会收到一个QoS降低为指定的 限制QoS 的消息（消息的QoS降为1，不保证只收到一次）
- 订阅关系可以被覆盖，以TopicFilter为标识。如果后面订阅一个相同的TopicFilter，但是指定的QoS不同，则以后面的为准，QoS升高后，重发相应等级的 Retain 消息
安全传输与
鉴权认证 S
ecurity & Certification
传输层
- 可以采用 TCP、SSL/TLS [RFC5246] 、WebSocket 作为传输层。UDP不可以，因为不保证可靠传输与有序传输。
- 服务器端返回的数据极有可能出现 粘包 的情况。客户端经常会在连接建立之后，连续调用多个订阅，这样服务器端就会回复多个订阅ACK包，同时还有各个Topic上的持久消息，一般粘成一个TCP包返回过来
- 8883：over SSL/TLS，单向认证（强烈建议）
潜在的风险与应对机制
- 客户端和服务端的静态数据可以被访问（比如客户端Root导致数据泄露、服务器被拖库）
- 协议规定的行为可能有副作用 (如计时器攻击 “timing attacks”)
- 通信可能会被拦截、修改、重定向或者泄露（抓包、中间人）
客户端身份验证
与授权
（
Authentication & Authorization of Client
）
- 用户名+密码验证：Connect 登录的时候，传入 UserName 和 Password
- 用户名（UserName Flag）标记设置为1，才可以穿入
- 外部验证：LDAP、OAuth 或者 操作系统的认证机制
- 应用层：客户端通过应用消息给服务端发送凭证用于身份验证。
- 授权：基于客户端提供的信息如用户名、客户端标识符(ClientId)、客户端的主机名或 IP 地址，或者身份认证的结果，服务端可以限制对某些服务端资源的访问
服务端身份验证 （
Authentication of
Server
by Client
）
- MQTT 协议不是双向信任的，它没有提供客户端验证服务端身份的机制
- TLS：客户端可以使用服务端发送的SSL证书验证服务端的身份
- 应用层：可以通过服务端给客户端发送凭证用于身份验证的应用层消息
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)可以确保客户端连接的是预期的服务器。
控制报文和 Payload 的完整性（Integrity）
- TLS：提供了对网络传输的数据做完整性校验的哈希算法
- 应用层：可以在应用消息中单独包含哈希值。这样做可以为 PUBLISH 控制报文的网络传输和静态数据提供内容的完整性检查
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)连接可以在 VPN 覆盖的网络段提供数据完整性检查
控制报文和
Payload
的保密性
（Privacy）
- 轻量级加密：AES or DES，可适用于低端设备
- 应用层：可以单独加密 Payload 内容。这可以提供 Payload 传输途中和静态数据的私密性。但不能给应用消息的其它属性如 Topic 加密
- 静态数据加密：客户端和服务端实现可以加密存储静态数据，例如可以将应用消息作为会话的一部分存储
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)连接可以在 VPN 覆盖的网络段保证数据的私密性
异常行为的检测
- 服务端实现可以监视客户端的行为，检测潜在的安全风险。例如:
- 发现违反安全规则的行为，服务端实现可以断开客户端连接
- 可以基于 IP地址 或 ClientID 实现一个 动态黑名单列表
- 可以使用网络层面的控制，实现基于 IP 地址或其它信息的 速率限制 或黑名单
最佳实践 Best Practice
客户端 Client
选型
服务器端 Server
Broker选型
Benchmark
- Mosquitto + Apollo + Rabbit MQ + Mosca + VerneMQ 测评
- RocketMQ vs Kafka vs RabbitMQ 消息中间件的对比 —— 消息发送性能
分布式部署 Cluster
TopicTree 设计
参考
- HiveMQ: mqtt-essentials-part-5-mqtt-topics-best-practices
- MQTT topic naming convention
参考 Reference
v3.1.1
其他资源
网站
测试工具
基本概念 Basic Conception
Session 会话
定义
- 定义：某个客户端（由ClientID作为标识）和某个服务器之间的逻辑层面的通信
ClientID
- 只能包含这些 大写字母，小写字母 和 数字（0-9a-zA-Z），23个字符以内
- 如果 ClientID 在多次 TCP连接中保持一致，客户端和服务器端会保留会话信息（Session）
- 同一时间内 Server 和同一个 ClientID 只能保持一个 TCP 连接，再次连接会踢掉前一个
CleanSession 标记
- 0 —— 开启会话重用机制。网络断开重连后，恢复之前的Session信息。需要客户端和服务器有相关Session持久化机制。
- 1 —— 关闭会话重用机制。每次Connect都是一个新Session，会话仅持续和网络连接同样长的时间。
客户端 Session
- 已经发送给服务端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息
- 已从服务端接收，但是还没有完成确认的 QoS 2 级别的消息
服务器端 Session
- 会话是否存在，即使会话状态的其它部分都是空 (SessionFlag)
- 客户端的订阅信息 (ClientSubcription)
- 已经发送给客户端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息
- 即将传输给客户端的 QoS 1 和 QoS 2 级别的消息
- 已从客户端接收，但是还没有完成确认的 QoS 2 级别的消息
- （可选）准备发送给客户端的 QoS 0 级别的消息
长连接维护与管理
Keep Alive 心跳
- 目的是保持长连接的可靠性，以及双方对彼此是否在线的确认。
- 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文，它必须断开客户端的网络连接
- Keep Alive 的值由具体应用指定，一般是几分钟。允许的最大值是 18 小时 12 分 15 秒
Will 遗嘱
- 遗嘱消息（Will Message）存储在服务端，当网络连接关闭时，服务端必须发布这个遗嘱消息，所以被形象地称之为遗嘱，可用于通知异常断线。
- 客户端发送 DISCONNECT 关闭链接，遗嘱失效并删除
- 客户端在保持连接（Keep Alive）的时间内未能通讯
- 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接
- 0 -- 关闭遗嘱功能，Will QoS 和 Will Retain 必须为 0
- 1 -- 开启遗嘱功能，需要设置 Will Retain 和 Will QoS
消息基本概念
报文标识 Packet
Identifier
- 存在报文的可变报头部分，非零两个字节整数 (0-65535]
- 一个流程中重复：这些报文包含 PacketID，而且在一次通信流程内保持一致：
- PUBLISH(QoS>0 时)，PUBACK，PUBREC，PUBREL，PUBCOMP
- 新的不重复：客户端每次发送一个新的这些类型的报文时都必须分配一个当前 未使用的PacketID
- 当客户端处理完这个报文对应的确认后，这个报文标识符就释放可重用。
- 独立维护：客户端和服务端彼此独立地分配报文标识符。因此，客户端服务端组合使用相同的报文标识符可以实现 并发 的消息交换。可能出现一下情况，并不算异常：
Payload 有效载荷，消息体
- Publish 的 Payload 允许为空。在很多场合下，代表将持久消息（或者遗嘱消息）清空。
Retain 持久消息（粘性消息）
- RETAIN 标记：每个Publish消息都需要指定的标记
- 0 —— 服务端不能存储这个消息，也不能移除或替换任何 现存的保留消息
- 1 —— 服务端必须存储这个应用消息和它的QoS等级，以便它可以被分发给未来的订阅者
- 每个Topic只会保留最多一个 Retain 持久消息
- 客户端订阅带有持久消息的Topic，会立即受到这条消息
- 服务器可以选择丢弃持久消息，比如内存或者存储吃紧的时候
- 如果客户端想要删除某个Topic 上面的持久消息，可以向这个Topic发送一个Payload为空的持久消息
QoS 服务等级（消息可靠性）
最多一次 At most Once（
QoS == 0）
- 没有回复，不需要存储。有可能丢失（网络异常断开，业务层繁忙或者错误）
至少一次 At least Once（
QoS == 1
）
- 发送者S 发送前需要做持久化存储，接受者R 不需要持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBACK，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 接受者R 发送 PUBACK 后，不需要知道对方是否收到，马上把消息交给上层业务。如果此时网络异常，会导致发送者重发。这样接受者收到多个消息（所以叫至少一次）。
有且仅有一次 Exactly Once（
QoS == 2 ）
- 发送者S 发送 PUBLISH 前，需要做持久化存储。接受者R 回复PUBREC 后，也需要做持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBREC，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 如果 接受者R 没有收到 发送者S 的回复 PUBREL，过一段时间 接受者R 会重新发送PUBREC。
- 发送者S 收到 PUBREC后，删除持久化消息，但是要保存 PacketID
- 接收者R 受到 PUBREL后，删除持久化PUBREC。然后将消息发给上层，同时回复 PUBCOMP。
- 发送者S 收到 PUBCOMP 后，删除 PacketID，通信完美结束。
- 这套流程可以 严格保证 一个包不管在什么情况下 接收者R 只收到一次 。
重传标记 DUP 与重传机制 (QoS > 0)
- 如果客户端或者服务器发送了一个 Publish 消息，一段时间内没收到 PublishAck 回复，则认为消息丢失，进行重传。
- 在一个Session内，进行重传的时候，头部的 DUP 重传标志 设置为1。
- 客户端有可能收到 DUP == 0 的重传包（Payload相同，PacketID不同）。因为可能因为网络问题，下次重传时间较久，Session已经释放，PacketID 已经变更。
- 客户端发给服务器的和服务器转发给别的客户端的 Publish 消息，DUP 重传标志不会传递
- 接收者收到一个 DUP 标志为 1 的控制报文时，并不能保证之前收到过相同的报文
消息
重传顺序
- 重发任何之前的 PUBLISH 报文时，必须按原始 PUBLISH 报文的发送顺序重发 (适用于QoS 1 和 QoS 2 消息)
- 必须按照对应的 PUBLISH 报文的顺序发送 PUBACK 报文 (QoS 1 消息)
- 必须按照对应的 PUBLISH 报文的顺序发送 PUBREC 报文 (QoS 2 消息)
- 必须按照对应的 PUBREC 报文的顺序发送 PUBREL 报文 (QoS 2 消息)
- QoS == 1 时，虽然是PUBLISH有序的，但是可能会重复。例如，发布者按顺序 1,2,3,4 发送消息，订阅者收到的顺序可能是 1,2,3,2,3,4。
- QoS == 1 时，如果限制 传输窗口 (in-flight window) ==1，即同一时刻只有一个包在传输，就可以保证乱序。例如，订阅者收到的顺序可能是 1,2,3,3,4，而不是 1,2,3,2,3,4
话题 与订阅机制
Topic & Subcribe
Topic 话题 和
TopicFilter 话题过滤器
- UTF-8 编码字符串，不能超过 65535 字节。层级数量没有限制
- 不能包含任何的下文中提到的特殊符号（/、+、#），必须至少包含一个字符
- 区分大小写，可以包含空格，不能包含空字符 (Unicode U+0000)
- 在收部或尾部增加 斜杠 “/”，会产生不同的Topic和TopicFilter。举例：
- 只包含斜杠 “/” 的 Topic 或 TopicFilter 是合法的
TopicFilter
中的特殊符号
- 主题层级分隔符可以出现在 Topic 或 TopicFilter 的任何位置
- 特例：相邻的主题层次分隔符表示一个零长度的主题层级
- 只能用于单个主题层级匹配的通配符。例如，“a/b/+” 匹配 “a/b/c1” 和 “a/b/c2” ，但是不匹配 “a/b/c/d”
- 可以匹配 任意层级，包括第一个和最后一个层级。例如，“+” 是有效的，“sport/+/player1” 也是有效的。
- 可以在多个层级中使用它，也可以和多层通配符一起使用。 例如，“+/tennis/#” 是有效的。
- 只能匹配本级不能匹配上级。例如，“sport/+” 不匹配 “sport” 但是却匹配“sport/”，“/finance” 匹配 “+/+” 和 “/+” ，但是不匹配 “+”。
- 匹配包含本身的层级和子层级。例如 “a/b/c/#" 可以匹配 “a/b/c”、“a/b/c/d” 和 “a/b/c/d/e”
- 必须是最后的结尾。例如“sport/tennis/#/ranking”是无效的
- “#”是有效的，会收到所有的应用消息。 （服务器端应将此类 TopicFilter禁掉 ）
以
$
开头的
，服务器保留
- 服务端不能将 $ 字符开头的 Topic 匹配通配符 (#或+) 开头的 TopicFilter
- 服务端应该阻止客户端使用这种 Topic 与其它客户端交换消息。服务端实现可以将 $ 开头的主题名用作其他目的。
- $SYS/ 被广泛用作包含服务器特定信息或控制接口的主题的前缀
- 客户端不特意订阅 $开头的 Topic，就不会收到对应的消息
- 订阅 “#” 的客户端不会收到任何发布到以 “$” 开头主题的消息
- 订阅 “+/A/B” 的客户端不会收到任何发布到 “$SYS/A/B” 的消息
- 订阅 “$SYS/#” 的客户端会收到发布到以 “$SYS/” 开头主题的消息
- 订阅 “$SYS/A/+” 的客户端会收到发布到 “$SYS/A/B” 主题的消息
- 如果客户端想同时接受以 “$SYS/” 开头主题的消息和不以 $ 开头主题的消息，它需要同时 订阅 “#” 和 “$SYS/#”
订阅
Subscribe
与 QoS降级
- 一个Subsribe请求 可订阅多个 Topic（节省带宽，多订阅尽量用一次请求）。取消订阅也同理
- 每一个订阅需要指定一个QoS，指定了客户端接收消息所允许的最大QoS级别。但是服务器端最终授权返回的QoS可能会小于等于客户端请求的QoS
- 对于高于QoS的消息（比如说订阅的QoS限制到1，消息的QoS指定到2），那么客户端会收到一个QoS降低为指定的 限制QoS 的消息（消息的QoS降为1，不保证只收到一次）
- 订阅关系可以被覆盖，以TopicFilter为标识。如果后面订阅一个相同的TopicFilter，但是指定的QoS不同，则以后面的为准，QoS升高后，重发相应等级的 Retain 消息
安全传输与
鉴权认证 S
ecurity & Certification
传输层
- 可以采用 TCP、SSL/TLS [RFC5246] 、WebSocket 作为传输层。UDP不可以，因为不保证可靠传输与有序传输。
- 服务器端返回的数据极有可能出现 粘包 的情况。客户端经常会在连接建立之后，连续调用多个订阅，这样服务器端就会回复多个订阅ACK包，同时还有各个Topic上的持久消息，一般粘成一个TCP包返回过来
- 8883：over SSL/TLS，单向认证（强烈建议）
潜在的风险与应对机制
- 客户端和服务端的静态数据可以被访问（比如客户端Root导致数据泄露、服务器被拖库）
- 协议规定的行为可能有副作用 (如计时器攻击 “timing attacks”)
- 通信可能会被拦截、修改、重定向或者泄露（抓包、中间人）
客户端身份验证
与授权
（
Authentication & Authorization of Client
）
- 用户名+密码验证：Connect 登录的时候，传入 UserName 和 Password
- 用户名（UserName Flag）标记设置为1，才可以穿入
- 外部验证：LDAP、OAuth 或者 操作系统的认证机制
- 应用层：客户端通过应用消息给服务端发送凭证用于身份验证。
- 授权：基于客户端提供的信息如用户名、客户端标识符(ClientId)、客户端的主机名或 IP 地址，或者身份认证的结果，服务端可以限制对某些服务端资源的访问
服务端身份验证 （
Authentication of
Server
by Client
）
- MQTT 协议不是双向信任的，它没有提供客户端验证服务端身份的机制
- TLS：客户端可以使用服务端发送的SSL证书验证服务端的身份
- 应用层：可以通过服务端给客户端发送凭证用于身份验证的应用层消息
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)可以确保客户端连接的是预期的服务器。
控制报文和 Payload 的完整性（Integrity）
- TLS：提供了对网络传输的数据做完整性校验的哈希算法
- 应用层：可以在应用消息中单独包含哈希值。这样做可以为 PUBLISH 控制报文的网络传输和静态数据提供内容的完整性检查
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)连接可以在 VPN 覆盖的网络段提供数据完整性检查
控制报文和
Payload
的保密性
（Privacy）
- 轻量级加密：AES or DES，可适用于低端设备
- 应用层：可以单独加密 Payload 内容。这可以提供 Payload 传输途中和静态数据的私密性。但不能给应用消息的其它属性如 Topic 加密
- 静态数据加密：客户端和服务端实现可以加密存储静态数据，例如可以将应用消息作为会话的一部分存储
- VPN：在客户端和服务端之间使用虚拟专用网(VPN)连接可以在 VPN 覆盖的网络段保证数据的私密性
异常行为的检测
- 服务端实现可以监视客户端的行为，检测潜在的安全风险。例如:
- 发现违反安全规则的行为，服务端实现可以断开客户端连接
- 可以基于 IP地址 或 ClientID 实现一个 动态黑名单列表
- 可以使用网络层面的控制，实现基于 IP 地址或其它信息的 速率限制 或黑名单
最佳实践 Best Practice
客户端 Client
选型
服务器端 Server
Broker选型
Benchmark
- Mosquitto + Apollo + Rabbit MQ + Mosca + VerneMQ 测评
- RocketMQ vs Kafka vs RabbitMQ 消息中间件的对比 —— 消息发送性能
分布式部署 Cluster
TopicTree 设计
参考
- HiveMQ: mqtt-essentials-part-5-mqtt-topics-best-practices
- MQTT topic naming convention
最后
以上就是矮小流沙为你收集整理的MQTT协议通俗讲解的全部内容，希望文章能够帮你解决MQTT协议通俗讲解所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复