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

news2024/11/15 15:33:21

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.coloradmin.cn/o/1612588.html

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

相关文章

Swift-20-基础数据类型

Swift-20-基础数据类型

数据定义 语法规则 先来看下下面的代码 import Cocoavar num1 "four" //a var num2: String "four" //b var num3 4 //c var num4: Int 4 //d上面的几行代码都能正常运行&#xff0c;其中a和b行等价&#xff0c;c和d行等价。区另就在于是否声…
阅读更多...
docker-compose 安装MongoDB续：创建用户及赋权

docker-compose 安装MongoDB续：创建用户及赋权

文章目录 1. 问题描述2. 分析2.1 admin2.2 config2.3 local 3. 如何连接3.解决 1. 问题描述 在这一篇使用docker-compose创建MongoDB环境的笔记里&#xff0c;我们创建了数据库&#xff0c;但是似乎没有办法使用如Robo 3T这样的工具去连接数据库。连接的时候会返回这样的错误&…
阅读更多...
关系抽取与属性补全

关系抽取与属性补全

文章目录 实体关系抽取的任务定义机器学习框架属性补全 实体关系抽取的任务定义 从文本中抽取出两个或者多个实体之间的语义关系&#xff1b;从文本获取知识图谱三元组的主要技术手段&#xff0c;通常被用于知识图谱的补全。美丽的西湖坐落于浙江省的省会城市杭州的西南面。&am…
阅读更多...
IDEA中SVN 的使用

IDEA中SVN 的使用

文章目录 前言一、svn安装二、IDEA集成SVN总结 前言 svn可以老牌的代码仓库了 说实话svn还是和git无法相比的,毕竟git有本地仓库的概念,可以很好的处理冲突,然而svn是没有本地仓库的概念的,所以只能拉取别人的代码,然后处理冲突后,才能提交代码; 由于最近的工作换成了用svn仓…
阅读更多...
el-menu 有一级二级三级菜单

el-menu 有一级二级三级菜单

效果如下 菜单代码如下 <el-menu:default-active"menuDefaultActive"class"el-menu-box":text-color"menuTextColor":active-text-color"menuActiveTextColor":unique-opened"true"><!-- 一级菜单 --><tem…
阅读更多...
线程池的核心参数有哪些？？？

线程池的核心参数有哪些？？？

线程池的核心参数包括以下七个&#xff1a; corePoolSize&#xff1a; 这是线程池中的核心线程数&#xff0c;即池中会保留的最少线程数。当提交任务时&#xff0c;如果当前线程数小于核心线程数&#xff0c;线程池会创建新的线程来执行任务。如果当前线程数等于或大于核心线程…
阅读更多...
Docker - 简介

Docker - 简介

原文地址&#xff0c;使用效果更佳&#xff01; Docker - 简介 | CoderMast编程桅杆https://www.codermast.com/dev-tools/docker/docker-introduce.html Docker是什么&#xff1f; Docker 是一个开源的应用容器引擎&#xff0c;基于 Go 语言 并遵从 Apache2.0 协议开源。 D…
阅读更多...
css-Echarts图表初始显示异常非完全显示

css-Echarts图表初始显示异常非完全显示

1.echarts图表初始加载异常 2.问题原因 初次加载时&#xff0c;由于外层使用%比 echarts dom元素没有完全加载完成&#xff0c;canvas绘画继承本身宽高&#xff0c;造成Echarts图表初始显示异常非完全显示。 3.使用echarts图表可参考以下代码&#xff08;实现一定的自适应&am…
阅读更多...
stm32开发之threadx+emwin+awizard使用记录

stm32开发之threadx+emwin+awizard使用记录

前言 图形化开发界面选择(awizard)emwin使用的版本是6.10芯片采用的是stm32f407zgt6这里使用的开发板是普中麒麟f4系列的 lcd驱动文件&#xff08;基于提供的源码修改&#xff09; 1、这里是剔除了很多兼容其他显示屏部分的代码&#xff0c;只保留具体信号的代码,把一些全局…
阅读更多...
Java实现AVL树

Java实现AVL树

AVI树 如果一颗二叉搜索树不平衡,那么搜索效率会受影响 二叉搜索树如果不是这种不平衡的情况,时间复杂度可以达到O(logn) 但是像图中的这种不平衡情况时间复杂度为O(n),那么如何解决呢? 可以通过旋转解决 旋转之后并不会破坏二叉搜索树的特性 判断是否平衡有一个规则:如果一…
阅读更多...
如何进行景气分析

如何进行景气分析

