HTTPS中S带来的性能损失

本文编译自David Naylor et all, The Cost of the “S” in HTTPS, CONEXT 2014

动机

随着Let’s Encrypt等服务的出现，使用HTTPS的成本已经十分低廉了。也有越来越多的网站开始使用HTTPS了，在YouTube上，史无前例的有超过50%的流量使用HTTPS。HTTPS中的S是Security的含义，而我们知道，安全总是伴随着成本的上升，HTTPS也不例外。HTTP上额外的安全性会带来那些成本上的提高呢？出于这个目的，本文研究了过去三年（即2011-2014年）间的HTTPS网络流量的变化，以及TLS(Transport Layer Security)对分别在有线网、Wi-Fi和3G连接的情况下对网络延迟、数据消耗、电池消耗的影响。我们将首先介绍本文的结论，之后分别介绍HTTPS的使用趋势、对网页加载时间的影响、对数据流量的影响、对电池生命的影响，对增值服务的影响。

结论

在三个截获自普通人家中的网络和无线网络的数据集以及自己进行的实验上，得出了以下的三个结论：
1.尽管存在着潜在的部署成本，HTTPS的使用还是很快的增长。
2.HTTPS存在一些较为明显的延时消耗影响。
3.HTTPS的数据开销是有限的
4.对于一些大文件，HTTPS带来了显著的电池消耗。

HTTPS使用趋势

(注意，由于这是一篇2014年的文章，作者提及的使用成本可能不适用。在最近几年，随着Let’s Encrypt等免费的签发机构，大大降低了HTTPS的上车成本，扩大了其使用。)

通常来说，使用HTTPS都会增加基础设施的成本（如计算成本、内存、数据开销等），更主要的则是证书的成本（有的高达1999美刀一年），因此大家会想仅在必要的时候使用HTTPS。为了测试HTTPS的使用趋势，我们监测了欧洲主要的一个ISP的25,000个居民家里的网络，在监测点使用一个实现了对HTTP和HTTPS进行分类的TStat程序。对于TLS的连接，TStat解析如下的内容：
1.SNI(Server Name Indication),即欲连接的主机名。
2.服务器证书的所附带的SCN(Subject Common Name)

上图展示了从2012年4月到2014年9月的HTTPS流量变化，HTTPS流量的增长是惊人的：在两年间就增长了超过2倍。到了2014年的9月，44.3%的网络连接都已经使用了HTTPS。

对网页加载时间的影响

我们都知道使用HTTPS协议进行通信的过程中会对数据进行加密和解密，所以不难推测对于相同内容的页面在分别使用HTTP和HTTPS时的加载时间会有所不同，因此对于这一点，作者进行了验证实验。

作者分别让测试的客户端处在用3G路由器连接的无线网络环境和通过光纤连接的有线网络中，进行两次实验。每次实验，测试机均在PhantomJS浏览器中首先使用HTTP协议来加载在Alexa网站上访问量为前500的网站20次，之后使用HTTPS协议做相同的操作。实验结果如下：

由上图可以明显看出，在3G环境下，90%的网站HTTPS的额外延迟大于500ms.在有线网络下的延迟小一点，但是仍然有40%的使用HTTPS的网站需要额外加载多于500ms.

通过分别使用HTTP协议和HTTPS协议加载相同网页的对比实验得出，相比于使用HTTP协议来说，使用HTTPS的网站加载时间明显更长。

那么是什么原因导致HTTPS的加载时间更长呢？作者通过收集每个页面的HTTP请求/响应信息（HAR）发现如下图，虽然相比于HTTP，40%的网站加载HTTPS时，建立更少的TCP连接；但是，接近一半的网站在建立TCP连接时，每一次握手却需要耗费更多的时间，这部分时间主要是由TLS引起的协商开销。因此，HTTPS的加载时间反而更长。

