全面理解云上网络
作者：ronaldoliu，腾讯 IEG 后台开发工程师
公司一直在推动业务上云，同时越来越多的项目也要开始出海，对云的依赖会越来越多。但是云并不像它宣传的那么简单易用，尤其是云上网络，是大家理解云的一大阻碍。本文比较全面地梳理了云上网络的各种概念以及简要的原理，希望能够帮助大家建立一个知识索引，以备不时之需。由于本人不是云的专家，因此文章中有不对的地方也欢迎指正。
私有网络 VPC
VPC 全称 Virtual Private Cloud，翻译成私有网络其实不太准确，但是它确实就是对网络资源的一种抽象。我身边的很多同事对 VPC 都很疑惑，每次一说到 VPC 感觉都有点儿晕，不知道为什么会有这个东西：你给我个云服务器不就行了，怎么还得有个什么 VPC 和子网，这到底是啥，好麻烦啊？
其实要理解 VPC，可以类比操作系统的虚拟内存。操作系统提供虚拟内存的抽象，让每个进程都像在独占地使用整个系统的内存，不用担心和其它进程内存地址冲突等等。而 VPC 也是提供类似的抽象，由于公有云上有非常多的企业，每个企业都有自己的网络规划需求，因此公有云需要提供一个类似于虚拟内存的抽象，让云上的某个客户像是在独占地使用整个网络，不用担心 IP 地址被别人占用了。有了 VPC 这层抽象，云上的客户几乎可以随意地规划网络，举例来说，你想让你的某台服务器或者数据库的地址是 10.10.1.123，那它就可以是这个 IP，不担心被占用，完全由你说了算。
并且，就像操作系统的虚拟内存一样，每个进程的地址空间都是彼此独立的，A 进程默认情况下是无法访问 B 进程的地址空间的。类似的，VPC 也是彼此独立的，张三在腾讯云上创立的 VPC 网络和李四的 VPC 网络也是隔离的。
VPC 网络还有个地域(Region)的概念，这个其实很好理解。因为网络的背后其实就是服务器，承载服务器的是机房，而机房肯定是在某个地域部署。
VPC 内还有个很重要的概念叫子网，一个 VPC 由一个或多个子网组成。子网其实就是把 VPC 进一步进行划分，一部分原因是 VPC 中的可用 IP 太多了，需要进行更细粒度的规划，比如游戏逻辑服务器用子网 A 中的 IP，代理网关服务器用子网 B，数据库用子网 C…另一个可能也是更重要的原因是，腾讯云在某个地域其实是多机房部署，每个机房都是电力和网络相互隔离的，避免一出问题全军覆没。每个小机房也叫作可用区(Zone)，比如广州分广州 1 区到广州 7 区……VPC 其实是有这些可用区中的子网络共同组成的。
做个类比的话，VPC、子网和可用区，其实有点像 kafka 的 topic、partition 和 broker 的关系。如果把 VPC 看成是一个 topic，那么子网就是 partition，它才是实际存在的网络。kafka 每个 partition 必须要在某个机器实例 broker 上，而子网也要属于某个可用区 Zone。多个子网共同组成了一个逻辑上的大网络，叫做 VPC。
同一个 VPC 中的不同子网之间默认是互相连通。但如果你仔细看了上面的描述，可能会觉得有点矛盾。因为前面说过，不同可用区(Zone)之间是电力和网络隔离的，以防止故障扩散。按理来说子网间就应该是隔离的啊…确实，不过既然是云上网络，那么系统可以默认给一个 VPC 中的不同子网关联一个路由表，路由器就知道不同网段如何转发了，这样子网间就可以互通了。
有了 VPC 之后，你就可以很方便地规划你的网络了。当你买数据库 CVM 等等资源时，就可以按需给它分配到不同的子网中，随机给一个 IP 即可。
VPC 本质上是个二层网络，我在网上搜索了很久也没找到各个云厂商相关的实现原理介绍，但是猜测应该是 VXLAN，如果有相关文章也希望能够分享下。下面贴两个相关的文章，感兴趣同学可以看看：
对等连接 Peering Connection
由于不同 VPC 之间是网络隔离的，假如不同 BG 都有各自的 VPC，那么当 IEG 的某个业务想要调用 PCG 的某个服务时，就无法连通。但这种场景又是刚需，因此这就需要有办法解决 VPC 之间的互通性。实际的解决办法有两种：对等连接和云联网。对等连接其实就是建立一个通道，让两个 VPC 之间可以互相访问。这个通道一般都是基于云厂商现有的基础设施，通过两端的路由配置来实现，而不依赖独立的硬件。
对等连接只能用于两个 VPC 之间，不具有传递性。假如 VPC1 和 VPC2 建立了对等连接，VPC1 和 VPC3 也建立了对等连接，传递性就是指，VPC2 可以访问 VPC3。但对等连接是不具有传递性，所以 VPC2 无法访问 VPC3。
关于云上对等连接的实现，可以参考基于 Neutron 实现 AWS VPC-Peering 的方案讨论 | SDNLAB |
风险提示：腾讯云的对等连接即将下线（相关公告），后续都推荐使用云联网来实现 VPC 之间的互通。
NAT 网关
解决了 VPC 内部和 VPC 之间的互联互通之后，接下来面临的问题就是 VPC 和公网的互通。
举个例子，假如你要在腾讯云的 VPC 里面部署一套 CI/CD 流水线，肯定就需要支持代码构建功能。而代码构建就需要去公网拉取依赖库，像构建前端项目会依赖 NPM，Java 会依赖 Maven，Go 依赖 github 等等。这些就需要 VPC 内部的构建服务器能够访问外网。
NAT 网关就是解决这个问题的。NAT 全称是 Network Address Translation（网络地址转换），云上的 NAT 网关支持 S(Source)NAT 和 D(Destination)NAT。
NAT 其实是计算机网络里面非常基础而重要的一个概念，我这里不做展开了。总之，如果你要访问公网，那么你也必须要有一个公网 IP 才行。但是公网 IP 是需要花钱的，如果给每个 CVM 都绑定个公网 IP 就太过于奢侈了，而且没有任何必要。SNAT 网关就可以看成是一个正向代理，VPC 里的 CVM 要访问外网，发送请求到 NAT 网关，由于 NAT 网关绑了了一个公网 IP，因此 NAT 网关可以发送请求带外网，然后收到响应后在把数据返回到 VPC 内对应的 CVM。从源头发出的网络包，经过 NAT 之后，源头就转换成了 NAT 的公网 IP，这就是所谓的 SNAT。
以 OSI 模型来说，NAT 一般是工作在 3 层和 4 层，因为它除了要进行 IP 地址的转换，还需要记住对应的端口，而端口其实是 4 层的概念。不过这些都不重要，重要的是，你知道 NAT 网关就是 VPC 和公网之间的一个转换器。VPC 要访问公网，需要 SNAT。而 VPC 内部的 IP 需要让公网能够访问，则需要 DNAT。DNAT 有点像 Nginx 反向代理，公网请求 NAT 网关的公网 IP，NAT 网关根据配置的端口转发规则，把公网请求转发到 VPC 内部 IP 和端口。
和 DNAT 类型的产品包括负载均衡 CLB 和 API 网关，它们的区别还是很好区分的：
DNAT 工作在 3-4 层，只能进行 1 对 1 的转发（一个 ip:port 转发到另一个 ip:port）
CLB 工作在 4 层，支持 1 多对转发，这也就是负载均衡的核心，并且能够做健康检查故障摘除
API 网关工作在 7 层，基本上是针对 http 协议做转发
更多的对比可以参考官网，这里就不展开了…
有了 NAT 网关之后，我们就能够解决 VPC 和公网之间的互通了。
VPN 网关
首先，这不是用来科学上网的。
VPN 网关要解决的问题是 VPC 和企业自己的 IDC 机房之间的互通。很多企业在上云之前都有自己的机房，这些机房的网络显然和 VPC 是不通的。而且上云是个渐进的过程，一般都是慢慢把业务往云上搬。这时候企业的业务就部分在云上 VPC，部分在自己的机房，那么这两个之间的互联互通也就成了刚需。
由于企业自己的机房和腾讯云是完完全全物理隔离的，它们之间如果不牵一根专线，那么就只能通过公网来互联。VPN 网关就处在 VPC 网络的边缘，负责处理和对应 IDC 之间的公网网络请求。
这里你可能会有疑问，这和 NAT 网关有啥区别呢？NAT 网关提供 VPC 访问公网和公网访问 VPC 的能力，看起来 VPN 网关也是这个功能？某种意义上来说，确实是差不多的。不过它们肯定是有差异的，而最核心的差异就在于加密。
企业在上云时，虽然部分业务在云上，部分在自己的 IDC，但是从企业的角度来讲，云上 VPC 和 IDC 之间的网络通信应该属于“内网环境”。但是云上 VPC 和 IDC 的互联如果不拉专线，就必须走公网，而公网上面就存在各种安全隐患，比如数据泄露等等。所以 VPC 和 IDC 之间如果要走公网，就必须建立一个安全的加密通道，这就是 VPN 网关的职责。
由于需要建立加密的通信通道，那对端势必也需要进行加密和解密。所以 VPN 网关和 NAT 网关还有个很大的不同是，VPN 网关要求通信的双方——VPC 和 IDC，都部署同样的 VPN 网关。
VPN 网关根据不同的加密协议，分为 IPSec VPN 和 SSL VPN，具体的差别见腾讯云官网，推荐 IPSec。
VPN 网关其实就是一个公网上的网络代理，它在 VPC 网络边缘可以和 VPC 通信，同时它拥有公网 IP 可以和公网通信，这其实引出了 VPN 网关的另一个用途——支持不同 IDC 之间的互通。多个 IDC 都可以连接同一个 VPN 网关，只要转发规则配置好，那么 IDC 之间也是互通的。所以通过 VPN 网关，最终可以实现 VPC 和多个 IDC 都互联互通。
那假如 IDC 想要和多个 VPC 互通呢？其实也很简单，只要保证 VPN 网关能够和多个 VPC 互通即可。这里我们可以在腾讯云上创建 CCN 类型的 VPN 网关，来实现这个功能。引入 CCN VPN 网关之后，云上的多个 VPC 和外部多个 IDC 都可以是互通的
云联网 CCN
上面的图中你会发现，CCN 类型的 VPN 网关依赖于一个叫做云联网的路由表，才能最终实现多 VPC 和多 IDC 之间的互联互通。那么什么是云联网，它是干什么的呢？
回忆我们之前讲的对等连接，它实现的是两个 VPC 之间的互通，并且不具有传递性，如果要实现多个 VPC 之间任意互通，那么就需要在所有 VPC 两两之间都配置一个对等连接。这个配置是很麻烦的，假如有 n 个 VPC，那么总共就需要 C(n, 2)个对等连接，比如 n 是 5，则需要配置 10 个对等连接。这时云联网就出场了，它解决的就是多个隔离的网络彼此互通的问题，这个隔离的网络不仅可以是 VPC，还可以是 IDC。
理解云联网具体的实现原理需要一些网络相关的基础知识，本文不做展开，KM 上的这篇文章讲得很清楚：腾讯云联网（CCN）全网互联的技术实现 - 腾讯云业务线 - KM 平台 (woa.com)
作为用户来说，我们可以简单地把云联网看做一个巨大的路由器，不同的网络只要能够接入腾讯云的网络，就能加入云联网这个大路由器。而这个大路由器根据各种自动学习算法，来适应我们的网络拓扑，从而实现不同网络之间的互联互通。
由于云联网的便捷以及更好的性能，它将是构建混合云的基石，从而取代难以维护的对等连接。
专线网络 Direct Connect
我们前面讲了企业自己的 IDC 如果要和腾讯云的 VPC 互通，可以通过 VPN 网关来实现。但 VPN 网关是通过公网来建立通信连接的，即使使用了 IPSec 等加密技术，那也直解决了通信安全的问题，但网络质量依然会很不稳定。这时，对于有需求的大型企业来说，拉一根专线接入到腾讯云就很有必要了。一旦 IDC 通过专线接入了腾讯云的网络，那么后续的各种互联互通就变得非常容易了。
比如，如下图所示，可以通过配置专线网络实现和不同 VPC 的互通：
当然更简单的办法是专线接入腾讯云网络之后，直接和云联网打通，从而实现任意网络的互联：
私有连接
前面讲的对等连接 VPN 网关 云联网 专线等等，都是想要屏蔽不同网络的差异，让用户的网络请求就像在同一个网络中一样。但是有些时候出于安全等各方面考虑，不同 VPC 之间，我只想让你访问我的某个服务，不想开放整个网络。此时，我可以把服务暴露到公网，你通过公网域名来访问，这没问题。假如两个 VPC 都在腾讯云上，如果走公网，数据包去公网绕一大圈不说，还会浪费宝贵的公网带宽。
此时私有连接就派上用场了。私有连接其实就是 VPC2 开放一个 IP+端口给 VPC1 调用，这样请求就可以在腾讯云内网中完成，效率更高也更安全更省成本。
如图所示，用户需要把 VPC2 中的服务提供给 VPC1 调用，那么就需要在 VPC2 中创建一个私有连接的终端节点服务，这个服务其实就是把负载均衡 CLB 对外暴露。同时调用方 VPC1 可以创建一个终端节点，连接 VPC2 的终端节点服务。配置好之后，VPC1 的终端节点其实就是一个 VIP，VPC1 中向这个 VIP 发送请求，就会被转发到 VPC2 的终端节点服务所对应的 CLB，从而实现不同 VPC 中服务间的内网调用
前面讲的所有内容，都是在解决不同 VPC 和 IDC 之间网络层面互通的问题。利用上述的服务，我们可以构建出符合企业不同需求的混合云网络。然而网络构建也只是万里长征第一步，接下来还需要从应用层考虑，怎么保证服务的高可用，怎么加速用户的网络访问速度提高用户体验等等。
负载均衡 CLB
负载均衡是我们接触得最多的产品，基本上所有业务服务都会需要使用 CLB。CLB 其实就是把对某个服务的请求转发到该服务对应的多个 CVM 上，通过各种算法来保证请求尽可能均匀地分布减少单台 CVM 的压力，同时 CLB 会感知 CVM 的健康状态，把不健康的实例从转发目标中摘除，从而减少不必要的请求失败。通过 CLB 还可以避免暴露内部 CVM 实例的 IP。
CLB 和我们熟知的 Nginx 职责基本上一样的，最早的 CLB 只是工作在 4 层网络（现在腾讯云的 CLB 也支持配置 7 层转发，相当于和 Nginx 进行了产品融合），而 Nginx 主要工作在 7 层网络。如果你仔细回想，可能会发现 4 层的 CLB 和 DNAT 网关似乎也类似，它们都是公网用户访问网关的公网 IP，再由网关根据配置转发到内网。不过 DNAT 主要是 1 对 1 的地址翻译，它的转发是确定的唯一的，用户对某个 ip+port 的请求，一定会翻译成另一个确定的 ip+port。而 CLB 会把对一个 ip+port 的请求转发到一系列 ip+port 中的任意一个。假如 CLB 转发的 CVM 实例就只有一台的话，那 CLB 其实就和 DNAT 达到的效果差不多。
那假如一个依赖于 Nginx 的业务系统要上云，还需要 4 层 CLB 吗？这个问题的答案其实不难得出，你可以先自己想一下。
首先，业务的 Nginx 是单点吗？如果有多个 Nginx 的实例，那么用户流量是怎么到达的呢？一种方式是通过 DNS 服务，把域名映射到多个 Nginx 实例的 IP，但这又要求每个 Nginx 都有公网 IP 才行，这会增加成本。同时，用户如果直接通过 DNS 查找 Nginx 实例，很难以做到动态的负载均衡，因为 DNS 的负载均衡一般都是通过配置权重来实现的。你可以把所有 IP 的权重都调成一样来实现负载均衡，但假如某台 Nginx 实例突然故障了，DNS 依然会把固定比例的流量指向该故障实例。
而引入 CLB 的话，DNS 处只需要暴露一个 CLB 的公网 IP，CLB 先进行 4 层的负载均衡，把流量转发到不同 Nginx，Nginx 再进行 7 层转发。如果 Nginx 出问题，CLB 可以自动摘除。如果 Nginx 扩容了新实例，去 CLB 上添加的生效时间也比配置 DNS 快得多。
当然，由于腾讯云上的 CLB 现在同时支持 4 层和 7 层转发，因此如果没有依赖于 Nginx 的特殊能力的话，其实可以只用 CLB 就可以了。
至此，我们已经覆盖了 VPC 内部，VPC 之间，VPC 和 IDC 之间，IDC 和 IDC 之间的各种网络接入的概念和技术，也知道了它们到底是要解决哪些问题，你可以根据需要自行深入去了解相关内容。
我们前面覆盖的内容，其实从某种意义上来说都属于是“内网”。接下来要讲讲另一个很重要的概念，就是接入网络。也就是用户怎么连接到我们的内网。
DNSPod
用户不可能记住我们的公网 IP，我们需要提供更容易记忆的域名，来支持用户访问我们的服务。所以第一步，你需要先去购买一个域名，然后配置这个域名解析到你的公网 IP，然后等待域名解析生效。
用户通过域名访问网站时，就会经历一个递归地域名查找流程，最终找到域名对应的 IP，然后再通过那个 IP 访问网站。这里的递归查询在没有缓存的情况下（比如用户第一次访问）会进行很多次，从而使得首次访问速度很慢，极大的影响用户体验。好不容易花钱买量买过来的用户，打开你的运营页面竟然白屏一直加载，然后关掉了，这不是亏惨了。
所以 DNSPod 就登场了，它其实解决的核心问题就是 DNS 解析的加速。域名商只关心你的域名是否可以正确解析，而 DNSPod 关心的是你的域名解析速度快不快。DNSPod 通过自己的 DNS 解析集群，能够极大的提高解析速度。
域名到 IP 的解析还只是第一步，接下来连接到这个 IP 也是有一些问题的。比如，不同运营商之间的网络访问是比较慢的，假如用户是电信的网，但是域名解析后拿到了联通的 IP，那么访问速度依然很慢。要解决这个问题，就需要 DNS 服务器能够根据用户的 IP 属于哪个运营商来返回对应的 IP 地址（如果有的话）。而 DNSPod 的智能线路解析就是干这个工作的。
所以 DNSPod 不仅可以减少 DNS 查找时的查询次数，还可以根据用户网络尽可能返回相同运营商的 IP，从而提高用户的访问速度。
Anycast 公网加速 AIA
用户访问速度要快除了加速 DNS 解析，还有个很重要的就是就近接入。就近接入细分又有两种：
目标服务器离用户近
POP 接入点离用户近
目标服务器离用户近的场景，有个我们都非常熟悉的产品——CDN（Content Delivery Network）。如果问 CDN 的大致原理，相信大家都知道，就是把内容缓存到很多个边缘节点服务器上，用户访问 CDN 资源时，从离他最近的节点取数据，而不需要去源站（VPC 内）取数据，能够大大缩短响应时间。
而 POP 接入点离用户近，是为了优化网络质量。之前我们也提过，公网的网络质量是很不稳定的，所以如果有可能，要尽量减少数据包在公网的传输距离，而应该让数据包尽可能多的在云厂商自己的骨干网中传输。POP 点就是分布在世界各地的接入点，用户的请求只要到了 POP 点，之后就可以走云厂商自己的骨干网了。
但是你有没有想过，不论是 CDN 还是 POP 点，用户怎么知道哪个节点离他最近呢，或者说，是谁帮用户选择最近的节点？——这就要用到 Anycast 技术了。
Anycast 简单来说就是多个不同的服务器共享同一个 IP 地址，利用 BGP 最优寻路算法，把请求路由到离用户最近的服务器。当这些服务器是 POP 点时，那么就相当于用户请求在公网上用最短的距离就接入了云厂商的骨干网，从而提高的后续的传输速率，达到加速的目的。
如上图所示，离真正游戏服务器部署地区越远的用户，请求在公网上传输的距离也越长，延时也就越高。云厂商在全球各地部署了相当多的 POP 点，这些 POP 点都通过专线和云厂商的骨干网连接。因此通过 Anycast 加速网络，虽然不能减少物理距离带来的时延，但是可以尽可能减少公网传输带来的时延，让请求绝大多数时候在云厂商骨干网里传输，从而提高传输速度。
Anycast 背后更深入的原理，则需要比较多的计算机网络知识和概念，如果不是相关从业人员，只是使用方的话，没有太大必要去深入细节。想要了解更多关于 Anycast 的技术，可以参考 KM 上这篇文章：草堂答疑系列微视频之腾讯云 BGP Anycast 技术简介 - 运营识堂课后分享沙龙 - KM 平台 (woa.com)。
全球应用加速 GAAP
和 Anycast 加速还有个类似的产品，叫做 GAAP。虽然是不同的产品，但是它们的加速原理都是一致的，就是把请求尽量多地放到云的骨干网络中传输而不是公网。
可能你也发现了，其实绝大多数的网络加速方案，原理都是让网络包尽量走内网，减少走公网。而 GAAP 其实就可以理解为：把腾讯云的骨干网传输能力对外售卖。它和 AIA 的一个很大不同是，AIA 接入骨干网之后，后续访问的只能是腾讯云中的资源。而 GAAP 是售卖腾讯云骨干网的传输能力，用户的网络包有一段在加速通道中传输，加速通道尽头又会把请求通过公网发送到请求的目的地。
举个例子，比如游戏服务器部署在新加坡，但是我希望加拿大的用户也能比较快的访问。此时，我可以通过 GAAP 创建一条加速通道，这条通道的起点在腾讯云加拿大（假如有），实际的形式其实就是一个 IP。而通道的另一端是新加坡，通道内部都是走的腾讯云的骨干网。通道的尽头你可以想象成是一个 SNAT 网关，负责把流量从内网重新发到公网上。由于请求都已经到新加坡了，那么即使走公网，也很快就到达新加坡的服务器了。
GAAP 相比于 AIA 的优势就是，它可以不限定要加速的源服务器所在的网络。比如，假设游戏服务器部署在新加坡自建的 IDC 机房或者在 AWS 新加坡 VPC 中，那么依然可以通过 GAAP 加速。而考虑到海外业务很多时候由于政策问题需要使用当地的云服务商，那么 GAAP 可能是比 AIA 更合适的加速方案。
总结
本文简要地分享了腾讯云上各种网络的概念，从最基础的 VPC 和子网，到各种网络互通方案，比如对等连接，云联网。同时为了支持 IDC 和腾讯云网络的互通，还有基于公网的 VPN 方案以及专线方案。而腾讯云内部，不同 VPC 之间还可以通过私有连接来实现服务级别的相互访问，而不是网络地址空间的全部打通。
除了云上的内部网络，我们还关注用户怎么接入。这里首先就是 DNSPod，能够加速 DNS 的查询速度以及返回更适合用户网络的 IP 地址。而如果部署的服务器离用户很远，那么可以更多地利用腾讯云的骨干网来传输数据减少时延，这方面有 Anycast 和 GAAP 两种方案。Anycast 更简单，但是限制是访问的资源必须在腾讯云上，而 GAAP 基本上就属于对外售卖传输通道，访问的目标资源可以在任意的地方。
希望通过本文能够帮大家梳理一下上云需要涉及到的网络知识，遇到项目出海或者上云时，能够更从容地选择方案，也能更快地理由其它公有云提供的类似服务，进行择优选用。