企业官网建设流程全解析

最近在帮朋友调试一个环境监测项目，节点端用的还是老式 HTTP 上报，每次看抓包我都觉得心疼：一条几字节的温湿度数据，硬要背着一百多字节的 HTTP 头在窄带无线链路上跑。也就是从那时候起，我把 CoAP 协议从头到尾重新捋了一遍，才有了这篇总结。如果你也在做物联网设备接入、低功耗节点通信，或者正在纠结到底该用 HTTP、MQTT 还是 CoAP，这篇文章应该能帮你省掉不少弯路。CoAP 协议全称 Constrained Application Protocol，中文常译作“受限应用协议”，它是面向资源受限设备、低带宽低功耗网络设计的一套应用层协议，底层跑在 UDP 上，但提供了可靠的请求-响应语义。

这篇文章我会尽量按“为什么设计成这样、协议本体的字段和消息机制、怎么用它做业务通信、扩展能力、安全方案、生产环境避坑”这个顺序来讲，每一部分都会结合我实际项目里的观察和踩坑经历，而不是只贴 RFC 原文。

1. CoAP到底是为了什么样的设备而生的

1.1 HTTP在受限节点上让我最受不了的三件事

先说个实际的观察。在某个老旧厂房改造的温湿度监测项目里，接入点用的是板载资源非常紧张的单片机级别设备，主频几十兆赫兹，RAM 以 KB 计，无线通信走的是低功耗子 GHz 频段，调制速率通常只有几十 kbps。在这种环境下用 HTTP over TCP，有三个问题会立刻冒出来：

第一，TCP 连接的状态是重量级的。每一个连接都要维护发送缓冲、接收缓冲、序列号、拥塞窗口这些状态，这对动辄几十 KB 内存的节点是真实的负担。而且 TCP 三次握手 + HTTP 请求响应，一发一收至少要 4 个报文才能完成一次业务数据交换。

第二，HTTP 报文头部的固定开销太大。简简单单一个 GET 请求，带上 User-Agent、Host、Accept 这些字段，几百字节很容易就出去了。在几十 kbps 的低速链路上，这意味着一次上报要占用好几秒的信道时间，对电池供电设备来说是致命的。

第三，TCP 的“流式可靠”在 RF 环境下并不必然带来好处。低功耗无线网络的丢包是常态，TCP 的拥塞控制和慢启动在这种场景下往往表现得非常保守，而且乱序重排、重传都发生在内核协议栈里，应用层完全不可控。你很难知道一次请求到底什么时候才算“真正结束”。

我当时的第一个念头是：能不能把 HTTP 的语义保留下来，但把底层的搬运方式换掉？CoAP 就是干这个的。

1.2 它不是HTTP的简化版，而是为UDP重新设计了语义

很多人第一次看到 CoAP 会觉得它就是“把小写字母换成大写、把长字段名缩短”的 HTTP 变体，这么理解其实会害死人。CoAP 在设计上保留了 HTTP 的 REST 风格语义——URI、方法（GET/POST/PUT/DELETE）、响应码、内容协商，这些你都能找到对应物；但它的传输模型完全是基于 UDP 重新设计的，不是把 TCP 简单砍掉。

它把“可靠性”从传输层搬到了“消息层”。UDP 只管把数据报发出去，至于这个数据报丢了没有、对方收到了没有，由 CoAP 自己通过消息类型和重传机制来保证。这样设计的直接好处是：没有连接状态、没有 TCP 栈、可以一个请求发给多个设备（组播）、可以自由控制重传策略。对嵌入式系统来说，这几乎是为它们量身定做的。

1.3 适合与不适合CoAP的场景

用我自己的经验来划分，CoAP 适合这些场景：

• 资源受限的传感器/执行器节点，内存百 KB 级以下，传统 TCP 协议栈都不一定跑得顺；
• 本地网络或私有网络内的设备通信，节点数几十到几百，每个节点大概率同时承担“被查询”和“主动上报”两类角色；
• 需要服务端主动推送状态变化（观察模式）、或者局域网内设备自动发现的场景；
• 通过代理网关将设备能力映射给互联网应用使用。

不适合的场景也有：

• 千米级广域网、弱信号、要求严格顺序交付的大文件传输，这不是 CoAP 的强项；
• 海量公网直连设备，没有做安全设计就直接裸跑 CoAP，风险极大；
• 对实时性要求特别高的流式数据（音视频），CoAP 的请求响应模式并不合适。

