集线器与交换机对比实验：数据链路层转发原理详解

网络课程做到“交换机和集线器”这一节，最容易被忽略的是：它们从外表看都是“把几台电脑连起来”的铁盒子，可实际工作方式差了整整一个维度。我曾经在实验课上见过有同学把Hub和Switch换着插，发现网络都能通，就说“这俩没区别”，直到我们用抓包软件把数据摆到屏幕上，他才意识到自己之前对链路层转发的理解全是模糊的。这篇实验笔记就围绕这个关键分歧展开：先讲清楚集线器和交换机在协议栈里所处的位置，然后用三台PC加一台Hub、一台Switch做一组对照实验，分别观察单播、广播和并发传输下的表现，最后说说那些报告中容易写错、实验里容易误读的结论。如果你正准备做计算机网络实验，或者想彻底理解数据链路层的转发原理，这篇文章可以当成一份能直接照着操作的实验记录。

1. 实验前先把一个分歧点想清楚：集线器和交换机差在哪一层

1.1 传声筒与派件员：两种完全不同的工作框架

我习惯把集线器比喻成办公室里的传声筒。你对着传声筒说一句话，传声筒并不关心这句话是说给谁的，它只负责把你的声音放大，然后送到连接在它身上的每一根线路上。集线器就是这样一个物理层设备，它处理的是电信号，只要某个端口收到电平变化，它就把这些信号整形、放大之后从其他所有端口发出去。它根本没有能力去看以太网帧里的MAC地址，因为“读地址”这件事需要理解帧的结构，而物理层设备只认比特，不认帧。

交换机就不一样了，它是数据链路层的设备，能够完整地识别以太网帧，读取帧头里的目的MAC地址和源MAC地址。为了完成转发，交换机内部维护着一张MAC地址表，专业一点叫CAM表。这张表记录着“哪个MAC地址从哪个端口学到”的对应关系。当一帧进入交换机，它会查找目的MAC对应的端口，如果找得到，就只从那个端口发出去；如果找不到，才把帧从除了接收端口以外的所有端口发送出去，这个过程叫泛洪。

所以在实验开始之前，你要在脑子里建立两个完全不同的模型：Hub是物理层的“无脑转发器”，它不查MAC、不学地址；Switch是链路层的“智能派件员”，它查表、学习、老化、定向投递。至于为什么两者都能把网络连通，是因为以太网本身就容忍“先把帧发给所有人，让接收方自己判断该不该收”的机制，但这不代表它们的工作方式相同。

1.2 一个冲突域与多个冲突域，最终表现为带宽模型不同

另一个必须提前理解的概念是冲突域。集线器把所有端口连接在同一个共享信道上，整个Hub就是一个冲突域。想象一条很窄的会议电话线，接进来的所有人都共享这条线，A说话的时候B如果也开口，声音就混在一起，谁也听不清。以太网解决这种冲突的办法是CSMA/CD，也就是先听再发、边发边听，发现冲突就随机退避后重传。Hub因为内部是共享总线结构，同一时刻只允许一个端口发送数据，而且工作在半双工状态，不能同时收和发。

交换机则把物理隔离做到了端口级别。每个交换端口通过独立的点到点链路连接一台主机，这个端口就是一个独立的冲突域。现代交换机几乎都支持全双工，发送和接收使用不同的线对，也就不存在冲突问题。正因如此，两台主机在一个Hub上通信时，总带宽被整个冲突域共享；而在交换机上，每个端口独享自己的线路带宽，多个端口可以同时通信。

很多人把这个区别简单记成“Hub共享带宽，Switch独享带宽”，这个说法基本不错，但理解时要小心：Hub是物理共享，所有主机抢同一条链路；Switch是逻辑转发，数据从背板或交换矩阵中走，各端口之间只要处理能力够，可以同时并行传输。实验中看不看得到这个差异，取决于你是否做了并发流量测试。

1.3 带着三个观测目标进实验室

直接连上设备就抓包容易变成“无头苍蝇”。我在做这个实验前，会在实验报告第一页写下三个要验证的问题。

