此規(guī)范的目的是詳細(xì)介紹 BitTorrent 協(xié)議規(guī)范 v1.0 。Bram 的協(xié)議規(guī)范網(wǎng)站 http://www.bittorrent.com/protocol.html 簡(jiǎn)要地?cái)⑹隽舜藚f(xié)議，在部分范圍缺少詳細(xì)行為闡述。希望此文檔能成為 一個(gè)正式的規(guī)范，明確的條款，將來能作為討論和執(zhí)行的基礎(chǔ)。
此文檔規(guī)定由 BitTorrent 開發(fā)者維持和使用。歡迎大家為它做貢獻(xiàn)，其中的內(nèi)容代表當(dāng)前協(xié)議，它仍由許多客戶使用。
這里不是提出特性請(qǐng)求的地方。如果有請(qǐng)求，請(qǐng)見郵箱列表。
本文檔適用于 BitTorrent 協(xié)議規(guī)范的第一版(v1.0)。目前，這份文檔應(yīng)用于 torrent 文件結(jié)構(gòu)、用戶線路協(xié)議和服務(wù)器（Tracker） HTTP/HTTPS 協(xié)議規(guī)范。如果某個(gè)協(xié)議的修改有了新的定義，它們會(huì)被指定在協(xié)議相應(yīng)的頁(yè)面，而不在這里。
在本文檔中，使用了許多約定來簡(jiǎn)明和明確地表達(dá)信息。
為了幫助其他人找到本文檔最近的修改，請(qǐng)?zhí)顚懜淖內(nèi)罩荆ㄗ詈笠欢危?。它?yīng)包含一個(gè)簡(jiǎn)短的項(xiàng)目（如：一行），用來記錄你每次對(duì)此文檔的主要改動(dòng)。
B編碼是一種以簡(jiǎn)潔格式指定和組織數(shù)據(jù)的方法。支持下列類型：字節(jié)串、整數(shù)、表和字典。
字節(jié)串按如下編碼：<以十進(jìn)制 ASCII 編碼的串長(zhǎng)度>：<串?dāng)?shù)據(jù)>
注意沒有開始和結(jié)束的分隔符。 例：“4：spam” 代表字符串“spam”
整數(shù)按如下編碼：i<以十進(jìn)制 ASCII 編碼的整數(shù)>e
開始的“i”與結(jié)尾的“e”分別是開始和結(jié)束分隔符?？梢允褂萌?#8220;i-3e”之類的負(fù)數(shù)。但不能把“0”放到數(shù)字的前面，如“i04e”。另外，“i0e”是有效的。
例：“i3e”代表整數(shù)“3”
表按如下編碼：l<編碼值>e
開始的“l”與結(jié)尾的“e”分別是開始和結(jié)束分隔符。 表可以包含任何已編碼的類型，包括整數(shù)、串、字典和其他的表。
例：l4:span4:eggse 代表兩個(gè)串的表“spam”、“eggs”
字典按如下編碼：d<編碼串><編碼元素>e
開始的“d”與結(jié)尾的“e”分別是開始和結(jié)束分隔符。 注意關(guān)鍵字必須被編碼為串。值可以是任何已編碼類型，包括整數(shù)、串、表和其他字典。關(guān)鍵字必須是串，以分類的順序出現(xiàn)（以原始串排列，而不是以字母數(shù)字）
例1：d3:cow3:moo4:spam4:eggse 代表字典 { "cow" => "moo", "spam" => "eggs" }
例2：d4:spaml1:a1:bee 代表字典 { "spam" => ["a", "b"] }
所有在元信息文件中的數(shù)據(jù)都要編碼。編碼規(guī)則如上所述。
元信息文件（以 .torrent 結(jié)尾的文件）的內(nèi)容是一個(gè)編碼的字典，包含以下列表中的各項(xiàng)。所有字符串值都以 UTF-8 編碼。標(biāo)記沒有為“可選”的鍵值是必需的字段：
一個(gè)描述 torrent 文件的字典。有兩種可能的形式：一種是沒有目錄結(jié)構(gòu)的“單一文件”，另一種是包含子目錄樹的“多文件”
對(duì)于“單一文件”來說，信息字典包含以下的結(jié)構(gòu)：
長(zhǎng)度: 文件字節(jié)數(shù)長(zhǎng)度（整數(shù)）
md5和: （可選）一個(gè) 32 位的 16 進(jìn)制字符串，它對(duì)應(yīng)于文件的 MD5和。不被 BitTorrent 所使用，但被一些程序包含，以提供更大的兼容性。
名稱: 文件的名稱。建議使用（字節(jié)串）。
片斷長(zhǎng)度: 每個(gè)片斷的字節(jié)數(shù)（整數(shù)）。
片斷: 包含所有 20 字節(jié) SHA-1 散列值的字符串，每個(gè)片斷都有唯一的值。（字節(jié)串）
對(duì)于“多文件”來說，信息字典包含以下的結(jié)構(gòu)：
文件：字典列表，每個(gè)文件都有一個(gè)。每個(gè)在表中的字典包含以下鍵值：
長(zhǎng)度：文件長(zhǎng)度的字節(jié)數(shù)（整數(shù)）
md5和: （可選）一個(gè) 32 位的 16 進(jìn)制字符串，它對(duì)應(yīng)于文件的 MD5和。不被 BitTorrent 所使用，但被一些程序包含，以提供更大的兼容性。
路徑：一個(gè)包含著一個(gè)或多個(gè)字符串元素的，它包含路徑和文件名。每個(gè)表中元素對(duì)應(yīng)于一個(gè)目錄名或（在最后的元素的情況下）文件名。
例：文件名“dir1/dir2/file.ext”將包含三種串元素：“dir1”、“dir2”和“file.ext”。編碼為串表的例子“l4:dir14:dir28:file.exte”
名稱：結(jié)構(gòu)中根目錄的名稱－－包含上述文件列表中所有文件的目錄（字符串）
片斷長(zhǎng)度: 每個(gè)片斷的字節(jié)數(shù)（整數(shù)）。
片斷: 包含所有 20 字節(jié) SHA-1 散列值的字符串，每個(gè)片斷都有唯一的值。（字節(jié)串）
注意：
服務(wù)器是用類響應(yīng) HTTP GET 請(qǐng)求的一種 HTTP/HTTPS 服務(wù)。該請(qǐng)求包括客戶端的度量標(biāo)準(zhǔn)，這個(gè)標(biāo)準(zhǔn)可以幫助服務(wù)器全面統(tǒng)計(jì) torrent 文件?；镜?URL 包括元數(shù)據(jù)文件（torrent）中定義的“發(fā)布 URL”。再將那些參數(shù)通過標(biāo)準(zhǔn) CGI 方法添加到此 URL 中（如：“?”在發(fā)布 URL 之后，緊接著“參數(shù)=值”的序列，分隔符“&”）
注意所有在 URL 中的二進(jìn)制數(shù)據(jù)（特別是 info_hash 和 peer_id）必須使用轉(zhuǎn)義符。這意味著除 0-9，a-z，A-Z和$-_.+!*'()外，其余字節(jié)需要采用“%nn”格式的編碼，其中的“nn”是字節(jié)的 16 進(jìn)制數(shù)值。（詳細(xì)見 RFC1738）
客戶端向服務(wù)器的 GET 請(qǐng)求的參數(shù)如下：
服務(wù)器作出“text/plain”文檔的響應(yīng)包括以下編碼字典的關(guān)鍵字：
如上所述，用戶列表長(zhǎng)度默認(rèn)值為 50。如果連接的用戶少于該值，列表會(huì)更小。另外，服務(wù)器隨機(jī)選擇用戶及其響應(yīng)。服務(wù)器在響應(yīng)請(qǐng)求時(shí)可能使用一個(gè)更智能的機(jī)構(gòu)來選擇用戶。例如，應(yīng)避免向其他做種者報(bào)告種子。
在事件發(fā)生（即：已停止或已完成）或客戶端需要連接更多的用戶時(shí)，客戶端向服務(wù)器發(fā)送請(qǐng)求的間隔可以低于指定的時(shí)間間隔。但是，為了獲得更多的用戶而向服務(wù)器頻繁地請(qǐng)求會(huì)被認(rèn)為是錯(cuò)誤的行為。如果客戶端想在回應(yīng)中得到許多用戶，則需要在“需求數(shù)目”參數(shù)中設(shè)定。
使用者注意：30 個(gè)用戶就算豐富的源了，官方客戶端版本 3（v3）實(shí)際上在連接數(shù)少于 30 時(shí)會(huì)嘗試增加新的連接，當(dāng)連接數(shù)大于或等于 55 時(shí)會(huì)拒絕連接多余的用戶。這個(gè)值對(duì)性能很重要。當(dāng)完成下載一個(gè)新的片斷時(shí)，“已擁有”消息（見下面）將會(huì)發(fā)送到最活動(dòng)的用戶。結(jié)果廣播通信量與用戶數(shù)目成正比例增加。大于 25 時(shí)，新用戶不太可能會(huì)增加下載速度。有人強(qiáng)烈建議用戶界面設(shè)計(jì)者使該項(xiàng)模糊和很難修改，因?yàn)槟菢幼鰩缀鯖]有用。
根據(jù)慣例，多數(shù)服務(wù)器支持請(qǐng)求的另一種形式，這種方式詢問給定的服務(wù)器正在處理的 torrent （或所有的 torrent）。通常叫做“刮頁(yè)”，因?yàn)樗詣?dòng)處理“刮屏”（服務(wù)器統(tǒng)計(jì)頁(yè)）冗長(zhǎng)的部分。刮 URL 也是一種類似于上面描述的 HTTP GET 方法。但基本 URL 不同。用以下步驟來得到刮 URL：從發(fā)布 URL 開始尋找其中最后一個(gè)“/”。如果在文本之后的“/”不是“announce”，它將被作為一個(gè)符號(hào)，此符號(hào)不支持刮約定。如果是，則以“scrape”代替“announce”來找到刮頁(yè)。
例：(發(fā)布 URL -> 刮 URL)
http://example.com/announce -> http://example.com/scrape http://example.com/x/announce -> http://example.com/x/scrape http://example.com/announce.php -> http://example.com/scrape.php http://example.com/a -> (不支持刮) http://example.com/announce?x=2%0644 -> http://example.com/scrape?x=2%0644 http://example.com/announce?x=2/4 -> (不支持刮) http://example.com/x%064announce -> (不支持刮)
特別注意：結(jié)束引語(yǔ)沒有完成。此標(biāo)準(zhǔn)是由 Bram 在 BitTorrent 開發(fā)列表文件中說明的。
刮 URL 可以作為可選參數(shù)“info_hash”的一個(gè)補(bǔ)充，是一個(gè) 20 字節(jié)的值。這限制了服務(wù)器向特殊種子匯報(bào)。另外，服務(wù)器正在處理的所有種子的統(tǒng)計(jì)也被發(fā)回。為了降低服務(wù)器的負(fù)載和帶寬，有人強(qiáng)烈建議軟件作者盡可能使用“info_hash”參數(shù)。
HTTP GET 方法的響應(yīng)是一個(gè)由編碼字典組成的“text/plain”文檔，包括以下關(guān)鍵字：
注意此響應(yīng)有三層字典嵌套。例如：
d5:filesd20:....................d8:completei5e10:downloadedi50e10:incompletei10eeee
其中“....................”是 20 字節(jié)的 info_hash，以上表明有 5 個(gè)做種者，10 個(gè)吸血者和 50 個(gè)完成下載的用戶。
用戶線路協(xié)議使元信息文件中片斷的交換變得更容易。
注意原始規(guī)范在描述用戶協(xié)議時(shí)也使用術(shù)語(yǔ)“片斷”，但與元信息文件中的術(shù)語(yǔ)“片斷”不同。由于該原因，術(shù)語(yǔ)“塊”將在本規(guī)范中用來描述用戶之間通過線路交換的數(shù)據(jù)。
客戶端必須為每個(gè)遠(yuǎn)程用戶的連接保持狀態(tài)信息：
注意這也意味著客戶端需要記住自己是否對(duì)遠(yuǎn)程用戶感興趣和阻塞它。因此，真正的列表看起來像這樣：
客戶端的連接以“被阻塞”和“不感興趣”開始。也就是：
當(dāng)客戶端對(duì)遠(yuǎn)程用戶感興趣并且遠(yuǎn)程用戶未阻塞該客戶端時(shí)，客戶端開始下載塊。當(dāng)客戶端沒有阻塞遠(yuǎn)程用戶并且遠(yuǎn)程用戶對(duì)該客戶端感興趣時(shí)，客戶端開始上傳塊。
客戶端保持通知遠(yuǎn)程用戶自己是否對(duì)它們感興趣，這是很重要的。與每個(gè)遠(yuǎn)程用戶連接的狀態(tài)信息應(yīng)保持最新，直到該客戶端被阻塞。這允許遠(yuǎn)程用戶知道當(dāng)自己未阻塞時(shí)，客戶端是否會(huì)開始下載；反之亦然。
如果不特別指定，在用戶線路協(xié)議中的所有整數(shù)都會(huì)編碼成 4 字節(jié) big endian 值。這包括所有消息中的長(zhǎng)前綴，它在握手之后。
用戶線路協(xié)議包括初始握手。之后，用戶通過長(zhǎng)前綴消息的交換來進(jìn)行通信。長(zhǎng)前綴是上述的一個(gè)整數(shù)。
握手是必需的消息，它一定是由客戶端發(fā)送的第一條消息。
在 BitTorrent 協(xié)議 v1.0 中：pstrlen=19，pstr="BitTorrent protocol"
連接的發(fā)起者應(yīng)該立即發(fā)送彼此的握手信息。即使接收者能同時(shí)提供多個(gè) torrent（torrent 通過自己的 info_hash 來唯一標(biāo)識(shí)），它也應(yīng)等待發(fā)起者的握手信息。但是，接收者在看到握手的 info_hash 部分后必須迅速回應(yīng)。服務(wù)器的 NAT 檢查特性不會(huì)發(fā)送握手的 peer_id 字段。
如果客戶端收到一個(gè)當(dāng)前不能處理的握手 info_hash，該客戶端就會(huì)斷開那個(gè)連接。
如果連接的發(fā)起者收到一個(gè)握手信息，其中的 peer_id 與預(yù)期的不同，那么發(fā)起者就會(huì)斷開該連接。注意發(fā)起者可能會(huì)收到來自服務(wù)器的遠(yuǎn)程用戶信息，它包括遠(yuǎn)程用戶注冊(cè)的 peer_id。來自服務(wù)器的 peer_id 與握手信息中的應(yīng)該相同。
主要有兩種將客戶端及其版本信息編碼到 peer_id 的方法：Azureus 型和 Shadow 型。
Azureus 型使用如下編碼：“-”，一個(gè)客戶端標(biāo)識(shí)使用兩個(gè)字符，版本號(hào)用 4 個(gè) ASCII 數(shù)字表示，“-”緊跟在隨機(jī)數(shù)字之后。
例如：'-AZ2060-'...
已知采用這種方法編碼的客戶端是：
Shadow 型采用如下編碼：用 1 個(gè) ASCII 字母或數(shù)字標(biāo)識(shí)客戶端，3 個(gè) ASCII 數(shù)字標(biāo)識(shí)版本號(hào)，“----”緊跟在隨機(jī)數(shù)字之后。
例如：'S587----'...
已知采用此種類型編碼的客戶端為：
Bram 的客戶端現(xiàn)在采用的形式： 'M3-4-2--'
BitComet則不同。它的 peer_id 由四個(gè) ASCII 字符組成“exbc”，后面是兩個(gè)字節(jié)的“x”和“y”，之后才是隨機(jī)字符。版本號(hào)“x”是在小數(shù)點(diǎn)前的十進(jìn)制數(shù)值，“y”是小數(shù)點(diǎn)之后的兩個(gè)十進(jìn)制數(shù)值。BitLord 使用相同的結(jié)構(gòu)，但在版本號(hào)后添加“LORD”字符。一個(gè) BitComet 的非官方補(bǔ)丁將“exbc”替換成了“FUTB”。BitComet 用戶標(biāo)識(shí)的編碼在 0.59 及其以前的版本都采用的 Azureus 型。
XBT Client也有自己的風(fēng)格。其 peer_id 由三個(gè)大寫字母“XBT”緊跟三個(gè)代表版本號(hào)的 ASCII 數(shù)字。如果客戶端處在調(diào)試階段，第七字節(jié)則是小寫字母“d”，其他情況下是“-”。之后是“-”和隨機(jī)數(shù)字，大寫和小寫字母。例：'XBT054d-'表示 0.5.4 版的開始調(diào)試階段。
Opera 8 previews采用以下結(jié)構(gòu)：前面兩個(gè)字符“OP”緊跟四個(gè)相等的構(gòu)建號(hào)。之后所有字符都是隨機(jī)小寫 16 進(jìn)制的數(shù)字。
Bits on Wheels采用格式“-BOWAxx-yyyyyyyyyyyy”，其中“y”是隨機(jī)大寫字母，x 取決于版本。版本 1.0.6 中 xx＝0C。
許多客戶端使用隨機(jī)數(shù)字或 12 個(gè)〇緊跟著隨機(jī)數(shù)字（如以前舊版本的 Bram 客戶端）。
協(xié)議中所有發(fā)送的消息均采用“<長(zhǎng)前綴><消息標(biāo)識(shí)符><有效負(fù)載>”的形式。長(zhǎng)前綴是一個(gè) 4 字節(jié) big endian 值。消息標(biāo)識(shí)符是一個(gè)十進(jìn)制字符。有效負(fù)載是消息依賴的。
keep-alive: <len=0000>
“保持活動(dòng)”消息是由〇組成的字節(jié)串，將長(zhǎng)前綴設(shè)為〇可指定。沒有消息標(biāo)識(shí)符和有效負(fù)載。如果在一段時(shí)間內(nèi)，用戶沒有收到消息，它會(huì)斷開連接，所以需要發(fā)送活動(dòng)消息來維持連接。一條保持活動(dòng)消息大概每?jī)煞昼姲l(fā)送一次。
choke: <len=0001><id=0>
阻塞消息是定長(zhǎng)的，無有效負(fù)載。
unchoke: <len=0001><id=1>
未阻塞消息是定長(zhǎng)的，無有效負(fù)載。
interested: <len=0001><id=2>
感興趣消息是定長(zhǎng)的，無有效負(fù)載。
not interested: <len=0001><id=3>
不感興趣消息是定長(zhǎng)的，無有效負(fù)載。
have: <len=0005><id=4><piece index>
擁有消息是定長(zhǎng)的。有效負(fù)載是剛成功下載和通過散列值校驗(yàn)的〇基片段的索引。
使用者注意：這是嚴(yán)格的定義，實(shí)際上會(huì)用到某些游戲程序。特別地，因?yàn)橛脩魳O不可能下載已經(jīng)擁有的片斷，用戶可能不會(huì)選擇向另一個(gè)用戶宣布已擁有那個(gè)片斷的消息。少量“擁有抑制”會(huì)導(dǎo)致?lián)碛邢p少一半，在協(xié)議前面將轉(zhuǎn)化到 25-35%。
惡意用戶可能會(huì)選擇宣布擁有別人永遠(yuǎn)不會(huì)下載的片斷。因此，向普通用戶發(fā)送此信息是壞主意。
bitfield: <len=0001+X><id=5><bitfield>
位字段消息可能在握手序列發(fā)送完成后，在其他任何消息發(fā)送之前立即發(fā)送。它是可選的，如果客戶端沒有此片斷則不必發(fā)送。
位字段消息是變長(zhǎng)的，其中的“X”是位字段的長(zhǎng)度。有效負(fù)載是代表成功下載片斷的位字段。首字節(jié)的高位對(duì)應(yīng)片斷索引 0。已清除的位則指出缺少的片斷，通過一個(gè)有效可用的片斷來設(shè)置位。末位剩下的位設(shè)置為〇。
一個(gè)錯(cuò)誤長(zhǎng)度的位字段被認(rèn)為是錯(cuò)誤。客戶端在收到不正確大小的位字段或已有設(shè)置為剩下位的位字段時(shí)應(yīng)斷開連接。
request: <len=0013><id=6><索引><開始><長(zhǎng)度>
請(qǐng)求消息是定長(zhǎng)的，用來請(qǐng)求塊。有效負(fù)載包含以下信息：
索引：指定〇基片斷索引的整數(shù)。
開始：指定片斷內(nèi)〇基字節(jié)的偏移量整數(shù)。
長(zhǎng)度：指定被請(qǐng)求長(zhǎng)度的整數(shù)。
根據(jù)官方規(guī)范有關(guān)主要版本3，“所有當(dāng)前執(zhí)行應(yīng)使用 2^15（32 KB），請(qǐng)求數(shù)量大于 2^17 （128 KB）時(shí)應(yīng)斷開連接。”在主要版本4中，此反應(yīng)修改到了 2^14 （16 KB），超過該值的用戶會(huì)強(qiáng)迫拒絕。注意到塊請(qǐng)求小于片斷大?。?gt;=2^18 字節(jié)），所以為下載一個(gè)完整片斷需要多次請(qǐng)求。
由于新版本將限制定在 16 KB，嘗試使用 32 KB 的塊就好比用 4 發(fā)子彈來玩俄式輪盤－－會(huì)遇到困難。更小的請(qǐng)求會(huì)導(dǎo)致更大的系統(tǒng)時(shí)間和空間開銷，因?yàn)橐櫤芏嗾?qǐng)求。結(jié)果應(yīng)使用所有客戶端都允許的 16 KB。
請(qǐng)求塊大小的限制執(zhí)行的選擇沒有減少一部分清楚。在主要版本 4 中，強(qiáng)制使用 16 KB 的請(qǐng)求，許多客戶端會(huì)使用該值，只有一個(gè)嚴(yán)格客戶端組不會(huì)使用。大多數(shù)舊客戶端使用 32 KB 請(qǐng)求，不允許明顯減少可能用戶的批次。同時(shí) 16 KB 是現(xiàn)在部分官方的限制（“部分”是因?yàn)楣俜絽f(xié)議文檔沒有更新），所以強(qiáng)制使用沒有錯(cuò)。另外，允許更大的請(qǐng)求增大了可能用戶的批次，除在非常低的帶寬連接（小于 256 kbps）中，多個(gè)塊會(huì)在一個(gè)阻塞周期內(nèi)完成下載，從而強(qiáng)迫使用舊的限制僅會(huì)降低很少的性能。因此，推薦僅在舊的 128 KB 下才強(qiáng)行限制。
piece: <len=0009+X><id=7><索引><開始><塊>
片斷消息是變長(zhǎng)的，其中的“X”是塊長(zhǎng)度。有效負(fù)載包含以下信息：
索引：由〇基片斷索引指定的整數(shù)
開始：由片斷內(nèi)〇基字節(jié)偏移量指定的整數(shù)
塊：數(shù)據(jù)塊，是索引指定片斷的子集。
cancel: <len=0013><id=8><索引><開始><長(zhǎng)度>
取消信息是定長(zhǎng)的，用來取消塊的請(qǐng)求。有效負(fù)載與“請(qǐng)求”消息相同。典型用在“最后階段”中。（見下面的算法段）
port: <len=0003><id=9><listen-port>
端口消息是由運(yùn)行 DHT 服務(wù)器的新版本的主要部分。監(jiān)聽端口是用戶 DHT 節(jié)點(diǎn)正在監(jiān)聽的端口。如果 DHT 服務(wù)器支持，則應(yīng)把此用戶加入本地的路由表中。
通常建議用戶在每個(gè)連接上保持一些未完成的請(qǐng)求。因?yàn)閺囊粔K的下載到開始下載另一塊需要一個(gè)完全的往返程（往返程在片斷消息和下一個(gè)請(qǐng)求消息之間）。一旦與高 BDP （Bandwidth Delay Product，高延遲或帶寬）相連，會(huì)降低很多性能。官方客戶端未完成請(qǐng)求的默認(rèn)值是 5。
用戶注意：這是最嚴(yán)格的性能條款。一個(gè) 5 請(qǐng)求的靜態(tài)隊(duì)列對(duì)于具有 50 ms 延遲 5 Mbps 中的 32 KB 塊是合理的。連接更大的帶寬越來越常見，所以用戶界面設(shè)計(jì)者被催促使其對(duì)于改變更適用。特別地，線纜調(diào)制解調(diào)器以調(diào)整通信量和增加其可能緩和部分由此導(dǎo)致的問題，這是眾所周知的。
自動(dòng)調(diào)整：調(diào)整此參數(shù)的一個(gè)合理的方法是連續(xù)測(cè)量單個(gè)連接的帶寬。如果該用戶增加帶寬而隊(duì)列不夠，則嘗試增加隊(duì)列長(zhǎng)度。使用相同標(biāo)志如果減少隊(duì)列長(zhǎng)度沒有減少帶寬和延遲，可能是隊(duì)列長(zhǎng)度太大了。
（該項(xiàng)不是原始規(guī)范的一部分）
在 S-5.5 中的超級(jí)種子特性是一種新的做種算法，用來幫助只有有限帶寬的做種者發(fā)布很大的文件，減少為了產(chǎn)生新的種子而上傳的數(shù)據(jù)總量。
當(dāng)做種者使用“超級(jí)種子模式”時(shí)，它不會(huì)作為標(biāo)準(zhǔn)種子，而是偽裝成一個(gè)沒有數(shù)據(jù)的普通客戶端。當(dāng)客戶端連接時(shí)，它會(huì)通知它們自己收到一塊從未發(fā)送或源很少的片斷。這將促使客戶端僅嘗試下載那個(gè)片斷。
當(dāng)客戶端完成下載該片斷時(shí)，做種者看到它以前發(fā)送的片斷在其他用戶中至少有一個(gè)擁有后，才會(huì)繼續(xù)發(fā)送另外的片斷。在那之前，客戶端下載不到做種者的其他片斷，這樣不會(huì)浪費(fèi)做種者的帶寬。
這種方法會(huì)有更高的效率，同時(shí)促使用戶只下載源最少的數(shù)據(jù)，降低了多余數(shù)據(jù)的發(fā)送，限制了沒有為該群傳輸數(shù)據(jù)的用戶而發(fā)送的數(shù)據(jù)量。在這之前，做種者可能需要上傳文件總大小的 1.5 到 2 倍，其他用戶才可能成為種子。但是，使用超級(jí)種子模式的單個(gè)客戶端發(fā)布大的文件只需上傳文件大小的 1.05 倍就能成為種子。這是標(biāo)準(zhǔn)做種效率的 1.5 到 2 倍。
不推薦一般用戶采用超級(jí)種子模式。雖然它有助于稀少數(shù)據(jù)的擴(kuò)散，但是它限制了客戶端下載片斷的選擇，同時(shí)限制了客戶端下載自己已得到部分的片斷。所以，超級(jí)種子模式只推薦原始做種者使用。
綜上，“原始做種者模式”或“發(fā)布者模式”是更恰當(dāng)?shù)拿Q。
客戶端可以隨機(jī)順序下載片斷。
更好的方法是首先下載源最少的片斷。客戶端可以從每個(gè)其他用戶保存的原始位字段來決定，通過擁有消息來更新。然后，客戶端可以下載出現(xiàn)在其他用戶位字段中頻率最低的片斷。
下載接近完成時(shí)，最后幾塊的速度有變慢的趨勢(shì)。為了加速，客戶端向其他所有擁有自己缺少塊的用戶發(fā)送請(qǐng)求。為防止變成無效，客戶端在每個(gè)塊完成后就向其他用戶發(fā)送一個(gè)取消的消息。
沒有已定的界限，推薦百分比或能用來作為指導(dǎo)的塊計(jì)數(shù)。
何時(shí)進(jìn)入最后階段模式有待討論。一些客戶端以請(qǐng)求了所有塊來進(jìn)入最后階段。其他的等到剩余塊的數(shù)目少于傳輸中塊的數(shù)目或不超過 20 來進(jìn)入該階段。保持很少的等待塊（1 或 2 塊）來將允許值減到最少，如果隨機(jī)選擇塊的請(qǐng)求，可能會(huì)重復(fù)下載到已有的塊。更多的協(xié)議說明見：http://hal.inria.fr/inria-00000156/en
阻塞有幾種原因。TCP 擁塞控制在同時(shí)發(fā)出許多連接時(shí)表現(xiàn)很差。同時(shí)，阻塞使每個(gè)用戶使用 tit-for-tat-ish 算法來確定自己得到一致的下載速度。
下面描述的阻塞算法是現(xiàn)在使用的。所有新算法同時(shí)在整個(gè)包括它們的網(wǎng)絡(luò)中工作正常，這是很重要的。
一個(gè)好的阻塞算法應(yīng)有幾個(gè)標(biāo)準(zhǔn)。它應(yīng)為更高的 TCP 性能改進(jìn)并發(fā)上傳數(shù)。它應(yīng)避免被叫做“原纖化作用”的快速阻塞和未阻塞。它應(yīng)互換到讓自己下載的用戶。最后，它應(yīng)偶爾測(cè)試未使用連接來發(fā)現(xiàn)是否比當(dāng)前使用的更好，這叫做最佳暢通。
當(dāng)前使用的阻塞算法通過每 10 秒鐘改變被阻塞用戶來避免原纖化作用。
互換和上傳數(shù)目的改進(jìn)是由擁有最佳上傳速度和感興趣的 4 個(gè)未阻塞用戶來控制的。這將使客戶端的下載速度變得最大。這 4 個(gè)用戶被稱為下載者，因?yàn)樗鼈儗?duì)從客戶端的下載感興趣。
與下載者相比，具有較高上傳速度的用戶對(duì)未阻塞不感興趣。如果它們感興趣，具有最低上傳速度的下載者將被阻塞。如果客戶端擁有完成的文件，它使用上傳速度而不是下載速度來決定哪一個(gè)用戶未阻塞。
對(duì)于最佳暢通，在任何時(shí)候只有一個(gè)未阻塞用戶，而不管它的上傳速度（如果感興趣，它會(huì)成為 4 個(gè)允許的下載者之一）。最佳暢通的用戶 30 秒循環(huán)一次。最新連接的用戶有 3 次可能作為循環(huán)中當(dāng)前的最佳暢通。這給它們得到一個(gè)完成塊就上傳的機(jī)會(huì)。
（擴(kuò)展不在官方協(xié)議中）
偶爾一個(gè) BitTorrent 用戶會(huì)被其他用戶冷落，它先前從那些用戶中下載了數(shù)據(jù)。在這種情況下，它通常得到很低的下載速度，直到最佳暢通找到更好的用戶。為了緩和此問題，當(dāng)過了 1 分鐘而沒有從某個(gè)用戶得到一個(gè)片斷，BitTorrent 認(rèn)為它被那個(gè)用戶“冷落”了，不上傳給那個(gè)用戶（除了最佳暢通以外）。這會(huì)頻繁導(dǎo)致超過 1 個(gè)的用戶同時(shí)變成最佳暢通（一個(gè)例外是最佳暢通，規(guī)則如上所述），它會(huì)使波動(dòng)的下載速度回復(fù)得更快。
聯(lián)系客服
