前言

在面試過程中，HTTP 被提問的概率還是比較高的

我搜集了 5 大類 HTTP 面試常問的題目，同時這 5 大類題跟 HTTP 的發展和演變關聯性是比較大的，通過問答 + 圖解的形式由淺入深的方式幫助大家進一步的學習和理解 HTTP 協議。

• HTTP 基本概念
• Get 與 Post
• HTTP 特性
• HTTPS 與 HTTP
• HTTP/1.1、HTTP/2、HTTP/3 演變
  

正文

01 HTTP 基本概念

HTTP 是什么？描述一下

HTTP 是超文本傳輸協議，也就是HyperText Transfer Protocol。

能否詳細解釋「超文本傳輸協議」？

HTTP的名字「超文本協議傳輸」，它可以拆成三個部分：

• 超文本
• 傳輸
• 協議

1. 「協議」

在生活中，我們也能隨處可見「協議」，例如：

• 剛畢業時會簽一個「三方協議」；
• 找房子時會簽一個「租房協議」；

生活中的協議，本質上與計算機中的協議是相同的，協議的特點:

• 「協」字，代表的意思是必須有兩個以上的參與者。例如三方協議里的參與者有三個：你、公司、學校三個；租房協議里的參與者有兩個：你和房東。
• 「儀」字，代表的意思是對參與者的一種行為約定和規范。例如三方協議里規定試用期期限、毀約金等；租房協議里規定租期期限、每月租金金額、違約如何處理等。

針對 HTTP 協議，我們可以這么理解。

HTTP 是一個用在計算機世界里的協議。它使用計算機能夠理解的語言確立了一種計算機之間交流通信的規范（兩個以上的參與者），以及相關的各種控制和錯誤處理方式（行為約定和規范）。

2. 「傳輸」

所謂的「傳輸」，很好理解，就是把一堆東西從 A 點搬到 B 點，或者從 B 點 搬到 A 點。

別輕視了這個簡單的動作，它至少包含兩項重要的信息。

HTTP 協議是一個雙向協議。

我們在上網沖浪時，瀏覽器是請求方 A ，百度網站就是應答方 B。雙方約定用 HTTP 協議來通信，于是瀏覽器把請求數據發送給網站，網站再把一些數據返回給瀏覽器，最后由瀏覽器渲染在屏幕，就可以看到圖片、視頻了。

數據雖然是在 A 和 B 之間傳輸，但允許中間有中轉或接力。

就好像第一排的同學想穿遞紙條給最后一排的同學，那么傳遞的過程中就需要經過好多個同學（中間人），這樣的傳輸方式就從「A < — > B」，變成了「A <-> N <-> M <-> B」。

而在 HTTP 里，需要中間人遵從 HTTP 協議，只要不打擾基本的數據傳輸，就可以添加任意額外的東西。

針對傳輸，我們可以進一步理解了 HTTP。

HTTP 是一個在計算機世界里專門用來在兩點之間傳輸數據的約定和規范。

3. 「超文本」

HTTP 傳輸的內容是「超文本」。

我們先來理解「文本」，在互聯網早期的時候只是簡單的字符文字，但現在「文本」。的涵義已經可以擴展為圖片、視頻、壓縮包等，在 HTTP 眼里這些都算做「文本」。

再來理解「超文本」，它就是超越了普通文本的文本，它是文字、圖片、視頻等的混合體最關鍵有超鏈接，能從一個超文本跳轉到另外一個超文本。

HTML 就是最常見的超文本了，它本身只是純文字文件，但內部用很多標簽定義了圖片、視頻等的鏈接，在經過瀏覽器的解釋，呈現給我們的就是一個文字、有畫面的網頁了。

OK，經過了對 HTTP 里這三個名詞的詳細解釋，就可以給出比「超文本傳輸協議」這七個字更準確更有技術含量的答案：

HTTP 是一個在計算機世界里專門在「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」數據的「約定和規范」。

HTTP 常見的狀態碼，有哪些？

• 1xx

1xx 類狀態碼屬于提示信息，是協議處理中的一種中間狀態，實際用到的比較少。

