BitTorrent 的 UDP Tracker 協(xié)議
簡(jiǎn)介
為了在一個(gè) BitTorrent 下載群體中找到其他的節(jié)點(diǎn)，一個(gè)客戶端會(huì)向一個(gè)追蹤器發(fā)出宣告自己的請(qǐng)求。這個(gè)請(qǐng)求使用 HTTP 協(xié)議，并包含一些參數(shù)，比如?info_hash?、?key?、?peer_id?、?port?、?downloaded?、?left?、?uploaded?和?compact?等。追蹤器會(huì)返回一組節(jié)點(diǎn)（主機(jī)和端口）以及其他一些信息給客戶端。這個(gè)請(qǐng)求和響應(yīng)都非常簡(jiǎn)短。由于使用的是 TCP 協(xié)議，需要在發(fā)送請(qǐng)求前打開連接，在完成請(qǐng)求后關(guān)閉連接，這會(huì)引入額外的開銷。
系統(tǒng)開銷
使用 HTTP 協(xié)議會(huì)帶來很大的系統(tǒng)開銷，因?yàn)樵谝蕴W(wǎng)層、 IP 層、 TCP 層和 HTTP 層都會(huì)有開銷，并且一個(gè)請(qǐng)求加上響應(yīng)包含 50 個(gè)節(jié)點(diǎn)需要使用大約 10 個(gè)數(shù)據(jù)包，總共使用的字節(jié)數(shù)約為 1206 。通過使用基于 UDP 的協(xié)議可以顯著減少這種開銷，本文提出的協(xié)議只需 4 個(gè)數(shù)據(jù)包和約 618 個(gè)字節(jié)，將流量減少了 50% 。雖然對(duì)于客戶端來說每小時(shí)節(jié)省 1KB 并不重要，但對(duì)于為百萬節(jié)點(diǎn)提供服務(wù)的 Tracker 來說，減少流量的 50% 非常重要。此外，基于 UDP 的二進(jìn)制協(xié)議不需要復(fù)雜的解析器和連接處理，降低了 Tracker 代碼的復(fù)雜性并提高了其性能。
UDP 連接 / 欺騙攻擊
在理想情況下，只需要兩個(gè)數(shù)據(jù)包就可以完成通信。在使用 UDP 協(xié)議時(shí)，由于 UDP 協(xié)議是無連接的，因此可能會(huì)存在偽造源地址的情況。因此，tracker 必須采取措施來確保不會(huì)出現(xiàn)欺騙行為。為了避免這種情況發(fā)生，Tracker（一個(gè)網(wǎng)絡(luò)中用來協(xié)調(diào)客戶端與其他 peer 之間數(shù)據(jù)共享的服務(wù)器程序）采取一些措施。
當(dāng)客戶端向 tracker 發(fā)送一個(gè)請(qǐng)求時(shí)，tracker 會(huì)生成一個(gè)隨機(jī)數(shù)（connection_id），并將其發(fā)送給客戶端?？蛻舳嗽俅蜗?tracker 發(fā)送請(qǐng)求時(shí)，需要帶上這個(gè) connection_id，以便 tracker 可以驗(yàn)證請(qǐng)求的來源是否合法。如果客戶端偽造了源地址，則不可能收到 tracker 發(fā)回的 connection_id，從而請(qǐng)求會(huì)被 tracker 拒絕。
為了確保 connection_id 不被客戶端猜測(cè)到，tracker 可以采用類似于 TCP 握手和 syn-cookie 的方法，在服務(wù)器端存儲(chǔ) connection_id，并僅在特定情況下才返回給客戶端使用。一個(gè) connection_id 可以用于多個(gè)請(qǐng)求，并且客戶端可以在接收到 connection_id 后的一分鐘內(nèi)使用它。 tracker 應(yīng)該在發(fā)出 connection_id 后的兩分鐘內(nèi)接受它，并驗(yàn)證來自客戶端的請(qǐng)求是否匹配這個(gè) connection_id 。
超時(shí)
UDP 是一種不保證數(shù)據(jù)包可靠傳輸?shù)膮f(xié)議，這意味著如果在傳輸過程中丟失了數(shù)據(jù)包，UDP 不會(huì)自動(dòng)重傳。相反，使用 UDP 的應(yīng)用程序需要負(fù)責(zé)處理丟失的數(shù)據(jù)包，并在必要時(shí)進(jìn)行重傳。
為了處理丟失的數(shù)據(jù)包，客戶端應(yīng)該在發(fā)送請(qǐng)求后等待服務(wù)器的響應(yīng)。如果在 15 * 2 ^ n 秒后沒有收到響應(yīng)，則客戶端應(yīng)該重新發(fā)送請(qǐng)求。重新發(fā)送請(qǐng)求的時(shí)間間隔從 15 秒開始，每次嘗試都會(huì)加倍，最多嘗試 8 次，即 3840 秒。
需要注意的是，如果連接 ID 已經(jīng)過期，在重新發(fā)送請(qǐng)求之前需要重新請(qǐng)求新的連接 ID 。這確保了請(qǐng)求將被正確地認(rèn)證并由服務(wù)器進(jìn)行處理。
樣例
常規(guī)廣播：
t = 0: connect request
t = 1: connect response
t = 2: announce request
t = 3: announce response
連接超時(shí)：
t = 0: connect request
t = 15: connect request
t = 45: connect request
t = 105: connect request
etc
廣播超時(shí)：
t = 0:
t = 0: connect request
t = 1: connect response
t = 2: announce request
t = 17: announce request
t = 47: announce request
t = 107: connect request (because connection ID expired)
t = 227: connect request
etc
多重請(qǐng)求：
t = 0: connect request
t = 1: connect response
t = 2: announce request
t = 3: announce response
t = 4: announce request
t = 5: announce response
t = 60: announce request
t = 61: announce response
t = 62: connect request
t = 63: connect response
t = 64: announce request
t = 64: scrape request
t = 64: scrape request
t = 64: announce request
t = 65: announce response
t = 66: announce response
t = 67: scrape response
t = 68: scrape response
UDP Tracker 協(xié)議
所有數(shù)值（例如整數(shù)或浮點(diǎn)數(shù)）在發(fā)送時(shí)都應(yīng)該按照網(wǎng)絡(luò)字節(jié)順序（大端序）進(jìn)行編碼。此外，不應(yīng)該預(yù)期每個(gè)數(shù)據(jù)包都具有確定的大小。因?yàn)閷砜赡軙?huì)通過添加新功能來增加數(shù)據(jù)包的大小。
連接
Before announcing or scraping, you have to obtain a connection ID.
Choose a random transaction ID.
Fill the connect request structure.
Send the packet.
對(duì)于進(jìn)行”announcing” 或 “scraping” 操作之前，需要先獲取一個(gè)連接 ID 的過程。步驟如下：
隨機(jī)生成一個(gè) Transaction ID 作為唯一標(biāo)識(shí)符。
填充連接請(qǐng)求結(jié)構(gòu)體。
發(fā)送請(qǐng)求數(shù)據(jù)包。
連接請(qǐng)求：
Offset ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? 64-bit integer ?protocol_id ? ? 0x41727101980 // magic constant
8 ? ? ? 32-bit integer ?action ? ? ? ? ?0 // connect
12 ? ? ?32-bit integer ?transaction_id
16
接收數(shù)據(jù)包。
檢查它的長(zhǎng)度是否至少為 16 字節(jié)。
檢查接收到的數(shù)據(jù)包中的 Transaction ID 是否與之前發(fā)送請(qǐng)求時(shí)選擇的 ID 一致。
檢查數(shù)據(jù)包中的操作是否為”connect” 。
將數(shù)據(jù)包中的 Connection ID 存儲(chǔ)到本地，并用于后續(xù)操作。
連接響應(yīng)：
Offset ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? 32-bit integer ?action ? ? ? ? ?0 // connect
4 ? ? ? 32-bit integer ?transaction_id
8 ? ? ? 64-bit integer ?connection_id
16
廣播
從系統(tǒng)中隨機(jī)選擇一個(gè) Transaction ID 。
填入一個(gè)廣播請(qǐng)求結(jié)構(gòu)。
發(fā)送數(shù)據(jù)包。
IPv4 廣播請(qǐng)求：
Offset ?Size ? ?Name ? ?Value
0 ? ? ? 64-bit integer ?connection_id
8 ? ? ? 32-bit integer ?action ? ? ? ? ?1 // announce
12 ? ? ?32-bit integer ?transaction_id
16 ? ? ?20-byte string ?info_hash
36 ? ? ?20-byte string ?peer_id
56 ? ? ?64-bit integer ?downloaded
64 ? ? ?64-bit integer ?left
72 ? ? ?64-bit integer ?uploaded
80 ? ? ?32-bit integer ?event ? ? ? ? ? 0 // 0: none; 1: completed; 2: started; 3: stopped
84 ? ? ?32-bit integer ?IP address ? ? ?0 // default
88 ? ? ?32-bit integer ?key
92 ? ? ?32-bit integer ?num_want ? ? ? ?-1 // default
96 ? ? ?16-bit integer ?port
98
接收數(shù)據(jù)包。
檢查數(shù)據(jù)包的長(zhǎng)度是否至少為 20 字節(jié)。
檢查數(shù)據(jù)包中的交易 ID 是否與之前選擇的交易 ID 相等，以確保接收到的是之前發(fā)送的通告請(qǐng)求的響應(yīng)。
檢查數(shù)據(jù)包中的操作是否為 “announce” 。
進(jìn)行時(shí)間間隔檢查。如果與上次廣播請(qǐng)求時(shí)間不足一定時(shí)間間隔（interval 秒），則不再進(jìn)行廣播請(qǐng)求；否則，可以繼續(xù)進(jìn)行廣播請(qǐng)求或等待事件觸發(fā)后再次請(qǐng)求。
大多數(shù) Tracker 只在某些特定情況下才會(huì)考慮 IP 地址字段。
IPv4 廣播請(qǐng)求:
Offset ? ? ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? ? ? 32-bit integer ?action ? ? ? ? ?1 // announce
4 ? ? ? ? ? 32-bit integer ?transaction_id
8 ? ? ? ? ? 32-bit integer ?interval
12 ? ? ? ? ?32-bit integer ?leechers
16 ? ? ? ? ?32-bit integer ?seeders
20 + 6 * n ?32-bit integer ?IP address
24 + 6 * n ?16-bit integer ?TCP port
20 + 6 * N
IPv6
IPv6 和 IPv4 在協(xié)議結(jié)構(gòu)上的區(qū)別以及如何在使用中進(jìn)行適配。其中，IPv6 和 IPv4 的消息格式基本相同，但是在回應(yīng)消息中，<IP地址、TCP端口>對(duì)的步進(jìn)大小從 6 字節(jié)變成了 18 字節(jié)。此外，在請(qǐng)求消息中，IP 地址字段仍然是 32 位寬度，不能用于 IPv6，并且始終應(yīng)該設(shè)置為 0 。
同時(shí)，該段落還提到了適配的方式：根據(jù) UDP 包的地址族來確定所使用的格式，即來自 IPv4 地址的數(shù)據(jù)包使用 IPv4 格式，來自 IPv6 地址的數(shù)據(jù)包使用 IPv6 格式。最后，對(duì)于將主機(jī)名解析為 IPv4 和 IPv6 并向兩個(gè)傳輸使用相同密鑰的客戶端，需要確保跟蹤器能夠準(zhǔn)確地匹配兩個(gè)通告，以實(shí)現(xiàn)準(zhǔn)確統(tǒng)計(jì)。
抓取
最多可以同時(shí)獲取約 74 個(gè)種子文件的信息。無法使用此協(xié)議完成完整的數(shù)據(jù)抓取。
隨機(jī)選擇一個(gè) Transaction ID 。
填充抓取請(qǐng)求結(jié)構(gòu)。
發(fā)送數(shù)據(jù)包。
抓取請(qǐng)求：
Offset ? ? ? ? ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? ? ? ? ? 64-bit integer ?connection_id
8 ? ? ? ? ? ? ? 32-bit integer ?action ? ? ? ? ?2 // scrape
12 ? ? ? ? ? ? ?32-bit integer ?transaction_id
16 + 20 * n ? ? 20-byte string ?info_hash
16 + 20 * N
接受數(shù)據(jù)包。
檢查數(shù)據(jù)包的長(zhǎng)度是否至少為 8 字節(jié)。
檢查該數(shù)據(jù)包中的 Transaction ID 是否與之前你選擇的相同。
檢查數(shù)據(jù)包中的操作是否為 “scrape” 。
抓取響應(yīng):
Offset ? ? ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? ? ? 32-bit integer ?action ? ? ? ? ?2 // scrape
4 ? ? ? ? ? 32-bit integer ?transaction_id
8 + 12 * n ?32-bit integer ?seeders
12 + 12 * n 32-bit integer ?completed
16 + 12 * n 32-bit integer ?leechers
8 + 12 * N
如果 tracker 遇到錯(cuò)誤，可能會(huì)發(fā)送一個(gè)錯(cuò)誤數(shù)據(jù)包。
接受數(shù)據(jù)包。
檢查數(shù)據(jù)包的長(zhǎng)度是否至少為 8 字節(jié)。
檢查該數(shù)據(jù)包中的 Transaction ID 是否與之前你選擇的相同。
錯(cuò)誤
錯(cuò)誤響應(yīng)：
Offset ?Size ? ? ? ? ? ?Name ? ? ? ? ? ?Value
0 ? ? ? 32-bit integer ?action ? ? ? ? ?3 // error
4 ? ? ? 32-bit integer ?transaction_id
8 ? ? ? string ?message
現(xiàn)有實(shí)例
IMFile，Azureus，libtorrent，opentracker，XBT Client 和 XBT Tracker 支持該協(xié)議。
插件
為了保持協(xié)議的兼容性，一般不會(huì)在協(xié)議中包含擴(kuò)展位或版本字段?？蛻舳撕?Tracker 也不應(yīng)該假定數(shù)據(jù)包的大小。這樣做可以在不破壞兼容性的情況下添加額外的字段。換句話說，通過避免固定數(shù)據(jù)包長(zhǎng)度和格式，協(xié)議可以更容易地進(jìn)行擴(kuò)展和更新，并且可以保持向后兼容性。
總結(jié)
UDP Tracker Protocol for BitTorrent 是一種用于點(diǎn)對(duì)點(diǎn)文件共享協(xié)議 BitTorrent 中的追蹤器通信協(xié)議。它是基于 UDP 協(xié)議的，相較于 HTTP 協(xié)議，可以更快地傳輸數(shù)據(jù)，同時(shí)也具有更好的擴(kuò)展性和高效性。
通過 UDP Tracker Protocol，BitTorrent 客戶端可以向追蹤器發(fā)送請(qǐng)求，獲取連接到種子的其他用戶列表。這些用戶可以幫助下載者提供文件塊，提高下載速度。此外，追蹤器還可以提供有關(guān)特定種子的統(tǒng)計(jì)信息，如上傳和下載速度、剩余時(shí)間等。
盡管 UDP Tracker Protocol 具有許多優(yōu)點(diǎn)，但由于其本質(zhì)上是無狀態(tài)的，因此在某些情況下可能會(huì)遇到一些問題，例如有時(shí)會(huì)丟失請(qǐng)求或響應(yīng)。為了解決這些問題，很多 BitTorrent 客戶端還支持 HTTP Tracker Protocol，同時(shí)使用兩種不同的追蹤器通信協(xié)議以提高可靠性。
參考鏈接
http://www.bittorrent.org/beps/bep_0015.html
http://xbtt.sourceforge.net/udp_tracker_protocol.html
http://www.rasterbar.com/products/libtorrent/udp_tracker_protocol.html
http://opentracker.blog.h3q.com/
http://bittorrent.org/beps/bep_0041.html