景气分析是一种短期经济分析方法。主要分析短时间内&#xff08;一般指一年内&#xff0c; 或几个月内&#xff09;经济运行的态势&#xff0c;包括当前的状态和未来的趋势。景气分析可以为宏观经济政策提供重要的决策与参考信息&#xff0c;例如根据经济运行的方向、强弱可建议…
阅读更多...
【AI开发：音频】二、GPT-SoVITS使用方法和过程中出现的问题（GPU版）

【AI开发：音频】二、GPT-SoVITS使用方法和过程中出现的问题（GPU版）

1.FileNotFoundError: [Errno 2] No such file or directory: logs/guanshenxxx/2-name2text-0.txt 这个问题中包含了两个&#xff1a; 第一个&#xff1a;No module named pyopenjtalk 我的电脑出现的就是这个 解决&#xff1a;pip install pyopenjtalk 第二个&#xff1a…
阅读更多...
数据结构练习-数据结构概述

数据结构练习-数据结构概述

----------------------------------------------------------------------------------------------------------------------------- 1. 在数据结构中&#xff0c;从逻辑上可以把数据结构分成( )。 A. 动态结构和静态结构 B. 紧凑结构和非紧凑结构 C. 线性结…
阅读更多...
初识ansible变量及实例配置

初识ansible变量及实例配置

目录 1、为什么要使用变量 2、变量分类 3、 变量详解 3.1 vars,vars_files , group_vars 3.1 .1 vars 剧本中定义变量 3.1.2 vars_file 将变量存放到一个文件中&#xff0c;并在剧本中引用 3.1.3 group_vars 创建一个变量文件给某个组使用 实例1-根据不同的主机…
阅读更多...
CGLIB动态代理

CGLIB动态代理

文章目录 前言概要SpringBoot中使用小结 前言 当我们需要在Java中实现动态代理时&#xff0c;通常会考虑使用 JDK原生动态代理 或者 CGLIB动态代理。 我这里说一下CGLIB动态代理&#xff0c;并给出一个例子。 概要 CGLIB&#xff08;Code Generation Library&#xff09;是一…
阅读更多...
无损以太网的ROCE革命，队列的缓存空间优化分析

无损以太网的ROCE革命，队列的缓存空间优化分析

ROCE无损以太网&#xff0c;队列的缓存空间优化 多级缓存架构优化芯片性能&#xff1a;* 缓存空间细分为芯片级、端口级和队列级&#xff0c;实现精细管理。* 无损队列引入Headroom缓存空间&#xff0c;确保数据完整性。 在芯片层面&#xff1a; 静态缓存为端口提供保证的缓存空…
阅读更多...
RHCE：网络服务综合项目

RHCE：网络服务综合项目

基础配置&#xff1a; 1.配置主机名&#xff0c;静态IP地址 2.开启防火墙并配置 3.部分开启SElinux并配置 4.服务器之间使用同ntp.aliyun.com进行时间同步 5.服务器之间实现SSH免密登录 业务需求&#xff1a; 1.Server-NFS-DNS主机配置NFS服务器&#xff0c;将博客网…
阅读更多...
智慧园区引领未来产业趋势：科技创新驱动园区发展，构建智慧化产业新体系

智慧园区引领未来产业趋势：科技创新驱动园区发展，构建智慧化产业新体系

目录 一、引言 二、智慧园区引领未来产业趋势 1、产业集聚与协同发展 2、智能化生产与服务 3、绿色可持续发展 三、科技创新驱动园区发展 1、创新资源的集聚与整合 2、创新成果的转化与应用 3、创新文化的培育与弘扬 四、构建智慧化产业新体系 1、优化产业布局与结构…
阅读更多...
5.SpringBoot 配置文件

5.SpringBoot 配置文件

文章目录 1.配置文件作用2.配置文件格式2.1项目中同时存在两种配置文件2.2application.properties2.2.1 application.properties语法格式2.2.2获取自定义配置项 2.3 application.yml2.3.1 application.yml语法格式2.3.1.1单双引号区别2.3.1.2和application.properties格式对比&…
阅读更多...
安全狗云眼的主要功能有哪些？

安全狗云眼的主要功能有哪些？

"安全狗云眼"是一款综合性的网络安全产品&#xff0c;主要用于实时监控和保护企业的网络安全。其核心功能包括威胁检测、漏洞扫描、日志管理和合规性检查等。 以下是安全狗云眼的主要功能详细介绍&#xff1a; 1、资产管理 定期获取并记录主机上的Web站点、Web容器、…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023