摘要

通過在下載過程中使用 HTTP 或 FTP 服務器向節(jié)點發(fā)送額外的數(shù)據(jù)來增加下載速度，從而減少 BitTorrent 下載中可能出現(xiàn)的下載停滯情況。

原理

很多提供 BitTorrent 下載鏈接的網(wǎng)站也會同時提供相同文件的 HTTP 或 FTP URL 。這些 URL 所指向的文件是完全相同的。利用 WebSeeding 技術的 BitTorrent 客戶端可以從任意一種來源（即 BitTorrent 和 HTTP 或 FTP）下載文件，將下載到的數(shù)據(jù)塊組裝成為一個完整的文件。 HTTP 或 FTP 服務器充當著一個始終處于未限速狀態(tài)的 “種子”，即它可以不間斷地提供文件的數(shù)據(jù)塊，以加速文件的下載。

優(yōu)勢

每個 BitTorrent 下載都有一些開放下載端口的源，也就是種子，任何人都可以從這些源開始下載。

對于不能識別元數(shù)據(jù)添加的客戶端，這種新方法不會破壞或更改任何內(nèi)容。

不支持 HTTP/FTP 種子的 BitTorrent 客戶端仍然可以通過其他支持 HTTP/FTP 的同伴來共享數(shù)據(jù)塊。

無需更改元數(shù)據(jù)。下載管理工具通?？梢詾橐粋€文件添加多個 HTTP/FTP 鏡像網(wǎng)址，用戶只需單擊網(wǎng)頁上多個鏈接并識別相同的文件名即可。

大家對 HTTP/FTP 服務器及其協(xié)議非常熟悉。

這種新方法已經(jīng)在多個 BitTorrent 客戶端中實現(xiàn)，如 IMFile 、 GetRight 、 Mainline 、 uTorrent 、 Azureus 和 libTorrent 。

只需要在 BitTorrent 客戶端中進行少量更改，并且不需要更改 Tracker 、 HTTP 或 FTP 服務器。在 HTTP 或 FTP 服務器上也不需要使用腳本。

由于許多常見的客戶端已經(jīng)支持此功能（特別是 IMFile 客戶端），因此使用公司或個人現(xiàn)有的 HTTP/FTP 服務器完全可以進行 BitTorrent 下載的種子發(fā)布。

元數(shù)據(jù)擴展

在 BitTorrent 元數(shù)據(jù)文件的主要區(qū)域中，而不是 “info” 部分的一部分，將會有一個新鍵 “url-list” 。該鍵將引用一個或多個 URL 地址列表，并包含可以檢索種子數(shù)據(jù)的網(wǎng)址列表。如果客戶端無法使用此鍵，則可以安全地忽略它。

例：

? ? ?d 8:announce27:http:tracker.com/announce ? ? ?8:url-list26:http:mirror.com/file.exe ? ? ?4:info…

如果 “url-list” URL 以斜杠 “/” 結尾，則客戶端必須添加種子文件名來生成完整的 URL 。這樣可以讓?.torrent?生成器將此字段同等對待單文件和多文件種子。

多文件種子

在下載多文件種子時，BitTorrent 客戶端通常會使用種子文件中 “info” 部分中的 “name” 字段作為根目錄，并使用 “path/file” 字段來指定在該根目錄下的文件路徑和名稱。但是，在這個例子中，種子文件的 “url-list” 字段被用作根目錄，因此客戶端需要將 “name” 和 “path/file” 添加到該根目錄中，以創(chuàng)建請求的 URL 。

例如，

... 8:url-list22:http://mirror.com/pub/ 4:infod5:filesld6:lengthi949e4:pathl10:Readme.txte e4:name7:michael

在這個例子中，客戶端需要將 “name” 設置為 “michael”，并將 “path/file” 中的 “Readme.txt” 文件添加到 http://mirror.com/pub/ 根目錄中，以生成下載請求的 URL ?？蛻舳藢⑹褂蒙鲜霾襟E生成的根目錄、文件路徑和文件名稱，將它們拼接起來，生成一個完整的下載請求 URL：http://mirror.com/pub/michael/Readme.txt 。

客戶端實現(xiàn)概述

首先，客戶端應該忽略它不認識的協(xié)議，因為如果嘗試連接這樣的協(xié)議可能會導致錯誤。例如，一個客戶端可能只支持 HTTP 而不支持 FTP，或者反過來。

其次，HTTP 和 FTP 協(xié)議都是流式傳輸?shù)膮f(xié)議，而沒有 BitTorrent 中所謂的數(shù)據(jù)塊的概念。這意味著當使用 HTTP 或 FTP 下載時，會出現(xiàn)很多數(shù)據(jù)空隙，因為無法像 BitTorrent 那樣對文件進行分塊下載。

