1. 简介

Tor网络是数字隐私最流行的工具之一。各种不同的用户使用其洋葱路由协议来保护他们在互联网上产生的隐私信息。截至2016年5月，该网络包括7000个自愿运行的中继向用户目的地转发流量，网络共同转发近75Gbps的流量，并且估计每天有175万用户连接。
统计数据对于了解Tor目前的影响力以及如何改进服务至关重要。然而，由于其保护隐私，典型的网络监控方法不能直接应用于Tor。例如，简单地衡量用户数量是非常困难的，因为Tor旨在让用户保持匿名，并且也不应收集有关用户身份的信息。Tor目前收集了很少的测量数据，其中许多使用了未知精度的启发式技术。
在差分隐私保护和实用隐私保护聚合的基础上开发了PrivCount，一种高效，灵活的系统，用于在隐私保护下的Tor测量。PrivCount增加了可重复的测量阶段，以便进行迭代测量。它还提供了一个综合的方法来应用差分隐私多元化和多样化的Tor统计，同时保持了高精度。开发了一个实现PrivCount的开源工具，该工具强大，安全，特别适用于Tor的研究。
用PrivCount工具对Tor用户和流量进行测量研究，对PrivCount的研究部署涉及到4个不同国家的6个独立参与者，想要破坏系统的安全属性，需要让所有参与者都妥协。测量汇总在7个Tor中继上进行，这可以防止根据流量特征来识别来源。
收集了客户端和目的地的统计数据，目标是为将来的Tor业务模型做参考和网络改进。在出口流量方面的结果表明，Web端口的流量现在占Tor的数据字节的91％，高于2010年的42％。还使用完全不同于Tor自测量的的方法第一次提供了Tor用户数量的估计。数据表明，在任何给定的10分钟内，平均有71万用户连接到Tor，其中超过55万（77％）是活跃的。也看到了出口策略的效果，这些策略会被传递以限制将连接到哪些端口和IP，并且证据表明出口策略会显着影响出口中继的流量类型，这是以前的研究没有考虑的因素。

2 PrivCount隐私计数

为了安全地收集Tor网络的统计数据，设计和实现了一个名为PrivCount的隐私保护数据收集和聚合系统。

2.1 角色和体系结构概述

PrivCount是一个分布式计数系统，依靠多个节点和实体来实现隐私和安全。PrivCount部署包含Tally服务器（TS）节点，一个或多个数据收集器（DC）节点以及一个或多个共享管理器（SK）节点。
Tally服务器。TS是系统的中心点。TS在认可DC和SK节点之前先验证它们，跟踪它们的可用性和状态，并同步系统操作。为了最小化PrivCount部署的攻击面，TS充当其他节点之间所有通信的中央代理。TS服务器端口是唯一需要在整个PrivCount系统中打开并可通过Internet访问的端口;DC和SK仅与TS建立连接。DC和SK之间的所有通信都被加密和认证，因为TS仍然不可信。
数据收集器 DC是处理测量的主要节点。DC负责从本地运行的Tor进程收集事件，计算事件的统计数据，并维护一段时间内每个统计数据的计数。每个计数器用随机噪声加共享数进行初始化。噪声用于提供最终汇总值的差分隐私。共享数用于“致盲（blind）”计数器;共享数被每个SK加密一次，然后在DC被擦除之前，每个数都被发送到相应的SK（通过TS代理）。这个过程确保转发隐私：任何DC泄漏都不会泄漏超过本地计数器的值（计数器会随机出现）。DC在采集期间对计数器进行重新计数，然后在汇总期间将最终计数（真实计数，噪声和共享数的总和）发送给TS。
共享管理器 SK负责存储由DC分配给它的共享数;对于每个计数器，每个SK将从每个DC收到一个共享值。在汇总过程中，对每个计数器，每个SK将它们从DC接收到的共享值求和，并将总和发送给TS。一旦TS收到来自DC的所有计数和来自SK的所有总计共享值，TS将来自每个计数器的所有DC的计数相加，然后通过减去总计的共享值来“去致盲”每个计数器。每个计数器的最终总计数只有在所有SK的所有总和秘密都被移除后才有意义。只要至少有一名SK在秘密数求和中诚实行事，TS就无法学习单独的DC数量，并且除了最终的汇总计数没有任何数据暴露，但最终最终的汇总计数受到差别隐私保护。（所以使用多个SK是为了保证安全）。

2.2 协议规范

