89、物联网应用层协议与安全机制深度解析

物联网应用层协议与安全机制深度解析

1. CBOR与SenML简介

在物联网数据处理中，CBOR（Concise Binary Object Representation）和SenML（Sensor Model Language）是两个重要的数据表示和传输方案。

CBOR可以直接映射到JSON，但在表示数据结构方面更强大，尤其是对于对象。在CBOR中，键不必是字符串类型，也可以是整数类型，这样更加紧凑，并且同一对象中的键可以重复多次，这对于对象中键的增量编码很有用。此外，CBOR还通过在线数据类型（标签）提供比JSON更精确的类型定义。标签以二进制序列110开头，其余部分在CBOR的RFC或其他文档中定义。例如，字符串可以被标记为日期或URI，包含两个元素的数组可以被视为分数。CBOR在物联网中广泛用于处理复杂结构，还可用于使用CDDL定义协议头。

SenML是一种用于从受限设备传输测量数据的JSON或CBOR数据结构，其格式在RFC 8428中定义，依赖于数组结构来组合对象。SenML定义了对象中使用的键，为了实现紧凑表示，这些键被限制为1或2个字符。例如，“bn”表示基名，“n”表示设备名称；如果有多个设备发送数据，可以将设备标识符的公共部分放在“bn”中以避免重复。基时间（“bt”）是一种紧凑的时间表示方式，时间（“t”）给出偏移量，从而得到较小的值。基单位（“bu”）指定默认单位，如果其他对象没有携带单位（“u”）键，则使用该默认单位。数值使用“v”键，字符串使用“vs”键。在CBOR对象中，正负数小整数会被替换，例如“bn”、“bt”和“bu”分别用 -1、 -2和 -3表示，“n”、“t”和“u”用 +0、 +2和 +6表示。

2. CoAP协议详解

HTTP是实现REST范式的主导协议，但HTTP消息使用ASCII定义，虽然提供了很大的灵活性，但导致了冗长的交换和相对复杂的头部。而CoAP（Constrained Application Protocol）则通过严格的二进制格式使头部编码和解码更加简单。

2.1 CoAP强制头部

CoAP强制头部以2位表示CoAP版本，始终设置为01。类型字段用2位编码，表示CoAP消息的四种类型之一。由于CoAP最初设计为在UDP上运行，因此必须实现自己的消息恢复协议以确保传输可靠。强制头部包含一个16位的消息ID，可确认消息携带特定的消息ID，接收方通过确认（ACK）该值来通知对方消息已成功接收。非确认消息不触发确认，消息ID仅用于检测重复。最后一种消息类型用于重置传输。

接下来的4位表示令牌长度，令牌本身紧跟在强制头部之后，长度可以在0到8字节之间。在HTTP中，由于请求和响应在同一TCP连接上，因此很容易关联它们；而在UDP中，连接的概念消失了，令牌起到了会话标识符的作用，请求中选择的令牌值会在响应中回显，使客户端能够将响应映射到其请求。

强制头部还包含一个1字节的代码字段，用于指示REST请求的性质或响应代码。在HTTP中，响应代码用三位数字编码，分为5个类别；而在CoAP中，所有信息都编码在1字节中，最左边的3位编码类别，最右边的5位编码细节。例如，404错误在CoAP中表示为4.04，二进制编码为100.00100，转换为单字节0x84或132。CoAP保留了与HTTP相同的代码，除了对GET请求的“200”OK响应，该代码过于通用，被更具体的2.05所取代。0.YY类用于编码请求，0.00表示空的CoAP消息，可用于ping另一个CoAP实体。从0.01到0.05的值在原始CoAP RFC（RFC 7252）中定义，分别表示GET、POST、PUT和DELETE。RFC 8132扩展了这个列表，增加了FETCH（代码0.05），它可以看作是GET的等效操作，主要区别在于请求的资源和补充信息不是编码在URI中，而是在有效负载中，这样可以实现更紧凑的表示。标准还定义了PATH和iPATH（分别为代码0.06和0.07），允许仅修改资源的某些元素。