為了解決這個問題，對實現(xiàn)中的 “最稀缺優(yōu)先” 塊選擇方法進行了修改，使得下載的文件中存在更多的數(shù)據(jù)空隙，這樣 HTTP 和 FTP 線程就可以從這些空隙開始下載，直到填滿整個空隙?？梢允褂?HTTP 的字節(jié)范圍請求功能來請求單個塊，但這可能會被服務器記錄下來，并被誤認為是針對該服務器的 DoS 攻擊。

客戶端實現(xiàn)注意事項

為了讓 HTTP 和 FTP 連接更好地填充文件中的很多連續(xù)塊，BitTorrent 的標準算法進行了一些更改。

空隙的定義

空隙指的是客戶端沒有的多個相鄰塊所組成的空間。在這個例子中，假設有一個位域”YYnnnnYnnY”，其中 Y 表示客戶端擁有的塊，n 表示客戶端沒有的塊。那么，在該位域中就存在兩個空隙，分別是長度為 4 和長度為 2 的相鄰未下載的塊組成的空間。

下載塊的選擇

最主要的變化是下載塊的選擇，如果所有缺失塊的稀有度相似，那么在請求一個塊時，最好從長度為 2 的間隙中選擇一個塊開始下載。而在任何間隙中，最好從結尾開始填充 (即優(yōu)先選擇最高編號的塊) 。因此，在給定的位域 “YYnnnnYnnY” 中，如果缺失塊的稀有度相似，則最好選擇 “# pieces YYnnnnY##Y” 中的一個塊進行下載，其中最佳的選擇是選擇塊 “$ YYnnnnYn$Y” 。

這些塊選擇策略可以最大程度地利用 HTTP/FTP 連接的連續(xù)數(shù)據(jù)下載。這樣，HTTP/FTP 連接可以從間隔的開頭開始下載，并在連接到客戶端已有的塊之前盡可能多地下載數(shù)據(jù)。

更改塊選取策略

將下載塊選取策略從原來的 “先選最稀有的” 修改為 “優(yōu)先選取與已完成塊距離最遠且相對稀有的” 。

最罕見且最大間隔的塊

首先找到當前所有未下載塊中出現(xiàn)頻率最少的塊，即 PRWBG（Pretty Rare With Biggest Gap –?最罕見且最大間隔的塊），假設它距離已經(jīng)下載完成的另一塊的距離為 D 。

對于其他未下載塊，如果它們與已下載塊的距離小于 D，則認為它們比 PRWBG 更罕見，因此被標記為 “ 罕見-X”（其中 X 是一個常數(shù)，等于 “對等方數(shù)量減 1 的平方根”）。

相反地，如果某個未下載塊與已下載塊之間的距離大于 D，則認為它可能比 PRWBG 更容易獲得，并被標記為 “ 罕見+X”，以備可能選擇作為下一個下載塊。

如果當前最稀有的一塊只有 3 個節(jié)點擁有，那么通常的算法會選擇另外兩個節(jié)點也有的拼。但是，如果使用修改后的算法，當一塊距離完整文件的距離小于當前最稀有塊的間隔時，只需要有 1 個節(jié)點擁有這一塊即可選擇它。

如果間隔更大且該塊的 “稀有程度” 與通常的 “稀有-1” 相同，那么將選擇這一塊（因此，如果間隔更大，則會選擇具有 2 或 3 個節(jié)點擁有的塊）。

因此，在給定的”YYnnn1Yn2Y” 情況下，除非 1 比 2 更稀有，否則最好選擇 2 。

偽代碼邏輯：

? ? ?X = sqrt(Peers) - 1; ? ? ?Gap = 0; ? ? ?CurGap = 0; ? ? ?CurRarest = MaxPieces+1; ? ? ?for (i=0; i<MaxPieces; i++) { ? ? ? ? ?if (IDoNotHavePiece(i)) { ? ? ? ? ? ? ?Gap++; ? ? ? ? ? ? ?if (PeerHasPiece(i)) { ? ? ? ? ? ? ? ? ?PieceRareness = NumberOfPeersWithThePiece(); ? ? ? ? ? ? ? ? ?if (PieceRareness<(CurRarest-X) || ? ? ? ? ? ? ? ? ? ? ?(PieceRareness<=(CurRarest+X) && Gap>CurGap)) { ? ? ? ? ? ? ? ? ? ? ?CurRarest = PieceRareness; ? ? ? ? ? ? ? ? ? ? ?CurGap = Gap; ? ? ? ? ? ? ? ? ? ? ?NextPiece = i; ? ? ? ? ? ? ? ? ?} ? ? ? ? ? ? ?} ? ? ? ? ?} else { ? ? ? ? ? ? ?Gap = 0; ? ? ? ? ?} ? ? ?}

填補空隙

當一個文件已經(jīng)完成了 50% 以上時，使用不同的方法隨機選擇下載塊。（在 50% 以上，你應該有大量其他節(jié)點想要下載的塊。）

每隔幾個塊，它會選擇距離完整文件最近的塊，忽略所有的稀有度。例如，在位域 “YYnnnnYnnY” 中，它將選擇塊 #”YYnnnnYn#Y” 。這有助于填補小缺口。