考虑使用一个telly服务器T，n个数据收集器Di，和m个共享管理器Sj，j∈来部署PrivCount。此外，假设正在收集l个统计数据;令sk为第k次统计的计算值k∈{1，…，l}。统计值可以是单个整数或表示成直方图的整数向量。单个数是用一个计数器实现的的一个整数，是PrivCount中的基本数据结构。
PrivCount的目标是保护隐私的同时测量所有统计数据，然后只显示所有DC中汇合的差分隐私计数，即计算∑i=1nski+Nki\sum_{i=1}^ns_k^i+N_k^i∑i=1n​ski​+Nki​，其中+Nki+N_k^i+Nki​是Di的（ϵ，δ）-差分隐私随机噪声组件。
PrivCount将实现这种汇合的步骤分成许多阶段，这些阶段允许一个迭代的收集过程，在这个过程中可以使用初始结果来影响后来的数据收集。此设计在测量类型和长度方面具有灵活性，运行协议的独立参与方之间的协调最少，同时仍保持其安全属性。因为操作人员是这一过程的关键组成部分，所以在描述中包含操作人员如何与自动化系统进行交互。PrivCount的操作阶段如下：

2.2.1 初始化

初始化阶段包含所有需要DC和SK操作员参与的操作。PrivCount将操作员之间的协调集中在开始阶段，其后阶段仅由TS操作员自行决定多次执行。
在此阶段，TS操作员应该为TS配置一份将在所有协议参与者之间共享的部署文档。部署文档包含所需DC和SK的公钥。它还包括以下参数来控制加入统计数据的保护隐私的噪声量：差分隐私参数ϵ和δ，每个统计的敏感度（即，在给定用户活动的某个有限的变化量的情况下，统计信息可以改变的最大量），重新配置时间（必须在采集阶段以不同配置相互交换）以及噪声权重wiw_iwi​（即由DC DiD_iDi​提供的相对噪声量）。部署文档还包括得到测量输出的DC的最小子集。TS然后将部署文档发送到每个DC和SK。

2.2.2 配置

所有的DC和SK都接受了部署文档后，只有TS会进入配置阶段。在配置阶段，TS设置数据收集的特征，DC和SK自动适应这些特性以维持隐私保证。这显着提高了使用PrivCount的速度和便利性。在这个阶段，在TS中设置以下特征：（i）收集的开始和结束时间，
（ii）将被收集的统计信息sks_ksk​，
（iii）用于统计每个统计信息的计数器的数量ckc_kck​，
（iv）每个bin的范围（当统计值是直方图时）
（v）每个统计的估计值vkv_kvk​，它将指导PrivCount确定如何增加噪音，以使相对准确的每个统计量最大化，同时在所有统计数据中提供（ϵ，δ）差异隐私。
这些配置特征收集在配置文件中，发送给每个DC和SK。一旦收到，每个DC就会确定每个统计sks_ksk​的噪声大小σkσ_kσk​。此计算基于初始化期间设置的噪声参数以及配置期间由T（TS）选择的估计量。

2.2.3 执行

设置 在设置过程中，DiD_iDi​对每个计数器产生噪声，然后DiD_iDi​给每个计数器产生m（SK的数量）个共享值，Di通过将噪声和m个共享值的和初始化计数器。每个计数器现在都有m+1个值：噪声和m个共享值。共享值用于致盲计数器提供转发隐私，并且将在聚合过程后移除。每个DiD_iDi​通过T将每个共享值Bki,jB_k^{i,j}Bki,j​发送给SjS_jSj​，然后安全地擦除本地存储的共享值。每个SK在收集过程期间存储收到的共享值。
收集 在收集过程中，每个DC监视来自其本地Tor实例的事件并调整计数器。当在DiD_iDi​上进行影响统计sks_ksk​的观察时，Di调整其计数器skis_k^iski​中的一个。收集过程将持续配置阶段设置的时间长度。
聚合。一旦收集过程结束，T请求来自每个DC DiD_iDi​的计数器值。每个DiD_iDi​然后将每个计数器的值发送给T。然后T从每个SK请求与每个计数器的有效DC间分享的值的总和。回想一下，每个SjS_jSj​存储n⋅∑k=1lckn·∑_{k=1}^lckn⋅∑k=1l​ck共享值，每个计数器的每个DC都有一个共享值。如果成功的DC是部署文档中列出的一些最小所需DC的集合，则每个SjS_jSj​为每个计数器添加成功的DC的共享值并发送共享值和到T。在从每个SjS_jSj​接收到所有共享值总和之后，T通过添加来自有效DC的计数器并从SK减去相应的共享值总和来计算每个计数器的最终计数。
然后可以在开始另一个执行阶段之前重新计算PrivCount，而不需要重新初始化。此外，DC和SK不会接受新的配置文档，除非在设置的重新配置时间过后才开始收集。

