- QUICはWebアプリケーションの性能向上に画期的な変化をもたらすと期待されるプロトコルだが、性能は期待に及ばない
- この論文では、高速ネットワークにおけるQUICの性能を体系的に分析する
要旨
- 高速インターネットにおいて、UDP+QUIC+HTTP/3スタックはTCP+TLS+HTTP/2と比べて最大45.2%のデータ転送スループット低下を示す
- QUICとHTTP/2の性能差は、基礎帯域幅が増加するほど大きくなる
- この問題は、軽量データ転送クライアントと主要Webブラウザ（Chrome、Edge、Firefox、Opera）、多様なホスト（デスクトップ、モバイル）、多様なネットワーク（有線ブロードバンド、セルラー）で観測される
- ファイル転送だけでなく、動画ストリーミング（最大9.8%の動画ビットレート低下）、Webブラウジングなど多様なアプリケーションに影響を与える
- 厳密なパケット追跡分析とカーネルおよびユーザー空間のプロファイリングを通じて根本原因を特定する
- 特に、過剰なデータパケットとQUICのユーザー空間ACKによって受信側の処理オーバーヘッドが高い
- 観測された性能問題を緩和するための具体的な推奨事項を提示する
性能低下の根本原因
- 受信側のカーネルレベルで過剰なパケット処理オーバーヘッドが発生
- QUICはUDP GRO（Generic Receive Offload）を使用しないため、TCPに比べてはるかに多くのパケットを処理しなければならない
- これは
netif_receive_skb関数の呼び出し回数がQUICで大幅に多いことから確認される
- ユーザー空間でもQUICの過剰なパケット処理オーバーヘッドが発生
- カーネルから渡された多数のパケットを処理する際のオーバーヘッドが大きい
- ユーザー空間でQUIC ACKを生成することもオーバーヘッドの原因となる
性能低下緩和のための提案
- 受信側でUDP GROを導入
- UDPスタックで処理すべきパケット数を減らし、カーネルおよびユーザー空間のオーバーヘッドを低減
- ただし、多様なクライアント環境でUDP GROを展開するのは容易ではない可能性がある
- GSO/GROのようなオフロードソリューションをQUIC向けに改善
- 異なるサイズのUDPパケットトレインもオフロードできるように支援
- GSOに適切なペーシング設定を追加してネットワーク輻輳を防止
- 受信側のQUICロジックを最適化
- QUIC ACK送信を遅延させ、応答生成オーバーヘッドを低減
recvmmsgを使って一度に複数のUDPパケットを読み取り、性能を改善
- マルチスレッドダウンロードを使用
- 大容量ファイルでは、複数CPUコアを活用したマルチスレッドダウンロードで受信性能を向上できる
- ただし、公平性の問題を考慮する必要がある
1件のコメント
Hacker Newsの意見