facebook推广--脸书买观看量

社会公众号高度关注 「美妙的 Linux 当今世界」

标为「隆哥蒙」，每晚带你畅享 Linux ！

译者者序

责任编辑译者自 Facebook 在 LPC 2021 讨论会上的一则撷取：From XDP to Socket: Routing of packets beyond XDP with BPF^[1]。

副标题可意译为《从 XDP 到 Socket 的（客货运输径）网络流量交换机：XDP 不如，BPF 来凑》，即使 XDP 运转 在存储设备上，因此在边界线和网络流量出口处，再尔后的方向（特别是到了Mach协定栈）它就管不 到了，因此导入了其它许多 BPF 控制技术来接力赛那个交换机操作过程。除此之外， 这儿的交换机绝非广义的交换机器四层交换机，而要特指 L3-L7 网络流量转贴。

虽然译者者水准非常有限，责任编辑难免存有陈述或严重错误含意。但如疑问，请翻查书名。

以下是译文。

1 引言

用户请求从公网到达 Facebook 的边界线 L4LB 节点之后，往下会涉及到两个阶段（每个阶 段都包括了 L4/L7）的网络流量转贴：

1. 从 LB 节点负载均衡到特定主机

2. 主机内：将网络流量负载均衡到不同 socket

以上两个阶段都涉及到网络流量的一致性交换机（consistent routing of packets）问题。责任编辑介绍这一操作过程中面临的挑战，以及我们如何基于最新的 BPF/XDP 特性来应对这些挑战。

1.1 前期工作

几年前也是在 LPC 讨论会，我们撷取了 Facebook 基于 XDP 开发的几种服务，例如

1. 基于 XDP 的四层负载均衡器（L4LB）katran^[2]， 从 2017 年开始，每个进入 facebook.com 的包都是经过 XDP 处理的；

2. 基于 XDP 的防火墙（挡在 katran 前面）。

1.2 Facebook 网络流量基础设施

从层次上来说，如下图所示，Facebook 的网络流量基础设施分为两层：

1. 边界线层（edge tiers），位于 PoP 点

2. 数据中心层，我们称为 Origin DC

• 每层都有一套全功能 LB（L4+L7）

• Edge PoP 和 Origin DC 之间的 LB 通常是长链接

从功能上来说，如下图所示：

1. 用户连接（user connections）在边界线终结，

2. Edge PoP LB 将 L7 网络流量交换机到终端主机，

3. Origin DC LB 再将 L7 网络流量交换机到最终的应用，例如 HHVM 服务。

1.3 面临的挑战

总结一下前面的内容：公网网络流量到达边界线节点后，接下来会涉及 两个阶段的网络流量负载均衡（每个阶段都是 L4+L7），

1. 宏观层面：LB 节点 -> 后端主机

2. 微观层面（主机内）：主机Mach -> 主机内的不同 socket

这两个阶段都涉及到网络流量的高效、一致性交换机（consistent routing）问题。

责任编辑介绍这一操作过程中面临的挑战，以及我们是如何基于最新的 BPF/XDP 特性 来解决这些挑战的。具体来说，我们用到了两种类型的 BPF 程序：

1. BPF TCP header options^[3]：解决主机外（宏观）负载均衡问题；

2. BPF_PROG_TYPE_SK_REUSEPORT^[4]（及相关 map 类型BPF_MAP_TYPE_REUSEPORT_SOCKARRAY）：解决主机内（微观）负载均衡问题。

2 选择后端主机：数据中心内网络流量的一致性与无状态交换机（四层负载均衡）

先看第一部分，从 LB 节点转贴到 backend 机器时，如何来选择主机。这是四层负载均衡问题。

2.1 Katran (L4LB) 负载均衡机制

回到网络流量基础设施图，这儿主要高度关注 Origin DC 内部 L4-L7 的负载均衡，

katran 是基于 XDP 实现的四层负载均衡器，它的内部机制：

• 实现了一个 Maglev Hash 变种，通过一致性哈希选择后端；