2.3 隐私保护噪声

PrivCount为每个计数器添加随机噪声，为用户的行为提供隐私。PrivCount中使用的隐私概念是（ϵ，δ）-差异隐私，允许扩展统计集合并使其适用于小型研究部署。
隐私定义 PrivCount为一定数量的用户活动提供隐私。在给定的时间长度内进行有限活动下隐私的概念，并将其扩展到包含其他类型的用户活动。在这个概念下的差分隐私保证是，对于在一定时间内都发生的活动中的两组动作，攻击者几乎等可能看到给定的输出，无论用户是执行哪一组。PrivCount保护给定时间段内以下类型的用户操作的有限数量：（i）与guard连接，（ii）使用来自不同IP地址的guard，（iii）电路创建，（iv）流创建，（v）发送或接收一个字节的数据。
在测量Tor的情况下输入“数据库”是Tor网络上的活动。给定x的活动和时间范围t的活动的约束ax，若两个网络活动序列相邻，那么他们仅在单个用户的动作不同，这些动作在长度t的时间段内且对每个类型的活动x最多ax个动作。差异可能在于这些行为的存在性或行为的属性。请注意，这些约束同时适用于不同类型的活动，因此可为用户对Tor的整体影响提供隐私，前提是该活动属于活动和时间范围。例如，假设网络活动N1和N2的两个序列仅在一天中的一个用户的行为上有所不同，并且该用户在N2中创建了另外的电路且在N2中保持流打开的时间比在N1中更长。那么如果t至少是一天，acirc≥1a_circ≥1ac​irc≥1，并且astream≥1a_stream≥1as​tream≥1，那么N1和N2将被认为是相邻的，其中acirc≥1a_circ≥1ac​irc≥1和astream≥1a_stream≥1as​tream≥1分别是类型（iii）和（iv）的活动约束。
根据统计数据确定噪音
在统计中分配隐私预算
选择噪声权重 噪声值会跨越DC进行聚合，因此可能会导致超出必要的噪声。因此PrivCount在每个Di施加的噪声权重wi来调整DC间的噪声，来维持过度噪声与保持隐私间的平衡，即使某些DC是恶意的并且不添加噪声。

3 方法

3.1使用PrivCount测量Tor

使用PrivCount来安全测量Tor。虽然第2部分描述了PrivCount协议，但现在解释如何收集和处理Tor事件，以便计算感兴趣的统计数据。
收集事件。为了便于收集和处理来自Tor的事件，使用PRIVCOUNT类型的新异步事件扩展了Tor控制协议。一旦应用程序使用Tor进行身份验证并注册了新事件，修改过的Tor软件就会在发生任何子事件时发出以下消息：（i）出口流结束：信道ID，电路ID，流ID，读取的字节数，写入的num字节，出口端口，开始时间，结束时间;（ii）出口电路结束：信道ID，电路ID;（iii）入口电路结束：信道ID，电路ID，客户端绑定信元，出口绑定信元，开始时间，结束时间，客户端IP;和（iv）入口连接结束：通道ID。每个PrivCountDC连接到运行修改过的软件的Tor中继以收集这些信息，并按如下方式处理它。
将Streams分类。为了更好地理解Tor用户可能的类似行为，DC根据每个流的出口端口将流分类为流量类别。每当接收到出口流结束事件时，DC将用以下流量类之一标记该流：HTTP/S端口80和443被标记为Web;SSH和常见的IRC端口被标记为交互式（322，194，994，[6660，6670]，6679,6697和7000）;任何剩余的端口标记为其他。
按出口分类仅是行为的粗略近似：由于不同的应用程序可以使用相同的端口，因此分类不能完美地分割应用程序协议。但是，通过更精确的技术如深度包检测等协议嗅探降低了隐私风险，并且不需要统计学习的处理和存储开销。
电路分类。将电路分为明显使用和不使用的电路。每当接收到一个出口电路结束事件时，如果该电路上至少有一个数据流完成，则DC将该电路标记为有效，否则将该电路停用。另外，如果在电路上至少完成一个Web、交互和其他流，电路将分别标记为携带Web、交互和其他流量。每当接收到输入电路结束事件时，如果在该电路上已经传送了至少8个信元（6个信元用于电路的设置，并且至少1个信元用于每个方向上的电路使用），则电路被标记为激活的，否则不激活。
IP地址映射轮换。PrivCount使用客户端IP地址映射来计算每个唯一的客户端统计信息。由于将客户端IP地址存储在内存中是敏感的，限制必须在清除映射之前20分钟计算每个客户端的统计信息。这与Tor的默认电路寿命相差10分钟，也注意到Tor项目采用类似的方法来维护统计数据，比如每个国家的用户数量，但目前存储客户端IP地址的时间更长，更不安全（24小时）。
4.2PrivCount部署
在正常工作的Tor网络上部署了PrivCount，其中包括1个Tally服务器，6个共享管理器和7个数据收集器，每个收集器监视一个Tor中继。SK每个都独立运行，在6个不同的机器上有6个不同的操作员，分布在4个不同的国家。DC和Tor中继由2台操作员在3台不同的主机上运行（详见表1）。专注于提供高度安全的SK基础设施，以证明使用任意数量的Tor中继运行PrivCount的可行性，实际上SK设置需要6个操作员或机器泄露才能颠覆，这相对Tor的当前9个目录认证中只要5个泄露就可以控制网络共识，从而控制Tor更加安全。使用PGP密钥作为PKI。

