[TOC] # HTTP/2 HTTP/2 相比于 HTTP/1，可以說是大幅度提高了網頁的性能。 在 HTTP/1 中，為了性能考慮，我們會引入雪碧圖、將小圖內聯、使用多個域名等等的方式。這一切都是因為瀏覽器限制了同一個域名下的請求數量（Chrome 下一般是限制六個連接），當頁面中需要請求很多資源的時候，隊頭阻塞（Head of line blocking）會導致在達到最大請求數量時，剩余的資源需要等待其他資源請求完成后才能發起請求。 在 HTTP/2 中引入了多路復用的技術，這個技術可以只通過一個 TCP 連接就可以傳輸所有的請求數據。多路復用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，同時也接更容易實現全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。 大家可以通過[該鏈接](https://link.juejin.im/?target=https%3A%2F%2Fhttp2.akamai.com%2Fdemo)感受下 HTTP/2 比 HTTP/1 到底快了多少。  在 HTTP/1 中，因為隊頭阻塞的原因，你會發現發送請求是長這樣的  在 HTTP/2 中，因為可以復用同一個 TCP 連接，你會發現發送請求是長這樣的  ## 二進制傳輸 HTTP/2 中所有加強性能的核心點在于此。在之前的 HTTP 版本中，我們是通過文本的方式傳輸數據。在 HTTP/2 中引入了新的編碼機制，所有傳輸的數據都會被分割，并采用二進制格式編碼。  ## 多路復用 在 HTTP/2 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。 幀代表著最小的數據單位，每個幀會標識出該幀屬于哪個流，流也就是多個幀組成的數據流。 多路復用，就是在一個 TCP 連接中可以存在多條流。換句話說，也就是可以發送多個請求，對端可以通過幀中的標識知道屬于哪個請求。通過這個技術，可以避免 HTTP 舊版本中的隊頭阻塞問題，極大的提高傳輸性能。  ## Header 壓縮 在 HTTP/1 中，我們使用文本的形式傳輸 header，在 header 攜帶 cookie 的情況下，可能每次都需要重復傳輸幾百到幾千的字節。 在 HTTP /2 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小。并在兩端維護了索引表，用于記錄出現過的 header ，后面在傳輸過程中就可以傳輸已經記錄過的 header 的鍵名，對端收到數據后就可以通過鍵名找到對應的值。 ## 服務端 Push 在 HTTP/2 中，服務端可以在客戶端某個請求后，主動推送其他資源。 可以想象以下情況，某些資源客戶端是一定會請求的，這時就可以采取服務端 push 的技術，提前給客戶端推送必要的資源，這樣就可以相對減少一點延遲時間。當然在瀏覽器兼容的情況下你也可以使用 prefetch 。 # HTTP/3 雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，雖然這個問題并不是它本身造成的，而是底層支撐的 TCP 協議的問題。 因為 HTTP/2 使用了多路復用，一般來說同一域名下只需要使用一個 TCP 連接。當這個連接中出現了丟包的情況，那就會導致 HTTP/2 的表現情況反倒不如 HTTP/1 了。 因為在出現丟包的情況下，整個 TCP 都要開始等待重傳，也就導致了后面的所有數據都被阻塞了。但是對于 HTTP/1 來說，可以開啟多個 TCP 連接，出現這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數據。 那么可能就會有人考慮到去修改 TCP 協議，其實這已經是一件不可能完成的任務了。因為 TCP 存在的時間實在太長，已經充斥在各種設備中，并且這個協議是由操作系統實現的，更新起來不大現實。 基于這個原因，Google 就更起爐灶搞了一個基于 UDP 協議的 QUIC 協議，并且使用在了 HTTP/3 上，當然 HTTP/3 之前名為 HTTP-over-QUIC，從這個名字中我們也可以發現，HTTP/3 最大的改造就是使用了 QUIC，接下來我們就來學習關于這個協議的內容。 ## QUIC 之前我們學習過 UDP 協議的內容，知道這個協議雖然效率很高，但是并不是那么的可靠。QUIC 雖然基于 UDP，但是在原本的基礎上新增了很多功能，比如多路復用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重傳等等功能。這里我們就挑選幾個重要的功能學習下這個協議的內容。 **多路復用** 雖然 HTTP/2 支持了多路復用，但是 TCP 協議終究是沒有這個功能的。QUIC 原生就實現了這個功能，并且傳輸的單個數據流可以保證有序交付且不會影響其他的數據流，這樣的技術就解決了之前 TCP 存在的問題。 并且 QUIC 在移動端的表現也會比 TCP 好。因為 TCP 是基于 IP 和端口去識別連接的，這種方式在多變的移動端網絡環境下是很脆弱的。但是 QUIC 是通過 ID 的方式去識別一個連接，不管你網絡環境如何變化，只要 ID 不變，就能迅速重連上。 **0-RTT** 通過使用類似 TCP 快速打開的技術，緩存當前會話的上下文，在下次恢復會話的時候，只需要將之前的緩存傳遞給服務端驗證通過就可以進行傳輸了。 **糾錯機制** 假如說這次我要發送三個包，那么協議會算出這三個包的異或值并單獨發出一個校驗包，也就是總共發出了四個包。 當出現其中的非校驗包丟包的情況時，可以通過另外三個包計算出丟失的數據包的內容。 當然這種技術只能使用在丟失一個包的情況下，如果出現丟失多個包就不能使用糾錯機制了，只能使用重傳的方式了。 # 參考資料 [前端面試之道 - 掘金小冊](https://juejin.im/book/5bdc715fe51d454e755f75ef/section/5bdc72b151882516f039fce3)