CloudFront 部署小指南（十九）：通过“标准化域名”改善互联网用户访问云服务的体验

引言

影响用户访问云服务体验的关键网络因素包括：传输路径、连接质量（延迟/抖动/丢包率）、网络往返次数（Round of Trip）、流量特征以及客户端行为模式。

在这些因素中，往返次数往往被低估，但其影响不容忽视。以具体场景为例：在亚马逊云科技单个 AZ 内部的 2 台 EC2 互访，1ms 的基础延迟（RTT）下，2 次往返仅需 2ms，3 次往返为 3ms，用户几乎无感知差异。

然而，在互联网环境中，假设 client 到 CloudFront CDN POP 的基础延迟达到 100ms 时，情况截然不同：2 次往返变成 200ms，3 次往返则达到 300ms。当单个网页需要建立 100 个网络连接时，这种延迟累积效应会显著影响用户体验。

减少网络往返次数是提升用户体验的有效策略，且不依赖外部网络条件。文中提出的“标准化域名”方案正是针对这一痛点的解决方案，通过优化域名解析和连接复用来减少不必要的往返，从而改善整体网络性能表现。

“标准化域名”实现原理

当客户端发起的 TCP/TLS 请求统一使用不同域名时，即使连接的服务端（如亚马逊云科技 ALB 或者 CloudFront）相同，依然会建立不同的 TCP/TLS 连接；但是当客户端发起的 TCP/TLS 请求统一使用相同域名时，TCP/TLS 连接将会被复用的有效复用。

我们以客户端接入 CloudFront 为例，让我们通过一个具体演示来对比分析：客户端访问多个不同域名资源与访问单一域名下多个资源时，在 TCP 连接建立、TLS 握手和 HTTP 请求过程中产生的网络往返次数差异：

通过 CURL 同时请求 2 个资源，使用不同域名

curl https://<1st domain name>/original.png -o /dev/null --resolve <1st domain name>:<CloudFront POP same IP address> -w "\n ---download_1--- time_connect: %{time_connect} --- time_appconnect: %{time_appconnect} --- \n" --next https://<2nd domain name>/original.png -o /dev/null --resolve <2nd domain name>:<CloudFront POP same IP address> -w "\n ---download_2---  time_connect: %{time_connect} --- time_appconnect: %{time_appconnect} --- \n"

我们会发现每次请求都需要经历 TCP/TLS 建联，连接无法复用。

通过 CURL 同时请求 2 个资源，使用相同域名

curl https://<same domain name>/original.png -o /dev/null --resolve <same domain name>:<CloudFront POP same IP address> -w "\n ---download-- time_namelookup: %{time_namelookup} --- time_connect: %{time_connect} --- \n" --next https://<same domain name>/original.png -o /dev/null --resolve <same domain name>:<CloudFront POP same IP address> -w "\n ---download-- time_namelookup: %{time_namelookup} --- time_connect: %{time_connect} --- \n"

我们会发现第 2 次请求的 TCP/TLS 建联时间是 0，下载速率和首包时延明显加快了。

通过 Chrome 浏览器同时请求 2 个资源，使用不同域名

通过 Chrome 浏览器同时请求 2 个资源，使用相同域名

“标准化域名”改造建议

指向各自的前端子系统；如使用 api.example.com/api_1, api.example.com/api_2 来替代 api_1.example.com 和 api_2.example.com。

前端 workload 可以部署 Amazon CloudFront 来服务这些“标准化域名”的用户接入session，有效地进行 TCP/TLS 连接复用；CloudFront 随后通过识别不同的路径，可以将用户请求引导到对应的前端子系统上，每个前端子系统依旧可以使用原有的域名。

如下图，访问 api.example.com/api_1 的用户请求将会被 CloudFront 引导到 ALB_1 关联的前端子系统上（api_1.example.com ）；访问 api.example.com/api_2 的用户请求将会被 CloudFront 引导到 ALB_2 关联的前端子系统上（api_2.example.com）。

“域名标准化”在 SAAS 场景下的使用

SaaS 服务提供商通常采用多域名策略来区分不同租户，以强化各租户的品牌标识。由于终端用户在特定时间段内通常只访问单一租户的服务，对各租户进行域名标准化改造仍能有效提升用户体验。

此外，SaaS 提供商普遍采用共享后端架构（如 EKS 集群）来统一管理多租户资源。基于这种架构特点，我们可以将域名标准化的优化理念进一步扩展到 CDN 与源站之间的连接层面，通过优化这段链路的延迟来实现整体性能提升。

如上图所示，在 CloudFront SaaS 部署架构中，客户端请求通过 CloudFront 实现从租户专属域名到统一 EKS Ingress 域名的智能路由转换，从而显著提升 CloudFront 与源站之间的连接复用效率。

在这个转换过程中，租户信息通过以下两种方式进行传递：

方式一：路径转换

将租户域名标识（如 tenantx.saas.com ）转换为统一域名下的路径参数（如 www.saas.com/tenantx）
保持租户隔离的同时实现后端连接统一

方式二：Header转换

利用 CloudFront 边缘计算功能，如 CloudFront Function 或者 Lambda Edge等服务将租户域名信息转换为自定义 HTTP Header。
在保持域名标准化的同时，通过 Header 传递租户信息（参考blog）。

总结

在提升互联网用户访问响应速度的优化实践中，减少网络往返次数（RTT）是服务提供商能够直接控制的关键优化手段。尤其在网络延迟较高的地理区域，多次往返产生的累积延迟往往远超服务器实际处理时间，成为性能瓶颈的主要因素。

“域名标准化”通过充分利用 TCP/TLS 连接复用机制，有效减少不必要的网络往返，从而显著改善响应延迟。

消除握手冗余：避免重复执行 TCP 三次握手和 TLS 安全协商流程，减少建连开销
缓解延迟放大效应：在高延迟网络环境中，连接复用的性能提升效果更加显著
优化资源配置：通过减少服务器端并发连接数量，提升整体资源利用效率和系统吞吐能力

当结合 HTTP/2、HTTP/3 或 gRPC 等现代协议的多路复用特性时，连接复用效率得到进一步提升，与域名标准化形成协同效应，实现更高的连接利用率。

亚马逊AWS官方博客