HTTP - ShuWa

1. HTTP 基本概念#

1.HTTP 是什麼？#

HTTP 是超文本傳輸協議，也就是 HyperText Transfer Protocol。
HTTP 的名字「超文本協議傳輸」，它可以拆成三個部分：

超文本：超越了普通文本的文本，它是文字、圖片、視頻等的混合體，最關鍵有超鏈接，能從一個超文本跳轉到另外一個超文本。
傳輸：兩點之間雙向傳輸數據
協議：確立了一種計算機之間交流通信的規範（兩個以上的參與者）

2.HTTP 常見的狀態碼有哪些？#

1xx 類狀態碼屬於提示信息，是協議處理中的一種中間狀態，實際用到的比較少。
2xx 類狀態碼表示伺服器成功處理了客戶端的請求，也是我們最願意看到的狀態。
「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，伺服器返回的響應頭都會有 body 數據。
「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 數據。
「206 Partial Content」是應用於 HTTP 分塊下載或斷點續傳，表示響應返回的 body 數據並不是資源的全部，而是其中的一部分，也是伺服器處理成功的狀態。
3xx 類狀態碼表示客戶端請求的資源發生了變動，需要客戶端用新的 URL 重新發送請求獲取資源，也就是重定向。
「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。
「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。
301 和 302 都會在響應頭裡使用字段 Location，指明後續要跳轉的 URL，瀏覽器會自動重定向新的 URL。
「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩衝文件，也稱緩存重定向，也就是告訴客戶端可以繼續使用緩存資源，用於緩存控制。
4xx 類狀態碼表示客戶端發送的報文有誤，伺服器無法處理，也就是錯誤碼的含義。
「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。
「403 Forbidden」表示伺服器禁止訪問資源，並不是客戶端的請求出錯。
「404 Not Found」表示請求的資源在伺服器上不存在或未找到，所以無法提供給客戶端。
5xx 類狀態碼表示客戶端請求報文正確，但是伺服器處理時內部發生了錯誤，屬於伺服器端的錯誤碼。
「500 Internal Server Error」與 400 類型，是個籠統通用的錯誤碼，伺服器發生了什麼錯誤，我們並不知道。
「501 Not Implemented」表示客戶端請求的功能還不支持，類似 “即將開業，敬請期待” 的意思。
「502 Bad Gateway」通常是伺服器作為網關或代理時返回的錯誤碼，表示伺服器自身工作正常，訪問後端伺服器發生了錯誤。
「503 Service Unavailable」表示伺服器當前很忙，暫時無法響應客戶端，類似 “網絡服務正忙，請稍後重試” 的意思。

3.HTTP 常見字段有哪些？#

Host 字段：客戶端發送請求時，用來指定伺服器的域名。
Content-Length 字段：伺服器在返回數據時，會有 Content-Length 字段，表明本次回應的數據長度。HTTP 協議通過設置回車符、換行符作為 HTTP header 的邊界，通過 Content-Length 字段作為 HTTP body 的邊界，這兩個方式都是為了解決 “粘包” 的問題。
Connection 字段：Connection 字段最常用於客戶端要求伺服器使用「HTTP 長連接」機制，以便其他請求復用。HTTP/1.1 版本的默認連接都是長連接，但為了兼容舊版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。
Content-Type 字段：Content-Type 字段用於伺服器回應時，告訴客戶端，本次數據是什麼格式。
Content-Encoding 字段：Content-Encoding 字段說明數據的壓縮方法。表示伺服器返回的數據使用了什麼壓縮格式gzip

4.GET 與 POST#

GET 方法就是安全且幂等的，因為它是「只讀」操作，無論操作多少次，伺服器上的數據都是安全的，且每次的結果都是相同的。所以，可以對 GET 請求的數據做緩存，這個緩存可以做到瀏覽器本身上（徹底避免瀏覽器發請求），也可以做到代理上（如 nginx），而且在瀏覽器中 GET 請求可以保存為書籤。
POST 因為是「新增或提交數據」的操作，會修改伺服器上的資源，所以是不安全的，且多次提交數據就會創建多個資源，所以不是幂等的。所以，瀏覽器一般不會緩存 POST 請求，也不能把 POST 請求保存為書籤。

5.HTTP 緩存#