2. 先把报文从头看到尾：4字节固定头里到底放了什么

2.1 头字段逐字节拆解

CoAP 报文的最小固定部分只有 4 个字节，整整齐齐，一个多余的都没有。第一个字节的高 2 位是版本号（Ver），目前固定为 01；接着是类型字段（T），占 2 位，标记这条消息是 CON、NON、ACK 还是 RST，这个在后面消息模型里细讲；再往下 4 位是 Token Length（TKL），表示令牌字段的长度。

第二个字节的全部 8 位都是消息代号（Code），前 3 位是类别（如 0 表示请求，2 表示成功响应，4 和 5 表示各种错误），后 5 位是具体细节。举个例子，常见的 GET 请求代号是 0.01，即字节值为 0x01；成功响应带资源的代号是 2.05，即字节值为 0x45。这个设计跟 HTTP 状态码的“大类 + 细分”逻辑很像，但只用了一个字节来表达。

第三和第四字节合起来是 Message ID，16 位，范围 0-65535。它由发送方随机生成，用途有两个：一是把 CON 消息和对应的 ACK 消息配对，二是接收方用来去重。在低功耗网络上，一条消息重传是常态，没有 Message ID 做去重，接收方会把同一份数据当成两次业务请求处理。

2.2 Options段：参数都在这里排队

固定头之后是可选的 Token，再之后是一个接一个的 Option。CoAP 把 HTTP 里那些头部字段，比如 Host、Content-Type、Cache-Control，全都折算成了带编号的 Option。每个 Option 由头部和值组成，头部用 4 位 Delta 和 4 位 Length 表示“当前 Option 编号比上一个 Option 编号大多少，值有多长”，这种增量编码能省很多字节。

我实际抓包看到的一个典型请求是这样的：GET 一个资源路径 /s/temp，长度 7 个字符，如果每个字符单独用 Option 表示，会分成 Uri-Path: "s" 和 Uri-Path: "temp" 两个 Option。从外面看这篇报文，固定头 4 字节加 Token 2 字节，再加两个 Uri-Path Option 和可能的一个 Content-Format Option，总长度常常在 15-25 字节之间。对比 HTTP 动辄 80 字节以上的请求头，差距非常直观。

2.3 Payload边界与报文大小的隐性限制

选项区结束之后，如果还有业务数据，CoAP 用一个值为 0xFF 的字节作为“载荷起始标记”，后面跟的就是 Payload。这个设计很巧妙：0xFF 在 Option 编码里是一个用不到的头部值（因为 Option Length 字段最多表示 15，且带有扩展格式），所以不会产生歧义。Payload 的应用格式由 Content-Format Option 告诉接收方，可以是纯文本、JSON、CBOR 等。

关于报文大小，CoAP 官方并未硬性规定最大载荷，但实际设计时必须参考底层传输能力。比如在 802.15.4 网络的单帧载荷上限约 80 字节左右，在低功耗蓝牙里单次通知典型值是 20 字节起步。所以即便 CoAP 头很小，你也不能忽略链路 MTU 对报文尺寸的约束。这也是为什么后来才有分块传输（Blockwise）扩展，后面会讲到。

3. 可靠传输不是TCP的专利：消息模型和重传机制

3.1 CON、NON、ACK、RST四种消息的分工

CoAP 最大的特色之一，就是它把“可靠性”做成了可选开关。消息类型一共四种：CON（Confirmable，需确认）、NON（Non-confirmable，无需确认）、ACK（Acknowledgment，确认）、RST（Reset，复位）。

CON 消息发送出去之后，如果发送方在一定超时时间内没收到 ACK，就会重新发送，重点在于“对方必须回应”，这是 CoAP 的可靠传输通道。NON 消息则发完就完事，不期待任何确认，适合周期性上报这种丢一两包无所谓的数据。注意，NON 消息虽然没有 ACK，但接收方如果发现它有问题，可以回一个 RST 来终止这个“伪连接”，比如服务器根本不支持这个请求就回 RST。

ACK 和 RST 则比较特殊。它们一个负责对 CON 消息做确认，一个负责拒绝。一个很容易被误解的点是：ACK 并不代表业务成功。ACK 只是在传输层说“我收到了”，至于业务层面是处理成功还是失败，要在 ACK 里再带一个响应消息（例如 4.04 Not Found）。这个跟 HTTP 里 TCP ACK 和 HTTP 响应完全分离是同一个道理。

