集线器、交换机、路由器这三样东西，几乎每一本网络入门的资料里都要讲一遍，但真把它们摆在同一张拓扑图上，能把“为什么这里放交换机、那里放路由器、那个角落为什么还给留了一台老集线器”讲清楚的人并不多。我见过不少刚入行的朋友，配置命令敲得飞快，一到排障就卡壳，根子往往不在命令行，而在于脑子里没有一张清晰的“设备能力地图”——不知道某个设备看得懂什么、看不懂什么、会把流量怎么处理。这篇内容就围绕集线器、交换机、路由器的工作原理区别展开，把三层设备的分层定位、转发逻辑、冲突域与广播域、地址表与路由表的生成过程、带宽与包转发率的算法，以及实际组网和排障中真正会踩的坑，一次讲透。无论你是刚接触网络、还在背 OSI 七层模型的新手，还是已经能独立配交换机和路由器、但想把底层逻辑补扎实的从业者，都能从里面拿到能直接用的东西。
1. 先把三个盒子放回分层里，差异一眼就出来了
1.1 它们比的不是性能高低，而是“看得懂什么”
很多人下意识地把这三者理解成一条性能阶梯：集线器最差、交换机中等、路由器最强。这个理解是错的，而且错得会误导后面的所有判断。它们在设计上根本不是同一个维度的东西，真正的区别在于工作在哪一层、能识别报文里的哪一部分信息。
打个生活化的比方。集线器像一台复读机，谁在它耳边说话，它就把声音原样放大传给房间里所有其他人，它完全不管说话内容是什么、是不是该给某一个人听。交换机像一个楼层前台，它手里有一张工位对照表，看一眼信封上写的工号（MAC 地址），就知道该把东西送到哪张桌子，不用全楼广播。路由器则像跨城市的物流中转站，它不看工号，看的是城市和街道（IP 地址与网段），决定这东西下一站该发往哪个城市。
对应到分层模型上：集线器工作在物理层，处理的是比特流，也就是电信号的高低电平，它眼里没有“帧”这个概念；交换机工作在数据链路层，处理的是以太网帧，能读懂帧头里的源 MAC 和目的 MAC；路由器工作在网络层，处理的是 IP 包，能读懂源 IP、目的 IP、协议号，还负责改 TTL、做地址转换。
这个层级的差异直接决定了三件事：谁能隔离冲突、谁能隔离广播、谁能连接不同网段。后面所有的性能差异、安全差异、故障现象差异，全是这三件事的推论，而不是反过来。
1.2 冲突域和广播域：一把能解释九成现象的钥匙
我刚带人的时候发现，把这两个概念讲透，比讲十遍设备参数都有用。冲突域指的是同一时刻只能有一台设备发送数据的范围——在这个范围里两台设备同时开口，信号就会互相叠加、彼此破坏，这在以太网里叫冲突（Collision）。广播域指的是一个广播帧能够到达的范围——广播帧的目的 MAC 是全 F，任何收到它的设备都必须处理，不管自己是不是目标。
这两者的边界，恰好就是三种设备的分水岭。我在下面这张表里把关系列清楚，建议直接记住这个结构，比死记硬背设备参数有用得多：
| 设备 | 工作层次 | 每个端口是否独立冲突域 | 是否隔离广播域 | 转发依据 |
|---|---|---|---|---|
| 集线器 | 物理层 | 否，所有端口同属一个冲突域 | 否 | 无，比特复制扩散 |
| 二层交换机 | 数据链路层 | 是，每端口一个冲突域 | 否，整机默认一个广播域 | 目的 MAC 地址 |
| 路由器 | 网络层 | 是 | 是，每接口一个广播域 | 目的 IP 与路由表 |
要注意一个容易被忽略的细节：VLAN 也能切广播域，但它属于交换机的功能扩展，不是交换机的基本属性。默认配置下的交换机所有端口在同一个广播域里，一个广播帧会从除接收口以外的所有端口发出去。很多“网络莫名其妙变慢”的故障，根源就是某个环节产生了广播风暴，而这个广播风暴之所以能蔓延到整层楼，正是因为中间那台交换机没有做广播域隔离。
理解了这张表，很多现象就不用猜了。为什么集线器接的设备一多就卡？因为冲突域没被切开，大家抢同一条信道。为什么交换机下某台机器中毒发包，整层楼的机器都受影响？因为广播域没被切开，广播帧和未知单播被泛洪到了所有端口。为什么路由器两边的设备互相“看不见”？因为它天然隔离广播，ARP 请求根本过不去，这是设计意图，不是故障。
2. 集线器：物理层的复读机，慢是结构性的
2.1 一个比特进来，从所有端口出去
集线器的内部结构简单到几乎没有“逻辑”可言。它本质上是一个多端口中继器：某个端口收到电信号，经过整形放大（补偿线路衰减、重新生成规整的波形），然后复制到除接收端口以外的所有端口上发出去。整个过程不解析帧头，不校验地址，不做任何缓存，也没有队列。信号进来和出去之间的延迟只有硬件转发的那一点时间，通常在微秒级以内。
这个设计带来两个直接后果。第一是共享介质：物理上虽然是一堆网线接在同一个盒子上，但逻辑上等同于所有人接在同一根同轴电缆上，任何时刻只能有一个人说话，否则就撞车。第二是半双工：接在集线器上的设备不能同时收发，因为一旦同时发，收发线对上都会有信号，自己的发送会和自己收到的别人信号叠在一起，直接冲突。这也是早期以太网设备必须靠 CSMA/CD 协议来协调的根本原因。
顺带说一个实践中的认知点：集线器不是“不检查错误”，而是它检查不了。它转发的比特流里如果帧校验序列（FCS）是错的，它照样原封不动地扩散出去，坏帧会占用所有端口的带宽。交换机则不同，收到坏帧直接丢弃，不会浪费其他端口的带宽。这个差异在高负载时非常明显。
2.2 CSMA/CD：那套被遗忘的抢麦规则
既然所有设备共享同一条信道，就必须有一套规则来决定谁先说。这套规则就是带冲突检测的载波侦听多路访问（CSMA/CD），它的流程可以拆成四步，我用开会抢话的场景类比一下会更直观。
第一步，先听后说（载波侦听）：发言前先听一下频道上有没有人在讲，如果信道忙就等，一直等到静默。第二步，边听边说（冲突检测）：开始发言后仍然要保持监听，因为可能刚好有两个人同时判断信道空闲、同时开口。第三步，撞了就停：一旦检测到冲突，立刻停止发送，转而发送一个 32 位的干扰序列（Jam 信号），目的是把冲突信号加强、拉长，确保网络上所有设备都能可靠地感知到这次冲突，而不是有的人感知到了、有的人没感知到。第四步，随机退避：停止发送后，各自等待一段随机时间再重试。
退避时间的算法是二进制指数退避，公式是：退避时间 = 随机整数 × 时隙时间，其中随机整数的取值范围随重试次数翻倍，第一次冲突取 0 或 1，第二次取 0 到 3，第三次取 0 到 7，依次翻倍，重试到第 10 次以后范围固定在 0 到 1023，累计重试 16 次仍失败则向上层报错、丢弃这一帧。
这个“范围翻倍”的设计很有意思：它让冲突的双方在下一轮里被拉开距离的概率越来越大，同时它也是自适应的——网络越拥塞，退避窗口越大，主动降低抢信道的激烈程度。代价是重试次数多了以后，等待时间明显变长，表现出来就是你感觉“网络有时候会莫名其妙顿一下”。
2.3 一台集线器能带多少台机器，算一遍就清楚了
厂商宣传的“10M 集线器”，说的是整台设备共享 10Mbps，不是每个端口 10Mbps。这一句话就能解释绝大多数疑问。假设 10 台终端接一台 10Mbps 集线器，理论上平均每台分到 1Mbps；但这只是理想值，实际还要扣掉冲突带来的时间损失——每次冲突至少要浪费一个时隙加上退避等待，冲突越多，有效吞吐越低。业界的经验是，共享式以太网在负载达到 30% 到 40% 时，冲突开销就开始明显侵蚀吞吐，实际叠加下来，10 台机器的体验远不如理论上的平均 1Mbps。
再往深一层，冲突还和线缆长度强相关，因为 CSMA/CD 要求发送方在帧发完之前就能检测到冲突，所以“冲突窗口”必须大于信号走完整个网络最远往返路程的时间。在 10Mbps 以太网里，一个时隙定义为 512 比特时间，也就是 51.2 微秒，这约束了整个网络的直径。以太网早期有个著名的“5-4-3 规则”：最多 5 个网段、最多 4 个中继器（集线器）、其中最多 3 个网段可以接设备。这不是厂商拍脑袋定的，而是传播时延算出来的物理上限。
所以，问“集线器能带几台机器”，标准答案不是某个数字，而是：能带几台取决于业务流量模型和布线长度，但无论怎么算，它都是一个共享带宽设备，加一台机器就摊薄一次。我一般给的建议是，如果非要用，尽量控制在 5 台以内、只跑小流量业务，并且注意不要级联太多层。
2.4 今天还在用集线器的场景，以及必须避开的坑
坦白说，纯集线器在新组网里基本没有位置了。但在一些特殊场景里它仍然会被翻出来：老旧设备的兼容验证、某些需要“所有端口收到同样流量”的调试环境、以及某些对成本极度敏感的临时链路。
这里有一条必须提醒的经验：想监听流量，别顺手拿集线器接进现网。很多人听说了“集线器会把流量扩散到所有端口”，就想当然地拿它串在链路中间做抓包。问题是，一个 10Mbps 半双工的集线器串进一条千兆全双工链路，不仅把带宽砍到原来的百分之一，还把双工模式从全双工降成半双工，同时因为共享冲突，原本正常的业务会被拖慢甚至丢包。想抓包，正规做法是交换机端口镜像或者专用的分光/串接设备，不要把生产链路拿去做实验。
另外要警惕一个隐蔽问题：集线器年代久远，很多老设备的电源和端口已经老化，接触不良会产生大量 CRC 错误帧，而它自己又不会统计和丢弃，直接把坏帧扩散出去。现象就是链路“时通时断、速度忽高忽低”，用 ping 看延迟忽大忽小但又不完全断。遇到这种，第一件事不是查配置，而是换掉那台老盒子。
3. 交换机：切开冲突域的那把刀
3.1 一张 MAC 地址表是怎么自己长出来的
交换机之所以聪明，核心在于它内部维护了一张MAC 地址表（有的资料叫转发表、CAM 表），记录着“哪个 MAC 地址出现在哪个端口上”。这张表不是手工配的，是设备自己学出来的，这个过程叫自学习，逻辑就三步。
第一步，学习源地址。任何一帧进入某个端口，交换机第一件事就是把帧头里的源 MAC 和这个入端口绑定，写进表里，并重置这个表项的定时器。含义是“从这个口进来的帧，源地址是它，说明这台设备在我这个方向”。第二步，查目的地址。拿到目的 MAC 后去表里找。第三步，决定动作：找到对应端口就只从那个端口发出去（这叫转发，Forward）；查不到就从除接收口外的所有端口发出去（这叫泛洪，Flooding）；如果查到对应端口恰好就是接收口本身，直接丢弃（这叫过滤，Filter），因为收发在同一侧的流量没必要再送回去。
表项不是永久的，有老化时间，多数设备的默认值在 300 秒左右。这个设计的好处是设备换端口、换机器时表能自动修正，不用人工清理；坏处是长时间没有流量的设备记录会被清掉，下次通信又得重新泛洪一次。所以你会看到一种现象：一条空闲了很久的链路，突然有了流量，前一两个包会带一点额外的延迟和泛洪，之后才恢复正常——这不是故障，是表项老化重建的正常过程。
这里有个实操细节值得记：MAC 表容量是有上限的。低端设备可能只有几百到几千条，一旦表满，新学到的地址会覆盖不掉或者干脆学不进来，表现就是大量流量退化成泛洪，整机性能断崖式下跌。这一点在接入设备多、或者遭遇地址泛洪攻击时特别容易暴露，排查时直接看表项使用率和泛洪计数就能定位。
3.2 四种转发行为，四种典型现象
把上面的逻辑展开，交换机对一帧的处理就是四种结果，每一种都对应着你能观察到的现象，我整理成表方便对照：
| 行为 | 触发条件 | 现象与影响 |
|---|---|---|
| 转发 | 目的 MAC 在表里且对应端口不是入端口 | 只占两个端口的带宽，其他端口无感 |
| 过滤 | 目的 MAC 对应的端口就是入端口 | 帧被丢弃，通常发生在同口环路或本口自环 |
| 未知单播泛洪 | 目的 MAC 不在表里 | 除入端口外全网段扩散，安全与带宽双重风险 |
| 广播/组播泛洪 | 目的 MAC 为全 F 或组播地址 | 全体端口扩散，是广播风暴的物理基础 |
未知单播泛洪是最容易被忽略的一项。很多人以为“只有广播帧才会扩散”，其实不是。任何没学过地址的单播帧都会泛洪，包括刚开机、刚换端口、刚过老化时间的设备产生的第一个包。这也解释了为什么在某些监控或者工业控制场景中，一个网段里的设备频繁上下线，会在交换机上看到持续的泛洪流量。
广播帧则更彻底，它是不会“学会”的，永远泛洪。ARP 请求、DHCP 发现报文这些都属于广播，所以一个广播域里的设备越多，广播帧带来的总开销越大。这就是为什么大型网络必须切广播域——不是为了好看，是为了把广播的波及范围压在某一个 VLAN 或某一个接口下。
3.3 全双工和微段化，把带宽口径彻底改写了
交换机每端口一个冲突域，这句话的实际意义是：每个端口各自独立，互不干扰，而且端口可以工作在全双工模式下——发送和接收各走一对线，同时进行，不需要 CSMA/CD 协调。既然没有冲突了，CSMA/CD 在交换机端口上自然就关闭了，这一点很多人不知道：全双工链路下冲突计数永远是 0，如果看到某端口有冲突计数，那基本可以断定双工模式配置不匹配（一端全双工、一端半双工或自协商失败），这是非常典型的故障特征。
带宽的计算口径也随之改变。很多采购参数里写的“背板带宽”或“交换容量”，算法是：端口数量 × 单端口速率 × 2（全双工双向）。一台 24 口千兆交换机，就是 24 × 1Gbps × 2 = 48Gbps。如果厂商标称值明显低于这个数，说明内部存在阻塞，满配时可能跑不满线速。
另一个更实在的指标是包转发率（也叫吞吐率），单位是 Mpps（每秒百万包）。线速转发的算法要基于最小以太网帧：帧长 64 字节，加上前导码 8 字节和帧间隙 12 字节，实际占用 84 字节，也就是 672 bit。千兆端口跑满时的包转发率 = 1,000,000,000 bit/s ÷ 672 bit ≈ 1.488 Mpps。一个千兆端口约 1.488 Mpps，24 口就是 35.7 Mpps 左右，万兆端口则是 14.88 Mpps。
为什么要算这个？因为交换机内部的转发引擎是有处理能力的上限的，如果标称的包转发率达不到端口数算出来的线速值，那么在大量小包（比如游戏、语音、DNS 查询）冲击下就会开始丢包，而大包业务（比如文件传输）却完全正常。这种“大包没事、小包丢”的现象，很多人一开始会怀疑线路，其实根源是转发引擎能力不足。我一般在选型时会拿这两个数做交叉验证：交换容量对得上、包转发率也对得上，才算是真正无阻塞。
3.4 VLAN 和生成树：交换机真正好用的两条腿
单台交换机的自学习逻辑其实不复杂，训练有素的人一下午就能摸清。交换机真正的工程价值体现在两个扩展能力上：VLAN 和生成树。
VLAN的作用是把一台物理交换机切成多台逻辑交换机，每个 VLAN 是一个独立广播域。实现上靠 802.1Q 标签，在以太网帧头插入 4 个字节，其中 12 位是 VLAN ID，可用范围 1 到 4094（0 和 4095 保留）。端口分两种角色：接终端的叫 Access 口，进出都不带标签，由交换机负责打标和去标；交换机之间互联的叫 Trunk 口，允许多个 VLAN 的带标签帧通过。这套机制解决了两个实际问题：一是把广播域压小，二是让不同部门/不同业务在物理上共用一个布线系统但逻辑上互不相通。
有一点必须说清楚：VLAN 隔离的是二层广播域，不是三层路由。跨 VLAN 通信必须经过三层设备（路由器或者三层交换机），因为不同 VLAN 的主机 IP 通常在不同网段，二层根本处理不了。这也是很多人配完 VLAN 后发现“同 VLAN 能通、跨 VLAN 不通”的原因，不是配错了，是缺了三层网关。
生成树解决的是环路问题。二层网络最怕环路，因为以太网帧头里没有 TTL 这种“跳数上限”字段，一旦成环，广播帧会在环里无限循环、不断复制，几秒钟就能把链路带宽占满，整网瘫痪，这就是广播风暴。生成树的思路是：交换机之间交换 BPDU 报文，选出一个根桥，然后各交换机计算到根桥的最短路径，把多余的端口逻辑上阻塞掉，物理上保留、逻辑上不通，一旦主链路故障，被阻塞的端口再自动放开。经典 STP 收敛要 30 到 50 秒，RSTP 能压到秒级，MSTP 在此之上支持多实例、按 VLAN 负载分担。
我在实际项目里吃过一次教训：做接入层改造时，为了省事把新交换机直接上电接入，没检查生成树配置，结果两台设备之间的链路被误判，BPDU 处理不一致，短时间出现了环路告警和端口震荡，业务抖了将近一分钟。从那以后我的习惯是，任何交换机上线前先确认三件事：生成树模式是否统一、边缘端口有没有开、BPDU 保护有没有配。
3.5 动手验证：看一眼 MAC 表，抓一次 ARP
理论讲再多，不如自己看一眼。验证交换机自学习最简单的方式是三步。
先看终端的邻居缓存和接口信息，Linux 下：
ip -br addr ip neigh showWindows 下：
ipconfig /all arp -a然后在终端 A 上 ping 终端 B，再去看交换机的 MAC 地址表（不同设备的查看入口不一样，通常是“MAC 地址表”或“转发表”相关的查看项，有的设备也支持通过网管界面看）。你会发现 A 和 B 的 MAC 分别挂在各自的接入端口上，并且表项后面带着一个剩余老化时间。
再做一次更有意思的验证：把终端 B 关机，重复 ping，同时抓包。你会看到交换机对 B 的 MAC 一开始仍然按表转发，等表项老化（或 B 关机后无人应答）之后，流量开始泛洪，网络上出现针对 B 的 ARP 请求广播，直到底层确认不可达。这个过程把“未知单播泛洪”和“广播泛洪”两个概念同时演示了一遍，比看十页文档直观。
4. 路由器：它管的不是线，是网段
4.1 路由表长什么样，最长前缀匹配怎么算
交换机看 MAC，路由器看 IP。路由器的核心数据结构是路由表，每一条表项至少包含三样信息：目的网段/掩码、下一跳地址（或出接口）、度量值。它的作用就是回答一个问题：这个目的 IP，我该从哪个口发出去、交给谁。
路由表里的条目来源有三种：直连路由（接口配了 IP 且状态 up，自动生成）、静态路由（手工配置）、动态路由（跑协议学来的，比如 OSPF、BGP 这类）。三种来源的可信度用管理距离/优先级来排序，直连最优先，静态次之，动态再次之，所以同一目的网段有多条来源时，先比优先级，优先级相同再比度量值。
真正决定转发的是最长前缀匹配规则：在所有匹配目的地址的表项里，选掩码最长（最精确）的那条。这条规则的逻辑很朴素——越具体的描述越可信。举个例子，假设路由表里有这么几条：
| 目的网段/掩码 | 下一跳 | 说明 |
|---|---|---|
| 0.0.0.0/0 | 203.0.113.1 | 默认路由，兜底 |
| 192.168.0.0/16 | 192.168.1.1 | 汇总路由 |
| 192.168.1.0/24 | 直连 | 本地网段 |
| 192.168.1.128/25 | 192.168.1.254 | 细分网段 |
现在有一个目的地址 192.168.1.200。它同时匹配 /0、/16、/24、/25 四条，按最长前缀，最精确的是 /25，所以走 192.168.1.254。如果目的地址是 192.168.1.100，只匹配 /0、/16、/24 三条，最长是 /24，直连，于是路由器直接在本地网段发 ARP 找这台主机。
这个匹配是按位比较的，不是按数字大小，所以要特别注意掩码边界。我见过有人把 192.168.1.128/25 配成了 192.168.1.128/24，结果整个 /24 的流量都往错误的方向走，排查了半天才发现是掩码少算了一位。
4.2 一个包的真实旅程：IP 基本不变，MAC 逐跳重写
这是理解路由器最关键的一环，也是考试和面试里最爱问的点。假设主机 A（192.168.1.10）要访问另一网段的主机 B（198.51.100.20），中间经过两台路由器。整个过程里，源 IP 和目的 IP 全程不变（除非中间有 NAT），但源 MAC 和目的 MAC 每一跳都在变。
具体是这样走的。主机 A 先用目的 IP 和自己的子网掩码做与运算，发现 B 不在本网段，于是决定把包交给默认网关。它发一个 ARP 请求问“谁是这个网关 IP”，拿到网关的 MAC，然后组帧：源 MAC 是自己的，目的 MAC 是网关的。第一台路由器收到后，先校验、减 TTL，然后查路由表决定下一跳，接着用下一跳的 IP 发起 ARP 拿到下一跳的 MAC，重新组帧：源 MAC 换成自己出接口的 MAC，目的 MAC 换成下一跳的 MAC，IP 头原样保留（TTL 已经减 1）。如此重复，直到最后一台路由器发现目的网段直连，直接 ARP 找到主机 B 的 MAC，把帧送过去。
把这套流程整理成表更清楚：
| 环节 | 源 IP | 目的 IP | 源 MAC | 目的 MAC | TTL |
|---|---|---|---|---|---|
| A 发出 | 192.168.1.10 | 198.51.100.20 | A 的 MAC | 网关1 的 MAC | 64 |
| 网关1 转发 | 192.168.1.10 | 198.51.100.20 | 网关1 出接口 MAC | 网关2 的 MAC | 63 |
| 网关2 转发 | 192.168.1.10 | 198.51.100.20 | 网关2 出接口 MAC | B 的 MAC | 62 |
TTL 的作用是防止包在网络里无限打转：每经过一台路由器减 1，减到 0 就丢弃，并回一个 ICMP 超时报文。这就是 tracert（Windows）或 traceroute（Linux）能工作的原理——它故意发 TTL 从 1 开始递增的包，靠沿途路由器回的超时报文把路径一段段画出来。所以看到 traceroute 某一跳是星号，通常是那台设备配置了不回 ICMP，而不是链路真的断了。
理解了“MAC 逐跳重写、IP 端到端不变”，很多现象就顺理成章了：为什么改 IP 之后不用改交换机配置？因为交换机根本不看 IP。为什么跨网段通信必须先配网关？因为没有网关，主机不知道第一跳该把帧送给谁的 MAC。为什么同一台主机的 ARP 表里只有网关的 MAC 而没有远端主机的 MAC？因为它从来不需要知道远端主机的 MAC。
4.3 ARP、默认网关、NAT、DHCP 各自站在哪一环
路由器周边有四个配角，理解了分工，组网时就不容易乱。
ARP负责把 IP 翻译成 MAC，是二层和三层之间的桥。它在本地广播域内工作，跨不过路由器，这也是判断“某故障是二层还是三层问题”的分水岭：如果 ARP 都学不到，问题在二层或物理层；如果 ARP 正常但不通，问题在三层及以上。
默认网关是主机路由表的最后一条兜底规则。主机发现目的地址不在本网段，就交给网关。这里有个容易忽略的点：主机判断“是否同网段”用的是自己的掩码，不是网关的掩码，所以网关地址配错掩码边界会导致“以为是同网段、实际不是”，现象很怪——本地部分地址通，另一部分不通。
NAT（网络地址转换）解决的是私网地址访问外网时的地址映射问题。最常见的形式是端口级复用（NAPT/PAT），把多个内网地址映射到同一个公网地址的不同端口上，靠一张转换表记录对应关系。它顺带带来一个副作用：外部无法主动访问内网主机，除非手工做端口映射。这也是为什么内网服务要对外提供访问，必须在边界设备上配映射规则。
DHCP负责自动下发地址，四步交互：发现（客户端广播找服务器）、提供（服务器回应可用地址）、请求（客户端广播确认要用哪个）、确认（服务器最终确认并下发掩码、网关、DNS）。这四步里有三步是广播，所以 DHCP 服务器和客户端必须在同一广播域，或者中间配了中继把广播转成单播送到远端服务器。
4.4 动手看：路由表怎么读，静态路由怎么加
看路由表是最基础也最实用的技能。Linux 下：
ip route show典型输出里，default via 192.168.1.1 dev eth0就是默认路由，192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10是直连路由。Windows 下用route print，会分成接口列表、IPv4 路由表、持久路由三块，重点看“网络目标/网络掩码/网关/接口/跃点数”这几列，跃点数越小优先级越高。
加一条静态路由，Linux：
ip route add 198.51.100.0/24 via 192.168.1.1 dev eth0Windows：
route add 198.51.100.0 mask 255.255.255.0 192.168.1.1验证路由是否生效，用tracert 198.51.100.20（Windows）或traceroute 198.51.100.20（Linux），看第一跳是不是你配置的下一跳。这里有个我踩过的坑：加了静态路由但没生效，查了半天发现是出接口写错了，包被送到了错误的接口上，而该接口恰好也有到目的网段的路由，形成了次优路径，现象是“能通但延迟异常高”。所以配静态路由时，下一跳和出接口都写明确，能避免这类歧义。
4.5 路由器为什么“慢”，三层交换机又是怎么来的
老式的软件路由器转发一个包要走完整流程：收包、拆帧、校验、查路由表、减 TTL、重算校验和、可能还要做 ACL 过滤和 NAT 转换、重新组帧、发出去。这套流程走 CPU，一个包要几微秒到几十微秒，折算下来就是几十万到几百万 pps 的量级，跟交换机硬件转发动辄几十上百 Mpps 完全不在一个量级。这就是“路由器慢”印象的来源——它慢在通用处理，不在设计缺陷。
后来出现了三层交换机，思路是“一次路由、多次交换”：第一个包走软件流程查路由、建立转发表项，后续同一条流的包直接由硬件 ASIC 按缓存表项高速转发。现代的实现已经把这个过程做得更彻底，直接用硬件查 FIB（转发信息库），根本不需要“第一次走软件”。所以今天说“三层交换机比路由器快”这句话是有条件的：它快在纯三层转发场景，但如果要做复杂的 NAT、策略路由、深度报文检测、加密隧道，还是得靠专门的路由设备或者更强的处理平台。选型时别被一个“快”字带偏，先看清自己的流量模型。
顺带说，这也是很多机房核心层用三层交换机做 VLAN 间路由、而边界用路由器做出口的原因：内网大流量走硬件转发，出口做地址转换和策略，各司其职，这是长期实践总结出来的分工，不是习惯问题。
5. 对比与选型：别抄结论，抄判断方法
5.1 关键参数对照，一张表看全
把前面所有内容压缩成一张对照表，方便随时回查：
| 对比项 | 集线器 | 二层交换机 | 路由器 |
|---|---|---|---|
| 工作层次 | 物理层 | 数据链路层 | 网络层 |
| 转发依据 | 无 | 目的 MAC | 目的 IP |
| 冲突域 | 全部端口一个 | 每端口一个 | 每接口一个 |
| 广播域 | 全部端口一个 | 默认一个（VLAN 可切） | 每接口一个 |
| 双工模式 | 半双工 | 全双工 | 全双工 |
| 是否隔离广播 | 否 | 默认否 | 是 |
| 是否连接不同网段 | 否 | 否（需三层功能） | 是 |
| 带宽特性 | 全员共享 | 每端口独享 | 每接口独享 |
| 典型延迟 | 极低（微秒内） | 低 | 相对高 |
| 常见故障 | 冲突、带宽摊薄、坏帧扩散 | 环路、泛洪、表满、双工不匹配 | 路由错配、NAT 表满、MTU 问题 |
5.2 四类场景，四种摆法
家庭或小工作室：一台无线路由设备基本包办所有角色——它内部其实同时包含了交换模块、路由模块和无线接入模块。这时候你不用纠结三者区别，但要知道它内部的交换模块是不隔离广播的，所以家里设备一多，广播流量会上升，但通常不影响使用。
小型办公网：接入层用二层交换机，负责端口密度和 VLAN 划分；出口用路由器，负责地址转换和上网策略。这里的判断标准很简单：如果要跨网段通信、要接外网，必须有路由器或三层交换机；如果只是同网段扩展端口，二层交换机足够。
机房或中型网络：接入层二层交换机做端口接入和 VLAN，汇聚层用三层交换机做 VLAN 间路由和策略控制，核心/边界用路由器做出口。这里要特别注意生成树的设计和广播域的规划，VLAN 数量不是越多越好，每个 VLAN 都要占用三层网关资源，规划混乱后期维护成本极高。
工业、监控、临时链路：这类场景关注的是稳定性和实时性，往往不需要复杂的路由功能。交换机选型重点看工作温度、供电方式、端口防护和是否有环网冗余协议。这类环境里我曾经因为省事用了商用品，夏天机柜温度一上来就开始丢包重启，后来换成工业级才稳定，这个教训值得记——环境适应性是参数表里最容易被忽略的一栏。
5.3 五个流传很广的误解
第一，“交换机隔离广播”。不对，默认不隔离，只有配了 VLAN 才隔离，而且是靠 VLAN 这个逻辑划分，不是靠端口本身。
第二，“路由器一定比交换机快”。不对，纯三层转发场景下三层交换机快得多，路由器胜在功能全面和策略灵活。
第三，“集线器和交换机只是新旧区别”。不对，它们是工作机制的根本不同，一个共享一个独享，集线器接多台设备必然互相拖累，这不是性能差不差的问题，是结构决定的。
第四，“有了三层交换机就不需要路由器”。不对，出口的地址转换、策略控制、链路备份这些，还是路由设备更成熟。三层交换机擅长的是内网高速转发。
第五，“MAC 地址表配好就不用管了”。不对，它是自学习的，会老化、会溢出、会被攻击污染。实际维护中要关注表项数量、泛洪计数和老化行为，尤其是设备频繁上下线的场景。
6. 排查实录：现象倒推层级，比盲猜快十倍
6.1 常见问题速查表
排障最忌讳一上来就改配置。我的习惯是先看现象，用现象反推层级，再动手验证。下面这张表是我这些年攒下来的高频对照：
| 现象 | 最可能的原因 | 优先验证动作 |
|---|---|---|
| 一台上网，全组变慢 | 集线器共享带宽或广播风暴 | 看冲突计数、广播包速率 |
| 时通时断、延迟忽大忽小 | 物理层问题（线缆、接触、双工不匹配） | 看端口 CRC 错误、双工状态 |
| 同网段能通，跨网段不通 | 缺网关或路由缺失 | 查主机网关、查路由表 |
| 同 VLAN 通，跨 VLAN 不通 | 缺三层网关或 VLAN 接口未配 | 查 VLAN 接口状态与地址 |
| 全部不通且端口灯狂闪 | 二层环路 | 查生成树状态、端口流量 |
| 大包通、小包丢 | 转发引擎能力不足或 MTU 问题 | 测不同包长的丢包率 |
| 刚接上的设备头几个包慢 | MAC 表项老化重建、ARP 学习 | 观察泛洪计数变化 |
| 某台设备突然全网可见 | 未知单播泛洪或地址欺骗 | 查 MAC 表异常表项 |
6.2 我的排查顺序：从下往上，逐层排除
遇到“网不通”，我基本按这个顺序走，绝大多数问题能在前三步定位。
第一步，物理层。看端口灯、看链路状态，Linux 用ip -br link，确认接口是不是 up、速率和双工协商成了什么。如果看到半双工或者速率不对，先解决协商问题，别急着往上查。
第二步，二层。看 ARP 能不能学到对端，ip neigh show或arp -a。ARP 学不到，说明广播域不通，往下查 VLAN、查端口是否在同一个广播域、查有没有端口被生成树阻塞。ARP 能学到但 ping 不通，往三层走。
第三步，三层。查本机路由表、查网关配置、逐跳tracert。这里有个技巧：tracert 如果第一跳就不通，是本机到网关的问题；如果中间某跳开始不通，问题在那一段；如果能到倒数第二跳、最后一跳不通，多半是目的端防火墙或回程路由问题。回程路由这个坑很隐蔽——去程通、回程没路由，现象就是“请求发出去了但收不到回应”，用抓包在目的端能看到请求进来、却没看到回应出去。
第四步，应用层与策略。到这一步链路和路由都通了，问题往往在端口、ACL、NAT 映射或者服务本身。用ping加端口探测（比如 telnet 到目标端口）区分是网络不通还是服务没起。
6.3 三个我印象最深的坑
第一个是双工不匹配。现象是低速时一切正常，一上大流量就开始丢包、延迟飙升。原因是链路一端强制全双工、另一端自协商成了半双工，半双工那端会把全双工端同时收发的行为当成冲突。查法是看两端的双工状态和冲突计数，解决方法是两端统一（要么都自协商，要么都强制同一种模式）。这个坑的迷惑性在于，ping 小包完全正常，只有压测才暴露。
第二个是MAC 表溢出引发的泛洪。某次接入设备较多，网络开始出现莫名的延迟和广播量上升，查了半天配置都对，最后看交换机的表项使用率已经接近上限，大量新地址学不进来，流量退化成泛洪。解决办法不是加配置，是重新规划接入规模、切小广播域。这提醒我，选型时表容量这个参数不能只看“够用”，要看峰值和余量。
第三个是MTU 不一致导致的大包黑洞。现象很典型：网页能打开（小包），文件传一半卡死（大包），ping 大包直接不通。原因是路径中某一段 MTU 更小，而报文带了“禁止分片”标志，中间设备既不能转发也不能分片，只能丢弃，还不一定回错误。验证方法是用不同大小的包逐步试探（ping 时指定包长并禁止分片），找到那个临界值，然后调整 MTU 或者修正 MSS。这类问题在任何跨运营商、跨隧道封装的链路上都可能出现，属于必查项。
我个人的体会是，这三类故障的共同点在于“都发生在设备之间的交界处”——双工是两端配置的交界，MAC 表是学习能力与规模的交界，MTU 是两段链路参数的交界。所以我现在排查时，会优先去看“边界”而不是“中心”，很多问题就出在两边没对齐的那一点上。同理，选型和设计时，凡是要把两种不同设备、不同网段、不同参数接在一起的地方，都值得多花十分钟确认参数一致，这十分钟往往能省掉后面几小时的排查。
