承载网演进

10 个阶段，按规模从小到大；每一阶段都从「上一版什么撑不住了」开始。

① 两台服务器

2 台服务器 · 1 个机房

这一版架构：★ 一根网线把两块网卡直连，两端配同网段静态 IP —— 不需要交换机、不需要 hub、不需要 DHCP、连默认网关都不用配

上一阶段什么撑不住了

• 这是起点：两台机器只要一根线就能互通。两端配 192.168.1.1/24 和 192.168.1.2/24，ARP 直接问到对面的 MAC，帧就送到了。
• ★ 默认网关为什么不用配：网关是「要去别的网段时交给谁」。这里只有一个网段、而且对面就在同一根线上，压根没有「别的网段」这件事。
• ★ 历史上这根线得是交叉线：两端都是网卡，都用 1/2 对发、3/6 对收，不对调就是「两个人都在对着对方的嘴说话」。现在网卡普遍支持 Auto-MDI-X，会自己协商谁发谁收，所以直连线也能用了。
• ★★★ 这个方案的极限非常清楚：只能连两台。第三台没地方插。硬要不加设备就得全互联 —— n 台要 n(n-1)/2 根线、每台 n-1 块网卡：3 台是 3 根线，4 台 6 根，10 台 45 根。这条曲线比服务器数量涨得快得多，所以必须有一个中间设备。

动手试试（两台直连：只有「同网段」这一个条件）

• ★★★ 把服务器 2 的 IP 改成 192.168.2.2 —— 立刻不通了。因为两台不在同一网段，就需要网关；而这里压根没有路由器可求。
• ★★ 或者把服务器 1 的掩码从 /24 改成 /16 —— 这时它又认为对方是本网段的了。但只改一边：去程通、回程不通，这就是单向故障。

② 三台服务器

3 台服务器 · 1 个机房

这一版架构：要一个中间设备把三台连起来。最便宜的是 hub —— 它工作在物理层，收到什么就往其他所有口原样复制，不看 MAC、也没有转发表。3 台的时候这样够用

上一阶段什么撑不住了

• ★★★ 上一阶段一根线只能连两台。3 台想不加设备就得全互联：3 根线、每台 2 块网卡。勉强能做，但 4 台就要 6 根线、每台 3 块网卡 —— 立刻走不通。所以这一步真正发生的事是：第一次出现了一个专门用来连接的设备。
• ★★ hub 做的事简单到可以一句话说完：它是个电信号放大器。从任何一个口收到比特，就往其他所有口重放一遍。它不知道 MAC 是什么，不做任何判断，所以也没有转发表这个概念。
• ★ 代价是所有口都在同一个冲突域里：同一时刻只能有一个人说话，两个人同时发就碰撞，双方都要退避重发（CSMA/CD）。而且是半双工 —— 收和发不能同时进行；带宽也是所有口共享的。
• ★ 但 3 台的时候这些都还不疼：只有三个人说话，撞车概率还低。交换机当然更好，只是那个年代它贵得多。「够用就好」在这个规模是成立的 —— 这也是为什么这一阶段是「可以 hub、也可以交换机」。

动手试试（三台 + hub：一台发，所有人都收到）

• ★★★ 仿真一次 1 → 2，看图上服务器 3 也被点亮了 —— hub 不看 MAC，从一个口收到就往其他所有口复制。这就是「共享介质」。
• ★★ 把服务器 2 的 IP 改到别的网段，看失败原因变成「ARP 没人应答」——注意不是「路由不通」，这个规模上压根没有路由这回事。

③ 10 台服务器

10 台服务器 · 1 个机房

这一版架构：必须换成交换机。它工作在二层：靠 MAC 地址表知道哪个 MAC 在哪个口，然后只往那个口转发。于是每个口自己一个冲突域、可以全双工、各自独享带宽

上一阶段什么撑不住了

• ★★★ hub 到 10 台就崩了，而且三个后果是同一个原因：所有口在一个冲突域里。 · 碰撞概率随说话人数迅速上升。共享介质的经典以太网有效吞吐大概只有标称的三四成，而且越忙越差 —— 因为退避重发本身又在占用这个介质； · 半双工：同一时刻只能收或只能发； · 带宽共享：10 台分一个 10M 的段，不是每台 10M。
• ★★ 还有一个常被忽略的后果是安全：hub 把每一帧复制给所有人，所以任何一台机器把网卡设成混杂模式，就能听到全部流量。
• ★★★ 交换机一次把这些全解决了，靠的是一件事：它看得懂 MAC 地址。从某个口收到一帧，它记下「这个源 MAC 在这个口」（这就是学习）；转发时查表，只往目的 MAC 所在的那个口发。于是每个口是独立的冲突域（两台设备一根线，可以全双工），别人的流量你也听不到。
• ★ 但交换机也带进来一个新的有限资源：MAC 地址表。表是有大小的，满了之后学不进新条目，交换机只能对不认识的目的 MAC 泛洪（往所有口发）——行为退化回 hub。这件事到规模再大的时候会重新找上来。

