1.1 解释:CDN 把静态资源分发到靠近用户的边缘节点,减少 RTT(往返时延),缓解源站带宽瓶颈;
1.2 实践意义:对于托管在欧洲某一地区(如德国、荷兰)的 VPS,使用覆盖欧洲的 CDN 点(例如伦敦、阿姆斯特丹、巴黎)能显著缩短加载首字节时间(TTFB)。
2.1 步骤:评估提供商(Cloudflare、AWS CloudFront、KeyCDN、Fastly、BunnyCDN)在目标国家的 PoP(节点)覆盖;
2.2 操作:查看提供商的节点地图、询问最低抖动/延迟的欧洲城市,选择有近源 “POP” 和 “origin shield” 的服务以减少回源流量。
3.1 准备:在现有 DNS 服务中降低 TTL 为 60-300 秒,便于切换回滚;
3.2 切换:在 CDN 控制台添加站点并获取 CDN 指向的 CNAME 或修改 A 记录到 CDN 提供的 IP;验证通过 dig 或 nslookup:例如 dig +short www.example.com。
4.1 Nginx 示例:在 server 块添加缓存头与压缩
4.2 示例代码(直接复制): p: add_header Cache-Control "public, max-age=31536000, immutable"; p: gzip on; gzip_types text/plain text/css application/javascript application/json image/svg+xml; p: brotli on; brotli_types text/plain text/css application/javascript application/json image/svg+xml; (把上面三行分别放到 nginx 配置中相应位置并 reload nginx)。
5.1 步骤:在 CDN 控制台设置缓存行为——静态资源(js/css/img)缓存长 TTL(30天或更长),HTML 页面短 TTL 或不缓存;
5.2 规则示例:在 Cloudflare 建立 Page Rule:匹配 *example.com/*.css 和 *.js,设置 Edge Cache TTL 为 1 month;为 API 路径设置绕过缓存;
5.3 注意:设置 Cache-Control: public/max-age 优先于 CDN 默认策略,确保文件版本化(文件名带 hash)以安全更新缓存。
6.1 在 CDN 中开启 HTTP/2 或 HTTP/3(QUIC),以及 TLS1.3;
6.2 在源站 Nginx 中启用 keepalive、OCSP stapling 与 TLS 配置示例(简化): p: ssl_protocols TLSv1.2 TLSv1.3; ssl_stapling on; keepalive_timeout 65;
7.1 本地构建时:使用 cwebp 或 imagemagick 批量转换并生成 WebP/AVIF 版本,示例命令:cwebp -q 80 input.jpg -o output.webp;
7.2 在 CDN/边缘启用自动图片优化(Cloudflare Image Resizing 或 Cloudinary),并在 HTML 中使用
8.1 使用 curl 测试头信息和 TTFB:curl -w "@curl-format.txt" -o /dev/null -s https://www.example.com (自建 curl-format 显示 time_starttransfer);
8.2 使用 WebPageTest 选择欧盟节点(London/Frankfurt)或 GTmetrix,比较启用 CDN 前后的首字节时间、完全加载时间与请求数;使用 mtr 或 traceroute 检查路由是否走 CDN 边缘。
9.1 Cloudflare:使用 API 清除缓存 p: curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \ -H "X-Auth-Email: you@example.com" -H "X-Auth-Key: API_KEY" \ -H "Content-Type:application/json" --data '{"files":["https://www.example.com/css/app.css"]}'
9.2 CloudFront:使用 AWS CLI 创建 invalidation: p: aws cloudfront create-invalidation --distribution-id XXXXXX --paths "/css/*" "/js/*"
10.1 关键指标:TTFB、First Contentful Paint (FCP)、Largest Contentful Paint (LCP)、总阻塞时间;
10.2 操作:用 CDN 和 APM(如 New Relic 或 Datadog)设置告警,监控边缘命中率(Edge Hit Ratio),当命中率下降时检查 Cache-Control 与 URL 版本化策略。
11.1 若发现回源流量高:检查是否存在动态查询字符串导致无法缓存,或是否未开启 GZIP/Brotli;
11.2 排查命令:curl -I https://www.example.com 查看响应头,确认 x-cache 或 cf-cache-status 等字段表明命中/未命中。
12.1 在构建阶段生成带 hash 的静态文件名(例如 app.abc123.js),把 manifest 写入版本记录;
12.2 部署后自动触发 CDN invalidation 或用版本化避免 invalidation,CI 中加入 Lighthouse 自动化测试并在发布失败时回滚。
答:用 curl 查看响应头(curl -I https://域名),检查常见字段如 CF-Cache-Status、X-Cache、Via 等;使用 traceroute/mtr 对比启用前后路径,或在 CDN 控制台查看边缘命中率与各 PoP 的请求分布。
答:先用 WebPageTest 选择具体城市测试,确认是网络路由问题还是资源未缓存;用 mtr 定位跳数延迟,查看 CDN 是否在该城市有 PoP,必要时启用区域加速或使用多区域负载均衡(GeoDNS 或负载均衡器)。
答:建议在源站启用压缩以便在回源时减少流量,且部分 CDN 在回源请求时会使用源站压缩;同时在 CDN 上启用边缘压缩(如 Brotli)以确保最终用户在边缘收到最优压缩格式。
