http和https在性能上有什么主要的区别吗?我似乎记得读到过HTTPS的速度是HTTP的五分之一。这对当前的web服务器/浏览器有效吗?如果有,是否有相关白皮书支持?


当前回答

考虑到SSL需要一个非sll HTTP不需要的额外加密步骤,这几乎肯定是正确的。

其他回答

考虑到SSL需要一个非sll HTTP不需要的额外加密步骤,这几乎肯定是正确的。

要真正理解HTTPS如何增加延迟,您必须了解HTTPS连接是如何建立的。这是一个很好的图表。关键在于,客户端不是在2个“腿”(一个往返,你发送一个请求,服务器发送一个响应)后才获得数据,而是至少要到4个“腿”(2个往返)后才能获得数据。因此,如果一个数据包在客户端和服务器之间移动需要100毫秒,那么您的第一个HTTPS请求至少需要500毫秒。

当然,这可以通过重新使用HTTPS连接来缓解(浏览器应该这样做),但它确实解释了加载HTTPS网站时的部分初始停滞。

这里似乎有一个令人讨厌的边缘情况:Ajax胜过拥塞的wifi。

Ajax通常意味着KeepAlive在20秒后超时。然而,wifi意味着(理想的快速)ajax连接必须进行多次往返。更糟糕的是,wifi经常丢包,并且有TCP重传。在这种情况下,HTTPS执行得非常非常糟糕!

这个问题没有一个单一的答案。

加密总是会消耗更多的CPU。在许多情况下,这可以卸载到专用的硬件上,成本将根据所选择的算法而变化。例如,3des比AES更贵。有些算法对加密者来说比解密者更昂贵。有些则有相反的代价。

比批量加密更昂贵的是握手成本。新的连接将消耗更多的CPU。这可以通过会话恢复来减少,代价是保留旧的会话秘密直到它们过期。这意味着来自客户端的小请求是最贵的。

对于跨互联网流量,您可能不会注意到数据速率的成本,因为可用带宽太低了。但您肯定会在繁忙的服务器上的CPU使用情况中注意到这一点。

除了到目前为止提到的所有内容,请记住,出于安全原因,一些(所有?)web浏览器不会将通过HTTPS获得的缓存内容存储在本地硬盘上。这意味着,从用户的角度看,在浏览器重启后,含有大量静态内容的页面加载速度会变慢,而从服务器的角度看,通过HTTPS请求静态内容的量将比通过HTTP请求的量要高。