CDN加速原理与配置实战

从GSLB到边缘计算：CDN架构演进与核心原理

我去年接手了一个跨国SaaS服务的性能优化项目，用户遍布北美、欧洲和东南亚，源站部署在AWS us-east-1。当时最头疼的问题是：新加坡用户访问仪表盘，首屏加载时间稳定在1.2秒以上，其中TCP握手和TLS协商就占了400ms。我意识到单纯优化源站代码已经到瓶颈，必须依赖CDN的网络层优势。

CDN的核心调度机制是全局负载均衡（GSLB）。我通过dig命令分析过我们使用的Akamai CDN的调度逻辑：当用户在新加坡发起请求，权威DNS服务器会返回距离最近的边缘节点IP（通常是新加坡本地节点）。GSLB不仅看地理位置，还会实时检测节点健康度。有一次我们雅加达节点因为光缆故障出现高延迟，GSLB在TTL过期后的下一次调度中自动将流量切到了新加坡节点，这个过程对业务是透明的。

边缘缓存是静态资源加速的基础。我在配置Nginx源站时，针对构建产物设置了明确的缓存头：

# 源站Nginx配置片段
location /static/ {
    # 针对构建哈希后的文件，设置长达1年的强缓存
    if ($request_filename ~* .*\.[a-f0-9]{8,}\.(js|css|png|jpg)$) {
        add_header Cache-Control "public, max-age=31536000, immutable";
        # 原因在于：文件名带哈希意味着内容不可变，浏览器无需验证，直接缓存
    }
    # 普通静态资源缓存7天
    add_header Cache-Control "public, max-age=604800";
    # 开启Brotli压缩，比Gzip平均再小15%-20%
    brotli on;
    brotli_comp_level 6;
}

动态加速的原理完全不同。对于我们的API接口（如/api/v1/order/status），CDN节点不会缓存内容，而是建立一条优化的传输通道。我通过curl测试过路径优化效果：从上海直连us-east-1的API，RTT约220ms；经过Cloudflare Argo Smart Routing后，RTT降至160ms。原因在于CDN厂商拥有专线的内部骨干网，避免了公网路由的绕行和拥塞。

协议优化是2023-2024年的重点。我们现在全面开启了HTTP/3 (QUIC)。QUIC基于UDP，解决了HTTP/2的队头阻塞问题。我在Cloudflare后台开启HTTP/3后，客户端支持的情况下，首屏时间进一步降低了。但需要注意，部分企业内网会封锁UDP 443端口，导致HTTP/3握手失败回退到HTTP/2。解决方案是在应用层做好降级兼容，不要强制依赖HTTP/3特性。

边缘计算是架构演进的最新阶段。我们曾有一个需求：需要根据用户的Accept-Language请求头，在响应中注入不同的Content-Language。传统做法是源站Nginx用map指令处理，但这增加了源站逻辑。我将其迁移到了Cloudflare Workers上：

// Cloudflare Worker脚本
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // 1. 先尝试从边缘缓存获取静态资源
  const cache = caches.default;
  let response = await cache.match(request);

  if (!response) {
    // 2. 未命中则回源
    response = await fetch(request);
    // 克隆响应，因为Response Body只能读一次
    let newResponse = new Response(response.body, response);
    
    // 3. 边缘逻辑：根据Header注入语言标签
    const lang = request.headers.get('Accept-Language') || 'en';
    newResponse.headers.set('Content-Language', lang.split(',')[0]);
    
    // 4. 如果是GET请求且状态码200，缓存起来
    if (request.method === 'GET' && newResponse.status === 200) {
      // 缓存时间5分钟，原因在于：语言偏好变化不频繁，但需保持一定新鲜度
      newResponse.headers.set('Cache-Control', 'public, max-age=300');
      event.waitUntil(cache.put(request, newResponse.clone()));
    }
    return newResponse;
  }
  
  // 命中缓存，直接返回
  return response;
}

这个Worker脚本运行在Cloudflare全球300多个节点上，冷启动时间通常在5ms以内（基于2024年的运行时数据）。我选择边缘计算而非源站处理的原因在于：这减少了源站的计算负载，且逻辑更贴近用户，修改逻辑只需发布Worker，无需重启源站服务。

实战复盘：百万日活电商大促，CDN静态与动态加速配置全记录

