【001_IoT/物联网通信协议基础: HTTP、Websocket、MQTT、AMQP、COAP、LWM2M一文搞懂】

2024-04-21 21:20
文章标签 基础 http websocket mqtt 一文 联网 001 通信协议 搞懂 amqp iot coap lwm2m

本文主要是介绍【001_IoT/物联网通信协议基础: HTTP、Websocket、MQTT、AMQP、COAP、LWM2M一文搞懂】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

001_IoT/物联网通信协议基础: HTTP、Websocket、MQTT、AMQP、COAP、LWM2M一文搞懂

文章目录

  • 001_IoT/物联网通信协议基础: HTTP、Websocket、MQTT、AMQP、COAP、LWM2M一文搞懂
    • 创作背景
    • 通信模型
      • ISO/OSI七层模型 和 TCP/IP四层模型
      • 网络通信数据包格式（Ethernet II）
    • MQTT - Message Queuing Telemetry Transport(v3.1.1)
      • MQTT 数据包格式
      • MQTT库
      • 官方文档
    • HTTP - Hypertext Transfer Protocol
      • HTTP消息格式
      • HTTP 常用请求方法
      • HTTP 常用请求头
      • HTTP 常用响应头
      • HTTP 常用返回码
      • HTTP 测试工具
    • CoAP - Constrained Application Protocol
      • CoAP 和 HTTP 区别
      • CoAP 结构模型
      • CoAP 消息/Message层
      • CoAP 请求Request/响应Response层
      • CoAP 消息/Message 格式
      • CoAP 智能家居的应用
      • CoAP 常用库
    • WebSocket
      • `WebSocket` 解决 `HTTP` 单向通信限制:
      • `WebSocket` 解决 `HTTP` 服务端无法主动通知客户端:
      • `WebSocket` 分层结构
      • `WebSocket` 协议
      • Websocket URI说明
      • WebSocket 格式
      • Websocket Mask/掩码处理
      • WebSocket 实现库
      • HTTP VS. Websocket
        • **HTTP 更适合的场景**
        • **WebSocket 更适合的场景**
    • LWM2M
      • LWM2M总体架构
      • LWM2M 客户端/Client 引擎架构
      • LWM2M对象模型
      • LWM2M 内部对象
      • LWM2M 设备管理
      • LWM2M 应用场景示例
    • AMQP - Advanced Message Queuing Protocol
      • AMQP 整体架构
      • AMQP交换机类型/AMQP Exchange Type
    • IoT 通信协议对比
    • 术语

创作背景

学历代表过去、能力代表现在、学习力代表将来。 一个良好的学习方法是通过输出来倒逼自己输入。写博客既是对过去零散知识点的总结和复盘，也是参加了 零声教育 写博客活动。

零声教育体验课：https://xxetb.xetslk.com/s/3fbO81

本文是开发过程中的知识点总结，供大家学习交流使用，如有任何错误或不足之处，请在评论区指出。

通信模型

ISO/OSI七层模型 和 TCP/IP四层模型

img_network_model

如图，左边为 ISO/OSI 7层模型，右边是 TCP/IP 4层模型，中间为各层对应的协议。

  • HTTP：超文本传输协议，用于在 客户端/C和服务器/S 之间传输和交换Web页面和数据。
  • Websocket：在HTTP基础上提供了 双向通信 能力的协议，适用于实时交互式应用。
  • MQTT：消息队列遥测传输，一种轻量级的 发布/订阅 消息传输协议，常用于物联网设备之间的通信。
  • AMQP：高级消息队列协议，用于可靠地传输和交换消息的协议，适用于 企业级消息队 列系统。
  • CoAP：约束应用协议，一种专为受限环境（如物联网设备）设计的轻量级通信协议, 一般基于UDP。
  • LWM2M：物联网设备管理和数据传输协议，基于CoAP层之上的，用于远程管理和监控物联网设备。
  • TCP: 面向连接的、可靠的数据传输，适用于对数据完整性要求高的场景，会增加延时，如数据需要加密则在应用层和TCP层之间加入TLS/SSL相关库（openssl、mbedTLS）进行数据加密。
    IEEE 802.11 ax 为Wi-FI 6，在通信过程中一般在底层会把包转换以太网格式，因此在 tcpdump 等工具抓出来的包显示的是以太网包。
  • UDP: 面向无连接的、不可靠的数据传输，适用于实时性要求高但对数据丢失不敏感的应用，有些场景会应用层实现可靠传输，实现数据加密（DTLS）。
  • IEEE 802.3 : 以太网局域网技术的规范。
  • IEEE 802.11 ：一系列（IEEE 802.11 a/g/n/ax）无线局域网（WLAN）标准，它规定了无线网络的各种方面，包括传输速率、频谱利用、安全性等。

网络通信数据包格式（Ethernet II）

img_ethernet_ii_format
如图，Ethernet II 数据包格式：

  • Preamble（前导码）：7个字节，用于在数据包传输之前进行同步。
  • Start of Frame Delimiter（帧起始符）：1个字节，指示数据包的开始。
  • 目的地址（Destination Address）：6个字节，指示数据包的目标MAC地址。
  • 源地址（Source Address）：6个字节，指示数据包的源MAC地址。
  • 类型/长度（Type/Length）：2个字节。当数值小于等于 1500 时，表示长度，当数值大于 1500 时，表示类型。长度指示了上层数据的长度，类型指示了上层协议的类型，如IPv4（0x0800）、IPv6（0x86DD）等。
  • 有效载荷（Payload）：46-1500个字节，包含了上层协议的数据。
  • 帧校验序列（Frame Check Sequence）：4个字节，用于校验数据包在传输过程中是否损坏。
  • Interpacket Gap（包间间隔）：12个字节，用于在两个数据包之间进行间隔，确保网络设备能够正确处理数据包。

