[新产品/新功能] Network Load Balancer 新增 QUIC 协议支持，加速移动优先应用

**发布时间:** 2025-11-13 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-quic-protocol-support-for-network-load-balancer-accelerating-mobile-first-applications/ --- <!-- AI_TASK_START: AI标题翻译 --> [新产品/新功能] Network Load Balancer 新增 QUIC 协议支持，加速移动优先应用 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 产品功能分析 ## 新功能/新产品概述 AWS **Network Load Balancer (NLB)** 现已支持 **QUIC** 协议。该功能的核心目标是为移动优先和延迟敏感型应用（如手机游戏、共享出行服务）提供超低延迟的流量转发能力。 其技术原理基于 **直通模式 (passthrough mode)**，即 NLB 不会终止或解密客户端的 **QUIC** 连接，而是将原始的 **QUIC** 流量（基于 **UDP**）直接转发至后端目标。这种设计最大程度地减少了处理开销。为了在客户端 IP 和端口频繁变化的移动网络环境下维持连接，NLB 利用 **QUIC 连接ID (Connection ID)** 来实现会话粘性。具体而言，它依赖于 IETF 的 **QUIC 负载均衡器规范 (QUIC-LB)**，通过解析 **Connection ID** 中编码的 **服务器ID (Server ID)** 来识别并路由到正确的后端实例。 此功能是对现有 **Amazon CloudFront** 在边缘网络终止 **QUIC** 连接能力的补充，为客户提供了在核心基础设施层进行性能优化的新选择，特别适用于那些希望对 **TLS** 证书和端到端加密有完全控制权的客户。 ## 关键客户价值 - **极致的低延迟与高性能** - **业务价值**：通过 **直通模式** 进行数据包级转发，避免了终止和重建连接的开销，从而将延迟降至最低。对于实时交互应用，这能显著改善用户体验，原文提及可将端到端应用延迟降低 *25-30%*（例如从 *500ms* 降至 *350ms*）。 - **差异化优势**：与终止连接的应用层负载均衡器不同，NLB 的 **QUIC** 直通模式将性能优化的控制权完全交给了后端应用，提供了最高的吞吐量和最低的延迟。 - **增强的连接韧性与会话保持** - **业务价值**：移动设备在蜂窝网络和 Wi-Fi 之间切换时，IP 地址会发生变化。基于 **QUIC Connection ID** 的会话保持机制确保了在这种场景下用户会话不会中断，提升了移动应用的稳定性和用户体验。 - **实现机制**：NLB 路由决策不依赖传统的网络五元组，而是解析 **Connection ID** 中嵌入的 **Server ID**，实现了独立于网络地址变化的持久连接。 - **端到端的安全与完全控制** - **业务价值**：由于 NLB 不解密流量，客户可以在后端服务器上完全控制 **TLS 1.3** 证书和加密握手过程，满足了高安全性和合规性要求。负载均衡器本身不持有解密密钥，降低了潜在的安全风险。 - **差异化优势**：客户可以自由升级加密算法或调整应用层协议，而不受负载均衡器功能的限制，拥有最大的灵活性。 - **简化的架构与原生集成** - **业务价值**：为客户提供了一个原生的 AWS 解决方案，无需再依赖复杂且昂贵的自定义实现来处理 **QUIC** 流量。 - **实现机制**： - 与 **Amazon Elastic Kubernetes Service (EKS)** 通过 **AWS Load Balancer Controller** 深度集成，简化了容器化 **QUIC** 应用的部署。 - 健康检查可与现有的 **TCP** 健康检查兼容，降低了从现有 TCP/TLS 架构迁移的复杂性。 ## 关键技术洞察 - **基于 IETF QUIC-LB 规范的路由机制** - **技术独特性**：_基于 IETF 的 QUIC 负载均衡器草案规范_，NLB 的路由逻辑依赖于 **Connection ID** 中嵌入的 **Server ID**。这是一种高效的无状态路由方式，负载均衡器无需维护庞大的会话状态表。 - **工作原理**：后端服务器在与客户端协商时，必须生成包含自身唯一标识（**Server ID**）的 **Connection ID**。当携带此 ID 的数据包到达 NLB 时，NLB 提取该 **Server ID** 并将其映射到已注册的后端目标实例，从而完成精确转发。 - **实现挑战**：此机制要求后端应用服务器支持生成符合规范的 **Connection ID**。目前主流服务器软件尚未原生支持，AWS 建议使用其开源库 **s2n-quic** 作为参考实现，因为它支持自定义 **Connection ID** 生成器。 - **创新的 TCP_QUIC 混合协议监听器** - **技术创新点**：NLB 提供了一种名为 **TCP_QUIC** 的特殊监听器类型，允许在同一个端口（如 443）上同时处理 **QUIC (UDP)** 和 **TCP** 流量。 - **对性能的影响**：这对于部署 **HTTP/3** 应用至关重要。它允许应用无缝地为支持 **HTTP/3** 的客户端提供 **QUIC** 服务，同时为不支持的客户端优雅地回退到传统的 **HTTPS (TCP)**，整个过程通过一个监听器完成，极大地简化了配置和管理。 - **对后端目标的强依赖与配置** - **技术实现**：配置目标组时，目标类型必须是 **实例ID (Instance ID)**，并且需要为每个实例手动配置一个唯一的 **Server ID**。 - **对可用性的影响**：这种设计将路由逻辑与具体的实例标识强绑定。虽然实现了高性能转发，但也要求客户在应用层面仔细管理 **Server ID** 的分配和生命周期，并设计好故障转移策略，以应对后端实例失败或替换的场景。 ## 其他信息 - **监控与可观测性** - 新增了三个 **QUIC** 相关的 **Amazon CloudWatch** 指标： - `NewFlowCount_QUIC`：新建立的 QUIC 流数量。 - `ProcessedBytes_QUIC`：QUIC 监听器处理的总字节数。 - `QUIC_Unknown_Server_ID_Packet_Drop_Count`：因 **Server ID** 未知而被丢弃的数据包数量。此指标对于排查路由问题至关重要，应设置告警。 - **技术生态与成熟度** - **QUIC-LB** 规范本身仍处于 IETF 的草案阶段，未来可能发生变更。 - 主流服务器软件（如 Nginx、Envoy 等）尚未在其主线版本中实现 **QUIC-LB** 支持，这可能成为早期采用的技术障碍。 - **成本** - 使用此功能不收取额外费用，仅按标准的 **NLB** 使用费计费。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # Network Load Balancer 现已支持 QUIC 协议：为移动优先应用加速 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-quic-protocol-support-for-network-load-balancer-accelerating-mobile-first-applications/](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-quic-protocol-support-for-network-load-balancer-accelerating-mobile-first-applications/) **发布时间:** 2025-11-13 **厂商:** AWS **类型:** BLOG --- 今天，AWS 宣布为 [网络负载均衡器 (Network Load Balancer, NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) 推出 [QUIC](https://en.wikipedia.org/wiki/QUIC) 协议支持。这项功能让客户能够以超低延迟将 QUIC 流量转发至目标，同时利用 QUIC 连接 ID (Connection IDs) 保持会话粘性 (session stickiness)。在本博客中，我们将概述 QUIC，演示如何使用 AWS 控制台和 CLI 启用它，并提供一些额外的注意事项。 ## 什么是 QUIC？它为何如此重要？ QUIC ([RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000)) 代表了在移动优先的时代下，我们处理网络通信方式的一次根本性转变。QUIC 是一种基于 UDP 运行的传输协议，提供内置的加密、拥塞控制和多路复用功能。QUIC 是 HTTP/3 的传输协议，使应用程序能为其工作负载使用 HTTP/3，从而实现更低的延迟、更强的连接弹性和更少的行头阻塞 (head-of-line blocking)。与为静态节点设计的传统网络协议不同，QUIC 是为移动设备和应用从零开始构建的，能够满足以下需求： - **超低延迟**：通过最小化握手和减少数据包往返次数实现 - **内置安全**：采用 [TLS 1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security) 加密 - **连接弹性**：即使客户端 IP 地址或端口号发生变化，也能维持会话 ## 移动革命要求更佳性能 智能手机应用的爆炸式增长带来了新的性能期望。移动游戏、共享出行应用以及其他对延迟敏感的行业公司，已在其应用中实施 QUIC 以提供卓越的用户体验。在客户端，包括 Safari、Chrome、Edge 和 Firefox 在内的主流浏览器都默认支持 QUIC。QUIC 可以将端到端应用延迟降低 25-30%，将用户体验从 500 毫秒的迟缓响应转变为 350 毫秒的快速交互。在蜂窝带宽有限、网络质量较差的地区，这种改进尤为重要。 ## NLB QUIC：以直通模式实现最高性能 网络负载均衡器的 QUIC 协议直通模式 (passthrough) 与 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 现有的 QUIC 终止功能相辅相成，让客户可以灵活地在基础设施的边缘和核心优化性能。网络负载均衡器的实现侧重于 QUIC 直通模式，这意味着 NLB 将 QUIC 流量直接转发到目标，而无需终止客户端会话。这种方法带来了几个关键优势： - **最小延迟开销** – 无额外处理延迟 - **高性能** – 数据包级转发，实现最大吞吐量 - **客户可控** – 客户通过对负载进行端到端 TLS 加密，完全控制 TLS 证书和客户端-服务器交互。 - **灵活性** – 客户可以不受负载均衡器限制，继续优化其应用 - **会话粘性** – 使用 QUIC 连接 ID 维持连接连续性，即使会话期间 UDP 5 元组发生变化。 - **健康检查兼容性** – 可与现有的 TCP 健康检查 (Health Checks) 配合使用，简化了从当前架构的迁移。 - **Kubernetes 集成** – 通过 [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/) 支持 [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS) 部署。 - **复用现有指标** – 利用当前的 UDP 指标，并为连接跟踪和路由决策提供额外的 QUIC 特定洞察。详情和建议请参见后面的监控部分。 该功能利用了 [互联网工程任务组 (Internet Engineering Task Force, IETF) 的 QUIC 负载均衡器规范](https://www.ietf.org/)) 。其关键概念是 QUIC 连接 ID (QUIC 的一个标准部分，由服务器软件为客户端生成) 内部编码了一个服务器 ID (Server ID)。NLB 需要一个 8 字节的服务器 ID，客户需要为每个实例进行配置，具体如下文所述。 早期采用者已经看到了显著的好处。一位客户预计在其延迟敏感的搜索服务中节省一个完整的网络往返时间，从而直接提高其移动用户界面的响应速度。在预计每日使用量 145 TB、峰值连接速率每秒 20 万次的情况下，性能提升将转化为可衡量的商业价值。 ## 开始使用 新的和现有的网络负载均衡器均已支持 QUIC。您可以通过 [AWS 管理控制台 (AWS Management Console)](https://aws.amazon.com/console/) 、[CLI](https://aws.amazon.com/cli/) 、[API](https://docs.aws.amazon.com/general/latest/gr/Welcome.html) 或 AWS Load Balancer Controller 启用 QUIC 协议支持。 对于当前使用变通方案或考虑替代方案的客户，NLB 的 QUIC 支持提供了一个原生的 AWS 解决方案，消除了自定义实现的复杂性和额外成本。 要通过控制台开始使用： 1. 转到 EC2，然后选择负载均衡器 2. 点击创建负载均衡器 3. 在网络负载均衡器下点击创建。在下一个屏幕上，当未定义安全组时，您将看到与 QUIC 相关的新选项，如图 1 所示。  图 1: 负载均衡器配置中新增的 QUIC 和 TCP_QUIC 协议选项 您可以选择 QUIC 作为协议类型，它支持标准的基于 UDP 的 QUIC。TCP_QUIC 是一个更好的选择，对于使用 QUIC 支持 HTTP/3 应用的场景，因为它允许您用一个侦听器同时配置 UDP 443 上的 QUIC 和 TCP 443 上的标准 HTTPS 回退服务。 在配置目标组 (target group) 时，您有两个对应的选项：QUIC 和 TCP_QUIC。请确保您的目标组和侦听器匹配。  图 2: NLB 目标组配置，其中高亮显示了新的 QUIC 和 TCP_QUIC 协议选项 完成目标组创建后，您将进入一个“注册目标”屏幕，该屏幕与其他模式略有不同 (图 3)。首先，您必须使用实例 ID (Instance ID) 作为目标类型。其次，QUIC 的一个新参数是服务器 ID：  图 3: 目标组注册屏幕，其中高亮显示了新的服务器 ID 字段。 您需要在这里配置哪个服务器 ID 对应哪个实例。这种机制 (称为明文 CID) 允许 NLB 在不需要您提供解密密钥的情况下路由流量，从而避免了安全风险。NLB 使用服务器 ID (连接 ID 的一部分) 来相应地引导流量。 如果您使用 QUIC 模式，最终的侦听器配置应如下所示 (图 4)：  图 4: 完成的侦听器配置，其中高亮显示了 QUIC 协议和目标组。 请遵循最佳实践，为您的目标 [配置健康检查](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) ，就像使用任何其他 NLB 一样。 在 AWS CLI 或 [AWS SDK](https://aws.amazon.com/what-is/sdk/) 中执行相同的步骤也能达到预期效果： 1. 创建目标组，同样使用 QUIC 或 TCP_QUIC 作为协议： ``` % aws elbv2 create-target-group --name API-QUIC --protocol QUIC --port 443 --vpc-id vpc-1234567890abcdef0 { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0", "TargetGroupName": "API-QUIC", "Protocol": "QUIC", "Port": 443, "VpcId": "vpc-1234567890abcdef0", "HealthCheckProtocol": "TCP", "HealthCheckPort": "traffic-port", "HealthCheckEnabled": true, "HealthCheckIntervalSeconds": 30, "HealthCheckTimeoutSeconds": 10, "HealthyThresholdCount": 5, "UnhealthyThresholdCount": 2, "TargetType": "instance", "IpAddressType": "ipv4" } ] } ``` 2. 创建负载均衡器： ``` % aws elbv2 create-load-balancer --name API-QUIC-LB --subnets subnet-1234567890abcdef0 subnet-1234567890abcdef1 subnet-1234567890abcdef2 --type network --scheme internet-facing { "LoadBalancers": [ { "LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/021345abcdef67890", "DNSName": "API-QUIC-LB-021345abcdef67890.elb.ap-southeast-4.amazonaws.com", "CanonicalHostedZoneId": "Z12345678ABCDEFGHIJK", "CreatedTime": "2025-10-31T02:24:43.514000+00:00", "LoadBalancerName": "API-QUIC-LB", "Scheme": "internet-facing", "VpcId": "vpc-1234567890abcdef0", "State": { "Code": "provisioning" }, "Type": "network", "AvailabilityZones": [ { "ZoneName": "ap-southeast-4a", "SubnetId": "subnet-1234567890abcdef0", "LoadBalancerAddresses": [] }, { "ZoneName": "ap-southeast-4b", "SubnetId": "subnet-1234567890abcdef1", "LoadBalancerAddresses": [] }, { "ZoneName": "ap-southeast-4c", "SubnetId": "subnet-1234567890abcdef2", "LoadBalancerAddresses": [] } ], "IpAddressType": "ipv4", "EnablePrefixForIpv6SourceNat": "off" } ] } ``` 3. 创建侦听器，将 NLB 连接到目标组： ``` % aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/1234567890abcdef0 --protocol QUIC --port 443 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0 { "Listeners": [ { "ListenerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:listener/net/API-QUIC-LB/1234567890abcdef0/abcdef01234567890", "LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/1234567890abcdef0", "Port": 443, "Protocol": "QUIC", "DefaultActions": [ { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0" } ], "TargetGroupStickinessConfig": { "Enabled": false } } } ] } ] } ``` 4. 最后，将您的实例注册到目标组，除了常规条目外，还需使用新的 `QuicServerId` 字段： ``` % aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0 --targets Id=i-1234567890abcdef0,Port=443,QuicServerId=0x1122334455667788 ``` 您可以将同一个实例注册到多个目标组，并为它们使用相同的 `QuicServerId`。不同的实例必须使用不同的 `QuicServerId`。 ## 监控 QUIC 网络负载均衡器提供了新的 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) [指标 (metrics)](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) ，客户应将其添加到监控和告警系统中： - **NewFlowCount_QUIC** – 该指标提供了通过负载均衡器观察到的新发起的 QUIC 流的数量。客户应监控此指标，以发现偏离其工作负载模式的变化。 - **ProcessedBytes_QUIC** – 该指标显示了 QUIC 侦听器处理的总字节数。客户应监控此指标，以发现偏离其基线工作负载模式的变化。 - **QUIC_Unknown_Server_ID_Packet_Drop_Count** – 当负载均衡器收到未在 NLB 注册的服务器 ID 时，该指标会递增。客户应针对此计数的增加设置告警，因为这表明正在生成无效的服务器 ID。当服务器在客户端完成会话之前被注销和移除时，可能会发生递增。 ## 注意事项 - 来自 IETF 的 [QUIC 负载均衡器规范](https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/) (QUIC-LB) 目前处于草案阶段。AWS 基于当前的草案版本提供支持，该版本已稳定数月。从现在到 QUIC-LB 成为 RFC 期间，细节可能会发生变化。请关注该规范，以便实施可能需要的变更。 - QUIC 用于处理单一端口的面向互联网的流量，因此无法在 NLB 前添加额外的安全组。如需进行限制，请在您的服务器软件中实现。 - QUIC-LB 是一项新技术，服务器软件平台尚未在其主代码库中实现它。为了测试此功能，我们使用 AWS 的 [s2n-quic 库](https://github.com/aws/s2n-quic) 及其对自定义连接 ID 生成器的支持，用 [Rust](https://en.wikipedia.org/wiki/Rust_\(programming_language\)) 构建了一个服务器。如果您的用例需要这种级别的自定义，s2n-quic 库是一个很好的起点。一些快速迭代的软件分支也可用于评估，或者您可以询问您的软件供应商何时会增加对 QUIC-LB 的支持。 - 对于网络专业人士，请注意 [QUIC RFC](https://datatracker.ietf.org/doc/rfc9000/) 在 [第 14 节](https://www.rfc-editor.org/rfc/rfc9000.html#name-datagram-size) 中指出，UDP 数据包不能是分片，这降低了实现的复杂性。 - 您的服务器软件将特定的服务器 ID 编码到连接 ID 中，NLB 使用该编码而不是粘性会话或其他技术来将会话绑定到单个目标。请考虑您的应用程序将如何处理故障转移。Amazon 的首席技术官 [Werner Vogels](https://en.wikipedia.org/wiki/Werner_Vogels) 说过：‘任何事情都可能随时发生故障 (Everything Fails All the Time)’。请规划好您的软件如何处理服务器故障或需要更换的情况。 - 此功能在所有 AWS 商业区域和 GovCloud (美国) 区域均受支持。 - 除了标准的 NLB 费用外，使用此功能不收取额外费用。 ## 结论 此次发布表明了 AWS 对支持移动和 Web 应用的承诺。NLB 的 QUIC 协议直通功能与现有的 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) QUIC 终止功能相辅相成，让您可以灵活地在基础设施的边缘和核心优化性能。AWS 提供了交付高质量用户体验所需的工具和服务。Network Load Balancer 对 QUIC 的支持进一步增强了这一能力。 立即在您的网络负载均衡器上启用 QUIC 支持，以提升您的移动应用性能。有关详细的技术规范和实施指南，请访问 AWS [文档](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 。 ## 关于作者  ### Andrew Gray Andrew Gray 是 AWS 的一名首席解决方案架构师，专注于网络架构和工程。凭借在电信和高等教育领域担任首席网络工程师的经验，Andrew 乐于运用其技术专长开发创新的云解决方案。他对解决网络、基础设施和代码交叉领域的复杂挑战充满热情。  ### Milind Kulkarni Milind 是 Amazon Web Services (AWS) 的一名首席产品经理。他在网络、数据中心架构、SDN/NFV 和云计算领域拥有超过 20 年的经验。他是九项美国专利的共同发明人，并合著了三项 IETF 标准。 <!-- AI_TASK_END: AI全文翻译 -->