云网络网关分类、功能定位及技术路线有哪些？

按照是否需要维护租户流量的会话状态，可以将云 网络网关分为无状态网关和有状态网关两类。

云网络（也称作 SDN）是实现公有云环境下多租户隔离的关键技术手段， 而云网络网关（也称作 SDN 网关）作为云网络系统的关键网元，在云网络系统 中扮演着至关重要的角色，如实现租户流量集中转发控制（比如跨 VPC 的互访） 和复杂业务处理逻辑（比如网络地址翻译即 NAT 和服务器负载均衡即 SLB）。 按照是否需要维护租户流量的会话状态（比如 TCP/UDP 会话），可以将云 网络网关分为无状态网关和有状态网关两类。顾名思义，无状态网关无需维护会 话状态，而有状态网关则需维护会话状态。

无状态网关 ：无状态网关通常只需要维护路由转发表和静态的地址映射表。VPC 网关（以 下简称 VGW）和互联网网关（以下简称 IGW）是典型的无状态网关。VGW 主 要维护 VPC 路由信息，IGW 除了维护 VPC 路由之外，通常还需要维护 VPC 私 网地址和公网地址的 1:1 NAT 映射表和功能用于 1:1 NAT 功能。IGW 的 1:1 NAT 功能有别于下文中提到的 NAT 网关的功能，1:1 NAT 主要完成 VPC 地址 到公网地址的 1:1 翻译，1:1 NAT 映射条目在租户购买公网 IP 地址之后就通过SDN 集中控制器配置生成并下发到 IGW，而不是由途径 IGW 的 TCP/UDP 等 流量触发创建，因此，IGW 的 1:1 NAT 条目数量取决于 IGW 所在的云数据中 心对外已售卖的 EIP 地址数量，而与会话数量无关。

有状态网关： 有状态网关除了需要维护少量条目的路由转发表之外，需要动态创建并维 护由途径的 TCP/UDP 等流量触发的会话连接表条目。NAT 网关和 SLB 网关是 典型的有状态网关。NAT 网关主要完成 VPC 内主机主动访问互联网所需要的 n:1 SNAT 功能，即源地址翻译功能，由于某个 VPC 内的多个 VPC 私有地址会 复用一个关联到 NAT 网关的公网地址或 NAT 网关的私网地址（注：该私网地 址将在 IGW 上完成 1:1 NAT，将该私网地址转化为公网地址）对外通信，NAT 网关需要维护 TCP/UDP 会话连接状态来实现多种用途，比如保证一个内部主机 主动发起的任意一个 TCP/UDP 会话的所有数据包在经过 NAT 网关时，源地址 和源端口翻译之后的源地址和源端口始终保持不变。SLB 网关主要完成四层负 载均衡能力，不论是采用 Full NAT 模式，DR 模式还是 DSR 模式，SLB 网关都 需要跟踪维护会话连接状态信息，以保证同一 TCP/UDP 会话的流量始终被负载 分担到服务器集群中某个固定的真实服务器 Real Server 或 L7 负载均衡服务器 （比如 Ngnix 服务器）。 此外，VPN 网关也属于有状态网关，因为其需要与对端 VPN 设备（如 VPN 客户端）建立和维护 IPsec 或 SSL 会话连接。

针对上述提到的云网络网关（包括有状态网关和无状态网关）的技术实现路 线，不同云厂商采用的技术路线往往不尽相同，比如，有的完全采用 NFV 方式 实现有状态网关和无状态网关，有的则采用超融合硬件设备来实现有状态网关 和无状态网关，有的则采用 NFV 方式实现有状态网关而采用可编程硬件设备实 现无状态网关。

NFV 形态网关技术路线： 云网络发展早期主要使用厂商硬件设备方案支撑相关网关业务发展，但随 着云网络业务的快速发展，上述方案暴露出的问题越来越明显，比如设备的采购 成本和维护成本高昂，设备的规格和特性无法快速升级迭代，已经严重制约了云 网络的快速和可持续发展。由此，云网络网关开始往 NFV 网关技术方向演进， 相关技术经过多年的发展，目前已经经过了三轮迭代演进，分别是 NFV 1.0、 NFV2.0 和 NFV3.0。

基于 Linux 内核的 NFV1.0 方案，如图 2-1 所示。在 Linux 内核中，基于 网络子系统的 Netfilter 模块，开源组织开发出了用于负载均衡的 LVS 和用于防 火墙、NAT 的 Iptables。云厂商将这部分功能进行整理和自定义，完成了 NFV 1.0 的方案。该方案基于开源系统，可以在有新需求的时候进行快速开发迭代， 并且该方案运行在 x86 服务器上，当设备性能和容量不够时可以方便快速地扩 容 x86 服务器集群。NFV1.0 方案很好地满足了云网络业务快速开发迭代、快速 扩容的需求，但是受限于 Linux 内核相对复杂冗长的报文处理逻辑，单个 NFV 网元设备的性能始终无法达到较高水平。

