如何進(jìn)行優(yōu)化HTTPS

如何進(jìn)行優(yōu)化HTTPS，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

HTTP 2.0

HTTP 2.0即超文本傳輸協(xié)議 2.0，是下一代HTTP協(xié)議。是由互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小組進(jìn)行開(kāi)發(fā)。是自1999年http1.1發(fā)布后的首個(gè)更新，HTTP/2 協(xié)議是從 SPDY 演變而來(lái)，SPDY 已經(jīng)完成了使命并很快就會(huì)退出歷史舞臺(tái)（例如 Chrome 在「2016 年初結(jié)束對(duì) SPDY 的支持」；Nginx在版本1.9.5+，Apache在版本2.4.16+都已經(jīng)全面支持HTTP/2。

上圖是Akamai的HTTP/2 DEMO，通過(guò)加載300張圖片，對(duì)比HTTP/1.1和HTTP/2，首先直觀地感受一下HTTP/2，下來(lái)解釋一下這個(gè)感受的原因，即HTTP/2新特性：

• 二進(jìn)制分幀

• 首部壓縮

• 流量控制

• 多路復(fù)用

• 請(qǐng)求優(yōu)先級(jí)

• 服務(wù)器推送

二進(jìn)制分幀

二進(jìn)制分幀層，是HTTP2.0性能增強(qiáng)的核心

HTTP 1.x在應(yīng)用層以純文本的形式進(jìn)行通信，HTTP2.0在不改變HTTP1.x的語(yǔ)義、方法、狀態(tài)碼、URL以及首部字段的情況下，為了突破原有性能限制，在應(yīng)用層(HTTP)和傳輸層(TCP)之間增加了一個(gè)二進(jìn)制分幀層。HTTP2.0將所有的傳輸信息分割為更小的消息和幀，并對(duì)它們采用二進(jìn)制格式編碼，如下圖所示

這里引入一個(gè)新的通信單位：幀

幀是HTTP 2.0通信的最小單位，包括幀首部、流標(biāo)識(shí)符、優(yōu)先值和幀凈荷等

其中，幀類(lèi)型可以分為：

• DATA：用于傳輸HTTP消息體

• HEADERS：用于傳輸首部字段

• SETTINGS：用于約定客戶端和服務(wù)端的配置數(shù)據(jù)。比如設(shè)置初識(shí)的雙向流量控制窗口大小

• WINDOW_UPDATE：用于調(diào)整個(gè)別流或個(gè)別連接的流量

• PRIORITY：用于指定或重新指定引用資源的優(yōu)先級(jí)

• RST_STREAM：用于通知流的非正常終止

• PUSH_ PROMISE：服務(wù)端推送許可

• PING：用于計(jì)算往返時(shí)間，執(zhí)行“ 活性” 檢活

• GOAWAY：用于通知對(duì)端停止在當(dāng)前連接中創(chuàng)建流

標(biāo)志位，用于不同的幀類(lèi)型定義特定的消息標(biāo)志。比如DATA幀就可以使用End Stream: true表示該條消息通信完畢；流標(biāo)識(shí)位表示幀所屬的流ID；優(yōu)先值用于HEADERS幀，表示請(qǐng)求優(yōu)先級(jí)；R表示保留。

下面是抓包的一個(gè)HEADERS幀：

另外一個(gè)兩個(gè)要說(shuō)一下的概念：消息和流

消息是指邏輯上的HTTP消息(請(qǐng)求/響應(yīng))，一系列數(shù)據(jù)幀組成一個(gè)完整的消息，比如一系列DATA幀和一個(gè)HEADERS幀組成了請(qǐng)求消息。

流是鏈接中的一個(gè)虛擬信道，可以承載雙向消息傳輸，每個(gè)流有唯一證書(shū)標(biāo)識(shí)符，為了防止兩端流ID沖突，客戶端發(fā)起的流具有奇數(shù)ID，服務(wù)端發(fā)起的流具有偶數(shù)ID。

所有HTTP 2.0通信都在一個(gè)TCP鏈接上完成，這個(gè)鏈接可以承載任意數(shù)量的雙向數(shù)據(jù)流Stream。相應(yīng)地，每個(gè)數(shù)據(jù)流以消息的形式發(fā)送，而消息由一個(gè)或多個(gè)幀組成，這些幀可以亂序發(fā)送，然后根據(jù)每個(gè)幀首部的流標(biāo)識(shí)符重新組裝。

