QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介

現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。

現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。

それがHTTP/3で「QUIC」が採用される大きな理由といわれています。

TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。

そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高いUDPを用いつつ、QUIC独自の通信制御などを組み込むことで信頼性を確保することで、より高速で信頼性を保つトランスポート層をHTTP/3に提供することが目指されました。

QUICの実装を、長年にわたって洗練されてきたTCPの実装並みにできるか？

そのQUICを実装するにあたり、長年にわたって改善と洗練が進められ、しかもカーネル内で動作している現在のTCPの実装と比べて（QUICの実装は基本的にユーザー空間で実行されるため）、見劣りしない程度の効率を達成できるのでしょうか。

Fastlyの奥一穂氏とJana Iyengar氏が同社のブログに投稿した記事「Can QUIC match TCP’s computational efficiency?」（QUICはTCPの計算効率に並ぶことができるか？）では、この問いについて同社の実装のベンチマークテストを行いつつ結果を紹介しています。

With the #QUIC working group at @ietf rolling out the new transfer protocol's first edition soon, many are wondering how high the computational cost will be.

There's still work to be done, but we believe QUIC can be as computationally efficient as #TCP: https://t.co/4ezdrC0iYv

— Fastly (@fastly) May 4, 2020

記事では、まず結論が次のように示されました。

「 Yes, QUIC can be as computationally efficient as TCP!」（イエス。QUICはTCP並みの計算効率を実現できる！）

それぞれの実装がCPUを100％利用したときに、どのくらいのスループットを達成できるかで計られたベンチマークでは、「TLS over TCP」が461Mbps、「QUIC」では464Mbpsと、QUICの方が高いスループットを実現しているのです。

TCPが「TLS 1.3 over TCP」となっているのは、QUICが暗号化プロトコルとしてTLS 1.3を内包しているのと同じ条件で比較するためです。

そしてQUICでは条件として（この記事では上の図が縮小されていて文字が小さくて読みにくくて申し訳ないのですが）「delayed ack、gso10、mtu1460」と補足されています。これら1つ1つがQUICの効率を高める最適化のための工夫となっています。

これらがそれぞれどういったものなのか、記事から要約して紹介しましょう（要約と引用について許可をいただきました）。

Ackを減らす、パケットをまとめる、パケットサイズを増やす

まず、実装上の工夫をなにもしない状態でのベンチマークの結果は以下のようになっています。QUICの実装は同社が開発しているquicly、TCPはLinuxのものにTLSとしてpicotlsを組み合わせたもの。このとき、QUICはTLS 1.3 over TCPの半分以下のスループットとなっています。

そこでQUICに対する1つ目の最適化はAcknowledgementを減らすこと、です。

QUIC仕様の推奨では、送信者、受信者ともに2パケットごとにAcknowledgementを返すことになっています。

これを10パケットごとにすることで、よりスループットを高めることができます。これはQUIC Delayed ACK extensionと呼ばれるプロポーザルとし、実装に反映されています。

次はGeneric Segmentation Offload (GSO)と呼ばれるLinuxの機能をUDPの処理に適用し、複数のパケットを仮想的に1つにまとめる実装の採用です。

これによってパケットの処理ごとに発生するコンテキストスイッチを減少させるなど、大幅な効率化が実現されました。

3つ目はパケットサイズの増加です。QUICのデフォルト最小パケットは1200バイト。これをTCPのペイロード並みの1460バイトに増加させることで、スループットは466Mbpsにまで増加。TCPを上回ることになりました。

今回のベンチマークでQUICはTCPに対して一定の効率性を実現し得ることが示されました。今後同社は、今回用いたQUICの実装であるquiclyにおいて、さらにさまざまな環境での効率化や高性能化を進めるとしています。

詳細についてはぜひ原文をご参照ください。

関連記事

• FastlyがHTTP/3とQUICのサポートを発表

2021年5月、QUICがRFC 9000としてインターネット標準となりました。

• HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として