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

這是我參與8月更文挑戰的第6天，活動詳情查看：8月更文挑戰

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

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

前言

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

HTTP 發展至今，總共經歷了四個版本——HTTP 0.九、HTTP 1.0、HTTP 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：二進制分幀、多路複用、頭部壓縮、服務器推送

~

~本文完，感謝閱讀！

~

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

你們好，我是〖編程三昧〗的做者 隱逸王，個人公衆號是『編程三昧』，歡迎關注，但願你們多多指教！

你來，懷揣指望，我有墨香相迎！ 你歸，不管得失，惟以餘韻相贈！

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