二進(jìn)制分幀主要是為HTTP2.0其他特性提供基礎(chǔ)。它能把一個(gè)數(shù)據(jù)劃分封裝為更小更便捷的數(shù)據(jù)。首先是在單鏈多資源方式中，減少服務(wù)端的鏈接壓力，內(nèi)存占用更少，鏈接吞吐量更大；另一方面，由于TCP鏈接的減少而使網(wǎng)絡(luò)擁塞狀態(tài)得以改善，同時(shí)慢啟動(dòng)時(shí)間減少，使擁塞和丟包恢復(fù)的速度更快。

首部壓縮

HTTP1.x每次通信(請(qǐng)求或響應(yīng))都會(huì)攜帶首部信息用于描述資源屬性。而HTTP2.0在客戶端和服務(wù)端之間使用首部表來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵值對(duì)，首部表在連接過(guò)程中始終存在，新增的鍵值對(duì)會(huì)更新到表尾，因此不需要每次通信都攜帶首部，請(qǐng)求與響應(yīng)首部的定義在HTTP2.0中基本沒(méi)有變。

另外HTTP2.0使用了首部壓縮技術(shù)，壓縮算法采用HPACK，讓報(bào)頭更緊湊、更快速傳輸，有利于移動(dòng)網(wǎng)絡(luò)環(huán)境。需要注意的是，HTTP2.0的首部壓縮，與我們常用的gzip等報(bào)文內(nèi)容壓縮不沖突。

流量控制

HTTP/2.0 “流”的流量控制的目標(biāo)是：在不改變協(xié)議的情況下允許使用多種流量控制算法

流量控制是特定于一個(gè)連接的。每種類(lèi)型的流量控制都是在單獨(dú)的一跳的兩個(gè)端點(diǎn)之間的，并不是在整個(gè)端到端的路徑上的。（這里的一跳指的是HTTP連接的一跳，而不是IP路由的一跳）

流量控制是基于WINDOW_UPDATE幀的。接收方公布自己打算在每個(gè)流以及整個(gè)連接上分別接收多少字節(jié)。這是一個(gè)以信用為基礎(chǔ)的方案。

流量控制是有方向的，由接收者全面控制。接收方可以為每個(gè)流和整個(gè)連接設(shè)置任意的窗口大小。發(fā)送方必須尊重接收方設(shè)置的流量控制限制?？蛻舴健⒎?wù)端和中間代理作為接收方時(shí)都獨(dú)立地公布各自的流量控制窗口，作為發(fā)送方時(shí)都遵守對(duì)端的流量控制設(shè)置。

無(wú)論是新流還是整個(gè)連接，流量控制窗口的初始值是65535字節(jié)。

幀的類(lèi)型決定了流量控制是否適用于幀。目前，只有DATA幀服從流量控制，所有其它類(lèi)型的幀并不消耗流量控制窗口的空間。這保證了重要的控制幀不會(huì)被流量控制阻塞。

流量控制不能被禁用。

HTTP/2只定義了WINDOW_UPDATE幀的格式和語(yǔ)義，并沒(méi)有規(guī)定接收方如何決定何時(shí)發(fā)送幀、發(fā)送什么樣的值，也沒(méi)有規(guī)定發(fā)送方如何選擇發(fā)送包。具體實(shí)現(xiàn)可以選擇任何滿足需求的算法。

多路復(fù)用

在HTTP1.1中，瀏覽器客戶端在同一時(shí)間，針對(duì)同一域名下的請(qǐng)求有一定數(shù)量的限制。超過(guò)限制數(shù)目的請(qǐng)求會(huì)被阻塞，而HTTP2.0中的多路復(fù)用優(yōu)化了這一性能。

基于二進(jìn)制分幀層，HTTP2.0可以在共享TCP連接的基礎(chǔ)上，同時(shí)發(fā)送請(qǐng)求和響應(yīng)。HTTP消息被分解為獨(dú)立的幀，而不破壞消息本身的語(yǔ)義，交錯(cuò)發(fā)送出去，最后在另一端根據(jù)流ID和首部將他們重新組合。對(duì)比看一下HTTP1.x和HTTP2.0，這里不考慮HTTP1.x的pipeline機(jī)制。

