BitComet 的 P2P 加速原理：為什麼它下載比別人快兩倍？

BitComet 是什麼

BitComet（中文名叫比特彗星）是一款開源免費的資源下載軟體，最早以 BT 下載器 身份打響名號，後來逐步擴展支援 HTTP、FTP 等多種協定。手機版 App 提供 torrent 種子檔案和磁力連結兩種 BT 下載方式，同時內建了 HTTP 下載的 P2P 加速機制——這一點讓它在同類下載器中顯得與眾不同。

我留意到一個有趣的現象：同樣一個 10GB 的遊戲安裝包，用瀏覽器直下可能只有 2~3MB/s，用某些多執行緒下載器頂多跑到 5MB/s，但用 BitComet官網 提供的版本有時能飆到 15MB/s 甚至更高。為什麼它能快這麼多？答案不在執行緒數量、也不在鏡像搜尋——而在於它偷偷在你的 HTTP 下載任務裡疊了一層 BT 協定的加速通道。這篇文章我想把這個設計從裡到外拆給你看。

安裝

BitComet 手機版（Android APK）最新版本為 2.7.0，安裝包大小約 26.81MB。安裝方式和一般 Android App 類似，但有幾個值得注意的前置條件與首次啟動細節。

首先，確保手機已允許「未知來源」安裝——Android 8.0 之後這個選項被分散到各個 App 層級，你需要在瀏覽器或檔案管理員的「允許安裝未知應用」開關中打開權限。安裝完成後首次啟動，BitComet 會請求兩個關鍵權限：儲存空間存取權（用來建立下載目錄與暫存檔）和 網路權限（執行 BT 協定堆疊與 DHT 網路查詢），兩者都必須授予，否則 P2P 加速功能無法正常工作。

安裝後建議立刻進入「設定」檢查兩件事：一是預設下載目錄是否指向內部儲存空間中剩餘空間充足的資料夾（不建議指向 SD 卡，BT 的頻繁隨機讀寫會加速記憶體磨損）；二是上傳速度限制——P2P 加速需要你也上傳資料，預設不限速可能把你的上行頻寬吃滿，建議設一個合理值（比如 500KB/s 到 1MB/s），避免影響正常上網。完整的安裝與設定步驟見 BitComet下載 指南。

從一個問題切入：HTTP 下載為什麼總是慢？

在拆解 BitComet 的 P2P 加速之前，我們先來看傳統 HTTP 下載的速度瓶頸在哪裡。

想像一個熱門檔案的下載場景：官方伺服器總頻寬 1Gbps，同時有 10,000 個使用者在下載，人均分到的頻寬只有 100Kbps——大約 12KB/s。就算你把多執行緒開到 50 段，伺服器端的總輸出能力還是那麼多，多執行緒只是把同一碗湯分成 50 個小碗，並沒有讓湯變多。

多鏡像是解決這個問題的經典方案：在網路上找到多個內容相同的下載位址，把不同的下載段分配到不同的伺服器上，理論上速度可以線性疊加。但多鏡像也有極限——不是每個熱門檔案都有充足的鏡像，有些冷門資源根本找不到第二個下載點。

BitComet 的設計者面對的就是這個問題：當 HTTP 源和鏡像都供不上來的時候，還有沒有第三條路？他們的答案是——向 BT 網路借一條。

BitComet 的 P2P 加速機制：四步流程拆解

我把 BitComet 在 HTTP 下載中疊加 P2P 加速的整個流程拆成四個步驟，每一步都有精心設計的技術細節。

第一步：檔案指紋生成

HTTP 下載任務啟動後，BitComet 首先計算整個檔案的 MD5 雜湊值——一個 32 位十六進位字串。這個雜湊就是這個檔案在 BitComet P2P 網路裡的唯一身份識別碼，類似於 BT 任務的 btih 雜湊。

為什麼選擇 MD5 而不是 BT 協定標準使用的 SHA-1？我的推測是相容性考量：MD5 計算速度比 SHA-1 快，而 HTTP 檔案的完整性校驗通常也用 MD5，這樣 BitComet 可以一石二鳥——同一個雜湊既用來做檔案完整性驗證，又用來做 P2P 網路查詢的身份識別。

第二步：DHT 網路查詢

有了檔案雜湊後，BitComet 把它廣播到 DHT（Distributed Hash Table，分散式雜湊表）網路裡，查詢一個問題：有沒有其他 BitComet 客戶端正在下載或已經下載了這個雜湊對應的檔案？

