想象一支由“口袋信使”组成的队伍——它们是低功耗传感器，口袋里只有几 KB 内存，电池要撑好几年，无线链路还时好时坏。如果要它们像普通网站那样用 HTTP 通信：先三次握手“搭电话线”，再寄一封几百字节的挂号信，信使还没走出两步，口袋就被掏空了。于是 IETF 在 2014 年发布了 CoAP（受限应用协议）——一套专为“口袋信使”设计的小纸条暗号系统。它保留 HTTP 的 REST 理念，却把跑车拆成了自行车：运行在 UDP 上不用搭线路，头部最少 4 字节，重要纸条要回执（CON），例行纸条随手一丢（NON），长信撕成几页送（Blockwise），怕偷看就上密语本（DTLS）。读完这篇文章，你会彻底理解这套小纸条系统如何撑起智能家居、工业物联网与边缘 AI 的数据通路。

岗位关联

想驾驭低功耗设备的“最后一公里”，CoAP 是绕不开的传令官——理解它，你才能真正理解物联网数据从哪里来、如何高效到达 AI 的嘴边。

目录
  1. 可视化演示
  2. 协议诞生背景
  3. RESTful设计
  4. 消息模型
  5. 资源发现机制
  6. Blockwise传输
  7. 安全机制
  8. 应用场景
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示CoAP协议消息模型、Blockwise分块传输、DTLS安全握手与低功耗对比，切换模式查看IoT通信核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

CoAP消息模型：RESTful over UDP CON确认/NON非确认消息类型 消息ID(16bit)+Token匹配请求响应 MID = 16bit, Token = 0-8B 基于UDP的轻量RESTful协议，消息头部仅4字节

协议诞生背景

想象一支由口袋信使组成的队伍——他们是低功耗传感器，口袋里只有几 KB 内存，电池要撑好几年。他们给总部汇报消息时，如果强行用 HTTP 那套：先三次握手搭一条“电话专线”，再寄一封几百字节的挂号信，信使还没走出两步，口袋就被掏空了。这并非玩笑，真实物联网节点常只有约 10KB 可用 RAM 与 100KB 程序存储，无线链路丢包率可达 10% 甚至更高。

TCP 三次握手和 HTTP 庞大的文本头部，对这些信使而言是奢侈的负担。于是 IETF 的 CoRE 工作组在 2014 年发布了 RFC 7252：CoAP 协议，专为“口袋里的小信使”设计。它保留了 HTTP 的 REST 思想，却把运行底座从 TCP 换成 UDP。UDP 不需要建立连接，发一条数据报就像随手塞一张纸条，省去握手开销。

CoAP 报文头部最少只要 4 字节，而 HTTP 请求行加头部通常超过 100 字节。在同等的发送任务下，CoAP 的能量开销往往只是 HTTP 的零头。以头部尺寸对比为例：

正是靠着这张“小纸条”级别的开销，口袋信使才能背着纽扣电池走完几年巡检路。有了 CoAP，传感器不必再仰望 HTTP 那套重型邮路，世界从此轻装出发。

Scoap=4∼10 bytes,Shttp>100 bytesS_{\text{coap}} = 4\sim 10\ \text{bytes}, \qquad S_{\text{http}} > 100\ \text{bytes}
对比两个协议的报文头部尺寸：CoAP 短小精悍，HTTP 臃肿庞大。
  1. CoAP 头部长度一条最基本的 CoAP 消息只需 4 字节固定头，算上常用选项也只有 10 字节左右。
    Scoap=4 (base)+n×1 (options)S_{\text{coap}} = 4\ \text{(base)} + n \times 1\ \text{(options)}
  2. HTTP 头部长度请求行、Host、Connection 等文本字段累加起来，通常超过 100 字节。
    Shttp=∑ilen⁡(headeri)>100 bytesS_{\text{http}} = \sum_{i} \operatorname{len}(\text{header}_i) > 100\ \text{bytes}