收集轮次和统计。收集了多轮不同长度的Tor测量数据。推动这种方法的主要制约因素是需要增加足够的噪音来掩盖用户活动对所有统计数据的影响。考虑到部署中的中继规模，收集少量十几个统计数据需要每天增加的噪声小于每个估计值的10％。因此，每天进行多轮探索性轮次，并进行多个不同长度的深度轮次。虽然大多数探索性轮次都是首先进行的使得他们的结果可以通告深度轮次，但两轮轮次类型是重叠的。每个收集到的统计信息是一个入口统计信息，即只有在中继处于Tor电路的入口位置时才会增加，或者出口统计信息，即仅在出口位置增加。这样可以确保每个统计量仅通过一个中继的DC增加，从而限制其灵敏度并减少附加噪声。在探索性研究中，收集了13种单一统计类型的统计数据，目的是获得各种类型的Tor活动的平均估计值。在第5.2节中介绍了运行PrivCount部署6次的结果，其中每个收集阶段运行24小时并使用不同的出口策略（有关详细信息，请参阅表2）。在开始每个收集阶段之前，调整了出口中继出口策略，并确认新策略已正确传播至官方Tor共识。在所有探索性收集阶段，选择中继的入口位置平均概率为0.196％，在出口位置选择中继的平均概率为1.283％。

在探索性轮次中收集的统计数字是单个数字。唯一的入口统计数据是连续10分钟时间片中观察到的唯一客户端IP的总和。出口统计信息对发送或接收的有效和无效电路，数据流和数据字节进行计数。这些项目中的每一项都按整体和每类（即Web，交互和其他）进行计数。
在深度轮次中，将重点放在描述最重要Tor活动类型的统计数据上，这些探测数据由探测轮确定。在一些深度轮次中，着重于入口统计，而在其他一些中，主要关注出口统计。统计出口统计数据时，使用直方图来获取活动的分布而不是简单的平均数。考虑到增加的噪声，只使用每个柱状图3-4个bin来获得至少是最受欢迎的bin的足够的相对精度。运行多个深度轮次来调整bin范围以获得bin计数的更均匀分布。
在第5.3节中，提出了在整个深度测量阶段收集的4个入口统计数据（4个单一数字），运行了4天，并在整个深度测量阶段收集了26个出口统计数据（10个单一数字和16个直方图）跑了21天（细节见表3）。在入口统计数据收集阶段，选择中继的平均可能性为0.130％，出口统计数据收集阶段选择出口位置的中继平均可能性为0.914％。

在深度轮次中收集的入口统计信息包括在10分钟的时间片上添加活动和非活动客户端的数量以及客户端连接的总数。收集的出口统计数据包括列出了电路寿命的直方图以及Web和其他类别电路的直方图，后者测量了每个电路所承载的数据流数量。此外，还为所有流，Web流和其他流添加了流间创建时间的直方图。直方图也被添加到Web和其他流中，用于度量到达目标的字节数，到客户端的字节数以及出字节到入字节的比例。
由于探索性测量和分析表明了交互式流量是Tor流量分布的一小部分，选择在深度阶段不收集与交互相关的统计数据（以降低隐私风险并提高其他测量的准确性）。相关地，选择使用默认出口策略来收集深度度量，因为发现它是最受支持的策略：84.7％的出口中继接受端口80或443，并阻止或部分阻止那些也被默认端口策略阻止的端口。
噪声。PrivCount部署使用ϵ=0.3和δ=10-3的差分隐私参数。ϵ值与Tor用于隐藏服务统计数据相同[16]。δ可以被看作是选择违反电子差分隐私的噪声值的概率的上限。

