HTTP協議：HTTP1.0、HTTP1.一、HTTP2.0對比

時間 2019-12-28

標籤 http 協議 http1.0 http1 http2.0 對比欄目 HTTP/TCP 简体版

原文原文鏈接

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

對比

	HTTP1.0	HTTP1.1	HTTP2.0
Host頭	✗	✔	✔
Range頭	✗	✔	✔
長鏈接	✗	✔	✔
request method	GET HEAD POST	以上+ OPTIONS PUT DELETE TRACE CONNECT	以上所有
cache	Expire Last-Modefied Pragma	以上+ETag Cache-Control	以上所有
header壓縮	✗	✗	✔
多路複用	✗	✗	✔
服務器推送	✗	✗	✔

解析

咱們這裏主要選取了幾個點來進行分析前端

Range

這裏的Range 和 Content-Range 是針對於HTTP1.0的寬帶浪費現象而提出來的一個解決方案。nginx

在這裏，咱們接觸的最多的即是斷點續傳了，咱們在請求下載某一個較大文件的時候，秉着耐心終於等到了99%了，可是這時候卻忽然斷網了，若是再讓你等待幾十分鐘去等待他從新下載完成，咱們估計都要爆發了，而若是客戶端，知道本地已經下了99%，只去請求服務端剩餘的部分，這樣不只節約了用戶的時間，還解決了服務器傳輸多餘的重複數據而致使的寬帶浪費web

長鏈接

一個web頁面上面可能包含幾十個圖片文件或js、css文件，在HTTP1.0的時代，規定了瀏覽器與服務器只能保持短暫的鏈接，瀏覽器的每一個請求都要與服務器創建一個新的TCP鏈接，TCP的鏈接須要三次握手，https還須要校驗證書，那麼問題就暴漏出來了，這幾十次圖片、js、css文件實際上是在同一個web頁面裏面的，若是咱們去除多餘的幾十次三次握手，那麼訪問速度就會提高上來，HTTP1.1使用了長鏈接來解決這個問題，咱們能夠配置後臺服務器的長鏈接的時間，超時無內容傳輸纔會斷開鏈接，從而，在必定時間內的瀏覽器的請求可使用同一個TCP鏈接或者幾個TCP鏈接，減小了握手帶來的時間損耗ajax

多路複用

既然上面解析了長鏈接，這裏就把多路複用提上來吧。HTTP2.0使用了多路複用的技術，作到同一個鏈接併發處理多個請求，並且併發請求的數量比HTTP1.1大了好幾個數量級。算法

以chrome爲例，每一個頁面，瀏覽器最多容許創建6個TCP鏈接，發起請求->服務端處理->響應請求這樣算是完成了一個瀏覽器請求。可是若是一個頁面同時發起幾百個請求，其中前幾個請求又比較耗時，則會把這6個TCP鏈接所有佔用，同時阻塞了後面的請求，這樣總體請求都會慢下來了。chrome

HTTP2採用多路複用是指，在同一個域名下，開啓一個TCP的connection，每一個請求以stream的方式傳輸，每一個stream有惟一標識，connection一旦創建，後續的請求均可以複用這個connection而且能夠同時發送，server端能夠根據stream的惟一標識來相應對應的請求。這樣上面請求阻塞的問題就能夠獲得解決。瀏覽器

服務器推送

意思是說，當咱們對支持HTTP2.0的web server請求數據的時候，服務器會順便把一些客戶端須要的資源一塊兒推送到客戶端，省得客戶端再次建立鏈接發送請求到服務器端獲取。這種方式很是合適加載靜態資源。服務器

header壓縮

咱們在傳輸文本等靜態資源的時候，通常會開啓壓縮，gzip等，這樣會減小寬帶的佔用，對於一些較大的文本文件，壓縮後會減小的特別明顯，相應也會感受提高了不少。而header頭信息的傳輸卻一直使用字符串來傳輸，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。網絡