第一个目标：验证集线器对单播帧是不是真的无差别转发。也就是说，当PC1向PC2发送一个目的MAC是PC2的数据帧时，PC3能不能同样收到。第二个目标：验证交换机是不是永远都“定向投递”。更准确地说，应该观察交换机在什么情况下会泛洪，什么情况下能精确定向转发。第三个目标：在广播和并发传输场景下，搞清楚冲突域数量和广播域范围是怎么变化的。把这三个目标写在前面，后面每一步操作就有了方向，报告也不容易写成流水账。

2. 实验台怎么搭：三台PC、一张拓扑、两类观察手段

2.1 最省事的拓扑和IP规划

这个实验不需要太复杂的网络结构，最典型的是星型拓扑，中间设备分别换成Hub和Switch。我建议至少准备三台PC，分别记为PC1、PC2、PC3，都接到中间的待测设备上。PC1扮演发送方，PC2扮演目标主机，PC3作为“无关主机”用来观察是否有不该出现的流量。

三台机器的IP地址规划在同网段即可，例如PC1是192.168.1.1/24，PC2是192.168.1.2/24，PC3是192.168.1.3/24。必须处在同一网段，是为了排除跨三层路由的变量，让实验聚焦在二层转发上。子网掩码统一为255.255.255.0，网关可以不配，因为本实验所有通信都发生在同一个广播域内，不需要离开本网段。如果你用的是Cisco Packet Tracer或华为eNSP这类模拟器，创建三台PC和一台Hub、一台交换机，用直通线连好即可，连接方式跟真实设备没什么区别。

如果条件允许，我更建议在真实设备上做一遍。原因后面会专门讲，因为模拟器能模拟帧的转发路径，却模拟不了信号冲突时的真实物理表现。不过对大多数课程实验来说，先用模拟器把逻辑跑通，再找机会碰真机，是比较高效的学习路径。

2.2 抓包与查表：两个需要同时打开的观察窗口

要把转发行为看清楚，靠肉眼和ping命令远远不够。我的做法是同时在PC1、PC2、PC3上打开抓包工具，这样能看到同一个帧在不同端口上的不同命运。抓包工具首选Wireshark，启动之后选择对应的网卡接口，然后开始捕获。这里有一个非常重要的前提：必须把网卡设置成混杂模式，否则网卡默认会丢弃目的MAC不是自己的帧，你在PC3上就看不到Hub转发过来的无关单播帧了。

除了抓包，第二类观察手段是看交换机内部的MAC地址表。这是理解交换机能不能“定向转发”的最直接证据。不同厂商设备的命令略有差异，但思想一样，常见命令如下：

执行之后你会看到一张表格，里面有VLAN号、MAC地址、类型和端口等信息。第一次看这张表时，很多人会惊讶——原来交换机真的在偷偷记录每一台主机的“住址”。这张表就是你理解交换机“智能”的最直观物证，所以实验过程中我会在每次ping之后都执行一次查看命令，记录表项是否发生变化。

2.3 动手前先清理状态

实验刚开始我吃过一个亏：没有清理PC的ARP缓存和交换机的MAC地址表，结果做了好几轮测试，抓包结果前后不一致，自己还以为是设备出了问题。后来养成了固定习惯，每轮测试之前必须做三件清理工作。

首先在PC上打开命令行，执行arp -d清空ARP缓存，Windows和Linux都支持这个命令；接着在交换机上执行清空动态MAC表项的命令，确保交换机“失忆”；最后再盯一眼抓包软件，确认当前没有多余的历史流量干扰判断。清理完之后，再开始第一轮测试，得到的抓包数据才有对照意义。第2章的准备工作做完，才进入真正的对比实验。

3. 单播流量对照实验：先看集线器“无差别转发”的实锤

3.1 测试结果记录表

这个实验的做法是：让PC1去ping PC2，PC3边的Wireshark全程抓包，分别记录使用Hub和使用Switch时的结果。为了好对照，我给两种设备各跑了一组，记录结果如下：

Hub组的结果非常直白。PC1发出的每一个以太网帧，不管目的MAC是PC2还是别的谁，Hub都原封不动转发到PC3所在端口，所以PC3的抓包工具里能看到完整的ARP广播帧和后续所有ICMP单播帧。这正是Hub的典型特征：它把一个交换式网络退化成了“一根无形的共享总线”。从物理层还原的角度看，Hub只是把所有端口拼接在一起，让电信号到达每个端口，至于PC3是不是这些帧的真正目标，Hub完全不关心。

