HTTP協議多版本之間的區別和聯繫

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

微信公衆號搜索 程序媛小莊 人生苦短一塊兒學Python數據庫

HTTP協議各版本介紹

HTTP協議是現在互聯網與服務端技術的基石，HTTP協議的演進也從側面反應了互聯網技術的快速發展。這兩天在準備一次關於HTTP1.1協議特性的技術分享過程當中，順便了解了下各版本HTTP協議的特色，在這裏作個簡單的總結。瀏覽器

HTTP協議到如今爲止總共經歷了3個版本的演化，第一個HTTP協議誕生於1989年3月。緩存

HTTP 0.9

HTTP 0.9是第一個版本的HTTP協議，已過期。性能優化

它的組成極其簡單，只容許客戶端發送GET這一種請求，且不支持請求頭。服務器

因爲沒有協議頭，形成了HTTP 0.9協議只支持一種內容，即純文本。不過網頁仍然支持用HTML語言格式化，同時沒法插入圖片。微信

HTTP 0.9具備典型的無狀態性，每一個事務獨立進行處理，事務結束時就釋放這個鏈接。markdown

一次HTTP 0.9的傳輸首先要創建一個由客戶端到Web服務器的TCP鏈接，由客戶端發起一個請求，而後由Web服務器返回頁面內容，而後鏈接會關閉。若是請求的頁面不存在，也不會返回任何錯誤碼。併發

HTTP 1.0

HTTP協議的第二個版本，第一個在通信中指定版本號的HTTP協議版本，至今仍被普遍採用。相對於HTTP 0.9 增長了以下主要特性：post

請求與響應支持頭域
響應對象以一個響應狀態行開始
響應對象不僅限於超文本
開始支持客戶端經過POST方法向Web服務器提交數據，支持GET、HEAD、POST方法
支持長鏈接（但默認仍是使用短鏈接），緩存機制，以及身份認證

HTTP 1.1

HTTP協議的第三個版本是HTTP 1.1，是目前使用最普遍的協議版本。HTTP 1.1是目前主流的HTTP協議版本。

HTTP 1.1引入了許多關鍵性能優化：keepalive鏈接，chunked編碼傳輸，字節範圍請求，請求流水線等

Persistent Connection（keepalive鏈接）容許HTTP設備在事務處理結束以後將TCP鏈接保持在打開的狀態，一遍將來的HTTP請求重用如今的鏈接，直到客戶端或服務器端決定將其關閉爲止。在HTTP1.0中使用長鏈接須要添加請求頭 Connection: Keep-Alive，而在HTTP 1.1 全部的鏈接默認都是長鏈接，除非特殊聲明不支持（ HTTP請求報文首部加上Connection: close ）

chunked編碼傳輸該編碼將實體分塊傳送並逐塊標明長度,直到長度爲0塊表示傳輸結束, 這在實體長度未知時特別有用(好比由數據庫動態產生的數據)
字節範圍請求 HTTP1.1支持傳送內容的一部分。比方說，當客戶端已經有內容的一部分，爲了節省帶寬，能夠只向服務器請求一部分。該功能經過在請求消息中引入了range頭域來實現，它容許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。若是服務器相應地返回了對象所請求範圍的內容，則響應碼206（Partial Content）
Pipelining（請求流水線）

另外，HTTP 1.1還新增了以下特性：

請求消息和響應消息都應支持Host頭域在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。所以，Host頭的引入就頗有必要了。
新增了一批Request method HTTP1.1增長了OPTIONS,PUT, DELETE, TRACE, CONNECT方法
緩存處理 HTTP/1.1在1.0的基礎上加入了一些cache的新特性，引入了實體標籤，通常被稱爲e-tags，新增更爲強大的Cache-Control頭。

HTTP 2.0

HTTP 2.0是下一代HTTP協議，目前應用還很是少。主要特色有：

爲了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增長雙工模式，即不只客戶端可以同時發送多個請求，服務端也能同時處理多個請求，解決了隊頭堵塞的問題（HTTP2.0使用了多路複用的技術，作到同一個鏈接併發處理多個請求，並且併發請求的數量比HTTP1.1大了好幾個數量級）。

HTTP請求和響應中，狀態行和請求/響應頭都是些信息字段，並無真正的數據，所以在2.0版本中將全部的信息字段創建一張表，爲表中的每一個字段創建索引，客戶端和服務端共同使用這個表，他們之間就以索引號來表示信息字段，這樣就避免了1.0舊版本的重複繁瑣的字段，並以壓縮的方式傳輸，提升利用率。

多路複用（二進制分幀） HTTP 2.0最大的特色: 不會改動HTTP 的語義，HTTP 方法、狀態碼、URI 及首部字段，等等這些核心概念上一如往常，卻能致力於突破上一代標準的性能限制，改進傳輸性能，實現低延遲和高吞吐量。而之因此叫2.0，是在於新增的二進制分幀層。在二進制分幀層上， HTTP 2.0 會將全部傳輸的信息分割爲更小的消息和幀,並對它們採用二進制格式的編碼，其中HTTP1.x的首部信息會被封裝到Headers幀，而咱們的request body則封裝到Data幀裏面。 HTTP 2.0 通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。相應地，每一個數據流以消息的形式發送，而消息由一或多個幀組成，這些幀能夠亂序發送，而後再根據每一個幀首部的流標識符從新組裝。
頭部壓縮當一個客戶端向相同服務器請求許多資源時，像來自同一個網頁的圖像，將會有大量的請求看上去幾乎一樣的，這就須要壓縮技術對付這種幾乎相同的信息。
隨時復位 HTTP1.1一個缺點是當HTTP信息有必定長度大小數據傳輸時，你不能方便地隨時中止它，中斷TCP鏈接的代價是昂貴的。使用HTTP2的RST_STREAM將能方便中止一個信息傳輸，啓動新的信息，在不中斷鏈接的狀況下提升帶寬利用效率。
服務器端推流: Server Push 客戶端請求一個資源X，服務器端判斷也許客戶端還須要資源Z，在無需事先詢問客戶端狀況下將資源Z推送到客戶端，客戶端接受到後，能夠緩存起來以備後用。
優先權和依賴每一個流都有本身的優先級別，會代表哪一個流是最重要的，客戶端會指定哪一個流是最重要的，有一些依賴參數，這樣一個流能夠依賴另一個流。優先級別能夠在運行時動態改變，當用戶滾動頁面時，能夠告訴瀏覽器哪一個圖像是最重要的，你也能夠在一組流中進行優先篩選，可以忽然抓住重點流。

結語

文章首發於微信公衆號程序媛小莊，同步於掘金。

碼字不易，轉載請說明出處，走過路過的小夥伴們伸出可愛的小指頭點個贊再走吧(╹▽╹)