下载后可任意编辑大型互联网站点 HTTPS 实践(三)：基于协议和配置的优化 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 头部之后，在一段时间内，不管用户输入 www.baidu.com 还是http://www.baidu.com，都会默认将请求内部跳转成 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 只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于百度或者其他大型互联网公司而言，单机 ...
