去年年底到今年早些时候，我参与某司一款新的路由芯片架构设计，过程中争议很多，甚至发现一些做设计多年的工程师，对不少基础概念已经生疏了。这些年亲历了网络芯片从“软”变“硬”、又从“硬”变“软”的循环，也见证了软件定义网络、智能网卡、SRv6、P4 等技术把“网络可编程性”的体系结构推到新阶段。写下这篇综述，一方面回看历史，一方面也想提醒：做架构决策时别轻易走弯路。
注：建议从三个维度看待网络体系结构的变化：软件 / 硬件 / 网络报文编码。
0. 时间轴总览：软硬来回摆动的四十年
1986~1995：软件实现为主
- 报文编码：基于目的 IP 地址的最长匹配做查询
- 软件结构：软件算法优化，使用 Tree 查找与 Cache 优化
- 硬件结构：大量基于 MIPS 指令集 CPU 的软件转发；后期出现基于总线的分布式转发架构（如 Cisco 7500）
1995~2010：由软向硬的过渡
- 报文编码：MPLS 简化核心路由表条目数
- 软件结构：相对稳定，变化不大
- 硬件结构：专用处理器繁荣十年：加密芯片、TCAM 查表、微码网络处理器；Fabric 逐渐采用 CLOS 架构构建多机集群
2010~2015：由硬到软——软件定义时代
- 报文编码：VXLAN 与 Overlay 兴起
- 软件结构：软件转发回归，DPDK/VPP 等开源软件出现
- 硬件结构：多核通用处理器更强；SR-IOV 出现；核心交换芯片更强并支持虚拟化
2015~2019：由软到硬——可编程智能网卡时代
- 报文编码：Segment Routing（数据包即指令）
- 软件结构：容器出现，CNI 触发 Host Overlay；尽量用协处理器/网络设备卸载；P4 等通用网络编程语言兴起
- 硬件结构：可编程交换芯片出现；SmartNIC 方案盛行；低时延通信需求上升，尤其 AI 带来更快 I/O 响应诉求
1. 网络的“本质指标”与架构取舍
网络的本质是快速、可靠、安全、可控、便捷、便宜的通信。所有厂商做产品，本质都在这几个目标上做 trade-off。时代不同、软硬件基础不同、客户场景不同，选择自然也不同。
常见错误不是“软件一定好/硬件一定好”，而是：
- 对知识边界误判
- 对客户场景把握不足
- 过分强调软件或过度优化硬件
- 忽略了“报文编码”也能从根上改变复杂度
2. 其实网络一开始就是“软件定义”的
一开始的路由器甚至被称为服务器：1986 年思科发布 AGS（Advanced Gateway Server）。Cisco IOS 本质上就是一个软件操作系统。
最早的报文处理系统就是软件的。为了避免“不可说”的内容，下文引用公开资料；例如老书《Inside Cisco IOS Software Architecture》。
2.1 进程交换（Process Switching）
当时极力在软件算法上优化。最早是进程交换：在操作系统上执行一个转发进程，每个包进来都走这个进程查路由表，然后转发。
2.2 快速交换 → CEF
每个报文都查一次路由表太“重”。随着网络规模扩大，路由表变大导致性能问题，于是出现 Fast Switching：增加 Cache 用于路由查询。
再后来，路由表规模继续变大，只能改数据结构：逐渐出现基于各种树的查询。例如 Linux Kernel 曾长期使用 Radix Tree；Cisco 从 Radix Tree 发展到后期的 CEF。
（相关基础概念可参考：TCP/IP,HTTP,Linux,并发）
2.3 第一个软件转发时代总结
那时通信数据量不算大，协议复杂度高但吞吐诉求有限（大多在 100Mbps 处理能力以内），用软件转发是性价比较高的方案。很多产品基于 MIPS 处理器实现，CPU 内部执行标准 MIPS 指令集；升级主要靠 CPU 升级：
- Motorola 68000 → R4600 / R4700 → R5000
- 总线结构从 Cisco Cbus 到标准 PCI、PA 卡、CyBus 等
本质结构变化不大：
这种集中式架构很自然会引出“多 CPU 分布式转发”：Cisco 7500 系列在线卡放 CPU，把转发表下载到线卡形成 Distributed-CEF。
3. 从软件到硬件转发：Fabric 与 Linecard 两条主线
从软件到硬件转发的变革看多了容易“打脸”。主导者之一甚至是后来 SDN 的关键人物：斯坦福教授 Nick Mckeown。
技术上差异主要在两点：
1) 线卡 ASIC 如何设计
2) Fabric ASIC 如何设计
下面分别展开。
4. 硬件转发之 Fabric：从 Crossbar 到 CLOS/BENES
4.1 交换机出现与 ASIC 加速
同网段主机通信占比高，WAN 带宽相对小，交换机兴起。思科收购 Cresendo / Grand Junction / Kalpana 等以太网交换公司，以及 ATM 交换 LightStream。本质上是在用 ASIC 做特定转发加速：精确匹配目的地址做硬件查表肯定比 CPU 指令译码快。
交换机制也有取舍：
- Cut-Through（检查目的 MAC，低时延但易碰撞/残帧）
- Fragment-Free（检查前 64B，规避碰撞碎片）
- Store-and-Forward（更稳妥，但增加时延）
这类机制本质上对应交叉矩阵控制开关，也就是 switch 的由来：
4.2 背板瓶颈与 Crossbar
总线型分布式路由器平台遇到背板瓶颈：ISA→EISA→PCI 增长有限，Internet 发展要求更快 backplane。共享总线易冲突，高速总线难度越来越大，促使“用交换结构互联线卡”的思路出现。
这是当年 GSR 培训胶片示意：
注：Crossbar 架构由 Nick Mckeown 在论文《Fast Switched Backplan for a Gigabit Switched Router》中提出，并在 1995 年起担任 Cisco GSR 架构师；Cisco GSR 12000 基于 Crossbar 架构推出。
Crossbar 的代价也明显：如何同步多平面？如何避免阻塞？
4.3 Cell based Switch：固定长度信元与时隙调度
报文过 Crossbar 传输有两种路线：
- 变长报文直通
- 切分为固定长度 Cell（类似 ATM 信元），输出端重组
固定长度 Cell 有利于：
- 估算转发时间 → 定义时隙
- 在时隙结束点统一做调度与矩阵配置
- 更高效使用 Crossbar 带宽
变长报文则在 Scheduler 上难：转发时间不可估计，需要持续监测完成情况与矩阵状态，导致大量等待时隙与带宽浪费。
Cisco 定义 Cell 大小 64 bytes。仿真显示：固定 Cell 可接近 100% 利用；变长直通约 60%。因此 GSR 12000 采用固定 Cell 模式。
4.4 HOL Blocking 与 VOQ：把 58.6% 拉回 100%
当所有卡都向一个卡发，会出现 HOL Blocking。常见缓冲方式是 Input Queue / Output Queue：
- Output Queue：带宽利用高，但缓存要具备 [N \times R] 速度
- Input Queue：缓存速度仅需 [R]，但会遇 HOL Blocking
在 IQ 交换机上受 HOL Blocking 限制，最大吞吐量约 58.6%。解决方案之一是 VOQ（Virtual Output Queueing）：每个输入端口为每个输出端口各建一个队列，消除 HOL Blocking，并保持缓存操作速度为 [R]。
VOQ 的关键在 matching scheduler：数学模型实质是二分图匹配问题。常见：
- MSM：Maximum Size Matching（边数最大）
- MWM：Maximum Weight Matching（权重和最大）
- 工程常用 maximal matching 近似，降低复杂度与硬件实现难度
Cisco GSR 12000 实现 VOQ + iSLIP，吞吐量接近理论 100%：
VOQ 技术后来在 Nexus7000、ASR9000 等继续使用。还有 CIOQ（来自 Avici）等路线；其调度常见基于稳定婚姻问题（Stable Marriage Problem），同样属于二分图匹配。
4.5 CLOS / BENES：可扩展交换网络
当系统容量上到 1Tbit 以上，单级 Crossbar 扩展性受限：
- 大 Crossbar 难做（管脚、实现复杂度），复杂度随 [O(N^2)] 增长
- 集中仲裁器调度复杂度高，端口速率到 10G+、端口数到 10+，在一个信元时隙内完成仲裁会变得很难
于是多级交换结构成为主流：Clos、Banyan、Butterfly、Benes 等。Cisco CRS-1 采用 BENES：
多芯片交换网既可并行作为多个 fabric 连接线卡，也可做成路由器集群的专用 Fabric 机框：
Cisco 使用 FCC + LCC 的 Multichassis 集群：最多 8xFCC + 72xLCC，容量从 1.25T 拉到 92T。标题写 CLOS 的原因是：当时 Huawei NE5000E、Juniper T-series 多采用 CLOS，后期很多交换机厂商在单芯片不足时也用类似方式堆叠，本质一致。
近年一些厂商实践也类似：
例如为提供 128x100GE，采用 3.2T 芯片需要 4（Spine）+8（Leaf）共 12 颗芯片，本质还是十多年前的思路。更系统的内容可参考相关专著：
5. 硬件转发之 Linecard：从 TCAM 到多核网络处理器
Fabric 相对“直观”，更难的是线卡：路由表容量越来越大、功能需求越来越多。以 Cisco 为例，线卡结构经历：
- 核心 CPU 转发
- 总线控制器调度
- Cisco 7500：VIP 接口卡，分布式 CPU
- Crossbar 平台：ASIC 处理（7600 OSM、Cisco 10000 的 PXF）
- 网络处理器（NP）：Cisco SPA/SIP
- CRS-1 的 SPP、ASR1000 的 QuantumFlow（QFP）等
这是一个百花齐放、争论不断的年代：
注：GPP = General Purpose Processor，ASIP = Application Specific Instruction Processor
5.1 不得不说的 ASIC：TCAM
传统表项查找多基于 SRAM 的“类软件”查找：线性遍历慢；二叉树查找受树深影响；而 TCAM 查找可在同一时刻查询整个表项空间，速度不受表项空间大小影响。
TCAM 之所以叫 Ternary Content，是因为每个 bit 有三种状态：0 / 1 / Don't care。非常适合做匹配，尤其是路由的 Longest Match。
典型做法：TCAM 查询得到 Index，再去内存取出 Index 对应信息返回给转发逻辑。
那个年代大量设备用 TCAM 实现查表与 ACL 匹配，直到现在仍有不少产品沿用。
5.2 固定流水线的 ASIP：从 Offload 到“类 P4 Pipeline”
加速线卡处理器最先想到的是把固定功能 offload 到硬件流水线批量执行。Cisco PXF（Parralled eXpress Forwarding）就是那个年代的产物：7200 的成功与之相关，也让 IOS 在转发上第一次用上“类多核”的思路（但仍依赖微码编程）。
本质就是一串 pipeline + memory 的 ASIC：第一级做 A 功能、第二级做 B 功能，并发处理多个报文。你会发现它和今天很多 P4 ASIC 的直觉非常接近（后来的 VPP 向量化处理在结构上也有相似点）。
原文摘录（《Understanding Network Processors, Niraj Shah》）：
The PXF consists of a pair of ICs... 16 processors arranged in 4 pipelines... 32 processors... 2-issue VLIW... 8 stages... different packet forwarding function...
5.3 RTC 网络处理器（SPP/QFP）：功能弹性与容量取舍
固定流水线网络处理器会遇到资源不均衡问题：有的功能几乎不用却仍要走，有的功能用得多资源不够。再叠加 MPLS VPN 兴起带来的路由表容量诉求、以及接入场景硬件平台碎片化，微码编程逐渐难以维护。
此时不得不提 Will Eatherton：论文《Tree bitmap: hardware/software IP lookups with incremental updates》提出的方法可绕开 TCAM 的容量约束。Will 参与设计了 Cisco SPP/QFP，后来去 Juniper 做 Trio 系列。
QFP 的 FP 设计采用 Run-To-Compile（RTC）结构：功能再多，一个处理器“跑完”一个包的所有功能；编程以 C 为主，内存操作灵活。
它把功能做了较好的抽象与分离：
- On-chip memory：等待调度到 PPE
- PPE：多核专用指令集处理器（如 Tensillica 精简指令集）
- 片外 TCAM/加密协处理器：加密与 ACL 查询
- 专用 TM 芯片：QoS
- 路由表查询：Tree Bitmap + DRAM（在容量与成本上做取舍）
这种做法让软件编程有足够弹性，后期一台设备能“单挑”一堆盒子，成为瑞士军刀：
Juniper MX/SRX 的 Trio 体系也类似（从查表引擎到转发、QoS、接口芯片的分工协作）。商用可见参考书：
5.4 商用多核网络处理器（RMI / Cavium / Tilera）
QFP 推动更多厂商尝试商用多核处理器，常见以 MIPS 多核为主，片上网络（NoC）发展明显。为了通用编程能力，多使用标准 MIPS 核心，并辅以网络相关协处理器。
5.5 Cache 一致性与 FBD（Flow Based Distribution）
多核平台的另一个难题是调度：如何把包分到不同核、如何负载均衡？
- 一种做法：Cache 非一致性，依赖大内存带宽；用锁锁住 flow，避免同一 flow 的不同包并发更新
- 另一种做法：FBD，首包查好建立流表，根据流表分配到不同核
但在一些极端测试里，容易出现 elephant flow hash 到同一核导致丢包；甚至在源目的 IP 固定、随机端口的场景下性能显著下降。
5.6 商用网络处理器（Ezchip NP5c）：ASR9000 的成功路径
当你以为路线已收敛，新的组合又会跑出来并且成功：ASR9000 基于 Ezchip NP 系列。
网络行业的艺术永远是 trade-off：CRS-1、ASR1000 虽然有 SPP/QFP，但“贵”。互联网宽带、城域以太、MPLS 普及带来运营商边缘路由增长；高速 Fabric 芯片又让多级交换架构更显昂贵；ASR1000 也没有把 QFP 做成分布式，于是 NP4/NP5 带来的 ASR9000 抓住了机会。
Ezchip 的参考书：
摘两页图意会即可：
那个年代很多设计都有严格的计算、调度算法与数学证明。纪念一下 SDN 之父的胶片：
5.7 本章小结
这是一个百花齐放的年代。软件算法遇到瓶颈后：
- 报文编码：MPLS 标签降低查表复杂度
- 硬件：ASIC/NP 繁荣，精简指令集、TCAM 加速
- 容量与成本：Tree Bitmap + DRAM 与 TCAM 方案取舍
- 架构趋势：多核处理器与片上网络逐渐普及，为后续通用处理器多核化打下基础
这一章要传递的核心观念只有一个：当软件遇到瓶颈时，可以从硬件和报文编码两条线一起解题；十年后这个故事还会再演一次。
6. 软件定义网络：虚拟化把网络再次“软化”
分分合合，合合分分。虚拟化兴起后，虚拟机内互相通信的网络需求，把网络设备再次软件化。起初主要是交换机侧；为了虚拟交换机可编程和转发方便，OpenFlow 与 Open vSwitch 出现。公有云/私有云部署推动设备进一步虚拟化，虚拟云路由器随之出现；伴随 VDC/VPC，设备虚拟化更进一步。
6.1 SR-IOV：从虚拟化开销里“抠”性能
软件虚拟化带来的问题是：大量设备通信如何处理？于是有了 PCI-E SR-IOV。
标准架构如下：
- SI（System Image）：客户机（虚拟机 OS）
- VI（Virtual Intermediary）：虚拟机管理层
- SR-PCIM：配置与管理 SR-IOV，含 PF/VF
- PF：物理功能
- VF：虚拟功能
SR-IOV 的价值在于绕开 Hypervisor/VMM 的软件瓶颈，让 PCIe 设备性能更充分发挥，实现多个虚拟机共享物理资源。
6.2 DPDK：绕开内核协议栈瓶颈
在由硬到软的过程中，传统 Linux 转发遇到瓶颈：
- 数据包到达网卡设备
- 网卡按配置进行 DMA
- 网卡中断唤醒 CPU
- 驱动填充读写缓冲区数据结构
- 报文进入内核协议栈做高层处理
- 若用户态应用，数据从内核搬到用户态
- 若内核态应用，在内核继续处理
于是需要一套在 IA-X86 多核处理器上的快速包处理机制：报文直接进入用户态。DPDK 使用轮询（polling）而非中断：重载驱动不靠中断通知 CPU，而是把包存入内存，应用通过 DPDK 接口直接处理，减少 CPU 中断与内存拷贝。
（DPDK 进一步学习可结合：Linux,Shell,CI/CD,Jenkins,Ansible 做压测与部署联动）
6.3 VPP：向量化包处理与可插拔转发链
VPP 本质是把报文处理做成向量批处理，同时定义灵活的链式转发结构，便于在链条上插入新的软件特性。
6.4 本章总结
这一时期报文编码发展主要为了解决虚拟化问题，VXLAN/LISP 等 Overlay 兴起；网络设备被要求在 X86 虚拟化平台下运行，虚拟路由器/交换机/防火墙出现。为了优化虚拟机性能，DPDK/VPP 等开源库出现；BGP-EVPN、YANG/NETCONF 控制器技术推进 SDN 落地。硬件侧更多是 SerDes 加强与芯片堆料，100G MAC 标准推进，行业进入相对“简单粗暴”的阶段。
7. 又“硬”起来：智能网卡与网络编程的回潮
当大家全软件化后，发现 CPU 资源 50% 以上被网络占用，尤其是公有云：CPU 是拿来卖钱的。于是轰轰烈烈的 Offload 运动开始，网络再次“硬化”。
7.1 Segment Routing 与 P4：从“查表”到“Match-Action + 指令”
当软件和传统硬件手段都不够时，目光转向指令集与报文编码。
一方面，SR 对设备进行编码：有 SID，再编码 Function 与 Args。传统设备做目的地址查表时，就可以有更灵活的函数 Callback 栈，实现更灵活的功能。
另一方面，把网络处理抽象成连续的 Match-Action，做成 pipeline，于是 P4 顺理成章出现。此前 Cisco UADP 也有类似思路。随后 Barefoot 被 Intel 收购，Intel 推 One API；Xilinx 推 SDNet，把 P4 编译成 IPCore。
7.2 存储与 RoCE：低时延 I/O 推动无损以太网
NVMe SSD 兴起使 IOPS 更低延迟，传统存储协议难以应对；AI 训练繁荣推动低时延 I/O 需求，RoCEv2 与 Lossless DC Ethernet 逐渐成熟。
7.3 AWS：从 SR-IOV 到 Nitro 式卸载
AWS 2011 年引入智能网卡，提供 SR-IOV 类 VF；后续基于收购 Annapurna 的设计推出 25G 智能网卡，承担原本物理机内虚拟交换机负载：路由、conntrack 匹配、ACL 过滤、VTEP 查表、MAC 代答、tunnel 建立等，降低延时、提升吞吐；并在硬件上实现虚拟机粒度的带宽与五元组 QoS，提供稳定可预测的网络性能。
7.4 Microsoft Azure：可重构加速与云规模架构
微软在智能网卡与可重构计算方面论文较多，例如：
- 《Large-Scale Reconfigurable Computing in a Microsoft Datacenter》
- 《A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services》
后续还有《A Cloud-Scale Acceleration Architecture》等：
AWS Nitro、阿里云神龙是代表。对低时延/高性能敏感的行业（如数值仿真、低延迟交易）上云受虚拟化损耗阻碍，Baremetal 与 DPU 方案成为折中路径。Fungible 的 DPU 也很有意思：
7.6 Pensando：对标 Nitro 的另一种实现
在智能网卡年代，不提 Pensando 不太完整。它更看重对标 Nitro 的位置：P4 编程引擎不错，内置 HBM 做高性能路由查表，并有加密/正则协处理器，总体中规中矩。参考书：
7.7 本章总结
这是一个体系结构大改的年代：
- 虚拟机逐渐被更轻量的容器替代，Service Mesh、Serverless 出现带来新机会
- AI 兴起、高速分布式存储繁荣、Persistent RAM 等铺好了基石
- 人们在性能竞赛中重新重视网络：开始网络编程、利用 RoCE 降低时延
- P4 的出现让报文编码扩展有了更清晰的工程入口
（容器与 CNI/Service Mesh 的落地路线可结合：Kubernetes,Docker,Istio,Prometheus 体系化对照理解）
8. 后浪：2020~未来的 NewIP 思路（QUIC + SR）
回归本源再看网络，会发现很多问题。但工程上很难推倒重来。有公司想做 NewIP，想法很好，但工程可行性是另一回事。那么“后路”在哪里？
这是前些年的 PPT：TCP 的问题逐渐被 BBR 修补，QUIC 随 HTTP/3 与 TLS1.3 迅速登场。QUIC 的优势很多：
- UDP userspace 加速空间大
- 独立 CONNECTION-ID，支持 IP Migration
- 低时延
- 传输安全
- 既可可靠（quic-transport），也可不可靠（quic-datagram）
- 多流复用、流控
传输层看起来越来越“完整”。
前段时间测试上海到莫斯科通信质量：约 25% 丢包、300ms 延迟；但若从公有云绕一圈，效果好很多：
丢包统计：
8.1 把“选路权”下沉到终端
所以到了 2020 年，每个老司机开车都有选择道路的权力；那终端（比如手机）是否也该拥有“选路”的权力？
与 SR 的结合就变成一个不错的选择：
QUIC 扩展也可以很直接：在 UDP payload 里放一个带 SRH 明文的 QUIC packet 即可：
这样“后浪”就拥有选择能力：
由于它仍是 L4 传输层协议，有 CONNECTION-ID 维持连接特征，IP 头随便改，IPv4/IPv6/MPLS 都可穿越。把下一跳信息放在 uSID + KV mapping 表里即可：
8.2 借 QUIC “顺手”减少 Overlay
过去十年用了太多 Overlay。既然 QUIC 已与 IP 地址解耦传输，为什么不借机把 Overlay 减掉？都 2020 年了，还用 IPsec VPN 拨到 VPC 吗？
服务端支持也更容易：用 sidecar 改 QUIC-SR。
甚至数据中心内部的 RoCE 也可以改造：让 SmartNIC 选择 Spine switch 也是一件好事。
5G 与 WiFi 融合也能更平滑、可控：
做安全与微分段，也可以扩字段：
（安全方向延伸可参考：网络安全,渗透测试,OAuth,JWT）
9. 终章：给“十字路口决策者”的一句话
这就是我过去十多年看到的盛世繁华：软件与硬件反复拉扯，协议与报文编码不断改写复杂度边界。很多时候不是“站队”，而是识别约束、选择合适 trade-off，并给未来留足可演进空间。
2020~未来：NewIP（后浪）：给更多终端智能选路的权力（回顾）
- 报文编码：QUIC + SR
- 软件结构：给更多终端“后浪般”的选择权
- 硬件结构：智能更多沉到设备侧，网络可以简单一点
发表于 4 小时前
|
查看: 1|
回复: 0