HTTP2.0成功解決了HTTP1.x的隊(duì)首阻塞問(wèn)題(TCP層的阻塞仍無(wú)法解決)，同時(shí)，也不需要通過(guò)pipeline機(jī)制多條TCP連接來(lái)實(shí)現(xiàn)并行請(qǐng)求與響應(yīng)。減少了TCP連接數(shù)對(duì)服務(wù)器性能有很大提升，同時(shí)也消除不必要的延遲，從而減少頁(yè)面加載的時(shí)間。

請(qǐng)求優(yōu)先級(jí)

把HTTP消息分為很多獨(dú)立幀之后，就可以通過(guò)優(yōu)化這些幀的交錯(cuò)和傳輸順序進(jìn)一步優(yōu)化性能。

每個(gè)流都可以帶有一個(gè)31bit的優(yōu)先值：0表示最高優(yōu)先級(jí)；2的31次方-1表示最低優(yōu)先級(jí)。

客戶端明確指定優(yōu)先級(jí)，服務(wù)端可以根據(jù)這個(gè)優(yōu)先級(jí)作為交互數(shù)據(jù)的依據(jù)，比如客戶端優(yōu)先設(shè)置為.css>.js>.jpg。服務(wù)端按此順序返回結(jié)果更加有利于高效利用底層連接，提高用戶體驗(yàn)。然而，在使用請(qǐng)求優(yōu)先級(jí)時(shí)應(yīng)注意服務(wù)端是否支持請(qǐng)求優(yōu)先級(jí)，是否會(huì)引起隊(duì)首阻塞問(wèn)題，比如高優(yōu)先級(jí)的 慢響應(yīng)請(qǐng)求會(huì)阻塞其他資源的交互。

服務(wù)器推送

HTTP2.0增加了服務(wù)端推送功能，服務(wù)端可以根據(jù)客戶端的請(qǐng)求，提前返回多個(gè)響應(yīng)，推送額外的資源給客戶端

如下圖，客戶端請(qǐng)求stream 1(/page.html)。服務(wù)器在返回stream 1的消息的同時(shí)推送了stream 2(/script.js)和stream4(/style.css)

• PUSH_PROMISE幀是服務(wù)端向客戶端有意推送資源的信號(hào)。

• PUSH_PROMISE幀中只包含預(yù)推送資源的首部。如果客戶端對(duì)PUSH_PROMISE幀沒(méi)有意見(jiàn)，服務(wù)端在PUSH_PROMISE幀后發(fā)送響應(yīng)的DATA幀。如果客戶端已經(jīng)緩存了該資源，不需要推送，可以拒絕PUSH_PROMISE幀。

• PUSH-PROMISE必須遵循請(qǐng)求-響應(yīng)原則，只能借著對(duì)請(qǐng)求的響應(yīng)推送資源。

• PUSH_PROMISE幀必須在返回響應(yīng)之前發(fā)送，以免客戶端出現(xiàn)競(jìng)態(tài)條件（競(jìng)態(tài)條件是指在多線程的情況下不同的執(zhí)行順序會(huì)導(dǎo)致計(jì)算機(jī)執(zhí)行出不同的結(jié)果正確性不同）

• HTTP2.0連接后，客戶端與服務(wù)端交換SETTINGS幀，借此限定雙向并發(fā)的最大數(shù)量。因此，客戶端可以限定推送流的數(shù)量，或者通過(guò)把這個(gè)只設(shè)置為0來(lái)完全禁止服務(wù)器推送。

• 所有推送的資源都必須遵守同源策略。換句話說(shuō)，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過(guò)雙方的確認(rèn)才行。

HTTP/2現(xiàn)在已經(jīng)獲得絕大多數(shù)瀏覽器的支持，不過(guò)在使用過(guò)程中HTTP/2需要使用1.0.1e之后的openssl版本，通過(guò)nginx -V，可以查看nginx的openssl版本，如果版本低，重新編譯nginx即可。

那么在nginx中如何配置支持HTTP/2？很簡(jiǎn)單，只需要在server中的listen部分添加http2即可。

怎么測(cè)試http2是否已開(kāi)啟，方法很多，這里介紹三種方法：

1、瀏覽器開(kāi)發(fā)者工具

2、Chrome擴(kuò)展HTTP/2 and SPDY indicator

3、命令行客戶端nghttp

另外HTTP/2的服務(wù)器推送，需要nginx配置才能有效利用。

通過(guò)http2_push指令配置

這種情況下，demo.html需要用到的資源style.css、image1.jpg和image2.jpg被推送到客戶端。資源少的情況下，我們可以這么使用，但是資源多的情況下這種方式就不太現(xiàn)實(shí)。