动手试试（十台 + 交换机：只送给该收的那一台）

• ★★★ 仿真 1 → 7，和上一个规模对照：只有 7 被点亮，别人一个字节都收不到。交换机查 MAC 表，只往那一个口转发。
• ★★ 把服务器 7 的掩码改成 /28 —— 它就和服务器 1 不在同一网段了。去程还能到（1 认为 7 是本地的），但 7 回不来 —— 又是一次单向故障。

④ 100 台服务器

100 台服务器 · 1 个机房

这一版架构：拆成多个网段，网段之间靠路由器（或三层交换机）转发。同时一台交换机的端口不够了，多台堆起来 + 冗余链路就有了二层环路，于是必须跑 STP

上一阶段什么撑不住了

• ★★★ 交换机解决了碰撞，但没有解决广播。二层的广播（ARP、DHCP、以及查不到目的 MAC 时的泛洪）是发给广播域里每一个人的。100 台意味着每一次 ARP 都要 100 块网卡收下来、100 个 CPU 各处理一遍；而广播的量是随主机数一起涨的 —— 这是个 O(n) 遇上 O(n) 的问题。
• ★★★ 更糟的是故障域：一块网卡坏了开始疯狂发广播（广播风暴），整个 100 台一起卡死。而交换机拦不住它 —— 把广播转出去正是它的本职工作。在一个广播域里，一台机器的故障是所有人的故障。
• ★★ 物理上也到顶了：一台交换机没有 100 个口。多台交换机连起来之后，为了不因为一根线断掉就失联，就要有冗余链路 —— 而冗余链路就是环路。二层的环路是致命的：以太帧头里没有 TTL，一个广播帧会在环里永远转下去，越转越多，几秒就把交换机 CPU 打满。所以必须跑 STP，而 STP 的办法是把冗余链路阻塞掉（图上那条灰虚线）。
• ★★★ 出路是把广播域拆小：分成几个网段，每段的广播只在本段里转。但拆完之后网段之间就不通了 —— 跨网段转发要看的是 IP 地址，那是三层的事，交换机（只看 MAC）做不到。所以路由器在这一步成为必需品：它的价值恰恰是「不转发广播」。

动手试试（一百台：两个网段 + 一台路由器）

• ★★★ 先仿真一次 A → B：包必须经过路由器（同网段是不经过的）。对照着看：把目的改成同一段里的地址，路由器立刻从路径上消失。
• ★★★ 把 A 段服务器的网关清空 —— 报错变成「没有网关可交」，包连发都发不出去。
• ★★★ 把 A 段服务器的网关改成 10.0.9.1 —— 报错变成「网关不在本网段」。这是个死结：要送到网关得先 ARP 网关，而 ARP 只能在本网段里问。
• ★★ 把 A 段服务器的掩码改成 /8 —— 它会认为 10.0.2.11 是本网段的，于是不找网关、直接 ARP，然后没人应答。掩码填太宽就是这个后果。
• ★ 把 B 段服务器的 IP 改成 10.0.3.11 —— 报错变成「路由器没有到该网段的路由」，而这一次源端会收到 ICMP 不可达（路由器是三层设备，有能力回报错）。

⑤ 1000 台服务器

1000 台服务器 · 1 个机房

这一版架构：spine-leaf（Clos）：每台 leaf 上连所有 spine，任意两台 leaf 之间永远是 2 跳，所有链路靠 ECMP 同时转发。前提是三层做到 leaf

上一阶段什么撑不住了

• ★★★ 上一阶段那套「交换机 + 路由器」在 1000 台的时候有两个藏不住的硬伤： · STP 把冗余链路阻塞掉了 —— 等于买了一半的带宽扔在那儿不用； · 跨机柜的流量必须上到上层再下来，而上层是按收敛比设计的（比如 4:1）。结果是：两台服务器之间能跑多少带宽，取决于它们插在哪两个机柜 ——同样两台机器换个位置性能就变了，这在设计上是不可接受的。
• ★★★ Clos 把这件事变成确定的：每台 leaf 连所有 spine，所以任意两台 leaf 之间永远是 leaf → spine → leaf，固定 2 跳，而且有多少台 spine 就有多少条等价路径。带宽不够就加一台 spine（所有 leaf 一起变宽），端口不够就加一台 leaf。这是横向扩展；而上一代是纵向的 —— 不够就换一台更大的核心，总有换不动的那天。
• ★★★ 但这里有一个真正的门槛：ECMP 是三层的能力（按五元组哈希在多个等价下一跳里挑一个）。所以 leaf 和 spine 之间必须跑路由，不能是二层 —— fabric 内部要有一个 IGP 或 BGP。「三层做到 leaf」是这一步的入场券，做不到就还是回到 STP 那套。
• ★ 顺带一个很舒服的结果：STP 从 fabric 里彻底消失了。没有二层环路，就不需要一个协议去阻塞链路。

