QPACK是HTTP/3专门为头部压缩设计的算法，相当于HTTP/2中HPACK的升级版。它的核心思路和HPACK一样：把重复出现的头部字段放进一张动态表，用短索引代替完整字符串传输。但QPACK引入了一个关键改动——动态表的更新走单向流，且插入操作允许乱序到达。这个设计提升了抗丢包能力，却也带来了新的问题：如果动态表的更新指令在传输中真的丢了，发送端以为表里已经有某个条目，接收端却始终没插入，两边状态失配之后，解码器按索引取值就会取到错误的字段甚至失败。本文围绕这个问题，讲解如何用Ruby检测QPACK动态表更新丢失，并给出可运行的实现代码。
QPACK动态表的工作原理与失配根因
QPACK在规范中定义了三类流：编码器流、解码器流以及请求流。头部字段的插入操作通过编码器流单向发送，解码器收到后插入自己的动态表副本。与HPACK不同，QPACK的解码器可以落后于编码器，只要编码器引用的索引还没就绪，解码器就会通过Section Acknowledgement和Stream Cancellation等指令反馈状态，必要时阻塞等待。
动态表本身是一个定长环形缓冲区，容量由SETTINGS_QPACK_MAX_TABLE_CAPACITY协商。每次插入新条目，表的插入计数加一，超容量时最老的条目被挤出。编码器引用动态条目时使用的是“相对索引”，指向的是插入计数上的偏移，这就是失配问题的根源：索引本身依赖两端对插入历史的共识。假设编码器插入了字段user-agent的值，插入计数变为12，随后在请求头里用相对索引引用它；如果这条插入指令因为流重传异常或中间代理实现缺陷而彻底丢失，接收端的插入计数停在11，解码时按相对索引12去查表，要么查到上一次的旧值，要么直接触发解码错误。
更麻烦的是这种失配往往不会立刻暴露。前几个请求可能碰巧没引用动态条目，全靠字面量编码也能正常工作，直到某次请求引用了丢失的那条记录，问题才炸出来。所以丢失检测不能依赖“出错再补救”，而要在更新链路上主动探测。
检测思路：状态哈希与确认水位线
检测的核心思路是把动态表状态抽象成可比较的摘要。每次插入条目时，编码器把条目内容连同插入计数一起喂给一个滚动哈希函数，得到当前表状态的一个校验值；解码器在收到插入指令后做同样的事。当编码器发出一条插入指令后，它会等待解码器的Section Acknowledgement回执，如果在合理时间内没收到回执，或者收到的回执里隐含的已知计数与本地记录不符，就说明这条更新可能丢失了。
具体判定规则可以细分为两层。第一层是水位线检测：编码器维护一个“已确认插入计数”，解码器每处理一批插入就回传它当前的插入计数，如果编码器侧的已发送计数与确认计数之间的差值持续超过阈值且长时间不收敛，标记为疑似丢失。第二层是哈希比对：在连接空闲或定时器到期时，编码器主动发送一个携带当前状态哈希的探测指令，解码器比对本地哈希，不一致则立刻回报失配详情，编码器据此重置动态表回到已知一致点。
哈希的选择不需要密码学强度，重点是分布均匀和计算轻量。FNV-1a或者64位Murmur风格的算法都够用，Ruby标准库里的Digest::SHA1也可以，只是稍微重一点。下面是状态摘要的核心建模代码。
require 'digest'
class QpackDynTable
attr_reader :insert_count, :capacity
def initialize(capacity = 4096)
@capacity = capacity
@entries = [] # 动态表条目，最新的在头部
@insert_count = 0 # 插入计数
@state_hash = 0xcbf29ce484222325 # FNV-1a偏移基数
end
# 插入一条：name与value均为字符串
def insert(name, value)
entry = [name, value]
@entries.unshift(entry)
@insert_count += 1
# 挤出超容量的老条目（简化版：按条目数而非字节数）
@entries.pop while byte_size(@entries) > @capacity
update_hash(entry, @insert_count)
@insert_count
end
def state_digest
format('0x%016x', @state_hash)
end
private
def byte_size(entries)
entries.sum { |n, v| n.bytesize + v.bytesize + 32 }
end
# FNV-1a滚动更新，把条目和计数一起纳入摘要
def update_hash(entry, count)
data = "#{entry[0]}=#{entry[1]}##{count}"
data.each_byte do |b|
@state_hash ^= b
@state_hash = (@state_hash * 0x100000001b3) & 0xFFFFFFFFFFFFFFFF
end
end
end这段代码把动态表建模成一个简单的数组加插入计数器，每次插入都同步更新滚动哈希。注意哈希计算把插入计数也编进去了，这样即使两条内容相同的条目先后插入，也能区分出不同的表状态，避免哈希碰撞导致漏检。
丢失检测器的完整实现
有了状态摘要，下一步是写检测器。检测器跑在编码器一侧，负责追踪每条插入指令的发送时间、回执状态，并在超时后触发探测或重置。这里用Ruby实现一个基于定时轮询的版本，实际工程中可以挂到EventMachine或nio4r的事件循环里。
class LossDetector
ACK_TIMEOUT = 0.5 # 回执超时，单位秒
PROBE_INTERVAL = 2.0 # 主动探测间隔
GAP_THRESHOLD = 8 # 未确认插入数告警阈值
def initialize(local_table, peer)
@local = local_table
@peer = peer # 模拟对端（解码器）通道
@acked_count = 0 # 已确认插入计数（水位线）
@pending = {} # insert_count => 发送时间
@last_probe = Time.now
@alarms = []
end
# 编码器发出一条插入后调用
def on_insert_sent(insert_count)
@pending[insert_count] = Time.now
end
# 收到解码器的确认水位线
def on_ack(remote_count)
@acked_count = remote_count
@pending.reject! { |k, _| k <= remote_count }
@alarms.clear if @local.insert_count - @acked_count < GAP_THRESHOLD
end
# 主循环，每次tick调用
def tick(now = Time.now)
check_timeouts(now)
maybe_probe(now)
@alarms
end
private
def check_timeouts(now)
@pending.each do |count, sent_at|
next unless now - sent_at > ACK_TIMEOUT
gap = @local.insert_count - @acked_count
@alarms << "插入##{count}疑似丢失：已发送#{@local.insert_count}条，" \
"仅确认#{@acked_count}条，落差#{gap}" if gap >= GAP_THRESHOLD
end
end
def maybe_probe(now)
return unless now - @last_probe >= PROBE_INTERVAL
@last_probe = now
digest = @local.state_digest
reply = @peer.probe(digest) # 解码器比对后回话
unless reply[:match]
@alarms << "状态失配：本地#{digest}，对端#{reply[:digest]}，" \
"建议重置动态表"
end
end
end检测器给出了两条告警路径：水位线落差告警和探测哈希失配告警。前者响应快，适合捕捉刚发生的丢失；后者兜底，能发现长期累积的漂移，比如某条指令被中间件悄悄丢弃但解码器没有察觉的场景。解码器侧的probe实现很简单，收到编码器摘要后与自己本地的摘要比对即可。
失配后的恢复策略与注意事项
检测到丢失只是第一步，合理的恢复动作同样重要。规范层面的标准做法是让编码器在失配后停止引用动态条目，改用字面量编码发送头部，同时通过Set Capacity指令把动态表容量压到极小甚至为零，逼迫两端同步收缩到一致状态，再重新协商容量重建表。这种方式的代价小、兼容性好，推荐作为默认策略。
def recover_from_mismatch!
# 第一步：通知对端收缩容量，两端同步清空条目
send_set_capacity(0)
@local.reset!
# 第二步：一段时间内全部改用字面量编码，不用相对索引
@encoder.literal_only_mode = true
# 第三步：确认对端也完成收缩后，恢复容量并解除限制
after_ack do
send_set_capacity(@original_capacity)
@encoder.literal_only_mode = false
log '动态表已重建，恢复索引编码'
end
end有几个工程细节值得注意。第一，探测指令本身也可能丢失，所以告警要做成幂等的，连续两次失配再触发恢复，避免误杀。第二，哈希比对应放在连接空闲时进行，避免和正常请求争抢解码器资源。第三，如果你的Ruby实现是跑在rsock或原生QUIC库之上的封装层，记得把检测器的tick频率和底层流的ACK机制对齐，否则会出现两层超时互相打架的情况。把这套状态哈希加水位线的思路落地后，QPACK动态表失配问题基本能在秒级被发现，远早于它演变成解码故障的那一刻。