2024年Java最全一文读懂物联网 MQTT 协议之基础特性篇，我被面试官绝地反杀了

结尾

这不止是一份面试清单，更是一种”被期望的责任“，因为有无数个待面试者，希望从这篇文章中，找出通往期望公司的”钥匙“，所以上面每道选题都是结合我自身的经验于千万个面试题中经过艰辛的两周，一个题一个题筛选出来再次对好答案和格式做出来的，面试的答案也是再三斟酌，深怕误人子弟是小，影响他人仕途才是大过，也希望您能把这篇文章分享给更多的朋友，让他帮助更多的人，帮助他人，快乐自己，最后，感谢您的阅读。

由于细节内容实在太多啦，在这里我花了两周的时间把这些答案整理成一份文档了，在这里只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

2.4 消息过滤

很明显，broker 在 pub/sub 过程中起着举足轻重的作用。但是代理如何过滤所有消息，以便每个订阅者只接收感兴趣的消息？broker 有几个可以过滤的选项：

• 基于主题的过滤

此过滤基于属于每条消息的主题。接收客户端向代理订阅感兴趣的主题，订阅后，broker 就会确保客户端收到发布到 topic 中的消息。

• 基于内容的过滤

在基于内容的过滤中，broker 会根据特定的内容过滤消息，接受客户端会经过过滤他们感兴趣的内容。这种方法的一个显著的缺点就是必须事先知道消息的内容，不能加密或者轻易修改。

• 基于类型的过滤

当使用面向对象的语言时，基于消息（事件）的类型/类进行过滤是一种常见做法。例如，订阅者可以收听所有类型为 Exception 或任何子类型的消息。

2.5 MQTT 与消息队列的区别

这里你又会说了，既然 MQTT 与主流的消息的队列都采用发布/订阅模式，那他们就是一样的。这里老周得再提一嘴，确实和消息队列很多相似的地方，但还有有些差异的，下面就来说道说道：

• 消息队列存储消息直到消息被消费 使用消息队列时，每条传入消息都存储在队列中，直到被客户端（通常称为消费者）接收。如果没有客户端接收到消息，消息将保持在队列中并等待被消费。在消息队列中，不会存在消息没有客户端消费的情况，但是在 MQTT 中，却存在 topic 无 subscriber 订阅的情况。

• 一条消息只被一个客户端消费 另一个很大的区别是，在传统的消息队列中，一条消息只能被一个消费者处理。负载分布在队列的所有消费者之间。在 MQTT 中，行为完全相反：订阅主题的每个订阅者都会收到消息，每个订阅者有相同的负载。

• 队列是命名的，必须显式创建 队列比主题严格得多。在使用队列之前，必须使用单独的命令显式创建队列。只有在队列命名和创建之后，才可以发布或消费消息。相比之下，MQTT 主题非常灵活，可以即时创建。

三、MQTT 重要概念

---

3.1 MQTT Client

publisher 和 subscriber 都属于 MQTT Client，之所以有发布者和订阅者这个概念，其实是一种相对的概念，就是指当前客户端是在发布消息还是在接收消息，发布和订阅的功能也可以由同一个 MQTT Client 实现。

MQTT 客户端是运行 MQTT 库并通过网络连接到 MQTT 代理的任何设备（从微控制器到成熟的服务器）。例如，MQTT 客户端可以是一个非常小的、资源受限的设备，它通过无线网络进行连接并具有一个最低限度的库。基本上，任何使用 TCP/IP 协议使用 MQTT 设备的都可以称之为 MQTT Client。MQTT 协议的客户端实现非常简单直接，易于实施是 MQTT 非常适合小型设备的原因之一。MQTT 客户端库可用于多种编程语言。例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和 .NET。

3.2 MQTT Broker

与 MQTT Client 对应的就是 MQTT Broker，Broker 是任何发布/订阅协议的核心，根据实现的不同，代理可以处理多达数百万连接的 MQTT Client。

Broker 负责接收所有消息，过滤消息，确定是哪个Client 订阅了每条消息，并将消息发送给对应的 Client，Broker 还负责保存会话数据，这些数据包括订阅的和错过的消息。Broker 还负责客户端的身份验证和授权。

