国产精品无码一区二区三区太,亚洲一线产区二线产区区别,欧美A区,人妻jealousvue人妻

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