Tcp fast open

HTTPS 和 HTTP 使用 TCP 協(xié)議進行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個 RTT 的時間內(nèi)只傳輸一個 syn 包是不是太浪費？能不能在 syn 包發(fā)出的同時捎上應(yīng)用層的數(shù)據(jù)？其實是可以的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理可以參考 rfc7413。
遺憾的是 TFO 需要高版本內(nèi)核的支持，linux 從 3.7 以后支持 TFO，但是目前的 windows 系統(tǒng)還不支持 TFO，所以只能在公司內(nèi)部服務(wù)器之間發(fā)揮作用。

HSTS

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

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

2. 降低訪問速度，302 跳轉(zhuǎn)不僅需要一個 RTT，瀏覽器執(zhí)行跳轉(zhuǎn)也需要執(zhí)行時間。
   由于 302 跳轉(zhuǎn)事實上是由瀏覽器觸發(fā)的，服務(wù)器無法完全控制，這個需求導(dǎo)致了 HSTS 的誕生：
   HSTS(HTTP Strict Transport Security)。服務(wù)端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時間內(nèi)，不管用戶輸入都會默認將請求內(nèi)部跳轉(zhuǎn)成。
   Chrome, firefox, ie 都支持了 HSTS。

Session resume

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

1. 減少了 CPU 消耗，因為不需要進行非對稱密鑰交換的計算。

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

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

Session cache

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

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

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

Session cache 也有一個非常大的優(yōu)點：

1. session id 是 TLS 協(xié)議的標準字段，市面上的瀏覽器全部都支持 session cache。

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

Session ticket

上節(jié)提到了 session cache 的兩個缺點，session ticket 能夠彌補這些不足。
Session ticket 的原理參考 RFC4507。簡述如下：
server 將 session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器后續(xù)握手請求時會發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。
顯然，session ticket 的優(yōu)點是不需要服務(wù)端消耗大量資源來存儲 session 內(nèi)容。
Session ticket 的缺點：

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

2. session ticket 需要維護一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

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

Ocsp stapling

Ocsp 全稱在線證書狀態(tài)檢查協(xié)議 (rfc6960)，用來向 CA 站點查詢證書狀態(tài)，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請求，CA 返回證書狀態(tài)內(nèi)容，然后瀏覽器接受證書是否可信的狀態(tài)。
這個過程非常消耗時間，因為 CA 站點有可能在國外，網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內(nèi)容呢？ocsp stapling 就能實現(xiàn)這個功能。
詳細介紹參考 RFC6066 第 8 節(jié)。簡述原理就是瀏覽器發(fā)起 client hello 時會攜帶一個 certificate status request 的擴展，服務(wù)端看到這個擴展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成證書狀態(tài)檢查。
由于瀏覽器不需要直接向 CA 站點查詢證書狀態(tài)，這個功能對訪問速度的提升非常明顯。
Nginx 目前已經(jīng)支持這個 ocsp stapling file，只需要配置 ocsp stapling file 的指令就能開啟這個功能：

False start

通常情況下，應(yīng)用層數(shù)據(jù)必須等完全握手全部結(jié)束之后才能傳輸。這個其實比較浪費時間，那能不能類似 TFO 一樣，在完全握手的第二個階段將應(yīng)用數(shù)據(jù)一起發(fā)出來呢？google 提出了 false start 來實現(xiàn)這個功能。詳細介紹參考 
簡單概括 False start 的原理就是在 client_key_exchange 發(fā)出時將應(yīng)用層數(shù)據(jù)一起發(fā)出來，能夠節(jié)省一個 RTT。
False start 依賴于 PFS（perfect forward secrecy 好前向加密），而 PFS 又依賴于 DHE 密鑰交換系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優(yōu)先支持 ECDHE 密鑰交換算法實現(xiàn) false start。

使用 SPDY 或者 HTTP2

SPDY 是 google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議，它基本上沿用了 HTTP 協(xié)議的語義 , 但是通過使用幀控制實現(xiàn)了多個特性，顯著提升了 HTTP 協(xié)議的傳輸效率。
SPDY 大的特性就是多路復(fù)用，能將多個 HTTP 請求在同一個連接上一起發(fā)出去，不像目前的 HTTP 協(xié)議一樣，只能串行地逐個發(fā)送請求。Pipeline 雖然支持多個請求一起發(fā)送，但是接收時依然得按照順序接收，本質(zhì)上無法解決并發(fā)的問題。
HTTP2 是 IETF 2015 年 2 月份通過的 HTTP 下一代協(xié)議，它以 SPDY 為原型，經(jīng)過兩年多的討論和完善最終確定。
本文就不過多介紹 SPDY 和 HTTP2 的收益，需要說明兩點：

1. SPDY 和 HTTP2 目前的實現(xiàn)默認使用 HTTPS 協(xié)議。

2. SPDY 和 HTTP2 都支持現(xiàn)有的 HTTP 語義和 API，對 WEB 應(yīng)用幾乎是透明的。
   Google 宣布 chrome 瀏覽器 2016 年將放棄 SPDY 協(xié)議，全面支持 HTTP2，但是目前國內(nèi)部分瀏覽器廠商進度非常慢，不僅不支持 HTTP2，連 SPDY 都沒有支持過。
   百度服務(wù)端和百度手機瀏覽器現(xiàn)在都已經(jīng)支持 SPDY3.1 協(xié)議。

分享題目：HTTPS 訪問速度優(yōu)化
分享路徑：http://m.2m8n56k.cn/news/44979.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計公司、網(wǎng)站內(nèi)鏈、定制開發(fā)、企業(yè)建站、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)