HTTP/2 相比於 HTTP/1.1，可以說是大幅度提高了網頁的性能，只需要升級到該協議就可以減少很多之前需要做的性能優化工作。當然，兼容問題以及如何優雅降級應該是國內還不普遍使用的原因之一。雖然 HTTP/2 提高了網頁的性能，但並不代表它已經完美，HTTP/3 就是為了解決 HTTP/2 存在的一些問題而被推出的。
HTTP/1.1 發明以來發生了哪些變化？
如果仔細觀察打開那些最流行的網站首頁所需要下載的資源的話，會發現一個非常明顯的趨勢。近年來，加載網站首頁需要的下載的數據量在逐漸增加，並已經超過了 2100K。但在這裡我們更應該關心的是：平均每個頁面為了完成顯示與渲染所需要下載的資源數已經超過了 100 個。
正如下圖所示，從 2011 年以來, 傳輸數據大小與平均請求資源數量不斷持續增長，並沒有減緩的跡象。該圖表中，綠色直線展示了傳輸數據大小的增長，紅色直線展示了平均請求資源數量的增長。
HTTP/1.1 自從 1997 年發佈以來，我們已經使用 HTTP/1.x 相當長一段時間了，但是隨著近十年互聯網的爆炸式發展，從當初網頁內容以文本為主, 到現在以富媒體（如圖片、聲音、視頻）為主, 而且對頁面內容實時性要求高的應用越來越多 （如聊天、視頻直播）, 於是當時協議規定的某些特性，已經無法滿足現代網絡的需求了。
HTTP/1.1 的缺陷
1. 高延遲 – 帶來頁面加載速度的降低
雖然近幾年來網絡帶寬增長非常快，然而我們卻並沒有看到網絡延遲有對應程度的降低。網絡延遲問題主要由於隊頭阻塞 (Head-Of-Line Blocking) 產生，導致帶寬無法被充分利用。
隊頭阻塞是指，當順序發送的請求序列中的一個請求因為某種原因被阻塞時，在後面排隊的所有請求也一併被阻塞，會導致客戶端遲遲收不到數據。針對隊頭阻塞, 人們嘗試過以下辦法來解決：
- 將同一頁面的資源分散到不同域名下，提升連接上限。Chrome 有個機制，對於同一個域名，默認允許同時建立 6 個 TCP 持久連接。使用持久連接時，雖然能共用一個 TCP 管道，但是在一個管道中同一時刻只能處理一個請求，在當前的請求沒有結束之前，其他的請求只能處於阻塞狀態。另外，如果在同一個域名下同時有 10 個請求發生，那麼其中 4 個請求會進入排隊等待狀態，直至進行中的請求完成。
- Spriting 合併多張小圖為一張大圖, 再用 JavaScript 或者 CSS 將小圖重新“切割”出來的技術。
- 內聯 (Inlining) 是另一種防止發送很多小圖請求的技巧，將圖片的原始數據嵌入在 CSS 文件裡面的 URL 裡，減少網絡請求次數。
.icon1 {
background: url(data:image/png;base64,<data>) no-repeat;
}
.icon2 {
background: url(data:image/png;base64,<data>) no-repeat;
}
/<data>/<data>- 拼接 (Concatenation) 將多個體積較小的 JavaScript 使用 webpack 等工具打包成 1 個體積更大的 JavaScript 文件, 但如果其中 1 個文件改動，會導致大量數據被重新下載多個文件。
2. 無狀態特性 – 帶來巨大的 HTTP 頭部
由於報文 Header 一般會攜帶 "User Agent" “Cookie”“Accept”"Server" 等許多固定的頭字段（如下圖），多達幾百字節甚至上千字節，但 Body 卻經常只有幾十字節（比如 GET 請求、 204/301/304 響應），成了不折不扣的“大頭兒子”。Header 裡攜帶的內容過大，在一定程度上增加了傳輸成本。更要命的是，成千上萬的請求響應報文裡有很多字段值都是重複的，非常浪費。
3. 明文傳輸 – 帶來不安全性
HTTP/1.1 在傳輸數據時，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份，這在一定程度上無法保證數據的安全性。
你有沒有聽說過 " 免費 WiFi 陷阱”之類的新聞呢？黑客就是利用了 HTTP 明文傳輸的缺點，在公共場所架設一個 WiFi 熱點開始“釣魚”，誘騙網民上網。一旦你連上了這個 WiFi 熱點，所有的流量都會被截獲保存，裡面如果有銀行卡號、網站密碼等敏感信息的話那就危險了，黑客拿到了這些數據就可以冒充你，為所欲為。
4. 不支持服務器推送消息
SPDY 協議與 HTTP/2 簡介
1.SPDY 協議
上面我們提到, 由於 HTTP/1.x 的缺陷，我們會引入雪碧圖、將小圖內聯、使用多個域名等方式來提高性能，不過這些優化都繞開了協議。直到 2009 年，谷歌公開了自行研發的 SPDY 協議，主要解決 HTTP/1.1 效率不高的問題。谷歌推出 SPDY，才算是正式改造 HTTP 協議本身。降低延遲，壓縮 header 等等，SPDY 的實踐證明了這些優化的效果，也最終帶來 HTTP/2 的誕生。
HTTP/1.1 有兩個主要的缺點：安全不足和性能不高。由於揹負著 HTTP/1.x 龐大的歷史包袱, 所以協議的修改, 兼容性是首要考慮的目標，否則就會破壞互聯網上無數現有的資產。如上圖所示, SPDY 位於 HTTP 之下，TCP 和 SSL 之上，這樣可以輕鬆兼容老版本的 HTTP 協議 (將 HTTP1.x 的內容封裝成一種新的 frame 格式)，同時可以使用已有的 SSL 功能。
SPDY 協議在 Chrome 瀏覽器上證明可行以後，就被當作 HTTP/2 的基礎，主要特性都在 HTTP/2 中得到繼承。
2.HTTP/2 簡介
2015 年，HTTP/2 發佈。HTTP/2 是現行 HTTP 協議（HTTP/1.x）的替代，但它不是重寫，HTTP 方法 / 狀態碼 / 語義都與 HTTP/1.x 一樣。HTTP/2 基於 SPDY，專注於性能，最大的目標是在用戶和網站間只用一個連接（connec-tion）。從目前的情況來看，國內外一些排名靠前的站點基本都實現了 HTTP/2 的部署，使用 HTTP/2 能帶來 20%~60% 的效率提升。
HTTP/2 由兩個規範（Specification）組成：
- Hypertext Transfer Protocol version 2 - RFC7540
- HPACK - Header Compression for HTTP/2 - RFC7541
HTTP/2 新特性
1. 二進制傳輸
HTTP/2 傳輸數據量的大幅減少, 主要有兩個原因: 以二進制方式傳輸和 Header 壓縮。我們先來介紹二進制傳輸，HTTP/2 採用二進制格式傳輸數據，而非 HTTP/1.x 裡純文本形式的報文 ，二進制協議解析起來更高效。HTTP/2 將請求和響應數據分割為更小的幀，並且它們採用二進制編碼 。
它把 TCP 協議的部分特性挪到了應用層，把原來的 "Header+Body" 的消息 " 打散 " 為數個小片的二進制 " 幀 "(Frame), 用 "HEADERS" 幀存放頭數據、"DATA" 幀存放實體數據。HTTP/2 數據分幀後，“Header+Body" 的報文結構就完全消失了，協議看到的只是一個個 " 碎片”。
HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數量的雙向數據流。每個數據流都以消息的形式發送，而消息又由一個或多個幀組成。多個幀之間可以亂序發送，根據幀首部的流標識可以重新組裝 。
2.Header 壓縮
HTTP/2 並沒有使用傳統的壓縮算法，而是開發了專門的 "HPACK”算法，在客戶端和服務器兩端建立“字典”，用索引號表示重複的字符串，還採用哈夫曼編碼來壓縮整數和字符串，可以達到 50%~90% 的高壓縮率。
具體來說：
- 在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發送的鍵 - 值對，對於相同的數據，不再通過每次請求和響應發送。
- 首部表在 HTTP/2 的連接存續期內始終存在，由客戶端和服務器共同漸進地更新 。
- 每個新的首部鍵 - 值對要麼被追加到當前表的末尾，要麼替換表中之前的值。
例如下圖中的兩個請求， 請求一發送了所有的頭部字段，第二個請求則只需要發送差異數據，這樣可以減少冗餘數據，降低開銷 。
3. 多路複用
在 HTTP/2 中引入了多路複用的技術。多路複用很好地解決了瀏覽器限制同一個域名下請求數量的問題，同時也更容易實現全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。
大家可以通過該鏈接直觀感受下 HTTP/2 比 HTTP/1 到底快了多少: https://http2.akamai.com/demo
在 HTTP/2 中，有了二進制分幀之後，HTTP /2 不再依賴 TCP 鏈接去實現多流並行了，在 HTTP/2 中：
- 同域名下所有通信都在單個連接上完成。
- 單個連接可以承載任意數量的雙向數據流。
- 數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間可以亂序發送，因為根據幀首部的流標識可以重新組裝。
這一特性使性能有了極大提升：
- 同個域名只需要佔用一個 TCP 連接，使用一個連接並行發送多個請求和響應, 這樣整個頁面資源的下載過程只需要一次慢啟動，同時也避免了多個 TCP 連接競爭帶寬所帶來的問題。
- 並行交錯地發送多個請求 / 響應，請求 / 響應之間互不影響。
- 在 HTTP/2 中，每個請求都可以帶一個 31bit 的優先值，0 表示最高優先級， 數值越大優先級越低。有了這個優先值，客戶端和服務器就可以在處理不同的流時採取不同的策略，以最優的方式發送流、消息和幀。
如上圖所示，多路複用的技術只通過一個 TCP 連接就可以傳輸所有的請求數據。
4.Server Push
HTTP2 還在一定程度上改變了傳統的“請求 - 應答”工作模式，服務器不再完全被動地響應請求，也可以新建“流”主動向客戶端發送消息。比如，在瀏覽器剛請求 HTML 的時候就提前把可能會用到的 JS、CSS 文件發給客戶端，減少等待的延遲，這被稱為 " 服務器推送 "（ Server Push，也叫 Cache push）。
如下圖所示，服務端主動把 JS 和 CSS 文件推送給客戶端，而不需要客戶端解析 HTML 時再發送這些請求。
另外需要補充的是，服務端可以主動推送，客戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器緩存過，瀏覽器可以通過發送 RST_STREAM 幀來拒收。主動推送也遵守同源策略。換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是經過雙方確認才行。
5. 提高安全性
出於兼容的考慮，HTTP/2 延續了 HTTP/1 的“明文”特點，可以像以前一樣使用明文傳輸數據，不強制使用加密通信，不過格式還是二進制，只是不需要解密。
但由於 HTTPS 已經是大勢所趨，而且主流的瀏覽器 Chrome、Firefox 等都公開宣佈只支持加密的 HTTP/2，所以“事實上”的 HTTP/2 是加密的。也就是說，互聯網上通常所能見到的 HTTP/2 都是使用 "https”協議名，跑在 TLS 上面。HTTP/2 協議定義了兩個字符串標識符：“h2" 表示加密的 HTTP/2，“h2c”表示明文的 HTTP/2。
HTTP/3 新特性
1.HTTP/2 的缺點
雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，主要是底層支撐的 TCP 協議造成的。HTTP/2 的缺點主要有以下幾點：
- TCP 和 TCP+TLS 建立連接的延時
HTTP/2 是使用 TCP 協議來傳輸的。如果使用 HTTPS 的話，還需要使用 TLS 協議進行安全傳輸，而使用 TLS 也需要一個握手過程，這樣就需要有兩個握手延遲過程：
①在建立 TCP 連接的時候，需要和服務器進行三次握手來確認連接成功，也就是說需要在消耗完 1.5 個 RTT 之後才能進行數據傳輸。
②進行 TLS 連接，TLS 有兩個版本——TLS1.2 和 TLS1.3，每個版本建立連接所花的時間不同，大致是需要 1~2 個 RTT。
總之，在傳輸數據之前，我們需要花掉 3～4 個 RTT。
- TCP 的隊頭阻塞並沒有徹底解決
上文我們提到在 HTTP/2 中，多個請求是跑在一個 TCP 管道中的。但當出現了丟包時，HTTP/2 的表現反倒不如 HTTP/1 了。因為 TCP 為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，HTTP/2 出現丟包時，整個 TCP 都要開始等待重傳，那麼就會阻塞該 TCP 連接中的所有請求（如下圖）。而對於 HTTP/1.1 來說，可以開啟多個 TCP 連接，出現這種情況反倒只會影響其中一個連接，剩餘的 TCP 連接還可以正常傳輸數據。
讀到這裡，可能就會有人考慮為什麼不直接去修改 TCP 協議？其實這已經是一件不可能完成的任務了。因為 TCP 存在的時間實在太長，已經充斥在各種設備中，並且這個協議是由操作系統實現的，更新起來不大現實。
2.HTTP/3 簡介
Google 在推 SPDY 的時候就已經意識到了這些問題，於是就另起爐灶搞了一個基於 UDP 協議的“QUIC”協議，讓 HTTP 跑在 QUIC 上而不是 TCP 上。而這個“HTTP over QUIC”就是 HTTP 協議的下一個大版本，HTTP/3。它在 HTTP/2 的基礎上又實現了質的飛躍，真正“完美”地解決了“隊頭阻塞”問題。
QUIC 雖然基於 UDP，但是在原本的基礎上新增了很多功能，接下來我們重點介紹幾個 QUIC 新功能。不過 HTTP/3 目前還處於草案階段，正式發佈前可能會有變動，所以本文儘量不涉及那些不穩定的細節。
3.QUIC 新功能
上面我們提到 QUIC 基於 UDP，而 UDP 是“無連接”的，根本就不需要“握手”和“揮手”，所以就比 TCP 來得快。此外，QUIC 也實現了可靠傳輸，保證數據一定能夠抵達目的地。它還引入了類似 HTTP/2 的“流”和“多路複用”，單個“流 " 是有序的，可能會因為丟包而阻塞，但其他“流”不會受到影響。具體來說，QUIC 協議有以下特點：
- 實現了類似 TCP 的流量控制、傳輸可靠性的功能。
雖然 UDP 不提供可靠性的傳輸，但 QUIC 在 UDP 的基礎之上增加了一層來保證數據可靠性傳輸。它提供了數據包重傳、擁塞控制以及其他一些 TCP 中存在的特性。
- 實現了快速握手功能。
由於 QUIC 是基於 UDP 的，所以 QUIC 可以實現使用 0-RTT 或者 1-RTT 來建立連接，這意味著 QUIC 可以用最快的速度來發送和接收數據，這樣可以大大提升首次打開頁面的速度。0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優勢。
- 集成了 TLS 加密功能。
目前 QUIC 使用的是 TLS1.3，相較於早期版本 TLS1.3 有更多的優點，其中最重要的一點是減少了握手所花費的 RTT 個數。
- 多路複用，徹底解決 TCP 中隊頭阻塞的問題。
和 TCP 不同，QUIC 實現了在同一物理連接上可以有多個獨立的邏輯數據流（如下圖）。實現了數據流的單獨傳輸，就解決了 TCP 中隊頭阻塞的問題。
總結
- HTTP/1.1 有兩個主要的缺點：安全不足和性能不高。
- HTTP/2 完全兼容 HTTP/1，是“更安全的 HTTP、更快的 HTTPS"，頭部壓縮、多路複用等技術可以充分利用帶寬，降低延遲，從而大幅度提高上網體驗。
- QUIC 基於 UDP 實現，是 HTTP/3 中的底層支撐協議。該協議基於 UDP，又汲取了 TCP 中的精華，實現了既快又可靠的協議。
本文轉載自微信公眾號：前端工匠
閱讀更多 北漂日誌 的文章