RESTful设计

小纸条也有自己的“格式礼仪”。虽然省纸，但信纸上仍然写着明确的收件人地址——这就是 REST 的地址系统：每个能访问的东西都是一个资源，资源有一个 URI 编号。REST 是 HTTP 世界的成熟架构风格，CoAP 把它原汁原味搬到了受限设备上：客户端与服务器以“资源”为中心交互，而不是以“命令”为中心——发什么指令不重要，改资源状态才重要。

CoAP 定义了四种方法与 HTTP 一一对应：GET 读取资源状态、POST 触发操作或新增子资源、PUT 整体替换资源、DELETE 删除资源。URI 的写法也很眼熟，例如 coap://192.168.1.20/sensors/temp。而 HTTP 的头部字段被压缩成紧凑的 Option：Uri-Path 选项逐段表示路径，Content-Format 表示负载格式，Observe 用于订阅资源变化。

小纸条虽然小，但地址和动作一应俱全。正因为它贴近 REST 的通用礼仪，传感器网络和互联网之间才可以通过代理顺畅地互相转信。

MCoAP={GET, POST, PUT, DELETE}\mathcal{M}_{\text{CoAP}} = \{ \text{GET},\ \text{POST},\ \text{PUT},\ \text{DELETE} \}
CoAP 提供与 HTTP 相同的四类操作动词，方便开发者把 Web 经验平移过来。
  1. 方法集合定义协议的可用操作集合，每个方法对应一类语义。
    MCoAP={GET,POST,PUT,DELETE}\mathcal{M}_{\text{CoAP}} = \{ \text{GET}, \text{POST}, \text{PUT}, \text{DELETE} \}
  2. GET 语义幂等查询，不改变资源状态。
    GET⁡(r)→rstate\operatorname{GET}(r) \rightarrow r_{\text{state}}
  3. PUT 语义整体替换资源，是幂等写操作。
    PUT⁡(r,v)→r:=v\operatorname{PUT}(r, v) \rightarrow r := v

消息模型

小信使传纸条时有两种截然不同的心情：写“重要事项”的纸条，一定要对方回个收到；写“例行通知”的纸条，手指一弹就完事。CoAP 把这两种心情做成了两种消息：CON 和 NON。CON（Confirmable，可确认消息）发出后发送方启动重传计时器：等不到 ACK 就再发一次，重复次数约 4 次，退避时间指数翻倍——对应纸条上“没收到回执就一直补寄”。

ACK（Acknowledge，确认消息）是对方的回执，而且回执里可以直接捎带响应的内容，省一趟腿。NON（Non-confirmable，非确认消息）发出后不需要任何应答，适合温度、湿度这类周期性上报：每 10 秒一次，丢一条下一条马上补上。RST（Reset，复位消息）则用来拒绝不认识的请求。报文头里的 Message ID 负责去重和配对 ACK，Token 则把某个请求和对应响应“对上号”，避免同时发多个请求时张冠李戴。

假设无线链路单次送达率为 \(p\)，最多尝试 4 次，则一条 CON 消息最终被送达的概率：

CoAP 的心情拿捏得很准：重要的纸条翻来覆去地寄，例行公事的纸条轻轻一丢。这份“懂取舍”，正是它比 HTTP 更省电却依然可靠的关键。

PdeliverCON=1−(1−p)4P_{\text{deliver}}^{\text{CON}} = 1 - (1-p)^{4}
这是“重复寄信直到回执”模型的数学表达：四次独立尝试中至少一次成功的概率。
  1. 单次失败概率无线链路单次发送失败的概率为 \(1-p\)。
    Pfail(1)=1−pP_{\text{fail}}^{(1)} = 1-p
  2. 四轮全部失败四次尝试相互独立，全部失败的概率是 \((1-p)^4\)。
    Pfail(4)=(1−p)4P_{\text{fail}}^{(4)} = (1-p)^4
  3. 至少一次成功用 1 减去全部失败的概率，得到最终送达率。
    PdeliverCON=1−(1−p)4P_{\text{deliver}}^{\text{CON}} = 1-(1-p)^4

