HTTp/3和QUIC：HTTp的下一個主要更新背后是什么？

誰不是作為管理員忙于優(yōu)化Web服務(wù)器，不太可能偶然發(fā)現(xiàn)HTTp / 3。任何試圖閱讀該主題的人都會遇到令人眼花繚亂的首字母縮略詞和術(shù)語，如qQUIC，iQUIC，HTTp-over-QUIC或HTTp / QUIC，這些都不是不言自明的。隱藏這些縮略語的背后隱藏著什么，連接它們以及它如何繼續(xù)使用HTTp是本文的內(nèi)容。

超文本傳輸協(xié)議（簡稱HTTp）是除了URL和HTML之外的萬維網(wǎng)的三大支柱之一。當(dāng)然，HTTp也有不同的開發(fā)階段，可以從版本控制中讀取。然而，與合理維護(hù)良好的HTML標(biāo)準(zhǔn)相比，近年來相對較少。1999年推出的HTTp / 1.1至今仍被絕大多數(shù)網(wǎng)站使用。盡管差不多四年的繼任者HTTp / 2承諾了巨大的速度優(yōu)勢，但它仍然只能帶來不到34％的差距。

目前的協(xié)議版本HTTp / 2幾乎不為人所知，更不用說傳播 - 門前已有接班人：HTTp / 3。第三個版本應(yīng)該帶來一些根本性的變化。

一個四級社會，或：層模型

新協(xié)議版本的主要原因是基于技術(shù)創(chuàng)新。實(shí)際上，舊的TCp應(yīng)該被新的傳輸協(xié)議QUIC取代。這就是為什么我們在這種情況下談?wù)揌TTp-over-QUIC，HTTp / QUIC或類似的東西。為了更好地理解QUIC的技術(shù)和使用，回到計(jì)算機(jī)科學(xué)的第一個學(xué)期并重新訪問TCp / Ip層模型是有幫助的（圖1）。

為了能夠?qū)碜跃W(wǎng)絡(luò)電纜的電子信號顯示為網(wǎng)頁，它們通過四層。在稍微更詳細(xì)的OSI層模型中，有七個，但就我們的目的而言，簡化的四層視圖已經(jīng)足夠了。每個層由特定協(xié)議表示，該協(xié)議接受相鄰層的信號或數(shù)據(jù)，處理它并將其轉(zhuǎn)發(fā)到下一層。

從信號的純物理傳輸開始，到質(zhì)量保證到應(yīng)用程序（例如瀏覽器）中的表示，每個級別都有其自身的含義。HTTp是最后一層協(xié)議，即應(yīng)用層。它不僅用于傳輸超文本標(biāo)記語言（HTML）思想，還用于傳輸z。作為音頻，視頻和圖片。如果發(fā)生加密，則在第四層和第五層之間使用傳輸層安全性（TLS）。在傳輸層，使用已經(jīng)變得很舊的TCp（傳輸控制協(xié)議）。另一種更快的傳輸協(xié)議是UDp（用戶數(shù)據(jù)報(bào)協(xié)議）。由于UDp無法保證所有數(shù)據(jù)包都被傳輸，

當(dāng)視頻傳輸時，如果以每秒24幀中的一幀丟失某些信息，則幾乎不可察覺。但是，HTML文件幾乎沒用，只有一個HTML標(biāo)簽的非傳輸剪輯。

曾幾何時......

由于每個好的計(jì)算機(jī)科學(xué)講座都包含歷史性的游覽，因此這里將簡要介紹HTTp的發(fā)展（圖2）。有史以來第一次，Tim berners-Lee在1991年夏天提到了HTTp。他對WWW的概念包括三個組件HTML，統(tǒng)一資源定位器（然后是通用文檔標(biāo)識符，UDI）和HTTp。當(dāng)時，HTTp仍然是一個非常簡單的基于文本的協(xié)議，每次傳輸都需要自己的TCp連接。請求是一行的，來自服務(wù)器的響應(yīng)僅包含所需的資源。

HTTp在接下來的幾年里逐漸發(fā)展到了它的任務(wù)，并且來自多方面，或多或少地混亂，配備了新功能。五年后，在1996年夏天，互聯(lián)網(wǎng)工程任務(wù)組（IETF）總結(jié)了最常見的功能，并在備忘錄RFC1945中描述了HTTp / 1 。然而，重要的是要注意這不是一個標(biāo)準(zhǔn)：“這份備忘錄沒有規(guī)定任何形式的互聯(lián)網(wǎng)標(biāo)準(zhǔn)，”它當(dāng)時非常簡潔地說。

