作為一種廣泛的，流行的下載模式.Bittorrent協議的使用給我們的互聯網下載帶了新的概念。那么在Bittorrent協議交互中我們如何理解這個過程呢？針對這方面的數據傳輸，我們現在來詳細介紹一下。

Bittorrent協議交互

考慮到不同軟件對Bittorrent協議的實現不同,我們下面的協議交互測量實驗只針對于數據傳輸前后的報文進行分析｡我們實驗用的是BitComet 0.63｡以下是測量的一些現象:(假設我們的機器是主機A)

1､無種子時的通信現象

在沒有下載種子和提交下載命令的時候,可以看到主機與一系列IP地址的遠端主機通信,發送大小為98字節的UDP報文,使用的端口都是17638｡這些數據包可以看作是BitComet程序特有的給P2P網絡主機發送的消息包(因為在ABC下載程序中中就沒有這些UDP報文)

2､與tracker服務器通信

由于Tracker服務器提供Http/Https的服務,對Http/Https的請求做出響應｡其中響應里包含了peer的列表,幫助主機A獲得所需的信息｡主機A通過.torrent文件中所記錄的信息:tracker服務器列表和文件的info值發起對tracker服務器的HTTP連接,并用GET 命令獲得peer列表｡

3､與peers通信

當主機獲得peer列表后將主動向這些IP地址發起TCP連接,端口隨機分布,而且之后的數據傳輸都建立在TCP之上｡在一次觀測中發現一個IP(222.95.92.4 假設為B)地址占據了主要的流量,下面就對他們的通信進行觀測分析:

在一次實驗中(5M buffer)我們的主機A 與B的發送數據統計如下

可以看到B作為A的主要數據來源, 也從A受到了相當的數據量,說明B地址的主機不是一個種子,而是與A一樣的下載者｡

在三次TCP握手之后,A主機向B發起Bittorrent handshake,B回送一個handshake. 其中關于handshake報文的內容信息可以參考,值得注意的是握手以字符19(0x13)開始,跟著是字符串'BitTorrent protocol',這可以作為檢測BT下載的一個關鍵字信息｡握手完畢之后是長度前綴和信息輪流出現的數據流｡零長度信息用來保持連接,被忽略｡這種信息一般2分鐘發一次,但是在等待數據期間超時很容易發生｡

Bittorrent協議中相關概念

Tracker：收集下載者信息的服務器，并將此信息提供給其他下載者，使下載者們相互連接起來，傳輸數據。

種子：指一個下載任務中所有文件都被某下載者完整的下載，此時下載者成為一個種子。發布者本身發布的文件就是原始種子。

做種：發布者提供下載任務的全部內容的行為；下載者下載完成后繼續提供給他人下載的行為。