androidmqtt
Ⅰ 如何采用mqtt协议实现android消息推送
使用一个代理服务器message broker，客户端client连接上这个服务器，然后告诉服务器，可以接收哪些类型的消息，同时client也可以发布自己的消息，这些消息根据协议的内容，可以别的client获取。这样就实现了消息推送。消息推送是通过一定的技术标准或协议，在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。
如果想要使用消息推送，推荐使用深圳极光的消息推送系统。深圳极光是国内首个为移动应用开发者提供专业、高效的消息推送服务的产品。品牌成长的过程，就是与客户肩并肩迈向成功的过程。极光将以市场为导向，以创新为动力，以技术为支持，不断用心努力，为每一位尊贵的客户提供极致的服务。
Ⅱ Android MQTT 通信
MQTT 协议 是基于发布/订阅模式的物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。
常用于 IOT 物联网和一些需要服务端主动通知客户端的场景。
1. 导入依赖
2. 创建 MqttHelper 辅助类，设置回调监听
3. 连接 MQTT
连接成功或失败，以及中途的连接掉线，会触发 OnMqttStatusChangeListener 回调
4. MQTT 连接状态监听
5. MQTT 收发消息监听
onSubMessage 订阅的消息回调，因为存在订阅多个 topic 的情况，所以回调能知道是来自哪个 Topic 的消息；
onPubMessage 发布的消息回调，用于确认发布的消息是否发送成功。
6. MQTT 订阅 Topic
需要在 MQTT 连接成功后才能订阅 topic，否则订阅 Topic 不成功，收不到对应消息
7. MQTT 取消订阅 Topic
8. MQTT 发布消息
9. MQTT 断开连接
10. 通知设置
由于 MQTT 启动了一个 Service，而 Android 8.0 以上对于后台 Service 限制时长 5 秒；所以将 MqttService 绑定到 Notification 上成为了一个前台通知；通知的标题和内容显示可以在 strings.xml 中设置，对应属性如下：
Android 8.0 及以上开启前台服务绑定到通知，8.0 以下默认不启用，可将 mqtt_foreground_notification_low_26 设为 true，将 8.0 以下设备也开启前台通知服务
创建 MQTT 实例时需要传送参数 MqttOptions,下面将介绍下部分参数;
1. Topic
MQTT 是一种发布/订阅的消息协议, 通过设定的主题 Topic,
发布者向 Topic 发送的 payload 负载消息会经过服务器, 转发到所有订阅袜桥
该 Topic 的订阅者
通配符 : 假想移动端消息推送场景,有的系统消息是全体用户接收,有的消息是 Android 或 iOS 设备接收, 又或者是某些消息具体推送到用户,当然, 对应的多种类型消息可以通过多订阅几个对应的 Topic 解决,也可以使用通配符;
通配符有两个, " + " 和 " # ", 与正斜杠 " / " 组合使用;加号只能表示一级Topic, 井号可以表示任意层级 Topic; 例如: 订阅 Topic为 " System/+ ", 发布者发布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而订阅的 Topic 如果是" System/# " 则可以收到;
注意,只有订阅的 Topic 才可以使用 通配符, 发布和遗嘱的 Topic 不能包含通配符.
2. ClientID
发布者和订阅者都是属于客户端, 客户端与服务端建立连接之后,发送的第一个报文消息必须是 Connect 消息隐好缺,而 Connect 的消息载荷中必须包含 clientID 客户端唯一标识;
如果两个客户端的 clientID 一样, 则服务端记录第一个客户端连接之后再收到第二个客户端连接请求,则会向一个客户端发送 Disconnect 报文断开连接, 并连接第二个客户端, 而如果此时设置了自动重连, 第一个客户端再次连接,服务端又断开与第二个的连接, 连上第一个客户端, 如此将导灶辩致两个客户端不断的被挤掉重连.
注意: clientID 使用的字符最好是 大小写字母和数字, 长度最好限制在[1, 23] 之间;
3. 遗嘱消息
可选参数, 客户端没有主动向服务端发起 disconnect 断开连接消息,然而服务端检测到和客户端之间的连接已断开, 此时服务端将该客户端设置的遗嘱消息发送出去
应用场景: 客户端因网络等情况掉线之后, 可以及时通知到所有订阅该遗嘱 Topic 的客户端;
遗嘱 Topic 中不能存在通配符.
4. Session
客户端和服务端之间建立的会话状态, 一般用于消息保存, 如果设置清除 Session,则每次客户端和服务端建立连接会创建一个新的会话,之前连接中的消息不能恢复,
而设置不清除会话, 对应发布者发送的 qos 为 1和2 的消息,还未被订阅者接收确认,则需要保存在会话中, 以便订阅者下次连接可以恢复这些消息;
注意: Session 存储的消息是保存在内容中的, 所以如果不是重要的消息,最好是设置清除 Session, 或者设置 qos = 0;
5. 心跳包
标识客户端传输一次控制报文到下一次传输之间允许的空闲时间；在这段时间内，如果客户端没有其他任何报文发送，必须发送一个 PINGREQ 报文到服务器，而如果服务端在 1.5 倍心跳时间内没有收到客户端消息，则会主动断开客户端的连接，发送其遗嘱消息给所有订阅者。而服务端收到 PINGREQ 报文之后，立即返回 PINGRESP 报文给客户端
心跳时间单位为秒，占用2个字节，最大 2^16 - 1 = 65535秒（18小时12分钟15秒）,设置为 0 表示不使用心跳机制； 心跳时间一般设置为几分钟或几十秒即可，时间短点可以更快的发出遗嘱消息通知掉线，但是时间短会增加消息频率，影响服务端并发； 微信长连接为 300 秒，而三大运营商貌似也有个连接时间最小的为 5 分钟。
6. qos
服务质量等级 qos 对应两部分,一是客户端到服务端发送的消息, 一是服务端到客户端订阅的消息; 从发布者到订阅者实际 qos 为两段路中 qos 最小的。
qos 可选值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
qos = 0 ：接收方不发送响应，发送方不进行重试；发送方只管发一次，不管是否发成功，也不管接收方是否成功接收，适用于不重要的数据传输；
qos = 1 ：确保消息至少有一次到达接收方，发送方向接收方发送消息，需要等待接收方返回应答消息，如果发送方在一定时间之内没有收到应答，发送方继续下一次消息发送，直到收到应答消息，删除本地消息缓存，不再发送；所以接收方可能收到1-n次消息；适用于需要收到所有消息，客户端可以处理重复消息。
qos = 2 ：确保消息只一次到达接收方，发送方和接收方之间消息处理流程最复杂；
Mqtt Qos 深度解读 和 MQTT协议QoS2 准确一次送达的实现
7. payload 负载消息
字节流类型, 是 MQTT 通信传输的真实数据
8. 保留消息
发布消息时设置, 对应参数 retain, 服务端将保留对应 Topic 最新的一条消息记录; 保留消息的作用是每次客户端连接上线都会收到其 Topic 的最后一条保留消息, 所以可能存在网络不稳定,频繁掉线重连,每次重连重复收到保留消息;
可以向对应的 Topic 发送一条 空消息,用于清除保留消息。
MQTT 服务搭建 Apache Apollo 服务器 搭建 MQTT 服务
Github 仓库
mqtt 协议
Ⅲ android studio怎么安装mqtt
你好，
1、 下载Apollo服务器，下载后解压，然后运行apache-apollo-1.6\bin\apollo.cmd，输入create mybroker（名字任意取，这里是根据 官网 介绍的来取的）创建服务器实例，服务器实例包含了所有的配置，运行时数据等，并且和一个服务器喊哪进程关联。
2、create mybroker之后会在bin目录下生成mybroker文件夹，里面包含有很多信息，其中etc\apollo.xml文件下是配置服务器信息的文件，etc\users.properties文件包含连接MQTT服务器时用到的用户名和密码，后面会介绍，可以修改原始的admin=password，可以接着换行添加新的用户名密码。
3、打开cmd，运行…apache-apollo-1.6\bin\mybroker\bin\apollo-broker.cmd run 开启服务器，可以在浏览器中输入 http://127.0.0.1:61680/ 查看是否安装成功，该界面展示了topic，连接数等很多信息。
经过上面的简单步骤，服务器基本上就已经完成，下一篇将介绍Android客户端的编写和注意事项。
客户端使用的API，开始我使用昌渗拦的是mqtt-client，使用过后发现问耐胡题百出，不能很好的满足要求，后来使用了官方推荐的 Eclipse Paho ，下面开始客户端代码的编写，为了方便测试这里有android和j2se两个工程：
1、新建android工程MQTTClient
2、MainActivity代码如下：
[java] view plainprint?
package ldw.mqttclient;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheledExecutorService;
import java.util.concurrent.TimeUnit;
import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
import org.eclipse.paho.client.mqttv3.MqttCallback;
import org.eclipse.paho.client.mqttv3.MqttClient;
import org.eclipse.paho.client.mqttv3.MqttConnectOptions;
import org.eclipse.paho.client.mqttv3.MqttException;
import org.eclipse.paho.client.mqttv3.MqttMessage;
import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.view.KeyEvent;
import android.widget.TextView;
import android.widget.Toast;
public class MainActivity extends Activity {
private TextView resultTv;
private String host = "tcp://127.0.0.1:1883";
private String userName = "admin";
private String passWord = "password";
private Handler handler;
private MqttClient client;
private String myTopic = "test/topic";
private MqttConnectOptions options;
private ScheledExecutor
Ⅳ Android 中使用MQTT(第一篇)
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议。它是一种发布/订阅，极其简单和轻量级的消息传递协议，专为受限设备和低带宽，高延迟或不可靠的网络而设计。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境。相对于XMPP，MQTT更加轻量级，并且占用的宽带低。
MQTT协议有以下特点：
那么问题来了？重连连接成功后重复接收到最后一条消息
MQTT推送消息订阅端重复接收问题。
（背景）订阅端断开的时候，发布端多次推送消息。
（现象）订阅端启动时，接收到最后一条推送消息有两次；即使Qos设置为2；依然是两次。
经排查是因为
MqttMessage的Retained设置为了true;
该值很多文章上只说了是 消息保留机制，若设置为true，mqtt服务器会保留每次发布的消息；较少提到 若订阅某主题的客户端重启，则会把此主题之前发布的消息重新推送到客户端。该值默认为false;去掉修改该值即可
那么问题来了？重连连接后手动那么多遗漏的消息，怎么选择只接收最新的一条消息呢？
MQTT推送消息订阅端重复接收问题。
（背景）订阅端断开的时候，发布端多次推送消息。
（现象）订阅端启动时，接收到msg1，msg2，msg3 （这三个消息都是同一个类型消息，只需要处理最新的msg3就好，不然界面会刷新三次）这个谁有什么好办法没呢？
GitHub地址： https://github.com/eclipse/paho.mqtt.android
mqtt的官方文档： http://mqtt.org/documentation
Github上有中文翻译： https://github.com/mcxiaoke/mqtt
在mole的build.gradle文件中添加依赖
在 AndroidManifest.xml 添加限权
在 AndroidManifest.xml 注册Service （MyMqttService为自己写的服务，下文会讲到）
Ⅳ android消息推送GCM、XMPP、MQTT三种方案的优劣是什么
android消息推送GCM、XMPP、MQTT三种方案的优劣如下：1、GCM
（1）优点：提供的服务、原生、简单，无需实现和部署的服务端。
（2）缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定相关的Google帐号，而且只受限于Google。
2、XMPP
（1）优点：成熟、强大、可扩展也性强、目前主要应用于聊天系统中，且已有开源的Java版的开发实例androidpn。
（2）缺点：协议较复杂、冗余（基于XML）、也比较费流量和费电，部署硬件成本高。
3、MQTT
（1）优点：简洁、小巧、可扩展性强、是比较省流量、省电。目前已有C++版的服务端组件rsmb。
（2）缺点：不够成熟、实现起来较复杂、服务端组件rsmb不开源，也是部署硬件成本较高。
消息推送软件可以使用深圳极光的。极光成立于2011年；凭借领先的人工智能及机器学习技术，极光将在APP消息推送、用户增长与活跃等方面为客户提供服务。
Ⅵ android消息推送GCM、XMPP、MQTT三种方案的优劣，越仔细越好，有具体分析更好！
android消息推送GCM、XMPP、MQTT三种方案的优劣：1、GCM服务（Google Cloud Messaging）优点：Google提供的服务、原生、简单，无需实现和部署服务端。缺点：Android版本限制，该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。
2、XMPP协议（Openfire + Spark + Smack）优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。
3、MQTT协议优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb。缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。
d消息推送可以去了解一下极光，极光是个不错的平台。极光紧密围绕移动开发者需求，打造的开发者服务平台，可以提供一站式SaaS服务，通过全面覆盖PC、手机、传感器、无线路由器等多种设备数据，打造全域数据平台。当前，不断更新的SaaS产品及服务已深受国内百万开发者的认可和信赖。
Ⅶ 如何写一个MQTT连接的android客户端
MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。 我们可以从这里下载该项目的实例代码，并且可以找到一个采用php书写的服务器端实现。 架构如下所示： wmqtt.jar 是IBM提供的MQTT协议的实现。你可以从如下站点下载它。你可以将该jar包加入你自己的Android应用程序中。 Really Small Message Broker (RSMB) ，他是一个简单的MQTT代理，同样由IBM提供。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。 SAM是一个针对MQTT写的PHP库。你可以从这个下载它. send_mqtt.php是一个通过POST接收消息并且通过SAM将消息发送给RSMB的PHP脚本。 实例代码： Ø 采用XMPP协议实现Android推送 这是我在项目中采用的方案。事实上Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。 XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。 androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。经过源代码研究我发现，该服务器端基本是在另外一个开源工程openfire基础上修改实现的，不过比较郁闷的是androidpn的文档是由韩语写的，所以整个研究过程基本都是读源码。它的实现示意图如下： androidpn客户端需要用到一个基于java的开源XMPP协议包asmack，这个包同样也是基于openfire下的另外一个开源项目smack，不过我们不需要自己编译，可以直接把androidpn客户端里面的asmack.jar拿来使用。客户端利用asmack中提供的XMPPConnection类与服务器建立持久连接，并通过该连接进行用户注册和登录认证，同样也是通过这条连接，接收服务器发送的通知。 androidpn服务器端也是java语言实现的，基于openfire开源工程，不过它的Web部分采用的是spring框架，这一点与openfire是不同的。Androidpn服务器包含两个部分，一个是侦听在5222端口上的XMPP服务，负责与客户端的XMPPConnection类进行通信，作用是用户注册和身份认证，并发送推送通知消息。另外一部分是Web服务器，采用一个轻量级的HTTP服务器，负责接收用户的Web请求。服务器架构如下： 最上层包含四个组成部分，分别是SessionManager，Auth Manager，PresenceManager以及Notification Manager。SessionManager负责管理客户端与服务器之间的会话，Auth Manager负责客户端用户认证管理，Presence Manager负责管理客户端用户的登录状态，NotificationManager负责实现服务器向客户端推送消息功能。 服务器端界面如下，分别对应了上述的几个功能模块： 发送以后，我们可以在手机端看到接收的消息：
Ⅷ 为什么每份 Android 简历都说 “熟悉 MQTT 协议”
MQTT (Message Queuing Telemetry Transport，消息队列遥测传输) 是一种基于 TCP/IP 协议族的应用层协议。MQTT 协议是专门针对硬件性能低下 & 网络状况不稳定的场景设计的，这使得 MQTT 在物联网和移动应用等受限场景得到广泛应用。
目前，MQTT 主要分为两个大版本：
物联网和移动应用场景的特点是硬件性能低下和网络状况不稳定，而 MQTT 协议就是专门针对这种环境设计的，主要在四个方面有优势：
结论：这三种协议并没有绝对的优胜者，最好的协议取决于具体的需求和限制条件。但如果只从带宽、电池、功能多样性这些基本条件看，MQTT 在其中是更占优的选择。
MQTT 协议的设计特性中包含了一项 “高可靠性交付”，它需要一个保证可靠的底层传输层协议，因此 TCP 协议、TLS 协议、WebSocket 协议都可以作为 MQTT 的底层协议。而无连接的 UDP 协议会丢失或重排数据，不能满足 MQTT 协议的传输需要。
MQTT 是基于发布 - 订阅模型 (pub/sub) 的消息传递协议，与请求 - 响应模型不同，发布 - 订阅模型主要有三种角色： publisher & subscriber & subscriber ：
当 client 发布某个主题的消息时，broker 会将该消息分发给任何已订阅该主题的 client。通常来说，client 不会存储消息，一旦消橡举息被发送到这些 client，消息就会从 broker 上删除。另外，保留消息、持久连接和服务质量 QoS 可能会导致消息临时存储在 broker 上。
发布 - 订阅模式使得 消息的发布者和订阅者解耦 ，主要体现为空间解耦和时间解耦：
图片引用自 https://juejin.cn/post/6976441705067184135 —— cxuan 着
一个 MQTT 消息由三部分组成：
1、固定报头： 每一个 MQTT 消息都包含一个固定报头，包含消息类型、标志位和剩余长度三个部分。固定报头长度为 2 ~ 5 字节，具体取决于 “剩余长度” 的大小，格式如下：
2、可变报头： 不同消息的可变报头内容不一样，不过其中有一个比较通用的字段：
3、载荷： 某些 MQTT 消息会包含一个有效载荷，对于 PUBLISH 消息来说，有效载荷就是应用消息。
MQTT 的连接总是发生在 client 和 broker 之间，两个 client 之间不会互相感知。请求连接时，client 会向 broker 发送 CONNECT 连接消息，broker 接受连接后会响应 CONNACK 连接确认消息。一旦连接建立，连接会一直保持打开状态，直到 client 发送 DISCONNECT 断开连接消息或连接异常中断。
CONNECT 是 client 发送给 broker 的首个消息，并且在一次连接中，client 只能发送一次 CONNECT 消息，发送的第二个 CONNECT 消息会被 broker 当作违反协议处理，并断开连接。在 CONNECT 消息中，主要包含以下内容：
CONNACK 消息用于确认 CONNECT 消息。CONNECT 是 client 发送给 broker 的首个消息，相应地，broker 发送给 client 的首个消息一定是 CONNACK 消息。在 CONNACK 消息中，主要包含以下内容：
DISCONNECT 消息由 client 发送给 broker，用于断开连接。 DISCONNECT 消息没有可变报头和有效载荷，也没有对应的确认应答消息，表示一个干净利索地断开连接操作 。断开连接后，client 不能再发送除 CONNECT 消息之外的消息，broker 也需要丢弃和当前会话有环的遗嘱消息。
MQTT 是档虚基于发布订阅模型的协议，在建立连行如燃接后，client 可以向 broker 订阅感兴趣的一个或多个话题。
SUBSCRIBE 消息由 client 发送给 broker，用于订阅感兴趣的话题，SUBSCRIBE 消息主要包含以下内容：
SUBACK 消息用于确认 SUBSCRIBE 消息。SUBACK 消息主要包含以下内容：
UNSUBSCRIBE 消息由 client 发送给 broker，用于退订不感兴趣的话题，UNSUBSCRIBE 消息主要包含以下内容：
UNSUBACK 消息用于确认 UNSUBSCRIBE 消息。UNSUBACK 消息非常简单，只有一个包唯一标识（位于可变报头）。
当 MQTT client 在连接到 broker 之后就可以发送消息了，每条 PUBLISH 消息都包含一个 topic ，broker 会根据 topic 将消息发送给感兴趣的 client。除此之外，每条消息还会包含一个 Payload，Payload 是真正发布的应用消息，载荷的内容和格式由应用层决定，MQTT 协议层不关心。
PUBLISH 消息可以由 client 发送给 broker，也可以由 broker 发送给 client，用来运送应用层消息。PUBLISH 消息主要包含以下内容：
PUBLISH 消息的接收方需要发送确认应答，不同 QoS 等级的 PUBLISH 消息响应的消息不同：
当 client 和 broker 在一段时间内没有数据交互时，client 会发送 PINGREQ 探测消息，用于判断连接是否正常，来决定是否要关闭该连接，这就是 MQTT 协议的保活机制。
PINGREQ 消息由 client 发送给 broker。
PINGRESP 消息由 broker 发送给 client，代表 client 是存活的。
MQTT 主题本质上是一种 “寻址形式” ，用于将应用层消息分发到期望的客户端。MQTT 主题是一种类似于文件系统的分层结构，使用 “/” 正斜杠 作为分隔符。
客户端订阅主题时，可以订阅确定的主题（例如 “group/group123”），也可以使用 “通配符” 来同时订阅多个主题。需要注意的是： 在发布消息是不允许使用主题通配符，client 每次发布消息只能发布到单个主题。
$SYS 主题是 broker 上默认创建的只读主题，除此之外，broker 不会默认创建任何主题，所有主题都是由客户端订阅或发布才创建的，都不是永久性的。关于 $SYS 主题的更多介绍在 这里
当 client 连接到 broker 时，可以使用持久连接或非持久连接，这是通过 CONNECT 消息中的 CleanSession 标志来决定的（当 CleanSession = 0 时表示持久连接）。对于持久会话，broker 会存储会话状态；而对于非持久会话，broker 不会存储 client 的任何内容。会话状态主要包含以下内容：
QoS 0 等级的 PUBLISH 消息的交付能力完全依赖于底层传输层，QoS 1 和 QoS 2 等级开始在应用层提高 PUBLISH 消息的交付能力。当消息丢失时，发送端会重新发送早前尝试发送过的 PUBLISH 消息（DUP = 1），接收者收到消息也会发送确认响应消息。
在 QoS 0 的等级的 PUBLISH 消息中不包含包唯一标识。发送者不考虑消息交付结果，接收者也不发送响应。接收者最多只能收到一次消息，也有可能一次也收不到。
在 QoS 1 等级的 PUBLISH 消息中包含包唯一标识，发送方会一直将该消息当作 “未确认” 的消息，直到收到对应的 PUBACK 确认消息。具体消息流如下：
QoS 2 是最高的服务质量，保证消息不会丢失也不会重复，缺点是会增加开销。在 QoS 2 等级的 PUBLISH 消息中包含包唯一标识，发送者会一直将该消息当作 “未确认” 的消息，知道收到对应的 PUBCOMP 确认消息。
当 client 发布某个主题的消息时，broker 会将该消息分发给任何已订阅该主题的 client，随后这条消息会从 broker 上删除。可以设置 RETAIN 保留标志设置该 PUBLISH 消息为保留消息，broker 会存储该主题的最后一条保留消息，当新的 client 注册订阅时，并且匹配该消息主题时，该保留消息会发送给订阅者。 需要注意：broker 只会为每个主题保存最近一条保留消息，新收到的 RETAIN = 1 的消息会覆盖原本那条保留消息；
持久会话 & 服务质量等级 & 保留消息都会影响新订阅者是否接受消息，总结如下表：
标记 DUP = 1 的消息是重复发送的消息，MQTT 消息重传有两种场景：
需要注意：DUP 标志只对 OoS > 0 的消息有效，所有 QoS = 0 的消息 DUP 标志必须设置为 0；
TCP 协议的报文重传机制是对所有 TCP 报文有效的重传机制，而 MQTT 协议的消息重传机制只对一小部分消息有效，用于实现更可靠的消息交付保证。虽然 TCP 协议在一般情况下可以保证不丢包，但是这并不是绝对的，依然存在请求超时或者连接中断等情况。而 MQTT 协议的 QoS 1 和 QoS 2 要求更可靠的交付能力，并且需要在客户端重连后也能保证交付。因此，MQTT 协议也定义了一个消息重传机制。
到这里，关于 MQTT 协议的工作原理 & 协议消息格式 & 核心特性等内容就介绍完了。我知道你应该会对 MQTT 协议的实战应用更加感兴趣，下一篇文章里，我将带你实现基于 MQTT 协议的 IM 服务，请关注。