设置的重新配置时间是24小时。表4给出了定义收集提供的隐私的活动界限（见第2.3节）。Tor客户端默认保持一个入口连接，因此为入口处的24小时客户端观察值以及12个总入口连接（即每2小时新建一个连接端口）提供隐私。默认情况下，Tor客户端创建2个抢先式电路，每个电路10分钟。因此，保护24小时的连续电路使用：146=24·60/10+2.请注意，保护较少数量的交互式电路（20），这些电路通常使用时间更长，因此创建频率比其他类别低。保护了30,000个流，特别覆盖了100个网页，每页最多300个请求，其中包括95％的网页由HTTP Archive测量。对于交互式和其他流，只保护一个在动作范围内创建的每个电路的流（分别为20和144）。还保护10MiB的任何方向的流量。这涵盖了HTTP Archive测量的95％的网页，并且是Tor隐藏服务统计中保护的流量的十倍。
设定行动界限需要在隐私和准确性之间进行平衡。为了获得合理的准确性，必须选择与Tor的实际活动（特别是部署中的中继）相比不高的边界。因此，选择为比较频繁的操作（例如创建Web流）提供更强大的保护。这可能看起来不一致，但认为隐私保护在每种情况下都是足够的，在某些情况下甚至比其他情况更好。
统计的敏感性很容易从这些行动界限中确定。例如，统计计数活动电路的灵敏度仅为146，这是创建电路的动作约束。请注意，直方图对可以更改值的输入的数量很敏感而对输入值更改本身不敏感。例如，流间创建时间的直方图的灵敏度为60,000，因为允许单个用户改变30,000个流的生命周期和存在，并且直方图的灵敏度是可以改变的输入数量的两倍。使用每个统计的灵敏度来确定噪声标准偏差通常是一种最差情况下的近似值，它允许所有统计数据同时改变灵敏度那么大的值，但对于部署，统计数据实际上可以同时改变那么多。
如果至少有一台运行数据中心的机器是诚实的，设置噪声权重以提供不同的隐私。部署的3台机器运行1,2和4个DC（回想每个DC与Tor中继配对）。对于运行k∈{1，2，4}DC的机器，其DC的噪声权重为1/k1/\sqrt{k}1/k​。因此，任何一台诚实的机器都会产生所有必要的噪音，如果所有的都是诚实的，那么需要增加3\sqrt33​倍的噪音。将整套DC作为最小集合，因为在相对较小的部署中，丢失任何中继的输入都会显着影响统计的准确性。
估算值。对于探索性轮次，使用Tor中继发布的额外信息文档（第2.1.2节）估计统计值。这些文件包括每个中继统计数据，特别包括关于（i）在入口中看到的用户的数据;（ii）电路，包括其流量;和（iii）出口处的流量，包括每个端口的数量和流量。来自这三个类别的数据是不完整的，因为它们都是默认关闭的，因此只有少数中继会报告。此外，它们仅限于Tor所建立的统计数据，且准确度通常较差，因为每个中继都混淆了它的数据（例如四舍五入到给定倍数），从而产生与中继数量成比例的噪声。这些统计数据通常不满足任何正式的隐私概念，并且它们的准确性和频率是通过特定的隐私参数选择的。但是，它们为提供了足够的数据，以便为探索性轮次中的每个统计数据提供合理的估计值。通过调整他们的中继权重和探索轮次的长度来产生额外信息值的估计值，进行有根据的猜测以填补一些空白（例如，根据观察到的Web流的数量来猜测Web电路的数量）。对于深度轮次，使用探索性轮次的结果，并根据轮次变化进行调整。大部分添加到探索性轮次中的统计数据都是直方图。对于这些，只需要估计输入的总数（不是它们的值），并且探索性轮次提供了这样的估计。

4 测量结果

4.1 出口策略分析

每个Tor中继都配置了一个出口策略，该出口策略指定了该中继允许和不允许连接的目的端口。所有中继的出口策略都包含在Tor共识文档中，Tor客户使用它们为其预期的目标端口选择合适的出口节点。因此，具有非常严格的出口策略（例如仅允许端口22的出口策略）的出口中继可能观察到明显不同于允许所有端口（包括端口80和443）的出口中继的业务特性。
为确保出口中继的测量结果为提供了所有Tor网络流量的准确信息，对Tor出口中继使用的出口策略进行了分析。在分析了2016年4月期间产生的多个共识之后，发现在Tor的默认出口策略6中拒绝所有219个端口（其中大部分与文件共享有关）构成了Tor中219个最被拒绝的端口。还发现，类似的出口带宽片段可用于几个默认被阻止的端口。表5显示了这些类似分组的端口以及通常与它们关联的流量类型以及最常接受的流量类型（HTTP/S）的端口。
继续分析，以了解每个中继接受和拒绝表5中哪些端口组的组合。计算了出口中继的百分比，这些出口中继的出口位置的选择概率加权，接受或拒绝每组端口。在这些出口策略的25=32个可能组合中，只有7个有效（即至少有一个出口符合策略）。表6列出了前6个策略以及支持每个策略的出口带宽百分比（忽略了剩余的有效出口策略，因为它支持的出口带宽小于0.1％）。
发现默认策略是目前最流行的策略：68％的中继支持默认策略，并支持出口65,315最多允许的端口。还发现，17％的出口支持至少一些通常与文件共享相关的端口，即使这些端口是允许的最小端口。最后，超过14％的出口带宽不支持出口到HTTP/S端口80和443，尽管它是Tor中允许的最大流量类型。根据分析结果，在探索阶段选择出口策略用于出口中继。

