CoAP：支持 M2M 应用的智能解决方案

并非所有连接的设备都设计为相等。虽然有些技术先进且坚固耐用，但有些则是简单的传感器和家庭自动化系统，内存、能量、带宽和计算能力有限。将网络引入资源受限的低功耗设备并使其能够有效通信，需要开发人员实施特定类型的物联网协议。这就是受限应用协议或 CoAP 出现的地方。

什么是 CoAP？

CoAP 于 2014 年推出，是由 CoRE（受限资源环境）互联网工程任务组 (IETF) 设计的轻量级 RESTful 协议。它通常用于机器对机器 (M2M) 应用程序，例如智能能源和楼宇自动化设备。

CoAP 是物联网网络中低功耗物联网设备的高效通信协议。它允许资源受限的传感器节点、家庭自动化工具和其他需要较少带宽或计算能力的连接对象通过互联网进行通信。

CoAP 是用于创建和管理设备、发布/订阅数据、在多个客户端之间多播数据以及在客户端请求时提供设备描述的出色协议。

它还具有检测设备电源状态的机制。此外，由于与 HTTP REST 操作在基础架构上有相似之处，设计人员可以将他们对 RESTful 模式的理解运用到他们使用 CoAP 进行的 IoT 应用程序开发中。

CoAP 协议概览

物联网生态系统是一个快速发展的空间，即使是最杰出的设计人员和开发人员也很容易在 M2M 协议补丁、漏洞、第三方库错误和实施缺陷的知识和管理方面被超越。

因此，物联网设备使用流行的 CoAP 协议来阻止 M2M 应用程序中的网络攻击也就不足为奇了。它们支持异步消息交换，提供 URI 和内容类型支持，利用代理和缓存功能，并且易于解析。但在我们深入研究 CoAP 协议之前，有必要了解其结构，它通常由以下实体组成：

1. “Sender”——发送消息的实体。
2. “接收者”——消息的接收者或目的地。
3. “客户端”——请求的来源和响应的目的地。
4. “端点”——参与 CoAP 协议的实体，通常与主机标识。
5. “服务器”——客户端和接收者之间的链接。它接收来自客户端的请求并将响应发送回客户端。

典型的 CoAP 协议可能看起来类似于 HTTP 协议，因为 CoAP 部署了用户数据报协议 (UDP) 作为底层网络协议。反过来，UDP 会帮助客户端发出请求，而服务器会传输响应——就像在 HTTP 中发生的那样。

两层让 CoAP 脱颖而出

请求/响应层根据请求/响应消息处理请求/响应交互。
消息层处理异步消息和用户数据报协议 (UDP)。

如您所见，CoAP 协议不仅仅是 HTTP 协议的压缩版本，而且是专为 IoT 设计的。 CoAP 支持四种类型的消息，包括：

1. 重置 (RST)
2. 可确认 (CON)
3. 不可确认 (NON)
4. 确认（ACK）

这些消息的主要交换对于请求/响应交互是透明的。 CoAP 是一个单一的协议，请求/响应和消息作为 CoAP 头的特征。

CoAP 通常如何运作

CoAP 主要用于受限设备，使执行器和传感器能够在物联网生态系统内高效通信。这些应用程序通过将它们的数据作为系统的一部分提供来进行控制。该协议可以通过低网络开销和低功耗在高拥塞和低带宽场景中提供卓越的性能。 CoAP 还支持具有许多节点的网络。即使在基于 TCP 的协议 MQTT 无法在设备之间交换信息和有效通信的情况下，它也可以继续工作。

此外，CoAP 协议允许设备在较差的信号质量下运行并可靠地传输数据。这一特性还使卫星能够方便地保持远程通信。这就是 M2M 开发服务中发生的情况。

CoAP消息模型的构建

这是协议的最低层元素，因为它处理端点之间的 UDP 传输消息。每个 CoAP 消息都有一个唯一的 ID，这对于检测消息重复非常有用。平均而言，CoAP 消息模型由三部分组成，其中两部分是可选的：