3.2 默认重传策略的时序与退避

CoAP 的重传逻辑简单但讲究。默认参数 ACK_TIMEOUT=2 秒、ACK_RANDOM_FACTOR=1.5，首次超时取 2 到 3 秒之间的随机值；如果没有按时收到 ACK，下一次超时时间翻倍，也就是变成 4 到 6 秒，再下一次 8 到 12 秒，最多再试 4 次。

我用一个实际例子来演示时序：

• 第 0 秒：发送 CON 请求，Message ID=100
• 第 2.4 秒：还没收到 ACK，超时，重传 Message ID=100
• 第 6.2 秒：再次超时，重传 Message ID=100
• 第 13.5 秒：再次超时，重传 Message ID=100
• 第 27.3 秒：最后一次超时，重传 Message ID=100
• 总重传窗口约 45 秒后，放弃

这里有个细节：每次重传的 Message ID 必须相同，因为它本质上是同一个“数据报”的多次发送；但 Token 和请求内容也都保持不变。接收方靠 Message ID 识别重复，丢弃后面到达的副本，但对业务只处理一次。这种“报文级去重”就是靠 16 位 Message ID 实现的。

3.3 去重与匹配：Token为什么不能省

Message ID 管的是“这条消息是不是重复的”，Token 管的则是“这条响应对应哪个请求”。因为 UDP 是无连接的，服务器很可能同时收到多个客户端的多个请求，响应回到客户端时，它必须知道这个响应是哪个请求的。Token 由客户端生成，服务器原样带回。

Token 的一个典型应用场景是并发发多个 GET 请求，每个请求用不同 Token，响应对号入座。另一个场景是响应比请求耗时更长时，服务器可以先回一个空的 ACK（表示“我收到了，在给你处理”），等业务完成后再单独发一个 NON 或 CON 消息携带结果。这时 Token 就是唯一的关联依据，客户端拿到带 Token 的响应，才知道它与最初那个请求的关系。我见过很多初学 CoAP 的人在这里出错：把 Token 留空，在并发请求一多就出现响应错配。协议本身允许空 Token，但生产环境我强烈建议每个请求都生成随机 Token。

4. 从请求到响应：CoAP如何用REST语义完成业务通信

4.1 方法、URI与子资源设计

CoAP 的方法表基本平移了 HTTP 的 REST 方法：GET 用于获取资源，POST 用于创建资源或触发动作，PUT 用于更新或创建，DELETE 用于删除。此外还定义了 FETCH 和 PATCH 用于部分更新，只是实际设备上用得较少。

URI 的写法也跟 HTTP 很像：coap://[主机地址]:5683/路径/子路径?查询参数。端口默认是 5683，走 DTLS 加密后默认端口是 5684。需要特别留意的是，路径的每一段都对应一个独立的 Uri-Path Option，查询参数每一个也是对独立的 Uri-Query Option。设计 REST 资源时，我常用的套路是把设备抽象成集合和属性：

• 设备集合：/devices
• 单台设备：/devices/{id}
• 设备属性：/devices/{id}/temp、/devices/{id}/humidity
• 执行动作：/devices/{id}/actuators/relay

在 CoAP 里，“资源”不一定是静态数据，可以是一个动作。比如用 POST 访问 /devices/01/reboot 就能触发设备重启。这种把操作也建模成资源的思路，跟 HTTP API 设计是一脉相承的。

4.2 响应码：3位数字分成3组

CoAP 响应码压缩成 3 位十进制数字，但只占一个字节。第一组是成功类，第二组是客户端错误，第三组是服务端错误。常见的我在项目里经常用到的：

• 2.01 Created：POST/PUT 创建资源成功
• 2.02 Deleted：删除成功
• 2.04 Changed：PUT/POST 修改成功
• 2.05 Content：GET 成功并携带资源内容
• 4.00 Bad Request：请求格式不对
• 4.01 Unauthorized：未授权或凭证错误
• 4.04 Not Found：资源路径不存在
• 4.05 Method Not Allowed：方法不允许
• 4.13 Request Entity Too Large：请求体超出节点处理能力
• 5.00 Internal Server Error：服务器内部错误
• 5.03 Service Unavailable：暂时不可用，常在过载时返回

这些响应码虽然和 HTTP 很接近，但在 Code 字节里的编码是二进制压缩的，比如 2.05 Code 实际是 0x45（4*16+5）。写代码的时候你直接按数字理解就行，不用背。

