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