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四层模型
如图，左边为 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）
如图，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连接协议
- 极轻量级的发布/订阅消息传输
- 小型代码，网络带宽非常有限
- 卫星链路、拨号上网、家庭自动化和小型设备场景
- 小尺寸、低功耗、数据包尺寸最小化
如图，在MQTT协议中，有三个重要的角色：发布者（Publisher）、代理（Broker） 和 订阅者（Subscriber）。
-
发布者（Publisher）
发布者是MQTT网络中的客户端，负责发布（发送）消息到MQTT代理（Broker）。发布者将消息发送到一个或多个主题（Topic），并且可以选择消息的服务质量级别（QoS）。
-
代理（Broker）
代理是MQTT网络中的中介，负责接收发布者发布的消息，并将其传递给订阅者。它负责维护订阅者与发布者之间的关系，处理订阅和取消订阅的请求，并确保消息按照订阅者的需求进行传递。
-
订阅者（Subscriber）
订阅者是MQTT网络中的客户端，负责订阅（接收）一个或多个主题（Topic）的消息。订阅者告知代理它感兴趣的主题，然后代理在有新消息发布时将其传递给订阅者。
MQTT 数据包格式
-
固定头部（Fixed Header）：
位 字段 描述 0-3 控制报文类型 指示数据包的类型，如CONNECT、PUBLISH等。 4 DUP 指示消息是否是重发的副本。 5-6 QoS 指示消息的服务质量级别。 7 RETAIN 指示代理是否应保留已发布的消息。 8+ 剩余长度（RL） ① 编码剩余长度字段，表示可变头部和有效载荷的总长度。
最多可以使用4个字节来编码长度字段。
② 最高位为0表示剩余长度的编码结束，
7个比特位用于表示长度的最低7位。
③ 每个字节的最高位为1，
表示后续还有剩余长度字段，
剩下的7个比特位用于表示长度的下一个字节。
④ MAX=268435455 (0xFF, 0xFF, 0xFF, 0x7F)。- 控制报文类型，如下表所示:
控制报文类型 值 描述 Reserved 0 保留，不使用。 CONNECT 1 客户端请求连接到代理。 CONNACK 2 代理对 CONNECT 请求的响应。 PUBLISH 3 发布消息到指定主题。 PUBACK 4 对 QoS 1 的 PUBLISH 报文的确认。 PUBREC 5 对 QoS 2 的 PUBLISH 报文的接收。 PUBREL 6 对 QoS 2 的 PUBLISH 报文的释放。 PUBCOMP 7 对 QoS 2 的 PUBLISH 报文的完成。 SUBSCRIBE 8 订阅一个或多个主题。 SUBACK 9 对 SUBSCRIBE 报文的确认。 UNSUBSCRIBE 10 取消订阅一个或多个主题。 UNSUBACK 11 对 UNSUBSCRIBE 报文的确认。 PINGREQ 12 客户端发送心跳请求。 PINGRESP 13 代理对 PINGREQ 请求的响应。 DISCONNECT 14 客户端主动断开连接。 Reserved 15 保留，不使用。 - QoS， 如下表所示：
QoS 值 描述 0 0 最多一次传输（At most once）：消息可能丢失。 1 1 至少一次传输（At least once）：消息至少被传输一次，但可能会重复。 2 2 有且仅有一次传输（Exactly once）：确保消息仅被传输一次。
- 控制报文类型，如下表所示:
-
可变头部（Variable Header）：
-
根据报文类型的不同，可变头部的内容也不同（不是所有的类型都有可变头）。例如，CONNECT 报文的可变头部包含协议版本号、连接标志等。具体如下表所示:
可变头部的数据包标识符字段在几种数据包类型中是共同存在的，具体是否存在，如下表:
-
-
有效载荷（Payload）：Payload 数据段是 MQTT 数据包中实际传输的部分，它是实现 MQTT 消息传输的核心。
- 数据包是否有payload，如下表所示:
- 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.9 | RFC 1945 | 1990 | - 最初的版本，只支持 GET 方法 - 响应内容是 HTML 格式 |
| HTTP/1.0 | RFC 2068 | 1996 | - 引入了请求头和响应头 - 支持更多的请求方法和状态码 |
| HTTP/1.1 | RFC 2616 RFC 7230-7235 | 1997 2014 | - 当前互联网使用最广 - 引入持久连接，提高性能 - 支持管道化，允许并行发送多个请求 - 引入 Host 头字段，支持虚拟主机 - 协议参考这里 |
| HTTP/2 | RFC 7540 | 2015 | - 使用二进制格式进行传输，减少了传输的开销 - 引入了头部压缩机制，减少了头部的大小 - 支持多路复用，允许在单个连接上发送多个请求和响应 |
| HTTP/3 | RFC 9114 | 2019 | - 基于 QUIC 协议，提供更快的连接建立和数据传输 - 改善了性能和安全性，减少了网络延迟 |
HTTP消息格式
| 消息格式 | 说明 |
|---|---|
| 起始行/请求行/状态行 | 包含协议版本、状态码和状态消息（对于响应消息） 请求方法、请求URI和协议版本（对于请求消息）。 |
| 0或多个请求头 | 包含一系列键值对，每个键值对描述了消息的一些信息，如Content-Type、Content-Length等。每个键值对以冒号分隔，键值对之间以换行符分隔。 |
| 空行 | 用于分隔请求头和消息体，通常只包含一个换行符，表示请求头结束。 |
| 可选消息体 | 包含具体的消息内容，如POST请求中的表单数据或服务器返回的HTML页面内容。对于GET请求，通常没有消息体。 |
| 空行 | 表示消息体的结束，后面没有其他内容。 |
具体消息格式如下图所示：
HTTP 常用请求方法
| 序号 | 请求方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的资源。 |
| 2 | POST | 向指定的资源提交数据进行处理请求（例如提交表单或上传文件）。 |
| 3 | PUT | 请求服务器存储一个资源，并用请求的数据替换指定的资源。 |
| 4 | DELETE | 请求服务器删除指定的资源。 |
| 5 | HEAD | 类似于GET请求，但服务器只返回请求头，不返回请求体。 |
| 6 | PATCH | 请求服务器对资源进行部分修改。 |
| 7 | OPTIONS | 请求查询服务器支持的HTTP请求方法和其他特性，在跨域请求的时候，在调用其它方法前，会调用此方法。 |
| 8 | TRACE | 用于测试远程服务器的性能。 |
HTTP 常用请求头
| 序号 | 请求头 | 描述 |
|---|---|---|
| 1 | User-Agent | 客户端标识，包含了客户端的软件类型、操作系统、软件版本等信息。 |
| 2 | Accept | 告诉服务器客户端能够处理的媒体类型和媒体类型的相对优先级。 |
| 3 | Content-Type | 请求或响应的实体的媒体类型。 |
| 4 | Content-Length | 请求或响应实体的长度（以字节为单位）。 |
| 5 | Host | 表示服务器的主机名和端口号。 |
| 6 | Cookie | 客户端向服务器发送的Cookie信息。 |
| 7 | Cache-Control | 控制缓存行为的指令，如no-cache、max-age等。 |
| 8 | Accept-Encoding | 告诉服务器客户端能够解码的编码方式。 |
| 9 | Accept-Language | 告诉服务器客户端偏好的自然语言。 |
| 10 | Referer | 表示请求的来源，即前一个页面的URL。 |
| 11 | Authorization | 包含客户端提供给服务器的身份验证凭证。 |
| 12 | Origin | 请求的来源，用于跨域请求。 |
| 13 | Connection | 控制是否保持连接，如keep-alive、close等。 |
| 14 | If-Modified-Since | 如果资源自指定日期以来没有被修改，则发送请求。 |
| 15 | If-None-Match | 如果资源与指定的ETag匹配，则发送请求。 |
HTTP 常用响应头
| 序号 | 响应头 | 描述 |
|---|---|---|
| 1 | Content-Type | 响应的实体的媒体类型。 |
| 2 | Content-Length | 响应实体的长度（以字节为单位）。 |
| 3 | Cache-Control | 控制缓存行为的指令，如no-cache、max-age等。 |
| 4 | Content-Encoding | 响应实体的编码方式，如gzip、deflate等。 |
| 5 | Server | 表示响应的服务器软件类型和版本号。 |
| 6 | Last-Modified | 表示响应实体的最后修改时间。 |
| 7 | Location | 重定向时新的URL。 |
| 8 | Set-Cookie | 服务器向客户端设置的Cookie信息。 |
| 9 | Expires | 表示响应的过期时间。 |
| 10 | ETag | 资源的唯一标识，用于缓存控制。 |
| 11 | Content-Disposition | 响应实体的处理方式，如inline、attachment等。 |
| 12 | Access-Control-Allow-Origin | 指定响应可以被哪些域访问。 |
| 13 | Access-Control-Allow-Headers | 指定响应可以被哪些请求头访问。 |
| 14 | Access-Control-Allow-Methods | 指定响应可以支持哪些HTTP方法。 |
| 15 | Access-Control-Allow-Credentials | 指定响应中是否包含凭证信息。 |
HTTP 常用返回码
| 序号 | 状态码 | 描述 |
|---|---|---|
| 1 | 100 | 继续。客户端应继续其请求。 |
| 2 | 101 | 切换协议。服务器正在协商切换协议。 |
| 3 | 200 | 请求成功。 |
| 4 | 201 | 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立。 |
| 5 | 204 | 服务器成功处理了请求，但不需要返回任何实体内容。 |
| 6 | 301 | 永久性重定向。 |
| 7 | 302 | 临时性重定向。 |
| 8 | 304 | 资源未修改，客户端可使用缓存数据。 |
| 9 | 400 | 请求参数有误。 |
| 10 | 401 | 需要身份验证。 |
| 11 | 403 | 服务器拒绝请求。 |
| 12 | 404 | 请求的资源不存在。 |
| 13 | 405 | 请求方法不被允许。 |
| 14 | 500 | 服务器内部错误。 |
| 15 | 502 | 网关错误。 |
| 16 | 503 | 服务不可用。 |
| 17 | 504 | 网关超时。 |
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那样使用复杂的拥塞控制。
如下图是分层对比图：
CoAP 结构模型
- 图中显示了
CoAP采用了两层结构。 - 底层是消息层，设计用于处理
UDP和异步切换。 - 请求/响应层涉及通信方法，并处理请求/响应消息。
CoAP 消息/Message层
-
4种消息类型：
消息类型 数值 描述 Confirmable 0 可确认的消息，需要接收到确认响应。 Non-confirmable 1 不需要确认的消息，发送后不期望接收到响应。 Acknowledgment 2 确认消息的响应，用于确认接收到 Confirmable 消息。 Reset 3 重置消息，用于表示对某个消息的不理睬或超时。 -
可靠/不可靠消息传输
- 可靠消息传输： 持续重传直至收到带有相同消息ID的确认消息（ACK）。当接收方完全无法处理CON消息时，会用RST替换ACK作为响应。
- 不可靠消息传输： 不需要进行确认（ACK），但必须包含消息ID以便在重传时进行监控。当接收方无法处理NON消息时，可能会以RST作为回复。
CoAP 请求Request/响应Response层
- Piggybacked response（承载式响应）： 当客户端发送一个带有确认请求标志（CON）或不带确认请求标志（NON）的消息时，如果服务器可以立即响应，则服务器可以将响应直接放在确认消息（ACK）中发送回客户端。这样的响应方式称为承载式响应，因为响应“搭载”在了确认消息中一起发送，节省了额外的网络往返时间。
- Separate response（分离式响应）： 如果服务器不能立即响应客户端的请求，或者需要更长的时间来准备响应，服务器会先发送一个空的确认消息（ACK）给客户端，然后在准备好响应后，以一个新的确认消息（CON）的形式单独发送响应。这种响应方式称为分离式响应，因为响应和确认消息是分开发送的。
CoAP 消息/Message 格式
- 版本（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 智能家居的应用
CoAP 常用库
| 库名 | 语言 | 客/服务端支持 | 描述 | 链接 |
|---|---|---|---|---|
| aiocoap | Python 3 | Client + Server | Blockwise Transfers, Observe (partial) | aiocoap |
| Californium | Java | Client + Server | Observe, Blockwise Transfers, DTLS | Californium |
| cantcoap | C++/C | Client + Server | cantcoap | |
| Canopus | Go | Client + Server | Core | Canopus |
| CoAPSharp | C#, .NET | Client + Server | Core, Observe, Block, RD | CoAPSharp |
| CoAPthon | Python | Client + Server + Forward Proxy + Reverse Proxy | Observe, Multicast server discovery, CoRE Link Format parsing, Block-wise | CoAPthon |
| CoAP Shell | Java | Client | Observe, Blockwise Transfers, DTLS | CoAP Shell |
| Copper | JavaScript | Client | Observe, Blockwise Transfers | Copper |
| eCoAP | C | Client + Server | Core | eCoAP |
| iCoAP | Objective-C | Client | Core, Observe, Blockwise Transfers | iCoAP |
| jCoAP | Java | Client + Server | Observe, Blockwise Transfers | jCoAP |
| libcoap | C | Client + Server | Observe, Blockwise Transfers, DTLS | libcoap |
| LibNyoci | C | Client + Server | Core, Observe, Block, DTLS | LibNyoci |
| lobaro-coap | C | Client + Server | Observe, Blockwise Transfers | lobaro-coap |
| microcoap | C | Client + Server | microcoap | |
| nCoap | Java | Client + Server | Observe, Blockwise Transfers, CoRE Link Format, Endpoint-ID-Draft | nCoap |
WebSocket
WebSocket是一种在单个TCP连接上提供全双工通信的网络协议。- 它通过在客户端和服务器之间建立持久连接来实现双向通信，从而允许服务器实时地向客户端推送数据，而无需客户端发送请求。
WebSocket协议通过HTTP/HTTPS端口（80/443）与服务器进行握手，并在建立连接后使用自定义的WebSocket协议进行通信。WebSocket通常用于实现实时的Web应用程序，如在线游戏、聊天应用程序、股票市场数据更新等。- 相比于传统的
HTTP请求/响应模式，使得服务端可以主动通知客户端，具有更低的延迟和更高的效率，同时可以减少服务器和客户端之间的通信开销。
WebSocket 解决 HTTP 单向通信限制:
WebSocket 解决 HTTP 服务端无法主动通知客户端:
WebSocket 分层结构
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 格式
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
| 字段 | 描述 |
|---|---|
| FIN | 1=消息中的最后一个片段 |
| RSV1, RSV2, RSV3 | 非零=扩展 |
| MASK | 定义 “Payload 数据” 是否masked/被掩码处理 |
| Masking-key | 0 或 4 字节的长度 |
| Payload length | 7 位、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 实现库
HTTP VS. Websocket
HTTP 更适合的场景
- 获取资源： 需要状态但不需要持续更新。如，获取页面，但不需要更新页面内容。
- 可高度缓存的资源： 当资源变化不频繁或多个客户端会频繁请求相同资源时，资源从缓存种取，这样较少服务器负载，提高性能。
- 幂等性和安全性： “幂等”即请求一次或多次都会产生相同的结果，请求重试或失败提高数据一致性。另一方面，POST和PUT于更新资源，需要身份验证和授权，确保安全性。
- 错误场景： 标准的错误状态码机制
- 同步事件： 客户端发送请求并等待服务器的响应。
WebSocket 更适合的场景
- 快速反应时间
- 持续更新
- 即时通讯
- 频繁通信与小负载
LWM2M
LWM2M是一种针对物联网设备设计的轻量级机器到机器通信协议，提供了高效的远程管理和通信能力，同时保持了低功耗和高安全性。这使得它成为物联网领域中的重要标准之一，广泛应用于各种物联网场景中。
- 轻量级协议： LWM2M采用轻量级的通信协议，适用于资源受限的物联网设备，如嵌入式设备、传感器等。
- 远程管理： LWM2M允许对物联网设备进行远程管理，包括配置、监视、更新和维护，提高了设备的灵活性和效率。
- 资源模型： LWM2M使用资源模型描述设备功能和属性，基于RESTful原则，允许通过HTTP等协议对设备进行访问和操作。
- 低功耗： 设计用于低功耗和有限网络带宽环境，具有高效的能源和网络资源利用率。
- 安全性： 提供安全的通信机制，包括数据加密、身份验证和访问控制，确保设备之间的通信和管理安全可靠。
LWM2M总体架构
LWM2M 架构由 对象（Objects）、**接口（Interfaces）**和 **协议栈（Stack）**组成。
- 对象： 每个对象代表设备的一个功能或属性，如传感器、执行器等。对象由多个资源组成，描述设备的状态、配置和控制。
- 接口： 提供标准的方法与对象进行交互，包括读取资源、写入资源、观察资源变化等。
- 协议栈： 实现LWM2M协议的软件组件，处理通信、消息解析、设备管理等功能。
在LWM2M分层结构中：
- UDP：为设备和服务器之间的通信
- SMS：作为备用通信机制，用于发送警报、通知或命令。
- DTLS：提供安全的数据传输，包括加密、身份验证和数据完整性保护。
- CoAP：是LWM2M的下一层协议，作为基础通信协议，支持设备和服务器之间的轻量级、高效的通信和管理。
LWM2M 客户端/Client 引擎架构
LWM2M对象模型
对象（Object）是最高级别的组织单位，每个对象代表了设备的一个功能或属性集合。每个对象由一个或多个资源（Resource）组成，资源表示对象的一个具体属性或功能。资源可以是只读的、可写的或可观察的，用于描述设备的状态、配置和控制。对象还可以包含一个或多个实例（Instance），实例用于区分具有相同功能的不同设备。
- 对象/资源访问 URI：
/{Object ID}/{Object Instance}/{Resource ID}，示例如下图：
LWM2M 内部对象
- Security Object（安全对象）： 用于配置设备的安全性设置，包括用于DTLS握手的密钥和证书。
- Server Object（服务器对象）： 用于配置设备连接到的LWM2M服务器的参数，如服务器地址、端口和传输模式等。
- Access Control Object（访问控制对象）： 用于管理对设备资源的访问权限，包括读、写、执行和观察等操作。
- Device Object（设备对象）： 提供设备的基本信息和状态，如制造商、型号、固件版本等。
- Connectivity Monitoring Object（连接监控对象）： 用于监视设备的连接状态和网络参数，如信号强度、网络类型等。
- Firmware Object（固件对象）： 用于管理设备固件的更新和升级过程，包括下载、安装和验证等操作。
- Location Object（位置对象）： 提供设备的地理位置信息，包括经度、纬度、海拔等。
- Connectivity Statistics Object（连接统计对象）： 提供设备的连接统计信息，如连接时长、数据传输量等。
LWM2M 设备管理
LWM2M 应用场景示例
AMQP - Advanced Message Queuing Protocol
- 一种可靠的消息传递协议，用于构建分布式系统和异步通信，提供灵活的消息模式和跨平台支持。
- 它被广泛应用于金融、电信和物联网等领域，以实现高效的消息交换和异步处理。
- 包括消息导向、消息队列、消息路由（包括点对点和发布-订阅）、可靠性和安全性。
生产消费模型如下：
AMQP 整体架构
- Broker（代理）： 代理是消息队列系统中的中间件组件，负责接收、路由和传递消息。它充当消息的中转站，管理消息的存储和转发。
- Virtual Host（虚拟主机）： 虚拟主机是在消息代理中创建的逻辑消息服务环境。它允许多个应用程序共享同一个消息代理，每个虚拟主机都有自己的独立消息队列和交换机等资源。
- Connection（连接）： 连接是客户端与消息代理之间的通信通道，用于发送和接收消息。一个连接可以包含多个通道（channels），允许客户端并行发送和接收多个消息。
- Channel（通道）： 通道是在连接上创建的逻辑通信通道，用于在客户端和消息代理之间进行消息传递。通道可以看作是连接内的独立会话，允许客户端并行进行多个操作。
- Exchange（交换机）： 交换机是消息代理中的组件，负责接收来自生产者的消息，并根据预定的路由规则将消息路由到一个或多个队列中。它定义了消息的路由策略和目标队列。
- Queue（队列）： 队列是消息代理中用于存储消息的数据结构，它按照先进先出（FIFO）的原则处理消息。消费者从队列中获取消息，并对其进行处理。
- Binding（绑定）： 绑定是交换机和队列之间的关联关系，它定义了交换机如何将消息路由到队列。绑定通常使用路由键（routing key）来指定消息的路由规则，将满足条件的消息发送到相应的队列中。
AMQP交换机类型/AMQP Exchange Type
AMQP交换机的类型，用于定义消息的路由规则和行为。
AMQP定义了几种主要的交换机类型，每种类型都有不同的路由策略和行为，提供了不同的消息路由策略，允许开发者根据应用场景选择最适合的交换机类型来实现消息的路由和传递，如下图3种交换机类型：
-
Direct Exchange（直连交换机）： 直连交换机将消息根据指定的路由键（routing key）发送到与之完全匹配的队列中。它适用于一对一的消息传递，消息将被发送到唯一的队列中。
-
Fanout Exchange（广播交换机）： 广播交换机将消息发送到所有与之绑定的队列中，忽略路由键。它适用于一对多的消息广播，消息将被发送到所有绑定的队列中。
-
Topic Exchange（主题交换机）： 主题交换机根据消息的路由键和交换机与队列之间的绑定规则将消息发送到匹配的队列中。它支持通配符匹配，可以根据路由键的模式匹配将消息发送到多个队列中。
-
Headers Exchange（头交换机）： 头交换机根据消息的头部属性将消息发送到与之匹配的队列中。它不依赖于路由键，而是根据消息头部的属性进行匹配。
IoT 通信协议对比
| Protocol | MQTT | CoAP | HTTP | Websocket | AMQP | XMPP | DDS | JMS | M3DA | STOMP | SNMP |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Architecture | Client/Server | Client/Server | Client/Server | Client/Server | Client/Server | Client/Gateway/Server | Client/Server | Client/Server | Client/Server | Client/Server | Client/Server |
| Model | Publish/Subscribe | Request/Response | Request/Response | N/A | Producer/Consumer | Publish/Subscribe | Publish/Subscribe | Publish/Subscribe | Message/Response | Producer/Consumer | Agent Mnanager |
| Relationship | Many-to-Many | One-to-One | Many-to-One | One-to-One | Many-to-Many | Many-to-Many | Many-to-Many | Many-to-Many | One-to-One | Many-to-Many | Many-to-one |
| Transfer Efficiency | High | High | General | High | High | General | High | General | High | General | General |
| Time-validity | High | Poor | Poor | High | High | High | Very High | General | High | Poor | General |
| Power consumption | General | Low | High | High | High | High | High | High | Low | High | High |
| QoS Support | Yes | No | No | No | Yes | Yes | Yes | No | No | No | No |
| Hard-Real-Time Capability | No | No | No | No | No | No | Yes | No | No | No | No |
| Coding Way | Binary | Binary | Text(XML/JSON) | Binary/Text | Binary | XML | Binary | Binary | Binary | Text/Binary | ASN.1 |
| Interoperability | Portion | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes |
| 2G, 3G, 4G Suitability (1000s nodes) | Excellent | Excellent | Excellent | N/A | Excellent | Excellent | N/A | N/A | N/A | N/A | N/A |
| LLN Suitability (1000s nodes) | Fair | Excellent | Fair | N/A | Fair | Fair | N/A | N/A | N/A | N/A | N/A |
| Resource Consumption | General | Low | General | General | General | General | General | High | Low | General | High |
| Long Connection | Yes | No | No | Yes | Yes | Yes | N/A | Yes | N/A | Yes | No |
| Security | Account/SSL/TLS | DTLS | SSL/TLS | SSL/TLS | SASL/SSL/TLS | SSL/TLS | SSL/TLS | SSL/TLS/JAAS | SSL/TLS/DTLS | SSL/TLS | DTLS |
| Transport | TCP | UDP/SMS | TCP | TCP | TCP | TCP | UDP/IP | TCP(default) | HTTP/TCP/UDP/SMS | TCP | UDP |
| IP | IP | 6LoWPAN | IP | IP | IP | IP | IP | IP | IP | IP | IP |
| Implement | libumqtt | libcoap | curl | uWebSockets | OpenAMQ | Openfire | OpenDDS | OpenJMS | Mihini | libstomp | net-snmp |
| Implement | mosquitto | microcoap | httpd | ws-rs | RabbitMQ | gloox | OpenSplice DDS | mom4j |
术语
- 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 - 线路链路网络
