Русский
English
Українська
Deutsch
Español
Português
Türkçe
中文
内容分发网络（CDN）中的代理充当中间服务器，把内容缓存到离最终用户更近的位置、优化网络请求，并在分布式基础设施上高效分配流量，从而加速内容分发。
代理在 CDN 架构中的作用
在 CDN 中，代理是核心组件，主要以边缘服务器或接入点（PoP）的形式存在。这些服务器在全球范围内战略性部署，在源站与最终用户之间构成一层网络。当用户请求内容时，DNS 解析通常会把用户导向最近或最优的 CDN 边缘代理，而不是原始的内容主机。这种就近接入可显著降低延迟并缩短加载时间。
边缘代理与接入点（PoP）
每个 PoP 都包含一台或多台用于处理用户请求的代理服务器。这些代理的功能远不止简单转发，它们主动参与内容分发链路，以提升速度和可靠性。其主要目标是尽可能从边缘提供内容，尽量减少从远端源站取数据的需要。
提速的核心机制
代理通过若干机制加速内容分发：
在边缘缓存内容
缓存是 CDN 代理带来的最大提速手段。当边缘代理收到此前已抓取过的内容请求时，可以直接从本地存储提供该内容，无需回源。这样可以减少：
* 往返时延（RTT）： 请求从用户到源站再返回所需的时间。
* 源站负载： 降低源站的处理压力，避免变慢或宕机。
* 带宽消耗： 降低源站的数据传输成本。
缓存命中与缓存未命中：
* 缓存命中： 请求的内容存在于代理缓存中，代理直接提供该内容。
* 缓存未命中： 请求的内容不在代理缓存中或已过期。代理从源站取回内容，提供给用户，并保存一份副本以备后续请求。
缓存失效：
CDN 通过多种策略管理缓存新鲜度：
* 生存时间（TTL）： 内容按预设时长缓存。
* 缓存头： Cache-Control 和 Expires 等 HTTP 头决定缓存行为。
* 手动清除： 管理员可以在整个 CDN 上显式删除缓存内容。
* API 驱动的失效： 内容更新时由自动化系统触发清除。
负载均衡与流量分配
CDN 中的代理同时充当负载均衡器，把用户请求分配到多个资源上。这可能包括：
* 在单个 PoP 内的多台服务器之间分配请求： 确保没有单台服务器过载。
* 在多个源站之间分配请求： 当 CDN 配置为从多个源站回源时。
* 将流量导向负载最低或地理位置最近的 PoP： 通过基于 DNS 的路由或 IP Anycast 实现。
负载均衡算法确保资源得到最优利用并避免瓶颈，即使在高流量下也能保持稳定的分发速度。常见算法包括 Round Robin、Least Connections 和 IP Hash。
内容优化与压缩
CDN 代理可以实时优化和压缩内容以减小文件体积，这直接带来更快的下载速度。
* 压缩： 如果源站尚未压缩，代理可以对文本类资源（HTML、CSS、JavaScript）应用 Gzip 或 Brotli 压缩。
* 图片优化： 部分 CDN 提供由边缘代理完成的图片处理服务，例如缩放、格式转换（如 WebP）和降低画质。
* 压缩精简（Minification）： 在不改变功能的前提下删除代码中的多余字符。
用于 Gzip 压缩的 Nginx 代理配置示例：
http {
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}
协议优化
代理让用户与边缘之间（有时也包括边缘与源站之间）能够使用更现代、更快的通信协议。
* HTTP/2 与 HTTP/3（QUIC）： 这些协议支持多路复用（单条连接承载多个请求）、头部压缩和服务器推送，相比 HTTP/1.1 可大幅降低延迟。无论源站是否支持，CDN 代理通常都用这些较新的协议终结用户连接。
* TCP 优化： 代理可以采用优化过的 TCP 栈（如 BBR）和参数配置，加快连接建立和数据传输，长距离传输时效果尤为明显。
优化的路由
CDN 采用精细的路由机制，把用户请求导向最高效的边缘代理。判断依据通常包括：
* 地理位置： 把用户导向最近的 PoP。
* 网络拥塞： 让流量避开过载的网络路径。
* 服务器健康状况： 避开出现问题的 PoP 或服务器。
因此，即使用户在地理上靠近某个 PoP，若主路径拥塞，也会被路由到备选路径，从而保持最佳速度。
安全性作为性能保障
虽然在数据传输层面并非直接的提速手段，但在代理层实施的安全功能通过保障可用性、防止性能下降，对内容分发速度做出了贡献。
* DDoS 缓解： 代理吸收并过滤恶意流量，防止拒绝服务攻击压垮源站或 CDN 基础设施，否则将导致严重变慢或服务中断。
* Web 应用防火墙（WAF）： 防护常见的 Web 漏洞，保障应用稳定性，避免可能中断服务并拖慢内容分发的攻击。
* SSL/TLS 卸载： 代理承担计算开销较大的 SSL/TLS 握手与加解密工作，把这部分任务从源站卸下，并常借助专用硬件加快处理。
CDN 场景中的代理类型
反向代理
CDN 内部使用的主要代理类型是反向代理。反向代理位于一台或多台 Web 服务器之前，拦截来自客户端的请求，将请求转发给相应的服务器，取回服务器的响应，再交付给客户端。在 CDN 中，边缘服务器就是源站的反向代理。
CDN 反向代理的特点：
* 对客户端透明： 客户端认为自己是直接与源站通信。
* 缓存能力： 保存静态和动态内容的副本。
* 安全层： 提供抵御攻击的第一道防线。
* 负载均衡： 在内部资源之间分配请求。
* SSL/TLS 终结： 处理加解密。
实践落地：一次请求的流程示例
假设用户请求 example.com/image.jpg：
- DNS 查询： 用户浏览器对
example.com进行 DNS 解析。CDN 的 DNS 服务返回最近或最优的 CDN 边缘代理服务器的 IP 地址。 - 向边缘代理发起请求： 用户浏览器直接向 CDN 边缘代理发送
example.com/image.jpg的 HTTP 请求。 - 检查缓存： 边缘代理在本地缓存中查找
image.jpg。- 缓存命中： 如果找到
image.jpg且仍然有效，代理立即把图片返回给用户。 - 缓存未命中： 如果未找到
image.jpg或其已过期，代理把请求转发到源站（例如origin.example.com）。
- 缓存命中： 如果找到
- 回源获取（缓存未命中时）： 源站处理请求，并把
image.jpg返回给边缘代理。 - 缓存并交付： 边缘代理收到
image.jpg后在缓存中保存一份副本，再交付给用户。之后被路由到该 PoP 的用户再请求image.jpg时将命中缓存，交付时间显著缩短。
代理缓存与优化的配置示例
Nginx 或 Varnish 等代理服务器常作为 CDN PoP 内的组件使用。它们的配置直接决定内容如何被缓存和优化。
Nginx 代理缓存配置片段：
下面的示例演示了用于缓存上游服务器响应的基础 Nginx 配置。
http {
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
proxy_cache_key "$scheme$request_method$host$request_uri";
server {
listen 80;
server_name cdn.example.com;
location / {
proxy_pass http://origin.example.com;
proxy_cache my_cache;
proxy_cache_valid 200 302 10m; # 成功响应缓存 10 分钟
proxy_cache_valid 404 1m; # 404 错误缓存 1 分钟
add_header X-Cache-Status $upstream_cache_status; # 调试用响应头
expires 30d; # 浏览器缓存
}
}
}
Varnish Cache 配置片段（简化的 vcl_recv）：
Varnish Cache 是一款专注于缓存的 HTTP 反向代理。
vcl 4.1;
backend default {
.host = "origin.example.com";
.port = "80";
}
sub vcl_recv {
# 移除静态文件上的 cookie，提高可缓存性
if (req.url ~ "(?i)\.(css|js|jpg|jpeg|png|gif|ico|svg|webp|woff|woff2|ttf|otf|eot)(\?.*)?$") {
unset req.http.Cookie;
}
# 不缓存 POST 请求
if (req.method == "POST") {
return (pass);
}
# 查找缓存
return (hash);
}
sub vcl_backend_response {
# 若源站未指定 TTL，则为所有对象设置默认值
if (beresp.ttl <= 0s || beresp.http.Set-Cookie || beresp.http.Vary == "*") {
set beresp.ttl = 1h; # 默认缓存 1 小时
}
return (deliver);
}