第 11 章 网络层（下）：DNS 与 CDN 初识
副题：问路与抄近道——域名怎么变成 IP，以及"让旅程变短"的 CDN 为什么存在
第 10 章我们跟着请求走完了网络段的"上路"部分：报文写好了、连接建好了、加密加上了。但还差最后一步才能出发——**浏览器怎么知道要去哪台服务器？**小明输入的是
www.example.com，可网络世界里没有"名字"，只有 IP 地址。本章回答两个问题：谁把域名翻译成 IP（DNS）？以及为什么有的页面加载飞快、有的慢吞吞——除了服务器远近，还有什么在起作用（CDN）？
本章要建立的认知
- DNS 是互联网的"电话簿"：域名 → IP 的翻译靠一套分层的解析体系（递归 + 迭代），分层的意义是"每层只管自己的事"；
- CDN 是"让旅程变短"的技术：静态资源（图片/JS/CSS）离用户越近越快——CDN 把内容复制到边缘节点，用户就近取；
- 两个技术都遵循同一个原则：业务没到，别先上——CDN 是阶段 2 用户增长之后才被逼出来的（第 2 章的"业务逼出技术"）。
11.1 问路：域名到 IP
小明输入 www.example.com，按下回车。浏览器要做的第一件事不是发请求——是问路：这台服务器在哪儿？
这个顺序不是习惯，是依赖：没有 IP 就建不了 TCP 连接（第 10 章），没有连接就发不了 HTTP 报文——DNS 是整条旅程的"第一块多米诺"。所以第 10 章时间线的"连接前空白"，本质是"DNS 还没完成"——先知道去哪，才能出发。这也解释了为什么浏览器要做 DNS 预解析（11.2 的 dns-prefetch）：把第一块多米诺提前推倒，后面的旅程就能快点走完。
网络世界里没有名字，只有 IP 地址（一串数字，如 203.0.113.7）。让"名字"和"地址"对应起来的东西，叫 DNS（Domain Name System，域名系统）——互联网的"电话簿"。浏览器把 www.example.com 交给 DNS，DNS 回答"它在 203.0.113.7"，浏览器才真正出发。
第 10 章说过，慢请求的时间线里有一段"连接前的空白"——那就是 DNS。DNS 慢，请求根本发不出去（浏览器连"去哪"都不知道）。所以 10.1 的"转圈"排查清单里，DNS 是第一个候选：请求发不出去，先问"名字查到了吗"。
排查 DNS 的实操：命令行敲 nslookup www.example.com 或 dig www.example.com——能立刻看到"名字 → IP"的解析结果和耗时。如果 nslookup 都要 200ms，DNS 就是慢请求的元凶；如果 nslookup 秒回但浏览器还是慢，问题在别处（连接或服务端）。DNS 是排查链路上最容易被忽略、也最好排除的一环——一条命令就能定位。（排查"改 DNS 没生效"时，dig 看权威答案、nslookup 看本地缓存——两个一对比，"没生效"到底是服务器没改还是缓存没过期，一目了然。）
解析失败也有几种形态，先认识：域名不存在（nslookup 返回 NXDOMAIN——打错字了/域名没解析）、权威服务器无响应（超时——域名服务商出问题了）、解析到错误 IP（域名被劫持，见 11.3）。排查口诀：先 nslookup 看"查不查得到"，再看"查到的是不是对的"——查不到是 DNS 配置问题，查到不对是安全事件。
可靠性的最后一块砖：本地 DNS 超时怎么办？你的路由器/操作系统会配置多个 DNS 服务器（主/备）——一个没响应就换下一个；浏览器也有自己的兜底（超时后重试或直接报错）。所以"DNS 挂了"很少是"完全解析不了"，更多是"变慢"（主 DNS 超时，等超时才换备）——"慢"比"挂"多，是 DNS 可靠性的常态。
DNS 还是高可用的第一道闸（第 23 章的伏笔）：A 记录可以配多个 IP（203.0.113.7 和 203.0.113.8 两台服务器）——DNS 会轮询返回，用户随机到其中一台；配合"健康检查"（第 23 章），挂掉的服务器可以从 DNS 应答里摘除。"DNS 做负载均衡"（简单版）是第 23 章负载均衡的入场方式——先有 DNS 轮询，后有专业负载均衡。
网络段的排查链也在这里收拢（第 10 章的四段补上 DNS）：DNS（本章）→ 连接（第 10 章）→ TTFB（第 12/14 章）→ 下载（第 16 章）——10.1 的"慢在哪段看哪段"，现在每一段都有了章节归属（网络段的完整总结，留到本章末尾 CDN 讲完之后再做）。
浏览器侧的解析也是一条缓存链：浏览器缓存 → 操作系统缓存 → 本地 DNS——浏览器先查自己的缓存（上次解析过），没有就查操作系统（系统级 DNS 缓存），都没有才问本地 DNS。这条链的意义：解析过的域名几乎不再真的"解析"——日常访问的 99% 是缓存命中。这也是"改 DNS 后要等很久才生效"的原因：不只是服务器端缓存，你本机的三层缓存都在说旧地址。
"电话簿"这个比喻只说对了一半——DNS 不是一本大电话簿，是一套分布式的层级系统。为什么不能是"一本大电话簿"？因为互联网太大了：全球几亿个域名、每天无数次查询，任何一台"总电话簿"都会被查爆，而且单点故障会让全网瘫痪。所以 DNS 的设计是：没有中心，只有层级。
还有一个"为什么用域名"的根本理由要点破：域名是稳定的名字，IP 是可换的地址。服务器迁移（第 22 章）、换云厂商、加一台服务器（第 23 章）——IP 会变，但域名不变。用户和代码只认域名，IP 变了不影响任何人（DNS 记录更新即可）——域名把"名字"和"地址"解耦了，这和第 5 章决策记录里"服务器会迁移"的约束是同一件事的两个面。反过来，如果代码里写死 IP（"连 203.0.113.7 的数据库"），服务器一迁移就全线崩——写 IP 是反模式，写域名是常识。
还有一个用户侧的理由：域名是给人记的，IP 是给机器认的。www.example.com 有语义（example 的 www 服务），203.0.113.7 是随机数字——人记域名、机器查 IP，各取所需。这也解释了为什么域名本身是资产（一个简短好记的域名能卖钱）：域名是用户和产品之间的第一层品牌。
11.2 解析的旅程：递归与迭代
www.example.com 这个域名，从右往左看，每一段都是一层：
www.example.com
└── .com ← 顶级域（Top-Level Domain）
└── example.com ← 二级域（example 在 .com 下注册的）
└── www.example.com ← 主机名（www 是 example.com 下的一台主机）
顶级域的类型也混个脸熟：通用顶级域（gTLD）——.com、.org、.net（全球通用）；国家顶级域（ccTLD）——.cn、.jp、.hk（按国家/地区）。选哪个影响不大（都归 ICANN 管），但"域名背后的注册局"不同——.com 归美国的 Verisign 管，.cn 归中国的 CNNIC 管——极端情况下（政治、政策）会有管辖权差异，大公司会同时注册多个顶级域（example.com + example.cn）防风险。
域名的层级对应 DNS 服务器的层级，每一层只管自己那一截。其中"本地 DNS"先定义清楚：它就是替你递归的服务器——你的路由器向运营商要一个（或你手动配 8.8.8.8），它负责把问题一路问下去（迭代）并把最终答案带回给你。浏览器认识的只有它，其他的层级浏览器一概不知——这也是"换 DNS"（把本地 DNS 从运营商默认改成公共 DNS）能改变上网体验的原因：递归服务器的质量（缓存、就近、防污染）直接决定你的解析体验。
浏览器
│ ① 问：www.example.com 是几号？ （递归查询：浏览器把问题丢给"本地 DNS"）
▼
本地 DNS 服务器（你的 ISP 或 8.8.8.8 提供的）
│ ② 问：www.example.com 是几号？ （迭代查询：一路问下去）
▼
根服务器（"."）── 答：去问 .com 的服务器 （根服务器只认识顶级域）
▼
.com 服务器 ── 答：去问 example.com 的服务器 （顶级域只认识二级域）
▼
example.com 的权威服务器 ── 答：www 在 203.0.113.7 （权威服务器说了算）
│
▼
本地 DNS 把答案告诉浏览器 ── 浏览器出发
这条旅程里有三个设计要记住：
**第一，递归和迭代的分工。**浏览器只问一次（递归：把问题全权交给本地 DNS，等最终答案）；本地 DNS 一路问下去（迭代：每层只回答"下一步去问谁"）。递归是"代办"，迭代是"逐级问"——浏览器不用知道根服务器、.com 服务器是什么，它只需要认识一个"本地 DNS"就够。
**第二，每层只管自己那一截。**根服务器不认识 example.com（它只认识 .com 在哪儿）；.com 服务器不认识 www（它只认识 example.com 的服务器在哪儿）；只有 example.com 的权威服务器认识 www。分层让每一层的表都很小——根服务器只需要维护 1000 多个顶级域的地址，而不是几亿个域名。这就是"没有中心"的代价与收益：查询要多走几跳，但任何单点倒下都只是"少一层"，不是"全网瘫痪"。（根服务器的事实也补一句：全球只有 13 组根服务器，由 ICANN 协调管理，分布在各大洲——它们是 DNS 层级的"地基"，但正因为每层只管一点，13 组就够用了。）
第三，权威服务器是"说了算"的。"www.example.com 在 203.0.113.7"这个答案，只有 example.com 自己的权威服务器能给出——它是这层域的"产权人"（域名是租的，租约记录在权威服务器里）。其他层都是"指路"，只有权威层是"答案"。这也是为什么域名到期不续费会出大事：权威服务器里的记录失效，整个域名在互联网上"消失"——域名是租来的资产，产权在注册商那里，解析在权威服务器上，两个环节都不能断。
递归服务器还有一个"看不见"的重要职责：它缓存所有问过的答案。你访问过 example.com，你的本地 DNS 就把答案记下来——下次再问，直接答（不用再走迭代链）。所以"换 DNS"（换递归服务器）的体验差异，一半来自递归服务器的缓存质量（缓存多、就近、更新快）。"本地 DNS 的缓存"是解析体验的第一道关——这也是为什么排查 DNS 问题时，dig 要分别看本地解析和公共 DNS 解析（dig example.com vs dig @8.8.8.8 example.com）——两条路的答案一致，才是"权威答案"；不一致，就是中间有人在捣鬼（劫持的排查手法）。
一次"冷解析"（完全没有缓存）的耗时大约 20-100ms（多跳累加）；"热解析"（各级缓存命中）<1ms。这个量级差，就是缓存存在的全部理由——DNS 的体验，就是缓存的体验。
DNS 查询还有两个浏览器侧的"预取"优化（第 8 章资源优化的网络段补充）：dns-prefetch（<link rel="dns-prefetch" href="//cdn.example.com">——提前解析将来要用的域名）和 preconnect（第 10 章提过：提前建立连接）。原理都是"把关键路径上的 DNS 时间提前花掉"——第 8 章的关键路径思维，在这里变成具体的网络段优化。
11.3 DNS 的代价与边界
DNS 的收益很直接（名字可记忆、层级可扩展），它的代价和风险也认识一下。
缓存：快，但有延迟。DNS 查询的每一层都会缓存答案（本地 DNS 缓存、浏览器缓存、操作系统缓存），缓存让重复访问"秒查"。但缓存的代价是更新延迟：域名指向的 IP 变了（服务器迁移、换 CDN），老缓存还在说旧地址——所以 DNS 记录带 TTL（Time To Live，存活时间）：缓存多久作废重查。TTL 短（如 60 秒）更新快但查询多；TTL 长（如 86400 秒）省查询但迁移后要等一天。改 DNS 前先调低 TTL，改完再调回来——运维圈的老经验。
迁移服务器的完整流程走一遍（1-3 年开发者迟早要干一次）：提前一天把 TTL 从 86400 调到 60（让旧缓存快速过期）→ 切 DNS 记录指向新服务器 → 等几分钟到几小时（旧缓存过期，全世界都解析到新地址）→ 验证新服务器正常 → 把 TTL 调回 86400（恢复正常缓存节奏）。跳过第一步的后果：全世界最多要等 24 小时才全部切到新服务器——迁移期间的"一部分用户还在旧服务器"，就是这么来的。
**风险：DNS 是攻击者的头号目标。**第 10 章说过，网络不可靠是基本事实——DNS 是"最容易被利用的不可靠"之一：DNS 劫持（本地 DNS 被篡改，把 example.com 指到攻击者的服务器——用户在假网站上输入密码）、DNS 污染（中间设备篡改 DNS 响应——有些网络环境就是靠这个"墙"一些网站的）。防御手段：DNSSEC（给 DNS 记录加数字签名，验证"答案是真的"——第 10 章证书的签名思想在 DNS 上的复用：CA 给证书签名，DNSSEC 给 DNS 记录签名，同一个"签名链验证身份"的套路）、DoH/DoT（DNS 查询走加密通道——HTTPS 加密思想在 DNS 上的复用）。这两个手段现阶段只需要知道名字——第 19 章安全会回到这里。
DNSSEC 的部署现实也一句：部署率一直不高——因为要在权威服务器上配置密钥、定期轮换，运维成本挡住了大部分站点（直到今天，绝大多数域名都没有 DNSSEC）。所以现实是：DNSSEC 是"应该做但多数没做"——安全手段的部署，永远落后于攻击手段（第 19 章安全会看到这个规律）。
DoH 还有一个现实要提：Chrome、Firefox 已经默认开启 DoH（浏览器自己走加密 DNS，不经过本地 DNS）——用户的 DNS 流量正在"加密化"，运营商和中间设备越来越难劫持 DNS。对你的影响：你的权威服务器要能正确应答加密通道里的查询（DoH 走的是 HTTPS 标准端口，对服务器端透明），但"用户用哪个 DNS"越来越由浏览器说了算——你管不住入口（用户侧），但要保证出口（你的 DNS 配置）永远正确。
DNS 劫持的完整场景走一遍（它是 1-3 年开发者最容易踩的坑）：小明的路由器被攻击者入侵，路由器的 DNS 设置被改成攻击者的服务器——小明访问 bank.example.com，本地 DNS 回答"在攻击者的服务器"——浏览器地址栏显示 bank.example.com（没错！），但页面是攻击者做的假银行——小明输入账号密码，账号没了。DNS 劫持的可怕之处：地址栏是对的，页面是假的——用户无法从浏览器发现。防御手段见 11.3（DNSSEC 验证签名、DoH 绕过被篡改的通道）。
边界：DNS 不是只能查 IP。DNS 记录有类型：A 记录（域名 → IPv4）、AAAA 记录（域名 → IPv6）、CNAME 记录（域名 → 另一个域名，别名）、MX 记录（域名 → 邮件服务器）。日常开发里最常用的是 A 和 CNAME：A 是"终点"（指向 IP），CNAME 是"别名"（指向另一个域名，让那个域名去解析）——CDN 的调度就靠 CNAME（11.5 会看到）。还有一种泛解析（*.example.com 通配所有子域名）——省得每个子域名建一条记录，但也要小心：通配太宽会把不该解析的域名也接住（运维事故的常见来源）。
**决策模型轻量版：DNS 用谁的？**自建 DNS 服务器（bind 一类）vs 用云厂商托管（阿里云/Cloudflare 的 DNS 服务）——九步的答案几乎总是"托管"：托管免费、高可用、带 DDoS 防护；自建要维护、要抗攻击。DNS 是最不该自建的互联网基础设施之一——它的价值在于"全世界都能查到"，自建等于把全世界的查询压在自己服务器上。
域名的"管理清单"也提一句（运维日常的一部分）：注册商（域名在谁那租的——续费、转移都找它）、续费（到期忘了续 = 域名被收回，11.2 说过）、邮箱验证（注册商/WHOIS 的联络邮箱要能收信——很多"域名被偷偷转移"的事故，都是从邮箱被黑开始的）。域名资产的管理口诀：注册商、续费日、联络邮箱，三样都不能丢。
客户端侧也有"用谁的 DNS"的决策（这个由用户/网络环境决定，不由你）：运营商默认 DNS（离你近但可能被劫持）、公共 DNS（8.8.8.8 Google、1.1.1.1 Cloudflare、223.5.5.5 阿里）——公共 DNS 的准确性、防污染能力普遍更好，这也是 DoH 流行后"浏览器自己选 DNS"成为默认的原因。你控制不了用户用哪个 DNS，但你的权威服务器要能正确应答所有查询——你管不了入口，但管得住出口。
11.4 CDN：让旅程变短
DNS 的问题解决了，浏览器出发了。但新的问题来了：页面里的图片、JS、CSS 加载慢。
案例的服务器在上海（一台服务器，第 5 章的选型）。用户分布在全国各地：上海的用户打开快，哈尔滨的用户打开慢——因为物理距离就是延迟：光在光纤里每秒 20 万公里，上海到哈尔滨往返 4000 公里，光速也要 20ms+，加上路由器的排队和转发，实际延迟 40-60ms。页面里的 50 个静态资源（图片、JS、CSS）每个都从上海拉——哈尔滨用户打开页面的时间，是上海用户的 2-3 倍。
静态资源的加载有个特点：内容不变。小明的头像、卡片的 CSS、框架的 JS——这些文件今天加载和明天加载，内容一模一样。第 10 章说过"无状态让缓存成为可能"——静态资源正是缓存的完美对象：为什么不把内容复制到离用户近的地方，让用户就近取？
哈尔滨用户的完整体验描述一下（它是本章的"事故"）：打开内容流，文字先出来了（HTML 是动态的，走源服务器），但图片一张张转圈（50 个静态资源，每个都要从上海拉）——第 8 章说 FCP（第一个内容出现）和白屏有关，而这里的问题是另一个指标：图片到位的时间。页面"打开了但没完全打开"，就是静态资源没有就近加速的典型体验——CDN 的引入，就是冲着这个体验去的。
这里还有一层和第 8 章指标的衔接：静态资源是 LCP 的主要对象。第 8 章说过 LCP（最大内容出现的时间）——网页的"最大内容"通常是图片（头像、封面、大图），而图片走 CDN 就近加载，LCP 直接受益。所以"CDN 让页面变快"在指标上的落点很具体：FCP 更快（样式提前到位）、LCP 更快（图片就近加载）、TTFB 不变（接口还是走源服务器）——三个指标，三种归属，CDN 管前两个。
"物理距离就是延迟"展开一层：延迟 = 传播延迟（光在光纤里的时间，物理极限）+ 排队延迟（路由器转发的等待，与网络拥塞有关）。第 10 章的 RTT 就是这两者的总和——上海到哈尔滨 40-60ms，跨海（到美国）150-200ms。延迟的物理部分没法优化（光速是极限），能优化的只有"路程"——CDN 就是"把路程变短"，而不是"让光更快"。
什么算静态、什么算动态，边界要划清：静态 = 内容不随用户变（图片、JS、CSS、字体、视频）——可以缓存、可以复制；动态 = 内容随用户/状态变（接口响应、个性化页面、购物车数据）——不能缓存（缓存了就给错人）。一句话判断：同一个 URL，两个不同用户拿到的是否一样？一样=静态，不一样=动态——这就是 CDN 能不能加速的判决标准。
静态资源的"形式"也混个脸熟（第 16 章会做格式优化）：图片（JPEG 照片/PNG 透明图/WebP 新一代——体积差好几倍）、JS/CSS（第 21 章构建会压缩打包）、字体（中文网页的字体文件很大，是 CDN 的重点对象）、视频（流媒体是 CDN 最重的负载）。静态资源的"重"，是 CDN 存在的大前提——如果页面没有图片没有样式，CDN 的价值就少一大半。
这就是 CDN（Content Delivery Network，内容分发网络）的思路：把静态内容复制到各地的"边缘节点"，用户请求时从最近的节点取，而不是每次都去源服务器。CDN 不是"加速魔法"，是"让旅程变短"：从"哈尔滨 → 上海"变成"哈尔滨 → 哈尔滨旁边的节点"。
CDN 不是新概念——1998 年 Akamai 成立，内容分发从"用户去取"变成"内容送上门"（从"拉"到"推"的转变）：CDN 先把内容复制到边缘（推），用户再从最近的边缘取（拉）。这又是第 2 章演进循环的实例：带宽越来越贵、用户越来越远，"就近分发"被逼出来了——一个技术活了二十多年，说明它解决的是真实问题。
回到案例：阶段 1 的静态资源（图片、JS、CSS）都在源服务器上（第 5 章的选型：一台服务器全包）——50 个静态资源全部从上海拉。第 8 章的关键路径在这里多了一段：白屏之后，图片和样式还在慢慢到位。这个痛点会在阶段 2 用户增长后被放大（第 16 章的故事），现在先记住：阶段 1 的静态资源裸奔，是合理的（用户还没变远）。
把 CDN 放回第 8 章的关键路径：静态资源在关键路径上（尤其是 LCP 的图片），CDN 不是"移除"关键路径，是"缩短"关键路径的网络段（就近取，跨地域延迟没了）——和第 10 章的连接复用、TLS 会话复用是同一个思路：关键路径不能消失，但每一段都能变短。第 16 章性能优化时，"把关键路径的每一段变短"就是全部工作的总纲——DNS、连接、加密、就近，都是这句话的注脚。
缓存层级的最前端也补一句：浏览器缓存命中的请求，根本到不了 CDN——浏览器（第 10 章的 Cache-Control 会告诉浏览器"能缓存多久"）先接住大部分重复请求，CDN 接住剩下的一部分，源服务器只处理真正的"漏网之鱼"。所以完整的静态资源链路是：浏览器缓存 → CDN 节点 → 源服务器——每一级都是"命中就停，没命中才往下走"（第 16 章的多级缓存图景，这里先立住前两级）。
第 10 章和第 11 章的关系也在这里对齐：HTTP 是"路"，DNS 是"问路"，CDN 是"抄近道"——三样东西合起来，才是"请求在网络段怎么走"的完整答案。
11.5 CDN 的工作原理
CDN 的工作分两层：调度（把用户送到最近的节点）和缓存（节点里存着内容）。
调度靠 DNS。CDN 会把你的域名"接管"过去（通过 CNAME：cdn.example.com 指向 CDN 提供的域名），然后 CDN 的 DNS 服务器根据用户的 IP 判断"他在哪个区域"，返回离他最近的边缘节点的 IP——这就是 GSLB（Global Server Load Balancing，全局负载均衡）：用 DNS 做地理调度。所以 CDN 依赖 DNS 的准确性：DNS 说"你离哈尔滨节点近"，用户就去哈尔滨节点——调度的精度，就是用户体验的精度。
GSLB 和"普通 DNS"的差别也顺带看清：普通 DNS 的答案是"固定的"（example.com 一直在 203.0.113.7），GSLB 的答案是"因人而异的"（哈尔滨用户拿哈尔滨节点、上海用户拿上海节点）——DNS 不只是"查表"，可以是"决策"：第 23 章的负载均衡（按服务器负载决策）与 CDN 的 GSLB（按地理位置决策），是同一个"调度"思想的两张面孔。
GSLB 的一个细节：CDN 返回的 DNS 记录 TTL 通常很短（如 30-60 秒）——因为调度要灵活：节点挂了要能快速切走、新节点上线要能快速接客。普通域名 TTL 长（省查询），CDN 域名 TTL 短（保灵活）——TTL 是"稳定"和"灵活"之间的旋钮，不同场景拧到不同位置（11.3 的原则，这里有了具体实例）。
**缓存靠"回源"。**用户请求 https://cdn.example.com/images/avatar.jpg，流程是：
用户 → 边缘节点（哈尔滨）→ 节点里有吗？
├─ 有 → 直接返回（缓存命中，快）
└─ 没有 → 回源：去源服务器（上海）取一份 → 存到本地 → 返回用户
（下次哈尔滨的用户再来，就命中了）
"边缘节点"的物理形态也补一句：它们是 CDN 厂商部署在世界各地数据中心里的缓存服务器群（一个区域通常有多个节点互为备份）——哈尔滨的节点不是一台服务器，是一个小型机房。CDN 的能力差距，本质就是节点覆盖密度的差距：节点越多越密，"最近"就越近（第 16 章选 CDN 厂商时，节点覆盖是核心维度）。
CDN 的三个概念要分清：命中（节点有，直接给——快）、回源（节点没有，去源服务器取——慢，但只有第一次）、命中率（命中的请求占比——CDN 性能的核心指标，第 16 章深化）。CDN 的性能逻辑就一句话：命中率越高，用户越快——而命中率取决于内容是不是"真的不变"（图片基本不变，命中率高；个性化接口天天变，命中率低，不适合 CDN）。
命中率优化的三个方向先预告（第 16 章展开）：长 TTL（缓存久一点，命中率高但更新慢）、版本化文件名（11.6 的手法，让"缓存失效"变成"换新名字"）、预热（活动前把热点资源主动推上节点——11.6 的"主动推送"模式）。三个方向都是同一个目标：让"命中"成为常态，让"回源"成为例外。
命中与回源的量级差先给个直觉：命中 10-20ms（就近节点直接给），回源 100-200ms（跨地域去源服务器）——差一个量级。页面 50 个静态资源，全命中 vs 全回源，就是"秒开" vs "转圈"的区别。所以 CDN 配置的核心工作，就是把命中率做高（第 16 章深化）。
回源还有一个第 12 章的衔接：回源请求本质是一次普通的 HTTP 请求到源服务器——CDN 节点替用户发请求、取内容、存本地、返给用户。所以"CDN 回源"在源服务器眼里，就是"一个用户请求"（只是 User-Agent 是 CDN 节点）——第 12 章服务端处理的所有机制（路由、限流、日志），对回源请求一视同仁（第 23 章还要专门识别：CDN 回源和真实用户，限流策略不同）。
节点缓存多久，由第 10 章的 Cache-Control 首部说了算：源服务器响应时带上 Cache-Control: public, max-age=86400，CDN 节点就知道"这个内容可以缓存一天"——第 10 章的首部，在这里变成了 CDN 的缓存指令（HTTP 的每个设计都在被复用）。源服务器不带头，CDN 默认不缓存（保守）——"CDN 不生效"的排查第一站：看源响应有没有 Cache-Control。
CDN 和 HTTPS 还有一个协同点：全站 HTTPS（第 10 章）下，CDN 节点也要有证书——用户访问 https://cdn.example.com，证书要么由 CDN 代管（把证书交给 CDN 部署），要么回源时再走一轮源服务器自己的 HTTPS。证书管理（第 10 章的"要续期"）在 CDN 场景多了一层：域名和证书的部署面从一台服务器变成几十个节点——这也是云厂商 CDN 普遍免费代管证书的原因。
CDN 管静态，服务器管动态——这是分工的边界：图片、JS、CSS、字体（静态，内容不变）走 CDN；接口（动态，内容随用户和状态变）走源服务器。第 7 章的接口设计在这里多了一层含义：静态资源和接口要分域名（cdn.example.com 管静态，api.example.com 管接口）——分域名不只是整洁，是让 CDN 只缓存"该缓存的"（第 10 章说过同一域名并发连接限制，静态资源走独立域名还顺便绕开了它）。第 7 章的 12 个接口清单回头看：没有一个是静态的——接口全部走源服务器，CDN 的边界在"接口之外"。
把一次完整的 CDN 请求串起来，就是本章所有概念的合体：用户访问 https://cdn.example.com/images/avatar.jpg → CNAME（11.3：cdn.example.com 指向 CDN 域名）→ GSLB（CDN 的 DNS 判断用户区域，返回最近节点 IP）→ HTTPS（第 10 章：节点证书验证）→ 边缘节点（命中直接返回 / 未命中回源）→ Cache-Control（第 10 章首部决定节点缓存多久）。一次请求，DNS、CDN、HTTPS、HTTP 四章的知识全部在场——网络段的每一个概念，都在一次真实请求里协同工作。
11.6 CDN 的代价与边界
CDN 的收益（就近加速）很直接，代价和边界也要诚实。
代价一：缓存一致性。节点里的内容和源服务器可能不一致——源服务器更新了图片，节点还存着旧的（TTL 过期前）。解法是主动刷新（源更新时通知 CDN 清除旧缓存）和 TTL 策略（版本化文件名：avatar_v2.jpg 而不是 avatar.jpg——文件名变了，缓存自然失效，这是最常用的"缓存革命"手法）。缓存一致性是第 16 章性能章的深化主题，这里先认识名字。
"版本化文件名"展开一下（它是前端工程的标准做法，第 21 章构建章会正式登场）：构建时给文件名加内容指纹（avatar_a1b2c3.jpg——内容变了哈希就变），新文件是一个新 URL，旧 URL 自然没人访问，缓存随旧 URL 一起退休——不需要任何"清缓存"操作，缓存就自己对了。这是"用 URL 代替清缓存"的思路：让缓存失效变成'换一个新名字'，而不是'删掉旧内容'。
**代价二：动态内容不适合。**接口、个性化页面（每个用户不一样）走 CDN 会命中率极低，回源成本反而更高——CDN 不是"所有内容都能加速"，是"静态内容才能抄近道"。
CDN 的成本也诚实一句：按流量计费——静态资源从源服务器搬到 CDN，省了源服务器的带宽，但 CDN 流量本身要花钱。对小项目来说，CDN 的流量费可能比省下的带宽费还贵——"要不要 CDN"的九步里，成本是真实的一维，阶段 1 的"不上"也因此更合理。
选 CDN 厂商也可以走一遍九步：评价维度——节点覆盖（11.5：节点越密越近）、价格（按流量）、HTTPS 支持（第 10 章：全站加密下节点证书代管是否免费）、控制台体验。选型结论通常是"大厂 CDN 都够用，选价格和覆盖平衡的"——但每个维度都要过一遍九步，才是"做决策"而不是"跟风"。
CDN 的内容来源还有两种模式：回源拉取（用户请求触发，节点去源服务器取——本章讲的，省事）和主动推送（源主动把内容推到 CDN——适合大文件/预热场景，比如大促前把活动图片先推上节点）。阶段 2 的案例用回源拉取就够——先用简单的，被逼出来再加（第 4 章的复杂度预算精神）。
CDN 的演进也一句带过（第 2 章演进循环的又一次实例）：从 1998 年的静态加速（图片/文件）到今天的动态加速（DCDN：把接口/动态页面也加速——靠边缘计算和更聪明的回源），再到边缘计算（在 CDN 节点上跑业务逻辑——第 26 章云原生的"边缘"概念）。但万变不离其宗：CDN 的本质始终是"内容离用户更近"——变的是"内容"的范围（静态→动态→逻辑），不变的是"就近"这个核心。
**决策模型：要不要 CDN？**走一遍九步（轻量版）：业务目标：静态资源加载快；业务约束：阶段 1 用户集中在本地（先服务上海及周边）、静态资源量小；技术问题：要不要引入 CDN？候选：A 不上（先裸奔）；B 上 CDN；评价维度：用户分布、静态资源占比、成本；方案选择：阶段 1 不上——用户都在上海，CDN 的"就近"没有用武之地；收益（如果上）：就近加速；代价：配置与缓存管理成本；演进条件：用户分布到全国（阶段 2 用户增长）——那时 CDN 才被逼出来。这就是"业务逼出技术"的正面教材：CDN 不是"好技术所以用"，是"用户变远了所以不得不用"——第 2 章的演进循环，在这里又一次上演。这个决策也写进第 5 章的决策记录：CDN——阶段 1 不上，演进条件=用户分布到全国——决策记录里的"不上"和"上"一样重要（第 5 章说过，决策包含不做什么），而"不上"的价值在阶段 2 真正需要时才显现（"该上时知道该上"，就是第 9 步演进条件的作用）。阶段 2 的引入预告也提前写好（第 16 章会完整展开）：用户从上海扩散到全国 → 哈尔滨用户"图片转圈"的投诉变多 → 静态资源迁到 CDN（CNAME 接入 + 分域名）→ 图片加载时间从 2 秒降到 300ms → 新问题：缓存一致性（更新图片要等 TTL）——每个技术都带来新代价，第 2 章说过的循环。
边界：CDN 与第 24 章还有一层关系。CDN 不只是加速——它还是天然的流量缓冲：用户请求打到边缘节点就结束了，源服务器只承受"回源"的那部分流量。攻击者打流量（第 19 章 DDoS），打在 CDN 上（CDN 有防护），源服务器反而安全。CDN 是"离用户最近的服务器"，也是"挡在源服务器前面的第一道墙"——这个视角第 24 章高可用会用到。
CDN 的故障模式也提前认识：**边缘节点挂了怎么办？**CDN 的 DNS 调度（GSLB）会自动把该区域的用户指到邻近的健康节点——"节点挂了，调度换一个"是 CDN 的默认高可用机制（第 23 章负载均衡的"健康检查"思想在 CDN 上的实例）。反过来，源服务器挂了，CDN 还能撑一会儿：节点里有缓存，用户还能拿到旧内容（"源站挂了但页面还能打开"——CDN 的缓存是意外的容灾）。这个特性第 23 章会变成"降级策略"的素材。
最后把 CDN 放回第 16 章的多级缓存图景（先给个全貌）：用户的请求会依次经过浏览器缓存 → CDN 节点 → 服务器缓存 → 数据库——CDN 只是多级缓存中的一级（虽然是最靠近用户的一级）。第 16 章性能优化时，"缓存打几层"是核心决策——本章认识 CDN 这一级，第 16 章拼全图。
CDN 的监控指标也预告给第 25 章：命中率、回源率、节点延迟——这三个数字是 CDN 健康状况的体温计（命中率掉 = 缓存策略出问题；回源率涨 = 用户开始等源服务器；某节点延迟高 = 该区域节点要排查）。第 25 章可观测性讲"监控什么"时，CDN 指标是基础设施监控的一部分。
本章和第 16 章的边界一句话：第 11 章回答'CDN 为什么存在、怎么工作'，第 16 章回答'命中率怎么优化、缓存策略怎么设计'——机制在前，优化在后，和前几章的边界模式一致。
11.7 本章对应表
| 业务诉求 | 技术选择 | 为什么 | 代价/取舍 |
|---|---|---|---|
| 名字要可记忆、能查 | DNS 分层解析（递归+迭代） | 层级让每层表小，无中心抗单点 | 多走几跳；缓存 TTL 与更新延迟 |
| 解析要快 | 各层缓存 + TTL | 缓存秒查，TTL 控制失效 | 更新延迟（改 DNS 先调低 TTL） |
| 解析要安全 | DNSSEC / DoH（初识） | 防劫持防污染 | 部署成本（第 19 章深化） |
| 静态资源加载慢 | CDN 就近缓存 | 物理距离决定延迟，就近抄近道 | 缓存一致性、动态内容不适合 |
| 用户去哪取 | DNS 调度（GSLB） | CDN 复用 DNS 做地理调度 | 调度精度依赖 DNS 准确性 |
| 要不要 CDN | 九步决策（阶段 1 不上） | 用户没分布到全国，没被逼出 | 阶段 2 用户增长才上（16 章接） |
每一行都在本章正文里有完整的论证：DNS 分层在 11.2，缓存与安全在 11.3，CDN 就近在 11.4，工作原理在 11.5，代价与决策在 11.6。和前面章节的对应表一样，先看"业务诉求"列——这一章的每一行，都是从"哈尔滨用户打开慢"和"域名查不到"里长出来的。
把本章放回旅程图（图 8-1）：网络段到此走完（第 10 章上路、本章问路与抄近道）——第三部分地图进度：浏览器 ✅ → 网络（上）✅ → 网络（下）✅ → 服务端 → 数据层 → 第 15 章全链路。下一站，请求终于到达服务器：POST /v1/contents 的报文落在一台真实机器上——服务器怎么接住它，就是第 12 章的事。
网络段的完整账本也在这里合拢（第 8 章关键路径 × 第 10-11 章网络段）：一次 HTTPS 请求的关键路径 = DNS（问路，11 章）+ TCP 握手（1 RTT，10 章）+ TLS 握手（1-2 RTT，10 章）+ 发送请求 + TTFB（服务端，12/14 章）+ 下载（16 章）——现在这段旅程的每一站，都有一个章节对应。第三部分的"地图"，从浏览器站走到了服务器门口。
对两种读者，本章的收益也呼应前几章：后端读者把"配置域名"从"填个表格"升级成"理解解析体系"（递归/迭代/权威/TTL——DNS 不再是玄学）；前端读者把"图片慢"从"抱怨网络"升级成"知道是 CDN 的事"（静态资源分域名、版本化文件名——前端工程与网络段的第一次握手）。全栈的"全"，在网络段这里补上了最后一块拼图——下一站，就是服务器。
本章小结
DNS/CDN 速查（第三部分回指本章时翻回这里）：
- DNS 是电话簿：递归（浏览器→本地 DNS）+ 迭代（本地 DNS→根→顶级→权威），每层只管自己那一截，权威服务器说了算；
- 权威服务器说了算，其余都是指路；A 记录是终点，CNAME 是别名（CDN 调度靠它）；
- 缓存 + TTL：快但有更新延迟——改 DNS 前先调低 TTL，迁移完再调回来；
- CDN = 就近 + 回源：命中走捷径、未命中才回源；命中率是核心指标（第 16 章深化）；5. CDN 管静态（分域名）、服务器管动态；要不要 CDN 走九步——阶段 1 不上，用户变远才上（决策记录已写入演进条件：用户分布到全国）。 （五条速查对应本章的认知结构：1-3 是"问路"（DNS 的分层/权威/缓存），4-5 是"抄近道"（CDN 的就近/回源）——问路决定"去哪"，抄近道决定"多快"；网络段两章（第 10 章的上路 + 本章的问路与抄近道）到此合拢——DNS 负责把请求带到服务器门口，CDN 负责让静态内容少跑路，第 16 章性能会回来放大 CDN 的缓存策略，那时"业务逼出技术"的循环又会转完一圈，而第三部分也即将走到下一站——服务端。）
- DNS 是互联网的"电话簿"：域名 → IP 的翻译靠分层解析（递归 + 迭代），分层的意义是"每层只管自己的事"；
- CDN 是"让旅程变短"的技术：静态内容复制到边缘节点，用户就近取——命中走捷径，未命中才回源；
- DNS 和 CDN 都遵循"业务逼出技术"：CDN 是阶段 2 用户增长后才被逼出来的（第 16 章接上）；
- CDN 还是"挡在源服务器前面的第一道墙"——第 24 章高可用会用到这个视角；
- 网络段（第 10、11 章）到此结束——下一站，请求终于到达服务器门口。
下一章
问路问完了（DNS），近道也知道了（CDN）——现在，请求真的到达了服务器：POST /v1/contents 的报文落在服务器上。服务器怎么接住它？谁先接待（框架的路由）？怎么把报文变成业务逻辑的调用（中间件、控制器）？业务规则又在哪里执行？这些问题的答案，都在旅程的下一站——服务器。
下一章，服务端：业务逻辑的家——请求到达服务器之后，整个后端是怎么组织起来的，从"谁先接待这个报文"开始讲起。