4.3 内容协商与媒体类型：用数字编号，不靠字符串

HTTP 用 MIME 字符串比如 application/json 来标识媒体类型；CoAP 因为要省字节，改用数字编号。最常见的几个：

• 0：text/plain; charset=utf-8
• 16：application/json
• 40：application/link-format
• 42：application/cbor
• 50：application/json-text-seq

如果你做过嵌入式开发就会明白，解析 "application/json" 这种字符串而不是对比单个数字，在 MCU 上代价是完全不同的。CoAP 在 Content-Format Option 里直接放一个数字，客户端查表就能确认，省了很多事。请求方还可以通过 Accept Option 告诉服务器自己偏好哪种格式，作用等价于 HTTP 的 Accept 头。

4.4 资源发现机制

CoAP 有个特别实用的能力：自描述。一个设备上线后，它可以在 /.well-known/core 路径上暴露自己支持的全部资源。客户端只需要向这个路径发一个 GET，就能得到一份资源清单，格式是 RFC 6690 定义的 link-format，本质是一组带属性的 URI 列表。

举个例子，一个传感器节点可能返回：

</s/temp>;rt="temperature-c";if="sensor",</s/humidity>;rt="humidity-c";if="sensor", ;rt="device-info"

这里的 rt 属性是资源类型（Resource Type），if 是接口类型（Interface Type）。设备互联时，平台侧可以通过这个机制自动发现设备能力，省掉人工录入配置的工作。我在某个项目中就是靠这个能力做了一套“设备即插即用”的接入流程：节点上电后主动发一条 NON 通知到网关，网关去 /.well-known/core 拉资源列表，注册流程就完成了。

下面给一段基于 Python 的简单示例，向大家展示“最小可用”的服务端和客户端写法。别把这段代码当真生产方案，但它足够帮你把整个请求-响应流程跑通：

# 客户端示例：读取某节点的温度资源 import asyncio from aiocoap import Context, Message, GET async def fetch_temp(uri): ctx = await Context.create_client_context() request = Message(code=GET, uri=uri) response = await ctx.request(request).response print("响应码:", response.code) print("载荷:", response.payload.decode("utf-8")) await ctx.shutdown() asyncio.run(fetch_temp("coap://192.168.1.100:5683/s/temp"))

# 服务端示例：暴露一个温度资源 import asyncio from aiocoap import resource, Context from aiocoap.numbers.contentformat import ContentFormat class TempResource(resource.Resource): async def render_get(self, request): payload = "24.5".encode("ascii") return self.reply(payload, contentformat=ContentFormat.TEXT) async def main(): root = resource.Site() root.add_resource(["s", "temp"], TempResource()) await Context.create_server_context(root) print("CoAP 服务已启动，监听 5683 端口") await asyncio.get_running_loop().create_future() asyncio.run(main())

跑完这段代码，你就会对 CoAP 的“轻量 REST”有非常直观的感受：没有任何连接建立过程，客户端发一个不到 20 字节的 UDP 数据报，服务端回一个同样很小的数据报，一次完整业务交互完成。

5. 真正拉开差距的几个扩展：Observe、Blockwise和代理

5.1 Observe观察模式

基础的 CoAP 是请求-响应模型，只有客户端主动发请求才能拿到数据。但很多 IoT 场景要求的是“数据变化主动推送”，总不能靠节点高频轮询。CoAP 用 Observe 扩展解决了这个问题。

Observe 的核心思想很朴素：客户端在 GET 请求里带上 Observe Option（注册观察），服务器返回当前状态并把这个客户端加入观察者列表；之后每次资源状态变化，服务器主动发一个新响应给所有观察者，同时在这个响应里带一个递增的观察序列号。客户端如果不想继续收，就发一个带 Observe 值为 1 的 GET（取消观察），或者直接回 RST。

这个机制带来的场景直接类比服务端推送：温度超过阈值自动通知，插座开关状态变化实时同步给手机端。在某个示范项目里，我们用 Observe 把灯光状态从“轮询每 2 秒拉一次”改成了“变化即时推送”，节点日报文数量降了一半左右，体验反而更好。

5.2 Blockwise分块传输

前面提过，很多链路单帧载荷很小。那么问题来了：如果要把一整张配置表或 OTA 升级包发给设备，单帧塞不下怎么办？Blockwise（RFC 7959）就是用“分块”来解决的。

