最近一段時(shí)間以來,關(guān)于HTTP/3的新聞有很多,越來越多的國際大公司已經(jīng)開始使用HTTP/3了。10 月 8 日消息, 據(jù) smalltechnews 報(bào)道,谷歌宣布開始在其 Chrome 瀏覽器中實(shí)現(xiàn)對 HTTP / 3 的支持。
最近一段時(shí)間以來,關(guān)于HTTP/3的新聞有很多,越來越多的國際大公司已經(jīng)開始使用HTTP/3了。10 月 8 日消息, 據(jù) smalltechnews 報(bào)道,谷歌宣布開始在其 Chrome 瀏覽器中實(shí)現(xiàn)對 HTTP / 3 的支持。
那么,作為一線開發(fā)者,我們也是時(shí)候了解下到底什么是HTTP/3,為什么需要HTTP/3了。
HTTP的發(fā)展歷史
HTTP 這個(gè)定義于 1991 年的協(xié)議是用來管理 Web 的。它的全名是超文本傳輸協(xié)議,讓你可以從網(wǎng)頁中獲取資源,網(wǎng)頁數(shù)據(jù)從 Web 服務(wù)器傳輸?shù)侥愕臑g覽器上。它基于較低級別的協(xié)議——TCP,這里是重點(diǎn)——而且它是無狀態(tài)的。這意味著每個(gè)請求都是完全獨(dú)立的。頁面上顯示的每個(gè) GIF 圖片都在互聯(lián)網(wǎng)上獨(dú)立存在,這對這些 GIF 圖片本身來說是好事。但對我們來說,這樣的一個(gè)系統(tǒng)是有些支離破碎的。
問題在于每個(gè)請求一次只會查找一個(gè)文件。每次都要?jiǎng)?chuàng)建一個(gè)昂貴的 TCP 連接。想象一下,如果你的頁面上有 10,000 個(gè)小技巧,這會是多么沉重的負(fù)擔(dān)啊。盡管瀏覽器可以同時(shí)發(fā)出六個(gè)不同的請求,但是 HTTP 仍然很慢,并且需要很多 TCP 連接。
另外,我們開發(fā)人員通常不會在意這一點(diǎn)。我們喜歡在頁面上塞滿各種垃圾。比如說巨大的 jQuery 庫,包含 300 個(gè)無用的 CSS 樣式表,結(jié)尾是一個(gè)透明的 8 兆大 PNG 圖。
當(dāng)谷歌發(fā)現(xiàn)我們在互聯(lián)網(wǎng)上到處傾倒垃圾后,他們就開始搞一個(gè)稱為 SPDY 的東西了。目的是什么呢?當(dāng)然是加快互聯(lián)網(wǎng)的速度。當(dāng)你讀取 HTML 時(shí),瀏覽器會查看你在頁面中要詢問的所有內(nèi)容。然后,它可以一次獲取所有內(nèi)容,這樣就可以避免一個(gè)文件一個(gè)文件地獲取了。
HTTP2 的第一份草案基于 SPDY。HTTP2 很快被廣泛采用,隨后互聯(lián)網(wǎng)上的一切變得快多了。今天,互聯(lián)網(wǎng)上 42.7%的內(nèi)容使用 HTTP2。
然而,HTTP/2因?yàn)榈讓邮褂玫膫鬏攲訁f(xié)議仍然是TCP,所以他著TCP隊(duì)頭阻塞、TCP握手延時(shí)長以及協(xié)議僵化等問題。這導(dǎo)致HTTP/2雖然使用了多路復(fù)用、二進(jìn)制分幀等技術(shù),但是仍然存在著優(yōu)化空間。
而 HTTP/3是HTTP協(xié)議的第三個(gè)主要版本。在HTTP/3中,將棄用TCP協(xié)議,改為使用基于UDP協(xié)議的QUIC協(xié)議實(shí)現(xiàn)。2018年10月,互聯(lián)網(wǎng)工程任務(wù)組(IETF) HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名為HTTP/3,以區(qū)分其特點(diǎn)以及與Google 公司的QUIC的獨(dú)立性。
HTTP/3的原理
QUIC協(xié)議我們知道,HTTP/2之所以"被棄用",是因?yàn)樗褂玫膫鬏攲訁f(xié)議仍然是TCP,所以HTTP/3首要解決的問題就是繞開TCP。那么如果研發(fā)一種新的協(xié)議,同樣還是會因?yàn)槭艿街虚g設(shè)備僵化的影響,導(dǎo)致無法被大規(guī)模應(yīng)用。所以,研發(fā)人員們想到了一種基于UDP實(shí)現(xiàn)的方式。于是,Google是最先采用這種方式并付諸于實(shí)踐的,他們在2013年推出了一種叫做QUIC的協(xié)議,全稱是Quick UDP Internet Connections。從名字中可以看出來,這是一種完全基于UDP的協(xié)議。在設(shè)計(jì)之初,Google就希望使用這個(gè)協(xié)議來取代HTTPS/HTTP協(xié)議,使網(wǎng)頁傳輸速度加快。2015年6月,QUIC的網(wǎng)絡(luò)草案被正式提交至互聯(lián)網(wǎng)工程任務(wù)組。2018 年 10 月,互聯(lián)網(wǎng)工程任務(wù)組 HTTP 及 QUIC 工作小組正式將基于 QUIC 協(xié)議的 HTTP(英語:HTTP over QUIC)重命名為HTTP/3。所以,我們現(xiàn)在所提到的HTTP/3,其實(shí)就是HTTP over QUIC,即基于QUIC協(xié)議實(shí)現(xiàn)的HTTP。那么,想要了解HTTP/3的原理,只需要了解QUIC就可以了。QUIC協(xié)議有以下特點(diǎn):
基于UDP的傳輸層協(xié)議:它使用UDP端口號來識別指定機(jī)器上的特定服務(wù)器。
可靠性:雖然UDP是不可靠傳輸協(xié)議,但是QUIC在UDP的基礎(chǔ)上做了些改造,使得他提供了和TCP類似的可靠性。它提供了數(shù)據(jù)包重傳、擁塞控制、調(diào)整傳輸節(jié)奏以及其他一些TCP中存在的特性。
實(shí)現(xiàn)了無序、并發(fā)字節(jié)流:QUIC的單個(gè)數(shù)據(jù)流可以保證有序交付,但多個(gè)數(shù)據(jù)流之間可能亂序,這意味著單個(gè)數(shù)據(jù)流的傳輸是按序的,但是多個(gè)數(shù)據(jù)流中接收方收到的順序可能與發(fā)送方的發(fā)送順序不同!
快速握手:QUIC提供0-RTT和1-RTT的連接建立
使用TLS 1.3傳輸層安全協(xié)議:與更早的TLS版本相比,TLS 1.3有著很多優(yōu)點(diǎn),但使用它的最主要原因是其握手所花費(fèi)的往返次數(shù)更低,從而能降低協(xié)議的延遲。
那么,QUIC到底屬于TCP/IP協(xié)議族中的那一層呢?我們知道,QUIC是基于UDP實(shí)現(xiàn)的,并且是HTTP/3的所依賴的協(xié)議,那么,按照TCP/IP的分層來講,他是屬于傳輸層的,也就是和TCP、UDP屬于同一層。
如果更加細(xì)化一點(diǎn)的話,因?yàn)镼UIC不僅僅承擔(dān)了傳輸層協(xié)議的職責(zé),還具備了TLS的安全性相關(guān)能力,所以,可以通過下圖來理解QUIC在HTTP/3的實(shí)現(xiàn)中所處的位置。
HTTP3 代表著充滿魅力的未來,它的 HTTP 基礎(chǔ)潛能已經(jīng)被谷歌的那些極客發(fā)揮到極致。在撰寫本文時(shí),只有 4.6%的互聯(lián)網(wǎng)內(nèi)容在使用 HTTP3,但這個(gè)數(shù)字在未來幾年中可能會增長許多。
免責(zé)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)自行上傳,本網(wǎng)站不擁有所有權(quán),也不承認(rèn)相關(guān)法律責(zé)任。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容,請發(fā)送郵件至:operations@xinnet.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),本站將立刻刪除涉嫌侵權(quán)內(nèi)容。