HTTP1.0、HTTP1.1和HTTP2.0的區(qū)別

一、HTTP的歷史

早在HTTP建立之初,主要就是為了將超文本標(biāo)記語言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器。也是說對(duì)于前端來說,我們所寫的HTML頁面將要放在我們的web服務(wù)器上,用戶端通過瀏覽器訪問url地址來獲取網(wǎng)頁的顯示內(nèi)容,但是到了WEB2.0以來,我們的頁面變得復(fù)雜,不僅僅單純的是一些簡單的文字和圖片,同時(shí)我們的HTML頁面有了CSS,Javascript,來豐富我們的頁面展示,當(dāng)ajax的出現(xiàn),我們又多了一種向服務(wù)器端獲取數(shù)據(jù)的方法,這些其實(shí)都是基于HTTP協(xié)議的。同樣到了移動(dòng)互聯(lián)網(wǎng)時(shí)代,我們頁面可以跑在手機(jī)端瀏覽器里面,但是和PC相比,手機(jī)端的網(wǎng)絡(luò)情況更加復(fù)雜,這使得我們開始了不得不對(duì)HTTP進(jìn)行深入理解并不斷優(yōu)化過程中。


二、HTTP的基本優(yōu)化

影響一個(gè)HTTP網(wǎng)絡(luò)請(qǐng)求的因素主要有兩個(gè):帶寬和延遲。
帶寬
如果說我們還停留在撥號(hào)上網(wǎng)的階段,帶寬可能會(huì)成為一個(gè)比較嚴(yán)重影響請(qǐng)求的問題,但是現(xiàn)在網(wǎng)絡(luò)基礎(chǔ)建設(shè)已經(jīng)使得帶寬得到極大的提升,我們不再會(huì)擔(dān)心由帶寬而影響網(wǎng)速,那么就只剩下延遲了。
延遲

  • 瀏覽器阻塞(HOL blocking):瀏覽器會(huì)因?yàn)橐恍┰蜃枞?qǐng)求。瀏覽器對(duì)于同一個(gè)域名,同時(shí)只能有 4 個(gè)連接(這個(gè)根據(jù)瀏覽器內(nèi)核不同可能會(huì)有所差異),超過瀏覽器最大連接數(shù)限制,后續(xù)請(qǐng)求就會(huì)被阻塞。
  • DNS 查詢(DNS Lookup):瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接。將域名解析為 IP 的這個(gè)系統(tǒng)就是 DNS。這個(gè)通常可以利用DNS緩存結(jié)果來達(dá)到減少這個(gè)時(shí)間的目的。
  • 建立連接(Initial connection):HTTP 是基于 TCP 協(xié)議的,瀏覽器最快也要在第三次握手時(shí)才能捎帶 HTTP 請(qǐng)求報(bào)文,達(dá)到真正的建立連接,但是這些連接無法復(fù)用會(huì)導(dǎo)致每次請(qǐng)求都經(jīng)歷三次握手和慢啟動(dòng)。三次握手在高延遲的場(chǎng)景下影響較明顯,慢啟動(dòng)則對(duì)文件類大請(qǐng)求影響較大。

三、HTTP1.0和HTTP1.1的一些區(qū)別

HTTP1.0最早在網(wǎng)頁中使用是在1996年,那個(gè)時(shí)候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)請(qǐng)求上,而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請(qǐng)求中,同時(shí)HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議。 主要區(qū)別主要體現(xiàn)在:

  1. ** 緩存處理**,在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn),HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
  2. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用,HTTP1.0中,存在一些浪費(fèi)帶寬的現(xiàn)象,例如客戶端只是需要某個(gè)對(duì)象的一部分,而服務(wù)器卻將整個(gè)對(duì)象送過來了,并且不支持?jǐn)帱c(diǎn)續(xù)傳功能,HTTP1.1則在請(qǐng)求頭引入了range頭域,它允許只請(qǐng)求資源的某個(gè)部分,即返回碼是206(Partial Content),這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
  3. 錯(cuò)誤通知的管理,在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼,如409(Conflict)表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突;410(Gone)表示服務(wù)器上的某個(gè)資源被永久性的刪除。
  4. Host頭處理,在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址,因此,請(qǐng)求消息中的URL并沒有傳遞主機(jī)名(hostname)。但隨著虛擬主機(jī)技術(shù)的發(fā)展,在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)(Multi-homed Web Servers),并且它們共享一個(gè)IP地址。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域,且請(qǐng)求消息中如果沒有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤(400 Bad Request)。
  5. 長連接,HTTP 1.1支持長連接(PersistentConnection)和請(qǐng)求的流水線(Pipelining)處理,在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng),減少了建立和關(guān)閉連接的消耗和延遲,在HTTP1.1中默認(rèn)開啟Connection: keep-alive,一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)。

