BT通信协议

BT通信协议

• 1. torrent文件的格式
• 2. tracker HTTP 协议
• 3. peer wire协议(使用TCP)

1. torrent文件的格式

.torrent文件的内容，采用了B编码(Bencoding)。B编码是一种简洁的数据组织方式，支持4种数据类型： strings、integers、lists和dictionaries。详细可参见 B编码(Bencoding)

包含Tracker信息和文件信息两部分。Tracker信息主要是BT下载中需要用到的Tracker服务器的地址和针对Tracker服务器的设置，文件信息是根据对目标文件的计算生成的，计算结果根据BitTorrent协议内的B编码规则进行编码。所以，torrent文件就是被下载文件的“索引”。

Torrent文件基本结构：

    {
    "announce"="http://btfans.3322.org:8000/announce"   ;tracker 服务器的URL(字符串)
    "announce-list"=["http://..","http://.."]           ;备用tracker服务器列表(列表)
    "creation date"=1175204110                          ;种子创建的时间，Unix标准时间格式
    "encoding"="GBK"                                    ;编码
    "comment"="备注"
    "created by"="创建人信息"
    {
    
    "info"={"files"=[{"filehash"="SHA1 Hash","length"=168099584,"path"=["01.rmvb"]},
                  {...},
                  {...}                
                 ]
    
         "name"="保存目录名"
         "piece length"=2097152    ；每个块的大小，单位字节(整数)
         "pieces"="每个块的SHA1 Hash的值的顺序排列(二进制格式,长度为"20 X 块数")" 
         } 
    }
    
    }
    
    
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
    

• announce：tracker服务器的URL，本例中为http：//tracker.cnxp.com:8080/announce。
  • announce-list：可选。
  • creationdate：可选。.torrent文件的创建日期，使用标准的UNIX时间
  • comment：可选。.torrent文件制作者添加的任意格式的说明。
  • createdby：可选。制作.torrent文件的工具
  • encoding：可选。
  • info：发布的文件的信息。有两种格式，单文件格式和多文件格式。单文件格式包括length、md5sum（可选）、name、piecelength、pieces；多文件格式包括files、name、piecelength、pieces，其中files包括length、path、md5sum（可选），每一个文件都有单独的length、path、md5sum（可选）,其他信息参考 B编码(Bencoding)。

2. tracker HTTP 协议

BT客户端依次向.torrent中的trackerr服务器发送连接请求，以获得正在下载该文件的对等方列表，报告自己的信息。如果连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。

其中一些成分的含有如下：

• info_hash：.torrent文件中的info部分的sha1效验码，共20字节。Tracker服务器通过它在发布列表中找到对应的记录。
• peer_id：BT客户端的唯一性标识，在客户端启动时产生，共20bit。貌似没有具体的产生peer-id的算法，只要求能够保证唯一性即可。
• ip：可选，IP地址，没有的话服务器会自己找到。
• port：监听端口 。
• uploaded/downloaded：上传/下载的字节数（从客户机向Tracker服务器发送”started”开始计算）。
• left：还需下载的字节数。
• numwant：可选。客户端希望从Tracker服务器得到的对等方的数目。
• key:可选。一个扩展的唯一性标识，即使改变了IP地址，也可以使用该字段标识该BT客户机。
• compact：压缩标志。如果值为1表示接受压缩格式的对等方列表，即用6byte表示一个对等方 （前4byte表示IP地址，后2byte表示端口号）；值为0表示不接受。

Tracker服务器有个tracker程序来管理这些请求，得到这一串代码后就会用info_hash来查找列表，若找到就可以下载。接着就会反连（NatCheck）客户端的IP地址和端口，判断它是内网用户还是公网用户。接下来服务器返回现在正在下载这个文件的所有公网用户的IP和端口。

3. peer wire协议(使用TCP)

BT客户机会尝试与返回的对等方列表中的部分对等方建立连接

建立TCP连接之后，对等方之间的交互过程包括以下几步：

握手，通过Handshake分组实现。

互换所拥有的资源的情况。通过Bitfield分组实现。该例中，对等方B尚未下载任何资 源，故公布资源拥有情况的只有对等方A。对等方A通过分组283公布了自己资源拥有情况。

互通对资源的意愿情况，包括interested、nointerested、choke、unchoke等4种。

互相请求资源，通过request piece、piece分组实现。

断开连接。因为peer wire协议使用了TCP方式，对等方A与对等方B断开连接时，只需要断开他们之间的TCP连接即可。

连接的发起者应该立即发送握手报文。如果接收方能够同时地服务多个torrent，它会等待发起者的握手报文(torrent 由infohash 唯一标识)。尽管如此，一旦接收方看到握手报文中的info_hash 部分，接收方必须尽快响应。tracker 的NAT-checking 特性不会发送握手报文的peer_id 字段。

如果一个客户端接收到一个握手报文，并且该客户端没有服务这个报文的info_hash，那么该客户端必须丢弃该连接。如果一个连接发起者接收到一个握手报文，并且该报文中peer_id 与期望的peer_id 不匹配，那么连接发起者应该丢弃该连接。注意发起者可能接收来自tracker 的peer 信息，该信息包含peer 注册的peer_id。来自于tracker 的peer_id 需要匹配握手报文中的peer_id。

bitfield 报文可能仅在握手序列发送之后，其他消息发送之前立即发送。它是可选的，如果一个客户端没有piece(片)，就不需要发送该报文。bitfield 报文长度可变，其中x 是bitfield 的长度。payload 是一个bitfield，该bitfield 表示已经成功下载的piece(片)。第一个字节的高位相当于piece 索引0。设置为0 的位表示一个没有的piece，设置为1 的位表示有效的和可用的piece。末尾的冗余位设置为0。

       长度不对的bitfield 将被认为是一个错误。如果客户端接收到长度不对的bitfield 或者bitfield 有任一冗余位集，它应该丢弃这个连接。