随缘惜情最近团队把 HagiCode Desktop 的下载链路整体从“纯 CDN”切到混合分发架构之后，我一直在盯大文件下载的测速数据和源站带宽曲线。结果比预期明显：源站出口带宽峰值降了大约七成，2GB 以上安装包场景里用户的平均下载完成时间反而缩短了接近一半。核心就是把 PP（这里指 P2P，点对点传输，不是 SAP 里的 PP 生产计划模块）和传统 HTTP 下载做了融合，而不是单纯堆 CDN 节点。
如果你也在处理软件安装包、游戏客户端、固件镜像或者内部离线资源包这类大文件分发，这篇内容能帮你理清混合分发架构怎么设计、PP 加速怎么落地、测速怎么做才不注水。我会结合 HagiCode Desktop 这套系统的实际改造过程，把架构思路、核心原理、关键参数、实操流程和踩坑记录都摊开讲，适合做下载分发、客户端交付、基础设施优化的同学参考。
1. 混合分发架构：为什么不是纯 CDN，也不是纯 P2P
1.1 大文件分发场景里的三个典型困境
先还原一下我们当时的场景。HagiCode Desktop 负责分发的文件主要有三类：客户端安装包，单包 1.5GB 到 3GB；虚拟机镜像和固件包，单个 4GB 到 12GB；周期性更新的离线数据包，最大的超过 20GB。这三类文件有个共同点——体积大、下载耗时长、发版节点集中爆发。
第一个困境是带宽成本失控。平时流量低的时候，CDN 节点和源站都很轻松，但一到发版窗口，成百上千用户同时拉同一个大包，回源流量瞬间冲到上限。我们用的是按量计费的 CDN，回源和边缘流量都在计费，一个月下来分发成本占了基础设施预算的很大一块。而且成本不是线性的——用户越多、包越大、发版越频繁，成本曲线就越陡。
第二个困境是高峰期用户体验崩坏。带宽被高并发均分之后，单个用户的下载速度会掉到非常难看，2GB 的安装包拖一个多小时是常态。发版日那几天工单系统全是“下载慢”“进度卡住”的反馈，运维和客服都疲于应付。用户侧感知差，业务侧的信任度也会跟着掉，这不是靠加几个 CDN 节点就能糊弄过去的。
第三个困境是纯 P2P 落地阻力大。理论上用户之间互相传就能解决成本问题，但冷启动、NAT、防火墙这些现实问题把纯 P2P 方案的理想状态打得粉碎。第一个下载的人找不到可连的 peer，仍然要全量走源站；大量家用和办公网络环境无法建立 peer 直连，最后不得不依赖服务器中转，带宽一点没省。
1.2 纯 CDN、纯 P2P、混合分发三方案对比
我把三种方案放一起做了对比评估，这里直接给出一张对比表：
| 评估维度 | 纯 CDN | 纯 P2P | 混合分发 |
|---|---|---|---|
| 可用性 | 很高，任意时间可下载 | 冷启动时差，依赖种子存活 | 高，HTTP 通道保底 |
| 成本曲线 | 随流量线性增长 | 用户越多越便宜，但初期投入高 | 规模上来后显著低于纯 CDN |
| 用户体验 | 高峰会变慢 | 无 peer 时很慢 | 全程相对稳定，高峰体验好 |
| 部署复杂度 | 简单 | 复杂，客户端和服务端都要做对等机制 | 中等，比纯 P2P 简单 |
| 对网络环境要求 | 无 | 要求 NAT 可穿透、防火墙放行 | HTTP 兜底，P2P 失效也不影响完成 |
选型逻辑其实就三条：第一，必须保证任意时间、任意网络环境下都能把文件完整下载下来，这是底线；第二，用户规模增长时源站带宽不能跟着线性增长，否则成本和稳定性都会失控；第三，改造必须对用户透明，不能让人去配路由器或者装额外插件。混合分发在这三点上都站得住。
1.3 为什么 HTTP 保底 + P2P 提速是当前最优解
HagiCode Desktop 最终落地的架构一句话就能说清：客户端先和 HTTP 源站建立一条稳定连接，同时加入由 tracker 和 DHT 组成的对等网络，文件被切成大小相同的分片，一部分从 HTTP 拉取，一部分从 peer 拉取，两边