【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/pingmian/1352.shtml

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

相关文章

20240421阿夏的CSDN创作纪念日（3周年）

20240421阿夏的CSDN创作纪念日（3周年）

缘 提示&#xff1a;可以和大家分享最初成为创作者的初心 3年前我写下第一篇CSDN&#xff0c;开启了Python研究之旅win10系统64位&#xff08; 惠普&#xff09;台式电脑自动开机、关机图文详细解&#xff08;一&#xff09;_惠普主板设置自动开机-CSDN博客文章浏览阅读4.2k次…
阅读更多...
深入OceanBase内部机制：资源隔离实现的方式总结

深入OceanBase内部机制：资源隔离实现的方式总结

码到三十五 &#xff1a; 个人主页 心中有诗画&#xff0c;指尖舞代码&#xff0c;目光览世界&#xff0c;步履越千山&#xff0c;人间尽值得 ! 目录 1. 为何HTAP需要资源隔离2. OceanBase的资源隔离机制概述租户间资源隔离租户内资源隔离物理资源隔离大查询请求的隔离优先级…
阅读更多...
4月21敲一篇猜数字游戏，封装函数，void，无限循环，快去体验体验

4月21敲一篇猜数字游戏，封装函数，void，无限循环，快去体验体验

今天敲一篇猜数字游戏 目录 今天敲一篇猜数字游戏 1.打开先学goto语句&#xff1a; 2.开干&#xff1a; 首次我们学习随机数&#xff1a; 讲解一下&#xff1a; 改用srand; 加入时间变量&#xff1a; 获取时间&#xff1a;哈​编辑 3.我本来想已近够完美了&#xff0…
阅读更多...
Flink学习（七）-单词统计

Flink学习（七）-单词统计

前言 Flink是流批一体的框架。因此既可以处理以流的方式处理&#xff0c;也可以按批次处理。 一、代码基础格式 //1st 设置执行环境 xxxEnvironment env xxxEnvironment.getEnvironment;//2nd 设置流 DataSource xxxDSenv.xxxx();//3rd 设置转换 Xxx transformation xxxDS.…
阅读更多...
Spring Boot中接收各种各样的参数

Spring Boot中接收各种各样的参数

一、接收json参数&#xff0c;封装为Map 1.1、核心代码 /*** 接收json参数&#xff0c;封装为Map* param servletRequest* return* throws Exception*/ PostMapping("/getParam") public R getParam(HttpServletRequest servletRequest) throws Exception {Map<…
阅读更多...
Bootstrap 5 保姆级教程（十二）：弹出框 消息弹窗

Bootstrap 5 保姆级教程（十二）：弹出框 消息弹窗

一、弹出框 1.1 创建弹出框 通过向元素添加 data-bs-toggle"popover" 来来创建弹出框。 title 属性的内容为弹出框的标题&#xff0c;data-bs-content 属性显示了弹出框的文本内容&#xff1a; 注意: 弹出框要写在 JavaScript 的初始化代码里。 以下实例可以在文…
阅读更多...
投入产出表的分析要点有哪些

投入产出表的分析要点有哪些

投入产出分析是利用投入产出表、投入产出系数和投入产出模型&#xff0c;对国民经济各部门之间的技术经济联系和影响进行分析的一种经济数据分析方法。 一、什么是投入产出表 我国的投入产出表是描述国民经济中各种产品的来源与使用去向的棋盘式平衡表 , 是产品部门 产品部门…
阅读更多...
【已解决】电脑设置notepad++默认打开txt

【已解决】电脑设置notepad++默认打开txt

1、以管理员的方式打开notepad 步骤&#xff1a;打开设置 -> 首选项 -> 文件关联 2、 设置Notepad默认打开 按照以下步骤将Notepad设置为默认打开.txt文件&#xff1a; 右键单击任何一个.txt文件。选择“属性”。在“常规”选项卡中&#xff0c;找到“打开方式”&#…
阅读更多...
【Interconnection Networks 互连网络】Dragonfly Topology 蜻蜓网络拓扑

【Interconnection Networks 互连网络】Dragonfly Topology 蜻蜓网络拓扑

蜻蜓拓扑 Dragonfly Topology 1. 拓扑参数2. Topology Description 拓扑描述3. Topology Variations 拓扑变体 蜻蜓拓扑 Dragonfly Topology 1. 拓扑参数 Dragonfly拓扑参数&#xff1a; N N N: 网络中终端(terminal)的总数量 p p p: 连接到每个路由器的终端数量 a a a: 每…
阅读更多...
VR全景：为户外游玩体验插上科技翅膀

VR全景：为户外游玩体验插上科技翅膀

