腾讯网关 TGW 基础原理入门

作者：厉辉，腾讯后台研发高级工程师，当前在腾讯游戏后台团队工作，熟悉四七层负载均衡以及 API 网关等技术领域，同时也是 CNCF Ambassador 以及 Apache APISIX PMC。

本文是在组内技术分享的发言稿，主要介绍 TGW 基本原理和架构，同时为了加深理解，会辅助对比 TGW 与 LVS（ipvs）的异同。本次分享是偏基础性的 TGW 介绍，不会特别深入技术细节，目的是帮助需要用到 TGW 的同事快速的了解 TGW。

零、引言

TGW，全称 Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统。TGW 具有可靠性高，扩展性强，性能高，抗流量攻击能力强等特点，其主要提供 IP 收敛、多线接入和负载均衡的功能。

一、概况介绍

1. 诞生背景

不同运营商用户间无法互通。在十几年前，中国的网络运营商主要有电信和联通两大运营商，又戏称南电信北网通，电信和网通分别布设了光缆，同一个运营商内相互联通，但运营商与运营商间互通需要经过专门的网络通道，一个是带宽有限，另一个是互通通道主要布置在骨干网，所以，在南方地区用电信的客户去访问网通的网站或者游戏，访问路径会变长，带宽受限，访问延迟高，反之也一样。就比如 DNF 的区服就分为了电信服和网通服。

分服的方式可以让同一个运营商的玩家以较低的时延游玩游戏，但当一个南方电信玩家想跟北方网通玩家一起联机的时候，就会体验很差。后来，以游戏为代表的业务多线接入的需求越来越强烈，但是公司缺乏一种通用的解决方案。

思考：站在业务或者产品侧角度，为什么要用双线/多线服？抛开其他因素，双线区的游玩体验更好，游戏收入比单独的电信区/网通区高。

公网 IPv4 地址不足。全球公网 IPV4 地址早在 2011 年就已经分配完毕，IP 地址不足制约着部分重点业务的发展。

2. 多通接入

传统的网络方案，机房和网络类型是绑定的，即一台普通的服务器只能单独接入电信或者联通网络。由于用户跨运营商访问的速度非常慢，通常，游戏业务会为每个运营商均部署一套服务，但这样的方式也有两个问题：一是不同网络的用户互动麻烦，二是网络环境复杂，运维部署困难。（当然还有多线服务器解决方案，但需要是专门的多线机房/多线服务器，服务器成本也高）。

使用 TGW 的多线接入方案后，电信/联通/移动的玩家可以分别就近访问电信/联通/移动的网络访问至腾讯与各个运营商的入口外网 IP，经过 TGW 转发后，通过腾讯自建的内网专线，快速的连接至游戏服务器中（类似于网络游戏加速器的机制），缩短了网络路径。该方案的主要优势是，业务可以透明接入，服务器部署也灵活方便。

公司内首先试用多通接入的游戏业务有轩辕传奇、御龙在天和斗战神。

本质：不同运营商的用户，通过就近接入（域名就近解析或者 IP 就近接入 anycast），访问较近的对应运营商的腾讯外网入口，再通过腾讯内网专线访问对应服务器。

3. IP 收敛

从 2011 年下半年开始，腾讯开放平台开始对外推广（腾讯 QQ 空间页游业务大爆发，比如 QQ 农场/抢车位等等），众多第三方应用开始接入腾讯开放平台。按照当时的网络架构，每个开发商需要几十个到上百个的外网 IP，而合作专区的外网 IP 资源有限，很快就用完了。开发商申请不到外网 IP，制约了腾讯开放平台的进一步发展。经过分析发现，开放平台以小长尾应用居多，其中 90%以上的应用是网页游戏，网页游戏又以分区分服为主，一个游戏少则几十个区，多则数百个区，例如游戏蜀山传奇开了将近 800 个区，意味着需要消耗 800 个外网 IP。

针对于这个问题，解决方案是让网页游戏接入四七层负载均衡（也就是 TGW），不同的区服使用同一个 IP 加不同的端口，多个业务可以复用外网 IP，以节省外网 IP 资源。

本质：不同的服务器，利用 TGW 端口转换功能，使用相同的外网 IP 不同的端口对外提供服务，复用外网 IP。

4. 负载均衡

当然，TGW 最主要的功能还是负载均衡，业务接入负载均衡后，便可以集群化，横向扩展，同时兼具一定的高可用和高性能。常用的四层负载均衡算法为带权重的最小连接数 WLC（Weighted Least Connection）和加权轮询（Weighted Round Robin）。

