玩转PubSubClient MQTT库

1.前言    在ESP8266学习系列中,博主一直使用HTTP协议。HTTP连接属于短连接,而在物联网应用中,广泛应用的却是MQTT协议。所以,本篇我们将学习Arduino平台上的MQTT实现库 —— PubSubClient。2.MQTT协议2.1 简介    MQTT协议(Message Queuing Telemetry Transport),翻译过来就是遥信消息队列传输,是IBM...
摘要由CSDN通过智能技术生成

1.前言

    在ESP8266学习系列中,博主一直使用HTTP协议。HTTP连接属于短连接,而在物联网应用中,广泛应用的却是MQTT协议。所以,本篇我们将学习Arduino平台上的MQTT实现库 —— PubSubClient。

2.MQTT协议

2.1 简介

    MQTT协议(Message Queuing Telemetry Transport),翻译过来就是遥信消息队列传输,是IBM公司于1999年提出的,现在最新版本是3.1.1。MQTT是一个基于TCP的发布订阅协议,设计的初始目的是为了极有限的内存设备和网络带宽很低的网络不可靠的通信,非常适合物联网通信。

image

    MQTT属于应用层协议,基于TCP协议,确保了可靠性。博主在这里不会去详细讲述MQTT协议(网上讲解MQTT协议内容很多,不需要重复),希望有兴趣的读者自行去阅读,可参考 MQTT中文文档

    MQTT通信模型如下:

image

  • 发布方(Publisher)将消息发送到 Broker(MQTT服务器);
  • Broker 接收到消息以后,检查下都有哪些订阅方订阅了此类消息,然后将消息发送到这些订阅方;
  • 订阅方(Subscriber)从 Broker 获取该消息。

2.2 MQTT消息的QOS

    MQTT消息支持三种QOS等级:

  • QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。
  • QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。
  • QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。

2.3 MQTT控制报文格式

    MQTT控制报文由三部分组成:

  • 固定报头(Fixed header),每个MQTT控制报文都包含一个固定报头;固定报头指明控制报文类型、标志Flags、剩余长度三大部分。
  • 可变报头(Variable header),某些MQTT控制报文包含一个可变报头部分;它在固定报头和有效载荷之间;可变报头的内容根据报文类型的不同而不同,通常包括 报文标识符(Packet Identifier);
  • 有效载荷(Payload),某些MQTT控制报文在报文的最后部分包含一个有效载荷,也就是携带的数据信息;

    整体上说,MQTT整体控制报文协议就是:

固定报头(一定有) + 可变报头(部分有) + 有效载荷(部分有)

    数据结构简单,传输数据量小,这也是为什么能应用于物联网应用的原因之一。

2.4 MQTT控制报文

2.4.1 CONNECT – 连接服务端

注意点:

  • 客户端到服务端的网络连接建立后,客户端发送给服务端的第一个报文必须是CONNECT报文;
  • 在一个网络连接上,客户端只能发送一次CONNECT报文。服务端必须将客户端发送的第二个CONNECT报文当作协议违规处理并断开客户端的连接;
  • 有效载荷包含一个或多个编码的字段。包括客户端的唯一标识符,Will主题,Will消息,用户名和密码。除了客户端标识之外,其它的字段都是可选的,基于标志位来决定可变报头中是否需要包含这些字段。

报文格式:

固定报头 + 可变报头 + 有效载荷

  • 固定报头: MQTTCONNECT(1 << 4)
  • 可变报头: 协议名(Protocol Name),协议级别(Protocol Level),连接标志(Connect Flags)和保持连接(Keep Alive)
  • 有效载荷: 客户端标识符,遗嘱主题,遗嘱消息,用户名,密码
2.4.2 CONNACK —— 确认连接请求

注意点:

  • 服务端发送CONNACK报文响应从客户端收到的CONNECT报文。服务端发送给客户端的第一个报文必须是CONNACK;
  • 如果客户端在合理的时间内没有收到服务端的CONNACK报文,客户端应该关闭网络连接。合理 的时间取决于应用的类型和通信基础设施;

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTCONNACK(2 << 4)
  • 可变报头: 连接确认标志 + 连接返回码
2.4.3 PUBLISH —— 发布消息

注意点:

  • PUBLISH控制报文是指从客户端向服务端或者服务端向客户端传输一个应用消息;

报文格式:

固定报头 + 可变报头 + 有效载荷

  • 固定报头: MQTTPUBLISH(3 << 4),重发标志 DUP,服务质量等级 QoS,保留标志 RETAIN,剩余长度字段
  • 可变报头: 主题名和报文标识符
  • 有效载荷: 被发布的应用消息
2.4.4 PUBACK —— 发布确认

注意点:

  • PUBACK报文是对QoS 1等级的PUBLISH报文的响应

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTPUBACK(4 << 4),剩余长度字段
  • 可变报头: 包含等待确认的PUBLISH报文的报文标识符
2.4.5 PUBREC —— 发布收到(QoS 2,第一步)

