訂閱以接收新文章的通知:

檢查 HTTP/3 一年來的使用情況

2023-06-06

閱讀時間:9 分鐘
本貼文還提供以下語言版本:English日本語한국어简体中文

2022 年 6 月,在發佈了一組與 HTTP 相關的網際網路標準(包括正式定義 HTTP/3 的 RFC)後,我們發佈了 HTTP RFC 的演變情況:Cloudflare HTTP 使用趨勢檢視。一年過去了,隨著 RFC 迎來一週歲生日,我們認為回顧過去一年這些趨勢的演變將會很有意義。

Examining HTTP/3 usage one year on

我們之前的文章回顧了 2021 年 5 月至 2022 年 5 月期間在 Cloudflare 網路中觀察到的 HTTP/1.1HTTP/2HTTP/3 使用趨勢,按版本和瀏覽器系列以及搜尋引擎索引和社群媒體機器人進行分類。當時我們發現,儘管 HTTP/3 的使用量顯示出增長的跡象,但瀏覽器驅動的流量絕大多數使用 HTTP/2。搜尋和社交機器人對 HTTP/1.1 與 HTTP/2 的偏好各不相同,但幾乎沒有使用 HTTP/3。

在 2022 年 5 月至 2023 年 5 月期間,我們發現 HTTP/3 在瀏覽器擷取內容中的使用率持續增長,但搜尋引擎索引和社群媒體機器人仍然實際上忽略了最新版本的 Web 核心通訊協定。(儘管如此,HTTP/3 的優勢是以使用者為中心的,對於旨在非同步爬蟲作業和索引內容的機器人來說,其優勢微乎其微。這可能是我們看到這些自動使用者代理程式採用率如此之低的一個關鍵原因。)此外,HTTP/3 在 API 流量中的使用率仍然很低,但在這一年中翻了一番。使用 Cloudflare 免費服務層級的區域預設啟用對 HTTP/3 的支援,而付費客戶可以選擇啟動支援。

HTTP/1.1 和 HTTP/2 使用 TCP 作為傳輸層,並透過 TLS 新增安全性。HTTP/3 使用 QUIC 來提供傳輸層和安全性。由於傳輸層的差異,使用者代理程式通常需要先瞭解可以使用 HTTP/3 存取來源,然後再嘗試。一種探索方法是 HTTP 替代服務,即伺服器傳回 Alt-Svc 回應標頭,其中包含受支援的應用程式層通訊協定交涉識別碼 (ALPN ID) 清單。另一種方法是 HTTPS 記錄類型,用戶端查詢 DNS 以瞭解支援的 ALPN ID。HTTP/3 的 ALPN ID 是「h3」,但在規範處於開發和反覆運算階段時,我們新增了一個尾碼來標識特定的草案版本,例如「h3-29」標識草案 29。為了對廣泛的用戶端保持相容性,Cloudflare 公告了「h3」和「h3-29」。然而,草案 29 已於近三年前發佈,客戶已跟上對最終 RFC 的支援。截至 2023 年 5 月下旬,Cloudflare 不再為啟用了 HTTP/3 的區域公告 h3-29,這有助於在每個本需要包含該內容的 HTTP 回應或 DNS 記錄上節省幾個位元組。由於瀏覽器和 Web 伺服器通常會自動協商可用的最高 HTTP 版本,因此 HTTP/3 優先於 HTTP/2。

在下面的部分中,基於 Cloudflare 機器人評分的「可能為自動化」和「自動化」流量已被篩選掉,未用於桌面和行動瀏覽器分析,以將分析限制為「可能是人類」流量,但在搜尋引擎和社群媒體中機器人分析中是包含這些流量的。此外,下文中提到的 HTTP 請求或 HTTP 流量包括透過 HTTP 和 HTTPS 發出的請求。

基於 HTTP 版本的總體請求分佈情況