资源发现机制

新来的小信使到了陌生街区，第一步总想知道：这里都有哪些住户、谁家是花园、谁家是厨房？CoAP 为这类“认门”需求安排了一个固定目录：/.well-known/core。客户端只要对这个固定路径发一个 GET 请求，服务器就会返回一份资源列表。列表用什么格式写？CoRE Link Format——一种比 HTML link 更精简的链接描述语法。

每条资源记录形如 </sensors/temp>;rt=temperature-c;if=sensor：尖括号里是资源路径，分号后是属性。rt 表示资源类型，if 表示资源接口，sz 表示资源最大尺寸。客户端还可以带查询参数，例如 GET /.well-known/core?rt=temperature-c——只关心温度类资源，省得把整个通讯录看一遍。

有了这本通讯录，设备加入网络后无需人工配置就能找到“邻居”。物联网络的大规模自动组网，正是从这一页小小的目录开始的。

rmatch(r,q)=1[rt(r)=q]r_{\text{match}}(r, q) = \mathbb{1}\bigl[ rt(r) = q \bigr]
一条资源只有当其类型等于查询条件时才被返回，这就是按需过滤。
  1. 资源集合服务器上有若干资源 \(r\)，每个资源带有 \(rt\) 属性描述类型。
    r∈R,rt(r)=资源类型r \in R,\quad rt(r) = \text{资源类型}
  2. 过滤条件请求中的查询变量 \(q\) 指定客户端需要的类型。
    q=temperature-cq = \text{temperature-c}
  3. 匹配判定逐条比对，类型相等才纳入结果，输出 1 否则输出 0。
    rmatch(r,q)=1[rt(r)=q]r_{\text{match}}(r,q) = \mathbb{1}[rt(r)=q]

Blockwise传输

传纸条也有物理上限：折得太厚，塞不进 UDP 这扇窄门。IPv6 环境下每个链路的最小 MTU 通常按 1280 字节规划，UDP 报文一旦超过路径 MTU，就可能在途中被撕碎或直接丢弃。CoAP 的做法很朴素——长纸条撕成几页，每页标注页码，按顺序递送，收齐后拼成完整内容，这就是 Blockwise 传输。

实现上通过两个选项协作：Block1 处理请求体的分块（比如向设备上传配置），Block2 处理响应体的分块（比如下载固件）。每个块选项包含三个字段：NUM 是块序号，M 表示是否还有后续块，SZX 决定块大小。实际块大小按 \(2^{\text{SZX}+4}\) 计算，比如 SZX=6 时块大小就是 1024 字节。发送方与接收方依靠块序号协商推进，直到 M=0 的最后一页到达。

对上层应用来说，分不分页完全透明——应用只管交出整封信，Blockwise 在底层默默完成撕页和拼页。这正是“长内容不怕窄链路”的答案。

N=⌈LpayloadSblock⌉N = \left\lceil \frac{L_{\text{payload}}}{S_{\text{block}}} \right\rceil
大负载被拆成的总块数：负载总长除以单块长度，向上取整保证能装下最后一块。
  1. 负载总长待传输完整数据的总字节数。
    LpayloadL_{\text{payload}}
  2. 单块大小由 SZX 指数换算出的块容量。
    Sblock=2SZX+4S_{\text{block}} = 2^{\text{SZX}+4}
  3. 总块数负载除以单块大小，向上取整，确保最后一块也有位置安放。
    N=⌈Lpayload/Sblock⌉N = \left\lceil L_{\text{payload}} / S_{\text{block}} \right\rceil

安全机制