客戶端可以選擇是否執(zhí)行此步驟，如果實現(xiàn)此功能，還可以使用另一個文件完成百分比。

偽代碼邏輯：

? ? ?Gap = 0; ? ? ?Piece = -1; ? ? ?CurGap = MaxPieces+1; ? ? ?for (i=0; i<MaxPieces; i++) { ? ? ? ? ?if (IDoNotHavePiece(i)) { ? ? ? ? ? ? ?Gap++; ? ? ? ? ? ? ?if (PeerHasPiece(i)) { ? ? ? ? ? ? ? ? ?Piece = i; ? ? ? ? ? ? ?} ? ? ? ? ?} else {---- ? ? ? ? ? ? ?if (Gap<CurGap && Gap>0 && Piece!=-1) { ? ? ? ? ? ? ? ? ?CurGap = Gap; ? ? ? ? ? ? ? ? ?NextPiece = Piece; ? ? ? ? ? ? ?} ? ? ? ? ? ? ?Gap = 0; ? ? ? ? ? ? ?Piece = -1; ? ? ? ? ?} ? ? ?}

HTTP 和 FTP 優(yōu)化

對于 HTTP/FTP 協(xié)議或服務器本身無需進行修改。

如果客戶端知道 HTTP/FTP 下載是 BitTorrent 下載的一部分，則最好在第一次連接時隨機選擇文件中的某個位置開始下載。這樣，它獲得的第一批 HTTP 數(shù)據(jù)塊更有可能對 BitTorrent 節(jié)點進行共享。

如果在啟動 HTTP/FTP 連接時已經(jīng)存在一個正在進行的 BitTorrent 下載，則 HTTP/FTP 應從最大空隙的開頭開始。對于位域 “YYnnnnYnnY”，它應該從＃號開始：“YY＃nnnYnnY” 。

如果成功從 HTTP/FTP 服務器下載了一塊數(shù)據(jù)塊，但 SHA 校驗和不匹配，則必須關閉連接并丟棄該 URL 。

如果客戶端收到 “忙” 回復，則無需放棄 HTTP 或 FTP 服務器的 URL 。

多文件種子

當使用 HTTP/FTP 服務器進行多文件種子下載時，需要額外的選擇算法來優(yōu)化下載效率。

對于大型文件，客戶端可以選擇 BitTorrent 塊以優(yōu)化下載速度，從而能夠從 HTTP/FTP 服務器完整地下載整個文件。

對于包含小文件的種子，可能需要進行多個 HTTP/FTP 傳輸才能完成一個塊的下載。在這種情況下，使用 BitTorrent 進行傳輸可能更為合適。例如，如果有 100 個 1KB 的文件，假設塊大小為 32KB，則需要進行 100 個 HTTP/FTP 傳輸才能完成文件的下載，但只需要 4 個 BitTorrent 塊請求。

因此，將小文件給予 BitTorrent 塊選擇更高的優(yōu)先級，將大文件給予 HTTP/FTP 更高的優(yōu)先級，可以有效提高下載效率。

另一種可能的客戶端實現(xiàn)

如果客戶端只支持 HTTP 而不支持 FTP，則可以利用 HTTP 的字節(jié)范圍請求功能，但每次請求多個塊。

將多個塊視為單個集合，并向 HTTP 服務器發(fā)送單個字節(jié)范圍請求。這將減少 HTTP 連接的數(shù)量，并且對于客戶端可能會有很好的效果。

可以將塊視為 10 、 50 或 100 個塊。如果按照這種方式進行處理，”Pieces Per Block” 可以選擇為 MaxPieces/20，因此每次請求約為文件的 5% 。

不建議的客戶端實現(xiàn)

客戶端可以簡單地使用 HTTP 字節(jié)范圍請求來請求單個片段。但是，一些服務器管理員可能不會喜歡這種實現(xiàn)方式，因為針對單個文件將會在他們的日志中產(chǎn)生數(shù)百或數(shù)千個請求。有些人甚至可能認為這是對他們的拒絕服務攻擊。

其他協(xié)議內(nèi)容

可能用于下載數(shù)據(jù)的協(xié)議。盡管在上文中列出了 HTTP/FTP 作為用于種子分享的協(xié)議，但是客戶端可以使用任何允許下載數(shù)據(jù)的協(xié)議。例如 HTTPS 、 FTPS 或 SFTP 等協(xié)議也可以被使用，但可能不是所有客戶端都支持。

RTSP 和 MMS 等協(xié)議也有可能被使用。甚至還可以使用 Usenet 的 NNTP 協(xié)議進行下載。

其他協(xié)議可能存在其他問題，例如不允許從文件的任意位置開始下載。

客戶端可以選擇僅實現(xiàn) HTTP 或 FTP 協(xié)議中的一個而不是兩者同時實現(xiàn)。

參考鏈接

• http://www.bittorrent.org/beps/bep_0019.html