计算机基础5月28日 09:26
什么是 CDN 边缘计算？有哪些应用场景？## CDN 边缘计算是什么？
CDN 边缘计算是将计算能力从中心化源站下沉到 CDN 边缘节点，在靠近用户的网络边缘执行计算任务的一种架构模式。传统 CDN 只做静态内容缓存，而边缘计算让边缘节点具备了运行业务逻辑的能力——请求不必回源，直接在边缘节点处理并返回结果。
两者的核心区别：CDN 解决的是"内容离用户更近"的问题，边缘计算解决的是"计算离用户更近"的问题。当两者结合，边缘节点既能缓存静态资源，又能执行动态计算，形成完整的边缘服务能力。
## 为什么需要边缘计算？
### 延迟：从数百毫秒到数十毫秒
传统架构下，动态请求必须回源处理：用户 → 边缘节点 → 源站（可能跨区域）→ 返回，端到端延迟通常 200-500ms。边缘计算将计算逻辑部署到边缘节点，请求在本地完成处理，延迟可降至 10-50ms。对于实时交互场景（在线游戏、金融交易、视频直播），这几十到几百毫秒的差异直接影响用户体验和业务指标。
### 回源压力与带宽成本
没有边缘计算时，所有动态请求都打到源站，源站需要为每个请求分配 CPU、内存和网络资源。引入边缘计算后，大部分请求在边缘节点就地处理，只有少数需要中心数据的请求才回源。以 Cloudflare Workers 为例，官方数据显示边缘处理可节省至少 30% 的回源流量成本。
### 数据合规与隐私
各国数据本地化法规（如欧盟 GDPR、中国《数据安全法》）要求用户数据在本地处理。边缘计算让数据在产生地就近处理，减少跨境传输，既满足合规要求，又降低了数据泄露风险。
## 核心应用场景
### 1. API 网关与请求路由
在边缘节点部署路由规则，根据 URL 路径、请求头、用户地域等信息将请求分发到不同的后端服务。好处是路由决策在离用户最近的位置完成，避免了不必要的回源往返。
```javascript
// Cloudflare Workers: 边缘 API 路由
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname.startsWith("/api/v1")) {
return fetch("https://api-v1.example.com" + url.pathname + url.search);
}
if (url.pathname.startsWith("/api/v2")) {
return fetch("https://api-v2.example.com" + url.pathname + url.search);
}
return new Response("Not Found", { status: 404 });
}
};
```
### 2. A/B 测试与个性化内容
在边缘节点根据用户特征（地域、设备、Cookie 等）决定返回哪个版本的页面或接口数据。相比在源站做 A/B 分流，边缘分流避免了回源延迟，用户感知几乎为零。这也是电商、媒体平台常用的策略。
```javascript
// 边缘 A/B 测试
export default {
async fetch(request) {
const country = request.cf?.country;
if (country === "CN") {
return fetch("https://cn-version.example.com" + new URL(request.url).pathname);
}
return fetch("https://global-version.example.com" + new URL(request.url).pathname);
}
};
```
### 3. 图片与视频实时处理
在边缘节点对图片进行缩放、裁剪、格式转换（WebP/AVIF），对视频流做转码或画质优化。请求到达边缘时，如果缓存中已有处理后的版本直接返回；没有则从源站取原始文件，在边缘处理后缓存并返回。这样源站只需存储一份原图，由边缘按需处理不同尺寸和格式。
### 4. 认证鉴权
将 JWT 验证、API Key 校验、权限检查等逻辑下沉到边缘节点。无效请求在边缘就被拦截，不会浪费源站资源。这对于高并发场景（秒杀、抢购）尤其重要，可以在边缘挡住大量未授权请求。
### 5. 限流与防爬
在边缘节点基于 IP、用户标识、请求频率等维度实施限流策略，识别并拦截爬虫和恶意请求。相比在源站做限流，边缘限流在请求进入内部网络前就完成过滤，防护效果更好。
```javascript
// 边缘限流示意（基于 IP）
const rateLimiter = new Map();
export default {
async fetch(request) {
const ip = request.headers.get("CF-Connecting-IP");
const now = Date.now();
const record = rateLimiter.get(ip);
if (record && now < record.resetTime && record.count >= 100) {
return new Response("Too Many Requests", { status: 429 });
}
rateLimiter.set(ip, {
count: (record?.count || 0) + 1,
resetTime: now + 60000
});
return fetch(request);
}
};
```
### 6. 数据聚合与智能缓存
多个后端服务的响应可以在边缘节点聚合后统一返回给前端，减少前端的请求数量。同时，边缘节点可以对聚合结果设置智能缓存策略，后续相同请求直接返回缓存，无需再次回源。
## 主流平台对比
| 平台 | 运行时 | 语言支持 | 特点 |
|------|--------|----------|------|
| Cloudflare Workers | V8 隔离 | JS/TS/WASM | 全球节点最多（300+），免费额度慷慨 |
| AWS Lambda@Edge | Node.js/Python | JS/Python | 与 CloudFront + AWS 生态深度集成 |
| Fastly Compute@Edge | WASM | Rust/C++/JS | 基于 WebAssembly，冷启动极快 |
| Vercel Edge Functions | V8 隔离 | JS/TS | 与 Next.js 无缝配合 |
选型建议：如果你需要全球覆盖和独立部署，选 Cloudflare Workers；如果技术栈在 AWS 生态内，选 Lambda@Edge；如果追求极致性能和冷启动速度，考虑 Fastly；如果是 Next.js 项目，Vercel Edge Functions 是最省事的选择。
## 边缘计算的设计原则
**无状态优先**：边缘节点随时可能被销毁或迁移，不要依赖本地变量或文件系统存储状态数据，应使用 KV 存储（如 Cloudflare KV）或外部数据库。
**优雅降级**：边缘计算可能出现超时、节点不可用等情况，必须设计降级策略——返回缓存数据、展示兜底内容、或降级到源站处理，而不是直接报错。
**控制执行时间**：各平台对边缘函数的执行时间有严格限制（Cloudflare Workers 免费版 CPU 时间 10ms，付费版 50ms；Lambda@Edge 超时 5-30s）。代码要尽量轻量，避免在边缘做重计算。
**冷启动问题**：边缘函数在首次请求时会经历冷启动（加载代码 → 初始化运行时 → 执行函数）。保持代码体积小、减少外部依赖，可以有效缩短冷启动时间。
## 面试回答要点
回答"什么是 CDN 边缘计算"时，按以下逻辑组织：
1. **先给定义**：CDN 边缘计算是把计算逻辑从中心化源站下沉到 CDN 边缘节点，在靠近用户的位置处理请求
2. **说清价值**：降低延迟（200ms → 50ms）、减少回源流量（节省 30%+）、满足数据合规要求
3. **列举场景**：API 路由、A/B 测试、图片处理、认证鉴权、限流防爬、数据聚合
4. **提到平台**：Cloudflare Workers / Lambda@Edge / Fastly，能说出各自的适用场景
5. **指出挑战**：无状态设计、执行时间限制、冷启动、调试困难
可能的追问及应对：
- **边缘计算和 Serverless 有什么区别？** Serverless 是一种部署和计费模式，边缘计算是一种架构模式。边缘计算通常采用 Serverless 的方式部署，但 Serverless 不一定运行在边缘。
- **边缘计算适合所有场景吗？** 不适合。需要访问中心数据库的复杂查询、涉及大量数据的批处理、对一致性要求高的事务型操作，仍然应该放在源站或云端处理。
- **边缘节点之间数据如何同步？** 通常通过分布式 KV 存储（如 Cloudflare KV）实现最终一致性，不适合强一致性场景。标签
CDN
内容分发网络（Content Delivery Network，简称 CDN）是一组分布在多个地理位置的服务器，它们共同工作以提供快速、高可用性和安全的互联网内容传输服务。CDN 的主要目标是通过将内容存储在靠近最终用户的边缘服务器上，来减少网络延迟和带宽消耗，从而提升用户体验。
计算机基础5月28日 09:24
CDN 的负载均衡策略有哪些？如何实现 CDN 的高可用？## 面试核心结论
CDN 负载均衡的核心策略分为两层：**全局调度层**（GSLB/DNS）决定用户访问哪个边缘节点，**本地均衡层**（L4/L7 LB）决定节点内部请求分发到哪台服务器。主要策略包括地理位置路由、就近性路由、轮询、加权轮询、最少连接和一致性哈希。实现高可用的关键在于：健康检查 + 故障自动转移 + 熔断降级 + 多活冗余，缺一不可。
**追问方向**：GSLB 的 DNS 调度流程是怎样的？一致性哈希在 CDN 缓存中为什么重要？Anycast 和 DNS 调度有什么区别？
## CDN 负载均衡的两层架构
理解 CDN 负载均衡，首先要分清两层调度：
- **全局调度（GSLB）**：当用户发起请求时，DNS 解析通过 CNAME 指向 CDN 的 GSLB，GSLB 根据用户 IP、节点负载、网络质量等选择最优边缘节点，返回该节点的 IP。这一层决定"用户去哪个机房"。
- **本地负载均衡（SLB）**：请求到达边缘节点后，节点内部的负载均衡器（Nginx、HAProxy 等）将请求分发到后端的缓存服务器集群。这一层决定"请求去哪台机器"。
面试时很多候选人只讲本地负载均衡，忽略了 GSLB 这一层，这是不够的。CDN 的核心优势——就近接入，正是由 GSLB 实现的。
## 六种核心负载均衡策略
### 地理位置路由（Geo-based Routing）
根据用户 IP 所属地域，将请求调度到最近的边缘节点。这是 CDN 最基础也最常用的全局调度策略。
**实现机制**：GSLB 维护一张 IP 地址段到地理位置的映射表（GeoIP 数据库），用户 DNS 请求到达后，查询映射表确定用户所在区域，返回该区域对应节点的 IP。
**局限性**：地理位置近不等于网络延迟低。比如跨运营商访问时，物理距离近但网络绕行严重。因此通常和就近性路由配合使用。
### 就近性路由（Proximity-based Routing）
不依赖地理数据，而是通过实际网络测量选择最优节点。
**测量方式**：
- **主动探测**：GSLB 定期从各节点向探测点发送 ICMP/TCP 探测，收集 RTT 数据
- **被动测量**：分析实际用户请求的响应时间，统计各节点的真实服务质量
- **混合模式**：主动探测提供基线数据，被动测量做实时修正
实际生产中混合模式最常见。纯主动探测有探测盲区，纯被动测量冷启动阶段没数据。
### 一致性哈希（Consistent Hashing）
在 CDN 场景中，一致性哈希的核心价值是**提高缓存命中率**。
**为什么重要**：如果用轮询策略，同一 URL 的请求可能落在不同缓存服务器上，导致重复回源。用 URL 做一致性哈希，相同 URL 始终路由到同一台服务器，缓存只需存一份。
**关键参数**：虚拟节点数。虚拟节点越多，数据分布越均匀，但管理开销也越大。通常设置 100-200 个虚拟节点。
**节点变更影响**：当节点增减时，一致性哈希只影响相邻虚拟节点上的数据，不会全盘重新分配。相比取模哈希（节点变化时全部重分布），这是巨大优势。
```nginx
# Nginx 一致性哈希配置
upstream cdn_cache {
hash $request_uri consistent;
server 10.0.0.1:8080;
server 10.0.0.2:8080;
server 10.0.0.3:8080;
}
```
### 加权轮询（Weighted Round Robin）
为不同性能的服务器分配不同权重，高性能服务器承载更多请求。
```nginx
upstream cdn_nodes {
server 10.0.0.1:8080 weight=5; # 32核 64G 高配
server 10.0.0.2:8080 weight=3; # 16核 32G 中配
server 10.0.0.3:8080 weight=1; # 8核 16G 低配
}
```
权重不是一成不变的。成熟的 CDN 系统会根据服务器实时负载（CPU、内存、连接数）动态调整权重，这叫**动态权重调整**。
### 最少连接（Least Connections）
将新请求分发给当前活跃连接数最少的服务器。相比轮询，它适合请求处理时间差异大的场景——轮询只看"分了几个"，最少连接看"还剩多少余力"。
```nginx
upstream cdn_nodes {
least_conn;
server 10.0.0.1:8080;
server 10.0.0.2:8080;
server 10.0.0.3:8080;
}
```
### IP 哈希（IP Hash）
用客户端 IP 做哈希，保证同一用户的请求始终落到同一台服务器。主要用于会话保持场景，但在 CDN 中不如 URL 哈希常用，因为 CDN 主要是无状态的内容分发。
## 健康检查：高可用的基础
没有可靠的健康检查，负载均衡就是瞎指挥。健康检查分两种：
### 主动健康检查
LB 定期向后端发送探测请求，判断服务是否正常：
```nginx
# Nginx Plus 主动健康检查
upstream cdn_nodes {
zone health 64k;
server 10.0.0.1:8080;
server 10.0.0.2:8080;
health_check interval=5s fails=3 passes=2 uri=/health;
}
```
关键参数：
- **interval**：探测间隔，正常节点 5-10s，异常节点缩短到 1-2s
- **fails**：连续失败几次标记为不健康
- **passes**：连续成功几次恢复为健康
### 被动健康检查
基于实际业务请求的响应判断，不额外发探测：
```nginx
upstream cdn_nodes {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
}
```
`max_fails=3 fail_timeout=30s` 表示 30 秒内失败 3 次，该节点被标记不可用 30 秒。
**生产实践**：两种方式配合使用。主动检查发现硬故障（进程挂了、端口不通），被动检查发现软故障（响应变慢、错误率升高）。
## 高可用架构的关键机制
### 故障自动转移
当节点被标记不健康后，负载均衡器自动将流量切到健康节点。关键问题是**切换速度**：
- DNS 级别的 GSLB 切换依赖 TTL，即使设置很短的 TTL（如 30s），仍有本地 DNS 缓存问题，实际切换可能需要数分钟
- Anycast 方式切换更快，因为 BGP 路由变化可在秒级生效
- 本地 SLB 切换最快，通常在 1-2 个探测周期内完成
### 熔断与降级
当后端持续异常时，快速失败比慢慢等更好：
- **熔断**：错误率超过阈值（如 50%），直接断开，不再向该节点发请求，等一段时间后半开探测
- **降级**：返回缓存内容（stale-while-revalidate）、返回简化版本、或者直接拒绝（比超时等待体验更好）
```nginx
# Nginx 熔断配置思路
proxy_connect_timeout 2s;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_timeout 10s;
proxy_next_upstream_tries 2;
```
`proxy_next_upstream` 实现了请求级别的自动重试和故障转移。
### 多活与冗余
单点永远不可靠。CDN 的高可用需要多层次的冗余：
- **节点级冗余**：每个区域至少部署 2 个边缘节点，互为备份
- **服务器级冗余**：节点内部至少 2 台缓存服务器
- **网络级冗余**：多运营商接入（BGP 多线），避免单运营商故障
- **DNS 级冗余**：多组权威 DNS，避免 DNS 服务本身成为单点
### Anycast 与 DNS 调度的对比
这是面试中经常被追问的进阶问题：
| 维度 | DNS 调度（GSLB） | Anycast |
|------|-------------------|---------|
| 切换速度 | 分钟级（受 TTL 和缓存影响） | 秒级（BGP 路由收敛） |
| 精度 | 基于 IP 库，有偏差 | 基于网络拓扑，更精准 |
| 运维复杂度 | 相对简单 | 需要 ASN 和 BGP 配置 |
| 适用场景 | 大多数 CDN | 对延迟敏感、需快速故障转移 |
| 缓存问题 | 本地 DNS 缓存导致调度不准 | 无此问题 |
大型 CDN（Cloudflare、Akamai）通常两种方式结合：Anycast 做全局入口，DNS 调度做精细化区域分配。
## 监控指标与告警
负载均衡不是配置完就完事了，需要持续监控：
**核心指标**：
- **P50/P95/P99 响应时间**：关注长尾延迟，P99 比 P50 更能反映用户体验下限
- **错误率**：5xx 比例超过 0.1% 就需要告警
- **缓存命中率**：低于 80% 说明负载均衡策略或缓存策略有问题
- **节点可用性**：目标 99.99%（年停机约 52 分钟）
**告警分级**：
- P1：节点完全不可用 → 立即处理，自动故障转移
- P2：错误率 > 1% 或 P99 > 5s → 5 分钟内响应
- P3：缓存命中率下降 > 10% → 工单跟进
## 面试回答要点
回答这个问题的正确姿势：
1. **先说两层架构**：全局调度（GSLB/Anycast）+ 本地均衡（L4/L7），展示你对 CDN 整体架构的理解
2. **策略选讲 3-4 个**：地理位置路由、一致性哈希、最少连接、加权轮询，每个说清楚适用场景和取舍
3. **高可用讲机制链**：健康检查 → 故障转移 → 熔断降级 → 多活冗余，形成完整链路
4. **举实际例子**：比如"我们线上遇到过 DNS 缓存导致 GSLB 切换慢的问题，后来加了 Anycast 做补充"，比纯理论更有说服力
5. **提 Anycast**：很多人会忽略这个，提了就是加分项计算机基础5月28日 09:23
什么是CDN回源？如何减少回源请求？## CDN 回源是什么？
回源（Origin Pull）是指 CDN 边缘节点没有缓存用户请求的内容时，向源站（Origin Server）请求资源的过程。简单来说：用户请求 → CDN 没有缓存 → CDN 去源站拿 → 缓存一份再返回给用户。
回源是 CDN 机制中不可避免的环节，但回源率过高会直接拖慢响应速度、压垮源站、推高成本。面试中考察这个点，核心是看你能不能从"理解机制"到"控制回源"形成完整闭环。
## 回源在什么情况下触发？
### 缓存未命中
最常见的回源原因，包含三种典型场景：
- **首次访问**：资源从未被任何边缘节点缓存过，冷启动必然回源
- **缓存过期**：资源超过 TTL（Time To Live）过期时间，CDN 必须重新验证或拉取
- **缓存被清除**：主动刷新（Purge）或被动淘汰（LRU 内存不足）导致缓存消失
### 缓存键不匹配
URL 相同但参数不同，CDN 可能将其视为不同资源：
```
https://example.com/api/data?version=1
https://example.com/api/data?version=2
// 若未配置忽略 version 参数，两次请求各自缓存，回源翻倍
```
生产环境中，UTM 参数、时间戳、随机 token 是导致缓存键膨胀的三大元凶。
### 请求类型或头部触发回源
- **POST/PUT/DELETE**：写操作通常不缓存，直接回源
- **携带 Authorization/Cookie**：CDN 默认不缓存带鉴权头的响应
- **动态内容**：业务规则标记为不可缓存的路径（如 `/api/`、`/user/`）
## 回源对系统有什么影响？
### 延迟：从毫秒到秒级的跨越
- 缓存命中：用户 → 边缘节点，通常 < 50ms
- 回源请求：用户 → 边缘节点 → 源站 → 边缘节点 → 用户，延迟 200ms~1s+
回源率每升高 10%，P99 延迟可能翻倍。高并发场景下，回源还会引发排队效应，延迟雪崩式恶化。
### 源站压力：回源风暴的风险
当热点资源同时过期，多个边缘节点会同时向源站发起请求，这就是**回源风暴**（Thundering Herd）。极端情况下，10 个边缘节点 × 每秒 1000 次 = 源站瞬间承受 10000 QPS，可能导致源站宕机。
### 成本：回源带宽是真金白银
- CDN 回源流量通常按带宽计费，价格高于普通 CDN 出流量
- 源站需要更高配置承受回源压力
- 超出套餐配额的回源流量费用更高
## 如何减少回源？六大核心策略
### 策略一：合理设置缓存 TTL
不同类型资源设置不同的过期时间：
```
// 静态资源：长 TTL + immutable
Cache-Control: public, max-age=31536000, immutable
// 半静态内容：中等 TTL
Cache-Control: public, max-age=3600
// 动态 API：短 TTL + stale-while-revalidate
Cache-Control: public, max-age=10, stale-while-revalidate=60
```
`stale-while-revalidate` 是一个容易被忽视的关键指令：它允许 CDN 在后台异步刷新缓存的同时，先返回过期的旧内容给用户。既保证响应速度，又保证内容最终一致。
配合 URL 版本化更新静态资源，彻底避免因内容更新导致的缓存失效：
```
// 版本化文件名，内容变更即更换 URL
/app.v1.a1b2c3.js
/app.v2.d4e5f6.js
```
### 策略二：缓存预热（Prefetch）
在用户访问前，主动将内容推送到 CDN 节点：
```bash
# 通过 CDN API 预热 URL
curl -X POST "https://cdn-api.example.com/prefetch" \
-H "Authorization: Bearer <token>" \
-d "{\"urls\": [\"https://example.com/new-page.html\", \"https://example.com/bundle.js\"]}"
```
预热适用场景：
- 新版本发布前预热静态资源
- 大促活动前预热商品页面
- 热门内容预测性预热（基于历史访问模式）
### 策略三：配置缓存键优化
**忽略无关查询参数**，让更多请求命中同一缓存：
```
// 配置忽略 utm_source、timestamp 等参数
https://example.com/data?utm_source=wechat&ts=123
https://example.com/data?utm_source=weibo&ts=456
// 忽略参数后，两个请求命中同一份缓存
```
**规范化请求头**：统一 Vary 头，避免因 Accept-Encoding 差异产生重复缓存。
### 策略四：多级缓存架构
CDN 本身就有多级缓存结构，合理利用可以大幅减少回源：
- **边缘缓存（L1）**：离用户最近，容量小，响应最快
- **区域缓存（L2）**：覆盖一个地理区域，容量中等
- **中心缓存 / Origin Shield（L3）**：所有边缘节点的回源汇聚点
Origin Shield 是 AWS CloudFront 的叫法，Akamai 称为 Origin Shielding，阿里云叫集中回源。核心原理：在源站前再加一层缓存，即使所有边缘节点都 miss，也只需一次回源到 Shield 层，避免多节点直接打源站。Akamai 的数据显示，Origin Shield 可以减少 95% 的源站请求。
### 策略五：请求合并（Request Coalescing）
当多个用户同时请求同一份未缓存的资源时，CDN 只向源站发一次请求，其余请求排队等待同一份响应。这个机制叫做请求合并或 Request Collapsing。
这是解决回源风暴的核心手段。没有请求合并，1000 个并发 miss 请求 = 1000 次回源；有了请求合并，= 1 次回源。
### 策略六：边缘计算
将简单逻辑下沉到 CDN 边缘节点执行，避免回源：
- **A/B 测试分流**：在边缘节点根据 Cookie 分配实验组
- **URL 重写**：边缘节点直接改写 URL，无需回源
- **简单 API 聚合**：边缘节点拼接多个缓存片段返回
- **地理定向**：根据用户 IP 返回不同区域的缓存内容
## 面试追问与回答
**追问 1：缓存穿透、缓存击穿、缓存雪崩分别是什么？和回源有什么关系？**
- **穿透**：请求的数据源站也不存在，每次都回源且永远无法缓存。解决：缓存空值或用 Bloom Filter 拦截
- **击穿**：热点 key 过期瞬间，大量请求同时回源。解决：请求合并 + 互斥锁回源
- **雪崩**：大批 key 同时过期，回源量暴增。解决：TTL 加随机偏移 + stale-while-revalidate
**追问 2：如何监控回源率？合理范围是多少？**
核心指标：
- 回源率 = 回源请求数 / 总请求数，目标 < 5%
- 回源带宽占比 = 回源流量 / 总出流量
- 回源延迟 P99
通过 CDN 控制台或日志分析工具（如 ELK）监控，设置回源率 > 10% 的告警阈值。
**追问 3：CDN 回源和源站宕机如何处理？**
- 配置 `stale-if-error` 指令，源站不可用时返回过期缓存
- 设置源站健康检查，自动切换到备用源站
- 多源站负载均衡 + 故障自动摘除
- 关键业务配置 Origin Shield 作为缓冲层计算机基础5月28日 08:26
CDN 成本过高如何优化？## CDN 账单为什么这么高？
一家中型互联网公司，业务量稳定增长，但 CDN 月费从 8 万涨到了 28 万，涨幅远超业务增速。复盘后发现：缓存命中率只有 72%，图片未做格式转换，视频全部用 H.264 编码，没有做任何成本管控。经过一轮系统优化，月费降回了 11 万。
CDN 成本优化不是省钱，是花该花的钱。下面从成本构成、六大核心优化策略、监控体系三个层面讲清楚。
## CDN 成本由哪些部分组成？
理解成本结构是优化的前提。CDN 的费用主要来自五个方面：
| 费用类型 | 计费方式 | 占比（典型场景） |
|---------|---------|--------------|
| 流量/带宽 | 按流量（GB）或按带宽峰值（Mbps） | 60%-70% |
| 请求次数 | 按千次请求计费 | 10%-15% |
| HTTPS 证书 | 按证书数量或域名数 | 3%-5% |
| 安全防护（WAF/DDoS） | 按规则数或防护流量 | 5%-10% |
| 边缘计算/视频处理 | 按调用次数或处理时长 | 5%-10% |
**流量/带宽是绝对大头**，优化重心应该放在这里。计费方式的选择也很关键：流量平稳的业务选按流量计费更划算，有明显峰值波动的（如直播、促销）选按带宽峰值第五计费（95 带宽）更合适。
## 策略一：缓存命中率提升到 95% 以上
缓存命中率每提升 1 个百分点，回源流量大约减少 3%-5%。命中率从 72% 提升到 95%，仅此一项就能节省 30% 以上的流量成本。
**关键配置：**
```http
# 静态资源：长缓存 + immutable
Cache-Control: public, max-age=31536000, immutable
# API 响应：短缓存，CDN 侧可缓存更久
Cache-Control: public, max-age=60, s-maxage=300
# 用户敏感数据：禁止缓存
Cache-Control: no-store
```
**缓存键优化**也很容易被忽略。默认缓存键会包含所有查询参数，但 `?utm_source=xxx` 这类追踪参数不影响内容，应该忽略：
```nginx
# 忽略不影响内容的查询参数
proxy_cache_key "$scheme$request_method$host$uri";
```
**资源版本化**是避免缓存失效的常用手段。不要用 `style.css?v=2`，改成 `style.v2.css`，旧版本自然过期，不需要手动刷新缓存。
**缓存预热**适合内容发布场景。新页面上线前，主动将关键资源推送到边缘节点，避免用户首次访问时回源。大部分 CDN 厂商都提供了预热 API，可以在 CI/CD 发布流程中自动调用。
**缓存一致性**是面试常问的追问点。常见方案有三种：一是 TTL 自然过期（最简单，适合容忍短暂不一致的场景）；二是主动 Purge（适合内容更新后必须立即生效的场景，但频繁 Purge 会降低命中率）；三是版本化 URL（改 URL 不改内容，最推荐）。实际生产中通常组合使用：静态资源用版本化 URL，动态内容用短 TTL + 关键更新时 Purge。
## 策略二：内容压缩和格式转换
### 图片优化：单此一项可减少 50%-70% 流量
| 格式 | 适用场景 | 相比 JPEG 节省 |
|-----|---------|-------------|
| WebP | 照片、复杂图形 | 25%-35% |
| AVIF | 对兼容性要求不高的场景 | 40%-50% |
| PNG → WebP | 含透明通道的图 | 60%-70% |
实际操作中，用 CDN 的图片处理服务做实时转换是最省事的方案。Cloudflare 的 Polish、阿里云的图片处理、七牛的 imageView2 都支持按请求参数自动转换格式和压缩质量。这种方式不需要改源站图片，CDN 边缘实时转换，用户请求时自动返回最优格式。
```html
<!-- 通过 URL 参数请求 WebP 格式 -->
<img src="https://cdn.example.com/photo.jpg?format=webp&q=80">
```
也可以通过 `Accept` 请求头自动协商：浏览器发送 `Accept: image/webp`，CDN 自动返回 WebP 格式，无需改业务代码。
### 文本压缩：Brotli 比 Gzip 再省 20%-30%
```nginx
gzip on;
gzip_types text/plain text/css application/json application/javascript;
# Brotli 压缩效果更好，主流浏览器已支持
brotli on;
brotli_types text/plain text/css application/json application/javascript;
brotli_comp_level 6;
```
Brotli 在压缩比上优于 Gzip，但压缩速度稍慢。对于静态资源可以预压缩，动态内容用 Gzip 即可。Cloudflare 默认开启 Brotli，阿里云 CDN 需要在控制台手动开启。
### 视频优化：编码格式选择影响巨大
H.264 是兼容性最好的选择，但从成本角度看，H.265/HEVC 比 H.264 节省约 50% 的码率，AV1 节省约 60%。如果目标用户主要在移动端，可以优先推送 H.265 版本。
自适应码率（ABR）也是必须做的：根据用户带宽动态选择清晰度，避免 4K 视频推给 3G 网络，既浪费流量又卡顿。HLS 和 DASH 协议都原生支持 ABR，配置好码率阶梯即可。
## 策略三：计费方式优化
很多人只关注 CDN 的单价，但计费方式选错了，再低的价格也省不了钱。
**按流量 vs 按带宽峰值：**
- 流量平稳、可预测 → 按流量计费
- 有明显高峰（直播、促销、游戏更新）→ 按 95 带宽峰值计费
- 流量波动大但不确定 → 先按流量计费，积累一个月数据再判断
**预留带宽/流量包：** 各厂商都提供预付费流量包，通常比按量付费便宜 20%-40%。适合流量稳定的业务。阿里云的 CDN 流量包、腾讯云的预付费带宽包都是这个思路。
**跨区域费用差异：** 国内流量和海外流量价格差 2-5 倍。如果海外用户不多，不需要开全球加速。只开需要的区域，能省不少钱。一个常见误区是开了"全球加速"却 90% 的流量来自国内，多花了好几倍的钱。
**主流 CDN 厂商价格对比（国内流量，2026 年参考价）：**
| 厂商 | 按流量（元/GB） | 按带宽（元/Mbps/天） | 特点 |
|-----|-------------|-----------------|-----|
| 阿里云 | 0.20-0.24 | 0.96-1.36 | 生态完善，流量包折扣大 |
| 腾讯云 | 0.20-0.25 | 0.96-1.20 | 免费额度多，适合中小业务 |
| 七牛云 | 0.18-0.29 | - | 图片处理能力强 |
| Cloudflare | 免费起步 | Pro $20/月 | 海外节点多，国内速度一般 |
## 策略四：多 CDN 架构
单一 CDN 供应商存在两个问题：一是议价空间有限，二是可用性风险集中。多 CDN 不是大公司才需要，日流量超过 10TB 就值得考虑。
**实现方式：**
1. **DNS 层面**：用 CNAME 指向多个 CDN，做加权轮询。缺点是切换延迟较高（DNS 缓存 TTL）
2. **智能调度**：根据用户位置、CDN 节点负载、实时成本选择最优路径。DNSPod、NS1 等支持按策略解析
3. **按内容类型分配**：静态资源走便宜 CDN，动态内容走高性能 CDN，视频走专用 CDN
```javascript
// 简化的 CDN 选择逻辑
function selectCDN(contentType, userRegion) {
const policy = {
'image': { cdn: 'low-cost-cdn', regions: ['cn-east', 'cn-south'] },
'video': { cdn: 'video-cdn', regions: ['global'] },
'api': { cdn: 'high-perf-cdn', regions: ['cn-east'] }
};
return policy[contentType]?.cdn || 'default-cdn';
}
```
**按内容类型分配 CDN 的成本差异示例：** 一家视频平台把图片流量切到低成本的通用 CDN（单价低 40%），视频流量留在专用 CDN，整体成本下降约 25%。
**多 CDN 的难点**在于缓存一致性管理和流量调度精细化。面试中如果追问，可以从 DNS 切换的延迟问题、缓存预热策略、流量分配比例调整这几个角度展开。
## 策略五：请求次数优化
请求次数费用容易被忽略，但在高并发场景下占比不低。每千次请求 0.01 元，日请求 10 亿次就是每天 1 万元。
**主要优化手段：**
- **资源合并**：把多个小文件合并成一个，减少请求数。CSS/JS 打包是基本操作
- **雪碧图**：小图标合并为一张大图，用 CSS 定位显示。在 HTTP/1.1 下效果明显，HTTP/2 下收益降低
- **HTTP/2 多路复用**：升级到 HTTP/2 后，多个请求可以复用一个连接，但请求次数仍然计费
- **减少无效请求**：404 请求也计费，定期清理失效链接和过期资源
- **API 响应合并**：多个接口调用合并为一个批量接口，减少 API 请求次数
## 策略六：成本监控与告警
不做监控的优化都是盲目的。需要关注的指标：
| 指标 | 告警阈值 | 说明 |
|-----|---------|-----|
| 缓存命中率 | < 90% | 低于此值说明缓存策略有问题 |
| 流量环比增长 | > 20% | 短期突增可能是攻击或配置错误 |
| 带宽峰值/均值比 | > 3:1 | 峰值过高说明可以优化计费方式 |
| 4xx/5xx 比例 | > 1% | 错误请求也在花钱 |
**成本归因分析**也很重要。用 SQL 分析 CDN 日志，找出流量 Top 10 的 URL，看看是不是某个大文件没做压缩，或者某个接口的缓存 TTL 设置太短。
```sql
-- 查询流量最大的 URL
SELECT url, SUM(bytes) as total_bytes, COUNT(*) as requests
FROM cdn_logs
WHERE date >= CURRENT_DATE - INTERVAL 7 DAY
GROUP BY url
ORDER BY total_bytes DESC
LIMIT 10;
-- 查询缓存命中率低的 URL
SELECT url,
COUNT(*) as total,
SUM(CASE WHEN cache_status = 'HIT' THEN 1 ELSE 0 END) / COUNT(*) * 100 as hit_rate
FROM cdn_logs
WHERE date >= CURRENT_DATE - INTERVAL 7 DAY
GROUP BY url
HAVING hit_rate < 80
ORDER BY hit_rate;
```
## 优化效果汇总
| 优化手段 | 典型节省幅度 | 实施难度 |
|---------|-----------|--------|
| 缓存命中率提升（72%→95%） | 30%-40% 流量 | 低 |
| 图片格式转换（JPEG→WebP） | 25%-35% 图片流量 | 低 |
| 视频编码升级（H.264→H.265） | 40%-50% 视频流量 | 中 |
| 计费方式调整 | 10%-30% 总成本 | 低 |
| 多 CDN 架构 | 15%-25% 总成本 | 高 |
| Brotli 替代 Gzip | 20%-30% 文本流量 | 低 |
**优化优先级建议**：先做缓存命中率和图片优化（投入小、见效快），再做计费方式调整和视频编码升级（需要一定技术投入），最后考虑多 CDN 架构（架构改动大）。
面试中回答这个问题，核心要传达三点：一是理解 CDN 成本的结构性差异（流量是大头，优化重心在这里），二是掌握分层优化思路（缓存 → 内容 → 计费 → 架构），三是能给出量化的优化预期（不是笼统的"能省钱"，而是"缓存命中率从 X 提升到 Y 可以节省 Z% 的流量成本"）。追问方向通常涉及缓存一致性如何保证、多 CDN 的流量调度怎么实现、如何平衡成本和性能——这三个问题想清楚，这个话题基本就过了。计算机基础5月27日 22:32
CDN 缓存策略有哪些？命中率怎么优化？## 直接回答
CDN 缓存策略核心就三件事：**控制缓存多久（TTL）、区分缓存谁（Cache Key）、决定何时更新（刷新机制）**。优化命中率的关键是：**减少回源、合理分 TTL、忽略无关参数、预热热门资源**。
## 缓存策略拆解
### TTL 策略——最基础的缓存控制
TTL 决定内容在边缘节点的存活时间：
- 静态资源（图片、字体、CSS/JS 带 hash）：设长 TTL，甚至 `max-age=31536000, immutable`
- 半静态内容（商品页、文章页）：分钟级 TTL，配合软刷新
- 动态接口（用户数据、实时行情）：不缓存或秒级 TTL，走协商缓存（ETag / Last-Modified）
```http
Cache-Control: public, max-age=31536000, immutable // 带 hash 的静态资源
Cache-Control: public, max-age=300, s-maxage=60 // CDN 缓 60s，浏览器缓 5min
Cache-Control: no-cache, ETag: "v2-abc" // 协商缓存
```
### Cache Key 策略——决定哪些请求共享缓存
默认 Cache Key 是完整 URL。问题在于：`?utm_source=weibo` 和 `?utm_source=zhihu` 本是同一资源，却被分成两条缓存，白白回源。
优化方式：
- **忽略无关查询参数**：过滤 `utm_*`、`timestamp` 等不影响内容的参数
- **自定义 Cache Key**：加入 `Cookie` 中的地区码，忽略 `PHPSESSID`
- **Vary 头**：让 CDN 按 `Accept-Encoding` 区分 gzip/br 版本
### 分层缓存——边缘 → 区域 → 源站
请求查找顺序：**边缘节点 → 区域节点 → 源站**。边缘未命中会回区域，区域未命中才回源。所以优化重点是**让请求尽量在边缘命中**。
## 命中率优化实战
### 1. 忽略 URL 参数
这是命中率低最常见的原因。一条 `?token=xxx` 就能让缓存全部失效。阿里云 CDN 实测：忽略无关参数后命中率可从 40% 提升到 90%+。
### 2. 大文件分片回源（Range 回源）
用户看视频只看了前 5 分钟，但 CDN 回源拉了整个文件。开启 Range 回源后只拉需要的片段，减少回源流量，也提升字节命中率。
### 3. 缓存预热
新版本发布或大促前，主动把热门资源推到各边缘节点。两种方式：
- **API 预热**：调用 CDN 控制台接口主动推送
- **模拟请求**：用脚本批量请求触发被动缓存
### 4. 版本化发布代替刷新
与其发版后全站刷新缓存，不如在文件名里带 hash：`app.3f2a1b.js`。内容变了 hash 就变，旧缓存自然过期，**无需主动刷新**。
### 5. 监控命中率指标
- **请求命中率** = 缓存命中请求数 / 总请求数
- **字节命中率** =（边缘响应流量 - 回源流量）/ 边缘响应流量
请求命中率 >90% 为健康，70%-90% 需要优化，<70% 必须排查。
## 追问：内容更新后用户还看到旧版本怎么办？
三层解法，按优先级：
1. **文件名带 hash**，一劳永逸（最推荐）
2. **URL 刷新**，精确清除单条缓存
3. **全站刷新**，最后手段，会瞬间压高源站
## 追问：缓存命中率突然下降怎么排查？
按这个顺序查：
1. 看是否有新参数打入了 Cache Key（查访问日志里的 URL 变体）
2. 看源站是否返回了 `no-store` / `private` 头
3. 看 TTL 是否被覆盖缩短
4. 看是否有大流量回源（可能是爬虫或攻击绕过缓存）
计算机基础5月27日 22:21
CDN 如何配置 HTTPS？三种回源模式有什么区别？## 直接回答
CDN 配置 HTTPS 主要有三种方式：**自定义证书上传、CDN 免费证书、SNI 多域名证书**。HTTPS 回源模式分三档：Flexible（仅客户端加密）、Full（全链路加密但不验证源站证书）、Full Strict（全链路加密且严格验证源站证书），生产环境应选 Full Strict。
## HTTPS 配置方式
**自定义证书上传**：购买或申请 SSL 证书后，在 CDN 控制台上传 .crt 证书和 .key 私钥。优点是完全可控，支持通配符和 EV 证书；缺点是需手动续期。
**CDN 免费证书**：主流 CDN 支持 Let's Encrypt 等免费证书，自动签发和续期，适合中小站点。Cloudflare 的 Universal SSL 就属此类。
**SNI 方式**：CDN 在同一 IP 上通过 SNI 区分不同域名的证书，客户端握手时携带域名，服务端返回对应证书。现代浏览器均支持。
```bash
# Cloudflare 启用 Universal SSL 示例
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/ssl" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-d '{"value":"strict"}'
```
## 三种 HTTPS 回源模式
这是面试核心，务必理解三者区别：
**Flexible**：用户→CDN 走 HTTPS，CDN→源站走 HTTP。源站无需证书，但回源链路明文传输，存在中间人风险。仅适合测试环境或纯静态内容。
**Full**：全链路 HTTPS，但 CDN 不验证源站证书是否合法（自签名证书也接受）。比 Flexible 安全，但无法防御源站侧的证书伪造攻击。
**Full Strict**：全链路 HTTPS + 严格证书验证，要求源站证书由受信 CA 签发且域名匹配。安全性最高，证书异常会直接拒绝连接。金融、政务等场景必选。
## 关键配置实践
强制 HTTPS 跳转和 HSTS 是标配：
```nginx
# Nginx 强制跳转
server {
listen 80;
return 301 https://$host$request_uri;
}
# HSTS 响应头
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
```
SSL 协议只保留 TLS 1.2 和 1.3，禁用弱加密套件。启用 OCSP Stapling 减少握手延迟，配置会话缓存复用 SSL 连接：
```nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
```
## 常见坑
**无限重定向循环**：CDN 开启强制 HTTPS，源站又把 HTTPS 重定向回 HTTP，形成死循环。解决办法是源站只监听 80 端口或正确识别 CDN 传递的 X-Forwarded-Proto 头。
**混合内容警告**：HTTPS 页面加载了 HTTP 资源，浏览器会拦截。用 CSP 头自动升级：`Content-Security-Policy: upgrade-insecure-requests`。
**证书链不完整**：只上传了域名证书缺少中间证书，导致客户端无法验证。解决：按域名证书→中间证书的顺序拼接后上传。
## 追问方向
- SNI 在什么场景下会失效？老旧客户端（IE6/Windows XP）不支持 SNI，CDN 如何兼容？
- 如果源站证书过期，Full Strict 模式下会发生什么？如何做到零停机续期？
- CDN 开启 HSTS 后源站切换回 HTTP 会有什么后果？计算机基础5月27日 22:21
CDN 如何实现视频加速？有哪些关键技术？## CDN 如何实现视频加速？有哪些关键技术？
CDN 视频加速的核心思路：把视频切片、多码率编码、缓存在离用户最近的边缘节点，播放时根据网络状况动态选择码率和分片，从而降低首屏时间、减少卡顿。
### 一、自适应码率（ABR）
播放器实时检测带宽和缓冲区水位，动态切换码率档位。主流 ABR 算法分三类：
- **基于缓冲区**：缓冲区低选低码率，充足选高码率，实现简单但反应慢
- **基于吞吐量**：用近期下载速率预估带宽，选不超过带宽的最高码率，反应快但波动大
- **混合算法**：同时参考缓冲区和吞吐量，BOLA 和 MPC 是工业界常用方案
**追问：ABR 切换时为什么会出现画面模糊再清晰？**
因为切换发生在分片边界，中间需要等当前分片播完才能请求新码率分片，这段时间画面保持旧码率。
### 二、视频编码优化
| 编码格式 | 相比 H.264 体积 | 编码速度 | 兼容性 | 典型场景 |
|---------|----------------|---------|--------|---------|
| H.264 | 基准 | 快 | 最好 | 通用点播 |
| H.265 | 小 50% | 慢 3-5x | 较差 | 高清/带宽受限 |
| AV1 | 小 60% | 极慢 | 有限 | 未来/超高清 |
生产中通常生成多码率多分辨率版本（码率阶梯），编码参数重点控制：GOP 大小（关键帧间隔）、maxrate/bufsize（码率上限）、帧率（动态场景 60fps，静态 24fps）。
### 三、流媒体协议：HLS vs DASH
**HLS**（Apple 主导）：m3u8 播放列表 + .ts 分片，生态成熟，iOS 原生支持。
**DASH**（MPEG 标准）：mpd（XML）+ .m4s 分片，跨平台，灵活度更高。
两者都能跑在纯 HTTP 上，天然适配 CDN 缓存。CMAF 格式让 HLS 和 DASH 共用同一套 fMP4 分片，只需维护两份 manifest，存储成本减半。
**追问：直播场景下 HLS 延迟为什么高？如何优化？**
HLS 延迟 = 分片时长 x 3（编码缓冲 + 播放列表刷新 + 缓冲区预载）。优化方向：缩短分片到 2-4 秒、用 LL-HLS 的部分分片预加载、或改用 WebRTC/FLV 方案。
### 四、CDN 缓存策略
- **分片缓存**：每个 .ts/.m4s 独立缓存，命中率高，TTL 可设较长（1-24h）
- **播放列表缓存**：.m3u8/.mpd 动态更新，TTL 短（直播 5s，点播 5min）
- **缓存锁**：`proxy_cache_lock` 防止同一分片并发回源击穿缓存
- **智能预加载**：播放器预取后续 2-3 个分片和下一码率档位
### 五、传输层优化
HTTP/2 多路复用减少连接数、头部压缩降低开销；HTTP/3（QUIC）基于 UDP 减少握手延迟、改善弱网拥塞控制。点播用 HTTP 足够，直播低延迟场景倾向 UDP（WebRTC）。
### 六、播放体验优化
首屏慢的典型链路：DNS 解析 → TCP 连接 → TLS 握手 → 请求 m3u8 → 请求分片 → 解码首帧。优化手段：预连接、初始选低码率快速起播、增加关键帧频率（GOP 缩小到 1-2 秒）、预加载首屏分片。
拖动进度条时，需要定位到目标时间对应的关键帧所在的分片。关键帧间隔越短，seek 响应越快，但编码效率略降。
### 七、质量监控
关键指标：首屏时间、卡顿率、码率切换频率、平均播放码率。播放端通过 `waiting`/`playing` 事件采集缓冲数据，定时上报，服务端做聚合告警。
**追问：卡顿率高但码率切换少，可能是什么原因？**
ABR 没有及时降码率，可能是吞吐量估算偏高、缓冲区水位阈值设置过高，或者分片缓存未命中导致回源延迟。计算机基础5月27日 22:21
CDN 如何防御 DDoS 攻击？有哪些安全防护机制？## CDN 能防住 DDoS 吗？核心机制是什么
CDN 确实能防御 DDoS，但靠的不是单点硬扛，而是分布式架构把攻击流量"化整为零"。核心思路：隐藏源站 IP + 全球节点分散流量 + 智能清洗恶意请求。
## DDoS 防护：流量清洗是关键
CDN 防御 DDoS 的核心是**流量清洗**——在边缘节点识别并过滤恶意流量，只把正常请求回源。
清洗分三层：
- **L3/L4 网络层**：过滤 SYN Flood、UDP Flood、ICMP Flood 等协议级攻击。边缘节点直接丢弃不符合 TCP/IP 规范的畸形包，对特定攻击源 IP 在骨干网层面封禁
- **L7 应用层**：分析 User-Agent、Cookie、TLS 指纹等，用 JS Challenge 或滑块验证判断请求是否来自真人。AI 行为分析会给每个请求打信誉分，低分直接拦截
- **Anycast 架构**：攻击流量根据地理位置被吸引到最近的边缘节点，把大规模分布式攻击拆成多个小流量就地处理，不集中到单点
限流是清洗的辅助手段：
```nginx
# 单 IP 限流
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
limit_req zone=api burst=20 nodelay;
}
```
## WAF：应用层攻击的防火墙
WAF（Web Application Firewall）防护 SQL 注入、XSS、CSRF、文件包含等 Web 攻击：
- **输入验证**：过滤用户输入中的恶意载荷
- **输出编码**：对响应内容编码，防止 XSS 执行
- **规则匹配**：基于正则或签名库拦截已知攻击模式
```nginx
# 防注入和 XSS
if ($args ~* "union.*select.*from") { return 403; }
if ($args ~* "<script|javascript:") { return 403; }
```
WAF 部署模式：反向代理（CDN 作为代理入口）、透明代理（旁路拦截）、DNS 模式（通过 DNS 重定向引流）。
## 访问控制：限源、限地、防盗链
**IP 黑白名单**——直接放行或封禁特定 IP 段：
```nginx
allow 192.168.1.0/24;
deny all;
```
**地理位置限制**——仅允许特定国家/地区访问，或屏蔽高风险地区：
```nginx
geo $allowed_country {
default no;
CN yes;
}
if ($allowed_country = no) { return 403; }
```
**Referer 检查**——防盗链，阻止第三方直接引用你的资源：
```nginx
valid_referers none blocked example.com *.example.com;
if ($invalid_referer) { return 403; }
```
## 加密传输与 Token 鉴权
HTTPS + HSTS 保证传输层安全。Token 认证防止资源被非法访问——服务端用密钥、路径、时间戳生成签名，CDN 边缘校验签名合法性：
```python
import hashlib, time
def generate_token(secret, path, ts):
return hashlib.sha256(f"{secret}{path}{ts}".encode()).hexdigest()
```
## 爬虫防护
识别合法爬虫（如 Googlebot）放行，恶意爬虫限流或封禁。方法：User-Agent 分析、行为模式识别、访问频率监控。
## 分层防御才是正确姿势
单一机制防不住复杂攻击，生产环境必须分层：
```
用户 → CDN 边缘节点（流量清洗） → WAF（应用层防护） → 源站（深度防御）
```
- 边缘节点：基础过滤、限流、清洗
- WAF：应用层攻击拦截
- 源站：最小权限、定期审计、应急响应
面试回答时记住：**CDN 防御 DDoS 靠分布式 + 智能清洗，不是硬扛；应用安全靠 WAF + 访问控制组合拳；生产环境必须分层，没有银弹。**
**追问：CDN 能防住多大规模的 DDoS？** 看厂商能力。主流高防 CDN 的 Anycast 网络总带宽可达 10Tbps+，远超单机高防的 1Tbps 上限。关键在于 Anycast 架构能把流量分散到全球节点，不是靠一台机器硬抗。计算机基础5月27日 22:19
CDN 性能监控有哪些核心指标？怎么搭建监控体系？## CDN 性能监控的五个核心指标
**缓存命中率**——CDN 监控的第一指标。命中率 = 缓存命中请求数 / 总请求数 × 100%，静态资源目标 95% 以上，整体 90% 以上。命中率骤降往往意味着缓存键配置错误或 TTL 过短，这是面试最爱追问的点。
**TTFB（首字节时间）**——从请求发出到收到第一个字节的耗时，包含 DNS 解析、TCP 连接、TLS 握手和服务器处理。静态内容 P95 应低于 100ms，动态内容低于 500ms。注意：要分开统计命中和未命中的 TTFB，否则平均值会掩盖问题。
**回源率**——回源请求数占总请求的比例，目标低于 10%。回源率高直接导致源站压力大、用户延迟高。面试常见追问：缓存命中率突然从 95% 掉到 60%，你怎么排查？思路：检查是否有大范围缓存失效（批量 purge）、缓存键是否冲突、TTL 是否被改短。
**错误率**——4xx 和 5xx 占总请求比例，4xx 目标低于 0.1%，5xx 低于 0.01%。5xx 飙升通常意味着源站过载或 CDN 节点异常，4xx 激增则可能是配置错误（如回源 URL 改了但 CDN 规则没更新）。
**带宽与 QPS**——带宽监控分边缘带宽和回源带宽，QPS 关注峰值和均值。流量突增需要区分是正常业务高峰还是攻击，结合错误率和延迟一起判断。
## 监控体系怎么搭
三层架构：**数据采集 → 存储/计算 → 可视化/告警**。
采集层用 CDN 厂商的日志流（Cloudflare Logs、AWS CloudFront 实时日志）或自建 Nginx 日志，关键字段包括 `request_time`、`upstream_cache_status`、`upstream_response_time`。存储计算层用 Prometheus 做指标聚合，ELK 做日志检索。可视化用 Grafana 搭看板，按地域、ISP、内容类型分维度展示。
告警规则要设置三个：TTFB P95 超阈值持续 5 分钟、缓存命中率低于 80% 持续 10 分钟、5xx 错误率超 1% 持续 3 分钟。告警通道走企业 IM + 值班电话，5xx 告警级别必须高于延迟告警。
## 面试追问方向
- **缓存命中率低怎么优化？** 检查缓存键是否包含不必要的动态参数、TTL 是否合理、是否需要分层缓存（parent cache + edge cache）。
- **如何区分 CDN 问题还是源站问题？** 对比命中请求和未命中请求的 TTFB，如果命中请求也慢，问题在 CDN 层；如果只有未命中慢，问题在源站或回源链路。
- **多 CDN 怎么监控？** 统一指标口径，用同一套 Grafana 看板对比各厂商的命中率、延迟和错误率，按地域做流量调度。
掌握五个核心指标（命中率、TTFB、回源率、错误率、带宽/QPS）加一套采集-存储-告警的完整方案，面试基本够用。计算机基础5月27日 22:18
CDN 故障排查的流程是什么？有哪些常用工具？## 直接回答
CDN 故障排查的核心流程：**确认范围 → 检查DNS → 检查网络连通性 → 检查缓存状态 → 检查源站 → 定位修复**。
**第一步，确认故障范围。** 问三个问题：是全量用户还是部分地域？是持续报错还是间歇性？是从什么时候开始的？范围判断决定后续排查方向——全局故障看CDN节点和DNS，局部故障看网络链路和缓存。
**第二步，检查DNS解析。** CDN 依赖 DNS 将用户调度到最近的边缘节点，DNS 出问题一切白搭。用 `dig` 或 `nslookup` 确认域名是否正确解析到 CDN CNAME，检查不同地域 DNS 服务器的解析结果是否一致。常见坑：DNS 缓存未更新导致调度到已下线节点。
**第三步，检查网络连通性。** `ping` 看延迟，`traceroute` 或 `mtr` 看链路丢包，`curl -v` 看 HTTP 握手各阶段耗时。重点关注 SSL 握手时间——如果证书链不完整或配置错误，握手会失败或变慢。
**第四步，检查缓存状态。** 看响应头里的 `X-Cache` 字段，HIT 还是 MISS。缓存命中率骤降是最常见的性能劣化原因。排查缓存键配置是否合理、TTL 是否过长导致内容不更新、是否有绕过缓存的请求头。
**第五步，检查源站。** 绕过 CDN 直接访问源站，如果源站也慢，问题在源站不在CDN。看源站负载、响应时间、错误日志。
## 核心工具速查
| 场景 | 工具 | 用法 |
|------|------|------|
| DNS排查 | `dig`/`nslookup` | `dig @8.8.8.8 example.com` |
| 网络延迟 | `ping`/`mtr` | `mtr -r -c 10 cdn.example.com` |
| HTTP调试 | `curl` | `curl -w "@format.txt" -o /dev/null -s URL` |
| SSL检查 | `openssl` | `openssl s_client -connect host:443` |
| 缓存分析 | 日志+响应头 | `grep "X-Cache" access.log \| sort \| uniq -c` |
| 日志分析 | ELK Stack | Kibana 看错误率趋势和地域分布 |
```bash
# curl 计时模板 curl-format.txt
time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_starttransfer: %{time_starttransfer}
time_total: %{time_total}
```
## 追问：缓存刷新后用户仍看到旧内容怎么办？
先确认刷新是否生效——用 `curl -I` 检查响应头的 `X-Cache` 和 `Last-Modified`。如果刷新成功但用户仍看到旧内容，三个可能：本地浏览器缓存、中间运营商缓存、多CDN节点同步延迟。对应措施：版本化URL（`app.js?v=2`）、缩短TTL、检查CDN供应商的刷新接口是否覆盖全部节点。
## 追问：如何预防CDN故障？
三件事：监控告警（节点可用性、缓存命中率、错误率）、健康检查（定时探测各节点）、容灾预案（多CDN切换、源站冗余、DNS快速切流量）。面试中能讲出"监控+容灾"两条线，基本过关。