BT9G LABS / DHT 深度解析 #13

Seeders 與 Leechers：數字代表甚麼，又是如何統計的？

理解 Seeder、Leecher、Tracker scrape 計數、DHT 的統計限制，以及為甚麼全球 Swarm 規模很難被精確測量。

BT9G Labs發布於 2 分鐘閱讀

BT9G Labs / DHT Deep Dive #13. 區分協議定義、Tracker 統計和搜索站展示值，避免把估算指標包裝成精確的全球實時人數。

Seeders 與 Leechers：數字代表甚麼，又是如何統計的？

快速摘要

  • 主題: Seeders 與 Leechers：數字代表甚麼，又是如何統計的？
  • 核心關鍵詞: Seeders, Leechers, Tracker scrape, Swarm size, DHT
  • 適合讀者: 後端工程師、協議研究者、搜索工程師以及 BitTorrent 實現者
  • 目標: 用足夠準確的協議與系統視角解釋原理，並能直接支持真實的採集、索引和搜索架構設計。

系統視圖

先把定義說清楚

Seeder 通常指已經擁有完整內容、仍然向其他 Peer 上傳的參與者；Leecher 一般指還沒有完整內容、正在下載並可能同時上傳的 Peer。但不同 Tracker 或產品在邊界條件上可能採用略有差異的統計方式。

更重要的是，這些數字通常不是某個全球權威中心實時匯總出來的，而是特定觀察源在特定時間看到的狀態。

Tracker scrape 為甚麼常見

支持 scrape 的 Tracker 可以針對 InfoHash 返回 complete、incomplete、downloaded 等計數。這些資料非常適合展示該 Tracker 自己掌握的 Swarm 狀態，而且比單純從 Peer 地址猜測 Seeder 更有明確語義。

但一個 Torrent 可能同時使用多個 Tracker、DHT 和 PEX。不同 Tracker 的 Peer 集合可能重疊，因此不能把多個 scrape 數字直接相加。

DHT 為甚麼不能直接給精確 Seeder 數

BEP 5 的 get_peers 主要返回可聯繫 Peer endpoints，並不為每個 endpoint 標注“我是否已經擁有 100% 內容”。單次 DHT 查詢也只能看到局部候選，而不是全網完整參與者集合。

因此僅靠 DHT 很難得出嚴格的 Seeder/Leecher 全球精確數。你可以測量近期可見 Peer、成功連接數、活躍時間等，但應該用更準確的產品名稱。

更好的產品語義

搜索站如果無法獲得可靠 scrape，最好展示諸如“recent peers observed”“last active”“activity score”這類與真實測量方式一致的欄位，而不是製造看似精確的 Seeder/Leecher 數字。

如果確實展示 Tracker 資料，也可以標注來源和採樣時間，讓使用者知道這是某個 Tracker 的 snapshot，而不是全局真值。

實現示意

{
  "source": "tracker_scrape",
  "infohash": "...",
  "complete": 142,
  "incomplete": 37,
  "observed_at": "2026-09-16T03:00:00Z"
}

BT9G Labs 工程筆記

對 BT9G 一類索引系統而言，最重要的不是單純追求事件數量，而是把內容身份、網路觀察、採集狀態和搜索文檔拆成清晰的資料層。所有來自 DHT 或 Peer 的欄位都應該保留來源與時間戳，並通過階段化指標區分發現、連接、協商、Metadata 獲取、校驗、入庫和索引等環節。這樣才能在規模擴大後定位真實瓶頸，而不是把所有失敗都歸因於“網路不穩定”。

常見誤區

  • 把 Seeder 和任意活躍 Peer 視為同義詞。
  • 把多個 Tracker scrape 計數直接相加。
  • 從 DHT endpoint 數量推導精確 Seeder 數。
  • 展示統計值卻不記錄採樣時間與來源。

相關 BT9G Labs 文章

參考資料

下一篇: 為甚麼 Torrent Metadata 獲取會失敗？10 個真實原因與更好的重試模型 →

本文用於解釋公開的 BitTorrent 協議與工程實現思路，不代表任何被觀察到的 Swarm 一定可用、有效或被授權傳播。