序•魔戒再现
几天前，OpenSSL 官方宣布即将发布的新版本 （OpenSSL 1.1.1） 将会提供 TLS 1.3 的支持，并且还会和以前的 1.1.0 版本彻底兼容，这固然是个好消息。若是说 HTTP/2 是当前互联网 Web 发展的讨论热点之一，那么下一个热点应该就是 TLS 1.3 了。
谈到 TLS 那么就不得不说回 HTTPS，2016 年应该算是国内站点使用 HTTPS 激增的一年，从 Google Trend 上也能够看出该关键词的搜索热度从 2016 年开始飙升。不光如此，全部从事互联网 Web 技术相关的开发人员，也应该可以明显感觉到，身边使用 HTTPS 的网站愈来愈多了。
为何近两年来 HTTPS 被你们更普遍的应用？
一方面得益于「中国特点」的网络安全环境，运营商层出不穷的各类劫持给全部的用户和开发者都上了生动的一课。
用户天天被来自各类广告联盟漫天的牛皮癣广告和运营商话费余额查询所包围。不只如此，随着公司流量不断的被劫持导流到其余地方。搞得不少公司连苦心经营的市场蛋糕都没办法安心的吃，终于大部分公司坐不住了。固然声讨和口诛笔伐是没有用的，因此拥有业务上拥有 HTTPS 和 HTTP DNS 解决方案，也就瓜熟蒂落的成了技术公司在伟大防火墙内生存的必备技能之一。
另外一方面，从安全角度讲，互联网上经过明文传输数据自己就是一件高风险的事情，什么数据泄露、中间人攻击、用户被盗号、被竞争对手背后捅刀子 App 下载被劫持.....也是家常便饭。
那么说回主题，既然 HTTPS 能够一劳永逸的解决上述问题，而为何你们以前不尽快的用起来？
问题在于：考虑到 HTTPS 要比 HTTP 更加消耗服务器资源，并且相比于 HTTP 创建链接握手时须要消耗的大量时间影响用户端的体验，使得不少人望而却步，尤为是在移动网络下。
固然，还有 SSL 证书的成本也要算进去。
王者归来
在 Web 领域，传输延迟（Transmission Latency）是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 连接的创建大概须要如下四步：
第一步：DNS 查询
浏览器在创建连接以前，须要将域名转换为互联网 IP 地址。通常默认是由你的 ISP DNS提供解析。ISP 一般都会有缓存的，通常来讲花费在这部分的时间不多。
第二步：TCP 握手（ 1 RTT）
和服务器创建 TCP 链接，客户端向服务器发送 SYN 包，服务端返回确认的 ACK 包，这会花费一个往返（1 RTT）。
第三步：TLS 握手 （2 RTT）
该部分客户端会和服务器交换密钥，同时设置加密连接，对于 TLS 1.2 或者更早的版本，这步须要 2 个 RTT。
第四步：创建 HTTP 链接（1 RTT）
一旦 TLS 链接创建，浏览器就会经过该链接发送加密过的 HTTP 请求。
咱们假设 DNS 的查询时间忽略不计，那么从开始到创建一个完整的 HTTPS 链接大概一共须要 4 个 RTT，若是是浏览刚刚已经访问过的站点的话，经过 TLS 的会话恢复机制，第三步 TLS 握手可以从 2 RTT 变为 1 RTT。
总结：
创建新链接 ：
4 RTT + DNS 查询时间
访问刚浏览过的链接：
3 RTT + DNS 查询时间
那么 TLS 1.3 以及 0-RTT 是如何减小延迟的?
在此以前咱们须要简单回顾一下 TLS 1.2 是如何工做的
TLS 1.2 创建新链接
- 在一次新的握手流程中，Client Hello 老是客户端发送的第一条消息，该消息包含客户端的功能和首选项，与此同时客户端也会将自己支持的全部密码套件（Cipher Suite）列表发送过去
- Server Hello 将服务器选择的链接参数传送回客户端，同时将证书链发送过去，进行服务器的密钥交换
- 进行客户端部分的密钥交换，此时握手已经完成，加密链接已经可使用
TLS 1.2 会话恢复
会话恢复：
在一次完整协商的链接断开时，客户端和服务器都会将会话的安全参数保留一段时间。但愿使用会话恢复的服务器会为会话指定惟一的标识，称为会话 ID。
- 但愿恢复会话的客户端将相应的会话 ID 放入 ClientHello 消息中，提交给服务器
- 服务器若是愿意恢复会话，将相同的会话 ID 放入 Server Hello 消息返回，使用以前协商的主密钥生成一套新密钥，切换到加密模式，发送完成信息
TLS 1.3 创建新链接
- 在一次新的握手流程中，客户端不只会发送 Client Hello 同时也会将支持的密码套件以及客户端密钥发送给服务端，相比于 TLS1.2，该步骤节约了一个 RTT
- 服务端发送 Server Hello ，服务端密钥和证书
- 客户端接收服务端发过来的信息，使用服务端密钥，同时检查证书完整性，此时加密链接已经创建能够发送 HTTP 请求，整个过程仅仅一个 RTT
TLS 1.3 0-RTT 会话恢复
TLS 1.2 中经过 1 个 RTT 便可完成会话恢复，那么 TLS 1.3 是如何作到 0 RTT 链接的？
当一个支持 TLS 1.3 的客户端链接到一样支持 TLS 1.3 的服务器时， 客户端会将收到服务器发送过来的 Ticket 经过相关计算，一块儿组成新的 预共享密钥，PSK （PreSharedKey）。客户端会将该 PSK 缓存在本地，在会话恢复时在 Client Hello 上带上 PSK 扩展，同时经过以前客户端发送的完成（finished）计算出恢复密钥 （Resumption Secret）经过该密钥加密数据发送给服务器。服务器会从会话 Ticket 中算出 PSK，使用它来解密刚才发过来的加密数据。
至此完成了该 0-RTT 会话恢复的过程。
以上简单描述了 TLS 1.3 创建链接的大体流程，也解释了为何 TLS 1.3 相比于以前的 TLS 1.2 会有更出色的性能表现。
固然 TLS 1.3 还有很是很是多的细节以及安全特性，优势以及缺点（去除静态 RSA 和 DH 密钥协商、禁止 RC四、有反作用的 0-RTT握手存在重放攻击，不支持前向保密.....），限于篇幅并无更深刻的去探讨。
总结
TLS 1.3 将是 Web 性能以及安全的一个新的里程碑，随之 TLS1.3 带来的 0-RTT 握手，淡化了你们以前对使用 HTTPS 性能上的隐忧。于此同时，在将来随着 HTTP/2 的不断普及，强制性使用 HTTPS 成为了一种必然。
HTTPS 的推广也离不开一些公益性的组织，好比 Let's Encrypt。
Let's Encrypt 推进了基础 DV HTTPS 证书的普及，让互联网上的中小站长和独立博客用户很容易的用上 HTTPS。而对于企业来讲，DV 证书是不能知足要求的。须要信任等级更高、安全级别更强的企业型 SSL 证书（OV SSL）以及加强型SSL证书（EV SSL），相比于 DV 证书，后二者价格虽会更贵一些，而带来的安全性保证倒是前者 DV 证书不能相比的。
SSL 证书是 HTTPS 中必不可少的一步，七牛云也于近日上线了一站式 SSL 证书申购服务，为更多的互联网企业以及我的开发者提供证书服务，也有为我的站长及开发者推出免费单域名 DV SSL 证书。即刻申购，最高可节省 66000 元哦！浏览器
