定义与设计目标
CoAP（Constrained Application Protocol）是IETF专为物联网受限设备设计的应用层协议，基于UDP，提供类似HTTP的RESTful接口，支持GET/POST/PUT/DELETE，报文头最小仅4字节。CoAP适用于内存、算力、功耗受限的传感器、执行器等设备，常与6LoWPAN、NB-IoT等配合使用。
核心特性
技术特点
- 基于UDP：无连接、轻量，适合低功耗设备
- RESTful风格：与HTTP语义一致，易于迁移
- 观察模式：支持资源订阅，类似MQTT的发布订阅
- 与HTTP代理：可通过代理与HTTP互转，实现Web与IoT互通
- 可选DTLS：支持加密传输
与MQTT、HTTP对比
| 协议 | 传输层 | 模式 | 适用 |
|---|---|---|---|
| CoAP | UDP | 请求-响应/观察 | 受限设备、低功耗 |
| MQTT | TCP | 发布/订阅 | 持续连接、双向推送 |
| HTTP | TCP | 请求-响应 | 通用Web、REST API |
典型应用
智能家居、工业传感器、NB-IoT设备、6LoWPAN网络等场景的轻量级数据交互。适合资源受限、间歇性上报、请求-响应模式的场景。
达希物联的NB-IoT物联网卡常用于智能抄表、环境监测等低功耗场景，此类设备多采用CoAP或轻量级MQTT进行数据上报。CoAP基于UDP，在NB-IoT窄带环境下可减少连接建立开销，适合小数据包、间歇性上报。达希物联在为客户提供NB-IoT方案时，会结合设备协议栈（CoAP/MQTT/私有协议）进行选型建议，确保在受限网络条件下实现可靠、低功耗的数据传输。
消息类型和令牌号怎样配合去重
CoAP把可靠性和请求语义拆开。确认消息要求对端回一个应答或复位，非确认消息发完即走。同一请求的身份看令牌，而不是只看消息编号。编号用于匹配确认和重传，令牌用于把响应交回对应的请求。服务器若只按编号去重，重传改了编号就会执行两次开阀；客户端若重用旧令牌，会把上一次的响应当成这一次的结果。两个字段都要在未完成事务的生命周期内唯一。
复位消息表示对端根本不认识这个确认，常见于服务器重启后收到迟到的重传。客户端应放弃该事务并重新建立观察或请求，而不是把复位当成业务层的“禁止”。把复位重试成更密的确认，只会在窄带空口上放大无效流量。
确认重传的间隔要按指数拉开
确认消息超时后按指数增加等待再重传，并设有重传次数上限。间隔若固定且很短，丢包时会把同一请求堆进已经拥塞的小区。窄带链路上往返时间本身就长，初始超时若按局域网的几十毫秒去设，第一次响应还在路上，第二次重传已经发出，服务器看到重复请求。判断是超时设短了还是真的没送达：响应最终到达、且带着原来的令牌，多半是超时过激；一直只有重传没有响应，才去查地址和端口。
非确认消息没有这套重传。用它上报可丢的周期量，可以省掉应答的空口开销；用它下发关断命令，丢了也不会有人知道。关键指令应走确认消息，并在应用层保留一个幂等的执行序号，以便重传不会把阀门开关两次。
观察关系在休眠唤醒后容易被拆掉
观察模式让服务器在资源变化时主动把新表示推给客户端，客户端用观察选项登记。终端进入深休眠后，地址和端口映射可能失效，服务器仍按旧映射推送，推送失败几次就会取消观察。终端醒来若只读本地缓存，不会发现观察已经没了，云端也不再收到变化。判断条件是：登记之后的前几包正常，休眠周期一到就只剩单次查询能通。唤醒后应重新登记，或把推送改成终端自己按节奏读取。
达希物联的窄带物联网卡适合承载这种小请求，但卡的省电定时器会改变地址保持时间。CoAP观察的保活必须短于地址映射和休眠唤醒的间隔，否则协议层以为订阅还在，网络层已经没有返回路径。平台侧应把“观察仍登记”和“最近一包确认的时间”分开显示，避免用卡的在线状态代替应用订阅状态。
块传输的块号不能拿来代替确认编号
较大的载荷会被拆成块，每一块带自己的块号，请求是否可靠仍由消息类型和消息编号决定。只按块号去重，重传的同一块会因为编号变化被当成新块再写一次；只按消息编号去重，不同块又会被当成重复而丢弃。两个序号各管一件事：块号管载荷拼装，消息编号管这一次发送有没有被确认。服务器在块未到齐时不应执行写操作，否则重传会把寄存器写两次。
块的大小还要小于路径上的最小报文长度。窄带网络或带安全头的链路若小于客户端假设的块长，块会在下层再次被截断，CoAP层却以为一块已经完整。协商块大小时应取路径能稳定通过的长度，而不是取协议允许的最大值。达希物联窄带卡上的有效载荷更小，固件下载若走CoAP块传输，应把块长、确认超时和卡的省电周期一起算。省电周期若在块序列中间把终端叫醒到新地址，未完成的块序列应作废重来，不能从旧块号续传。