• 2xx

2xx 類狀態碼表示服務器成功處理了客戶端的請求，也是我們最愿意看到的狀態。

「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，服務器返回的響應頭都會有 body 數據。

「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 數據。

「206 Partial Content」是應用于 HTTP 分塊下載或斷電續傳，表示響應返回的 body 數據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態。

• 3xx

3xx 類狀態碼表示客戶端請求的資源發送了變動，需要客戶端用新的 URL 重新發送請求獲取資源，也就是重定向。

「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。

「302 Moved Permanently」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段 Location，指明后續要跳轉的 URL，瀏覽器會自動重定向新的 URL。

「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。

• 4xx

4xx 類狀態碼表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義。

「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。

「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯。

「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端。

• 5xx

5xx 類狀態碼表示客戶端請求報文正確，但是服務器處理時內部發生了錯誤，屬于服務器端的錯誤碼。

「500 Internal Server Error」與 400 類型，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并不知道。

「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思。

「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發生了錯誤。

「503 Service Unavailable」表示服務器當前很忙，暫時無法響應服務器，類似“網絡服務正忙，請稍后重試”的意思。

http 常見字段有哪些？

1. Host

客戶端發送請求時，用來指定服務器的域名。

Host: www.A.com

有了 Host字段，就可以將請求發往「同一臺」服務器上的不同網站。

Content-Length 字段

服務器在返回數據時，會有 Content-Length 字段，表明本次回應的數據長度。

Content-Length: 1000

如上面則是告訴瀏覽器，本次服務器回應的數據長度是 1000 個字節，后面的字節就屬于下一個回應了。

2. Connection 字段

Connection 字段最常用于客戶端要求服務器使用 TCP 持久連接，以便其他請求復用。

HTTP/1.1 版本的默認連接都是持久連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。

Connection: keep-alive

一個可以復用的 TCP 連接就建立了，直到客戶端或服務器主動關閉連接。但是，這不是標準字段。

3. Content-Type 字段

Content-Type 字段用于服務器回應時，告訴客戶端，本次數據是什么格式。

Content-Type: text/html; charset=utf-8

上面的類型表明，發送的是網頁，而且編碼是UTF-8。

客戶端請求的時候，可以使用 Accept 字段聲明自己可以接受哪些數據格式。

