詳解 HTTP 1.0 / 1.1 / 2.0 / 3.0的區別
1.0和1.1有什麼區別？
響應狀態碼的區別
HTTP/1.0 僅定義了 16 種狀態碼。HTTP/1.1 中新加入了大量的狀態碼，光是錯誤響應狀態碼就新增了 24 種。比如說，100 (Continue)——在請求大資源前的預熱請求，206 (Partial Content)——範圍請求的標識碼，409 (Conflict)——請求與當前資源的規定衝突，410 (Gone)——資源已被永久轉移，而且沒有任何已知的轉發地址。
連線方式的區別
HTTP/1.0 預設使用短連線 ，也就是說，客戶端和伺服器每進行一次 HTTP 操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個 HTML 或其他型別的 Web 頁中包含有其他的 Web 資源（如 JavaScript 檔案、影像檔案、CSS 檔案等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 TCP 連線，這樣就會導致有大量的“握手報文”和“揮手報文”佔用了頻寬。
HTTP/1.1 最佳化為預設長連線模式 。 採用長連線模式的請求報文會通知服務端：“我向你請求連線，並且連線成功建立後，請不要關閉”。因此，該 TCP 連線將持續開啟，為後續的客戶端-服務端的資料互動服務。也就是說在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸 HTTP 資料的 TCP 連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。
如果 TCP 連線一直保持的話也是對資源的浪費，因此，一些伺服器軟體（如 Apache）還會支援超時時間的時間。在超時時間之內沒有新的請求達到，TCP 連線才會被關閉。
另外，HTTP/1.0 仍提供了長連線選項，即在請求頭中加入Connection: Keep-alive。同樣的，在 HTTP/1.1 中，如果不希望使用長連線選項，也可以在請求頭中加入Connection: close，這樣會通知伺服器端：“我不需要長連線，連線成功後即可關閉”。
還有兩點需要注意：
① 因為HTTP 1.0/1.1都是基於TCP的，所以HTTP 協議的長連線和短連線，實質上是 TCP 協議的長連線和短連線。
②還有就是，實現長連線需要客戶端和服務端都支援長連線。
解決多個主機/網站共享一個資源時無法區分的問題
要訪問的一個資源的URL是 http://xiaozhang.com/homepage.html
假設現在xiaozhang.com 和 xiaoli.com 兩個網站對應的伺服器都有 homepage.html這個資源
如果是HTTP1.0的請求，將會是 GET/homepage.html HTTP/1.0 這樣的話沒有辦法區分究竟是訪問哪個網站的這個資源
如果是HTTP1.1的請求 將會額外新增一個Host:xiaozhang.com欄位 這樣就能正確區分了
頻寬最佳化及網路連線的使用
HTTP1.0 中，存在一些浪費頻寬的現象，例如客戶端只是需要某個物件的一部分，而伺服器卻將整個物件送過來了，並且不支援斷點續傳功能，HTTP1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個部分，即返回碼是 206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用頻寬和連線。
1.1 和 2.0 有什麼區別？
多路複用
2.0在同一連線上可以同時傳輸多個請求和響應，互不干擾。1.1則採用序列的方式，每個請求和響應都要獨立連線。這使得2.0在處理多個請求的時更加高效，減少了網路延遲並提高了效能
資料傳輸方式
1.1採用文字格式的報文。 2.0則採用二進位制幀進行資料傳輸。顯然 ，二進位制幀更加緊湊和高效，減少了傳輸的資料量和頻寬的消耗
頭部壓縮
1.1只支援body壓縮，2.0新增了支援對Header進行壓縮。減少了網路開銷
伺服器推送
2.0支援伺服器推送，可以在客戶端請求一個資源的時候，將其它相關的資源一併推送給客戶端，從而減少了客戶端的請求次數。
2.0和3.0有什麼區別？
傳輸協議
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 三次握手過程（由於安全的 HTTPS 連線建立還需要 TLS 握手，共需要大約 3 個 RTT）。由於 QUIC 協議的特性（TLS 1.3，TLS 1.3 除了支援 1 個 RTT 的握手，還支援 0 個 RTT 的握手）連線建立僅需 0-RTT 或者 1-RTT。這意味著 QUIC 在最佳情況下不需要任何的額外往返時間就可以建立新連線。
頭部壓縮
HTTP/2.0 使用 HPACK 演算法進行頭部壓縮，而 HTTP/3.0 使用更高效的 QPACK 頭壓縮演算法。
隊頭阻塞：HTTP/2.0 多請求複用一個 TCP 連線，一旦發生丟包，就會阻塞住所有的 HTTP 請求。由於 QUIC 協議的特性，HTTP/3.0 在一定程度上解決了隊頭阻塞（Head-of-Line blocking, 簡寫：HOL blocking）問題，一個連線建立多個不同的資料流，這些資料流之間獨立互不影響，某個資料流發生丟包了，其資料流不受影響（本質上是多路複用+輪詢）。
連線遷移
HTTP/3.0 支援連線遷移，因為 QUIC 使用 64 位 ID 標識連線，只要 ID 不變就不會中斷，網路環境改變時（如從 Wi-Fi 切換到移動資料）也能保持連線。而 TCP 連線是由（源 IP，源埠，目的 IP，目的埠）組成，這個四元組中一旦有一項值發生改變，這個連線也就不能用了。
錯誤恢復：HTTP/3.0 具有更好的錯誤恢復機制，當出現丟包、延遲等網路問題時，可以更快地進行恢復和重傳。而 HTTP/2.0 則需要依賴於 TCP 的錯誤恢復機制。
安全性
在 HTTP/2.0 中，TLS 用於加密和認證整個 HTTP 會話，包括所有的 HTTP 頭部和資料負載。TLS的工作是在 TCP 層之上，它加密的是在 TCP 連線中傳輸的應用層的資料，並不會對 TCP 頭部以及 TLS 記錄層頭部進行加密，所以在傳輸的過程中 TCP 頭部可能會被攻擊者篡改來干擾通訊。而 HTTP/3.0 的 QUIC 對整個資料包（包括報文頭和報文體）進行了加密與認證處理，保障安全性。