- 1 -
中国科技论文在线
Tor 隐匿服务可扩展性研究
韩越，陆天波**
作者简介：韩越（1992-），男，硕士研究生，主要研究方向为网络信息安全、匿名通信系统等
通信联系人：陆天波（1977-），男，副教授，主要研究方向为计算机网络与信息安全等
（北京邮电大学软件学院，北京 100876）
5 摘要：随着网络服务的发展与人们对隐私要求的日益提高。在提供用户通信匿名的基础上，
产生了保护服务器匿名性的需求。第二代洋葱路由 The Second Generation Onion Router
（Tor）的隐匿服务功能就完美地实现了这样的需求。然而自其提出至今已逾 10 年，其隐匿
服务技术并未得到良好的发展。近年来，随着网络服务规模的不断扩大，在 Tor网络上架设
大型网络服务，或将网络服务迁移至 Tor 网络中的需求逐渐增多。然而，在隐匿服务设计之10
初，由于其实现只考虑了单核单线程的情况，并未能充分利用现在流行的多核架构，也不支
持负载均衡等技术。因而，其可扩展性成为了服务提供者需要解决的首要问题。本文通过使
用相同的主机名与私钥运行多个隐匿服务实例来解决其可扩展性问题，并使用 Shadow 在离
线环境下进行仿真，最终通过实验分析了这种方式对 Tor 隐匿服务带来的性能提升及可能存
在的问题。 15
关键词：计算机网络；匿名通信；Tor；隐匿服务
中图分类号：TP393
Tor Hidden Service Scaling
HAN Yue, LU Tianbo 20
(Beijing University of Posts and Telecommunications, Software Engineering, Beijing 100876)
Abstract: With the development of the network services and people's increasing privacy
requirements, a coming grows need of protecting servers’ anonymity has reveal a certain concern.
The Second Generation Onion Router (Tor) can provide the hidden service as a perfect realization
from this demand. The hidden service technology has been published more than 10 years, but 25
rarely you can get some research about it. In recent years, with the continuous expansion of the
network service‘s scale, setting up network services on the Tor network, or migrating some
network services to the Tor network, will encounter a lot of difficulties. However, Tor’s hidden
services in its current state does not fully utilise multi-core architecture or provide any load
balancing options in regards to multi-server systems. Thus, its scalability has become a primary 30
issue that needs to be solved. By using the exact host name and the same private key to run
multiple instances of hidden services, can partially solve their scalability problems. We choose
shadow to do the simulation and the results show that this method can truly improved the
performance of Tor hidden services’ scaling.
Key words: computer network; anonymous communication; Tor; hidden service 35
0 引言
近年来网络服务发展迅猛，网络应用中用户对个人隐私及信息安全的要求日益提升，进
而产生了保护网络服务隐匿性的需求。The Second Generation Onion Router（Tor）[1]匿名通
信系统被称为第二代洋葱路由系统，是目前最为流行的匿名通信解决方案。它能够在抵抗多40
种被动或主动攻击的同时，保持良好的性能。Tor 的低通信延迟、高匿名性、易使用、易部
署等诸多特点使得它在近年来得到飞速发展。现今，全球已有超过 6000 个 Tor 网络结点，
超过 200 万人使用 Tor 网络进行通信。
Tor 于 2004 年便提出了隐匿服务（Hidden Service）的概念[2]。自此，Tor 不仅可以支持
- 2 -
中国科技论文在线
客户端用户完成基本的匿名通信服务，还一定程度上确保了隐匿服务提供方的匿名。通过使45
用 Tor 网络，用户可以匿名地访问该隐匿服务，而隐匿服务提供方也可以维护地理位置不可
知的服务器。
用户需要通过 Tor 指定的顶级域名（Top Level Domain，TLD）.onion 访问隐匿服务。
Tor 网络可以识别自己的 TLD，并自动连接到该隐匿服务。然后，隐匿服务会将收到的请求
交由普通的服务器软件进行处理。 50
虽然 Tor 的隐匿服务发布至今已逾 10 年，但其发展远没有 Tor 本身那样繁盛。隐匿服
务现在处于一个尴尬的境遇。它拥有一定数量的忠实用户群体，但很少有研究学者来专门关
注它。这使得 Tor 隐匿服务仍有许多问题需要研究、实验，以增强其有效性及安全性。且随
着在 Tor 网络上架设大型网络服务，或将网络服务迁移至 Tor 网络中的需求逐渐增多，隐匿
服务的可扩展性自然成为了其需首要解决的问题之一。 55
1 Tor 隐匿服务概述
Tor 隐匿服务基本流程
当某用户希望对外提供 Web 服务或即时通信服务时，Tor 的隐匿服务可以帮助服务提
供者隐藏其物理地址。通过提供“集合结点”（Rendezvous Point，RP），其他用户可以在
对服务提供者除域名信息外一无所知的情况下，顺利访问其隐匿服务[3]。 60
第一步：服务提供方为了能够在 Tor 网络中匿名地对外提供服务，需要对 Tor 网络声明
其存在，将一些必要的信息通报给 Tor 网络。因此，在正式提供服务之前，服务提供方需要
随机选取 Tor 网络中的几个中继结点，与之建立连接，传递服务的公钥，并请求这些中继结
点作为该隐匿服务的介绍结点（Introduction Point， IP）。
如图 1 所示，隐匿服务提供方 Bob 向 IP1，IP2，IP3 分别建立 3 条匿名链路，并请求他65
们成为自己的介绍结点。由于它们之间建立的是 Tor 匿名链路，而非直连，IP1，IP2，IP3
三者只知道其服务相关的公钥，并不知道服务提供方 Bob 的身份或 IP 地址。
图 1 隐匿服务工作流程图 1
The flow chart of hidden service 1 70
第二步：如图 2 所示，Bob 需要为其提供的隐匿服务生成一个隐匿服务描述符。
- 3 -
中国科技论文在线
图 2 隐匿服务工作流程图 2
The flow chart of hidden service 2
该描述符之中应包含：隐匿服务对应的公钥，隐匿服务的介绍结点列表，以及利用隐匿75
服务私钥对该描述符前述部分的签名。
一旦成功生成了隐匿服务描述符，它会被上传到响应的隐匿服务目录服务器以供其他用
户查找。其查找索引形式为“”，其中 XYZ 为根据隐匿服务公钥生成的隐匿服
务名，一般由 16 个英文字母组成。至此，隐匿服务已被成功部署，等待提供服务。
第三步：如图 3 所示，当一个用户想要连接到一个隐匿服务时，他需要事先通过其他途80
径获得该隐匿服务对应的洋葱地址，即前述的“”。得到该地址后，用户通过分
布式哈希表询问对应的隐匿服务目录服务器来获得与之对应的隐匿服务描述符。若存在该描
述符，那么用户就可以知晓匿名服务的介绍结点列表以及其所使用的公钥信息。
于此同时，用户随机挑选一个 Tor 网络中的中继结点，并通过告知该结点一个一次性秘
密信息，来请求其作为该用户的集合结点 RP。 85
图 3 隐匿服务工作流程图 3
The flow chart of hidden service 3
第四步：当用户成功获取了隐匿服务的描述符，并设置了集合结点后，用户需要再构造
一个由隐匿服务公钥加密的消息。该消息需包含：集合结点的地址，以及先前预先协商完成90
的一次性秘密信息。该消息将通过 Tor 链路被发送至隐匿服务的某一个介绍结点，而介绍结
点则会将该消息回传给隐匿服务提供者。如图 4 所示，隐匿服务提供方 Bob 与请求方 Alice
均通过 Tor 链路来进行数据通信，双方的身份信息都不会被泄露，从而保证了各自的匿名。
- 4 -
中国科技论文在线
图 4 隐匿服务工作流程图 4 95
The flow chart of hidden service 4
第五步：隐匿服务提供方 Bob 对用户 Alice 发送来的服务相关消息进行解密，并获得其
中的集合结点地址及一次性秘密信息。随后，Bob 向集合结点建立匿名链路，并向其发送接
收到的一次性秘密信息，如图 5 所示。
100
图 5 隐匿服务工作流程图 5
The flow chart of hidden service 5
第六步：集合结点通知隐匿服务请求者 Alice，自己已成功与隐匿服务提供方建立起链
接。Alice 确认该消息后，便可以利用通过集合结点建立起的匿名链路进行类似于常规 Tor
网络通信的匿名通信。对于隐匿服务提供方亦是如此。 105
该匿名链路与常规 Tor 网络中的匿名链路的主要差别在于，隐匿服务中的匿名链路大多
由 6 个结点组成，长度是常规匿名链路的 2 倍。且在该链路中，集合结点明确知道自己的身
份。
在整个隐匿服务协议的运行过程之中，协议力求保证通信双方的匿名性。协议中所选用
的 IP1，IP2，IP3，以及 RP 均无法确切得知通信双方的身份及地理位置，匿名性由 Tor 链110
路的特性（单个路由无法得知整条链路）提供保障。
Tor 隐匿服务描述符的发布与获取
隐匿服务目录服务器与分布式哈希表
为了连接到特定的隐匿服务，用户客户端需要对该隐匿服务的相关信息进行查询。在
- 5 -
中国科技论文在线
Tor 网络中，该查询服务的实现原理类似于分布式哈希表[4]，可以让隐匿服务的描述符在 Tor115
网络中被结点转发传播。
权威目录服务器（Directory authorities）会对运行超过 24 小时的结点进行投票，来决定
该结点是否有成为隐匿服务目录服务器的资格。这样会确保只有高可靠性的结点才会被选作
隐匿服务目录服务器结点。一旦一个中继结点被授予 HSDir 标记，就意味着它可以作为隐
匿服务目录服务器，有能力处理隐匿服务描述符，并允许用户对其进行上传或下载。 120
一个隐匿服务的描述符会被发布到哪台隐匿服务目录服务器上是确定的。因此，当一个
用户想访问一个特定的隐匿服务时，它可以通过计算得知自己需要向哪台隐匿服务目录服务
器去请求所需的隐匿服务描述符。在同一时刻，网络中会有 6 台隐匿服务目录服务器持有对
同一特定隐匿服务的描述符。并且，每个客户端实例也都会保存一个当前网络中隐匿服务目
录服务器列表的子集。 125
在最初的实现中，Tor 网络中有一组特定的目录服务器用于存储网络中隐匿服务的描述
符。这种实现不能抵抗单点失效，其可扩展性、可用性、抗审查能力等方面也都存在着问题。
而现在的设计则提供了更好的可用性及可扩展性。
分布式哈希表的实现形式使得隐匿服务描述符的存储没有最初设计中那样集中。对于特
定的隐匿服务，如果持有其隐匿服务描述符的一台隐匿服务目录服务器发生故障，网络中还130
会有其他的隐匿服务目录服务器正常工作，便不会导致隐匿服务的描述符获取失败。并且，
这样的设计提高了攻击者针对隐匿服务目录服务器的攻击难度。
隐匿服务描述符的创建及发布
Tor 隐匿服务首先产生两个相同的描述符，不同的描述符会根据其描述符 ID 与得到的
签名进行区分[5]。 135
隐匿服务描述符 ID（Descriptor－id）的计算方法如下：
replicacookiedescriptorperiodtimeHidpermanentHidDescriptor |||
(1)
公式（1）中，H 为一个安全的哈希函数 H，连接起后述多个值。
permanent－id 为隐匿服务公钥截断前 80 位的哈希结果。 140
time－period 为隐匿服务生效时间的 Unix 时间戳。
descriptor-cookie 是一个可选参数，为一个客户端和一个隐匿服务之间用于认证互通而
共同协商的秘密信息。
replica 则标识了哪两个副本被建立，它决定了描述符会发布于分布式哈希表中的位置，
下文会针对此作详述。 145
- 6 -
中国科技论文在线
图 6 隐匿服务描述符在哈希环上的分布
Distribution of hidden service descriptors in the hash ring
完成了描述符的创建后，隐匿服务会发布每个副本到 3 个隐匿服务目录服务器，即共有
6 台隐匿服务目录服务器会持有该隐匿服务的描述符。一个隐匿服务会去权威目录服务器下150
载 Tor 网络结点数据，保留 HSDir 标识的结点信息，并按结点的指纹信息（fingerprint），
即结点公钥的哈希值排列成环状（也称作哈希环）。顺时针顺序，取指纹信息与描述符指纹
相近的三个中继结点作为其隐匿服务目录服务器结点，保存其隐匿服务描述符。隐匿服务描
述符的两个副本都遵循同样的规则。如上图 6 所示，该匿名服务的两个描述符分别选中了
n1，n2，n3 和 k1，k2，k3 作为其隐匿服务目录服务器结点。这种规则使得两个指向同一隐155
匿服务的描述符，能够在 Tor 网络中得到更均匀的分布，从而提高其可用性。
当隐匿服务目录服务器接收到一个隐匿服务描述符时，首先要验证其真实性。它会使用
隐匿服务的公钥来验证其描述符中的签名信息，并将结果与其描述符 ID 做比对。另外，如
果该隐匿服务目录服务器上已经存储了同一隐匿服务的描述符，则会对其进行更新。
通常情况下，隐匿服务会每隔一小时重新发布它的描述符。另外，在检测到隐匿服务目160
录服务器发生变更或介绍结点失效时，隐匿服务也会更新其描述符至对应的隐匿服务目录服
务器。
隐匿服务描述符的获取
对于一个想要连接到隐匿服务的客户端，它需要先去获取隐匿服务对应的有效描述符。
当客户端持有该隐匿服务描述符的缓存时，它会尝试直接与之建立连接。如若失效，则165
需要去重新获取。
与隐匿服务发布其描述符类似，客户端首先通过权威目录服务器下载 Tor 网络结点的数
据，并获取其中包含 HSDir 标识的结点，根据其指纹排列成环。然后，客户端会根据欲连
接的隐匿服务的 ID 来计算可能含有该隐匿服务描述符的隐匿服务目录服务器地址集合。该
集合一般含有 6 个结点，客户端会随机选择其一，对隐匿服务描述符进行获取。如若失败，170
则会依次尝试。
2 可扩展的 Tor 隐匿服务
在最初的设计实现中，Tor 的隐匿服务并非针对多服务器系统，也没能充分利用多处理
器架构，或提供负载均衡功能。而随着近年来网络服务的迅猛发展，在 Tor 网络上架设大型
网络服务的需求逐渐增多。因此，其可扩展性成为了服务提供者需要解决的首要问题。 175
目前，隐匿服务并不能很方便地进行扩展。大型网站很难在不改变其现有体系结构的情
况下，以隐匿服务的方式迁移到 Tor 网络中。这其中最主要的问题便是，隐匿服务需要通过
介绍结点接入隐匿服务。一个隐匿服务描述符只能对应 3 到 10 个介绍结点。而大多介绍结
点只是普通的中继结点，有着有限的带宽，并不善于处理大规模的流量。
其次，隐匿服务本身缺乏对负载均衡的支持[6]。虽然我们可以使用 TCP/HTTP 负载均180
衡工具（例如 HAProxy 等）来进行初步的负载均衡，但并没有类似 DNS 轮询这样的技术来
将客户端分配到不同的 IP 上。我们可以设立很多相同的隐匿服务当作“子服务“，通过增加
描述符数量来达到类似的效果。这样的方式虽然在结果上有一定的吸引力，但同时又会引入
更多的问题，比如子服务间的通信、长期密钥的存储、介绍结点的分配等等。
综上所述，对 Tor 隐匿服务可扩展性的改进大体可以通过两种方式解决。一是针对提供185
隐匿服务的服务器自身的改进。我们可以简单地加强其硬件等资源，使其拥有诸如更多的内
- 7 -
中国科技论文在线
存，更快的 CPU；或者改进其体系架构，使其更有效地利用现有资源，以更低的成本完成
性能的调优。二是针对隐匿服务工作方式的特殊性，在请求来临时，将不同请求派发到指向
不同实例的介绍结点，进行有效的流量分发、使负载均衡。
在这里，我们重点关注后者。在接下来的实验中，我们会使用相同的主机名和公钥运行190
多个隐匿服务实例，通过实验来探究这种方式对提升隐匿服务性能带来的收益，并进一步探
究运行的实例个数对提升性能的影响。
3 实验
实验工具
Tor 网络当前拥有数千个结点，用户数量也在与日俱增。如何在 Tor 网络上进行相关实195
验成为了一个较为重要的问题。而局域网仿真，即是解决该问题的一个重要方法。
Shadow
[7]是一个离散事件网络仿真器。它允许用户在其上建立、仿真一个含上千结点的
大型 Tor 网络，以获得网络负载和性能相关的重要参数。同时，Shadow 也是一个重要的调
试工具，在其上可以运行关于 Tor 的相关确定性实验，在学术界广受追捧。Shadow 在现有
版本中已经直接附带了 Tor 网络的几种基本配置，用以帮助用户迅速地实现 Tor 网络仿真的200
起步工作。
Shadow 的 Tor 插件允许用户通过 XML 文件来定义、配置其网络拓扑和网络流量，甚
至还可以定义 Tor 的相关配置文件，比如各种结点配置等。在实验结束时，Shadow 还能产
出详细的日志文件，描述了各结点 CPU、内存使用情况，生成、接收到的流量等一系列具
体信息。 205
Shadow 附带了很多实用的日志分析工具，并支持自定义生成实验结果的图表。后文中，
我们通过在实验中监控隐匿服务结点的使用情况来确定其性能，图表结果大多来源于此。
实验设计
接下来，我们将进行两组实验，一是通过负载均衡实验来评估这种扩展方式的性能，二
是通过故障之后的服务切换来衡量其可靠性。 210
在负载均衡实验中，我们会记录各个隐匿服务实例对客户端请求的响应数据，也会探究
隐匿服务使用的实例数量是否会对整个系统的性能产生影响。而在故障转移实验中，则会重
点关注在某实例发生故障后，流量重新建立的时间开销，来衡量隐匿服务的可靠性。
实验中，我们选用 Shadow 对 Tor 网络进行仿真，并保证实验环境的一致。本文所有实
验皆运行于同一台 8G 内存的笔记本，且 Shadow 中对 Tor 网络拓扑结构的设置除隐匿服务215
结点外完全相同。每个实验都会仿真 5000Ticks（Shadow 中的时间计量单位）。由于计算机
内存限制，网络拓扑由一个权威目录服务器、30 个中继结点、10 个出口结点、30 个隐匿服
务客户端及若干隐匿服务服务器组成。
实验将模拟一个简化的 Tor 网络，所有隐匿服务客户端都会重复地向同一个.onion 地址
发送数据包。在负载均衡实验中，所有的隐匿服务服务器会在实验周期中正常运行；而在故220
障转移实验中，一台隐匿服务服务器会在 3000ticks 时停止服务。
在这两个实验中，我们会分别运行 1、2、3、6 个隐匿服务实例，以观察运行更多的实
例是否可以得到更好的性能与可靠性，或者反之亦然。
- 8 -
中国科技论文在线
实验结果
负载均衡实验 225
图 7 负载均衡实验（隐匿服务实例数 1）
Load balancing experiment (hidden service instance number: 1)
图 8 负载均衡实验（隐匿服务实例数 2） 230
Load balancing experiment (hidden service instance number: 2)
- 9 -
中国科技论文在线
图 9 负载均衡实验（隐匿服务实例数 3）
Load balancing experiment (hidden service instance number: 3)
235
图 10 负载均衡实验（隐匿服务实例数 6）
Load balancing experiment (hidden service instance number: 6)
图 7 至图 10 展示了隐匿服务实例个数分别为 1、2、3、6 时，各隐匿服务实例接收流量
随时间变化的曲线。
如图 8 所示，在只包含 2 个隐匿服务实例的情况下，其中一个隐匿服务实例240
“hiddenserver1～”接受了约 360MiB 的请求流量，占总流量的 56%，而另一个实
例“hiddenserver2～”占据 44%。可见，流量确实被分发到两个实例上，且较为均
匀。从而，我们通过实验也证实了，通过运行多个 Tor 隐匿服务实例，确实可以起到简单的
负载均衡效果，来增加其性能。
但是随着实验中我们对隐匿服务实例数量的增加，流量分配开始变得不均。如图 9 所示，245
实验在 3 个隐匿服务实例下进行，其中一隐匿服务“hiddenserver3～”被分配到了
约 330MiB 的流量，约占整体的 50%，而其他两个隐匿服务实例，“hiddenserver1～”
与“hiddenserver2～”，分别只分配到约 32％和 18％的流量。
- 10 -
中国科技论文在线
我们再观察图 10，在运行 6 个隐匿服务实例的实验中，只有其中 4 个隐匿服务实例接
收到了流量，另外两个实例“hiddenserver5～”与“hiddenserver6～”所接250
收到的流量占比甚至不到总量的 0%。
由此可见，随着运行隐匿服务实例个数的增多，这种通过简单运行多实例的方式带来的
负载均衡效果将越来越差。
对比这些隐匿服务各自发布描述符的时间，我们猜测，隐匿服务实例接收到的流量与匿
名描述符发布时间也有着紧密的联系，最先发布描述符的隐匿服务实例往往会接收到更多的255
流量。
图 11 同数量隐匿服务实例下载 1MiB 所需时间
Time cost of downloading 1Mib file for different number of hidden service instances
再来看图 11，它展示了分别运行 1、2、3、6 个隐匿服务实例的情况下，隐匿服务客户260
端接收固定字节文件（1048576 bytes）所消耗时间的曲线。我们可以明显发现，运行多个实
例的隐匿服务完成下载的时间大幅少于单实例。因此，我们可以得出结论，一个隐匿服务运
行更多的实例，会让用户得到更快的响应时间，性能得到显著提升。
失效转移实验
在失效转移实验中，我们同样会分别运行具有 2、3、6 个实例的隐匿服务，但会在各实265
验大约一半的时间时（3000ticks），关闭其中一个隐匿服务实例。
按照 Tor 隐匿服务协议，当这一情况发生时，原本连接到那台失效的隐匿服务实例上的
客户端会查询之前获取到的隐匿服务描述符缓存，选择另一个介绍结点，试图与隐匿服务恢
复连接。直到检测到所有介绍结点皆失效，才会到目录服务器重新获取新的描述符，继而连
接到隐匿服务（另外一个有效的实例上）。 270
- 11 -
中国科技论文在线
图 12 失效转移实验（隐匿服务实例数 2）
Failure transfer experiment (hidden service instance number: 2)
图 13 失效转移实验（隐匿服务实例数 3） 275
Failure transfer experiment (hidden service instance number: 3)
- 12 -
中国科技论文在线
图 14 失效转移实验（隐匿服务实例数 3，启动时间不同）
Failure transfer experiment (hidden service instance number: 3, with different startup time)
图 12 至图 14 展示了各隐匿服务实例接收流量随时间变化的曲线。后缀带有“will_stop”280
的隐匿服务实例会在 3000 ticks 处关闭，表现为 3000 ticks 后该实例服务的流量将不再变化，
如图中水平直线所示。
观察图 12、图 13，当一台隐匿服务失效后，其他的隐匿服务很快便承担了其流量。究
其原因，在这两个实验中，各隐匿服务实例在最开始同时发布了其描述符至相应的匿名服务
目录服务器，因而，在遇到某一隐匿服务实例失效时，通过重新获取隐匿服务描述符，便可285
得到能够有效连接到隐匿服务的介绍结点列表。
我们偶然发现，如果隐匿服务开启时间不同，所得到的结果也会不同。如图 14 所示，
在这个实验中，一个隐匿服务实例“hiddenserver_will_stop～”在其他实例运行后
开启，因此这个实例的描述符在上传后会替换所有相应隐匿服务目录服务器上的描述符。在
这之后连接隐匿服务的客户端所获取的描述符都会指向该最近启动的隐匿服务实例。如若此290
时这个实例关闭，客户端便无法获取到有效的隐匿服务描述符，直至其他有效的隐匿服务更
新其描述符。
这正如图 14 所展示的一样，在 3000ticks 后，客户端由于无法获取到有效的隐匿服务描
述符，在一定时间内会导致整个隐匿服务的失效。直至 4000ticks，其有效的隐匿服务实例
定期更新其描述符，才使得客户端可以获取到有效的隐匿服务描述符，流量与服务才得以恢295
复。
实验结论
通过实验，我们可以确认运行多个隐匿服务实例可以完成对请求流量分配的原因。
第一，在任意给定时间，隐匿服务目录服务器上对于一个隐匿服务可能持有不同的描述
符。有的指向实例 a，有的指向实例 b。 300
即使所有的隐匿服务实例同时开启并发布他们的描述符。隐匿服务目录服务器接收到描
述符的时间也可能会不同。因为隐匿服务会定期更新它的描述符，所以每个隐匿服务目录服
务器只会使最新获取的描述符生效。
第二，客户端决定访问哪个目录服务器获取描述符是随机的。在真实 Tor 网络中，描述
- 13 -
中国科技论文在线
符的同时发布很难实现。这就导致隐匿服务目录服务器很可能只保存了刚刚开启的实例的描305
述符，而没有保存另外其他的描述符。
但是，因为每个隐匿服务实例需要一定周期才会更新其描述符，所以网络中一段时间中
存储的描述符会发生变化。这样会使所有的新连接都链接到最新的隐匿服务实例上，以达到
流量的动态分配。
4 总结与展望 310
本文介绍了 Tor 隐匿服务的设计原理，且通过实验证实了通过运行多个 Tor 隐匿服务实
例，更准确的说目录服务器持有指向不同实例的描述符，可以起到分散负载的作用。这在一
定程度上提高了 Tor 隐匿服务的可扩展性。通过负载均衡实验，揭示了实例数量与最终负载
均衡、性能提升的对应关系。并通过失效转移实验暴露出了该方法所存在的一些问题。这些
都为在 Tor 中架设大型隐匿服务时所需的相关配置提供了非常可观的参考价值。 315
由于工作量和时间的关系，本文只探讨了隐匿服务可扩展性方面的问题与解决方案。
Tor 隐匿服务还存在着很多的问题等待完善。在解决其可用性与可扩展性之后，随着隐匿服
务的普及，它需要大量的研究者们投身于其安全性上的改进。毕竟，大规模网络服务技术已
经相当成熟，而隐匿服务，多了一份保护服务提供者的隐匿性的责任，需要在现有技术之上
做出更多的努力。 320
[参考文献] (References)
[1] Dingledine R, Mathewson N, Syverson P. Tor: The second-generation onion router[R]. Washington DC: Naval
Research Lab, 2004.
[2] Guitton C. A review of the available content on Tor hidden services: The case against further development[J].
Computers in Human Behavior, 2013, 29(6): 2805-2815. 325
[3] Lenhard J, Loesing K, Wirtz G. Performance Measurements of Tor Hidden Services in Low-Bandwidth Access
Networks[J]. Lecture Notes in Computer Science, 2009, 5536: 324-341.
[4] Hopper N, Vasserman E, Chan E. How much anonymity does network latency leak?[J]. ACM Transactions on
Information and System Security (TISSEC), 2007, 13(2): 82-91.
[5] Hopper N. Challenges in Protecting Tor Hidden Services from Botnet Abuse[J]. Springer Berlin Heidelberg, 330
2014, 8437: 316-325.
[6] Øverlier L, Syverson P. Improving efficiency and simplicity of Tor circuit establishment and hidden services[J].
Springer Berlin Heidelberg, 2007, 4776: 134-152.
[7] Jansen R, Hooper N. Shadow: Running Tor in a box for accurate and efficient experimentation[R].
Minneapolis: Department of Computer Science and Engineering University of Minnesota, 2011. 335
