数据平面核心功能：报文转发流程
各位同学，今天我们来聊聊数据平面最核心的部分——报文转发。说实话，我在做路由芯片的十几年里，见过太多工程师把转发流程想得太复杂。其实说白了，转发就是三个动作：收包、查表、发包。
但别小看这三个动作。我当年刚入行时，就因为在转发流程上少考虑了一个边界情况，导致芯片在压力测试下频繁丢包。嗯，那次教训挺深刻的。
转发流程的五个阶段
一个标准的报文转发，我习惯把它拆成五个阶段：
- 报文接收：从MAC层收上来，做CRC校验
- 头部解析：提取五元组、目的IP等关键字段
- 查表匹配：根据解析结果查找转发表
- 动作执行：修改TTL、重写MAC、封装VLAN等
- 报文发送：从对应端口发出去
你想想看，这五个阶段里，哪个最耗时？没错，就是查表匹配。我做过统计，在100Gbps的线速下，查表时间不能超过几十纳秒。否则，报文就会在芯片内部排队，最终导致丢包。
关键指标：转发延迟 < 100ns，吞吐量 = 线速 × 端口数
查表算法：LPM与精确匹配
查表是转发芯片的命门。这里有两种主流算法，我分别讲讲。
最长前缀匹配（LPM）
LPM主要用于IPv4/IPv6路由查找。为什么叫「最长前缀」？举个例子：
路由表：
192.168.1.0/24 → 端口1
192.168.0.0/16 → 端口2
0.0.0.0/0 → 端口3
目的IP：192.168.1.100
匹配结果：192.168.1.0/24 → 端口1
这里三个表项都能匹配，但我们要选前缀最长的那个。我在项目中遇到过一个问题：有人把默认路由（0.0.0.0/0）放在了最前面，结果所有流量都走了默认路由。嗯，这就是典型的「匹配顺序」坑。
避坑指南：我曾经因为LPM表项插入顺序不对，导致芯片在热升级后路由混乱。后来我强制要求：所有LPM表项必须按前缀长度降序排列。
精确匹配
精确匹配就简单多了。MAC地址表、ARP表、ACL规则，这些都用精确匹配。说白了就是：key完全相等才算命中。
我建议你在设计芯片时，把精确匹配和LPM分开做。为什么？因为它们的硬件实现完全不同。精确匹配适合用哈希表，LPM适合用Trie树或TCAM。
| 特性 | LPM | 精确匹配 |
|---|---|---|
| 匹配方式 | 最长前缀 | 完全相等 |
| 典型应用 | 路由表 | MAC表、ACL |
| 硬件实现 | TCAM / Trie | 哈希表 / SRAM |
| 表项容量 | 几千到几十万 | 几万到几百万 |
| 查找延迟 | 5-20ns | 2-5ns |
数据平面硬件加速：TCAM与SRAM
软件查表太慢了，所以路由芯片必须用硬件加速。这里有两个核心器件：TCAM和SRAM。
TCAM：三态内容寻址存储器
TCAM是LPM的「天然搭档」。它为什么叫三态？因为每个bit可以存三种值：0、1、don't care（通配符）。
举个例子，你要匹配192.168.1.0/24，在TCAM里存的就是：
11000000.10101000.00000001.xxxxxxxx
后面的8个x就是通配符。查找时，TCAM会并行比较所有表项，一次出结果。我当年第一次看到TCAM的并行查找能力时，真的被震撼到了——所有表项同时比较，一个时钟周期就出结果。
个人经验：TCAM虽然快，但功耗大、面积大。我建议只在路由表、ACL这类需要通配符的场景使用。对于MAC表这种精确匹配，用哈希表更划算。
SRAM：静态随机存取存储器
SRAM在数据平面里主要做两件事：
- 存储转发表：哈希表、Trie树的节点数据
- 缓存报文：在查表期间暂存报文内容
SRAM的优点是速度快、功耗低。但容量有限，一般芯片上也就几MB到几十MB。我见过有人试图把所有路由表都塞进SRAM，结果容量不够，只能降级到DRAM，查表速度直接掉了10倍。
硬件加速的核心思路：用TCAM做并行匹配，用SRAM做快速查表，两者配合实现纳秒级的转发决策。
实战：一个简单的转发流程
我们来看一个实际例子。假设芯片收到一个IPv4报文：
步骤1：解析头部
- 目的IP：10.0.0.5
- 源MAC：00:11:22:33:44:55
- 协议：TCP
步骤2：查路由表（LPM）
- TCAM查找：10.0.0.0/24 → 命中
- 结果：下一跳IP 192.168.1.1，出端口Port3
步骤3：查ARP表（精确匹配）
- 哈希查找：192.168.1.1 → 命中
- 结果：目的MAC 00:AA:BB:CC:DD:EE
步骤4：修改报文
- TTL减1
- 源MAC改为Port3的MAC
- 目的MAC改为00:AA:BB:CC:DD:EE
步骤5：发送
- 从Port3发出
整个过程，从报文进来到出去，我要求芯片在100ns内完成。你想想看，这中间还要做两次查表、一次报文修改，时间非常紧张。
注意：我曾经在调试中发现，TTL减1后忘记重新计算IP校验和，导致下游设备全部丢包。这个bug查了整整两天。所以，动作执行阶段的每个步骤都要仔细验证。
数据平面核心逻辑图
下面我用一张SVG图来展示数据平面的核心逻辑。这张图是我做芯片架构时常用的思路框架：
这张图展示了数据平面的完整流程。你看，从报文接收到发送，中间经过了解析、查表、动作执行三个关键步骤。而TCAM和SRAM作为硬件加速的核心，直接支撑了查表匹配的速度。
我的建议：在设计芯片时，优先保证查表路径的流水线深度。我一般会把查表放在流水线的中间阶段，前后各留一些缓冲，这样既能保证速度，又能处理突发流量。
好了，这一章的内容就到这里。数据平面的核心就是「快」——用硬件加速把转发延迟压到纳秒级。下一章我们会深入TCAM的内部结构，看看它是怎么做到并行匹配的。
公众号:蓝海资料掘金营，微信deep3321