网络通信中的常见硬件设备及其工作层次。
1. 全景拓扑:数据包从互联网到你的工位
先看一张典型企业网全景图,自上而下就是外网流量进入园区、到达服务器/终端的路径,本文所有设备都能在上面找到位置:
Internet │ ┌─────────┴─────────┐ │ 出口路由器 │ ← 跨网路由、NAT(L3,隔离内外广播域) └─────────┬─────────┘ ┌─────────┴─────────┐ │ 防火墙 │ ← 安全边界(L3~L7 访问控制) └─────────┬─────────┘ ┌─────────┴─────────┐ │ 核心三层交换机 │ ← 园区骨干(万兆互联,L2+L3) └────┬──────────┬───┘ ┌───────┴───┐ ┌───┴─────────┐ │ 汇聚交换机 │ │ 负载均衡器 │ ──▶ 服务器池(Web/APP/DB) └─────┬─────┘ └─────────────┘ ┌─────┴─────┐ │ 接入交换机 │ ← 终端就近接入(百兆/千兆到桌面) └─┬───┬───┬─┘ PC PC AP(无线接入点)对照速记:路由器管"去哪儿",交换机管"哪个口",防火墙管"能不能去",负载均衡管"该谁去"。Hub/中继器已基本淘汰,只在下方冲突域对比图中出镜。
2. 设备一览
| 设备 | 工作层 | 功能 | 冲突域 | 广播域 |
|---|---|---|---|---|
| 集线器(Hub) | L1 | 广播信号 | 不隔离 | 不隔离 |
| 中继器(Repeater) | L1 | 信号放大 | 不隔离 | 不隔离 |
| 交换机(Switch) | L2 | 按 MAC 转发 | 隔离 | 不隔离 |
| 网桥(Bridge) | L2 | 连接两网段 | 隔离 | 不隔离 |
| 路由器(Router) | L3 | 按 IP 路由 | 隔离 | 隔离 |
| 三层交换机 | L2+L3 | MAC 转发+IP 路由 | 隔离 | 隔离 |
| 网关(Gateway) | L7 | 协议转换 | — | — |
| 防火墙(Firewall) | L3~L7 | 访问控制 | — | — |
| 负载均衡器 | L4~L7 | 流量分发 | — | — |
专家视角:冲突域和广播域是理解网络设备的核心概念。Hub 不隔离任何域(所有端口一个冲突域),交换机隔离冲突域但广播帧仍全转发(一个广播域),路由器隔离广播域(不转发 255.255.255.255)。VLAN 是交换机内虚拟隔离广播域的技术。
三张图看懂"域"的隔离差异:
① Hub —— 不隔离任何域 PC1 ─┐ ┌──────────────────────────────┐ PC2 ─┼── [ Hub ] │ 1 个冲突域 = 1 个广播域 │ PC3 ─┤ PC1→PC2 的帧, │ 所有端口共享总线、抢着发 │ PC4 ─┘ PC3/PC4 也能收到 └──────────────────────────────┘ ② Switch —— 隔离冲突域,不隔离广播域 PC1 ─┐ ┌──────────────────────────────┐ PC2 ─┼── [ Switch ] │ 4 个冲突域(全双工无碰撞) │ PC3 ─┤ 单播帧按 CAM 表 │ 1 个广播域 │ PC4 ─┘ 精准转发; │ → 广播帧仍泛洪到所有端口 │ ARP/DHCP 广播 │ → VLAN(802.1Q)才能切分 │ 仍全网泛洪 └──────────────────────────────┘ ③ Router —— 广播域也隔离 [ Switch A ] ──── [ Router ] ──── [ Switch B ] 广播域 A ↑ 广播域 B 广播(如 ARP 请求)到路由器为止,不再转发3. 交换机深度
3.1. 工作原理
- 学习:收到帧,记录源 MAC → 端口映射到 CAM 表
- 转发:查目的 MAC,命中则单播转发,未命中则泛洪(除入端口外全转发)
- 老化:CAM 表条目定期老化(默认 300s)
一图看懂三步(PC1 想发帧给 PC3):
① 学习:帧从哪来,就记谁 ② 转发:目的 MAC 怎么走 PC1 ══ 帧(源=MAC1) ══▶ 端口1 命中 CAM 表 → 单播精准发出 │ PC1 ──帧(目的=MAC3)──▶ [Switch] ──▶ 仅端口3发出 ▼ CAM 表 += { MAC1 → 端口1 } 未命中 → 泛洪(未知单播当广播处理) PC1 ──帧(目的=未知)──▶ [Switch] ──▶ 除端口1外全发 ③ 老化:300s 无新流量 ⇒ 删除条目 (终端换了端口/网卡,旧条目不会一直指错方向) 端口1 端口2 端口3 │ │ │ PC1 PC2 PC33.2. 关键特性
| 特性 | 说明 |
|---|---|
| 全双工 | 每端口独享带宽,无 CSMA/CD |
| 自协商 | 端口速率/双工模式自动协商 |
| VLAN | 802.1Q 标签隔离广播域 |
| STP | 生成树协议防环路(802.1D) |
| 链路聚合 | LACP 多链路捆绑(802.3ad) |
| 镜像 | 端口镜像用于抓包分析 |
3.3. CAM 表 vs 路由表
| 对比 | CAM 表(交换机) | 路由表(路由器) |
|---|---|---|
| 键 | MAC 地址 | IP 网段 |
| 值 | 物理端口 | 下一跳 IP + 出接口 |
| 学习 | 自动学习(源 MAC) | 路由协议/静态配置 |
| 规模 | 数千~数万 | 数万~数十万 |
4. 路由器深度
4.1. 工作原理
- 收到 IP 包,查路由表最长前缀匹配
- TTL 减 1,TTL=0 则丢弃并发 ICMP协议 Time Exceeded
- 重组帧(改目的 MAC 为下一跳的 MAC),从出接口转发
逐跳转发图(IP 端到端不变,MAC 每跳重写,TTL 每跳递减):
PC1 R1 R2 Server 10.1.1.2 10.1.1.1 / 10.3.3.1 10.3.3.2 / 10.2.2.1 10.2.2.2 │ │ │ │ │ ①帧[MAC-A→MAC-B]│ │ │ ├───────────────▶│ 查路由表(最长前缀匹配 10.2.2.0/24) │ │ │ ②TTL: 64→63;改帧[MAC-C→MAC-D] │ │ ├───────────────────▶│ ③TTL: 63→62;改帧[MAC-E→MAC-F] │ │ ├─────────────────▶│ ▼ ▼ ▼ ▼ IP 头(全程不变):源 10.1.1.2 ──────────────────────────▶ 目的 10.2.2.2 MAC 帧(每跳重写):每段链路只填"本段的下一跳" MAC TTL:64 →(R1) 63 →(R2) 62 (减到 0 = 丢弃 + 回 ICMP Time Exceeded)4.2. 路由协议
| 协议 | 类型 | 说明 |
|---|---|---|
| RIP | 距离向量 | 跳数≤15,已淘汰 |
| OSPF | 链路状态 | 企业内网标配,区域分层 |
| IS-IS | 链路状态 | ISP 骨干网常用 |
| BGP | 路径向量 | 互联网骨干路由协议 |
专家视角:BGP 是互联网的"政治协议"——它不仅选最短路径,还按AS 路径策略路由(政治/商业考量)。BGP 配置错误可导致全球级故障(如 2021 Facebook 6 小时宕机,BGP 撤回路由导致 DNS 无法解析)。
5. 防火墙
5.1. 代类型
| 类型 | 工作层 | 说明 |
|---|---|---|
| 包过滤 | L3/L4 | 按 IP/端口/协议过滤 |
| 状态检测 | L3/L4 | 维护连接状态表,只放行已建立连接 |
| 应用层 | L7 | 深度包检测(DPI),识别应用协议 |
| 下一代(NGFW) | L3~L7 | 集成 IDS/IPS/AV/URL 过滤 |
6. 负载均衡器
| 类型 | 工作层 | 典型 |
|---|---|---|
| L4 LB | 传输层 | LVS、AWS NLB |
| L7 LB | 应用层 | Nginx、HAProxy、AWS ALB |
| Global LB | DNS/Anycast | AWS Route53、Cloudflare |
专家视角:L4 vs L7 负载均衡的核心区别——L4 只看 IP+端口,转发快但不感知 HTTP 语义(无法按 URL/Cookie 分流);L7 解析 HTTP,可按路径/头部/会话分流,但需解 HTTP 协议(TLS 终止开销)。
防火墙与负载均衡器在数据中心南北向流量中的典型部署位置:
Internet(用户请求 https://…) │ ┌──────┴──────┐ │ 路由器/BGP │ ← 接入运营商,宣告公网 IP └──────┬──────┘ ┌──────┴──────┐ │ 防火墙 NGFW │ ← 只放行 443;拒绝其余(L3~L7 策略) └──────┬──────┘ ┌──────┴──────┐ │ 负载均衡器 │ ← L7:按 URL/Cookie 分流(本例) └─┬───┬───┬──┘ │ │ │ ↘ /api ──▶ APP 服务器组 ┌───┴┐ ┌┴───┐ ┌┴───┐ ↘ /img ──▶ 缓存/CDN 回源 │SVR1│ │SVR2│ │SVR3│ ↘ 其余 ──▶ Web 服务器组 └────┘ └────┘ └────┘ (后端服务器池:健康检查剔除故障节点)7. SDN(软件定义网络)
传统网络:控制平面(路由协议)+ 数据平面(转发)耦合在设备内。
SDN:控制平面集中到 SDN 控制器,设备只保留数据平面。
传统网络:每台设备自带"大脑+手脚" SDN:大脑上收集中,设备只留手脚 ┌───────────────┐ ┌───────────────┐ ┌────────────────────┐ │ 交换机/路由器 │ │ 交换机/路由器 │ │ SDN 控制器 │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ (集中算路/全局视图) │ │ │ 控制平面 │ │ │ │ 控制平面 │ │ └──┬──────┬──────┬──┘ │ │ (OSPF/BGP) │ │ │ │(OSPF/BGP) │ │ OpenFlow│ │ │ (南向接口) │ └───────────┘ │ │ └───────────┘ │ ▼ ▼ ▼ │ ┌───────────┐ │ │ ┌───────────┐ │ ┌────┐ ┌────┐ ┌────┐ │ │ 数据平面 │ │ │ │ 数据平面 │ │ │ SW │ │ SW │ │ SW │ ← 只按流表转发 │ └───────────┘ │ │ └───────────┘ │ └────┘ └────┘ └────┘ └───────────────┘ └───────────────┘ 各自为战,CLI 逐台配置 全网一次编排,策略统一下发| 组件 | 说明 |
|---|---|
| SDN 控制器 | 集中计算转发表,下发到设备 |
| OpenFlow | 控制器↔设备南向接口协议 |
| 数据平面 | 设备按流表转发 |
专家视角:SDN 的价值是网络可编程——用软件定义转发策略,而非逐设备 CLI 配置。但在企业落地缓慢,因为改变运维模式比技术更难。云厂商内部全量 SDN(AWS VPC、阿里云 VPC),因为云网络必须 API 驱动。
8. 拓扑演进:三层架构 vs Spine-Leaf
三层架构(园区网主流) Spine-Leaf(数据中心主流) [核心 Core] Spine1 Spine2 Spine3 / \ / | \ / | \ / | \ [汇聚] [汇聚] / | \ / | \ / | \ / \ / \ Leaf1 Leaf2 Leaf3 … LeafN [接入][接入] [接入][接入] (每个 Leaf 与所有 Spine 全交叉互联) 终端PC/打印机/AP (服务器全部接在 Leaf 下) 垂直层级清晰、省链路 任意两台服务器恒定 2 跳 但跨层存在收敛阻塞点 无阻塞(等价多路径 ECMP) 适合南北向流量为主(上网) 适合东西向流量为主(服务器互访)推断:云厂商 VPC 的"交换架构"本质上是 Spine-Leaf 思想的软件化延伸(叠加网络/VXLAN 封装实现租户隔离),待验证。