随着 DPDK（Data Plane Development Kit，数据平面开发套件）技术的 出现和不断成熟，业界开始使用 DPDK 技术开发用户态的网关系统，由此从 NFV 1.0 进入到 NFV 2.0 阶段。在如图 2-2 所示的 NFV 2.0 方案下，通过内核旁路、 核隔离、独占网卡、内存巨页、网卡多队列和 DPDK 用户态协议栈等一系列优 化技术的使用，单个 NFV 网元的性能得到了大幅提升，已经可以达到 10/25G 网卡线速转发能力, 相比内核态网关，大约有 10 倍以上的提升。

虽然在 NFV 2.0 阶段解决了性能问题，但随着云网络的进一步发展，弹性 能力不足、开放性不够等新的问题又开始凸显出来。为进一步解决弹性扩容、支 撑第三方网元等问题，业界开始了 NFV 3.0 的演进。NFV 3.0 方案如图 2-3 所 示。在 NFV 3.0 方案中 NFV 网元不再部署在物理服务器上，而是使用通用云主 机（即虚拟机），这样网元便拥有了普通云主机的极致灵活性，具有极强的弹性 伸缩能力，也不再需要适配新的网卡硬件。网元开始被统一的 NFV 平台纳管调 度，这就使得其开放性大幅提高，云上用户自己的第三方网元也可以运行到 NFV 平台上，被 NFV 平台调度，提供服务给云上其他租户使用。 基于 NFV 形态的 SDN 网元拥有了极致的弹性和开放性，这极大促进了云 网络网关的快速发展。然而随着云网络的持续快速发展，在一些场景下开始出现 一些 NFV 方案无法解决的问题，主要体现在以下两方面： 1、无法处理超大单流NFV 通过进行横向弹性扩容来支持大流量的处理，但这种大流量有个前提， 即整体流量中流比较均匀且每条流都不能太大。如果流量中出现了一些超大的 单流或者 HASH 分发不均匀，则 NFV 方案将遇到性能瓶颈，因为 NFV 方案中 网络流量转发依赖于 CPU 核的软件转发，而单个 CPU 核的转发能力是存在一 个上限的。当单个 CPU 核上承载的流量超过其上限时将会出现过载丢包，影响 大单流的租户和该 CPU 核上的其他租户。 2、超大规模部署下的高昂成本 NFV 的横向弹性扩容将会使得在处理超大带宽时引入超大规模的网元集群。 假设某个集群达到了 1Tbps 的带宽，以单个虚拟网元 8Gbps 处理能力计算， 则需要至少 125 台虚拟网元，如果考虑冗余容错等其他因素，则需要更多的虚 拟网元。这将导致 NFV 集群的整体拥有成本即 TCO 变得十分高昂。

超融合硬件形态云网络网关技术路线 ：近年来，一些云厂商采用了超融合硬件网关来实现高性能 SDN 网关功能。 超融合硬件网关也称作 Server Switch，其包含了 Tofino、x86 CPU 甚至 FPGA 等硬件资源，将所有网元包括有状态网关和无状态网关统一在超融合硬件网关 内实现。

当前 Tofino 芯片的片上内存容量（SRAM、TCAM）相对较小，无法大规 模云网络对数以百万计的 VPC 路由容量需求。为此，需要从多个维度对表项资 源的分配使用进行优化：第一个维度是使用多级存储转发架构，用 FPGA 甚至 CPU 作为可编程交换机中可编程交换芯片有限片上内存资源的补充，可编程芯 片没有流表命中的流量将转到 FPGA 甚至 CPU 处理；第二个维度是使用多台可 编程交换机实现表项的水平分割；第三个维度是在单台可编程交换机上，使用流 水线折叠等技巧压缩表项的存储空间占用（如图 2-5 所示）；第四个维度是基 于可编程交换机集群和 x86 服务器集群的两级转发处理架构，其中流量经过负 载均衡器之后首先进入可编程交换机集群进行快速处理，因为可编程交换机交 换芯片的片上内存容量有限，没有流表命中的流量将转到 x86 服务器集群处理。

首先，报文在 Tofino 查表命中会进行快速转发；然后，若报文未命中 Tofino 表，会上送到 FPGA 查表命中后转发；最后，如果报文均未命中 Tofino 和 FPGA， 会上送 CPU 后进行转发。 超融合硬件网关优势主要体现在超强的包转发处理性能，例如单个 Tofino 芯片就可以提供 12.8Tbps 的转发性能，相当于几十台的 x86 服务器的性能， 且由于单个流水线转发吞吐极大，流量突发或汇聚产生的网关打爆导致丢包现象将很少出现。 超融合硬件网关同样存在以下两方面的不足：首先，超融合硬件网关将 CPU、 DPU、FPGA 和可编程芯片（如 Tofino）集成在一个硬件设备上，且需要上述 转发单元之间的转发逻辑协同，系统架构相对复杂，开发和维护技术门槛较高； 其次，超融合硬件网关通常基于领域特定芯片提供极致的性能，这类芯片产量较 少，盈利模式不稳定，因此其技术路线的发展也同样容易出现变数，例如 Intel 突然宣布不再支持下一代 Tofino 芯片的研发，这给云厂商技术路线的选择带来 挑战。