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

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

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

一個(gè)四級(jí)社會(huì)，或：層模型

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

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

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

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

曾幾何時(shí)......

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

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

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

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

在那之后，HTTp安靜了一段時(shí)間。直到2012年，HTTp / 2的草案才開(kāi)始實(shí)施，主要基于SpDY，這是Google自2009年以來(lái)一直在努力的替代協(xié)議。在HTTp / 2標(biāo)準(zhǔn)正式出臺(tái)，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é)議。從那時(shí)起，QUIC已在許多Google產(chǎn)品中實(shí)施，包括服務(wù)器端和客戶端。2016年，IETF成立了一個(gè)工作組來(lái)解決這項(xiàng)新技術(shù)的標(biāo)準(zhǔn)化問(wèn)題，以便將其用于HTTp。雖然QUIC的名稱沒(méi)有進(jìn)一步采用，但它堅(jiān)持認(rèn)為它不是縮寫：“QUIC是一個(gè)名字，而不是一個(gè)縮寫”。

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

兩個(gè)世界中最好的一個(gè)

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

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

這同樣適用于應(yīng)該在HTTp / 2中使用的持久連接，以減少所需的TCp連接數(shù)。但是，網(wǎng)絡(luò)改變了。例如，如果您將智能手機(jī)從Wi-Fi更改為移動(dòng)網(wǎng)絡(luò)，則會(huì)丟失TCp連接。與基于發(fā)送方和接收方的Ip地址和端口的TCp連接的識(shí)別不同，QUIC連接被賦予唯一的64位標(biāo)識(shí)符。這是跨網(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提供了加密連接，可以說(shuō)是準(zhǔn)標(biāo)準(zhǔn)。QUIC采用更激進(jìn)的方法并直接實(shí)現(xiàn)加密。因此消除了TLS中間層，QUIC接管了連接的加密和認(rèn)證。這也對(duì)性能產(chǎn)生積極影響。但并非全部：TLS僅加密有效負(fù)載，連接的元數(shù)據(jù)可以純文本形式讀取。另一方面，QUIC還加密連接元數(shù)據(jù)，提供額外的安全性。

QUIC在野外

任何想要了解qQUIC技術(shù)模型的人都可以使用眾多Google服務(wù)中的一種。在Chrome瀏覽器的開(kāi)發(fā)者控制臺(tái)中，如果您之前通過(guò)上下文菜單啟用了相應(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)容才會(huì)被解密。搜索查詢無(wú)法以明文形式顯示。該協(xié)議的快速過(guò)濾器是gquic。到z。例如，要顯示初始gQUIC請(qǐng)求，請(qǐng)使用快速過(guò)濾器gquic.tag == CHLO。圖6顯示了gQUIC（此處為Q043版本）無(wú)需加密即可傳輸?shù)臄?shù)據(jù)摘錄。

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

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

展望

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

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

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

網(wǎng)頁(yè)題目：HTTp/3和QUIC：HTTp的下一個(gè)主要更新背后是什么？
轉(zhuǎn)載注明：http://jinyejixie.com/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)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)