HTTP/3的流控来自QUIC层，和TCP的滑动窗口思路相似，但由于QUIC支持多路独立的流，流控被拆分成了连接级和流级两个层次。连接级控制所有流的总接收缓存，流级控制单个流的接收上限。发送端每发送一段数据，就会消耗对应的接收窗口信用，当信用耗尽时，发送必须暂停，直到收到对端发来的更新帧。这块逻辑如果用Ruby来实现，需要处理几个关键点：窗口增量的触发条件、信用恢复帧的发送时机，以及阻塞后的解除策略。
HTTP/3流控的核心概念与信用消耗模型
在QUIC中，每个流都有一对窗口：发送窗口和接收窗口。我们这里讨论的是接收端维护的窗口，它决定了发送端还能向该流发送多少字节。每当接收端从流中读取数据后，接收缓冲区就会释放出空间，此时接收端可以决定把新增的可用窗口以信用更新的形式告知对端。信用更新通常通过MAX_STREAM_DATA帧（流级）和MAX_DATA帧（连接级）来传递，帧中携带一个绝对上限值，告诉对端当前允许发送的最大偏移量。
信用消耗是发送端的行为，接收端只需要记录已经通告的窗口上限，以及当前实际接收到的数据偏移。假设初始窗口大小为16KB，接收端通告上限为16384。发送端可以连续发送最多16KB数据，接收端应用层每次读取4KB，那么每读取一次，接收缓冲区就多出4KB空间，此时接收端可以决定是否立刻通告新的上限。如果每次都通告，就能保持发送端始终有窗口可用，但也可能产生大量的小帧，浪费带宽。如果延迟通告，则可能让发送端因信用不足而阻塞，增加时延。
阻塞恢复的难点在于：接收端如何知道自己当前缓冲区的剩余空间足够大到值得发送一次更新？如果简单地在每次读取后都更新，虽然无阻塞，但帧开销大；如果等到缓冲剩余空间超过某个阈值才更新，又需要准确判断发送端是否已经因为窗口耗尽而停止发送。因为在HTTP/3中，接收端无法直接看到发送端的状态，只能通过定时器或数据到达的间隔来推测。
用Ruby构建流控信用管理器
下面实现一个简化的Ruby类FlowController，它同时管理连接级和单个流的窗口。我们假设每个流有独立的StreamFlowController，而ConnectionFlowController负责汇总所有流消耗的信用，并向外提供统一的更新接口。为了简化，示例只做一个流级控制器，但会包含阻塞检测和恢复逻辑。
class StreamFlowController
attr_reader :stream_id, :recv_window, :max_recv_offset, :recv_buffer
def initialize(stream_id, initial_window: 16 * 1024)
@stream_id = stream_id
@initial_window = initial_window
@max_recv_offset = initial_window # 已通告给对端的绝对上限
@recv_buffer = 0 # 当前接收缓冲区中被应用层尚未读取的字节数
@recv_window = initial_window # 实际可用窗口大小（初始等于通告值）
@blocked = false
end
# 当数据到达时调用，增加缓冲区占用
def on_data_received(bytes_count)
@recv_buffer += bytes_count
# 检查是否因缓冲区接近上限而进入阻塞状态
if @recv_buffer >= @max_recv_offset
@blocked = true
end
end
# 当应用层从缓冲区读取数据后调用
def on_data_consumed(bytes_count)
@recv_buffer -= bytes_count
# 判断是否需要发送窗口更新
if should_advertise_update?
advertise_window_update
end
end
private
# 决定是否发送更新：剩余空间大于窗口的1/4时触发，或当前已阻塞且空间大于0
def should_advertise_update?
available = @max_recv_offset - @recv_buffer
return true if @blocked && available > 0
available >= (@initial_window / 4)
end
# 发送MAX_STREAM_DATA帧，更新绝对上限
def advertise_window_update
new_abs_offset = @recv_buffer + @initial_window
@max_recv_offset = new_abs_offset
@blocked = false
# 在实际协议栈中，这里会调用帧发送接口
puts "[Stream #{@stream_id}] 发送MAX_STREAM_DATA，新上限=#{new_abs_offset}"
end
end
这个类的基本思路是：维护一个绝对上限max_recv_offset，表示当前对端允许发送到的最大字节偏移。每当收到数据，recv_buffer增加，如果缓冲区占用达到或超过上限，就设置blocked为true。应用层读取数据后，recv_buffer减少，随后判断是否需要更新窗口。更新的条件是阻塞状态解除时立即更新，或者未阻塞但剩余可用空间达到初始窗口的四分之一以上。这样既能及时解除阻塞，又不会过于频繁地发送更新帧。
注意这里我们用绝对偏移量来通告窗口，而不是增量。QUIC规范建议使用绝对偏移量，因为接收端能够明确知道发送端的当前发送位置。如果使用增量，就需要额外的确认机制，容易出错。当advertise_window_update被调用时，新的绝对上限设置为当前缓冲区占用加上初始窗口大小，相当于把窗口整体向前滑动，保证发送端始终有足够的信用继续发送。
阻塞检测与恢复的完整流程
阻塞不仅仅发生在单个流上，连接级别的流控也可能导致所有流都停摆。例如，连接级接收缓冲区被多个流的数据占满，即使某个流自己的窗口还有空间，也无法继续接收数据，因为连接级上限已经耗尽。因此，一个健壮的实现需要同时跟踪连接级信用，当连接级缓冲区被应用层消费后，需要广播连接级更新，并可能触发多个流的窗口更新。
下面扩展一个ConnectionFlowController，它持有多个StreamFlowController实例，并维护连接级接收缓冲区。当任意流的数据被消费后，连接级缓冲区减少，如果之前连接级处于阻塞状态，就需要立即发送MAX_DATA帧解除阻塞。同时，连接级更新可能释放出足够空间，允许之前因连接级限制而无法发送的流继续工作。
class ConnectionFlowController
def initialize(initial_conn_window: 64 * 1024)
@conn_window = initial_conn_window
@conn_buffer = 0
@max_conn_offset = initial_conn_window
@conn_blocked = false
@streams = {}
end
def register_stream(stream_id, stream_controller)
@streams[stream_id] = stream_controller
end
def on_conn_data_received(bytes_count)
@conn_buffer += bytes_count
if @conn_buffer >= @max_conn_offset
@conn_blocked = true
# 连接级阻塞会间接影响所有流，即使流级窗口还有空间也无法发送
end
end
def on_conn_data_consumed(bytes_count)
@conn_buffer -= bytes_count
if @conn_blocked && (@max_conn_offset - @conn_buffer) > 0
advertise_conn_update
@conn_blocked = false
# 解除连接级阻塞后，通知各流检查是否也需要发送流级更新
@streams.each_value do |stream_ctrl|
stream_ctrl.send(:advertise_window_update) if stream_ctrl.instance_variable_get(:@blocked)
end
end
end
private
def advertise_conn_update
new_abs_offset = @conn_buffer + @conn_window
@max_conn_offset = new_abs_offset
puts "发送MAX_DATA，新连接级上限=#{new_abs_offset}"
end
end
在上面的代码中，连接级阻塞解除时会检查所有已注册的流，如果某个流自身也处于阻塞状态，就强制触发其窗口更新。这种设计避免了某个流单独解除阻塞后，连接级仍然阻塞导致的其他流死锁。需要注意，这里直接用send调用私有方法advertise_window_update，在实际生产中应当封装成公开接口，例如maybe_send_stream_update。
整体流程可以总结为：接收数据→增加缓冲区→可能设置阻塞标志→应用读取→减少缓冲区→判断更新条件→发送更新帧→重置阻塞标志。对于连接级和流级需要分别处理，但两者可以统一抽象成相似的控制器逻辑，减少重复代码。
Ruby实现HTTP/3流控的关键在于窗口池的管理和更新时机的把握。阻塞恢复最忌讳的是发送端不知道接收端何时释放了空间，从而一直等待。通过合理的阈值和阻塞状态标志，可以在低开销和低时延之间取得平衡。实际协议栈中还需要考虑乱序数据、重传、以及定时器触发的主动更新，但以上示例已经覆盖了核心的信用更新与阻塞恢复框架。