Tcp fast open

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

HSTS

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

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

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

Session resume

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

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

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

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

Session cache

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

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

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

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

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

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

Session ticket

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

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

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

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

Ocsp stapling

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

False start

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

使用 SPDY 或者 HTTP2

SPDY 是 google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議，它基本上沿用了 HTTP 協(xié)議的語(yǔ)義 , 但是通過(guò)使用幀控制實(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ì)上無(wú)法解決并發(fā)的問(wèn)題。
HTTP2 是 IETF 2015 年 2 月份通過(guò)的 HTTP 下一代協(xié)議，它以 SPDY 為原型，經(jīng)過(guò)兩年多的討論和完善最終確定。
本文就不過(guò)多介紹 SPDY 和 HTTP2 的收益，需要說(shuō)明兩點(diǎn)：

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

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

分享題目：HTTPS 訪問(wèn)速度優(yōu)化
分享網(wǎng)址：http://aaarwkj.com/news29/44979.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁(yè)設(shè)計(jì)公司、移動(dòng)網(wǎng)站建設(shè)、營(yíng)銷型網(wǎng)站建設(shè)、動(dòng)態(tài)網(wǎng)站、靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計(jì)公司

廣告

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