這裡有一個關鍵的設計取捨：HTTP P2P 加速的對等者發現只依賴 DHT，不走 Tracker 伺服器。BT 任務同時用 Tracker（中心化的對等者目錄）和 DHT（去中心化的對等者發現），但 HTTP P2P 加速只有 DHT。原因我能理解——HTTP 檔案沒有對應的 .torrent 檔，自然也沒有 Tracker 伺服器可以查。DHT 作為純去中心化的發現機制，正好填補了這個空缺。

第三步：對等者連線與資料交換

如果 DHT 查詢找到了其他也在下載同一個檔案的 BitComet 使用者，接下來就是 BT 協定堆疊的經典流程：建立連線、交換檔案片段可用性清單、互相請求與上傳資料片。

BitComet 採用了 BT 協定堆疊的一個子集——只用來交換資料片，不做完整的 BT 任務管理（比如種子文件建立、Tracker 溝通等）。這種設計的好處是輕量，不會因為 P2P 加速通道而影響主要的 HTTP 下載邏輯。

第四步：雙通道資料合併

這是整個機制最精妙的一步：HTTP/FTP 源的資料和 P2P 對等者的資料，兩路合併寫入同一個目標檔案。BitComet 自動做去重和分片校驗——如果某個資料片同時從 HTTP 源和 P2P 對等者那裡拿到了，只保留一份。

一個生活化的類比

讓我用一個自己造的類比幫你把這整套機制在腦子裡具象化：

普通 HTTP 下載 = 你去一個餐廳吃飯，一個服務員慢慢給你上菜。服務員的手速就是伺服器的出口頻寬，你再急也只能等。

多鏡像 = 你同時叫來 5 個外賣店（鏡像伺服器），每個店給你上不同的菜。速度確實快了，但前提是你知道這 5 個店都有你要的菜。

P2P 加速 = 你發現鄰桌 3 桌客人也在吃和你一樣的菜，他們的盤子裡有些菜你剛好也想要，你和他們約好互相交換——你有的和他們換、他們有的和你換。你甚至不需要知道這些鄰桌客人是誰，BitComet 自動幫你匹配和交換。更妙的是，就算一個鄰桌客人都沒找到，你原來的 HTTP 下載照樣在跑——P2P 通道是純粹的加成，不會讓原本的工作停下來。

這套設計的代價與邊界

說完原理，我們來講取捨——這套設計在什麼情況下會失靈、什麼場景下反而幫倒忙。

最明顯的代價是上行頻寬消耗。參與 HTTP P2P 網路意味著你也在為別人上傳資料。如果你家裡只有 100KB/s 的上行頻寬（比如某些老小區寬頻），P2P 加速的上傳會把你上行吃滿，反而讓正常上網變卡。這也是為什麼 BitComet 預設提供了上傳限速選項。

隱私是另一個代價。參與 HTTP P2P 加速的隱私影響和 BT 任務類似——DHT 網路是公開的，任何加入 DHT 網路的客戶端都能查到你對哪些檔案雜湊感興趣。版權監控機構同樣會用 DHT 來追蹤侵權行為。BitComet 不內建匿名下載，你的真實 IP 會暴露給對等者。

效果的場景依賴性很強。熱門大檔案（比如剛發布的遊戲、流行的軟體安裝包）是 P2P 加速最有效的場景——下載的人多、BitComet 用戶也多，P2P 通道貢獻可能超過 HTTP 源本身。但冷門小檔案（全網可能就你一個人在下載），P2P 通道永遠找不到對等者，等於這功能不存在。

我的判斷：這套原理意味著什麼

從技術架構的角度看，BitComet 的 P2P 加速是一個非常聰明的設計——它沒有發明新的協定，而是把成熟的 BT 協定堆疊「嫁接」到了 HTTP 下載流程上，用最小的代價換來了可觀的加速收益。

它適合什麼人？有固定寬頻、經常下載熱門大檔案、對下載速度敏感但不太在意隱私的使用者。它不適合什麼人？公司或學校網路環境（BT 協定通常被封）、隱私敏感的使用者、上行頻寬特別寶貴的移動網路用戶。

我個人最欣賞這套設計的一點是它的優雅降級——P2P 通道找不到對等者時，HTTP 下載照常工作，就像沒開 P2P 一樣。沒有強制、沒有彈窗、不會讓原本的任務失敗。這種「加分項而非必需品」的設計哲學，在當今很多軟體越做越重、功能越塞越多的環境下，反而顯得難得可貴。

技術有時就是這樣：最精妙的設計不是發明了什麼全新的東西，而是把已有的零件以最恰當的方式組合在一起。BitComet 的 P2P 加速就是一個很好的例子——BT 協定不是什麼新技術，DHT 網路也不是它發明的，但把它們嵌入 HTTP 下載流程這個點子，讓它在同類產品中脫穎而出。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。