摘要

  • 在基于 UDP 的 CoAP 中，Message ID 用于发现重复报文并关联 ACK/Reset；Token 连同相应端点信息，用于把响应归入尚未结束的请求。两者服务于不同状态机。
  • Token 匹配只是一张关联回执，不能单独证明对端是谁、谁拥有设备、请求是否获准、资源是否仍为当前状态，或应用与物理动作是否完成。

设想一条生产日志：token_match=true, identity_verified=true, operation_success=true。三个布尔值写在同一行，看起来像一条完整因果链。实际上，只有第一个值可能直接来自 CoAP 的 Token 规则。后两个判断需要安全会话、授权引擎、资源版本、事务提交或设备反馈等别的证据。

把三个值绑在一起，不是“补全上下文”，而是让一个短字段替其他参与者发言。

Carsten Bormann 在这条边界上的公开贡献有明确文献。RFC 7252 的三位作者是 Zach Shelby、Klaus Hartke 和 Carsten Bormann；它定义了 CoAP 的 Message ID 与 Token。RFC 8323 的作者名单以 Bormann 开头；它把 CoAP 放到 TCP、TLS 和 WebSockets 上。可靠传输接管重传与去重后，CoAP 删除 Type 和 Message ID，却保留 Token。

这个差异比“Token 是请求标识符”更直观：能随传输变化而删除的字段，和必须留在请求响应层的字段，本来就不是同一件事。

Message ID 回答的是“这份报文见过吗”

UDP 可能丢包，也可能让同一报文多次到达。Confirmable 报文在没有及时收到 ACK 时会重传。接收方因此可能在 EXCHANGE_LIFETIME 内，从同一源端点看到相同 Message ID 的副本。

RFC 7252 要求 ACK 或 Reset 回显对应的 Message ID，并把端点信息纳入匹配条件。对重复的 Confirmable 报文，接收方通常应再次确认，但只处理其中承载的请求或响应一次。Message ID 的 16 位空间、同一端点内的禁用重用窗口、重传计时器和去重缓存共同构成一套短期状态。

它没有回答“这是同一个用户吗”。源地址和端口也不是人的签名。NAT 可能改写端点，进程重启可能重置生成器，不同端点可以使用相同数值。Message ID 最多帮助一台实现判断某个报文交换是否已出现，以及一个 ACK/Reset 属于哪个报文。

如果应用在收到同一请求副本时执行两次扣款或两次开阀，问题不能只归到网络“重复发送”。CoAP 的去重证据和应用的幂等性记录必须分别检查。报文只处理一次，也不自动证明数据库或物理世界只改变一次。

Token 回答的是“这份回应归到哪项等待”

Token 由客户端生成，服务器在任何由该请求产生的响应中原样回显。客户端再结合相应端点信息，把响应同本地仍在等待的请求对应起来。RFC 7252 甚至指出，它原本可以叫作“request ID”。

“本地”是最重要的限定。当前在用的 Token 应在一个源/目的端点对内保持唯一，而不是全网唯一。不同端点可以复用同一值。严格串行、没有其他并发 Token 的场景甚至可以使用空 Token。收到自己没有生成的 Token 的端点必须将它当作不透明字节，不得假设内容和结构。

因此，服务器原样回显 Token 时没有签发身份证明。它没有确认字节里编码的客户号、设备号或业务状态。那些含义即使由客户端私下定义，也只属于客户端自己的恢复逻辑。

在 piggybacked 响应里，ACK 与 Confirmable 请求的 Message ID 匹配，响应与请求的 Token 也匹配。分离响应则用 Token 维持请求语义的连续性，而新报文拥有自己的 Message ID。把两个字段都归并为 transaction_id，就再也无法知道失败发生在报文层还是请求层。

可靠传输做了一次自然的对照试验

TCP 提供可靠、有序的字节流。RFC 8323 为 CoAP 增加帧长度，但不再需要 UDP 版本的 CON/NON/ACK/RST 机制，也不再需要 Message ID。Token 仍然存在，因为 TCP 只知道字节顺序，不知道哪个 CoAP 响应满足哪个并发请求。

这为故障定位提供了一组很实用的对照：

  • 只在 UDP 出现的异常，优先检查 Message ID 重用、重传、ACK、去重缓存与交换寿命。
  • UDP 与 TCP/TLS 都出现的错误，优先检查 Token 生成、请求等待表、端点或连接绑定、代理映射与响应处理。
  • 只在经过网关时出现的错配，优先检查跳间映射，不要把源服务器侧的 Token 直接当作终端客户端的标识。

TLS 可能在配置正确时提供对端认证。那是安全会话给出的结论，不是 Token 自己发生了身份升级。会话可以更新，Token 可以过期，请求也可以被取消。只有分开的字段才能按各自寿命撤销结论。

随机 Token 防的是盲猜回应

