|
對BitTorrent通信協議的分析與檢測
關鍵字: 測試 電信 服務器 網絡 計算機 ASCII 路由器 P2P IP
摘要 風靡一時的應用程序BitTorrent（BT）曾在短期內改變了因特網的流量構成，對IP網絡的運營、維護和管理產生了巨大影響。
本文建立了分析BT協議的環境，通過俘獲BT分組并對照BT協議規范，分析了BT通信協議的交互過程，并據此配合BT的特征字符串、特征端口及行為特征，提出了一種檢測通信流中存在BT通信的方法。
1、概述
傳統的因特網服務如Web、FTP、DNS等均使用客戶機/服務器（C/S）模式進行通信。在通信過程中，提供服務的程序稱為服務器，請求服務的程序稱為客戶機。因此，在復雜通信的過程中，一個服務器很可能在另一次通信中變為客戶機，反之亦然。C/S模式的特征是：服務器是總是打開的主機，具有永久的IP地址，并可擴展為服務器池；客戶機與服務器直接通信，可以間歇地與服務器連接，可以具有動態的IP地址，并且客戶機彼此之間不直接通信。C/S模式的最大特點是服務和資源集中，所有對服務請求的處理通常是由服務器完成的。
對等方到對等方（peer-to-peer，P2P）是近年來流行起來的通信模式，但實際上因特網正是基于這種理念建立起來的。隨著因特網用戶和服務的增多，服務器面臨的壓力越來越大，P2P又重新回到了人們的視線中。在P2P模式中，無總是打開的應用服務器，任意的端系統之間可直接通信，對等方間歇地連接，并可改變IP地址。P2P模式的特征是：服務和資源分布化，資源不集中存儲在某些設備上，而是分散存儲在運行P2P程序的設備上，每一個對等方都可以為其他對等方提供服務。例如，主機A要從網上下載一個文件a，如果以P2P模式工作，那么它工作的基本過程是：定位具有文件a的對等方，向對等方提出下載請求，并獲得該文件。值得注意的是，主機A在下載文件a的同時，可能也在為其他用戶提供文件（包括文件a）下載。根據定位文件a的方式不同，可將P2P應用方式分為3類：集中式目錄、分布式查詢和結合這兩者的混合方式[1]。集中式目錄模式屬于第一代P2P應用，使用一臺大型服務器（或服務器場）來提供目錄服務，其代表是Napster[2]，缺點是存在單點故障、性能瓶頸和侵犯版權等問題。分布式查詢將目錄服務完全分布在覆蓋網絡的所有對等方中，每一個對等方負責維護一部分目錄內容。系統采用洪泛查詢（query flooding）算法使用戶獲得文件信息，收到該報文的主機向它們的所有鄰居轉發該報文，這些鄰居又依次向它們的所有鄰居轉發該報文等，其代表是Gnutella[3]。第3種方式是前兩種方式的結合，其中一種實現方法是將覆蓋網絡中的對等方劃分為若干小組，每個小組選取一個具有高帶寬連接和高因特網連接性的成員作為組長，組長負責管理組內成員及與其他組長通信。在小組內使用集中式目錄服務，服務器就是該組的組長。各組長之間使用分布式的目錄服務�；旌戏绞侥壳霸赑2P應用中使用最為廣泛，其代表是KaZaA、BitTorrent（BT）[4]。
由于BT使用廣泛，其通信協議引起的流量巨大，BT對因特網的運營、維護和管理具有重要影響。為此，參考文獻[5]對BT的一般工作原理進行了介紹，參考文獻[6]在分析BT工作原理的基礎上，比較了BT與C/S模式應用程序的特點，提出了一種BT改進建議，但這些文獻都沒有詳細地分析BT通信協議（簡稱BT協議）原理和交互過程。為此本文深入分析了BT通信協議和其交互過程，研究了BT通信的特點，并由此提出了一種檢測通信流中存在BT通信的方法。
2、建立BT的分析環境
支持BT協議的P2P應用程序很多，如BitBuddy、FlashBT、BitComet和BitSpirit等，這里以應用程序BT為例來分析BT協議。本文中的BT，如其后沒有“協議”兩字，表示的是BT應用程序。
BT由如下幾部分組成：.torrent文件、種子提供站點、目錄服務器和內容發布者/下載者。.torrent文件是一個文本文件，包含了tracker信息和文件信息兩部分。tracker信息主要是BT下載中需要用到的tracker服務器的地址和針對tracker服務器的設置；文件信息是指將目標文件計算處理后再根據BT協議的B編碼規則網編碼后得到的信息。BT的主要原理是把提供下載的文件虛擬分成大小相等的塊，塊大小必須為2 Kbyte的整數次方（由于是虛擬分塊，硬盤上并不產生各個塊文件），并把每個塊的索引信息和Hash驗證碼寫入.torrent文件中，所以.torrent文件就是被下載文件的“索引”。種子提供站點也就是.torrent文件的提供站點，為下載者提供.torrent文件下載服務。目錄服務器記錄被下載的文件的索引信息及下載該文件的用戶的信息（主要是IP地址及端口號）。早期的BT協議只支持tracker服務器，這種目錄服務器是集中式目錄與分布式查詢的混合型；在BT協議的升級版本中，增加了對DHT（分布式Hash表）網絡的支持，該網絡中目錄服務器是分布式的。本文的討論只涉及tracker服務器。內容發布者/下載者是BT網絡的主體，最終的下載由它們完成。構成BT網絡的這幾部分的相互關系如圖1所示。
圖1 BT覆蓋網絡的結構
根據BT的工作原理，為了分析BT協議的交互過程，本文重點關注本地BT客戶機的運行過程。圖2顯示了BT協議的測試環境，其中BT客戶機的IP地址是192.168.0.179，使用Active Ports工具獲取BT使用的端口號，Active Ports的版本號為1.4。使用協議分析儀Ethereal俘獲BT協議分組的交互過程，運行Ethereal協議分析儀的IP地址是192.168.0.179，Ethereal版本號為0.10.14。它們通過路由器與因特網相連，BT服務器位于因特網，BT版本號為4.20.2。
圖2 BT協議的測試環境
3、BT協議的工作過程
BT協議主要包括3個部分：.torrent文件的格式、tracker HTTP/HTTPS協議和Peer wire協議（使用TCP）。其中tracker HTTP/HTTPS協議是BT客戶機與tracker服務器之間的通信協議，Peer wire協議是BT客戶機之間的通信協議。
使用Ethereal跟蹤分析下載一個文件的過程中BT協議的具體交互過程，結合BT協議規范，繪制了BT協議各組件的工作時序圖（參見圖3）。
圖3 BT協議各組件的工作時序
3.1 .torrent文件的結構
圖4是下載中使用的.torrent文件的一段主要內容，采用了B編碼。B編碼是一種簡潔的數據組織方式，支持4種數據類型：byte strings、integers、lists和dictionaries。integers、lists和dictionaries類型分別以字母i、l、d作為首定界符，以字母e作為尾定界符。byte strings類型不使用首/尾定界符，其格式為<十進制表示的字符串長度>：<字符串>，如4:spam表示字符串“spam”。這4種數據類型嵌套使用構成了.torrent文件的內容。其中，用*號代替空格以便于分析。
圖4 .torrent文件的內容
其中的一些主要成份如下：
- announce：tracker服務器的URL，本例中為http：//tracker.cnxp.com:8080/announce。
- announce-list：可選。備用tracker服務器的URL列表，本例中為http://tracker.cnxp.com:8080/announce,http://btfans.3322.org:6969/announce等。
- creation date：可選。.torrent文件的創建日期，使用標準的UNIX時間，本例中為1152105243。
- comment：可選。.torrent文件制作者添加的任意格式的說明。
- created by：可選。制作.torrent文件的工具，本例中使用的制作工具是BitComet/0.67。
- encoding：可選。發布的資源使用的編碼方式，在本例中使用的是GBK。
- info：發布的文件的信息。有兩種格式，單文件格式和多文件格式。單文件格式包括length、md5sum（可選）、name、piece length、pieces；多文件格式包括files、name、piece length、pieces，其中files包括length、path、md5sum（可選），每一個文件都有單獨的length、path、md5sum（可選）。本例使用多文件格式，共有兩個文件，分別是“Love Undercover Ⅲ.txt”和“影視帝國（bbs.cnxp.com）.新扎師妹
3.國語DVDSCR中字.rmvhe”，piece長度為262 144 byte.piece個數為34 780。
.torrent文件中還包括其他一些可選項，只要它們遵循B編碼方式就能夠被客戶機識別，這里不再累述。
3.2 tracker HTTP/HTTPS協議
BT客戶機依次向.torrent中的tracker服務器發送連接請求，以獲得正在下載該文件的對等方列表（主要是IP地址和監聽端口）。如果連接成功獲得列表，就關閉連接，嘗試與列表中的對等方建立連接；如果不成功，嘗試下一個tracker服務器。
服務器tracker.cnxp.com的IP地址為61.129.77.239，btfans.3322.org的IP地址為61.129.78.114，BT客戶機與BT服務器的交互過程如圖5所示。
圖5 BT客戶機與BT服務器的交互過程
分析這些分組，易知分組702、748（分組702的重傳）、750、752是建立TCP連接的三次握手。BT客戶機通過753號分組向tracker服務器發出獲取對等方列表的請求，754號、755號分組為應答。757-760號分組為關閉連接的交互過程。下面重點分析753號、754號和755號分組。
753號分組中的HTTP部分內容如圖6所示，使用*號代替空格以便于分析。
圖6 753號分組中的HTTP部分內容
其中一些成分的含義如下：
- info_hash：.torrent文件中的info部分的Shal校驗碼，共20 byte。tracker服務器通過它在發布列表中找到對應的記錄。
- peer_id：BT客戶機的惟一性標志，在客戶機啟動時產生，共20 bit。在BT V1.0中沒有規定產生peer_id的算法，只要求能夠保證惟一性即可。
- port：提供上傳的端口號，亦即常說的監控端口，這里是6641（可自行設定）。
- key：可選。一個擴展的惟一性標志，即使改變了IP地址，也可以使用該字段標志該BT客戶機。
- uploaded/downloaded：上傳/下載的字節數（從客戶機向tracker服務器發送“started”開始計算），服務器可以用它來做流量分析。
- left：還需要下載的字節數。
- compact：壓縮標志。如果值為1表示接受壓縮格式的對等方列表，即用6 byte表示一個對等方（前4 byte表示IP地址，后2 byte表示端口號）；值為0表示不接受。
- event：表明客戶機的狀態，只能是started、completed、stopped等3種中的一種。
- 除了上面這些例子中包含的參數外，可選的參數還有：
- ip：可選。IP地址，沒有的話服務器會自己找到。
- numwant：可選。客戶機希望從tracker服務器得到的對等方的數目。
- trackerid：可選。如果在之前的announce中包含了trackerid，將其值設置在該處。
服務器中有個track程序來管理這些請求，得到這一串代碼后就會用info_hash來查找列表，若找到就可以下載。接著它會反連（NatCheck）客戶機的IP地址和端口來判斷它是內網用戶還是公網用戶（像10.10.10.x這樣的地址。是無法連通的）。接下來服務器返回現在正在下載這個文件的所有公網用戶的IP地址和端口（包含在分組754、755中，因為返回的數據比較多，所以被分片返回）。HTTP之上的部分數據如圖7所示。
圖7 HTTP之上的部分數據
其中“1998：”及其之前的部分使用的是ASCII字符集，“1998：”之后的部分是用16進制表示的二進制數。從分組內容可以看出interval的值為1 800。也就是BT客戶機最多每隔1 800個時間單位就與tracker服務器重新聯系一次：peers部分共有1 998 byte。對753號分組的分析可知，BT客戶機支持對對等方列表的壓縮，因此在754、755號分組返回的對等方列表是用壓縮方式存儲的，即6 byte表示一個對等方，例如da40 91 e8 41 af表示的對等方是218.64.145.232:16815,dd ea 3b 9f 7a 2f表示的對等方是221.234.59.149:31279。對等方列表的長度為1 998 byte，也就是說返回的對等方個數為333個。
3.3 Peer wire協議
BT客戶機會嘗試與返回的對等方列表中的部分對等方建立連接，下面以對等方列表中的221.234.59.149:31279為例，分析一下對等方之間的交互過程。如圖8所示，只分析TCP之上的部分。約定對等方A指的是221.234.59.149:31279，對等方B指的是192.168.0.179:1504。
圖8 對等方間通信過程
建立TCP連接之后，對等方之間的交互過程包括以下幾步：
�。�1）握手，通過Handshake分組實現。在本例中通過分組2480和2481實現。
（2）互換所擁有的資源的情況。通過Bitfield分組實現。該例中，對等方B尚未下載任何資源，故公布資源擁有情況的只有對等方A。對等方A通過分組2487公布了自己的資源擁有情況。
�。�3）互通對資源的意愿情況，包括interested、not interested、choke、unchoke等4種。本例中通過分組2490、2493實現。
�。�4）互相請求資源，通過request piece、piece分組實現，例如本例中的分組2495、2503、2696。
（5）斷開連接。因Peer wire協議使用了TCP方式，對等方A與對等方B斷開連接時，只需要斷開它們之間的TCP連接即可。
分組2495是一個request piece分組，其結構如圖9所示，其中需要的參數有piece index（片標志）、begin offset of piece（片起始偏移地址）、piece length（片長度）。分組2696是一個answer piece分組（也稱為piece分組），其結構如圖10所示，其中包括piece index（片標志）、begin offset of piece（片起始偏移地址）、date（數據）。
圖9 request piece分組的結構
圖10 piece分組的結構
4、一種檢測BT流量的方法
經分析，BT應用程序的工作過程歸納如下：
- 資源發布者制作.torrent文件并上載到種子發布站點，將客戶機連入BT網絡并在tracker服務器上發布信息。默認情況下，BT的監聽端口為6881-6889，也可由使用者指定；tracker服務器的監聽端口主要有8080、8000、6969和2710，它們采取的連接方式都是TCP。
- BT客戶機（下載者）獲取.torrent文件，并向.torrent文件中提供的tracker服務器依次發起連接請求，直至與其中之一建立TCP連接并獲取對等方列表。使用Ethereal抓包分析，發現這些連接請求被接受的可能性比較小，一般不到10%。
- BT客戶機（下載者）獲取.torrent文件，并向.torrent文件中提供的tracker服務器依次發起連接請求，直至與其中之一建立TCP連接并獲取對等方列表。使用Ethereal抓包分析，發現這些連接請求被接受的可能性比較小，一般不到10%。
- BT客戶機隨機地向列表中的對等方發起連接請求，因為對等方列表中對等方個數比較多，所以在短時間內發出大量TCP連接請求分組。這些分組的源地址相同，源端口號相鄰，目的地址／端口號不同，并且有相當一部分的目的端口號為6881-6889。
- 如果連接建立成功，BT對等方之間進行握手，握手過程中使用特征字符串“BitTorrent protocol”。然后使用interested、not interested、choke和unchoke等4種分組互通對資源的意愿情況，之后通過Request Piece和Piece分組傳輸資源。
- 資源傳輸完畢，關閉TCP連接。
- 依據BT應用程序的這些特點，本文提出了檢測BT流量存在的一種方法。該檢測方法主要分4個步驟：
- 特征字符串匹配。如果分組的負載中出現了字符串“BitTorrent protocol”，表明有BT客戶機運行，將該分組中的源IP地址和源端口號記為{IP.port}對，凡與此{IP，port}對相關的分組均判定為BT流量。
- 特征端口匹配。所有使用6881-6889作為端口號的分組均被判定為BT流量。
- tracker服務器規則。將目的端口號為8000、8080、6969和2710的TCP分組的目的IP地址標記為tracker服務器，將源端口號為8000、8080、6969和2710的TCP分組的源IP地址標記為tracker服務器，所有與tracker服務器相關的分組均被判定為BT流量。
- 通過以上3步可以較準確地判斷流中是否存在BT業務，但并不能保證找出所有的BT分組。為了進一步增加判斷的準確性�？墒褂昧髦g關系信息。例如某一時間段內，相同兩臺主機之間的流被關聯在一起；來自不同主機的有著相同目的地址和目的端口號的流被關聯起來；在某一時間段內來自同一主機的流被關聯起來等。
筆者根據這種檢測BT流量的方法實現了相關檢測程序。由于該方法使用了特征字符串和特征端口來判斷BT流量并使用流關系，在一定程度上解決了因程序使用隨機端口帶來的檢測困難，提高了檢測的準確性。程序實驗結果也表明了上述算法的有效性。限于篇幅，將另文報告。
參考文獻
- Kurose J，Ross K著.陳鳴譯.計算機網絡——自頂向下方法與因特網特色(原書第三版).北京：機械工業出版社，2005
- Napster protocol specification.http：//opennap.sourceforge.net/napster.txt,Apr 2000
- The Gnutella Protocol Specification v0.4.http：//www9.1imewire.com/developer/gnutella_protocol_0.4.pdf
- Bittorrent Protocol Specification v1.0.http//wiki.theory.org/BitTorrentSpecifieation，Sep 2006
- 王玨.BitTorrent下載技術研究.科技廣場，2005（2）:26-27
- 孔彬，徐良賢.BitTorrent原理分析及改進.計算機工程，2004，30(12)：257～259
|
