4、发现机制：CoAP协议在设备发现中的应用、局域网发现流程
设备发现，说白了就是让设备互相“打个招呼”。
我刚开始接触鸿蒙分布式软总线时，觉得设备发现不就是广播一下嘛，有什么难的？后来真动手做项目才发现，这里面坑不少。尤其是在复杂的局域网环境下，怎么让手机、平板、智能音箱这些设备快速找到彼此，还要省电、稳定，这就有讲究了。
4.1 为什么选CoAP？
你可能要问：HTTP不行吗？MQTT不行吗？
嗯，理论上都行。但鸿蒙选CoAP，是有道理的。
CoAP（Constrained Application Protocol）是专门为资源受限设备设计的。说白了，它就像HTTP的“轻量版”。HTTP跑在TCP上，CoAP跑在UDP上。UDP没有三次握手，没有重传机制，所以开销极小。
我举个例子你就明白了。一个智能灯泡，内存可能只有几百KB，CPU主频几十MHz。你让它跑HTTP？太吃力了。CoAP的报文头只有4个字节，而HTTP头动不动几百字节。你想想看，差距有多大。
核心对比：
| 特性 | HTTP | CoAP |
|---|---|---|
| 传输层 | TCP | UDP |
| 报文头大小 | 数百字节 | 4字节 |
| 请求/响应模型 | 同步 | 异步（支持观察者模式） |
| 资源发现 | 需额外实现 | 内置/.well-known/core |
我在项目中遇到过一个问题：用HTTP做设备发现，每次扫描都要建立TCP连接，耗时不说，还容易把设备搞死。换成CoAP后，一个UDP组播包发出去，所有设备都能收到，响应也快得多。
4.2 CoAP在设备发现中的角色
鸿蒙的设备发现，CoAP主要干三件事：
- 宣告存在：设备上线时，发一个CoAP组播消息，告诉局域网里所有设备“我来了”。
- 查询资源：通过
/.well-known/core接口，获取设备支持的服务列表。 - 状态更新：设备状态变化时（比如从空闲变成忙碌），通过CoAP通知其他设备。
说白了，CoAP就是设备之间的“传话筒”。它不负责业务逻辑，只负责把消息可靠地送到。
个人习惯：我一般会在CoAP的Payload里带上设备的类型、名称、IP地址和端口。这样接收方不用再额外查询，一步到位。
4.3 局域网发现流程
好，我们来看看完整的发现流程。我画了一张图，方便你理解。
流程其实不复杂，我拆解一下：
4.4 详细步骤拆解
第一步：组播发现
设备A上线后，向CoAP组播地址（通常是224.0.1.187:5683）发送一个GET请求，目标资源是/.well-known/core。
这个地址是CoAP协议规定的标准组播地址。所有支持CoAP的设备都会监听这个地址。
报文示例：
// 设备A发送的组播发现请求
GET coap://224.0.1.187:5683/.well-known/core
Accept: application/link-format
// 设备B的响应
2.05 Content
</light>;rt="light";if="core.light",
</temp>;rt="temperature";if="core.sensor"你注意看响应格式。它用的是link-format，这是CoAP资源发现的标准格式。每个资源用<>括起来，后面跟着属性。比如rt是资源类型，if是接口类型。
第二步：单播响应
设备B、C、D收到组播请求后，不会立即回复。它们会随机等待一段时间（0到几秒），然后再单播回复。这叫“响应抖动”，目的是避免所有设备同时回复，造成网络拥塞。
我曾经调试过一个项目，发现设备一多，网络就卡死了。后来查了半天，就是没有加响应抖动。所有设备同时回复，UDP包把缓冲区撑爆了。嗯，这个坑我踩过，你一定要注意。
第三步：确认与交互
设备A收到响应后，就知道了局域网里有哪些设备、每个设备提供什么服务。接下来，它可以根据需要，与特定设备建立连接，进行数据交换。
CoAP支持确认模式（CON）和非确认模式（NON）。对于设备发现这种场景，我建议用NON模式。为什么？因为发现消息丢了也无所谓，下次再发就行了。用CON模式反而增加开销。
注意：CoAP的组播消息只能用NON模式。CON模式在组播场景下会导致确认风暴，所有设备同时回复ACK，网络直接瘫痪。这个坑我亲眼见过，一个同事没注意，测试环境直接挂了。
4.5 鸿蒙的优化策略
鸿蒙在标准CoAP基础上，还做了一些优化：
- 缓存机制：设备发现结果会缓存一段时间。如果短时间内再次发现，直接走缓存，不用重新组播。
- 增量更新：设备状态变化时，只发送变化的部分，不用全量更新。
- 优先级排序：根据设备的历史连接质量，给设备打分。发现时优先返回高分设备。
这些优化，说白了就是为了让发现更快、更省电、更稳定。我在做智能家居项目时，用了这些优化后，设备发现时间从原来的3秒降到了0.5秒以内。用户体验提升很明显。
4.6 避坑指南
最后，分享几个我踩过的坑：
- 组播地址别写错：CoAP标准组播地址是
224.0.1.187，端口5683。写错了设备就找不到了。 - 防火墙要放行：有些路由器默认会拦截组播包。记得在防火墙里放行UDP 5683端口。
- 响应超时设置：组播发现不要等太久。我一般设2秒超时，收不到就认为设备不在线。
- Payload别太大：CoAP的Payload最大支持64KB，但组播场景下建议控制在1KB以内。太大了容易丢包。
好了，关于CoAP在设备发现中的应用，就讲到这里。你只要记住：CoAP是轻量级的HTTP，专为资源受限设备设计。鸿蒙用它做设备发现，既省电又高效。实际项目中，注意组播地址、响应抖动、Payload大小这几个点，基本就不会出问题。