• 在一致性哈希之上，还维护了自己的一个本地缓存来跟踪连接。那个设计是为了在某些后端维护或故障时，避免其它后端的哈希发生变化，后面会详细讨论。

用伪代码来表示 Katran 选择后端主机的逻辑：

intpick_host(packet* pkt){if(is_in_local_cache(pkt))returnlocal_cache[pkt]returnconsistent_hash(pkt) % server_ring}

这种机制非常有效，也非常高效（highly effective and efficient）。

2.2 一致性哈希的局限性

2.2.1 容错性：后端故障对非相关连接的扰动

一致性哈希的一个核心特性是具备对后端变化的容错性（resilience to backend changes）。当一部分后端发生故障时，其它后端的哈希表项不受影响（因此对应的连接及主机也不受影响）。Maglev 论文中已经给出了评估这种容错性的指标，如下图，

Maglev: A fast and reliable software network load balancer. OSDI 2016

• 横轴表示 backend 挂掉的百分比

• 纵轴是哈希表项（entries）变化的百分比，对应受影响连接的百分比

Google 放这张图是想说明：一部分后端发生变化时，其它后端受影响的概率非常小；但从我们的角度来说，以上这张图说明：即使后端挂掉的比例非常小， 整个哈希表还是会受影响，并不是完全无感知 —— 这就会 导致一部分网络流量被严重错误交换机（misrouting）：

• 对于短连接来说，例如典型的 HTTP 应用，那个问题可能影响不大；

• 但对于 tcp 长连接，例如持续几个小时的视频流，这种扰动就不能忍了。

2.2.2 TCP 长连接面临的问题

首先要说明，高效 != 100% 有效。对于 TCP 长连接来说（例如视频），有两种场景会它们被 reset：

