HTTP与HTTPS性能
http和https之间在性能上有什么重大区别？ 我似乎回想起，HTTPS可以是HTTP的五分之一。 这是适用于当前一代的网络服务器/浏览器？ 如果有，是否有任何白皮书支持？
这里有一个非常简单的答案： 剖析Web服务器的性能，以查看性能损失是否适合您的特定情况。 有几个工具可以比较HTTP和HTTPS服务器（JMeter和Visual Studio）的性能，而且它们很容易使用。
没有一些关于网站性质，硬件，软件和网络配置的信息，没有人能给你一个有意义的答案。
正如其他人所说，由于加密会有一定程度的开销，但它高度依赖于：
- 硬件
- 服务器软件
- 动态与静态内容的比率
- 客户到服务器的距离
- 典型的会话长度
- 等（我个人最喜欢的）
- 缓存客户的行为
根据我的经验，动态内容较多的服务器往往受HTTPS影响较小，因为与内容生成时间相比，加密所花的时间（SSL开销）是微不足道的。
服务于一小部分容易被缓存在内存中的静态页面的服务器会承受更高的开销（在一种情况下，吞吐量被“内部网”所占用）。
编辑：其他几个人提出的一点是SSL握手是HTTPS的主要成本。 这是正确的，这就是为什么“典型的会话长度”和“客户的缓存行为”是重要的。
许多非常短的会话意味着握手时间将压倒任何其他表现因素。 较长的会话将意味着在会议开始时将产生握手成本，但随后的请求将具有相对较低的开销。
客户端缓存可以在几个步骤完成，从大型代理服务器到单个浏览器缓存。 通常，HTTPS内容不会缓存在共享缓存中（尽管少数代理服务器可以利用中间人类型的行为来实现此目的）。 许多浏览器缓存当前会话的HTTPS内容，并经常在会话中缓存。 不缓存或减少缓存的影响意味着客户端将更频繁地检索相同的内容。 这导致更多的请求和带宽服务相同数量的用户。
HTTPS需要初始握手，可能会非常缓慢。 作为握手一部分传输的实际数据量并不是很大（一般在5kB以下），但是对于非常小的请求，这可能会带来相当大的开销。 但是，一旦握手完成，就会使用非常快速的对称加密形式，因此开销很小。 底线：通过HTTPS做出很多简短的请求将比HTTP慢很多，但是如果你在一个请求中传输大量的数据，那么差异将是微不足道的。
但是，keepalive是HTTP / 1.1中的默认行为，所以您将通过同一个连接执行一次握手，然后执行大量请求。 这对HTTPS有很大的影响。 你可能应该描述一下你的网站（正如其他人所建议的那样），但是我怀疑这个性能差异不会很明显。
要真正了解HTTPS如何增加延迟，您必须了解如何建立HTTPS连接。 这是一个很好的图表 。 关键是客户端不会在2个“腿”（一个往返，发送一个请求，服务器发送一个响应）之后获取数据，而是至少4条腿（2个往返） 。 因此，如果数据包在客户端和服务器之间移动需要100 ms，那么您的第一个HTTPS请求将至少需要500 ms。
当然，这可以通过重新使用HTTPS连接（浏览器应该这样做）来缓解，但是当加载HTTPS网站时，它确实解释了初始失速的一部分。
开销不是由于加密。 在现代的CPU上，SSL所需的加密是微不足道的。
开销是由于SSL握手，这是漫长的，并大大增加了HTTPS会话所需的往返次数。
测量（使用Firebug等工具）服务器在模拟高延迟链路末端的页面加载时间。 存在工具来模拟高延迟链接 – 对于Linux，有“netem”。 在相同的设置上将HTTP与HTTPS进行比较。
延迟可以通过以下方式在一定程度上得到缓解：
- 确保您的服务器使用HTTP Keepalive – 这允许客户端重新使用SSL会话，这避免了另一个握手
- 尽可能减少请求的数量 – 尽可能地结合资源（例如.js包括文件，CSS）并鼓励客户端缓存
- 减少页面加载的数量，例如通过加载页面中不需要的数据（可能在一个隐藏的HTML元素中），然后使用客户端脚本来显示它。
2014年12月更新
您可以使用AnthumChris的HTTP vs HTTPS Test网站轻松地在您自己的浏览器中测试HTTP和HTTPS性能之间的差异：“此页面测量其在不安全的HTTP和加密的HTTPS连接上的加载时间。 这两个页面加载360个独特的非缓存图像（共2.04 MB）。“
结果可能会让你大吃一惊。
由于Mozilla，Akamai，思科，电子前沿基金会和IdenTrust， Let's Encrypt证书颁发机构将在2015年夏季开始发布免费，自动化和开放的SSL证书，因此了解HTTPS性能至关重要。
2015年6月更新
Let's Encrypt的最新消息 – 2015年9月到达：
- 让我们加密发布时间表 （2015年6月16日）
- 让我们加密根证书和中间证书 （2015年6月4日）
- 我们加密用户协议草案 （2015年5月21日）
更多关于Twitter的信息： @letsencrypt
有关HTTPS和SSL / TLS性能的更多信息，请参阅：
- TLS快吗？
- 高性能浏览器网络，第4章：传输层安全
- 超频SSL
- SSL处理的解剖和性能
有关使用HTTPS的重要性的更多信息，请参阅：
- 为什么选择HTTPS？ （仅限HTTPS标准）
- 让我们加密 （互联网安全研究组）
- HTTPS无处不在 （电子前沿基金会）
总而言之，让我引用Ilya Grigorik的话 ： “TLS只有一个性能问题：它的使用不够广泛，其他方面都可以优化。
感谢Chris – HTTP vs HTTPS测试基准测试的作者 – 以下是他的评论。
目前的最佳答案并不完全正确。 正如其他人指出的那样，https需要握手，因此需要更多的tcpip往返。 在WAN环境中，延迟通常会成为限制因素，而不是服务器上CPU使用率的增加。 请记住，从欧洲到美国的延迟时间可能在200ms左右（torundtrip时间）。
你可以用HTTPWatch轻松地测量这个（对于单个用户的情况）
除了目前提到的所有内容之外，请记住，出于安全原因，某些（所有？）Web浏览器不会将通过HTTPS获取的缓存内容存储在本地硬盘上。 这意味着，从用户的角度来看，有大量静态内容的页面在浏览器重新启动后显示为加载速度较慢，从服务器的角度来看，通过HTTPS的静态内容请求量将高于通过HTTP的请求量。
这没有一个单一的答案。
加密总是会消耗更多的CPU。 在许多情况下，这可以卸载到专用硬件，并且成本将根据选择的算法而变化。 例如，3des比AES更昂贵。 一些算法对于加密器比解密器更昂贵。 有些有相反的成本。
比批量加密更昂贵的是握手成本。 新的连接将消耗更多的CPU。 这可以通过会话恢复来减少，代价是保持旧的会话秘密，直到它们到期。 这意味着来自客户的小的请求不会再回来，这是最昂贵的。
对于互联网流量，您可能不会注意到您的数据传输速率，因为可用带宽太低。 但是你一定会注意到它在繁忙的服务器上的CPU使用情况。
我可以告诉你（作为一个拨号用户），通过SSL的同一页面比通过普通HTTP慢几倍…
在许多情况下，SSL握手的性能影响可以通过两端（桌面和服务器）缓存SSL会话来缓解。 例如，在Windows机器上，SSL会话最多可以缓存10个小时。 请参阅http://support.microsoft.com/kb/247658/EN-US 。 一些SSL加速器也将有参数，允许您调整会话缓存的时间。
要考虑的另一个影响是，通过HTTPS提供的静态内容不会被代理缓存，这可能会降低通过同一代理访问网站的多个用户的性能。 这可以通过静态内容缓存在桌面上来缓解，Internet Explorer版本6和7缓存可缓存的HTTPS静态内容，除非有其他指示（工具菜单/ Internet选项/高级/安全/不保存加密页面到磁盘）。
我做了一个小实验，并从flickr（233 kb）获得了相同图像的16％时差：
7405/13368635263_d792fc1189_b.jpg
7405/13368635263_d792fc1189_b.jpg
当然，这些数字取决于许多因素，如计算机性能，连接速度，服务器负载，路径上的QoS（从浏览器到服务器的特定网络路径），但是它显示了总体思路：HTTPS比HTTP慢，因为它请求更多操作来完成（SSL握手和编码/解码数据）。
这里有一篇关于SSL握手延迟的文章（有点旧，但仍然很棒）。 帮助我确定SSL是通过慢速Internet连接使用我的应用程序的客户缓慢的主要原因：
由于我正在为我的项目调查同样的问题，所以我找到了这些幻灯片。 较老但有趣：
http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm
TLS快吗？ 是。
- 请观看： https ： //www.youtube.com/watch？v = 0EB7zh_7UE4
- 阅读： https : //istlsfastyet.com/
有许多项目旨在模糊线条并使HTTPS同样快速。 像SPDY和mod-spdy 。
HTTP VS HTTPS性能对比
与普通的旧HTTP相比，我总是将HTTPS与较慢的页面加载时间相关联。 作为一个Web开发人员，网页性能对我来说很重要，任何会降低我的网页性能的东西都是不可能的。
为了理解所涉及的性能影响，下面的图表给出了一个基本的想法，即当您使用HTTPS请求资源时发生的情况。
从上图可以看出，与使用普通HTTP相比，使用HTTPS时需要执行一些额外的步骤。 当您使用HTTPS发出请求时，需要进行握手以验证请求的真实性。 与HTTP请求相比，这种握手是一个额外的步骤，不幸的是会产生一些开销。
为了了解性能影响并亲自了解性能影响是否显着，我使用这个站点作为测试平台。 我前往webpagetest.org并使用视觉比较工具来比较使用HTTPS和HTTP的网站加载。
正如你可以从这里看到的是测试视频使用HTTPS的结果确实影响了我的页面加载时间，但是差异是微不足道的，我只注意到300毫秒的差异。 需要注意的是，这些时间取决于许多因素，例如计算机性能，连接速度，服务器负载以及与服务器的距离。
您的网站可能会有所不同，彻底测试您的网站并检查切换到HTTPS所涉及的性能影响非常重要。
我们可以提高性能吗？ 访问这里获取详细信息
在这里似乎有一个讨厌的边缘案例：在拥挤的无线网络上的Ajax。
Ajax通常意味着KeepAlive在20秒之后超时。 但是，wifi意味着（理想的快速）ajax连接必须进行多次往返。 更糟糕的是，wifi往往会丢失数据包，并且有TCP重新传输。 在这种情况下，HTTPS的执行真的非常糟糕！
更重要的性能差异是HTTPS会话在用户连接时处于打开状态。 HTTP会话只持续一个项目请求。
它正在运行一个网站与大量的并发用户，期望购买大量的内存。
鉴于SSL需要额外的加密步骤，而非SLL HTTP所不需要的，这几乎肯定会成为现实。
有一种方法来衡量这一点。 来自apache的称为jmeter的工具将测量吞吐量。 如果您使用Jmeter设置了大量的服务样本，那么在受控的环境中，使用和不使用SSL，您应该可以准确比较相对成本。 我会对你的结果感兴趣。
HTTPS具有加密/解密开销，因此总是会稍微慢一些。 SSL终止非常占用CPU。 如果您有设备卸载SSL，则根据服务器的负载情况，延迟差异可能几乎不明显。
