摘要#
透過在下載過程中使用 HTTP 或 FTP 伺服器向節點發送額外的數據來增加下載速度，從而減少 BitTorrent 下載中可能出現的下載停滯情況。
原理#
很多提供 BitTorrent 下載鏈接的網站也會同時提供相同文件的 HTTP 或 FTP URL。這些 URL 所指向的文件是完全相同的。利用 WebSeeding 技術的 BitTorrent 客戶端可以從任意一種來源（即 BitTorrent 和 HTTP 或 FTP）下載文件，將下載到的數據塊組裝成一個完整的文件。 HTTP 或 FTP 伺服器充當著一個始終處於未限速狀態的 "種子"，即它可以不間斷地提供文件的數據塊，以加速文件的下載。
優勢#
每個 BitTorrent 下載都有一些開放下載端口的源，也就是種子，任何人都可以從這些源開始下載。
對於不能識別元數據添加的客戶端，這種新方法不會破壞或更改任何內容。
不支持 HTTP/FTP 種子的 BitTorrent 客戶端仍然可以通過其他支持 HTTP/FTP 的同伴來共享數據塊。
無需更改元數據。下載管理工具通常可以為一個文件添加多個 HTTP/FTP 鏡像網址，用戶只需單擊網頁上多個鏈接並識別相同的文件名即可。
大家對 HTTP/FTP 伺服器及其協議非常熟悉。
這種新方法已經在多個 BitTorrent 客戶端中實現，如 IMFile、GetRight、Mainline、uTorrent、Azureus 和 libTorrent。
只需要在 BitTorrent 客戶端中進行少量更改，並且不需要更改 Tracker、HTTP 或 FTP 伺服器。在 HTTP 或 FTP 伺服器上也不需要使用腳本。
由於許多常見的客戶端已經支持此功能（特別是 IMFile 客戶端），因此使用公司或個人現有的 HTTP/FTP 伺服器完全可以進行 BitTorrent 下載的種子發布。
元數據擴展#
在 BitTorrent 元數據文件的主要區域中，而不是 "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" 添加到該根目錄中，以創建請求的 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。
客戶端實現概述#
首先，客戶端應該忽略它不認識的協議，因為如果嘗試連接這樣的協議可能會導致錯誤。例如，一個客戶端可能只支持 HTTP 而不支持 FTP，或者反過來。
其次，HTTP 和 FTP 協議都是流式傳輸的協議，而沒有 BitTorrent 中所謂的數據塊的概念。這意味著當使用 HTTP 或 FTP 下載時，會出現很多數據空隙，因為無法像 BitTorrent 那樣對文件進行分塊下載。
為了解決這個問題，對實現中的 "最稀缺優先" 塊選擇方法進行了修改，使得下載的文件中存在更多的數據空隙，這樣 HTTP 和 FTP 線程就可以從這些空隙開始下載，直到填滿整個空隙。可以使用 HTTP 的字節範圍請求功能來請求單個塊，但這可能會被伺服器記錄下來，並被誤認為是針對該伺服器的 DoS 攻擊。
客戶端實現注意事項#
為了讓 HTTP 和 FTP 連接更好地填充文件中的很多連續塊，BitTorrent 的標準算法進行了一些更改。
空隙的定義#
空隙指的是客戶端沒有的多個相鄰塊所組成的空間。在這個例子中，假設有一個位域 "YYnnnnYnnY"，其中 Y 表示客戶端擁有的塊，n 表示客戶端沒有的塊。那麼，在該位域中就存在兩個空隙，分別是長度為 4 和長度為 2 的相鄰未下載的塊組成的空間。
下載塊的選擇#
最主要的變化是下載塊的選擇，如果所有缺失塊的稀有度相似，那麼在請求一個塊時，最好從長度為 2 的間隙中選擇一個塊開始下載。而在任何間隙中，最好從結尾開始填充（即優先選擇最高編號的塊）。因此，在給定的位域 "YYnnnnYnnY" 中，如果缺失塊的稀有度相似，則最好選擇 "# pieces YYnnnnY##Y" 中的某個塊進行下載，其中最佳的選擇是選擇塊 "$ YYnnnnYn$Y"。
這些塊選擇策略可以最大程度地利用 HTTP/FTP 連接的連續數據下載。這樣，HTTP/FTP 連接可以從間隔的開頭開始下載，並在連接到客戶端已有的塊之前盡可能多地下載數據。
更改塊選取策略#
將下載塊選取策略從原來的 "先選最稀有的" 修改為 "優先選取與已完成塊距離最遠且相對稀有的"。
最罕見且最大間隔的塊#
首先找到當前所有未下載塊中出現頻率最少的塊，即 PRWBG（Pretty Rare With Biggest Gap - 最罕見且最大間隔的塊），假設它距離已經下載完成的另一塊的距離為 D。
對於其他未下載塊，如果它們與已下載塊的距離小於 D，則認為它們比 PRWBG 更罕見，因此被標記為 "罕見 - X"（其中 X 是一個常數，等於 "對等方數量減 1 的平方根"）。
相反地，如果某個未下載塊與已下載塊之間的距離大於 D，則認為它可能比 PRWBG 更容易獲得，並被標記為 "罕見 + X"，以備可能選擇作為下一個下載塊。
如果當前最稀有的一塊只有 3 個節點擁有，那麼通常的算法會選擇另外兩個節點也有的拼。但是，如果使用修改後的算法，當一塊距離完整文件的距離小於當前最稀有塊的間隔時，只需要有 1 個節點擁有這一塊即可選擇它。
如果間隔更大且該塊的 "稀有程度" 與通常的 "稀有 - 1" 相同，那麼將選擇這一塊（因此，如果間隔更大，則會選擇具有 2 或 3 個節點擁有的塊）。
因此，在給定的 "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% 以上，你應該有大量其他節點想要下載的塊。）
每隔幾個塊，它會選擇距離完整文件最近的塊，忽略所有的稀有度。例如，在位域 "YYnnnnYnnY" 中，它將選擇塊 #"YYnnnnYn#Y"。這有助於填補小缺口。
客戶端可以選擇是否執行此步驟，如果實現此功能，還可以使用另一個文件完成百分比。
伪代码逻辑：
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 優化#
對於 HTTP/FTP 協議或伺服器本身無需進行修改。
如果客戶端知道 HTTP/FTP 下載是 BitTorrent 下載的一部分，則最好在第一次連接時隨機選擇文件中的某個位置開始下載。這樣，它獲得的第一批 HTTP 數據塊更有可能對 BitTorrent 節點進行共享。
如果在啟動 HTTP/FTP 連接時已經存在一個正在進行的 BitTorrent 下載，則 HTTP/FTP 應從最大空隙的開頭開始。對於位域 "YYnnnnYnnY"，它應該從＃號開始："YY＃nnnYnnY"。
如果成功從 HTTP/FTP 伺服器下載了一塊數據塊，但 SHA 校驗和不匹配，則必須關閉連接並丟棄該 URL。
如果客戶端收到 "忙" 回覆，則無需放棄 HTTP 或 FTP 伺服器的 URL。
多文件種子#
當使用 HTTP/FTP 伺服器進行多文件種子下載時，需要額外的選擇算法來優化下載效率。
對於大型文件，客戶端可以選擇 BitTorrent 塊以優化下載速度，從而能夠從 HTTP/FTP 伺服器完整地下載整個文件。
對於包含小文件的種子，可能需要進行多個 HTTP/FTP 傳輸才能完成一個塊的下載。在這種情況下，使用 BitTorrent 進行傳輸可能更為合適。例如，如果有 100 個 1KB 的文件，假設塊大小為 32KB，則需要進行 100 個 HTTP/FTP 傳輸才能完成文件的下載，但只需要 4 個 BitTorrent 塊請求。
因此，將小文件給予 BitTorrent 塊選擇更高的優先級，將大文件給予 HTTP/FTP 更高的優先級，可以有效提高下載效率。
另一種可能的客戶端實現#
如果客戶端只支持 HTTP 而不支持 FTP，則可以利用 HTTP 的字節範圍請求功能，但每次請求多個塊。
將多個塊視為單個集合，並向 HTTP 伺服器發送單個字節範圍請求。這將減少 HTTP 連接的數量，並且對於客戶端可能會有很好的效果。
可以將塊視為 10、50 或 100 個塊。如果按照這種方式進行處理，"Pieces Per Block" 可以選擇為 MaxPieces/20，因此每次請求約為文件的 5%。
不建議的客戶端實現#
客戶端可以簡單地使用 HTTP 字節範圍請求來請求單個片段。但是，一些伺服器管理員可能不會喜歡這種實現方式，因為針對單個文件將會在他們的日誌中產生數百或數千個請求。有些人甚至可能認為這是對他們的拒絕服務攻擊。
其他協議內容#
可能用於下載數據的協議。儘管在上文中列出了 HTTP/FTP 作為用於種子分享的協議，但是客戶端可以使用任何允許下載數據的協議。例如 HTTPS、FTPS 或 SFTP 等協議也可以被使用，但可能不是所有客戶端都支持。
RTSP 和 MMS 等協議也有可能被使用。甚至還可以使用 Usenet 的 NNTP 協議進行下載。
其他協議可能存在其他問題，例如不允許從文件的任意位置開始下載。
客戶端可以選擇僅實現 HTTP 或 FTP 協議中的一個而不是兩者同時實現。