四、HTTPS與HTTP的一些區(qū)別

  1. HTTPS協(xié)議需要到CA申請(qǐng)證書,一般免費(fèi)證書很少,需要交費(fèi)。
  2. HTTP協(xié)議運(yùn)行在TCP之上,所有傳輸?shù)膬?nèi)容都是明文,HTTPS運(yùn)行在SSL/TLS之上,SSL/TLS運(yùn)行在TCP之上,所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。
  3. HTTP和HTTPS使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
  4. HTTPS可以有效的防止運(yùn)營商劫持,解決了防劫持的一個(gè)大問題。


五、SPDY:HTTP1.x的優(yōu)化

2012年google如一聲驚雷提出了SPDY的方案,優(yōu)化了HTTP1.X的請(qǐng)求延遲,解決了HTTP1.X的安全性,具體如下:

  1. 降低延遲,針對(duì)HTTP高延遲的問題,SPDY優(yōu)雅的采取了多路復(fù)用(multiplexing)。多路復(fù)用通過多個(gè)請(qǐng)求stream共享一個(gè)tcp連接的方式,解決了HOL blocking的問題,降低了延遲同時(shí)提高了帶寬的利用率。
  2. 請(qǐng)求優(yōu)先級(jí)(request prioritization)。多路復(fù)用帶來一個(gè)新的問題是,在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí),這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁,首頁的html內(nèi)容應(yīng)該優(yōu)先展示,之后才是各種靜態(tài)資源文件,腳本文件等加載,這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁內(nèi)容。
  3. header壓縮。前面提到HTTP1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。
  4. 基于HTTPS的加密協(xié)議傳輸,大大提高了傳輸數(shù)據(jù)的可靠性。
  5. 服務(wù)端推送(server push),采用了SPDY的網(wǎng)頁,例如我的網(wǎng)頁有一個(gè)sytle.css的請(qǐng)求,在客戶端收到sytle.css數(shù)據(jù)的同時(shí),服務(wù)端會(huì)將sytle.js的文件推送給客戶端,當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到,不用再發(fā)請(qǐng)求了。SPDY構(gòu)成圖:

    SPDY位于HTTP之下,TCP和SSL之上,這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式),同時(shí)可以使用已有的SSL功能。

六、HTTP2.0性能驚人

HTTP/2: the Future of the Internet 是 Akamai 公司建立的一個(gè)官方的演示,用以說明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同時(shí)請(qǐng)求 379 張圖片,從Load time 的對(duì)比可以看出 HTTP/2 在速度上的優(yōu)勢(shì)。

七、HTTP2.0:SPDY的升級(jí)版

HTTP2.0可以說是SPDY的升級(jí)版(其實(shí)原本也是基于SPDY設(shè)計(jì)的),但是,HTTP2.0 跟 SPDY 仍有不同的地方,如下:
HTTP2.0和SPDY的區(qū)別:

  1. HTTP2.0 支持明文 HTTP 傳輸,而 SPDY 強(qiáng)制使用 HTTPS
  2. HTTP2.0 消息頭的壓縮算法采用 HPACK,而非 SPDY 采用的 DEFLATE

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

  1. 新的二進(jìn)制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本協(xié)議的格式解析存在天然缺陷,文本的表現(xiàn)形式有多樣性,要做到健壯性考慮的場(chǎng)景必然很多,二進(jìn)制則不同,只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式,實(shí)現(xiàn)方便且健壯。
  2. 多路復(fù)用(MultiPlexing),即連接共享,即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id,這樣一個(gè)連接上可以有多個(gè)request,每個(gè)連接的request可以隨機(jī)的混雜在一起,接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面。
  3. header壓縮,如上文中所言,對(duì)前面提到過HTTP1.x的header帶有大量信息,而且每次都要重復(fù)發(fā)送,HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小,通訊雙方各自cache一份header fields表,既避免了重復(fù)header的傳輸,又減小了需要傳輸?shù)拇笮 ?/li>
  4. 服務(wù)端推送(server push),同SPDY一樣,HTTP2.0也具有server push功能。

