前言
试想一个场景，云上北京的一台机器要访问广州的网站（可能在当地公网，也可能在同一朵云的广州节点上），这个报文的生命周期会是什么样，它究竟会如何跨越万水千山达到目的地？旅途中又会经过哪些不同种类设备，这些设备都对报文做哪些修改，为何做这些修改，为什么需要这么设计？
而随着目的地的不同，通信场景的不同，报文的旅途具体可以抽象出哪几类，每一种场景里具体要做哪些设计考虑，需要解决哪些关键问题。对于从事云计算或通信行业的人来说，我想这样的问题或多或少有思考过，尤其对于长期从事传统网络而对云的这种Overlay网络知晓相对不是很多的读者，我想对于这样的一系列问题心中很可能有所疑惑和一定好奇。
说到标题里的“神奇”二字，公有云网络流量的走向路径与传统IDC网络有较大不同。公有云网络一般有数十个地域，近百个可用区机房，数百款具体产品，流量之间互通的场景多种多样，而为了提供高性能、高带宽、低延时、扩展性强、云原生化、高安全性、私密性等特点的转发功能，需要在很多层面（云产品架构、芯片架构、网络架构等等，如下图）进行精心设计。从这个角度看，一个IP报文在公有云上的整个生命旅途，确有其神奇之处。而本文主要聚焦于全链路层面。
另外，在处理云上疑难问题时，经常会碰到全链路问题，访问路径复杂，会经过很多台设备（包括CDN、安全设备、各类网络设备、各类网关、虚机内容器节点，甚至多云互联等），不同设备经常对报文做修改，以及云计算技术本身的抽象性（提供给用户的界面和操作很简单，但底层的层层封装和设计考虑往往很复杂），这些共同原因导致很多全链路问题处理起来比较耗时。
整体上看，如果对一个IP报文在云上的整个旅途有一种完整的全链路视角，带着这样的视角剖析云上各种场景的IP报文之旅，将旅途完完整整的展示出来，不仅能加深对云网络技术、产品和通信的理解，也会很大程度协助排查云上的诸多复杂全链路问题。
具体来说，IP报文在云上的旅途包括非常多场景：例如同地域VPC内及VPC之间，访问公网（Public IP/EIP/NAT），通过专线访问线下IDC等混合云场景，访问云服务场景，访问SLB/ALB场景，CEN TR场景，云防火墙&CEN TR结合场景，容器网络场景等等。
本文将以阿里云为例，介绍同地域内云上通信，同VPC（包括同交换机，不同交换机）及不同VPC之间流量互访的详细报文旅途、表项设计、报文封装，以及相应的思考。
下图为阿里云网络产品体系架构，可以通过此对阿里云主要云网络产品的总体分类有个基本认识，以及对一个报文跨越机房转发的轨迹有个大致的画面。
场景一：同VPC，同VSW
2.1 背景介绍
图中的源ECS（云服务器）和目的ECS是属于同一VPC（虚拟专用网）且同VSW（虚拟交换机）。因为是同一虚拟交换机，所以肯定是在同一可用区（同一IDC机房）内。
然后ECS互相ping对方，比如左边192.168.255.176 ping 192.168.255.169.
我们一起看下这中间，流量从起始后经过的每台Overlay节点设备需要查看的转发表项和实际抓包报文细节。分为路由层面和转发层面来看，先看路由层面。
2.2 路由层面
✪ 阿里云网络通信
在查看表项之前先看下面的两张图：
首先，阿里云网络是一张非常庞大的Overlay网络，云上端到端的通信都是Overlay通信，需要特别关注VPC的tunnel-id，VPC的路由表等。而每个VPC都有一个唯一的tunnel-id。VPC的路由表默认会包括所属每个虚拟交换机的网段，以及云服务地址网段。
如下图所示，阿里云上网络通信的一个基本原则就是相同tunnel-id（相同VPC）的流量默认可以通信，不同tunnel-id（不同VPC）的流量默认不能通信。这也是阿里云为了做到不同用户业务完全隔离的基本技术手段。当然，相同VPC内的流量也可以通过比如网络ACL、安全组等手段来限制通信，不同VPC的流量也可以通过建立对等连接、加入云企业网CEN等手段来实现互通。
✪ 源ECS 路由表项
报文从源ECS发出去，需要查看路由表，上面是源ECS路由表项，可以看到源ECS上只有一条默认路由，指向192.168.255.253这个网关地址，那这个是什么地址？
这其实是个虚地址，可以大致理解为阿里虚拟转发交换机vSwitch上的地址，所以下一跳需要查看这台vSwitch的相关表项。
这里的虚拟转发交换机和VPC配置中的交换机含义不同，前者为一套庞大软件组件，需要完成非常多核心转发功能，而后者其实并不存在具体对应的某个交换机被云实例所挂，只是VPC管控层面为云实例自动分配的一个属性，一个交换机一个网段，这样可以便于用户从high-level层面进行网段规划，业务规划和组网设计等。
✪ 阿里虚拟转发交换机vSwitch（也常称AVS）
首先它是阿里自研虚拟交换机（可类比OVS），以软件形态在物理服务器内部署，承担Overlay的封装/解封装、ECS安全组、路由表项查找、bps/pps等指标跟踪、session维护等等非常多的重要功能。它是服务器内部网络的核心组件，整体负责服务器内部ECS流量的转发和交换。如下图所示，存在Slowpath和Fastpath。
1）Slowpath：基于route/ACL和业务逻辑决定转发行为，首包需要走Slowpath
2）Fastpath：基于Slowpath生成的session做match/action，有session之后直接走Fastpath转发非常高效
✪ 阿里vSwitch（AVS）表项简要介绍
如下图所示，在物理机内每台ECS的每个网卡会连接到AVS上的一个虚拟接口（接口名和ECS网卡的mac地址有映射关系），报文到达AVS后，会在AVS内部依次查找多个表项，在不考虑配置多路由表/子网路由（类似策略路由，可根据源地址段做转换）的情况下，一般来说，主要会查看路由表、VTEP映射表。接下来简要说下各自的用途：
1）表1 路由表，根据tunenl-id来查找，也就是说这上面包含有多个VPC的路由表，那么一台AVS有多少tunnel-id的VPC路由表，实际上包括该物理机上所有ECS所属的VPC以及他们通过其他手段学习到的其他VPC的路由表。对于本VPC所属的交换机网段地址，这些VPC路由的下一跳为0.0.0.0，即继续查找表2。
2）表2 VTEP映射表，存放着要去往的目的地址所对应的物理机地址，用于做Overlay封装使用。最开始，这里面并没有表项，但是通信第一次之后，会通过VPC Gateway学习到目的地所对应的物理机地址。
如下图，包括所有路由表、安全组等非常多的信息都是通过VPC管控进行下发，必要时也会和ECS管控、云企业网CEN管控等其他控制器进行联合工作。如前面所说，云网络是一种非常庞大的Overlay网络，上层有各个产品的控制器进行管控，充分利用SDN思想的核心优势，让设备配置、表项、路由表等等信息的下发变得更加灵活，同时也得以支持超大规模云网络。
✪ 场景一整体通信过程梳理
当源ECS把包发给所在物理机的AVS后，AVS查看表项，先查路由表，下一跳为0.0.0.0，接着查表2。如果已经通信过一次，那么表2会有目的ECS与其物理机地址的映射关系。然后开始封装Overlay报文，内层源目的为私网ip，外层的源地址为本物理机地址，目的地址为目的物理机地址。如果没通信过，会先通过VPC Gateway进行学习映射表。
当物理机里的vSwitch收到报文后，根据报文里的tunnel-id查找相关VPC-id的表项（此场景下与目的ECS属于同一VPC），因为目的地址是该VPC的交换机网段地址，所以下一跳也为0.0.0.0，接着同样是查看VTEP映射关系表，由于目的地址为本AVS的虚拟接口所连接的ECS，所以表项里会对于目的地址为这样地址的下一跳设为该虚拟接口，从该虚拟接口转发给目的ECS。
✪ 回包路程
原理一模一样，例如目的ECS的路由表项，和源ECS非常类似，也是通过默认路由发给.253的地址。然后一路返回同样采用Overlay技术封装，由本物理机地址直接发送到源物理机地址。
2.3 转发层面
✪ 源ECS&目的ECS抓包
注意ip.id 20953，标识这个报文，后续抓包通过这个id来说明是同一个报文。
✪ 源ECS连接的物理机内vSwitch抓包
可以看到原始报文包在里面，外面是一层Overlay封装，最外面是外层源目的ip地址，为源物理机地址-->目的物理机地址，tunnel-id为源ECS所属的VPC tunnel-id 504301.
根据ip.id可以和ECS上抓的包对应起来，是同一个报文。
✪ 目的ECS连接的物理机内vSwitch抓包
通过时间，内层ip.id，外层ip.id都可以看出这个包就是上面源vSwitch发出的包。
通过四个点的同时抓包可以看到，报文的走向和表项分析的路径一样：源ECS-源AVS-物理机1--物理机2-目的AVS-目的ECS。
2.4 通信路径总结
简单来说，对于同VPC，同VSW，逻辑通信路径是：ECS1 → 源AVS → 源物理机 → (VPC Gateway) → 目的物理机 → 目的AVS → ECS2。
对于物理通信路径，因为源和目的属于同一可用区/机房，流量直接在机房内进行转发，也就是近年流行的3层CLOS架构。
另外，为何封装了外层目的地址物理机地址后，物理网络就知道怎么转发，原因是物理机地址段都已通告在underlay网络，所以underlay网络知道如何转发到相应物理机地址。
所以其实不管底层物理网络跳数有多少，从上层来看，非首包是一跳到位，直接从源物理机发到目的物理机，对于首包来说则是两跳，中间要经过VPC网关设备。所以这也是在尽可能简化通信，减小通信复杂度，只是这其中各种表项的定义和学习同步需要精心设计。
场景二：同VPC，不同VSW
3.1 背景介绍
场景二里的源ECS和目的ECS属于同一VPC，但属于不同虚拟交换机，即处于不同细分网段中，在这里同时处于不同可用区/机房。
3.2 路由层面
1）从Overlay层面和查看表项层面，其实这种场景和场景一非常类似，原因在于AVS上的表1路由表里会有VPC管控自动下发的本VPC里所有交换机的地址网段路由，下一跳都指向0.0.0.0，也就是表2. 所以源和目的AVS在查表1的时候都是直接指向表2，然后根据表2的表项内容进行封装和转发。
2）区别在于这两种场景的物理通信路径不一样（如果属于不同VSW同时也属于不同可用区的话），因为源和目的是不同可用区，就会多经过一个专用的连接不同可用区做内网通信的网络设备，加上每个可用区机房都要经过一次3层CLOS架构的设备，整体物理跳数会更多，延时相应的也会更大。
3.3 转发层面
下面通过几个节点的抓包来验证通信路径是否如上述分析一样：
✪ 源ECS抓包
注意锁定这里的ip.id 36495
✪ 源ECS连接的源AVS抓包
注意ip.id 36495，可以看到同样是和场景一一样，外面包一层Overlay封装，外层源目的IP是本物理机地址 → 目的物理机地址。
✪ 目的ECS连接的AVS上抓包
注意ip.id 36495，可以看到这就是上面那个包。
目的AVS拆掉Overlay封装，把里层的报文发给虚拟接口所连接的ECS（根据内层目的IP地址可进行路由找到出接口是连接目的ECS的虚拟接口）。
✪ 目的ECS上抓包
3.4 通信路径总结
1）和场景一类似，也是首包过VPC Gateway，对于非首包，直接从源物理机到目的物理机进行Overlay封装，并没有额外步骤。
具体来说，路径也是为 ECS1 → 源AVS → 源物理机 → (VPC Gateway) → 目的物理机—目的AVS → ECS2。
2）所以只要是同一VPC内通信，不管是不是处于同一VSW虚拟交换机，是不是同一可用区，底层逻辑通信和封装结构并没有明显区别。当然，物理通信路径会多经过一些跳数（如果不同可用区），延时会更大一点。
场景三：不同VPC，同地域
4.1 背景介绍
这里的ECS1和ECS2是同地域的不同VPC，一般来说，可以通过对等连接/VPC互联，CEN1.0、CEN2.0/CEN TR这三种方式进行通信。
前两种方式的底层通信路径比较类似，所以这里直接选用采取CEN1.0的方式互通进行剖析。
4.2 路由层面
✪ 源ECS路由表项
和场景一类似，到达目的地172.16.7.98会通过默认路由送往.253地址。
✪ 目的ECS路由表项
同样和场景一类似：
✪ 源vSwitch/AVS表项
1）首先也是查看表1路由表；
2）在这里就和前两种场景不同，此时的目的地址段不是源VPC里的交换机网段地址，而是另一个VPC的地址段，那么它是否会出现在源vSwitch的路由表里？
这就要看源VPC是否有学习到目的VPC的路由表，学习方式一般有对等连接、CEN1.0、CEN 2.0 TR。对等连接方式需要手动在两边的VPC路由表里添加到对端网段的路由，CEN方式会自动进行学习（只要源目的VPC加入同一个CEN）。
那么这里，是采用CEN1.0方式学习，所以源VPC的路由表里会出现对端VPC网段地址，下一跳为对端VPC的tunnel-id，非常关键，在这个场景里为371185（源VPC tunnel-id为504301）；
3）查到下一跳为对端VPC的tunnel-id后，报文会交给CEN网关（VPC Gateway），Gateway会转发给目的物理机；
4）同理可以推断，目的AVS上的表项回包到源ECS地址，路由表里下一跳是源VPC的tunnel-id 504301，也是发给网关Gateway。
4.3 转发层面
✪ 源ECS上抓包
锁定ip.id 17001
✪ 源vSwitch上抓包
因为这非首包，所以外层目的地址直接为目的物理机地址 11.246.47.134
要特别注意，源AVS发出去的包里的tunnel-id为371185，而并非504301，也就是说源vSwitch发出去的包，第一步直接就把tunnel-id置为对端VPC的tunnel-id。
✪ 目的vSwitch上抓包
根据ip.id 可以和前面的包完全对上，外层源目的IP地址为源物理机地址 → 目的物理机地址。
✪ 目的ECS抓包
目的ECS收到的是目的vSwitch解掉Overlay封装后的报文，ip.id可以对上。
4.4 通信路径总结
1）同地域跨VPC场景和场景一二类似，也是首包过VPC Gateway同时进行路由自学习；对于非首包，直接从源物理机到目的物理机进行Overlay封装。
2）不同的是，源vSwitch上查询路由表项的时候，会先找到对端VPC的tunnel-id，交给CEN网关/VPC Gateway转发给目的地。
至于为何阿里vSwitch上有这个路由表项，原因则是通过CEN1.0学习后，相关管控会下发此表项到相应的vSwitch上。
所以vSwitch上已经有通过一些方式学习到的其他相应VPC的目的前缀地址的表项，其中并非所有VPC的地址段都会存在，否则也就起不到隔离的作用。
3）以CEN1.0为例，某个VPC和哪些其他VPC一同加入同一个CEN实例且控制策略允许学习，那么该VPC的tunnel-id对应的vSwitch路由表里就会出现目的前缀为其他VPC的网段，下一跳为所学习到的VPC各自的tunnel-id。
简单来说，对于同地域不同VPC场景，逻辑overlay通信路径和场景一二基本一致，同样也是：ECS1 → 源AVS → 源物理机 → (VPC Gateway) → 目的物理机 → 目的AVS → ECS2。
从物理路径来说，只是跨VPC，源和目的可能处于同一可用区，也可能属于不同可用区，是否经过更多跳数并不确定，需要看是否跨可用区。
从这里也可以看出，云网络的不同租户业务隔离通过VPC实现，而VPC通过tunnel-id隔离。经过上面的探索过程，可以看到本质上，其实是通过底层设备的路由表进行隔离，对其他VPC网段又没有进行学习过的，vSwitch本VPC的路由表里就不会出现那些网段的路由，所以无法把报文发到目的地，也就实现了业务隔离。
进一步思考
云网络两大基础转发组件
云网络的基础转发组件主要包括两部分：虚拟转发交换机vSwitch和云网关Gateway（也常称XGW）。
5.1 虚拟转发交换机vSwitch
vSwitch本质上是一种Host Overlay技术，而实际上还有硬件Overlay等其他Overlay技术，那么这两者有何不同，为何公有云偏向选择Host Overlay？
1）硬件Overlay
为了满足云数据中心网络虚拟化的隔离需求，传统网络设备商提供了VxLAN隧道端点在硬件设备上实现的方案，虚拟化主机通过VLAN进行本地多租户隔离，在接入交换机上进行VLAN和VxLAN的映射转换，在核心层仅需完成IP转发（对东西向流量）。这种方案和传统网络模型较为接近，部署运维上变化较小，但由于受限于交换机的转发和封装规格资源限制，该方案只适合中型数据中心，无法满足公有云的大规模应用诉求。另外虚拟网络特性发布仍受限于硬件开发周期，对云上网络的高级特性如安全组、子网路由无法较好支持，因此目前仅存在于一些特性要求较为简单的私有云解决方案中。
2）Host Overlay
指在Hypervisor上部署虚拟化交换软件，控制器将租户VxLAN转发配置下发到虚拟交换机上，在Host上软件交换机完成VxLAN隧道端点的封装和解封，从而完成虚拟机之间、虚拟机到边界网络的流量转发。这种实现方式对物理网络仅仅需要IP可达即可，而不再受制于物理交换机支持Overlay特性的规格限制。同时基于Host技术方案实现的Overlay相比于硬件Overlay技术方案而言更加灵活，能很好的满足在硬件交换机上较难实现的安全组、flowlog、子网路由等特性。
5.2 云网关Gateway
前面一直提到的云网关Gateway实际上有多种角色，有VPC Gateway，负责VPC流量的首包兜底转发及映射表学习，公网Gateway负责公网流量转发，专线Gateway负责专线以及跨Region流量的汇聚和分发。因为有多种Gateway角色所以有时也把他们都统称XGW。Gateway和AVS一起为客户搭建一张庞大的虚拟专用网络。
5.3 关于Gateway底层形态的演进
1）云网关Gateway是云网络流量入口，也是云网络带宽压力和稳定性压力最大的一环。
如前面所说，Gateway的流量包括公网流量、专线流量、跨Region VPC互联流量。和云网络的其他组件一样，Gateway也是从x86软转开始。由于Gateway的性能要求较高，阿里云的Gateway跳过了kernel，第一天就开始使用DPDK平台，全自研网关软件。和其他基于x86+DPDK做软转发的云网络产品一样，Gateway的问题也是CPU存在单核性能瓶颈，在大流量和攻击流量场景下CPU可能会被打满，引起故障。随着大型企业上云增加，专线流量出现了数量级的增长，达到数十Tbps。Gateway作为云网络的流量入口，面临的性能和稳定性迫切需要优化。
2）阿里云软硬一体Gateway：
为应对超大流量的挑战，云网络基于可编程交换芯片的Gateway设计，成功实现了Gateway的软硬结合设计。
通过加速，Gateway单机bps性能提升20倍，单机pps性能提升80倍，延时降低25倍，集群能力提升5倍，整体Capex和Opex大幅降低。硬件网关的业务价值可以归结为以下几个方面：
- 大流量（例如阿里双11/大客户数Tbps～数十Tbps的上云流量）
- 大单流（例如IoT场景的GRE tunnel，单流数Gbps～数十Gbps）
- 稳定性（没有软转发的CPU打满隐患）
- 低延时/低抖动（硬件网关的管道足够粗，客户上云丝般柔滑，没有卡顿，就像高速公路的车道足够多，车辆行驶一路通畅，没有排队/没有阻塞）
结尾
总结来说，云上同地域的通信，首包要通过VPC网关转发，同时源虚拟转发交换机和目的虚拟转发交换机都通过内部私有协议学习到对端ECS的VTEP映射Peer地址，这样从第二个包开始就可以直接进行Overlay的外层封装到目的ECS的物理机（简单来说，后续通信是直接一跳到位），然后物理机里的vSwitch根据报文里的tunnel-id去查找相关VPC-id的表项，再根据报文的目的地址找到对应的虚拟接口，发给对应的目的ECS。同时在虚拟交换机内部非首包也会因为有session的存在走Fastpath性能更强延时更低。
除以上介绍，云上通信的场景种类还有非常多，例如访问公网（如下图1）、各种混合云场景（专线访问线下IDC等，如下图2）、访问SLB/ALB后端服务、云服务访问等等，这里面各自需要解决比如限速、导流、地址转换、路由表规模、东西向服务链等等问题，IP报文在这些场景下的旅途会更加漫长和复杂，但也更加有趣和精彩。
下图为混合云几种场景的拓扑图：
