現在的很多BT下載都採用了DHT網路，這樣進行BT下載就不需要中心伺服器了。本文針對的是需要中心伺服器的BT下載。

  小弟我最近正在研究BT通訊協議，網上的資料很全，但是不是那事詳細和完整，因此，整理下來，一方面他日用到拿來看看，另一方面，希望對正在研究BT通訊協議的有點幫助。若有不正之處，請指正。

1. BT協議的工作過程

   BT協議主要包括3個部分：.torrent檔案的格式、tracker HTTP/HTTPS協議和peer wire協議(使用TCP)。其中tracker HTTP/HTTPS協議是BT客戶機與tracker伺服器之間的通訊協議，peer wire是BT客戶機之間的通訊協議。

1.1 torrent檔案的結構

   .torrent檔案的內容，採用了B編碼。B編碼是一種簡潔的資料組織方式，支援4種資料型別：bytestrings、integers、lists和dictionaries。integers、lists和dictionaries型別分別以字母i、l、d作為首定界符，以字母e作為尾定界符。bytestrings型別不使用首/尾定界符，其格式為<十進位制表示的字串長度>：<字串>，如4:spam表示字串“spam”。這4種資料型別巢狀使用構成了.torrent檔案的內容。

   我們先看下所舉例子的種子檔案內容，種子檔案中的伺服器內容如下：
 

其中的一些主要成份如下：

●announce：tracker伺服器的URL，本例中為http：//tracker.cnxp.com:8080/announce。

●announce-list：可選。備用tracker伺服器的URL列表，本例中為http://tracker.cnxp.com:8080/announce,http://btfans.3322.org:6969/announce等。

●creationdate：可選。.torrent檔案的建立日期，使用標準的UNIX時間，本例中為1152105243。

●comment：可選。.torrent檔案製作者新增的任意格式的說明。

●createdby：可選。製作.torrent檔案的工具，本例中使用的製作工具是BitComet/0.67。

●encoding：可選。釋出的資源使用的編碼方式，在本例中使用的是GBK。
 

●info：釋出的檔案的資訊。有兩種格式，單檔案格式和多檔案格式。單檔案格式包括length、md5sum（可選）、name、piecelength、pieces；多檔案格式包括files、name、piecelength、pieces，其中files包括length、path、md5sum（可選），每一個檔案都有單獨的length、path、md5sum（可選）。

另外，還有一些可選項，這裡就不在累述。

1.2 tracker HTTP/HTTPS協議

   BT客戶端依次向.torrent中的trackerr伺服器傳送連線請求，以獲得正在下載該檔案的對等方列表。如果連線成功獲得列表，就關閉連線，嘗試與列表中的對等方建立連線；如果不成功，嘗試下一個tracker伺服器。

第一、客戶端獲取Tracker伺服器的IP地址

圖一 客戶端傳送DNS請求包

從DNS伺服器的響應來看，我們可以獲取Tracker伺服器的IP地址：

10.rarbg.com：是一個別名伺服器

   主名稱：tracker.publicbt.com：95.211.88.54、95.211.88.49、95.211.88.51、

       9.rarbg.com：                    83.149.126.97

           exodus.desync.com：              208.83.20.164

           pow7.com：                       同10.rarbg.com

           tracker.novalayer.org：          194.54.80.150

           tracker.publicbt.com：           95.211.88.54、95.211.88.49、95.211.88.51

       tracker.torrent.to：             127.0.0.1

           tracker.torrentbay.to：          109.235.55.11

           tracker.1337x.org:               95.215.62.224

           tracker.openbittorrent.com: 95.215.62.26

   以上為各Tracker伺服器的IP地址。

第二、TrackerHTTP/HTTPS協議

   BT客戶端依次向.torrent檔案中的tracker伺服器傳送連線請求，以獲取peers列表（主要是IP地址和監聽埠）。如果連線成功獲取列表，就關閉連線，嘗試與列表中的對等方建立連線；如果不成功，嘗試下一個tracker伺服器。

圖二 BT客戶端向Tracker伺服器傳送HTTP請求

   447號分組中的HTTP部分內容如圖6所示。

圖三 HTTP部分內容

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

● info_hash：.torrent檔案中的info部分的sha1效驗碼，共20位元組。Tracker伺服器通過它在釋出列表中找到對應的記錄。

● peer_id：BT客戶端的唯一性標識，在客戶端啟動時產生，共20bit。貌似沒有具體的產生peer-id的演算法，只要求能夠保證唯一性即可。

● ip：可選，IP地址，沒有的話伺服器會自己找到。

● port：監聽埠，這裡為10775。

● uploaded/downloaded：上傳/下載的位元組數（從客戶機向Tracker伺服器傳送”started”開始計算）。

● left：還需下載的位元組數。