我负责过一家日活约150万的跨境电商平台的大促保障。大促前压测时，我们发现商品详情页的加载时间随着并发增加从500ms飙升到2s以上，核心瓶颈在于源站带宽被打满和数据库查询压力。解决方案是重构CDN策略，将静态和动态内容分离处理。

静态资源加速配置相对直接，但细节决定成败。我们的前端是Vue SPA，构建后会生成带哈希的文件名（如app.8f3a9b.js）。我配置阿里云CDN时，针对这类文件设置了忽略参数缓存，并强制长缓存。原因在于：哈希值变了，URL就变了，旧文件自然失效，无需源站验证。

# 阿里云CDN API 配置缓存规则 (使用CLI工具)
# 针对带哈希的静态资源，缓存时间365天
aliyun cdn AddCdnDomainConfig --DomainName www.example.com --Functions '[{"functionArgs":[{"argName":"cache_ttl","argValue":"31536000"},{"argName":"file_type","argValue":"js,css,png,jpg,webp,gif"},{"argName":"weight","argValue":"50"}],"functionName":"cache_expires"}]'

# 针对HTML文件，设置不缓存或短缓存，确保用户能拿到最新的入口文件
aliyun cdn AddCdnDomainConfig --DomainName www.example.com --Functions '[{"functionArgs":[{"argName":"cache_ttl","argValue":"0"},{"argName":"file_type","argValue":"html,htm"},{"argName":"weight","argValue":"10"}],"functionName":"cache_expires"}]'

动态加速的配置更为关键。商品详情页的库存、价格接口（/api/sku/info）必须实时。我采用了全站加速（DCDN）模式，即动态路径也走CDN的优化链路。配置时，我设置了回源超时时间和重试策略。

有一次线上故障排查让我印象深刻：大促开始后的第10分钟，监控显示/api/sku/info接口的错误率突然从0.1%飙升到5%。我通过CDN的实时日志发现，错误集中在几个特定的边缘节点，返回的是502 Bad Gateway。原因在于这些节点到源站的链路出现了瞬时的丢包，而CDN默认的回源超时是30秒，导致大量请求堆积。

解决方案是调整回源配置：

// 阿里云DCDN 回源配置策略 (通过OpenAPI设置)
{
  "DomainName": "www.example.com",
  "DynamicOrigin": {
    "OriginTimeout": 5, // 将回源超时从30s降至5s，原因在于：API响应通常应在100ms内，5s足够容错，过长会占用连接资源
    "RetryCount": 2,    // 失败重试2次
    "RetryCondition": "5xx", // 仅对5xx错误重试
    "OriginSni": {
      "Enabled": true,
      "Value": "origin-api.example.com" // 回源时携带SNI，确保源站Nginx能正确匹配SSL证书
    }
  }
}

调整配置后，错误率迅速回落。原因在于：缩短超时时间让CDN节点能快速释放无效连接，重试机制则规避了偶发的节点抖动。

安全防护也是CDN配置的重点。我们开启了WAF和CC防护。大促期间，我们检测到针对登录接口的CC攻击，峰值达到5万次/秒。CDN的清洗中心在边缘就拦截了这些恶意流量，没有打到源站。我配置了一条自定义规则，对/login接口限制单一IP每秒最多10次请求，超出则返回验证码挑战。

# 源站Nginx配置，配合CDN的Real-IP传递
set_real_ip_from 0.0.0.0/0; # 信任CDN节点的IP段，生产环境应填写具体CDN IP段
real_ip_header X-Forwarded-For;
real_ip_recursive on;

location /login {
    # 限制请求频率，作为CDN防护后的第二道防线
    limit_req zone=login_limit burst=20 nodelay;
    proxy_pass http://backend;
}

缓存过期策略的优先级我也踩过坑。HTTP头中Cache-Control的优先级高于Expires，而ETag/Last-Modified是协商缓存。我曾在源站同时设置了Cache-Control: max-age=3600和Expires: Thu, 01 Dec 2024 16:00:00 GMT，结果浏览器优先使用了Cache-Control。原因在于RFC规范定义Cache-Control是HTTP/1.1标准，优先级更高。现在的做法是：静态资源只使用Cache-Control，并配合文件名哈希；API接口如果需要缓存，使用Cache-Control: no-cache强制协商，或者max-age=0, must-revalidate。

