摘要
通過在下載過程中使用 HTTP 或 FTP 服務器向節(jié)點發(fā)送額外的數據來增加下載速度袖瞻，從而減少 BitTorrent 下載中可能出現的下載停滯情況奏赘。
原理
很多提供 BitTorrent 下載鏈接的網站也會同時提供相同文件的 HTTP 或 FTP URL 痴奏。這些 URL 所指向的文件是完全相同的翎嫡。利用 WebSeeding 技術的 BitTorrent 客戶端可以從任意一種來源（即 BitTorrent 和 HTTP 或 FTP）下載文件请敦，將下載到的數據塊組裝成為一個完整的文件料祠。 HTTP 或 FTP 服務器充當著一個始終處于未限速狀態(tài)的 "種子"秃嗜，即它可以不間斷地提供文件的數據塊权均，以加速文件的下載。
優(yōu)勢
每個 BitTorrent 下載都有一些開放下載端口的源锅锨，也就是種子叽赊，任何人都可以從這些源開始下載。
對于不能識別元數據添加的客戶端必搞，這種新方法不會破壞或更改任何內容必指。
不支持 HTTP/FTP 種子的 BitTorrent 客戶端仍然可以通過其他支持 HTTP/FTP 的同伴來共享數據塊。
無需更改元數據恕洲。下載管理工具通乘穑可以為一個文件添加多個 HTTP/FTP 鏡像網址，用戶只需單擊網頁上多個鏈接并識別相同的文件名即可霜第。
大家對 HTTP/FTP 服務器及其協(xié)議非常熟悉葛家。
這種新方法已經在多個 BitTorrent 客戶端中實現，如 IMFile 泌类、 GetRight 癞谒、 Mainline 、 uTorrent 刃榨、 Azureus 和 libTorrent 弹砚。
只需要在 BitTorrent 客戶端中進行少量更改，并且不需要更改 Tracker 喇澡、 HTTP 或 FTP 服務器迅栅。在 HTTP 或 FTP 服務器上也不需要使用腳本。
由于許多常見的客戶端已經支持此功能（特別是 IMFile 客戶端）晴玖，因此使用公司或個人現有的 HTTP/FTP 服務器完全可以進行 BitTorrent 下載的種子發(fā)布读存。
元數據擴展
在 BitTorrent 元數據文件的主要區(qū)域中，而不是 "info" 部分的一部分呕屎，將會有一個新鍵 "url-list" 让簿。該鍵將引用一個或多個 URL 地址列表，并包含可以檢索種子數據的網址列表秀睛。如果客戶端無法使用此鍵尔当，則可以安全地忽略它。
例：
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 【莨客戶端將使用上述步驟生成的根目錄惋砂、文件路徑和文件名稱妒挎，將它們拼接起來绳锅，生成一個完整的下載請求 URL：http://mirror.com/pub/michael/Readme.txt 。
客戶端實現概述
首先酝掩，客戶端應該忽略它不認識的協(xié)議鳞芙，因為如果嘗試連接這樣的協(xié)議可能會導致錯誤。例如期虾，一個客戶端可能只支持 HTTP 而不支持 FTP原朝，或者反過來。
其次镶苞，HTTP 和 FTP 協(xié)議都是流式傳輸的協(xié)議喳坠，而沒有 BitTorrent 中所謂的數據塊的概念。這意味著當使用 HTTP 或 FTP 下載時茂蚓，會出現很多數據空隙壕鹉，因為無法像 BitTorrent 那樣對文件進行分塊下載。
為了解決這個問題聋涨，對實現中的 "最稀缺優(yōu)先" 塊選擇方法進行了修改晾浴，使得下載的文件中存在更多的數據空隙，這樣 HTTP 和 FTP 線程就可以從這些空隙開始下載牍白，直到填滿整個空隙脊凰。可以使用 HTTP 的字節(jié)范圍請求功能來請求單個塊茂腥，但這可能會被服務器記錄下來狸涌，并被誤認為是針對該服務器的 DoS 攻擊切省。
客戶端實現注意事項
為了讓 HTTP 和 FTP 連接更好地填充文件中的很多連續(xù)塊，BitTorrent 的標準算法進行了一些更改帕胆。
空隙的定義
空隙指的是客戶端沒有的多個相鄰塊所組成的空間数尿。在這個例子中，假設有一個位域"YYnnnnYnnY"惶楼，其中 Y 表示客戶端擁有的塊右蹦，n 表示客戶端沒有的塊。那么歼捐，在該位域中就存在兩個空隙何陆，分別是長度為 4 和長度為 2 的相鄰未下載的塊組成的空間。
下載塊的選擇
最主要的變化是下載塊的選擇豹储，如果所有缺失塊的稀有度相似贷盲，那么在請求一個塊時，最好從長度為 2 的間隙中選擇一個塊開始下載剥扣。而在任何間隙中巩剖，最好從結尾開始填充 (即優(yōu)先選擇最高編號的塊) 。因此钠怯，在給定的位域 "YYnnnnYnnY" 中佳魔，如果缺失塊的稀有度相似，則最好選擇 "# pieces YYnnnnY##Y" 中的一個塊進行下載晦炊，其中最佳的選擇是選擇塊 "Y" 鞠鲜。
這些塊選擇策略可以最大程度地利用 HTTP/FTP 連接的連續(xù)數據下載。這樣断国，HTTP/FTP 連接可以從間隔的開頭開始下載贤姆，并在連接到客戶端已有的塊之前盡可能多地下載數據。
更改塊選取策略
將下載塊選取策略從原來的 "先選最稀有的" 修改為 "優(yōu)先選取與已完成塊距離最遠且相對稀有的" 稳衬。
最罕見且最大間隔的塊
首先找到當前所有未下載塊中出現頻率最少的塊霞捡，即 PRWBG（Pretty Rare With Biggest Gap?-?最罕見且最大間隔的塊），假設它距離已經下載完成的另一塊的距離為 D 薄疚。
對于其他未下載塊碧信，如果它們與已下載塊的距離小于 D，則認為它們比 PRWBG 更罕見输涕，因此被標記為 " 罕見-X"（其中 X 是一個常數音婶，等于 "對等方數量減 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;
}
}
填補空隙
當一個文件已經完成了 50% 以上時睛藻，使用不同的方法隨機選擇下載塊启上。（在 50% 以上，你應該有大量其他節(jié)點想要下載的塊店印。）
每隔幾個塊冈在，它會選擇距離完整文件最近的塊，忽略所有的稀有度吱窝。例如讥邻，在位域 "YYnnnnYnnY" 中迫靖，它將選擇塊 #"YYnnnnYn#Y" 院峡。這有助于填補小缺口。
客戶端可以選擇是否執(zhí)行此步驟系宜，如果實現此功能照激，還可以使用另一個文件完成百分比。
偽代碼邏輯：
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 數據塊更有可能對 BitTorrent 節(jié)點進行共享口柳。
如果在啟動 HTTP/FTP 連接時已經存在一個正在進行的 BitTorrent 下載，則 HTTP/FTP 應從最大空隙的開頭開始有滑。對于位域 "YYnnnnYnnY"跃闹，它應該從＃號開始："YY＃nnnYnnY" 。
如果成功從 HTTP/FTP 服務器下載了一塊數據塊，但 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)先級，可以有效提高下載效率右遭。
另一種可能的客戶端實現
如果客戶端只支持 HTTP 而不支持 FTP做盅，則可以利用 HTTP 的字節(jié)范圍請求功能，但每次請求多個塊窘哈。
將多個塊視為單個集合吹榴，并向 HTTP 服務器發(fā)送單個字節(jié)范圍請求。這將減少 HTTP 連接的數量滚婉，并且對于客戶端可能會有很好的效果图筹。
可以將塊視為 10 、 50 或 100 個塊让腹。如果按照這種方式進行處理远剩，"Pieces Per Block" 可以選擇為 MaxPieces/20，因此每次請求約為文件的 5% 骇窍。
不建議的客戶端實現
客戶端可以簡單地使用 HTTP 字節(jié)范圍請求來請求單個片段瓜晤。但是，一些服務器管理員可能不會喜歡這種實現方式腹纳，因為針對單個文件將會在他們的日志中產生數百或數千個請求痢掠。有些人甚至可能認為這是對他們的拒絕服務攻擊哈恰。
其他協(xié)議內容
可能用于下載數據的協(xié)議。盡管在上文中列出了 HTTP/FTP 作為用于種子分享的協(xié)議志群，但是客戶端可以使用任何允許下載數據的協(xié)議着绷。例如 HTTPS 、 FTPS 或 SFTP 等協(xié)議也可以被使用锌云，但可能不是所有客戶端都支持荠医。
RTSP 和 MMS 等協(xié)議也有可能被使用。甚至還可以使用 Usenet 的 NNTP 協(xié)議進行下載桑涎。
其他協(xié)議可能存在其他問題彬向，例如不允許從文件的任意位置開始下載。
客戶端可以選擇僅實現 HTTP 或 FTP 協(xié)議中的一個而不是兩者同時實現攻冷。