本质：负载均衡

5. TGW 与 IPVS/LVS 异同

简要介绍完 TGW 的基本功能，这里再与业界常用的四层负载均衡器 LVS 进行对比

基本功能：TGW 作为有专业团队维护的产品，其功能肯定远比 LVS 丰富，其中 TGW 还支持全局 IP 限速限流；其 RS 均支持获取客户端 IP
转发模式：TGW 主要是 IP 隧道模式，LVS 考虑到泛用性，支持四种转发模式；TGW 入流量出流量均经过 TGW 转发，而 LVS，入流量经过 LVS 到后端服务器 RS，出流量直接从 RS 发到客户端；
性能：TGW 基于 DPDK，其性能可达亿级长连接，千万级 pps；而 LVS 基于内核模块，性能百万级连接，接近百万级 pps；
高可用：TGW 是集群高可用，LVS 是 HA 高可用；TGW 只同步长连接，LVS 则长短连接均同步；
其他：LVS 当前也是 kubernetes services ipvs 解决方案的核心转发组件，当前未来的趋势是使用 Cillium

6. 提问：TGW 和 CLB 有什么区别？

TGW，Tencent GateWay，是负载均衡（Load Balancer，LB），在公司内部习惯叫 TGW 了，其主要提供 4 层负载均衡、外网接入、多线接入等功能；若需要接入 HTTPS 或者七层负载均衡或者 QUIC/HTTP3 协议，则可以使用 STGW 替代接入（TGW nginx 加解密）

CLB，负载均衡（Cloud Load Balancer，CLB），是腾讯云产品化的名称，CLB 4 层就对应自研的 TGW， CLB 7 层对应自研的 STGW

二、架构原理

0. TGW 相关技术总览

我这里对 TGW 的技术进行了一个整体的梳理，整体如下图的思维导图。这里分别从业务特点以及技术难点要点角度来看

首先看 TGW 的业务特点。TGW 作为腾讯公网接入的桥头堡，它会有大量的用户访问，需要支持更高的连接数和报文转发能力（pps），会有大量公司内和公司外（腾讯云客户）的业务接入，故需要承载大量的业务规则、外网 VIP、路由。

故 TGW 最关注性能和稳定性，即性能稳定性 >> 功能丰富度；但随着平台的迭代演进，随着性能和可靠性的提升，如何在兼顾性能和可靠性的前提下，不断给 TGW 新增新的功能，保障其可扩展性和可维护性，也会有很多技术挑战。

本章节介绍 TGW 请求转发和负载均衡流程以及 TGW 如何实现高可用。（TGW 高性能的一些实践，由于本人这方面了解不深，故不作介绍）

下一步会介绍 TGW 的整体架构。

1. TGW 整体架构

网络转发，一般会将整体架构其分为管控平面和转发平面。管控平面负责管理控制，转发平面就是转发数据报文。TGW 的管控平面中最重要的便是规则，比如路由规则、限流规则、黑白名单规则，那么管控平面的主要职责便是控制规则，包括创建查询删除修改规则，如何高性能的将规则下发至转发平面，如何保证规则的一致性，对规则进行监控、拨测和告警等等；TGW 的转发平面主要是与路由器和交换机打交道，控制收到的报文如何处理，比如转发、负载均衡、协议转换、限流、黑白名单等。

2. 基本转发原理

转发模式

业界开源的 LVS 负载均衡器的转发模式有四种：NAT 模式（源地址替换）、IP 隧道模式（封装一层 IP 头，IPIP 协议或 GRE 协议）、DR 模式（替换 MAC 地址，负载均衡器 LD 和服务器 RS 均需在同一局域网内，通过 MAC 地址路由访问）、FULLNAT 模式（源/目标地址替换）。不同的转发模式各有优缺点，这里不作过多展开。

TGW 的转发模式是 IP 隧道模式（也是业界最常见的模式），其主要优势是不依赖底层网络结构（相较于 DR 和 NAT 模式），可以同一网络平面通信也可以跨 VPC 网络通信（依赖于 VPC Gateway），另一方面，后端服务器 RS 也可以获取到客户端原始 IP 信息（NAT 模式无法获取）。

上图是 TGW IP 隧道（IPIP 协议）的整体转发流程，其中 CIP:CPORT 是客户端发起访问的 IP 和端口，VIP:VPORT 是业务对外提供服务的外网 IP 和端口，RSIP:RSPORT 是后端服务的内网 IP 和端口，TGWIP 是 TGW 内网的 IP。客户端到 TGW 之间是普通的网络报文，TGW 到后端服务之间是隧道报文（IPIP 或者 GRE）

