010、暗网技术基础：Tor、I2P与Freenet架构对比

原创于 2026-04-19 08:16:02 发布 · 387 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#架构

从 IPFS 到暗网网关：探究全球分布式图书馆的底层技术实现专栏收录该内容

20 篇文章

订阅专栏

从一次诡异的网络超时说起

排查一个分布式存储节点的异常时，发现某个欧洲节点的请求延迟曲线呈现奇怪的“双峰分布”——一部分请求稳定在200ms内，另一部分却总是卡在30秒超时边缘。抓包看到TCP握手成功，但TLS协商始终悬在半空。同事随口提了句：“这节点会不会走了Tor出口？” 一句话点醒了我。在/etc/proxy环境变量里果然发现了socks5://127.0.0.1:9050的残留配置。这让我重新意识到，很多看似玄学的网络问题，背后可能藏着匿名网络的技术栈。

今天我们就拆解三种主流的暗网架构：Tor、I2P和Freenet。它们都喊着“去中心化”和“隐私保护”的口号，但设计哲学和实现路径截然不同。理解它们的差异，不仅能帮你避开我踩过的坑，还能在架构选型时多几个维度思考。

Tor：洋葱路由的经典实现

Tor的核心思想其实很直观——把数据像洋葱一样层层加密，每经过一个中继节点就剥开一层。但这个比喻容易让人误解，实际流量更像“套娃”：出口节点看到的是最内层明文，入口节点看到的是最外层加密。

# 伪代码示意Tor的加密层次（实际使用AES等算法）
def build_tor_circuit():
    # 客户端先选三个中继：Guard、Middle、Exit
    circuit = [guard_node, middle_node, exit_node]
    
    # 从出口节点开始反向协商密钥
    for node in reversed(circuit):
        # 每层使用不同的会话密钥
        encrypt_with_layer_key(node.session_key)  # 这里别用ECB模式，踩过坑
        
    # 最终数据包结构：
    # [加密给Guard的[Middle地址+加密给Middle的[Exit地址+加密给Exit的[原始数据]]]]

Tor的最大优势是兼容性。你几乎可以用它代理任何TCP流量，这也是为什么那么多“暗网版”的网站都跑在Tor上。但代价是入口和出口节点成为天然瓶颈。我监测过某个热门出口节点的流量，峰值时它要承载上千个并发连接的解密压力，延迟波动能达到秒级。

调试Tor网络时有个技巧：观察目录权威（Directory Authority）的共识文档。里面会列出所有中继节点的带宽权重和状态标志。如果发现“Exit”标签的节点数量突然下降，很可能意味着某个数据中心在批量封禁IP。

I2P：专注于隐藏服务的内部互联网

I2P的设计者显然研究了Tor的痛点。他们放弃了“出口节点”这个概念，整个网络只服务于I2P内部的“.i2p”域名。这相当于构建了一个完全隔离的覆盖网络（Overlay Network）。

I2P的路由表维护方式很特别。每个节点会维护一批“隧道”——单向的虚拟路径，入站和出站隧道是分开建立的。消息通过Garlic Routing（大蒜路由）传递，这个名字起得形象：你可以把多条消息像蒜瓣一样包在同一个加密包里。

// I2P的隧道构建逻辑（简化版）
class Tunnel {
    List<Hop> inboundTunnel;   // 入站隧道
    List<Hop> outboundTunnel;  // 出站隧道
    
    void forwardMessage(Message msg) {
        // 消息先用自己的出站隧道
        sendToNextHop(outboundTunnel, msg);
        
        // 接收方通过其入站隧道回复
        // 这里有个坑：隧道生命周期太短会导致频繁重建
        // 建议根据网络质量动态调整隧道长度
    }
}

I2P的Kademlia DHT实现比Tor的目录服务更去中心化，但代价是新节点引导时间更长。我测试过，在NAT后启动一个I2P节点，有时要花20分钟才能建立稳定的隧道网络。不过一旦跑起来，流媒体这种连续数据流的性能反而比Tor好，因为它允许端到端的流量整形。