MQTT - Message Queuing Telemetry Transport(v3.1.1)

  • M2M/IoT连接协议
  • 极轻量级的发布/订阅消息传输
  • 小型代码，网络带宽非常有限
  • 卫星链路、拨号上网、家庭自动化和小型设备场景
  • 小尺寸、低功耗、数据包尺寸最小化

img_mqtt_overview

如图，在MQTT协议中，有三个重要的角色：发布者（Publisher）、代理（Broker） 和 订阅者（Subscriber）。

  • 发布者（Publisher）

    发布者是MQTT网络中的客户端，负责发布（发送）消息到MQTT代理（Broker）。发布者将消息发送到一个或多个主题（Topic），并且可以选择消息的服务质量级别（QoS）。

  • 代理（Broker）

    代理是MQTT网络中的中介，负责接收发布者发布的消息，并将其传递给订阅者。它负责维护订阅者与发布者之间的关系，处理订阅和取消订阅的请求，并确保消息按照订阅者的需求进行传递。

  • 订阅者（Subscriber）

    订阅者是MQTT网络中的客户端，负责订阅（接收）一个或多个主题（Topic）的消息。订阅者告知代理它感兴趣的主题，然后代理在有新消息发布时将其传递给订阅者。

MQTT 数据包格式

img_mqtt_package_format

  1. 固定头部（Fixed Header）：

    位字段描述
    0-3控制报文类型指示数据包的类型，如CONNECT、PUBLISH等。
    4DUP指示消息是否是重发的副本。
    5-6QoS指示消息的服务质量级别。
    7RETAIN指示代理是否应保留已发布的消息。
    8+剩余长度（RL）① 编码剩余长度字段，表示可变头部和有效载荷的总长度。
    最多可以使用4个字节来编码长度字段。
    ② 最高位为0表示剩余长度的编码结束，
    7个比特位用于表示长度的最低7位。
    ③ 每个字节的最高位为1，
    表示后续还有剩余长度字段，
    剩下的7个比特位用于表示长度的下一个字节。
    ④ MAX=268435455 (0xFF, 0xFF, 0xFF, 0x7F)。
    • 控制报文类型，如下表所示:
      控制报文类型值描述
      Reserved0保留，不使用。
      CONNECT1客户端请求连接到代理。
      CONNACK2代理对 CONNECT 请求的响应。
      PUBLISH3发布消息到指定主题。
      PUBACK4对 QoS 1 的 PUBLISH 报文的确认。
      PUBREC5对 QoS 2 的 PUBLISH 报文的接收。
      PUBREL6对 QoS 2 的 PUBLISH 报文的释放。
      PUBCOMP7对 QoS 2 的 PUBLISH 报文的完成。
      SUBSCRIBE8订阅一个或多个主题。
      SUBACK9对 SUBSCRIBE 报文的确认。
      UNSUBSCRIBE10取消订阅一个或多个主题。
      UNSUBACK11对 UNSUBSCRIBE 报文的确认。
      PINGREQ12客户端发送心跳请求。
      PINGRESP13代理对 PINGREQ 请求的响应。
      DISCONNECT14客户端主动断开连接。
      Reserved15保留，不使用。
    • QoS， 如下表所示：
      QoS值描述
      00最多一次传输（At most once）：消息可能丢失。
      11至少一次传输（At least once）：消息至少被传输一次，但可能会重复。
      22有且仅有一次传输（Exactly once）：确保消息仅被传输一次。

  2. 可变头部（Variable Header）：

    • 根据报文类型的不同，可变头部的内容也不同（不是所有的类型都有可变头）。例如，CONNECT 报文的可变头部包含协议版本号、连接标志等。具体如下表所示:
      img_mqtt_variable_header

      可变头部的数据包标识符字段在几种数据包类型中是共同存在的，具体是否存在，如下表:
      img_mqtt_variable_header_id

  3. 有效载荷（Payload）：Payload 数据段是 MQTT 数据包中实际传输的部分，它是实现 MQTT 消息传输的核心。

    • 数据包是否有payload，如下表所示:
    • Payload 各类型数据包
      img_mqtt_payload

MQTT库

  • Servers/Brokers:
    • 这个链接链接列出来很多MQTT库：https://github.com/mqtt/mqtt.org/wiki/servers
    • 其中用得比较广泛的有EMQX、Mosquitto、NanoMQ、VerneMQ，这里是这4个的性能对比。
  • Client:
    • 客户端的库就非常多了，可以参考这里
    • 其中MQTTX用来测试非常不错，地址：https://mqttx.app/。

官方文档

  • mqtt-v3.1.1: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf
  • mqtt-v5.0: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf

HTTP - Hypertext Transfer Protocol

HTTP（，超文本传输协议）是一种用于传输超文本的应用层协议，它是万维网的基础。HTTP 被用于在 Web 浏览器和 Web 服务器之间传递数据。