⑥ 10k 台服务器 · 分数据中心

10000 台服务器 · 2 个机房

这一版架构：两层 Clos 有算得出来的上限，所以再加一层 super-spine，把 fabric 切成 pod；再往上分成多个数据中心，之间用 DCI 连起来

上一阶段什么撑不住了

• ★★★ 两层 Clos 的规模有一个能算出来的天花板：最大服务器数 ≈ spine 的端口数 × 每台 leaf 的下行口数。拿 32 口的 spine、48 口的 leaf 来算：最多 32 台 leaf、每台接 48 台服务器 ≈ 1500 台。想再大，两层结构本身不够了 —— 只能再加一层（super-spine），把原来那个 fabric 整体变成一个 pod。
• ★★★ 但真正先撞上的限制往往不是网络：一栋楼的供电、制冷、机位是有限的。到这个规模，机房本身成了那个装不下的容器。所以「分数据中心」这一步的驱动力，一半是网络结构、一半是物理。
• ★★ 还有故障域：一个 fabric 就是一个故障域。一次配置下发出错、一个控制面 bug，就能把上万台一起带走。切成 pod、切成 DC，本质上是在限制爆炸半径 —— 让一次事故只毁掉一个 pod，而不是全部。
• ★★★ 这个规模上还有一件事第一次绕不开了：必须画出连公网的那台路由器。 · 用户从公网进来，得有个边界； · ★★ 更要紧的是跨机房怎么走。这个规模通常还没有自己的骨干 ——要么向运营商租一条专线（贵、扩容要排期），要么干脆借公网：两端边界路由器之间起一条加密隧道（IPsec / GRE）。 ★ 借公网这条路便宜、开通快，但代价很实在：中间那段路由由互联网决定，你只能保证「通」，保不了时延和抖动 —— 数据库同步这类活儿放上去就会很难受。这也正是再往上一个规模非要自建骨干的原因。
• ★ 分了 DC 就多出一个新问题：机房之间的线又贵又少（相对机房内部随便撒的带宽）。于是「东西放在哪」第一次变成一个网络问题 ——什么该留在本 DC、什么值得跨出去，得算过才知道。

⑦ 100K 台服务器 · 分城市 + 骨干网

100000 台服务器 · 12 个机房

这一版架构：分城市，并自建骨干网：城市之间用自己的长途链路，靠流量工程（MPLS-TE / SR-TE）把这几条贵管子用满；IGP 按区域分层；底下多出一层 DWDM 光网络

上一阶段什么撑不住了

• ★★★ 上一阶段还能假设机房都在一个都市圈里 —— 几十公里，来回不到 1ms，所以「哪个机房」基本不影响时延。跨城之后光速成了硬约束：光在纤芯里大约 200,000 km/s，1000 公里单程 5ms、来回 10ms。★★ 这个数字加钱、加带宽、换设备都改不了 —— 它是物理常数。所以架构必须从「一个大池子」变成「按地理分区，每个区自己能服务本地用户」。
• ★★★ 城市之间的流量一大，买运营商线路就不划算也不可控了：价格按带宽线性涨、抖动不由你、扩容周期看别人排期。所以自己租/买长途纤、自己点亮 —— 骨干网从这里开始。
• ★★★ 长途链路贵且少，所以不能像机房里那样「ECMP 随便撒」。机房里链路便宜、哈希撒开就够好；骨干上必须做流量工程：显式指定哪条流走哪条路（MPLS-TE / SR-TE），否则就会出现一条管子挤爆、另一条空着 —— 而那条空管子一年几百万。
• ★★ 设备数量也让 IGP 撑不住了：一个 area / level 里塞几千台设备，任何一次拓扑变化全网都要重算一遍 SPF。所以 IGP 必须分层（OSPF 的 area、ISIS 的 level），区域之间用 BGP 连 —— 把「谁需要知道谁」限制住，这和限制广播域是同一个思路，只是上升到了三层。
• ★★ 自建了骨干不等于可以不要公网：用户本来就从公网进来；而且长途纤会被挖断、会被地震震断，那时候公网就是兜底路径 ——所以边界路由器一直在图上，只是它的角色从「唯一的路」变成了「备份的路」。
• ★ 到这一步「网络」不再只是路由器和交换机：底下还有一层光（DWDM）——一根纤上开几十个波长，容量规划变成光层的事。以前买的是「一条 10G 线路」，现在管的是「这根纤上还有几个波」。

