资源下载的两种模式
写在前面：一些说法可能不准确，仅出于便于理解的考虑选择这样表述。
中心式下载
顾名思义，在该模式中，资源提供者是唯一的中心，所有的需求者都需要向其获取文件，且相互之间毫无关联。如果用图来表示，大概就是这样：
不难发现，需求者有几个，提供者就得一模一样地传几份，这不仅低效，且将长时间占满提供者的带宽，而如果提供者的带宽捉急，则整个体系下的所有人都会「遭受苦难」。我相信大部分人都有被百度网盘的限速恶心过的经历，如果提供者出于某种考虑限速上传，需求者们的境况就会雪上加霜。
分布式下载
分布式下载允许需求者之间相互交换数据，这就极大地减轻了提供者的带宽和时间压力，此外，提供者也不再只有一个，因为当需求者下载完全部数据后，只要他愿意，他也能成为新的提供者之一，这就大大增加了体系内活跃的资源总份数，得益于此，需求者们不再受到限速的困扰，只要大家都不限速且互相能连得上，往往能跑到满速，而且参与的人越多，下载就越快。
这种模式节约时间的原理是什么呢？请见下面这张示意图：
提供者在单位时间内输出了一份完整的资源副本，但是一分为二分别交给了 A 和 B，而且 A 和 B 拥有的数据正好互补，于是他俩在下载的同时，也能够同时向对方分享自己已经拥有的数据，于是，在理想状态下，提供者输出完整副本的瞬间，A 和 B 手上也都会拥有一份完整的资源，皆大欢喜。比之一个个发，节省了一半的时间。以此类推，如果有三个下载者，就给每个人发互不重复的 ⅓，只要三人能数据互通，总的耗时与两个下载者的情况相同；人数再多，也是如此，怎么样，是不是值得你说一声「妙啊」？
这就是 BT 下载的原理，而为了下载到心仪的资源，还有三样重要的东西，那就是 Tracker、种子（Torrent）和 BT 客户端（比如 qBittorrent）。
- Tracker 用来帮助提供者和需求者整个群体的相互通信，如果没有它，大家相互之间是不能联系上的；
- 种子的体积很小，像一份清单，记录了 Tracker 和资源的具体信息，你拿着它，就可以在网络上寻到 Tracker，并借之与他人相连并获取所需数据；
- BT 客户端用来加载种子，是与 Tracker 通信以及资源数据交换的具体执行程序。无论你是想下载数据还是上传数据分享给别人，一个开启的 BT 客户端都是必须的。因此，在 Tracker 看来，参与进来的客户端都被视为同伴（Peer）。
PT——封闭化的 BT
上边这个模式看起来很完美，但事实果真如此吗？
这样设计的初衷，是让需求者在获得资源以后也能成为提供者，为资源的流传作出贡献，但分布式下载的参与者往往都是像你我这样的普通人，硬盘不大，网速不快，刚好够用而已；不同于中心式下载的提供方往往能长期留存资源，我们随时有可能因为各种各样的原因失去资源（欣赏完了觉得没必要留着删了、硬盘坏了文件无法恢复了……）。随着时间的流逝，体系中的参与者越来越多地不再具有资源文件，于是新来的需求者可能就无法再从任何一个人那里获得资源了，于是，这个种子就「死」了。如果这种情况还算是「寿终正寝」，则下面要讲的情况就更令人痛心。
由于在 BT 体系下对各参与者的行为没有任何约束，一个需求者下载完以后可以选择不老老实实参与贡献，他可以简简单单地删掉 BT 客户端中加载好的种子，从而与整个体系「脱钩」，这种行为被称为下完就跑（Hit and Run）；也可以吝啬地将上传网速设置得极低，只下不上，做一个「吸血鬼」。毫无疑问，这些行为都会增大资源提供者的压力，且有悖于互联网分享精神，但自觉的参与者们却对此无能为力，既不能限制他们的白嫖，也不能采用某种手段惩罚他们。
为了解决这一问题，PT 应运而生。
PT 的英文全称是 Private Tracker，也就是私有化的 Tracker，不同于 BT 所用的公共 Tracker 能被所有人访问，PT 站点的 Tracker 只有其注册用户能使用，而且使用时需要每个人都独一无二的密钥。于是，通过密钥，每个参与者的流量都可以被 Tracker 记录下来，他的上传量是多少？他的下载量又是多少？上传速度怎么样？他保留种子多久了？这些信息都可以知道，于是 PT 站点的大家就有了可以量化的标准来评判一个成员是贡献者还是吸血者，从而作出相应的应对。在 Tracker 看来，你就是密钥，密钥就是你；如果你的密钥不慎泄露，那么心怀恶意的人完全可以使用它来从 PT 站猛下一通，而账，却都会算到你头上，这就是密钥无论如何不能外泄的原因所在。
由于 PT 要求其用户在享受下载权利的同时履行上传义务，所以一些在下载方面表现良好，而上传方面极端吝啬的下载客户端就会被 PT 禁止使用，比较有代表性的就是迅雷。另外，一些在汇报数据方面不老实的客户端也同样会被禁止。
行为与指标
分享率
衡量用户分享状况是否良好的一个重要指标就是分享率（Ratio），分享率 = 上传量 ÷ 下载量。BT 客户端中记录的上传量和下载量都是真实值，下载量往往与资源大小相等，而上传量则不尽相同。你可能会问，上传量要如何获得？
获得上传量有两个条件：
- 你正在做种；
- 有需求者连上了你并且正在从你处下载数据。
做种
那么什么是做种？做种也有两个条件：
- 你完整拥有着资源文件；
- 客户端内加载着该资源所对应的种子，且它正处于「做种」状态：
- 这一状态的前提条件是种子能正确指向资源文件的存放路径，如果你下载后不再挪动，则默认是指向正确的，但如果动过，就需要重新指定。
连接性
你可能对上传量获得条件中的「有需求者连上了你」有所疑惑，这里要谈到一个「连接性」的概念。连接性通常通过一个名为可连接的状态来指示，要么为是，要么为否：
- 是，意味着用户网络条件不错，可以主动连接他人；
- 否，意味着用户网络条件较差，不能主动连接他人，只能成为被动的一方。
而在 BT 协议中，供需双方必须有其中一个的可连接为是才能开启相互之间的通讯，如果两边都被动，就无法交流。
所以，如果你的可连接为否，也不用太在意，因为只是条件稍差一点，但不会导致没法玩。但这类用户能获取到的上传量往往就比较少，进而导致分享率不太好看。一般我们认为，分享率达到 1，就代表着一份资源完整「经过」了这位用户，没有任何损失，即使他不再做种，由于已经输出了一个完整的副本，所以也没有关系。但这个要求对很多人来说并不容易达到，所以，如果站点的分享率计算同 BT 客户端完全一致，恐怕很多用户被视为「不合格」。
站点数据统计
于是 PT 站点的分享率往往会经过修饰，比如，让种子半价优惠，则下载者的统计下载量就只有真实下载量的一半了；而若是提供双倍上传，则上传者的统计上传量就会达到真实上传量的两倍。通过这些措施，就能让用户的账面数据更加好看。除此之外的手段还有很多，比如，用户如果做种，就能获取积分，而积分可以用来兑换一些用于改善分享率的商品，等等，你可以大开脑洞尽情想象。
常见问题解答
分享率可真是个好东西，这么说，是越高越好喽？
并非如此。通过上文，你可以知道，任何人的上传量都不可能凭空得来，必须要有人切实下载资源，做种的人们才能获得真实上传量。所以，一味推高分享率，很可能意味着你保持吝啬，毫不下载，这对于整个集体，并不是最有利的决策，在保持分享率健康的基础上，你完全可以多多下载，让其他人的手头也变得更宽裕，这样就会有更多人开心起来。
做种就是做贡献，但我具体要做种多久才算够格呢？
从站点的角度来说，自然是希望做种做到天长地久，这样种子就能保持「长生不老」；但我们也非常清楚这并不太可能，所以你只要量力而行、尽力而为就可以，一般而言，只要你的真实分享率达到 1，后边额外的增长都算是你的贡献了。有些人可能不需要关机，或是拥有 NAS，他们可以 24 小时不间断做种，如果你没有条件，就不必如此。
历史上曾有一个非常著名的 PT 站，名叫 What.CD，关于其介绍，你可以看 这里。
What.CD 所采用的架构名为 Gazelle，它也很值得说道，请见 本文。