【面試必備】硬核！30 張圖解 HTTP 常見的面試題

時間 2020-03-09

原文原文鏈接

每日一句英語學習，天天進步一點點：

前言

在面試過程當中，HTTP 被提問的機率仍是比較高的。小林我搜集了 5 大類 HTTP 面試常問的題目，同時這 5 大類題跟 HTTP 的發展和演變關聯性是比較大的，經過問答 + 圖解的形式由淺入深的方式幫助你們進一步的學習和理解 HTTP 。css

HTTP 基本概念
Get 與 Post
HTTP 特性
HTTPS 與 HTTP
HTTP/1.一、HTTP/二、HTTP/3 演變

提綱

正文

01 HTTP 基本概念

HTTP 是什麼？描述一下html

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

可否詳細解釋「超文本傳輸協議」？面試

HTTP的名字「超文本協議傳輸」，它能夠拆成三個部分：算法

超文本
傳輸
協議

三個部分

1. 「協議」shell

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

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

三方協議和租房協議

生活中的協議，本質上與計算機中的協議是相同的，協議的特色:瀏覽器

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

針對 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 是用於從互聯網服務器傳輸超文本到本地瀏覽器的協議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 Found」表示臨時重定向，說明請求的資源還在，但暫時須要用另外一個 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 常見字段有哪些？

Host

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

Host: www.A.com

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

Content-Length 字段

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

Content-Length: 1000

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

Connection 字段

Connection 字段最經常使用於客戶端要求服務器使用 TCP 持久鏈接，以便其餘請求複用。

image

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

Connection: keep-alive

一個能夠複用的 TCP 鏈接就創建了，直到客戶端或服務器主動關閉鏈接。可是，這不是標準字段。

Content-Type 字段

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

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

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

客戶端請求的時候，可使用 Accept 字段聲明本身能夠接受哪些數據格式。

Accept: */*

上面代碼中，客戶端聲明本身能夠接受任何格式的數據。

Content-Encoding 字段

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

Content-Encoding: gzip

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

客戶端在請求時，用 Accept-Encoding 字段說明本身能夠接受哪些壓縮方法。

Accept-Encoding: gzip, deflate

GET 與 POST

說一下 GET 和 POST 的區別？

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

好比，你打開個人文章，瀏覽器就會發送 GET 請求給服務器，服務器就會返回文章的全部文字及資源。

GET 請求

而POST 方法則是相反操做，它向 URI 指定的資源提交數據，數據就放在報文的 body 裏。

好比，你在我文章底部，敲入了留言後點擊「提交」（暗示大家留言），瀏覽器就會執行一次 POST 請求，把你的留言文字放進了報文 body 裏，而後拼接好 POST 請求頭，經過 TCP 協議發送給服務器。

POST 請求

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 信息來控制客戶端的狀態。

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

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 的性能問題。

由於當順序發送的請求序列中的一個請求由於某種緣由被阻塞時，在後面排隊的全部請求也一同被阻塞了，會招致客戶端一直請求不到數據，這也就是「隊頭阻塞」。比如上班的路上塞車。

隊頭阻塞

總之 HTTP/1.1 的性能通常般，後續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的性能。

04 HTTP 與 HTTPS

HTTP 與 HTTPS 有哪些區別？

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

HTTPS 解決了 HTTP 的哪些問題？

HTTP 因爲是明文傳輸，因此安全上存在如下三個風險：

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

HTTP 與 HTTPS 網絡層

HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議，能夠很好的解決了上述的風險：

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

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

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

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

1. 混合加密

經過混合加密的方式能夠保證信息的機密性，解決了竊聽的風險。

混合加密

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

在通訊創建前採用非對稱加密的方式交換「會話祕鑰」，後續就再也不使用非對稱加密。
在通訊過程當中所有使用對稱加密的「會話祕鑰」的方式加密明文數據。

採用「混合加密」的方式的緣由：

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

2. 摘要算法

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

校驗完整性

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

3. 數字證書

客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

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

因此這裏就須要藉助第三方權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。

數子證書工做流程

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

HTTPS 是如何創建鏈接的？其間交互了什麼？

SSL/TLS 協議基本流程：

客戶端向服務器索要並驗證服務器的公鑰。
雙方協商生產「會話祕鑰」。
雙方採用「會話祕鑰」進行加密通訊。

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

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

HTTPS 鏈接創建過程

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.一、HTTP/二、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）。每一個數據流都標記着一個獨一無二的編號，其中規定客戶端發出的數據流編號爲奇數，服務器發出的數據流編號爲偶數

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

HTT/1 ~ HTTP/2

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！

HTTP/1 ~ HTTP/3

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 次，減小了交互次數。

TCP HTTPS（TLS/1.3）和 QUIC HTTPS

因此， QUIC 是一個在 UDP 之上的僞 TCP + TLS + HTTP/2 的多路複用的協議。

QUIC 是新協議，對於不少網絡設備，根本不知道什麼是 QUIC，只會當作 UDP，這樣會出現新的問題。因此 HTTP/3 如今普及的進度很是的緩慢，不知道將來 UDP 是否可以逆襲 TCP。