如何觸發QUIC與QUIC的速度

QUIC連接可靠性

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

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

Initial QUIC connections 19,211,357
Failed connections 46,645
Failure rate 0.24%

表一、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的機制。

Used DNS HTTPS Query 1%
Used Alt-Svc Header 5%

表二、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)

發佈留言

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

回到頂端