什么是 VPC？从传统网络、VLAN、VRF 到云数据中心 Overlay 的完整解析
1. VPC 到底是什么？
VPC，全称：
Virtual Private Cloud，虚拟私有云
最简单的理解是：
VPC 是云厂商在一张共享的物理数据中心网络之上，为某个租户构造出来的一张逻辑隔离的三层网络。
例如，在传统数据中心里，你可能自己搭建这样一张网络：
到了云上，你不再购买：
- Router
- Firewall
- Core Switch
- Access Switch
而是在云控制台中创建：
VPC: 10.0.0.0/16
然后定义：
Subnet-A: 10.0.1.0/24
Subnet-B: 10.0.2.0/24
Subnet-C: 10.0.3.0/24
再配置：
Route Table
Security Group
NAT Gateway
Internet Gateway
VPN Gateway
Load Balancer
...
最终获得的逻辑效果，和自己建设一张企业网络非常相似。
AWS 官方将 VPC 描述为用户定义的、逻辑隔离的虚拟网络；阿里云也将 VPC 定义为用于部署云资源的安全、隔离虚拟网络。
2. 为什么需要 VPC？
理解 VPC 最重要的问题不是：
VPC 是什么？
而是：
为什么公有云一定需要 VPC？
假设腾讯、阿里、AWS 建了一个数据中心：
服务器、交换机、光纤都是云厂商自己的。
但是数据中心中可能同时存在：
客户 A
客户 B
客户 C
客户 D
客户 E
...
例如：
Alibaba Cloud Physical Network
|
+------------+------------+
| | |
Customer A Customer B Customer C
问题来了：
客户 A 需要：
10.0.0.0/8
客户 B 也可能需要：
10.0.0.0/8
客户 C 还是可能需要：
10.0.0.0/8
在传统 IP 网络中显然会发生地址冲突。
因此云网络必须做到：
Physical Fabric
|
+----------------+----------------+
| | |
VPC A VPC B VPC C
10.0.0.0/8 10.0.0.0/8 10.0.0.0/8
虽然三个客户使用：
相同 IP 地址
但是因为属于：
不同 VPC
所以不会发生冲突。
因此：
VPC 本质上首先解决的是 Multi-Tenancy——多租户网络隔离。
3. VPC 可以理解成什么？
如果从传统网络工程师视角理解，可以把 VPC 粗略理解成：
VPC
≈
VRF
+
Subnet
+
Virtual Router
+
Route Table
+
Security Policy
+
Overlay Tunnel
+
SDN Control Plane
但是必须注意：
VPC ≠ VLAN
VPC ≠ VRF
VPC ≠ VXLAN
这些只是实现 VPC 时可能使用的技术。
更准确的关系是：
VPC
|
+---------------+---------------+
| | |
Addressing Routing Security
| | |
Subnet Route Table SG / ACL
|
Virtual Router
|
Overlay Network
|
VXLAN / Geneve / ...
|
Physical Fabric
4. VPC 最核心的几个组成部分
一个典型 VPC 至少涉及以下概念：
VPC
|
+-- CIDR
|
+-- Subnet / vSwitch
|
+-- Route Table
|
+-- Virtual NIC
|
+-- Security Group
|
+-- Network ACL
|
+-- Internet Gateway
|
+-- NAT Gateway
|
+-- VPN / Direct Connect
|
+-- VPC Peering
|
+-- Transit Gateway / CEN
下面逐一解释。
5. CIDR：VPC 的地址空间
创建 VPC 时通常首先定义一个地址段。
例如：
10.0.0.0/16
意味着这个 VPC 的私网地址范围可以规划在：
10.0.0.0
~
10.0.255.255
然后继续切成多个 Subnet：
VPC
10.0.0.0/16
├── 10.0.1.0/24
├── 10.0.2.0/24
├── 10.0.3.0/24
└── 10.0.4.0/24
所以可以把：
VPC CIDR
理解成：
整张逻辑私有网络的 IP 地址空间。
6. Subnet / vSwitch 是什么？
有了：
VPC = 10.0.0.0/16
之后，通常不会直接把所有服务器全部扔进去。
而是进一步划分：
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
例如：
VPC
10.0.0.0/16
|
+------------+------------+
| | |
Web App DB
10.0.1.0/24 10.0.2.0/24 10.0.3.0/24
在 AWS 中通常叫：
Subnet
在阿里云中通常叫：
vSwitch
阿里云官方文档也将 VPC 描述为 Region 级资源，而 vSwitch 是 Zone 级资源；AWS 中 Subnet 同样位于单个 Availability Zone。
不过不同云厂商的资源层级不完全相同。例如 Google Cloud 的 VPC Network 是 Global Resource，而 Subnet 是 Regional Resource。
所以：
VPC 是一种通用架构思想，而不是所有云厂商都完全相同的一套实现。
7. Route Table：决定流量去哪里
VPC 不是单纯提供一个二层广播域。
实际上：
现代云 VPC 的核心能力是三层路由。
例如：
Destination Next Hop
10.0.0.0/16 Local
0.0.0.0/0 NAT Gateway
172.16.0.0/16 VPN Gateway
10.20.0.0/16 VPC Peering
于是服务器：
10.0.1.10
访问：
10.0.2.20
可能命中：
10.0.0.0/16 -> Local
访问：
8.8.8.8
则命中：
0.0.0.0/0 -> NAT Gateway
访问企业数据中心：
172.16.1.100
则可能命中：
172.16.0.0/16 -> VPN Gateway
因此 VPC 很像：
一台巨大的逻辑分布式 Router。
AWS 也明确将 Route Table 作为决定 Subnet 或 Gateway 流量转发方向的核心 VPC 组件。
8. 一个包在 VPC 里面到底怎么走？
例如：
VM-A
10.0.1.10
访问
VM-B
10.0.2.20
逻辑上：
VM-A
|
| 10.0.1.10
|
Subnet A
10.0.1.0/24
|
Virtual Router
|
Route Table
|
Subnet B
10.0.2.0/24
|
VM-B
10.0.2.20
逻辑世界看起来像这样。
但是物理世界可能完全不是这样。
例如：
VM-A
|
Physical Server 1
|
ToR-1
|
Spine-3
|
ToR-8
|
Physical Server 8
|
VM-B
因此这里出现了非常重要的两个概念：
Logical Network
vs
Physical Network
也就是：
Overlay
vs
Underlay
9. Underlay 和 Overlay
这是理解 VPC 最关键的一层。
Underlay
Underlay 是：
云数据中心真正的物理网络。
例如：
Server
|
Leaf
|
Spine
|
Leaf
|
Server
底层可能运行：
BGP
OSPF
IS-IS
ECMP
IPv4
IPv6
例如：
Spine1
/ \
Leaf1 Leaf2
| |
Server1 Server2
这就是：
Underlay Network
Overlay
租户看到的：
VPC A
10.0.0.0/16
实际上是：
Overlay Network
例如：
Tenant A
10.0.1.10
\
VXLAN / Geneve / Proprietary Tunnel
/
10.0.2.20
Tenant A
整个关系：
+-------------------------------------+
| Tenant VPC |
| |
| 10.0.1.10 <--------> 10.0.2.20 |
+-------------------------------------+
|
Overlay
|
=======================================
|
Underlay
|
Leaf -- Spine -- Leaf
于是：
租户不需要知道自己的虚拟机实际位于哪台物理服务器，更不需要知道底层经过哪几台 Spine。
10. VXLAN 和 VPC 是什么关系？
很多人容易认为：
VPC 就是 VXLAN。
其实不对。
更准确的是：
VPC = 云网络产品/逻辑网络模型
VXLAN = 实现 Overlay 网络的一种封装协议
VXLAN 会给不同虚拟网络设置：
VNI
VNI：
VXLAN Network Identifier
是一个 24-bit 标识。
理论上可以支持：
2^24 ≈ 16.7 million
个逻辑 Segment。
例如：
Tenant A
VNI 10001
Tenant B
VNI 20001
即使：
Tenant A:
10.0.0.1
Tenant B:
10.0.0.1
地址相同，也可以通过不同的 Overlay Context 加以区分。
逻辑上：
Physical Fabric
Tenant A Tenant B
VNI 10001 VNI 20001
10.0.0.1 10.0.0.1
| |
+------ VXLAN Overlay -------+
不过：
VPC ID、VRF ID 与 VXLAN VNI 并不一定是一一对应关系。
大型云厂商通常还有自己的：
Tenant ID
Endpoint ID
Network ID
Flow Table
Tunnel ID
等抽象。
11. VPC 和 VLAN 有什么区别？
这是非常重要的区别。
VLAN
VLAN 是典型的：
Layer 2 Virtualization
通过：
802.1Q VLAN ID
区分网络。
只有：
12 bit
因此理论最大：
4096 VLAN
实际上可用数量更少。
对于大型公有云：
10万租户
100万租户
显然不够。
VPC
VPC 通常是一种：
Layer 3-centric
Network Virtualization
可以通过：
VRF
VXLAN
Geneve
SDN Flow Table
Tunnel
实现。
所以：
| 特性 | VLAN | VPC |
|---|---|---|
| 主要层次 | L2 | 以 L3 网络抽象为核心 |
| 标识空间 | VLAN ID | 云平台 Tenant/Network ID |
| 规模 | 千级 | 可扩展至海量租户 |
| 网络控制 | 交换机配置 | SDN |
| 路由 | 依赖外部 Router | VPC 内建 |
| 安全策略 | ACL 等 | SG + ACL + 分布式策略 |
| 云资源集成 | 弱 | 强 |
| 自动化 | 较弱 | API 化 |
所以不能把 VPC 简单理解成：
一个大型 VLAN
12. VPC 和 VRF 的关系
如果一定要找一个传统网络技术与 VPC 最接近的概念：
VRF 比 VLAN 更接近 VPC。
VRF：
Virtual Routing and Forwarding
例如：
VRF A
10.0.0.0/8
VRF B
10.0.0.0/8
即使地址重复：
VRF A: 10.1.1.1
VRF B: 10.1.1.1
也不存在冲突。
因为路由查询实际上是：
VRF A Routing Table
和：
VRF B Routing Table
分别进行。
因此传统运营商网络：
MPLS L3VPN
经常通过：
VRF
+
MP-BGP
+
MPLS Label
实现租户隔离。
云数据中心则可能使用：
VPC
+
Virtual Routing
+
VXLAN/Geneve
+
SDN
实现类似目标。
可以建立这样的类比：
运营商 MPLS VPN 云数据中心
VPN Instance <------> VPC
VRF <------> Virtual Routing Domain
RD/RT <------> Tenant / Policy Information
MPLS Label <------> VNI / Tunnel Metadata
PE Router <------> VPC Gateway / VTEP / Distributed Router
MP-BGP <------> SDN Control Plane / EVPN / Proprietary Control Plane
但是：
这是概念类比，而不是严格一一映射。
13. Security Group 是什么？
VPC 不只是：
Connectivity
还必须解决：
Security Isolation
例如：
Web Server
10.0.1.10
可以配置：
TCP 80 Allow
TCP 443 Allow
TCP 22 Only 10.10.0.0/16
Others Deny
这种策略通常通过：
Security Group
实现。
逻辑上：
Internet
|
TCP 443
|
Security Group
|
Web Server
最大的区别是：
Security Group 往往不是一台真正的 Firewall。
它可能是：
Distributed Firewall
策略直接下发到：
Hypervisor
vSwitch
SmartNIC
DPU
Host Networking Stack
所以大型云数据中心不会让所有流量都经过一台中央 Firewall：
Server
\
Server ---- Firewall ---- Network
/
Server
否则扩展性非常差。
而是：
Server [Policy]
Server [Policy]
Server [Policy]
Server [Policy]
即：
安全能力本身也是分布式的。
14. VPC 怎么访问 Internet？
假设：
VM
10.0.1.10
这是 Private IP。
它不能直接被 Internet 路由。
因此一般需要：
Internet Gateway
NAT Gateway
Elastic/Public IP
之一或组合。
例如访问 Internet：
VM
10.0.1.10
|
Subnet
|
Route Table
0.0.0.0/0
|
NAT Gateway
|
Public IP
|
Internet
例如：
10.0.1.10
|
| SNAT
v
203.x.x.x
|
Internet
反过来，如果要提供 Web 服务：
Internet
|
Public IP
|
Load Balancer / Gateway
|
10.0.1.10
因此：
VPC 是 Private Network，并不意味着它不能访问 Internet。
是否连 Internet 取决于：
Route
+
Gateway
+
Public IP
+
Security Policy
15. 两个 VPC 怎么通信？
例如：
VPC A
10.0.0.0/16
VPC B
10.10.0.0/16
默认情况下：
VPC A X VPC B
是相互隔离的。
如果需要通信，可以建立：
VPC Peering
变成：
VPC A
10.0.0.0/16
|
| VPC Peering
|
VPC B
10.10.0.0/16
随后增加路由：
VPC A:
10.10.0.0/16
->
Peering
以及：
VPC B:
10.0.0.0/16
->
Peering
即可实现通信。
16. 为什么后来又有 Transit Gateway / CEN？
如果有：
100 个 VPC
全部做 Full-Mesh Peering：
连接数量接近：
N × (N - 1) / 2
100 个 VPC 就可能需要：
4950
条逻辑连接。
因此云厂商引入类似：
Transit Gateway
Cloud Enterprise Network
Virtual WAN
Cloud Router
的 Hub-Spoke 架构：
VPC A
|
|
VPC B ---- Transit ---- VPC C
|
|
VPC D
变成：
N 个 VPC
≈
N 条接入连接
管理复杂度大幅降低。
17. VPC 如何连接企业数据中心？
例如企业本来有：
Enterprise DC
172.16.0.0/16
云上建立：
Cloud VPC
10.0.0.0/16
可以通过：
VPN
连接：
Enterprise DC
172.16.0.0/16
|
IPSec VPN
|
Cloud VPC
10.0.0.0/16
或者通过：
Direct Connect
Express Connect
Cloud Connect
专线
连接：
Enterprise DC
|
| Dedicated Line
|
Cloud Provider
|
VPC
于是从企业网络看：
10.0.0.0/16
就像自己的另一个园区。
这就是：
Hybrid Cloud Networking。
18. 一个完整 VPC 网络长什么样？
例如一个典型业务：
VPC
10.0.0.0/16
分成：
Web:
10.0.1.0/24
App:
10.0.2.0/24
DB:
10.0.3.0/24
整体架构：
Internet
|
Internet Gateway
|
Load Balancer
|
+----------+----------+
| |
Web Subnet Web Subnet
10.0.1.0/24 10.0.4.0/24
| |
+----------+----------+
|
App Layer
10.0.2.0/24
|
|
DB Layer
10.0.3.0/24
与此同时：
Private Subnet
|
NAT Gateway
|
Internet
企业内部：
Office
|
VPN / Direct Connect
|
VPC
另外还有：
VPC
|
+-- Security Group
+-- Route Table
+-- ACL
+-- DNS
+-- DHCP
+-- Load Balancer
+-- NAT
+-- VPN
因此 VPC 实际已经是一整套：
Virtual Data Center Network。
19. VPC 背后的 SDN
到了这里，就可以理解：
为什么 VPC 和 SDN 密不可分。
用户在控制台创建：
Create VPC
CIDR = 10.0.0.0/16
实际上只是：
Control Plane API
云网络控制器随后完成：
创建 Tenant
↓
创建 Virtual Network
↓
创建 Virtual Router
↓
创建 Route Table
↓
创建 Tunnel Mapping
↓
下发 Flow Entry
↓
下发 Security Policy
↓
更新 Endpoint Database
可能最终下发到：
Hypervisor
SmartNIC
DPU
ToR
Gateway
因此：
用户看到：
VPC
实际上后面是：
Cloud Controller
|
+---------+---------+
| | |
Routing Security Tunnel
| | |
+---------+---------+
|
SDN
|
+---------------+--------------+
| | |
Hypervisor SmartNIC ToR
这就是：
网络控制平面与转发平面分离。
20. 一个数据包在真实云网络中的过程
假设：
VM-A
10.0.1.10
访问：
VM-B
10.0.2.20
VM-A 可能实际位于：
Physical Server A
192.168.100.10
VM-B 位于：
Physical Server B
192.168.200.20
逻辑包：
Src: 10.0.1.10
Dst: 10.0.2.20
经过 Overlay 封装后可能类似：
+----------------------------------+
| Outer Ethernet |
+----------------------------------+
| Outer IP |
| Src: 192.168.100.10 |
| Dst: 192.168.200.20 |
+----------------------------------+
| VXLAN / Geneve |
| Tenant / VNI Information |
+----------------------------------+
| Inner IP |
| Src: 10.0.1.10 |
| Dst: 10.0.2.20 |
+----------------------------------+
| Payload |
+----------------------------------+
物理网络实际只需要知道：
192.168.100.10
->
192.168.200.20
并不需要知道：
10.0.1.10
属于哪个租户。
到目的 Host 后：
Tunnel Decapsulation
恢复：
10.0.1.10
->
10.0.2.20
再送给 VM-B。
这就是 Overlay 网络能够大规模扩展的关键之一。
21. 为什么 VPC 能允许不同客户 IP 地址重复？
现在可以完整解释：
假设：
Tenant A
VPC A
10.0.0.0/16
VM = 10.0.1.1
Tenant B：
VPC B
10.0.0.0/16
VM = 10.0.1.1
看起来 IP 完全一样。
但是云网络真正查找的可能并不是：
Destination IP
而是类似：
Tenant ID
+
VPC ID
+
Destination IP
于是：
(VPC-A, 10.0.1.1)
和：
(VPC-B, 10.0.1.1)
实际上是两个完全不同的 Endpoint。
这和传统：
VRF-A + 10.0.1.1
与：
VRF-B + 10.0.1.1
的原理非常相似。
22. VPC、VLAN、VXLAN、VRF、EVPN 的关系
可以用下面这张图统一理解：
VPC
|
Cloud Network Abstraction
|
+--------------+--------------+
| |
Routing Isolation
| |
VRF Tenant / VNI
| |
+--------------+--------------+
|
VXLAN / Geneve
|
Overlay
|
EVPN
（可能使用）
|
Underlay
|
IP / BGP / ECMP
注意：
EVPN 并不是所有 VPC 的必选技术。
很多大型公有云：
AWS
Google
Alibaba
Tencent
Azure
都有大量自研 SDN 技术。
所以更准确的表达是：
VPC
↓
Logical Network Abstraction
VXLAN/Geneve
↓
Possible Overlay Encapsulation
EVPN/SDN Controller
↓
Possible Control Plane
BGP/IP Fabric
↓
Physical Underlay
23. 为什么 VPC 对云计算如此重要？
没有 VPC，就很难实现真正意义上的：
Public Cloud
因为云必须同时满足：
① 多租户
Tenant A
Tenant B
Tenant C
共享：
Physical Infrastructure
但逻辑隔离。
② 地址自由
客户可以自己定义：
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
③ 网络自动化
不用网络工程师：
登录交换机
configure terminal
而是：
API
Terraform
CloudFormation
Console
创建网络。
④ 弹性
几分钟甚至几秒即可创建：
VPC
Subnet
Route
Security Policy
⑤ 分布式安全
策略跟随：
VM
Container
Pod
Bare Metal Server
而不是绑定物理交换机端口。
24. VPC 在 Bare-Metal Cloud 中为什么更难？
这一点对于理解 AI Cloud 特别重要。
传统虚拟机云：
VM
|
vNIC
|
vSwitch
|
Hypervisor
|
NIC
VPC 功能可以放在：
Hypervisor
里面。
例如：
VXLAN Encapsulation
ACL
Security Group
NAT
Routing
都可以在 Host 上完成。
但是：
Bare-Metal Server
没有虚拟机 Hypervisor 这一层：
Application
|
OS
|
Physical NIC
|
ToR
于是问题出现了：
VPC 的虚拟网络功能放在哪里？
可能转移到：
SmartNIC
DPU
NIC
ToR
Gateway
Host Network Stack
因此 Bare-Metal Cloud 的 VPC 实现明显更加困难。
逻辑上从：
VM
↓
Hypervisor VPC
↓
Physical Network
变成：
Bare Metal Server
↓
NIC / DPU / ToR
↓
VPC Virtualization
↓
Physical Fabric
25. 为什么 AI Bare-Metal Cloud 尤其需要 VPC？
AI Cloud 中经常出现：
Tenant A
1000 GPU
Tenant B
400 GPU
Tenant C
2000 GPU
这些 GPU 服务器可能连接到同一套：
Leaf-Spine Fabric
例如：
Shared AI Fabric
Spine --- Spine --- Spine
| | |
Leaf Leaf Leaf
| | |
Tenant A Tenant B Tenant C
物理网络是共享的。
但客户希望看到：
Tenant A VPC
Tenant B VPC
Tenant C VPC
因此 AI Cloud 需要同时实现：
高速转发
+
VPC Isolation
+
RDMA
+
Bare Metal
+
Multi-Tenancy
+
Security
难点就在这里。
尤其对于：
RoCE / RDMA
网络非常强调：
Low Latency
High Throughput
Low Jitter
如果每个数据包都经过复杂的软件虚拟交换：
VM
→
vSwitch
→
Firewall
→
Virtual Router
→
Tunnel
→
NIC
就可能影响性能。
因此现代 AI Cloud 越来越倾向把部分网络虚拟化能力：
Offload
到：
SmartNIC
DPU
NIC Hardware
ToR
26. 这也是理解 Pegasus 的关键
如果正在看：
Pegasus: A Data Center Network for Bare-Metal AI Cloud
就必须先理解 VPC。
Pegasus 面对的一个核心矛盾可以简化成：
Bare-Metal AI Cloud
一方面希望：
GPU Server
|
直接使用高性能网络
|
低延迟 / 高吞吐
另一方面又必须提供公有云需要的：
VPC
Isolation
Security
Routing
Multi-Tenancy
也就是说：
Performance
↑
|
Bare Metal -------+------- VPC
|
↓
Isolation
传统 VM Cloud 可以大量依赖：
Hypervisor vSwitch
而 Bare-Metal AI Cloud 没有这一层。
因此：
如何在不牺牲 Bare-Metal 网络性能的情况下实现大规模 VPC，是 Bare-Metal AI Cloud 网络设计的核心问题之一。
这也是为什么类似 Pegasus 的系统会非常关注：
Flow Table
VPC Mapping
Tunnel
Route
Host/Network Cooperation
Scalability
27. 最后用一句话理解 VPC
如果是普通用户，可以记住：
VPC 就是属于自己的“云上私有网络”。
如果是网络工程师，可以理解为：
VPC 是云平台利用 SDN、虚拟路由、Overlay Tunnel 和分布式安全策略，在共享物理 Fabric 上构建出来的多租户逻辑三层网络。
如果是数据中心网络工程师，可以进一步理解成：
VPC
|
Logical Network
|
+---------------+---------------+
| | |
Routing Security Tenant
| | |
VRF SG / ACL Network ID
\ | /
+--------------+-------------+
|
Overlay Encapsulation
|
VXLAN / Geneve
|
Tunnel Endpoint
|
+-----------+-----------+
| |
SmartNIC/DPU ToR
| |
+-----------+-----------+
|
IP Fabric
|
BGP + ECMP
|
Spine
|
Leaf
所以最终可以总结成：
VPC ≠ 一台设备
VPC ≠ VLAN
VPC ≠ VXLAN
VPC ≠ VRF
VPC =
一整套云数据中心网络虚拟化体系。
28. 一张图记住整个 VPC
这张图的核心就是：
用户看到 VPC
↓
云平台实现 Overlay
↓
Overlay 跑在 Underlay 上
↓
底层仍然是一张真正的 IP 数据中心网络
这就是 VPC 的本质。
DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)