2024年4月底，USENIX Annual Technical Conference（ATC）发布最新录用结果。作为计算机系统领域的顶级学术会议（CCF-A），USENIX ATC 2024吸引了来自不同领域的488篇论文投稿，最终精选出77篇具有代表性的论文。这些论文涵盖了虚拟化、系统和网络故障管理、云和边缘计算、移动和无线技术等广泛的研究领域。

其中，腾讯云架构平台部应用框架组 TQUIC(https://github.com/Tencent/tquic)团队结合长期的开发和实践经验， 并与南方科技大学李清老师开展前沿研究探索，提出了一种更高效的 QUIC 流量转发框架 QDSR。高动态内容请求和不断增长的下行中继转发服务使得7层 QUIC 转发工作负载过大，导致运营成本上升和端到端服务质量下降。为了解决这一问题，QDSR 采用了 QUIC 和直接服务器返回（Direct Server Return，DSR）技术，使得真实服务器能够同时直接向客户端发送数据，消除了传统七层过重的冗余中继转发。因此，QDSR 不仅仅实现了高性能、低延迟，并且几乎消除了额外的下行链路中继开销，为云服务提供商提供了一种创新且高效的解决方案。此项论文受到了 USENIX ATC 2024高度认可并被录用。

01

研究动因及技术解析

   1.1 研究背景与动机

广泛使用的 Load Balancer(LB)利用了工作在应用层(L7)的反向代理，可以实现连接级甚至请求级的细粒度控制，其内容感知功能使其能够实现更高级功能，如安全保护、支持粘着重定向等。对于云服务提供商而言，优化最终用户体验至关重要，这包括降低延迟、提高吞吐量、缩短网页加载时间等等。例如，HTTP/2实现了流的多路复用，HTTP/3 则采用 QUIC 替代 TCP 以实现更佳的并行性能，即用户可以同时生成多个请求来加速网页加载，但遗憾的是，七层的负载能力和并行性往往难以达到理想的平衡。典型的七层负载技术是 Proxy-based，如下图所示。LB 负责维护与客户端的连接状态，并将连接划分为请求粒度，然后，它将来自不同 RS（Real Server）请求的资源整合，并转发给客户端。就功能而言，由于 LB 中包含大量控制信息和潜在的攻击风险，将上行流量进行过滤和中继是有充分理由的，然而，将下行流量再次处理则显得冗余。大量无意义的下行中继会导致其迅速成为性能瓶颈，进而降低了吞吐量和端到端延迟。

解决冗余转发问题的典型方案是 DSR (Direct Server Return)技术，该技术允许 RS 直接与客户端建立数据传输通道。目前网络中较为成熟的 DSR 技术实践是 DSR-TCP 方案，如下图所示。然而，由于没有比 TCP 中的连接更细粒度的上下文(与 QUIC 中的流相比)，这意味着同时只有一个 RS 可以为一个连接同时向客户端发送资源，使得 HTTP/2和 HTTP/3中多个 HTTP 请求的复用几乎不可能在一个连接中有效工作。我们称之为 DSR-TCP 的串行请求困境(serial request dilemma)。此外，这种 DSR-TCP 方案将整个传输状态直接交给 RS，包括 TCP 连接移交和 TLS 状态移交，使 RS 直接暴露在广域网上，很容易直接受到攻击。

为了解决 L7 LB 负载能力与并行性之间的矛盾，本论文提出了一种基于 QUIC 和 DSR 的高性能、高性价比的 QUIC 流量转发框架 QDSR。通过 QUIC 和 DSR 技术的结合，QDSR 的细粒度请求处理方法可以同时平衡负载和并行性，如下图所示。然而，QDSR 的设计旨在解决以下挑战：

并行传输与安全：QDSR 使用流切换代替连接切换，实现了对同一个连接的多个请求流的并行处理。同时，为了避免广域网对 RS 的直接攻击，我们设计了一种异构的上行/下行链路结构，使得广域网的攻击无法直接到达 RS。

保持连接一致性：保留LB的上行控制能力，会导致控制与数据分离，这给保持连接一致性带来挑战。为了解决这一问题，QDSR 和每个 RS 之间建立了辅助长连接，通过长连接以特殊的形式交换控制信息。QDSR 保证了分离的控制和数据能力不违反连接的一致性，保证了客户端的透明传输。

包号空间隔离：由于RS不知道共享同一连接的其他 RS，因此不同 RS 的数据包之间可能会发生包序号冲突。由于路径的异构性，简单的预分配包号会导致包乱序和不必要的重传。为了解决该问题，本文提出了流包号空间隔离，其灵感来自多路径 QUIC 的包号空间管理。该方法允许每个 RS 独立地分配分包号，并通过辅助长连接交换分配信息。

   1.2 QDSR 技术架构解析

基于上文提到的问题和挑战，QDSR 的设计原则是：

1. 为高效实现数据传输，RS 直接打通和客户端之间的单向数据传输隧道，使下行流量不再需要进行二次转发。
2. 为确保客户端体验的连贯性，多个 RS 应能同时响应客户端发出的多个请求，同时，客户端对服务端的变化应保持无感知，如同客户端始终在和LB通信一样。
3. 为确保通信过程中的连接一致性，LB 和 RS 之间应灵活地交换连接和流状态信息，以避免潜在的通讯异常。
4. 为确保安全性，所有上行流量必须先经过处理与转发，防止 RS 直接暴露于广域网中，从而遭受恶意攻击。

因此，QDSR 的架构主要由重定向和传输两个阶段组成，具体技术实现如下图所示：

总结来说，当客户端建立 QUIC 连接之后，QDSR 会根据流 ID 将其组装成 HTTP 请求并根据负载均衡策略选择一个真实服务器 RS 处理该请求，并通过其和 RS 之间的重定向长连接将请求内容转发给相应的 RS。RS 接收到相应的HTTP请求后，会将其重新解码为 QUIC 连接状态，并模拟该 QUIC 连接与客户端之间构建单向数据传输隧道。由于一个 QUIC 连接中包含多个 QUIC 流，所以同一个 QUIC 连接的请求可以被多个 RS 共享，最终形成了多个 RS 为一个客户端服务的多对一传输过程。

当客户端收到来自于 RS 的数据后，会以 MPQUIC ACK_MP 帧的格式返回ACK。由于目前的客户端并不知道他们的数据直接来自于 RS，所以他们依旧会向 LB 发送 ACK 信息，收到 ACK 信息后，会根据 CID 分配表查找相应的 RS，并将解密后的ACK_MP帧转发到相应的 RS 上。所以，RS 发送的数据包的传输环路由 LB、RS 和客户端组成，RS 利用 MPQUIC 的包空间隔离机制，实现了不乱序的并行请求服务。

我们分别在真实场景和 Mahimahi 仿真场景中进行了测试，结果如下图所示：

实验结果表明，相比于传统方案，QDSR 可以额外处理4.8%-18.5%的客户端请求，当 LB 成为瓶颈后，QDSR 可以获得相比于传统基于代理的方案12.2倍以上的吞吐并显著降低端到端时延和首包时延。

02

论文评价

   2.1 QDSR 影响力

QDSR 收到了来自 ATC 审稿人和学术委员会的一致好评和关注，以4434的较高分数被 ATC 接收。

多位审稿人对 QDSR 的设计出发点、解决的问题以及良好的工程实现给予了肯定（摘录）：

"I thought the core idea was well motivated and neat。It is certainly useful to reduce the meassive bloat and overhead we have introduced in our data centers"

“The paper was discussed at the PC meeting。The reviewers agreed that the paper addresses an important problem and the solution is well-engineered。The reviewers also found the rebuttal provided by the authors......”

   2.2 最后

目前，QDSR 大规模落地应用需要客户端支持多路径 QUIC 或支持包空间隔离。随着多路径研究的推广和发展，未来客户端支持多路径是必然的趋势。TQUIC 开源项目(GitHub - Tencent/tquic: A high-performance, lightweight, and cross-platform QUIC library  地址：https://github.com/Tencent/tquic）结合 EdgeOne 的动态加速网络，为不同业务场景提供了多种可选的多路径调度算法与客户端集成。我们也将继续推动 QDSR 在业界的大规模部署及应用。

本工作受22-23年度犀牛鸟基础平台技术专项研究计划支持

-End-

📢📢欢迎加入腾讯云开发者社群，享前沿资讯、大咖干货，找兴趣搭子，交同城好友，更有鹅厂招聘机会、限量周边好礼等你来~

（长按图片立即扫码）