同一份内容交付给多个接收者时，发送端逐一建立单播连接最容易部署，却会在共享路径上重复发送相同字节。IP 组播把复制点下沉到网络分支，应用层覆盖把复制点放在中继节点，边缘缓存则利用内容在不同请求之间的可复用性。三种方案减少的重复范围不同，承担的状态也不同。

第 11、12 篇说明路由选择，第 23 篇讨论 HTTP 缓存，第 32 篇讨论负载均衡。本篇在固定树形拓扑上比较流量与状态成本，不把静态模型写成公网部署或性能测量。

先定义“少发一份”的计量单位

设对象大小为 B，一条路径经过的每条有向链路都传输一次完整对象。本文用“对象副本·链路”计数，再乘 B 得到 MiB·链路。这个量表示网络中各链路承载字节数的总和，不是吞吐率、费用或完成时间。

固定拓扑含一个源站、一个核心节点、四个区域节点，每个区域有两个接收者。源站到核心、核心到区域、区域到接收者各算一跳，共有八个接收者。对象大小为 4 MiB。

直接单播需要为每个接收者走三跳，因此成本为 8 × 3 × 4 = 96 MiB·链路。源站还要发送八份对象。这个基线不需要网络保存组播组状态，但发送端或代理仍要处理八条交付关系。

模式提炼：先定位复制点

总链路字节 = Σ(每份副本经过的链路数 × 对象大小)

优化的关键变量是副本在哪个节点产生。复制点越接近共同路径的末端，共享链路上的重复越少；复制点下沉也会引入转发状态、缓存状态或中继会话。

IP 组播在分支节点复制

IP 组播把一个目的组地址关联到动态成员集合。RFC 1112 给出的服务仍是尽力而为：报文不保证完整到达所有成员，也不保证相对顺序。组播节省复制流量，不自动提供可靠交付、拥塞控制、访问控制或应用会话管理。

IGMPv3（Internet Group Management Protocol Version 3）让 IPv4 主机向相邻组播路由器报告组成员关系，并支持按源包含或排除。IGMP 只解决接入链路上的成员报告，不负责构造跨路由器转发树。

PIM-SM（Protocol Independent Multicast - Sparse Mode）利用单播路由信息建立共享树，并可为具体源建立最短路径树。路由器需要维护 (*, G)、(S, G) 等组播转发状态并处理加入、剪枝与树切换。接收者数量增加时，链路副本可能增长得较慢，但组数、源数、接口和变更频率会增加控制面与转发表压力。

固定拓扑的组播树只在每条树边发送一份对象：源站到核心 1 份，核心到四个区域共 4 份，区域到八个接收者共 8 份，总计 13 × 4 = 52 MiB·链路。模型记录五个复制或转发节点的组状态；真实 PIM 状态数量还取决于共享树、源树、冗余路径和实现。

覆盖网络在应用节点复制

应用层覆盖网络在现有单播 IP 之上建立逻辑拓扑。源站向四个区域中继各发一份，中继再向本区域两个接收者复制。部署不要求沿途路由器支持 IP 组播，但应用必须维护父子关系、成员变化、故障检测、重连和授权。

逻辑边不等于独占物理路径。四条源站到区域中继的连接都会经过源站到核心的同一条底层链路，所以该链路仍承载四份对象。固定拓扑中，源站到四个中继需要 4 × 2 = 8 个对象副本·链路，中继到接收者需要 8 个，总计 16 × 4 = 64 MiB·链路。

覆盖树的形状还会改变故障范围。中继失效会同时影响其子节点；增加备用父节点能缩短恢复，却增加连接、探测和重复传输。底层选路变化也可能让看似分散的覆盖边重新汇聚到同一瓶颈。

边缘缓存利用跨请求复用

边缘缓存与实时分发的时间语义不同。缓存先保存可复用响应，后续请求命中时才省去上游传输。RFC 9111 规定 HTTP 缓存必须遵守缓存键、Vary、新鲜度、验证、no-store、private 和授权请求等条件；收到 200 OK 不能单独证明响应可被共享缓存重复使用。

固定模型为每个区域部署一个缓存。冷缓存时，四个区域各从源站取回一次对象，再分别服务两个接收者，流量与四中继覆盖相同，为 64 MiB·链路。缓存预热且响应仍可复用时，上游不传对象，只剩八条区域到接收者链路，为 32 MiB·链路。代价是四份对象存储、缓存键和新鲜度状态，以及失效、回源和请求路由机制。

这个结果依赖“八个请求命中同一表示”。若响应按用户授权、Cookie、语言或编码变化，缓存键会拆分；若响应禁止共享存储、已经过期或每次内容都不同，热缓存假设失效。直播分片可以缓存，但只有仍有后续请求复用的分片才能获得这类收益。

固定拓扑手算

distribution_cost.py 读取拓扑与对象大小，输出四种方案的链路字节和分项状态。状态项的单位不同，脚本不会把组播转发表项、覆盖会话和缓存对象强行合成一个总分。

1
2
python3 source/_posts/2026-09-24-计算机网络E08-IP组播、覆盖网络与内容分发/distribution_cost.py --help
python3 source/_posts/2026-09-24-计算机网络E08-IP组播、覆盖网络与内容分发/distribution_cost.py

素材包括固定拓扑输入、成本计算脚本、计算结果、资料与运行记录和审阅记录。

成立条件、限制和反例

IP 组播适合受控网络内的大量接收者同时消费同一数据流，前提是端点、接入网络和路由域都支持成员管理与组播路由。跨越不支持组播或不愿维护组状态的网络时，模型中的树并不存在。

覆盖网络适合底层只提供单播、内容又需要实时复制的场景。若覆盖边在底层高度重合，逻辑树仍会重复占用物理链路；若中继容量不足，复制点本身会成为瓶颈。

边缘缓存适合可缓存对象被同一区域的多个请求重复使用。只有一次请求、强个性化响应或严格禁止共享缓存时，缓存无法产生热命中收益，还会增加存储与一致性管理。

接收者很少、内容各不相同或运维状态必须最小化时，直接单播可能是更清楚的选择。静态链路字节更少也不保证时延更低，因为排队、连接建立、缓存未命中、节点负载和故障恢复都未进入模型。

练习

练习一：把每个区域的接收者从 2 增加到 10，保持拓扑和对象大小不变，分别计算直接单播、IP 组播、覆盖网络和热缓存的 MiB·链路。指出哪些链路成本随接收者线性增长。

练习二：把对象改为带 Cache-Control: private 的个性化响应。说明热缓存模型中的哪项假设失效，并比较应用层覆盖是否能在不泄露用户内容的前提下继续共享副本。

模式速查表

方案 复制位置 主要状态 适用条件
直接单播 源站或入口代理 每接收者连接/请求 接收者少或内容不同
IP 组播 网络分支路由器 组、源、接口与树状态 受控组播域内同步同流
应用层覆盖 中继节点 父子会话、成员与恢复状态 单播底座上的实时复制
边缘缓存 区域缓存 对象、缓存键、新鲜度与失效状态 可缓存内容被重复请求

官方一手参考资料

验证边界

已验证：Python 3 标准库对固定树形拓扑执行确定性手算，核对单播复制、IP 组播、应用层覆盖、冷缓存和热缓存的链路字节与分项状态，验证类型为 HAND_CALC。

NOT_RUN：未配置真实 IGMP/PIM 组播域、应用层中继、CDN、共享 HTTP 缓存、路由器转发表或跨主机流量，未测吞吐、时延、丢包、收敛、缓存命中率和故障恢复。模型结果不能外推为公网、跨地域或生产结论。