• 论文信息
  • 作者信息
• 论文内容
  • 摘要
  • 介绍
  • 工具和术语
    • A. 基本的页面加载
    • B. Tor的高延迟原因
    • C. 加载时间分类
  • HTTP/1.1 Pipelining
    • A. Tor浏览器中的Pipelining
    • B. Pipelinig的问题
    • C. 数据收集和方法
    • D. 数据分析
  • HTTP/2
    • Tor浏览器中的HTTP/2
    • HTTP/2的问题
    • 数据分析
      • 整体性能
      • 加载时间的分类
      • 潜在问题的分析
  • 设计一个更好的浏览器
    • 什么导致了长加载时间？
    • 仿真
    • 提出的特征
    • 对变更的评估
    • 改进的拓展性
    • 执行情况评价
    • 讨论

论文信息

作者信息

• Tao Wang
• 香港科技大学计算机科学与工程系
• taow@cse.ust.hk

论文内容

摘要

Tor是一个匿名网络，允许客户端无痕迹的浏览网页，但用Tor加载网页速度很慢。为了分析浏览器如何加载网页，我们使用新的浏览器日志记录和模拟工具BLAST检查它们的资源树。我们发现，使用Tor加载页面所需的时间几乎完全取决于往返次数，而不是带宽，并且Tor浏览器有一些不必要的往返。 资源位于浏览器队列中，过多地等待TCP和TLS握手，每个握手都需要单独的往返。 我们发现使用更大的Pipelining甚至HTTP/2 来增加资源加载量并不会减少加载时间，因为它们不减少往返次数。

我们通过一系列协议和改进浏览器的措施（包括TCP Fast Open，optimistic data和0-RTT TLS）来最大程度地减少往返行程。 我们还建议使用数据库来帮助客户端进行重定向，识别HTTP / 2服务器和prefetch。 所有这些功能均旨在减少加载网页时出现的往返次数。 为了评估这些改进，我们创造了一个模拟工具，该工具在预测网页平均加载时间方面非常准确。 我们使用模拟器来分析这些特征，并显示它们将比HTTP/2减少平均页面加载时间61％。 我们对用户体验的作出了巨大改进,但对Tor网络的开销影响很小

介绍

匿名网络通过全球多个节点中继用户流量，确保窃听者无法同时知道流量的真实来源和目的地。

Tor是一个非常成功的匿名网络，拥有数以百万计的用户，Tor浏览器基于Firefox。缺点是Tor浏览器速度明显较慢：根据版本不同，加载网页平均需要16到19秒。

本文目的是改进Tor浏览器的设计来减少加载时间。

文章提到浏览器设计的改变需要很长时间来验证是否有效，因为可能某些设计是针对特定的网络情况，比如Pipelining就因为没有显著的性能提升而被Chrome和Firefox废弃。

作者提出了BLAST(Browser Logging, Analysis and Simulation for Tor),一个能够在Tor上详细记录、分析和模拟页面加载的工具。 BLAST由记录器和模拟器组成。记录器是Tor浏览器的拓展工具，可以分析其页面加载过程； 模拟器基于有关其结构的基本信息来模拟页面负载。 通过BLAST，文章做出了以下贡献：

1. 分析BLAST日志，我们发现Tor浏览器的页面加载时间几乎完全是由于Tor的高延迟引起的往返，而不是由于带宽或资源加载能力的限制。此外，尽管HTTP/2具有出色的多路复用功能，但在Tor上的加载速度并不比使用Pipelining的HTTP/1.1更快。
2. 创建了一个页面加载模拟器工具，该工具可以在各种浏览器设置（包括HTTP/1.1，带Pipelining的HTTP/1.1和HTTP/2）下，非常准确地预测页面平均加载时间。
3. 我们提出了许多浏览器和协议改进措施，以消除不必要的往返行程，并使用BLAST模拟器验证了它们在减少页面加载时间方面的作用。 根据模拟器预测，我们提出的功能组合将平均页面加载时间从18s减少到7.1s，减少了61％。

工具和术语

A. 基本的页面加载

