SSL延迟有多大?

http://www.ruanyifeng.com/blog/2014/09/ssl-latency.html

作者: 阮一峰

日期: 2014年9月24日

据说,Netscape公司当年设计SSL协议的时候,有人提过,将互联网所有链接都变成HTTPs开头的加密链接。

这个建议没有得到采纳,原因之一是HTTPs链接比不加密的HTTP链接慢很多。(另一个原因好像是,HTTPs链接默认不能缓存。)

自从我知道这个掌故以后,脑袋中就有一个观念:HTTPs链接很慢。但是,它到底有多慢,我并没有一个精确的概念。直到今天我从一篇文章中,学到了测量HTTPs链接耗时的方法。

首先我解释一下,为什么HTTPs链接比较慢。

HTTPs链接和HTTP链接都建立在TCP协议之上。HTTP链接比较单纯,使用三个握手数据包建立连接之后,就可以发送内容数据了。

上图中,客户端首先发送SYN数据包,然后服务器发送SYN+ACK数据包,最后客户端发送ACK数据包,接下来就可以发送内容了。这三个数据包的发送过程,叫做TCP握手。

再来看HTTPs链接,它也采用TCP协议发送数据,所以它也需要上面的这三步握手过程。而且,在这三步结束以后,它还有一个SSL握手

总结一下,就是下面这两个式子。

HTTP耗时 = TCP握手

HTTPs耗时 = TCP握手 + SSL握手

所以,HTTPs肯定比HTTP耗时,这就叫SSL延迟。

命令行工具curl有一个w参数,可以用来测量TCP握手和SSL握手的具体耗时,以访问支付宝为例。



$ curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://www.alipay.com

TCP handshake: 0.022, SSL handshake: 0.064

上面命令中的w参数表示指定输出格式,time_connect变量表示TCP握手的耗时,time_appconnect变量表示SSL握手的耗时(更多变量请查看文档实例),s参数和o参数用来关闭标准输出。

从运行结果可以看到,SSL握手的耗时(64毫秒)大概是TCP握手(22毫秒)的三倍。也就是说,在建立连接的阶段,HTTPs链接比HTTP链接要长3倍的时间,具体数字取决于CPU的快慢和网络状况。

所以,如果是对安全性要求不高的场合,为了提高网页性能,建议不要采用保密强度很高的数字证书。一般场合下,1024位的证书已经足够了,2048位和4096位的证书将进一步延长SSL握手的耗时。

(完)

时间: 2024-10-24 15:01:01

SSL延迟有多大?的相关文章

SSL延迟有多大?(转)

add by zhj: SSL层在TCP层之上,SSL握手是在TCP握手完成之后,除了这点之外,两者应该是相对独立的过程.在服务端,这两个过程有可能不在同一台主机上, 比如服务端用LVS+Nginx实现负载均衡,LVS是四层负载均衡,只解析到TCP层,并不会解析SSL层,而Nginx实现的是七层负载均衡,可以解析到应用层.因此, LVS与客户端只建立TCP连接,而SSL握手是在Nginx上实现的. 原文:http://www.ruanyifeng.com/blog/2014/09/ssl-lat

网络通信分享(一):数字签名,数字证书

一:数字签名 参考: 图解SSL/TLS协议 http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html SSL延迟有多大? 数字证书原理 http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

MariaDB数据库主从复制、双主复制、半同步复制、基于SSL的安全复制实现及其功能特性介绍

一.复制概述 MariaDB/MySQL内建的复制功能是构建大型,高性能应用程序的基础.将MySQL的数据分布到多个系统上去,这种分布的机制,是通过将MySQL的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位

seconds_behind_master监控复制延迟的不足及pt-heartbeat改进方法

seconds_behind_master含义及不足 seconds_behind_master的值是通过将salve服务器当前的时间戳与二进制日志中的事件的时间戳相比得到的,所以只有执行事件时才会报告延迟. 1.1  如果备库复制线程没有运行,就会报延迟为null. 1.2  一些错误比如网络不稳定可能导致复制中断或停止复制线程,但是seconds_behind_master将显示为0,而不是显示错误 1.3  即使备库线程正在运行,备库有时候可能无法计算延时,如果发生这种情况,备库会报0或者

MySQL复制中slave延迟监控

在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟.这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态: [email protected] [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for maste

基于SSL的mysql(MariaDB)主从复制

一.前言 备份数据库是生产环境中的首要任务,重中之重,有时候不得不通过网络进行数据库的复制,这样就需要保证数据在网络传输过程中的安全性,因此使用基于SSL的复制会大加强数据的安全性 二.准备工作 1.主从服务器时间同步 [[email protected] ~]# crontab -e */30 * * * * /usr/sbin/ntpdate 172.16.0.1 &>/dev/null 2.mysql说明 (1)主服务器 hostname:master    IP:172.16.7.2

如何实现1080P延迟低于500ms的实时超清直播传输技术<转>

转载地址:http://www.yunweipai.com/archives/9037.html 最近由于公司业务关系,需要一个在公网上能实时互动超清视频的架构和技术方案.众所周知,视频直播用 CDN + RTMP 就可以满足绝大部分视频直播业务,我们也接触了和测试了几家 CDN 提供的方案,单人直播没有问题,一旦涉及到多人互动延迟非常大,无法进行正常的互动交谈.对于我们做在线教育的企业来说没有互动的直播是毫无意义的,所以我们决定自己来构建一个超清晰(1080P)实时视频的传输方案. 先来解释下

视频直播技术(二):延迟优化

音视频的直播系统是一个复杂的工程系统,要做到非常低延迟的直播,需要复杂的系统工程优化和对各组件非常熟悉的掌握.下面整理几个简单常用的调优技巧: 编码优化 1. 确保 Codec 开启了最低延迟的设置.Codec 一般都会有低延迟优化的开关,对于 H.264 来说其效果尤其明显.很多人可能不知道 H.264 的解码器正常情况下会在显示之前缓存一定的视频帧,对于 QCIF 分辨率大小的视频(176 × 144)一般会缓存 16 帧,对于 720P 的视频则缓存 5 帧.对于第一帧的读取来说,这是一个

流式传输的两大主流种类及流式传输特点

转自:http://blog.csdn.net/hguisu/article/details/7418087 流式传输定义很广泛,现在主要指通过网络传送媒体(如视频.音频)的技术总称.其特定含义为通过Internet 将影视节目传送到PC机.实现流式传输有两种方法:实时流式传输(Realtime streaming)和顺序流式传输(progressive streaming).(百度百科) 在网络上传输音/视频(英文缩写A/V)等多媒体信息目前主要有下载和流式传输两种方案.A/V文件一般都较大,