以下是CoAP响应代码与HTTP响应代码的对比表格：
| 类别 | HTTP代码 | CoAP代码 | 含义 |
| ---- | ---- | ---- | ---- |
| 1XX | 1XX | 1.YY | 服务器已处理请求 |
| 2XX | 200 | 2.05 | 成功 |
| | 其他2XX | 2.YY | 成功 |
| 3XX | 3XX | 3.YY | 重定向 |
| 4XX | 4XX | 4.YY | 客户端错误 |
| 5XX | 5XX | 5.YY | 服务器错误 |

2.2 CoAP选项

CoAP选项分为控制选项和REST选项，用于控制CoAP行为或编码REST选项。

控制选项 ：
- 块选项 ：IPv6或为物联网设计的6LoWPAN适配层的分段效率不高。如果在链路层无法发送太大的消息，会将其切成较小的片段。在第3层分段中，如果一个片段丢失，整个原始消息必须重新发送。CoAP提供了一种更有效的方法来处理大资源，将其切成块（RFC 7959）。由于CoAP允许确认可确认消息，如果发送方检测到丢失，可以重新发送信息。块的大小可以从16到1024字节不等。当客户端请求太大而无法在单个消息中传输的资源时，服务器会添加一个块选项，包含块编号、是否还有更多块的标志以及块大小。客户端收到第一个块后，会重复请求，但会增加块选项编号以请求缺失的信息。由于块选项在两个方向都使用（请求特定块或指示特定块），并且分段可能在两个方向都发生（从服务器到客户端的GET请求或从客户端到服务器的PUT或POST请求），因此定义了两个块选项：Block1选项用于从服务器向客户端传输分段资源，Block2选项用于相反方向。RFC还指定了一个大小选项，以帮助接收方管理其内存。
- 观察选项 ：CoAP引入了HTTP中没有的新功能。在纯客户端/服务器模型中，响应由请求触发。当使用REST范式监控设备时，这可能会导致大量流量。例如，在工业物联网中，泵需要控制水箱中的液位，客户端会不断请求液位信息。CoAP的观察选项（RFC 7641）可以优化请求数量。客户端想要观察资源时，会在请求中添加观察选项。接受该请求的服务器会定期回复资源的新状态。观察选项也会设置在响应中，并包含一个递增的数字，用于在客户端对响应进行排序。使用相同的CoAP令牌来关联查询和多个答案。观察选项在服务器中创建了一个状态，这在某种程度上违反了REST原则。因此，服务器可能会向网络中不再存在或已重启的客户端定期发送资源。在客户端重启的情况下，客户端可以使用RST CoAP消息停止发送。在客户端不存在的情况下，服务器应不时发送可确认消息，期望从存活的客户端收到ACK。客户端可以随时通过发送带有观察消息的新查询来停止观察响应。观察行为取决于服务器实现和资源性质，响应可以定期发送，也可以仅在值达到阈值时发送。
- 无服务器响应选项 ：CoAP并行实现了两个用于可靠传输的状态机：基于类型和消息ID的传输状态机用于确保消息到达目的地，基于代码字段和令牌的REST状态机用于确保请求得到处理。有时，客户端希望限制来自接收方的反馈，例如在车载通信中资源被信标发送或在LPWAN网络中节省下行链路流量。如果CoAP非确认消息避免了ACK的接收，REST请求仍会被确认。无服务器响应选项（RFC 7967）告诉服务器其确认行为，它包含一个位图，指示允许的响应类别。例如，阻止2.XX类响应，仅将否定确认（4.XX和5.XX）返回给客户端。

