Linux TC Flower (cls_flower)：VPN 网关的线速硬件卸载技术

数据包分类的吞吐瓶颈：为何传统软件过滤器在 100G 下失效

在处理多吉比特聚合流量的高密度 VPN 边缘网关中，网络数据吞吐量极其巨大。当网络链路攀升至 25 Gbps、40 Gbps 或 100 Gbps 时，每秒流入系统的数据包数量经常突破数千万包（Mpps）。在如此极端的数据流下，数据包分类（即解析报文协议头并据此执行路由、过滤、限速及隧道分流的过程）成为制约系统吞吐的首要瓶颈。

在过去的架构中，Linux 工程师多采用 iptables 或早期 nftables 链表来执行报文过滤。虽然在小规模网关上表现良好，但在高吞吐场景下，纯软件链表会触及明显的物理极限：

软中断上下文中的线性规则逐行遍历：软件防火墙按顺序比对过滤规则。当数千万数据包经由 Linux 软中断程序（ksoftirqd）灌入协议栈时，遍历数百条规则会迅速消耗 CPU 计算周期。一旦 VPN 监听端口遭受大流量 UDP 报文冲击，处理器核心在完成认证之前便已被规则链遍历完全占满。
早期 TC 分类器中易错的比特位偏移运算：Linux 流量控制子系统传统的 u32 分类器需要手动计算数据包的字节偏移。面对可变长度的 IPv4 选项、IPv6 扩展报头以及复杂的隧道嵌套封装，u32 的位移计算极易失效。
系统内存总线拥塞与 CPU 缓存频繁失效：在软件转发模式下，每个进入网卡的数据包都必须穿过 PCIe 总线并在系统主内存中分配套接字缓冲区（sk_buff）。海量报文的涌入不断冲刷 CPU 的 L2 与 L3 缓存，导致用于 ChaCha20-Poly1305 和 AES-GCM 的加密计算单元无法获得充足的计算资源。

为了在海量并发下保持物理线速转发，现代高性能 VPN 网关需要一种能够将流分类逻辑直接下沉至网卡硬件硅片的先进技术：Linux TC Flower（cls_flower）。

深入剖析 Linux TC Flower (cls_flower) 分类架构

作为集成在现代 Linux 内核中的关键模块，Flower 分类器（cls_flower）将 Linux 流量控制（tc）子系统转变为高效的流分类引擎。与 u32 脆弱的偏移量计算不同，Flower 深度整合了内核原生协议解析器（flow dissector），能够结构化解析 Layer 2、Layer 3 以及 Layer 4 的关键报文头。

+-------------------------------------------------------------------------+
|                        入站以太网数据帧 (Ingress)                       |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  内核原生协议解析器 (Flow Dissector)                    |
|     - 提取 L2：MAC 地址、VLAN 标签、EtherType                           |
|     - 提取 L3：IPv4 / IPv6 源与目的地址、DSCP 字段                      |
|     - 提取 L4：UDP / TCP 端口号、TCP 标志位、ICMP 类型                  |
|     - 提取隧道封装键值（VNI、Tunnel ID）                                |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  TC Flower 掩码匹配哈希表 (Mask-and-Match)              |
|   - 基于预设元组键执行近乎 O(1) 的常数时间快速哈希检索                 |
+-------------------------------------------------------------------------+
         |                                  |
     匹配成功                           未命中规则
         |                                  |
         v                                  v
+-----------------------+          +-----------------------+
|  执行预设 TC 动作     |          | 默认转发逻辑          |
|  - drop（直接丢弃）   |          | 进入常规 IP 协议栈    |
|  - mirred redirect    |          +-----------------------+
|  - police（速率管控） |
|  - skbedit priority   |
+-----------------------+

TC Flower 的核心架构特性

掩码匹配哈希表（Mask-and-Match）：Flower 根据规则的位掩码对过滤器进行分组。进入的数据包仅需针对相关报文头字段计算一次哈希，即可在近乎常数时间 O(1) 内完成精准匹配，检索耗时不会随规则数量膨胀。
协议感知深度匹配：Flower 原生支持对多层网络属性的直接匹配，无需编写底层计算逻辑，包括 VLAN 标签（vlan_id、vlan_prio）、服务类型标识（ip_tos）、TCP 连接控制位（tcp_flags syn）以及特定 UDP 端口特征。
多功能动作编排：当报文命中规则后，Flower 可以串联执行丰富的数据处理动作，例如快速丢弃（action drop）、硬件重定向（action mirred egress redirect）、精细限速（action police）或套接字优先级调整（action skbedit）。

在目标网络设备上部署 Flower 规则前，需首先为其挂载 ingress 排队规则：

# 在物理网络接口 enp1s0f0 上添加 ingress 入站队列
tc qdisc add dev enp1s0f0 ingress

# 匹配并丢弃所有指向本地管理端口的无效 UDP 数据包
tc filter add dev enp1s0f0 ingress protocol ip prio 10 flower \
    ip_proto udp \
    dst_port 53 \
    action drop

利用 ASIC 硬件卸载实现物理线速分类