1. 強制緩存#

強緩存是利用下面這兩個 HTTP 響應頭部（Response Header）字段實現的，它們都用來表示資源在客戶端緩存的有效期：

Cache-Control，是一個相對時間；
Expires，是個絕對時間；

Cache-Control 的優先級高於 Expires
流程如下：

當瀏覽器第一次請求訪問伺服器資源時，伺服器會在返回這個資源的同時，在 Response 頭部加上 Cache-Control，Cache-Control 中設置了過期時間大小；
瀏覽器再次請求訪問伺服器中的該資源時，會先通過請求資源的時間與 Cache-Control 中設置的過期時間大小，來計算出該資源是否過期，如果沒有，則使用該緩存，否則重新請求伺服器；
伺服器再次收到請求後，會再次更新 Response 頭部的 Cache-Control。

2. 協商緩存#

請求的響應碼是 304，這個是告訴瀏覽器可以使用本地緩存的資源，通常這種通過服務端告知客戶端是否可以使用緩存的方式被稱為協商緩存

第一種：請求頭部中的 If-Modified-Since 字段與響應頭部中的 Last-Modified 字段實現，這兩個字段的意思是：

響應頭部中的 Last-Modified：標示這個響應資源的最後修改時間；
請求頭部中的 If-Modified-Since：當資源過期了，發現響應頭中具有 Last-Modified 聲明，則再次發起請求的時候帶上 Last-Modified 的時間，伺服器收到請求後發現有 If-Modified-Since 則與被請求資源的最後修改時間進行對比（Last-Modified），如果最後修改時間較新（大），說明資源又被改過，則返回最新資源，HTTP 200 OK；如果最後修改時間較舊（小），說明資源無新修改，響應 HTTP 304 走緩存。

第二種：請求頭部中的 If-None-Match 字段與響應頭部中的 ETag 字段，這兩個字段的意思是：

響應頭部中 Etag：唯一標識響應資源；
請求頭部中的 If-None-Match：當資源過期時，瀏覽器發現響應頭裡有 Etag，則再次向伺服器發起請求時，會將請求頭 If-None-Match 值設置為 Etag 的值。伺服器收到請求後進行比對，如果資源沒有變化返回 304，如果資源變化了返回 200。

如果帶上了 ETag 和 Last-Modified 字段信息給服務端，這時 ETag 的優先級更高

為什麼 ETag 的優先級更高？這是因為 ETag 主要能解決 Last-Modified 幾個比較難以解決的問題：

在沒有修改文件內容情況下文件的最後修改時間可能也會改變，這會導致客戶端認為這文件被改動了，從而重新請求；
可能有些文件是在秒級內修改的，If-Modified-Since 能檢查到的粒度是秒級的，使用 Etag 就能夠保證這種需求下客戶端在 1 秒內能刷新多次；
有些伺服器不能精確獲取文件的最後修改時間。

2.HTTP 與 HTTPS#

1.HTTP 與 HTTPS 有哪些區別？#

HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
HTTP 連接建立相對簡單， TCP 三次握手之後便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之後，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
兩者的默認端口不一樣，HTTP 默認端口號是 80，HTTPS 默認端口號是 443。
HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證伺服器的身份是可信的。

2.HTTPS 解決了 HTTP 的哪些問題？#

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

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

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

混合加密的方式實現信息的機密性，解決了竊聽的風險。
摘要算法的方式來實現完整性，它能夠為數據生成獨一無二的「指紋」，指紋用於校驗數據的完整性，解決了篡改的風險。
將伺服器公鑰放入到數字證書中，解決了冒充的風險。

混合加密#

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

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

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

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

摘要算法 + 數字簽名#

為了保證傳輸的內容不被篡改，我們需要對內容計算出一個「指紋」，然後同內容一起傳輸給對方。
對方收到後，先是對內容也計算出一個「指紋」，然後跟發送方發送的「指紋」做一個比較，如果「指紋」相同，說明內容沒有被篡改，否則就可以判斷出內容被篡改了。
那麼，在計算機裡會用摘要算法（哈希函數）來計算出內容的哈希值，也就是內容的「指紋」，這個哈希值是唯一的，且無法通過哈希值推導出內容。
通過哈希算法可以確保內容不會被篡改，但是並不能保證「內容 + 哈希值」不會被中間人替換，因為這裡缺少對客戶端收到的消息是否來源於伺服端的證明。
那為了避免這種情況，計算機裡會用非對稱加密算法來解決，共有兩個密鑰：

