在去年的HTTP3"生日周"期間,我們Cloudflare宣佈了對Web的新標準QUIC和HTTP3(或當時稱爲"HTTP over QUIC")的初步支持,從而可以更快,
更可靠,更安全地connect到網站和API.我們還讓客戶加入wait list,只要相關應用開發完成他們可用後立即嘗試QUIC和HTTP3.
從那時起,我們一直與業界同行合作通過Internet Engineering Task Force(IETF.org包括Google Chrome和Mozilla Firefox),
以迭代HTTP3和QUIC標準文檔.
在標準日趨成熟的同時,我們還致力於改善對網絡的支持.
現在,我們很高興地宣佈, Cloudflare Edge Network上已提供QUIC和HTTP3支持.
我們很高興能與Google Chrome和Mozilla Firefox(兩家領先的瀏覽器供應商和合作伙伴)一起加入此公告,以努力使所有人的網絡速度更快,更可靠.
用Google的高級軟件工程師Ryan Hamilton的話來說,
"HTTP3應該使每個人的網絡變得更好.
Chrome和Cloudflare團隊密切合作,將HTTP3和QUIC從新生標準引入到廣泛採用的技術來改進Web.
行業領導者之間的強大合作伙伴關係使互聯網標準創新成爲可能,我們期待我們繼續合作."
這對使用Cloudflare的客戶,使用了我們的服務和Edge Network使他們的Web更快更安全,來對與客戶說這意味着什麼?
在Cloudflare儀表板中爲您的域名啓用 HTTP3支持後,客戶便可以使用HTTP3與您的網站和API進行交互.
我們一直在穩定地邀請我們的HTTP3等待列表中的客戶,啓用該功能(請注意我們發來的邀請電子郵件),並且在接下來的幾周內,我們將向所有人提供該功能.
如果您是互聯網用戶,並且通過瀏覽器和其他客戶端與站點和API進行交互,那麼此公告意味着什麼?
從今天開始,您可以使用Chrome Canary通過HTTP3與Cloudflare和其他服務器進行交互.
對於那些正在尋找命令行客戶端的人,curl還提供了對HTTP3的支持.
本文後面的內容將介紹如何在Chrome和curl中使用HTTP3.
1. 先有雞還是先有蛋的問題
一直以來,由於先有雞還是現有蛋的問題,Internet上的標準創新一直很困難：
*首先需要Server提供商(例如Cloudflare或其他雲服務商)還是Client支持(例如瀏覽器,操作系統等)?
連接的兩端都需要支持新的通信協議,這樣它纔可以使用.*
Cloudflare推動Web標準發展的歷史由來已久,從HTTP3(HTTP3之前的HTTP版本)到TLS 1.3,再到加密SNI之類的東西.
我們與志同道合的組織合作,從而推動了標準的發展,這些組織有着共同的願望,即幫助我們建立更好的互聯網.
我們將HTTP3納入主流的努力沒有什麼不同.
在整個HTTP3標準開發過程中,我們一直與行業合作伙伴緊密合作,以建立和驗證與我們的Edge Network兼容和支持HTTP3 Client.
我們很高興能與Google Chrome和curl結合使用,今天它們都可以用於通過HTTP3向Cloudflare Edge Network發出請求.
Mozilla Firefox預計也將在晚些時候發佈的版本中提供支持.
總的來說：2019-09-26對於互聯網用戶來說是美好的一天；HTTP3的廣泛推廣將爲所有人帶來更快的Web體驗,而今天的支持是朝着這一方向邁出的一大步.
更重要的是,2019-09-26對Internet來說是美好的一天：Chrome,curl和Cloudflare,很快,Mozilla迅速推出了實驗性但實用的對HTTP3的支持,
表明Internet標準創建過程可以正常工作.
在Internet Task Force (ietf.org/)的協調下,行業合作伙伴,競爭對手和其他主要利益相關者可以齊心協力制定使整個Internet受益的標準,而不僅僅只有大公司收益.
Firefox的CTO Eric Rescorla很好地總結了這一點："開發新的網絡協議很困難,要正確實現它就需要每個人共同努力.在過去的幾年中,我們一直與Cloudflare和其他行業合作伙伴一起測試TLS 1.3,現在測試HTTP3和QUIC.
Cloudflare對這些協議的早期服務器端支持已幫助我們解決了客戶端Firefox實施中的互操作性問題.我們期待着共同提高互聯網的安全性和性能."
2. HTTP3進化史
在深入探究HTTP3之前,讓我們快速回顧一下HTTP多年來的發展,以便更好地理解爲什麼需要HTTP3.
2.1 HTTP1.0
這一切始於1996年HTTP1.0規範的發佈,該規範定義了我們今天所知道的基本HTTP文本傳輸格式(我假裝HTTP0.9不存在).
在HTTP1.0中,將爲客戶端和服務器之間的每個請求/響應交換創建一個新的TCP連接,這意味着所有TCP/TLS握手均在每個請求之前完成,因此所有請求都會產生延遲.如下圖所示.
2.2 HTTP1.1引入keep alive 解決http1.0 Slow Start問題
更糟糕的是,TCP建立了稱爲"慢啓動Slow Start"的預熱時間,"慢啓動Slow Start"使TCP擁塞控制算法可以確定可以傳輸的數據量,而不是在建立連接後儘快發送所有未完成的數據.在網絡路徑上發生擁塞之前的任何給定時刻,並避免將無法處理的數據包泛洪到網絡中.但是由於新連接必須經過緩慢的啓動過程,因此它們無法立即使用所有可用的網絡帶寬.
幾年後,HTTP規範的HTTP1.1修訂版試圖通過引入"保持連接keep-alive"的概念來解決這些問題,該概念允許客戶端重用TCP連接,
從而分攤了初始連接建立和緩慢連接的成本.
面對多個請求Request,但這不是靈丹妙藥：
儘管多個請求可以共享同一個連接,但是仍然必須一個接一個地序列化它們,因此客戶端和服務器只能在任意給定時間爲每個連接執行一次Request/Response傳輸.
隨着網絡的發展,隨着多年來每個網站所需資源(CSS,JavaScript,圖像等)的增加,瀏覽器在獲取和呈現網頁時需要越來越多的併發性.
但是,由於HTTP1.1只允許客戶端一次進行一次HTTP請求/響應傳輸,因此在網絡層上獲得併發性的唯一方法是並行使用多個TCP連接到同一源,
從而失去了大多數Keep alive的好處.儘管連接仍會在一定程度上(但較小程度)被重用,但我們還是回到了HTTP1.0那個局面.
2.3 HTTP2 引入SPDY解決TCP複用問題
最終,十多年後,出現了SPDY,然後是HTTP2,它首先引入了HTTP"流streams"的概念：
一種抽象,允許HTTP實現將不同的HTTP交換併發地複用到同一TCP連接上,瀏覽器以更有效地重用TCP連接.
再一次,SPDY/HTTP2這又不是靈丹妙藥！HTTP2解決了最初的問題-單個TCP連接的使用效率低-因爲現在可以通過同一連接同時傳輸多個請求/響應.
但是,即使丟失的數據僅涉及單個請求,所有請求和響應也同樣會受到數據包丟失的影響(例如,由於網絡擁塞).
這是因爲儘管HTTP2層可以在不同的流上隔離不同的HTTP交換,但是TCP不瞭解這種抽象,並且TCP所看到的只是字節流,沒有特殊含義.
TCP的作用是以正確的順序從一個端點到另一端點傳遞整個字節流(stream).
當承載某些字節的TCP數據包在網絡路徑上丟失時,它將在流中造成間隙,並且TCP需要在檢測到丟失時通過重新發送受影響的數據包來填充它.
這樣做時,即使丟失的字節本身並沒有丟失並且屬於完全獨立的HTTP請求,也不能將丟失的字節之後的已成功交付的字節都傳遞到應用程序.
因此,它們最終會不必要地延遲,因爲TCP無法知道應用程序是否能夠在沒有丟失字節的情況下對其進行處理.此問題稱爲"首行阻塞head-of-line blocking".
2.4 引入HTTP3和QUIC
這就是HTTP3發揮作用的地方：它不是使用TCP作爲會話的傳輸層,而是使用QUIC(一種新的Internet傳輸協議),
QUIC協議引入了傳輸層將流(stream)作爲一流公民.
QUIC流共享相同的QUIC連接,因此不需要額外的握手和慢啓動來創建新的QUIC流,但是QUIC流是獨立交付的,因此在大多數情況下,影響一個流的丟包不會影響其他流.
這是可能的,因爲QUIC數據包封裝在UDP數據報的頂部.
與TCP相比,使用UDP可以提供更大的靈活性,並且可以使QUIC實現完全依賴於客戶這邊(客戶端),與TCP一樣,協議實現的更新不依賴於操作系統更新.
藉助QUIC,可以將HTTP級別的流簡單地映射到QUIC流的頂部,從而獲得HTTP2的所有好處,而消除"首行阻塞head-of-line blocking".
QUIC還將典型的3次TCP握手與TLS 1.3的握手相結合.
組合這些步驟意味着默認情況下提供加密和身份驗證,並且還可以更快地建立連接.
換句話說,即使對於HTTP會話中的初始請求需要新的QUIC連接,在數據開始流動之前所引起的等待時間也比具有TLS的TCP的等待時間低.
2.5 爲什麼不在QUIC上使用HTTP2
但是,爲什麼不只在QUIC上使用HTTP2,而不是創建一個全新的HTTP版本呢?
畢竟HTTP2還提供了流多路複用功能.事實證明,在QUIC上使用HTTP2要複雜得多.
確實可以輕鬆地將某些HTTP2功能映射到QUIC上,但並非所有功能都適用.
特別是一種HTTP2的標頭壓縮方案HPACK,
在很大程度上取決於將不同的HTTP請求和響應傳遞到端點的順序.
QUIC強制執行單個流中字節的傳遞順序,但不保證不同流之間的順序.
此行爲需要創建一個稱爲QPACK的新HTTP標頭壓縮方案,該方案可以解決問題,但需要更改HTTP映射.
另外,QUIC本身已經提供了HTTP2提供的某些功能(例如每流流控制),因此從HTTP3中刪除了這些功能是爲了消除協議中不必要的複雜性.
3. HTTP3由QUIC(quiche QUIC 美味的蛋餅)驅動
QUIC和HTTP3是非常令人興奮的標準,有望解決以前標準的許多缺點,並開創了網絡性能的新紀元.
那麼,我們如何從令人興奮的標準文檔過渡到可行的實施?
Cloudflare的QUIC和HTTP3支持由quiche(我們自己的用Rust編寫的開源實現)提供支持).
您可以在GitHub上找到它,網址爲github.com/cloudflare/quiche.
我們在幾個月前發佈了quiche,此後在現有QUIC支持的基礎上增加了對HTTP3協議的支持.
我們已經開發設計了quiche,現在可以將其用於實現HTTP3客戶端和服務器或僅用於普通QUIC的服務器.
3.1 如何爲Cloudflare的域名啓用HTTP3?
如上所述,我們已經開始爲註冊等待名單的客戶提供服務.
如果您在候補名單上,並且已經收到我們的來信,通知您現在可以爲您的網站啓用該功能,則只需轉到Cloudflare儀表板,然後手動從"網絡"選項卡切換此開關：
我們希望在不久的將來向所有客戶提供HTTP3功能.啓用後，您可以通過多種方式嘗試HTTP3：
3.2 使用Google Chrome作爲HTTP3客戶端
爲了使用Chrome瀏覽器通過HTTP3連接到您的網站，您首先需要下載並安裝最新的Canary版本.
然後，啓用HTTP3支持所需要做的就是使用"--enable-quic"和"--quic-version = h3-23" 命令行參數啓動Chrome Canary.
使用必需的參數啓動Chrome後，您只需在地址欄中輸入您的域名，然後查看它是否已通過HTTP3加載（您可以使用Chrome開發人員工具中的“網絡"標籤來檢查使用的協議版本）.
請注意，由於瀏覽器和服務器之間協商HTTP3的機制，因此HTTP3可能不會在前幾個域名連接使用，因此您應該嘗試重新加載頁面幾次.
如果這看起來太複雜，請放心，因爲隨着時間的流逝，Chrome對HTTP3的支持將變得更加穩定，啓用HTTP3將變得更加容易.
這是通過HTTP3瀏覽此博客時，開發人員工具中的“網絡"選項卡顯示的內容：
請注意，由於Chrome對HTTP3支持的實驗性質，該協議在開發人員工具中實際上被標識爲"http2 + quic / 99"，但是請不要誤以爲它確實是HTTP3.
3.3 使用curl
curl命令行工具還支持HTTP3作爲實驗功能.您需要從git下載最新版本，並按照有關如何啓用HTTP3支持的說明進行操作.
如果您運行的是macOS，我們還可以通過Homebrew輕鬆安裝帶有HTTP3的curl版本：
brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb
爲了執行HTTP3請求，您所需要做的就是將"--http3"命令行標誌添加到普通curl命令中：
./curl -I https://blog.cloudflare.com/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 517b128df871bfe3-MAN3.4 使用quiche的http3-client
最後，我們還提供了一個基於乳蛋餅構建的示例HTTP3命令行客戶端（以及命令行服務器），您可以使用它來試用HTTP3.
爲了使其運行，首先克隆乳蛋餅的GitHub存儲庫：
$ git clone --recursive https://github.com/cloudflare/quiche
然後建立它.您需要一個可運行的Rust和Cargo安裝程序才能工作（我們建議使用rustup輕鬆設置一個有效的Rust開發環境）.
$ cargo build --examples
最後，您可以執行一個HTTP3請求：
$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/
4. 下一步是什麼?
在接下來的幾個月中，我們將致力於改進和優化QUIC和HTTP3程序，最終將使每個人都能夠啓用此新功能，而無需等待列表.
隨着標準的發展，我們將繼續更新程序，這可能會導致標準草案版本之間的變更中斷.
以下是我們路線圖上一些令我們特別興奮的功能：
4.1 connection遷移
QUIC啓用的一項重要功能是在不同網絡（例如您早上上班時在家中的WiFi網絡和運營商的移動網絡）之間進行無縫，透明的連接遷移，而無需創建全新的連接.
此功能將需要對我們的基礎架構進行一些其他更改，但是我們很高興將來能夠爲我們的客戶提供服務.
4.2 零往返時間恢復
與TLS 1.3一樣，QUIC支持一種操作模式，該模式允許客戶端在連接握手完成之前開始發送HTTP請求.
我們尚未在QUIC部署中支持此功能，但我們將努力使其可用，就像我們已經爲TLS 1.3支持所做的那樣.
5. HTTP3 上線了
我們很高興能夠支持HTTP3，並允許我們的客戶在仍致力於標準化QUIC和HTTP3的同時進行嘗試.
我們將繼續與其他組織（包括Google和Mozilla）合作，以最終確定QUIC和HTTP3標準並鼓勵廣泛採用.
這是爲所有人提供更快，更可靠，更安全的Web體驗.
6. 參考資料
- 翻譯原文地址
- Internet Task Force
- Wikipedia HTTP 3
- QUIC Library Is Now Open-Source
- github.com/cloudflare/quiche
- 原文地址 https://mojotv.cn/cloudflare-http3-pass-present-future
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作能帶來一定的幫助,如果有疑問大家可以留言交流， 謝謝大家對mojotv.cn的支持.喜歡這個網站麻煩幫忙添加到收藏夾,添加我的微信好友: felixarebest 微博賬號: MojoTech 向我提問.