Freenet：为内容永存而生的分布式存储

如果说Tor和I2P关心的是“路径匿名”，那么Freenet追求的是“内容匿名”。它的设计目标更激进：即使节点运营者自己，也无法知道本地存储了哪些内容。

Freenet使用基于内容哈希的密钥（CHK）来寻址文件。文件被分割成加密块，每个节点只存储自己“邻近”的块。请求文件时，节点会沿着密钥空间跳转，像在Chord DHT里查找一样。

// Freenet的数据块请求流程（概念代码）
int fetch_chk(CHK key) {
    Node* current = self;
    while (!has_local_chunk(key)) {
        // 找离key更近的邻居
        Node* next = find_closest_neighbor(key);
        if (next == current) break;  // 死循环保护
        
        // 把请求转发过去（不暴露自己是请求源）
        forward_request(next, key);
        current = next;
    }
    // 返回时数据块沿原路加密传回
    return decrypt_chunk(ciphertext);
}

我在2015年做过Freenet的存储实验，上传一个10MB的PDF，两天后发现它已经“漂移”到了三个大洲的节点上。更神奇的是，即使原始上传者下线，文件依然可访问——只要还有节点缓存着这些块。但这种设计对动态内容极不友好，更新一个文件需要发布新版本，旧版本还会在网络里残留很久。

横向对比与选型思考

把三者的架构差异列出来，你会发现它们其实代表了三种不同的哲学：

维度	Tor	I2P	Freenet
核心目标	匿名访问明网	隐藏服务内部通信	抗审查内容存储
网络拓扑	星型（目录权威）	分布式哈希表	结构化P2P网络
延迟特性	出口依赖导致波动大	隧道内相对稳定	检索时间不可预测
数据持久性	不保证	会话级	永久存储（可能）

实际工程中怎么选？我的经验是：

用Tor：当你需要临时匿名访问现有互联网服务，或者快速搭建一个暗网站点。但记住出口节点可能被污染，传输大文件时一定要端到端加密。

用I2P：构建需要长期运行的隐藏服务，特别是P2P应用。它的自包含网络设计避免了出口节点瓶颈，但准备好应对NAT穿透问题。

用Freenet：存档那些“希望被永久保存”的静态文档。别用它做实时通信，它的存储逻辑决定了同步延迟可能以天为单位。

调试暗网应用的几个私房技巧

延迟诊断：Tor的延迟高峰往往在UTC时间下午（欧洲用户活跃），I2P的隧道重建高峰在整点附近（很多客户端默认60分钟生命周期）。
内存管理：I2P的Java实现容易堆内存泄漏，记得加-XX:+UseG1GC参数。Freenet的本地存储默认不限大小，一定要设配额。
匿名性误区：没有哪种架构能提供绝对匿名。Tor的入口节点可能被监控，I2P的隧道首跳可能被识别，Freenet的请求模式可能被分析。永远采用“深度防御”策略。
协议兼容：很多自称支持暗网的应用，其实只做了Tor的SOCKS代理适配。如果要兼容I2P，得自己实现SAM协议；对接Freenet得用FCP协议。

最后说点感性的。研究这些暗网技术多年，我越来越觉得它们本质上是“分布式系统在极端约束下的特化版本”。Tor的目录共识算法、I2P的隧道流量均衡、Freenet的缓存淘汰策略，每一个细节都在匿名性、可用性和性能之间做艰难取舍。

下次当你设计一个需要隐私保护的P2P系统时，不妨问问自己：我的场景更接近三者中的哪一个？答案往往能帮你避开大量重复造轮子的时间。

毕竟，好的工程决策从来不是选“最先进”的技术，而是选“最合适”的架构。在这个监控无处不在的时代，理解这些底层设计，或许某天能帮你保住那些不该消失的数据。