【前端 · 面試】HTTP 總結（六）—— HTTP 版本區別

阿新 • • 發佈：2021-08-06

HTTP 發展至今，總共經歷了四個版本——HTTP 0.9、HTTP 1.0、HTTP 1.1、HTTP 2.0 。

最近我在做前端面試題總結系列，感興趣的朋友可以新增關注，歡迎指正、交流。

爭取每個知識點能夠多總結一些，至少要做到在面試時，針對每個知識點都可以侃起來，不至於啞火。

前言

HTTP 各版本之間的區別也是一個面試常見問題。

HTTP 發展至今，總共經歷了四個版本——HTTP 0.9、HTTP 1.0、HTTP 1.1、HTTP 2.0 。接下來，我們分別看一下，各個版本給 HTTP 帶來了什麼改變。

HTTP 0.9

HTTP 0.9 是最早釋出出來的一個版本，於1991年釋出。

它只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支援請求頭。由於該版本不支援 POST 方法，因此客戶端無法向伺服器傳遞太多資訊。

HTTP 0.9 具有典型的無狀態性，每個事務獨立進行處理，事務結束時就釋放這個連線。HTTP 協議的無狀態特點在其第一個版本中已經成型。

HTTP 1.0

HTTP 1.0是HTTP協議的第二個版本，於1996年釋出，如今仍然被廣泛使用，尤其是在代理伺服器中。

這是第一個在通訊中指定版本號的HTTP協議版本，具有以下特點：

不僅僅支援 GET 命令，還支援 POST 和 HEAD 等請求方法。
HTTP 的請求和迴應格式也發生了變化，除了要傳輸的資料之外，每次通訊都包含頭資訊，用來描述一些資訊。
不再侷限於 0.9 版本的純文字格式

根據頭資訊中的 Content-Type 屬性，可以支援多種資料格式，這使得網際網路不僅僅可以用來傳輸文字，還可以傳輸影象、音訊、視訊等二進位制檔案。
開始支援cache，就是當客戶端在規定時間內訪問同一網站，直接訪問cache即可。
其他的新增功能還包括狀態碼（status code）、多字符集支援、多部分發送（multi-part type）、許可權（authorization）、快取（cache）、內容編碼（content encoding）等。

1.0 版本的工作方式是每次 TCP 連線只能傳送一個請求，當伺服器響應後就會關閉這次連線，下一個請求需要再次建立 TCP 連線。 TCP 連線的建立成本很高，因為需要客戶端和伺服器三次握手，並且開始時傳送速率較慢（slow start）。

HTTP 1.0 版本的效能比較差。隨著網頁載入的外部資源越來越多，這個問題就愈發突出了。為了解決這個問題，有些瀏覽器在請求時，即在請求頭部加上 Connection 欄位：

這個欄位要求伺服器不要關閉TCP連線，以便其他請求複用。伺服器同樣迴應這個欄位。

一個可以複用的TCP連線就建立了，直到客戶端或伺服器主動關閉連線。但是，這不是一個標準欄位，不同實現的行為可能不一致，因此不是根本的解決辦法。

HTTP 1.1

預設採用持續連線（Connection: keep-alive），能很好地配合代理伺服器工作。

還支援以管道方式在同時傳送多個請求，以便降低線路負載，提高傳輸速度。

HTTP 1.1 具有以下特點：

引入了持久連線（persistent connection）

即 TCP 連線預設不關閉，可以被多個請求複用，不用宣告 Connection: keep-alive。客戶端和伺服器發現對方一段時間沒有活動，就可以主動關閉連線。不過，規範的做法是，客戶端在最後一個請求時，傳送 Connection: close，明確要求伺服器關閉 TCP 連線。
加入了管道機制

在同一個 TCP 連線裡，允許多個請求同時傳送，增加了併發性，進一步改善了 HTTP 協議的效率。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個 TCP 連線裡面，先發送 A 請求，然後等待伺服器做出迴應，收到後再發出 B 請求。