小纸条裸奔在无线信道里，等于是把家底写在明信片上。CoAP 本身只管格式和流程，加密这把锁还要请专业锁匠来装——它就是 DTLS。DTLS（Datagram Transport Layer Security）是 TLS 的 UDP 版本。TLS 依赖 TCP 提供有序可靠的传输，换成 UDP 后，握手阶段必须自己处理乱序和丢包；DTLS 还引入 cookie 机制防止伪造源地址的放大攻击。

把 CoAP 跑在 DTLS 之上，就得到了 CoAPs，默认端口 5684，对应 HTTP 与 HTTPS 的关系。DTLS 提供三种认证方式：PSK 预共享密钥只需在设备里烧录一串口令，握手最快，最贴合低功耗设备；RPK 原始公钥省去证书链，中等成本；X.509 证书体系最重最完整，适合管理能力强的设备。物联网设备通常优先选 PSK。对 AI 工程师来说，可以在较高的抽象层享受同样的加密通道，而不必操心密钥协商细节。

有了 DTLS 这层密语本，连最穷酸的信使也能送出旁人看不懂的密信。低功耗、可恢复、防窃听——CoAPs 让受限设备第一次拥有了“上锁的纸条”。

Etotal(DTLS)=Ehandshake+EsessionE_{\text{total}}(\text{DTLS}) = E_{\text{handshake}} + E_{\text{session}}
DTLS 的总体能耗分为一次性握手开销和持续会话开销两部分，握手越轻，设备越省电。
  1. 握手开销建立 DTLS 会话时交换密钥产生的能耗与延时。
    Ehandshake≈2Etx+EcpuE_{\text{handshake}} \approx 2 E_{\text{tx}} + E_{\text{cpu}}
  2. 会话开销每条数据报文额外增加的加密与解密成本。
    Esession=Npkt×ecryptoE_{\text{session}} = N_{\text{pkt}} \times e_{\text{crypto}}
  3. 总能耗两者求和，得到整个安全会话的能耗模型。
    Etotal=Ehandshake+EsessionE_{\text{total}} = E_{\text{handshake}} + E_{\text{session}}

应用场景

今天，这套小纸条体系已经渗透进世界的各个角落。凡是电池小、链路窄、设备多的场景，几乎都能看到 CoAP 的身影。在智能家居领域，智能灯泡、温控器、门锁都暴露成 REST 资源，手机 App 通过网关用 CoAP 开关和控制；在工业物联网中，振动、温度传感器以 NON 消息周期性上报数据，边缘节点负责汇聚和异常检测；在智慧农业中，土壤传感器和灌溉阀构成一张低功耗局域网。

运营商级的 LPWAN 也常把 CoAP 当作应用层协议，让海量设备共用有限带宽。而和 AI 结合时，CoAP 的价值体现在数据供给：传感器状态经 CoAP 快速到达边缘网关，边缘 AI 完成推理，再把控制信号以 CoAP 命令发回设备——一条实时闭环通路就此打通。一个链路能容纳多少设备，可以用容量公式估算：

小纸条系统的规模可以被公式算得明明白白：带宽有限、周期有限，CoAP 把每次开销压到最低，于是能容纳的设备数被提到最高。这就是它作为 IoT 传令官的最大价值。

Ndevice=⌊Blink×TreportSreport⌋N_{\text{device}} = \left\lfloor \frac{B_{\text{link}} \times T_{\text{report}}}{S_{\text{report}}} \right\rfloor
单链路可容纳的最大设备数：链路带宽乘上报周期，除以单次上报的总字节数。
  1. 链路带宽接入网可用的总速率，单位比特每秒。
    BlinkB_{\text{link}}
  2. 上报周期每台设备的两次上报之间的时间间隔。
    TreportT_{\text{report}}
  3. 单设备占用一个周期内单台设备产生多少比特。
    Sreport=(Scoap+Spayload)×8S_{\text{report}} = (S_{\text{coap}} + S_{\text{payload}}) \times 8
  4. 设备容量链路在一个周期内能塞下多少个这样的循环，向下取整。
    Ndevice=⌊BlinkTreport/Sreport⌋N_{\text{device}} = \left\lfloor B_{\text{link}} T_{\text{report}} / S_{\text{report}} \right\rfloor