REST选项 ：
- URI编码 ：URI在REST架构中对于识别资源至关重要。当用作定位器时，会分析URI以确定哪个服务器拥有该资源。URI以方案开头，该方案决定了URI的后续结构。在CoAP中，方案通常是“coap”或“coaps”用于加密流量。接下来是服务器地址，有时会包含端口号（如果不使用默认端口5683）。URI路径包含服务器内部用于定位资源的不同元素，查询字符串传输服务器在处理资源时使用的信息。通常，在REST请求中只需要发送路径和查询字符串，因为协议服务器地址和端口号用于联系适当的服务器。HTML使用连接路径元素和查询字符串的字符串，服务器解析该信息。在CoAP中，由于服务器的资源和内存可能有限，解析工作由客户端完成；路径中的每个元素存储在不同的URI - path选项中，查询字符串围绕“&”字符拆分并存储在多个URI - query选项中。URI - path和URI - queries是CoAP请求中最常见的两个选项，CoAP还定义了其他用于在CoAP和HTTP之间代理REST的选项。
- 内容编码 ：在REST架构中，告知资源的内容格式几乎是必需的。客户端必须知道格式才能处理资源和其中包含的链接。为了实现紧凑表示，CoAP使用整数表示内容格式。默认值0表示ASCII文本，值50表示JSON结构，值60表示CBOR结构。值在110到116之间表示SenML的JSON、CBOR或XML表示。目前大约有50个代码与应用格式相关联。在请求中，发送方可以指定期望的响应格式。
- 缓存 ：CoAP提供了与HTTP相同的缓存机制。资源可以通过etag（资源内容哈希）进行标识，请求可以包含该etag以仅获取资源的较新版本。CoAP还建议添加资源持续时间选项，以限制资源可以被缓存的时间。

下面是CoAP处理大资源的流程mermaid图：

graph LR
    A[客户端请求大资源] --> B[服务器添加块选项并发送第一块]
    B --> C[客户端接收第一块]
    C --> D[客户端重复请求并增加块选项编号]
    D --> E[服务器发送后续块]
    E --> F{是否还有块}
    F -- 是 --> D
    F -- 否 --> G[客户端接收完整资源]

3. 资源目录与发布/订阅

从网络角度看，每个设备都有IP地址，但很难判断它是温度传感器还是运动传感器。RFC 6690解释了如何定义包含此类信息的资源，使用一种不同于JSON或CBOR的基于Web链接的格式，内容格式值40表示Web链接格式。在这种格式中，URI用<>字符表示，后面跟着一些属性。例如，设备可能拥有两个资源，通过相对路径表示，资源类型（rt）标识资源的性质，接口（if）告诉如何访问资源。每个设备上的此类资源都可以通过相同的URI访问，标准规定为.wellknown/core。该URI可能包含查询字符串以限制响应范围。

所有可用资源可以通过扫描所有设备或使用多播来查找，但这两种方法都不可扩展，并且消耗大量能量和带宽。一些工作建议将信息集中在中央服务器中，当应用程序想要查找特定资源时，可以查询该服务器。

发布/订阅架构也可以使用CoAP实现，类似于MQTT。经纪人从客户端接收发布主题，并将其传播给订阅这些主题的客户端。客户端可以通过资源目录或直接查询“.wellknown/core”来发现服务器的经纪人功能。特定的资源类型core.ps已分配给用于发布/订阅服务的URI，该URI返回用于此服务的URI（例如 /ps）。要在经纪人上创建主题，客户端使用链接格式发送POST请求来指示主题。

以下是发布/订阅流程的表格：
| 步骤 | 操作 | 说明 |
| ---- | ---- | ---- |
| 1 | 客户端查询经纪人功能 | 通过资源目录或直接查询“.wellknown/core” |
| 2 | 服务器返回服务URI | 例如 /ps |
| 3 | 客户端发送POST请求创建主题 | 使用链接格式指示主题 |
| 4 | 经纪人接收主题并传播 | 给订阅该主题的客户端 |

物联网应用层协议与安全机制深度解析

4. 物联网安全机制

