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

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

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

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

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

為了能夠將來自網絡電纜的電子信號顯示為網頁，它們通過四層。在稍微更詳細的OSI層模型中，有七個，但就我們的目的而言，簡化的四層視圖已經足夠了。每個層由特定協議表示，該協議接受相鄰層的信號或數據，處理它并將其轉發到下一層。

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

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

曾幾何時......

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

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

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

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

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

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

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

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

兩個世界中最好的一個

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

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

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

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

QUIC在野外

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

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

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

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

展望

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

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

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

網頁題目：HTTp/3和QUIC：HTTp的下一個主要更新背后是什么？
轉載注明：http://www.js-pz168.com/news46/296646.html

成都網站建設公司_創新互聯，為您提供網站排名、網站制作、用戶體驗、網站設計公司、品牌網站制作、網站建設

廣告

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