SSL和TLS都是用于保障端到端之间连接的安全性。SSL最初是由Netscape开发的，后来为了使得该安全协议更加开放和*，更名为TLS，并被标准化到RFC中，现在主流的是TLS 1.2版本。
从上图，可以看出SSL/TLS是介于应用层和传输层之间，并且分为握手层（Handshake Layer）和记录层（Record Layer）。
- 握手层：端与端之间协商密码套件、连接状态。
- 记录层：对数据的封装，数据交给传输层之前，会经过分片-压缩-认证-加密。
TLS中可被配置的算法分类：
- 数字签名：RSA、DSA
- 流加密：RC4
- 分组加密：DES、AES
- 认证加密：GCM
- 公钥加密：RSA
- 消息认证码：SHA
- 密钥交换：Diffie–Hellman
密码套件决定了会使用到的算法，例如执行“openssl ciphers -v 'ALL' | grep ECDHE-RSA-AES128-GCM-SHA256”：
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
表明该算法是在TLS 1.2中支持的，密钥交换采用ECDH（EC是指采用椭圆曲线的DH）,数字签名采用RSA，加密采用128位密钥长度的AESGCM，消息认证码采用AEAD（AEAD是一种新的加密形式，把加密和消息认证码结合到一起，而不是某个算法，例如使用AES并采用GCM模式加密，就能够为数据提供保密性、完整性的保障）。
如何理解完整性？
A 将明文M加密后为MC，发给B，B解密，得到明文。 如果此时有中间人C，将MC替换为CMC（虽然C不知道A怎么加密的，但这没关系），B将CMC解密，得到明文（那么B拿到的其实是错误的明文）。 所以需要引入消息认证码，B才能够判断收到的密文是否被篡改过。 这里你可能会问：那如果C同时伪造消息认证码呢？ 这个就得看MAC和加密是如何配合的了，详情可以查看认证加密中的Approaches to Authenticated Encryption章节。
在TLS握手和数据传输的不同阶段会采用相应的算法：
- 服务端身份验证：数字签名（RSA、ECDSA）
- 密钥交换：RSA/密钥交换算法（ECDH）
- 加密/解密：流加密（RC4）和分组加密（3DES/AES/AESGCM）
- 生成消息认证码：SHA/AEAD
不知是否有人发现并没有提到压缩算法，如果google下TLS压缩优化相关的内容，会发现没有，因为目前在TLS 1.2 RFC中，关于压缩方法的结构定义为enum { null(0), (255) } CompressionMethod;，即只有null方法（不进行压缩）。目前存在对TLS压缩的攻击，可能是基于此原因，TLS压缩目前只是个概念性的东西，没有被真正应用起来。
如何选择算法——安全性通常加密算法的安全性依赖于密钥的长度，且不同加密算法，即使密钥长度相同，但提供的安全性也可能是不同的，相关资料：key size。所以并没有一个标准的归一化方法去衡量所有的加密算法，但是有来自世界上各个组织/机构对不同类型算法安全性的评估，可以看下这个网站：https://www.keylength.com/。
执行“openssl ciphers -v 'ALL' | wc -l”会发现有100+个密码套件（不同openssl版本提供的密码套件有点差异），然而，实际只会使用到其中一部分，因为openssl提供的不少算法是不安全的，需要排除掉。
执行“openssl ciphers -v 'HIGH MEDIUM !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !CAMELLIA !IDEA !SEED !RC4' | wc -l”，发现只剩下50+个密码套件。
筛选后剩下的密码套件还是挺多的，一个个做性能测试的话，会GG的= =。其实可以根据需要支持的客户端，再筛选出主流的密码套件。网址：https://www.ssllabs.com/ssltest/clients.html，提供了绝大部分客户端对TLS的支持情况，点击相应的User agent可以查看到其支持的密码套件，并且各套件的安全性也被标注出来了。
网址：https://www.ssllabs.com/ssltest/，可以用于测试服务器的SSL配置情况，并会给出得分，如下图google的得分为A：
以下性能测试都是选取主流的算法进行。
数字签名：ECDSA vs RSA
需要先分别生成采用ECDSA和RSA的签名证书。
生成ECDSA自签名的证书：
openssl ecparam -name prime256v1 -genkey -out ec_key.pem openssl req -new -x509 -key ec_key.pem -out cert.pem -days 365
-param_enc参数使用默认的named_curve就可以了，如果使用explicit，会发现生成的证书nginx能配置成功，但客户端连接时会出现handshake error。
生成RSA签名的证书：
openssl req -newkey rsa:2048 -nodes -keyout rsa_key.pem -x509 -days 365 -out cert.pem
执行openssl speed rsa2048 ecdsap256测试下：
sign verify sign/s verify/s rsa 2048 bits 0.000834s 0.000024s 1198.9 41031.9 sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0000s 0.0001s 21302.5 9728.5
可以看到签名性能ECDSA > RSA，而验证性能RSA > ECDSA。
测试环境：
- 服务端：1台虚拟机CentOS 4核 openresty 2个worker
- 客户端：4台虚拟机CentOS 4/2/2/2核（手头只有这些虚拟机= =）， 用shell脚本模拟并发的ab -c 800 -n 800（并发的ab实例数=2*CPU_NUM），使用time命令获取消耗的时间
- 测试页面562字节，目标是测试数字签名的性能，所以页面小点，避免加密/解密、数据传输占用太多时间
多台客户端如何同时启动？ctrl+tab，命令+回车……
为什么不用jmeter？我用了1Master3Slave的jmeter分布式压测发现，jmeter对于在该场景（CPU bound）下的性能测试不行，服务端压力上不去。
在相同的请求量下，RSA签名会使服务端CPU占用更高，所以这次测试需要在两种签名的压测下，服务端CPU都保持在90%以上（不然的话，对ECDSA就不公平了）。
为何openresty是2个worker？因为开4个的话，ECDSA的压测没法使openresty4个worker的CPU消耗达到90%。
ECDHE-ECDSA-AES128-GCM-SHA256，服务端CPU占比90%，结果：
| 客户端（CPU核数标识） | 4 | 2 | 2 | 2 |
| 第一次 | 11.988 | 17.334 | 9.161 | 7.748 |
| 第二次 | 12.524 | 13.750 | 12.129 | 7.582 |
| 第三次 | 11.836 | 17.991 | 9.195 | 10.023 |
| 第四次 | 11.617 | 7.081 | 9.168 | 8.919 |
ECDHE-RSA-AES128-GCM-SHA256，服务端CPU占比100%，结果：
| 客户端（CPU核数标识） | 4 | 2 | 2 | 2 |
| 第一次 | 12.704 | 21.088 | 18.232 | 6.134 |
| 第二次 | 13.355 | 21.071 | 26.990 | 6.102 |
| 第三次 | 14.638 | 16.009 | 11.669 | 6.071 |
| 第四次 | 13.913 | 21.061 | 21.271 | 5.108 |
从表格中的数据可以看出ECDSA的性能要比RSA好点，这里ECDSA的测试尚未压榨完服务端呢。从openssl speed的结果也可以看出ECDSA的签名性能是要远超过RSA的，而且签名是在服务端做的，所以面对海量的客户端，服务端应该选择使用ECDSA。
密钥交换：RSA vs ECDHE
测试环境同上，但只使用了4/2核两台客户端机器发请求。证书使用的是生成的RSA证书，ECDSA证书能用到的密钥交换算法只能是ECDHE。
AES256-GCM-SHA384，服务端CPU占比100%，结果：
| 客户端（CPU核数标识） | 4 | 2 |
| 第一次 | 12.144 | 15.737 |
| 第二次 | 12.133 | 15.452 |
| 第三次 | 11.902 | 16.145 |
| 第四次 | 11.614 | 16.133 |
ECDHE-RSA-AES256-GCM-SHA384，服务端CPU占比100%，结果：
| 客户端（CPU核数标识） | 4 | 2 |
| 第一次 | 11.950 | 16.213 |
| 第二次 | 12.488 | 16.666 |
| 第三次 | 12.167 | 16.378 |
| 第四次 | 13.784 | 16.484 |
从表格中的数据可以看出ECDHE与RSA的性能差不多。ECDHE比RSA要多了一次端到端的传输，还会用到RSA对DH参数进行签名和验证；而RSA密钥交换则会使用到RSA的加密/解密，具体可看如下CloudFlare的两张图，图片来自Keyless SSL: The Nitty Gritty Technical Details：
ECDHE支持前向保密（Forward Secrecy），简单理解：中间人可以保存下来客户端和服务端之间的所有通信数据，如果使用RSA握手，那么未来某一天，中间人如果获取到了服务端的私钥，就可以解密所有之前采集的通信数据了；如果采用ECDHE握手的话，就可以避免这个问题。而且使用ECDHE握手的话，还有可能开启TLS false start的特性（下文中会提到）。
RSA握手：
ECDHE握手：
所以密钥交换算法ECDHE会更好些。
对称加密：AES256-GCM vs AES256 vs AES128-GCM vs 3DES
测试环境同上，但只使用了4核一台客户端机器发请求，ab参数为 ab -n 2000 -c 10 ，ab实例4个，测试页面153K。因为是要压测对应用层数据的加密解密性能，所以连接数少，但每个连接的请求数多。
ECDHE-RSA-AES256-GCM-SHA384，服务端CPU占比94%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 17.972 |
| 第二次 | 18.863 |
| 第三次 | 18.761 |
| 第四次 | 19.345 |
ECDHE-RSA-AES256-SHA384，服务端CPU占比98%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 20.490 |
| 第二次 | 19.575 |
| 第三次 | 19.725 |
| 第四次 | 20.262 |
ECDHE-RSA-AES128-GCM-SHA256，服务端CPU占比92%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 17.886 |
| 第二次 | 18.449 |
| 第三次 | 17.897 |
| 第四次 | 18.371 |
DES-CBC3-SHA，服务端CPU占比100%，结果（太慢了，就测了两个=。=）：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 52.262 |
| 第二次 | 51.476 |
从表格中的数据可以看出AES128GCM > AES256GCM > AES256 > 3DES。
消息认证码：SHA256 vs SHA1 vs AEAD
测试环境同上。
AES256-SHA256，服务端CPU占比100%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 18.544 |
| 第二次 | 18.309 |
| 第三次 | 18.594 |
| 第四次 | 18.670 |
AES256-SHA，服务端CPU占比98%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 15.418 |
| 第二次 | 15.071 |
| 第三次 | 16.614 |
| 第四次 | 16.146 |
AES256-GCM-SHA384，服务端CPU占比95%，结果：
| 客户端（CPU核数标识） | 4 |
| 第一次 | 14.443 |
| 第二次 | 15.669 |
| 第三次 | 15.880 |
| 第四次 | 15.960 |
从结果中可以看出AES256-GCM-SHA384 > AES256-SHA > AES256-SHA256。
会话恢复Session Cache
客户端希望恢复先前的session，或者复制一个存在的session，可以在ClientHello中带上Session ID，如果服务端能够在它的Session Cache中找到相应的Session ID的session-state（存储协商好的密码套件等信息），并且愿意使用该Session ID重建连接，那么服务端会发送一个带有相同Session ID的ServerHello。
目前Nginx 只支持单机Session Cache，Openresty 支持分布式Session Cache，但处于实验阶段。
Session Ticket
Session Cache需要服务端缓存Session相关的信息，对服务端存在存取压力，而且还有分布式Session Cache问题。 对于支持Session Ticket的客户端，服务端可以通过某种机制将session-state加密后作为ticket发给客户端。客户端凭借该ticket就可以恢复先前的会话了。
类似于HTTP中用Json Web TOken作为cookie-session的另一种选择。
当客户端在握手环节接受到服务端的证书时，除了对证书进行签名验证，还需要知道证书是否被吊销了，那么需要向证书中指定的OCSP url发送OCSP查询请求。
对于同一份服务端证书，如果每个客户端都自己去查询一次证书状态就浪费了。所以，OCSP stapling就是为了解决这一问题，由服务端查询到证书状态（通常会缓存一段时间），并返回给客户端（客户端会在本地校验这个证书状态是否真实）。
在nginx的配置中，可以选择性的配置是否对OCSP response做校验，防止将非法的证书状态发送给客户端。如果设置了校验，ssl_trusted_certificate参数需要为包含所有中间证书+根证书的文件。
如下图是对nginx请求OCSP Server的抓包，可以看到发了个http的ocsp请求：
下图是对nginx在发送证书给客户端时，带上的证书状态的抓包：
nginx默认的ssl_buffer_size是16K（TLS Record Layer最大的分片），即一个TLS Record的大小，如果HTTP的数据是160K，那么就会被拆分为10个TLS Record（每个TLS Record会被TCP层拆分为多个TCP包传输）发送给客户端。
如果TLS Record Size过大的话，拆分的TCP包也会较多，传输时，如果出现TCP丢包，整个TLS Record到达客户端的时间就会加长，客户端必须等待完整的TLS Record收到才能进行解密。
如果TLS Record Size小一些的话，TCP丢包影响的TLS Record占比就会小很多，到达客户端的TLS Record就会多些，客户端干等着的时间就相对少了。但是，TLS Record Head的负载就增加了，可能还会降低连接的吞吐量。
假设ssl_buffer_size设置为1460byte：
通常，在TCP慢启动的过程中，TLS Record Size小点好，因为这个时候TCP连接的拥塞窗口cwnd较小，TCP连接吞吐量也小。而在TCP连接结束慢启动之后，TLS Record Size就可以增大一些了，因为这个时候吞吐量上来了。所以更希望能够动态的调整nginx中ssl_buffer_size的大小，目前官方nginx还不支持，不过cloudflare为nginx打了个patch，以支持动态的调整TLS Record Size：Optimizing TLS over TCP to reduce latency。
TLS False Start某一端在发送 Change Cipher Spec、Finished 之后，可以立即发送应用数据，无需等待另一端的 Change Cipher Spec、Finished 。这样，应用数据的发送实际上并未等到握手全部完成，从而节省出一个RTT时间。
完整握手时，Client Side False Start：
简短握手时，Server Side False Start：
Client Side False Start需要的条件：
- 客户端和服务端都需要支持NPN/ALPN（浏览器要求）
- 需要采用支持前向保密的密码套件，即使用ECDHE进行密钥交换（RFC7918中有规定）
- TCP优化，毕竟SSL数据也是基于TCP进行传输的
- 证书优化，采用ECDSA证书、服务器发送给客户端的证书链包含所有中间证书
- 硬件配置优化，例如使用SSL加速器
本文是个人近段时间学习到的关于HTTPS性能优化的总结，推荐阅读HTTPS权威指南和High Performance Browser Networking以了解更多内容。
推荐的密码套件列表：
openssl ciphers -v 'ECDHE+ECDSA ECDHE AESGCM AES HIGH MEDIUM !kDH !kECDH !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !CAMELLIA !IDEA !SEED !RC4 !3DES'
其他额外的密码套件，比如需要支持IE6，可以放在密码套件列表末尾。
自己写了个go程序用于检测密码套件列表支持/不支持的客户端：sslciphersuitescheck
本文地址：http://www.linuxprobe.com/https-performance-optimization.html