BT种子的原理

这个可以分两个层面来解释下：

1、torrent文件的原理：如果您这个问题是指torrent文件本身，那么，当您对一个文件（或者文件夹）制作成.torrent文件，实际上生成的.torrent文件里面主要包括了这些信息：

A）这个文件（文件夹）中数据的SHA1值，比如一个1G的文件，如果按1M每块进行分块，则会被分为了1000块，torrent中就会有这1000个数据块的指纹值（SHA1的hash值），这个占据了torrent文件的绝大部分空间。这些值的目的是为了下载的过程中进行数据校验，确保数据收到的和当时源头制作torrent时的源文件100%一致，防止恶意数据攻击。

B）一般制作torrent文件时，还会要指定一个或者多个Tracker的地址，比如http://www.a.com:8080/announce这种地址。torrent里面一般也会存储了这个信息，这个其实也尤为重要。相当于记录了一个问询服务器的地址，这个问询服务器的作用，后面我再解释。

C）文件或者文件夹内每个文件的名字，方便下载文件时，磁盘上直接命名好跟原始数据一样的目录结构、文件名。

D）其它一些辅助和可扩展的信息，比如可以配置一个P2SP的http地址辅助下载，比如制作软件的名字、备注……。 E）上面信息生成后，torrent会把A）里面的这些信息，以及torrent里面的文件名等关键信息，再进行一次Hash，生成一个新的SHA1值，作为torrent的HASH值，也就是我们经常看到的下载软件里面对这个种子命名的一个唯一的hash值，也有的在magnet这种磁力链接中可以看到这个值，这就是torrent的唯一标记。

以上就是.torrent文件的内容，可以用记事本打开，但可能看到乱码。这个文件的编码遵循了bencode编码规则。但实际内容就主要是上面这些。所以，torrent可以理解为对原始数据的一些记录。

2、如果您的问题是指，BT是如何通过.torrent开始进行下载的，那么这个的原理大概是这样的：

A）下载软件拿到.torrent文件后，先进行打开，读取里面的这些信息，载入内存。

B）torrent中有Tracker的地址，下载软件拿到后，会去跟Tracker进行通讯，告诉Tracker：我要下载这个文件（通过hash值作为标记）； Tracker收到请求后，会记录这个客户端的公网IP（记录这厮在下载这个文件），同时呢，会返回给他：我这边还知道哪些人也在下载这个文件，一般是会返回200个IP（如果不够，当然就有多少返回多少）。 当然了，如果下载过程中，协议要求你必须5分钟跟tracker通讯一次，如果太久不通讯，tracker就认为你下线了，会把你从节点列表中删除的。

C）客户端拿到了一堆IP后，就开始挨个去尝试连接，连上后就开始互相通讯了。比如告诉对方，我有哪些分块，问问对方有哪些，然后把我有的给对方；让对方把他有的某一块给我，这样就你来我往开始了下载。当然，如果很悲催的情况下，此时没别人在线，那就只能没速度了，就只能不停的找啊找啊找朋友，直到找到一个好朋友。

D）当然，如果torrent中有一个P2SP的Http地址辅助下载，那么也可以同时从这个Http服务器要数据，也会把这个服务器当成一个普通的节点，每次要1块数据，通过Http协议里面的Range标记，指定只要一部分数据过来辅助下载。

整个BT的基本原理和过程就是这样，当然，这只是BT的基本原理，要做好一个完善的BT还是有很多路要走的。比如：

1）如果Tracker服务器出问题了，连不上这个问询的服务器，就拿不到周围的邻居节点，怎么办？---NB的BT发明者提出了DHT的概念，就算Tracker连不上了，也可以通过分布式哈希表DHT技术，通过DHT网络慢慢的寻找志同道合的邻居节点，只是没有Tracker那么直接那么快速，但慢一些总还是有机会找到邻居的。

2）网络是复杂的，特别是我们聪明的各个运营商，为了不让自己的用户消耗太多带宽，很多地区的运营商对P2P是有封锁的，比如我知道的包括某城宽带等。他们的做法早期是分析协议里面的握手消息，BT的握手消息是明文的Bittorrent Protocol，粗暴的运营商看到刚建立完连接就发这个明文会立即断开连接；文明点的运营商看到后不断开连接，但会限速到20K让你慢慢下载。当然，BT后来也发明了加密协议，运营商也升级了封锁的设备，也开始模拟自己是一个客户端，尝试分析加密后的协议，精彩纷呈。所以，要做一个稳定的靠谱的P2P系统还是有不少坑要趟的。

3）还有很多很多，比如BT对磁盘的调度、缓存的机制、文件分块的调度算法、服务器对几百万几千万用户量时的性能提升等等。

以上是看到问题随便想到的一些，希望能有所帮助。

转载链接：https://www.zhihu.com/question/49829233/answer/160765176