模块一 · 应用层
P2P 与内容分发网
一个文件如果要给一百万人下载，服务器怎么扛得住？答案有两条完全不同的路 —— 让用户互相传（P2P），或者把内容提前搬到离用户近的地方（CDN）。这一章讲清这两种思路，以及它们在什么场景下各自更合适。
本章要解决的问题：一个文件如果要给一百万人下载，服务器怎么扛得住？答案有两条完全不同的路 —— 让用户互相传（P2P），或者把内容提前搬到离用户近的地方（CDN）。这一章讲清这两种思路，以及它们在什么场景下各自更合适。
本章的证据来源：概念讲法参考教材§2.5–2.6，纸书90–102页（PDF109–121页），具体出处见章末。旧稿的命令与数值属于历史转述，相关附件未随当前项目提供，本次没有重新采集或运行原实验；模型计算、协议规则与观察不能互相替代。
先从一个例子理解概念
一百万人要下载同一个视频。如果只从一台服务器取，出口可能承受不了。可以让参与者互相提供内容，也可以把内容部署到多个节点。
客户端/服务器与P2P
客户端/服务器由服务方响应请求；P2P参与者可彼此提供资源，也可能依赖协调服务。区别在服务分工，不能只看是否有一台服务器。
内容分发网（CDN）
CDN在多个节点分发内容，并把请求导向合适节点。合适不必等于地图上最近，还取决于网络路径、负载和策略。
一个问题：一百万人同时下载同一个文件
假设你要分发一个 1000 MB 的文件，自己的服务器上行带宽只有 1 MB/s。
用最朴素的办法（所有人从你这台服务器下载）：
1 个人下载 : 约 17 分钟
10 个人下载 : 服务器上行要分给 10 个人 → 约 2.8 小时
100 个人下载 : 约 27.8 小时
1000 个人下载 : 约 11.6 天服务器是瓶颈，而且用户越多越慢 —— 这是一条直线式的恶化。
换一条思路：既然下载的人自己已经拿到了文件的一部分，为什么不让他们互相传？
P2P：把用户变成"小服务器"
P2P（Peer-to-Peer，对等方到对等方） 的核心思想一句话：
于是总上传能力不再只是你那台服务器，而是"服务器 + 所有已经拿到部分数据的用户"之和。人越多，总上传能力越大。
用同一组数字算一遍（本机计算，公式见小结）：
| 下载人数 | 客户-服务器 | P2P | P2P 快多少 |
|---|---|---|---|
| 1 | 16.7 分 | 16.7 分 | 1.0 倍 |
| 10 | 2.8 小时 | 27.8 分 | 6.0 倍 |
| 100 | 27.8 小时 | 32.7 分 | 51.0 倍 |
| 1000 | 277.8 小时（约 11.6 天） | 33.3 分 | 501 倍 |
看一眼增长速度就更清楚了：
从 10 人增加到 100 人：
客户-服务器：2.8 小时 → 27.8 小时，慢了 10 倍
P2P： 27.8 分 → 32.7 分，只慢了 1.18 倍这就是 P2P 的"可扩展性" —— 用户数增加时，客户-服务器的下载时间是线性恶化的，而 P2P 几乎不受影响（因为新增的用户既消耗带宽也贡献带宽）。
BitTorrent 是怎么组织这件事的
最成功的 P2P 文件分发协议是 BitTorrent，它解决上面几个问题的办法很巧妙：
| 机制 | 做法 | 解决什么 |
|---|---|---|
| 分块 | 把文件切成很多小块（通常 256 KB 左右），每块单独下载 | 拿到一块就能立刻开始给别人传，不用等整个文件下完 |
| 跟踪器 / DHT | 告诉你"哪些对等方有你要的块" | 让新加入的人能找到人 |
| 最稀有优先 | 优先下载副本最少的那一块 | 防止某一块绝版导致整个文件永远下不完 |
| 以牙还牙 | 优先给上传给自己最快的那些对等方回传 | 惩罚只下载不上传的搭便车者 |
"最稀有优先"这个策略特别值得琢磨：它看起来是反直觉的 —— 为什么不先下容易下的块？因为你手上的块的价值，取决于别人缺不缺它。如果所有人都只下"热门块"，那些稀有块就会消失，最后所有人都卡在同一块上。保证稀有块的副本数，才是让整个网络转起来的关键。
视频分发：从"下载完再看"到"边看边调"
视频是互联网上流量最大的内容，它对分发方式的要求比普通文件更高。演进过程大致三步：
| 阶段 | 做法 | 问题 |
|---|---|---|
| ① 下载后播放 | 整个文件下完再播 | 要等到天荒地老 |
| ② 流式播放 | 边下边播，播放速度维持在下完速度之前 | 带宽一波动就卡 |
| ③ 自适应流（DASH） | 把视频切成小段，每段准备多个清晰度，客户端根据当前带宽自己选 | 现在的标准做法 |
DASH 的核心思路：把整个视频切成几秒钟一段的小文件，每一段都预先编码成好几个码率版本（比如 480p、720p、1080p）。
客户端一边播，一边测自己的下载速度，然后为下一段挑一个合适的码率：
- 带宽好 → 挑高清段
- 带宽变差 → 自动切到低清段，保证不卡
这就是为什么你在看视频时会觉得"画质忽然糊了一下" —— 那是客户端主动降级在保连续播放。它选择了"糊但不卡"，而不是"清楚但一直转圈"。
CDN：把内容搬到离用户近的地方
P2P 解决的是"服务器带宽不够"，CDN 解决的是另一个问题：距离太远。
回顾上一章算过的数字：跨洋往返的传播时延约 80 毫秒，而且这和带宽无关。 如果你的用户在美国而服务器在中国，每一个请求都要付这个物理成本 —— 没法用加带宽解决。
CDN（Content Delivery Network，内容分发网）的做法是：
两种部署思路
| 思路 | 做法 | 适合 |
|---|---|---|
| 广泛铺开 | 在很多城市部署大量小节点，尽量靠近用户 | 用户分布广、要求低时延 |
| 集中在关键点 | 只在少数位置建大节点，通过高速链路连到各地 ISP | 成本更可控 |
第一种的时延更低，但节点多、维护成本高；第二种更省钱，但效果依赖与 ISP 的互联质量。 实际的大厂往往是两者混用。
用户怎么被引导到最近的节点
主要靠 DNS：解析同一个域名时，DNS 根据请求的来源返回离你最近的那个节点的地址。
北京的用户解析 cdn.example.com → 返回北京的节点 IP
上海的用户解析同一个域名 → 返回上海的节点 IP可能还有第二层：任播（Anycast）。 同一个 IP 地址在多个节点上同时宣告，网络本身会把你的包送到"路由意义上最近"的那一个。DNS 是在域名层面调度，任播是在 IP 层面调度。
实测：能看到哪些 CDN 痕迹，看不到哪些
能看到的部分 —— 响应头里的缓存状态。 这是本机早前抓到的真实响应（观察条件见章首说明；这个环境的响应时好时坏，同一目标不同时刻结果可能不同）：
< CF-Cache-Status: HIT ← 这个响应来自 CDN 缓存，没有回源
< Age: 3 ← 这份缓存在节点上已经放了 3 秒
< Cache-Control: max-age=10 ← 客户端可以缓存 10 秒
< Vary: accept-encoding ← 缓存要按压缩格式区分
< Server: cloudflare ← 由 Cloudflare 的节点提供CF-Cache-Status: HIT 是直接证据：这个响应不是从源站取的，而是从 CDN 节点的缓存里直接返回的。Age: 3 说明这份缓存是 3 秒前放进去的。
再看一眼能省多少：Cache-Control: max-age=10 意味着 10 秒内同一个资源的所有请求都会命中节点缓存。对一个热门页面来说，这能把源站的负载降到极低。
看不到的部分 —— 多 IP 的 DNS 调度。 我原本想观察"同一个域名在不同时刻解析出不同节点"这个现象，但本机做不到：
www.cloudflare.com -> 198.18.0.210
cdn.jsdelivr.net -> 198.18.1.8
www.bing.com -> 198.18.1.9三个完全不同的域名，解析结果全部落在 198.18.0.0/15 —— 那是《应用层》模块讲过的 fake-IP 段。代理把所有域名都换成了本地假地址，所以真实的 CDN 节点地址根本看不到。
和前面章节的联系
CDN 可以理解成"地理维度的负载均衡"。 《应用层》模块的《代理与负载均衡》那一章讲过：
| 负载均衡 | CDN | |
|---|---|---|
| 解决的问题 | 一台服务器扛不住并发 | 用户离服务器太远 |
| 调度依据 | 连接数、权重、一致性哈希 | 用户的地理位置 |
| 调度手段 | L4/L7 转发 | DNS 与任播 |
| 缓存 | 通常不做 | 核心就是缓存 |
两者经常一起用：CDN 节点本身就是一组服务器，节点前面还有负载均衡。
常见误解
误解一：「P2P 只是省服务器带宽，对用户没好处」
不只对服务器有好处。 从上面的表能看出：人数越多，P2P 的下载时间几乎不变，而客户-服务器模式会恶化到几天。用户数一多，P2P 对用户也明显更快。
误解二：「P2P 下载一定比直接下载慢」
取决于人数和做种情况。 只有一个做种者时，P2P 和直接下载没有区别（表里 N=1 那一行都是 16.7 分）。人多了 P2P 才有优势；反过来，如果没人做种，P2P 会一直卡在 99%。
误解三：「CDN 就是把文件复制几份放着」
核心难点在"怎么把用户引导到最近的那一份"和"缓存怎么失效"。 复制文件本身不难；难的是 DNS 调度要准、节点缓存要能及时更新（源站改了内容，各节点都得跟上）、以及命中率要足够高才有意义。
误解四：「看视频画质变糊是网络断了」
通常不是断了，而是客户端主动降级。 DASH 检测到带宽不足时，会为后续片段挑一个更低的码率 —— 它选择"糊但连续"，而不是"清楚但卡住"。带宽恢复后画质会自动回来。
误解五：「CDN 只对大公司有意义」
不一定。 只要你的用户分布超出单个机房能覆盖的范围，或者有静态资源（图片、JS、视频）需要反复分发，CDN 就能省下源站带宽并降低时延。不过如果用户都集中在一个城市，CDN 的收益就有限。
本章小结
| 结论 | 类型 |
|---|---|
| 客户-服务器的下载时间随用户数线性恶化 | 标准 |
| P2P 中每个下载者同时是上传者，总上传能力随用户数增长 | 标准 |
| 同一组参数下：10 人时 P2P 快 6 倍；100 人时快 51 倍；1000 人时快 501 倍 | 计算（本机复算） |
| 从 10 人到 100 人，客户-服务器慢 10 倍，P2P 只慢 1.18 倍 | 计算 |
| BitTorrent 用分块、最稀有优先、以牙还牙来组织分发 | 标准 |
| 「最稀有优先」的目的是保证稀有块的副本数，避免整体卡住 | 标准 |
| 视频分发演进：下载后播放 → 流式 → DASH 自适应 | 标准 |
| DASH 让客户端按当前带宽逐段选择码率，画质波动是主动取舍 | 标准 |
| CDN 解决的是地理距离造成的时延，这与带宽无关 | 标准 |
| 用户被引导到最近节点主要靠 DNS，其次靠任播 | 标准 |
实测：响应头出现 CF-Cache-Status: HIT、Age: 3，证明响应来自节点缓存 | 实测（历史观察，注明条件） |
实测：三个不同域名均解析到 198.18.0.0/15，多 IP 调度在本机观察不到 | 实测 |
| 本机未做 P2P 实验（只有一台机器，且流量经代理） | 实测限制 |
自测题
7 题 · 先自己答，再展开对照
为什么 P2P 的用户数增加时，下载时间几乎不变，而客户-服务器模式会线性恶化？
因为在 P2P 里，每个新加入的用户既消耗带宽也贡献带宽。 分发的总上传能力 = 服务器的上行 + 所有用户上行的总和，这个总和随用户数增长，所以摊到每个人头上的下载时间几乎不变。
而客户-服务器模式里，服务器的上行带宽是固定的，用户越多，每个人分到的越少 —— 总时间随用户数线性增长。本机复算的结果：1000 人时前者要 11.6 天，后者只要 33 分钟。BitTorrent 为什么要"优先下载最稀有的块"？如果反过来会怎样？
为了保证稀有块的副本数不下降。 如果把"容易下的块"优先下完，那么大家都容易拿到热门块，而稀有块的副本数会越来越少；一旦持有某个稀有块的最后一个用户退出，这个文件就永远下不完了（卡在 99%）。
「最稀有优先」让每个用户的下载选择都倾向于补充网络的短板，从而保证所有块都有足够副本。DASH 为什么要给同一段视频准备多个码率版本？
为了适应波动的带宽。 网络速度会随时变化（尤其无线和移动网络）。如果只准备一个高清版本，带宽一降就必然卡顿；准备多个码率后，客户端可以在带宽不足时切到低码率，用画质换连续播放。看视频时画质突然变糊，最可能是什么原因？
最可能是客户端主动降级（DASH 自适应），而不是网络断了。它检测到下载速度跟不上当前码率，于是为后续片段选了更低的清晰度，以保证不卡顿。等带宽恢复，画质会自动回升。CDN 和负载均衡解决的是同一个问题吗？
不是。 负载均衡解决的是"一台服务器扛不住并发"，调度依据是连接数、权重等；CDN 解决的是"用户离服务器太远"，调度依据是地理位置。两者经常一起用（CDN 节点前面通常还有负载均衡），但目标不同。你想观察"同一个域名被解析到不同 CDN 节点"这个现象。本机为什么做不到？应该怎么做？
因为本机的代理把所有域名都解析成198.18.0.0/15的假地址（fake-IP）。无论查哪个域名、查几次，拿到的都是代理生成的本地假地址，真实节点地址根本不会出现。
正确的做法：在不受代理接管的网络上做，而且最好从不同地理位置（或借助不同地区的公共 DNS）分别查询同一个域名，如果得到不同的 IP，就说明存在基于来源的 DNS 调度。响应头里有
CF-Cache-Status: HIT和Age: 3，说明什么？说明这个响应来自 CDN 节点的缓存，没有回源到原始服务器。CF-Cache-Status是 Cloudflare 的缓存状态头，HIT表示命中缓存；Age: 3表示这份缓存是 3 秒前放入节点缓存的。
实际意义：源站完全没有被这次请求打扰，用户也从就近节点快速拿到了内容 —— 这就是 CDN 的主要价值。
参考资料与适用范围
- 《计算机网络：自顶向下方法（原书第8版）》§2.5–2.6，纸书90–102页（PDF109–121页）：本章概念与机制的对应教学章节，引用时需保留模型与版本条件。
- 教材作者配套教学资源入口：网站目前显示的教材版本与用户提供的第8版可能不同，页码以本章列出的中文第8版为准。
修订核对日期：2026-10-13。本次补充概念入口与教材出处；旧稿的具体数值为历史观察，未重新实测。相关脚本和完整日志未随当前项目提供，不能仅凭转述断言实验已复核，也不据此断言数据造假。