4.2 探索性测量

与流量分布有关的主要测量结果如图3所示。图3a显示了出口中继在24小时收集间隔内根据流量类型计算的活动电路总数（至少有一个完整流的电路）按PrivCount分类。图3b类似地显示了由出口中继观察到的流的数量（离开Tor网络的TCP连接），并且图3c示出了在这些流上在两个方向上传输的数据量的总和。表6中每项出口策略的收集测量结果均以95％的置信区间显示，因为计算出的概率性增加了噪音。
在图3所示的所有六项出口策略和所有三项统计数据中，观察到交互式流量相对于Web或其他流量的计数非常低。这表明交互式流量是Tor整体流量分布的很小部分，因此在后期测量期间可能会安全忽略。



除了严格的策略外，在测量过程中使用的所有出口策略中，Web类的电路数（3a）和数据流（3b）保持相对一致。流的数量确实在出口策略中显示出一些波动，将其归因于Web类的较大误差范围。请注意，严格的出口策略不允许被分类为Web的流量，因此图3中严格策略下Web的正计数直接对应于由PrivCount添加到这些计数器的噪声。
尽管Web电路和在整个出口策略中，流保持相对一致，其他电路和流却不是如此。当使用允许出口到文件共享端口的出口策略时，观察到的其他电路（3a）的数量显着增加并且有些零星。当允许文件共享端口时，观察到的其他流（3b）的数量也相应增加，并且由于使用限制较少的出口策略（因此允许更多的文件共享端口），因此流的数量趋于更高。这些观察遵循文件共享协议的常见流量模式，这些协议倾向于与同伴建立许多连接以便减少大文件的下载时间。
与电路和流计数趋势类似，随着出口中继允许的文件共享端口数量的增加，在Tor（3c）连接上传输的其他流数据量也显着增加。但是，与网络电路和流计数（其大部分不受其他电路和流的增加影响）不同，传输的Web数据量随着其他数据传输量的增加而下降。这表明一个挤出情况，每个流量类别都直接竞争出口中继的有限带宽，文件共享流量赢得竞争。即使当传输的Web数据量（3c）减少时，Web电路（3a）和数据流（3b）的数量也是一致的，这表明与文件共享流共存的Web流的性能可能显着降低。如果这个假设成立，那么用户可以简单地通过排除那些允许文件共享端口在构建电路时出口策略的出口中继来改善他们的网页浏览体验。这为未来的工作提供了一个有趣的领域。
最后，观察到，使用严格策略限制Web流量的出口中继并不会导致为交互式或其他类传输的电路数据流或数据剧增。这增加了信心，即没有其他端口的活动被与Web端口关联的活动所挤出。
推断网络总计。从探索阶段获得的结果提高了对流量特征如何随不同出口策略变化的理解。但是，直接比较时若不考虑每种出口策略类型可用的相对出口带宽支持，结果可能会有些误导。考虑到在测量过程中使用的每个出口策略的受欢迎程度，可以更好地估计整个Tor网络的整体流量特征。
收集了在上面提出的6个探索性测量轮次中每一个产生的24个共识文件（每个小时一个文件）（24·6=共144个文件）。对于每组24个文件（其对应于单个出口策略和测量结果集合），计算了用于选择输入位置中的中继的平均分数权重Wg，用于选择出口位置中的中继的平均分数权重We，以及在收集阶段支持出口策略的其他中继的平均分数权重Wp。然后，通过Wp/Wg将测量的入口统计量和Wp/We将测量出口统计量进行比例缩放，并对各阶段的缩放结果进行求和，以产生最终的网络总体估计值。
表7显示了在平均10分钟的时间间隔内，对于每个流量类别以及整个Tor网络在数据流上传输的有效电路数量，数据流量和总数据量的推断估计。请注意，对于未达到100％的统计数据，表格中显示的百分比是使用收集的单独总计数（例如总活动电路）计算的，而不是三个特定类别个别计数的总和。这样做是为了避免噪声聚集，并在可能的情况下提高估计的准确性。显示的置信区间包括与添加到计数器的噪音相关的不确定性以及抽样误差。

