最近我在做前端面試題總結系列，感興趣的朋友可以添加關注，歡迎指正、交流。
爭取每個知識點能夠多總結一些，至少要做到在面試時，針對每個知識點都可以侃起來，不至於啞火。
前言
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：二進制分幀、多路複用、頭部壓縮、服務器推送
~
~本文完，感謝閱讀！
~
學習有趣的知識，結識有趣的朋友，塑造有趣的靈魂！
大家好，我是〖編程三昧〗的作者 隱逸王，我的公衆號是『編程三昧』，歡迎關注，希望大家多多指教！
你來，懷揣期望，我有墨香相迎！ 你歸，無論得失，唯以餘韻相贈！
知識與技能並重，內力和外功兼修，理論和實踐兩手都要抓、兩手都要硬！
