1 前言
上文讲到HTTPS对用户访问速度的影响。 本文就为大家介绍HTTPS在访问速度，计算性能，安全等方面基于协议和配置的优化。 本文最早发表于百度运维部官方博客
2 HTTPS访问速度优化2.1 Tcp fast open
HTTPS和HTTP使用TCP协议进行传输，也就意味着必须通过三次握手建立TCP连接，但一个RTT的时间内只传输一个syn包是不是太浪费？能不能在syn包发出的同时捎上应用层的数据？其实是可以的，这也是tcp fast open的思路，简称TFO。具体原理可以参考rfc7413。 遗憾的是TFO需要高版本内核的支持，linux从3.7以后支持TFO，但是目前的windows系统还不支持TFO，所以只能在公司内部服务器之间发挥作用。
2.2 HSTS
前面提到过将用户HTTP请求302跳转到HTTPS，这会有两个影响： 1. 不安全，302跳转不仅暴露了用户的访问站点，也很容易被中间者支持。 2. 降低访问速度，302跳转不仅需要一个RTT，浏览器执行跳转也需要执行时间。 由于302跳转事实上是由浏览器触发的，服务器无法完全控制，这个需求导致了HSTS的诞生： HSTS(HTTP Strict Transport Security)。服务端返回一个HSTS的http header，浏览器获取到HSTS头部之后，在一段时间内，不管用户输入还是，都会默认将请求内部跳转成https://www.baidu.com。 Chrome, firefox, ie都支持了HSTS（）。
2.3 Session resume
Session resume顾名思义就是复用session，实现简化握手。复用session的好处有两个： 1. 减少了CPU消耗，因为不需要进行非对称密钥交换的计算。 2. 提升访问速度，不需要进行完全握手阶段二，节省了一个RTT和计算耗时。
TLS协议目前提供两种机制实现session resume，分别介绍一下。
2.3.1 Session cache
Session cache的原理是使用client hello中的session id查询服务端的session cache,如果服务端有对应的缓存，则直接使用已有的session信息提前完成握手，称为简化握手。 Session cache有两个缺点： 1. 需要消耗服务端内存来存储session内容。 2. 目前的开源软件包括nginx,apache只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于百度或者其他大型互联网公司而言，单机session cache几乎没有作用。
Session cache也有一个非常大的优点： 1. session id是TLS协议的标准字段，市面上的浏览器全部都支持session cache。
百度通过对TLS握手协议及服务器端实现的优化，已经支持全局的session cache，能够明显提升用户的访问速度，节省服务器计算资源。
2.3.2 Session ticket
上节提到了session cache的两个缺点，，session ticket能够弥补这些不足。 Session ticket的原理参考RFC4507。简述如下： server将session信息加密成ticket发送给浏览器，浏览器后续握手请求时会发送ticket，server端如果能成功解密和处理ticket，就能完成简化握手。 显然，session ticket的优点是不需要服务端消耗大量资源来存储session内容。 Session ticket的缺点： 1. session ticket只是TLS协议的一个扩展特性，目前的支持率不是很广泛，只有60%左右。 2. session ticket需要维护一个全局的key来加解密，需要考虑KEY的安全性和部署效率。
总体来讲，session ticket的功能特性明显优于session cache。希望客户端实现优先支持session ticket。
2.4 Ocsp stapling
Ocsp全称在线证书状态检查协议(rfc6960)，用来向CA站点查询证书状态，比如是否撤销。通常情况下，浏览器使用OCSP协议发起查询请求，CA返回证书状态内容，然后浏览器接受证书是否可信的状态。 这个过程非常消耗时间，因为CA站点有可能在国外，网络不稳定，RTT也比较大。那有没有办法不直接向CA站点请求OCSP内容呢？ocsp stapling就能实现这个功能。 详细介绍参考RFC6066第8节。简述原理就是浏览器发起client hello时会携带一个certificate status request的扩展，服务端看到这个扩展后将OCSP内容直接返回给浏览器，完成证书状态检查。 由于浏览器不需要直接向CA站点查询证书状态，这个功能对访问速度的提升非常明显。 Nginx目前已经支持这个ocsp stapling file，只需要配置ocsp stapling file的指令就能开启这个功能：
ssl_stapling on; ssl_stapling_file ocsp.staple;2.5 False start
通常情况下，应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间，那能不能类似TFO一样，在完全握手的第二个阶段将应用数据一起发出来呢？google提出了false start来实现这个功能。详细介绍参考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。 简单概括False start的原理就是在client_key_exchange发出时将应用层数据一起发出来，能够节省一个RTT。 False start依赖于PFS（perfect forward secrecy完美前向加密），而PFS又依赖于DHE密钥交换系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以尽量优先支持ECDHE密钥交换算法实现false start。
2.6 使用SPDY或者HTTP2
SPDY是google推出的优化HTTP传输效率的协议（https://www.chromium.org/spdy），它基本上沿用了HTTP协议的语义,但是通过使用帧控制实现了多个特性，显著提升了HTTP协议的传输效率。 SPDY最大的特性就是多路复用，能将多个HTTP请求在同一个连接上一起发出去，不像目前的HTTP协议一样，只能串行地逐个发送请求。Pipeline虽然支持多个请求一起发送，但是接收时依然得按照顺序接收，本质上无法解决并发的问题。 HTTP2是IETF 2015年2月份通过的HTTP下一代协议，它以SPDY为原型，经过两年多的讨论和完善最终确定。 本文就不过多介绍SPDY和HTTP2的收益，需要说明两点： 1. SPDY和HTTP2目前的实现默认使用HTTPS协议。 2. SPDY和HTTP2都支持现有的HTTP语义和API，对WEB应用几乎是透明的。 Google宣布chrome浏览器2016年将放弃SPDY协议，全面支持HTTP2，但是目前国内部分浏览器厂商进度非常慢，不仅不支持HTTP2，连SPDY都没有支持过。 百度服务端和百度手机浏览器现在都已经支持SPDY3.1协议。
3 HTTPS计算性能优化3.1 优先使用ECC
ECC椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是NIST推荐的密钥长度对照表。
对于RSA算法来讲，目前至少使用2048位以上的密钥长度才能保证安全性。ECC只需要使用224位长度的密钥就能实现RSA2048位长度的安全强度。在进行相同的模指数运算时速度显然要快很多。
3.2 使用最新版的openssl穿过紫堇，穿过木棉，穿过时影时现的悲喜和无常。