消息处理流程

上图是 TGW 的消息处理流程。具体如下：

转发的核心对象和概念。TGW 负载均衡的核心对象是 VIP 规则，VIP VPORT 便是路由规则的主键，后端可以挂载多个服务器 RS，用于负载均衡；TGW 中有两个关键的查询表，规则表用于保存 VIP 规则，通过控制台/接口进行配置下发，对转发平面来讲是静态配置，连接表保存负载均衡调度结果，是在新建连接时动态创建。
整体报文转发流程如上图，当一个请求到达时，解析报文后，查询连接表，如果是首包（未命中连接表），则查询规则表，进行调度和创建连接表，并转发报文，如果命中路由表，则根据已有的连接表信息转发报文。

抓包

再通过抓包，直观理解报文处理流程，如下图：

第一部分是 TCP 建链的首包 SYNC 和回包 ACK 包，第一和第四行对应客户端与 TGW 间的 SYNC 和 ACK 包，第二和第三行对应 TGW 与后端服务间的 GRE 的 SYNC 和 ACK 包。
第二部分对应第一行的 SYNC 包，可以看到它的源 IP：源 Port 是 203.195.x.x：53101，目的 IP：目的 Port 是 45.40.x.x:80，即原始地址。
第三部分对应第二行的 SYNC 包，可以看到这个是一个 GRE 包，内层与原包基本类似（目标 Port 被修改，映射成 RS 的服务端口），中间的 GRE 包头，外层 IP 地址则是 TGW 和后端服务所在的母机（因为是 GRE 包，RS 在 VPC 网络中，TGW 会将报文转发到 RS 的母机）内网地址（9.171.x.x 和 10.112.x.x）。
TGW 将该请求转发到后端母机后，母机会将该 GRE 包头去掉，然后将内层报文转发到 RS。

考虑到信息安全，将外网 IP 地址部分打码

负载均衡转发流图

TGW 当前提供的负载均衡功能支持外网负载均衡、内网负载均衡、以及 VPC 内网负载均衡，下图是提供的三种负载均衡转发格式图：

如图所示，外网负载均衡，客户端与 TGW 之间是 IP 包，后端 RS 若是物理机（Underlay 网络），则使用 IPIP 包，后端 RS 若是虚拟机或容器（Overlay 网络），则使用 GRE 包，若业务服务需要申请外网 IP 对外提供服务，便是该场景；VPC 内网负载均衡，调用者/客户端与 TGW 之间是 GRE 报文，TGW 与后端 RS 是 GRE 报文，通常使用场景是云上的虚拟机/内网服务 A 通过云上内网负载均衡访问另一个内网服务 B，对应云上的内网负载均衡。
访问后端是物理机，TGW 需要侵入式的在机器上配置 IPIP 解报文配置，对使用者来说，是侵入式的；如果后端是虚拟机，则是在母机中进行解包 GRE 报文操作，对于虚拟机/容器用户来讲是透明的。
PS：内网负载均衡已经不建议使用，若需要内网负载均衡/内网集群化，建议选用服务发现方案，比如腾讯的北极星 Polaris，开源的 Zuul、Consul、Etcd 等

3. TGW 高可用

TGW 高可用整体方案

大家都知道，业务会通过四层七层负载均衡，让业务集群化提供高可用的服务，TGW 也是如此，TGW 是利用交换机的集群化功能，通过 OSPF 路由发布协议和 ECMP 功能，让 TGW 集群化的提供集群化的四层流量接入功能。其整体架构图如下：

TGW 的集群化架构纵览：

核心路由器和接入交换机。两个核心交换机同时提供服务，两个接入交换机同时提供服务；核心路由器与接入交换机两两互联，核心路由器与其下联接入交换机相连，同时与对端核心和下联接入交换机相连；接入交换机与下联服务器（也就是 TGW LD）相连，与对端接入交换机相连；
TGW 集群。一个 TGW 集群由 4/8/16 台机器，每个 LD 均配置相同的 VIP、路由转发规则，同时提供服务；TGW LD 外、内网分别与外网接入交换机 TGW-W、内网接入交换机 TGW-L 相连
OSPF 路由发布和 ECMP 负载均衡。OSPF：开放最短路径优先协议，支持多路路由；TGW 内、外网上联交换机内、外网核心路由器在同一个 OSPF 域中，实现交换机、核心路由的流量负载均衡；TGW 内、外网上联交换机和 TGW LD 内、外网在同一个 OSPF 域中，实现交换机、TGW LD 的流量负载均衡。