Switch组的结果就需要多解释一句。如果你第一次做实验，可能会看到PC3偶尔也能抓到一段ICMP流量，于是怀疑结论不对。其实这不是Switch坏了，而是MAC地址表还没学会PC2的位置，交换机把未知目的的单播帧也泛洪了出去。等到PC2回应过之后，交换机就已经记住了PC2的MAC地址对应的端口，后续正常的单播通信就不会再扩散到PC3了。

3.2 为什么第一次ping和后几次ping结果不一样

为了解释上面那种“时有时无”的现象，必须把第一次ping的过程拆开看。PC1第一次ping PC2时，IP层要先知道PC2的MAC地址，所以PC1会先发送一个ARP广播请求，询问“谁是192.168.1.2，请告诉我你的MAC地址”。这个ARP请求的目的MAC是全F的广播地址，交换机既不能确认目标，也没有学习过这个目的地址，就只能向除接收端口以外的所有端口泛洪，所以PC3此时能收到ARP广播。

当PC2收到ARP请求后，它会回一个ARP应答，把自己的MAC地址告诉PC1。这个应答是单播帧，源MAC是PC2，目的MAC是PC1。如果交换机已经通过之前的ARP请求学到了PC1的MAC在哪个端口，那么这个应答会被精确定向转发到PC1所在端口，PC3收不到。如果刚好PC1还没有被学到，交换机就只能继续泛洪。之后PC1发出ICMP Echo Request，目的MAC明确是PC2；只要交换机已经学到了PC2的MAC地址，这个单播帧就不会再出现在PC3上。

所以结论是：交换机对已经学习到的目的MAC是定向转发，只有目的MAC未知时才会泛洪；而Hub对所有帧一律全端口转发。这也是为什么很多实验报告会写“Switch第一次ping可能仍然泛洪，表象和Hub一样，但本质上一个是没学会，一个是根本没有学习能力”。这句话一定要写清楚，它是考官判断你有没有真正理解二层的金标准。

3.3 学会看MAC地址表

这一节做下来，最有趣的环节其实是实时查看交换机的MAC地址表。在PC1第一次ping PC2之后，我立刻在交换机上执行show mac address-table，会看到类似下面的内容：

第一行通常是PC1的MAC，第二行是PC2的MAC，第三行则可能来自PC3。PC3之所以会出现在表中，是因为PC3收到了ARP广播请求，它的网卡虽然会丢弃这个广播帧，但交换机在泛洪过程中已经把PC3的源MAC从对应端口学走了。这点很有趣：交换机学习源MAC和定向转发目的MAC是两件独立的事，任何从某个端口收到的帧的源MAC，都会让交换机更新这张表。

当时做实验时，PC3明明不是通信双方，交换机却知道PC3在哪，这个现象让我重新理解了交换机的“学习机制”：它不关心你是谁，只关心哪个源MAC从哪个口进来，然后默默登记。清空动态表项后再次ping，表又会一条一条长回来。这个过程动画感很强，建议每一组实验都做一次。

4. 广播与并发场景，区分两种设备的关键实验

4.1 广播帧处理：行为表面相似，出发逻辑完全不同

第二轮实验我建议换成广播流量，比如让PC1去ping一个当前网段中不存在的地址192.168.1.100，这样PC1会不断发送目的MAC为广播地址的ARP请求。处理广播帧时，Hub和Switch的表现看起来非常接近：Hub会把这个广播帧从所有其他端口发出去，Switch没有对应目的MAC可查，也会把广播帧从除接收端口外的所有端口转发出去，从外部看都是“全员收到”。

但要区分的恰恰是动机。Hub没有查表能力，它转发广播帧的逻辑和转发普通单播帧的逻辑是一样的，都只是物理信号的中继；Switch转发广播帧则是因为数据链路层的规则要求广播帧必须到达同一个广播域内的所有主机。如果给交换机划分了VLAN，广播帧只会在同一个VLAN内传播，而Hub没有任何办法做这种隔离，因为它根本不理解VLAN标签这类逻辑。