一個是公鑰，這個是可以公開給所有人的；
一個是私鑰，這個必須由本人管理，不可洩露。
公鑰加密，私鑰解密。這個目的是為了保證內容傳輸的安全，因為被公鑰加密的內容，其他人是無法解密的，只有持有私鑰的人，才能解密出實際的內容；
私鑰加密，公鑰解密。這個目的是為了保證消息不會被冒充，因為私鑰是不可洩露的，如果公鑰能正常解密出私鑰加密的內容，就能證明這個消息是來源於持有私鑰身份的人發送的。

所以非對稱加密的用途主要在於通過「私鑰加密，公鑰解密」的方式，來確認消息的身份，我們常說的數字簽名算法，就是用的是這種方式，不過私鑰加密內容不是內容本身，而是對內容的哈希值加密。

數字證書#

缺少身份驗證的環節，萬一公鑰是被偽造的呢？

通過了一個權威的機構 CA （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。

3.HTTPS 是如何建立連接的？其間交互了什麼？#

TLS 的「握手階段」涉及四次通信，使用不同的密鑰交換算法，TLS 握手流程也會不一樣的，現在常用的密鑰交換算法有兩種：RSA 算法和 ECDHE 算法。
TLS 協議建立的詳細流程：

ClientHello
首先，由客戶端向伺服器發起加密通信請求，也就是 ClientHello 請求。
在這一步，客戶端主要向伺服器發送以下信息：
（1）客戶端支持的 TLS 協議版本，如 TLS 1.2 版本。
（2）客戶端生成的隨機數（Client Random），後面用於生成「會話秘鑰」條件之一。
（3）客戶端支持的密碼套件列表，如 RSA 加密算法。
SeverHello
伺服器收到客戶端請求後，向客戶端發出響應，也就是 SeverHello。伺服器回應的內容有如下內容：
（1）確認 TLS 協議版本，如果瀏覽器不支持，則關閉加密通信。
（2）伺服器生成的隨機數（Server Random），也是後面用於生成「會話秘鑰」條件之一。
（3）確認的密碼套件列表，如 RSA 加密算法。
（4）伺服器的數字證書。
客戶端回應
客戶端收到伺服器的回應之後，首先通過瀏覽器或者操作系統中的 CA 公鑰，確認伺服器的數字證書的真實性。
如果證書沒有問題，客戶端會從數字證書中取出伺服器的公鑰，然後使用它加密報文，向伺服器發送如下信息：
（1）一個隨機數（pre-master key）。該隨機數會被伺服器公鑰加密。
（2）加密通信算法改變通知，表示隨後的信息都將用「會話秘鑰」加密通信。
（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供服務端校驗。
上面第一項的隨機數是整個握手階段的第三個隨機數，會發給伺服器，所以這個隨機數客戶端和伺服器都是一樣的。
伺服器和客戶端有了這三個隨機數（Client Random、Server Random、pre-master key），接著就用雙方協商的加密算法，各自生成本次通信的「會話秘鑰」。
伺服器的最後回應
伺服器收到客戶端的第三個隨機數（pre-master key）之後，通過協商的加密算法，計算出本次通信的「會話秘鑰」。
然後，向客戶端發送最後的信息：
（1）加密通信算法改變通知，表示隨後的信息都將用「會話秘鑰」加密通信。
（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供客戶端校驗。

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

RSA 算法#

上述連接過程就是使用 RSA 算法建立連接的過程，他保證了客戶端和伺服器間的安全通訊，但是仍有缺陷：
使用 RSA 密鑰協商算法的最大問題是不支持前向保密。
因為客戶端傳遞隨機數（用於生成對稱加密密鑰的條件之一）給伺服器時使用的是公鑰加密的，伺服器收到後，會用私鑰解密得到隨機數。所以一旦伺服器的私鑰洩漏了，過去被第三方截獲的所有 TLS 通訊密文都會被破解。
為了解決這個問題，後面就出現了 ECDHE 密鑰協商算法，我們現在大多數網站使用的正是 ECDHE 密鑰協商算法。

