HTTP/2协议引入了多路复用与流依赖树机制，使得同一个TCP连接上的多个流可以通过显式的父子关系和权重值来分配可用带宽。理解权重调整如何改变流量分布，是排查接口耗时抖动的重要手段。本文使用Ruby语言从帧数据层面建模依赖树，量化权重变化对流量的影响，并提供可直接运行的示例代码。
HTTP/2依赖树与权重模型的基础原理
在HTTP/2中，每个流都可以声明一个父流以及介于1到256之间的权重值。权重并不直接等于带宽百分比，而是表达了兄弟流之间的相对分配比例。当多个子流挂在同一个父流之下时，父流可用的带宽会按照子流权重之和进行分割，权重越高的流获得的发送机会越多。真正的传输比例还受流状态、窗口大小以及独占依赖标记的影响。
很多工程师误以为把某个流的权重从16改成32，该流流量就会精确翻倍，实际上若其父流本身被更高层级的依赖限制，或者设置了独占依赖导致原有兄弟被挂到子节点，带宽分配会被重构。Ruby适合用来把这些层级关系抽象成树结构，通过遍历计算出每个叶子流的理论有效权重，从而看清配置改动背后的数学含义。
我们可以用一个简单类来表达节点。每个节点保存自身权重、子节点列表以及是否独占。通过递归将局部权重换算为全局比例，就能在调整前后分别输出各流的占比，避免仅凭直觉判断。下面给出基础模型代码。
class Http2Node
attr_accessor :stream_id, :weight, :children, :exclusive
def initialize(stream_id, weight = 16, exclusive = false)
@stream_id = stream_id
@weight = weight
@children = []
@exclusive = exclusive
end
# 计算以本节点为根时，每个流ID对应的全局权重比例
def compute_shares(parent_weight_sum = nil)
result = {}
current_sum = @children.map(&:weight).inject(0, :+)
current_sum = 1 if current_sum == 0
@children.each do |child|
share = child.weight.to_f / current_sum
if child.children.empty?
result[child.stream_id] = share
else
sub = child.compute_shares
sub.each { |k, v| result[k] = v * share }
end
end
result
end
end
使用Ruby解析帧数据并重构依赖树
要分析真实流量影响，第一步是从抓包文件或日志中提取HEADERS帧和PRIORITY帧。Ruby可以借助二进制字符串切片解析HTTP/2帧头，拿到Stream ID、依赖Stream ID、权重和独占标志。把这些关系逐条应用到我们上面定义的树中，就得到了某次连接的实际依赖拓扑。
需要注意，PRIORITY帧中的依赖Target Stream可能尚未在树中创建，因此解析时应使用哈希暂存所有节点，遇到未知ID则先建空节点，等后续帧补全权重。下面示例展示了一个简化版解析循环，它读取一组伪造的帧描述并构建树。真实场景可替换为对pcap或h2日志的读取。
解析完成后，对比调整权重前后的compute_shares输出，就能看到例如流A从占比25%降为12%，而流B升至50%。这种量化结果比单纯看权重数字更有说服力，也方便向业务方解释为何某个接口变慢。代码如下。
nodes = {}
frames = [
{type: :priority, stream: 3, dep: 0, weight: 16, excl: false},
{type: :priority, stream: 5, dep: 3, weight: 32, excl: false},
{type: :priority, stream: 7, dep: 3, weight: 16, excl: false}
]
frames.each do |f|
next unless f[:type] == :priority
nodes[f[:stream]] ||= Http2Node.new(f[:stream])
nodes[f[:dep]] ||= Http2Node.new(f[:dep])
nodes[f[:stream]].weight = f[:weight]
nodes[f[:stream]].exclusive = f[:excl]
nodes[f[:dep]].children << nodes[f[:stream]] unless nodes[f[:dep]].children.include?(nodes[f[:stream]])
end
root = nodes[0]
shares = root.compute_shares
puts shares.inspect
权重调整对流量的影响评估与模拟方法
拿到依赖树份额后，可进一步结合历史吞吐数据估算真实流量变化。假设父流所在连接稳定带宽为1000KB/s，那么叶子流理论速率即为份额乘以带宽。将调整前和调整后的速率做差，就能得出某业务流是会受挤压还是获增益。Ruby可以批量读取多组权重方案，自动生成对比表。
实践中我们发现，仅下调某个叶子权重但保留其兄弟独占依赖，会造成该叶子流量骤降甚至长期饥饿。通过在Ruby脚本中模拟独占标志切换，能提前暴露这种隐患。以下代码演示如何输出两种方案的对比，并用表格形式打印，方便纳入压测报告。
这种分析方法的价值在于把抽象的协议参数转成可读的数字。团队在调整网关推送策略或API优先级时，先跑一遍Ruby脚本，就能知道权重改动会不会引发隐性争抢，而不必等到监控告警才被动响应。
def compare_schemes(root_before, root_after)
before = root_before.compute_shares
after = root_after.compute_shares
puts "Stream | Before% | After% | Delta%"
before.keys.each do |sid|
b = (before[sid] * 100).round(2)
a = (after[sid] * 100).round(2)
puts "#{sid} | #{b} | #{a} | #{(a - b).round(2)}"
end
end
# 假设root_before与root_after为两组不同权重构建出的Http2Node根
# compare_schemes(root_before, root_after)
在Ruby中落地持续分析与避坑建议
建议将上面的解析与对比逻辑封装为Rake任务或CI脚本，每次变更HTTP/2优先级配置前自动运行。可把线上抓取的帧序列落盘为JSON，由Ruby读取并断言关键流的份额波动不超过阈值，从而实现配置防护。这样能防止有人误将权重调得过低却未察觉。
另一个常见坑是忽略流取消后仍残留的依赖节点。HTTP/2中流关闭不会自动清理父树结构，若脚本不处理closed状态，会导致份额计算偏大。Ruby侧应在解析时标记流状态，并在compute_shares中跳过已关闭节点，保证结果贴合真实运行态。
最后，权重分析只是手段，真正解决问题还要结合TCP拥塞窗口与接收端窗口。Ruby模型给出的比例应与实际压测曲线交叉验证，才能形成可靠的流量影响结论。