• 资源：页面上各个元素都是资源，对应加载各种GET/PUT请求
• 连接：TCP连接，Tor浏览器最多同时建立6个到同一服务器的连接
• 资源队列

  B. Tor的高延迟原因

• 大量的web服务器：每次连接的建立都需要至少三次往返：TCP连接建立、TLS协商、HTTP资源请求，如果多个资源连接到同一个服务器可以避免前两次往返。所以如果网页将资源分布在很多的服务器上，将导致产生更多的往返，加载时间变长。
• 较长的资源树：浏览器只能在接受父级数据并分析后来获取其后续的引用资源，资源树的高度就是最小的往返次数，最坏的情况下每个资源都在单独的服务器上，所以往返次数是资源树高度的三倍
• 资源过多：可同时加载的资源数量称为资源加载能力，在没有Pipelining的http/1.1上是6，有Pipelining的话是6-14，在HTTP/2上是100

C. 加载时间分类

• 页面加载时间：计算加载95%的资源所需要的时间（剩余的资源可能是广告或者用户追踪资源，会持续加载很长时间）
• 资源加载时间：分五个事件衡量加载时间
  1. 资源请求创建
  2. 资源分配到可用的TCP连接上
  3. 客户端发送第一个字节（请求）
  4. 服务端接受第一个字节（响应）
  5. 服务器接收的最后一个字节（响应）

①②之间是队列等待时间，②③之间是TLS等待时间，③④之间是服务器等待时间，④⑤之间是传输时间，理想情况下是希望服务器等待时间正好是一次往返时间，其余的时间接近于0

作者还对资源树加载时间进行分类，计算最终的资源和根资源之间的资源加载时间。

HTTP/1.1 Pipelining

A. Tor浏览器中的Pipelining

浏览器对服务器的资源加载能力等于最大连接数（6）乘以Pipe’li’ng的深度。 Pipelining对于性能的提升没有作用，所以浏览器都默认关闭此功能。新版的Firefox和Tor浏览器上，为了使用HTTP/2，完全移除了Pipelining的代码。 但是Pipelining确实能减少Tor的加载时间，每个网页中拥有资源最多的服务器，平均拥有34.4个资源。假如没有Pipelining，一次往返只能加载6个资源。

B. Pipelinig的问题

队首阻塞：管线队首的资源传输时间较大的话，后续的资源的延迟也会增大

Pipelinig错误：尽管在HTTP/1.1中对Pipelinig支持进行了标准化，但许多服务器仍然对Pipelinig响应不正确，从而导致浏览器中出现连接错误。这些连接被丢弃，资源请求必须在另一个连接中重新发送，从而导致延迟。如果在该连接上挂起大量资源请求，则这尤其有害。然后，浏览器将停止在该服务器上为给定的页面负载使用Pipelinig，从而失去Pipelinig的好处。

Pipelinig深度。虽然较大的Pipelinig深度会增加浏览器的总资源加载容量，但同时也会加剧队首阻塞和加载错误导致的潜在延迟。另一方面，较大的Pipelinig深度有助于并行加载具有许多小资源的服务器。提高资源加载能力的另一种方法是并行使用更多的连接，但这会导致某些路由出现问题，并增加服务器的内存消耗。

C. 数据收集和方法

使用两个版本的Tor，分别是使用HTTP/2的TB-8.5 和使用Pipelining的TB-6.5，并将Pipelining的代码引入8.5进行对比。

实验访问了三组页面，来自Alexa Top 1000，丢弃了一些加载不正确的页面（正确加载的资源不超过2个）

• Top 10页面，每个50次
• Top 200页面，每个5次
• Top 1000页面，每个1次

D. 数据分析

1. 整体性能： 在Pipelining数据集上，每个页面平均有104个资源，页面平均大小为2.1MB，平均资源大小为20kb，但是中位数为3kB。资源树的高度平均为15.4。Top 10的站点平均只有55个资源，Top 200平均有116个资源，Top 1000有118个资源。整体加载时间为16.4s，Top10为13.7，剩下两个类别是19.6

