HTTP/2

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

上圖是Akamai的HTTP/2 DEMO，通過加載300張圖片，對比HTTP/1.1和HTTP/2，首先直觀地感受一下HTTP/2，下來解釋一下這個感受的原因，即HTTP/2新特性：

• 二進(jìn)制分幀
• 首部壓縮
• 流量控制
• 多路復(fù)用
• 請求優(yōu)先級
• 服務(wù)器推送

二進(jìn)制分幀

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

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

這里引入一個新的通信單位：幀

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

其中，幀類型可以分為：

• DATA：用于傳輸HTTP消息體
• HEADERS：用于傳輸首部字段
• SETTINGS：用于約定客戶端和服務(wù)端的配置數(shù)據(jù)。比如設(shè)置初識的雙向流量控制窗口大小
• WINDOW_UPDATE：用于調(diào)整個別流或個別連接的流量
• PRIORITY：用于指定或重新指定引用資源的優(yōu)先級
• RST_STREAM：用于通知流的非正常終止
• PUSH_ PROMISE：服務(wù)端推送許可
• PING：用于計算往返時間，執(zhí)行“ 活性” 檢活
• GOAWAY：用于通知對端停止在當(dāng)前連接中創(chuàng)建流

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

下面是抓包的一個HEADERS幀：

另外一個兩個要說一下的概念：消息和流

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

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

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

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

首部壓縮

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

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

流量控制

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

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

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

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

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

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

流量控制不能被禁用。

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

多路復(fù)用

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

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

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

請求優(yōu)先級

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

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

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

服務(wù)器推送

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

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

• PUSH_PROMISE幀是服務(wù)端向客戶端有意推送資源的信號。
• PUSH_PROMISE幀中只包含預(yù)推送資源的首部。如果客戶端對PUSH_PROMISE幀沒有意見，服務(wù)端在PUSH_PROMISE幀后發(fā)送響應(yīng)的DATA幀。如果客戶端已經(jīng)緩存了該資源，不需要推送，可以拒絕PUSH_PROMISE幀。
• PUSH-PROMISE必須遵循請求-響應(yīng)原則，只能借著對請求的響應(yīng)推送資源。
• PUSH_PROMISE幀必須在返回響應(yīng)之前發(fā)送，以免客戶端出現(xiàn)競態(tài)條件（競態(tài)條件是指在多線程的情況下不同的執(zhí)行順序會導(dǎo)致計算機(jī)執(zhí)行出不同的結(jié)果正確性不同）
• HTTP2.0連接后，客戶端與服務(wù)端交換SETTINGS幀，借此限定雙向并發(fā)的最大數(shù)量。因此，客戶端可以限定推送流的數(shù)量，或者通過把這個只設(shè)置為0來完全禁止服務(wù)器推送。
• 所有推送的資源都必須遵守同源策略。換句話說，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方的確認(rèn)才行。

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

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

怎么測試http2是否已開啟，方法很多，這里介紹三種方法：

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

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

3、命令行客戶端nghttp

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

通過http2_push指令配置

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

自動將資源推送給客戶端

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

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

測試如下：

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

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

• 相比過去的的版本，引入了新的密鑰協(xié)商機(jī)制 — PSK
• 支持 0-RTT 數(shù)據(jù)傳輸，在建立連接時節(jié)省了往返時間
• 廢棄了 3DES、RC4、AES-CBC 等加密組件，廢棄了 SHA1、MD5 等哈希算法
• ServerHello 之后的所有握手消息采取了加密操作，可見明文大大減少
• 不再允許對加密報文進(jìn)行壓縮、不再允許雙方發(fā)起重協(xié)商
• DSA 證書不再允許在 TLS 1.3 中使用

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

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

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

默認(rèn)情況下nginx因為安全原因，沒有開啟TLS 1.3的 0-RTT，可以通過指令ssl_early_data on來開啟。

ECC

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

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

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

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

• 更適合于移動互聯(lián)網(wǎng)：ECC加密算法的密鑰長度很短(256位)，意味著占用更少的存儲空間，更低的CPU開銷和占用更少的帶寬。隨著越來越多的用戶使用移動設(shè)備來完成各種網(wǎng)上活動，ECC加密算法為移動互聯(lián)網(wǎng)安全提供更好的客戶體驗。
• 更好的安全性：ECC加密算法提供更強(qiáng)的保護(hù)，比目前的其他加密算法能更好的防止攻擊，使你的網(wǎng)站和基礎(chǔ)設(shè)施比用傳統(tǒng)的加密方法更安全，為移動互聯(lián)網(wǎng)安全提供更好的保障。
• 更好的性能：ECC加密算法需要較短的密鑰長度來提供更好的安全，例如，256位的ECC密鑰加密強(qiáng)度等同于3072位RSA密鑰的水平(目前普通使用的RSA密鑰長度是2048位)。其結(jié)果是你以更低的計算能力代價得到了更高的安全性。經(jīng)國外有關(guān)權(quán)威機(jī)構(gòu)測試，在Apache和IIS服務(wù)器采用ECC算法，Web服務(wù)器響應(yīng)時間比RSA快十幾倍。
• 更大的IT投資回報：ECC可幫助保護(hù)您的基礎(chǔ)設(shè)施的投資，提供更高的安全性，并快速處理爆炸增長的移動設(shè)備的安全連接。ECC的密鑰長度增加速度比其他的加密方法都慢(一般按128位增長，而 RSA則是倍數(shù)增長，如：1024 –2048--4096)，將延長您現(xiàn)有硬件的使用壽命，讓您的投資帶來更大的回報。

不過使用ECC證書有兩個問題需要注意：

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

2、一些舊的設(shè)備或瀏覽器不支持ECC，可能需要ECC+RSA雙證書的模式來使用

Brotli

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

更具Google發(fā)布的報告指出，Brotli有一下特點：

• 針對常見的 Web 資源內(nèi)容，Brotli 的性能相比 Gzip 提高了 17-25%；
• 當(dāng) Brotli 壓縮級別為 1 時，壓縮率比 Gzip 壓縮等級為 9（最高）時還要高；
• 在處理不同 HTML 文檔時，Brotli 依然能夠提供非常高的壓縮率。

Brotli的支持必須依賴HTTPS，nginx支持Brotli必須編輯添加brotli模塊

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

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

趕快優(yōu)化一下你的HTTPS吧！