全面理解云上网络

见贤思齐

作者：ronaldoliu，腾讯IEG后台开发工程师公司一直在推动业务上云，同时越来越多的项目也要开始出海，对云的依赖会越来越多。但是云并不像它宣传的那么简单易用，尤其是云上网络，是大家理解云的一大阻碍。本文比较全面地梳理了云上网络的各种概念以及简要的原理，希望能够帮助大家建立一个知识索引，以备不时之需。由于本人不是云的专家，因此文章中有不对的地方也欢迎指正。私有网络VPCVPC全称VirtualPrivateCloud，翻译成私有网络其实不太准确，但是它确实就是对网络资源的一种抽象。我身边的很多同事对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，如果有相关文章也希望能够分享下。下面贴两个相关的文章，感兴趣同学可以看看：-VPC浅谈-知乎(zhihu.com)-什么是VXLAN-华为(huawei.com)对等连接PeeringConnection由于不同VPC之间是网络隔离的，假如不同BG都有各自的VPC，那么当IEG的某个业务想要调用PCG的某个服务时，就无法连通。但这种场景又是刚需，因此这就需要有办法解决VPC之间的互通性。实际的解决办法有两种：对等连接和云联网。对等连接其实就是建立一个通道，让两个VPC之间可以互相访问。这个通道一般都是基于云厂商现有的基础设施，通过两端的路由配置来实现，而不依赖独立的硬件。对等连接只能用于两个VPC之间，不具有传递性。假如VPC1和VPC2建立了对等连接，VPC1和VPC3也建立了对等连接，传递性就是指，VPC2可以访问VPC3。但对等连接是不具有传递性，所以VPC2无法访问VPC3。关于云上对等连接的实现，可以参考基于Neutron实现AWSVPC-Peering的方案讨论|SDNLAB|风险提示：腾讯云的对等连接即将下线（相关公告），后续都推荐使用云联网来实现VPC之间的互通。NAT网关解决了VPC内部和VPC之间的互联互通之后，接下来面临的问题就是VPC和公网的互通。举个例子，假如你要在腾讯云的VPC里面部署一套CI/CD流水线，肯定就需要支持代码构建功能。而代码构建就需要去公网拉取依赖库，像构建前端项目会依赖NPM，Java会依赖Maven，Go依赖github等等。这些就需要VPC内部的构建服务器能够访问外网。NAT网关就是解决这个问题的。NAT全称是NetworkAddressTranslation（网络地址转换），云上的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网关根据不同的加密协议，分为IPSecVPN和SSLVPN，具体的差别见腾讯云官网，推荐IPSec。VPN网关其实就是一个公网上的网络代理，它在VPC网络边缘可以和VPC通信，同时它拥有公网IP可以和公网通信，这其实引出了VPN网关的另一个用途——支持不同IDC之间的互通。多个IDC都可以连接同一个VPN网关，只要转发规则配置好，那么IDC之间也是互通的。所以通过VPN网关，最终可以实现VPC和多个IDC都互联互通。那假如IDC想要和多个VPC互通呢？其实也很简单，只要保证VPN网关能够和多个VPC互通即可。这里我们可以在腾讯云上创建CCN类型的VPN网关，来实现这个功能。引入CCNVPN网关之后，云上的多个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)作为用户来说，我们可以简单地把云联网看做一个巨大的路由器，不同的网络只要能够接入腾讯云的网络，就能加入云联网这个大路由器。而这个大路由器根据各种自动学习算法，来适应我们的网络拓扑，从而实现不同网络之间的互联互通。由于云联网的便捷以及更好的性能，它将是构建混合云的基石，从而取代难以维护的对等连接。专线网络DirectConnect我们前面讲了企业自己的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（ContentDeliveryNetwork）。如果问CDN的大致原理，相信大家都知道，就是把内容缓存到很多个边缘节点服务器上，用户访问CDN资源时，从离他最近的节点取数据，而不需要去源站（VPC内）取数据，能够大大缩短响应时间。而POP接入点离用户近，是为了优化网络质量。之前我们也提过，公网的网络质量是很不稳定的，所以如果有可能，要尽量减少数据包在公网的传输距离，而应该让数据包尽可能多的在云厂商自己的骨干网中传输。POP点就是分布在世界各地的接入点，用户的请求只要到了POP点，之后就可以走云厂商自己的骨干网了。但是你有没有想过，不论是CDN还是POP点，用户怎么知道哪个节点离他最近呢，或者说，是谁帮用户选择最近的节点？——这就要用到Anycast技术了。Anycast简单来说就是多个不同的服务器共享同一个IP地址，利用BGP最优寻路算法，把请求路由到离用户最近的服务器。当这些服务器是POP点时，那么就相当于用户请求在公网上用最短的距离就接入了云厂商的骨干网，从而提高的后续的传输速率，达到加速的目的。如上图所示，离真正游戏服务器部署地区越远的用户，请求在公网上传输的距离也越长，延时也就越高。云厂商在全球各地部署了相当多的POP点，这些POP点都通过专线和云厂商的骨干网连接。因此通过Anycast加速网络，虽然不能减少物理距离带来的时延，但是可以尽可能减少公网传输带来的时延，让请求绝大多数时候在云厂商骨干网里传输，从而提高传输速度。Anycast背后更深入的原理，则需要比较多的计算机网络知识和概念，如果不是相关从业人员，只是使用方的话，没有太大必要去深入细节。想要了解更多关于Anycast的技术，可以参考KM上这篇文章：草堂答疑系列微视频之腾讯云BGPAnycast技术简介-运营识堂课后分享沙龙-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基本上就属于对外售卖传输通道，访问的目标资源可以在任意的地方。希望通过本文能够帮大家梳理一下上云需要涉及到的网络知识，遇到项目出海或者上云时，能够更从容地选择方案，也能更快地理由其它公有云提供的类似服务，进行择优选用。