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 - 线路链路网络

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/816624.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

在MOS管栅极前加100Ω电阻，有啥妙用

在MOS管栅极前加100Ω电阻，有啥妙用

我们经常会听到在MOSFET栅极前增加一个电阻。那么&#xff0c;为什么要增加这个电阻&#xff0c;进一步地来讲&#xff0c;为什么要增加一个100Ω电阻&#xff1f; 在MOSFET的栅极前增加一个电阻&#xff1f; MOS管是电压型控制器件&#xff0c;一般情况下MOS管的导通&#x…
阅读更多...
基于ollama搭建本地chatGPT

基于ollama搭建本地chatGPT

ollama帮助我们可以快速在本地运行一个大模型&#xff0c;再整合一个可视化页面就能构建一个chatGPT&#xff0c;可视化页面我选择了chat-ollama&#xff08;因为它还能支持知识库&#xff0c;可玩性更高&#xff09;&#xff0c;如果只是为了聊天更推荐chatbox 部署步骤 下载…
阅读更多...
unity记一下如何播放动画

unity记一下如何播放动画

我使用的版本是2022.3.14fc 展开你的模型树&#xff0c;是会出现这个三角形的东西的 然后在资源面板创建一个animation controller 进去之后&#xff0c;把三角形拖进去&#xff0c;就会出现一个动画&#xff0c;然后点击他 在左侧给他创建这么个状态名字&#xff0c;类型…
阅读更多...
(一)基于IDEA的JAVA基础15

(一)基于IDEA的JAVA基础15

还是先来说一下: Arrays工具类 Arrays是java.util包提供的工具类 提供了操作数组的方法&#xff0c;如排序,查询等。 如排序(升序)使用sort方法 语法: Arrays.sort(数组名)&#xff1b; 还是直接写来看看: public class Test01 { public static void main(String[] args)…
阅读更多...
Swagger API 文档 | SpringBoot 3.x 集成 SpringDoc

Swagger API 文档 | SpringBoot 3.x 集成 SpringDoc

文章目录 常规方式第 1 步：添加依赖第 2 步：配置 API 信息及全局参数配置 OpenAPI 文档配置单个 OpenAPI 文档 - 方式 1配置单个 OpenAPI 文档 - 方式 2配置多个 OpenAPI 文档其它 SpringDoc 及 Swagger-UI 配置第 3 步：添加 Swagger3 注解Swagger2 和 Swagger3 注解对应关系…
阅读更多...
云服务器web环境之mariadb

云服务器web环境之mariadb

1.安装mariadb服务 yum install mariadb-server 启动mariadb服务 systemctl start mariadb.service 输入mysql就能使用数据库了。 2.服务相关操作 systemctl stop mariadb.service systemctl restart mariadb.service 2.配置开机自启动 systemctl enable mariadb.serv…
阅读更多...
vue快速入门（二十四）输入停顿再进行响应

vue快速入门（二十四）输入停顿再进行响应

注释很详细&#xff0c;直接上代码 上一篇 新增内容 使用侦听器监视数据变化情况使用clearTimeout与定时器实现停顿一段时间再操作内容 源码 <!DOCTYPE html> <html lang"en"><head><meta charset"UTF-8"><meta name"view…
阅读更多...
64B/66B GT Transceiver 配置

64B/66B GT Transceiver 配置

一、前言 前一篇文章已经讲述了64B/66B的编码原理&#xff0c;此篇文章来配置一下7系列GT的64B/66B编码。并讲述所对应的例子工程的架构&#xff0c;以及部分代码的含义。 二、IP核配置 1、打开7 Series FPGAs Transceiver Wizards&#xff0c;选择将共享逻辑放置在example …
阅读更多...
使用DockerCompose安装Redis

使用DockerCompose安装Redis

本文使用docker-compose的方式安装Redis&#xff0c;如何未安装docker-compose&#xff0c;可以参考这篇文章进行安装【在Ubuntu上安装Docker Compose】 一、创建一个DockerCompose配置文件 第一步&#xff1a;创建相关目录文件 为了更好的组织管理Docker容器的配置文件和映射…
阅读更多...
5G网络开通与调测ipv4

5G网络开通与调测ipv4

要求如下&#xff1a; 1. 勘站规划 1. 【重】首先观察NR频点&#xff0c;完成设备选型 2645--选择N41 3455--选择N78 4725--选择N79 设备选型如下&#xff1a;观察AAU的通道数&#xff0c;最大发射功率&#xff1b;选择N41的选型频段也要选41 2. …
阅读更多...
【MATLAB源码-第189期】基于matlab的人工蜂群优化算法(ABC)无人机三维路径规划，输出做短路径图和适应度曲线

【MATLAB源码-第189期】基于matlab的人工蜂群优化算法(ABC)无人机三维路径规划，输出做短路径图和适应度曲线