intpick_host(packet* pkt){if(is_in_local_cache(pkt))// 场景一：ECMP shuffle 时（例如 LB 节点维护或故障），这儿会 missreturnlocal_cache[pkt]returnconsistent_hash(pkt) % server_ring// 场景二：后端维护或故障时，这儿的好像有（较小）概率发生变化}

解释一下：

1. 如果 LB 升级、维护或发生故障，会导致交换机器 ECMP shuffle，那原来交换机到某个 LB 节点的 flow，可能会被重新交换机到另一台 LB 上；虽然我们维护了 cache，但它是 LB node local 的，因此会发生 cache miss；

2. 如果后端节点升级、维护或发生故障，那么根据前面 maglev 容错性的实验结果，会有一 部分（虽然比例不是很大）的 flow 受到影响，导致交换机严重错误。

解决那个问题的一种方式是在所有 LB 节点间共享那个 local cache （类似于 L4LB 中的 session replication），但这是个很糟糕的主意 ，即使这就需要去解决除此之外一大堆分布式系统相关的问题，特别我们不希望导入任何 会降低那个极快数据方向性能的东西。

2.2.3 QUIC 协定为什么不受影响

但对于 QUIC 来说，这都不是问题。

connection_id

QUIC 规范（RFC 9000）中允许 server 将任意信息嵌入到包的connection_id字段。

Facebook 已经广泛使用 QUIC 协定，因此在 Facebook 内部，我们可以

1. 在 server 端将交换机信息（routing information）嵌入到connection_id字段，并

2. 要求客户端必须将那个信息带回来。

完全无状态四层交换机

这样整条链路上都可以从包中提取那个 id，无需任何哈希或 cache 查找，最终实现的是一个 完全无状态的四层交换机（completely stateless routing in L4）。

那能不能为 TCP 做类似的事情呢？答案是可以。这就要用到 BPF-TCP header option 了。

2.3 TCP 连接解决方案：利用 BPF 将 backend server 信息嵌入 TCP Header

2.3.1 原理和流程

基本思想：

1. 编写一段BPF_PROG_TYPE_SOCK_OPS类型的 BPF 程序，attach 到 cgroup：

• 在 LISTEN, CONNECT, CONN_ESTD 等事件时会触发 BPF 程序的执行

• BPF 程序可以获取包的 TCP Header，然后往其中写入交换机信息（这儿是 server_id），或者从中读取交换机信息

2. 在 L4LB 侧维护一个 server_id 缓存，记录仍然存活的 backend 主机

以下图为例，我们来看下 LB 节点和 backend 故障时，其它 backend 上的原有连接如何做到不受影响：

1. 客户端发起一个 SYN；

1. L4LB 第一次见这条 flow，因此通过一致性哈希为它选择一台 backend 主机，然后将包转贴过去；

• 图中这台主机获取到自己的 server_id 是 42，然后将那个值写到 TCP header；

• 客户端主机收到包后，会解析那个 id 并存下来，后面发包时都会带上那个 server_id；

1. 服务端应答 SYN+ACK，其中 服务端 BPF 程序将 server_id 嵌入到 TCP 头中；

假设过了一会发生故障，前面那台 L4LB 挂了（这会导致 ECMP 发生变化）；除此之外，某些 backend hosts 也挂了（这会 影响一致性哈希，原有连接接下来有小概率会受到影响），那么接下来，

1. 客户端网络流量将被（数据中心基础设施）转贴到另一台 L4LB；

1. 这台新的 L4LB 解析客户端包的 TCP header，提取 server_id，查询 server_id 缓存（ 注意不是 Katran 的 node-local 连接缓存）之后发现 这台机器还是 active 的，因此直接转贴给这台机器。

可以看到在 TCP Header 中导入了交换机信息后，未发生故障的主机上的长连接就能够避免 因 L4LB 和主机挂掉而导致的 misrouting（会被直接 reset）。

2.3.2 开销

数据开销：TCP header 增加 6 个字节

struct tcp_opt {uint8_t  kind;uint8_t  len;uint32_t server_id;}; // 6-bytes total

运转时开销：不明显

需要在 L4LB 中解析 TCP header 中的 server_id 字段，理论上来说，那个开销跟代码实 现的好坏相关。我们测量了自己的实现，那个开销非常不明显。

2.3.3 实现细节

监听的 socket 事件

switch(skops->op) {caseBPF_SOCK_OPS_TCP_LISTEN_CB:caseBPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:caseBPF_SOCK_OPS_TCP_CONNECT_CB:caseBPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB:caseBPF_SOCK_OPS_PARSE_HDR_OPT_CB:caseBPF_SOCK_OPS_HDR_OPT_LEN_CB:caseBPF_SOCK_OPS_WRITE_HDR_OPT_CB:. . .}

维护 TCP flow -> server_id 的映射

在每个 LB 节点上用 bpf_sk_storage 来存储 per-flow server_id。也就是说，

1. 对于建连包特殊处理，

2. 建连之后会维护有 flow 信息（例如连接跟踪），

3. 对于建连成功后的普通网络流量，从 flow 信息就能直接映射到 server_id， 不需要针对每个包去解析 TCP header。

server_id 的分配和同步

前面还没有提到如何分配 server_id，以及如何保证这些后端信息在负 载均衡器侧的时效性和有效性。

我们有一个 offline 工作流，会给那些有业务在运转的主机随机分配 一个 id，然后将那个信息同步给 L4 和 L7 负载均衡器（Katran and Proxygen）， 后者拿到这些信息后会将其加载到自己的控制平面。因此那个系统不会有额外开销，只要 保证 LB 的元信息同步就行了。

虽然那个机制同时适用于 QUIC 和 TCP，因此 pipeline 是同一个。

2.3.4 效果

2.3.5 限制

这种方式要求 TCP 客户端和服务端都在自己的控制之内，因此

• 对典型的数据中心内部访问比较有用；

• 要用于数据中心外的 TCP 客户端，就要让后者将带给它们的 server_id 再带回来，但那个基本做不出；

  即使它们带上了，网络中间处理节点（middleboxes）和防火墙（firewalls）也可能会将这些信息丢弃。

2.4 小结

通过将 server_id 嵌入 TCP 头中，我们实现了一种 stateless routing 机制，

• 这是一个完全无状态的方案

• 额外开销（CPU / memory）非常小，基本感知不出

• 其它竞品方案都非常复杂，例如在 hosts 之间共享状态，或者将 server_id 嵌入到 ECR (Echo Reply) 时间戳字段。

这部分内容在 SIGCOMM 2020 论文中有详细介绍。想了解细节的可参考：

Facebook,Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website^[5]. SIGCOMM 2020

1. 拉出：拉出之后的实例不再接受新连接，但在一定时间窗口内，继续为老连接提供服务；

1. 那个窗口称为 graceful shutdown（也叫 draining） period，例如设置为 5 或 10 分钟；

2. 拉出一般是通过将 downstream service 的健康监测置为 false 来实现的，例如在那个例子中，就是让 Proxygen 返回给 katran 的健康监测是失败的。

2. 一般来说，只要 graceful 时间段设置比较合适，一部分甚至全部老连接能够在那个 窗口内正常退出，从而不会引起用户可见的 spike；但另一方面，如果此时仍然有老 连接，那这些客户端就会收到 tcp reset。

1. 部署新代码，

2. 关闭现有进程，创建一个新进程运转新代码。

3. 监听并接受新连接：升级之后的 Proxygen 开始正常工作， 最终达到和升级之前同等水准的一个连接状态。

3.1.2 存有的问题

1. 从 graceful shutdown 开始，到新代码已经接入了正常量级的网络流量，这段时间内 系统容量并没有达到系统资源所能支撑的最大值， 例如三个 backend 本来最大能支撑 3N 个连接，那在升级其中一台的时间段内，系统能支撑的最大连接数就会小于 3N，在 2N~3N 之间。这也是为什么很多公司都避免在业务高峰（而要选择类似周日凌晨五点这样的时间点）做这种变更的原因之一。

2. 本质上来说，这种方式扩展性太差，主机或实例数量一多效率就非常低了。

3.2.1 早期方案：socket takeover (or zero downtime restart)

• TCP socket 分为两部分：已接受的连接（编号 1~N）和监听新连接的 listening socket

• UDP socket，bind 在 VIP 上

1. 创建一个新实例

2. 将 TCP listening socket 和 UDP VIP 迁移到新实例；老实例仍然 serving 现有 TCP 连接（1 ~ N），

3. 新实例开始接受新连接（N+1 ~ +∞），包括新的 TCP 连接和新的 UDP 连接

4. 老实例等待 drain

可以看到，这种方式：

3. 老连接被 reset 的概率可以大大降低，只要允许老实例有足够的 drain 窗口

那么，这种方式有什么缺点吗？

存有的问题

但我们今天要讨论的是另一个问题：UDP 网络流量的分发或称解复用（de-multiplex）。

• TCP 的状态维护在Mach。

• UDP 协定 —— 特别是维护连接状态的 UDP 协定，具体来说就是 QUIC —— 所有 状态维护在应用层而非Mach，因此Mach完全没有 QUIC 的上下文。

虽然 socket 迁移是在Mach做的，而Mach没有 QUIC 上下文（在应用层维护），因此 当新老进程同时运转时，Mach无法知道对于一个现有 UDP 连接的包，应该送给哪个进程 （即使对于 QUIC 没有 listening socket 或 accepted socket 的概念），因此有些包会到老进程，有些到新进程，如下图左边所示；

为解决那个问题，我们导入了用户空间解决方案。例如在 QUIC 场景下，会查看 ConnectionID 等 QUIC 规范中允许携带的元信息，然后根据这些信息，通过另一个 local socket 转贴给相应的老进程，如以上右图所示。

虽然能解决 QUIC 的问题，但可以看出，这种方式非常复杂和脆弱，涉及到大量进程间通信，需要维护许多状态。有没有简单的方式呢？

3.2.2 其它方案调研：SO_REUSEPORT

Socket takeover 方案复杂性和脆弱性的根源在于：为了做到客户端无感，我们在两个进程间共享了同一个 socket。因此要解决那个问题，就要避免在多个进程之间共享 socket。

这自然使我们想到了SO_REUSEPORT^[6]:  它允许 多个 socket bind 到同一个 port。但这儿仍然有一个问题：UDP 包的交换机操作过程是非一致的（no consistent routing for UDP packets），如下图所示：

如果新老实例的 UDP socket bind 到相同端口，那一个实例重启时，哈希结果就会发生变化，导致那个端口上的包发生 misrouting。

另一方面，SO_REUSEPORT 还有性能问题，

• TCP 是有一个独立线程负责接受连接，然后将新连接的文件描述符转给其它线程 ，这种机制在负载均衡器中非常典型，可以认为是在 socket 层做分发；

• UDP 状态在应用层，因此Mach只能在 packet 层做分发， 负责监听 UDP 新连接的单个线性不但要处理新连接，还负责包的分发，显然会存有瓶颈和扩展性问题。

因此直接使用 SO_REUSEPORT 是不行的。

3.2.3 思考

我们后退一步，重新思考一下我们的核心需求是什么。有两点：

1. 在Mach中实现网络流量的无损切换，以便客户端完全无感知；

2. 操作过程能做到快速和可扩展，不存有明显性能瓶颈；

Mach提供了很多功能，但并没有哪个功能是为专门那个场景设计的。因此要彻底解决问题，我们必须导入某种创新。

• 理论上：只要我们能控制主机内包的交换机操作过程（routing of the packets within a host），那以上需求就很容易满足了。

• 实现上：仍然基于 SO_REUSEPORT 思想，但同时解决 UDP 的一致性交换机和瓶颈问题。

最终我们导入了一个 socket 层负载均衡器 bpf_sk_reuseport。

3.3 新方案：bpf_sk_reuseport

3.3.1 方案设计

简单来说，

1. 在 socket 层 attach 一段 BPF 程序，控制 TCP/UDP 网络流量的转贴（负载均衡）:

2. 通过一个 BPF map 维护配置信息，业务进程 ready 之后自己配置网络流量切换。

3.3.2 好处

这种设计的好处：

1. 通用，能处理多种类型的协定。

2. 在 VIP 层面，能更好地控制新进程（新实例）启动后的网络流量接入操作过程，例如

   Proxygen 在启动时经常要做许多初始化操作，启动后做许多健康检测工作， 因此在真正开始干活之前还有一段并未 ready 接收请求/网络流量的窗口 —— 即使它此时已经 bind 到端口了。

   在新方案中，我们无需关心这些，应用层自己会判断新进程什么时候可以接受网络流量 并通知 BPF 程序做网络流量切换；

3. 性能方面，也解决了前面提到的 UDP 单线程瓶颈；

4. 在包的交换机（packet-level routing）方面，还支持根据 CPU 调整交换机权重（adjust weight of traffic per-cpu）。例如在多租户环境中，CPU 的利用率可能并不均匀，可以根据自己的需要实现特定算法来调度，例如选择空闲的 CPU。

5. 最后，未来迭代非常灵活，能支持多种新场景的实验，例如让每个收到包从 CPU 负责处理该包，或者 NUMA 相关的调度。

用一个BPF_MAP_TYPE_REUSEPORT_SOCKARRAY类型的 BPF map 来配置转贴规则，其中，

• key：:

• value：socket 的文件描述符，与业务进程一一对应

如下图所示，即使新进程已经起来，但只要还没 ready（BPF map 中仍然指向老进程），

BPF 就继续将所有网络流量转给老进程，

新进程 ready 后，更新 BPF map，告诉 BPF 程序它可以接收网络流量了：

BPF 程序就开始将网络流量转贴给新进程了：

前面没提的一点是：我们仍然希望将 UDP 包转贴到老进程上，这儿实现起来其实就非常简单了：

1. 已经维护了 flow -> socket 映射

2. 如果 flow 存有，就就转贴到对应的 socket；不存有在创建一个新映射，转贴给新实例的 socket。

这也解决了扩展性问题，现在可以并发接收包（one-thread-per-socket），不用担心新进程启动时的 disruptions 或 misrouting 了：

3.3.4 新老方案效果对比

• 另一个条是同一时间的丢包数量，

可以看到在整个升级期间，丢包数量没有明显变化。

再来看网络流量分发性能，分别对 socket takeover 和 bpf_sk_reuseport 两种方式加压：

• 控制组/对照组（左边）：3x 网络流量时开始丢包，

• 实验组（右边）：30x，因此还没有到分发瓶颈但 CPU 已经用满了，但即使这样丢包仍然很少。

3.3.5 遇到的坑

生产环境遇到过一个严重问题：新老进程同时运转期间，观察到 CPU spike 甚至 host locking；但测试环境从来没出现过，因此在实现上我们也没有特别消耗 CPU 的逻辑。

排查之后发现，那个问题跟 BPF 程序没关系，直接原因是

1. 在同一个 netns 内有大量 socket，

2. 新老实例同时以支持和不支持 bpf_sk_reuseport 的方式 bind 到了同一端口，

   bind("[::1]:443"); /* without SO_REUSEPORT. Succeed. */bind("[::2]:443"); /* with    SO_REUSEPORT. Succeed. */bind("[::]:443");  /* with    SO_REUSEPORT. Still Succeed */

3. bind() 实现中有一个 spin lock 会遍历一个很长的 hashtable bucket，

   如果有大量 http endpoints，那 key 很可能就是  443 和 80；这会导致 CPU 毛刺甚至机器卡住。

那个问题花了很长时间排查，因此有人在类型场景下遇到类似问题，很可能跟那个有关。相关Mach代码^[7]， 修复见patch^[8]。

3.3.6bpf_sk_select_reuseportvsbpf_sk_lookup

Cloudflare 导入了`bpf_sk_lookup`^[9]，

This series proposes a new BPF programtypenamed BPF_PROG_TYPE_SK_LOOKUP,or BPF sk_lookupforshort.BPF sk_lookup program runs when transport layer is looking up a listeningsocketfora new connection request (TCP), or when looking up anunconnected socketfora packet (UDP).This serves as a mechanism to overcome the limits of whatbind() API allowsto express. Two use-cases driving this work are:(1) steer packets destined to an IP range, fixed port to a single socket192.0.2.0/24, port 80 -> NGINX socket(2) steer packets destined to an IP address, any port to a single socket198.51.100.1, any port -> L7 proxy socket

更多信息，可参考他们的论文：

The ties that un-bind: decoupling IP from web services and sockets for robust addressing agility at CDN-scale, SIGCOMM 2021

可以看到，它也允许多个 socket bind 到同一个 port，因此与bpf_sk_select_reuseport功能有些重叠，即使二者都源于这样一种限制：在收包时，缺少从应用层直接命令Mach选择哪个 socket 的控制能力。

但二者也是有区别的：

• sk_select_reuseport与 IP 地址所属的 socket family 是紧耦合的

• sk_lookup则将 IP 与 socket 解耦 —— lets it pick any / netns

3.3.7 小结

1. 简化了运维流程，去掉脆弱和复杂的进程间通信（IPC），减少了故障；

2. 效率大幅提升，例如 UDP 性能 10x；

3. 可靠性提升，例如避免了 UDP misrouting 问题和 TCP 三次握手时的竞争问题。

引用链接

[1]

From XDP to Socket: Routing of packets beyond XDP with BPF:https://linuxplumbersconf.org/event/11/contributions/950/

书名链接：https://arthurchiao.art/blog/facebook-from-xdp-to-socket-zh/

你可能还喜欢

点击下方图片即可阅读

云原生分布式文件存储 MinIO 保姆级中文教程点击上方图片，『美团|饿了么』外卖红包天天免费领

更多有趣的互联网新鲜事，高度关注「美妙的互联网」视频号全了解！

→CL自助下单平台←