在上述備忘錄開始前一年開始制定官方標(biāo)準(zhǔn)，最初名稱為HTTp / NG（NG代表下一代）。1997年，它成為RFC2068版本的HTTp / 1.1，現(xiàn)在也作為“真正的”標(biāo)準(zhǔn)推出。

最重要的變化是keepalive函數(shù)，它允許第一次持久連接。現(xiàn)在可以使用開放的TCp連接進(jìn)行多個數(shù)據(jù)傳輸。此外，該協(xié)議還支持首次向服務(wù)器發(fā)送數(shù)據(jù)（pUT方法）。通過流水線理論上，理論上也可以進(jìn)行查詢，而不必等待答案 - 一個功能，當(dāng)時僅由少數(shù)瀏覽器支持。

在那之后，HTTp安靜了一段時間。直到2012年，HTTp / 2的草案才開始實(shí)施，主要基于SpDY，這是Google自2009年以來一直在努力的替代協(xié)議。在HTTp / 2標(biāo)準(zhǔn)正式出臺，2015年。主要變化：多路復(fù)用已啟用改進(jìn)的異步數(shù)據(jù)交換。它也是第一次使用二進(jìn)制協(xié)議。因此，數(shù)據(jù)不再以純文本形式傳輸（方框：“Transitory，persistent，pipelining and Multiplexing”，圖3）。

首字母縮寫詞potpourri - HTTp / 3的方式

QUIC（快速UDp Internet連接）是Google于2012年首次推出的協(xié)議。從那時起，QUIC已在許多Google產(chǎn)品中實(shí)施，包括服務(wù)器端和客戶端。2016年，IETF成立了一個工作組來解決這項(xiàng)新技術(shù)的標(biāo)準(zhǔn)化問題，以便將其用于HTTp。雖然QUIC的名稱沒有進(jìn)一步采用，但它堅(jiān)持認(rèn)為它不是縮寫：“QUIC是一個名字，而不是一個縮寫”。

為了更好地區(qū)分分支，他們從加利福尼亞qQUIC調(diào)用了開發(fā)，并選擇iQUIC作為計(jì)劃的IETF標(biāo)準(zhǔn)。當(dāng)然，必須調(diào)整使用QUIC的底層HTTp。該項(xiàng)目的工作標(biāo)題最初是HTTp-over-QUIC或HTTp / QUIC。在2018年底，他們正式宣布他們正在開發(fā)最新版本的協(xié)議：HTTp / 3。

兩個世界中最好的一個

長期以來，TCp一直是WWW的忠實(shí)仆人，但它不再符合現(xiàn)代要求。該協(xié)議不僅需要固定的發(fā)送訂單，還需要發(fā)送數(shù)據(jù)的收據(jù)。這使得協(xié)議可靠，但也很慢。UDp速度更快但可靠性更低。該協(xié)議檢查數(shù)據(jù)的完整性，但在出現(xiàn)錯誤或數(shù)據(jù)丟失時不采取糾正措施。

借助HTTp / 2和許多新功能，他們嘗試將兩種協(xié)議的優(yōu)點(diǎn)結(jié)合起來，而不會失去對TCp的依賴。盡管HTTp / 2和多路復(fù)用仍在繼續(xù)的一個問題是TCp級別的線頭阻塞。如果在TCp傳輸期間丟失數(shù)據(jù)包，則所有后續(xù)數(shù)據(jù)包必須等待數(shù)據(jù)包的新傳輸。另一方面，QUIC啟用真正的多路復(fù)用：請求可以異步發(fā)送，答案的順序無關(guān)緊要，丟失的數(shù)據(jù)包不再保留隊(duì)列（圖4）。

這同樣適用于應(yīng)該在HTTp / 2中使用的持久連接，以減少所需的TCp連接數(shù)。但是，網(wǎng)絡(luò)改變了。例如，如果您將智能手機(jī)從Wi-Fi更改為移動網(wǎng)絡(luò)，則會丟失TCp連接。與基于發(fā)送方和接收方的Ip地址和端口的TCp連接的識別不同，QUIC連接被賦予唯一的64位標(biāo)識符。這是跨網(wǎng)絡(luò)維護(hù)的，因此可以實(shí)現(xiàn)真正的持久連接。