与直接测量一样，推断表明交互式流量对Tor的整体推断活动的贡献非常小。推断还表明，Web流量是网络上显示的所有三种统计数据的主要流量类型。特别是，发现Web流量占Tor中创建的流的88％和流数据的91％。表8给出了与以前的测量研究的对比。总体而言，结果表明，与其他协议相比，2010年以来HTTP/S的使用量有所增加，认为这是由于用Tor浏览网页的可用性改进（例如Tor浏览器）。

4.3 深度测量

通过平均进入和出口概率分别调整每个进入和出口统计数据来计算深度轮次的结果，作为推断的Tor网络总数。请注意，基于出口统计的推断假设使用非默认出口策略的中继观察到的流量特征与使用默认策略时观察到的类似。

入口统计。收集的入口统计数据关注于观察唯一客户端的数量以及处于活动状态和非活动状态的客户端数量。出于隐私原因，唯一的客户端IP地址每10分钟重新计数一次。表9显示了在4天入口测量期间（有4·24·6=576个这样的间隔）以及置信区间（考虑噪声和采样误差）发生的所有10分钟间隔内的平均推断计数。
发现Tor平均每隔10分钟就有大约700,000个唯一客户端连接到网络。Tor自己估计的2016年5月每天约175万客户[4]，这表明客户人群每天翻约2.5倍。有点令人惊讶的是，发现大约13万客户在平均10分钟内有无效电路。此外，发现与客户端数量相比，客户端的连接数较少，但注意到，在4天测量期间没有关闭的客户端连接不会被计算在内（因为PrivCount在关闭时计算连接数）。
出口统计。出口统计数据集中在电路和流统计数据上，以帮助更好地理解Tor流量。表10显示了在21天内出口测量期间发生的所有10分钟间隔内的平均推断计数（这里有21·24·6=3024个这样的间隔）以及置信区间（考虑了噪声和采样误差）。虽然所有的计数都是在整个21天的出口测量期间进行的，但为了清晰呈现，将计数显示为10分钟的均值。
推断在平均10分钟内有140万个活动电路使用，相当于每个活动的客户端有2到3个活动电路。平均10分钟内非活动电路的数量与活动电路数量相同，因为推断的入口统计数据中有大量非活动客户端，并且考虑到一些因性能原因先建立的Tor电路可能永远不会被使用。正如在探索性轮次中一样，大多数活动电路承载Web流量，并且绝大多数流和流数据对应于Web流量。每个Web电路平均有大约25个Web流，并且出口中继与每个这样的流的目的地平均交换约50KiB。类似地，每个其他电路平均有大约2个其他流，并且与每个其他流的目的地平均交换大约150KiB。
直方图统计信息显示在表11中。对于每个统计信息，该表显示bin范围和相对计数（统计量落入每个bin范围内的次数的百分比）以及适用于每个bin计数的95％置信区间。所显示的百分比是通过将bin计数作为每种流量类型（即总计，网络和其他）的单计数器总计数（即电路数量，流数量和流数据）的一部分计算出来的，因此置信区间考虑了总数和bin数的范围。

