HagiCode Desktop 这个项目我们其实折腾了挺久。最初它只是一个内部工具用来解决团队跨地域同步大文件的问题。但做到后面发现单纯靠 HTTP 拉文件带宽和成本都顶不住于是我们把整套下载链路重写了一遍最终落地了一套 CDN 回源加 P2P 节点互助的混合分发架构。这篇文章就是这次重构的完整复盘从为什么选混合方案、分片怎么拆、节点怎么调度到踩过的坑和最终实测数据都会讲到。如果你也在做软件分发、安装包更新、游戏资源下载这类需要传输大文件的东西这套思路应该能给你不少直接能用的参考。1. 先从问题说起单靠 HTTP 下载大文件卡在哪1.1 带宽与成本的双重挤压先说一个真实场景。假设你要推一个 5GB 的安装包同时在线下载的用户数量是 1000 人。如果所有人都走 HTTP 回源也就是直接从你的服务器或者 CDN 边缘节点拉文件那服务器出口带宽的消耗就是 5GB 乘以 1000等于 5TB 的流量。即使按 CDN 每 GB 两毛钱算一次发布就是 1000 块钱这还不算峰值带宽的费用。如果用户量再翻几倍或者安装包体积更大成本会直线上升。更重要的是用户体验。HTTP 下载是典型的服务器带宽瓶颈模型当你的出口带宽被跑满每个用户分到的实际速度就会快速下降。用户表面上看到的是一个下载进度条实际上他是在跟几百个人抢同一条水管。我们测过在没做任何优化前一个 5GB 的包在高并发下平均下载速度只有 1.5MB/s 左右碰上晚高峰甚至能掉到几百 KB。这种体验放到现在这个时代基本等于劝退。1.2 纯 P2P 也不完美那是不是直接用 P2P 就万事大吉了也不是。P2P 的核心理念是让用户之间互相传数据从而减轻源站压力。这个思路本身没错但它有几个硬伤。第一个是冷启动问题。一个文件刚发布的时候除了源站以外没有任何一个节点拥有完整数据。这时候 P2P 网络是空的所有用户都得从源站拉数据然后慢慢扩散。如果文件发布瞬间涌进来几千个请求源站一样会被打爆。这就是典型的“第一公里困境”P2P 再厉害也得先有人把数据带进网络。第二个是节点质量问题。P2P 网络里的节点是不可控的有的用户在线时间只有几分钟有的用户上行带宽被运营商限制得很死有的用户压根就没公网 IP只能被动接收数据无法给别人提供上传。这些因素叠加在一起会导致下载速度非常不稳定。第三个是网络环境的复杂性。NAT 类型不同、防火墙策略不同、运营商对 UDP 流量的限制不同这些都会直接影响节点之间的连通成功率。我们在早期做纯 P2P 测试的时候小规模内网环境下跑得飞快一到公网就各种连不上光是排查 NAT 穿透问题就花了两周。所以结论很明确大文件下载不能押注在单一模式上。HTTP 回源保证了可用性P2P 节点互助解决了带宽成本问题两者混在一起用才能兼顾稳定和效率。这就是 HagiCode Desktop 要做混合分发架构的根本原因。2. 混合分发架构的设计拆解让 CDN 和 P2P 各干各的2.1 整体架构与数据流向HagiCode Desktop 的下载引擎在逻辑上分成了三层获取路径按优先级排序第一层是本地缓存第二层是 P2P 节点第三层是 HTTP 回源。客户端启动一个下载任务之后会先去判断本地有没有已经下载过的分片比如上次中断时留下的临时文件如果有就直接复用省掉重复下载。这一步对于增量更新场景特别有用因为很多情况下用户只差几个分片就能补齐整个文件。本地没有的分片就会进入 P2P 层。客户端会向 Tracker 服务发起节点查询Tracker 会返回一批当前正在下载或者已经下载完成的节点列表。客户端拿到这些节点之后会尝试跟它们建立连接然后互相交换各自拥有的分片信息。这个阶段是数据传输的主力理论上能覆盖绝大多数的分片需求。如果 P2P 层在指定时间内找不到合适的节点或者某些分片实在太稀缺客户端才会回源到 CDN 拉取。这个回源动作是主动降级的不需要用户干预。为了确保回源本身不会造成突发流量我们给每个客户端设置了回源速率上限并且采用“只补稀缺分片”的策略不会让客户端从头到尾全量走 CDN。这套架构的下载流程可以简化成四步获取元数据、加载本地缓存、P2P 节点交换、回源兜底。元数据这一步很多做下载的人容易忽略其实它非常关键。客户端在真正开始下载之前必须先从服务端拉取一个包含文件大小、分片数量、每个分片的哈希值等信息的描述文件。没有这份元数据客户端根本没法定向去 HTTP 服务器请求某个具体字节范围也没法校验从 P2P 节点拿到的那块数据是不是对的。2.2 分片与校验大文件拆成多少块最合适混合分发架构里分片的设计是整个系统的基石。所谓分片就是把一个大文件拆成若干固定大小的数据块每个块作为一个独立的传输单元。客户端下载完一个分片就校验一个分片然后把它标记为“我有这块数据”方便其他节点来索要。分片大小怎么定这里面有个权衡。比如 256KB 甚至更小的分片调度的粒度更细单块传输失败后重试成本低但是分片数量会暴增元数据的体积、Tracker 的消息处理量、每块哈希校验的开销都会跟着涨。而如果分片太大比如 4MB虽然需要管理的单元变少了但调度的灵活性会下降尤其是下载接近尾部时可能只剩下几个大分片分散在不同节点手里等待时间特别长。以 HagiCode Desktop 的实际配置来看一般文件默认用 1MB 的分片大小。对于 5GB 的文件也就是拆成 5120 个分片。这个数量级在日常使用中表现比较均衡元数据大概几十 KB内存开销可控调度也不会因为分片太多而卡顿。当然如果文件特别大比如超过 20GB或者网络抖动比较频繁我们会把分片大小调成 2MB以减少分片总量。校验方面每个分片在发布时都会计算一个 SHA-256 哈希值连同分片序号一起写入种子文件。客户端每拿到一个分片就计算本地数据的 SHA-256与元数据里的记录比对。完全匹配才认为这块数据有效否则直接丢弃并要求重新拉取。这里有个细节值得说校验要在写入磁盘之前做先在内存里算一遍哈希确认无误再落盘。如果先把数据写进硬盘再校验发现问题再删掉重来不仅多耗一次磁盘 IO还可能因为文件系统缓存机制导致明明数据不对但读回来的却是旧内容。对于超大文件逐分片校验产生的额外请求量是可观的但也不至于成为瓶颈。SHA-256 的计算速度在现代 CPU 上普遍能跑到几百 MB/s检验一个 1MB 分片只需要几毫秒完全不是问题。真正要小心的是别在下载线程里同步做校验应该把校验放到独立的 worker 线程池里避免阻塞下载流程。2.3 节点发现与选择怎么找到靠谱邻居P2P 系统里一个很容易被低估的模块是节点发现。理想状态下客户端想找到一个拥有完整数据且网络连接良好的节点现实是它面对的是一个鱼龙混杂的节点池里面充斥着已经掉线的节点、NAT 严格到完全无法穿透的节点、上行带宽被限制的移动设备以及在线时长只有几分钟的“路人”节点。HagiCode Desktop 用了三套节点发现机制组合。首先是 Tracker 服务它是一台中心化服务器维护着每个文件当前有哪些节点在线、各自拥有哪些分片。Tracker 的好处是实时性强响应快客户端启动后向它请求一批候选节点即可。DHT分布式哈希表补齐了 Tracker 的一个致命弱点Tracker 挂了怎么办。DHT 把节点信息分散存储在网络里的多个节点上即使没有中心服务器客户端也能通过 DHT 网络找到部分节点。第三套是 PEX也就是节点交换。它和 DHT、Tracker 都不冲突做法是当你和某个节点建立了 P2P 连接后对方会把他手里已知的其他节点列表分享给你。这有点像线下社交你认识 AA 认识 B于是通过 A 认识了 B。PEX 的最大优势是不消耗额外的服务器资源完全靠客户端之间的点对点通信来扩展连接池。找到一批节点之后还需要给它们打分排序不然可能连上全是慢节点。HagiCode 的节点打分体系主要看四个维度连接往返时间、历史在线时长、当前可用带宽的估算值以及对方手上分片的稀缺程度。综合打分后客户端会优先尝试连接分数高的节点而不是随机挑。这里有个小坑想提醒大家初期设计里把“对方拥有多少分片”这个权重放得太高导致所有客户端都拼命去连那些拥有完整文件的用户结果就是热点节点被挤爆冷门节点无人问津。后来我们把分数计算改成加权平均限制同一客户端最多只能跟同一个节点建立一条连接才把整个网络的连接分布给理顺了。3. P2P 加速的关键机制调度、穿透与传输3.1 分片调度算法稀缺优先是怎么工作的客户端有了分片列表、节点列表接下来核心问题就是按什么顺序去下载这些分片。如果单纯按文件顺序从头下到尾会有一个严重问题所有客户端都集中在开头部分争抢相同的数据越是前面的分片越繁忙越是后面的分片越没人传。真正高效的方案是稀缺优先策略。所谓稀缺优先就是优先下载当前节点池里拥有数量最少的分片。这样做的逻辑很简单一个分片在网络里的副本数越少它断供的风险就越大。如果放着不管最后可能出现整个文件的其他部分都齐了只剩某个独一无二的分片还在某个节点手里而那个节点恰好掉线整个下载就卡住了。但完全严格地执行稀缺优先也不行。极端情况下客户端会一直跑来跑去下载各种稀缺分片而顺序下载的效率优势比如磁盘连续读写就丢了。HagiCode 的实现是稀缺优先加随机抖动加顺序回退三层结合。具体来说85% 的情况下选择稀缺优先策略10% 的情况下随机选择分片作为探测和弥补剩下的 5% 走顺序下载逻辑保证基础调度不会完全乱套。尾部效应是另一个在实测中暴露出来的问题。大文件下载到最后阶段所有客户端都差不多把分片拿全了剩下的都是那些极度稀缺的分片。这时候网络里可供调度的数据少下载速度会明显下降。我们的处理策略是为最后 N 个分片设置一个“保险期限”如果超过 10 秒还没能从 P2P 节点拉到就直接触发 HTTP 回源拉取不跟稀缺分片死磕。牺牲那一个分片的 P2P 命中率换来的却是整个下载任务接近满速完成这个置换非常划算。3.2 NAT 穿透与连接失败NAT 穿透是 P2P 开发里绕不开的坎也是很多初入这个领域的人最头疼的部分。先说理论。互联网上的设备并不都有公网 IP大部分设备躲在 NAT 网关后面网关给内部设备分配一个类似 192.168.x.x 的私网地址。当两个都在 NAT 后面的设备想要直接互相通信就必须先知道对方的公网 IP 和端口然后让两边的 NAT 网关都认为自己是在“应对外部主动发起的连接”这就是 UDP 打洞的基本原理。理论上听起来简单实际成功率却很不稳定。HagiCode Desktop 在公网环境下的 P2P 连接成功率大概在 80% 到 90% 之间具体取决于 N 节点的 NAT 类型组合。如果两边都是完整的锥型 NAT打洞基本都能成功如果有一边是限制型 NAT 或者对称型 NAT打洞就很容易失败。对称型 NAT 之所以难搞是因为它为每次新连接都会分配一个不同的公网端口外部设备根本没法提前预判该往哪个端口发探针。打洞失败之后客户端不能一直干等。HagiCode 的降级策略是打洞失败超过三次自动切换到中继模式通过一台自建的 relay 服务器进行流量转发。当然中继模式会消耗服务器带宽所以 relay 只在得知连接双方无法直接通信时才启用。即使启用了中继我们也会进一步判断中继流量的大小如果中继转发占比过高就直接回源到 CDN 拉取剩下的分片不给服务器平添压力。传输层协议选型上我们最终选择了基于 UDP 的自定义协议而不是基于 TCP 的传输方案。选择 UDP 的核心原因是灵活性UDP 没有 TCP 的拥塞控制限制能自己实现流量控制和重传策略在丢包率不高的网络环境下效率更高。缺点是要处理丢包、乱序、重复等问题这部分工作量不小。如果是团队刚开始做优先考虑 WebRTC 或者成熟的 P2P 库会比从零写协议省力得多。3.3 传输加速与实测效果P2P 传导优化的另一个重心是并发管理。HagiCode 默认每个下载任务最多同时保持 12 条出站数据传输连接每条连接同时最多传输 4 个分片。这个数字是我们反复测试后权衡出来的结果连接数太少网络利用率不足连接数太多反而会触发路由器的并发连接限制还会加剧文件系统碎片化。文件读写方面也做了针对性优化。大文件如果随机写入磁盘 IO 会成为瓶颈。我们的做法是建一个环形缓冲池按照分片序号排序后批量写入尽量把零散的写入请求合并成连续写入。内存池大小一般是 64MB超出这个上限就强制落盘避免占用过多内存导致客户端被系统判定为卡死。实测数据方面我们内部做了一轮对比测试。测试文件是一个 4.8GB 的资源包参与者分布在三个不同的城市客户端数量是 120 台。纯 HTTP 模式下的平均下载速度是 2.1MB/s峰值速度 4.3MB/s。开启混合分发之后平均下载速度提升到了 9.6MB/s峰值速度到过 21MB/s总体来看体感快了四到五倍。更让人惊喜的是源站流量下降比例到了测试后期只有大约 15% 的分片需要回源拉取剩下的 85% 都通过 P2P 节点互助解决了。当然这个数据是在节点充足、网络通畅的理想测试条件下跑出来的。实际的用户网络环境会差很多尤其是手机热点、学校网络这类特殊场景提速效果会打折扣。但从整个系统的稳定性来看混合分发带来的改善是实打实的。4. 常见问题与排查技巧实录4.1 典型问题速查表整个开发和上线阶段我们陆陆续续收集了不少问题这里挑几个典型的列出来。问题现象可能原因处理办法下载进度卡在 99% 不动尾部分片稀缺P2P 协调不齐设置保险期限超时强制回源拉取剩余分片节点连接全部失败NAT 穿透无法完成检查是否对称型 NAT自动降级到中继模式或纯 HTTP 模式下载速度忽快忽慢高权重节点在线状态不稳定增加节点打分频次降低单节点权重影响分片校验频繁失败对端节点数据损坏或网络传输被篡改超过 3 次失败拉黑该节点并交给回源逻辑兜底局域网内设备互相传文件很慢没有启用本地节点发现走了公网绕路开启 LSD 局域网发现协议自动匹配同网段节点磁盘空间不足临时文件和最终文件同时占用空间调整分片写入策略下载过程中及时释放临时分片缓存4.2 几个真实踩坑记录第一个是分片校验失败被误判。初期我们采用“校验失败就立刻拉黑节点”的策略结果有段时间内测群里反反复复有人说下载失败。后来查了半天才发现问题出在部分节点的内存被其他程序占用过多导致哈希校验时数据被交换到虚拟内存读取速度跟不上超时后被当作失败。后来把校验超时时间从 5 秒放宽到 15 秒并且连续失败 5 次才拉黑节点问题就明显缓解了。第二个是回源流量成倍翻车。我们有一次把一个压缩包的更新频率调错了导致同一时间大量客户端请求同一个 URL 的回源。虽然 CDN 本身能扛住但高峰期回源流量瞬间冲到了正常水平的 8 倍账单非常难看。这次之后我们给回源接口加上了请求签名、过期时间和限流策略同时把回源逻辑改成全随机延迟抖动错峰效果立竿见影。第三个是“连上了但很慢”的隐蔽原因。有些节点明明建立连接成功下载速度却几乎为零。排查发现这些节点里有不小的比例是没有公网 IP 的纯内网设备它们发起连接没问题但数据传输时因为 NAT 端口映射的限制实际吞吐量极低。后来我们在协议里加入了一个握手后的双向带宽探测1 秒内测速低于阈值的节点直接断开连接不浪费时间。4.3 网络环境与部署建议最后说点部署层面的建议。如果这套架构用于企业内部系统建议优先保障 Tracker 和 relay 的内网部署并且开放对应的 TCP/UDP 端口。企业网络往往有严格的防火墙规则如果不提前告知网络管理员需要放行哪些端口P2P 通信很容易被拦截。如果是面向公众用户的软件分发建议在安装包里预置一份常用 Tracker 节点列表同时保持 DHT 网络的开启状态。这样即使在 Tracker 服务短时不可用的情况下客户端之间依然可以通过 DHT 和 PEX 找到对方。回源策略上建议给回源请求设置一个较大的抖动窗口比如 30 到 90 秒之间的随机延迟避免同时产生大规模回源高峰。补充一个做增量更新的技巧把分片哈希的元数据单独拆出来存成一个可以缓存的 JSON 文件。这样客户端启动时可以快速比对本地已有分片和服务器端最新分片只下载新增或变化的内容。这个方案配合混合分发架构效果非常显著很多用户更新一个 2GB 的应用实际下载量可能只需要 200MB。5. 写在最后做 HagiCode Desktop 这段时间我最深的感触是分发系统没有银弹只有取舍。CDN 贵但是稳定P2P 省成本但不可控混合分发本质上是在两者之间找到一个动态平衡点。不要一开始就指望 P2P 能包揽全部流量也不要把 CDN 当作唯一的依靠。先把降级路径设计好把数据校验做好再一步步调整两块之间的比例。如果你也要做一个类似的分发系统我建议第一版先把“本地缓存加 HTTP 回源”跑通再引入 P2P 层最后再考虑 DHT 和 PEX 这些进阶机制。稳扎稳打地迭代暴露出来的问题反而比一次性上大而全的方案少得多。这也是我们这个项目后期迭代比较顺利的原因。