性能对决：开启HTTP/3与Brotli压缩后的真实压测数据对比

为了验证协议和压缩算法的实际收益，我在今年3月对一个真实的生产环境（电商商品详情页）进行了严格的A/B测试。测试环境模拟了跨地域访问：压测机位于上海，源站位于AWS us-west-2（俄勒冈），CDN节点使用Cloudflare（洛杉矶节点）。

测试对象与配置

我准备了四组配置进行对比：

基线组：HTTP/2 + Gzip (压缩级别6)
压缩优化组：HTTP/2 + Brotli (压缩级别5)
协议优化组：HTTP/3 (QUIC) + Gzip
全优化组：HTTP/3 + Brotli

压测工具与参数

我使用wrk进行压测，模拟200个并发连接，持续压测60秒。测试页面是一个包含完整HTML、内联CSS和JS的商品详情页，原始大小约85KB。

# wrk 压测命令示例
# 测试HTTP/2 + Gzip (基线)
wrk -t4 -c200 -d60s --latency -H "Accept-Encoding: gzip, br" https://www.example.com/product/12345

# 测试HTTP/3 + Brotli (全优化)
# 注意：wrk原生不支持HTTP/3，我使用了支持QUIC的h2load进行补充测试
# h2load 命令示例
h2load -n 100000 -c 200 -t 4 --h3 https://www.example.com/product/12345

真实数据对比

| 测试组 | 协议 | 压缩 | 首字节时间 (TTFB) | 完整加载时间 (LCP) | 传输体积 | 连接建立耗时 |

| :--- | :--- | :--- | :--- | :--- | :--- | :--- |

| 基线组 | HTTP/2 | Gzip | 185ms | 420ms | 28.5 KB | 140ms (TCP+TLS1.3) |

| 压缩优化组 | HTTP/2 | Brotli | 180ms | 395ms | 22.1 KB | 140ms |

| 协议优化组 | HTTP/3 | Gzip | 160ms | 350ms | 28.5 KB | 80ms (QUIC握手) |

| 全优化组 | HTTP/3 | Brotli | 155ms | 320ms | 22.1 KB | 80ms |

数据分析与结论

Brotli压缩的收益：在HTTP/2环境下，Brotli相比Gzip减少了约22%的传输体积（从28.5KB到22.1KB）。原因在于Brotli使用了更先进的上下文建模算法，对文本类资源（HTML/JS/CSS）的压缩效率更高。这直接导致了LCP时间从420ms降到了395ms，虽然绝对值不大，但在弱网环境下，减少6KB可能意味着减少一个RTT。

HTTP/3 (QUIC) 的收益：最显著的提升在于连接建立耗时。HTTP/2基于TCP，需要TCP握手（1-RTT）和TLS握手（1-2 RTT），在跨太平洋网络下，光握手就可能消耗150ms以上。HTTP/3的QUIC协议结合了加密和传输握手，通常只需1-RTT甚至0-RTT（连接迁移时）。我的测试数据显示，连接建立耗时从140ms降到了80ms，TTFB相应降低了25ms。原因在于QUIC避免了TCP的队头阻塞，丢包时只影响单个流，不影响其他流的数据传输。

组合效应：全优化组表现最好。但我也发现一个现象：在丢包率较高的网络下（我通过tc命令人为添加了2%的丢包模拟弱网），HTTP/3的优势更加明显。HTTP/2在丢包时，整个TCP连接都会受阻，导致页面加载时间飙升至800ms以上；而HTTP/3在同样丢包率下，LCP仅增加到450ms左右。

实际部署中的取舍

我在部署HTTP/3时遇到了一个实际问题：部分企业用户的防火墙策略严格限制了UDP流量。有一次，一家合作企业的员工反馈无法访问我们的网站，报错是ERR_QUIC_PROTOCOL_ERROR。排查后发现，他们的企业网关丢弃了UDP 443端口的包。

解决方案是渐进式开启。我在CDN配置中设置了HTTP/3为"可选"而非"强制"。浏览器会先尝试HTTP/3，如果握手失败（通常是由于UDP被封），会自动回退到HTTP/2。

