HTTP2.0探究

　

      http1.1和http2.0在請求379張圖片的對比演示（HTTP2.0性能驚人）。

 

  　HTTP2.0是HTTP協議自1999年HTTP1.1發佈後的首個更新，主要基於SPDY（讀speedy）。  該協議在2015年以RFC 7540正式發表 。

　　

基本介紹

HTTP/1.1 時代

HTTP/1.1 對 HTTP/1.0 作了許多優化，也是當今使用得最多的 HTTP 協議：

1. 持久化鏈接（keep-alive）以支持鏈接重用
2. 分塊傳輸編碼（chunked）以支持流式響應
3. 請求管道以支持並行請求處理
4. 字節服務以支持基於範圍的資源請求
5. 改進的更好的緩存機制

　　 這裏所說的持久連接是指：在HTTP1.0時代，每個請求都會從新創建一個TCP鏈接，一旦相應返回，就關閉連接，而創建一個連接，須要進行三次握手，這極大的浪費了性能。而HTTP1.1新增了【keep-alive】功能，當瀏覽器創建一個TCP連接時，多個請求都會使用這個鏈接。 （如今大多數瀏覽器都是默認開啓的。）　　

　　而咱們所說的pipeLining管道是解決另外一個問題：在TCP連接中，同一時間內只可以發送一個請求，而且須要等到響應完成以後才能發送第二個請求。所以HTTP/1.1制定了Pipelining管道，經過這個管道，瀏覽器的多個請求能夠同時發送到服務器，可是服務器的響應只能一個接着一個的返回（可是各大瀏覽器不支持/默認關閉，因此這個功能就是雞肋了）。 

　　 因此，因爲雞肋的功能，最終HTTP/1.1仍是一條連接只能返回一個響應，所以瀏覽器爲了改善這種狀況，會同時開啓4~8個TCP連接進行發送請求。

　　

如何使用上 HTTP/2.0

1. 須要瀏覽器的支持，目前最新版的 Chrome、Opera、 FireFox、 IE十一、 edge 都已經支持了
2. 須要 WEB 服務器的支持，好比 Nginx , H20

　　若是瀏覽器或服務器有一方不支持，那麼會自動變成 Http/1.1

 

HTTP的基本優化

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

• 帶寬：若是說咱們還停留在撥號上網的階段，帶寬可能會成爲一個比較嚴重影響請求的問題，可是如今網絡基礎建設已經使得帶寬獲得極大的提高，咱們再也不會擔憂由帶寬而影響網速，那麼就只剩下延遲了。
• 延遲：
  1. 瀏覽器阻塞（HOL blocking）：瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。
  2.  DNS 查詢（DNS Lookup）：瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。
  3.  創建鏈接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。

 

 

　　一、鏈接和拼接

　　連接或者拼接JS和CSS文件，雪碧圖，以減小HTTP請求，同時瀏覽器能夠緩存這些靜態資源，爲下次訪問節約時間。可是這樣帶來的反作用是，維護成本高，其中某一個小改動都會使得整個拼接後的文件發生改變，從新緩存。

　　固然並非說無止境的拼接，建議大小爲： 30~50 KB

　　

　　

　    二、域名分區

　　因爲瀏覽器的限制，同一個域下最多隻能創建6個鏈接。咱們一般使用子域名來減小全部資源在只有一個鏈接時的產生的排隊延遲。

 

　　

　　三、資源內嵌

　　對於不經常使用的，較小大資源內嵌在文檔中，好比base64的圖片，以減小HTTP請求，可是這樣的資源不能在瀏覽器中緩存，也不可能被其餘頁面共享，同時還有可能編碼以後的資源變等更大了。

 

 

SPDY 時代

　　因爲現代網頁的不斷豐富， HTTP/1.1 協議的性能也逐漸吃不消，所以2012年google如一聲驚雷提出了SPDY的方案，實際上，HTTP/2.0 也是以 SPDY 做爲原型進行開發的。

　　

SPDY基礎功能

多路複用（multiplexing)

多路複用經過多個請求stream共享一個tcp鏈接的方式，解決了http1.x holb（head of line blocking）的問題，下降了延遲同時提升了帶寬的利用率。

請求優先級（request prioritization)

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

header壓縮

前面提到過幾回http1.x的header不少時候都是重複多餘的。選擇合適的壓縮算法能夠減少包的大小和數量。SPDY對header的壓縮率能夠達到80%以上，低帶寬環境下效果很大。

SPDY 現已經被大多數瀏覽器以及 WEB 服務器所支持，但爲了推動 HTTP/2.0, Google 已經宣佈在 2016年對其中止開發。

 

 

HTTP/2.0 時代

二進制分幀

在應用層與傳輸層之間增長一個二進制分幀層，以此達到「在不改動HTTP的語義，HTTP 方法、狀態碼、URI及首部字段的狀況下，突破HTTP1.1的性能限制，改進傳輸性能，實現低延遲和高吞吐量。」

