CoAP（受限应用协议）在物联网低功耗设备中承担着轻量型通信职责，其资源观察机制允许客户端订阅某个资源并在资源变更时收到服务器主动推送。当客户端希望停止观察，规范定义了通过发送特定Observe选项的请求来取消观察关系。但在实际网络中，如果服务器不返回明确的确认报文，客户端无法判断取消是否生效，服务器端也可能继续保留观察记录造成资源浪费。本文围绕如何使用Ruby实现服务器确认取消机制展开，从协议细节、代码构造到服务端响应处理逐步说明。
CoAP观察取消的协议原理与确认必要性
在RFC 7641中，CoAP资源观察通过请求中的Observe选项值为0（注册观察）或1（取消观察）来控制。客户端发送一个非确认或可确认型的GET请求，携带Observe=1，即告知服务器解除先前的观察关系。若原始观察建立在可靠传输（如CON报文）之上，服务器应当用2.05 Content或Reset报文回应，这便是服务器确认取消的核心。确认机制的存在是因为受限设备常处于丢包严重的无线环境，没有确认就无法知晓对方是否仍保留定时器与观察者列表。
从服务器视角看，若未实现确认取消逻辑，它会在资源状态变化时持续向已离开的客户端发送非确认通知，消耗电池与带宽。而客户端若未收到确认，可能重复发送取消请求，进一步增加流量。因此Ruby实现时不能仅发出Observe=1就结束，必须注册对回应报文的处理，依据响应码或Reset标志清理本地观察句柄。这种双向闭环是稳健CoAP栈的基础能力。
另外需注意，取消确认并不依赖Observe选项本身携带确认位，而是借由CoAP消息层的交互完成。例如客户端用CON发取消请求，服务器回ACK加2.05；若用NON发取消，服务器可用NON回含已删状态的响应，或干脆回Reset。Ruby代码应兼容这两种路径，通过消息ID与令牌匹配来识别是哪次取消得到了确认。
使用Ruby构造取消观察请求并发送
Ruby生态中可采用coap gem或基于EventMachine的自研库来操作CoAP报文。下面示例展示如何构建一个携带Observe=1选项的CON请求，目标为服务器资源并等待确认。我们显式设置Message ID与Token，便于后续匹配回包。
require 'coap'
# 创建客户端，绑定本地端口
client = Coap::Client.new(host: '192.168.0.1', port: 5683)
# 构造取消观察请求：Observe选项值为1表示取消
options = {
observe: 1, # 1 = 取消观察
uri_path: 'sensors/temp'
}
# 发送CON类型GET，并期待ACK确认
response = client.get(uri_path: 'sensors/temp', observe: 1, type: :con, message_id: 0x1234, token: '\xAB\xCD')
puts "服务器响应码: #{response.code}"
puts "是否收到确认取消: #{response.ack? || response.reset?}"
上述代码中，observe: 1是取消观察的关键。我们将类型设为:con以确保服务器必须回ACK，从而得到明确确认。若服务器返回码为2.05，说明它已删除观察项并附上当前资源表示；若返回Reset，则代表服务器本就没有该观察或直接中止了事务。Ruby客户端需把这两种都视为成功确认。
在真实项目里，观察往往由独立线程或反应式循环管理。取消时应先查找本地观察表，取出对应的Token与Message ID再发请求，避免错删其他订阅。若使用NON报文取消，要设定重传计时器：超过一定时间未收到服务器任何回应，就按“假设已取消”处理并本地清理，防止悬挂状态。这种策略在弱网中比死等ACK更实用。
服务器端确认逻辑与Ruby实现要点
若你用Ruby写CoAP服务器，需要在收到Observe=1时查找观察者列表，移除对应条目，然后返回确认。下面片段演示基于coap库的简单服务端点如何处理取消并返回2.05。
require 'coap'
server = Coap::Server.new(port: 5683)
# 观察记录结构: token -> client_addr
@observers = {}
server.on_get('/sensors/temp') do |req, res|
if req.options[:observe] == 1
# 取消观察
@observers.delete(req.token)
res.code = 205 # 2.05 Content
res.payload = 'canceled'
res.ack! # 明确确认
elsif req.options[:observe] == 0
# 注册观察
@observers[req.token] = req.remote
res.code = 205
res.payload = read_temp
else
res.code = 205
res.payload = read_temp
end
end
server.run
此例中，服务器识别observe==1后从哈希中删去令牌对应的客户端，并将响应码置为205且调用ack!。这满足了协议对确认取消的要求。若服务器此前从未记录该令牌，回Reset更合适，因为CON请求得不到对应状态时可借Reset终结对话。Ruby实现应注意线程安全，观察者列表可能被多个请求并发修改，需加互斥锁。
从整体架构看，服务器确认取消不仅释放内存，也令客户端状态机闭环。在网关聚合多设备观察时，确认机制能防止下游僵尸订阅向上游蔓延。测试时可故意不发确认，观察客户端是否重发或超时清理，以此验证鲁棒性。Ruby的灵活语法让我们能用少量代码覆盖CON/NON、ACK/Reset多种组合，是原型验证CoAP观察取消的好选择。
常见误区与调试建议
不少开发者误以为CoAP取消观察只需客户端单方丢弃回调即可，这是典型误区。若服务器未确认，它依旧把客户端当作活跃观察者，在每次温度变化时组包发送，导致客户端收到意料之外的非确认通知。用Ruby抓包时可借助coap自带的打印或Wireshark过滤coap.code==205来确认取消回包。
另一个误区是混淆Observe选项值：把注册用的0错写成取消用的1，或反之。应在常量层定义OBSERVE_REGISTER=0与OBSERVE_CANCEL=1，杜绝魔法数字。调试中若服务器总回4.00 Bad Request，先检查URI路径与Observe选项是否同属于一个合法请求。Ruby的异常捕获应能区分网络超时与协议错误，分别触发重发或本地强制取消流程。
最后建议编写集成测试：模拟服务器不回确认、回2.05、回Reset三种情形，断言客户端本地观察表最终为空。只有把服务器确认取消机制当作一等公民实现，CoAP应用在电池供电场景中才真正省电可靠。