HTTP的歷史
- HTTP協議是什麼? ：Hyper Text Transfer Protocol（超文本傳輸協議）,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。HTTP是一個基於 TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。HTTP是一個屬於 應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分佈式超媒體信息系統。HTTP協議工作於 客戶端-服務端架構上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。
![在這裏插入圖片描述]()
- HTTP協議的發展 ：早在 HTTP 建立之初，主要就是爲了將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。也是說對於前端來說，我們所寫的HTML頁面將要放在我們的 web 服務器上，用戶端通過瀏覽器訪問url地址來獲取網頁的顯示內容，但是到了 WEB2.0 以來，我們的頁面變得複雜，不僅僅單純的是一些簡單的文字和圖片，同時我們的 HTML 頁面有了 CSS，Javascript，來豐富我們的頁面展示，當 ajax 的出現，我們又多了一種向服務器端獲取數據的方法，這些其實都是基於 HTTP 協議的。同樣到了 移動互聯網時代，我們頁面可以跑在手機端瀏覽器裏面，但是和 PC 相比，手機端的網絡情況更加複雜，這使得我們開始了不得不對 HTTP 進行深入理解並不斷優化過程中。
![在這裏插入圖片描述]()
其中核心版本(具有代表性的)爲HTTP1.0, HTTP1.1, HTTP2.0
- HTTP協議的優化 :影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。
帶寬：如果說我們還停留在撥號上網的階段，帶寬可能會成爲一個比較嚴重影響請求的問題，但是現在網絡基礎建設已經使得帶寬得到極大的提升，我們不再會擔心由帶寬而影響網速，那麼就只剩下延遲了。
延遲：
1)瀏覽器阻塞（HOL blocking）：瀏覽器會因爲一些原因阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個連接（這個根據瀏覽器內核不同可能會有所差異），超過瀏覽器最大連接數限制，後續請求就會被阻塞。
2)DNS 查詢（DNS Lookup）：瀏覽器需要知道目標服務器的 IP 才能建立連接。將域名解析爲 IP 的這個系統就是 DNS。這個通常可以利用DNS緩存結果來達到減少這個時間的目的。
3)建立連接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連接，但是這些連接無法複用會導致每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件大量請求影響較大。
HTTP 0.9
1991年，伴隨WWW誕生之初，HTTP/0.9協議已經提出。HTTP0.9是簡單且應用受限的協議。其協議之簡單甚至只用下面一個訪問谷歌主機的例子概括了HTTP/0.9的全部。
telnet google.com 80
Connected to x.x.x.x
GET /about
(Hyper text)
(Conection closed)
- 支持從網絡主機獲取對應路徑的資源, 但是沒有擴展屬性。
- 協議只支持GET操作.
- 沒有http頭.
- 響應只能是超文本(支持HTML語言格式化,但沒有圖片等)。
- 具有典型的無狀態性(短連接)，每個事務獨立進行處理，事務結束時就釋放這個連接。由此可見，HTTP協議的無狀態特點在其第一個版本0.9中已經成型。一次HTTP/0.9的傳輸首先要建立一個由客戶端到Web服務器的TCP連接，由客戶端發起一個請求，然後由Web服務器返回頁面內容，然後連接會關閉。
- 如果請求的頁面不存在，也不會返回任何錯誤碼。
HTTP 1.0
1996年, HTTP1.0最早在網頁中使用，那個時候只是使用一些較爲簡單的網頁上和網絡請求上.其特點如下:
- 響應對象以一個響應狀態行開始
- 開始支持客戶端通過POST方法向Web服務器提交數據，支持GET、HEAD、POST方法
- 請求與響應支持頭域
- 響應對象不只限於超文本
- 默認短連接（但支持長連接,只需要在header中設置Connection:Keep-Alive,可以在一定時間內複用連接，具體複用時間的長短可以由服務器控制，一般在15s左右)
- 緩存機制，以及身份認證
HTTP 1.1
1999年, HTTP1.1則以RFC標準形式廣泛應用於現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲廣泛的HTTP協議。 相對於HTTP1.0主要區別主要體現在增加了多個頭部字段：
- 緩存管理(cache-Control頭)，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的cache-Control頭來控制緩存策略。
- 範圍請求功能(range頭), 實現了帶寬優化及網絡連接的使用. HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
- 錯誤通知管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
- 虛擬主機管理(host頭)，在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
- 默認爲長連接，HTTP 1.1支持長連接（PersistentConnection) 和請求流水線( Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。如果相關閉長連接,可以設置Conection:Close.
長連接不需要多次的建立連接,可以在短暫的週期內(同一個域名連接內,大約15s),連續請求並且獲取響應.其缺點是串行連接,第一個請求的響應沒有獲取到,之後的請求都會出現頭部阻塞的問題.
pipelining請求流水線,雖然仍然是串行模式,但是不需要等待前面的請求獲取響應之後在發送.而是前面的請求發送完之後,就可以接着發送請求.這樣可以極大的降低時延.
HTTPS
1999年,TLS1.0出現,HTTP加密與解密形成.相對於HTTP協議的區別:
- HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。
- HTTP協議運行在TCP之上，所有傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的。
- HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
- HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。
SPDY: HTTP 1.x
2012年google提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體如下：
- 降低延遲，針對HTTP高延遲的問題，SPDY優雅的採取了多路複用（multiplexing）。多路複用通過多個請求stream共享一個tcp連接的方式，解決了head of line blocking(頭部阻塞)的問題，降低了延遲同時提高了帶寬的利用率。其中 head of line blocking(頭部阻塞)是指,串行的數據傳輸,前面的流發生擁塞,後面的流都需要等待,直到前面的流全部處理結束.
- 請求優先級（request prioritization）。多路複用帶來一個新的問題是，在連接共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級，這樣重要的請求就會優先得到響應。比如瀏覽器加載首頁，首頁的html內容應該優先展示，之後纔是各種靜態資源文件，腳本文件等加載，這樣可以保證用戶能第一時間看到網頁內容。
- header壓縮。前面提到HTTP1.x的header很多時候都是重複多餘的。選擇合適的壓縮算法可以減小包的大小和數量。
- 基於HTTPS的加密協議傳輸，大大提高了傳輸數據的可靠性。
HTTP 2.0
2015年,HTTP2.0出現. HTTP2.0可以說是SPDY的升級版（其實原本也是基於SPDY設計的)
HTTP2.0 跟 SPDY 的區別
HTTP2.0和HTTP1.0相比的新特性
- 二進制分幀
HTTP 2.0 將所有傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼。
注：HTTPS 是二進制分幀的另一個典型示例：所有HTTP 消息都以透明的方式爲我們編碼和解碼，不必對應用進行任何修改。HTTP2.0工作原理有點類似
流：流是連接中的一個虛擬信道，可以承載雙向的消息；每個流都有一個唯一的整數標識符（1、2 … N）；
消息：是指邏輯上的 HTTP 消息，比如請求、響應等，由一或多個幀組成。
幀：客戶端與服務器通過交換幀來通信，幀是基於這個新協議通信的最小單位。
- 多路複用
多路複用允許同時通過單一的HTTP/2.0 連接發起多重的請求-響應消息。有了新的分幀機制後，HTTP/2.0不再依賴多個TCP 連接去處理更多併發的請求。每個數據流都拆分成很多互不依賴的幀，而這些幀可以交錯（亂序發送），還可以分優先級。最後再在另一端根據每個幀首部的流標識符把它們重新組合起來。HTTP 2.0 連接都是持久化的，而且客戶端與服務器之間也只需要一個連接（每個域名一個連接）即可。
圖中包含了同一個連接上多個傳輸中的數據流：客戶端正在向服務器傳輸一個DATA 幀（stream 5），與此同時，服務器正向客戶端亂序發送stream 1 和stream 3的一系列幀。此時，一個連接上有3 個請求/ 響應並行交換！
把HTTP 消息分解爲獨立的幀，交錯發送(並行連接)，然後在另一端重新組裝是HTTP 2.0 最重要的一項增強。這個機制會在整個Web 技術棧中引發一系列連鎖反應，從而帶來巨大的性能提升。
HTTP 2.0 的二進制分幀機制和多路複用解決了HTTP 1.x 中存在的隊首阻塞問題，也消除了並行處理和發送請求及響應時對多個連接的依賴。
- 每個來源一個連接
大多數HTTP 連接的時間都很短，而且是突發性的，但TCP 只在長時間連接傳輸大塊數據時效率才最高。HTTP 2.0 通過讓所有數據流共用同一個連接，可以更有效地使用TCP 連接。 - 頭部壓縮(HPACK壓縮算法)
HTTP/1.1 的首部帶有大量信息，由於cookie和user agent很容易膨脹，而且每次都要重複發送。HTTP/2.0 要求通訊雙方各自緩存一份首部字段表, 一邊用index mapping table壓縮，一邊編碼，這個table由靜態表和動態表組成, 從而避免了重複傳輸。
http2.0會壓縮首部元數據：在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發送的鍵值對，對於相同的數據，不再通過每次請求和響應發送；“首部表”在http2.0的連接存續期內始終存在，由客戶端和服務器共同漸進地更新；每個新的首部鍵值對要麼追加到當前表的末尾，要麼替換表中之前的值。
請求與響應首部的定義在HTTP2.0中基本沒有改變，只是所有首部鍵必須全部小寫，而且請求行要獨立爲 :method、:scheme、:host、:path這些鍵值對。
- 請求優先級
把HTTP 消息分解爲很多獨立的幀之後，就可以通過優化這些幀的交錯和傳輸順序，每個流都可以帶有一個31 比特的優先值：0 表示最高優先級；2的31次方-1 表示最低優先級。服務器可以根據流的優先級，控制資源分配（CPU、內存、帶寬），而在響應數據準備好之後，優先將最高優先級的幀發送給客戶端。HTTP 2.0 一舉解決了所有這些低效的問題：瀏覽器可以在發現資源時立即分派請求，指定每個流的優先級，讓服務器決定最優的響應次序。這樣請求就不必排隊了，既節省了時間，也最大限度地利用了每個連接。 - 服務端推送server pull
就是服務器可以對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確地請求。服務端推送能把客戶端所需要的資源伴隨着index.html一起發送到客戶端，省去了客戶端重複請求的步驟。正因爲沒有發起請求，建立連接等操作，所以靜態資源通過服務端推送的方式可以極大地提升速度。
HTTP 2.0 連接後，客戶端與服務器交換SETTINGS 幀，藉此可以限定雙向併發的流的最大數量。因此，客戶端可以限定推送流的數量，或者通過把這個值設置爲0 而完全禁用服務器推送。
所有推送的資源都遵守同源策略。換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是經過雙方確認纔行。
PUSH_PROMISE：所有服務器推送流都由PUSH_PROMISE 發端，服務器向客戶端發出的有意推送所述資源的信號。客戶端接收到PUSH_PROMISE 幀之後，可以視自身需求選擇拒絕這個流
相關鏈接
[1] HTTP 0.9 HTTP 1.0 HTTP 1.1 HTTP 2.0區別
[2] http2.0深入理解
[3] HTTP 2.0 協議詳解
[4] http2.0
[5] HTTP1.0、HTTP1.1 和 HTTP2.0 的區別