HTTP 版本RFC 文档发布时间主要特性
HTTP/0.9RFC 19451990- 最初的版本，只支持 GET 方法
- 响应内容是 HTML 格式
HTTP/1.0RFC 20681996- 引入了请求头和响应头
- 支持更多的请求方法和状态码
HTTP/1.1RFC 2616
RFC 7230-7235		1997
2014		- 当前互联网使用最广
- 引入持久连接，提高性能
- 支持管道化，允许并行发送多个请求
- 引入 Host 头字段，支持虚拟主机
- 协议参考这里
HTTP/2RFC 75402015- 使用二进制格式进行传输，减少了传输的开销
- 引入了头部压缩机制，减少了头部的大小
- 支持多路复用，允许在单个连接上发送多个请求和响应
HTTP/3RFC 91142019- 基于 QUIC 协议，提供更快的连接建立和数据传输
- 改善了性能和安全性，减少了网络延迟

HTTP消息格式

消息格式说明
起始行/请求行/状态行包含协议版本、状态码和状态消息（对于响应消息）
请求方法、请求URI和协议版本（对于请求消息）。
0或多个请求头包含一系列键值对，每个键值对描述了消息的一些信息，如Content-Type、Content-Length等。每个键值对以冒号分隔，键值对之间以换行符分隔。
空行用于分隔请求头和消息体，通常只包含一个换行符，表示请求头结束。
可选消息体包含具体的消息内容，如POST请求中的表单数据或服务器返回的HTML页面内容。对于GET请求，通常没有消息体。
空行表示消息体的结束，后面没有其他内容。

具体消息格式如下图所示：
img_http_protocol

HTTP 常用请求方法

序号请求方法描述
1GET请求指定的资源。
2POST向指定的资源提交数据进行处理请求（例如提交表单或上传文件）。
3PUT请求服务器存储一个资源，并用请求的数据替换指定的资源。
4DELETE请求服务器删除指定的资源。
5HEAD类似于GET请求，但服务器只返回请求头，不返回请求体。
6PATCH请求服务器对资源进行部分修改。
7OPTIONS请求查询服务器支持的HTTP请求方法和其他特性，在跨域请求的时候，在调用其它方法前，会调用此方法。
8TRACE用于测试远程服务器的性能。

HTTP 常用请求头

序号请求头描述
1User-Agent客户端标识，包含了客户端的软件类型、操作系统、软件版本等信息。
2Accept告诉服务器客户端能够处理的媒体类型和媒体类型的相对优先级。
3Content-Type请求或响应的实体的媒体类型。
4Content-Length请求或响应实体的长度（以字节为单位）。
5Host表示服务器的主机名和端口号。
6Cookie客户端向服务器发送的Cookie信息。
7Cache-Control控制缓存行为的指令，如no-cache、max-age等。
8Accept-Encoding告诉服务器客户端能够解码的编码方式。
9Accept-Language告诉服务器客户端偏好的自然语言。
10Referer表示请求的来源，即前一个页面的URL。
11Authorization包含客户端提供给服务器的身份验证凭证。
12Origin请求的来源，用于跨域请求。
13Connection控制是否保持连接，如keep-alive、close等。
14If-Modified-Since如果资源自指定日期以来没有被修改，则发送请求。
15If-None-Match如果资源与指定的ETag匹配，则发送请求。

HTTP 常用响应头

序号响应头描述
1Content-Type响应的实体的媒体类型。
2Content-Length响应实体的长度（以字节为单位）。
3Cache-Control控制缓存行为的指令，如no-cache、max-age等。
4Content-Encoding响应实体的编码方式，如gzip、deflate等。
5Server表示响应的服务器软件类型和版本号。
6Last-Modified表示响应实体的最后修改时间。
7Location重定向时新的URL。
8Set-Cookie服务器向客户端设置的Cookie信息。
9Expires表示响应的过期时间。
10ETag资源的唯一标识，用于缓存控制。
11Content-Disposition响应实体的处理方式，如inline、attachment等。
12Access-Control-Allow-Origin指定响应可以被哪些域访问。
13Access-Control-Allow-Headers指定响应可以被哪些请求头访问。
14Access-Control-Allow-Methods指定响应可以支持哪些HTTP方法。
15Access-Control-Allow-Credentials指定响应中是否包含凭证信息。

HTTP 常用返回码

序号状态码描述
1100继续。客户端应继续其请求。
2101切换协议。服务器正在协商切换协议。
3200请求成功。
4201请求已经被实现，而且有一个新的资源已经依据请求的需要而建立。
5204服务器成功处理了请求，但不需要返回任何实体内容。
6301永久性重定向。
7302临时性重定向。
8304资源未修改，客户端可使用缓存数据。
9400请求参数有误。
10401需要身份验证。
11403服务器拒绝请求。
12404请求的资源不存在。
13405请求方法不被允许。
14500服务器内部错误。
15502网关错误。
16503服务不可用。
17504网关超时。

HTTP 测试工具

  • Postman: 非常好用
  • Linux curl 命令

CoAP - Constrained Application Protocol