1. 一个二进制头
2. 一组紧凑的选项（可选）
3. 有效载荷（可选）

CoAP 协议指定了两种类型的消息：

可确认

这些在两个端点之间传输的消息是可靠的。这意味着客户端确信消息将到达服务器。在 CoAP 中，使用可确认 (CON) 消息类型代码获得专用消息。 Confirmable 消息会重复发送，直到另一方（即服务器）发送确认（ACK）消息，该消息包含与 Confirmable 消息相同的 ID，但带有 ACK 响应代码。

不可确认

这些消息不需要来自客户端的确认，而是始终在两个端点之间携带请求或响应。对于应用要求，不可确认 (NON) 消息会无限重复——例如，从传感器中重复读取最终到达就足够了。这样的消息必须包含有效载荷。

揭示“请求和响应”模型

这是协议的第二层。 使用 CON 或 NON 消息发送请求。 如果使用 CON 消息发送请求，则服务器的响应取决于服务器是否可以立即响应客户端的请求：

1. 如果服务器可以及时响应，服务器会向客户端发送一条包含错误代码或响应的 ACK 消息，以及一个 Token 字段，该字段反映了请求中的 Token 字段。 Token 不同于 Message-ID，它用于匹配两个端点之间的请求和响应。
2. 如果服务器不能及时响应从客户端收到的请求，另一方面，它会发送一个消息字段为空的 ACK 消息。 一旦响应可用，服务器就会向共享状态的客户端发送 CON 消息。

如果来自客户端的请求携带不可确认消息，则服务器仅使用该类型的消息进行响应。

什么是消息格式？

CoAP 消息以二进制形式编码。 CoAP 消息由固定大小的 CoAP 报头组成，辅以有效载荷和以类型-长度-值 (TLV) 格式指定的选项。

虽然标头指定了这些选项，但有效载荷由根据数据报长度计算选项长度之后的字节组成。 CoAP 消息占用 UDP 数据报的数据部分以避免分段。

由于 CoAP 节省能源并简化设备之间的通信，因此使用紧凑消息。 CoAP 报头的必填字段是：

1. 版本（CoAP 消息格式的 2 位版本；有时缩写为“VER”）
2. 类型（对应于 RST、CON、NON 或 ACK 消息类型的 2 位无符号整数）
3. 令牌长度（一个 4 位字段，指定“令牌”字段的字节长度；有时缩写为“TKL”）
4. 代码（一个 8 位字段，提供有关请求或响应的更多信息）
5. Message-ID（与消息关联的唯一 ID，用 16 位值表示）

考虑 CoAP 安全性

安全是物联网生态系统中的一个重大问题，并且有充分的理由：设备通过互联网连接，在它们之间交换各种信息。无论所讨论的物联网设备是用于个人用途还是商业用途，数据安全都至关重要。

CoAP 将 UDP 应用于传输信息，并进一步依赖它进行信息保护。最小的 CoAP 消息长度为 4 个字节，并使用两种消息类型（响应和请求），使用简单的二进制基本报头格式。

后者是经过优化的 TLV 格式的选项，可提供高级别的通信安全性。留在包中的头中的任何字节都被归类为消息体，这由数据报长度暗示。

交给你

在 M2M 应用程序中，从长远来看，应用程序/XML、应用程序/八位字节流或文本/纯文本等通用互联网媒体类型并没有被证明对现实世界的应用程序有帮助。例如，智能能源应用程序负载可能会请求更具体的类型，如 application/se+exi，因为它是作为 XML 携带的。

这就是为什么需要更先进的物联网协议的原因。 CoAP 在降低云设备连接成本方面发挥了关键作用，使物联网设备能够在更大的网络上经济高效且安全地发送数据，同时消耗更少的电量。

随着物联网环境的发展，对关键协议的需求也在增长，以经济高效且安全地实现跨设备的数据传输。毫无疑问，CoAP 是一种支持 M2M 应用的智能解决方案。由于它的产品种类繁多，让我们希望它的用途在未来也能发展到物联网的其他不同方面。