ECDHE 算法#

ECDHE 密鑰協商算法是 DH 算法演進過來的，所以我們先從 DH 算法說起。

DH 算法#

DH 算法是非對稱加密算法，因此它可以用於密鑰交換，該算法的核心數學思想是離散對數。
離散對數是在對數運算的基礎上加了「模運算」，也就是說取餘數，對應編程語言的操作符是「%」，也可以用 mod 表示。離散對數的概念如下圖：

上圖的，底數 a 和模數 p 是離散對數的公共參數，也就是說是公開的，b 是真數，i 是對數。知道了對數，就可以用上面的公式計算出真數。但反過來，知道真數卻很難推算出對數。
特別是當模數 p 是一個很大的質數，即使知道底數 a 和真數 b ，在現有的計算機的計算水平是幾乎無法算出離散對數的，這就是 DH 算法的數學基礎。

如上圖：a 和 b 分別是各自的私鑰，A 和 B 分別是各自的公鑰，G P 是公開信息，這個 K 就是小紅和小明之間用的對稱加密密鑰，可以作為會話密鑰使用。

DHE 算法#

E 全稱是 ephemeral（臨時性的）, 雙方的私鑰在每次密鑰交換通信時，都是隨機生成的、臨時的。
這樣，即使有個牛逼的黑客破解了某一次通信過程的私鑰，其他通信過程的私鑰仍然是安全的，因為每個通信過程的私鑰都是沒有任何關係的，都是獨立的，這樣就保證了「前向安全」。

ECDHE 算法#

DHE 算法由於計算性能不佳，因為需要做大量的乘法，為了提升 DHE 算法的性能，所以就出現了現在廣泛用於密鑰交換算法 —— ECDHE 算法。

ECDHE 算法是在 DHE 算法的基礎上利用了 ECC 椭圓曲線特性，可以用更少的計算量計算出公鑰，以及最終的會話密鑰。

小紅和小明使用 ECDHE 密鑰交換算法的過程：

雙方事先確定好使用哪種椭圓曲線，和曲線上的基點 G，這兩個參數都是公開的；
雙方各自隨機生成一個隨機數作為私鑰 d，並與基點 G 相乘得到公鑰 Q（Q = dG），此時小紅的公私鑰為 Q1 和 d1，小明的公私鑰為 Q2 和 d2；
雙方交換各自的公鑰，最後小紅計算點（x1，y1） = d1Q2，小明計算點（x2，y2） = d2Q1，由於椭圓曲線上是可以滿足乘法交換和結合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此雙方的 x 坐標是相同的，所以它是共享密鑰，也就是會話密鑰。

這個過程中，雙方的私鑰都是隨機、臨時生成的，都是不公開的，即使根據公開的信息（椭圓曲線、公鑰、基點 G）也是很難計算出椭圓曲線上的離散對數（私鑰）。

握手過程#

TLS 第一次握手
客戶端首先會發一個「Client Hello」消息，消息裡面有客戶端使用的 TLS 版本號、支持的密碼套件列表，以及生成的隨機數（Client Random）。
TLS 第二次握手
服務端收到客戶端的「打招呼」，同樣也要回禮，會返回「Server Hello」消息，消息面有伺服器確認的 TLS 版本號，也給出了一個隨機數（Server Random），然後從客戶端的密碼套件列表選擇了一個合適的密碼套件。
接著，服務端為了證明自己的身份，發送「Certificate」消息，會把證書也發給客戶端。
這一步就和 RSA 握手過程有很大的區別了，因為服務端選擇了 ECDHE 密鑰協商算法，所以會在發送完證書後，發送「Server Key Exchange」消息。
這個過程伺服器做了三件事：

選擇了名為 x25519 的椭圓曲線，選好了椭圓曲線相當於椭圓曲線基點 G 也定好了，這些都會公開給客戶端；
生成隨機數作為伺服器椭圓曲線的私鑰，保留到本地；
根據基點 G 和私鑰計算出伺服器的椭圓曲線公鑰，這個會公開給客戶端。