自動(dòng)將資源推送給客戶端

nginx支持?jǐn)r截link預(yù)加載頭的約定，推送這寫(xiě)頭中標(biāo)識(shí)的資源，需要在配置中啟動(dòng)預(yù)加載，配置http2_push_preload on

這里也有一個(gè)問(wèn)題，一般的靜態(tài)資源，我們都會(huì)設(shè)置緩存有效期。當(dāng)客戶端資源在緩存有效期內(nèi)的時(shí)候，我們強(qiáng)制推送靜態(tài)資源，只會(huì)增加服務(wù)器帶寬的壓力，所以我們需要指定客戶端是否需要這些資源，并且不太可能已經(jīng)緩存過(guò)，可能的方法，就是客戶端在首次訪問(wèn)時(shí)服務(wù)端推送，并在隨后的訪問(wèn)請(qǐng)求中包含cookie，服務(wù)端通過(guò)cookie去判斷是否進(jìn)行推送，就是有選擇的向客戶端推送資源，配置方法如下：

測(cè)試如下：

TLS 1.3

TLS(Transport Layer Security Protocol，傳輸層安全協(xié)議)主要目的是提供隱私和數(shù)據(jù)亮哥通信應(yīng)用之間的完整性。該協(xié)議由兩層組成：TLS記錄協(xié)議(TLS Record)和TLS握手協(xié)議(TLS Handshake)。

TLS協(xié)議經(jīng)過(guò)很多次版本的更新，目前低版本的TLS，如SSL 3.0/TLS 1.0等，存在許多嚴(yán)重漏洞，目前受到主流支持的TLS協(xié)議版本是1.1和1.2，但也都已經(jīng)落后于時(shí)代的需求。在2018年8月份，IETF終于宣布TLS 1.3規(guī)范正式發(fā)布了，標(biāo)準(zhǔn)規(guī)范定義在rfc8446。

相較于之前的版本TLS優(yōu)化內(nèi)容有：

• 相比過(guò)去的的版本，引入了新的密鑰協(xié)商機(jī)制 — PSK

• 支持 0-RTT 數(shù)據(jù)傳輸，在建立連接時(shí)節(jié)省了往返時(shí)間

• 廢棄了 3DES、RC4、AES-CBC 等加密組件，廢棄了 SHA1、MD5 等哈希算法

• ServerHello 之后的所有握手消息采取了加密操作，可見(jiàn)明文大大減少

• 不再允許對(duì)加密報(bào)文進(jìn)行壓縮、不再允許雙方發(fā)起重協(xié)商

• DSA 證書(shū)不再允許在 TLS 1.3 中使用

在https中，每個(gè)連接的TLS的握手是很消耗資源及時(shí)間的，所以TLS 1.3的優(yōu)化，比之前的版本建立連接的時(shí)間少了一個(gè)RTT，同等情況下，節(jié)省了很多時(shí)間，提高了響應(yīng)速度。

TLS 1.3需要openssl 1.1.1支持，在nginx上，需要nginx 1.13+支持。

在編譯nginx的時(shí)候，需要添加編譯參數(shù)--with-openssl-opt=enable-tls1_3來(lái)開(kāi)啟TLS 1.3支持，并在配置中ssl_protocols中添加TLSv1.3，對(duì)應(yīng)的TLS1.3引入了新的算法，所以ssl_ciphers也需要添加新算法

默認(rèn)情況下nginx因?yàn)榘踩?，沒(méi)有開(kāi)啟TLS 1.3的 0-RTT，可以通過(guò)指令ssl_early_data on來(lái)開(kāi)啟。

ECC

ECC(Elliptic curve cryptography，橢圓曲線密碼學(xué))，一種建立公開(kāi)密鑰的算法，基于橢圓曲線數(shù)學(xué)。

內(nèi)置ECDSA公鑰的證書(shū)一般稱(chēng)為ECC證書(shū)，內(nèi)置RSA公鑰的證書(shū)一般稱(chēng)為RSA證書(shū)。

