Merkle Tree - 在BT下载BitTorrent文件中的使用
什么是BT下载
BT下载，大家应该都很熟悉，所谓的BT下载，其实就是采用了P2P技术来让客户端相互间进行数据传输，一来加快数据下载的速度，二来减轻下载服务器的负担。
为了更好的理解，我还是举个简单的BT下载的例子吧。假如，下载服务器T上有BT资源 S，既然是BT资源，那么S里的数据肯定被分成一块一块的，假如它由a,b二块组成。这时，A、B两个用户都想下载BT资源S， A首先会从T上下载a, 下载完成后，就会告知B，此时B知道A上已经有数据块a了，如果这时B去下载S时，它会从T上下载b,并且同时去A上下载a，这样既加快了下载效率，又减轻了服务器T的负载。
上面只是简单的描述了数据传输的大概逻辑，但是有一点我们还没有提到，那就是数据传输正确性的验证。一般，数据在跨网络传输时，为了却确保传输的正确性，客户端在接收到数据时需要对数据进行验证，验证数据在传输过程中是否出现了什么意外情况，如验证数据是否被别人篡改，数据是否丢失等。常用的验证方式是，数据传输前，对传输的数据进行计算，生成一个信息摘要，而客户端接收到数据时，会再次对接收到的数据进行计算，形成一个新的摘要，然后比对新摘要和接收的摘要是否一致，如果一致表示接收到的数据时是效的，反之，数据是无效的，需要重新进行传输。
BT下载的处理过程简述
大家都知道，我们使用BT下载时，通常要先下载一个称为种子文件的东西（文件后缀名是.torrent), 这个文件里包含哪些内容呢？ 它其实包含了对要下载的资源的一些描述，如实际资源所在的地址，文件名，文件长度，数据块长度，以及各个数据块对应的摘要信息等。下载文件的过程分为以下几个步骤：
1. 首先，客户端A会根据下载的种子文件得出资源的目标服务器地址，然后与目标服务器地址建立连接， 进行数据块下载；
2. 当一个数据块下载完成后，客户端A会计算该数据块的摘要，然后用这个摘要与先前种子文件里的摘要进行比对，如果一致，表示这个数据块下载成功，否则，重新下载；
3. 如果数据块下载成功，客户端A会与其它下载资源的客户端进行通信，告知它们它已经成功下载了一个数据块，然后其他客户端也需要下载这个数据块时，会去客户端A下载。 当然，实际情况可能并不是这么简单，里面肯定还牵涉到负载相关的东西。
这个算法看似非常不错，但是它存在一点点问题：它把资源里所有的数据块对应的摘要信息都存储在 种子文件里，而摘要信息也是需要占用一定存储空间的，大概20B，这样，当下载的资源特别大时，会产生许多数据块，从而会产生许多摘要信息，最终会使得种子文件变得非常庞大。如果这样，客户端争先去下载这个种子文件时，会对种子文件服务器造成很大的负载压力。
怎么办呢？ 一种方法是将数据块的大小设的特别大，这样，数据块的数量就会减少，从而产生的摘要数量就会变小，但是使用这个方法就会衍生出其它问题：一个客户端下载完一个数据块后，验证数据块时发现数据块无效，此时需要重新传输，由于数据块很大，导致白白浪费了很多网络资源（因为数据块比较大，传一块不容易嘛）。
采用Merkle Hash Tree简化数据块的验证
首先根据下载资源里的所有数据块构造一个Merkle Hash Tree，具体如图一。 此时，已经不是将所有数据块的摘要放在种子文件里了，而仅仅是存放根节点（0节点）hash值，这样，无论下载资源有多大，种子文件里只保存一个信息摘要，占用存储会大大减少。客户端下载种子文件时，会很快就下载完成，从而减少了种子文件服务器的负担，提高了系统的整体性能。
如果这样，客户端从种子文件里只能得到一个Hash值（根节点），那么当客户端下载得到一个数据块又怎么验证呢？ 验证过程是这样的，拿图一来举例子吧，假如客户端下载piece0, 这样可得到节点15的hash值，然后通过组合计算，通过15、16节点的hash值计算得到节点7的hash值，依次计算，最后得到节点0的hash值，然后把这个值和种子文件里的hash值进行比较，如果一样，表示数据块有效，否则重新进行下载。这里有点需要注意：如果验证成功，会将hash校验相关路径的hash值会缓存下来，以简化后续数据块的校验。例如，客户端对数据块piece0进行了验证，且缓存了各相关节点的hash值，此时如果你需要对piece1进行验证，无需从其它客户端获得 及节点8、4、2的hash值，因为在对piece0进行验证时已经证明了节点7的正确性。所以，缓存的节点hash值越多，验证越容易。
图一 Merkle Hash Tree
参考论文地址：http://www.docin.com/p-439367248.html