DHT 是什么？BitTorrent 分布式哈希表实用指南
深入理解 BitTorrent DHT 如何用基于 Kademlia 的分布式 Peer 发现机制替代中心化 Tracker。
BT9G / ENGINEERING NOTES
BT9G Labs
理解去中心化发现背后的协议与系统。
深入讲解 BitTorrent、DHT、元数据交换、Peer 发现与分布式搜索基础设施的工程实践。
01
精选指南
02
浏览 DHT 深度系列
DHT 基础
DHT 是什么？BitTorrent 分布式哈希表实用指南
深入理解 BitTorrent DHT 如何用基于 Kademlia 的分布式 Peer 发现机制替代中心化 Tracker。
Kademlia 原理详解：XOR 距离、路由与 BitTorrent DHT 的可扩展性
从工程角度理解 XOR distance、迭代查询、并行度和 k-bucket，以及它们如何让 BitTorrent DHT 在大规模网络中工作。
BitTorrent DHT 如何找到 Peer：从 Bootstrap 到 get_peers 与 announce_peer
完整追踪 BitTorrent DHT 从空 routing table 启动、建立节点知识、查询 Swarm 到获得可用 Peer 的全过程。
InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 与 BTMH
理解 BitTorrent 内容标识如何计算，以及 v1 SHA-1、v2 SHA-256、BTIH 与 BTMH 在 Magnet 链接中的关系。
BEP 5 DHT 报文详解：ping、find_node、get_peers 与 announce_peer
从报文级别理解 BEP 5 定义的 KRPC 封装和四类核心 BitTorrent DHT 查询。
DHT Routing Table 内部原理：k-Bucket、节点 Churn 与联系人选择
理解 k-bucket 如何组织 DHT 联系人、为什么稳定节点更有价值，以及 routing table 如何在高 churn 网络中保持可用。
协议、Peer 与元数据
为什么 DHT 会看到海量 InfoHash？理解互联网规模的 Swarm 发现
解释 DHT 观察者为什么会持续看到大量 InfoHash，其中同时包含活跃、重复、陈旧和低质量信号。
DHT Crawler 如何发现 InfoHash：主动查询、网络观察与负责任设计
从系统角度解释 DHT crawler 如何发现 InfoHash，以及为什么发现、Metadata 获取和索引必须拆成不同流水线。
Magnet 链接如何变成文件 Metadata：完整 Peer 与 Metadata 流程
从 Magnet 中的 InfoHash 出发，追踪 DHT Peer 发现、BEP 10 扩展协商和 BEP 9 Metadata 获取的完整链路。
BEP 9 ut_metadata 详解：如何从 Peer 获取 Torrent Metadata
技术解析 BEP 9 的消息类型、Metadata 分片、哈希校验以及高并发 crawler 中的调度细节。
BEP 10 Extension Protocol：BitTorrent 如何在不破坏兼容性的情况下扩展能力
理解 extended handshake、动态消息 ID，以及为什么 BEP 10 是 ut_metadata、PEX 等扩展能力的基础。
Tracker vs DHT vs PEX：三种 BitTorrent Peer 发现机制对比
比较中心化 Tracker、去中心化 DHT 和 Peer Exchange，理解三者如何以不同方式共同解决 Peer 发现。
Seeders 与 Leechers：数字代表什么，又是如何统计的？
理解 Seeder、Leecher、Tracker scrape 计数、DHT 的统计限制，以及为什么全球 Swarm 规模很难被精确测量。
为什么 Torrent Metadata 获取会失败？10 个真实原因与更好的重试模型
诊断 Metadata timeout、冷 Swarm、扩展不支持、坏 Peer 和调度错误，并构建更合理的长期重试策略。
爬虫工程
高性能 DHT Crawler 架构：队列、背压与资源边界
设计高吞吐 DHT observation 系统：高效 UDP 处理、有界内存、职责分离、异步 Metadata worker 与 backpressure。
每分钟获取 1,000+ 条 Torrent Metadata，需要什么样的架构？
围绕成功吞吐、Peer discovery、连接成功率、timeout budget 和调度并发，反推千条/分钟级 Metadata pipeline。
数十亿 InfoHash 如何去重？避免重复 Metadata 工作的多层设计
用 exact key、Bloom filter、热缓存和持久化状态构建多层 InfoHash 去重系统，降低大规模 DHT 采集成本。
为什么失败的 InfoHash 也应该保留：长期重试调度器设计
设计能够保留历史哈希、对冷 Swarm 做退避，并在新活动出现时快速重新激活的长期 Metadata 重试系统。