一种专为受限环境和物联网设备设计的轻量级通信协议。它被设计用于在资源受限的网络中进行低带宽、低功耗的通信。
主要特性如下：

  • 在受限环境中满足机器对机器（M2M）需求的Web协议
  • 基于UDP [RFC0768] ，支持可选的可靠性，同时支持单播和组播请求。
  • 异步消息交换
  • 低报头开销和解析复杂性。
  • URI 和内容类型支持。
  • 简单的代理和缓存功能。
  • 无状态的 HTTP 映射，允许构建代理以一种统一的方式通过 HTTP 访问 CoAP 资源，或者通过 CoAP 实现简单的 HTTP 接口。
  • 安全绑定到数据报传输层安全性 (DTLS) [RFC6347]。

CoAP 和 HTTP 区别

  • CoAP 是面向网络的协议，使用类似于 HTTP 的特性，但也允许低开销、组播等。
  • 与基于HTTP的协议不同，CoAP 使用 UDP 而不是像 TCP 那样使用复杂的拥塞控制。
    如下图是分层对比图：
    img_coap_vs_http

CoAP 结构模型

img_coap_structure_model

  • 图中显示了 CoAP 采用了两层结构。
  • 底层是消息层，设计用于处理 UDP 和异步切换。
  • 请求/响应层涉及通信方法，并处理请求/响应消息。

CoAP 消息/Message层

  • 4种消息类型：

    消息类型数值描述
    Confirmable0可确认的消息，需要接收到确认响应。
    Non-confirmable1不需要确认的消息，发送后不期望接收到响应。
    Acknowledgment2确认消息的响应，用于确认接收到 Confirmable 消息。
    Reset3重置消息，用于表示对某个消息的不理睬或超时。

  • 可靠/不可靠消息传输

img_coap_message_layer_model

  • 可靠消息传输： 持续重传直至收到带有相同消息ID的确认消息（ACK）。当接收方完全无法处理CON消息时，会用RST替换ACK作为响应。
  • 不可靠消息传输： 不需要进行确认（ACK），但必须包含消息ID以便在重传时进行监控。当接收方无法处理NON消息时，可能会以RST作为回复。

CoAP 请求Request/响应Response层

img_coap_request_response_layer_model

  • Piggybacked response（承载式响应）： 当客户端发送一个带有确认请求标志（CON）或不带确认请求标志（NON）的消息时，如果服务器可以立即响应，则服务器可以将响应直接放在确认消息（ACK）中发送回客户端。这样的响应方式称为承载式响应，因为响应“搭载”在了确认消息中一起发送，节省了额外的网络往返时间。
  • Separate response（分离式响应）： 如果服务器不能立即响应客户端的请求，或者需要更长的时间来准备响应，服务器会先发送一个空的确认消息（ACK）给客户端，然后在准备好响应后，以一个新的确认消息（CON）的形式单独发送响应。这种响应方式称为分离式响应，因为响应和确认消息是分开发送的。

CoAP 消息/Message 格式

img_coap_message_format

  • 版本（Ver/Versionh）: CoAP版本，必须设置为 1，其他值保留给未来版本使用。
  • 类型（T/Type）: 消息类型，可为 Confirmable (0), Non-confirmable (1), Acknowledgement (2), 或 Reset (3)。
  • 令牌长度（TKL/Token Length）: 令牌字段的长度，最大为 8 字节。
  • 代码（Code）: 消息代码，格式为 “c.dd”，其中 c=0-6，dd=0-31。
  • 消息ID（Message ID）: 用于匹配类型的消息ID。
  • 令牌（Token）: 令牌值用于关联请求和响应。
  • 选项（Options）: 零个或多个选项。
  • 负载标记器（Payload Marker）: 0xFF。
  • 负载（Payload）: 负载数据从标记器后开始，延伸至UDP数据包的末尾。T

CoAP 智能家居的应用

img_coap_for_smarthome

CoAP 常用库

库名语言客/服务端支持描述链接
aiocoapPython 3Client + ServerBlockwise Transfers, Observe (partial)aiocoap
CaliforniumJavaClient + ServerObserve, Blockwise Transfers, DTLSCalifornium
cantcoapC++/CClient + Servercantcoap
CanopusGoClient + ServerCoreCanopus
CoAPSharpC#, .NETClient + ServerCore, Observe, Block, RDCoAPSharp
CoAPthonPythonClient + Server + Forward Proxy + Reverse ProxyObserve, Multicast server discovery, CoRE Link Format parsing, Block-wiseCoAPthon
CoAP ShellJavaClientObserve, Blockwise Transfers, DTLSCoAP Shell
CopperJavaScriptClientObserve, Blockwise TransfersCopper
eCoAPCClient + ServerCoreeCoAP
iCoAPObjective-CClientCore, Observe, Blockwise TransfersiCoAP
jCoAPJavaClient + ServerObserve, Blockwise TransfersjCoAP
libcoapCClient + ServerObserve, Blockwise Transfers, DTLSlibcoap
LibNyociCClient + ServerCore, Observe, Block, DTLSLibNyoci
lobaro-coapCClient + ServerObserve, Blockwise Transferslobaro-coap
microcoapCClient + Servermicrocoap
nCoapJavaClient + ServerObserve, Blockwise Transfers, CoRE Link Format, Endpoint-ID-DraftnCoap

