HTTP1.0、HTTP1.1 和 HTTP2.0 的區別

文章轉自(https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A)

 

 

做者 | 一隻好奇的茂

地址 | http://www.jianshu.com/p/be29d679cbff

聲明 | 本文是 一隻好奇的茂 原創，已獲受權發佈，未經原做者容許請勿轉載

 

 

1、HTTP的歷史

早在 HTTP 創建之初，主要就是爲了將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。也是說對於前端來講，咱們所寫的HTML頁面將要放在咱們的 web 服務器上，用戶端經過瀏覽器訪問url地址來獲取網頁的顯示內容，可是到了 WEB2.0 以來，咱們的頁面變得複雜，不只僅單純的是一些簡單的文字和圖片，同時咱們的 HTML 頁面有了 CSS，Javascript，來豐富咱們的頁面展現，當 ajax 的出現，咱們又多了一種向服務器端獲取數據的方法，這些其實都是基於 HTTP 協議的。一樣到了移動互聯網時代，咱們頁面能夠跑在手機端瀏覽器裏面，可是和 PC 相比，手機端的網絡狀況更加複雜，這使得咱們開始了不起不對 HTTP 進行深刻理解並不斷優化過程當中。

 

 

2、HTTP的基本優化

影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。

• 帶寬：若是說咱們還停留在撥號上網的階段，帶寬可能會成爲一個比較嚴重影響請求的問題，可是如今網絡基礎建設已經使得帶寬獲得極大的提高，咱們再也不會擔憂由帶寬而影響網速，那麼就只剩下延遲了。

• 延遲：

• 瀏覽器阻塞（HOL blocking）：瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。

• DNS 查詢（DNS Lookup）：瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。

• 創建鏈接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。

   

3、HTTP1.0和HTTP1.1的一些區別

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

1. 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

2. 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

3. 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

4. Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。

5. 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

    

4、HTTPS與HTTP的一些區別

• HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。

• HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。

• HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

• HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

 

 

5、SPDY：HTTP1.x的優化

2012年google如一聲驚雷提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體以下：

1. 下降延遲，針對HTTP高延遲的問題，SPDY優雅的採起了多路複用（multiplexing）。多路複用經過多個請求stream共享一個tcp鏈接的方式，解決了HOL blocking的問題，下降了延遲同時提升了帶寬的利用率。

2. 請求優先級（request prioritization）。多路複用帶來一個新的問題是，在鏈接共享的基礎之上有可能會致使關鍵請求被阻塞。SPDY容許給每一個request設置優先級，這樣重要的請求就會優先獲得響應。好比瀏覽器加載首頁，首頁的html內容應該優先展現，以後纔是各類靜態資源文件，腳本文件等加載，這樣能夠保證用戶能第一時間看到網頁內容。

3. header壓縮。前面提到HTTP1.x的header不少時候都是重複多餘的。選擇合適的壓縮算法能夠減少包的大小和數量。

4. 基於HTTPS的加密協議傳輸，大大提升了傳輸數據的可靠性。

5. 服務端推送（server push），採用了SPDY的網頁，例如個人網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就能夠直接從緩存中獲取到，不用再發請求了。SPDY構成圖：

 

 

SPDY位於HTTP之下，TCP和SSL之上，這樣能夠輕鬆兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可使用已有的SSL功能。

 

6、HTTP2.0性能驚人

HTTP/2: the Future of the Internet https://link.zhihu.com/?target=https://http2.akamai.com/demo 是 Akamai 公司創建的一個官方的演示，用以說明 HTTP/2 相比於以前的 HTTP/1.1 在性能上的大幅度提高。 同時請求 379 張圖片，從Load time 的對比能夠看出 HTTP/2 在速度上的優點。

 

 

7、HTTP2.0：SPDY的升級版

HTTP2.0能夠說是SPDY的升級版（其實本來也是基於SPDY設計的），可是，HTTP2.0 跟 SPDY 仍有不一樣的地方，以下：

HTTP2.0和SPDY的區別：

1. HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS

2. HTTP2.0 消息頭的壓縮算法採用 HPACK http://http2.github.io/http2-spec/compression.html，而非 SPDY 採用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE

 

8、HTTP2.0和HTTP1.X相比的新特性

• 新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少，二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。

• 多路複用（MultiPlexing），即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的 id將request再歸屬到各自不一樣的服務端請求裏面。

• header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

• 服務端推送（server push），同SPDY同樣，HTTP2.0也具備server push功能。

   

9、HTTP2.0的升級改造

• 前文說了HTTP2.0其實能夠支持非HTTPS的，可是如今主流的瀏覽器像chrome，firefox表示仍是隻支持基於 TLS 部署的HTTP2.0協議，因此要想升級成HTTP2.0仍是先升級HTTPS爲好。

• 當你的網站已經升級HTTPS以後，那麼升級HTTP2.0就簡單不少，若是你使用NGINX，只要在配置文件中啓動相應的協議就能夠了，能夠參考NGINX白皮書，NGINX配置HTTP2.0官方指南 https://www.nginx.com/blog/nginx-1-9-5/。

• 使用了HTTP2.0那麼，本來的HTTP1.x怎麼辦，這個問題其實不用擔憂，HTTP2.0徹底兼容HTTP1.x的語義，對於不支持HTTP2.0的瀏覽器，NGINX會自動向下兼容的。

 

10、附註

HTTP2.0的多路複用和HTTP1.X中的長鏈接複用有什麼區別？

• HTTP/1.* 一次請求-響應，創建一個鏈接，用完關閉；每個請求都要創建一個鏈接；

• HTTP/1.1 Pipeling解決方式爲，若干個請求排隊串行化單線程處理，後面的請求等待前面請求的返回才能得到執行機會，一旦有某請求超時等，後續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；

• HTTP/2多個請求可同時在一個鏈接上並行執行。某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行；
  具體如圖：

   

 

服務器推送究竟是什麼？
服務端推送能把客戶端所須要的資源伴隨着index.html一塊兒發送到客戶端，省去了客戶端重複請求的步驟。正由於沒有發起請求，創建鏈接等操做，因此靜態資源經過服務端推送的方式能夠極大地提高速度。具體以下：

• 普通的客戶端請求過程：

 

• 服務端推送的過程：

 

 

 

爲何須要頭部壓縮？
假定一個頁面有100個資源須要加載（這個數量對於今天的Web而言仍是挺保守的）, 而每一次請求都有1kb的消息頭（這一樣也並很多見，由於Cookie和引用等東西的存在）, 則至少須要多消耗100kb來獲取這些消息頭。HTTP2.0能夠維護一個字典，差量更新HTTP頭部，大大下降因頭部傳輸產生的流量。具體參考：HTTP/2 頭部壓縮技術介紹

 

HTTP2.0多路複用有多好？
HTTP 性能優化的關鍵並不在於高帶寬，而是低延遲。TCP 鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲 TCP 慢啓動。因爲這種緣由，讓本來就具備突發性和短時性的 HTTP 鏈接變的十分低效。
HTTP/2 經過讓全部數據流共用同一個鏈接，能夠更有效地使用 TCP 鏈接，讓高帶寬也能真正的服務於 HTTP 的性能提高。

 

11、參考

HTTP/2.0 相比1.0有哪些重大改進？深刻研究：HTTP2 的真正性能到底如何HTTP/2 頭部壓縮技術介紹