这个实验的价值在于提醒你：不能只凭“PC3收到了某帧”就判断设备是不是交换机。判断标准应该是：当目的MAC是明确且已知的单播地址时，交换机能不能把它精确定向转发到目标端口。如果一台交换机对着已知单播目的MAC还到处群发，那才是真正的异常。

4.2 同时传输：一个会冲突，一个各说各话

单播和广播测试都做完了，还差一个最能体现“工作方式差异”的测试：并发传输。我通常在真机环境下用大文件拷贝或者打流工具来做，模拟器里也可以用连续ping大包观察。操作很简单，让PC1和PC2之间传数据，同时让PC3和PC1之间也传数据，观察两种设备下的吞吐表现。

Hub环境下，因为所有端口共享同一条总线，且整个Hub只有一个冲突域，两个方向的流量会互相争抢。如果两个发送端同时开口，就会发生冲突，以太网协议检测到冲突后会让双方退避重传，实际吞吐会明显下降。你可以想象成几个人挤在一根旧电话线上同时说话，系统被迫反复喊“听不清，重来”。集线器时代CSMA/CD之所以重要，就是因为在共享介质上冲突无法避免。

交换机环境下，PC1和PC2的通信走交换机的两个端口，PC3和PC1的通信走另外两个端口，每个端口是独立的点到点链路。只要交换机背板处理能力够，这两路数据可以几乎同时进行，互不干扰。端口配置成全双工后，发送和接收还能同时发生，效率自然高出一大截。这个对照实验做完，你就能直观理解为什么当年的以太网要从“总线型共享介质”进化为“星型交换结构”。

4.3 报告里最值得写清楚的一张总结表

实验报告阶段，我觉得最值得放进去的是一张设备特性总结表。它能帮你把实验现象压缩成几个结论，也方便考前复习。表格内容大致如下：

这张表看起来简单，里面的每个结论都是从前面几轮实验里推出来的，不是靠背教材背出来的。比如“冲突域数量”，如果没做过并发传输实验，你很难理解为什么Hub是1个而Switch是每端口1个。一旦实际看到了冲突导致的吞吐下降，这个概念就不需要死记硬背了。

5. 实验报告阶段最容易误读的四个问题

5.1 “交换机也群发”不等于交换机是高级集线器

很多同学在PC3的抓包结果里看到ARP广播之后，会得出一个过于简单的结论：“交换机也不过是把帧发给所有人嘛，跟Hub一样。”这是实验报告里最常见的误读。实际上，交换机的泛洪只发生在两种情形：目的MAC未知，或者本身是广播/组播帧。对已经学习到的已知单播，交换机必然是定向转发的。要验证这一点，最直接的办法就是做第3章的第二个阶段：学完MAC地址表后再ping，观察PC3还能不能收到该帧。如果PC3收不到，说明交换机已经“记住”了目标端口；如果还能收到，那才需要进一步排查是不是设备配置出了问题或者有广播帧混在里面。

5.2 不要在Hub身上找IP和MAC逻辑概念

第二类误读是把太多“智能”赋予Hub，比如问“Hub知道PC3不该收这个帧吗？”答案是不知道，它甚至不关心以太网帧里的任何字段。Hub能够中继的只是电信号，它连“碰撞检测”都只在共享介质意义下发生，谈不上主动决策。排障时如果你听到有人说“这台Hub会过滤广播”，这几乎可以断定是错误的。Hub没有过滤能力，它也不具备地址表，任何试图从Hub上找到MAC学习逻辑的尝试都是徒劳的。

从这点出发，你可以反过来理解：一台设备要做出转发决策，至少要能读懂帧头；而Hub读不到，所以它的所有行为都停留在物理层。类似地，如果你在教学实验里看到一台设备既识别MAC又能划分VLAN，那它必然已经是交换机，而不是Hub。

5.3 模拟器里看不到的物理差异

在Packet Tracer这类模拟器里，Hub和Switch的转发逻辑表现得很清晰，但你也需要知道，有些物理层面的差异是模拟器看不出来的。比如集线器转发过程中会因为信号整形和再生带来延迟，交换机存储转发模式下也有内部处理延迟；但Hub环境下的冲突重传、单端口全双工状态的变化、端口指示灯随流量闪动的模式，这些现象需要真实设备才能观察。