為了保證這個椭圓曲線的公鑰不被第三方篡改，伺服器會用 RSA 簽名算法給伺服器的椭圓曲線公鑰做個簽名。
隨後，就是「Server Hello Done」消息，伺服器跟客戶端表明：“這些就是我提供的信息，打招呼完畢”。
TLS 第三次握手
客戶端收到了伺服器的證書後，自然要校驗證書是否合法，如果證書合法，那麼伺服器到身份就是沒問題的。校驗證書的過程會走證書鏈逐級驗證，確認證書的真實性，再用證書的公鑰驗證簽名，這樣就能確認伺服器的身份了，確認無誤後，就可以繼續往下走。
客戶端會生成一個隨機數作為客戶端椭圓曲線的私鑰，然後再根據伺服器前面給的信息，生成客戶端的椭圓曲線公鑰，然後用「Client Key Exchange」消息發給伺服器。
最終的會話密鑰，就是用「客戶端隨機數 + 伺服器隨機數 + x（ECDHE 算法算出的共享密鑰）」三個材料生成的。
算好會話密鑰後，客戶端會發一個「Change Cipher Spec」消息，告訴伺服器隨後改用對稱算法加密通信。
接著，客戶端會發「Encrypted Handshake Message」消息，把之前發送的數據做一個摘要，再用對稱密鑰加密一下，讓伺服器做個驗證，驗證下本次生成的對稱密鑰是否可以正常使用。
TLS 第四次握手
最後，伺服器也會有一個同樣的操作，發「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果雙方都驗證加密和解密沒問題，那麼握手正式完成。於是，就可以正常收發加密的 HTTP 請求和響應了。

4.HTTPS 的應用數據是如何保證完整性的？#

TLS 在實現上分為握手協議和記錄協議兩層：

TLS 握手協議就是我們前面說的 TLS 四次握手的過程，負責協商加密算法和生成對稱密鑰，後續用此密鑰來保護應用程序數據（即 HTTP 數據）；
TLS 記錄協議負責保護應用程序數據並驗證其完整性和來源，所以對 HTTP 數據加密是使用記錄協議；

TLS 記錄協議主要負責消息（HTTP 數據）的壓縮，加密及數據的認證，過程如下圖：

具體過程如下：

首先，消息被分割成多個較短的片段，然後分別對每個片段進行壓縮。
接下來，經過壓縮的片段會被加上消息認證碼（MAC 值，這個是通過哈希算法生成的），這是為了保證完整性，並進行數據的認證。通過附加消息認證碼的 MAC 值，可以識別出篡改。與此同時，為了防止重放攻擊，在計算消息認證碼時，還加上了片段的編碼。
再接下來，經過壓縮的片段再加上消息認證碼會一起通過對稱密碼進行加密。
最後，上述經過加密的數據再加上由數據類型、版本號、壓縮後的長度組成的報頭就是最終的報文數據。

記錄協議完成後，最終的報文數據將傳遞到傳輸控制協議 (TCP) 層進行傳輸。

5.HTTPS 安全之中間人伺服器#

HTTPS 一定安全可靠嗎？
客戶端通過瀏覽器向伺服器發起 HTTPS 請求時，被「假基站」轉發到了「中間人伺服器」，於是客戶端是和「中間人伺服器」完成了 TLS 握手，然後這個「中間人伺服器」再與真正的伺服器完成 TLS 握手。

結論：中間人伺服器與客戶端在 TLS 握手過程中，實際上發送了自己偽造的證書給瀏覽器，而這個偽造的證書是能被瀏覽器（客戶端）識別出是非法的，於是就會提醒用戶該證書存在問題。
如果用戶點擊接受了中間人伺服器的證書，那麼中間人就可以解開瀏覽器發起的 HTTPS 請求裡的數據，也可以解開伺服器響應給瀏覽器的 HTTPS 響應數據。相當於，中間人能夠 “偷看” 瀏覽器與伺服器之間的 HTTPS 請求和響應的數據。
所以，HTTPS 協議本身到目前為止還是沒有任何漏洞的，即使你成功進行中間人攻擊，本質上是利用了客戶端的漏洞（用戶點擊繼續訪問或者被惡意導入偽造的根證書），並不是 HTTPS 不夠安全。

3.HTTP/1.1、HTTP/2、HTTP/3 演變#

1. HTTP/1.1 相比 HTTP/1.0 提高了什麼性能？#

