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

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

前言

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 請求數據的時候，服務器會順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創建連接發送請求到服務器端獲取。這種方式非常合适加載靜态資源。 服務器端推送的這些資源其實存在客戶端的某處地方，客戶端直接從本地加載這些資源就可以了，不用走網絡，速度自然是快很多的。

總結

HTTP/0.9：功能撿漏，隻支持GET方法，隻能發送HTML格式字符串。

HTTP/1.0：支持多種數據格式，增加POST、HEAD等方法，增加頭信息，每次隻能發送一個請求（無持久連接）

HTTP/1.1：默認持久連接、請求管道化、增加緩存處理、增加Host字段、支持斷點傳輸分塊傳輸等。

HTTP/2.0：二進制分幀、多路複用、頭部壓縮、服務器推送

~

~本文完，感謝閱讀！

~

學習有趣的知識，結識有趣的朋友，塑造有趣的靈魂！

大家好，我是〖編程三昧〗的作者 隐逸王，我的公衆号是『編程三昧』，歡迎關注，希望大家多多指教！

你來，懷揣期望，我有墨香相迎！ 你歸，無論得失，唯以餘韻相贈！

知識與技能并重，内力和外功兼修，理論和實踐兩手都要抓、兩手都要硬！

,