正文字數(shù)：2402 ?閱讀時長：4 分鐘

本篇文章為IETF近期對Lucas Pardue 關于QUIC標準化工作的訪談。作者為IETF Blog 記者Grant Gross。

?

文 /?Grant?Gross

譯 / Alex

技術review：劉連響

原文鏈接 /?https://www.ietf.org/blog/quicwg-more-security-internet-traffic/

Lucas Pardue ?來自倫敦，IETF QUIC工作組聯(lián)合主席，同時也是CloudFlare（一家美國網(wǎng)絡基礎設施和網(wǎng)站安全公司）的高級軟件工程師。

--------

IETF Blog：QUIC工作組是做什么的？它是什么時候成立的？

Pardue: QUIC工作組匯聚了你能想到的各類人才，包括研究人員、從業(yè)人員、工程師、開發(fā)者、政策制定者、基礎設施運營商、服務提供商等。從2016年開始，我們一直在進行QUIC 第一個版本的標準化工作，包括傳輸行為、丟包檢測、恢復、擁塞控制、安全問題等，并與HTTP工作組一起，致力于適用于QUIC協(xié)議的HTTP。

很多人可能知道，關于QUIC 的工作早在 2016 年之前就開始了。我們以此為起點，并寫下章程，該章程幫助我們創(chuàng)建了一套包含工作組和IETF社區(qū)共識的文檔。隨著RFC的發(fā)布，工作組完成了QUIC第一個版本的標準化工作，隨后又踏上了新的征程。現(xiàn)在我們的工作重點是協(xié)議的維護和演進，并不斷產(chǎn)生可以用到QUIC豐富擴展性功能的新想法。我們的未來一片光明。

--------

IETF Blog：QUIC 如何提高使用它的服務的性能、隱私和安全特性？

Pardue：默認情況下，QUIC傳輸協(xié)議是安全的，這意味著它能為所有服務提供包括完整性、真實性和機密性在內(nèi)的強大特性。今天使用TCP協(xié)議的服務（無論有沒有TLS）都應該將QUIC作為可以直接代替TCP的協(xié)議。工作組目前正在研究的Unreliable Datagram extension（非可靠數(shù)據(jù)報擴展）將在未來代替DTLS或者其他此類協(xié)議。與TCP不同，QUIC關鍵在于保護數(shù)據(jù)包元數(shù)據(jù)，很少有信息暴露給被動觀測者，且中間無人能操縱序列號和選項。這為傳統(tǒng)的流量管理方式帶來了挑戰(zhàn)，但同時也解決了一個大問題——僵化。

當?shù)谌皆诓慌c你協(xié)調(diào)的情況下修改你的流量時，他們會對協(xié)議和協(xié)議遍歷的系統(tǒng)做出假設。當?shù)谝环?#xff08;端點）想要改進或試驗時，就有可能跟這些假設產(chǎn)生沖突。極端情況下，它會使擴展變得毫無意義，甚至破壞協(xié)議。安全的QUIC 可以防止這種不協(xié)調(diào)的串改，并為我們提供了一個可以不斷前行的優(yōu)質(zhì)平臺。現(xiàn)在，多虧了0-RRT，QUIC 可以實現(xiàn)快速握手，并且許多實現(xiàn)都擁有了智能擁塞控制。未來，QUIC的基礎性能只會變得越來越好。?

在性能方面，避免隊頭阻塞是QUIC的殺手锏（通過流的多路復用實現(xiàn)），我會在后面的回答中進一步說明。該性能不像QUIC 的其他特性那樣可以直接替換，需要使用 QUIC 的應用程序在與獨立流交互時保持智能。

--------

IETF Blog：QUIC 的部署范圍有多廣？它是如何廣泛部署的？

Pardue: 由于 QUIC 工作組一直致力于制定規(guī)范，我們已經(jīng)看到了許多客戶端和服務端代碼的實現(xiàn)。其中一部分已經(jīng)工作于生產(chǎn)環(huán)境中，如 Web 瀏覽器和面向公眾的服務。2019 年 9 月，Cloudflare 向所有人公開提供 QUIC 和 HTTP/3 支持。我們非常高興看到人們開啟QUIC并使用 Chrome、Firefox 和 Safari 等瀏覽器的Dev/Canary/Nightly Channel進行測試。隨著規(guī)范接近成熟，看到客戶端支持開始進入穩(wěn)定Channel并在默認情況下開啟，這是非常令人高興的。?