这些数据在Shadow等工具中对Tor流量分布建模很有用。发现每个电路的大多数Web流少于7个流;相比之下，HTTP Archive[5]报告称，23％的页面每页少于10个连接。相对较低的流数量的一个潜在原因可能是因为Tor浏览器默认阻止了JavaScript，这会阻止加载许多嵌入式页面对象。大多数其他电路的流少于3个。出口中继的读取Web流有33％小于2KiB、有37％在2KiB和16KiB之间，而读取其他流有56％小于2KiB。出口中继写入少于1KiB到77％的Web流和到46％的其他数据流。还测量了使用log2（byteswritten/bytesread）作为每个流的直方图输入计算的“每流比特字节数”统计量。在这种解释下，范围（-∞，-1）对应于出口中继读取的字节数多于写入字节数的两倍的数量，范围[-1,1）对应于出口数据流中继读取并写入大约相同的数量，范围[1，∞）对应于出口中继读数小于写入数量一半的数据流。结果表明，出口中继主要是从Web流读取的，但是对于其他流，其中出口中继写入的流量超过12％的其他流的双峰分布存在。最后，发现同一电路上68％的Web流在彼此的1秒钟内创建，而其他流更加均匀地分散在统计的bin中。

【笔记】Safely Measuring Tor相关推荐

1. 论文笔记：MEASURING DISENTANGLEMENT: A REVIEW OF METRICS

   0 摘要 学习解缠和表示数据中的变化因素是人工智能中的一个重要问题.虽然已经取得了许多关于学习这些表示的进展,但如何量化解缠仍然不清楚. 虽然存在一些度量标准,但对它们的隐含假设.真正衡量的内容以及限 ...

2. Halcon学习笔记：1D Measuring一维测量_fuse.hdev灯丝测量示例

   Halcon学习笔记:1D Measuring一维测量_fuse.hdev灯丝测量示例 一.基本概念 基本流程为: 获取图像 对图像进行灰度值标定 (针对相机获取的图像灰度和输入能量之间的非线性关系, ...

3. HALCON 20.11：学习笔记---一维测量(Measuring)

   HALCON 20.11:学习笔记---一维测量(Measuring) 本章主要提供有关一维测量的信息. 一维测量的概念 通过一维测量可以沿着预定义的线或弧定位从亮到暗或从暗到亮的过渡边缘.这使您可以 ...

4. Are VQA Systems RAD? Measuring Robustness to Augmented Data with Focused Interventions 论文阅读笔记

   Are VQA Systems RAD? Measuring Robustness to Augmented Data with Focused Interventions 论文阅读笔记 一.Abst ...

5. 【安全牛学习笔记】TOR

   保护隐私防止被追踪 志愿者组成 长期在天朝完全无法使用 感谢 云 暗网 互联网搜索引擎无法发现 互联网黑市 下载和看视频是不道德的行为 互联网黑市交易的货币是比特币 比特币很难在互联网复原 下载 ht ...

6. 论文阅读笔记 | On the Challenges of Geographical Avoidance for Tor（NDSS 2019）

   文章目录 论文信息 核心思想 1. 背景 2. 方法 2.1 Symmetric Approach 2.2 Asymmetric Approach 2.3 Empirical Approach 3. ...

7. 『论文笔记』Are VQA Systems RAD? Measuring Robustness to Augmented Data with Focused Interventions

   Are VQA Systems RAD? Measuring Robustness to Augmented Data with Focused Interventions 一句话总结 本文提出一个基 ...

8. 爬虫学习笔记--Tor隐藏Ip

   因为在爬虫时,如果使用了默认的IP 可能导致自己的IP遭到封禁 所以就要隐藏自己的IP 事先说明 爬虫要有度 也要考虑服务器的压力 本篇基于win10 tor的原理 http://www.cnblog ...

9. 张高兴的 Windows 10 IoT 开发笔记：BH1750FVI 光照度传感器

   张高兴的 Windows 10 IoT 开发笔记:BH1750FVI 光照度传感器 原文:张高兴的 Windows 10 IoT 开发笔记:BH1750FVI 光照度传感器 BH1750FVI 是一款 ...

最新文章

1. 我是如何拿到蚂蚁金服 offer ?
2. STM32开发 -- 4G模块开发详解（3）
3. “堆外内存泄漏”排查及经验总结
4. Nginx ab压力测试
5. 一步一步写算法（之 A*算法）
6. myeclipse jsp和java字体设置
7. uefi下的开机顺序_如何访问UEFI或BIOS并进行设置？
8. 程序员必读的职业规划书 - 思维导图
9. 多元统计分析因子分析何晓群版课后作业
10. PBRT-V3体渲染笔记
11. 程序员要不要懂底层原理
12. 使用跨端解决方案Rax编写鸿蒙应用
13. android 怎么看架构,怎么查看手机设备架构
14. 如何防御DOS和DDOS攻击
15. 【收藏】2020届互联网公司校招时间总表
16. MATLAB矩阵基本运算的实现（一）
17. 【笔记】Linux 文件写入失败，提示文件系统已满
18. 用JAVA实现简单的WORD转PDF 亲测有效
19. 工业相机分辨率怎么选择
20. 打印杨辉三角的9种方法与解析

热门文章

1. scpi指令转换c语言,SCPI 命令表
2. Good Morning Beijing,Good Night Shanghai
3. 游戏的分类，游戏立项前的关键步骤！
4. Egg + Puppeteer 实现Html转PDF(已开源)
5. ORB_SLAM2 源码解析 ORB_SLAM2简介（一）
6. homeassistant 接入小米温湿度计2
7. Chrome常用快捷键
8. 【阿不】深入ASP.NET数据绑定（下）—多样的绑定方式
9. Fortran 编译提示 Error:This USE statement is not positioned correctly within the scoping unit.
10. PHP+Mysql图书商城 网上校园图书购物商城 基于PHP图书商城的系统设计与实现 效果图