3.3 MQTT Connection

MQTT 协议基于 TCP/IP。客户端和代理都需要有一个 TCP/IP 协议支持。

MQTT 连接始终位于一个客户端和代理之间。客户端从不直接相互连接。要发起连接，客户端向代理发送 CONNECT 消息。代理使用 CONNACK 消息和状态代码进行响应。建立连接后，代理将保持打开状态，直到客户端发送断开连接命令或连接中断。

四、消息列表

---

4.1 CONNECT

为了创建连接，客户端向代理发送命令消息。如果此 CONNECT 消息格式错误（根据 MQTT 规范）或打开网络套接字和发送连接消息之间的时间过长，代理将关闭连接。

一个 MQTT 客户端发送一条 CONNECT 连接，这条 CONNECT 连接可能会包含下面这些信息：

我们将重点关注以下选项：

• ClientId：ClientId 的长度可以是 1-23 个字符，在一个服务器上 ClientId 不能重复。如果超过 23 个字符，则服务器返回 CONNACK 消息中的返回码为 Identifier Rejected。在 MQTT 3.1.1 中，如果您不需要代理持有状态，您可以发送一个空的 ClientId。空的 ClientId 导致连接没有任何状态。在这种情况下，clean session 标志必须设置为 true，否则代理将拒绝连接。

• Clean Session：Clean Session 标志告诉代理客户端是否要建立持久会话。在持久会话 (CleanSession = false) 中，代理存储客户端的所有订阅以及以服务质量（QoS）级别 1 或 2 订阅的客户端的所有丢失消息。 如果会话不是持久的 (CleanSession = true )，代理不为客户端存储任何内容，并清除任何先前持久会话中的所有信息。

• Username/Password：MQTT 可以发送用户名和密码进行客户端认证和授权。但是，如果此信息未加密或散列，则密码将以纯文本形式发送。我们强烈建议将用户名和密码与安全传输一起使用。像 HiveMQ 这样的代理可以使用 SSL 证书对客户端进行身份验证，因此不需要用户名和密码。

• Will Message：LastWillxxx 表示的是遗愿，client 在连接 broker 的时候将会设立一个遗愿，这个遗愿会保存在 broker 中，当 client 因为非正常原因断开与 broker 的连接时，broker 会将遗愿发送给订阅了这个 topic（订阅遗愿的 topic）的 client。

• KeepAlive：keepAlive 是 client 在连接建立时与 broker 通信的时间间隔，通常以秒为单位。这个时间指的是 client 与 broker 在不发送消息下所能承受的最大时长。

4.2 CONNACK

当 broker 收到 CONNECT 消息时，它有义务回复 CONNACK 消息进行响应。CONNACK 消息包括两部分内容：

• The session present flag：会话当前标志

• A connect return code：连接返回码

• Session Present flag

会话当前标志，这个标志会告诉 client 当前 broker 是否有一个持久性会话与 client 进行交互。SessionPresent 标志和 CleanSession 标志有关，当 client 在 CleanSession 设置为 true 的情况下连接时，SessionPresent 始终为 false，因为没有持久性会话可以使用。如果 CleanSession 设置为 false，则有两种可能性，如果 ClientId 的会话信息可用，并且 broker 已经存储了会话信息，那么 SessionPresent 为 true，否则如果没有 ClientId 的任何会话信息，那么 SessionPresent 为 false。

• Connect return code

CONNACK 消息中的第二个标志是连接确认标志。这个标志包含一个返回码，告诉客户端连接尝试是否成功。连接确认标志有下面这些选项：

4.3 PUBLISH

MQTT 客户端可以在连接到 broker 后立即发布消息，MQTT 使用的是基于 topic 主题的过滤。每条消息都必须包含一个主题，broker 可以使用该主题将消息转发给感兴趣的客户端。通常，每条消息都有一个负载（Payload），其中包含要以字节格式传输的数据。MQTT 是数据无关性的，也就是说数据是由发布者 - publisher 决定要发送的是 XML 、JSON 还是二进制数据、文本数据。

MQTT 中的 PUBLISH 消息有几个我们想要详细讨论的属性：

