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

    https其实就是建构在SSL/TLS之上的 http协议，所以要比较https比http多用多少服务器资源，主要看SSL/TLS本身消耗多少服务器资源。

    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。

    那采用 https 后，到底会多用多少服务器资源，2010年1月 Gmail切换到完全使用 https， 前端处理 SSL 机器的CPU 负荷增加不超过1%，每个连接的内存消耗少于20KB，网络流量增加少于2%。由于 Gmail 应该是使用N台服务器分布式处理，所以CPU 负荷的数据并不具有太多的参考意义，每个连接内存消耗和网络流量数据有参考意义。这篇文章中还列出了单核每秒大概处理1500次握手（针对1024-bit 的 RSA），这个数据很有参考意义，具体信息来源的英文网址：ImperialViolet。

    Heartbleed这个被称作史上最大的网络安全漏洞，想必很多人都有所耳闻，Heartbleed之所以能够出现，其实和我们这个问题关系还不小，前面我们谈到了频繁重建 SSL/TLS的session对于服务器影响是致命的，所以聪明的RFC 在2012年提出了 RFC6520 TLS 的心跳扩展。这个协议本身是简单和完美的，通过在客户端和服务器之间来回发送心跳的请求和应答，保活 TLS session，减少重建 TLS的session的性能开销。令人遗憾的是，openssl 在实现这个心跳扩展时，犯了一个低级的错误，没有对收到的心跳请求进行长度检查，直接根据心跳请求长度拷贝数据区，导致简单的心跳应答中可能包含了服务器端的核心数据区内容，用户名，密码，信用卡信息，甚至服务器的私有密钥都有可能泄露。心因为心跳保活的这个 BUG 在滴血，这个名字起的极度形象。

开启 SSL 会增加内存、CPU、网络带宽的开销，后二者跟你使用的 cipher suite 密切相关，其中参数很多，很难一概而论。开启 SSL 的前提是你的 cert 和 key 必须放在 TCP endpoint，你是否信得过那台设备？

SSL 开销来自于两部分，handshake 和 bulk encryption。对于性能，前者我们关注 handshakes/s，后者关注 MiB/s。

先说比较简单的 bulk encryption，首先由于 padding 和 MAC，消息会变长，增加一些网络带宽。其次，bulk encryption 和 MAC 会增加 CPU 使用，具体跟所使用的加密算法和 MAC 算法有关，如果用 AES，也跟 CPU 是否支持 AESNI 指令有关。如果用常见的 AES-256-CBC + SHA1 组合，单个 CPU core 就能轻松打满千兆网带宽。（AES128 vs. AES256 和 SHA1 vs. SHA256 还有细微差别，但透过千兆网就不一定能看出来了，不过 3DES 要慢得多。）另外，如果用 GCM 代替 CBC，会节约一些带宽（省了 MAC），但会增加 CPU 开销。测试 bulk encryption 的性能是比较容易的。

再说 handshake，这里边水比较深。开销主要取决于 key exchange 算法。这里暂且只考虑流行的 2048 bit RSA key，不考虑新潮的 ECDSA。
首先，你要决定是否采用  forward secrecy，即如果有人录下你今天的 traffic，将来再搞到了你的 private key，他是否能追溯解密以往的消息。这决定了是 RSA key exchange 还是 ECDHE RSA key exchange。（这里就不考虑慢得多的 DHE key exchange 了。）

单从性能方面考虑，RSA key exchange 比 ECDHE RSA key exchange 快。大体上一秒钟能做几百上千次 handshake，比 TCP 三路握手慢很多。如果你用 ECDHE，注意选 secp256r1/secp224r1 等曲线，而不是更慢的 secp521r1。还有，对于 ECDHE，“每次 handshake 用新的 key （SSL_OP_SINGLE_ECDH_USE）”与“进程启动时产生一个 key 反复使用”也会有细微的性能差别。如果你要贴 benchmark 的对比结果，一定要把各个参数细节指明，否则没有参考意义。