連接方式 : HTTP/1.0 為短連接，HTTP/1.1 支持長連接。
狀態響應碼 : HTTP/1.1 中新加入了大量的狀態碼，光是錯誤響應狀態碼就新增了 24 種。比如說，100 (Continue)—— 在請求大資源前的預熱請求，206 (Partial Content)—— 範圍請求的標識碼，409 (Conflict)—— 請求與當前資源的規定衝突，410 (Gone)—— 資源已被永久轉移，而且沒有任何已知的轉發地址。
緩存機制 : 在 HTTP/1.0 中主要使用 Header 裡的 If-Modified-Since,Expires 來做為緩存判斷的標準，HTTP/1.1 則引入了更多的緩存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供選擇的緩存頭來控制緩存策略。
帶寬：HTTP/1.0 中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而伺服器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP/1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個部分，即返回碼是 206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
Host 頭（Host Header）處理 : HTTP/1.1 引入了 Host 頭字段，允許在同一 IP 地址上托管多個域名，從而支持虛擬主機的功能。而 HTTP/1.0 沒有 Host 頭字段，無法實現虛擬主機。

2. HTTP/2.0 相比 HTTP/1.1 提高了什麼性能？#

IO 多路復用（Multiplexing）：HTTP/2.0 在同一連接上可以同時傳輸多個請求和響應（可以看作是 HTTP/1.1 中長鏈接的升級版本）。HTTP/1.1 則使用串行方式，每個請求和響應都需要獨立的連接。這使得 HTTP/2.0 在處理多個請求時更加高效，減少了網絡延遲和提高了性能。
二進制幀（Binary Frames）：HTTP/2.0 使用二進制幀進行數據傳輸，而 HTTP/1.1 則使用文本格式的報文。二進制幀更加緊湊和高效，減少了傳輸的數據量和帶寬消耗。
頭部壓縮（Header Compression）：HTTP/1.1 支持 Body 壓縮，Header 不支持壓縮。HTTP/2.0 支持對 Header 壓縮，減少了網絡開銷。
伺服器推送（Server Push）：HTTP/2.0 支持伺服器推送，可以在客戶端請求一個資源時，將其他相關資源一並推送給客戶端，從而減少了客戶端的請求次數和延遲。而 HTTP/1.1 需要客戶端自己發送請求來獲取相關資源。

3. HTTP/3 做了哪些優化？#

傳輸協議：HTTP/2.0 是基於 TCP 協議實現的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections）協議來實現可靠的傳輸，提供與 TLS/SSL 相當的安全性，具有較低的連接和傳輸延遲。你可以將 QUIC 看作是 UDP 的升級版本，在其基礎上新增了很多功能比如加密、重傳等等。HTTP/3.0 之前名為 HTTP-over-QUIC，從這個名字中我們也可以發現，HTTP/3 最大的改造就是使用了 QUIC。
連接建立：HTTP/2.0 需要經過經典的 TCP 三次握手過程（一般是 3 個 RTT）。由於 QUIC 協議的特性，HTTP/3.0 可以避免 TCP 三次握手的延遲，允許在第一次連接時發送數據（0 個 RTT ，零往返時間）。
隊頭阻塞：HTTP/2.0 多請求復用一個 TCP 連接，一旦發生丟包，就會阻塞住所有的 HTTP 請求。由於 QUIC 協議的特性，HTTP/3.0 在一定程度上解決了隊頭阻塞（Head-of-Line blocking, 簡寫：HOL blocking）問題，一個連接建立多個不同的數據流，這些數據流之間獨立互不影響，某個數據流發生丟包了，其數據流不受影響（本質上是多路復用 + 輪詢）。
錯誤恢復：HTTP/3.0 具有更好的錯誤恢復機制，當出現丟包、延遲等網絡問題時，可以更快地進行恢復和重傳。而 HTTP/2.0 則需要依賴於 TCP 的錯誤恢復機制。
安全性：HTTP/2.0 和 HTTP/3.0 在安全性上都有較高的要求，支持加密通信，但在實現上有所不同。HTTP/2.0 使用 TLS 協議進行加密，而 HTTP/3.0 基於 QUIC 協議，包含了內置的加密和身份驗證機制，可以提供更強的安全性。