深入浅出:HTTPS 要比 HTTP 多用多少服务器资源?

标签: Misc | 发表时间:2013-11-06 05:28 | 作者:gouki
出处:http://www.neatstudio.com/

话外页,这是一篇好文章,深入浅出的写出了很多东西,所以,值得一看,有时候,写文章就是这样,你写的越学术,别人越不鸟你,毕竟不是每个人的知识点都象你那么丰富。所以一篇好的文章,能够很直白的表达出来才是最OK的。说起来,当年白居易就是写诗给90岁的老太太听,她能听得懂,这就是好诗(这是老师当年说的,我没有认证过。)

上菜:http://www.zhihu.com/question/21518760

有人提问:

HTTPS 要比 HTTP 多用多少服务器资源?

一些国际网站,比如维基百科,在启用https前先会考虑自己计算能力是否可以承载https。请问,https要比http多用多少服务器资源?
 
有人回答:

知乎用户, 网络设备从业者,对于互联网创新持续关注…

https其实就是建构在 ssl 层之上的 http协议,所以要比较https比http多用多少服务器资源,主要看 ssl 本身消耗多少服务器资源。
http使用TCP 三次握手建立连接,客户端和服务器需要交换3个包,https除了 TCP 的三个包,还要加上 ssl握手需要的9个包,所以一共是12个包。http 建立连接,按照下面链接中针对 Computer Science House的测试,是114毫秒;https建立连接,耗费436毫秒。ssl 部分花费322毫秒,包括网络延时和ssl 本身加解密的开销(服务器根据客户端的信息确定是否需要生成新的主密钥;服务器回复该主密钥,并返回给客户端一个用主密钥认证的信息;服务器向客户端请求数字签名和公开密钥)。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
当SSL 连接建立后,之后的加密方式就变成了3DES等对于 CPU 负荷较轻的对称加密方式。相对前面 SSL 建立连接时的非对称加密方式,对称加密方式对 CPU 的负荷基本可以忽略不记,所以问题就来了,如果频繁的重建 ssl 的session,对于服务器性能的影响将会是致命的,尽管打开https 保活可以缓解单个连接的性能问题,但是对于并发访问用户数极多的大型网站,基于负荷分担的独立的SSL termination proxy就显得必不可少了,Web 服务放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的,譬如F5;也可以是基于软件的,譬如维基百科用到的就是  Nginx,参见下面的链接说明:
SSL termination proxy
那采用 https 后,到底会多用多少服务器资源,2010年1月 Gmail切换到完全使用 https, 前端处理 SSL 机器的CPU 负荷增加不超过1%,每个连接的内存消耗少于20KB,网络流量增加少于2%。由于 Gmail 应该是使用N台服务器分布式处理,所以CPU 负荷的数据并不具有太多的参考意义,每个连接内存消耗和网络流量数据有参考意义。这篇文章中还列出了单核每秒大概处理1500次握手(针对1024-bit 的 RSA),这个数据很有参考意义,具体信息来源的英文网址: ImperialViolet

--------------------------------------------------------------------

可能看了上面的描述,有些概念过于专业,所以想讲一个故事让大家比较好理解:
从前山上有座庙,庙里有个和尚......,别胡闹了,老和尚来了。

小和尚问老和尚:ssl为什么会让http安全?

老和尚答道:譬如你我都有一个同样的密码,我发信给你时用这个密码加密,你收到我发的信,用这个密码解密,就能知道我信的内容,其他的闲杂人等,就算偷偷拿到了信,由于不知道这个密码,也只能望信兴叹,这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密,所以让http安全了,常用的加解密算法主要有3DES和AES等。

小和尚摸摸脑袋问老和尚:师傅,如果我们两人选择“和尚”作为密码,再创造一个和尚算法,我们俩之间的通信不就高枕无忧了?

老和尚当头给了小和尚一戒尺:那我要给山下的小花写情书,还得用“和尚”这个密码不成?想了想又给了小和尚一戒尺:虽然我们是和尚,不是码农,也不能自己造轮子,当初一堆牛人码农造出了Wifi的安全算法WEP,后来发现是一绣花枕头,在安全界传为笑谈;况且小花只知道3DES和AES,哪知道和尚算法?

小和尚问到:那师傅何解?

老和尚:我和小花只要知道每封信的密码,就可以读到对方加密的信件,关键是我们互相之间怎么知道这个对称密码。你说,我要是将密码写封信给她,信被别人偷了,那大家不都知道我们的密码了,也就能够读懂我们情书了。不过还是有解的,这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码,一个叫“公钥”,一个叫“私钥”,公钥发布到了江湖上,好多人都知道,私钥嘛,江湖上只有我一个人知道;这两个密钥有数学相关性,就是说用公钥加密的信件,可以用私钥解开,但是用公钥却解不开。公钥小花是知道的,她每次给我写信,都要我的公钥加密她的对称密码,单独写一张密码纸,然后用她的对称密码加密她的信件,这样我用我的私钥可以解出这个对称密码,再用这个对称密码来解密她的信件。

老和尚顿了顿:可惜她用的对称密码老是“和尚为什么写情书”这一类,所以我每次解开密码纸时总是怅然若失,其实我钟意的对称密码是诸如“风花”“雪月”什么的,最头痛的是,我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书,人世间最痛苦的事莫过于如此。可有一次出意外了,山下的张屠夫给了小花他自己的公钥,谎称的我公钥刚刚更新了,小花后面给我的信的密码都用这个加密,然后张屠夫用他自己的私钥解开小花的对称密码后,不仅看到了小花的信件,还用这个密码给小花发了很多下流的信,同时也用这个密码伪造了一封小花给我的绝交信,直到三个月之后才真相大白。有此教训后,我重新发布到江湖的公钥,上面都有嵩山少林寺的火印,没有火印的公钥,大家不再相信是我的,可是从此之后,我在江湖已经没有名声,也好久没有收到过情书。

