序•魔戒再現
幾天前，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 元哦！瀏覽器
