比特彗星 2.17 的两条自有机制：长效种子与顺序下载

比特彗星是老牌 BT 客户端里比较特殊的一个。通用部分——tracker、DHT、节点交换、磁力链接——它和别的客户端走的是同一套标准；真正的差异集中在两条自有的机制上：一条用来找做种者，一条用来控制数据到手的顺序。

这两个机制各自解决了一个具体问题，也各自带来一些副作用。理解它们，很多"为什么速度上不去""为什么边下边播会卡"就有确定答案了。

一、长效种子：不依赖 tracker 和 DHT 的找源方式

先说标准 BT 是怎么找到做种者的。两条路：

• tracker：中心服务器返回一份当前参与者的列表
• DHT：去中心化的分布式记录，问网络里谁手里有这份种子

这两条路都有共同的问题：记录是有时效的。一个人下完之后关掉客户端，记录慢慢失效；等哪天有人再打开这个老种子，可能一个源都找不到——哪怕某个角落里还有台机器留着完整数据。

长效种子换了思路：由客户端自己的服务端记录"谁保存着哪些完整文件、用什么地址对外提供服务"，客户端启动后去查这份记录，直接连过去取数据。

它的特点与代价都很明确：

	说明
不依赖 tracker 与 DHT	所以对没有 tracker 的老种子，也可能找到源
属自有协议	只有支持它的客户端之间能用；别的客户端即使在线做种，也走不上这条路
需要连服务端	客户端启动时必然有外部通信，这与纯 DHT 模式的习惯不同
记录在服务端	"谁保存了这份文件"是可被记录的，隐私上的取舍需要自行评估

第二行是最容易被误判的一条。 看到某个种子显示有做种者、速度却始终很低，一种常见情况是：那个做种者用的是别的客户端，它参与不进长效种子这条通道；而这种子又没有可用的 tracker 与 DHT 记录。两边都在线，就是握不上手。

二、顺序下载：为"能马上开始看"付出的代价

比特彗星 默认的取片策略是稀有优先——先取那些持有人最少的片段。这么做是为了整个网络：稀有片段一旦丢干净，整份文件就没人能拼齐了。

代价是数据到手的顺序完全随机。文件从中间开始出现，最后才是开头，所以默认模式下没法边下边看。

要边下边播，就得反过来：优先取靠前的片段，让它按播放顺序到达。这里有一个必然的取舍：

顺序下载时，能提供"下一个需要的那一片"的节点可能很少。 并行下载的通道数由"谁手里有我要的这片"决定；默认模式下任意节点都能提供一些片段，而顺序模式下选择面被限制在一个很窄的窗口里，于是：

• 并行度下降
• 整体速度变慢，尤其是刚开始那一段
• 一旦前段的提供者下线，进度就卡在同一个位置

所以它是个开关，不是优化：

• 需要边下边看：开顺序模式，接受总速度略低
• 只是要文件：用默认模式，速度更快

还有一个机制上的细节值得知道：媒体文件要先读到头部索引才能播放。有些封装格式把索引放在文件末尾，这时必须先取到尾部才能打开播放——这也是"明明下了前几分钟却播不了"的原因之一。

三、这两条机制都卡在同一个前提上：可连接性

不管走常规 peer 还是长效种子，能连上的前提是一样的：双方之间能建立连接。

问题出在 NAT 环境。如果你的机器在路由器后面、没有做端口映射，那么：

• 你能主动往外连别人
• 别人连不到你

后果是上传量接近 0，同时"能连上的节点数"被大幅削减——因为你只能占用自己主动建立的那些连接。表现就是：种子看着健康，速度却长期上不去。

处理方向按成本从低到高：

1. 开启客户端里的自动端口映射功能，让路由器放行
2. 路由器不支持或失败时，手动做端口转发
3. 无法改动网络环境时，用客户端自带的连接性检测确认状态，至少知道问题在哪一层

顺便说一句，协议加密能应对部分运营商对 BT 流量的特征识别，代价是略微增加开销。它是为受限网络准备的选项，正常情况下开着没有收益。

四、"最新版"这个说法实际影响什么

比特彗星 的版本号变化，对使用者可感知的部分通常只有三类：对新协议版本的支持范围、连接数与内存占用的表现、以及自有机制的实现方式。它不会改变上面那些机制的前提。

所以遇到速度问题，先判断瓶颈在哪一层，比纠结版本号有用：

• 连接数上不去 → 可连接性问题
• 连接数正常但速度低 → 对端上行有限、或对方客户端参与不进自有通道
• 磁盘占用长时间 100% → 写入侧问题，与网络无关

想确认客户端有没有被系统防火墙拦住，可以直接查它的规则状态：

Get-NetFirewallRule -DisplayName "*BitComet*" | Select-Object DisplayName, Enabled, Direction, Action

入站与出站是两条规则，只有出站被放行时，表现就是"能连出去、别人连不进来"，正好对应上一节说的那种情况。

五、按现象定位

现象	可能原因	处理方向
老种子显示有做种但速度极低	对方客户端参与不进自有通道	等待、换源，或确认自身可连接性
只有在特定客户端下才有的源	属自有协议范围	正常现象，不是故障
开顺序模式后速度明显下降	并行度收窄	不需要边看边下就关掉
边下边播卡住	索引在文件尾部，或前段提供者少	先取完整文件，或换源
上传长期为 0	不可连接	开启端口映射或手动转发
下载正常、上传很少	种子供需关系	属正常现象
磁盘占用持续 100%	写入瓶颈	调整缓存与下载目录

六、小结

比特彗星 2.17 这类客户端的差异，主要体现在两条机制上：

• 长效种子：绕开 tracker 与 DHT 的时效限制，代价是只在自有通道内有效、且依赖服务端记录
• 顺序下载：让数据按播放顺序到达，代价是并行度收窄、总速度下降

而两者能不能发挥作用，都先取决于你是不是可连接的——端口没通的情况下，再多机制也接不上人。

按"连接数是否正常"先把问题分成两半，再去看机制层面的细节，比逐个试开关有效。

相关页面：

相关页面下载