WebSocket

  • WebSocket是一种在单个TCP连接上提供全双工通信的网络协议。
  • 它通过在客户端和服务器之间建立持久连接来实现双向通信，从而允许服务器实时地向客户端推送数据，而无需客户端发送请求。
  • WebSocket协议通过HTTP/HTTPS端口（80/443）与服务器进行握手，并在建立连接后使用自定义的WebSocket协议进行通信。
  • WebSocket通常用于实现实时的Web应用程序，如在线游戏、聊天应用程序、股票市场数据更新等。
  • 相比于传统的HTTP请求/响应模式，使得服务端可以主动通知客户端，具有更低的延迟和更高的效率，同时可以减少服务器和客户端之间的通信开销。

WebSocket 解决 HTTP 单向通信限制:

img_websocket_vs_http

WebSocket 解决 HTTP 服务端无法主动通知客户端:

img_websocket_vs_http_2

WebSocket 分层结构

img_websocket_layer_model

WebSocket 协议

  • WebSocket协议包括2部分：

    • 握手/Handshake
    • 数据传输/Data Tranfer

  • 握手/Handshake

    • 客户端请求：
      握手过程始于一个 HTTP 升级请求/响应。允许 HTTP 服务器与 WebSocket 网关或服务器共享它们的默认 HTTP 和 HTTPS 端口（80和443）。一旦连接建立，通信就会切换到 WebSocket 协议，该协议不符合 HTTP 协议。
      GET /chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== 
Sec-WebSocket-Protocol: chat, superchat 
Sec-WebSocket-Version: 13 
Origin: http://example.com
    • 服务端响应：
      HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= 
Sec-WebSocket-Protocol: chat
    • 请求URI： 标识WebSocket连接的端点。
    • 主机： 客户端和服务器都可以验证它们同意使用哪个主机。
    • Sec-WebSocket-Protocol： 指示客户端可接受哪些子协议（WebSocket协议之上的应用层协议）。
    • 来源： 通过WebSocket API在Web浏览器中的脚本保护WebSocket服务器免受未经授权的跨源使用。
    • Sec-WebSocket-Key/Sec-WebSocket-Accept： 这可以防止攻击者通过使用XMLHttpRequest或表单提交向WebSocke 服务器发送精心制作的数据包来欺骗WebSocket服务器。
    • 状态码： 除了101之外的其他代码表示WebSocket握手尚未完成，仍然适用HTTP的语义。
    • 关闭流程： 任一对等方都可以发送一个带有数据的控制帧，其中包含指定的控制序列，以开始关闭握手。收到这样的帧后，另一个对等方会发送一个Close帧作为响应。

Websocket URI说明