2. 加载时间分类： 如下图，大约5.8s（36%）的页面加载时间是由于资源在队列中等待连接，同样的比例还有等待服务器响应的时间，只有0.91s（5.6%）是页面传输时间。
   资源平均加载时间为2.85s，但是只有0.079s（2.7%）是传输时间。1.56s（55%）是在队列中等待，一半以上的资源要等待半秒以上，30%的资源等待1s以上。这些长队列的等待时间可能表示缺乏资源加载能力，或者Pipelining连接错误的情况。

3. 潜在问题分析

队首阻塞： 1/3的资源被阻塞，平均阻塞时间为0.25s,只有1%的资源超过0.5s的阻塞。整体影响不大。

Pipelining错误：Pipelining中很大一部分遇到了错误并提前关闭。118746个使用Pipelining的资源中，有25679个（22%）被分配了在加载完成前就被关闭的连接了。另外73710个没使用Pipelining的资源中只有68个被提前关闭。
58%的服务器在使用Pipelining时没有出现提前关闭的情况。尚不清楚其他服务器不支持Pipelining的确切原因：我们观察到，它们只是在发送Pipelining连接请求后的一段时间内，在没有解释的情况下中止了连接。Pipelining的错误率妨碍了它的实用性。

Pipelining深度：由于资源加载能力差会增加队列等待时间，而队列等待时间是负载时间的重要组成部分，因此增加资源加载能力似乎有助于改善长的负载时间。在TB-8.5中，我们使用了每台服务器6个连接和6个Pipelinig深度（称为6-6），6个连接和20个Pipelinig深度（6-20），20个连接和6个Pipelinig深度（20-6），以及20个连接和20个Pipelinig深度深度（20-20）。在对比实验中，我们发现，令人失望的是，这些参数的变化没有产生任何显著的负载时间差异。6-6和20-6的平均加载时间为16.4s，6-20的平均加载时间为16.3s，20-20的平均加载时间为16.5s。 结果表明Pipelining已经提供了足够的资源加载能力，不会减少页面的加载时间。

总结：总结。行首阻塞对页面加载时间影响不大。我们还发现，通过增加同时连接数和Pipelinig深度来增加Pipelinig的资源加载能力不会影响页面加载时间，这表明Pipelinig具有足够的资源加载能力。但是，对于很大一部分服务器，Pipelinig通常会过早关闭。

HTTP/2

Tor浏览器中的HTTP/2

基于Google的实验性SPDY协议，HTTP/2改变了web页面的加载方式：它使用多路复用而不是多个连接。客户机与每台服务器建立一个多路复用连接，能够承载100个资源请求。请求可以随时发送，响应可以按任何顺序到达，而无需等待。为了管理并发资源加载，web浏览客户端对传入的响应实施流控制。

HTTP/2取代了较新版本的Tor浏览器上的HTTP/1.1管道。Web服务器越来越多地采用HTTP/2。在所有主流浏览器上，只有使用TLS的页面才能加载HTTP/2。

HTTP/2的问题

行首阻塞：在HTTP/2中，同一服务器上的所有资源通过一个TCP连接加载。但是TCP数据包必须按序到达，即在传输层仍然存在阻塞的情况。

传输率：随机的延迟可能导致使用单个TCP连接时，速率变慢

连接提前关闭：如果收到错误的响应，则Pipelining会提前关闭。如果HTTP/2的连接提前关闭，很多资源会被重新加载，增加延迟。

ALPN协商导致的额外往返：ALPN协议用于客户端确定服务器是否支持HTTP/2，该协议需要一次往返。TB-8.5默认使用没有Pipelining的HTTP/1.1

数据分析

整体性能

图4中显示了整个数据集的平均页面加载时间。结果表明在TB-8.5上，HTTP/2的性能比HTTP/1.1更差，但性能却略好于TB-6.5上的HTTP/1.1.

关于HTTP/2性能糟糕的猜想：
服务器支持HTTP/2吗?：在TB-8.5 HTTP/2的数据中，95%的网页有至少一个资源使用HTTP/2，总共有49%的资源使用HTTP/2传输。（因为ALPN协议的原因，服务器只有少数HTTP/2资源时不会使用HTTP/2协议）