注意点:

  • PUBREC报文是对QoS等级2的PUBLISH报文的响应。它是QoS 2等级协议交换的第二个报文。

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTPUBREC(5 << 4),剩余长度字段
  • 可变报头: 包含等待确认的PUBLISH报文的报文标识符
2.4.6 PUBREL —— 发布释放(QoS 2,第二步)

注意点:

  • PUBREL报文是对PUBREC报文的响应。它是QoS 2等级协议交换的第三个报文。

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTPUBREL(6 << 4),剩余长度字段
  • 可变报头: 包含与等待确认的PUBREC报文相同的报文标识符。
2.4.7 PUBCOMP —— 发布完成(QoS 2,第三步)

注意点:

  • PUBCOMP报文是对PUBREL报文的响应。它是QoS 2等级协议交换的第四个也是最后一个报文。

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTPUBCOMP(7 << 4),剩余长度字段
  • 可变报头: 包含与等待确认的PUBREL报文相同的报文标识符
2.4.8 SUBSCRIBE —— 订阅主题

注意点:

  • 客户端向服务端发送SUBSCRIBE报文用于创建一个或多个订阅
  • 为了将应用消息转发给与那些订阅匹配的主题,服务端发送PUBLISH报文给客户端
  • SUBSCRIBE报文也(为每个订阅)指定了最大的QoS等级,服务端根据这个发送应用消息给客户端

报文格式:

固定报头 + 可变报头 + 有效载荷

  • 固定报头: MQTTSUBSCRIBE(8 << 4),剩余长度字段
  • 可变报头: 报文标识符
  • 有效载荷:包含了一个主题过滤器列表,它们表示客户端想要订阅的主题
2.4.9 SUBACK —— 订阅确认

注意点:

  • 服务端发送SUBACK报文给客户端,用于确认它已收到并且正在处理SUBSCRIBE报文
  • SUBACK报文包含一个返回码清单,它们指定了SUBSCRIBE请求的每个订阅被授予的最大QoS等级

报文格式:

固定报头 + 可变报头 + 有效载荷

  • 固定报头: MQTTSUBACK(9 << 4),剩余长度字段
  • 可变报头: 包含等待确认的SUBSCRIBE报文的报文标识符
  • 有效载荷:包含一个返回码清单。每个返回码对应等待确认的SUBSCRIBE报文中的一个主题过滤器
2.4.10 UNSUBSCRIBE —— 取消订阅

注意点:

  • 客户端发送UNSUBSCRIBE报文给服务端,用于取消订阅主题

报文格式:

固定报头 + 可变报头 + 有效载荷

  • 固定报头: MQTTUNSUBSCRIBE(10 << 4),剩余长度字段
  • 可变报头: 报文标识符
  • 有效载荷:包含客户端想要取消订阅的主题过滤器列表
2.4.11 UNSUBACK —— 取消订阅确认

注意点:

  • 服务端发送UNSUBACK报文给客户端用于确认收到UNSUBSCRIBE报文

报文格式:

固定报头 + 可变报头

  • 固定报头: MQTTUNSUBACK(11 << 4),剩余长度字段
  • 可变报头: 包含等待确认的UNSUBSCRIBE报文的报文标识符
2.4.12 PINGREQ —— 心跳请求

注意点:

  • 客户端发送PINGREQ报文给服务端
  • 在没有任何其它控制报文从客户端发给服务端时,告知服务端客户端还活着
  • 请求服务端发送 响应确认它还活着
  • 使用网络以确认网络连接没有断开
  • 保持连接(Keep Alive)处理中用到这个报文

报文格式:

固定报头

  • 固定报头: MQTTPINGREQ(12 << 4),剩余长度字段
2.4.13 PINGRESP —— 心跳响应

注意点:

  • 服务端发送PINGRESP报文响应客户端的PINGREQ报文
  • 保持连接(Keep Alive)处理中用到这个报文

报文格式:

固定报头

  • 固定报头: MQTTPINGRESP(13 << 4),剩余长度字段
2.4.14 DISCONNECT —— 断开连接

注意点:

  • DISCONNECT报文是客户端发给服务端的最后一个控制报文。
  • 表示客户端正常断开连接。

报文格式:

固定报头

  • 固定报头: MQTTDISCONNECT(14 << 4),剩余长度字段

3.PubSubClient —— ArduinoMQTT库

    老规矩,上一个百度脑图:

image

3.1 PubSubClient —— 初始化构造器

函数1说明

/**
 * 创建一个没有初始化的PubSubClient对象
 */
PubSubClient::PubSubClient() {
    this->_state = MQTT_DISCONNECTED;
    this->_client = NULL;
    this->stream = NULL;
    setCallback(NULL);
}

在使用PubSubClient对象之前,必须配置完整的内容:

WiFiClient espClient;
PubSubClient client;

void setup() {
    client.setClient(espClient);
    client.setServer("broker.example.com",1883);
    // client is now configured for use
}

函数2说明

/**
 * 创建一个部分初始化的PubSubClient对象
 * @param client client实例
 */
PubSubClient::PubSubClient(Client&
  • 3
    点赞
  • 54
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值