在物联网领域，安全通信至关重要，而加密是保障通信安全的关键手段。在传统互联网中，加密通常在两个层面进行：IPsec用于加密IP有效负载，TLS主要用于在TCP上保护HTTP流量。然而，物联网设备的操作系统与传统操作系统有所不同，它们可能不会将内存资源划分为内核和用户空间，因此IPsec和TLS的实现差异并不那么明显。不过，近年来的微处理器引入了信任区，可以存储密钥并执行某些功能，这在一定程度上保护了设备免受物理攻击，但并未改变软件架构。

IPsec只是一种加密机制，需要另一个协议（如IKE）来交换密钥。TLS则通过握手阶段协商加密套件并生成会话密钥，但它只能与面向连接的协议（如TCP）一起使用，因此广泛用于保护HTTP通信。

4.1 DTLS协议

由于CoAP主要使用UDP，TLS需要扩展以支持数据报。DTLS（Datagram TLS）为数据报协议提供了通信安全，包括完整性、认证和保密性，适用于CoAP。DTLS的设计与TLS类似，在RFC 6347中定义，也可用于非IP网络（如3GPP CIoT）。DTLS通过单个数据报通道完成密钥协商和批量数据传输。

DTLS采用同步握手方式，消息必须按正确顺序到达，不能跳过。消息有序列号用于检测顺序，并使用偏移量和长度来避免IP分段。DTLS还基于两种策略添加了重传机制：
- 时间戳策略 ：适用于应用程序会反复执行握手，直到返回致命错误或零的情况，类似于使用阻塞I/O。在这种策略中，设置函数记录时间戳和延迟值，获取函数将存储的时间戳与当前时间进行比较。
- 定时器和事件策略 ：设置函数确保在延迟到期时使用超时处理程序。

DTLS可能会加剧DDoS攻击，但它提供了无状态cookie交换机制，用于验证客户端地址。该机制使用服务器端的秘密密钥，防止攻击者生成有效cookie。经过多次错误记录后，连接将被关闭。

以下是DTLS握手流程的mermaid图：

graph LR
    A[客户端发送ClientHello] --> B[服务器发送ServerHello和证书]
    B --> C[客户端验证证书并发送ClientKeyExchange]
    C --> D[服务器生成会话密钥并发送ChangeCipherSpec和Finished]
    D --> E[客户端生成会话密钥并发送ChangeCipherSpec和Finished]
    E --> F[握手完成，开始数据传输]

5. 总结

物联网的应用层协议和安全机制是保障物联网系统正常运行和数据安全的重要组成部分。CBOR和SenML为物联网数据的表示和传输提供了高效的解决方案，CoAP协议则针对受限设备和网络环境进行了优化，提高了通信效率和可靠性。资源目录和发布/订阅机制使得物联网资源的管理和信息传播更加灵活和便捷。而DTLS协议为基于UDP的通信提供了安全保障，确保了数据的完整性、认证和保密性。

在实际应用中，需要根据具体的场景和需求选择合适的协议和机制。例如，对于资源受限的设备，可以优先考虑使用CoAP协议；对于需要保障通信安全的场景，应采用DTLS进行加密。同时，随着物联网技术的不断发展，这些协议和机制也将不断完善和创新，以适应日益复杂的应用需求。

以下是物联网协议与机制的对比表格：
| 协议/机制 | 特点 | 应用场景 |
| ---- | ---- | ---- |
| CBOR | 可直接映射到JSON，更强大表示数据结构，键类型灵活 | 处理复杂数据结构 |
| SenML | 紧凑表示测量数据，键长度受限 | 受限设备数据传输 |
| CoAP | 头部编码简单，适用于UDP，有多种选项 | 受限网络环境 |
| 资源目录 | 集中管理资源信息 | 查找特定资源 |
| 发布/订阅 | 高效信息传播 | 信息广播和订阅 |
| DTLS | 为UDP提供安全保障 | 保障通信安全 |

通过合理运用这些协议和机制，可以构建更加高效、安全和可靠的物联网系统，推动物联网技术在各个领域的广泛应用。