一小部分页面的表现不好吗？ 为了确定少量错误数据是否使平均结果有偏差，我们通过直接比较同一电路上的实例之间的差异（使用第III-C节中的方法）来检查http2和pipeline 之间的页面加载时间差异。 页面加载时间差为0.74s ± 6.54s：标准偏差远高于平均值，这表明http2并非始终低于劣势。 如果我们舍弃了页面加载时间差异的顶部底部各20％，则结果将是-0.11s ± 1.30s。 结果的中位数表现相对相似。

特定类型的页面表现不好吗？ 测试了以下特征：资源数量、页面大小、资源树高度和HTTP/2资源百分比。结果表明，这些特征与加载时间差均无显著相关性，资源数量与加载时间差的最大r为0.22，其它r值均小于0.15。这意味着 与Pipelinig相比，HTTP/2的糟糕（或良好）性能并没有局限于特定类型的页面。

加载时间的分类

如图4b，http2具有更短的资源加载时间，在队列等待时间上有一个特别显著的增益：这是因为资源不必等待HTTP/2连接完成加载以前的资源。但是，对于整个页面加载时间，http2上的队列等待时间优势消失了。虽然在http2中，资源平均要少等待40%左右，但对页面加载时间有贡献的资源不会在队列等待时间上经历如此有益的减少。注意，在HTTP/2和HTTP/1.1中，加载到一个新的、独立的服务器上的资源等待管道的时间相等。如果这些资源是决定页面加载时间的资源，这可能解释了HTTP/2性能改进的不足。

潜在问题的分析

队首阻塞：首先确定使用单个连接是否会导致线头阻塞。为此，我们专门测量了在HTTP/2连接上发送的资源的资源加载时间，这些连接已经加载了其他资源。这5651个资源从不需要排队或等待连接建立。 他们平均等待服务器响应的时间为1.38 s，传输时间为0.40 s，而在http2上分别分别为0.99 s和0.15 s。 这确实表明HTTP/2队首阻塞有时在Tor浏览器上是一个问题：已经建立HTTP/2连接的服务器响应并传输速度稍慢。

传输速率 : 为了找出在HTTP/2中使用单个连接是否会影响传输速率，我们总结了大小超过500kb的所有资源的资源大小和传输时间。发现http2上的数据传输速率为164kB/s，pipeline上的数据传输速率为347kB/s，但这并不一定意味着HTTP/2速度较慢：数据传输速率是按每资源计算的，HTTP/2允许多路复用，而pipeline不允许多路复用。在 Top 10的站点上，http2和pipeline上的传输速率分别为343kB/s和420kB/s，差别不大。

连接过早关闭 在HTTP/2连接上调度的99947个资源中，只有7个在连接过早关闭。

ALPN协商往返 无法消除这种往返，所以无法分析其对页面加载的影响。 为此需要BLAST的第二个组件模拟器，模拟器将显示ALPN协商往返对页面加载时间影响较小。

总结。尽管HTTP/2似乎没有影响Tor页面加载的明显问题，但http2中的页面加载速度略慢于pipeline。HTTP/2的主要优点，优越的连接多路复用和更高的资源加载能力，与Tor浏览器上的页面加载无关。此外，对于不支持HTTP/2-HTTP/1.1且不使用管道的服务器，TB-8.5的性能有倒退

设计一个更好的浏览器

什么导致了长加载时间？

对带有管道的HTTP/1.1的分析表明，增加管道的数量和深度并不能提高页面加载时间。将HTTP/1.1与Pipelining和HTTP/2进行比较，我们发现HTTP/2连接多路复用也没有提高页面加载时间。此外，每当它们的性能不同时，这种差异并不是由于页面结构或大小造成的。在HTTP/2中缺乏改进也不是因为使用单个TCP连接有任何问题。

增加资源加载容量（无论是使用更多/更深的管道，还是使用HTTP/2多路复用）并不能解决在Tor浏览器上加载速度慢的问题。此外，对页面加载时间的分类也表明，增加带宽不会显著加快页面加载速度。这意味着Tor浏览器上的加载时间主要由加载页面所需的最小往返次数决定，称之为minRTT。
计算了minRTT和页面加载时间的相关系数是0.57

