面试题手册

CDN 的核心目标只有一个：让用户访问离自己最近的内容副本。而 DNS 是实现这个目标的第一道关卡——用户在浏览器输入域名的那一刻，DNS 就已经决定了流量去向。理解 DNS 在 CDN 中的调度机制，是网络和后端面试的高频考点。从一次完整请求说起当用户访问 www.example.com 时，DNS 解析并非直接返回源站 IP，而是经历了一条精心设计的调度链路：用户 → 本地 DNS 递归查询 → 根域名服务器 → .com 顶级域 → example.com 权威 DNS → 返回 CNAME: www.example.com.cdn-provider.com. → CDN 全局负载均衡（GSLB） → 根据用户 IP + 运营商 + 节点负载 → 返回最优边缘节点 IP → 用户直连边缘节点获取内容关键转折点在于 CNAME 记录。网站管理员将域名 CNAME 到 CDN 分配的别名域名后，后续的解析控制权就移交给了 CDN 的 DNS 系统。CDN 的 GSLB（Global Server Load Balancer）会综合多种因素，选择最合适的边缘节点 IP 返回给用户。四种核心调度策略基于地理位置的调度这是最基础也最常用的策略。CDN 的 DNS 服务器拿到用户 Local DNS 的 IP 地址后，通过 GeoIP 数据库查询其地理位置，然后返回同一区域内的边缘节点。但这里有一个经典问题：Local DNS 的位置不一定等于用户的位置。比如一个北京用户配了运营商的 DNS 服务器在上海，那 GeoIP 会认为用户在上海，返回上海节点。这也是 HTTPDNS 方案出现的重要原因，后面会详细讲。基于运营商的调度国内网络环境复杂，跨运营商访问往往延迟很高。CDN 通常会在每个主要运营商（电信、联通、移动）内部署专用节点，调度时优先匹配同运营商线路：电信用户 → 电信线路 CDN 节点（避免跨网绕行）联通用户 → 联通线路 CDN 节点对于小型运营商（如长城宽带、各地广电），CDN 通常将它们聚合到一条 BGP 线路上，简化调度配置的同时保证可达性。基于负载和健康的调度地理位置最近的节点不一定是最优的。如果北京节点 CPU 占用 90%、带宽跑满，把新流量继续导过去只会让体验更差。CDN 会实时监控每个节点的负载指标（CPU、带宽、并发连接数、响应时间），动态调整分配权重。健康检查同样关键。当某个节点宕机或响应异常时，调度系统会在秒级将其从可用列表中摘除，将流量切换到备用节点。这里 TTL 的设置直接影响切换速度——TTL 越短，客户端越快重新解析拿到新 IP，但 DNS 查询量也越大。生产环境通常设置 60~300 秒。基于 Anycast 的调度一些全球性 CDN（如 Cloudflare）采用 Anycast 技术。多个边缘节点共享同一个 IP 地址，路由协议（BGP）自动将用户流量导向网络拓扑上最近的节点。与传统 DNS 调度相比，Anycast 的优势在于：不依赖 GeoIP 数据库的准确性路由层自动容灾，节点故障时 BGP 自动收敛天然防 DDoS——攻击流量被分散到多个节点但 Anycast 对网络运维能力要求极高，国内 CDN 厂商大多还是以 DNS 调度为主。HTTPDNS：解决 Local DNS 调度不准的方案传统 DNS 调度依赖 Local DNS 的 IP 判断用户位置，但在以下场景会出问题：用户手动配了公共 DNS（如 8.8.8.8、114.114.114.114），GeoIP 无法定位真实位置运营商 DNS 劫持，返回错误 IP 或广告页面Local DNS 跨省跨运营商部署，调度结果偏差大HTTPDNS 的做法是：客户端（通常是 App）跳过系统 DNS，直接通过 HTTP 请求向 CDN 的 HTTPDNS 服务查询最优节点。服务端拿到客户端真实出口 IP，调度精度大幅提升：App → HTTP 请求 HTTPDNS 服务（携带域名） → 服务端获取客户端真实 IP → 精确调度 → 返回最优 CDN 节点 IP → App 直接连接该 IP微信、淘宝、抖音等国民级 App 都内置了 HTTPDNS，这也是面试中常被追问的知识点。CDN 缓存与回源机制DNS 把用户调度到边缘节点后，接下来是缓存命中还是回源的问题，这直接影响加速效果。缓存策略边缘节点根据 HTTP 响应头决定资源缓存时长：| 响应头 | 作用 ||-------|------|| Cache-Control: max-age=3600 | 缓存 3600 秒 || Expires: Thu, 01 Dec 2026 16:00:00 GMT | 绝对过期时间 || X-Cache: HIT | CDN 命中缓存 || X-Cache: MISS | CDN 未命中，需回源 |CDN 通常还会设置默认缓存规则：静态资源（图片、CSS、JS）默认缓存较长时间，动态接口默认不缓存或缓存极短时间。回源策略缓存 MISS 时，边缘节点需要回源站获取内容：普通回源：边缘节点直接请求源站，获取后缓存并返回给用户回源跟随 301/302：源站返回重定向时，CDN 跟随重定向获取最终内容回源负载均衡：多源站场景下，CDN 可配置多个源站 IP 并做负载均衡回源超时与重试：设置回源超时时间和重试次数，避免源站慢导致边缘节点阻塞生产环境中一个常见问题是回源风暴：当某个热门资源的缓存全部过期时，大量请求同时回源，可能把源站压垮。CDN 通常通过"回源合并"（多个相同请求只回源一次）来缓解。DNS 配置实战单域名全站加速www.example.com. 600 IN CNAME www.example.com.cdn-provider.com.这是最简单的接入方式，所有请求都经过 CDN。动静分离; 动态接口直连源站api.example.com. 300 IN A 192.0.2.1; 静态资源走 CDNstatic.example.com. 600 IN CNAME static.example.cdn-provider.com.img.example.com. 600 IN CNAME img.example.cdn-provider.com.动态内容（API 接口、用户数据）不适合 CDN 缓存，应该直接回源或使用动态加速（DCDN）；静态资源（图片、CSS、JS）走 CDN 缓存加速。TTL 设置的权衡| 场景 | 推荐 TTL | 理由 ||------|---------|------|| 主域名 CDN 接入 | 600 秒 | 平衡调度灵活性与查询开销 || 静态资源域名 | 3600 秒 | 资源变更少，长缓存减少查询 || 故障切换敏感业务 | 60 秒 | 快速摘除故障节点 |常见问题与排查思路用户被调度到远端节点排查方向：检查用户 Local DNS 的 IP 归属地，确认 GeoIP 数据是否准确。如果用户使用了公共 DNS，考虑引导接入 HTTPDNS。CDN 缓存命中率低常见原因：源站返回了 Cache-Control: no-store 或 max-age=0；URL 中包含随机参数导致缓存 key 不命中；TTL 设置过短。逐一排查响应头和缓存配置即可。源站 IP 暴露攻击者通过历史 DNS 记录或子域名爆破获取源站真实 IP 后，可绕过 CDN 直接攻击源站。防护措施：源站防火墙只放行 CDN 回源 IP 段；使用 Cloudflare 等支持代理模式的 CDN 时，确保 DNS 记录开启代理（橙色云图标）。面试核心问题Q: CDN 是怎么知道用户在哪的？通过用户 Local DNS 的 IP 地址查 GeoIP 数据库。但 Local DNS 不一定和用户同位置，所以更精确的方案是 HTTPDNS——客户端直接上报真实 IP。追问：如果用户用了 8.8.8.8 这种公共 DNS 怎么办？答：传统 DNS 调度会误判位置，所以大厂 App 都内置 HTTPDNS。Q: CDN 的 CNAME 记录 TTL 为什么设那么短？短 TTL 保证了节点故障时能快速切换——客户端缓存过期后会重新查询，拿到健康节点的 IP。代价是 DNS 查询量增大，但相比服务中断，这个代价是值得的。Q: CDN 节点挂了怎么办？健康检查系统检测到节点异常后，GSLB 立即将其从调度池摘除，新请求分配到其他健康节点。已缓存旧 IP 的客户端需等 TTL 过期后重新解析。紧急情况下可配合 302 重定向做即时切换。Q: Anycast 和 DNS 调度有什么区别？DNS 调度是应用层方案，根据 IP 地理位置信息做决策；Anycast 是网络层方案，BGP 路由协议自动选择拓扑最近的节点。Anycast 不依赖 GeoIP 准确性，天然容灾和防 DDoS，但对网络运维要求高，国内 CDN 以 DNS 调度为主流。