随着VR全景技术的愈发成熟&#xff0c;无数人感到惊艳&#xff0c;也让各行各业看到了一片光明的发展前景。尤其是越来越多的文旅景区开始引入VR全景技术&#xff0c;相较于以往的静态风景图&#xff0c;显然现在的VR全景结合了动态图像和声音更加吸引人。 VR全景技术正在逐步改…
阅读更多...
Dijkstra算法求最短路

Dijkstra算法求最短路

Dijkstra算法可以在图中寻找一个节点&#xff08;称为“源节点”&#xff09;到所有其它节点的最短路径。 文章目录 前言 一、Dijkstra算法是什么&#xff1f; 二、问题介绍 三、朴素版Dijkstra算法 1.图的存储 2.算法实现 四、使用步骤 1.代码如下&#xff08;示例&#xff09…
阅读更多...
Linux的UDEV机制

Linux的UDEV机制

udev 机制引入&#xff1a; 手机接入Linux热拔插相关 a. 把手机接入开发板 b. 安装adb工具&#xff0c;在终端输入adb安装指令&#xff1a; sudo apt-get install adb c. dmeg能查看到手机接入的信息&#xff0c;但是输入adb devices会出现提醒 dinsufficient permissions for …
阅读更多...
【Java】HashMap、HashTable和ConcurrentHashMap的区别

【Java】HashMap、HashTable和ConcurrentHashMap的区别

文章目录 区别一、HashMap1.1基本定义与特性1.2工作原理与实现1.3常用方法1.4性能与优化 二、HashTable三、ConcurrentHashMap3.1基本特点3.2实现原理3.3常用方法3.4适用场景3.5性能优化 HashTable、HashMap和ConcurrentHashMap之间的区别主要体现在线程安全、继承关系与实现接…
阅读更多...
kaggle 泰坦尼克号2 得分0.7799

kaggle 泰坦尼克号2 得分0.7799

流程 导入所要使用的包引入kaggle的数据集csv文件查看数据集有无空值填充这些空值提取特征分离训练集和测试集调用模型 导入需要的包 import pandas as pd import numpy as np import matplotlib.pyplot as plt import seaborn as sns import warnings warnings.filterwarni…
阅读更多...
从C到JAVA之学习JAVA的第一周笔记

从C到JAVA之学习JAVA的第一周笔记

文章目录 java语言概述JDK与JRE编写执行过程第一份java代码解读编写编译运行其他 注释三种注释方法 java API文档关键字标识符数据类型基本数据类型自动类型提升规则引用数据类型 string概述String与基本数据类型的变量间的运算 运算符键盘录入运行控制语句数组定义与静态初始化…
阅读更多...
springboot no mapping for.....解决办法

springboot no mapping for.....解决办法

这个问题是由于没有加入对应的GET,POST注解&#xff0c;导致映射失败&#xff0c;加入对应注解就ok了
阅读更多...
JDK 11下载、安装、配置

JDK 11下载、安装、配置

下载 到Oracle管网下载JDK 11&#xff0c;下载前需要登录&#xff0c;否则直接点下载会出现502 bad gateway。 下载页面链接 https://www.oracle.com/hk/java/technologies/downloads/#java11-windows 登录 有些人可能没有Oracle账号&#xff0c;注册也比较慢&#xff0c;有需…
阅读更多...
随笔05 我的创作纪念日（512天）

随笔05 我的创作纪念日（512天）

机缘 机缘这事儿&#xff0c;我在随笔系列博文里已经翻来覆去说了不少&#xff0c;这次就不再唠叨了&#xff0c;省得被小伙伴嫌弃成祥林嫂~&#x1f61c; &#x1f338;随笔01 我的创作纪念日&#xff08;128天&#xff09;_newmitbbs-CSDN博客 收获 我这一小片自留地&…
阅读更多...
JavaEE 初阶篇-深入了解 File 文件操作（实现文件搜索、非空文件夹删除）

JavaEE 初阶篇-深入了解 File 文件操作（实现文件搜索、非空文件夹删除）

&#x1f525;博客主页&#xff1a; 【小扳_-CSDN博客】 ❤感谢大家点赞&#x1f44d;收藏⭐评论✍ 文章目录 1.0 File 文件概述 2.0 创建 File 类对象的方法 2.1 判断文件类型、获取文件信息的方法 2.2 创建文件、删除文件的方法 2.3 遍历文件夹的方法 3.0 文件搜索与删除 3.1…
阅读更多...
WebSocket 快速入门 - springboo聊天功能

WebSocket 快速入门 - springboo聊天功能

目录 一、概述 1、HTTP&#xff08;超文本传输协议&#xff09; 2、轮询和长轮询 3、WebSocket 二、WebSocket快速使用 1、基于Java注解实现WebSocket服务器端 2、JS前端测试 三、WebSocket进阶使用 1、如何获取当前用户信息 2、 后端聊天功能实现 一、概述 HTTP…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023