AI 应用场景

智能家居的“说走就走”指令下发

阶段：设备接入与指令闭环

解决的问题：传统智能家居网关各自为政，手机 App 只能适配自家硬件；改用 CoAP 后，任何设备只要暴露成 REST 资源，App 通过网关就能统一开关，CON 消息失败自动重试，体验稳定。

具体案例：用户在公司点“回家模式”，云端经网关向门锁、空调、灯光分别发 CoAP PUT 请求。空调立刻回 ACK 确认，门锁超时后自动重传第二次，最终全部成功，全程只增加几 KB 网络流量。

工业预测性维护的“数据滴灌”

阶段：数据采集与边缘推理

解决的问题：传统旋转机械监测靠人工巡检，漏检率居高不下；振动传感器用 NON 消息每 10 秒上报一次，边缘 AI 用异常检测模型捕捉早期故障信号，日志与固件大文件则用 Blockwise 分块上传。

具体案例：电机轴承初现磨损，传感器上报的频谱特征被边缘节点捕捉，AI 模型判定为早期故障，网关随即发出 CoAP 写请求调整运行参数，避免了一次非计划停机。

智慧农业的低功耗遥测网络

阶段：端侧感知与决策执行

解决的问题：传统农业监测方案电缆布线昂贵、更换电池频繁；CoAP 配合 DTLS 与设备休眠机制，让两节 AA 电池撑满一年，同时保证数据加密可信。

具体案例：大棚里 50 个土壤湿度传感器通过 CoAP 上报数据到边缘服务器，季节预测模型算出最优灌溉量，再以 CoAP POST 请求触发电磁阀开关，实现按需浇水。

Python 演示

python36 行
import asynciofrom aiocoap import Context, Messagefrom aiocoap.numbers.codes import Code  async def discover_resources(host: str):    protocol = await Context.create_client_context()    msg = Message(        code=Code.GET,        uri=f"coap://{host}/.well-known/core",    )    resp = await protocol.request(msg).response    print("资源发现结果：")    print(resp.payload.decode())    await protocol.shutdown()  async def read_temperature(host: str):    protocol = await Context.create_client_context()    msg = Message(        code=Code.GET,        uri=f"coap://{host}/sensors/temperature",    )    resp = await protocol.request(msg).response    print("温度读数：", resp.payload.decode())    await protocol.shutdown()  async def main():    host = "127.0.0.1:5683"    await discover_resources(host)    await read_temperature(host)  if __name__ == "__main__":    asyncio.run(main())
目的：用 aiocoap 库演示 CoAP 客户端的两个核心动作——先请求 /.well-known/core 发现资源，再读取温度资源的值。
  1. Context.create_client_context()创建 CoAP 客户端会话，相当于准备好一叠空白小纸条和信封。
  2. Message(code=Code.GET, uri=...)构造一个 GET 请求消息，URI 就是纸条上的收件人地址。
  3. protocol.request(msg).response发送请求并等待响应，CON 语义下协议栈会自动处理重传和超时。
  4. resp.payload.decode()取出响应体文本，服务器传回的资源描述或温度读数就在这里。
  5. asyncio.run(main())用异步事件循环串起两个协程任务，符合 CoAP 高并发低阻塞的通信风格。

常见误区

误区“CoAP 是局域网里传感器对传感器用的协议，跟云平台、浏览器都没关系，想上互联网还得换 HTTP。”

正解CoAP 的 REST 设计天然适配代理转发。通过 CoAP-to-HTTP 代理（RFC 8075），CoAP 资源可以等价地暴露成 HTTP 资源，云端或浏览器直接访问，协议转换由代理完成。小纸条和挂号信之间有一座翻译驿站，不需要设备自己“改口”。

