http和https在性能上有什么主要的区别吗?我似乎记得读到过HTTPS的速度是HTTP的五分之一。这对当前的web服务器/浏览器有效吗?如果有,是否有相关白皮书支持?
当前回答
目前最上面的答案并不完全正确。
正如其他人在这里指出的,https需要握手,因此需要更多的TCP/IP往返。
在WAN环境中,延迟通常成为限制因素,而不是服务器上增加的CPU使用量。
请记住,从欧洲到美国的延迟大约是200毫秒(往返时间)。
您可以使用HTTPWatch轻松地测量这一点(对于单个用户情况)。
其他回答
目前最上面的答案并不完全正确。
正如其他人在这里指出的,https需要握手,因此需要更多的TCP/IP往返。
在WAN环境中,延迟通常成为限制因素,而不是服务器上增加的CPU使用量。
请记住,从欧洲到美国的延迟大约是200毫秒(往返时间)。
您可以使用HTTPWatch轻松地测量这一点(对于单个用户情况)。
对此有一个非常简单的答案:分析您的web服务器的性能,看看在您的特定情况下性能损失是什么。有几个工具可以比较HTTP和HTTPS服务器的性能(我想到了JMeter和Visual Studio),而且它们很容易使用。
没有人能给你一个有意义的答案没有一些关于你的网站的性质,硬件,软件和网络配置的信息。
正如其他人所说,由于加密,会有一定程度的开销,但它高度依赖于:
硬件 服务器软件 动态与静态内容的比例 客户端到服务器的距离 典型会话长度 等等(我个人的最爱) 客户端的缓存行为
根据我的经验,动态内容较多的服务器受HTTPS的影响较小,因为与内容生成时间相比,加密所花费的时间(ssl开销)微不足道。
大量服务于相当小的静态页面集(这些页面可以很容易地缓存在内存中)的服务器会遭受更高的开销(在一个案例中,吞吐量在“内部网”上受到了影响)。
编辑:有一点已经被其他几个人提出,SSL握手是HTTPS的主要成本。这是正确的,这就是为什么“典型会话长度”和“客户端的缓存行为”很重要。
很多非常短的会议意味着握手时间将压倒其他任何表现因素。较长的会话将意味着在会话开始时产生握手成本,但后续请求的开销将相对较低。
Client caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache (though a few proxy servers can exploit a man-in-the-middle type behavior to achieve this). Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.
这个问题没有一个单一的答案。
加密总是会消耗更多的CPU。在许多情况下,这可以卸载到专用的硬件上,成本将根据所选择的算法而变化。例如,3des比AES更贵。有些算法对加密者来说比解密者更昂贵。有些则有相反的代价。
比批量加密更昂贵的是握手成本。新的连接将消耗更多的CPU。这可以通过会话恢复来减少,代价是保留旧的会话秘密直到它们过期。这意味着来自客户端的小请求是最贵的。
对于跨互联网流量,您可能不会注意到数据速率的成本,因为可用带宽太低了。但您肯定会在繁忙的服务器上的CPU使用情况中注意到这一点。
我可以告诉你(作为一个拨号用户),通过SSL访问同一个页面要比通过常规HTTP慢几倍…
Browsers can accept HTTP/1.1 protocol with either HTTP or HTTPS, yet browsers can only handle HTTP/2.0 protocol with HTTPS. The protocol differences from HTTP/1.1 to HTTP/2.0 make HTTP/2.0, on average, 4-5 times faster than HTTP/1.1. Also, of sites that implement HTTPS, most do so over the HTTP/2.0 protocol. Therefore, HTTPS is almost always going to be faster than HTTP simply due to the different protocol it generally uses. However, if HTTP over HTTP/1.1 is compared with HTTPS over HTTP/1.1, then HTTP is slightly faster, on average, than HTTPS.
以下是我使用Chrome(版本64)运行的一些比较:
HTTPS over HTTP/1.1:
0.47秒的平均页面加载时间 在HTTP/1.1上比HTTP慢0.05秒 比HTTP/2.0上的HTTPS慢0.37秒
HTTP over HTTP/1.1
0.42秒的平均页面加载时间 比HTTP/1.1上的HTTPS快0.05秒 比HTTP/2.0上的HTTPS慢0.32秒
HTTPS over HTTP/2.0
平均加载时间0.10秒 在HTTP/1.1上比HTTP快0.32秒 比HTTPS/1.1快0.37秒
推荐文章
- 如何检查表上持有哪些锁
- 检查字符串是否包含字符串列表中的元素
- 最好的方法在asp.net强制https为整个网站?
- Scala vs Python的Spark性能
- 现代c++能让你免费获得性能吗?
- 对于PostgreSQL表来说,多大才算太大?
- 如何阻止恶意代码欺骗“Origin”报头来利用CORS?
- 即使从未抛出异常,使用try-catch块的代价是否昂贵?
- 如何有效地从数组列表或字符串数组中删除所有空元素?
- 在SQL Server上使用varchar(MAX) vs TEXT
- .toArray(new MyClass[0]) or .toArray(new MyClass[myList.size()])?
- 为什么说“HTTP是无状态协议”?
- 是什么导致JNI调用变慢?
- 我需要HTTP GET请求的内容类型报头吗?
- 如何允许本地主机上的Apache使用HTTPS ?