[解决方案] 剖析 Amazon CloudFront 请求的生命周期

**发布时间:** 2025-10-17 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/charting-the-life-of-an-amazon-cloudfront-request/ --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 剖析 Amazon CloudFront 请求的生命周期 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该文档详细阐述了 **Amazon CloudFront** 作为 AWS 原生 **内容分发网络 (CDN)** 服务，处理一个客户端 HTTP(s) 请求的完整生命周期。CloudFront 的核心目标是通过其遍布全球的 **边缘节点 (Points of Presence, POPs)** 和 **区域性边缘缓存 (Regional Edge Caches, RECs)** 网络，缓存内容并加速 Web 应用交付。该解决方案不仅限于静态内容缓存，还集成了地理位置过滤、**AWS WAF** 应用层防火墙、以及通过 **CloudFront Functions** 和 **Lambda@Edge** 实现的边缘计算能力。理解这一系列功能的执行顺序，对于优化应用交付、保障安全和进行故障排查至关重要。该方案适用于需要全球加速、高可用性、DDoS 防护和动态内容处理的各类 Web 应用和服务。 ## 实施步骤 一个典型的 CloudFront 请求生命周期按以下顺序执行： 1. **DNS 解析与连接建立** - 客户端发起 DNS 查询，CloudFront 的 DNS 系统根据网络延迟、负载等因素，返回最优 **POP** 的 IP 地址列表。 - 客户端与选定的 POP 建立 TCP 连接，并根据分发配置中的 **安全策略** 进行 TLS 协商。 - 每个 POP 都内置了 **AWS Shield Standard**，提供基础的 DDoS 攻击（如 SYN 泛洪、UDP 泛洪）防护。 2. **请求路由与验证** - POP 内部的请求路由器将连接负载均衡到多个缓存服务器。 - 在此阶段，系统会进行严格的 **RFC 合规性检查**，确保请求格式正确且无安全威胁，同时根据配置评估地理位置限制。 3. **AWS WAF 安全过滤** - 如果为分发启用了 **AWS WAF**，请求将在任何缓存或业务逻辑处理之前，经过 WAF WebACL 中定义的规则集进行检测，以抵御 SQL 注入、跨站脚本等应用层攻击。 4. **缓存行为 (Behaviors) 匹配** - CloudFront 根据请求的 URL 路径模式匹配预定义的 **行为 (Behaviors)**。 - 行为规则定义了请求应路由到哪个 **源站 (Origin)**、允许的 HTTP 方法、缓存策略、以及哪些请求参数（头、查询字符串、Cookie）应被转发。 5. **边缘计算执行 (Viewer Request 阶段)** - 在查询缓存之前，请求会触发与查看器相关的边缘函数。 - **CloudFront Functions**: 在 POP 上执行的轻量级 JavaScript 函数，适用于高吞吐量、低延迟的场景，如 Header 修改、URL 重写。 - **Lambda@Edge (Viewer Request)**: 如果配置了此触发器，请求会被转发到 **REC**，在 REC 上执行功能更强大的 Node.js 或 Python 函数。 6. **缓存查询 (POP & REC)** - 请求首先在 POP 的多层缓存中查找。如果未命中 (Cache Miss)，请求将被转发到相应的 **REC**。 - REC 作为第二层缓存，拥有更大的缓存容量。它会再次检查缓存。 - 如果配置了 **Lambda@Edge (Viewer Request)**，它会在查询 REC 缓存之前执行。 7. **源站请求与 Origin Shield** - 如果在 REC 中仍未命中缓存，请求将被发往源站。 - 在此之前，会执行 **Lambda@Edge (Origin Request)** 函数，它可以修改发往源站的请求。 - 可选的 **Origin Shield** 功能可以被启用，它作为所有 REC 到源站之间的集中缓存层，进一步减少对源站的请求量。 - REC 或 Origin Shield 与源站之间维持持久连接，以提高数据传输效率。 8. **源站响应与返回路径处理** - 源站处理请求并返回响应。 - 响应沿请求路径反向传递，首先到达 REC 或 Origin Shield。 - **Lambda@Edge (Origin Response)** 函数在响应被缓存前执行，可修改响应头或内容。 - 响应被缓存到 REC 和 POP。 - **Lambda@Edge (Viewer Response)** 和 **CloudFront Functions (Viewer Response)** 函数在响应发送给客户端前依次执行。 - 最终，经过处理和缓存的响应被交付给客户端。 ## 方案客户价值 - **极致的性能加速**：通过全球分布的 POP 和多层缓存架构（POP + REC + Origin Shield），最大化缓存命中率，显著降低用户访问延迟。 - **增强的应用程序可用性与弹性**：CDN 的分布式特性可以吸收流量高峰，而 Origin Shield 等功能可以有效保护源站，防止其因流量过载而崩溃。 - **深度集成的多层安全防护**： - 自动获得 **AWS Shield Standard** 的 DDoS 保护。 - 可与 **AWS WAF** 无缝集成，在边缘抵御应用层攻击，先于业务逻辑执行。 - 支持地理位置限制、字段级加密等多种安全控制。 - **强大的边缘可编程性**： - **CloudFront Functions** 提供低延迟、高性价比的简单逻辑处理能力。 - **Lambda@Edge** 提供更复杂的计算能力，支持在请求生命周期的四个不同节点进行定制化处理，实现如 A/B 测试、高级身份验证、动态内容生成等复杂场景。 - **提升的运营可见性**：可结合 **CloudWatch Network Monitor** 和 **Internet Monitor** 等工具，深入了解应用在公网上的性能和可用性表现。 ## 涉及的相关产品 - **Amazon CloudFront**: 核心 CDN 服务。 - **AWS WAF**: Web 应用防火墙，用于应用层安全防护。 - **AWS Shield**: 托管式 DDoS 保护服务，Standard 版本免费集成。 - **CloudFront Functions**: 在 CloudFront POP 上运行的轻量级边缘计算功能。 - **Lambda@Edge**: 在 CloudFront REC 上运行的边缘计算功能，是 **AWS Lambda** 的扩展。 - **Amazon Route 53**: 可用于源站的 DNS 解析，实现基于延迟或地理位置的智能路由。 - **Amazon CloudWatch**: 用于监控网络性能和可用性。 ## 技术评估 - **优势**: - **分层架构设计清晰**：清晰地划分了 POP 和 REC 的职责，POP 负责处理高频、低延迟的任务（如 TLS 卸载、CloudFront Functions），而 REC 负责处理更消耗资源的任务（如 Lambda@Edge 执行、大容量缓存），架构设计高效且可扩展。 - **灵活的边缘计算选项**：同时提供 CloudFront Functions 和 Lambda@Edge 两种边缘计算模型，满足了从简单请求操纵到复杂业务逻辑的不同需求，为开发者提供了极大的灵活性。 - **安全前置理念**：将 WAF 和 DDoS 防护置于请求处理流程的最前端，确保恶意流量在接触到缓存或应用逻辑之前就被拦截，体现了纵深防御的设计思想。 - **高度可定制化**：通过缓存策略、源站请求策略以及边缘函数的组合，用户可以对请求处理的每一个环节进行精细化控制，以适应复杂的业务场景。 - **可能的限制**: - **配置复杂性较高**：由于功能点众多且执行顺序严格，正确配置 WAF、缓存行为、多种边缘函数及其交互关系需要用户具备深入的理解，学习曲线相对陡峭。 - **故障排查挑战**：请求流经多个逻辑层（POP, REC, WAF, Edge Functions），当出现问题时，定位故障点可能需要综合分析多个服务的日志和指标，增加了排查的复杂性。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 剖析 Amazon CloudFront 请求的生命周期 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/charting-the-life-of-an-amazon-cloudfront-request/](https://aws.amazon.com/blogs/networking-and-content-delivery/charting-the-life-of-an-amazon-cloudfront-request/) **发布时间:** 2025-10-17 **厂商:** AWS **类型:** BLOG --- [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 是一款原生的 AWS 内容分发网络 (Content Delivery Network, CDN) 服务。CDN 通过一个遍布全球、更靠近终端用户的边缘站点网络来加速 Web 内容分发，并在边缘缓存内容。然而，CloudFront 的功能远不止于此，它还具备在边缘进行地理位置筛选 (geo-filtering)、执行函数、执行 [AWS Web Application Firewall (WAF)](https://aws.amazon.com/waf/) 过滤等多种功能。在本文中，我们将探讨客户端请求在 CloudFront 分配中的完整生命周期，并特别关注这些功能的执行顺序。理解这一过程对于优化您的 Web 应用程序交付、保护 Web 应用程序以及对 CDN 配置进行故障排查至关重要。 在开始这段旅程之前，我们可以先了解一下 CloudFront 客户端请求所涉及的基础设施组件。  *图 1: CloudFront 边缘站点和区域性边缘缓存* ## 边缘缓存概述 CloudFront 接入点 (Points of Presence, POP), 也称为边缘站点 (Edge locations), 是请求命中的第一组服务器，它们负责响应请求 (如果已缓存) 或将其转发到下一层。它们在全球范围内分布，其规模比传统的 [AWS 区域 (AWS Region)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 要小。为了逻辑清晰和组织有序，您可以将一个 POP 视为一个独立的逻辑单元。图 1 (引自 CloudFront 官方文档) 说明了这一点。 这种简化的模型运作良好，但有时我们可能需要更深入地研究请求-响应流程，以排查 CDN 配置问题、优化缓存或提高动态内容交付性能。我们注意到，查看器的请求和响应路径在 CloudFront 网络中遵循不同的层次。POP 负责初始连接处理、请求负载均衡、缓存和 [CloudFront Functions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) 的执行，而区域性边缘缓存 (Regional Edge Caches, REC) 则负责更多的缓存优化、[Lambda@Edge](https://aws.amazon.com/lambda/edge/) 的执行、边缘到源的连接、请求折叠以及源超时配置。您可以启用可选的 Origin Shield 功能来提高缓存效率。 除了 HTTP(s) 协议，CloudFront 还支持对该协议的增强，例如 [gRPC](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-using-grpc.html) (一个构建在 HTTP/2 之上的开源远程过程调用 (remote procedure call, RPC) 框架) 和 [Web Sockets](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.websockets.html) (一种基于 TCP 的协议，适用于客户端和服务器之间需要持久连接以支持实时应用的长连接场景)。 本文我们只关注 HTTP(s) 请求和响应的处理，将在后续文章中探讨 gRPC 和 Web Sockets 连接。 ## DNS 解析和 POP 我们的旅程从用户访问一个由 CloudFront 提供支持的网站开始，如下图所示。网站通常会使用一个 [自定义主机名 (custom hostname)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LinkFormat.html#LinkFormat_OwnDomain) 指向一个特定的 CloudFront 域名。CloudFront 根据 DNS 请求确定用户的位置，并返回一个包含处理该请求的最佳边缘站点的 DNS 响应。CloudFront 使用多项指标，如互联网网络健康状况、网络负载和其他因素，为查看器提供最佳 POP 的多个 IP 地址。根据终端用户的位置，您可以选择限制响应请求的基础设施，从而节省成本并使用不同的定价等级 (Price Classes)。CloudFront 分配中选择的定价等级会限制用户可用的 POP 列表。用户可以利用 [CloudWatch Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Network-Monitoring-Sections.html) 和 [CloudWatch Internet Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html) 的功能，来获得对托管在 AWS 上的应用程序的网络和互联网性能及可用性的运营可见性。 如果用户使用的是带有 [Anycast 静态 IP (Anycast static IPs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/request-static-ips.html) 的 CloudFront, 那么通过 DNS 解析确定理想 CloudFront POP 的过程会有所不同。本文假设使用的是非 Anycast IP。  *图 2: CloudFront 请求的路径* ### 连接建立和 TLS 协商 当 DNS 解析完成后，客户端应用程序 (Web 浏览器或移动应用，称为查看器 (viewer)) 会收到一组最佳 POP 的 IP 地址。客户端应用程序使用其中一个 IP 地址向 POP 发起连接，并在需要时可以使用其他任何 IP 地址进行故障转移。根据 IETF 标准，CloudFront 在端口 80/443 上 [接受](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValuesSupportedHTTPVersions) HTTP、HTTPs 和 WebSockets。每个 POP 都具备 [AWS Shield Standard](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-standard-summary.html) 防护，可抵御常见的 DDoS 容量攻击 (如 UDP 洪水、SYN 洪水)。下一层确保安全套接字层 (Secure Sockets Layer, SSL)/传输层安全 (Transport Layer Security, TLS) 连接正确建立。为 CloudFront 分配 [配置的安全策略 (security policy)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValues-security-policy) 指定了可接受的协议和加密套件。 ### 请求路由和验证 请求被移交给请求路由器。POP 处的请求路由器将客户端连接负载均衡到多个缓存服务器上。这里还有一个关键的安全层，它通过确保客户端请求符合 [请求评论 (Requests for Comments, RFC)](https://www.ietf.org/process/rfcs/) 规范且不构成任何非法/模糊语法的威胁，来监控和保护缓存服务器。该层确保转发到缓存层的请求格式正确且符合 HTTP 规范。此时，系统会根据 CloudFront 分配的配置评估可接受的协议、动词和地理位置限制。 ### AWS WAF 在请求负载均衡和预访问安全检查之后，如果为 CloudFront 分配启用了 AWS WAF, 那么请求将通过 AWS WAF Web 访问控制列表 (Web Access Control List, WebACL) 中启用的规则进行处理。AWS WAF 是一种 Web 应用程序防火墙，它监控对您应用程序的请求，以保护它们免受应用层攻击 (application layer attacks), 如 SQL 注入 (SQL injection)、跨站脚本 (cross-site scripting)、机器人攻击 (bot attacks) 或 DDoS 攻击。AWS WAF 总是在任何内容处理规则 (如缓存行为、请求/响应头策略) 或边缘计算函数 (如 CloudFront Functions 或 Lambda@Edge) 之前执行。 ### 行为 此时，用户可以在行为 (Behaviors) 部分定义 CloudFront 处理请求的方式。对于不同的路径模式 (path patterns), 行为可以有所不同。行为指定了要使用的源、允许的 HTTP 方法、缓存策略 (cache policy)、函数关联以及源请求策略 (origin request policy), 后者决定了哪些参数 (标头、查询字符串和 Cookie) 会被转发到源。用户还可以配置字段级加密 (field-level encryption) 来保护敏感信息。 ### 边缘函数 在查看器端 (缓存之前), 用户可以在两种类型的边缘函数之间进行选择：CloudFront Functions 或 Lambda@Edge。CloudFront Function 是一个在 POP 上执行的无服务器函数。CloudFront Functions 是用于大规模、延迟敏感的 CDN 定制化的轻量级 JavaScript 函数。Lambda@Edge 是 [AWS Lambda](https://aws.amazon.com/lambda/) 的扩展，它可以在 REC 上执行 Node.js 或 Python 函数。如果 CloudFront 分配配置了查看器端的 Lambda@Edge 代码，那么请求将被转发到 REC。Lambda@Edge 始终在 REC 上执行。对于 PUT、POST 和 DELETE 等 HTTP 方法也是如此，因为它们是动态请求。查看器请求函数可以修改所有现有的源能力，例如主源、自定义标头和超时。执行发生在第一个缓存层之前，这意味着它们会对每个请求都执行。 ### CloudFront 缓存 在 CloudFront Functions 查看器请求 (如果有的话) 之后，CloudFront 会查询 POP 上的缓存。在一个 POP 内部有多个缓存层，以最大化缓存命中率 (cache-hit ratio)。如果第一层缓存中没有对象，请求将被转发到下一层，依此类推。我们不能有无限数量的层，因此每个缓存堆栈中的缓存服务器数量或第一层所能触及的对等节点数量是有限的。如果 POP 内的最后一层缓存中没有对象，请求将被转发到 REC。 ### REC REC 具有类似的缓存层，以提高缓存覆盖范围、容量，并提供执行 Lambda@Edge 函数所需的计算基础设施。REC 作为 POP 和源之间的二级宏观缓存层，进一步提高缓存命中率，减少对源的请求，并作为 Lambda@Edge 代码执行的基础设施。 如果您定义了一个 Lambda@Edge 查看器请求函数，那么它将在此刻执行，即在 CloudFront 查看 REC 中的缓存之前。之后，如果对象在 REC 缓存中未找到，则任何 Lambda@Edge 源请求函数都将被执行。 如果 CloudFront 分配启用了 [Origin Shield](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html), 所有 REC 在向源发送请求之前都会连接到 Origin Shield, 从而减轻源的负载。Origin Shield 位于更靠近用户源的位置，通过减少到源的流量带宽和请求量来提高缓存效率。 源连接端的最后一层 (REC 或 Origin Shield) 与内容源保持持久连接，以实现高数据传输效率。源 [超时设置](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesOrigin.html#origin-connection-timeout) (针对自定义源) 允许用户调整以下值： 1. **连接尝试次数：** 您可以设置 CloudFront 尝试连接到源的次数。 2. **连接超时：** CloudFront 在尝试建立与源的连接时等待的秒数。 3. **响应超时：** CloudFront 在将请求转发到源后等待响应的时间，以及 CloudFront 在从源接收到一个响应数据包后到接收下一个数据包之间等待的时间。 [源请求策略](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValues-security-policy) 还决定了边缘在连接到源时使用的最低 SSL 版本。 ### 源响应 如果请求在任何缓存层、REC 或 Origin Shield 中都未找到，它将从源获取。源是一个可通过公共 IP 访问的资源，但如果与 [VPC 源 (VPC origins)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html) 结合使用，它也可以是私有资源。如果源是一个 URL, 那么 DNS 解析将在此刻进行。这使您可以使用 [Amazon Route 53](https://aws.amazon.com/route53/) 的路由策略，例如基于延迟的路由 (latency-based routing) 或地理位置路由 (geolocation routing), 来确定要使用的位置。 响应沿着请求路径反向进行。来自源的响应被发送回 REC。如果请求是可缓存的并且启用了压缩，响应将被压缩。缓存持续时间通过 CloudFront 行为的缓存策略进行管理。如果定义了 Lambda@Edge 源响应代码，它将在此刻执行，并在 REC 进行缓存。如果定义了 Lambda@Edge 查看器响应函数，它将被执行。出于安全原因，在响应上执行的函数无权读取响应体，但可以替换它。旅程继续在 POP 进行。如果定义了 CloudFront Functions 查看器响应函数，它将在 POP 执行，最终的资产将被交付给客户端。图 2 总结了请求/响应旅程中的主要步骤。 ## 结论 在本文中，我们跟踪了一个从查看器到 Amazon CloudFront, 再到源服务器，以及从源服务器返回查看器的单个请求的旅程，从而探讨了 CloudFront 提供的不同层和功能。 现在您对执行顺序以及每个特性/功能所在的位置有了更好的理解，我们鼓励您审查您的 CloudFront 配置，包括缓存设置、边缘函数、AWS WAF 和 AWS Shield, 并充分利用 CloudFront CDN 的强大功能。 ## 关于作者  ### Sanchith Kandaka Sanchith 在内容分发和应用安全领域拥有超过 15 年的经验，对所有与边缘相关的事物充满热情。他曾担任解决方案架构师和解决方案工程师，目前是 AWS 的一名专家级解决方案架构师，专注于 AWS 边缘服务和边界保护服务，包括 Amazon CloudFront、AWS WAF 和 AWS Shield。  ### Jorge Prado Jorge 是 AWS 在北卡罗来纳州的一名高级技术客户经理。他热衷于帮助企业支持客户找到合适的解决方案并实现卓越运营。他的重点是网络技术。在业余时间，他喜欢阅读、看电影以及和孩子们一起玩视频游戏。 <!-- AI_TASK_END: AI全文翻译 -->