QUIC的測量與資料封包大小

QUIC 測量

從2022年6月開始測量,整理出QUIC用戶中查詢HTTPS DNS資源紀錄和使用HTTP/3檢索URL的用戶數量。(圖一)

圖一、2022年6月QUIC數量測量結果

有趣的是,查詢HTTPS DNS資源紀錄的用戶數量佔10%到15%,但使用HTTP/3 檢索的用戶數量只有1.5%。如果戶端的瀏覽器能夠針對HTTP/3設置查詢DNS記錄,那麼為什麼使用HTTP/3進行後續查詢的數量較低?又有哪些用戶端使用HTTP/3?晚點再來探討這個問題。

觀察各區域使用HTTP/3進行查詢的分布也很有趣(圖二)。

圖二、各區域使用QUIC分佈

QUIC在丹麥、瑞典、挪威和瑞士較高,而在亞洲、南美洲和非洲地區較低(詳見QUIC完整報告

哪些客戶端使用 HTTP/3?

將每次HTTP查詢時瀏覽器的字串與使用的協議(HTTP/2或HTTP/3)進行匹配,可以得知那些平台和瀏覽器正在使用HTTP/3進行查詢(表一)。注意!把瀏覽器的字串作為資料來源並不完全準確,這裡只依資料比例,推測系統和瀏覽器執行HTTP/3的分布情況。

表一、系統與HTTP/3

HTTP/3 Non-HTTP/3
Android 47.7% 84.5%
iOS 44.5% 5.5%
Win 10.0% 5.5%
Mac OS X 1.5% 1.0%
Win7/8 1.0% 1.0%
Linux 0.3% 0.4%

表一包括使用「非QUIC」的資料作為比較。很明顯,這裡主要變化是在於iOS設備(iPhone和iPad)使用HTTP/3的數量。

針對瀏覽器做比較

表二、瀏覽器與HTTP/3

HTTP/3 Non-HTTP/3
Chrome 52.2% 91.7%
Safari 44.6% 4.3%
Firefox 2.2% 0.8%
Edge 0.6% 0.7%
Opera 0.3% 0.2%

表二中使用Safari瀏覽器進行QUIC使用,這與表一中呈現的iOS系統資料有很大的關聯性。

現今,在網路中HTTP/3和QUIC使用率不到一半,似乎是由於iOS系統和Safari瀏覽器市佔率高的原因。

QUIC封包大小

如[RFC9000]所述「UDP資料報絕不能在IP層分段。且戶端必須確保初始UDP資料報具有至少為1,200位元組的UDP有效負載,並依狀況添加填充位元(padding)將封包填滿。」意味著QUIC的實現必須控制封包大小,避免在傳輸路徑中被分段。

其中一種方式是執行路徑MTU探索(Path MTU Discovery)取得最小MTU的值。另一種方法是選擇一個大小相對安全的封包,就不會被分片。

為了回答用於QUIC的封包最大傳輸大小的問題,我們查看了每個QUIC會話(session)的封包最大長度(圖三)。

圖三、QUIC封包最大長度分布

最常見的會話封包大小為1,200位元組,佔所有會話的46%。接下來最常見的大小是1,250位元組佔18.5%,和1,252位元組佔16.4%。而沒有封包超過1,357位元組。

未來將持續探討「認識QUIC」系列,本系列共五篇。(4/5)

相關連結:

Geoff Huston(2022). A look at QUIC use. APNIC.

檢自:

https://blog.apnic.net/2022/07/11/a-look-at-quic-use/ (Aug. 29, 2022)

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

回到頂端