所以不难发现，HTTPS的开销与TLS握手的延迟带来的开销息息相关，但是此时还不能排除使用HTTPS协议的网页加载时间长短是否和网络状况的好坏有关。为了更好地了解其中的原因，作者修改了Tstat，并让Tstat从2014年4月3日由RES-ISP收集的一小时pcap踪迹数据，约有100万个TLS流量中提取（i）持续时间和（ii）每次TLS握手的字节数。作者选取了美国几个具有代表性的网站进行实验。通常我们认为，网络延迟的长短与客户端和服务器的之间的远近有关，因此作者引入外部的RTT来表示上述距离，当RTT大于100ms的时候表示服务器已经在欧洲之外了。然而在实验中发现，即使是客户端与服务器的距离很近，TLS握手的持续时间仍然很长（如下图左边），以TLS协商延迟最小的Google为例（如下图中间），大约90%的TLS握手持续时间在300ms以内，10%超过300ms。由此可以看出一个完整的TLS握手请求时间至少是RTT的2倍以上，由此不难发现TLS握手请求为服务器带来的巨大额外开销。一般来时，可能由于客户或服务器开销，或网络拥塞，或缓慢的OCSP认证，5%的请求一般都会经过一个时长是RTT的10倍的握手。

更近一步看，可以发现有4％的客户体验TLS握手持续时间最短的一个连接超过300毫秒（如下图中间）。 对于这种连接，50％（75％）具有51ms（97ms）的内部RTT（即有利位置和最终用户设备之间的RTT），较不保守的阈值（例如1秒）也是如此。这表明即使是具有良好网络连接性的客户端仍然遭受TLS握手开销的困扰。 TLS快速协商有助于减少握手延迟，但是我们发现只有30％的连接被使用。 我们推测这是一个下限，但不幸的是，根据现有数据，我们无法评估从更广泛采用TLS快速协商获得的可实现的上限。

对数据流量使用的影响

HTTPS的使用对数据流量也可能会有一定的影响，这是由于：

1. TLS握手包的数据
2. 我们往往无法优化这一过程中的缓存和进行压缩的代理

所以我们可以将其分为两部分讨论，分别来研究。

TLS握手包的开销

TLS握手包开销的影响，很大程度上取决于整体的数据包数量：很明显，如果整体的数据包数量越大，那相对来说，协商过程中的开销所占的比重就会越低。

上图展示了各大网站中TLS握手包所占的量。我们发现，大多数TLS的连接都处于非重度使用的状态，事实上，这些连接中有一半都是TLS握手包占总的包大小的42%以上。当然，也有一些服务是非常高效率的，他们重度使用TLS的连接，例如Amazon S3，这相对地减少了在协商阶段的消耗。也有一些服务是会在真正发送数据时选择使用“预打开”连接，这掩盖了一些对延迟的影响。因为在这种情况下，如果连接没有被真正的使用，TLS的开销就会占到总开销的100%。

不过总的来说，TLS的开销大约占到总开销的5%。

网络中的代理

HTTPS会阻止一些在网络中的内容优化措施，例如一些压缩和缓存的代理。为了衡量这种无法使用代理所带来的影响，作者分析了两种生产级别的移动环境上的HTTP代理Transp-Proxy和OptIn-Proxy，Transp-Proxy是一个服务了两千万欧洲用户的、广泛应用于欧洲大型运营商的的透明代理。OptIn-Proxy则是一个每日服务两千多用户的、同样广泛应用于欧洲国家的显式代理。

作者分别讨论了HTTPS对缓存和压缩两方面的影响。

对于缓存来说，在过去两年间，Transp-Proxy的命中率约有14.9%。对于一个单一服务300万订阅者的的Transp-Proxy实例来说，这意味着每天可以节省高达2TB的流量。实际上，这一命中率已经是下降的结果了。在2012年其命中率可以达到16.8%，到了2014年就只有13.2%了。OptIn-Proxy的结果与Transp-Proxy的结果类似。

但作者也同时提到，这一命中率的下降是多种因素造成的，亦有可能是个性化的内容快速产生，使得命中率下降，也有可能是HTTPS的广泛使用使得命中率下降。但无论如何，代理节省的流量还是十分可观的，但倘若全部切换到HTTPS，就没有办法使用代理节省流量了。（不知道3年后的今天，有没有办法代理HTTPS的流量？）

第二方面则是压缩，在将内容返回用户之前，网络代理往往会做一次无损的压缩（例如使用gzip），甚至会重新编码图像或是调整图像的大小。这个功能在网络总流量有限时是非常有用的（想一想浏览器的限流模式，是不是在流量只有30M的时候非常有用）。Transp-Proxy的日志显示其压缩比例高达28.5%。对于一些重度用户，这一压缩可能是十分关键的，每个月可能都会省下数百MB的流量。