ECDHE RSA key exchange 比 RSA key exchange 的总运算量大，但分配在服务端和客户端的比例不及后者悬殊。RSA key exchange 中，抛开 cert 验证，客户端耗CPU的操作是 RSA public key encrypt，而服务端需要做 RSA private key decrypt，后者要慢几倍。ECDHE RSA key exchange 中，客户端和服务端都要做 EC key generation 和 scalar multiplication，运算量相当，区别在于服务端还要做 RSA sign with private key，客户端只要 RSA verify with public key，总体来看，服务端的运算量略大。也就是说两种 key exchange 策略 handshake 产生的 CPU 负载在服务端和客户端的分配比例差别较大。

从前山上有座庙，庙里有个和尚......，别胡闹了，老和尚来了。

小和尚问老和尚：ssl为什么会让http安全？

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

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

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

小和尚问到：那师傅何解？

老和尚：我和小花只要知道每封信的密码，就可以读到对方加密的信件，关键是我们互相之间怎么知道这个对称密码。你说，我要是将密码写封信给她，信被别人偷了，那大家不都知道我们的密码了，也就能够读懂我们情书了。不过还是有解的，这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码，一个叫“公钥”，一个叫“私钥”，公钥发布到了江湖上，好多人都知道，私钥嘛，江湖上只有我一个人知道；这两个密钥有数学相关性，就是说用公钥加密的信件，可以用私钥解开，但是用公钥却解不开。公钥小花是知道的，她每次给我写信，都要我的公钥加密她的对称密码，单独写一张密码纸，然后用她的对称密码加密她的信件，这样我用我的私钥可以解出这个对称密码，再用这个对称密码来解密她的信件。老和尚顿了顿：可惜她用的对称密码老是“和尚为什么写情书”这一类，所以我每次解开密码纸时总是怅然若失，其实我钟意的对称密码是诸如“风花”“雪月”什么的，最头痛的是，我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书，人世间最痛苦的事莫过于如此。可我哪里知道，其实有人比我更痛苦。山下的张屠夫，暗恋小花很多年，看着我们鸿雁传书，心中很不是滋味，主动毛遂自荐代替香客给我们送信。在他第一次给小花送信时，就给了小花他自己的公钥，谎称是我公钥刚刚更新了，小花信以为真，之后的信件对称密码都用张屠夫的这个公钥加密了，张屠夫拿到回信后，用他自己的私钥解开了小花的对称密码，然后用这个对称密码，不仅能够看到了小花信件的所有内容，还能使用这个密码伪造小花给我写信，同时还能用他的私钥加密给小花的信件。渐渐我发现信件变味了，尽管心生疑惑，但是没有确切的证据，一次我写信问小花第一次使用的对称密码，回信中“和尚为什么写情书”赫然在列，于是我的疑惑稍稍减轻。直到有一次去拜会嵩山少林寺老方丈才顿悟，原来由于我的公钥没有火印，任何人都可以伪造一份公钥宣称是我的，这样这个人即能读到别人写给我的信，也能伪造别人给我写信，同样也能读到我的回信，也能伪造我给别人的回信，这种邪门武功江湖上称之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印，这个火印可有讲究了，需要将我的公钥及个人在江湖地位提交给18罗汉委员会，他们会根据我的这些信息使用委员会私钥进行数字签名，签名的信息凸现在火印上，有火印的公钥真实性在江湖上无人质疑，要知道18罗汉可是无人敢得罪的。

小和尚问：那然后呢？

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

老和尚摸着光头说：这头发可不是白掉的，我托香客给小花带话，我一切安好，希望她也拥有属于自己的一段幸福，不对，是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后，托香客给我送来，这样小花在每次给我写信时，都会在密码纸上贴上一朵小牡丹，牡丹上写上用她自己的私钥加密过的给我的留言，这样我收到自称是小花的信后，我会先抽出密码纸，取下小牡丹，使用小花的公钥解密这段留言，如果解不出来，我会直接将整封信连同密码纸一起扔掉，因为这封信一定不是小花写的，如果能够解出来，这封信才能确信来之于小花，我才仔细的解码阅读。小和尚：难怪听说张屠夫是被活活气死的。您这情书整的，我头都大了，我长大后，有想法直接扯着嗓子对山下喊，也省的这么些麻烦。不过我倒是明白了楼上的话，ssl 握手阶段，就是要解决什么看火印，读牡丹，解密码纸，确实够麻烦的，所以性能瓶颈在这里，一旦双方都知道了对称密码，之后就是行云流水的解码读信阶段了，相对轻松很多。