惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
WordPress大学
WordPress大学
人人都是产品经理
人人都是产品经理
Engineering at Meta
Engineering at Meta
小众软件
小众软件
I
InfoQ
有赞技术团队
有赞技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Martin Fowler
Martin Fowler
月光博客
月光博客
雷峰网
雷峰网
aimingoo的专栏
aimingoo的专栏
云风的 BLOG
云风的 BLOG
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
V
Visual Studio Blog
博客园 - 叶小钗
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
GbyAI
GbyAI
P
Proofpoint News Feed
Apple Machine Learning Research
Apple Machine Learning Research

博客园 - papering

由于系统缓冲区空间不足或队列已满,不能执行套接字上的操作 string byte 内存 硬盘 CAS ABA AtomicLong mysql 索引长度限制 docker network FTP Connection Modes (Active vs. Passive) 字符长度 mysql 【车载架构】AUTOSAR CP系列之27:系统内核之 WdgM 看门狗管理 单目录文件数限制 在联表 join 时 使用 case when 按不同的条件关联不同的行 JDK21 Process Reaper TLS 栈溢出循环故障深度分析 栈溢出 写入相邻的内存区域 GCC 的 -fstack-protector 会在每个函数的栈帧底部放一个随机“金丝雀值”,函数返回前检查它是否被改掉,以此检测栈缓冲区溢出。 潜伏5年!GitLab高危RCE漏洞爆发,低权限即可控服 Redis 漏洞分析——lua 脚本篇 Redis guarantees the script's atomic execution. AMQP 0-9-1 连接通过 信道 进行多路复用,信道可以被认为是“共享单一 TCP 连接的轻量级连接”。 WSAETIMEDOUT WSAEACCES This module supports asynchronous I/O on multiple file descriptors. 设置其优先级值的线程的句柄 QT 主线程 优化 卡顿 主线程上的同步重活 防重入:进行中直接 return,避免连点双开。 把「一次性任务」收到 ThreadPoolExecutor(max_workers=2~3),限制峰值线程数 统一 Activity 浮层 去掉连环成功弹窗 为 with语句上下文提供的工具 懒加载 IDE发现 import Canvas 指纹 魔改chromium源码——CDP(Chrome DevTools Protocol)检测01 whether the browser environment is controlled by a robot. chromium指纹魔改 对拷线 rpa 任务编排 a JSON formatted stream to ``fp`` “幽灵字符”问题 浏览器背后的黑科技 多进程 多线程
使用 DHT (Distributed Hash Table,分布式哈希表) 替代 Trac...
papering · 2026-04-16 · via 博客园 - papering

使用 DHT (Distributed Hash Table,分布式哈希表) 替代 Tracker,标志着 P2P 系统从“有中心”进化到了“完全去中心化”。

在这种模式下,每个节点既是客户端,也是微型 Tracker。

1. 核心思想:把目录分散到全球

在 Tracker 模式下,我们要找视频得问“前台”(服务器);在 DHT 模式下,我们直接问“路人”。

  • 资源标识:每个视频文件都有一个唯一的 InfoHash(40位特征码)。
  • 路由表:每个节点在内存中只维护一小部分邻居的信息,而不是全网信息。
  • 逻辑距离:DHT 使用 Kademlia (Kad) 算法。它通过计算 InfoHash 与节点 ID 的距离(异或运算)来找人。

2. 它是如何找人的?(以磁力链接为例)

当你输入一个 magnet:?xt=urn:btih:XXXX... 链接时,没有 Tracker 服务器,寻找过程如下:

  1. 冷启动:你的客户端连接几个预设的“种子节点”(Bootstrap Nodes,如 ://bittorrent.com),进入 DHT 网络。
  2. 递归查询:
    • 你问邻居:“谁离 XXXX 这个哈希值近?”
    • 邻居可能没有,但他会告诉你:“我知道节点 B 离它更近,你去问他。”
  3. 收敛到目标:经过几跳后,你最终会找到几个正好负责维护这个 InfoHash 信息的节点。
  4. 获取 Peer 列表:这些节点会告诉你,目前有哪些 IP 正在下载/分享这个视频。

3. DHT 相比 Tracker 的优劣势

特性Tracker (有中心)DHT (去中心化)
稳定性 服务器宕机则全线崩溃 极强,部分节点离线不影响整体
速度 获取节点列表极快(毫秒级) 初次寻找资源较慢(需几秒到十几秒)
隐私与版权 容易被封杀或监控 极难被彻底关停(磁力链接不死的原因)
维护成本 需支付服务器带宽和硬件费 几乎零成本,压力分散给所有用户

4. 视频传输中的“混合模式”

在现代视频分发(如快播、比特彗星、WebTorrent)中,通常不会二选一,而是两者并行:

  • Tracker 优先:如果 Tracker 能用,秒出节点。
  • DHT 保底/补全:Tracker 没资源时,通过 DHT 去全球“捞”更多节点。
  • PEX (Peer Exchange):节点之间还会互换自己知道的 Peer,进一步减少对 Tracker 的依赖。

5. 局限性

  • 冷门资源困境:如果一个视频全球只有几个人在看,DHT 很难通过逻辑距离算法精准“撞”到这几个人。
  • 流量开销:为了维持 DHT 路由表,客户端即便不下载,也会产生持续的微量上传流量(背景流量)。

应用建议:
如果你在开发一套私有/企业内部的视频分发系统,Tracker 依然是首选(效率高、可控);如果你在做互联网共享或抗封锁的视频应用,DHT 是核心。