小和尚问:那然后呢?

老和尚:过了一年才知道,其实小花还是给我写过信的,当时信确实是用有火印的公钥加密,张屠夫偷到信后,由于不知道我的私钥,解不开小花的密码信,所以一怒之下将信件全部烧毁了。也由于张屠夫无法知道小花的对称密码而无法回信,小花发出几封信后石沉大海,也心生疑惑,到处打听我的近况。这下张屠夫急了,他使用我发布的公钥,仿照小花的语气,给我发来一封信。拿到信时我就觉得奇怪,信纸上怎么有一股猪油的味道,结尾竟然还关切的询问我的私钥。情知有诈,我思量无论如何要找到办法让我知道来的信是否真是小花所写。后来竟然让我想到了办法....

老和尚摸着光头说:这头发可不是白掉的,我托香客给小花带话,我一切安好,希望她也拥有属于自己的一段幸福,不对,是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后,托香客给我送来,这样小花在每次给我写信时,都会在密码纸上贴上一朵小牡丹,牡丹上写上用她自己的私钥加密过的给我的留言,这样我收到自称是小花的信后,我会先抽出密码纸,取下小牡丹,使用小花的公钥解密这段留言,如果解不出来,我会直接将整封信连同密码纸一起扔掉,因为这封信一定不是小花写的,如果能够解出来,这封信才能确信来之于小花,我才仔细的解码阅读。

小和尚:难怪听说张屠夫是被活活气死的。您这情书整的,我头都大了,我长大后,有想法直接扯着嗓子对山下喊,也省的这么些麻烦。不过我倒是明白了楼上的话,ssl 握手阶段,就是要解决什么看火印,读牡丹,解密码纸,确实够麻烦的,所以性能瓶颈在这里,一旦双方都知道了对称密码,之后就是行云流水的解码读信阶段了,相对轻松很多。
 

相关 [https http 服务器] 推荐:

深入浅出:HTTPS 要比 HTTP 多用多少服务器资源?

- - 膘叔
话外页,这是一篇好文章,深入浅出的写出了很多东西,所以,值得一看,有时候,写文章就是这样,你写的越学术,别人越不鸟你,毕竟不是每个人的知识点都象你那么丰富. 所以一篇好的文章,能够很直白的表达出来才是最OK的. 说起来,当年白居易就是写诗给90岁的老太太听,她能听得懂,这就是好诗(这是老师当年说的,我没有认证过.

nginx强制使用https访问的多种方法(http跳转到https)

- - C1G军火库
nginx强制使用https访问的多种方法(http跳转到https). 先说明一下HTTP跳转的状态码. 301 Moved Permanently:该方式将所有的 HTTP 请求重定向到 HTTPS 上,并且该重定向是永久性的. 客户端在收到 301 响应后,会自动将 HTTP 请求转为 GET 请求,同时将请求地址修改为重定向后的地址.

让一个端口同时做两件事:http/https和ssh

- 蓝精灵 - Creke Blog
相信很多人都在YY:能不能让80端口分析连接协议,如果是http协议就让服务器交给http服务程序(如Apache、Nginx等)处理,如果是ssh协议就交给ssh服务程序(如OpenSSH Server)处理呢. 首先,配置http服务程序监听8080端口或者让https服务监听8443端口,配置ssh服务程序监听22端口.

Charles抓取微信小程序数据包(HTTP/HTTPS) - 简书

- -
项目前台为小程序,为快速定位错误,使用Charles进行抓包分析. 硬件环境:MAC + IPhone6P. Charles(MAC)破解版下载. 打开Charles -> Proxy -> Proxy Settings. 设置端口号为:8888,并勾选'Enable transparent Http proxying'项.

如何控制开放HTTPS服务的weblogic服务器

- - WooYun知识库
目前在公开途径还没有看到利用JAVA反序列化漏洞控制开放HTTPS服务的weblogic服务器的方法,已公布的利用工具都只能控制开放HTTP服务的weblogic服务器. 我们来分析一下如何利用JAVA反序列化漏洞控制开放HTTPS服务的weblogic服务器,以及相应的防护方法. 建议先参考 修复weblogic的JAVA反序列化漏洞的多种方法中关于weblogic的JAVA反序列化漏洞的分析.

Chrome浏览器强制http重定向到https的简单方法

- Coolxll - Chrome迷
有的朋友修改host进某些网站,但每次进入都是诸如 http://twitter.com ,大多时候有可能进不去. 前段时间就算修改了,输入http://plus.google.com ,G+也是也进不去的,需要手动修改http为https,方能进入. 今天,在Google+看到一篇介绍Chrome浏览器强制http重定向到https的简单方法,搬到这里来,纯粹的Chrome技巧.

四谈iOS抓包:Mac下好用的HTTP/HTTPS抓包工具Charles

- - 99css
在Mac下做开发,用Fiddler抓包由于离不开Windows比较痛苦,还好有Charles,到官网 http://www.charlesproxy.com/可下载到最新版本(若不支持rMBP可拖到 Retinizer中把文字变清晰). 查看Mac电脑的IP地址,如192.168.1.7. 打开iOS设置,进入当前wifi连接,设置HTTP代理Group,将服务器填为上一步中获得的IP,即192.168.1.7,端口填8888.