物联网主流通信协议解读

当今物联网的主流通信协议是 CoAP/LWM2M 协议和 MQTT 协议，本文将会为您分别解读这些协议的工作方式，了解它们的特点，助您选择最适合您的设备的通信协议。

通信协议又称为传输协议，用于定义多个设备之间传播信息时的系统标准。通信协议定义了设备通信中的语法、语义、同步规则和发生错误时的处理原则，可以理解为机器之间使用的语言。

在物联网场景中，通信主要发生在设备和物联网平台之间，由于大部分物联网设备都是资源受限型设备，它们的物理资源和网络资源都非常有限，直接使用现有的 HTTP 协议进行通信对它们来说要求实在是太高了。因此，物联网场景中主要使用的通信协议都是轻量级的，为资源受限环境而设计的通信协议，例如 CoAP/LWM2M 协议和 MQTT 协议。

本文将会为您分别解读 CoAP/LWM2M 协议和 MQTT 协议，希望能帮助您了解这些协议，并选择最适合您的设备的通信协议。

CoAP/LWM2M 协议

CoAP（Constrained Application Protocol，受限制的应用协议）运行于 UDP 协议之上，设计上主要借鉴了 HTTP 协议的 RESTful 风格，简化了协议包格式，一个最小的 CoAP 数据包仅 4 字节。CoAP 协议采用了和 HTTP 协议相同的请求/响应模型，客户端发出请求后，服务端处理请求并回复响应，是一种点对点的通信模型。CoAP 和 HTTP 一样都是通过 URI 指定要访问的资源，但 CoAP 协议以“coap:”或"coaps:"开头，其中 coaps 的 s 是指消息通过 DTLS 协议加密。CoAP 的每一条消息都是一条二进制的报文，由以下部分组成：

VER：长度 2 位，用于表示 CoAP 协议的版本号。

T：长度 2 位，用于表示报文类型。CoAP 协议定义了四种报文类型：

• CON：需要应答的报文，接受者收到该消息后需要及时回复一个 ACK 报文。

• NON：无需应答的报文。

• ACK：应答报文。

• RST：复位报文，当接受者无法解析收到的报文或收到的报文中含有错误时，可以回复 RST 报文。

TKL：长度 4 位，用于表示 Token 字段的长度。

Code：长度 8 位，在请求消息中用于表示请求方法（GET/POST/PUT/DELETE），在响应消息中表示响应码（与 HTTP 的响应码类似）。

Message ID：长度 16 位，用于标识报文。主要用途有两个，一个是服务端收到 CON 报文后，需要返回相同 Message ID 的 ACK 报文；另一个是重发场景下，用相同的 Message ID 表示这是同一条报文的重复发送。

Token：可选字段，长度由 TKL 决定，同样用来标识报文。例如，有时候服务端收到 CON 报文（携带了 Token）后，请求的内容无法立刻处理完成，就只能先回复一个不带响应数据的 ACK 报文，待请求处理完成后再通过一个 CON 或者 NON 报文将实际响应数据带给客户端；此时这个报文就必须携带和之前的 CON 报文相同的 Token，告诉客户端这个报文是之前的 CON 报文的响应。

同理，若客户端发送 NON 报文进行请求，服务端也可同样使用 NON 报文进行响应，两个报文使用 Token 进行关联。除此之外，Token 还可用于消息防伪造等场景，此处不再展开说明。

Options：可选字段，长度不定，作用类似于 HTTP 协议中的消息头。

1 1 1 1 1 1 1 1：隔离符，用于分隔 Options 和 Payload。

Payload：实际负载数据，即 HTTP 协议中的消息体，用于携带这条消息实际的内容，可以为空。

了解过 CoAP 协议后，接下来我们再了解下 LWM2M 协议。

LWM2M（Lightweight Machine-To-Machine，轻量级 M2M）协议是由由 OMA（Open Mobile Alliance）提出并定义的基于 CoAP 协议的物联网通信协议。LWM2M 协议在 CoAP 协议的基础上定义了接口、对象等规范，使得物联网设备和物联网平台之间的通信更加简洁和规范。

LWM2M 协议定义了三个逻辑实体：LWM2M Server（服务端），LWM2M Client（客户端），LWM2M Bootstrap Server（引导服务），其中 LWM2M Server 和 LWM2M Bootstrap Server 可以是同一个服务器。在这些实体间，LWM2M 协议定义了四个接口：

Bootstrap：引导接口。客户端首次启动后，可以通过该接口访问引导服务（需要厂家提前把引导服务器的地址写入设备），获取服务端的地址。

Device Discovery and Registration：设备发现与注册接口。客户端通过该接口将自己的基本信息写到服务端，包括自己支持哪些能力。该接口同时还可以用于升级注册信息和注销设备。

Device Management and Service Enablement：设备管理和业务实现接口。服务端通过该接口给客户端下发指令，客户端处理指令并返回响应。该接口定义了 7 种操作，分别是：“Create”、“Read”、“Write”、“Delete”、“Execute”、“Write Attributes”和“Discover”。

Information Reporting：信息上报接口。LWM2M 允许服务端向客户端订阅资源信息，客户端被订阅后按照接口约定的模式（事件触发或定期）向服务端主动上报信息。

在上述接口中，服务端对客户端进行操作时都需要指定一个具体的操作目标，例如读某个属性，写某个属性。在 HTTP 协议中，这种目标的指定是通过 URI 或者消息体内携带的文本消息进行指定。而 LWM2M 协议为了使通信消息更加简洁，定义了对象和资源的概念。

