1 前言

上文講到 HTTPS 對(duì)用戶訪問速度的影響。

本文就為大家介紹 HTTPS 在訪問速度，計(jì)算性能，安全等方面基于協(xié)議和配置的優(yōu)化。

2 HTTPS 訪問速度優(yōu)化

2.1 Tcp fast open

HTTPS 和 HTTP 使用 TCP 協(xié)議進(jìn)行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個(gè) RTT 的時(shí)間內(nèi)只傳輸一個(gè) syn 包是不是太浪費(fèi)？能不能在 syn 包發(fā)出的同時(shí)捎上應(yīng)用層的數(shù)據(jù)？其實(shí)是可以的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理可以參考 rfc7413。

遺憾的是 TFO 需要高版本內(nèi)核的支持，linux 從 3.7 以后支持 TFO，但是目前的 windows 系統(tǒng)還不支持 TFO，所以只能在公司內(nèi)部服務(wù)器之間發(fā)揮作用。

2.2 HSTS

前面提到過將用戶 HTTP 請(qǐng)求 302 跳轉(zhuǎn)到 HTTPS，這會(huì)有兩個(gè)影響：

1、不安全，302 跳轉(zhuǎn)不僅暴露了用戶的訪問站點(diǎn)，也很容易被中間者支持。

2、降低訪問速度，302 跳轉(zhuǎn)不僅需要一個(gè) RTT，瀏覽器執(zhí)行跳轉(zhuǎn)也需要執(zhí)行時(shí)間。

由于 302 跳轉(zhuǎn)事實(shí)上是由瀏覽器觸發(fā)的，服務(wù)器無法完全控制，這個(gè)需求導(dǎo)致了 HSTS 的誕生：

HSTS(HTTP Strict Transport Security)。服務(wù)端返回一個(gè) HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時(shí)間內(nèi)，不管用戶輸入www.baidu.com還是http://www.baidu.com，都會(huì)默認(rèn)將請(qǐng)求內(nèi)部跳轉(zhuǎn)成https://www.baidu.com。

Chrome, firefox, ie 都支持了 HSTS（http://caniuse.com/#feat=stricttransportsecurity）。

2.3 Session resume

Session resume 顧名思義就是復(fù)用 session，實(shí)現(xiàn)簡化握手。復(fù)用 session 的好處有兩個(gè)：

1、減少了 CPU 消耗，因?yàn)椴恍枰�進(jìn)行非對(duì)稱密鑰交換的計(jì)算。

2、提升訪問速度，不需要進(jìn)行完全握手階段二，節(jié)省了一個(gè) RTT 和計(jì)算耗時(shí)。

TLS 協(xié)議目前提供兩種機(jī)制實(shí)現(xiàn) session resume，分別介紹一下。

2.3.1 Session cache

Session cache 的原理是使用 client hello 中的 session id 查詢服務(wù)端的 session cache, 如果服務(wù)端有對(duì)應(yīng)的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。

Session cache 有兩個(gè)缺點(diǎn)：

1、需要消耗服務(wù)端內(nèi)存來存儲(chǔ) session 內(nèi)容。

2、目前的開源軟件包括 nginx,apache 只支持單機(jī)多進(jìn)程間共享緩存，不支持多機(jī)間分布式緩存，對(duì)于百度或者其他大型互聯(lián)網(wǎng)公司而言，單機(jī) session cache 幾乎沒有作用。

Session cache 也有一個(gè)非常大的優(yōu)點(diǎn)：

session id 是 TLS 協(xié)議的標(biāo)準(zhǔn)字段，市面上的瀏覽器全部都支持 session cache。

百度通過對(duì) TLS 握手協(xié)議及服務(wù)器端實(shí)現(xiàn)的優(yōu)化，已經(jīng)支持全局的 session cache，能夠明顯提升用戶的訪問速度，節(jié)省服務(wù)器計(jì)算資源。

2.3.2 Session ticket

上節(jié)提到了 session cache 的兩個(gè)缺點(diǎn)，session ticket 能夠彌補(bǔ)這些不足。

Session ticket 的原理參考 RFC4507。簡述如下：

server 將 session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器后續(xù)握手請(qǐng)求時(shí)會(huì)發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。

顯然，session ticket 的優(yōu)點(diǎn)是不需要服務(wù)端消耗大量資源來存儲(chǔ) session 內(nèi)容。

Session ticket 的缺點(diǎn)：

