HTTPS中S带来的性可以损失

动机

随着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来保护使用户用过程的安全还是十分有必要的。我们也希望可信代理商能成为互联网的一个非常重要的组成部分。