透過每天將全球 Web 流量彙總到 Cloudflare,我們可以觀察一年的調查期間內 HTTP/1.1、HTTP/2 和 HTTP/3 的使用趨勢。從 5 月到 9 月底,HTTP/1.1 流量所占比例從 8% 下降到 7%,但到 10 月又迅速增長到 11% 以上。進入新一年的一月份後,它一直保持在高位,到 2023 年 5 月回落到 9%。有趣的是,在 10 月份增加之後,工作日/週末的流量模式變得更加明顯,並在隨後的 6 個月中保持不變。HTTP/2 請求份額在這一年中出現了微弱的變化,從 2022 年 5 月的 68% 左右開始,到 6 月開始略有下降。此後,它的份額變化不大,在期間結束時僅略低於 64%。HTTP/2 沒有明顯的工作日/週末模式。通過 HTTP/3 的請求份額從 2022 年 5 月剛剛超過 23% 開始,到 8 月和 9 月增長到剛剛超過 30%,但到 11 月又下降到 26% 左右。在經歷了一些微弱的下降和增長之後,它在調查期結束時的份額為 28%。(請注意,由於在 6 月初產生圖表時遇到資料保留限制,本圖表從 5 月下旬開始。)

基於 HTTP 版本的 API 請求分佈情況

儘管 API 流量占 Cloudflare 請求量的很大一部分,但這些請求中只有一小部分是透過 HTTP/3 發出的。大約一半的此類請求是透過 HTTP/1.1 發出的,另外三分之一是透過 HTTP/2 發出的。不過,API 的 HTTP/3 使用率從 2022 年 5 月的約 6% 增長到了 2023 年 5 月的 12% 以上。HTTP/3 的流量份額較小,部分原因可能是 curl 等關鍵工具對 HTTP/3 的支援仍被視為「實驗性」。如果這種情況在未來發生變化,隨著 HTTP/3 在此類工具中獲得一流的支援,我們預計這將加速 HTTP/3 使用率在 API 中和整體上的增長。

基於 HTTP 版本的已緩解請求分佈情況

上述分析考慮了向 Cloudflare 發出的所有 HTTP 請求,但我們也認為,研究潛在惡意流量的 HTTP 版本使用情況會很有趣,因此我們分解了那些透過 Cloudflare 應用程式安全解決方案之一得到緩解的請求。上圖顯示,絕大多數被緩解的請求是透過 HTTP/1.1 和 HTTP/2 發出的,透過 HTTP/3 發出的請求一般不到 5%。被緩解的請求似乎最常透過 HTTP/1.1 發出,不過 HTTP/2 在 8 月初到 11 月下旬期間佔據了更大的份額。這些觀察結果表明,攻擊者似乎並沒有投入精力升級他們的工具以利用最新版本的 HTTP,而是認為舊版本的通訊協定足以滿足他們的需求。(請注意,由於在 2023 年 6 月初生成圖表時遇到資料保留限制,本圖表從 2022 年 5 月下旬開始。)

桌面瀏覽器的 HTTP/3 使用情況

正如我們去年指出的那樣,主要瀏覽器的穩定發佈通道中對 HTTP/3 的支援分別於 2020 年 11 月(Google Chrome 和 Microsoft Edge)以及 2021 年 4 月 (Mozilla Firefox) 提供。我們還注意到,在 Apple Safari 中,需要在生產版本的「實驗功能」開發人員功能表中啟用 HTTP/3 支援。然而,在 Safari 的最新版本中,似乎不再需要此步驟,現在原生支援 HTTP/3。

從各瀏覽器的請求份額來看,Chrome 瀏覽器在開始階段占 HTTP/3 請求量的 80% 左右,但隨著 Safari 瀏覽器的持續增長,到 2023 年 5 月,這一比例下降到 74% 左右。一年前,Safari 瀏覽器在 Cloudflare 的 HTTP/3 流量中所占比例不到 1%,但到 2023 年 5 月,這一比例增長到了近 7%,這可能是支援從實驗階段過渡到生產階段的結果。

從圖表中再次移除 Chrome 瀏覽器後,其他瀏覽器的趨勢更加明顯。如上所述,Safari 瀏覽器在去年經歷了大幅增長,而 Edge 瀏覽器在 2022 年 6 月從略低於 10% 躍升至略高於 11%。在新的一年裡,它一直保持在這一水準附近,然後在接下來的幾個月裡逐漸降至 10% 以下。Firefox 瀏覽器略有下降,從 10% 左右降至 9% 以下,而 Internet Explorer 瀏覽器報告的 HTTP/3 流量幾乎為零。

正如我們在去年的文章中所做的那樣,我們也想看看 HTTP 版本的份額在過去一年中在各主流瀏覽器中的變化情況。HTTP/2 和 HTTP/3 在過去一年中相對穩定,這與去年所發表文章中的觀察結果形成了鮮明對比,去年的觀察結果表明,在 2021 年 5 月至 2022 年 5 月期間,HTTP/2 和 HTTP/3 發生了一些明顯的變化。