Block 选项分 Block1 和 Block2：Block1 用在请求方向，把大请求体拆成多次发送（比如 PUT 大配置）；Block2 用在响应方向，把大响应体拆成多次返回（比如 GET 大文件）。每次交互里，客户端和服务端通过 NUM（当前块号）、M（是否还有后续块）、SZX（块大小指数）协商进度。块大小可以是 16、32、64、128、256、512、1024 字节，由 SZX 对应 0-6 的编号表示。

我在做固件升级的时候遇到过这样的情况：一次完整固件包 40KB，而节点的无线层单帧限制在几十字节。当时就是靠 Block2 把文件切成 256 字节的块逐个传输。这里有个容易踩的坑：块大小不要贪大，一旦底层链路 MTU 不够，分块传输会在传输层又触发 IP 分片，导致丢一个分片整块报废，效率反而更差。

5.3 CoAP到HTTP的代理映射与缓存思路

CoAP 不是孤立存在的。现实中很多设备在局域网内跑 CoAP，但应用平台跑在云端的 HTTP API 上。这时需要一个代理网关做双向翻译：设备侧是 CoAP，服务端侧是 HTTP。

代理怎么做呢？其实 RFC 8075 已经把 CoAP 到 HTTP 的映射规则写得比较清楚：CoAP 方法直接映射到 HTTP 方法，CoAP 响应码按类别映射成 HTTP 状态码并加上适当的语义，URI 做相应重写。CoAP 的缓存能力也继承了 HTTP 的语义，比如 Max-Age Option 表示资源有效期，ETag Option 用于条件请求。代理转发时可以缓存资源副本，减少对后端平台的请求压力。

我个人的经验是：代理层不要只做“搬运工”，还要做“缩略员”。NON 类周期性数据的聚合、观察者列表的维护、安全上下文的终结，这些功能最好都收敛在代理进行，让设备端保持极简。

6. 加密不是可选项：DTLS与四种安全模式

6.1 四种安全模式怎么选

没有安全设计的联调协议只能留在实验室里。CoAP 的安全层是 DTLS（Datagram Transport Layer Security），也就是把 TLS 搬到 UDP 上。RFC 7252 定义了四种安全模式：

• NoSec：无加密，UDP 5683，仅限可信网络；
• Pre-Shared Key：预共享密钥 PSK，UDP 5684，适合少量设备，密钥提前预置；
• Raw Public Key：使用非对称公私钥，UDP 5684，无需证书链，适合设备数量可控但安全要求更高的场景；
• Certificate：完整 X.509 证书体系，UDP 5684，适合设备接入统一平台、需要证明身份链的场景。

从一个维护者的视角，我的建议是：能上 PSK 就不上 NoSec，能上数字证书就尽量别只靠 PSK。特别是在多厂商设备混接的项目里，数字证书能省掉“把同一个预共享密钥复制给几十个厂商”这种噩梦。

6.2 握手开销给节点带来的真实体感

DLS 有一点和 TCP + TLS 类似：握手成本不小。DTLS 1.2 的握手需要多个往返数据报，每个数据报几百字节甚至更多。在低带宽高丢包链路上，这个开销会更明显：握手耗时可能达到秒级甚至数十秒级。

这就产生了一个非常重要的设计取舍：设备不能动不动重新握手。我当时测试过一组数据，在模拟丢包 5% 的 RF 链路上，一个 PSK 模式的 DTLS 会话建立平均耗时 1 到 2 秒；在证书模式下，握手载荷更大，耗时可能翻几倍。对每 5 秒上报一次数据的节点来说，这个开销是不可忽视的。

所以实践上有几个通用原则：会话必须尽量复用，用会话票据或缓存会话参数让新连接快速恢复；心跳频率和会话老化时间要匹配，避免“频繁重连”导致反复握手；只有在发生密钥轮换或设备重启后才允许重新执行完整握手。

6.3 设备侧密钥管理的简易实践

密钥管理可能是整个 CoAP 安全里最容易被低估的一环。对 PSK 模式，出厂预置密钥时一定要把密钥和设备的唯一 ID 绑定，避免所有设备共用同一个全局密钥——一旦一个设备被攻破，整个网络就听天由命了。

对证书模式，设备侧存储私钥时要注意保护，能用安全元件（Secure Element）就尽量用，成本敏感的可以用片内唯一的标识生成派生密钥。密钥轮换要留出足够的升级窗口，不要把“永不过期”当成省事的理由。我在生产维护中最怕看到的就是：设备已经联网运行三年，但 PSK 从来没换过，变更时只能一台一台手动拆壳。

