Bittorrent協(xié)議也就是BT下載軟件所使用的協(xié)議。那么這個協(xié)議規(guī)定了如何進行下載，其中也包含了很多過程。我們這里主要講述一下在Bittorrent協(xié)議交互情況下的一些概念。

Bittorrent協(xié)議交互

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

1､無種子時的通信現(xiàn)象

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

2､與tracker服務器通信

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

3､與peers通信

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

在一次實驗中(5M buffer)我們的主機A 與B的發(fā)送數(shù)據(jù)統(tǒng)計如下

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

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

Bittorrent協(xié)議中相關概念

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

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

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