BitTorrent協議支援基於TCP或UTP網路協議進行資料傳輸，但是由於TCP協議是有連線的，需要先進行握手。在進行資料傳輸的過程中，每個種子會佔有大量的TCP連線，從而佔有大量的使用者頻寬。這給其他需要高實時性的應用造成很大的網路壓力。

於是BitTorrent又支援UTP協議用來進行資料傳輸，這也是當前大部分BT下載客戶端所採用的實現方式。UTP(uTorrent Transport Protocol)是基於UDP網路協議的，也就是無連線協議，採用這種協議進行資料交換，可以很容易進行頻寬控制，不會造成網路擁堵。

下面主要分析BitTorrent中的UTP協議，因為這個常用嘛！

UTP協議的包結構如下：（不包含UDP header）

Fig. 1 UTP包結構(來自bittorrent.org)

•  type：資料包型別，0--帶負載資料包，就是通常在連線建立後，上傳資料或下載資料的包；1--連線結束資料包，結束一個連線；2--資料迴應包，當一個peer收到一個帶負載資料包後，會回一個ACK包，來表示這個包已正確接收，有點類似於TCP的SYN的感覺，但是這個是在UDP包的資料段做連線控制；3--重置連線；4--開始一個連線
•  ver：協議版本，通常為1
•  extension：擴充套件段，用於支援BEPs
•  connection_id：連線id，同一個連線id的資料包屬於一個連線，一般每兩個
  peer之間會開兩個連線，一個用於發，一個用於收
•  timestamp_microseconds：包的傳送時間
•  timestamp_difference_microseconds：由於雙方的時間戳不同，因此每個報文都要帶一個上次接收到的包中顯示的時間(就是上面的timestamp_microseconds)和當前時間戳之間的差值，然後把這個差值減去最小的基準差(也就是歷史差值中的最小值)，再把結果送到擁塞控制器中運算，進而控制速度。
•  wnd_size：傳送方當前剩餘視窗大小，用於進行速度和頻寬控制。BitTorrent協議中每一個發出去的資料包，都要求接收方回一個ACK包。而一個peer的視窗大小是指當前傳送出去，但還沒有收到迴應的包的總大小，單位為位元組。每一個
  peer都一個最大視窗值和一個視窗大小上限值。當wnd_size小於最小UTP包大小的時候，傳送方會停止傳送資料包，或調整每個資料包的資料負載大小
•  seq_nr：相對於一個連線，資料包的序列號，以一個包為計數單位
•  ack_nr：傳送方最近接收到的包的序列號

可能說這麼多，有點混亂了，下面以一個具體的UTP包做說明。

資料包內容如下：

0000   78 ac c0 55 45 4a 00 0c 86 23 b8 00 08 00 45 00

0010   00 30 2f e7 00 00 66 11 a4 23 01 a4 60 2e db f6

0020   42 ea 8f b9 cf 46 00 1c 00 00 21 00 19 a2 ec 07

0030   ea 27 c3 62 4a be 00 37 f5 10 11 89 32 d4

其中0x00-0x29是UDP header，這裡不再分析。咱來看一下它的資料部分：

210019a2ec07ea27c3624abe0037f510118932d4

可以看出來：

•  0x2是type欄位，代表這是一個數據迴應包
•  0x1是它的協議版本號
•  0x00是它的擴充套件欄位
•  00代表該包沒有擴充套件資訊
•  0x19a2是該包的連線id，這是一個隨機數
•  0xec07ea27是該包的傳送時間
•  0xc3624abe是這個包的傳送方最近一次接收包到這次發生包之間的間隔，間隔這麼長，表示當前網路環境不行，資料傳輸速度不是很快
•  0x0037f510是傳送方的視窗大小，也就是說當前傳送方還可以接收3.5MB的資料
•  0x1189是該資料包的序列包，也就意味著傳送方在這個連線上已經發送了4489個包
•  0x32d4是該傳送方最近接受到的包序列號