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


当前回答

HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

然而,keepalive是HTTP/1.1的默认行为,所以你会在同一个连接上进行一次握手,然后进行多次请求。这对HTTPS产生了重大影响。您可能应该对站点进行概要分析(正如其他人建议的那样)以确保这一点,但我怀疑性能差异不会很明显。

其他回答

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

HTTPS有加密/解密的开销,所以它总是会稍微慢一点。SSL终止是非常消耗CPU的。如果您有卸载SSL的设备,则延迟的差异可能几乎不明显,这取决于服务器所处的负载。

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

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

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

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

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

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

我做了一个小实验,从flickr (233 kb)上获得了16%的时差:

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

当然,这些数字取决于许多因素,如计算机性能、连接速度、服务器负载、路径上的QoS(从浏览器到服务器的特定网络路径),但它显示了一个大致的想法:HTTPS比HTTP慢,因为它需要更多的操作来完成(SSL握手和编码/解码数据)。