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高度认可并被录用。
研究动因及技术解析
研究背景与动机
广泛使用的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独立地分配分包号，并通过辅助长连接交换分配信息。
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****倍以上的吞吐并显著降低端到端时延和首包时延。
论文评价
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......”
最后
目前，QDSR大规模落地应用需要客户端支持多路径QUIC或支持包空间隔离。随着多路径研究的推广和发展，未来客户端支持多路径是必然的趋势。TQUIC开源项目(GitHub - Tencent/tquic: A high-performance, lightweight, and cross-platform QUIC library **地址：**https://github.com/Tencent/tquic）结合 EdgeOne的动态加速网络，为不同业务场景提供了多种可选的多路径调度算法与客户端集成。我们也将继续推动QDSR在业界的大规模部署及应用。
本工作受22-23年度犀牛鸟基础平台技术专项研究计划支持
【相关阅读】《正式开源！高性能轻量级跨平台QUIC协议库TQUIC来啦！》点击图片↓↓↓
扫码添加 “鹅厂架构师小客服” ，加入【鹅厂架构师圈】，与技术爱好者、技术关注者分享交流，共同进步成长，欢迎大家！↓↓↓
关于我们
技术分享：关注微信公众号 【鹅厂架构师】