做一个简单的真机观察：让PC1持续ping PC2，你去看Hub上的指示灯，会发现所有与PC相连的端口都在闪烁，因为每个帧都被发送到了所有端口；再看交换机，绝大多数时候只有PC1和PC2对应的端口指示灯在闪。这个视觉印象比十页文字都更能说明问题。如果实验室有支持接口统计的旧款Hub或交换机，还可以在接口下查看累积的冲突计数、CRC校验错误等数据，这些是真实以太网物理特性的体现，模拟器无法复现。

5.4 性能差距不是端口速率决定的

还有一类说法是“交换机比Hub快，是因为交换机端口速率更高”，这也不准确。当你把Hub和Switch的端口都设为同一速率时，性能依然有巨大差异，原因在于工作方式：Hub让所有端口争抢同一个冲突域，实际可用带宽会随着接入主机增多、流量增大而快速恶化；交换机则通过端口独立交换让多路通信并发执行。

交换机也不是完全没有瓶颈，它受限于背板带宽、交换矩阵的容量和缓冲内存。比如一台低端桌面交换机标称百兆端口，如果多个端口同时全速收发，总流量超过了背板处理能力，也会出现丢包。但这是另一个层面的资源限制问题，相比Hub把整个设备变成一个冲突域已经先进太多。写报告时如果能体现出这层理解，说明你真的做到了“知其所以然”。

6. 从实验台往外走：安全隔离和现网排障

6.1 “所有人都听得见”带来的安全问题

Hub最令人头疼的问题除了性能，还有安全。由于它把每个帧都转发到所有端口，整个冲突域里的任何一台PC如果开启了抓包工具的混杂模式，都可能看见别人的通信内容。早在明文协议流行、还没有普遍加密的年代，用Hub组网的局域网里，抓包工具能轻易还原出别人的账号密码，这不是什么高深黑客技巧，只是网络结构本身把所有数据“广播”了出去。

交换机天然把已知单播限制在源和目的端口之间，所以普通主机默认情况下收不到别人的单播流量，降低了被动监听的风险。但这不代表交换机网络绝对安全，地址欺骗、ARP欺骗、端口镜像等威胁依然存在。后面学到VLAN、端口安全、DHCP Snooping时会进一步看到，安全隔离是二层设备功能演进的重要驱动力。写到这里我想强调，做网络实验时抓包看到的那些数据可能是别人的明文信息，只应在自己搭的实验环境里使用，遵守实验规范和安全伦理是基本功。

6.2 现网里混入集线器或错误设备后的现象

把实验结论和现网故障联系起来，是让知识落地的好方法。实际网络中已经很少见到纯粹的Hub，但偶尔会有“把普通交换机当Hub用”的错误组网，比如为了节省端口或者图省事，将交换机一个端口同时并联多台PC，这就相当于把一个交换机端口人为变成了共享式Hub端口，冲突和带宽争用的问题会随之出现。

更危险的是，如果某台设备被错误地以Hub方式接入并构成了物理环路，而它本身不具备STP生成树协议能力，广播帧就会在环路里不断循环放大，最终形成广播风暴，把整个二层网络打瘫。这也是为什么现代交换机大多默认启用STP的原因之一。第6章这些内容已经从“Hub和Switch工作原理”延伸到组网设计，但我觉得实验报告里用一两句话点一下“为什么淘汰Hub”，比单纯罗列差异更有价值。

6.3 一个每次实验结束我都会做的事

最后分享一个我个人坚持的小习惯，做完这个实验之后你也可以试试。每次实验结果记录完毕，我会把交换机的动态MAC地址表清空，然后重新发起一次单播通信，同时在三台PC上各开一个抓包窗口，观察同一帧从发出到到达的目标端口，中间经历了怎样的过程。清空之前先截图保存，清空后再截一次，两张图对比下来，交换机的“学习过程”会变得特别直观。

具体操作很简单：先在交换机上执行清空动态表项的命令，然后去PC1上ping一下PC2，紧接着马上回到交换机查看MAC表，你会发现表里新增了PC1和PC2的两条记录。这个动作每重新做一次，就是一次完整的“源MAC学习加目的MAC定向转发”的全过程回放。长期积累下来，这种动手验证带来的理解深度，比单纯读完教材里的原理要扎实得多。