● numwant：可選。客戶端希望從Tracker伺服器得到的對等方的數目。

● key:可選。一個擴充套件的唯一性標識，即使改變了IP地址，也可以使用該欄位標識該BT客戶機。

● compact：壓縮標誌。如果值為1表示接受壓縮格式的對等方列表，即用6byte表示一個對等方 （前4byte表示IP地址，後2byte表示埠號）；值為0表示不接受。

   另外，在與Tracker伺服器互動的過程中，有很多伺服器的已經被封殺禁止，所以，會有很多這樣的結果。

圖四 被封后的Tracker伺服器互動過程

   Tracker伺服器有個tracker程式來管理這些請求，得到這一串程式碼後就會用info_hash來查詢列表，若找到就可以下載。接著就會反連（NatCheck）客戶端的IP地址和埠，判斷它是內網使用者還是公網使用者。接下來伺服器返回現在正在下載這個檔案的所有公網使用者的IP和埠。返回的部分資料如圖五所示。

圖五 HTTP之上部分資料

   其中“660：”以及之前的部分使用的是ASCII字符集，“660：”之後的部分是用16進製表示的二進位制數。從分組內容可以看出：完成整個檔案下載的peers數為76；正在下載的peers數目為10個；還沒有完成該檔案下載的peers數目為34；interval的值為1967，也就是說BT客戶端最多每隔1967個時間單位就與tracker伺服器重新聯絡一次；最少時間間隔為983；peer部分共有660個位元組，由於BT客戶端支援對等方列表的壓縮，即6個位元組表示一個對等方，也就說返回的對等方個數為110個。

1.3 peer wire協議

   BT客戶機會嘗試與返回的對等方列表中的部分對等方建立連線，下面是對等放列表中的208.131.161.209:53062為例，分析一下對等方之間的互動過程。如圖六所示，只分析TCP之上的部分。約定對等方A指的是208.131.161.209:53062，對等方B指的是172.16.8.93:3012.

圖六 對等方間通訊過程

   建立TCP連線之後，對等方之間的互動過程包括以下幾步：

（1） 握手，通過Handshake分組實現。

（2） 互換所擁有的資源的情況。通過Bitfield分組實現。該例中，對等方B尚未下載任何資 源，故公佈資源擁有情況的只有對等方A。對等方A通過分組283公佈了自己資源擁有情況。

（3） 互通對資源的意願情況，包括interested、nointerested、choke、unchoke等4種。

（4） 互相請求資源，通過request piece、piece分組實現。

（5） 斷開連線。因為peer wire協議使用了TCP方式，對等方A與對等方B斷開連線時，只需要斷開他們之間的TCP連線即可。

圖七 Handshake資料包的上層內容

   握手：Handshake：

   pstrlen: 的字串長度，單個位元組。

       pstr: 協議的識別符號，字串型別。

       reserved: 8 個保留位元組。當前的所有實現都使用全0.這些位元組裡面的每一個位元組都可以用來                      改變協議的行為。來自Bram 的郵件建議應該首先使用後面的位，以便可以使用前面                      的位來改變後面位的意義。

      info_hash: 元資訊檔案中info 鍵(key)對應值的20 位元組SHA1 雜湊。這個nfo_hash和在tracker                      請求中info_hash 是同一個。

      peer_id: 用於唯一標識客戶端的20 位元組字串。這個peer_id 通常跟在tracker 請求中傳送                      的peer_id相同(但也不盡然，例如在Azureus，就有一個匿名選項)。

   在BitTorrent 協議1.0 版本，pstrlen = 19, pstr = “BitTorrent protocol”。

   連線的發起者應該立即傳送握手報文。如果接收方能夠同時地服務多個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。

圖八 Bitfiled資料包上層資料

   bitfield:

   itfield 報文可能僅在握手序列傳送之後，其他訊息傳送之前立即傳送。它是可選的，如果一個客戶端沒有piece(片)，就不需要傳送該報文。bitfield 報文長度可變，其中x 是bitfield 的長度。payload 是一個bitfield，該bitfield 表示已經成功下載的piece(片)。第一個位元組的高位相當於piece 索引0。設定為0 的位表示一個沒有的piece，設定為1 的位表示有效的和可用的piece。末尾的冗餘位設定為0。

   長度不對的bitfield 將被認為是一個錯誤。如果客戶端接收到長度不對的bitfield 或者bitfield 有任一冗餘位集，它應該丟棄這個連線。

圖九 request piece資料包上層部分

   request piece分組結構如上圖所示。

   該報文長度固定，用於請求一個塊。payload包含如下資訊：

   index：整數，指定從零開始的piece索引。

   begin：整數，指定piece中從零開始的位元組偏移。

   length：整數，指定請求的長度。