HTTP/2.0的前世此生

前記

http協議是前端常常打交道的協議之一,發展至今已經到了2.0版本,這兩天我刷完了《圖解HTTP》,讓我對與HTTP協議的發展史有了更深層的瞭解html

萬維網的出現和HTTP的誕生

時間要回到1989年的聖誕節,那一天李爵士發明了世界上第一個網頁瀏覽器WorldWideWeb(同時也是網頁編輯器)和第一個網頁服務器。爲了在網頁瀏覽器和網頁服務器中傳輸文本信息,李爵士將超文本嫁接到因特網上(超文本的概念並非李爵士提出來的),由此誕生了超文本標記語言(HTML)前端

爲了在萬維網中發佈和接收HTML,李爵士發明了超文本傳輸協議協議,也就是HTTP的誕生web

最初的HTTP/0.9

1991年,李爵士發佈文章標誌着萬維網公共項目的開始。在創建HTTP標準規範時,制定者主要想把HTTP看成傳輸HTML文檔的協議,因此起初的協議很是簡單。瀏覽器

請求由單行指令構成,以惟一可用方法GET開頭,其後跟目標資源的路徑(一旦鏈接到服務器,協議、服務器、端口號這些都不是必須的)。緩存

GET /mypage.html安全

響應也極其簡單的:只包含響應文檔自己。bash

<HTML>這是一個很是簡單的HTML頁面</HTML>服務器

跟後來的版本不一樣,HTTP/0.9的響應內容並不包含HTTP頭,這意味着只有HTML文件能夠傳送,沒法傳輸其餘類型的文件;也沒有狀態碼或錯誤代碼:一旦出現問題,一個特殊的包含問題描述信息的HTML文件將被髮回,供人們查看。網絡

這時的HTTP協議,服務器發送完畢後就會關閉TCP鏈接編輯器

升級以後的HTTP/1.0

因爲 HTTP/0.9 協議的應用十分有限,瀏覽器和服務器的迅速發展和擴展,使其已經不可以知足須要,因此,1996年5月,HTTP協議的1.0版本發佈,此次發佈的內容並無被歸入標準,而是爲1.1版本的構建可擴展性的嘗試,更新的內容也很是多,主要有

  • 協議版本信息如今會隨着每一個請求發送(HTTP/1.0被追加到了GET行)
  • 狀態碼會在響應開始時發送,使瀏覽器能瞭解請求執行成功或失敗,並相應調整行爲(如更新或使用本地緩存)
  • 引入了HTTP頭的概念,不管是對於請求仍是響應,容許傳輸元數據,使協議變得很是靈活,更具擴展性
  • 在新HTTP頭的幫助下,具有了傳輸除純文本HTML文件之外其餘類型文檔的能力(感謝Content-Type頭)

此時,HTTP的請求已經變成這樣了

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
複製代碼

響應變成了這樣

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>
複製代碼

此時的HTTP協議已經初具雛形,和咱們如今看到的很是像,這是第一個在通信中指定版本號的HTTP協議版本,至今仍被普遍採用,可是它並非沒有問題的,它仍然存在着0.9版本的問題,就是TCP鏈接不能夠複用,每次發送請求都須要創建TCP鏈接,新建成本高,還須要發送前的預熱。因此HTTP/1.0性能較差,爲了解決這個問題,有些瀏覽器在發送請求時,使用了一個非標準的Connection字段。

Connection: keep-alive
複製代碼

服務器不關閉TCP鏈接,以便其餘請求複用,一樣回覆

Connection: keep-alive
複製代碼

一個能夠複用的TCP鏈接就創建了,直到客戶端或服務器主動關閉鏈接。可是,這不是標準字段,不一樣實現的行爲可能不一致,所以不是根本的解決辦法。

標準的誕生HTTP/1.1

就在HTTP/1.0發佈的幾個月後,HTTP/1.1就誕生了,此次版本它進一步完善了HTTP協議,哪怕到今天都是最流行的協議之一

HTTP/1.1 消除了大量歧義內容並引入了多項改進:

  • 鏈接能夠複用,節省了屢次打開TCP鏈接加載網頁文檔資源的時間。
  • 增長流水線操做,容許在第一個應答被徹底發送以前就發送第二個請求,以下降通訊延遲。
  • 支持響應分塊。
  • 引入額外的緩存控制機制。
  • 引入內容協商機制,包括語言,編碼,類型等,並容許客戶端和服務器之間約定以最合適的內容進行交換。
  • 感謝Host頭,可以使不一樣域名配置在同一個IP地址的服務器上。

已經發展到這個時候,那麼協議完美了嗎

事實上並無,雖然能夠複用TCP鏈接,而且能夠在一個鏈接中同時發送多個HTTP請求,可是服務端的處理是按順序的,這就形成一個請求阻塞了,那麼後面的全部請求的響應都會阻塞,這稱爲"隊頭堵塞"(Head-of-line blocking)

解決方法一是減小請求數,二是同時多開持久鏈接。但通常瀏覽器最多同時創建六個TCP鏈接

消除HTTP瓶頸的SPDY

隨着時代的發展,web的用途開始變得多種多樣,好比在線購物網站、社交網絡服務、企業或組織內部的各類管理工具,等等

雖然這些功能已經經過web應用和腳本程序實現,但在性能上未必最優,這是由於HTTP協議上的限制以及自身性能有限。

如下這些HTTP標準就會成爲瓶頸

  • 一條鏈接上服務端只能夠返回一個請求
  • 請求只能從客戶端開始,客戶端不能夠接收除響應之外的指令
  • 請求/響應首部未經壓縮就發送。首部信息越多延遲越大
  • 發送冗長的首部。每次互相發送相同的首部形成的浪費較多
  • 可任意選擇數據壓縮格式。非強制壓縮發送

HTTP的功能不足能夠經過建立一套全新的協議來彌補,但是目前基於HTTP協議的web瀏覽器已經遍及全球,所以沒法徹底拋棄HTTP,有一些新協議的規則是基於HTTP的,並在此基礎上添加了新的功能

Google在2010年發佈了SPDY,其開發目標旨在解決HTTP的性能瓶頸,縮短Web頁面的加載時間(50%)

SPDY沒有徹底改寫HTTP協議,而是在應用層和傳輸層之間經過新加會話層的形式運做。同時,考慮到安全性問題,SPDY規定通訊中使用SSL。

SPDY仍是採用HTTP創建通訊鏈接。所以仍是可使用HTTP的GET或POST等方法、Cookie以及HTTP報文等。

HTTP得到了如下額外的功能

  • 多路複用流
  • 賦予請求優先級
  • 壓縮HTTP首部
  • 推送功能
  • 服務器提示功能

SPDY解決了部分問題,可是並無從根本解決問題。

但這個協議在Chrome瀏覽器上證實可行之後,就被看成 HTTP/2 的基礎,主要特性都在 HTTP/2 之中獲得繼承。

期盼的HTTP/2.0的誕生

HTTP/2.0的目標是改善用戶在使用Web時的速度體驗

對比HTTP/1.1,改善有以下幾點

  • HTTP/2是二進制協議而不是文本協議。它不能再手動讀取和建立,改善的優化技術如今可被實施。
  • 這是一個複用協議。並行的請求能在同一個連接中處理,移除了HTTP/1.x中順序和阻塞的約束。
  • 頭部壓縮,由於headers在一系列請求中經常是類似的,其移除了重複和傳輸重複數據的成本。
  • 其容許服務器在客戶端緩存中填充數據,經過一個叫服務器推送的機制來提早請求。

參考資料

阮一峯博客 MDN 《圖解HTTP》

相關文章
相關標籤/搜索