// 前端监控代码片段，用于收集真实用户的协议使用情况
if (navigator.connection && navigator.connection.effectiveType) {
  const protocol = performance.getEntriesByType('navigation')[0]?.nextHopProtocol;
  // 上报数据到监控平台
  fetch('/api/log', {
    method: 'POST',
    body: JSON.stringify({
      protocol: protocol, // 可能是 "h3-29", "h2", "http/1.1"
      rtt: navigator.connection.rtt,
      downlink: navigator.connection.downlink
    })
  });
}

通过一周的数据收集，我发现约92%的用户成功使用了HTTP/3，剩下的8%主要是企业内网、特定移动运营商网络。这验证了"可选开启"策略的正确性。对于这8%的用户，他们自动降级到了HTTP/2，体验依然有保障。

关于eBPF的观察：在2024年的开发者社区中，eBPF在CDN节点内部的应用是个热门话题。虽然我没有直接编写eBPF程序，但在与Akamai的技术交流中了解到，他们正在利用eBPF优化节点内的网络包处理和可观测性，这能进一步降低节点内部的处理延迟。这也是我选择主流CDN服务商的原因之一：他们能更快地应用这类底层技术革新。

4. 避坑指南：一次因Cache-Control配置错误引发的线上回源雪崩排查

去年双十一大促前夜，我正盯着监控大屏喝着咖啡，突然收到告警：源站Nginx的CPU飙到98%，数据库连接池被打满，QPS从平时的2000骤降到不足200。当时我们的电商系统刚把商品详情页接入CDN，我第一反应是缓存失效了，但看了眼CDN控制台的命中率——只有12%，这明显不正常。

先解释下背景：我们的商品详情页是前后端分离架构，前端SPA打包后的静态资源（JS/CSS/图片）放在对象存储，通过CDN分发。当时为了赶进度，我直接复制了之前博客项目的CDN配置，在源站Nginx里加了这么一段：

location ~* \.(js|css|png|jpg)$ {
    add_header Cache-Control "max-age=0, no-cache, no-store, must-revalidate";
    add_header Pragma "no-cache";
    add_header Expires "0";
}

现在回想起来，这就是灾难的起点。当时我心想"反正商品信息更新频繁，缓存时间短点保险"，但完全没考虑CDN的工作机制。当CDN节点收到这个响应头时，会认为这些资源"绝对不能缓存"——max-age=0表示缓存立即过期，no-cache要求每次必须向源站验证，no-store直接禁止任何缓存存储。

结果就是：大促期间用户每秒发起5000+次商品页请求，CDN节点发现本地没有有效缓存，全部转回源站拉取资源。源站Nginx处理一个静态文件请求平均需要15ms（因为要走对象存储API），5000 QPS直接把CPU打满，响应时间从50ms飙升到2秒以上，大量请求超时。更糟的是，数据库因为部分动态接口被拖慢，也出现了慢查询堆积。

排查过程花了40分钟。我先看了CDN的访问日志，发现90%的请求都带了MISS标识（缓存未命中）；再对比源站日志，发现同一资源被不同CDN节点重复拉取——比如product-123.js在1秒内被上海、北京、广州的节点各请求了3次。这时候才意识到是缓存头的问题。

紧急修复时，我做了两件事：第一，把静态资源的Cache-Control改成max-age=86400, public（缓存24小时），对需要实时更新的商品图片，单独加了版本号（比如product-123_v2.jpg）；第二，在CDN控制台开启了"忽略源站缓存头"的临时开关，强制缓存1小时。修改后10分钟，CDN命中率回升到92%，源站CPU降到15%，接口响应时间恢复到80ms以内。

这里有个细节要注意：Cache-Control的优先级比Expires和Last-Modified高。当时我一开始还想用Expires设置过期时间，但浏览器和CDN都会优先看Cache-Control。另外，no-cache不是"不缓存"，而是"缓存但必须验证"，如果配合ETag使用，其实能减少回源流量——但我当时直接用了no-store，彻底堵死了缓存的可能性。

后来我们复盘，给团队定了个规则：静态资源缓存时间至少7天，更新时通过文件名哈希（比如app.8f3a2b.js）而不是改缓存头。现在我们的CDN配置里，静态资源缓存头是这样的：

location ~* \.(js|css|png|jpg|gif|ico|svg)$ {
    # 哈希命名的资源缓存1年，非哈希的缓存7天
    if ($request_filename ~* \.[a-f0-9]{8}\.) {
        add_header Cache-Control "max-age=31536000, immutable";
    }
    add_header Cache-Control "max-age=604800, public";
    # 保留ETag用于验证，避免重复下载
    etag on;
}