对象是资源的集合，LWM2M 协议定义了 8 个标准对象，给它们分别分配了 0~7 的对象 ID，例如对象 ID 为 5 的是固件对象。考虑到拓展性，LWM2M 协议也允许使用者自定义新的对象并分配对象 ID。

每个对象在被使用之前必须先被实例化，因为对象都是抽象的模型，一个对象可以有多个实例，每个实例为一个单独的逻辑实体。对象实例化时会被分配实例 ID，从 0 开始递增。

资源则可以理解为对象的属性，是 LWM2M 协议中实际用于携带信息的实体。同一个对象的不同实例中的资源携带值可以是不同的。每个资源都需要被分配了一个资源 ID，例如固件对象的固件包名称的资源 ID 为 6。和对象一样，LWM2M 协议也允许自定义资源。

至此，通过对象 ID，实例 ID 和资源 ID，我们就可以用三个数字指示一个具体的资源，例如 5/0/6 表示固件对象第一个实例的固件包名称。在注册阶段，客户端就会把自己支持的对象的示例写入服务端，用于通知服务端自己支持的能力。

MQTT 协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）协议运行于 TCP 协议之上，是一种基于发布/订阅模型的通信协议。在发布/订阅模型模型中，我们需要一个代理服务器（通常称之为 Broker），所有客户端都需要和服务器建立连接，然后进行订阅和发布。若某个客户端发布了其他客户端已订阅的主题（MQTT 协议中称之为 topic），服务器就会将这个主题转发给所有已订阅的客户端。例如有 A、B、C 三个客户端都连上了同一个服务器，B 和 C 订阅了“test”主题，然后 A 发布了一个主题为“test”的消息，服务器就会把这条消息转发给 B 和 C。

在物联网场景中，物联网平台既是一个服务器又是一个客户端。平台制定一套主题规则（我们可以称之为 MQTT 接口），并订阅数据上报类接口的主题，然后只要设备使用该接口上报数据，平台就可以接收到数据。同理，设备若想要收到平台下发的数据，需要先订阅数据下发类接口的主题。

MQTT 消息基于文本传输，主要有以下三类消息：

CONNECT：当客户端想要和服务器建立连接时，需要发送一条 CONNECT 消息给服务器，消息内包含自己的用户名、密码等信息，服务器鉴权通过后，和客户端建立连接。若双方想要断开连接，则需要遵循 TCP 协议的四次挥手规则，才能正常断开连接。客户端在发送 CONNECT 消息时，还可以指定“最后遗愿（last will）”消息，包括消息的主题和内容。当服务器检测到客户端异常断开连接时，就会自动发布这条“最后遗愿”消息。

SUBSCRIBE：当客户端订阅主题时，需要发送一条 SUBSCRIBE 消息给服务器，指定要订阅的主题。MQTT 协议的主题表示为层次结构，类似文件系统，例如“/huawei/v1/devices”这种格式。同理，客户端可以通过 UNSUBSCRIBE 消息取消订阅指定主题。

PUBLISH：当客户端发布消息时，需要发送一条 PUBLISH 消息给服务器，指定消息的主题和内容。MQTT 对发布消息的内容格式不做限制，需要由各个服务提供商自行制定规范。客户端发布消息时可以指定该消息是否需要保留，一个主题只能保留一条消息，被保留的消息会被代理服务器记录，以后每个新订阅这个主题的客户端都会先接收到这条保留消息。

在可靠传输方面，MQTT 协议提供三种 QoS 等级的实现：

• QoS=0 表示消息只会被发送一次，但该消息可能会丢失。

• QoS=1 表示确保消息会到达至少一次，但可能会造成订阅者收到多条重复消息。

• QoS=2 表示确保消息会到达且仅到达一次。

QoS 等级越高，消息传输的可靠度越高，但实现也会越复杂，对网络和设备资源的占用也会变多，所以传输时选用哪个级别的 QoS 需要根据实际状况选择。

总结

在分别了解过 CoAP/LWM2M 协议和 MQTT 协议之后，我们可以得知，LWM2M 协议是基于 CoAP 协议的一种具体规范，而 MQTT 协议是不同于 CoAP 协议的另一种传输协议。

CoAP/LWM2M 协议基于 UDP 协议，服务器和客户端之间不保持连接；通信基于请求/响应模型，与互联网主流的 HTTP 协议相同，主要用于点对点的通信。CoAP/LWM2M 协议针对物联网场景定义了各种类型和标签，支持内容协商与发现，允许设备相互探测以找到交换数据的方式；报文为极简的二进制报文，长度更短，对设备和网络的要求更低。

MQTT 协议基于 TCP 协议，服务端和客户端之间保持连接；通信基于分布/订阅模型，可以简单实现多对多的通信场景。MQTT 协议设计简单，易于理解和学习；报文消息基于文本，消息负载格式无限制，自由度更高，更便于调测和排障时查看和理解，但同时也需要服务提供商制定通信规范（接口文档），设备之间才可进行有效通信。

综上所述，CoAP/LWM2M 协议和 MQTT 协议各有其特点，并不存在谁优谁劣，您需要根据自己的设备的应用场景选择最适合的协议。

本文转载自公众号华为 IoT 云服务（ID：hwiot0601）。

原文链接：

https://mp.weixin.qq.com/s/QIuRTTR7uQUa7Q7Fy1pF2Q