为何常见：常见教程多在局域网内做传感器与网关演示，很少展示代理上云，导致初学者误以为 CoAP 走不出局域网。

误区“既然叫确认消息，那 CON 就代表绝对可靠，发出去必然会被服务器收到，我可以在应用层高枕无忧。”

正解CON 只承诺“发送方会重传”——默认最多约 4 轮尝试，采用指数退避。如果链路持续恶化，最终依然超时失败，上层必须准备兜底逻辑。它像是挂号信：邮局会多试几次，但不会为了你无限期送下去。

为何常见：把“可靠传输”等同于“绝不丢失”，忽略了重传次数和超时边界这两个物理约束。

误区“既然 CON 更可靠，那所有消息都应该发 CON，NON 这种不确认的消息没有存在价值。”

正解NON 适合周期性上报场景——温湿度每 10 秒一条，丢一条下一条马上补位，不需要重传浪费能量。消息层仍然用 Message ID 去重，避免重复处理。这是“例行通知纸条”的精髓：不值得为每条废话都跑一趟回执流程。

为何常见：新手只盯着“可靠”两个字，忽略了功耗与信道占用在低功耗设备上是更稀缺的资源。

误区“Blockwise 把大文件分块传输，那我在应用层收到一堆小块，得自己维护序号、拼回完整数据。”

正解Blockwise 是 CoAP 协议栈内部机制。应用层以完整负载为单位收发数据，分块、编号、拼接全部由协议栈（如 aiocoap、libcoap）透明完成。开发者写的代码和普通 CoAP 请求没有区别，就像你寄长信时不用自己折页编号。

为何常见：概念名叫“分块传输”，很容易让人误以为分块逻辑属于业务代码，实际上它属于底层通信库。

误区“UDP 是裸奔的协议，CoAP 又没有 TLS，那物联网设备的数据岂不是任人窃听？”

正解CoAP 把安全专门交给 DTLS——UDP 版的 TLS。运行在 DTLS 之上的 CoAP 叫 CoAPs，默认端口 5684，提供加密与双向认证。低功耗设备常用 PSK 预共享密钥模式，握手开销小且安全性足够。小纸条虽然轻，照样可以包上一层密语本。

为何常见：简单类比“UDP 不可靠”导致以偏概全，忽略了 DTLS 这一专门为 UDP 定制的安全层。

面试题

Q1. CoAP 默认运行在哪个传输层协议之上？

单选题 · easy

  • A.TCP（可靠但连接开销大）
  • B.UDP（轻量且无需握手）← 正确答案
  • C.QUIC（新兴通用传输层）
  • D.WebSocket（全双工通信协议）

答案：B。CoAP 专为受限设备设计，选择 UDP 作为底座，省去 TCP 三次握手和连接维护的开销。TCP 的可靠性可以让上层用 CON/ACK 机制自己实现，QUIC 和 WebSocket 都太重，不适合小信使的口袋。

Q2. CoAP 的默认端口是多少？

单选题 · easy

  • A.5683 作为默认端口← 正确答案
  • B.5684 作为安全端口
  • C.8080 是 HTTP 代理端口
  • D.1883 是 MQTT 常用端口

答案：A。CoAP 默认端口是 5683；5684 是运行在 DTLS 之上的 CoAPs 端口，属于加密版本。8080 是 HTTP 常用替代端口，1883 是 MQTT 的默认端口，三者都不是 CoAP 的默认端口。

Q3. 关于 CON 消息，下列说法正确的是？

单选题 · mid

  • A.发送后需等待 ACK 确认← 正确答案
  • B.发送后不需要任何回应
  • C.只能由服务器主动发出
  • D.传输过程中一定可以送达

答案：A。CON（可确认消息）发送后启动重传计时器，直到收到 ACK 才算完成，类似挂号信等回执。B 是非确认消息 NON 的特征，C 错误因为客户端服务器都能发，D 错误因为重传次数有限，极端恶劣链路下依然会失败。