仿真

BLAST页面加载模拟读取关于页面结构的基本信息，并生成与其加载对应的网络事件。模拟器将以下信息作为输入

• 资源树：资源的列表、大小和父级；
• 服务器的列表，每个服务器承载哪些资源，以及是否支持TLS、管道和HTTP/2；
• 平均带宽和往返时间

模拟器不使用任何资源计时信息，只需要知道要模拟的网页的静态信息。模拟TCP连接建立、TLS和ALPN，以及每个资源的调度和加载。它输出加载每个资源的时间和方式，简单地使用恒定的带宽速率和往返时间。

模拟器不模拟随机错误和延迟、Tor上的拥塞控制、HTTP/2，TCP，或在加载过程中随机断开连接。

模拟器可以准确地预测加载时间。我们将http2的往返时间设置为0.8s，将带宽设置为164kB/s，将管道设置为347kB/s；这些数字与我们在第IV-C节中从实际数据测量的数字相同。模拟器发现http2的平均页面加载时间为18.0s，将管道设置为17.1s，而实际数据集中的平均页面加载时间分别为18.4s和17.6s。仿真结果不仅准确，而且http2与管道的页面加载时间差与实际情况基本一致。这显示了我们的模拟器的价值，作为我们的主要发现之一，“HTTP/2比HTTP/1.1稍慢，在Tor浏览器上有Pipelining”，可以通过BLAST模拟器获得。

我们在图5中显示了http2的实际页面加载时间与模拟页面加载时间的散点图。相关性很强为r=0.63，模拟器产生准确的平均页面加载时间；
但是，模拟器在页面实例级别不一定准确，特别是因为它不可能模拟随机往返时间、延迟和拥塞。

提出的特征

提出六个改善来加快Tor浏览器的网页加载速度，基于http/2进行修改

TCP Fast Open：已经在最新版本的FireFox实验性的实现了，但还没有在Tor中实现

Optimistic Data： 2010年，Goldberg提出使用Optimistic data来减少Tor上的往返时间

Ian Goldberg. Optimistic data for Tor (PETS rump session talk). https: //thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf. Accessed Jan. 2019.

在未加密连接上，客户端同时发送资源请求和连接建立请求。Tor出口节点保留资源请求，建立连接后再发送资源请求。 这样可以将客户端和服务器之间的两次往返时间减少为一次往返，再加上出口节点和服务器之间的一个更小的往返时间。

在加密连接上，TLS协商包和连接建立的请求一起发送。

Optimistic Data是在2013年通过更改Tor并通过修改浏览器SOCKS状态机的快捷方式而实现的，但由于与新的浏览器代码不兼容，该修改最近已被删除。 我们无法使用以前的修改，但是可以通过模拟验证效果。

0-RTT TLS： TLS协商在建立连接后需要进行一次额外的往返，在此期间不能使用该连接发送资源请求。
TLS 1.3引入了0-RTT会话恢复：它允许客户端记住与服务器协商的密钥，并将其与会话恢复票证一起发送回去。 尽管0-RTT在前向保密和重放攻击方面存在安全隐患，但研究人员已经提出了解决这些问题的修补程序，并且某些浏览器和服务器已启用了此功能。
文章没有实现0-RTT TLS，但评估其对资源加载时间和页面加载时间的影响，以了解它可能对Tor浏览器有多大帮助。
HTTP/3（基于QUIC的HTTP）还通过允许单个QUIC握手建立连接并协商加密来减少往返次数。

通过以上三种方法，减少了资源往返次数

重定向数据库。数据集中的许多页面在初始页面导航时重新定向客户端。例如，youtube.com重定向到https://youtube.com，然后重定向到https://www.youtube.com。每次重定向都会导致多次不必要的往返。

通过解析来自Web服务器的重定向响应来自动生成此数据库。 浏览器界面在跳过重定向时发送通知，以便还原或禁用规则。

HTTP/2数据库：收集使用HTTP/2的服务器列表，以消除协商ALPN的额外往返行程。

