nftables concat通过多字段拼接成复合键实现O(1)哈希查表，替代线性匹配；支持最多16字段组合（如IP+端口+ICMP类型），总长≤256字节，提升吞吐、降低CPU 30%～35%。
利用 nftables 的 concat 特性实现单条规则多流高效匹配，核心是把多个网络维度“压缩”成一个复合键，让内核用哈希查表（O(1)）替代传统逐条比对。它不靠堆规则数量，而是靠结构升级提升吞吐能力。
理解 concat 的工作逻辑
传统写法如 nft add rule ip filter input ip saddr 192.168.10.5 tcp dport 8080 accept 是线性匹配：每来一个包，都要依次检查源 IP、再检查端口、再判断协议……字段越多，开销越大。而 concat 把这些字段拼成唯一标识，例如：
ip saddr . tcp dport → 192.168.10.5 . 8080
这个组合值直接作为 key 查 map，命中即执行对应动作，跳过其余规则遍历。
构建支持多流匹配的 concat 映射
以“仅允许指定 IP 访问指定服务端口+协议”为例：
- 定义映射，声明字段类型与组合结构：
nft add map ip filter multi_flow_map { type ipv4_addr . inet_service . icmp_type : verdict; }
（这里拼接了 IP + 端口 + ICMP 类型，适用于混合 TCP/UDP/ICMP 策略） - 插入多维规则项：
nft add element ip filter multi_flow_map { 192.168.10.5 . 8080 . 0 : accept, 10.0.20.12 . 3306 . 0 : drop, 203.0.113.7 . 53 . 3 : accept }
（分别对应 HTTP、MySQL、DNS 查询的精细控制） - 在链中调用：
nft add rule ip filter input @multi_flow_map { ip saddr . tcp dport . icmp type } counter
扩展更多匹配维度的实用组合
concat 最多支持 16 字段拼接，常见高价值组合包括：
-
IP + 接口 + 协议 + 端口：
ip saddr . iifname . meta l4proto . tcp dport
可区分 eth0 上的 192.168.1.100:22 和 br0 上同 IP 的相同端口，适合多网桥或容器宿主机场景 -
源 IP + 连接状态标记 + 时间段：
ip saddr . ct state . @time_slot
需提前用 set 存储时间片段（如set time_window { type time; }），实现“工作时间只放行运维 IP”类策略 -
IP + 用户 UID + 目标域名哈希前缀（需配合 socket 模块）：
ip saddr . skuid . @domain_hash
用于主机级应用层分流，比如限制某用户只能访问白名单域名
注意：所有字段拼接后总长度不能超过 256 字节；IPv4 地址占 4 字节、端口占 2 字节、接口名按实际字符串长度计算，建议用 nft list map ... -n 查看原始二进制键值避免越界。
验证是否真正生效
concat 规则容易配置无误却静默不触发，调试时重点关注三点：
- 用
nft list map ip filter multi_flow_map -n查看插入的键是否为预期数值（比如 192.168.10.5 显示为 0x050aa8c0） - 加
counter并配合nft monitor trace抓包，确认匹配路径走的是@multi_flow_map而非 fallback 到默认 drop - 对比压测数据：5000 条传统规则 vs 同等策略的 concat 映射，CPU 占用通常低 30%～35%，新建连接延迟稳定在 0.3ms 内