Q4. CoAP 支持哪些 REST 方法？

多选题 · mid

  • A.GET 查询资源当前状态← 正确答案
  • B.POST 创建或触发资源动作← 正确答案
  • C.PUT 整体替换资源内容← 正确答案
  • D.DELETE 删除指定资源← 正确答案

答案：ABCD。CoAP 完整映射了 REST 四类动词：GET 读取、POST 新建或触发、PUT 整体替换、DELETE 删除。这与 HTTP 的方法体系一一对应，是 CoAP 能通过代理平滑转换到 HTTP 的基础。

Q5. 资源发现机制的固定目录路径是什么？

单选题 · mid

  • A./.well-known/core← 正确答案
  • B./sensors/temperature
  • C./discovery/service
  • D./config/registry

答案：A。CoAP 规定客户端向 /.well-known/core 发起 GET 即可获取资源目录，这是 IETF 约定的“通讯录地址”。B 是具体资源的示例路径，C 和 D 是自定义路径，并非标准规定位置。

Q6. Blockwise 传输的主要目的是什么？

单选题 · mid

  • A.压缩数据从而节省存储空间
  • B.控制报文符合 MTU 限制← 正确答案
  • C.加密数据防止被窃听
  • D.加快确认响应的速度

答案：B。UDP 报文过大容易超过路径 MTU 被丢弃，Blockwise 将大负载拆成多个小报文依次传输，保证每块都能顺利抵达。它不负责压缩（A 错）、不负责加密（C 错）、也不加快响应（D 错）。

Q7. CoAP 的安全层协议是哪个？

单选题 · easy

  • A.DTLS 适配 UDP 的加密层← 正确答案
  • B.TLS 基于 TCP 的加密层
  • C.SSL 老一代的安全协议
  • D.IPsec 网络层的加密隧道

答案：A。UDP 上无法直接套用 TLS，DTLS 是 TLS 的 UDP 版本，专门为不可靠传输设计，支持 cookie 防放大攻击。TLS 依赖 TCP，SSL 已过时，IPsec 工作在更低层，都不是 CoAP 的标准安全层。

Q8. 关于 NON 消息，下列哪些说法正确？

多选题 · hard

  • A.适合周期性传感器上报← 正确答案
  • B.不依赖 ACK 应答确认← 正确答案
  • C.消息仍可携带 Token← 正确答案
  • D.比 CON 消息更耗电能

答案：ABC。NON 消息发出后无需确认，省去重传开销，特别适合温湿度这类定时上报场景；它依然可以携带 Token 供应用层匹配请求与响应。D 说反了，NON 因为不重传，通常比 CON 更省电。

Q9. CoAP 客户端如何匹配某个请求对应的响应？

单选题 · hard

  • A.通过 Token 选项匹配请求← 正确答案
  • B.通过源端口号进行匹配
  • C.通过消息 ID 全局去重
  • D.通过目标地址进行匹配

答案：A。Message ID 只用于消息层去重和配对 ACK/RST，不能区分同一个端点上的不同请求；Token 才是请求与响应之间的“身份证”，帮助客户端在并发多个请求时对号入座。源端口和目标地址只能定位到主机，无法区分具体请求。

Q10. 以下哪些属于 CoAP 的适用场景？

多选题 · hard

  • A.智能断路器的开关控制← 正确答案
  • B.温湿度传感器的定时上报← 正确答案
  • C.服务器间大规模文件同步
  • D.低功耗设备固件升级传输← 正确答案

答案：ABD。智能开关（A）和温湿度上报（B）是典型小消息、低功耗场景；固件升级（D）虽然数据量大但可用 Blockwise 分块传输，且升级频率低，CoAP 完全胜任。C 服务器间大规模文件同步要求高吞吐高可靠，TCP/HTTP 更合适，CoAP 的受限设计反而成为瓶颈。