如何觸發QUIC與QUIC的速度

QUIC連接可靠性

如果我們能夠檢測QUIC連接的兩端，就可以得知從用戶端到伺服器傳輸QUIC封包與從伺服器發出回應封包的可靠性。但我們無法掌控用戶端，所以只能依照從伺服器發送回用戶端的回應封包，或後續從用戶端收到的封包來得知可靠性。

表一為QUIC回應封包在24小時內的測量結果。伺服器上的連接狀態，初始連接的封包若沒有後續封包，表示QUIC連接失敗。由於發送第一次的QUIC封包不能確定是否失敗（短時間內會重新發送請求），因此表一中的失敗率是一個下限。

表一、QUIC連接失敗率

觸發 QUIC

之前提過，有兩種機制允許伺服器向用戶端發出訊號，表明它能夠使用QUIC支持 HTTP/3 會話。回顧這些機制：

•  替代服務指令，即：Alt-Svc: h3=”:443″。指示主機在UDP通訊埠443提供HTTP/3服務
• 具有已定義HTTPS DNS資源紀錄（Resource Record）的URL域名，其值為alpn=”h3″。

如何得知用戶使用哪一種？

替代服務指令Alt-Svc只在第二次搜索時使用，而定義DNS資源紀錄則在第一次使用時就建立。在實驗中，我們使用了這兩種不同的測試。五分之一的用戶端執行兩次搜索，每次間隔兩秒，剩餘用戶端執行一次。這兩種機制允許伺服器通知客戶端可以在第一次檢索時在Alt-Svc標頭中支持HTTP/3，然後在第二次檢索中使用 HTTP/3。

表二比較使用這兩種觸發的HTTP/3搜索率。如果用戶端在第一次搜索中沒有使用 HTTP/3，而是在第二次搜索改使用HTTP/3，就假設它使用了Alt-Svc機制。如果用戶端在第一次搜索就使用HTTP/3，就假設它使用HTTPS DNS的機制。

表二、QUIC觸發率

Chrome瀏覽器使用Alt-Svc指令，而iOS平台的Safari瀏覽器使用了DNS。從表格可看出Alt-Svc觸發程度是HTTPS DNS機制的四倍。造成這種差異的原因是，此次實驗中使用Chrome的用戶端大約占90%，表中用戶端中Alt-Svc的5%觸發率相當於在Chrome客戶端中有5.5%的觸發率；在整個測量樣本看到的DNS 1%的觸發率對應於Safari客戶端為20%到25%的觸發率。

QUIC更快嗎？

使用QUIC的動機之一是其序列延遲低於TCP和TLS會話。我們將測試此理論與實際使用上是否會有出入。

我們將比較用戶端使用HTTP/2加載1×1像素gif檔案的時間，和同一客戶端使用HTTP/3加載相同物件的時間。時間測量會有許多變量，包括瀏覽器內部任務調度等，但這些因素會因為有足夠大的樣本數可忽視。

圖一顯示+/- 500ms時間差。

圖一、QUIC與非QUIC搜索時間差

累積分佈顯示QUIC在2/3樣本中更快（圖二）。

圖二、檢索時間差累積分佈

總結

HTTP/3和QUIC在現今網路中，正有一些可部署的趨勢，主要是由於Apple在最近發布iOS和MacOS系統版本中Safari的影響。

QUIC對IP封包分段（IP packet fragmentation）執行保守（conservative）的響應，最大封包大小要保持在1,200到1,360位元組。

 由於Chrome瀏覽器在網際網路中被廣泛使用，QUIC的主要觸發機制仍是Alt-Svc指令，儘管Apple用戶端Safari是使用DNS HTTPS機制。

最重要的是，HTTP/3和QUIC通常比TCP和TLS更快。

在未來幾個月中，將可繼續追蹤QUIC的部署。這些報告可在APNIC labs獲得。

「認識QUIC」系列完結，本系列共五篇。(5/5)

相關連結：

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

檢自：

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