官方文档种定义两个URI方案，使用了ABNF语法（由[RFC5234]定义）和URI规范（由[RFC3986]定义）中定义的ABNF产生式。

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]host = <host, defined in [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3>
path = <path-abempty, defined in [RFC3986], Section 3.3>
query = <query, defined in [RFC3986], Section 3.4>
  • 端口组件是可选的；对于 “ws”，默认端口是 80，而对于 “wss”，默认端口是 443。
  • 如果方案组件不区分大小写地方 “wss” 匹配，则称 URI 为 “secure”。
  • 在 WebSocket URI 的上下文中，片段标识符是无意义的，不得在这些 URI 上使用。与任何 URI 方案一样，字符 “#” 在不表示片段起始时必须转义为 %23。

WebSocket 格式

img_websocket_base_framing
opcode：

  • %x0 ：继续帧/a continuation frame
  • %x1 ：文本帧/text frame
  • %x2 ：二进制帧/binary frame
  • %x3-7 ：保留/reserved
  • %x8 ：连接关闭帧/connection close
  • %x9 ：PING 帧/ping
  • %xA ：PONG 帧/pong
  • %xB-F ：保留/reserved
字段描述
FIN1=消息中的最后一个片段
RSV1, RSV2, RSV3非零=扩展
MASK定义 “Payload 数据” 是否masked/被掩码处理
Masking-key0 或 4 字节的长度
Payload length7 位、7+16 位或 7+64 位的长度
Payload扩展数据 + 应用数据

Websocket Mask/掩码处理

WebSocket掩码处理是WebSocket协议中的一项安全机制，用于在客户端和服务器之间传输数据时对数据进行混淆，以防止第三方窃取或篡改数据。

  • 所有从客户端发送到服务器的帧都将MASK位设置为1。
  • 它用于对与帧载荷数据在同一部分定义的“Payload data”进行掩码处理，其中包括“Extension data”和“Application data”。
  • 发送方（客户端）将数据按字节分割，并与掩码密钥的每个字节进行按位异或（XOR）运算。
  • 接收方（服务器）接收到数据后，使用相同的掩码密钥对数据进行解码，以还原原始数据。
  • 如下，转换后数据的第 i 个八位字节（“transformed-octet-i”）是原始数据的第 i 个八位字节（“original-octet-i”）与掩码密钥中第 i 个索引（模 4）的八位字节（“masking-key-octet-j”）进行异或运算的结果：
j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

WebSocket 实现库

img_websocket_implement_library

HTTP VS. Websocket

img_websocket_vs_http_3

HTTP 更适合的场景
  • 获取资源： 需要状态但不需要持续更新。如，获取页面，但不需要更新页面内容。
  • 可高度缓存的资源： 当资源变化不频繁或多个客户端会频繁请求相同资源时，资源从缓存种取，这样较少服务器负载，提高性能。
  • 幂等性和安全性： “幂等”即请求一次或多次都会产生相同的结果，请求重试或失败提高数据一致性。另一方面，POST和PUT于更新资源，需要身份验证和授权，确保安全性。
  • 错误场景： 标准的错误状态码机制
  • 同步事件： 客户端发送请求并等待服务器的响应。
WebSocket 更适合的场景
  • 快速反应时间
  • 持续更新
  • 即时通讯
  • 频繁通信与小负载

LWM2M

LWM2M是一种针对物联网设备设计的轻量级机器到机器通信协议，提供了高效的远程管理和通信能力，同时保持了低功耗和高安全性。这使得它成为物联网领域中的重要标准之一，广泛应用于各种物联网场景中。

  • 轻量级协议： LWM2M采用轻量级的通信协议，适用于资源受限的物联网设备，如嵌入式设备、传感器等。
  • 远程管理： LWM2M允许对物联网设备进行远程管理，包括配置、监视、更新和维护，提高了设备的灵活性和效率。
  • 资源模型： LWM2M使用资源模型描述设备功能和属性，基于RESTful原则，允许通过HTTP等协议对设备进行访问和操作。
  • 低功耗： 设计用于低功耗和有限网络带宽环境，具有高效的能源和网络资源利用率。
  • 安全性： 提供安全的通信机制，包括数据加密、身份验证和访问控制，确保设备之间的通信和管理安全可靠。

LWM2M总体架构

img_lwm2m_architecture
LWM2M 架构由 对象（Objects）、**接口（Interfaces）**和 **协议栈（Stack）**组成。

  1. 对象： 每个对象代表设备的一个功能或属性，如传感器、执行器等。对象由多个资源组成，描述设备的状态、配置和控制。
  2. 接口： 提供标准的方法与对象进行交互，包括读取资源、写入资源、观察资源变化等。
  3. 协议栈： 实现LWM2M协议的软件组件，处理通信、消息解析、设备管理等功能。

在LWM2M分层结构中：

  • UDP：为设备和服务器之间的通信
  • SMS：作为备用通信机制，用于发送警报、通知或命令。
  • DTLS：提供安全的数据传输，包括加密、身份验证和数据完整性保护。
  • CoAP：是LWM2M的下一层协议，作为基础通信协议，支持设备和服务器之间的轻量级、高效的通信和管理。

LWM2M 客户端/Client 引擎架构

img_lwm2m_client_engine_architecture

LWM2M对象模型

对象（Object）是最高级别的组织单位，每个对象代表了设备的一个功能或属性集合。每个对象由一个或多个资源（Resource）组成，资源表示对象的一个具体属性或功能。资源可以是只读的、可写的或可观察的，用于描述设备的状态、配置和控制。对象还可以包含一个或多个实例（Instance），实例用于区分具有相同功能的不同设备。

img_lwm2m_object_model_01

  • 对象/资源访问 URI： /{Object ID}/{Object Instance}/{Resource ID}，示例如下图：
    img_lwm2m_object_example

LWM2M 内部对象

  1. Security Object（安全对象）： 用于配置设备的安全性设置，包括用于DTLS握手的密钥和证书。
  2. Server Object（服务器对象）： 用于配置设备连接到的LWM2M服务器的参数，如服务器地址、端口和传输模式等。
  3. Access Control Object（访问控制对象）： 用于管理对设备资源的访问权限，包括读、写、执行和观察等操作。
  4. Device Object（设备对象）： 提供设备的基本信息和状态，如制造商、型号、固件版本等。
  5. Connectivity Monitoring Object（连接监控对象）： 用于监视设备的连接状态和网络参数，如信号强度、网络类型等。
  6. Firmware Object（固件对象）： 用于管理设备固件的更新和升级过程，包括下载、安装和验证等操作。
  7. Location Object（位置对象）： 提供设备的地理位置信息，包括经度、纬度、海拔等。
  8. Connectivity Statistics Object（连接统计对象）： 提供设备的连接统计信息，如连接时长、数据传输量等。

LWM2M 设备管理

img_lwm2m_device_management

LWM2M 应用场景示例

img_lwm2m_application_scenario

AMQP - Advanced Message Queuing Protocol

  • 一种可靠的消息传递协议，用于构建分布式系统和异步通信，提供灵活的消息模式和跨平台支持。
  • 它被广泛应用于金融、电信和物联网等领域，以实现高效的消息交换和异步处理。
  • 包括消息导向、消息队列、消息路由（包括点对点和发布-订阅）、可靠性和安全性。

生产消费模型如下：
img_amqp_producer_consumer_model

AMQP 整体架构

img_amqp_architecture

  1. Broker（代理）： 代理是消息队列系统中的中间件组件，负责接收、路由和传递消息。它充当消息的中转站，管理消息的存储和转发。
  2. Virtual Host（虚拟主机）： 虚拟主机是在消息代理中创建的逻辑消息服务环境。它允许多个应用程序共享同一个消息代理，每个虚拟主机都有自己的独立消息队列和交换机等资源。
  3. Connection（连接）： 连接是客户端与消息代理之间的通信通道，用于发送和接收消息。一个连接可以包含多个通道（channels），允许客户端并行发送和接收多个消息。
  4. Channel（通道）： 通道是在连接上创建的逻辑通信通道，用于在客户端和消息代理之间进行消息传递。通道可以看作是连接内的独立会话，允许客户端并行进行多个操作。
  5. Exchange（交换机）： 交换机是消息代理中的组件，负责接收来自生产者的消息，并根据预定的路由规则将消息路由到一个或多个队列中。它定义了消息的路由策略和目标队列。
  6. Queue（队列）： 队列是消息代理中用于存储消息的数据结构，它按照先进先出（FIFO）的原则处理消息。消费者从队列中获取消息，并对其进行处理。
  7. Binding（绑定）： 绑定是交换机和队列之间的关联关系，它定义了交换机如何将消息路由到队列。绑定通常使用路由键（routing key）来指定消息的路由规则，将满足条件的消息发送到相应的队列中。

AMQP交换机类型/AMQP Exchange Type

AMQP交换机的类型，用于定义消息的路由规则和行为。
AMQP定义了几种主要的交换机类型，每种类型都有不同的路由策略和行为，提供了不同的消息路由策略，允许开发者根据应用场景选择最适合的交换机类型来实现消息的路由和传递，如下图3种交换机类型：

img_amqp_exchange_type

  1. Direct Exchange（直连交换机）： 直连交换机将消息根据指定的路由键（routing key）发送到与之完全匹配的队列中。它适用于一对一的消息传递，消息将被发送到唯一的队列中。

  2. Fanout Exchange（广播交换机）： 广播交换机将消息发送到所有与之绑定的队列中，忽略路由键。它适用于一对多的消息广播，消息将被发送到所有绑定的队列中。

  3. Topic Exchange（主题交换机）： 主题交换机根据消息的路由键和交换机与队列之间的绑定规则将消息发送到匹配的队列中。它支持通配符匹配，可以根据路由键的模式匹配将消息发送到多个队列中。

  4. Headers Exchange（头交换机）： 头交换机根据消息的头部属性将消息发送到与之匹配的队列中。它不依赖于路由键，而是根据消息头部的属性进行匹配。

IoT 通信协议对比

ProtocolMQTTCoAPHTTPWebsocketAMQPXMPPDDSJMSM3DASTOMPSNMP
ArchitectureClient/ServerClient/ServerClient/ServerClient/ServerClient/ServerClient/Gateway/ServerClient/ServerClient/ServerClient/ServerClient/ServerClient/Server
ModelPublish/SubscribeRequest/ResponseRequest/ResponseN/AProducer/ConsumerPublish/SubscribePublish/SubscribePublish/SubscribeMessage/ResponseProducer/ConsumerAgent Mnanager
RelationshipMany-to-ManyOne-to-OneMany-to-OneOne-to-OneMany-to-ManyMany-to-ManyMany-to-ManyMany-to-ManyOne-to-OneMany-to-ManyMany-to-one
Transfer EfficiencyHighHighGeneralHighHighGeneralHighGeneralHighGeneralGeneral
Time-validityHighPoorPoorHighHighHighVery HighGeneralHighPoorGeneral
Power consumptionGeneralLowHighHighHighHighHighHighLowHighHigh
QoS SupportYesNoNoNoYesYesYesNoNoNoNo
Hard-Real-Time CapabilityNoNoNoNoNoNoYesNoNoNoNo
Coding WayBinaryBinaryText(XML/JSON)Binary/TextBinaryXMLBinaryBinaryBinaryText/BinaryASN.1
InteroperabilityPortionYesYesYesYesYesYesNoYesYesYes
2G, 3G, 4G Suitability
(1000s nodes)		ExcellentExcellentExcellentN/AExcellentExcellentN/AN/AN/AN/AN/A
LLN Suitability
(1000s nodes)		FairExcellentFairN/AFairFairN/AN/AN/AN/AN/A
Resource ConsumptionGeneralLowGeneralGeneralGeneralGeneralGeneralHighLowGeneralHigh
Long ConnectionYesNoNoYesYesYesN/AYesN/AYesNo
SecurityAccount/SSL/TLSDTLSSSL/TLSSSL/TLSSASL/SSL/TLSSSL/TLSSSL/TLSSSL/TLS/JAASSSL/TLS/DTLSSSL/TLSDTLS
TransportTCPUDP/SMSTCPTCPTCPTCPUDP/IPTCP(default)HTTP/TCP/UDP/SMSTCPUDP
IPIP6LoWPANIPIPIPIPIPIPIPIPIP
ImplementlibumqttlibcoapcurluWebSocketsOpenAMQOpenfireOpenDDSOpenJMSMihinilibstompnet-snmp
Implementmosquittomicrocoaphttpdws-rsRabbitMQglooxOpenSplice DDSmom4j

术语

  • N/A: Not Available - 不适用
  • QoS: Quality of Service - 服务质量
  • ASN.1: Abstract Syntax Notation dotone - 抽象语法表示法一
  • 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network - 低功耗无线个人区域网络上的IPv6
  • SSL: Secure Sockets Layer - 安全套接字层
  • TLS: Transport Layer Security - 传输层安全性
  • JAAS: Java Authentication and Authorization Service - Java身份验证和授权服务
  • SMS: Short Messaging Service - 短信服务
  • LLN: Line Link Network - 线路链路网络

这篇关于【001_IoT/物联网通信协议基础: HTTP、Websocket、MQTT、AMQP、COAP、LWM2M一文搞懂】的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/924061。

相关文章

【数据结构】——原来排序算法搞懂这些就行，轻松拿捏

【数据结构】——原来排序算法搞懂这些就行，轻松拿捏

前言：快速排序的实现最重要的是找基准值，下面让我们来了解如何实现找基准值 基准值的注释：在快排的过程中，每一次我们要取一个元素作为枢纽值，以这个数字来将序列划分为两部分。 在此我们采用三数取中法，也就是取左端、中间、右端三个数，然后进行排序，将中间数作为枢纽值。 快速排序实现主框架： //快速排序 void QuickSort(int* arr, int left, int rig
阅读更多...
零基础学习Redis(10) -- zset类型命令使用

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合，内部除了存储元素外，还会存储一个score，存储在zset中的元素会按照score的大小升序排列，不同元素的score可以重复，score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]
阅读更多...
BUUCTF靶场[web][极客大挑战 2019]Http、[HCTF 2018]admin

