BT 缺的那几块能从 HTTP 上补吗：跨协议多源是怎么成立的

下载冷门资源时，最常见的卡点是最后那几个百分点：速度掉到几 KB，甚至完全停住。

原因前面几篇讲过——做种的人少，缺的那几块只有极少数人手里有。

但还有一种情况：同样的文件，其实在网上某个 HTTP 服务器上也有。 那问题就来了——能不能从那儿把它补回来？

比特彗星2.17最新版 在这方面做了一件事：在下载的同时，去 HTTP、FTP 甚至 eMule 网络里找同名同内容的文件，把缺的部分从那边取回来。

听起来只是"多找几个源"，但真要做成，得先解决两个不显然的问题。

一、第一个问题：怎么认定"这是同一个文件"

这是整个机制的起点，也是最容易被忽略的一步。

两台服务器上都有一个叫 movie.iso、大小也一样的文件，它们是同一个文件吗？

不一定。 名字可以随便起，大小撞车也不罕见。如果搞错了，你拼进来的就是一段别人的数据。

所以在动手取之前，必须先有一个"验货标准"——一个不依赖文件名、不依赖来源、只看内容本身的依据。

BT 这边正好有：分片哈希。

每份种子文件里，都记着每个分片的哈希值。这个值是按内容算出来的，换个名字、换个来源，只要是同一份数据，哈希就对得上。

于是它天然可以当成跨来源的通用标准：

• 从 BT 网络拿到的数据，用分片哈希校验
• 从 HTTP/FTP 拿到的数据，同样用分片哈希校验
• 对得上就收下，对不上就丢掉

这就是整套机制的地基：不是"相信那个源"，而是"相信校验结果"。

顺带说明一个后果：正因为判定依据是内容本身，所以只要内容差一个字节，校验就会失败。这解释了后面"边界"那一节里的几种情况。

二、第二个问题：怎么只把缺的那几块取回来

认定同一个文件之后，还有第二个问题：HTTP 是按整个文件给的，难道要下一整份？

不用。HTTP 有一个特性正好能用上：可以只请求文件的某一段字节。

示意一下这种请求：

curl -r 1048576-2097151 -o piece.bin "$MIRROR/movie.iso"

这个请求要的不是整个文件，而是从第 1048576 字节到第 2097151 字节这一段。

有了它，“补齐”就成立了：缺哪一块，就去请求那一块对应的字节区间，拿回来校验通过，就填进对应的位置。比特彗星2.17最新版 的“多管齐下”就是建在这个能力上。

所以"多管齐下"不是把整个文件从多个地方各下一遍，而是"按需取块"——每一块从哪个源拿，都可以单独决定。

这里有个前提值得记住：如果那个服务器不支持断点/范围请求，就只能整份下载。 而整份下载意味着你没法只补缺的那几块——这条路就走不通了。

三、eMule 那一路为什么更难

HTTP/FTP 那一路之所以好办，是因为它们是无协议的"文件服务器"：你告诉它要哪段字节，它给你哪段，至于这段数据对不对，由你自己校验。

eMule 完全是另一回事：它是另一套独立的 P2P 网络，有自己的一套身份标识与校验方式。

两套网络的分块方式、哈希算法都不一样。 也就是说：

• BT 的分片哈希，在 eMule 那边不通用
• eMule 那边的分块，也和 BT 的分片边界对不齐

于是想跨这两套网络共用数据，就必须额外做一层识别与重新校验的工作——不能像 HTTP 那样"拿来即校验"。

这也说明了一件事：跨来源的难度不在"能不能连上"，而在"两边有没有共同认可的校验标准"。 有（BT 与 HTTP），就简单；没有（BT 与 eMule），就得自己造一座桥。

四、它和"长效做种"不是一回事

这两件事经常被放在一起说，但它们解决的是不同层面的问题。

长效做种仍然在 BT 这套网络里——它是让比特彗星的用户之间多一条找源的路，找的还是"持有这份数据的 BT 用户"。

跨协议则是直接离开 BT 网络，去别人的文件服务器上取数据。

所以两者的边界很清楚：

• 长效做种解决"BT 网络里人太少" → 只要还有人在比特彗星上挂着，就有机会
• 跨协议解决"BT 网络里根本没有你要的那几块" → 但前提是网上别处确实有同一份文件

前者靠协议内的机制，后者靠协议外的巧合。 这个区别决定了它们的可靠性不一样。

五、这套做法的边界

边界一：只在"确实存在同内容文件"时有效。

这是最硬的一条。 冷门资源之所以冷门，常常就是因为它只在这个种子里有，别处没有。这时候跨协议找源自然也无从下手。

边界二：内容差一个字节就不行。

因为判定依据是分片哈希。 网上那份如果是被重新压过的、改过字幕的、加过水印的，哈希对不上，一块都拼不进来。

换个角度说：它要求"完全一致"，而现实中的转载往往不是完全一致。

边界三：HTTP 那边的可用性不由你控制。

BT 是分布式的——一个人下线，别人还在。而 HTTP 源是单点的：那台服务器一关，这条路立刻断掉，而且你没有任何办法。

边界四：校验本身有开销。

从非 BT 源拿回来的数据，同样要算哈希。 比起直接信任，这份开销换来的正是"敢于从陌生来源取数据"的底气——这笔账是划算的，但它确实存在。

六、按现象定位

• 找得到同文件却补不进来（原因方向：内容不完全一致；处理方向：核对来源是否为同一版本）
• 只能整份下、无法补片（原因方向：服务器不支持范围请求；处理方向：属该源的限制，换源）
• 补进来的部分被丢弃（原因方向：校验未通过；处理方向：属正常保护，说明不是同一份数据）
• 卡在 99% 且找不到其他源（原因方向：别处确实没有这份文件；处理方向：属边界，只能等做种者）
• 昨天能补、今天不行（原因方向：HTTP 源下架（单点）；处理方向：属边界；BT 侧不受影响）
• eMule 那一侧始终用不上（原因方向：两套网络无共同校验标准；处理方向：属机制差异）
• 从多个源同时取，速度上去了（原因方向：按需取块 %2B 分别校验；处理方向：属预期）
• 期待"随便找个同名文件就能拼"（原因方向：误判了判定依据；处理方向：判定看内容，不看名字）

七、小结

关于 比特彗星2.17最新版 这类"跨协议多源"，记住四条：

• 地基是"有一个各方都认的校验标准"：BT 的分片哈希在这里充当了这个角色——不是相信来源，而是相信校验结果
• "多管齐下"是"按需取块"：靠 HTTP 可以只请求某段字节，才谈得上从别处补齐；不支持范围请求的源用不上
• 跨到 eMule 更难，因为两套网络没有共同的校验标准——难在"怎么认定是同一份"，不在"能不能连上"
• 它和长效做种是两个层面：一个在协议内多找源，一个到协议外找同一份文件——后者依赖"别处刚好也有"这个巧合

这里可以带走的经验是关于"跨来源整合"的：只要数据来自多个地方，就必然需要一个共同的校验标准；没有它，两份数据只能各自成篇。

所以"能不能整合"的第一个问题从来不是"怎么取"，而是"凭什么认定取回来的和已有的是一回事"——先把这个依据定下来，剩下的才是工程问题。

https://www.ijinshan.com/application/BitComet.html?channel=4102