在二進制分幀層上，HTTP2.0會將全部傳輸的信息分割爲更小的消息和幀,並對它們採用二進制格式的編碼，其中HTTP1.x的首部信息會被封裝到Headers幀，而咱們的request body則封裝到Data幀裏面。

 

壓縮頭部

HTTP/2.0規定了在客戶端和服務器端會使用而且維護「首部表」來跟蹤和存儲以前發送的鍵值對，對於相同的頭部，沒必要再經過請求發送，只需發送一次

事實上,若是請求中不包含首部（例如對同一資源的輪詢請求），那麼首部開銷就是零字節。此時全部首部都自動使用以前請求發送的首部。

若是首部發生變化了，那麼只須要發送變化了數據在Headers幀裏面，新增或修改的首部幀會被追加到「首部表」。首部表在 HTTP2.0的鏈接存續期內始終存在,由客戶端和服務器共同漸進地更新。

 

 

多路複用

　　HTTP/2.0 時代擁有了「多路複用」功能，意思是: 在一條鏈接上，我能夠同時發起無數個請求，而且響應能夠同時返回。（這個難點終於被解決了)

 

 

客戶端和服務器能夠把HTTP消息分解爲互不依賴的幀，而後亂序發送，最後再在另外一端把它們從新組合起來。注意，同一連接上有多個不一樣方向的數據流在傳輸。客戶端能夠一邊亂序發送stream，也能夠一邊接收者服務器的響應，而服務器那端同理。

注意，對一個域名，只須要開啓一條 TCP 鏈接，請求都在這條 TCP 鏈接上幹活。

所以在 HTTP/2.0 時代，以前的合併 JS、CSS 文件技巧，反而不適用了。

 

 

請求優先級

　　既然全部資源都是並行發送，那麼就須要「優先級」的概念了，這樣就能夠對重要的文件進行先傳輸，加速頁面的渲染。

 

 

服務器推送

　　在 HTTP2.0中，服務器推送是指在客戶端請求以前發送數據的機制。若是一個請求是由你的主頁發起的，服務器極可能響應主頁內容、logo以及樣式表，由於它知道客戶端會用到這些東西。這至關於在一個 HTML 文檔內集合了全部的資源，不過與之相比，服務器推送有一個很大的優點：能夠緩存！

 

　　

強制 SSL

　　雖然 HTTP/2.0 協議並沒聲明必定要用 SSL，可是 Google Chrome 等瀏覽器強制要求使用 HTTP/2.0 必需要用上 SSL， 也就是說必需要： https://

 

對優化的影響：

1. 由於「全部的HTTP2.0的請求都在一個TCP連接上」，「資源合併減小請求」，好比CSS Sprites,多個JS文件、CSS文件合併等手段沒有效果，或者說沒有必要。
2. 由於「多路複用」，採用「cdn1.cn,cdn2.cn,cdn3.cn，打開多個TCP會話，突破瀏覽器對同一域名的連接數的限制」的手段是沒有必要的。由於由於資源都是並行交錯發送，且沒有限制，不須要額外的多域名並行下載。
3. 由於「服務器推送」，內嵌資源的優化手段也變得沒有意義了。並且使用服務器推送的資源的方式更加高效，由於客戶端還能夠緩存起來，甚至能夠由不一樣的頁面共享（依舊遵循同源策略）

 

 

 

HTTP2.0與SPDY的區別

　　SPDY是谷歌公司2012年推出的一個新的協議，而HTTP2.0是基於SPDY的協議，因此HTTP2.0是SPDY的升級版！  因此，二者必然有不一樣之處。

• 新的二進制形式。 HTTP1.x的解析是基於文本。而基於文本協議的格式解析自然就存在缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景不少 ，即要考慮不少；而二進制形式則不一樣，只認0和1的組合，因此這種協議解析實現方便並且健壯 。
• 多路複用。 即連接共享，每個request都是用連接共享機制的， 一個request對應一個id，這樣一個鏈接上能夠有多個request， 每一個連接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的id將request再歸屬到不一樣的服務器請求了。
• header壓縮。HTTP2.0經過HPACK進行壓縮，這種壓縮方法是特地爲HTTP2.0設定的。
• 服務器推送。同SPDY同樣，HTTP2.0也具備server push功能。

 

 

 

爲何須要頭部壓縮？

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

 

HTTP2.0多路複用有多好？

以前就提到了，http性能取決於帶寬和延遲連個方面，如今帶寬已經很好了，幾乎再也不是阻礙，真正的阻礙是延遲！   HTTP 性能優化的關鍵並不在於高帶寬，而是低延遲。TCP 鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲 TCP 慢啓動。因爲這種緣由，讓本來就具備突發性和短時性的 HTTP 鏈接變的十分低效。HTTP/2 經過讓全部數據流共用同一個鏈接，能夠更有效地使用 TCP 鏈接，讓高帶寬也能真正的服務於 HTTP 的性能提高。

 

 

 

參考文章： HTTP2.0簡單總結 、HTTP1.0/1.1/2.0的區別