HTTP/3中的QPACK头部压缩通过动态表减少重复字段传输，但动态表容量变化必须被编码器和解码器同步感知。否则编码器引用了一个已被解码器驱逐的条目，解码器就会因为无法解析头部块而终止连接。Ruby作为实现QUIC协议栈的常用语言，需要有一套清晰的状态机来管理动态表容量更新通知。这个通知并不是单一的控制帧，而是由编码器指令、解码器回传以及阻塞流释放共同组成的一套机制。
动态表容量更新通知的协议触发条件
在QPACK规范RFC 9204中，动态表容量由两个层次定义：协商上限和实际使用量。SETTINGS_QPACK_MAX_TABLE_CAPACITY给出编码器允许使用的最大容量，而SETTINGS_QPACK_BLOCKED_STREAMS限制了因插入计数滞后而阻塞的请求流数量。编码器在任意时刻可以调整实际容量，但不得超过协商上限。触发调整的条件通常包括内存压力、优先级变化或者对端希望降低资源占用。
当编码器决定改变动态表容量时，它会在编码器流上发送一条Set Dynamic Table Capacity指令，指令格式为001开头，后面跟着用前缀整数编码的新容量值。这条指令本身不携带请求流ID，它是单向作用于整个连接的状态变更。编码器同时还需要重新计算Required Insert Count，因为动态表容量变化可能驱逐部分条目，导致后续头部块需要更少的插入计数。这里的通知机制关键点在于：容量变更后，编码器不能假设解码器立刻知道，而是通过后续头部块中的Required Insert Count字段和Decoder Stream中的确认来逐步收敛状态。
解码器收到该指令后，会调整自己的动态表上限，并驱逐超出部分的条目。随后解码器在Decoder Stream上发送Insert Count Increment，其值为解码器已经成功处理的插入总数。编码器收到这个增量后，更新已确认插入计数，并检查是否有被阻塞的流可以恢复处理。这一系列动作构成了完整的容量更新通知闭环。
Ruby实现中的状态字段与通知触发
用Ruby实现时，可以把编码器侧的状态封装在一个QpackEncoder类中。至少需要维护五个核心字段：最大表容量max_table_capacity、当前表容量current_table_capacity、插入计数insert_count、已确认插入计数acked_insert_count以及一个阻塞流哈希blocked_streams。哈希的键为流ID，值为该流所需的插入计数。此外还有一个编码器流输出缓冲区，用来承载指令。
容量变更通知的触发入口可以设计为change_table_capacity方法。方法首先校验新容量是否在合法范围内，然后编码并写入Set Dynamic Table Capacity指令，接着更新当前容量并驱逐条目。驱逐条目会降低insert_count？实际insert_count是单调递增的条目序号，驱逐条目不会减少insert_count，但会影响动态表的可用空间。通知机制中需要额外维护required_insert_count，它表示最近一次编码头部块时所需的插入计数，通常等于insert_count减去被驱逐条目数。用Ruby实现时，可以在驱逐完成后重新计算该值。
class QpackEncoder
attr_reader :current_table_capacity, :insert_count, :acked_insert_count
def initialize(max_table_capacity)
@max_table_capacity = max_table_capacity
@current_table_capacity = 0
@insert_count = 0
@acked_insert_count = 0
@blocked_streams = {}
@encoder_buffer = +"".b
@dynamic_entries = []
end
def change_table_capacity(new_capacity)
if new_capacity < 0 || new_capacity > @max_table_capacity
raise ArgumentError, "invalid table capacity"
end
# 发送Set Dynamic Table Capacity指令，指令码为001
prefix_int = encode_prefix_integer(new_capacity, 5, 0x20)
@encoder_buffer << prefix_int
@current_table_capacity = new_capacity
evict_entries_to_fit(new_capacity)
update_required_insert_count
end
private
def evict_entries_to_fit(capacity)
# 根据容量移除最老的条目，并更新实际占用
while @dynamic_entries.sum(&:size) > capacity
@dynamic_entries.shift
end
end
def update_required_insert_count
@required_insert_count = @insert_count - @dynamic_entries.size
end
end
上面的代码展示了通知触发的核心流程。change_table_capacity方法首先对输入做边界检查，然后使用前缀整数编码生成指令字节。在真实实现中，前缀整数编码需要处理多字节情况，这里简化为返回单个字节或字符串。完成后调用evict_entries_to_fit驱逐条目，并更新required_insert_count。注意当前容量变化不会直接影响insert_count，而是通过required_insert_count反映编码器对解码器的依赖程度。
通知机制还涉及阻塞流的登记。当编码器编码一个头部块时，如果required_insert_count大于acked_insert_count，并且阻塞流数量未超过限制，就需要把该流ID和所需插入计数记录到blocked_streams中。这样后续收到确认时才能找到对应的流进行解除阻塞操作。
解码器侧确认与通知闭环
解码器侧需要实现对应的指令解析和状态更新。当解码器在编码器流上收到Set Dynamic Table Capacity指令后，会调整自己的动态表上限，驱逐条目，并把当前已处理的插入计数通过Insert Count Increment指令回传给编码器。在Ruby中可以定义QpackDecoder类，维护类似的状态字段。
Decoder Stream上的Insert Count Increment编码为00开头的指令。解码器每处理完一个头部块中的插入条目，就会增加自己的insert_count。当容量变更导致驱逐时，解码器不需要减少insert_count，因为insert_count是单调递增的。编码器收到Insert Count Increment后，更新acked_insert_count，然后遍历blocked_streams，找出所有required_insert_count小于等于acked_insert_count的流，将它们标记为可继续处理，并从哈希中删除。
class QpackDecoder
attr_reader :insert_count, :table_capacity
def initialize(max_table_capacity)
@max_table_capacity = max_table_capacity
@table_capacity = 0
@insert_count = 0
@dynamic_entries = []
@decoder_buffer = +"".b
end
def process_encoder_instruction(bytes)
case bytes[0] & 0xE0
when 0x20
# Set Dynamic Table Capacity
new_capacity = decode_prefix_integer(bytes, 5, 0x20)
@table_capacity = new_capacity
evict_entries_to_fit(new_capacity)
send_insert_count_increment
end
end
def send_insert_count_increment
# 指令码00，插入计数增量
@decoder_buffer << encode_prefix_integer(@insert_count, 6, 0x00)
end
private
def evict_entries_to_fit(capacity)
while @dynamic_entries.sum(&:size) > capacity
@dynamic_entries.shift
end
end
end
上面的解码器实现中，process_encoder_instruction通过判断第一个字节的高三位来区分指令类型。当识别到Set Dynamic Table Capacity时，解码器解析新容量、更新本地表容量、驱逐多余条目，然后立即发送Insert Count Increment。编码器侧收到该通知后，执行确认处理逻辑。这个闭环保证了容量变更不会在两端长期不一致。
还有一点需要强调：Insert Count Increment回传的是解码器当前的insert_count，而不是容量值。编码器并不关心解码器的动态表容量本身，而是关心解码器已经处理了多少插入条目，因为头部块的解码依赖这些条目的存在。容量变更导致驱逐后，解码器能够处理的插入条目范围会缩小，编码器通过确认计数可以判断哪些头部块已无法解码。
边界条件与测试策略
实现容量更新通知机制时，有几个边界条件必须覆盖。第一个是零容量场景，当new_capacity为0时，动态表中的所有条目都要驱逐，required_insert_count会下降。此时编码器不能再引用任何动态条目，后续头部块全部使用静态表或原样编码。第二个是容量突增场景，从较小容量直接调到上限，不会驱逐条目，但可能改变阻塞流判断，因为更多的插入条目可以被保留。第三个是流取消，如果被阻塞的流在确认到达前被取消，编码器可以发送Stream Cancellation指令，并提前清理blocked_streams中的记录。
测试时可以用Ruby的Minitest框架构造单元测试。先创建编码器和解码器实例，设置最大容量为1024字节。编码器调用change_table_capacity(512)，断言编码器流缓冲区包含合法指令，且当前容量更新为512。然后模拟解码器处理该指令，断言解码器回传了Insert Count Increment。最后编码器处理该回传，断言acked_insert_count得到更新，并且此前登记的阻塞流被解除。
require "minitest/autorun"
class QpackNotifyTest < Minitest::Test
def test_capacity_update_notification_roundtrip
encoder = QpackEncoder.new(1024)
decoder = QpackDecoder.new(1024)
encoder.change_table_capacity(512)
instruction = encoder.instance_variable_get(:@encoder_buffer)
decoder.process_encoder_instruction(instruction.bytes)
ack_instruction = decoder.instance_variable_get(:@decoder_buffer)
encoder.process_decoder_instruction(ack_instruction.bytes)
assert_equal 512, encoder.current_table_capacity
assert_equal decoder.insert_count, encoder.acked_insert_count
end
end
测试代码中的process_decoder_instruction在编码器类中需要实现，用于解析Decoder Stream上的确认指令。这个测试重点验证容量更新通知能够走完编码器发送、解码器处理、回传确认、编码器更新状态的完整闭环。实际项目中还需要加入前缀整数编码的详细测试，因为该编码在容量较大时可能占用多个字节。
最终，Ruby实现QPACK动态表容量更新通知机制的关键在于把协议中分散的指令和字段组合成明确的状态转移。只要编码器和解码器各自维护正确的插入计数与容量值，就能在HTTP/3连接中避免因动态表不同步导致的头部解码失败。