电商网站HTTPS实践之路（三）——性能优化篇

通过分析TLS握手过程的细节我们会发现HTTPS比HTTP会增加多个RTT网络传输时间，既增加了服务端开销，又拖慢了客户端响应时间。因此，性能优化是必不可少的工作。很多文章都集中在服务端的性能优化上，但对于电商行业而言，大部分的用户流量源于App，因此客户端的性能优化配合服务端才能使收益最大化。

1. HTTPS带来的负担

凡事都有两面性。

1.1 增加的传输延时

使用HTTPS传输增加的开销不仅仅是两次TLS握手的过程。优化性能首先要知己知彼。了解性能损耗在哪里，才能有针对性的进行部署。
对于用户来说，使用HTTP请求，首次请求时只要和服务端TCP三次握手建立连接，便可以开始应用数据传输了。

而对于HTTPS而言，事情就不那么简单了。

1. 用户习惯于使用HTTP请求你的网站。要保护用户的安全，首先要让用户强制302/301到HTTPS。这次跳转至少增加1个RTT的延时；
2. 302跳转后要再次TCP建连，增加1个RTT的延时；
3. 开始两阶段TLS握手，细节如下图所示，增加至少两个RTT的延时。

- Client Hello: 客户端开始新的握手，并将自身支持的功能提供给服务端；
- Server Hello:服务端选择连接参数；
- Certificate*:服务端发送证书链；
- ServerKeyExchange*:服务端发送公钥（public key）等生成主密钥（premaster secrect）的额外信息给客户端；
- ServerHelloDone:服务端通知完成协商过程；
- ClientKeyExchange:客户端发送加密后的主密钥给服务端
- [ChangeChiperSpec]:客户端如果要切换加密方式通知服务端
- Finished:客户端完成
- [ChangeChiperSpec]:服务端如果要切换加密方式通知客户端
- Finished:服务端完成
4. 另外客户端如果第一次获取服务端的证书链信息，还需要通过Oscp来验证证书的吊销状态，又需要至少1个RTT延时。
5. 最终，开始应用层数据的传输。

1.2 服务端额外开销

TLS握手过程中密钥交换和加密对CPU都会产生额外的计算开销。选择不同的算法（身份验证算法、密钥交换算法、加密算法）开销不同。比如，2048位RSA作为密钥交换算法对CPU压力就会很大，而ECDHE_RSA（椭圆曲线密钥交换）开销就小的多，RSA可以仍保留用于身份验证。
当然，不管选用多优化的算法，开销是避免不了的，如下图所示。

2. 服务端性能优化

服务端性能优化，主要体现在Web服务器配置的优化，我们以Ngnix 1.11.0版本为例。当然你也可以选择Apache、H2O等。

2.1 HSTS的合理使用

HSTS（HTTP Strict Transport Security, HTTP严格传输安全协议）表明网站已经实现了TLS，要求浏览器对用户明文访问的Url重写成HTTPS，避免了始终强制302重定向的延时开销。
HSTS的实现原理是：当浏览器第一次HTTP请求服务器时，返回的响应头中增加Strict-Transport-Security，告诉浏览器在指定的时间内，这个网站必须通过HTTPS协议来访问。也就是对于这个网站的HTTP地址，浏览器需要现在本地替换为HTTPS之后再发送请求。
其配置如下所示。max-age表明HSTS在浏览器中的缓存时间，includeSubdomainscam参数指定应该在所有子域上启用HSTS，preload参数表示预加载，稍后会具体解释。

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

在CanIUse上我们可以查询HSTS协议的浏览器支持度：

在使用HSTS的过程中仍有一些值得注意的问题：
1. HSTS将全部的证书错误视为致命的。因此，一旦主域使用HSTS，浏览器将放弃对域名所有无效证书站点的连接。
2. 首次访问仍然使用HTTP，然后才能激活HSTS。无法保障首次访问的安全性如何解决？可以通过preloading预加载的方式，与浏览器厂商约定好一份支持HSTS的网站清单来缓解。目前Google已经提供了在线注册服务https://hstspreload.appspot.com/
3. 如何撤销HSTS？通过Strict-Transport-Security: max-age=0将缓存设置为0可以撤销HSTS。但是只有当浏览器再次访问网站并且得到响应更新配置时才能生效。

2.2 会话恢