BUUCTF靶场[web][极客大挑战 2019]Http、[HCTF 2018]admin

目录   [web][极客大挑战 2019]Http 考点：Referer协议、UA协议、X-Forwarded-For协议 [web][HCTF 2018]admin 考点：弱密码字典爆破 四种方法：   [web][极客大挑战 2019]Http 考点：Referer协议、UA协议、X-Forwarded-For协议 访问环境 老规矩，我们先查看源代码
阅读更多...
【Linux 从基础到进阶】Ansible自动化运维工具使用

【Linux 从基础到进阶】Ansible自动化运维工具使用

Ansible自动化运维工具使用 Ansible 是一款开源的自动化运维工具，采用无代理架构（agentless），基于 SSH 连接进行管理，具有简单易用、灵活强大、可扩展性高等特点。它广泛用于服务器管理、应用部署、配置管理等任务。本文将介绍 Ansible 的安装、基本使用方法及一些实际运维场景中的应用，旨在帮助运维人员快速上手并熟练运用 Ansible。 1. Ansible的核心概念
阅读更多...
RabbitMQ练习（AMQP 0-9-1 Overview）

RabbitMQ练习（AMQP 0-9-1 Overview）

1、What is AMQP 0-9-1 AMQP 0-9-1（高级消息队列协议）是一种网络协议，它允许遵从该协议的客户端（Publisher或者Consumer）应用程序与遵从该协议的消息中间件代理（Broker，如RabbitMQ）进行通信。 AMQP 0-9-1模型的核心概念包括消息发布者（producers/publisher）、消息（messages）、交换机（exchanges）、
阅读更多...
AI基础 L9 Local Search II 局部搜索