在按通訊協定版本查看主要桌面瀏覽器系列的請求份額時,我們發現在所有這些瀏覽器系列中,HTTP/1.1 份額在 10 月底都在增長。進一步的分析表明,這種增長是由於幾個大型用戶端區域的 HTTP/1.1 請求量顯著增加,但尚不清楚為什麼會出現使用舊版本 HTTP 的流量湧入。顯然,HTTP/2 仍然是主要瀏覽器用於內容請求的主要通訊協定,始終占 Chrome 瀏覽器和 Edge 瀏覽器請求量的 50-55%,以及占 Firefox 瀏覽器的約 60%。然而,對於 Safari 瀏覽器來說,由於 HTTP/3 使用量的增長,HTTP/2 的份額從 2022 年 5 月的近 95% 下降到一年後的 75% 左右。22 年 5 月的近 95% 下降到一年後的 75% 左右。

這一年裡,Safari 瀏覽器上的 HTTP/3 份額從不到 3% 增長到近 18%,而在其他瀏覽器上的份額則更為一致,Chrome 瀏覽器和 Edge 瀏覽器徘徊在 40% 左右,Firefox 瀏覽器則在 35% 左右,兩者都顯示出明顯的工作日/週末流量模式。(這種模式可以說在 Edge 中最為明顯。)這種模式在 2022 年底的 Safari 中變得更加明顯,但仍然很勉強,其變化往往不到百分之一。

行動瀏覽器的 HTTP/3 使用情況

行動裝置占 Cloudflare 請求量的一半以上,其中 Chrome Mobile 產生的請求占所有請求的 25% 以上,Mobile Safari 產生的請求量超過 10%。鑒於此,我們決定探索 HTTP/3 在這兩個主要行動平台上的使用情況。

在 Chrome Mobile 和 Chrome Mobile Webview(Chrome 瀏覽器的可嵌入版本,應用程式可使用該版本顯示 Web 內容)中,我們發現 HTTP/1.1 的使用率極低,最高不到請求的 5%。從 5 月到 9 月中旬,HTTP/2 的使用率從 60% 下降到 55%,但隨後又回升到接近 60%,在接下來的時間裡基本持平或略有下降。與此形成互補的是,HTTP/3 流量從 37% 增長到 45%,然後在 9 月中旬略低於 40%,一直持續到 5 月。使用模式最終看起來與桌面版 Chrome 瀏覽器非常相似,不過後者沒有明顯的工作日/週末流量模式。

Mobile Safari 和 Mobile Safari Webview 的使用模式與桌面 Safari 的使用模式非常相似,這也許並不令人意外。HTTP/1.1 的份額在 10 月份有所增加,而 HTTP/3 的份額增長強勁,從不足 3% 增長到接近 18%。

搜尋索引機器人

在探索搜尋引擎爬蟲/機器人對不同版本 HTTP 的使用情況時,我們發現去年的趨勢仍在繼續,HTTP/3 的使用率仍然很低(如上所述,這在一定程度上是意料之中的,因為 HTTP/3 是針對瀏覽器用例進行最佳化的)。由於正在調查四月份的異常資料,因此此處必應和百度的圖表截取了截至 2023 年 4 月 1 日的資料。

GoogleBot 仍然主要依賴 HTTP/1.1,通常占請求量的 55-60%。其餘部分幾乎全部是 HTTP/2,儘管 HTTP/3 使用量出現了微弱增長,在 3 月份達到了略低於 2% 的峰值。

到 2023 年 1 月,Microsoft 的 BingBot 約 85% 的請求是透過 HTTP/2 提出的,但在 1 月下旬下降到接近 80%。其餘請求都是透過 HTTP/1.1 提出的,因為 HTTP/3 的使用量可以忽略不計。

看看美國以外的搜尋引擎索引機器人,俄羅斯的 YandexBot 看上去幾乎只使用 HTTP/1.1,HTTP/2 的使用率一般在 1% 左右,不過在 8 月底至 11 月中旬期間使用率有所上升。目前還不清楚是什麼最終導致了這種增長。在 HTTP/3 上沒有看到有意義的請求量。中國搜尋引擎百度使用的索引機器人似乎也非常喜歡 HTTP/1.1,通常用於超過 85% 的請求。不過,HTTP/2 請求的百分比出現了幾次峰值,在 2022 年 7 月、11 月和 12 月以及 2023 年 1 月的幾天裡曾短暫達到 60% 以上,另外還有幾次峰值在 30% 左右。同樣,我們也不清楚是什麼導致了這種劇增的情況。百度也沒有實質上使用 HTTP/3。

