多层交换的核心是「第一个包走慢路，后面的包走快路」。 十兆字节的传输要查七千多次表，改成一次之后差三个数量级。
上一节讲两者的差别，这一节讲 L3 交换机凭什么快。 这一节的思想是「流」而不是「包」——这是理解多层交换的关键。
一、一次路由，多次交换
传统逐包路由：每个包都要上 CPU 查一次路由表。 一次路由多次交换：第一个包上 CPU 查表，同时把这条流的转发信息写进硬件，后面的包直接命中。
做法 第一个包 后续的包
传统逐包路由 CPU 查路由表 CPU 再查一次 一次路由多次交换 CPU 查表并写入硬件 芯片直接命中
算一条 10 MB 的传输：按 MSS 1460 要切成七千多个包。 逐包路由要查七千多次表，一次路由只查 1 次。 差三个数量级——这就是「软件转发扛不住园区网」的全部原因。
二、为什么以「流」为单位
同一对主机之间的一次通信，包的转发决定是一样的：同样的源、目的、端口、协议，要走同一条路。 所以「算一次、记住、反复用」是成立的。
这正是「缓存」的思想： 和 CPU 的 TLB、操作系统的路由缓存是同一个道理——把「慢但通用」的计算结果记住，让「快但专用」的硬件反复使用。
而它的失效条件也一样：流一多缓存就装不下，路由一变缓存就失效。 所以「一次路由多次交换」在「大量短连接 + 频繁路由变化」的网络里收益会掉。
三、从流缓存到逐包查表
早期的实现真的是「流缓存」：一张哈希表记五元组到转发结果的映射，缺点很清楚——表项多、 易被 DoS 打爆、路由变化要逐条老化。
今天的实现基本不用流缓存了，而是「一次查表就出结果」： TCAM 里同时放二层与三层表项，一个包进来一次并行比较就得到全部答案。 所以「多层交换」这个词今天的实际含义已经变成「一次查表完成多层转发」。
这个演进的道理值得记：「缓存」是「算力不够时的权宜」，「算力够了就直接算」才是终局。 今天连 ACL、NAT 都能在线速下做，就是因为查表这件事被做进了芯片。
四、多层交换的边界
「多层」不等于「所有层」： 二层的 MAC 与 VLAN、三层的 IP 前缀，都在芯片里；而四层以上的识别（应用识别、内容过滤）大多还要 CPU 或专用引擎。
所以「开了应用识别就掉速」这件事和 03.08.03 讲的「开功能掉 18 倍」是同一个原因： 一旦出了芯片的能力范围，就退回软件处理。
一条实践判断：规格书上的「L4 ～ L7 支持」要问清「是芯片做还是 CPU 做」。 芯片做的能线速，CPU 做的只能「能用」。 这一句话能把很多「标称支持」的水分挤出来。
五、动手 Demo：一次路由多次交换，省了多少次查表
这段对比两种做法在第一个包与后续包上的处理，再按「10 MB 除以 MSS 1460」算包数， 看查表次数从七千多降到一次。
pkts = -(-(10 * 1024 * 1024) // 1460)
P(u" 逐包路由：要查 %s 次。" % format(pkts, u","))
P(u" 一次路由：只查 1 次。")
实跑输出：
--------------------------------------------------------------------
一次路由多次交换，省了多少次查表
--------------------------------------------------------------------
**L3 交换机的核心思想是「第一个包走慢路，后面的包走快路」。**
**这就是所谓「一次路由、多次交换」。**
做法 第一个包 后续的包
------------------------------------------------------------
传统逐包路由 CPU 查路由表 CPU 再查一次
一次路由多次交换 CPU 查表并写入硬件 芯片直接命中
**关键差别在「后续的包」这一列**：**一次路由之后，这条流的信息被写进了硬件转发表**，
**后面的包不用再上 CPU。**
**算一条 10 MB 的传输要查多少次表**（按 MSS 1460）：
10 MB ÷ 1460 ＝ 7,183 个包。
逐包路由：要查 7,183 次。
一次路由：只查 1 次，其余 7,182 个包走芯片。
**七千多次与一次，差三个数量级。**
**这就是「软件转发扛不住园区网」的全部原因。**
**但这条快路有前提**：**流的特征要能被硬件记住**。
早期的实现用「流缓存」，**缓存满或老化掉就要重新走一遍慢路**。
**所以「一次路由多次交换」在「大量短连接」的场景下收益会大打折扣**——
**每个连接都只有几个包，等于每个包都得走慢路。**
「七千多次与一次」这个对比是本节的核心数字，但它只在「一条长连接」的假设下成立。 如果是一千条短连接，每条两三个包，那「一次路由」就要做一千次——收益几乎为零。
这也是「流缓存」这个方案最终被淘汰的现实原因之一： 互联网流量越来越「短连接化」（每个请求一个新连接）， 缓存命中率上不去，还多了一层被攻击的面。
最后「芯片做还是 CPU 做」这一条是选型要点： 同样写着「支持 L4 负载均衡」，芯片做的能跑线速，CPU 做的只能跑几十兆。 问清这一点，比看任何标称数字都管用。
30 秒实验
- 查一下你核心交换机的规格书，看 L4 以上功能是芯片还是 CPU 实现。
- 抓一次长传输的包，看第一个包与后续包有什么不同。
- 想一想：为什么「大量短连接」会削弱多层交换的优势。
常见误区
- 以为多层交换是「每一层都算一遍」。是一次查表出全部结果。
- 以为流缓存一直有效。短连接与路由变化都会让它失效。
- 以为标称支持 L4 就能线速。要看是芯片做还是 CPU 做。
自测三问（点开对答案）
1. 「一次路由多次交换」省下的是什么？ —— 后续包不必再上 CPU 查路由表，由芯片直接命中转发表。 2. 为什么这个优化在「大量短连接」场景下会失效？ —— 每个连接只有几个包，等于每个包都要走一次慢路。 3. 今天为什么不再用流缓存？ —— TCAM 能一次查表完成多层匹配，缓存反而增加表项压力与攻击面。下一节：这套思想是怎么被发明出来的。
- ☐ （本节完，下一节 04.02 L3交换机是如何诞生的）