談談HTTP1.0,HTTP1.1和HTTP2.0區別

>>>點擊獲取更多文章<<<

HTTP定義

HTTP協議（HyperTextTransferProtocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。

HTTP發展史

HTTP的基本優化

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

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

__延遲__：

• 瀏覽器阻塞（HOL blocking）：瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。
• DNS 查詢（DNS Lookup）：瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。
• 創建鏈接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。

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

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

• 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
• 帶寬優化及網絡鏈接的使用，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每次請求都要建立鏈接的缺點。

HTTPS與HTTP的一些區別

• HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
• HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。
• HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
• HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

HTTP 2.0 vs HTTP 1.0 性能

HTTP 2.0 的出現，相比於 HTTP 1.x ，大幅度的提高了 web 性能。

這是 Akamai 公司創建的一個官方的演示，用以說明 HTTP/2 相比於以前的 HTTP/1.1 在性能上的大幅度提高。 同時請求 379 張圖片，從Load time 的對比能夠看出 HTTP/2 在速度上的優點。

HTTP 2.0 和 HTTP1.1 區別

後面咱們將經過幾個方面來講說HTTP 2.0 和 HTTP1.1 區別，而且和你解釋下其中的原理。

區別一：多路複用

多路複用容許單一的 HTTP/2 鏈接同時發起多重的請求-響應消息。看個例子：

整個訪問流程第一次請求index.html頁面,以後瀏覽器會去請求style.css和scripts.js的文件。左邊的圖是順序加載兩個個文件的，右邊則是並行加載兩個文件。

咱們知道HTTP底層其實依賴的是TCP協議，那問題是在同一個鏈接裏面同時發生兩個請求響應着是怎麼作到的？

首先你要知道，TCP鏈接至關於兩根管道（一個用於服務器到客戶端，一個用於客戶端到服務器），管道里面數據傳輸是經過字節碼傳輸，傳輸是有序的，每一個字節都是一個一個來傳輸。

例如客戶端要向服務器發送Hello、World兩個單詞，只能是先發送Hello再發送World，沒辦法同時發送這兩個單詞。否則服務器收到的可能就是HWeolrllod（注意是穿插着發過去了，可是順序仍是不會亂）。這樣服務器就懵b了。

接上面的問題，可否同時發送Hello和World兩個單詞能，固然也是能夠的，能夠將數據拆成包，給每一個包打上標籤。發的時候是這樣的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。這樣到了服務器，服務器根據標籤把兩個單詞區分開來。實際的發送效果以下圖：

要實現上面的效果咱們引入一個新的概念就是：二進制分幀。

二進制分幀層 在 應用層(HTTP/2)和傳輸層(TCP or UDP)之間。HTTP/2並無去修改TCP協議而是儘量的利用TCP的特性。

在二進制分幀層中， HTTP/2 會將全部傳輸的信息分割爲幀（frame）,並對它們採用二進制格式的編碼 ，其中 首部信息會被封裝到 HEADER frame，而相應的 Request Body 則封裝到 DATA frame 裏面。

HTTP 性能優化的__關鍵並不在於高帶寬，而是低延遲__。TCP 鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲 TCP 慢啓動。因爲這種緣由，讓本來就具備突發性和短時性的 HTTP 鏈接變的十分低效。

HTTP/2 經過讓全部數據流共用同一個鏈接，能夠更有效地使用 TCP 鏈接，讓高帶寬也能真正的服務於 HTTP 的性能提高。

經過下面兩張圖，咱們能夠更加深刻的認識多路複用：

HTTP/1

HTTP/2

總結下：多路複用技術：單鏈接多資源的方式，減小服務端的連接壓力,內存佔用更少,鏈接吞吐量更大；因爲減小TCP 慢啓動時間，提升傳輸的速度

區別二：首部壓縮

爲何要壓縮？在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成。通常而言，消息主體都會通過 gzip 壓縮，或者自己傳輸的就是壓縮事後的二進制文件（例如圖片、音頻），但狀態行和頭部卻沒有通過任何壓縮，直接以純文本傳輸。

隨着 Web 功能愈來愈複雜，每一個頁面產生的請求數也愈來愈多，致使消耗在頭部的流量愈來愈多，尤爲是每次都要傳輸 UserAgent、Cookie 這類不會頻繁變更的內容，徹底是一種浪費。

咱們再用通俗的語言解釋下，壓縮的原理。頭部壓縮須要在支持 HTTP/2 的瀏覽器和服務端之間:

• 維護一份相同的靜態字典（Static Table），包含常見的頭部名稱，以及特別常見的頭部名稱與值的組合；
• 維護一份相同的動態字典（Dynamic Table），能夠動態的添加內容；
• 支持基於靜態哈夫曼碼錶的哈夫曼編碼（Huffman Coding）；

靜態字典的做用有兩個：

• 對於徹底匹配的頭部鍵值對，例如 「:method :GET」，能夠直接使用一個字符表示；
• 對於頭部名稱能夠匹配的鍵值對，例如 「cookie :xxxxxxx」，能夠將名稱使用一個字符表示。

HTTP/2 中的靜態字典以下（如下只截取了部分，完整表格在這裏）：

同時，瀏覽器和服務端均可以向動態字典中添加鍵值對，以後這個鍵值對就可使用一個字符表示了。須要注意的是，動態字典上下文有關，須要爲每一個 HTTP/2 鏈接維護不一樣的字典。在傳輸過程當中使用，使用字符代替鍵值對大大減小傳輸的數據量。

區別三：HTTP2支持服務器推送

服務端推送是一種在客戶端請求以前發送數據的機制。當代網頁使用了許多資源:HTML、樣式表、腳本、圖片等等。在HTTP/1.x中這些資源每個都必須明確地請求。這多是一個很慢的過程。瀏覽器從獲取HTML開始，而後在它解析和評估頁面的時候，增量地獲取更多的資源。由於服務器必須等待瀏覽器作每個請求，網絡常常是空閒的和未充分使用的。

爲了改善延遲，HTTP/2引入了server push，它容許服務端推送資源給瀏覽器，在瀏覽器明確地請求以前。一個服務器常常知道一個頁面須要不少附加資源，在它響應瀏覽器第一個請求的時候，能夠開始推送這些資源。這容許服務端去徹底充分地利用一個可能空閒的網絡，改善頁面加載時間。