參考了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請求，請求的內容主要有以下幾個方面：
info_hash
必填
種子文件info字段的SHA1值（20字節）
peer_id
必填
節點標識，由BT客戶端每次啓動時隨機生成
port
必填
節點端口，主要用於跟其他節點交互
uploaded
必填
總共上傳的字節數，初始值爲0
downloaded
必填
總共下載的字節數，初始值爲0
left
必填
文件剩餘的待下載字節數
numwant
必填
BT客戶端期望得到的節點數
ip
選填
BT客戶端IP，選填的原因是Tracker可以得到請求的IP地址，不需要客戶端直接上傳
event
選填
started/stopped/completed/空。當BT客戶端開始種子下載時，第一個發起的請求爲started，
在下載過程中，該值一直爲空，直到下載完成後才發起completed請求。做種過程中，發送
的event也爲空。如果BT客戶端停止做種或退出程序，則會發起stopped請求。
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正常返回的信息結構主要是：
interval
必填
請求間隔（秒）
complete
選填
種子節點數
Incomplete
選填
非種子節點數
peers
ip
必填
IP地址
peer_id
選填
節點標識
port
必填
端口
如果Tracker檢查發現異常，可以返回錯誤信息：
failure reason
錯誤原因
Tracker如何挑選種子節點並返回給客戶端？
最普遍也是最簡單的方式，那就是隨機返回，tbsource採用的就是隨機返回的機制。不少研究論文也提出了相關的算法，如IP地址策略和階段返回策略。
IP地址策略是指根據IP地址所含拓撲信息來判斷兩個節點的距離，從而返回距離請求節點較近的節點列表。該方法主要適用於IPV6。
階段返回策略，根據節點的下載進度，返回下載進度相近的節點列表。
個人觀點：無論tracker採用什麼算法，對BT客戶端來說，能夠提高的下載效率都是很有限的，採用“高級”的算法有時反而會增加tracker的負載。因此隨機返回還算是比較高效的。
Bt協議中，有兩個策略可以用來提高整個BT網絡的健壯性和下載速度，它們分別是：最少片段優先策略（BT客戶端處理）和最後階段模式。爲了響應“最後階段模式”，當種子節點的下載進度大於80%（個人指定）時，tracker服務器應該儘量返回種子節點給客戶端，幫助客戶端儘快完成下載，使其成爲種子節點。
三、private tracker原理
Privatetracker簡稱PT，目前主要應用於高清視頻下載。其實PT就是“我爲人人，人人爲我”這個目標的最佳實踐者。在實際的BT下載過程中，用戶通過種子下載完文件後，出於“自私”的考慮（怕佔用自己帶寬），往往會退出做種，從而降低種子的熱度。這就是爲什麼一個種子過了一段時間後，往往下載速度很慢或下載不完。
爲了真正地實現BT理念，PT強制每個下載者必須上傳一定量數據後，才能進行下載。如何保證這種行爲呢？
一、做種
現在很多BT軟件都提供了做種功能，在做種時，我們都必須指定tracker服務器地址，如果該地址無效，則做出來的種子對BT協議來說是沒有任何實際意義的。
二、bt tracker服務
對於純BT協議來說，每個BT網絡中至少要有一臺Tracker服務器（追蹤服務器），tracker主要基本工作有以下幾個方面：
記錄種子信息（torrent文件信息） 記錄節點信息 計算並返回節點列表給BT客戶端
每次我們利用BT軟件做完種子後，總要找個論壇之類的來上傳自己的種子，這樣別人就可以下載到這個種子。爲什麼要上傳種子呢？原因：
上傳種子，其實就是把種子信息記錄到tracker服務器上 種子可以在論壇傳播，種子的擴展程度就決定了種子的健康度和下載度
當其他用戶用BT軟件打開種子後，BT軟件會對種子進行解析（BDecode），主要得到種子的相關信息，包括：文件名、文件大小、tracker地址等。然後BT軟件會向tracker地址發送請求報文，開始進行下載。BT向tracker發送的是Get請求，請求的內容主要有以下幾個方面：
info_hash
必填
種子文件info字段的SHA1值（20字節）
peer_id
必填
節點標識，由BT客戶端每次啓動時隨機生成
port
必填
節點端口，主要用於跟其他節點交互
uploaded
必填
總共上傳的字節數，初始值爲0
downloaded
必填
總共下載的字節數，初始值爲0
left
必填
文件剩餘的待下載字節數
numwant
必填
BT客戶端期望得到的節點數
ip
選填
BT客戶端IP，選填的原因是Tracker可以得到請求的IP地址，不需要客戶端直接上傳
event
選填
started/stopped/completed/空。當BT客戶端開始種子下載時，第一個發起的請求爲started，
在下載過程中，該值一直爲空，直到下載完成後才發起completed請求。做種過程中，發送
的event也爲空。如果BT客戶端停止做種或退出程序，則會發起stopped請求。
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正常返回的信息結構主要是：
interval
必填
請求間隔（秒）
complete
選填
種子節點數
Incomplete
選填
非種子節點數
peers
ip
必填
IP地址
peer_id
選填
節點標識
port
必填
端口
如果Tracker檢查發現異常，可以返回錯誤信息：
failure reason
錯誤原因
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服務器會記錄相關信息，並對該用戶的下載及社區活動進行相關限制。
//g個人覺得private Tracker比較好