思考：多个节点怎么接入流量、且分配均匀？解决方案：交换机配置 ECMP 如果节点故障怎么让交换机知道？解决方案：OSPF 路由发布如何探测和发现节点故障？解决方案：状态监控、自动剔除如果节点故障上联交换机重新分配流量，怎么保证连接不中断？解决方案：连接同步

高可用分析

对网络层和 TGW 集群进行高可用分析：

网络层容灾：

两台外网核心路由器同时服务，容量冗余。在任意一台核心故障的情况下，余下一台核心路由器能完全接管所有流量。内网亦然。
两台外网接入交换机同时提供服务，容量冗余。任意一台外网接入交换机故障的情况下，余下一台外网接入交换机能完全接管集群所有流量。内网亦然。

TGW 集群容灾：

集群 50% LD 故障，剩余 LD 能够接管所有流量；
LD 故障时，OSPF 路由自动收敛，将故障 LD 剔除（如果是 LD 故障的话），上联交换机重新分配流量，分配到剩余的 LD，为确保连接不中断，需要进行连接同步。连接同步是以单播的方式进行同步。

连接同步

连接同步怎么做？有什么问题？又如何解决？又有其他什么挑战？

开源负载均衡 LVS 的连接同步是长短连接均同步，但这样的做法会影响负载均衡处理新建连接的性能。让我们设想一下，一个 TGW 集群 N 个节点（LD），不做连接同步，新建能力是 X，如果 TGW 集群没新建一个连接就立即同步该连接的话，做了连接同步后，极端情况下，新建能力下降为 X/N。另一方面，由于 TGW 支持的连接数达千万亿级，当新建连接数过多时，不论是新建连接的同步还是存量连接的同步，需要同步的数据量都会非常大。

针对于这两个问题的解决方案：

仅同步长连接。TCP 连接分为长连接和短连接，短连接生命周期很短，并不需要同步，故 TGW 仅对连接存在时间超过 3 秒进行同步，3 秒是一个经验值。
定期、长周期全量同步时间。第一次同步后，4 分钟同步一次，新加入节点先进入就绪状态只接收同步连接，等 5 分钟后，等待完整一个周期后（超过 4 分钟即可），确保所有连接均同步完成后，上线引流；
异步批量发送。连接同步不要求实时性，3 秒同步和 3.2 秒同步其实差异并不大，故可先放入队列缓存，合并成一个报文（MTU 大小）。

同时又有另一个问题，即 LD 间连接的一致性如何保障，但这里就不作过多展开，有兴趣的可以自行了解

（业务常用的一致性手段，2PC、3PC、Paxos、Raft）

防 SYNC DDos 攻击

LVS 如何处理超时连接？又有什么问题？TGW 是怎么做的？又有什么优势？

较早版本的 LVS 连接处理流程如上图的第一张图，其收到新建连接的 SYNC 包后，会创建新的连接，然后交由 timer 处理过期连接，该方案并不能及时的释放无效半连接，故 LVS 并不具有有效防 SYNC DDOS 攻击的能力，当 SYNC 包一旦占满的连接表，便无法新建连接。

关键点：如何确保在连接满之前一定能申请到连接？如何高效的释放无效 SYNC 包？

TGW 的做法是基于原有 LVS 的方案进行改进，使用 LRU 替换原有半连接表：

创建新连接时，若因为半连接表满，导致新建连接失败，由于最老的半连接几乎是不会进行后续建链（业务特点），故直接释放 LRU 链尾节点，使用这段内存用于新建连接；
新建连接后，设置超时 timer，并将该连接加入 LRU 头

该方案的优势主要有两点：

淘汰无效 SYNC 连接的时间复杂度为 O(1)，直接删除 LRU 链尾节点即可
新连接在连接表满之前，总是能够申请到新建连接所需的内存

FAQ

1. 为什么 RS 回包要经过 TGW？

RS 没有外网 IP（外网网卡 IP）
RS 回包有两种选择，经过 TGW 或者 NAT，本质上最少要经过一跳转发，直接回包并不能缩短网络路径；
TGW 网络路径转发性能好、带宽大、资源足；NAT（云下 NAT）转发能力和性能差，云上 NAT 则还需要额外占用外网 IP，若共用则可能出现端口冲突、TIME_WAIT 等问题。

2. 为什么是 IP 隧道模式，而不是 DR/NAT 等其他模式？

