BtTracker原理

注：參考了btsource、jbittorrent實現和utorrent機制

 一、做種

    現在很多BT軟體都提供了做種功能，在做種時，我們都必須指定tracker伺服器地址，如果該地址無效，則做出來的種子對BT協議來說是沒有任何實際意義的。

二、bt tracker服務

    對於純BT協議來說，每個BT網路中至少要有一臺Tracker伺服器（追蹤伺服器），tracker主要基本工作有以下幾個方面：

•  記錄種子資訊（torrent檔案資訊）
•  記錄節點資訊
•  計算並返回節點列表給BT客戶端

    每次我們利用BT軟體做完種子後，總要找個論壇之類的來上傳自己的種子，這樣別人就可以下載到這個種子。為什麼要上傳種子呢？原因：

• 上傳種子，其實就是把種子資訊記錄到tracker伺服器上
• 種子可以在論壇傳播，種子的擴充套件程度就決定了種子的健康度和下載度

    當其他使用者用BT軟體開啟種子後，BT軟體會對種子進行解析（BDecode），主要得到種子的相關資訊，包括：檔名、檔案大小、tracker地址等。然後BT軟體會向tracker地址傳送請求報文，開始進行下載。BT向tracker傳送的是Get請求，請求的內容主要有以下幾個方面：

 

    tracker收到該請求後主要進行以下幾步處理：

1.        根據info_hash查詢種子資訊，如果tracker沒有該種子的任何資訊，tracker伺服器可以返回錯誤或返回0個種子數

2.        如果tracker找到了種子資訊，接下來就會去查詢是否資料庫中已存在該peer_id的節點。接下來根據event的值進行相關處理。

3.        如果event是stopped，說明該節點已不可用，系統會刪除tracker上關於該節點的記錄資訊。

4.        如果event是completed，說明種子節點+1，非種子-1。

5.        如果event是started，說明這是種子第一次連線tracker，tracker需要記錄該節點資訊，此外如果left=0，說明這是一個種子節點。

6.        如果event是空，則說明節點正在下載或上傳，需要更新tracker伺服器上該節點的資訊。

7.        最後tracker從本地挑選出numwant個節點資訊返回給BT客戶端，實際返回的節點數不一定就是numwant，tracker只是儘量達到這個數量。

 

Tracker響應

Tracker正常返回的資訊結構主要是：

如果Tracker檢查發現異常，可以返回錯誤資訊：

 

Tracker如何挑選種子節點並返回給客戶端？

最普遍也是最簡單的方式，那就是隨機返回，tbsource採用的就是隨機返回的機制。不少研究論文也提出了相關的演算法，如IP地址策略和階段返回策略。

IP地址策略是指根據IP地址所含拓撲資訊來判斷兩個節點的距離，從而返回距離請求節點較近的節點列表。該方法主要適用於IPV6。

階段返回策略，根據節點的下載進度，返回下載進度相近的節點列表。

個人觀點：無論tracker採用什麼演算法，對BT客戶端來說，能夠提高的下載效率都是很有限的，採用“高階”的演算法有時反而會增加tracker的負載。因此隨機返回還算是比較高效的。

Bt協議中，有兩個策略可以用來提高整個BT網路的健壯性和下載速度，它們分別是：最少片段優先策略（BT客戶端處理）和最後階段模式。為了響應“最後階段模式”，當種子節點的下載進度大於80%（個人指定）時，tracker伺服器應該儘量返回種子節點給客戶端，幫助客戶端儘快完成下載，使其成為種子節點。

 

三、private tracker原理

         Privatetracker簡稱PT，目前主要應用於高清視訊下載。其實PT就是“我為人人，人人為我”這個目標的最佳實踐者。在實際的BT下載過程中，使用者通過種子下載完檔案後，出於“自私”的考慮（怕佔用自己頻寬），往往會退出做種，從而降低種子的熱度。這就是為什麼一個種子過了一段時間後，往往下載速度很慢或下載不完。

         為了真正地實現BT理念，PT強制每個下載者必須上傳一定量資料後，才能進行下載。如何保證這種行為呢？

    現在的PT一般存在於網路社群中，每個註冊網路社群的使用者都會分配到一個隨機的KEY，任何從社群下載的種子，都會包含使用者的KEY。每次使用者通過種子下載時，都會連線到社群的tracker伺服器上，tracker伺服器會檢查KEY對應使用者的上傳下載量，如果上傳量不滿足標準，則tracker伺服器會記錄相關資訊，並對該使用者的下載及社群活動進行相關限制。

測試，勿點