经过这次事故，我深刻体会到：CDN不是"接上就能用"的东西，缓存策略必须结合业务场景设计。如果是金融交易系统的动态接口，那确实要短缓存甚至不缓存；但电商的商品图片、前端打包文件，就该大胆设置长缓存——毕竟用户不会因为你改了个按钮颜色，就立刻刷新页面。

5. 边缘函数实战：用Cloudflare Workers替代中心云实现JWT鉴权

上个月我们重构一个To B的SaaS系统，原本的JWT鉴权逻辑放在阿里云的函数计算里，每次请求都要经过"用户请求→CDN→中心云函数→鉴权→返回结果"的流程。大客户反馈接口延迟高，平均要220ms，排查下来发现中心云函数冷启动占了80ms，网络传输又花了100ms。后来我试着把鉴权逻辑迁移到Cloudflare Workers，延迟直接降到了35ms，成本还降了60%。

先说说为什么选Cloudflare Workers。当时我们对比了几个方案：阿里云函数计算虽然稳定，但冷启动时间普遍在50-100ms（Node.js 18运行时）；AWS Lambda@Edge功能强，但配置复杂，而且按请求次数计费，大客户每月要花近2000美元。Cloudflare Workers基于V8引擎，冷启动时间官方数据是0-5ms（我实测平均3ms），而且免费套餐每月有10万次请求，对我们这种日均5万次鉴权请求的系统来说，几乎零成本。

我们的鉴权逻辑很简单：验证请求头里的Authorization: Bearer ，解码JWT后检查过期时间和权限字段。原本中心云函数的代码是这样的（Node.js 18）：

const jwt = require('jsonwebtoken');
const JWT_SECRET = process.env.JWT_SECRET;

exports.handler = async (req, res) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: '未提供token' });

  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    if (decoded.exp < Date.now() / 1000) {
      return res.status(401).json({ error: 'token已过期' });
    }
    // 把用户信息放到请求头，转发给后端
    req.headers['X-User-Id'] = decoded.userId;
    req.headers['X-User-Role'] = decoded.role;
    return res.status(200).json({ valid: true, user: decoded });
  } catch (err) {
    return res.status(401).json({ error: 'token无效' });
  }
};

迁移到Cloudflare Workers时，我一开始想直接用jsonwebtoken库，但发现Workers的环境不支持Node.js的crypto模块（它用的是Web Crypto API）。后来改用jose库，这个库同时支持Node.js和Web Crypto，而且体积很小（压缩后只有12KB）。改造后的Workers代码如下：

import { jwtVerify } from 'https://deno.land/x/jose@v4.14.4/src/index.ts';

const JWT_SECRET = 'your-256-bit-secret'; // 实际项目存在Workers环境变量里
const secret = new TextEncoder().encode(JWT_SECRET);

export default {
  async fetch(request) {
    // 只处理/api/开头的请求
    const url = new URL(request.url);
    if (!url.pathname.startsWith('/api/')) {
      return fetch(request); // 非API请求直接转发
    }

    const authHeader = request.headers.get('Authorization');
    if (!authHeader || !authHeader.startsWith('Bearer ')) {
      return new Response(JSON.stringify({ error: '未提供token' }), {
        status: 401,
        headers: { 'Content-Type': 'application/json' }
      });
    }

    const token = authHeader.split(' ')[1];
    try {
      const { payload } = await jwtVerify(token, secret, {
        algorithms: ['HS256']
      });

      // 检查过期时间（jwtVerify会自动验证exp字段，这里额外检查自定义的有效期）
      if (payload.iat && Date.now() / 1000 - payload.iat > 86400) {
        return new Response(JSON.stringify({ error: 'token已过期' }), {
          status: 401,
          headers: { 'Content-Type': 'application/json' }
        });
      }

      // 把用户信息添加到请求头，转发给源站
      const newRequest = new Request(request.url, {
        method: request.method,
        headers: request.headers,
        body: request.body
      });
      newRequest.headers.set('X-User-Id', payload.userId);
      newRequest.headers.set('X-User-Role', payload.role);

      return fetch(newRequest);
    } catch (err) {
      return new Response(JSON.stringify({ error: 'token无效' }), {
        status: 401,
        headers: { 'Content-Type': 'application/json' }
      });
    }
  }
};