社群媒體機器人

與上面必應和百度的情況類似,下面的圖表也是截至 4 月 1 日的資料。

在過去一年中,Facebook 使用 HTTP/3 進行網站爬蟲作業和索引的情況仍然接近於零,這與我們前一年觀察到的情況類似。HTTP/1.1 開始時占請求量的 60% 以下,除了 5 月下旬出現短暫的峰值之外,HTTP/1.1 的使用量在這一年中穩步下降,到 2023 年 4 月降至 30% 左右。與此同時,HTTP/2 的使用率從 2022 年 5 月的略高於 40% 增加到 2023 年 4 月的 70% 以上。Meta 工程師證實,這種棄用 HTTP/1.1 的轉變是其基礎架構對 HTTP 使用的預期漸進變化,並且他們正在慢慢努力從其基礎架構中完全移除 HTTP/1.1。

在去年的部落格文章中,我們指出「TwitterBot 顯然對 HTTP/2 有強烈且一致的偏好,占其請求的 75-80%,其餘部分為 HTTP/1.1。」這種偏好一直持續到 10 月初,此時 HTTP/2 使用率開始逐漸下降,到 2023 年 4 月僅略高於 60%。目前還不清楚是什麼原因導致 2022 年 5 月下旬 HTTP/2 出現長達一週的下降和 HTTP/1.1 激增。與去年一樣,TwitterBot 對 HTTP/3 的使用仍然不存在。

與 Facebook 和 Twitter 的網站爬蟲作業機器人相比,HTTP/3 在 LinkedIn 機器人的請求量中占比明顯,而且還在不斷增加,從 2022 年 5 月的不到 1% 增加到 2023 年 4 月的略高於 10%。我們去年曾指出,LinkedIn 對 HTTP/2 的使用從 2022 年 3 月開始激增,增長到請求量的約 5%。在今年的調查期間,該版本的使用率逐漸上升到 15%,但增長特別不穩定,呈尖峰狀,而不是平穩、持續的增長。HTTP/1.1 的份額雖然從 2022 年 5 月的 95% 左右降至 2023 年 4 月的 75%,但仍然是 LinkedIn 機器人使用的主要通訊協定。

結論

總的來說,我們很高興看到 HTTP/3 在基於瀏覽器的流量消耗中的使用率普遍提高,並且認識到,如果透過 curl 等關鍵工具的生產支援,HTTP/3 開始更積極地用於 API 交互,那麼 HTTP/3 將有機會進一步大幅增長。雖然很失望地看到搜尋引擎和社群媒體機器人對 HTTP/3 的使用仍然很少,甚至根本不存在,但我們也認識到,使用最新版本的 Web 基礎通訊協定所帶來的即時好處可能並不完全適用於非同步自動內容擷取。

您可以在 Cloudflare Radar 的「採用和使用情況」部分 (https://radar.cloudflare.com/adoption-and-usage) 關注這些趨勢和其他趨勢,也可以在 Twitter 上關注 @CloudflareRadar,或在 Mastodon 上關注 https://cloudflare.social/@radar

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
QUIC速度與可靠性安全性IETF

在 X 上進行關注

David Belson|@dbelson
Lucas Pardue|@SimmerVigor
Cloudflare|@cloudflare

相關貼文

2024年10月09日 下午1:00

Improving platform resilience at Cloudflare through automation

We realized that we need a way to automatically heal our platform from an operations perspective, and designed and built a workflow orchestration platform to provide these self-healing capabilities across our global network. We explore how this has helped us to reduce the impact on our customers due to operational issues, and the rich variety of similar problems it has empowered us to solve....

2024年10月08日 下午1:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

2024年10月06日 下午11:00

Enhance your website's security with Cloudflare’s free security.txt generator

Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!...

2024年10月02日 下午1:00

How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack

Over the past couple of weeks, Cloudflare's DDoS protection systems have automatically and successfully mitigated multiple hyper-volumetric L3/4 DDoS attacks exceeding 3 billion packets per second (Bpps). Our systems also automatically mitigated multiple attacks exceeding 3 terabits per second (Tbps), with the largest ones exceeding 3.65 Tbps. The scale of these attacks is unprecedented....