終端用戶應開始受益于 QUIC 所提升的安全性和性能，而無需采取任何手動操作。根據(jù) Cloudflare Radar 的數(shù)據(jù)，2021 年 1 月中旬，HTTP的全球份額約為：HTTP/1.1 占 24%，HTTP/2 占75%，HTTP/3 不到 1%。到 2 月中旬，HTTP/3 的使用率增長到略高于 5.5%，HTTP/2 下降到 69%，HTTP/3 的增長取代了 HTTP/2 的使用。到 5 月中旬，HTTP/3 占 HTTP 流量份額的 12%。

當越來越多的瀏覽器和網(wǎng)站使用QUIC, 我們預計這一增長趨勢會持續(xù)下去。

--------

IETF Blog：為什么流的多路復用和加密傳輸協(xié)議如此重要？

Pardue: 我已經(jīng)在上面第二個問題中解釋了防止串改是如何起作用的，所以這里不再重復。但我們不要忘記，私人通信就應該是私密的。加密傳輸是提高用戶安全性和隱私的基礎——它為應用開發(fā)者提供了額外的安全保障，如 Web源模型、同源策略和限制 Web API 以保護上下文。QUIC 的多路復用可以緩解隊頭阻塞的現(xiàn)象。一旦發(fā)生隊頭阻塞，丟包會阻止其后面的所有內(nèi)容。這可能會影響終端用戶體驗的方方面面。

如果某些關鍵網(wǎng)站腳本被不太緊急的數(shù)據(jù)所阻塞，你可能會被困在一個空白頁面上。如果你丟失了視頻流的一部分，就不能直接跳轉到余下的視頻流，而你可能最終會在緩沖或手動重新加載時觀看旋轉的圖標，并希望恢復之前視頻未丟失時的狀態(tài)。QUIC 有緩解隊頭阻塞的方法，如果使用得當，可以提高體驗質(zhì)量，尤其是在處理常規(guī)網(wǎng)絡問題方面。

TCP 中有一個邏輯字節(jié)流，其中發(fā)送的數(shù)據(jù)需要保證按順序接收。TCP 流被分成多個segment，以便使用 IP 在網(wǎng)絡上傳輸，由于不能確保網(wǎng)絡的可靠性，可能會造成丟包或者segment的重新排序。TCP 的工作就是處理此類事件并按預期呈現(xiàn)數(shù)據(jù)流。這通常很有效，但有時隊頭阻塞會使情況變得糟糕。想象一下，你在不同的數(shù)據(jù)包中發(fā)送了序列 A、B、C、D、E，而第三個丟失了。接收器獲得序列 A、B、D、E，它無法向應用程序展現(xiàn)這四個值，只能展現(xiàn)第一個連續(xù)范圍 A、B。

QUIC協(xié)議可以解決這個問題。每個流是獨立的，由一個 62 位的整型數(shù)值標識，就像它自己的 mini-TCP，都在一個共同的保護機制下傳輸。發(fā)送者可以選擇將 A、B、C、D、E 拆分為不同的流，并且發(fā)送者可以按任何順序讀取它們。

如果包含其中一個值的數(shù)據(jù)包丟失，沒關系，你只需在它到達時讀取所有內(nèi)容！然而，挑戰(zhàn)是按照發(fā)送的順序回讀序列。流 ID的作用就在這里，但實際發(fā)生的方式由應用程序映射（如 HTTP/3）描述。解決隊頭阻塞是可能的，但調(diào)整它以獲得最佳體驗質(zhì)量將是下一個機會。?

--------

IETF Blog： QUIC下一步有什么計劃？

Pardue: 我對 QUIC 的下一階段十分期待。隨著人們部署QUIC版本1，我們將學習并確認潛在的改進。QUIC 的版本控制和可擴展性豐富且穩(wěn)健。我們更新了工作組章程，以不斷拓寬工作范圍，同時也會采納一些新想法，如更加智能的重傳。我們正在考慮使用qlog這樣的模塊來實現(xiàn)更豐富的標準化端點日志記錄。就個人而言，我非常高興看到QUIC 所實現(xiàn)的應用層可能性。IETF 已經(jīng)在 QUIC 基礎上成立了MASQUE和WebTransport工作組。未來一片光明。

IETF: The Internet Engineering Task Force，互聯(lián)網(wǎng)工程任務組，成立于1985年底，是全球互聯(lián)網(wǎng)最具權威的技術標準化組織，主要任務是負責互聯(lián)網(wǎng)相關技術規(guī)范的研發(fā)和制定，當前絕大多數(shù)國際互聯(lián)網(wǎng)技術標準出自IETF。

詳情請掃描圖中二維碼或點擊閱讀原文了解大會更多信息。

總結

以上是生活随笔為你收集整理的IETF访谈： HTTP/3全球份额持续增长，QUIC前景一片光明的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。