从理论到实践，全方位认识HTTP/2
為了降低加載時間，相信大多數人都做過如下嘗試
- Keep-alive: TCP持久連接，增加了TCP連接的復用性，但只有當上一個請求/響應完全完成后，client才能發送下一個請求
- Pipelining: 可同時發送多個請求，但是服務器必須嚴格按照請求的先后順序返回響應，若第一個請求的響應遲遲不能返回，那后面的響應都會被阻塞，也就是所謂的隊頭阻塞
- 請求合并：雪碧圖，css/js內聯、css/js合并等，然而請求合并又會帶來緩存失效、解析變慢、阻塞渲染、木桶效應等諸多問題
- 域名散列：繞過了同域名最多6個TCP的限制，但增加了DNS開銷和TCP開銷，也會大幅降低緩存的利用率
- ……
不可否認，這些優化在一定程度上降低了網站加載時間，但對于一個web應用龐大的請求量來說，這些只是冰上一角、隔靴搔癢。
以上問題歸根結底是HTTP1.1協議本身的問題，若要從根本上解決HTTP1.1的低效，只能從協議本身入手。為此Google開發了SPDY協議，主要是為了降低傳輸時間；基于SPDY協議，IETF和SPDY組全體成員共同開發了HTTP/2，并在2015年5月以RFC 7504正式發表。SPDY或者HTTP/2并不是一個全新的協議，它只是修改了HTTP的請求與應答在網絡上的傳輸方式，增加了一個spdy傳輸層，用于處理、標記、簡化和壓縮HTTP請求，所以它們并不會破壞現有程序的工作，對于支持的場景，使用新特性可以獲得更快的速度，對于不支持的場景，也可以實現平穩退化。
HTTP/2繼承了spdy的多路復用、優先級排序等諸多優秀特性，也額外做了不少改進。其中較為顯著的改進是HTTP/2使用了一份經過定制的壓縮算法，以此替代了SPDY的動態流壓縮算法，用于避免對協議的Oracle攻擊。
多數主流瀏覽器已在2015年底支持了該標準（劃重點）。具體支持度如下：
數據來源
可以看到國內有58.55%的瀏覽器已經完全支持HTTP/2，而全球的支持度更是高達85.66%。這么高的支持度，so，你心動了嗎
why HTTP/2
二進制格式傳輸
我們知道HTTP/1.1的頭信息肯定是文本（ASCII編碼），數據體可以是文本，也可以是二進制（需要做自己做額外的轉換，協議本身并不會轉換）。而在HTTP/2中，新增了二進制分幀層，將數據轉換成二進制，也就是說HTTP/2中所有的內容都是采用二進制傳輸。
使用二進制有什么好處嗎？當然！效率會更高，而且最主要的是可以定義額外的幀，如果用文本實現幀傳輸，解析起來將會十分麻煩。HTTP/2共定義了十種幀，較為常見的有數據幀、頭部幀、PING幀、SETTING幀、優先級幀和PUSH_PROMISE幀等，為將來的高級應用打好了基礎。
如上圖，Binary Framing就是新增的二進制分幀層。
多路復用
二進制分幀層把數據轉換為二進制的同時，也把數據分成了一個一個的幀。幀是HTTP/2中數據傳輸的最小單位；每個幀都有stream_ID字段，表示這個幀屬于哪個流，接收方把stream_ID相同的所有幀組合到一起就是被傳輸的內容了。而流是HTTP/2中的一個邏輯上的概念，它代表著HTTP/1.1中的一個請求或者一個響應，協議規定client發給server的流的stream_ID為奇數，server發給client的流ID是偶數。需要注意的是，流只是一個邏輯概念，便于理解和記憶的，實際并不存在。
理解了幀和流的概念，完整的HTTP/2的通信就可以被形象地表示為這樣：
?
可以發現，在一個TCP鏈接中，可以同時雙向地發送幀，而且不同流中的幀可以交錯發送，不需要等某個流發送完，才發送下一個。也就是說在一個TCP連接中，可以同時傳輸多個流，即可以同時傳輸多個HTTP請求和響應，這種同時傳輸不需要遵循先入先出等規定，因此也不會產生阻塞，效率極高。
在這種傳輸模式下，HTTP請求變得十分廉價，我們不需要再時刻顧慮網站的http請求數是否太多、TCP連接數是否太多、是否會產生阻塞等問題了。
HPACK 首部壓縮
為什么需要壓縮？
在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成。一般而言，消息主體都會經過 gzip 壓縮，或者本身傳輸的就是壓縮過后的二進制文件（例如圖片、音頻），但狀態行和頭部卻沒有經過任何壓縮，直接以純文本傳輸。
隨著 Web 功能越來越復雜，每個頁面產生的請求數也越來越多，根據 HTTP Archive 的統計，當前平均每個頁面都會產生上百個請求。越來越多的請求導致消耗在頭部的流量越來越多，尤其是每次都要傳輸 UserAgent、Cookie 這類不會頻繁變動的內容，完全是一種浪費。
為了減少冗余的頭部信息帶來的消耗，HTTP/2采用HPACK 算法壓縮請求和響應的header。下面這張圖非常直觀地表達了HPACK頭部壓縮的原理：
圖片來源: Velocity 2015 ? SC 會議分享
具體規則可以描述為：
- 通信雙方共同維護了一份靜態表，包含了常見的頭部名稱與值的組合
- 根據先入先出的原則，維護一份可動態添加內容的動態表
- 用基于該靜態哈夫曼碼表的哈夫曼編碼數據
當要發送一個請求時，會先將其頭部和靜態表對照，對于完全匹配的鍵值對，可以直接使用一個數字表示，如上圖中的2：method: GET，對于頭部名稱匹配的鍵值對，可以將名稱使用一個數字傳輸，如上圖中的19：path: /resource，同時告訴服務端將它添加到動態表中，以后的相同鍵值對就用一個數字表示了。這樣，像cookie這些不經常變動的值，只用發送一次就好了。
server push
在開始HTTP/2 server push 前，我們先來看看一個HTTP/1.1的頁面是如何加載的。
<!DOCTYPE html>
<html>
<head>
? <link rel="stylesheet" href="style.css">
? <script src="user.js"></script>
</head>
<body>
? <h1>hello http2</h1>
</body>
</html>
至此，這個頁面才加載完畢，可以被用戶看到。可以發現在步驟3和4中，服務器一直處于空閑等待狀態，而瀏覽器到第6步才能得到資源渲染頁面，這使頁面的首次加載變得緩慢。
而HTTP/2的server push允許服務器在未收到請求時就向瀏覽器推送資源。即服務器發送/user.html后，就可以主動把/user.js和style.csspush給瀏覽器，使資源提前達到瀏覽器。這也是HTTP/2協議里面唯一一個需要開發者自己配置的功能。其他功能都是服務器和瀏覽器自動實現，無需開發者介入。
在HTTP1.1時代，也有提前獲取資源的方法，如preload和prefetch，前者是在頁面解析初期就告訴瀏覽器，這個資源是瀏覽器馬上要用到的，可以立刻發送對資源的請求，當需要用到該資源時就可以直接用而不用等待請求和響應的返回了；后者是當前頁面用不到但下一頁面可能會用到的資源，優先級較低，只有當瀏覽器空閑時才會請求prefetch標記的資源。從應用層面上看，preload和server push并沒有什么區別，但是server push減少瀏覽器請求的時間，略優于preload，在一些場景中，可以將兩者結合使用。
實戰
紙上談兵終覺淺，來實踐一下吧！親手搭建自己的 HTTP/2 demo，并抓包驗證。
spdy這個庫實現了 HTTP/2，同時也提供了對express的支持，所以這里我選用spdy + express搭建demo。demo源碼
路徑說明：
- ca/? 證書、秘鑰等文件
- src/
??? - img/
??? - js/
??? - page1.html
- server.js
HTTPS 秘鑰和證書
雖然HTTP/2有加密(h2)和非加密(h2c)兩種形式，但大多主流瀏覽器只支持h2-基于TLS/1.2或以上版本的加密連接，所以在搭建demo前，我們首先要自頒發一個證書，這樣就可以在瀏覽器訪問中使用https了，你可以自行搜索證書頒發方法，也可以按照下述步驟去生成
首先要安裝open-ssl，然后執行以下命令
$ openssl genrsa -des3 -passout pass:x -out server.pass.key 2048
....
$ openssl rsa -passin pass:x -in server.pass.key -out server.key
writing RSA key
$ rm server.pass.key
?
$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
....
$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
然后你就會得到三個文件server.crt,?server.csr,?server.key，將它們拷貝到ca文件夾中，稍后會用到。
搭建HTTP/2服務
express是一個Node.js框架，這里我們用它聲明了路由/，返回的html文件page1.html中引用了js和圖片等靜態資源。
// server.js
const http2 = require('spdy')
const express = require('express')
const app = express()
const publicPath = 'src'
?
app.use(express.static(publicPath))
?
app.get('/', function (req, res) {
??? res.setHeader('Content-Type', 'text/html')
??? res.sendFile(__dirname + '/src/page1.html')
})
?
var options = {
??? key: fs.readFileSync('./ca/server.key'),
??? cert: fs.readFileSync('./ca/server.crt')
}
http2.createServer(options, app).listen(8080, () => {
??? console.log(`Server is listening on https://127.0.0.1:8080 .`)
})
用瀏覽器訪問https://127.0.0.1:8080/，打開控制臺可以看所有的請求和它們的瀑布圖:
可以清楚地看到，當第一個請求，也就是對document的請求完全返回并解析后，瀏覽器才開始發起對js和圖片等靜態資源的的請求。前面說過，server push允許服務器主動向瀏覽器推送資源，那么是否可以在第一個請求未完成時，就把接下來所需的js和img推送給瀏覽器呢？這樣不僅充分利用了HTTP/2的多路復用，還減少了服務器的空閑等待時間。
對路由的處理函數進行改造：
app.get('/', function (req, res) {
+?? push('/img/yunxin1.png', res, 'image/png')
+?? push('/img/yunxin2.png', res, 'image/png')
+?? push('/js/log3.js', res, 'application/javascript')
??? res.setHeader('Content-Type', 'text/html')
??? res.sendFile(__dirname + '/src/page1.html')
})
?
function push (reqPath, target, type) {
??? let content = fs.readFileSync(path.join(__dirname, publicPath, reqPath))
??? let stream = target.push(reqPath, {
??????? status: 200,
??????? method: 'GET',
??????? request: { accept: '*/*' },
??????? response: {
??????????? 'content-type': type
??????? }
??? })
??? stream.on('error', function() {})
??? stream.end(content)
}
來看下應用了server push的瀑布圖：
很明顯，被push的靜態資源可以很快地被使用，而沒有被push的資源，如log1.js和log2.js則需要經過較長的時間才能被使用。
瀏覽器控制臺看到的東西畢竟很有限，我們來玩點更有意思的~
wireshark 抓包驗證
wireshark是一款可以識別HTTP/2的抓包工具，它的原理是直接讀取并分析網卡數據，我們用它來驗證是否真正實現了HTTP/2以及其底層通信原理。
首先去官網下載安裝包并安裝wireshark，這一步沒啥好說的。
我們知道，http/2里的請求和響應都被拆分成了幀，如果我們直接去抓取HTTP/2通信包，那抓到的只能是一幀一幀地數據，像這樣：
可以看到，抓到的都是TCP類型的包（紅色方框）；觀察前三個包的內容（綠色方框），分別是SYN、[SYN, ACK]和ACK，這就我們所熟知的TCP三次握手；右下角的黃色小方框是請求當前頁面后抓到的TCP包的總數，其實這個頁面只有七八個請求，但抓到的包的數量卻有334個，這也驗證了HTTP/2的請求和響應的確是被分成了一幀一幀的。
抓HTTP1.1的包，我們可以清楚地看到都有哪些請求和響應，它們的協議、大小等，而HTTP/2的數據包卻是一幀一幀地，那么怎么看HTTP/2都有哪些請求和響應呢？其實wireshark會自動幫我們重組擁有相同stream_ID的幀，重組后就可看到實際有哪些請求和響應了，但是因為我們用的是https，所有的數據都被加密了，wireshark就不知道該怎么去重組了。
有兩個辦法可以在wireshark中解密 HTTPS 流量：第一如果你擁有 HTTPS 網站的加密私鑰，可以用加密私鑰來解密這個網站的加密流量；2）某些瀏覽器支持將 TLS 會話中使用的對稱密鑰保存在外部文件中，可供 Wireshark 解密使用。
但是HTTP/2為了前向安全性，不允許使用RAS秘鑰交換，所有我們無法使用第一個方法來解密HTTP/2流量。介紹第二種方法：當系統環境變量中存在SSLKEYFILELOG時，Chrome和firefox會將對稱秘鑰保存在該環境變量指向的文件中，然后把這個文件導入wireshark，就可以解密HTTP/2流量了，具體做法如下：
這時用Chrome或Firefox訪問任何一個https頁面，ssl.log中應該就有寫入的秘鑰數據了。
解密完成后，我們就可以看到HTTP/2的包了
下圖是在demo的主頁面抓取的包，可以清楚地看到有哪些HTTP/2請求。
HTTP/2協議中的流和可以在一個TCP連接中交錯傳輸，只需建立一個TCP連接就可以完成和服務器的所有通信，我們來看下在demo中的HTTP/2是不是這樣的：
wireshark下方還有一個面板，里面有當前包的具體信息，如大小、源IP、目的IP、端口、數據、協議等，在Transmission Control Protocol下有一個[Stream index]，如下圖，它是TCP連接的編號，代表當前包是從哪個TCP連接中傳輸的。觀察demo頁面請求產生的包，可以發現它們的stream index 都相同，說明這些HTTP/2請求和響應是在一個TCP連接中被傳輸的，這么多流的確復用了一個TCP連接。
除了多路復用外，我們還可以通過抓包來觀察HTTP/2的頭部壓縮。下圖是當前路由下的第一個請求，實際被傳輸的頭部數據有253bytes，解壓后的頭部信息有482bytes。壓縮后的大小減少了幾乎一半
但這只是第一個請求，我們看看后來的請求，如第三個，實際傳輸的頭部大小只有30bytes，而解壓后的大小有441byte，壓縮后的體積僅為原來的1/14！如今web應用單是一個頁面就動輒幾百的請求數，HPACK能節約的流量可想而知。?
在文章開篇，我們列舉了HTTP1.x時代的困境，引入并簡要說明了HTTP/2的起源；然后對比著HTTP1.x，介紹了HTTP/2的諸多優秀特性，來說明為什么選擇HTTP/2；在文章的最后一部分，介紹了如何一步一步搭建一個HTTP/2實例，并抓包觀察，驗證了HTTP/2的多路復用，頭部壓縮等特性。最后，您是否也被這些高效特性吸引了呢？動手試試吧~
參考：
- HTTP/2 維基百科
- w3c-preload
- HTTP/2 Server Push with Node.js
- 使用 Wireshark 調試 HTTP/2 流量
- Optimize Your App with HTTP/2 Server Push Using Node and Express
- web性能優化與HTTP/2
?
想要技術干貨、行業洞察，歡迎關注網易云信博客。
了解網易云信，來自網易核心架構的通信與視頻云服務。
網易云信（NeteaseYunXin）是集網易18年IM以及音視頻技術打造的PaaS服務產品，來自網易核心技術架構的通信與視頻云服務，穩定易用且功能全面，致力于提供全球領先的技術能力和場景化解決方案。開發者通過集成客戶端SDK和云端OPEN API，即可快速實現包含IM、音視頻通話、直播、點播、互動白板、短信等功能。
總結
以上是生活随笔為你收集整理的从理论到实践，全方位认识HTTP/2的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 互联网1分钟 | 0121 Vlog陌生
- 下一篇： HDR视频生态圈追踪