ECC算法的數(shù)學(xué)理論非常深?yuàn)W和復(fù)雜，在工程應(yīng)用中比較難于實(shí)現(xiàn)，但它的單位安全強(qiáng)度相對(duì)較高，它的破譯或求解難度基本上是指數(shù)級(jí)的，黑客很難用通常使用的暴力破解的方法來(lái)破解。RSA算法的特點(diǎn)之一是數(shù)學(xué)原理相對(duì)簡(jiǎn)單，在工程應(yīng)用中比較易于實(shí)現(xiàn)，但它的單位安全強(qiáng)度相對(duì)較低。因此，ECC算法的可以用較少的計(jì)算能力提供比RSA加密算法更高的安全強(qiáng)度，有效地解決了“提高安全強(qiáng)度必須增加密鑰長(zhǎng)度”的工程實(shí)現(xiàn)問(wèn)題。

與RSA算法相比，ECC算法擁有一下優(yōu)勢(shì)：

• 更適合于移動(dòng)互聯(lián)網(wǎng)：ECC加密算法的密鑰長(zhǎng)度很短(256位)，意味著占用更少的存儲(chǔ)空間，更低的CPU開(kāi)銷(xiāo)和占用更少的帶寬。隨著越來(lái)越多的用戶使用移動(dòng)設(shè)備來(lái)完成各種網(wǎng)上活動(dòng)，ECC加密算法為移動(dòng)互聯(lián)網(wǎng)安全提供更好的客戶體驗(yàn)。

• 更好的安全性：ECC加密算法提供更強(qiáng)的保護(hù)，比目前的其他加密算法能更好的防止攻擊，使你的網(wǎng)站和基礎(chǔ)設(shè)施比用傳統(tǒng)的加密方法更安全，為移動(dòng)互聯(lián)網(wǎng)安全提供更好的保障。

• 更好的性能：ECC加密算法需要較短的密鑰長(zhǎng)度來(lái)提供更好的安全，例如，256位的ECC密鑰加密強(qiáng)度等同于3072位RSA密鑰的水平(目前普通使用的RSA密鑰長(zhǎng)度是2048位)。其結(jié)果是你以更低的計(jì)算能力代價(jià)得到了更高的安全性。經(jīng)國(guó)外有關(guān)權(quán)威機(jī)構(gòu)測(cè)試，在Apache和IIS服務(wù)器采用ECC算法，Web服務(wù)器響應(yīng)時(shí)間比RSA快十幾倍。

• 更大的IT投資回報(bào)：ECC可幫助保護(hù)您的基礎(chǔ)設(shè)施的投資，提供更高的安全性，并快速處理爆炸增長(zhǎng)的移動(dòng)設(shè)備的安全連接。ECC的密鑰長(zhǎng)度增加速度比其他的加密方法都慢(一般按128位增長(zhǎng)，而 RSA則是倍數(shù)增長(zhǎng)，如：1024 –2048--4096)，將延長(zhǎng)您現(xiàn)有硬件的使用壽命，讓您的投資帶來(lái)更大的回報(bào)。

不過(guò)使用ECC證書(shū)有兩個(gè)問(wèn)題需要注意：

1、不是所有類(lèi)型證書(shū)都支持ECC，一般需要商業(yè)證書(shū)的增強(qiáng)版本中才支持

2、一些舊的設(shè)備或?yàn)g覽器不支持ECC，可能需要ECC+RSA雙證書(shū)的模式來(lái)使用

Brotli

Brotli是Google于2015年9月推出的無(wú)損壓縮算法，Brotli通過(guò)變種的LZ77算法、Huffman編碼以及二階文本建模等方式進(jìn)行數(shù)據(jù)壓縮，與其他壓縮算法相比，它有者更高的壓縮效率。

更具Google發(fā)布的報(bào)告指出，Brotli有一下特點(diǎn)：

• 針對(duì)常見(jiàn)的 Web 資源內(nèi)容，Brotli 的性能相比 Gzip 提高了 17-25%；

• 當(dāng) Brotli 壓縮級(jí)別為 1 時(shí)，壓縮率比 Gzip 壓縮等級(jí)為 9（最高）時(shí)還要高；

• 在處理不同 HTML 文檔時(shí)，Brotli 依然能夠提供非常高的壓縮率。

Brotli的支持必須依賴(lài)HTTPS，nginx支持Brotli必須編輯添加brotli模塊

brotli模塊源碼地址https://github.com/eustas/ngx_brotli.git，下載之后，在nginx編譯的時(shí)候通過(guò)編譯參數(shù)--add-module=/path/to/ngx_brotli進(jìn)行編譯添加。添加之后通過(guò)配置文件中添加配置啟用brotli。

在開(kāi)發(fā)者工具中查看headers：

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。