CDN 带来这些性能优化
Category（分类）: Other Status: 已核查
前言
CDN 的全称是 Content Delivery Network，即内容分发网络。它通过分布在不同网络位置的边缘节点，为用户提供内容缓存、传输和安全能力。节点如何选择由 DNS、Anycast、路由、运营商、负载和健康状态等共同决定，因此“就近”通常是调度意义上的就近，不一定是地理距离最近。——根据 RFC 9111 及 CDN 公共文档整理
内容已经发布在 GitHub 了，欢迎围观 Star，更多文章都在 GitHub。
CDN 存在的意义：
在访问量较大时，把可缓存内容分散到网络边缘，减少用户到源站的距离和链路拥塞。
举个例子
在讲 CDN 之前我们先看个生活实例：
在淘宝购物
大部分个人卖家只在一个地方发货，江浙沪以外的地方收货可能较慢。
在京东购物
购买京东自营产品时，系统会根据收货地点、库存和物流能力选择仓库。这个比喻有助于理解 CDN 的分发思想，但 CDN 并不是简单地把每个文件永久复制到所有节点：边缘节点通常按需缓存，是否缓存、缓存多久以及是否回源由响应头和 CDN 配置决定。
CDN 的优势与边界
- 合理调度时可以减少跨运营商、跨地域访问带来的延迟；
- 缓存命中时请求在边缘节点完成，可以减轻源站负载并节省回源带宽；
- 可以结合 TLS、HTTP/2、HTTP/3、压缩、Range 请求、图片处理、WAF 和 DDoS 防护等能力。
CDN 并不保证所有请求都更快。低命中率、动态请求、频繁失效、回源很慢、边缘节点不理想或连接/TLS开销较高时，CDN 可能收益有限，甚至增加成本。应通过缓存命中率、回源耗时、Server-Timing、浏览器 Network Timing 和真实用户监控（RUM）验证效果。
CDN 的核心点可以概括为：缓存、调度和回源；DNS 解析负责找到服务入口，HTTP 缓存则负责内容能否被复用，两者不是同一个过程。
缓存
CDN 不是“从根服务器请求资源”。DNS 根服务器只参与部分域名解析链路，不提供网页文件。HTTP 请求到达边缘节点后，节点会按缓存键（通常包含 URL，可能还包含请求头、查询参数、Cookie 等）查找响应：命中时直接返回，未命中时向源站或上游缓存回源，再根据 HTTP 缓存策略决定是否存储。
常见响应头包括：
Cache-Control: max-age=86400：在指定时间内通常可以直接复用；只有确认响应可以在用户之间安全共享时，才使用public，共享缓存的独立时长还可以用s-maxage表达；ETag、Last-Modified：过期后可携带If-None-Match或If-Modified-Since重新验证，源站可返回304 Not Modified；Vary：声明哪些请求头会影响响应，配置不当会降低命中率或造成内容混用；Age：共享缓存中响应的大致存放时间。CDN 还可能提供命中/回源等诊断响应头。
no-cache 不等于“不缓存”，而是复用前必须重新验证；no-store 才表示不应存储响应。带有用户私密数据、授权信息或个性化 Cookie 的响应不应仅凭经验放入共享缓存。
回源
当用户请求的资源未命中、已过期且无法直接使用，或被主动刷新时，边缘节点会向源站或上游节点获取响应。传统的按需缓存通常由请求触发回源，但预热、主动刷新、分层缓存和 stale-while-revalidate 等能力可能在没有当前用户请求时拉取或异步更新，因此“没有人访问就绝不会回源”不是 CDN 的通用规则。
关键技术
以下是传统 CDN 资料常用的分类，部分术语属于特定厂商或早期网络环境，不能视为现代 Web CDN 的统一必选技术：
- 内容发布：通过缓存、分层缓存、对象存储同步、压缩和媒体处理，把内容提供给多个 POP（Point of Presence）；组播（Multicast）更常用于特定网络分发场景，并非普通 Web CDN 的必要条件；
- 内容路由：通过 DNS、Anycast、HTTP 重定向或应用层调度，在多个 POP 间选择合适的服务入口；
- 内容交换：根据缓存键、内容可用性、节点健康度、负载和用户网络环境处理请求。ICP、WCCP 等是历史上出现过的重定向/交换技术，不应与现代 CDN 能力混为一谈；
- 性能与安全管理：监控可用性、丢包、延迟、吞吐和首字节时间，并结合 TLS、访问控制、WAF、DDoS 防护和日志分析进行治理。
前端工程师不必运营 CDN，但应理解资源 URL、缓存策略、失效机制和监控指标，避免把“上 CDN”当成无需验证的性能开关。
CDN & 静态资源
静态资源通常具有访问频率高、内容相对稳定、承接流量大的特点，因此 JS、CSS、字体、图片、视频等资源经常适合使用 CDN。带内容哈希的文件名（如 app.8f3a.js）可以配合较长的 max-age，更新时生成新 URL；HTML、接口响应和用户专属内容则应单独设计缓存策略。
京东
掘金
这些截图是历史示例，当前站点的域名和请求策略可能已经变化。判断是否使用 CDN 应查看响应头、请求链路和命中率，而不是只看域名。
一个常见的静态资源响应示例：
Cache-Control: public, max-age=31536000, immutable
ETag: "8f3a-asset"
Vary: Accept-Encoding
只有当资源确实不可变、没有用户隐私内容且失效通过新 URL 完成时，才适合使用很长的缓存时间。
CDN & Cookie
Cookie 与域名、路径、Secure、SameSite 以及 Domain 属性有关，并不是“同一个域名的所有请求必然携带同一个 Cookie”。例如静态资源使用 static.example.com 时，如果 Cookie 仅设置在 www.example.com，通常不会发送；但如果主站设置了 Domain=.example.com，子域名仍可能携带该 Cookie。
静态资源往往并不需要 Cookie。
将静态资源放在独立域名可以减少无关 Cookie，并让缓存键更简单，但要同时检查：
- 不要为整个父域设置不必要的宽域 Cookie；
- 跨源字体、脚本或图片可能需要正确的 CORS 和 CSP；
- 第三方 CDN 会引入供应链、隐私、缓存污染和可用性风险，应优先使用可信来源并固定版本；
- 不要把含认证信息的请求或响应误配置为共享缓存。
参考资料
原文作者：小生方勤，来源：稀土掘金。本文保留其生活类比和历史截图，并对协议语义和现代实践作了补充。