AI基础 L9 Local Search II 局部搜索

Local Beam search 对于当前的所有k个状态，生成它们的所有可能后继状态。 检查生成的后继状态中是否有任何状态是解决方案。 如果所有后继状态都不是解决方案，则从所有后继状态中选择k个最佳状态。 当达到预设的迭代次数或满足某个终止条件时，算法停止。 — Choose k successors randomly, biased towards good ones — Close
阅读更多...
【Linux】应用层http协议

【Linux】应用层http协议

一、HTTP协议 1.1 简要介绍一下HTTP        我们在网络的应用层中可以自己定义协议，但是，已经有大佬定义了一些现成的，非常好用的应用层协议，供我们直接使用，HTTP（超文本传输协议）就是其中之一。        在互联网世界中，HTTP（超文本传输协议）是一个至关重要的协议，他定义了客户端（如浏览器）与服务器之间如何进行通信，以交换或者传输超文本（比如HTML文档）。
阅读更多...
如何确定 Go 语言中 HTTP 连接池的最佳参数？

如何确定 Go 语言中 HTTP 连接池的最佳参数？

确定 Go 语言中 HTTP 连接池的最佳参数可以通过以下几种方式： 一、分析应用场景和需求 并发请求量： 确定应用程序在特定时间段内可能同时发起的 HTTP 请求数量。如果并发请求量很高，需要设置较大的连接池参数以满足需求。例如，对于一个高并发的 Web 服务，可能同时有数百个请求在处理，此时需要较大的连接池大小。可以通过压力测试工具模拟高并发场景，观察系统在不同并发请求下的性能表现，从而
阅读更多...
音视频入门基础：WAV专题（10）——FFmpeg源码中计算WAV音频文件每个packet的pts、dts的实现

音视频入门基础：WAV专题（10）——FFmpeg源码中计算WAV音频文件每个packet的pts、dts的实现

一、引言 从文章《音视频入门基础：WAV专题（6）——通过FFprobe显示WAV音频文件每个数据包的信息》中我们可以知道，通过FFprobe命令可以打印WAV音频文件每个packet（也称为数据包或多媒体包）的信息，这些信息包含该packet的pts、dts： 打印出来的“pts”实际是AVPacket结构体中的成员变量pts，是以AVStream->time_base为单位的显
阅读更多...
C 语言基础之数组

C 语言基础之数组

文章目录 什么是数组数组变量的声明多维数组 什么是数组 数组，顾名思义，就是一组数。 假如班上有 30 个同学，让你编程统计每个人的分数，求最高分、最低分、平均分等。如果不知道数组，你只能这样写代码： int ZhangSan_score = 95;int LiSi_score = 90;......int LiuDong_score = 100;int Zhou
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2