总的来说，普通用户可能没有关注到HTTPS中缓存和压缩的消失带来的流量增多，但对于运营商来说，这就是一个比较明显的趋势了。

对电池使用时间的影响

HTTPS的使用对电池的使用时间有潜在的负面影响，这是由于：

1. 加解密操作会使用额外的CPU时间
2. 由于需要更长的下载时间，因此会有天线方面的消耗

作者将实验分成了两部分，合成的内容和真实的内容。

合成内容

作者使用了一部带电表的Galaxy S II，将亮度调至最低，每200微秒测量一次电力消耗。用这部手机通过3G及Wi-Fi下载从1KB-1MB的合成的内容。每个内容都会分别使用HTTP和HTTPS下载100次。值得注意的是，作者在Android上编译了curl，以避免无关的影响。

上图展示了在不同情况下完成一次下载的平均时间和电量的消耗情况。很明显，电池电量和下载时间是相关联的。而且，对于一些大文件，在Wi-Fi情况下的开销是比较明显的（相对于3G情况下），但造成这一点的原因尚不明确。总的来说，除去下载时间不同之外，HTTPS中的加密对电池的影响是几乎没有的。

真实内容

作者首先在自己的服务器上镜像了一个CNN的首页，并且使用Android上的Chrome来分别使用HTTP和HTTPS下载50次。结果如图：

可以看出，虽然有一定的开销，但并没有十分显著。

在第二个实验中，作者播放了5-12分钟的YouTube视频。但是由于在手机上的客户端及网站没有办法播放非HTTPS的视频，所以作者强制使用桌面版本的YouTube网站来使用HTTP。经过作者的测试，在Wi-Fi情况下，HTTP和HTTPS几乎没有差别；但在3G情况下，网络中的代理极大地影响了HTTP的结果，有两个视频使用HTTP的电池电量消耗比HTTPS的结果少了将近25%，另外两个视频也节省了10%-20%。

造成这一结果的是代理的两个行为：

1.一方面，代理限制了下载速率以减少网络拥塞（这和我们下载时选择“上网优先”是类似的），同时如果用户取消了，不再看这个视频了，这样做也可以减少对网络流量的消耗（想一想，有多少次我们点开了一个视频，然后又关掉它）。如果不使用代理的话，整个视频会在进入时迅速被下载完，之后网络设备就处于休眠状态。而使用代理的话，下载速度是较慢且稳定的，在整个视频播放过程中会即放即播，因此网络设备没有休息的机会，这会导致更多的电量消耗。

2.另一方面，代理会将JavaScript插入页面中，它会改写发送到YouTube服务器上的URL，以获取更适应移动设备的编码和视频质量。对于第二个和第四个视频，最初获取了webm格式的视频，而这两种视频格式在我们的移动设备上都不支持硬解码，因此代理将其更改为了mp4格式的视频。硬解码带来的优势抵消了部分网络设备的电量消耗。

在真实情况下的实验，控制变量的难度是相当大的。因此作者也提到，对这些数字应抱有怀疑和审慎的态度(should be taken with a grain of salt)。如果试图严谨地控制变量，我们应自行建立一个HTTPS和一个HTTP的视频站点，视频源使用同一个视频的不同格式来进行这个实验。

总的来说，这个实验还是告诉我们：

1. HTTPS中加密的操作对电池的消耗的影响并不显著，但代理可能会极大地影响电池的生命。
2. 运营商应仔细地考虑其中间件的设计，社区也是时候考虑是不是要全盘切换到HTTPS了。

总结和看法

鱼和熊掌不可得兼

安全和效率往往是很难同时兼顾的两面。尽管近年来的设备和技术更新已经大大降低了使用HTTPS的成本，但HTTPS的性能消耗依然是值得我们注意的一个问题。与此同时，HTTP 2.0也开始逐渐走入视野，除去安全性的考量，它的性能表现如何也是值得我们多加关注的一个话题。

但不得不说的是，在国内的网络环境下，甚至存在一些运营商劫持的问题下，网站使用HTTPS来保护用户使用过程的安全还是十分有必要的。我们也希望可信代理可以成为互联网的一个非常重要的组成部分。