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

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

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

圖1：層模型和日志分類

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

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

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

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

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

曾幾何時......

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

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

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

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

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

Transitory，Persistent，Pipelining and Multiplexing

Transitory
必須為每次數(shù)據(jù)交換創(chuàng)建TCP連接。

持久性
開放式TCP連接可用于多個請求和響應。

流水線操作
可以在不等待服務器響應的情況下發(fā)出HTTP請求。答案必須與請求的順序相匹配。

多路復用
HTTP請求可以獨立于先前的響應進行，順序無關緊要。

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

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

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

兩個世界中最好的一個

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

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

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

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

QUIC在野外

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

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

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

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

展望

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

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

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