HTTPS中S带来的性能损失
编辑:rootadmin
随着Let'sEncrypt等服务的出现，运用HTTPS的成本已经十分低廉了。也有越来越多的网站开始运用HTTPS了，在YouTube上，史无前例的有超过%的流量运用HTTPS。HTTPS中的S是Security的含义，而我们知道，安全总是伴随着成本的上升，HTTPS也不例外。HTTP上额外的安全性会带来那些成本上的提升呢？出于这个目的，本文研究了过去三年（即-年）间的HTTPS网络流量的变化，以及TLS(TransportLayerSecurity)对分别在有线网、Wi-Fi和3G连接的情况下对网络延迟、数据消耗、电池消耗的影响。我们将首先介绍本文的结论，之后分别介绍HTTPS的运用趋势、对网页加载时间的影响、对数据流量的影响、对电池生命的影响，对增值服务的影响。
HTTPS中S带来的性能损失 图 由上图可以显著看出，在3G环境下，%的网站HTTPS的额外延迟大于ms.在有线网络下的延迟小一点，但是依旧有%的运用HTTPS的网站需要额外加载多于ms. 通过分别运用HTTP协议和HTTPS协议加载相同网页的对比实验得出，相比于运用HTTP协议来说，运用HTTPS的网站加载时间显著更长。 那么是哪种故障导致HTTPS的加载时间更长呢？作者通过收集每个页面的HTTP请求/响应信息（HAR）发现如下图，虽然相比于HTTP，%的网站加载HTTPS时，建立更少的TCP连接；但是，接近一半的网站在建立TCP连接时，每一次握手却需要耗费更多的时间，这部分时间主要是由TLS引起的协商开销。因此，HTTPS的加载时间反而更长。HTTPS中S带来的性能损失 图 所以不难发现，HTTPS的开销与TLS握手的延迟带来的开销息息相关，但是此时还不能排除运用HTTPS协议的网页加载时间长短是否和网络状况的好坏有关。为了更好地了解其中的原因，作者修改了Tstat，并让Tstat从年4月3日由RES-*P收集的一小时pcap踪迹数据，约有万个TLS流量中提取（i）连续时间和（ii）每次TLS握手的字节数。作者选取了美国几个具有代表性的网站进行实验。通常我们认为，网络延迟的长短与客户端和服务器的之间的远近有关，因此作者引入外部的RTT来表示上述距离，当RTT大于ms的时候表示服务器已经在欧洲之外了。然而在实验中发现，即使是客户端与服务器的距离很近，TLS握手的连续时间依旧很长（如下图左边），以TLS协商延迟最小的Google为例（如下图中间），大约%的TLS握手连续时间在ms以内，%超过ms。由此可以看出一个完整的TLS握手请求时间至少是RTT的2倍以上，由此不难发现TLS握手请求为服务器带来的巨大额外开销。一般来时，可能由于客户或服务器开销，或网络拥塞，或缓慢的OCSP认证，5%的请求一般都会经过一个时长是RTT的倍的握手。 更近一步看，可以发现有4％的客户体验TLS握手连续时间最短的一个连接超过毫秒（如下图中间）。对于这种连接，％（％）具有ms（ms）的内部RTT（即有利位置和最终用户设备之间的RTT），较不保守的阈值（例如1秒）也是如此。这表明即使是具有良好网络连接性的客户端依旧遭受TLS握手开销的困扰。TLS快速协商有助于减少握手延迟，但是我们发现只有％的连接被运用。我们推测这是一个下限，但不幸的是，根据现有数据，我们无法评估从更广泛采用TLS快速协商获得的可实现的上限。HTTPS中S带来的性能损失 图 对数据流量运用的影响 HTTPS的运用对数据流量也可能会有一定的影响，这是由于：TLS握手包的数据我们往往无法优化这一过程中的缓存和进行压缩的代理 所以我们可以将其分为两部分讨论，分别来研究。 TLS握手包的开销 TLS握手包开销的影响，很大程度上取决于整体的数据包数量：很显著，如果整体的数据包数量越大，那相对来说，协商过程中的开销所占的比重就会越低。HTTPS中S带来的性能损失 图 上图展示了各大网站中TLS握手包所占的量。我们发现，大多数TLS的连接都处于非重度运用的状态，事实上，这些连接中有一半都是TLS握手包占总的包大小的%以上。当然，也有一些服务是非常高效率的，他们重度运用TLS的连接，例如AmazonS3，这相对地减少了在协商阶段的消耗。也有一些服务是会在真正发送数据时选择运用“预打开”连接，这掩盖了一些对延迟的影响。因为在这种情况下，如果连接没有被真正的运用，TLS的开销就会占到总开销的%。 不过总的来说，TLS的开销大约占到总开销的5%。 网络中的代理 HTTPS会阻止一些在网络中的内容优化措施，例如一些压缩和缓存的代理。为了衡量这种无法运用代理所带来的影响，作者分析了两种生产级别的移动环境上的HTTP代理Transp-Proxy和OptIn-Proxy，Transp-Proxy是一个服务了两千万欧洲用户的、广泛使用于欧洲大型*的的透明代理。OptIn-Proxy则是一个每日服务两千多用户的、同样广泛使用于欧洲国家的显式代理。 作者分别讨论了HTTPS对缓存和压缩两方面的影响。 对于缓存来说，在过去两年间，Transp-Proxy的命中率约有.9%。对于一个单一服务万订阅者的的Transp-Proxy实例来说，这意味着每天可以节省高达2TB的流量。实际上，这一命中率已经是下降的结果了。在年其命中率可以达到.8%，到了年就只有.2%了。OptIn-Proxy的结果与Transp-Proxy的结果相似。 但作者也同时提到，这一命中率的下降是多种原因造成的，亦有可能是个性化的内容快速产生，使得命中率下降，也有可能是HTTPS的广泛运用使得命中率下降。但无论如何，代理节省的流量还是十分可观的，但倘若所有切换到HTTPS，就没有办法运用代理节省流量了。（不知道3年后的今天，有没有办法代理HTTPS的流量？） 第二方面则是压缩，在将内容返回用户之前，*往往会*无损的压缩（例如运用gzip），甚至会重新编码图像或是调整图像的大小。这个功能在网络总流量有限时是非常有用的（想一想浏览器的限流模式，是不是在流量只有M的时候非常有用）。Transp-Proxy的日志显示其压缩比例高达.5%。对于一些重度用户，这一压缩可能是十分关键的，每个月可能都会省下数百MB的流量。 总的来说，普通用户可能没有关心到HTTPS中缓存和压缩的消失带来的流量增多，但对于*来说，这就是一个比较显著的趋势了。 对电池运用时间的影响 HTTPS的运用对电池的运用时间有潜在的负面影响，这是由于：加解密*作会运用额外的处理器时间由于需要更长的下载时间，因此会有天线方面的消耗 作者将实验分成了两部分，合成的内容和真实的内容。 合成内容 作者运用了一部带电表的GalaxySII，将亮度调至最低，每微秒测量一次电力消耗。用这部定位器通过3G及Wi-Fi下载从1KB-1MB的合成的内容。每个内容都会分别运用HTTP和HTTPS下载次。值得注意的是，作者在Android上编译了c*，以避免无关的影响。HTTPS中S带来的性能损失 图 上图展示了在不一样情况下完成一次下载的平均时间和电量的消耗情况。很显著，电池电量和下载时间是相关联的。而且，对于一些大文件，在Wi-Fi情况下的开销是比较显著的（相对于3G情况下），但造成这一点的原因尚不明确。总的来说，除去下载时间不一样之外，HTTPS中的加密对电池的影响是几乎没有的。 真实内容 作者首先在自己的服务器上镜像了一个CNN的首页，并且运用Android上的Chrome来分别运用HTTP和HTTPS下载次。结果如图：HTTPS中S带来的性能损失 图 可以看出，虽然有一定的开销，但并没有十分显著。 在第二个实验中，作者播放了5-分钟的YouTube*。但是由于在定位器上的客户端及网站没有办法播放非HTTPS的*，所以作者强制运用桌面版本的YouTube网站来运用HTTP。经过作者的测验，在Wi-Fi情况下，HTTP和HTTPS几乎没有差别；但在3G情况下，网络中的代理极大地影响了HTTP的结果，有两个*运用HTTP的电池电量消耗比HTTPS的结果少了将近%，另外两个*也节省了%-%。HTTPS中S带来的性能损失 图 造成这一结果的是代理的两个行为： 1.一方面，代理*了下载速率以减少网络拥塞（这和我们下载时选择“上网优先”是相似的），同时如果用户取消了，不再看这个*了，这样做也可以减少对网络流量的消耗（想一想，有多少次我们点开了一个*，然后又关掉它）。如果不运用代理的话，整个*会在进入时快速被下载完，之后网络设备就处于休眠状态。而运用代理的话，*是较慢且稳定的，在整个*播放过程中会即放即播，因此网络设备没有休息的机会，这会导致更多的电量消耗。 2.另一方面，代理会将JavaScript*页面中，它会改写发送到YouTube服务器上的URL，以获得更适应移动设备的编码和*质量。对于第二个和第四个*，最初获得了webm格式的*，而这两种*格式在我们的移动设备上都不支持硬*，因此代理将其更改为了mp4格式的*。硬*带来的优势抵消了部分网络设备的电量消耗。 在真实情况下的实验，控制变量的难度是相当大的。因此作者也提到，对这些数字应抱有怀疑和审慎的态度(shouldbetakenwithagrainofsalt)。如果试图严谨地控制变量，我们应自行建立一个HTTPS和一个HTTP的*站点，*源运用同一个*的不一样格式来进行这个实验。 总的来说，这个实验还是告诉我们：HTTPS中加密的*作对电池的消耗的影响并不显著，但代理可能会极大地影响电池的生命。*应仔细地考虑其中间件的规划，社区也是时候考虑是不是要全盘切换到HTTPS了。 总结和看法：鱼和熊掌不可得兼 安全和效率往往是很难同时兼顾的两面。尽管近年来的设备和技术更新已经大大降低了运用HTTPS的成本，但HTTPS的性能消耗依然是值得我们注意的一个问题。与此同时，HTTP2.0也开始慢慢走入视野，除去安全性的考量，它的性能表现如何也是值得我们多加关心的一个话题。 不得不说的是，在国内的网络环境下，甚至存在一些**的问题下，网站运用HTTPS来保护用户运用过程的安全还是十分有必要的。我们也希望可信代理可以成为互联网的一个非常重要的组成部分。
整理分享HTTPS中S带来的性能损失 ，希望有所帮助，仅作参考，欢迎阅读内容。
内容相关其他词:,内容如对您有帮助，希望把内容链接给更多的朋友！
HTTPS中S带来的性能损失 图 结论： 在三个截获自普通人家中的网络和监听网络的数据集以及自己进行的实验上，得出了以下的几个结论： 1.尽管存在着潜在的部署成本，HTTPS的运用还是很快的增长。 2.HTTPS存在一些较为显著的延时消耗影响。 3.HTTPS的数据开销是有限的 4.对于一些大文件，HTTPS带来了显著的电池消耗。 HTTPS运用趋势 (注意，由于这是一篇年的文章，作者提及的运用成本可能不适用。在最近几年，随着Let'sEncrypt等免费的签发机构，大大降低了HTTPS的上车成本，扩大了其运用。) 通常来说，运用HTTPS都会增加基础设施的成本（如计算成本、内存、数据开销等），更主要的则是证书的成本（有的高达美刀一年），因此大家会想仅在必要的时候运用HTTPS。为了测验HTTPS的运用趋势，我们监测了欧洲主要的一个*P的,个居民家里的网络，在监测点运用一个实现了对HTTP和HTTPS进行分类的TStat程序。对于TLS的连接，TStat解析如下的内容： 1.SNI(ServerNameIndication),即欲连接的主机名。 2.服务器证书的所附带的SCN(SubjectCommonName)HTTPS中S带来的性能损失 图 上图展示了从年4月到年9月的HTTPS流量变化，HTTPS流量的增长是惊人的：在两年间就增长了超过2倍。到了年的9月，.3%的网络连接都已经运用了HTTPS。 对网页加载时间的影响 我们都知道运用HTTPS协议进行通信的过程中会对数据进行加密和解密，所以不难推测对于相同内容的页面在分别运用HTTP和HTTPS时的加载时间会有所不一样，因此对于这一点，作者进行了验证实验。 作者分别让测验的客户端处在用3G路由器连接的监听网络环境和通过光纤连接的有线网络中，进行两次实验。每次实验，测验机均在PhantomJS浏览器中首先运用HTTP协议来加载在Alexa网站*ZZ词语*问量为前的网站次，之后运用HTTPS协议做相同的*作。实验结果如下：HTTPS中S带来的性能损失 图 由上图可以显著看出，在3G环境下，%的网站HTTPS的额外延迟大于ms.在有线网络下的延迟小一点，但是依旧有%的运用HTTPS的网站需要额外加载多于ms. 通过分别运用HTTP协议和HTTPS协议加载相同网页的对比实验得出，相比于运用HTTP协议来说，运用HTTPS的网站加载时间显著更长。 那么是哪种故障导致HTTPS的加载时间更长呢？作者通过收集每个页面的HTTP请求/响应信息（HAR）发现如下图，虽然相比于HTTP，%的网站加载HTTPS时，建立更少的TCP连接；但是，接近一半的网站在建立TCP连接时，每一次握手却需要耗费更多的时间，这部分时间主要是由TLS引起的协商开销。因此，HTTPS的加载时间反而更长。HTTPS中S带来的性能损失 图 所以不难发现，HTTPS的开销与TLS握手的延迟带来的开销息息相关，但是此时还不能排除运用HTTPS协议的网页加载时间长短是否和网络状况的好坏有关。为了更好地了解其中的原因，作者修改了Tstat，并让Tstat从年4月3日由RES-*P收集的一小时pcap踪迹数据，约有万个TLS流量中提取（i）连续时间和（ii）每次TLS握手的字节数。作者选取了美国几个具有代表性的网站进行实验。通常我们认为，网络延迟的长短与客户端和服务器的之间的远近有关，因此作者引入外部的RTT来表示上述距离，当RTT大于ms的时候表示服务器已经在欧洲之外了。然而在实验中发现，即使是客户端与服务器的距离很近，TLS握手的连续时间依旧很长（如下图左边），以TLS协商延迟最小的Google为例（如下图中间），大约%的TLS握手连续时间在ms以内，%超过ms。由此可以看出一个完整的TLS握手请求时间至少是RTT的2倍以上，由此不难发现TLS握手请求为服务器带来的巨大额外开销。一般来时，可能由于客户或服务器开销，或网络拥塞，或缓慢的OCSP认证，5%的请求一般都会经过一个时长是RTT的倍的握手。 更近一步看，可以发现有4％的客户体验TLS握手连续时间最短的一个连接超过毫秒（如下图中间）。对于这种连接，％（％）具有ms（ms）的内部RTT（即有利位置和最终用户设备之间的RTT），较不保守的阈值（例如1秒）也是如此。这表明即使是具有良好网络连接性的客户端依旧遭受TLS握手开销的困扰。TLS快速协商有助于减少握手延迟，但是我们发现只有％的连接被运用。我们推测这是一个下限，但不幸的是，根据现有数据，我们无法评估从更广泛采用TLS快速协商获得的可实现的上限。HTTPS中S带来的性能损失 图 对数据流量运用的影响 HTTPS的运用对数据流量也可能会有一定的影响，这是由于：TLS握手包的数据我们往往无法优化这一过程中的缓存和进行压缩的代理 所以我们可以将其分为两部分讨论，分别来研究。 TLS握手包的开销 TLS握手包开销的影响，很大程度上取决于整体的数据包数量：很显著，如果整体的数据包数量越大，那相对来说，协商过程中的开销所占的比重就会越低。HTTPS中S带来的性能损失 图 上图展示了各大网站中TLS握手包所占的量。我们发现，大多数TLS的连接都处于非重度运用的状态，事实上，这些连接中有一半都是TLS握手包占总的包大小的%以上。当然，也有一些服务是非常高效率的，他们重度运用TLS的连接，例如AmazonS3，这相对地减少了在协商阶段的消耗。也有一些服务是会在真正发送数据时选择运用“预打开”连接，这掩盖了一些对延迟的影响。因为在这种情况下，如果连接没有被真正的运用，TLS的开销就会占到总开销的%。 不过总的来说，TLS的开销大约占到总开销的5%。 网络中的代理 HTTPS会阻止一些在网络中的内容优化措施，例如一些压缩和缓存的代理。为了衡量这种无法运用代理所带来的影响，作者分析了两种生产级别的移动环境上的HTTP代理Transp-Proxy和OptIn-Proxy，Transp-Proxy是一个服务了两千万欧洲用户的、广泛使用于欧洲大型*的的透明代理。OptIn-Proxy则是一个每日服务两千多用户的、同样广泛使用于欧洲国家的显式代理。 作者分别讨论了HTTPS对缓存和压缩两方面的影响。 对于缓存来说，在过去两年间，Transp-Proxy的命中率约有.9%。对于一个单一服务万订阅者的的Transp-Proxy实例来说，这意味着每天可以节省高达2TB的流量。实际上，这一命中率已经是下降的结果了。在年其命中率可以达到.8%，到了年就只有.2%了。OptIn-Proxy的结果与Transp-Proxy的结果相似。 但作者也同时提到，这一命中率的下降是多种原因造成的，亦有可能是个性化的内容快速产生，使得命中率下降，也有可能是HTTPS的广泛运用使得命中率下降。但无论如何，代理节省的流量还是十分可观的，但倘若所有切换到HTTPS，就没有办法运用代理节省流量了。（不知道3年后的今天，有没有办法代理HTTPS的流量？） 第二方面则是压缩，在将内容返回用户之前，*往往会*无损的压缩（例如运用gzip），甚至会重新编码图像或是调整图像的大小。这个功能在网络总流量有限时是非常有用的（想一想浏览器的限流模式，是不是在流量只有M的时候非常有用）。Transp-Proxy的日志显示其压缩比例高达.5%。对于一些重度用户，这一压缩可能是十分关键的，每个月可能都会省下数百MB的流量。 总的来说，普通用户可能没有关心到HTTPS中缓存和压缩的消失带来的流量增多，但对于*来说，这就是一个比较显著的趋势了。 对电池运用时间的影响 HTTPS的运用对电池的运用时间有潜在的负面影响，这是由于：加解密*作会运用额外的处理器时间由于需要更长的下载时间，因此会有天线方面的消耗 作者将实验分成了两部分，合成的内容和真实的内容。 合成内容 作者运用了一部带电表的GalaxySII，将亮度调至最低，每微秒测量一次电力消耗。用这部定位器通过3G及Wi-Fi下载从1KB-1MB的合成的内容。每个内容都会分别运用HTTP和HTTPS下载次。值得注意的是，作者在Android上编译了c*，以避免无关的影响。HTTPS中S带来的性能损失 图 上图展示了在不一样情况下完成一次下载的平均时间和电量的消耗情况。很显著，电池电量和下载时间是相关联的。而且，对于一些大文件，在Wi-Fi情况下的开销是比较显著的（相对于3G情况下），但造成这一点的原因尚不明确。总的来说，除去下载时间不一样之外，HTTPS中的加密对电池的影响是几乎没有的。 真实内容 作者首先在自己的服务器上镜像了一个CNN的首页，并且运用Android上的Chrome来分别运用HTTP和HTTPS下载次。结果如图：HTTPS中S带来的性能损失 图 可以看出，虽然有一定的开销，但并没有十分显著。 在第二个实验中，作者播放了5-分钟的YouTube*。但是由于在定位器上的客户端及网站没有办法播放非HTTPS的*，所以作者强制运用桌面版本的YouTube网站来运用HTTP。经过作者的测验，在Wi-Fi情况下，HTTP和HTTPS几乎没有差别；但在3G情况下，网络中的代理极大地影响了HTTP的结果，有两个*运用HTTP的电池电量消耗比HTTPS的结果少了将近%，另外两个*也节省了%-%。HTTPS中S带来的性能损失 图 造成这一结果的是代理的两个行为： 1.一方面，代理*了下载速率以减少网络拥塞（这和我们下载时选择“上网优先”是相似的），同时如果用户取消了，不再看这个*了，这样做也可以减少对网络流量的消耗（想一想，有多少次我们点开了一个*，然后又关掉它）。如果不运用代理的话，整个*会在进入时快速被下载完，之后网络设备就处于休眠状态。而运用代理的话，*是较慢且稳定的，在整个*播放过程中会即放即播，因此网络设备没有休息的机会，这会导致更多的电量消耗。 2.另一方面，代理会将JavaScript*页面中，它会改写发送到YouTube服务器上的URL，以获得更适应移动设备的编码和*质量。对于第二个和第四个*，最初获得了webm格式的*，而这两种*格式在我们的移动设备上都不支持硬*，因此代理将其更改为了mp4格式的*。硬*带来的优势抵消了部分网络设备的电量消耗。 在真实情况下的实验，控制变量的难度是相当大的。因此作者也提到，对这些数字应抱有怀疑和审慎的态度(shouldbetakenwithagrainofsalt)。如果试图严谨地控制变量，我们应自行建立一个HTTPS和一个HTTP的*站点，*源运用同一个*的不一样格式来进行这个实验。 总的来说，这个实验还是告诉我们：HTTPS中加密的*作对电池的消耗的影响并不显著，但代理可能会极大地影响电池的生命。*应仔细地考虑其中间件的规划，社区也是时候考虑是不是要全盘切换到HTTPS了。 总结和看法：鱼和熊掌不可得兼 安全和效率往往是很难同时兼顾的两面。尽管近年来的设备和技术更新已经大大降低了运用HTTPS的成本，但HTTPS的性能消耗依然是值得我们注意的一个问题。与此同时，HTTP2.0也开始慢慢走入视野，除去安全性的考量，它的性能表现如何也是值得我们多加关心的一个话题。 不得不说的是，在国内的网络环境下，甚至存在一些**的问题下，网站运用HTTPS来保护用户运用过程的安全还是十分有必要的。我们也希望可信代理可以成为互联网的一个非常重要的组成部分。 