九、HTTP2.0的升級(jí)改造

  1. 前文說了HTTP2.0其實(shí)可以支持非HTTPS的,但是現(xiàn)在主流的瀏覽器像chrome,firefox表示還是只支持基于 TLS 部署的HTTP2.0協(xié)議,所以要想升級(jí)成HTTP2.0還是先升級(jí)HTTPS為好。
  2. 當(dāng)你的網(wǎng)站已經(jīng)升級(jí)HTTPS之后,那么升級(jí)HTTP2.0就簡單很多,如果你使用NGINX,只要在配置文件中啟動(dòng)相應(yīng)的協(xié)議就可以了,可以參考NGINX白皮書NGINX配置HTTP2.0官方指南
  3. 使用了HTTP2.0那么,原本的HTTP1.x怎么辦,這個(gè)問題其實(shí)不用擔(dān)心,HTTP2.0完全兼容HTTP1.x的語義,對(duì)于不支持HTTP2.0的瀏覽器,NGINX會(huì)自動(dòng)向下兼容的。

十、附注

HTTP2.0的多路復(fù)用和HTTP1.X中的長連接復(fù)用有什么區(qū)別?

  • HTTP/1.* 一次請(qǐng)求-響應(yīng),建立一個(gè)連接,用完關(guān)閉;每一個(gè)請(qǐng)求都要建立一個(gè)連接;
  • HTTP/1.1 Pipeling解決方式為,若干個(gè)請(qǐng)求排隊(duì)串行化單線程處理,后面的請(qǐng)求等待前面請(qǐng)求的返回才能獲得執(zhí)行機(jī)會(huì),一旦有某請(qǐng)求超時(shí)等,后續(xù)請(qǐng)求只能被阻塞,毫無辦法,也就是人們常說的線頭阻塞;
  • HTTP/2多個(gè)請(qǐng)求可同時(shí)在一個(gè)連接上并行執(zhí)行。某個(gè)請(qǐng)求任務(wù)耗時(shí)嚴(yán)重,不會(huì)影響到其它連接的正常執(zhí)行;
    具體如圖:


服務(wù)器推送到底是什么?
服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端,省去了客戶端重復(fù)請(qǐng)求的步驟。正因?yàn)闆]有發(fā)起請(qǐng)求,建立連接等操作,所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。具體如下:

  • 普通的客戶端請(qǐng)求過程:


  • 服務(wù)端推送的過程:


為什么需要頭部壓縮?
假定一個(gè)頁面有100個(gè)資源需要加載(這個(gè)數(shù)量對(duì)于今天的Web而言還是挺保守的), 而每一次請(qǐng)求都有1kb的消息頭(這同樣也并不少見,因?yàn)镃ookie和引用等東西的存在), 則至少需要多消耗100kb來獲取這些消息頭。HTTP2.0可以維護(hù)一個(gè)字典,差量更新HTTP頭部,大大降低因頭部傳輸產(chǎn)生的流量。具體參考:HTTP/2 頭部壓縮技術(shù)介紹

HTTP2.0多路復(fù)用有多好?
HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬,而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」,起初會(huì)限制連接的最大速度,如果數(shù)據(jù)成功傳輸,會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣取_@種調(diào)諧則被稱為 TCP 慢啟動(dòng)。由于這種原因,讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個(gè)連接,可以更有效地使用 TCP 連接,讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。

十一、參考

HTTP/2.0 相比1.0有哪些重大改進(jìn)?
深入研究:HTTP2 的真正性能到底如何
HTTP/2 頭部壓縮技術(shù)介紹

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,739評(píng)論 6 534
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,634評(píng)論 3 419
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,653評(píng)論 0 377
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,063評(píng)論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,835評(píng)論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,235評(píng)論 1 324
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,315評(píng)論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,459評(píng)論 0 289
  • 序言:老撾萬榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,000評(píng)論 1 335
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,819評(píng)論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,004評(píng)論 1 370
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,560評(píng)論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,257評(píng)論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,676評(píng)論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,937評(píng)論 1 288
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,717評(píng)論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,003評(píng)論 2 374

推薦閱讀更多精彩內(nèi)容