操作环境&#xff1a; MATLAB 2022a 1、算法描述 Artificial Bee Colony&#xff08;ABC&#xff09;算法是一种模仿蜜蜂觅食行为的优化算法&#xff0c;它通过模拟蜜蜂群体的社会结构和行为来解决数学优化问题。本文将详细介绍ABC算法的基本原理、算法流程、以及在实际应用…
阅读更多...
代理模式（结构型模式）

代理模式（结构型模式）

目录 1、概述 2、结构 2.1、角色分类 2.2、类图 3、静态代理 3.1、案例类图 3.2、案例代码 4、JDK 动态代理 4.1、案例代码 4.2、底层原理 4.3、执行流程说明 5、CGLib 动态代理 5.1、案例代码 6、三种代理的对比 6.1、JDK代理和CGLib代理 6.2、动态代理和静态…
阅读更多...
matlab学习（三）（4.9-4.15）

matlab学习（三）（4.9-4.15）

一、空域里LSB算法的原理 1.原理&#xff1a; LSB算法通过替换图像像素的最低位来嵌入信息。这些被替换的LSB序列可以是需要加入的水印信息、水印的数字摘要或者由水印生成的伪随机序列。 2.实现步骤&#xff1a; &#xff08;1&#xff09;将图像文件中的所有像素点以RGB形…
阅读更多...
【C语言】每日一题，快速提升（1）！

【C语言】每日一题，快速提升（1）！

调整数组使奇数全部都位于偶数前面 题目&#xff1a; 输入一个整数数组&#xff0c;实现一个函数 来调整该数组中数字的顺序使得数组中所有的奇数位于数组的前半部分 所有偶数位于数组的后半部分 解题思路&#xff1a; 给定两个下标left和right&#xff0c;left放在数组的起始…
阅读更多...
Web端Excel的导入导出Demo

Web端Excel的导入导出Demo

&#x1f4da;目录 &#x1f4da;简介:✨代码的构建&#xff1a;&#x1f4ad;Web端接口Excel操作&#x1f680;下载接口&#x1f680;导入读取数据接口 &#x1f3e1;本地Excel文件操作⚡导出数据&#x1f308;导入读取数据 &#x1f4da;简介: 使用阿里巴巴开源组件Easy Exce…
阅读更多...
软考中级工程师网络技术第二节网络体系结构

软考中级工程师网络技术第二节网络体系结构

OSPF将路由器连接的物理网络划分为以下4种类型&#xff0c;以太网属于&#xff08;25&#xff09;&#xff0c;X.25分组交换网属于&#xff08;非广播多址网络NBMA&#xff09;。 A 点对点网络 B 广播多址网络 C 点到多点网络 D 非广播多址网络 试题答案 正确答案&#xff1a; …
阅读更多...
【鸿蒙开发】第二十一章 Media媒体服务（二）--- 音频播放和录制

【鸿蒙开发】第二十一章 Media媒体服务（二）--- 音频播放和录制

1 AVPlayer音频播放 使用AVPlayer可以实现端到端播放原始媒体资源&#xff0c;本开发指导将以完整地播放一首音乐作为示例&#xff0c;向开发者讲解AVPlayer音频播放相关功能。 以下指导仅介绍如何实现媒体资源播放&#xff0c;如果要实现后台播放或熄屏播放&#xff0c;需要…
阅读更多...
Java使用OpenOffice将office文件转换为PDF

Java使用OpenOffice将office文件转换为PDF

Java使用OpenOffice将office文件转换为PDF 1. 先行工作1.1 OpenOffice官网下载1.2 JODConverter官网下载1.3 下载内容 2.介绍3. 安装OpenOffice服务3.1.Windows环境3.2 Linux环境 4. maven依赖5. 转换代码 1. 先行工作 请注意&#xff0c;无论是windows还是liunx环境都需要安装…
阅读更多...
Flutter - iOS 开发者速成篇

Flutter - iOS 开发者速成篇

首先 安装FLutter开发环境&#xff1a;M1 Flutter SDK的安装和环境配置 然后了解Flutter和Dart 开源电子书&#xff1a;Flutter实战 将第一章初略看一下&#xff0c;你就大概了解一下Flutter和Dart这门语言 开始学习Dart语言 作为有iOS经验的兄弟们&#xff0c;学习Dart最快…
阅读更多...
C# dynamic 数据类型

C# dynamic 数据类型

在C#中&#xff0c;dynamic是一种数据类型&#xff0c;它允许在运行时推迟类型检查和绑定。使用dynamic类型&#xff0c;可以编写更具灵活性的代码&#xff0c;因为它允许在编译时不指定变量的类型&#xff0c;而是在运行时根据实际情况进行解析。 dynamic类型的变量可以存储任…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023