1、不安全，302 跳转不仅暴露了用户的访问站点，也很容易被中间者支持。
2、降低访问速度，302 跳转不仅需要一个 RTT，浏览器执行跳转也需要执行时间。
由于 302 跳转事实上是由浏览器触发的，服务器无法完全控制，这个需求导致了 HSTS 的诞生：
HSTS(HTTP )。服务端返回一个 HSTS 的 http ，浏览器获取到 HSTS 头部之后，在一段时间内，不管用户输入还是，都会默认将请求内部跳转成。
, , ie 都支持了 HSTS（#feat=ity）。
2.3
顾名思义就是复用 ，实现简化握手。复用 的好处有两个：
1、减少了 CPU 消耗，因为不需要进行非对称密钥交换的计算。
2、提升访问速度，不需要进行完全握手阶段二，节省了一个 RTT 和计算耗时。
TLS 协议目前提供两种机制实现 ，分别介绍一下。
2.3.1 cache
cache 的原理是使用 hello 中的 id 查询服务端的 cache, 如果服务端有对应的缓存，则直接使用已有的 信息提前完成握手，称为简化握手。
cache 有两个缺点：
1、需要消耗服务端内存来存储 内容。
2、目前的开源软件包括 nginx, 只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于百度或者其他大型互联网公司而言，单机 cache 几乎没有作用。
cache 也有一个非常大的优点：
id 是 TLS 协议的标准字段，市面上的浏览器全部都支持 cache。
百度通过对 TLS 握手协议及服务器端实现的优化，已经支持全局的 cache，能够明显提升用户的访问速度，节省服务器计算资源。
2.3.2
上节提到了 cache 的两个缺点， 能够弥补这些不足。
的原理参考 。简述如下：
将 信息加密成 发送给浏览器，浏览器后续握手请求时会发送 ， 端如果能成功解密和处理 ，就能完成简化握手。
显然， 的优点是不需要服务端消耗大量资源来存储 内容。
的缺点：
1、 只是 TLS 协议的一个扩展特性，目前的支持率不是很广泛，只有 60% 左右。
2、 需要维护一个全局的 key 来加解密，需要考虑 KEY 的安全性和部署效率。
总体来讲，的功能特性明显优于 cache。希望客户端实现优先支持 。
2.4 Ocsp
Ocsp 全称在线证书状态检查协议 ()配置burpsuit谷歌浏览器证书及HSTS问题处理，用来向 CA 站点查询证书状态，比如是否撤销。通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。
这个过程非常消耗时间，因为 CA 站点有可能在国外，网络不稳定，RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢？ocsp 就能实现这个功能。
详细介绍参考 第 8 节。简述原理就是浏览器发起 hello 时会携带一个 的扩展，服务端看到这个扩展后将 OCSP 内容直接返回给浏览器，完成证书状态检查。
由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。
Nginx 目前已经支持这个 ocsp file，只需要配置 ocsp file 的指令就能开启这个功能：
2.5 False start
通常情况下，应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间，那能不能类似 TFO 一样，在完全握手的第二个阶段将应用数据一起发出来呢？ 提出了 false start 来实现这个功能。详细介绍参考。
简单概括 False start 的原理就是在 发出时将应用层数据一起发出来，能够节省一个 RTT。
False start 依赖于 PFS（ 完美前向加密），而 PFS 又依赖于 DHE 密钥交换系列算法（, , , ），所以尽量优先支持 ECDHE 密钥交换算法实现 false start。
2.6 使用 SPDY 或者 HTTP2
SPDY 是 推出的优化 HTTP 传输效率的协议（）配置burpsuit谷歌浏览器证书及HSTS问题处理，它基本上沿用了 HTTP 协议的语义, 但是通过使用帧控制实现了多个特性，显著提升了 HTTP 协议的传输效率。
SPDY 最大的特性就是多路复用，能将多个 HTTP 请求在同一个连接上一起发出去，不像目前的 HTTP 协议一样，只能串行地逐个发送请求。 虽然支持多个请求一起发送，但是接收时依然得按照顺序接收，本质上无法解决并发的问题。
HTTP2 是 IETF 2015 年 2 月份通过的 HTTP 下一代协议，它以 SPDY 为原型，经过两年多的讨论和完善最终确定。
本文就不过多介绍 SPDY 和 HTTP2 的收益，需要说明两点：
评论留言