CoAP（Constrained Application Protocol）是面向物联网受限设备设计的轻量级协议，默认运行在UDP之上。UDP不保证报文到达，CoAP因此自带一套消息层的确认与重传机制。当我们在Ruby中实现一个CoAP代理，负责把内网设备的请求转发到上游服务器时，如果只依赖协议默认行为，很容易在弱网环境下出现请求卡死、重复提交或者延迟过高的问题。本文将围绕Ruby实现CoAP代理转发的场景，系统地讲清楚超时与重试策略的配置方法。
一、理解CoAP的超时机制与代理转发的特殊之处
CoAP的消息层定义了几个关键参数：ACK_TIMEOUT（初始确认超时，默认2秒）、ACK_RANDOM_FACTOR（随机化因子，默认1.5）、MAX_RETRANSMIT（最大重传次数，默认4）。实际的首次超时时间在ACK_TIMEOUT到ACK_TIMEOUT * ACK_RANDOM_FACTOR之间随机取值，之后每次重传的超时时间按指数级翻倍。这套机制是CoAP协议栈自动完成的，但代理场景下问题要复杂得多。
代理转发涉及两段链路：客户端到代理、代理到上游服务器。两段的网络状况可能完全不同。比如客户端在内网，延迟只有几毫秒，而代理到上游要走公网甚至跨运营商，延迟抖动很大。如果代理对两段链路使用同一套超时参数，要么内网请求被无谓地等待太久，要么公网请求频繁超时失败。因此，代理需要为下游（面向客户端）和上游（面向目标服务器）分别维护独立的超时配置。
另一个容易踩坑的点是CoAP的Token与Message ID。代理在转发时通常会更换Message ID（因为消息层是逐跳的），但Token应当透传以便端到端匹配响应。如果重试逻辑写得不对，重复转发可能导致上游收到多次相同Token的请求，这在非幂等操作（如执行器控制指令）上会引发严重后果。所以重试策略必须结合请求方法来判断：GET、DELETE天然幂等，可以放心重试；POST则要谨慎，最好借助Request-Tag或去重缓存。
二、在Ruby中搭建CoAP代理转发的基础框架
Ruby生态里比较可用的CoAP库是coap gem，虽然它维护不算活跃，但消息编解码部分足够稳定。如果对依赖有顾虑，也可以只借用它的编解码能力，传输层自己用UDPSocket实现。下面是一个最小可用的代理转发骨架，重点展示参数结构的设计：
require 'socket'
require 'securerandom'
class CoapProxy
# 上游与下游分别维护独立的超时配置
UPSTREAM_CONFIG = {
ack_timeout: 2.0, # 初始超时（秒）
ack_random_factor: 1.5, # 随机化因子
max_retransmit: 4, # 最大重传次数
max_wait: 30.0 # 整体等待上限
}.freeze
DOWNSTREAM_CONFIG = {
ack_timeout: 1.0,
ack_random_factor: 1.2,
max_retransmit: 2,
max_wait: 10.0
}.freeze
def initialize(listen_port: 5683, upstream_host:, upstream_port: 5683)
@listen_port = listen_port
@upstream = UDPSocket.new
@upstream_host = upstream_host
@upstream_port = upstream_port
@pending = {} # token => 请求上下文
end
def start
server = UDPSocket.new
server.bind('0.0.0.0', @listen_port)
loop do
data, addr = server.recvfrom(2048)
handle_client_packet(data, addr, server)
end
end
private
def handle_client_packet(data, addr, server)
ctx = { client_addr: addr, server: server, received_at: Time.now }
# 解析后转发到上游，附带Token作为端到端关联
@upstream.send(data, 0, @upstream_host, @upstream_port)
token = extract_token(data)
@pending[token] = ctx
end
def extract_token(data)
tkl = data.bytes[0] & 0x0F
data.bytes[1, tkl].pack('C*')
end
end
这个骨架把上游和下游的配置拆成了两个常量结构，是后续所有重试策略的基础。实际项目中建议把这些参数挪到配置文件或环境变量里，比如通过ENV['COAP_UPSTREAM_ACK_TIMEOUT']读取，方便不同环境（测试环境网络好、生产环境网络差）使用不同参数。
三、实现指数退避重试与超时控制
有了基础框架，接下来是核心部分：为上游转发实现带抖动的指数退避重试。所谓指数退避，就是每次重试的等待时间是上一次的2倍；抖动则是叠加一个随机偏移，避免大量代理在同一时刻集体重试造成上游流量洪峰。下面是关键的重试调度代码：
class UpstreamForwarder
def initialize(socket, host, port, config)
@socket = socket
@host = host
@port = port
@config = config
end
# 带指数退避的转发，只对幂等请求自动重试
def forward_with_retry(packet, idempotent: true)
timeout = initial_timeout
retries = 0
loop do
@socket.send(packet, 0, @host, @port)
response = wait_for_response(timeout)
return response if response
retries += 1
break if retries > @config[:max_retransmit]
break if !idempotent && retries > 1 # 非幂等请求最多尝试一次额外确认
# 指数退避 + 随机抖动
timeout *= 2
jitter = timeout * (rand * 0.1)
sleep(timeout + jitter)
end
nil # 最终失败，由调用方返回 5.04 Gateway Timeout
end
private
def initial_timeout
base = @config[:ack_timeout]
factor = @config[:ack_random_factor]
base + base * (factor - 1) * rand
end
def wait_for_response(timeout)
deadline = Time.now + timeout
loop do
remaining = deadline - Time.now
return nil if remaining <= 0
return nil unless IO.select([@socket], nil, nil, remaining)
data, _ = @socket.recvfrom(2048)
return data
end
end
end
这段代码有几个值得注意的细节。第一，IO.select带超时地等待响应，避免了线程层面的阻塞问题；第二，初始超时通过随机因子产生抖动，符合RFC 7252的建议；第三，非幂等请求的重试受到严格限制，防止上游重复执行副作用操作。如果业务确实需要对POST也做重试，可以引入Request-Tag选项，让上游根据Tag做去重，或者代理本地维护一个已发送请求的指纹缓存，在窗口期内拦截重复提交。
失败后的处理同样重要。CoAP代理在转发最终失败时，应当向客户端返回5.04 Gateway Timeout或5.02 Bad Gateway，而不是让客户端的消息层自己超时——后者会让客户端多等好几秒，体验很差。可以在forward_with_retry返回nil后立即构造错误响应：
def build_error_response(code, message_id, token)
# code: 80 = 5.04 Gateway Timeout 的字节表示
[0x60 | message_id, 0x80, token].pack('CCC')
end
四、参数调优与可观测性实践
超时参数没有放之四海而皆准的最优值，必须结合实际网络测量。一个实用的做法是代理持续统计上游的往返时间，动态调整初始超时。例如维护一个滑动窗口内的RTT采样序列，取P95分位乘以安全系数作为ack_timeout。下面的代码展示了简化版的自适应逻辑：
class AdaptiveTimeout
WINDOW = 50
def initialize
@samples = []
end
def record(rtt)
@samples.push(rtt)
@samples.shift if @samples.size > WINDOW
end
def suggested_timeout
return 2.0 if @samples.empty?
sorted = @samples.sort
p95 = sorted[(sorted.size * 0.95).floor - 1] || sorted.last
[p95 * 2.5, 10.0].min # 不低于P95的两倍半，也不超过10秒
end
end
除了参数本身，可观测性决定了重试策略能否被有效运维。建议为每一次转发记录结构化日志：请求的URI路径、Token十六进制值、重试次数、每次尝试的耗时、最终结果。当日志中重试次数的分布明显右移时，说明上游网络劣化，这时应该告警而不是继续加大max_retransmit。盲目增加重试次数会把延迟放大到几十秒，客户端早已超时放弃，纯粹浪费带宽。
最后提醒两个工程细节。一是代理对下游客户端的响应超时要小于客户端自己的重传超时，否则客户端会先行重发，造成代理收到重复请求；二是如果上游走的是CoAP over TLS（即CoAPs，端口5684），传输层虽然变为可靠连接，但应用层超时依然需要保留，因为TLS只保证传输可靠，不保证服务端及时响应。把这些配置点组合起来，一个在弱网环境下依然稳定可用的Ruby CoAP代理就成型了。