没有传输层安全时，RFC 7252 建议客户端使用非平凡的随机 Token。面向一般互联网的客户端应考虑至少 32 位随机性。目的很具体：让不在路径上、看不到请求的攻击者更难猜中等待中的 Token，从而更难注入被接受的伪造响应。

Message ID 在这种防护中的帮助很小，因为它通常按顺序分配，容易猜测；攻击者还可以发送不依赖原请求 Message ID 的分离响应。

随机 Token 因而像一次局部挑战，但不能因此称为认证凭证。路径上的观察者能够看到它，代理掌握自己一跳内的值，弱随机源可能重复，过期状态也可能错误接收迟到响应。匹配事件必须同时记录 Token 长度、生成策略、端点、等待寿命、观察位置和安全模式，才足以说明它抵挡了什么。

日志若只保留 authenticated_by_token，会把威胁模型删除。名称变得自信，系统却失去复核能力。

每一跳都有自己的 Token 名字空间

CoAP Token 是逐跳机制。中间件收到客户端请求后，通常保存客户端 Token 与传输地址，再使用自己的 Token 向源服务器发起另一项请求。源端响应到来时，它查询本地映射，把结果送回下游。

因此，设备侧抓到的 Token 可能从未出现在用户侧链路。反过来，两个跳使用相同字节也不证明它们是同一个全局对象。重建链路需要中间件保存下游记录、上游记录和一项本地连接关系，标明接口、时间、超时和软件版本。

运营平台可以额外生成全局 UUID，方便跨服务跟踪。但这个 UUID 是平台写入的派生对象。它的可信度来自映射代码、时钟、存储和权限控制，不能伪装成 CoAP 在端到端线路上提供的事实。

这里还有隐私边界。为了关联，不一定要长期存储原始 Token。带密钥的摘要或受控内部索引可能已经够用。将短时协议值永久绑定设备身份，会创造协议本身没有要求的追踪面。

“无状态”只是把一部分状态换了位置

RFC 8974 允许客户端把每项请求的部分状态序列化进更长的 Token，服务器原样回传后，客户端恢复这些信息。该 RFC 的作者是 Klaus Hartke 与 Michael Richardson，不是 Bormann；它在本文中只用于检验早期机制扩展后的责任边界。

文档明确说，“stateless”是过度简化。客户端仍要保存每台服务器的状态、Token 生成状态和拥塞控制状态；UDP Confirmable 报文仍需要交换状态。若客户端依赖扩展 Token，还必须先用有状态方式发现服务器支持，除非环境另有可靠保证。

把状态送上线路后，完整性、重放、时效、隐私和格式版本都成为新义务。攻击者可能返回修改后的状态，也可能重放一份曾经有效但已经过时的状态。超长 Token 还能占满受限节点的内存；一串都想“无状态”的代理会在每一跳继续加入信息。

服务器仍然只回显不透明字节。客户端恢复的是自己先前封装的上下文，而不是服务器认证过的事实。状态从本地表迁到往返字节，责任没有消失。

一张不过度承诺的回执

最小可复核回执至少应保留下列层次：

  1. 观察点、墙钟时间与单调时钟。
  2. UDP、TCP、TLS 或 WebSocket，以及端点元组或连接引用。
  3. 安全模式、会话与认证对端结论（如有）。
  4. UDP 下的 Type、Message ID、重传与去重判定。
  5. Token 长度、隐私安全的值表示、生成与重用策略。
  6. 方法、目标 URI/选项及本地等待请求。
  7. ACK/Reset、响应形态与匹配结果。
  8. 响应码、资源版本与新鲜度。
  9. 授权决策、应用提交与独立设备结果。

这些行能分别改变。证书更新不必改变 Message ID 算法。代理映射出错不必意味着源服务器作恶。响应码正确不必意味着阀门已经动作。固件升级可能让此前的去重基线失效。

如果平台最终只写下 success，它不是总结，而是删除了责任链。

Bormann 的文献角色同样需要限界

2026 年 8 月 30 日复核的 IETF 个人页列出 Carsten Bormann 参与的 65 份 RFC，并将他列为 CoRE 工作组与 Thing-to-Thing 研究组主席。这是会变化的现行资料。

更稳定的归因来自 RFC 本身：他是 RFC 7252 的共同作者，也是 RFC 8323 作者名单中的第一位。两份标准轨文档都是 IETF 集体审议的产物。它们证明公开贡献，不证明某个设备已正确实现，也不赋予作者替运营商作出风险决定的权限。

运行中的实现、配置、抓包、状态迁移和应用结果，才能证明某个网络实际采纳了什么。作者身份是证据，不是执行权。这和 Token 的边界是同一种纪律：承认真实关联，不附送没有来源的权威。

Token 匹配了回应。剩下的结论，要由各自的证据来写。

来源