虽然 Flower 在内核软件内存中已具备很高的检索性能，但其最核心的架构优势在于通过 switchdev 框架无缝支持 ASIC 硬件卸载（Hardware Offload）。

企业级智能网卡（如 Intel Columbiaville E810 或 Mellanox ConnectX-5/6/7）内置了可编程的数据包处理引擎与 TCAM（三态内容寻址内存）。当配置硬件卸载标记后，Linux 内核会将 Flower 规则自动转化为硬件微代码，并写入网卡内部的硬件分类流表中。

+-------------------------------------------------------------------+
|                       物理光纤通信介质                            |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|               光收发模块及网卡物理层 MAC / PHY                     |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|             网卡内部片上硬件解析器与 TCAM 流表                    |
|                （由 TC Flower 卸载的硅片规则）                    |
|                                                                   |
|   规则：丢弃异常 UDP 流量 (skip_sw)  --> [在芯片内部直接销毁]     |
|   规则：精准引导 51820 端口流        --> [DMA 直达专用 CPU 核心]  |
+-------------------------------------------------------------------+
            | （仅经硬件验证的合法 VPN 加密报文进入主机）
            v
+-------------------------------------------------------------------+
|                 主机 PCIe 总线与系统内存 (DMA)                    |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|                RiceGuard 多线程高并发解密工作引擎                 |
+-------------------------------------------------------------------+

TC Flower 的三种硬件卸载执行模式

在下发策略时，管理员可通过参数明确限定执行环境：

自动卸载（默认）：若硬件驱动支持该规则，内核便将其下发至网卡 ASIC，同时在主机软件内存中保留副本。若硬件表项耗尽，系统自动退回至软件执行。
skip_hw 模式：强制规则仅在主机内核内存中运行，不占用网卡硬件流表。适用于包含复杂自定义动作的边缘规则。
skip_sw 模式（硬件独占执行）：强制规则必须且仅在网卡物理硅片内部生效。若硬件芯片无法完美支持该匹配模式或动作，tc 命令将立刻报错中断。

在 100 GbE 光口上配置纯硬件防护规则的示例如下：

# 在网卡硅片中直接丢弃伪造源 IP 网段的攻击报文
tc filter add dev enp1s0f0 ingress protocol ip prio 1 flower \
    src_ip 198.51.100.0/24 \
    skip_sw \
    action drop

# 将合法 VPN 业务流量直接分流至高优先级硬件队列
tc filter add dev enp1s0f0 ingress protocol ip prio 2 flower \
    ip_proto udp \
    dst_port 51820 \
    skip_sw \
    action skbedit priority 1

启用 skip_sw 后，未授权或异常的数据包在网卡物理层（PHY/MAC）就被直接丢弃。主机 PCIe 总线无需传输多余字节，主内存无需分配 sk_buff，处理器的软中断负载完全保持为 0%。

RiceGuard 高性能网关中的安全策略落地

在 VPNRice 的大规模分布式网络基础设施中，RiceGuard 协议通过将现代加密机制与硬件级流分发深度结合，保障了网络的高吞吐量与租户间的严格物理隔离。

+-------------------------------------------------------------------+
|                     VPNRice 边缘硬件网关节点                      |
|                                                                   |
|   +-----------------------------------------------------------+   |
|   |         100 GbE 物理网卡（Intel / Mellanox）              |   |
|   |         硬件 TCAM 芯片：TC Flower 规则表 (skip_sw)        |   |
|   +-----------------------------------------------------------+   |
|         |                                           |             |
|   [51820 端口合法 VPN 流量]               [未授权流量 / 异常涌浪] |
|         |                                           |             |
|         v                                           v             |
|   专用 RX 接收环 DMA 传输                 网卡内部直接丢弃        |
|         |                                 （0% 主机 CPU 占用）    |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  |                 RiceGuard 内核加密处理中心                  |  |
|  |                 ChaCha20-Poly1305 线速解密运算              |  |
|  +-------------------------------------------------------------+  |
|         |                                                         |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  | 隔离网络命名空间与加密 DNS 代理                             |  |
|  | 彻底杜绝明文数据逃逸与解析泄露                             |  |
|  +-------------------------------------------------------------+  |
+-------------------------------------------------------------------+

1. 入站流量硬件级精准分流

RiceGuard 并不依赖全局共享的软件单队列，而是通过 TC Flower 规则实时识别合法的 WireGuard/RiceGuard 报文。网卡 ASIC 会借助 RSS（接收端缩放）机制，将不同的业务流直接分发到与特定 CPU 核心绑定的独立接收队列上，消除内核锁冲突，将转发延迟稳定在亚毫秒以内。

2. 未认证流量的片上拦截防护

未经认证的海量报文可能迫使 VPN 网关频繁消耗算力响应握手。通过部署 TC Flower 硬件限速策略（action police rate 100mbit burst 10k drop skip_sw），网关节点能够在网卡物理芯片内部为握手端点设定严密的速率包络。异常流量在进入主机 CPU 前即被削峰，保障了解密处理线程的持续高响应能力。