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)