预取数据库： 根据BLAST日志自动生成资源预取数据库。如果客户端在解析资源响应之前知道哪些资源与页面相关联，则她可以在页面加载开始后立即请求这些资源。 这使资源树结构变得扁平，并消除了资源与其子资源之间原本必需的往返。 某些资源基于随机或动态活动（例如广告），因此无法有效地预取。

对变更的评估

分别对每一个变化进行累积和评估。在累积评估中，下表中的后一项改进包含了之前的所有改进：

1. 具有HTTP/2的原始Tor浏览器
2. TCP Fast Open
3. Optimistic Data
4. 0-RTT TLS
5. 重定向数据库
6. HTTP/2数据库
7. 预取数据库

在图6显示了根据BLAST模拟器的平均页面加载时间和资源加载时间。 除了HTTP/2数据库之外，每个添加的特性都明显减少了这两个加载时间。使用数据库的资源预取产生了最大的改进，仅此一项就能够将平均页面加载时间减少35%；所有功能的组合下平均页面加载时间减少61%，从18秒减少到7.1秒。

Top 200的网页中，平均每页预取55.7个资源，58%的资源是预取的。预取的资源中只有1%是误报，因此额外的带宽成本相当低。 包含Top 10000个网页的数据库的小于1MB，因此定期更新这样一个数据库几乎没有存储或通信成本。

改进的拓展性

89%的页面的加载时间至少减少了25%，68%的页面的加载时间至少减少了50%。

评估在某些类型的页面（如较小的页面或资源较少的页面）中，加载时间是否会不成比例地减少。为此，根据三个特性:总页面大小、资源树高度和资源数量来衡量性能改进（以百分比表示）。相应的r相关值分别为0.20、0.03和0.08,表明改进在所有类型的页面中都是一样的。

将数据集分成两个相等的部分：总页面大小大于/小于1.36MB，观察到下半部分有62%±24%的改进，上半部分有51%±31%的改进。

改进在所有页面都能生效，它们减少了往返时间，并使所有页面的资源树结构变平

执行情况评价

我们为Top 200 页面实施了两个功能的原型作为Firefox插件：

1. 重定向数据库，使用BLAST自动获取重定向
2. 服务器数据库，使用BLAST自动获取每个网页连接到的服务器，并在用户访问Top 200页面时立即创建到这些服务器的连接。

服务器数据库是预取数据库的一个较弱版本；我们不预取页面上的已知资源，而是预先建立到页面使用的已知服务器的连接，以便资源可以使用这些连接而无需等待。 通过插件实现Tor浏览器的预取数据库存在重大的技术挑战。两种实现都通过Tor浏览器在前200页的10个实例上进行评估。尽管这两种实现是兼容的，但它们是独立评估的。根据真实数据在下面给出结果

重定向数据库。重定向数据库允许用户在加载页面时跳过一些不必要的往返。在Top 200页面中，页面加载时间从18.4秒减少到15.7秒，减少了14.7%。每个页面减少了2.7秒±5.7秒，这是由于网络条件和Tor电路的随机性造成的一个很大的变化。 有80%的页面实例的加载时间减少；62%的页面实例的加载时间减少了1秒以上，而12%的页面实例的加载时间增加了1秒以上。 模拟器从17.3秒下降到15.5秒，降幅相似但较小，为10.4%。

服务器数据库。 服务器数据库允许用户在页面加载开始时而不是在需要资源时预先与所需服务器建立连接。 在Top 200页面中，我们将页面加载时间从18.5 s减少到16.8s,减少了9.4％。

每个实例的减少量是1.7s±6.0s，这比重定向数据库要大一些。 66％的页面实例的加载时间减少了。 66％的页面加载时间减少了超过1秒，而16％的页面增加超过一秒。

上图是两个特性显示了减少每个实例加载时间的CDF

讨论

• 可以将重定向和预取数据库作为Firefox附加组件来实现，不过要强制浏览器使用预取资源需要更改连接管理器。还需要对Tor本身进行更改，以便为客户端加载这些数据库

• 不建议实现HTTP/2数据库，因为它显示的性能增益很小