部署到Cloudflare Workers后，我做了个压测：用100并发持续请求鉴权接口，中心云函数平均响应220ms（冷启动80ms+执行30ms+网络110ms），而Workers平均35ms（冷启动3ms+执行8ms+网络24ms）。网络延迟的降低是因为Workers节点离用户更近——我们的用户主要在东南亚，Cloudflare在雅加达、新加坡都有节点，而中心云函数在杭州，物理距离就差了2000公里。

有个细节要注意：Workers的fetch请求默认会带上原请求的所有头，但如果你修改了Request对象，记得重新设置body——我一开始忘了这点，导致POST请求的body丢失，调试了半小时。另外，JWT密钥不要硬编码在代码里，要用Cloudflare Workers的"环境变量"功能存储，支持加密存储，比放在代码里安全得多。

现在我们的鉴权流程变成了"用户请求→最近的Cloudflare节点→Workers鉴权→转发到源站"，不仅延迟降了，还省去了中心云函数的运维成本。大客户反馈接口速度明显变快，尤其是移动网络下，从原来的300ms降到了80ms以内。这让我意识到：边缘计算不是"未来趋势"，而是已经能解决实际问题的技术——特别是对有全球用户的业务来说，把逻辑推到边缘，比优化中心云性能有效得多。

6. 技术选型：Akamai、阿里云与Cloudflare的深度对比与避坑建议

去年我们公司做全球化业务，需要选一个CDN服务商，我花了三周时间调研了Akamai、阿里云和Cloudflare，还做了为期两周的灰度测试。现在把真实体验写出来，不是那种官网参数的堆砌，而是我们实际踩过的坑和得出的结论。

先说说我们的业务场景：主要服务东南亚和欧洲的电商用户，静态资源（图片/JS/CSS）占60%，动态API（商品搜索/订单提交）占40%，需要支持HTTP/3和DDoS防护。测试期间，我们用同一个域名，分别解析到三个服务商的CNAME，通过DNS权重分配10%的流量做对比。

性能对比（实测数据）

我们在雅加达、新加坡、伦敦三个节点用WebPageTest做了100次测试，取平均值：

| 指标 | Akamai | 阿里云 | Cloudflare |

|---------------------|-----------------|-----------------|----------------|

| 静态资源加载时间 | 120ms | 180ms | 95ms |

| 动态API延迟 | 85ms | 110ms | 70ms |

| 节点覆盖率（东南亚） | 12个节点 | 8个节点 | 15个节点 |

Akamai的静态资源加载时间比Cloudflare慢，是因为它的节点更偏向企业客户，很多节点部署在数据中心而非ISP机房；阿里云在东南亚的节点少，导致雅加达用户经常要连到新加坡节点，延迟就高了。

功能特性对比

Akamai：我们测试了EdgeWorkers（边缘函数），支持Node.js 18运行时，冷启动时间约15ms，比Cloudflare Workers慢，但支持更复杂的计算（比如我们试过在边缘做图片裁剪，处理一张1MB的图片耗时80ms，Cloudflare Workers会超时）。安全防护很强，DDoS清洗能力实测能扛住500Gbps的攻击（我们找第三方做过压测），但配置复杂，光是WAF规则就要写200多行XML。
阿里云：优势是国内访问快，我们的中国用户访问延迟只有30ms（Cloudflare在国内需要备案，而且节点少）。但动态加速功能一般，API请求要经过"用户→阿里云节点→中心加速链路→源站"，链路优化不如另外两家。另外，阿里云的CDN控制台广告太多，每次登录都弹"升级全站加速"的提示，体验不好。
Cloudflare：边缘函数（Workers）是我们用过最顺手的，支持WebAssembly，我们试过在边缘跑一个轻量级的TensorFlow模型做图片内容审核，耗时120ms，完全可行。免费套餐就包含基础WAF和DDoS防护，对我们这种中小业务来说够用。但有个坑：它的"自动最小化"功能会修改JS代码，我们之前有个前端包用了eval，被它误判为恶意代码直接拦截了，后来只能关掉这个功能。

成本对比（按我们每月500TB流量、1000万次请求计算）