另一項(xiàng)改進(jìn)涉及通信的加密。以前，傳輸層安全性（TLS）充當(dāng)HTTp和TCp之間的附加層。即使在HTTp / 2標(biāo)準(zhǔn)中，也不強(qiáng)制使用TLS。相反，流行的瀏覽器為HTTp / 2提供了加密連接，可以說是準(zhǔn)標(biāo)準(zhǔn)。QUIC采用更激進(jìn)的方法并直接實(shí)現(xiàn)加密。因此消除了TLS中間層，QUIC接管了連接的加密和認(rèn)證。這也對性能產(chǎn)生積極影響。但并非全部：TLS僅加密有效負(fù)載，連接的元數(shù)據(jù)可以純文本形式讀取。另一方面，QUIC還加密連接元數(shù)據(jù)，提供額外的安全性。

QUIC在野外

任何想要了解qQUIC技術(shù)模型的人都可以使用眾多Google服務(wù)中的一種。在Chrome瀏覽器的開發(fā)者控制臺中，如果您之前通過上下文菜單啟用了相應(yīng)的列，則網(wǎng)絡(luò)選項(xiàng)卡將顯示您正在使用的協(xié)議（圖5）。Google QUIC的官方網(wǎng)站還提供了詳細(xì)的文檔和一些代碼示例。

網(wǎng)絡(luò)診斷程序Wireshark還能夠顯示二進(jìn)制QUIC數(shù)據(jù)，甚至可以區(qū)分gQUIC和iQUIC。為了以純文本形式查看qQUIC流量，必須在GQUIC [sic]協(xié)議的設(shè)置中激活所有（Google）QUIC payload的強(qiáng)制解碼的復(fù)選標(biāo)記。當(dāng)然，只要協(xié)議允許，內(nèi)容才會被解密。搜索查詢無法以明文形式顯示。該協(xié)議的快速過濾器是gquic。到z。例如，要顯示初始gQUIC請求，請使用快速過濾器gquic.tag == CHLO。圖6顯示了gQUIC（此處為Q043版本）無需加密即可傳輸?shù)臄?shù)據(jù)摘錄。

還有許多實(shí)驗(yàn)但也是QUIC的商業(yè)實(shí)現(xiàn)。例如，商業(yè)服務(wù)器軟件LiteSpeed提供QUIC支持。對于nginx，還有一個實(shí)驗(yàn)性QUIC模塊，以及Caddy。Caddy 在Go中使用了一個基于gQUIC和iQUIC的實(shí)現(xiàn)。可以在GitHub上找到所有QUIC實(shí)現(xiàn)的官方列表。

對于瀏覽器當(dāng)然有Chrome，它支持自2012年以來的內(nèi)部gQUIC?；旧?，每個瀏覽器都準(zhǔn)備好用于QUIC，如果他使用至少從版本29開始的渲染引擎Chromium - 作為z。b.歌劇院自2013年以來一直在做。在Opera中，您可能需要通過opera：flags選項(xiàng)頁面手動啟用QUIC 。

展望

下一次HTTp演進(jìn)背后的真正明星是QUIC。新的傳輸協(xié)議旨在取代歷史悠久的TCp，以提高速度，移動性和安全性，并且還將更加一致地實(shí)現(xiàn)HTTp / 2的承諾。

當(dāng)QUIC或HTTp / 3作為標(biāo)準(zhǔn)提供時，仍然完全不清楚。因此，開發(fā)人員和管理員仍有時間為未來制定計(jì)劃或恐慌?？只牌鋵?shí)不合適。QUIC在用戶空間中運(yùn)行，因此應(yīng)易于實(shí)現(xiàn)。由于廣泛的UDp被用作子結(jié)構(gòu)，因此瀏覽器軟件的更新就足夠了，而不必等待下一個操作系統(tǒng)的發(fā)布。此外，QUIC被描述為向后兼容。因此，如果新協(xié)議的遠(yuǎn)程站尚未就緒，則提供對TCp的回退。

在Cloudflare，預(yù)計(jì)QUIC工作組將在年底前提交第一份完成的草案。但是，HTTp工作組尚未公布固定日期。但是，至少已經(jīng)宣布將及時開發(fā)必要的擴(kuò)展來為QUIC準(zhǔn)備HTTp。那是件好事。

網(wǎng)頁題目：HTTp/3和QUIC：HTTp的下一個主要更新背后是什么？
轉(zhuǎn)載注明：http://www.muchs.cn/news46/296646.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、網(wǎng)站制作、用戶體驗(yàn)、網(wǎng)站設(shè)計(jì)公司、品牌網(wǎng)站制作、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)