鸿蒙有一个很重要的特性–分布式通信系统。其通信协议使用的是coap协议。

COAP协议简介

Coap（Constrained Application Protocol）是一种在物联网世界的类web协议，它的详细规范定义在 RFC 7252。COAP名字翻译来就是“受限应用协议”，顾名思义，使用在资源受限的物联网设备上。物联网设备的ram，rom都通常非常小，运行TCP和HTTP是不可以接受的。

COAP协议特点

1. COAP协议网络传输层由TCP改为UDP。
   
2. 它基于REST，server的资源地址和互联网一样也有类似url的格式，客户端同样有POST，GET,PUT,DELETE方法来访问server，对HTTP做了简化。
3. COAP是二进制格式的，HTTP是文本格式的，COAP比HTTP更加紧凑。
4. 轻量化，COAP最小长度仅仅4B，一个HTTP的头都几十个B了。
5. 支持可靠传输，数据重传，块传输。 确保数据可靠到达。
6. 支持IP多播, 即可以同时向多个设备发送请求。鸿蒙的设备发现功能就是用的这个特性。
7. 非长连接通信，适用于低功耗物联网场景。
8. 支持观察模式

COAP协议消息类型

COAP协议有4种消息类型

• CON—— 需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。这有点像TCP，对方必须给确认收到消息，用以可靠消息传输。
  
• NON—— 不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。这适用于消息会重复频繁的发送，丢包不影响正常操作。这个和UDP很像。用以不可靠消息传输。

• ACK —— 应答消息，对应的是CON消息的应答。
• RST —— 复位消息，可靠传输时候接收的消息不认识或错误时，不能回ACK消息，必须回RST消息。

COAP消息格式

消息头（HEAD）

第一行是消息头，必须有，固定4个byte。
Ver : 2bit， 版本信息，当前是必须写0x01。
T： 2bit， 消息类型，包括 CON, NON. ACK, RST这4种。
TKL: 4bit，token长度， 当前支持0~8B长度，其他长度保留将来扩展用。
Code：8bit，分成前3bit（0_{7）和后5bit（0}31），前3bit代表类型。 0代表空消息或者请求码， 2开头代表响应码，取值如下：

0.00 Indicates an Empty message

0.01-0.31 Indicates a request.

1.00-1.31 Reserved

2.00-5.31 Indicates a response.

6.00-7.31 Reserved

Message ID：16bit， 代表消息MID，每个消息都有一个ID ，重发的消息MID不变

• token（可选）用于将响应与请求匹配。 token值为0到8字节的序列 ( 每条消息必须带有一个标记, 即使它的长度为零），通过TKL指定Token长度。 每个请求都带有一个客户端生成的token, 服务器在任何结果响应中都必须对其进行回应。token类似消息ID，用以标记消息的唯一性。token还是消息安全性的一个设置，使用全8字节的随机数，使伪造的报文无法获得验证通过。
• option（可选，0个或者多个）
  请求消息 与回应消息都可以0~多个options。 主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述，比如是否用到代理服务器、目的主机的端口、CoAP请求参数和负载媒体类型等。
• payload（可选）
  实际携带数据内容， 若有， 前面加payload标识符“0xFF”，如果没有payload标识符，那么就代表这是一个0长度的payload。如果存在payload标识符但其后跟随的是0长度的payload，那么必须当作消息格式错误处理。

COAP的请求方法（requests）和响应码(responses)

请求方法

【0.01】GET方法——用于获得某资源

【0.02】POST方法——用于创建某资源

【0.03】PUT方法——用于更新某资源

【0.04】DELETE方法——用于删除某资源

响应码

1、 Success 2.xx

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

• 2.01 Created
• 2.02 Deleted
• 2.03 Valid
• 2.04 Changed
• 2.05 Content

2、 Client Error 4.xx
这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

• 4.00 Bad Request
• 4.01 Unauthorized
• 4.02 Bad Option
• 4.03 Forbidden
• 4.04 Not Found
• 4.05 Method Not Allowed
• 4.06 Not Acceptable
• 4.12 Precondition Failed
• 4.13 Request Entity Too Large
• 4.15 Unsupported Content-Format

3、 Server Error 5.xx
这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器的软硬件资源无法完成对请求的处理。

• 5.00 Internal Server Error
• 5.01 Not Implemented
• 5.02 Bad Gateway
• 5.03 Service Unavailable

媒体类型

• 【text/plain】 编号为0，表示负载为字符串形式，默认为UTF8编码。
• 【application/link-format】编号为40，CoAP资源发现协议中追加定义，该媒体类型为CoAP协议特有。
• 【application/xml】编号为41，表示负载类型为XML格式。
• 【application/octet-stream】编号为42，表示负载类型为二进制格式。
• 【application/exi】编号为47，表示负载类型为“精简XML”格式。
• 【applicaiton/cbor】编号为50，可以理解为二进制JSON格式。

CoAP的URL

coap的url和HTTP的有很相似的地方，开头是“coap”对应“http”或者“coaps”对应“https”。
HTTP的默认端口是tcp 80，coap的默认端口是udp 5683（coaps是5684）。

下面三个URL的地址是一样的。访问example.com这个域名，端口是udp 5683，访问的资源地址是~sensors/temp.xml。

coap://example.com:5683/~sensors/temp.xml

coap://EXAMPLE.com/%7Esensors/temp.xml

coap://EXAMPLE.com:/%7esensors/temp.xml

COAP的安全性

COAP的安全性是用DTLS加密实现的。DTLS的实现需要的资源和带宽较多，如果是资源非常少的终端和极有限的带宽下可能会跑不起来。DTLS仅仅在单播情况下适用。

鸿蒙设备发现

用户使用发现功能时，需要保证发现端设备与被发现端设备在同一个局域网内，并且互相能收到对方以下流程的报文。
（1） 发现端设备，发起discover请求后，使用coap协议在局域网内发送广播。报文如下：
（2）被发现端设备使用PublishService接口发布服务，接收端收到广播后，发送coap协议单播给发现端。报文格式如下：