安全上还有一个连带的坑：NON 消息在 CoAP 里默认不可靠，如果安全协商后的会话状态因为丢包变得不一致，后续的 Non-Confirmable 消息可能一直无法解析。此时比较稳妥的做法是，敏感指令一律走 CON 消息 + DTLS 会话，保证每一步都有状态确认。

7. 上生产之前，这几个坑必须提前排掉

7.1 NAT都不会为UDP开洞太久

如果你把 CoAP 设备部署在家庭 Wi-Fi 或企业办公网后面，UDP 数据报出网关时，NAT 映射表是有老化时间的。很多家用路由器的 UDP 映射老化时间只有一两分钟，期间没有出向流量，映射就没了。CoAP 没有 TCP 这种自带 keep-alive 的机制，所以应用层必须自己设计保活。

我在项目中常用的策略是：周期性的 NON 消息上报当作天然的 keep-alive；如果设备长时间没有上行流量，就在应用层设计一个轻量 PING 或读取固定资源，每 30-60 秒一次。注意不要用 CON 做保活，否则每次丢包都触发退避重传，白白消耗带宽。

7.2 不要用NON消息做关键操作

Con vs Non 的选择看似简单，实际很容易拍脑袋。我的判断准则是看“这个业务能不能容忍丢包”：

• 周期性温度上报：丢一包下一包，NON 完全够用；
• 开关指令：丢了可能设备就永远没执行，这是不可接受的，必须 CON；
• 注册、固件升级等流程性操作：全程 CON，每一个关键步骤都有确认。

还有一个折中方案：如果业务上想省流量，但又希望关键操作可靠，可以采用“NON 发送 + 应用层超时重试”的模式。即应用自己维护一个超时，没收到预期响应就在应用层重新发一次 NON。这样重传策略就完全掌握在业务手里，而不是依赖协议默认的指数退避。

7.3 仿真器和真实射频环境下的结果差很远

在给某个项目做技术验证时，我在仿真环境里测试 CoAP，报文收发一切正常，延迟几乎为 0。真正部署到实地后才发现，射频链路的突发丢包、障碍物绕射、多径效应会让重传大量出现，一轮请求下来可能需要 10-30 秒。如果此时再叠加 CON 的默认重传退避，整个系统响应就像卡住了一样。

因此，模拟测试一定要把“链路丢包率参数”调成真实值，至少 1%-5% 起测。压测环境里要加入随机乱序、延迟抖动，甚至模拟电池设备周期性休眠导致报文暂时不可达的情况。不要迷信局域网 0% 丢包的结果，那不是真实 IoT 网络的样子。

7.4 抓包与调试建议

调试 CoAP，第一件要做的事是用 Wireshark 打开 UDP 5683 端口，确保开启了 CoAP 协议解析器。这样你就能直观看到每条 CON 消息的 Message ID、Token、Option 列表和响应码。如果发现重复消息，先看是不是重传导致，再看是不是客户端没有正确处理 ACK。

另一个我常用的调试方式是写一个“最低配客户端”，把请求逐字节打印出来，然后对照 RFC 7225 的字段定义检查每一个字节的取值。对嵌入式开发来说，这比一遍遍看库函数日志要直观得多。很多“找不到节点”的问题，根因就是报文里 Option 编码时 Delta 算错了一位，导致后面的 Uri-Path 解析全乱掉。

另外，如果手头有现成的 HTTP 工具，别直接拿它请求 CoAP 节点，协议根本不兼容。要让 HTTP 请求和 CoAP 节点对接，中间需要代理转换，否则连端口都对不上。

最后再分享一个实际处理过的小教训。某个项目把 CoAP 客户端的重传超时从默认的 2 秒手动改成 200 毫秒，以为这样能提高响应速度。结果在稍差的无线环境下，250 毫秒超时后就开始重传，而原 ACK 往往在 300 毫秒左右才到，于是每个请求都白白重传好几次，流量反而翻倍。后来我把超时调到 1 秒并保留随机化，才恢复稳定。超时参数看起来只是数字，但它要和底层链路的真实延迟分布匹配，不能一拍脑袋就改。做 CoAP 设备接入，真正值钱的往往不是协议的某个宏大特性，而是这些细节上的克制和取舍。