有人把一台从仓库翻出来的旧集线器插进办公网，本意是"多接两台测试机"，结果整层楼的人同时感觉网页加载变慢、视频会议开始卡顿。拔掉之后一切恢复。这类事情在机房和实验室里反复上演，根子不在设备坏没坏，而在于很多人对集线器、交换机、路由器这三类设备的工作层次没有建立起清晰的物理直觉——知道它们"不一样"，但说不清差在哪一层、差在哪个动作上。
这篇东西就是把这层窗户纸捅破。我会从电气信号讲到 MAC 地址表，再到路由表和最长前缀匹配，把三种设备各自的"动作清单"摊开对比，中间穿插冲突域、广播域、背板带宽、TTL、NAT 这些绕不开的概念，最后落到"一次跨网段访问到底经历了什么"和"选型时哪些说法是错的"。适合刚接触网络、正在准备认证考试、或者被家里/公司网络折腾过几轮想搞明白原理的人。看完至少能做到：拿到一个网络拓扑，能判断哪台设备在干什么活、瓶颈可能卡在哪。
1. 先把"层"这件事摆平：三种设备站在不同的楼层干活
网络设备的所有差异，追到根上都是"它工作在 OSI 模型的第几层"和"它能看见数据帧里的哪些字段"。这个视角一旦建立，后面所有行为都是推论，不需要死记硬背。
1.1 冲突域与广播域：两个词解释了大半区别
先给两个定义，用大白话说。冲突域是指"在同一时刻只能有一台设备发送数据"的那片范围——两台机器同时开口说话就会撞车，撞了就得退让重来。广播域是指"一台设备发出广播帧，能被送达的所有设备的集合"——广播帧的特点是目的地址全 F，任何收到它的设备都得拆开看一眼。
这两个概念之所以关键，是因为三种设备对它们的作用完全不同：集线器的所有端口共享一个冲突域和一个广播域；交换机的每个端口是一个独立的冲突域，但默认情况下所有端口仍在同一个广播域里；路由器则天然把两边隔成两个广播域。
很多人背过"交换机隔离冲突域、路由器隔离广播域"这句话，但未必想过它意味着什么。举个具体例子：24 口集线器上接了 24 台主机，任意两台同时发数据的概率就非常高，重传、退避、再重传，有效吞吐能掉到标称带宽的三四成；换成 24 口交换机，每台主机独占一条全双工链路，收发互不干扰，理论上可以同时 24 对通信。这不是"性能好一点"，是量级差别。
提示：判断一台设备到底是哪一层，有个笨但好用的办法——看它能识别什么地址。只认电平信号的是第一层，认 MAC 地址的是第二层，认 IP 地址的是第三层。
1.2 用OSI七层把三台设备对号入座
把三台设备摆到 OSI 模型里，位置非常清楚：
| 设备 | 工作层次 | 识别的地址 | 转发依据 | 冲突域 | 广播域 |
|---|---|---|---|---|---|
| 集线器 | 物理层（L1） | 无 | 无，纯信号放大转发 | 全部端口共享 1 个 | 全部端口 1 个 |
| 交换机 | 数据链路层（L2） | MAC 地址 | MAC 地址表 | 每端口 1 个 | 默认全部端口 1 个（VLAN 可切分） |
| 路由器 | 网络层（L3） | IP 地址 | 路由表 | 每接口 1 个 | 每接口 1 个（天然隔离） |
这张表建议抄在本子上。它解释了三件事：为什么集线器换成交换机能立刻解决"人多就卡"；为什么交换机接再多台设备，广播包还是会传到每一个口；为什么跨网段通信必须经过路由器，交换机再贵也办不到。
再补一句容易被忽略的：集线器是半双工的，因为它本质上就是一根共享的导线，同一时刻只能有一个方向有信号；交换机端口可以全双工，收发各走一对线，互不冲突，所以不需要 CSMA/CD 那套碰撞检测机制。这一点在排查"为什么老设备接新交换机后丢包"时特别有用——有些老网卡或者工业设备只支持半双工，接上去就得手动协商，否则双工不匹配会产生大量 CRC 错误和冲突计数。
2. 集线器：物理层的信号复读机，为什么它天然不适合多台主机
集线器（Hub）几乎是网络设备里的活化石，但它恰恰是理解"为什么需要交换机"的最佳教材。把它彻底搞懂，交换机的价值就不用解释了。
2.1 端口之间只是导线相连：电气层面发生了什么
拆开一台集线器，你会看到非常"朴素"的结构：所有端口的收线在内部被连在一起，可能中间串了一级信号整形和放大电路。它的工作方式是这样——端口 A 上的网卡发出一个电平跳变，这个电信号经过集线器内部的共享总线，被复制到除 A 之外的所有端口上。没有任何解析，不检查目的地址，不看帧头，甚至不知道这一串 0 和 1 是不是一个合法的以太网帧。
这带来几个直接后果。第一，带宽是共享的：标称 100Mbps 的集线器，接 10 台设备，不是每台 100Mbps，而是大家抢这 100Mbps。第二，任何一台设备的信号都会抵达所有其他端口，包括那些根本不该收到它的设备——安全上这叫"被动嗅探的温床"，早期抓包工具接在集线器任意一个口上就能看到全网流量，正是因为这一点。第三，某个端口出现电气故障、持续发出噪声，整个网段都会被拖垮，因为噪声会被放大转发到所有端口。
注意：现在市面上还在流通的所谓"集线器"，一部分其实是低端交换机（内部有 MAC 表），购买或替换时必须确认清楚，否则按集线器的思路去规划网络会出问题。
2.2 用概率算一下：10台主机共享一个冲突域有多糟
CSMA/CD 的核心是"先听后说，边说边听，冲突就退避"。它的效率随站点数增加而下降，这个下降可以粗略算出来。
假设冲突域内有 N 个站点，每个站点在某个时隙内以概率 p 尝试发送。一个时隙能成功传输的条件是"恰好只有一个站点发送"，其概率为：
P(成功) = N × p × (1-p)^(N-1)
取最理想的 p = 1/N，代入看看：
| 站点数 N | 最优发送概率 p | 单时隙成功概率 |
|---|---|---|
| 2 | 0.5 | 0.500 |
| 5 | 0.2 | 0.410 |
| 10 | 0.1 | 0.387 |
| 20 | 0.05 | 0.377 |
数据摆在这：10 台主机挤在一个冲突域里，即使每个站点都用最优策略，也只有不到 39% 的时隙能成功传一帧，其余时间要么空转要么在冲突和退避。实际网络中还要叠加传播时延、退避算法的随机性、帧长差异，真实效率比这更低。这就是为什么当年一个教研室十几台机器挂在一个集线器上，实际下载速度只有标称值的零头。
换成交换机之后，每端口独享全双工链路，这个公式直接失效——因为不再存在冲突。**“把共享介质变成点对点链路”**是交换机最本质的贡献，其余特性都是从这一点衍生出来的。
2.3 半双工、带宽共享与"一台设备咳嗽，全网跟着喘"
集线器还有一个隐蔽的坑：它无法做速率协商的"翻译"。一个 10Mbps 的老设备和一个 100Mbps 的设备接在同一台 100M 集线器上，集线器本身只能整体工作在较低速率或者干脆不兼容，实际部署中经常出现"某台老机器一上线，全网降速"的现象。
另外，集线器对广播帧和未知单播帧的处理是同一种——照单全收地复制到所有端口。这意味着广播风暴在集线器上会以最快速度扩散，没有任何抑制手段。而交换机至少还有广播风暴抑制、端口隔离、VLAN 切分这些工具可以做边界。
今天集线器还活着的地方，基本只剩三类：极低成本的临时测试环境；某些老旧工业控制现场（设备固定、帧率极低、电磁环境特殊）；以及作为"教学道具"。真要在生产网络里看到它，第一反应应该是"这里是不是有个坑"。
3. 交换机：MAC地址表是怎么"长"出来的
交换机做的事情说起来一句话：根据目的 MAC 地址，把帧从正确的端口送出去。但"怎么知道哪个 MAC 在哪个端口"这个问题，答案里藏着整个二层转发的精髓。
3.1 上电那一刻，转发表是空的
交换机刚上电时，MAC 地址表是空表。它没有任何先验知识，不知道 1 号口后面挂着什么设备。
学习过程是这样的：当一帧从某个端口进入，交换机会读取源 MAC 地址，然后在这个表里记一条"这个 MAC 对应这个端口"，同时打上时间戳。注意，学习用的是源地址，转发用的是目的地址，这两个动作是分开的，很多人在这里混淆。
举个完整例子。假设 1 号口接主机 A（MAC 为 AA），3 号口接主机 B（MAC 为 BB）。
- A 发一帧给 B。交换机从 1 号口收到，先学：AA → 端口 1。
- 查目的 MAC BB，表里没有。未知单播帧，执行泛洪——从除 1 号口之外的所有端口发出去。
- B 收到并回复。交换机从 3 号口收到，学：BB → 端口 3。
- 查目的 MAC AA，表里有，命中端口 1，从 1 号口转发出去，不再泛洪。
从这一来一回之后，A 和 B 之间的通信就变成点对点了。这个过程叫自学习，交换机的"智能"全部来源于此，没有任何中心控制器参与。
3.2 一帧进来后的三条岔路
任何一帧进入交换机，处理逻辑只有三种结果，把它们列清楚，排障时就能快速定位：
| 目的 MAC 情况 | 处理动作 | 典型场景 |
|---|---|---|
| 表中有记录，且端口 ≠ 入端口 | 转发（Forward），只从记录端口发出 | 正常通信，绝大多数帧 |
| 表中无记录 | 泛洪（Flood），从除入端口外所有端口发出 | 新设备上线、表项老化、扫描行为 |
| 目的 MAC 就在入端口上 | 丢弃（Filter），不转发 | 同端口下的设备互访，或环路导致 |
| 目的 MAC 为全 F 广播 | 泛洪到所有端口（同 VLAN 内） | ARP 请求、DHCP 发现 |
| 目的 MAC 为组播且未开启侦听 | 泛洪到所有端口 | 视频流、组播发现协议 |
这里有个值得注意的点：泛洪不是错误，是机制。很多人在抓包时看到大量泛洪帧就以为交换机坏了，其实更可能是 MAC 表项老化或者网络里有扫描行为在不断触碰不存在的地址。
3.3 老化、泛洪抑制与广播风暴的边界
MAC 表项不是永久的，默认老化时间通常是300 秒（5 分钟）。超过这个时间没有新的流量刷新，表项就被删除。这样设计是因为设备可能换端口、下线、或者 MAC 地址本身就被虚拟化环境动态分配。
老化时间带来的一个典型现象是：一台设备静默十几分钟后突然发包，交换机可能已经不记得它在哪个口，于是第一帧又被泛洪一次。这在抓包里表现为"间歇性的泛洪抖动"，属于正常行为。
真正需要警惕的是广播风暴和MAC 地址漂移。前者是环路的典型症状——两个交换机之间接了两条线却没有启用生成树，广播帧在环里无限循环，端口指示灯疯狂闪烁，CPU 打满；后者表现为同一个 MAC 在极短时间内出现在多个端口上，日志里会刷"MAC flapping"，通常也是环路或者错误的双网卡绑定造成的。
提示：交换机上排查环路，先看端口流量是否呈异常对称的双向拉满，再看 MAC 地址表里同一地址是否在两个口之间反复跳。这两个特征同时出现，基本可以确诊。
3.4 交换机的几种转发模式与背板带宽怎么算
交换机内部转发不是只有一种方式：
- 存储转发（Store-and-Forward）：收完整帧、校验 FCS、再转发。延迟稍大但能丢弃错帧，是主流方式。
- 直通（Cut-Through）：只读到目的 MAC（前 6 字节之后）就开始转发。延迟极低，但会把错帧也转出去。
- 无碎片（Fragment-Free）：读满 64 字节再转发，过滤掉冲突碎片，是折中方案。
选型时经常被问"这台交换机性能够不够"，判断依据是背板带宽和包转发率。以一台 24 口千兆交换机为例：
- 背板带宽需求 = 24 × 1Gbps × 2（全双工双向）=48Gbps
- 包转发率需求 = 24 × 1.488Mpps =35.7Mpps
（1.488Mpps 是千兆线速下按最小帧 64 字节 + 前导 8 字节 + 帧间隙 12 字节 = 84 字节折算出来的每秒包数。）
如果标称参数明显低于这两个数，说明这台设备在满负载时会出现"线速跑不满"的情况，也就是常说的阻塞型交换机。买便宜货时这个参数最容易被含糊带过，值得盯一眼。
4. 路由器：跨网段这件事，交换机真的干不了
交换机再强，它的世界只有 MAC 地址。一旦目的 IP 不在本网段，它就完全无从下手——因为跨网段转发需要"根据 IP 查路由"，这是第三层的事。
4.1 路由表与最长前缀匹配：它凭什么决定往哪个口发
路由器收到一个 IP 包，做的是这样一件事：拿目的 IP 去路由表里逐条比对，找出所有匹配的表项，然后选前缀最长的那一条。
假设路由表里有三条：
10.0.0.0/8 → 下一跳 192.168.1.1 10.1.0.0/16 → 下一跳 192.168.1.2 10.1.2.0/24 → 下一跳 192.168.1.3目的地址是 10.1.2.55，三条都能匹配上，但 /24 最长，所以走 192.168.1.3。这就是最长前缀匹配。
为什么不直接按"先来后到"或者"第一条命中就停"？因为路由表是分层的：/8 可能是运营商汇总路由，/16 是区域路由，/24 是具体子网。如果第一条命中就停，具体路由永远用不上，流量会被错误地送到汇总出口。最长前缀匹配保证了"越精确的路由优先级越高"。
还有一条默认路由 0.0.0.0/0，前缀长度为 0，任何地址都能匹配，但优先级最低，只有在没有更精确匹配时才会用到。这就是"网关"的本质。
4.2 逐跳转发过程中被改写的字段
一个 IP 包穿过路由器时，有几个字段会被改动，这直接关系到排障时的现象判断：
TTL 减一。每经过一台路由器，TTL 减 1，减到 0 就丢弃并回一个 ICMP 超时报文。这个机制最初是为了防止包在环路里永远转下去，后来被 traceroute 用来探测路径——连续发 TTL 为 1、2、3 的包，看每一跳返回的源地址。所以如果发现 ping 不通但 traceroute 能到某一跳，通常说明问题出在那一跳之后。
源和目的 MAC 被重写。这一条最容易搞混。IP 地址在整条路径上保持不变（除非有 NAT），但MAC 地址是逐跳改变的。包从 A 发往路由器 R，帧头的目的 MAC 是 R 的接口 MAC；R 转发给下一跳 R2 时，会重新封装成目的 MAC 为 R2 的帧。所以抓包看到"MAC 地址和 IP 地址对不上"是正常的，不要以为是欺骗。
校验和重算。因为 TTL 变了，IP 头校验和必须重新计算。
可能触发分片。如果出接口的 MTU 小于包长且设置了 DF 标志，会返回 ICMP 需要分片的错误。这是很多"能 ping 通小包、大包不通"问题的根源。
4.3 NAT、DHCP、防火墙：家用路由器为什么是个"套装"
市面上的家用无线路由器，名字里虽然带"路由器"，但它其实是一个多功能合体设备：
- 路由模块：做 NAT、DHCP 服务、PPPoE 拨号
- 交换模块：内置 4 口左右的交换机，负责 LAN 侧接入
- 无线 AP 模块：把无线客户端桥接到 LAN
- 防火墙模块：状态检测、端口映射
其中 **NAT（网络地址转换）**是家用场景的核心。内部所有设备用私有地址，出口时统一换成公网地址，并用端口号区分不同会话（这叫 NAPT 或 PAT）。这就解释了为什么家里只有一个宽带账号，却能让手机、电脑、电视同时上网——它们共用同一个公网 IP，靠源端口号区分。
NAT 带来的副作用也很实际：外部主动发起的连接进不来，所以需要做端口映射才能从外网访问内网服务；某些点对点通信、语音协议会因为地址改写而失效，需要专门的穿透手段。这些都是 NAT "省 IP 地址"的代价。
注意：区分"路由器"和"三层交换机"时，看它是否支持 NAT、是否支持广域网接口类型（如拨号、专线）、是否具备完整的 ACL 和会话跟踪。很多三层交换机只做纯三层转发，不做地址转换。
5. 一次跨网段访问的全程复盘：谁在第几毫秒做了什么
把前面所有零件拼起来，看一次完整的通信过程，是最有效的巩固方式。分两个场景。
5.1 同网段场景：交换机独自完成
主机 A（192.168.1.10）访问主机 B（192.168.1.20），掩码 255.255.255.0。A 计算后发现目的地址和自己同网段，于是决定直接发 ARP 请求问"谁是 192.168.1.20"。
这个 ARP 请求是广播帧，目的 MAC 全 F。交换机会把它泛洪到所有端口（同 VLAN 内）。B 收到后回一个单播 ARP 应答。交换机在这个过程中学习到 A 和 B 的 MAC 与端口对应关系。
之后 A 和 B 之间的所有数据帧都是单播点对点，交换机只做查表转发。整个过程中路由器完全没有参与，甚至连它存不存在都不知道。这一条可以用来快速判断故障范围：如果同网段内两台机器不通，先怀疑交换机、VLAN 划分、网卡或者 IP 配置，别去动路由器。
5.2 跨网段场景：ARP、网关与MAC重写
主机 A（192.168.1.10）访问 10.0.0.5，掩码 255.255.255.0。A 发现目的地址不在本网段，于是决定把包发给网关（假设网关是 192.168.1.1）。
关键点来了：A 需要的是网关的 MAC 地址，不是目的主机的 MAC 地址。所以它发 ARP 请求问"谁是 192.168.1.1"。路由器接口回应，A 拿到网关 MAC。
然后 A 构造 IP 包：源 IP 192.168.1.10，目的 IP 10.0.0.5；封装成帧：源 MAC 是 A 的，目的 MAC 是网关的。这个帧被交换机转发到路由器接口。
路由器收到，拆掉帧头，查路由表发现 10.0.0.0/24 从另一个接口出去，TTL 减 1，重新封装成新的帧——源 MAC 换成自己出接口的，目的 MAC 换成一个网段内的下一跳或者目的主机（同样要先 ARP）。包就这样一跳一跳走到目的地。
整个链路上，IP 地址始终是 192.168.1.10 → 10.0.0.5，而 MAC 地址换了好几轮。理解了这一点，"为什么跨网段抓包看到的 MAC 和预期不一样"就不再是疑问了。
5.3 怎么自己验证：抓包与命令行观察点
想亲眼确认上面的流程，可以按这个顺序做：
- 在 A 上先
arp -a（Windows）或ip neigh（Linux），看网关的 MAC 是否已缓存。如果没有，ping一次网关，再看表里是否多了一条。 - 清空 ARP 缓存后再访问跨网段目标，同时抓包（抓包工具挂在 A 的网卡上）。会先看到 ARP 请求广播，然后是发往网关 MAC 的单播帧。
- 在路由器上查看路由表（
route print、ip route、或者设备的管理界面），确认去往目的网段的最优条目是哪一条，下一跳是什么。 - 用
tracert/traceroute看路径，结合 TTL 超时返回的地址，判断流量实际走了哪条路。
实测下来，最常见的排查误区是"只看 IP 不看 MAC"。比如两台机器 IP 都配对了却互 ping 不通，很多时候是 ARP 表里缓存了错误的 MAC（比如换过网卡、做过双机热备切换），清一下缓存立刻恢复。
6. 选型与踩坑：三层交换机能不能替代路由器
这是被问得最多的问题之一。答案不是简单的"能"或"不能"，取决于边界在哪。
6.1 三层的边界与三层交换机的定位
三层交换机确实能做路由转发，而且转发性能通常远高于同价位路由器——因为它用 ASIC 硬件转发，第一次查路由后会把结果写进硬件转发表，后续同一条流的包直接硬件转发，俗称"一次路由，多次交换"。
但它和路由器有几处本质差异：
| 对比项 | 三层交换机 | 路由器 |
|---|---|---|
| 转发方式 | ASIC 硬件转发，吞吐高、延迟低 | 通用 CPU 转发，吞吐相对低 |
| 端口类型 | 以以太网口为主 | 支持多种广域网接口、串口、光口 |
| NAT | 部分型号支持，能力有限 | 完整支持，会话数管理成熟 |
| 广域网特性 | 基本不具备 | 拨号、专线、策略路由、流量整形齐全 |
| 典型位置 | 园区网核心、数据中心汇聚 | 网络出口、跨地域互联 |
结论很清楚：内部网段之间的高速互访，用三层交换机；连接外部网络、做地址转换和出口策略，用路由器。把三层交换机直接怼在出口做 NAT，短时间可能没事，流量一上来会话表就打满了，或者某些协议根本转换不了。
反过来，在几十台服务器的机房里用一台家用路由器当核心网关，也是常见错误——路由器的交换模块通常只有几个口，且转发能力有限，内网互访会全部压在 CPU 上。
6.2 几个反复被问错的点
"交换机不是能隔离广播吗？"不能，除非划了 VLAN。默认所有端口在同一个广播域，一个 ARP 广播会传到每一个端口。VLAN 的逻辑是把一台物理交换机切成多台虚拟交换机，每个 VLAN 是一个独立广播域，VLAN 之间通信必须经过三层（路由器或三层交换机）。这是"交换机不能替代路由器"的核心原因之一。
"路由器是不是也隔离冲突域？"是，而且每个接口一个，比交换机更彻底。但因为路由器的接口通常不多，这个特性在实际中不太被提起。
"集线器和交换机能不能混用？"技术上能，把集线器接在交换机某个口上，那一片仍然共享带宽和冲突域。实际中除非临时应急，否则没必要——一台百元级的交换机就能解决的问题，用集线器等于给自己埋雷。
"为什么我的交换机明明是千兆，实际只有百兆？"先看端口协商状态。双工不匹配、线序问题（用了只有两对芯的网线）、或者对端设备只支持百兆，都会导致降速。命令行里看接口速率和双工模式是最快的确诊方式。
“MAC 地址表满了会怎样？”交换机的表容量有限（低端设备可能只有几 K 条）。表满了之后新 MAC 学不进去，所有未知单播全部泛洪，网络性能急剧下降，同时可能伴随 CPU 升高。虚拟化环境里大量虚拟机频繁迁移、或者遭遇到源 MAC 伪造的扫描，都可能触发这个问题。
我个人在实际操作中的体会是：排障时先问"这一层谁该负责"，比上来就抓包高效得多。同网段不通，查二层；跨网段不通，查三层和网关；能通但慢，查带宽、双工和广播量。把三种设备的能力边界刻在脑子里，大部分网络问题在十分钟内就能定位到该动哪台设备，而不是在三台设备之间来回试。