管道機制則是允許瀏覽器同時發出 A 請求和 B 請求，但是伺服器還是按照順序，先回應 A 請求，完成後再回應 B 請求。

一個 TCP 連線現在可以傳送多個迴應，勢必就要有一種機制，區分資料包是屬於哪一個迴應的。這就是 Content-length 欄位的作用，宣告本次迴應的資料長度。
分塊傳輸編碼

使用 Content-Length 欄位的前提條件是，伺服器傳送迴應之前，必須知道迴應的資料長度。對於一些很耗時的動態操作來說，這意味著，伺服器要等到所有操作完成，才能傳送資料，顯然這樣的效率不高。

更好的處理方法是，產生一塊資料，就傳送一塊，採用"流模式"（stream）取代"快取模式"（buffer）。

因此，HTTP 1.1 版本規定可以不使用 Content-Length 欄位，而使用"分塊傳輸編碼"（chunked transfer encoding）。只要請求或迴應的頭資訊有 Transfer-Encoding 欄位，就表明迴應將由數量未定的資料塊組成。
新增了請求方式 PUT、PATCH、OPTIONS、DELETE 等。
客戶端請求的頭資訊新增了 Host 欄位，用來指定伺服器的域名。
HTTP 1.1 支援檔案斷點續傳，RANGE:bytes，HTTP 1.0 每次傳送檔案都是從檔案頭開始，即 0 位元組處開始。RANGE:bytes=XXXX 表示要求伺服器從檔案 XXXX 位元組處開始傳送，斷點續傳。即返回碼是 206（Partial Content）

HTTP/2.0

這也是最新的 HTTP 版本，於 2015 年 5 月作為網際網路標準正式釋出。

它具有以下特點：

二進位制協議

HTTP 1.1 版的頭資訊肯定是文字（ASCII 編碼），資料體可以是文字，也可以是二進位制。

HTTP 2.0 則是一個徹底的二進位制協議，頭資訊和資料體都是二進位制，並且統稱為"幀"（frame）：頭資訊幀和資料幀。
多工

HTTP 2.0 複用 TCP 連線，在一個連線裡，客戶端和瀏覽器都可以同時傳送多個請求或迴應，而且不用按照順序一一對應，這樣就避免了"隊頭堵塞"（HTTP 2.0 使用了多路複用的技術，做到同一個連線併發處理多個請求，而且併發請求的數量比 HTTP 1.1大了好幾個數量級）。

舉例來說，在一個 TCP 連線裡面，伺服器同時收到了 A 請求和 B 請求，於是先回應 A 請求，結果發現處理過程非常耗時，於是就傳送 A 請求已經處理好的部分，接著迴應 B 請求，完成後，再發送 A 請求剩下的部分。
頭資訊壓縮

HTTP 協議不帶有狀態，每次請求都必須附上所有資訊。所以，請求的很多欄位都是重複的，比如 Cookie 和 User Agent，一模一樣的內容，每次請求都必須附帶，這會浪費很多頻寬，也影響速度。

HTTP 2.0 對這一點做了優化，引入了頭資訊壓縮機制（header compression）。一方面，頭資訊使用 gzip 或c ompress 壓縮後再發送；另一方面，客戶端和伺服器同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以後就不傳送同樣欄位了，只發送索引號，這樣就提高速度了。
伺服器推送

HTTP 2.0 允許伺服器未經請求，主動向客戶端傳送資源，這叫做伺服器推送（server push）。意思是說，當我們對支援 HTTP 2.0 的 web server 請求資料的時候，伺服器會順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次建立連線傳送請求到伺服器端獲取。這種方式非常合適載入靜態資源。
伺服器端推送的這些資源其實存在客戶端的某處地方，客戶端直接從本地載入這些資源就可以了，不用走網路，速度自然是快很多的。