HTTPS合理优化小技巧 HTTPS优化
HSTS
在网站全站 HTTPS 后，如果用户手动敲入网站的 HTTP 地址，或者从其它地方点击了网站的 HTTP 链接，依赖于服务端 301/302 跳转才能使用 HTTPS 服务。而第一次的 HTTP 请求就有可能被劫持，导致请求无法到达服务器，从而构成 HTTPS 降级劫持。
这个问题可以通过 HSTS来解决。HSTS 是一个响应头，格式如下：
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
l max-age，单位是秒，用来告诉浏览器在指定时间内，这个网站必须通过 HTTPS 协议来访问。也就是对于这个网站的 HTTP 地址，浏览器需要先在本地替换为 HTTPS 之后再发送请求。
l includeSubDomains，可选参数，如果指定这个参数，表明这个网站所有子域名也必须通过 HTTPS 协议来访问。
l preload，可选参数。
注意事项：HSTS 这个响应头只能用于 HTTPS 响应;网站必须使用默认的 443 端口;必须使用域名，不能是 IP。目前Chrome, firefox, ie 都支持了 HSTS
Session resume
Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存，则直接使用已有的 session 信息提前完成握手，称为简化握手。
Session cache 有两个缺点：
1、需要消耗服务端内存来存储 session 内容。
2、目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于百度或者其他大型互联网公司而言，单机 session cache 几乎没有作用。
Session cache 也有一个非常大的优点：
session id 是 TLS 协议的标准字段，市面上的浏览器全部都支持 session cache。
百度通过对 TLS 握手协议及服务器端实现的优化，已经支持全局的 session cache，能够明显提升用户的访问速度，节省服务器计算资源。
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。
总结：想要理想的实现站点HTTPS加密，并不是将SSL证书部署上去就万事大吉了。合理的优化不仅能加强网站的安全性，更能有效提升用户的浏览体验，是网站建设的必须步骤。