Accept: */*

上面代碼中，客戶端聲明自己可以接受任何格式的數據。

4. Content-Encoding 字段

Content-Encoding 字段說明數據的壓縮方法。表示服務器返回的數據使用了什么壓縮格式

Content-Encoding: gzip

上面表示服務器返回的數據采用了 gzip 方式壓縮，告知客戶端需要用此方式解壓。

客戶端在請求時，用 Accept-Encoding 字段說明自己可以接受哪些壓縮方法。

Accept-Encoding: gzip, deflate

02 GET 與 POST

說一下 GET 和 POST 的區別？

Get 方法的含義是請求從服務器獲取資源，這個資源可以是靜態的文本、頁面、圖片視頻等。

比如，你打開我的文章，瀏覽器就會發送 GET 請求給服務器，服務器就會返回文章的所有文字及資源。

GET 和 POST 方法都是安全和冪等的嗎？

先說明下安全和冪等的概念：

• 在 HTTP 協議里，所謂的「安全」是指請求方法不會「破壞」服務器上的資源。
• 所謂的「冪等」，意思是多次執行相同的操作，結果都是「相同」的。

那么很明顯 GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的數據都是安全的，且每次的結果都是相同的。

POST 因為是「新增或提交數據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數據就會創建多個資源，所以不是冪等的。

03 HTTP 特性

你知道的 HTTP（1.1） 的優點有哪些，怎么體現的？

HTTP 最凸出的優點是「簡單、靈活和易于擴展、應用廣泛和跨平臺」。

1. 簡單

HTTP 基本的報文格式就是 header + body，頭部信息也是 key-value 簡單文本的形式，易于理解，降低了學習和使用的門檻。

2. 靈活和易于擴展

HTTP協議里的各類請求方法、URI/URL、狀態碼、頭字段等每個組成要求都沒有被固定死，都允許開發人員自定義和擴充。

同時 HTTP 由于是工作在應用層（ OSI 第七層），則它下層可以隨意變化。

HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚至把 TCPP 層換成了基于 UDP 的 QUIC。

3. 應用廣泛和跨平臺

互聯網發展至今，HTTP 的應用范圍非常的廣泛，從臺式機的瀏覽器到手機上的各種 APP，從看新聞、刷貼吧到購物、理財、吃雞，HTTP 的應用片地開花，同時天然具有跨平臺的優越性。

那它的缺點呢？

HTTP 協議里有優缺點一體的雙刃劍，分別是「無狀態、明文傳輸」，同時還有一大缺點「不安全」。

1. 無狀態雙刃劍

無狀態的好處，因為服務器不會去記憶 HTTP 的狀態，所以不需要額外的資源來記錄狀態信息，這能減輕服務器的負擔，能夠把更多的 CPU 和內存用來對外提供服務。

無狀態的壞處，既然服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩。

例如登錄->添加購物車->下單->結算->支付，這系列操作都要知道用戶的身份才行。但服務器不知道這些請求是有關聯的，每次都要問一遍身份信息。

這樣每操作一次，都要驗證信息，這樣的購物體驗還能愉快嗎？別問，問就是酸爽！

對于無狀態的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術。

Cookie 通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

相當于，在客戶端第一次請求后，服務器會下發一個裝有客戶信息的「小貼紙」，后續客戶端請求服務器的時候，帶上「小貼紙」，服務器就能認得了了，

2. 明文傳輸雙刃劍

明文意味著在傳輸過程中的信息，是可方便閱讀的，通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接肉眼查看，為我們調試工作帶了極大的便利性。

但是這正是這樣，HTTP 的所有信息都暴露在了光天化日下，相當于信息裸奔。在傳輸的漫長的過程中，信息的內容都毫無隱私可言，很容易就能被竊取，如果里面有你的賬號密碼信息，那你號沒了。

3. 不安全

HTTP 比較嚴重的缺點就是不安全：

通信使用明文（不加密），內容可能會被竊聽。比如，賬號信息容易泄漏，那你號沒了。

不驗證通信方的身份，因此有可能遭遇偽裝。比如，訪問假的淘寶、拼多多，那你錢沒了。

無法證明報文的完整性，所以有可能已遭篡改。比如，網頁上植入垃圾廣告，視覺污染，眼沒了。

HTTP 的安全問題，可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，使得在安全上達到了極致。

那你說下 HTTP/1.1 的性能如何？

HTTP 協議是基于 TCP/IP，并且使用了「請求 - 應答」的通信模式，所以性能的關鍵就在這兩點里。

1. 長連接

早期 HTTP/1.0 性能上的一個很大的問題，那就是每發起一個請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，做了無畏的 TCP 連接建立和斷開，增加了通信開銷。

為了解決上述 TCP 連接問題，HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。

持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態。

2. 管道網絡傳輸

HTTP/1.1 采用了長連接的方式，這使得管道（pipeline）網絡傳輸成為了可能。

即可在同一個 TCP 連接里面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個TCP連接里面，先發送 A 請求，然后等待服務器做出回應，收到后再發出 B 請求。管道機制則是允許瀏覽器同時發出 A 請求和 B 請求。

但是服務器還是按照順序，先回應 A 請求，完成后再回應 B 請求。要是 前面的回應特別慢，后面就會有許多請求排隊等著。這稱為「隊頭堵塞」。

3. 隊頭阻塞

「請求 - 應答」的模式加劇了 HTTP 的性能問題。

因為當順序發送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一同被阻塞了，會招致客戶端一直請求不到數據，這也就是「隊頭阻塞」。好比上班的路上塞車。

04 HTTP 與 HTTPS

HTTP 與 HTTPS 有哪些區別？

1. HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。

2. HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。

3. HTTP 的端口號是 80，HTTPS 的端口號是 443。

4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的。

HTTPS 解決了 HTTP 的哪些問題？

HTTP 由于是明文傳輸，所以安全上存在以下三個風險：

• 竊聽風險，比如通信鏈路上可以獲取通信內容，用戶號容易沒。
• 篡改風險，比如強制入垃圾廣告，視覺污染，用戶眼容易瞎。
• 冒充風險，比如冒充淘寶網站，用戶錢容易沒。

HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議。

可以很好的解決了上述的風險：

• 信息加密：交互信息無法被竊取，但你的號會因為「自身忘記」賬號而沒。
• 校驗機制：無法篡改通信內容，篡改了就不能正常顯示，但百度「競價排名」依然可以搜索垃圾廣告。
• 身份證書：證明淘寶是真的淘寶網，但你的錢還是會因為「剁手」而沒。

可見，只要自身不做「惡」，SSL/TLS 協議是能保證通信是安全的。

HTTPS 是如何解決上面的三個風險的？

混合加密的方式實現信息的機密性，解決了竊聽的風險。

摘要算法的方式來實現完整性，它能夠為數據生成獨一無二的「指紋」，指紋用于校驗數據的完整性，解決了篡改的風險。

將服務器公鑰放入到數字證書中，解決了冒充的風險。

1. 混合加密

通過混合加密的方式可以保證信息的機密性，解決了竊聽的風險。

HTTPS 采用的是對稱加密和非對稱加密結合的「混合加密」方式：

• 在通信建立前采用非對稱加密的方式交換「會話秘鑰」，后續就不再使用非對稱加密。
• 在通信過程中全部使用對稱加密的「會話秘鑰」的方式加密明文數據。

采用「混合加密」的方式的原因：

• 對稱加密只使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換。
• 非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了密鑰交換問題但速度慢。

2. 摘要算法

摘要算法用來實現完整性，能夠為數據生成獨一無二的「指紋」，用于校驗數據的完整性，解決了篡改的風險。

客戶端在發送明文之前會通過摘要算法算出明文的「指紋」，發送的時候把「指紋 + 明文」一同
加密成密文后，發送給服務器，服務器解密后，用相同的摘要算法算出發送過來的明文，通過比較客戶端攜帶的「指紋」和當前算出的「指紋」做比較，若「指紋」相同，說明數據是完整的。

3. 數字證書

客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

這就存在些問題，如何保證公鑰不被篡改和信任度？

所以這里就需要借助第三方權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。

通過數字證書的方式保證服務器公鑰的身份，解決冒充的風險。

HTTPS 是如何建立連接的？其間交互了什么？

SSL/TLS 協議基本流程：

• 客戶端向服務器索要并驗證服務器的公鑰。
• 雙方協商生產「會話秘鑰」。
• 雙方采用「會話秘鑰」進行加密通信。

前兩步也就是 SSL/TLS 的建立過程，也就是握手階段。

SSL/TLS 的「握手階段」涉及四次通信，可見下圖：

SSL/TLS 協議建立的詳細流程：

1. ClientHello

首先，由客戶端向服務器發起加密通信請求，也就是 ClientHello 請求。

在這一步，客戶端主要向服務器發送以下信息：

（1）客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本。

（2）客戶端生產的隨機數（Client Random），后面用于生產「會話秘鑰」。

（3）客戶端支持的密碼套件列表，如 RSA 加密算法。

2. SeverHello

服務器收到客戶端請求后，向客戶端發出響應，也就是 SeverHello。服務器回應的內容有如下內容：

（1）確認 SSL/ TLS 協議版本，如果瀏覽器不支持，則關閉加密通信。

（2）服務器生產的隨機數（Server Random），后面用于生產「會話秘鑰」。

（3）確認的密碼套件列表，如 RSA 加密算法。

（4）服務器的數字證書。

3.客戶端回應

客戶端收到服務器的回應之后，首先通過瀏覽器或者操作系統中的 CA 公鑰，確認服務器的數字證書的真實性。

如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下信息：

（1）一個隨機數（pre-master key）。該隨機數會被服務器公鑰加密。

（2）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供服務端校驗。

上面第一項的隨機數是整個握手階段的第三個隨機數，這樣服務器和客戶端就同時有三個隨機數，接著就用雙方協商的加密算法，各自生成本次通信的「會話秘鑰」。

4. 服務器的最后回應

服務器收到客戶端的第三個隨機數（pre-master key）之后，通過協商的加密算法，計算出本次通信的「會話秘鑰」。然后，向客戶端發生最后的信息：

（1）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供客戶端校驗。

至此，整個 SSL/TLS 的握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用「會話秘鑰」加密內容。

05 HTTP/1.1、HTTP/2、HTTP/3 演變’

說說 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改進：

• 使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
• 支持 管道（pipeline）網絡傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。

但 HTTP/1.1 還是有性能瓶頸：

• 請求 / 響應頭部（Header）未經壓縮就發送，首部信息越多延遲越大。只能壓縮 Body 的部分；

• 發送冗長的首部。每次互相發送相同的首部造成的浪費較多；

• 服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端一直請求不到數據，也就是隊頭阻塞；

• 沒有請求優先級控制；

• 請求只能從客戶端開始，服務器只能被動響應。

那上面的 HTTP/1.1 的性能瓶頸，HTTP/2 做了什么優化？

HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

那 HTTP/2 相比 HTTP/1.1 性能上的改進：

1. 頭部壓縮

HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是一樣的或是相似的，那么，協議會幫你消除重復的分。

這就是所謂的 HPACK 算法：在客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發送同樣字段了，只發送索引號，這樣就提高速度了。

2. 二進制格式

HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式。

頭信息和數據體都是二進制，并且統稱為幀（frame）：頭信息幀和數據幀。

這樣雖然對人不友好，但是對計算機非常友好，因為計算機只懂二進制，那么收到報文后，無需再將明文的報文轉成二進制，而是直接解析二進制報文，這增加了數據傳輸的效率。

3. 數據流

HTTP/2 的數據包不是按順序發送的，同一個連接里面連續的數據包，可能屬于不同的回應。因此，必須要對數據包做標記，指出它屬于哪個回應。

每個請求或回應的所有數據包，稱為一個數據流（Stream）。

每個數據流都標記著一個獨一無二的編號，其中規定客戶端發出的數據流編號為奇數， 服務器發出的數據流編號為偶數

客戶端還可以指定數據流的優先級。優先級高的請求，服務器就先響應該請求。

4. 多路復用

HTTP/2 是可以在一個連接中并發多個請求或回應，而不用按照順序一一對應。

移除了 HTTP/1.1 中的串行請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率。

舉例來說，在一個 TCP 連接里，服務器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理過程非常耗時，于是就回應 A 請求已經處理好的部分，接著回應 B 請求，完成后，再回應 A 請求剩下的部分。

5. 服務器推送

HTTP/2 還在一定程度上改善了傳統的「請求 - 應答」工作模式，服務不再是被動地響應，也可以主動向客戶端發送消息。

舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會用到的 JS、CSS 文件等靜態資源主動發給客戶端，減少延時的等待，也就是服務器推送（Server Push，也叫 Cache Push）。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些優化？

HTTP/2 主要的問題在于：多個 HTTP 請求在復用一個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。

所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

• HTTP/1.1 中的管道（ pipeline）傳輸中如果有一個請求阻塞了，那么隊列后請求也統統被阻塞住了
• HTTP/2 多請求復用一個TCP連接，一旦發生丟包，就會阻塞住所有的 HTTP 請求。

這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！

UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題。

大家都知道 UDP 是不可靠傳輸的，但基于 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。

• QUIC 有自己的一套機制可以保證傳輸的可靠性的。當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響。
• TL3 升級成了最新的 1.3 版本，頭部壓縮算法也升級成了 QPack。
• HTTPS 要建立一個連接，要花費 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數。
  

所以， QUIC 是一個在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復用的協議。

QUIC 是新協議，對于很多網絡設備，根本不知道什么是 QUIC，只會當做 UDP，這樣會出現新的問題。所以 HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。