在 BGP 路由策略里，AS_PATH 是路径中自治系统号的序列，比如 65001 65002 65003。用 Ruby 分析路由表或做临时过滤时，最直白的写法是对整条路径字符串跑正则。比如想保留从 65001 学到的路由，常见写法是 as_path =~ /^65001_/。这个表达式在 Cisco 风格的正则里表示起点为 65001，但 Ruby 的正则并不会把下划线当成边界，直接移植不仅语义有偏差，性能也容易在批量场景中暴露问题。

为什么直接正则匹配会成为瓶颈

问题首先来自正则字面量的创建时机。在 Ruby 中，/^65001_/ 如果写在循环体内，每次迭代都会产生一个新的 Regexp 对象。单次开销可以忽略，但全量路由表几万条、几十万条时，对象分配和 GC 扫描会明显上升。下面这段代码就是典型的低效版本：

paths = ["65001 65002 65003", "65002 65003", "65003 65004 65005"]
paths.each do |as_path|
  if as_path =~ /^65001_/
    puts as_path
  end
end

即使把正则提成变量，如果继续用 =~，Ruby 会为每次成功匹配构造 MatchData 对象。MatchData 携带捕获信息，但这里只需要判断是否命中，并不关心位置和分组。换成 regexp.match?(str) 后，解释器只返回 true 或 false，省去了这部分分配。

另一个隐藏成本是回溯。AS_PATH 最长可能有几十跳甚至上百跳，字符串不短。如果规则里含有未锚定的重复片段或模糊量词，正则引擎可能需要在字符间反复尝试。很多情况下，策略只是判断前缀或包含某个 AS，这种需求用正则解决反而扩大了扫描范围。

预编译缓存与 match? 的配合

先把规则转换成 Regexp 对象并缓存起来，是投入最小、收益直接的一步。规则数量通常不多，可以放在一个全局 Hash 中，用 Mutex 保护并发访问。下面是一个线程安全的匹配器：

require 'thread'
module BgpAsPathMatcher
  @cache = {}
  @mutex = Mutex.new
  def self.match?(as_path, pattern)
    regexp = @mutex.synchronize do
      @cache[pattern] ||= Regexp.new(pattern)
    end
    regexp.match?(as_path)
  end
end

这个方法把正则创建从热路径中移出。@cache[pattern] ||= Regexp.new(pattern) 只在首次出现某个规则时编译，之后直接复用。线程竞争不激烈时，Mutex 的同步成本远低于重复创建正则。若脚本是单线程处理文件，也可以用普通 Hash，减少锁开销。

需要注意 match? 与 =~ 的返回值不同。=~ 返回整数位置或 nil，match? 返回布尔值。用在条件判断里两者都能工作，但 match? 不会产出 MatchData，因此更适合只需要真假的路由过滤。

缓存键最好只使用已经规范化过的白名单规则。如果 pattern 直接来自用户输入，缓存字典可能无限增长。可以限制规则数或在启动时一次性编译，避免运行时动态拼装未知模式。

前缀与包含判断降级为数组操作

BGP 策略里出现频率最高的规则是检查路径起点、末位 AS 或是否包含某个 AS。这些语义可以完全脱离正则。先把 AS_PATH 按空格切成数组，再用 first、last、include? 处理。

class FastAsPathMatcher
  def initialize(rules)
    @prefixes = []
    @contains = []
    @adjacent = []
    rules.each do |rule|
      case rule[:type]
      when :prefix
        @prefixes.push(rule[:as])
      when :contains
        @contains.push(rule[:as])
      when :adjacent
        @adjacent.push([rule[:left], rule[:right]])
      end
    end
  end
  def match?(as_path)
    segments = as_path.split
    return false if @prefixes.any? && !@prefixes.include?(segments.first)
    unless @contains.empty?
      return false if @contains.none? { |asn| segments.include?(asn) }
    end
    unless @adjacent.empty?
      return false if @adjacent.none? do |left, right|
        segments.each_cons(2).include?([left, right])
      end
    end
    true
  end
end

这个匹配器把规则分成三类。前缀规则只比较 segments.first，包含规则使用数组的 include?，相邻规则通过 each_cons(2) 遍历二元组。数组操作全部是线性扫描或首尾直接访问，没有正则状态机参与，也不需要转义 AS 号。

如果需要保留 BGP 正则里的下划线边界语义，比如 _65002_ 表示路径中单独出现 65002，可以理解为数组中的某个元素等于 65002。真正的正则边界转换反而容易出错：下划线在 BGP 里可能表示空格、逗号、行首或行尾，直接替换成 \s+ 并不能完全等价。因此能用数组表达的策略，优先用数组表达。

对于复杂模式，例如 ^65001_(65002|65003)*$ 这种 AS 集合和重复，仍可使用预编译正则。但需要在传入 Ruby 前做一层转换，把 BGP 的正则语法映射成 Ruby 正则语法，比如把 ^ 换成 \A，$ 换成 \z，下划线按实际分隔符替换。一个简化的转换函数如下：

def to_ruby_regexp(bgp_pattern)
  converted = bgp_pattern.gsub('_', '\\s+')
  converted = converted.sub(/\A\^/, '\\A')
  converted = converted.sub(/\$\z/, '\\z')
  Regexp.new(converted)
end

这段代码只覆盖常见场景，生产环境还需要处理花括号重复、可选子句等。核心思路是让少量复杂规则走正则，大量简单规则走数组，两类逻辑可以在一个入口中组合。

基准测试与 ReDoS 防护

优化效果可以通过 Benchmark 直观对比。假设 AS_PATH 有 80 跳，规则是起点为 65001，分别测试循环内正则、预编译 match? 和字符串前缀判断：

require 'benchmark'
path = (1..80).map { |i| (65000 + i).to_s }.join(' ')
pattern = '^65001_'
regexp = Regexp.new(pattern)
n = 100_000
Benchmark.bm do |x|
  x.report('literal regex') do
    n.times { path =~ /^65001_/ }
  end
  x.report('precompiled') do
    n.times { regexp.match?(path) }
  end
  x.report('string prefix') do
    n.times { path.start_with?('65001 ') }
  end
end

在普通笔记本上，字符串前缀判断通常比循环内正则快两个数量级以上，预编译 match? 也比每次创建正则快数倍。绝对数字会受 Ruby 版本和字符串长度影响，但趋势稳定。主要收益来自减少 Regexp 创建、去掉 MatchData 分配，以及首部判断避免扫描整条路径。

还要警惕正则本身带来的 ReDoS。AS_PATH 长度不可控，如果规则来自外部，攻击者可能提交包含嵌套量词的表达式，例如 (a+)+$。在 Ruby 的 Onigmo 引擎上，这类模式遇到长字符串可能产生指数级回溯。应对措施包括限制 AS_PATH 长度、维护规则白名单、禁止多个相邻量词嵌套，以及优先使用字符串操作。Ruby 标准库没有为正则直接提供超时参数，Timeout 包装又引入线程安全问题，因此从输入和规则两端做限制更可靠。

总体看，优化 BGP AS_PATH 匹配并不是要把所有正则都替换掉，而是分清简单判断和复杂模式。简单规则用数组，复杂规则预编译并缓存，加上 match? 和长度限制，能在不增加复杂度的前提下显著改善批量路由处理的效率。