Hub集线器、Switch交换机、三层设备
Hub集线器
集线器是早期以太网（如10Base-T）中最基础的网络连接设备，工作在OSI模型的物理层。它的核心功能可以概括为：信号放大与广播。
核心工作原理
-
信号接收与整形（放大）
- 当集线器某个端口接收到来自连接设备（如电脑）发送来的电信号时，由于信号在网线上传输会有衰减和失真，集线器会首先将这个微弱的信号放大和整形，恢复成标准、清晰的信号。
-
广播式转发
- 这是集线器最关键的特征。它并不识别数据内容，也不关心数据包的目的地址。
- 信号被放大整形后，集线器会将其复制，然后发送到除信号来源端口之外的所有其他端口。
- 例如，连接在端口1的电脑A发送数据，集线器会把这个数据包广播到端口2、端口3、端口4……所有连接的其他设备都会收到这个数据包。
-
冲突域共享
- 由于所有端口共享同一个通信信道，并且采用“半双工”模式（同一时间只能发送或接收），当两个或更多设备同时发送数据时，就会发生信号冲突，导致数据损坏。
- 集线器本身无法处理冲突，它只是简单地传输信号。检测和处理冲突的任务由连接设备上的网卡来完成（采用CSMA/CD协议）。
- 整个集线器网络（包括所有连接设备）属于同一个“冲突域” 。设备越多，发生冲突的概率越大，网络效率越低。
Switch交换机
交换机工作在OSI模型的数据链路层（第二层） ，因此它能够处理数据帧，并基于MAC地址进行智能转发。
三层设备
纯路由器 + 三层交换机
核心工作原理：三个关键功能
交换机的工作原理可以概括为三个核心动作：学习、转发/过滤、避免环路。
-
学习 - 构建MAC地址表
交换机内部维护着一个 MAC地址表（或叫CAM表）。这张表记录了 MAC地址 与交换机端口号的对应关系。
-
初始状态：交换机刚启动时，MAC地址表是空的。
-
学习过程：
- 当一个数据帧从某个端口进入交换机时，交换机会查看该帧的源MAC地址。
- 然后，交换机会将这个 源MAC地址 和 该帧进入的端口号 作为一个条目记录到MAC地址表中，并设置一个老化时间（通常为5分钟）。
- 关键点：交换机是通过观察数据帧的源地址来学习的，而不是目的地址。
-
-
转发与过滤 - 智能决策
当交换机需要转发一个数据帧时，它会查看该帧的目的MAC地址，并查询MAC地址表，做出以下三种决策之一：
-
单播转发：
- 如果MAC地址表中查找到了该目的MAC地址对应的端口。
- 并且这个端口不是该帧的源端口。
- 动作：交换机会将数据帧仅从那个特定的目标端口转发出去。这实现了点对点通信，其他端口上的设备收不到这个帧。这个过程称为“过滤”，即只转发到需要的端口。
-
广播/组播（泛洪） ：
- 如果数据帧的目的MAC地址是广播地址（全F，即FF:FF:FF:FF:FF:FF）。
- 或者是一个组播地址，且交换机未启用相关优化功能。
- 或者，如果目的MAC地址在MAC地址表中查找不到（未知单播帧）。
- 动作：交换机会将这个数据帧从除源端口之外的所有其他端口发送出去。这个过程称为“泛洪”。其目的是确保信息能被目标设备收到（目标设备收到后会回应，从而让交换机学习到它的位置）。
-
丢弃：
- 如果数据帧的目的MAC地址在MAC地址表中对应的端口，正好就是该帧的源端口（即发送者和接收者在同一个端口，这通常意味着它们连接在同一个Hub上，而Hub又连到了交换机这个端口）。
- 动作：交换机会丢弃这个帧，因为没必要转发回去。
-
二层数据发送示例
环路风暴
环路风暴出现的根本原因：交换机在收到数据帧时，会覆盖端口到mac地址的映射：端口xx<-->mac地址xx，即学习到如果要发送目标帧为mac地址xx的数据帧，应该走端口xx。
1 A 2
/ \
1 2
B 2 ----- 1 C
3 3
/ \
PC1 PC2
交换机初始MAC地址表（都为空）：
A: MAC表={}
B: MAC表={}
C: MAC表={}
连接关系：
A-1 ↔ B-1
A-2 ↔ C-2
B-2 ↔ C-1
B-3 ↔ PC1
C-3 ↔ PC2
此时，如上拓扑结构，PC1发送数据，不知道PC2的mac地址
1. PC1发送数据，B做转发
B-MAC表中未记录PC2-MAC，只能选择广播
B1 --> A1，B2 --> C1
A: MAC表={ A1 <--> PC1-MAC } B-MAC表={ B3 <--> PC1-MAC } C: MAC表={ C1 <--> PC1-MAC }
2. A-MAC表中未记录PC2-MAC，只能选择广播
A-->C
C-MAC表中未记录PC2-MAC，只能选择广播
C-->B、C-->PC2
A: MAC表={ A1 <--> PC1-MAC } B-MAC表={ B3 <--> PC1-MAC } C: MAC表={ C2 <--> PC1-MAC }
PC2收到PC1的数据，且确认目标mac为PC2-MAC，消息收到
3.
阶段一：初始ARP请求（引发环路）
步骤1：PC1发送ARP请求
-
PC1 要发送数据给PC2 (
192.168.1.20) -
PC1检查ARP缓存，没有PC2的MAC地址
-
PC1构造ARP广播请求：
帧头： - 目标MAC: FF:FF:FF:FF:FF:FF (广播地址) - 源MAC: AA:AA:AA:AA:AA:AA (PC1) ARP数据： - 谁有IP 192.168.1.20? 请告诉 192.168.1.10
步骤2：SW2收到ARP广播帧（开始环路）
SW2收到帧（从P3端口）：
- SW2学习：MAC AA:AA:AA:AA:AA:AA 在端口P3 ✓
- SW2 MAC表: {AA:AA:AA:AA:AA:AA: P3}
- 这是广播帧，所以泛洪到除接收端口(P3)外的所有端口：P1, P2
SW2从P1转发到SW1-P1
SW2从P2转发到SW3-P2
步骤3：帧到达SW1和SW3
SW1从P1收到帧：
text
复制下载
- SW1学习：MAC AA:AA:AA:AA:AA:AA 在端口P1 ✓
- SW1 MAC表: {AA:AA:AA:AA:AA:AA: P1}
- 广播帧，泛洪到除P1外的所有端口：P2
- SW1从P2转发到SW3-P1
SW3从P2收到帧（来自SW2-P2）：
text
复制下载
- SW3学习：MAC AA:AA:AA:AA:AA:AA 在端口P2 ✓
- SW3 MAC表: {AA:AA:AA:AA:AA:AA: P2}
- 广播帧，泛洪到除P2外的所有端口：P1, P3
- SW3从P1转发到SW1-P2
- SW3从P3转发到PC2（PC2收到并处理ARP请求）
步骤4：PC2回复ARP（正常部分）
text
复制下载
PC2收到ARP请求后回复：
帧头：
- 目标MAC: AA:AA:AA:AA:AA:AA (PC1)
- 源MAC: BB:BB:BB:BB:BB:BB (PC2)
ARP数据：
- IP 192.168.1.20 的MAC是 BB:BB:BB:BB:BB:BB
PC2的单播回复会正常到达PC1（因为MAC表已部分建立），但这不是环路的主要来源。
阶段二：广播风暴的形成
环路开始（关键步骤）：
从SW3-P1转发到SW1-P2的帧：
text
复制下载
SW1从P2收到帧（来自SW3-P1）：
- SW1检查源MAC: AA:AA:AA:AA:AA:AA
- SW1发现：AA:AA:AA:AA:AA:AA 已经在端口P1学习到了！
- SW1更新MAC表（错误地）：AA:AA:AA:AA:AA:AA: P2 ✓
- 广播帧，泛洪到除P2外的所有端口：P1
- SW1从P1转发到SW2-P1 ← 又回到SW2！
环路循环过程（风暴形成）：
循环路径1：SW1↔SW2↔SW3↔SW1
text
复制下载
时间线：
T0: PC1→SW2→(P1)SW1→(P2)SW3→(P1)SW1 （环路开始）
T1: SW1→(P1)SW2→(P2)SW3→(P1)SW1→(P1)SW2...
循环路径2：SW2↔SW3直接环路
text
复制下载
T0: PC1→SW2→(P2)SW3→(P2)SW2 （另一个环路）
T1: SW2→(P2)SW3→(P2)SW2→(P2)SW3...
MAC表混乱（持续更新）：
text
复制下载
SW1的MAC表在P1和P2间反复跳动：
时间 端口 原因
T0 P1 来自PC1的原始帧
T1 P2 从SW3-P1来的环路帧
T2 P1 从SW2-P1来的环路帧
... 循环...
SW2类似：
T0 P3 来自PC1的原始帧
T1 P1 从SW1-P1来的环路帧
T2 P2 从SW3-P2来的环路帧
... 循环...
SW3类似：
T0 P2 来自SW2-P2的帧
T1 P1 来自SW1-P2的帧
... 循环...
阶段三：广播风暴的爆发
现象：
-
指数级帧复制：
- 每个交换机每次收到广播帧都复制到2个端口
- 每循环一圈，帧数量翻倍
- 3个交换机环路 → 快速形成指数增长
-
网络资源耗尽：
text
复制下载
初始：1个广播帧 第1圈：变成3-4个帧 第2圈：变成8-12个帧 第3圈：变成20-30个帧 ...几分钟后：数千/秒 -
MAC表震荡：
- 源MAC AA:AA:AA:AA:AA:AA 在不同端口间疯狂跳动
- 交换机无法稳定学习MAC地址
- 即使单播帧也可能被泛洪
最终结果：
-
CPU过载：交换机CPU忙于处理广播帧
-
带宽饱和：所有链路被广播帧占满
-
正常通信中断：
- PC2的ARP回复可能无法到达PC1
- 即使到达，后续数据帧也会被错误泛洪
-
可能的硬件损坏：长期风暴导致设备过热
阶段四：如果有数据帧（不只是ARP）
如果PC1发送真实数据帧到PC2：
text
复制下载
目标MAC: BB:BB:BB:BB:BB:BB (PC2)
源MAC: AA:AA:AA:AA:AA:AA (PC1)
情况会恶化：
- 未知单播泛洪：如果MAC表混乱，即使目标MAC已知，也可能被当作未知单播而泛洪
- 多播风暴：如果涉及多播，情况类似
- 混合风暴：广播+未知单播+可能的多播
经典场景示例
- 主机A: IP =
192.168.1.2, MAC =AA-AA-AA-AA-AA-AA - 主机B: IP =
192.168.1.3, MAC =BB-BB-BB-BB-BB-BB - 目标：主机A想要Ping通主机B。
第一步：检查ARP缓存
主机A在发送数据前，会先查询自己的 本地ARP缓存表（一个IP-MAC对应表）。
- 如果找到
192.168.1.3对应的MAC地址，则直接使用该地址封装帧，发送数据。 - 如果没找到（首次通信时必然如此），则启动ARP解析过程。
第二步：发送ARP请求（广播）
-
主机A会构造一个 ARP请求包。
- 发送方IP/MAC:
192.168.1.2/AA-AA-AA-AA-AA-AA - 目标方IP:
192.168.1.3 - 目标方MAC:
00:00:00:00:00:00(全0，表示未知)
- 发送方IP/MAC:
-
主机A将这个ARP请求包封装在一个以太网广播帧中。
- 目的MAC地址:
FF:FF:FF:FF:FF:FF(广播地址) - 源MAC地址: 自己的
AA-AA-AA-AA-AA-AA
- 目的MAC地址:
-
主机A将这个广播帧发送到网络中。
关键点：由于是广播帧，同一个广播域内的所有主机和交换机都会收到它。
第三步：处理ARP请求（各主机）
-
交换机收到广播帧，会将其泛洪到所有端口（除了源端口）。
-
每台主机（包括主机B）的网卡收到这个广播帧后，都会拆包并查看内部的ARP请求。
-
每台主机将请求中的 “目标方IP” 与自己的IP地址比较：
- 主机B：发现“目标方IP (
192.168.1.3) == 我的IP”，于是它需要回复。 - 其他主机（如C、D）：发现IP不匹配，则安静地丢弃这个ARP请求包。
- 主机B：发现“目标方IP (
第四步：发送ARP回复（单播）
-
主机B构造一个 ARP回复包。
- 发送方IP/MAC:
192.168.1.3/BB-BB-BB-BB-BB-BB(这正是A想要的信息) - 目标方IP/MAC:
192.168.1.2/AA-AA-AA-AA-AA-AA(直接抄A请求里的信息)
- 发送方IP/MAC:
-
主机B将这个ARP回复包封装在一个以太网单播帧中。
- 目的MAC地址:
AA-AA-AA-AA-AA-AA(直接发给A) - 源MAC地址: 自己的
BB-BB-BB-BB-BB-BB
- 目的MAC地址:
-
主机B将这个单播帧发送出去。
关键点：由于此时B已经知道A的MAC地址，所以回复是点对点的单播，不再是广播。交换机根据MAC地址表，会将此帧智能地转发到主机A所在的端口。
第五步：接收回复并更新缓存
- 主机A收到ARP回复包。
- 主机A从回复包中提取出关键信息：IP
192.168.1.3-> MACBB-BB-BB-BB-BB-BB。 - 主机A将这对映射关系添加到自己的本地ARP缓存表中，并设置一个老化时间（通常为2-20分钟）。超过时间未使用，该条目会被删除，以保证网络变化时的准确性。
- 现在，主机A知道了主机B的MAC地址，它可以成功地将原始的Ping请求（ICMP包）封装成帧，发送给主机B。
注意事项
- 使用场景：ARP协议虽然是局域网内的Mac寻址，但在现代网络拓扑中，大部分跨子网的通信都通过网关，局域网内设备间的直接通信（如文件共享、打印机访问）反而比例较低。因此跨网段通信时，最后一跳：网关将公网数据转发至子网内指定设备，才是ARP协议最频繁、最关键的作用
- 安全问题：ARP协议本身没有任何身份验证机制。攻击者可以伪造并发送大量的虚假ARP回复包，声称“IP X 的MAC地址是 YY-YY...”（而这个YY-YY是攻击者的MAC）。这会导致网络中的其他主机更新错误的ARP缓存，将本该发往合法主机的流量发送给攻击者，从而实现中间人攻击或网络瘫痪。
ARP协议 & STP协议
在数据链路层（二层）进行通信，必须使用MAC地址，但应用程序和操作系统使用的是IP地址（三层）。此时如果要完成数据包的发送，必须有一种规范，用于在同一局域网内，通过已知的IP地址来解析其对应的MAC地址，即ARP协议。
STP协议
三层设备数据发送流程
┌─────────────┐
│ 路由器 │
│ (三层设备) │
│ 接口1: 192.168.1.1/24 ←─ 这是PC1的网关 │
│ 接口2: 192.168.2.1/24 ←─ 这是PC2的网关 │
└──────┬──────┘
│ (路由器有两个接口)
┌──────────┴──────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 交换机A │ │ 交换机B │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
PC1: 192.168.1.10/24 PC2: 192.168.2.20/24
网关: 192.168.1.1 网关: 192.168.2.1
↑ ↑
PC1的网关 PC2的网关
场景设定：
- PC1 上的一个应用程序（如 Web 浏览器）要访问 PC2 上的 Web 服务。
- PC1 (客户端)：IP
192.168.1.10， 使用随机端口54321发起连接。 - PC2 (服务器)：IP
192.168.2.20， Web 服务监听在TCP 80端口。
第一步：应用层发起请求
- PC1 上的用户输入
http://192.168.2.20或类似地址。 - 应用程序决定使用 TCP 协议，并分配一个 源端口
54321。目标端口明确为80。 - 应用程序将 HTTP 请求数据交给 TCP 模块。
第二步：网络层封装与判断
- TCP 模块构建 TCP 报文段，其中：
- 源端口：
54321 - 目标端口：
80 - 设置 SYN 标志（假设是新建连接）等。
- 源端口：
- TCP 报文段交给 IP 层。IP 层构建 IP 数据包，其中：
- 源 IP：
192.168.1.10 - 目标 IP：
192.168.2.20
- 源 IP：
- IP 层判断目标 IP 与自身不在同一网段，因此将数据包发往默认网关
192.168.1.1。
第三步：数据链路层封装与第一段传输
- 数据链路层需要网关
192.168.1.1的 MAC 地址（通过 ARP 获取，假设为R-MAC1）。 - 封装成第一个以太网帧（从 PC1 到路由器接口1）：
- 目标 MAC：
R-MAC1 - 源 MAC：
PC1-MAC - 承载的数据包内部：
- 目标 IP：
192.168.2.20， 源 IP：192.168.1.10（不变） - 目标端口：
80， 源端口：54321（不变）
- 目标 IP：
- 目标 MAC：
- 交换机A根据 MAC 地址转发该帧至路由器。
第四步：路由器路由与转发
- 路由器在接口1收到帧，解封装后看到 IP 数据包。
- 查询路由表，得知
192.168.2.0/24网段直连接口2。 - 关键：路由器操作在网络层。它不会修改 IP 数据包内部的 TCP 端口号（那是传输层信息），只会根据 IP 地址进行路由。
- 路由器将 IP 数据包从接口2转发出去。
第五步：重新封装与第二段传输
- 路由器需要为这个 IP 数据包封装新的帧头。它通过 ARP 查询
192.168.2.20的 MAC 地址（假设为PC2-MAC）。 - 封装成第二个以太网帧（从路由器接口2到 PC2）：
- 目标 MAC：
PC2-MAC - 源 MAC：
R-MAC2（路由器接口2的MAC） - 承载的数据包内部（与第8步完全一致）：
- 目标 IP：
192.168.2.20， 源 IP：192.168.1.10 - 目标端口：
80， 源端口：54321
- 目标 IP：
- 目标 MAC：
- 交换机B根据 MAC 地址转发该帧至 PC2。
第六步：目标主机处理
- PC2 收到以太网帧，解封装后得到 IP 数据包。
- IP 层检查目标 IP
192.168.2.20与本机匹配，将数据包载荷（TCP 报文段）上交至传输层（TCP模块）。 - TCP 模块根据目标端口
80来解复用。它发现端口80正被 Web 服务监听。 - TCP 模块将数据（如 SYN 请求）交给监听在
80端口的 Web 服务器应用程序进程处理。
总结与要点：
- 全程不变的“四元组”：整个跨网段通信过程中，源IP、目标IP、源端口、目标端口 这个四元组在 IP 数据包和 TCP 报文段中始终保持不变。这是端到端通信的唯一标识，确保了数据能准确到达目标主机上的正确应用程序。
- MAC地址逐跳变化：每经过一个网段（一个广播域），数据帧的源MAC和目标MAC都会改变，它们标识的是当前链路上的“下一跳”设备。
- 路由器的角色：
- 注意：这里是纯路由器，不是NET路由器，不会进行网络地址转换。
- 它工作在网络层（第三层）。
- 它根据IP地址进行路由决策。
- 它不关心也不修改传输层的端口号。端口号是端系统（PC1和PC2）的传输层用来区分不同应用程序的。
- 端口号的作用：仅在最终的目标主机（PC2）上发挥关键作用。目标主机的传输层通过 目标端口号（本例中的
80）来确定应该将接收到的数据交付给哪个正在等待的应用程序进程。同样，源端口号使得 PC2 的回复能够准确返回给 PC1 上发起请求的那个特定应用程序。