IP 隧道模式是通过给客户端报文加壳（IPIP 包头/GRE 包头）通用性强，不依赖底层网络结构，更适合当前虚拟化/多 VPC 网络环境
DR 模式是通过修改报文的源 MAC 和目的 MAC 地址实现的报文转发和负载均衡，负载均衡器和 RS 需要在同一个广播域，同时 RS 需要能够访问外网（比如要有外网 IP 地址）
NAT 模式是通过修改报文的 IP 地址（又分为 SNAT 和 FULLNAT），会导致业务方无法获取到客户端真实 IP。

3. 高性能网络框架的变化

epoll 多路复用（比如 nginx），瓶颈，几十万级 pps 时，用户态和内核态上下文切换，其未来发展有三个方向
方向一：LVS，基于 Netfilter/BPF（其他工具还有 iptables、tcpdump 等），转发逻辑在内核态，绕过用户态和内核态上下文切换；TGW DPDK 版本，基于 DPDK，直接从网卡取包，CPU 作转发逻辑，缩短报文处理路径；再进一步优化便是将报文处理逻辑下沉，比如智能网卡或者 P4；
方向二：eBPF，新的 VM 设计，比 cBPF/Netfilter 性能提升 20 倍以上，充分利用 CPU 寄存器，落地产品比如 Cillium；
方向三：epoll 的未来，io_uring。

4. CAP 三网合一的 IP 原理是怎么样？其价格与普通的三网外网 ip 有什么异同呢？

背景：中小运营商宽带用户跨网访问体验差
基本概念：腾讯 CAP（Content Accelerate Platform：内容加速平台），CAP IP 与中小运营商对等互联
为什么贵？CAP IP 必须具备电信与联通的 BGP 路由与带宽；电信与联通的用户庞大，两大运营商网络覆盖在中国市场各具有一定的垄断性，BGP 带宽资源价格昂贵；最初引入的电信与联通 BGP 带宽仅用于解决极少错配用户的互通问题，不可非合理使用

5. IPIP 协议和 GRE 协议基本概念和异同

IP 隧道技术：是路由器把一种网络层协议封装到另一个协议中以跨过网络传送到另一个路由器的处理过程。隧道技术是一种数据包封装技术，它是将原始 IP 包（其报头包含原始发送者和最终目的地）封装在另一个数据包（称为封装的 IP 包）的数据净荷中进行传输。
IPIP 即 IP in IP，一种 IP 隧道（IP Tunnel）协定，将一个 IP 封包，封装进另一个 IP 封包中。为了封装 IP 封包，在来源 IP 上要再加上一个外部的标头，隧道的进入点，目的位置，以及隧道离开的位置。这个技术使用于虚拟私人网络（VPN）上，RFC 2003 说明了这个协定的内容。
GRE 也类似，即 IP in GRE

名词介绍

OSPF 协议：一种动态路由协议，当前主要用于 tgw 的容灾功能上。

ECMP：等价多路由

IP 隧道技术：是路由器把一种网络层协议封装到另一个协议中以跨过网络传送到另一个路由器的处理过程。隧道技术是一种数据包封装技术，它是将原始 IP 包（其报头包含原始发送者和最终目的地）封装在另一个数据包（称为封装的 IP 包）的数据净荷中进行传输。

IPIP：即 IP in IP，一种 IP 隧道（IP Tunnel）协定，将一个 IP 封包，封装进另一个 IP 封包中。为了封装 IP 封包，在来源 IP 上要再加上一个外部的标头，隧道的进入点，目的位置，以及隧道离开的位置。这个技术使用于虚拟私人网络（VPN）上，RFC 2003 说明了这个协定的内容。

WC：IDC 机房的外网核心设备 WC

XGWW：连接 TGW 服务器和 NFV 服务器的 TOR，XGWL 为内网，XGWW 为外网

DPDK：旁路网卡 IO，绕过内核直接在用户态收发包来解决内核的瓶颈。

pps：一种单位，表示每秒报文数。

VIP：虚拟服务地址（virtual IP，VIP）

RS：后端服务器（Real Server，RS）

HA：High Available（高可用）; 或者指 HA 高可用，即多节点运行，仅有一台提供服务（相较于集群化高可用）

LD：Load Dispatcher，转发物理单元

LVS：Linux Virtual Server/IPVS

VPC：私有网络（Virtual Private Cloud，VPC）

SNAT：（Source Network Address Translation，源网络地址转换）

DNAT：（Destination Network Address Translation，目的网络地址转换）