序•魔戒再现
谈到 TLS 那么就不得不说回 HTTPS，2016 年应该算是国内站点使用 HTTPS 激增的一年，从 Google Trend 上也可以看出该关键词的搜索热度从 2016 年开始飙升。不光如此，所有从事互联网 Web 技术相关的开发人员，也应该能够明显感受到，身边使用 HTTPS 的网站越来越多了。
用户每天被来自各种广告联盟漫天的牛皮癣广告和运营商话费余额查询所包围。不仅如此，随着公司流量不断的被劫持导流到其他地方。搞得很多公司连苦心经营的市场蛋糕都没办法安心的吃，终于大部分公司坐不住了。当然声讨和口诛笔伐是没有用的，所以拥有业务上拥有 HTTPS 和 HTTP DNS 解决方案，也就顺理成章的成了技术公司在伟大防火墙内生存的必备技能之一。
另一方面，从安全角度讲，互联网上通过明文传输数据本身就是一件高风险的事情，什么数据泄露、中间人攻击、用户被盗号、被竞争对手背后捅刀子 App 下载被劫持…..也是屡见不鲜。
那么说回主题，既然 HTTPS 可以一劳永逸的解决上述问题
王者归来
在 Web 领域，传输延迟（Transmission Latency）是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 链接的建立大概需要以下四步：4 RTT + DNS 查询时间
访问刚浏览过的连接：
3 RTT + DNS 查询时间
TLS 1.2 建立新连接
- 在一次新的握手流程中，Client Hello 总是客户端发送的第一条消息，该消息包含客户端的功能和首选项，与此同时客户端也会将本身支持的所有密码套件（Cipher Suite）列表发送过去
- Server Hello 将服务器选择的连接参数传送回客户端，同时将证书链发送过去，进行服务器的密钥交换
- 进行客户端部分的密钥交换，此时握手已经完成，加密连接已经可以使用
- 客户端建立 HTTP 连接
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 密钥协商、禁止 RC4、有副作用的 0-RTT 握手存在重放攻击，不支持前向保密…..），限于篇幅并没有更深入的去探讨。
总结
