免费看又黄又无码的网站_久久久高清国产免费观看_亚洲一区二区三区在线免费观看_免费欧洲美女a视频一级毛片_日本最新免费二区三区

最近一段時(shí)間以來(lái)，關(guān)于HTTP/3的新聞?dòng)泻芏?，越?lái)越多的國(guó)際大公司已經(jīng)開始使用HTTP/3了。10 月 8 日消息， 據(jù) smalltechnews 報(bào)道，谷歌宣布開始在其 Chrome 瀏覽器中實(shí)現(xiàn)對(duì) HTTP / 3 的支持。
那么，作為一線開發(fā)者，我們也是時(shí)候了解下到底什么是HTTP/3，為什么需要HTTP/3了。
HTTP的發(fā)展歷史
HTTP 這個(gè)定義于 1991 年的協(xié)議是用來(lái)管理 Web 的。它的全名是超文本傳輸協(xié)議，讓你可以從網(wǎng)頁(yè)中獲取資源，網(wǎng)頁(yè)數(shù)據(jù)從 Web 服務(wù)器傳輸?shù)侥愕臑g覽器上。它基于較低級(jí)別的協(xié)議——TCP，這里是重點(diǎn)——而且它是無(wú)狀態(tài)的。這意味著每個(gè)請(qǐng)求都是完全獨(dú)立的。頁(yè)面上顯示的每個(gè) GIF 圖片都在互聯(lián)網(wǎng)上獨(dú)立存在，這對(duì)這些 GIF 圖片本身來(lái)說(shuō)是好事。但對(duì)我們來(lái)說(shuō)，這樣的一個(gè)系統(tǒng)是有些支離破碎的。
問(wèn)題在于每個(gè)請(qǐng)求一次只會(huì)查找一個(gè)文件。每次都要?jiǎng)?chuàng)建一個(gè)昂貴的 TCP 連接。想象一下，如果你的頁(yè)面上有 10,000 個(gè)小技巧，這會(huì)是多么沉重的負(fù)擔(dān)啊。盡管瀏覽器可以同時(shí)發(fā)出六個(gè)不同的請(qǐng)求，但是 HTTP 仍然很慢，并且需要很多 TCP 連接。
另外，我們開發(fā)人員通常不會(huì)在意這一點(diǎn)。我們喜歡在頁(yè)面上塞滿各種垃圾。比如說(shuō)巨大的 jQuery 庫(kù)，包含 300 個(gè)無(wú)用的 CSS 樣式表，結(jié)尾是一個(gè)透明的 8 兆大 PNG 圖。
當(dāng)谷歌發(fā)現(xiàn)我們?cè)诨ヂ?lián)網(wǎng)上到處傾倒垃圾后，他們就開始搞一個(gè)稱為 SPDY 的東西了。目的是什么呢？當(dāng)然是加快互聯(lián)網(wǎng)的速度。當(dāng)你讀取 HTML 時(shí)，瀏覽器會(huì)查看你在頁(yè)面中要詢問(wèn)的所有內(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í)長(zhǎng)以及協(xié)議僵化等問(wèn)題。這導(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首要解決的問(wèn)題就是繞開TCP。那么如果研發(fā)一種新的協(xié)議，同樣還是會(huì)因?yàn)槭艿街虚g設(shè)備僵化的影響，導(dǎo)致無(wú)法被大規(guī)模應(yīng)用。所以，研發(fā)人員們想到了一種基于UDP實(shí)現(xiàn)的方式。于是，Google是最先采用這種方式并付諸于實(shí)踐的，他們?cè)?013年推出了一種叫做QUIC的協(xié)議，全稱是Quick UDP Internet Connections。從名字中可以看出來(lái)，這是一種完全基于UDP的協(xié)議。在設(shè)計(jì)之初，Google就希望使用這個(gè)協(xié)議來(lái)取代HTTPS/HTTP協(xié)議，使網(wǎng)頁(yè)傳輸速度加快。2015年6月，QUIC的網(wǎng)絡(luò)草案被正式提交至互聯(lián)網(wǎng)工程任務(wù)組。2018 年 10 月，互聯(lián)網(wǎng)工程任務(wù)組 HTTP 及 QUIC 工作小組正式將基于 QUIC 協(xié)議的 HTTP（英語(yǔ)：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端口號(hào)來(lái)識(shí)別指定機(jī)器上的特定服務(wù)器。
可靠性：雖然UDP是不可靠傳輸協(xié)議，但是QUIC在UDP的基礎(chǔ)上做了些改造，使得他提供了和TCP類似的可靠性。它提供了數(shù)據(jù)包重傳、擁塞控制、調(diào)整傳輸節(jié)奏以及其他一些TCP中存在的特性。
實(shí)現(xiàn)了無(wú)序、并發(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的分層來(lái)講，他是屬于傳輸層的，也就是和TCP、UDP屬于同一層。
如果更加細(xì)化一點(diǎn)的話，因?yàn)镼UIC不僅僅承擔(dān)了傳輸層協(xié)議的職責(zé)，還具備了TLS的安全性相關(guān)能力，所以，可以通過(guò)下圖來(lái)理解QUIC在HTTP/3的實(shí)現(xiàn)中所處的位置。
HTTP3 代表著充滿魅力的未來(lái)，它的 HTTP 基礎(chǔ)潛能已經(jīng)被谷歌的那些極客發(fā)揮到極致。在撰寫本文時(shí)，只有 4.6％的互聯(lián)網(wǎng)內(nèi)容在使用 HTTP3，但這個(gè)數(shù)字在未來(lái)幾年中可能會(huì)增長(zhǎng)許多。