Akamai：约$8500/月（流量费$0.016/GB + 请求费$0.002/万次 + EdgeWorkers额外计费）
阿里云：约¥32000/月（流量费¥0.21/GB + 请求费¥0.05/万次，国内流量便宜，但国际流量贵30%）
Cloudflare：Pro套餐$20/月 + 流量费$0.01/GB（超过免费额度后），每月约$5020

这里要注意：Akamai没有公开的定价页，需要找销售谈，我们当时谈下来比官网报价低20%，但合同一签就是一年，灵活性差。Cloudflare的流量计费是按"流出到互联网"的量算，如果从Cloudflare回源到自己的服务器，流量是免费的——这点比另外两家良心，阿里云回源流量要额外收费。

避坑建议

如果业务主要在海外，选Cloudflare：它的节点覆盖广，边缘计算能力强，成本最低。但要注意：国内访问需要备案，而且部分地区的UDP（HTTP/3用的QUIC协议）会被运营商封锁，我们测试时发现有5%的用户无法用HTTP/3，后来只能降级到HTTP/2。
如果业务在国内，选阿里云：它的国内节点多，备案流程顺畅，而且和阿里云的其他产品（OSS、函数计算）集成好。但国际业务要谨慎，我们之前用阿里云加速欧洲用户，延迟比Cloudflare高40%。
如果是超大型企业，选Akamai：它的稳定性和安全性经过20多年的验证，金融、游戏行业的大客户多。但要做好"配置复杂"的心理准备，我们当时花了一周才把WAF规则配好，而Cloudflare的WAF规则向导10分钟就能完成。

最后说个我们实际遇到的问题：一开始我们同时用了Akamai和Cloudflare做双CDN，想通过DNS智能解析让亚洲用户走Cloudflare，欧美走Akamai。结果发现两个CDN的缓存策略不一致——Akamai默认缓存静态资源7天，Cloudflare默认缓存4小时，导致用户在不同地区看到的内容版本不一样。后来我们只能统一用Cloudflare，因为它的边缘函数能自定义缓存逻辑，而Akamai的缓存规则太死板。

现在我们的架构是：国内用户用阿里云CDN，海外用户用Cloudflare，动态API通过Cloudflare Workers做鉴权和链路优化。这个方案运行了半年，可用性99.99%，平均延迟85ms，成本比之前全用Akamai省了40%。技术选型没有"最好"，只有"最适合"——关键看你的用户在哪里，业务需要什么功能，以及能接受多少成本。

站长实战手记

去年双十一，我负责一个做跨境服饰的电商项目，日活大概八十万，主要用户集中在东南亚。当时我们用的是某国内云厂商的 CDN，静态资源全丢上去了，以为万事大吉。结果大促刚开始半小时，菲律宾节点的图片加载全部超时，后台监控显示回源带宽直接被打满，源站 CPU 飙到 98%。

我当时一脸懵，第一反应是节点挂了，后来抓包看日志才发现，问题出在 Cache-Control 头上。团队里一个新人配置缓存时，给商品详情页的 API 接口误设了 max-age=3600，结果 CDN 把这些包含用户个性化数据的动态请求全给缓存了。更糟的是，缓存过期那一瞬间，所有请求像洪水一样穿透到源站，直接把数据库打崩了。

我连夜回滚配置，把动态接口全改成 no-cache，并且针对静态图片单独设置了 s-maxage 区分浏览器和 CDN 的行为。折腾到凌晨四点，回源率直接从 60% 降到了 5% 以下，页面加载也稳在了 1.2 秒内。

经过这事，我对 CDN 的看法变了。很多人觉得只要上了 CDN 就一定能快，其实不然。如果是那种内部管理系统，或者用户量极少的工具站，你花时间去调校复杂的缓存策略，收益微乎其微，反而增加了运维复杂度。

关于选型，我建议别盲目追求 Akamai 这种顶级大厂，虽然稳，但贵且控制台反人类；对于中小企业，Cloudflare 的免费版其实够用了，特别是它那个 Workers 边缘函数，用来做简单的鉴权比在服务器上写中间件爽多了。

最后想跟你说一句，CDN 的配置文档看着简单，但 缓存键（Cache Key）和 HTTP 头 的相互作用极其复杂。别光看文档，一定要在测试环境模拟一遍回源失败的场景，不然真到了线上，查日志能查到你怀疑人生。