• Topic Name：主题名称是一个简单的字符串，它以正斜杠作为分隔符进行分层结构。例如，“我的家/客厅/温度”或“德国/慕尼黑/十月节/人”。

• QoS：此数字表示消息的服务质量 (QoS)。有三个级别：0、1 和 2。服务级别决定了消息到达预期接收者（客户端或代理）的保证类型。

• Retain Flag：此标志表示 broker 将最近收到的一条 RETAIN 标志位为 true 的消息保存在服务器端（内存或者文件）。

• Payload：这个是每条消息的实际内容。MQTT 是数据无关性的。可以发送任何文本、图像、加密数据以及二进制数据。

• Packet Identifier：这个 packetId 标识在 client 和 broker 之间唯一的消息标识。packetId 仅与大于零的 QoS 级别相关。

• DUP flag： 该标志表明该消息是重复的并且由于预期的接收者（客户端或代理）没有确认原始消息而被重新发送。这仅与 QoS 大于 0 相关。

当客户端向 MQTT broker 发送消息进行发布时，broker 读取消息、确认消息（根据 QoS 级别）并处理消息。broker 的处理包括确定哪些客户端订阅了主题并将消息发送给他们。

最初发布消息的客户端只关心将 PUBLISH 消息传递给 broker。一旦 broker 收到 PUBLISH 消息，broker 就有责任将消息传递给所有订阅者。发布客户端不会得到关于是否有人对发布的消息感兴趣或有多少客户端从 broker 收到消息的任何反馈。

4.4 Subscribe

client 会向 broker 发送 SUBSCRIBE 消息来接收有关感兴趣的 topic，这个 SUBSCRIBE 消息非常简单，它包含了一个唯一的数据包标识和一个订阅列表。

• Packet Identifier：这个 PacketId 和上面的 PacketId 一样，都表示消息的唯一标识符。

• List of Subscriptions：一个 SUBSCRIBE 消息可以包含一个客户端的多个订阅。每个订阅由一个主题和一个 QoS 级别组成。订阅消息中的主题可以包含通配符，使订阅主题模式而不是特定主题成为可能。如果一个客户端存在重叠订阅，则代理会传送该主题具有最高 QoS 级别的消息。

4.5 Suback

为了确认每个订阅，broker 向客户端发送一个 SUBACK 确认消息。该消息包含原始 Subscribe 消息的数据包标识符（以明确标识该消息）和返回码列表。

• Packet Identifier：包标识符是用于标识消息的唯一标识符。它与 SUBSCRIBE 消息中的相同。

• Return Code：broker 为它在 SUBSCRIBE 消息中收到的每个主题/QoS 对发送一个返回代码。例如，如果 SUBSCRIBE 消息有五个订阅，则 SUBACK 消息包含五个返回码。返回码确认每个主题并显示 broker 授予的 QoS 级别。如果 broker 拒绝订阅，则 SUBACK 消息包含该特定主题的失败返回代码。例如，如果客户端没有足够的权限订阅主题或主题格式错误。

客户端成功发送 SUBSCRIBE 消息并收到 SUBACK 消息后，它会获取与 SUBSCRIBE 消息包含的订阅中的主题匹配的每条已发布消息。

4.6 Unsubscribe

SUBSCRIBE 消息的对应是 UNSUBSCRIBE 消息。此消息删除 broker 上客户端的现有订阅。UNSUBSCRIBE 消息与 SUBSCRIBE 消息类似，具有数据包标识符和主题列表。

最后

很多程序员，整天沉浸在业务代码的 CRUD 中，业务中没有大量数据做并发，缺少实战经验，对并发仅仅停留在了解，做不到精通，所以总是与大厂擦肩而过。

我把私藏的这套并发体系的笔记和思维脑图分享出来，理论知识与项目实战的结合，我觉得只要你肯花时间用心学完这些，一定可以快速掌握并发编程。

不管是查缺补漏还是深度学习都能有非常不错的成效，需要的话记得帮忙点个赞支持一下

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

笔记和思维脑图分享出来，理论知识与项目实战的结合，我觉得只要你肯花时间用心学完这些，一定可以快速掌握并发编程。

不管是查缺补漏还是深度学习都能有非常不错的成效，需要的话记得帮忙点个赞支持一下

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取