CoAP（受限应用协议）在物联网场景中广泛使用，其资源观察机制允许客户端订阅服务端资源变化。当客户端不再需要接收通知时，需要发送带有Observe选项且值为1的GET请求来取消观察。服务器端不仅要停止向该客户端推送通知，还必须返回一个RST（复位）类型的确认消息，否则客户端会认为取消失败并不断重传。在Ruby语言中，我们可以基于现有的CoAP库构建轻量服务来处理这一流程。
CoAP观察取消的协议基础
CoAP的观察规范定义在RFC 7641中。客户端通过发送Observe选项值为0的GET请求注册观察，服务器随后以2.05 Content响应并在选项中标记Observe序列号。当客户端希望取消时，必须发送一个全新的GET请求，且Observe选项的值设为1（十进制），这个目标资源必须与之前观察的资源一致。服务器收到此类请求后，按照规范应该回应一个RST消息，该消息的Message ID需与收到的取消请求相同，以此完成事务层面的确认。
很多自行实现的CoAP服务容易忽略确认环节，仅仅在应用层标记客户端已取消，不再发送通知。但在UDP不可靠传输下，客户端若未收到RST，会启动重传计时器并重复发送取消请求。服务端若每次都只做内部标记而不回RST，就会形成无谓的流量和日志噪声。因此在Ruby实现中，显式构造并发送RST是合规的关键一步。
从消息结构看，CoAP首部包含版本、类型、令牌长度、代码与消息ID。取消确认的RST消息代码为0.00，类型字段为Reset（值为3）。Ruby中我们可以直接操作字节流或使用库提供的构造器。理解这一结构有助于在出现库封装不全时自行补齐逻辑。
基于Ruby的服务器端取消确认实现
在Ruby生态中，coap gem（如ruby-coap）提供了基础收发能力。下面的示例展示了一个简单的UDP服务，它接收CoAP报文，判断是否为观察取消请求，并回送RST。我们使用UDPSocket监听5683端口，解析收到的二进制数据。
代码首先读取前4字节获取首部，提取类型、代码与消息ID。当代码为0.01（GET）且Observe选项值为1时，认定是取消观察。此时构造RST：首部类型置为3，代码0.00，消息ID复制请求ID，不携带载荷。通过同一个socket发送回去即可。注意CoAP选项解析需要按RFC 7252的增量编码规则，示例中用简化方法提取。
require 'socket'
socket = UDPSocket.new
socket.bind('0.0.0.0', 5683)
def parse_observe_value(payload)
# 简化解析：跳过首部4字节，遍历选项
pos = 4
while pos < payload.length
opt_byte = payload[pos]
delta = (opt_byte >> 4) & 0x0F
length = opt_byte & 0x0F
pos += 1
if delta == 6 # Observe选项号
return payload[pos] # 值0注册 1取消
end
pos += length
break if delta == 0xFF
end
nil
end
puts 'CoAP server running'
loop do
data, addr = socket.recvfrom(1024)
ver_type_tkl = data[0]
code = data[1]
msg_id = (data[2] << 8) | data[3]
type = (ver_type_tkl >> 4) & 0x03
# 判断GET且Observe=1
if code == 0x01
obs = parse_observe_value(data)
if obs == 1
# 构造RST: 类型3 代码0.00
rst_header = ((1 << 6) | (3 << 4) | 0).chr +
[0x00].pack('C') +
[msg_id >> 8, msg_id & 0xFF].pack('CC')
socket.send(rst_header, 0, addr[3], addr[1])
puts "Sent RST for cancel observe msg_id=#{msg_id}"
end
end
end
上述代码虽然简化，但演示了核心确认逻辑。在生产环境，建议使用成熟库管理选项解析与事务状态，避免手工位移出错。同时服务端应维护观察客户端表，在收到RST确认后真正移除对应的回调，防止内存泄漏。
另一个细节是令牌（Token）处理。取消请求可能带令牌，RST消息通常不需要回令牌，但如果客户端使用并发请求，服务端可通过令牌关联上下文。Ruby实现中可以把令牌作为散列键，在取消时删除对应条目，提升多客户端场景的健壮性。
未确认取消的常见问题与对比
如果服务器仅停止通知而不发RST，客户端行为取决于其实现。严格遵循规范的客户端会在超时后重发取消请求，最多数次后报错。在弱网环境中，这种重传会加剧拥塞。下表对比两种处理方式的差异：
| 处理方式 | 客户端表现 | 服务端资源 | 链路占用 |
|---|---|---|---|
| 仅停止通知 | 重传取消请求，可能最终放弃 | 观察表残留需额外清理 | 有无效重传 |
| 停止并回RST | 立即确认，无重传 | 及时删除条目 | 单次交互 |
从对比可见，发送RST不仅合规，也节省资源。在Ruby服务中，我们可以将确认逻辑放在独立线程或使用事件循环，如EventMachine，以避免阻塞主接收循环。对于大量设备的网关，这种异步确认能显著降低延迟。
此外，有些开发者误以为取消观察的响应必须是2.04 Changed或普通ACK。实际上RFC明确使用RST来否认原始观察关系，因为观察本是“软状态”，复位是最轻量的终结信号。Ruby代码里若错误回了ACK带载荷，客户端会困惑甚至继续等待通知。因此写死消息类型为Reset十分必要。
综合来看，使用Ruby实现CoAP资源观察取消确认，重点在于准确识别Observe=1的GET、构造合规RST、并及时清理服务端状态。配合基础UDP编程或现有库，就能在嵌入式网关或云边协同中提供稳定的物联网观察取消能力。
RubyCoAPresource_observation修改时间：2026-08-13 07:15:32