⑧ 100 万台服务器 · 跨洲

1000000 台服务器 · 60 个机房

这一版架构：跨洲：海缆 + 自己掌握的光层（ROADM，直接在光层调波长）+ 集中控制器算路（SR / SRv6，把路径压进包头）

上一阶段什么撑不住了

• ★★★ 跨洲和跨城不是一回事，因为海缆是稀缺资源：建设周期以年计，容量要提前好几年买；一根断了（渔船拖锚、地震）修起来是几周，不是几小时。所以路径必须天然多样 —— 走不同的缆、不同的登陆点、甚至不同的方向绕地球，而不是简单做个「主备」。
• ★★★ 几十个区域、几千条候选路径，人工调流量已经不可能了。于是 SR / SRv6 加一个集中控制器：控制器看得到全网状态，算出最优路径，把路径压进包头；中间设备只按标签转发，不需要每台都懂全局。★ 这就是从「每台设备自己算」到「一个大脑算、大家执行」的转变（Google 的 B4 / Espresso 就是这类系统）。
• ★★ 到这个量级光层必须自己掌握：在 ROADM 上直接调一个波长过去，比在 IP 层绕一大圈便宜得多、也快得多。★ 甚至更进一步：顶层的包交换开始被光交换替代 ——如果两个 pod 之间就是要一大管固定带宽，用光路直接连比让它穿过一堆路由器更划算。
• ★ 最后一件反直觉但很重要的事：这个规模下大部分故障是自己造成的（一次配置下发、一次升级），不是硬件坏。所以网络会长出一层「变更验证 + 分批下发」的基础设施 ——它不在拓扑图上，但它才是决定可用性的那一层。

⑨ 三张网 · 业务 / 管理 / Console

10000 台服务器 · 1 个机房

这一版架构：同一个机房、同一批设备上并存三张网：业务网跑用户流量、管理网（带外）跑 SSH 和遥测、Console 网跑串口。★★★ 一条原则贯穿全部：管理通道不能依赖被管理的对象

上一阶段什么撑不住了

• ★★★★ 一条原则贯穿整页：管理通道不能依赖被管理的对象。 业务网挂了 → 管理网还在，你还能远程登进去查；管理网也挂了（或者设备系统起不来、还没有 IP）→ Console 还在，还能救回来；Console 也没有 → 只能开车去机房。 ★★ 所以这一步不加规模 —— 规模钉死在一个大机房，横切一刀看三个平面。
• ★★★★ 看图上那根红线 —— 它是这一页最贵的一课。 管理交换机为了省一条线，从业务交换机上取上行。平时一切正常，而业务网一挂，管理网跟着一起没 —— 你需要它的那一刻它正好不在。 ★★★ 这就是所有「远程救不回来、只能去现场」的共同原因：救援通道和故障对象共用了一段路。所以依赖方向必须是单向的。
• ★★★ 装机顺序恰好是三张网的倒序 —— 这也是它们关系最好的证明：先从 Console 进去配管理 IP（它是唯一不要求对面有配置的通道），再走管理网 SSH 推配置，最后才配业务网。排查时反过来走。 ★ 顺带一句：测试环境自己也有这三张网，它是再复制一套，不是第四张网 ——要不要和生产共用管理网，是下一课的事。

⑩ 生产网 · 办公 / 远程 / 测试

10000 台服务器 · 1 个机房

这一版架构：办公网、远程办公、测试环境 —— 三者都不是生产网，却都想碰到它。★★★ 这一课的轴是信任边界与入口：进来要过几道门，以及这几道门自己依赖什么

上一阶段什么撑不住了

• ★★★ 办公网、远程办公、测试环境 —— 三者都不是生产网，却都想碰到它。 ★★★★ 所以看右边图上那三根红线。每根都标着它凭什么这么连 —— 而那三个理由听起来都很合理，这正是它们危险的地方。正确的路只有一条：先过 VPN，再过跳板机。
• ★★★★ 最反直觉的一条：那两道门自己不能依赖办公网。 ★★★ 跳板机接办公网 AD 做统一认证很省事 —— 但 AD 被拿下你就进不了管理网，而那恰恰是勒索攻击的典型一步。最需要救援的那一刻，救援入口正好没了。 ★★ 所以跳板机要留一套独立的本地账号 + 硬件令牌，平时不用。
• ★★★ 远程办公之后，「内网可信」这个假设没了 —— 运维的电脑和别人家的智能电视在同一个广播域里。 ★★★★ 落到网络上最能立刻照着做的一条：别再把「源 IP 在内网段」当授权依据。