1、session ticket 只是 TLS 協(xié)議的一個(gè)擴(kuò)展特性，目前的支持率不是很廣泛，只有 60% 左右。

2、session ticket 需要維護(hù)一個(gè)全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

總體來講，session ticket 的功能特性明顯優(yōu)于 session cache。希望客戶端實(shí)現(xiàn)優(yōu)先支持 session ticket。

2.4 Ocsp stapling

Ocsp 全稱在線證書狀態(tài)檢查協(xié)議 (rfc6960)，用來向 CA 站點(diǎn)查詢證書狀態(tài)，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請(qǐng)求，CA 返回證書狀態(tài)內(nèi)容，然后瀏覽器接受證書是否可信的狀態(tài)。

這個(gè)過程非常消耗時(shí)間，因?yàn)?CA 站點(diǎn)有可能在國外，網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大。那有沒有辦法不直接向 CA 站點(diǎn)請(qǐng)求 OCSP 內(nèi)容呢？ocsp stapling 就能實(shí)現(xiàn)這個(gè)功能。

詳細(xì)介紹參考 RFC6066 第 8 節(jié)。簡述原理就是瀏覽器發(fā)起 client hello 時(shí)會(huì)攜帶一個(gè) certificate status request 的擴(kuò)展，服務(wù)端看到這個(gè)擴(kuò)展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成證書狀態(tài)檢查。

由于瀏覽器不需要直接向 CA 站點(diǎn)查詢證書狀態(tài)，這個(gè)功能對(duì)訪問速度的提升非常明顯。

Nginx 目前已經(jīng)支持這個(gè) ocsp stapling file，只需要配置 ocsp stapling file 的指令就能開啟這個(gè)功能：

• ssl_stapling on;ssl_stapling_file ocsp.staple;

2.5 False start

通常情況下，應(yīng)用層數(shù)據(jù)必須等完全握手全部結(jié)束之后才能傳輸。這個(gè)其實(shí)比較浪費(fèi)時(shí)間，那能不能類似 TFO 一樣，在完全握手的第二個(gè)階段將應(yīng)用數(shù)據(jù)一起發(fā)出來呢？google 提出了 false start 來實(shí)現(xiàn)這個(gè)功能。詳細(xì)介紹參考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。

簡單概括 False start 的原理就是在 client_key_exchange 發(fā)出時(shí)將應(yīng)用層數(shù)據(jù)一起發(fā)出來，能夠節(jié)省一個(gè) RTT。

False start 依賴于 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依賴于 DHE 密鑰交換系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優(yōu)先支持 ECDHE 密鑰交換算法實(shí)現(xiàn) false start。

2.6 使用 SPDY 或者 HTTP2

SPDY 是 google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議（https://www.chromium.org/spdy），它基本上沿用了 HTTP 協(xié)議的語義, 但是通過使用幀控制實(shí)現(xiàn)了多個(gè)特性，顯著提升了 HTTP 協(xié)議的傳輸效率。

SPDY 最大的特性就是多路復(fù)用，能將多個(gè) HTTP 請(qǐng)求在同一個(gè)連接上一起發(fā)出去，不像目前的 HTTP 協(xié)議一樣，只能串行地逐個(gè)發(fā)送請(qǐng)求。Pipeline 雖然支持多個(gè)請(qǐng)求一起發(fā)送，但是接收時(shí)依然得按照順序接收，本質(zhì)上無法解決并發(fā)的問題。

HTTP2 是 IETF 2015 年 2 月份通過的 HTTP 下一代協(xié)議，它以 SPDY 為原型，經(jīng)過兩年多的討論和完善最終確定。

本文就不過多介紹 SPDY 和 HTTP2 的收益，需要說明兩點(diǎn)：

1、SPDY 和 HTTP2 目前的實(shí)現(xiàn)默認(rèn)使用 HTTPS 協(xié)議。

2、SPDY 和 HTTP2 都支持現(xiàn)有的 HTTP 語義和 API，對(duì) WEB 應(yīng)用幾乎是透明的。

Google 宣布 chrome 瀏覽器 2016 年將放棄 SPDY 協(xié)議，全面支持 HTTP2，但是目前國內(nèi)部分瀏覽器廠商進(jìn)度非常慢，不僅不支持 HTTP2，連 SPDY 都沒有支持過。

百度服務(wù)端和百度手機(jī)瀏覽器現(xiàn)在都已經(jīng)支持 SPDY3.1 協(xié)議。

標(biāo)簽： HTTPS HTTPS協(xié)議 https和http有什么區(qū)別 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。