本記事は、TechFeed Experts Night#13 〜 HTTP3/QUIC…Webプロトコル最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。

本セッションの登壇者

セッション動画

@yuyarinと申します。前職では@kensaku_komatsuさんと同じ会社でクラウドを作っていました。現職はモバイルキャリアでエッジコンピューティングの基盤を作っているので、ぜひWebRTCをモバイル網で超低遅延で実現できるといいと思っています。私の本職はネットワーク側ですので、今回はネットワークから見たときにQUICはどう見えているのかをご紹介したいと思います。

ネットワークから見たQUICのインパクトは「この10年で最大」

IPネットワークから見ると、QUICはこの10年で一番大きなインパクトがある新プロトコルといえます。これまでも、20年前くらいにHTTPSが登場したときや、10年くらい前にBitTorrentやWinnyなどのアップロード型のプロトコルが登場したとき、ISP/ネットワーク事業者は大きな影響を受けましたが、QUICはそれ以来のインパクトがあるプロトコルです。

QUICのインパクトが大きい理由は、世界的な規模で利用されるUDPベースの新プロトコルであるということです。

QUICとNAT

このように大きなインパクトを持つ新プロトコルが世界規模で使われ始めると、トラブルもときどき発生します。たとえばこちらのツイートのように、ルータのNATを圧迫している理由を調査したところ、QUICだったということがありました。

NAT(Network Address Translation)は、プライベートのIPv4アドレスをパブリックのIPv4アドレスに変換し、複数の端末間でパブリックのIPv4アドレスを共有できます。NATは日常のさまざまな場面で使われており、みなさまのご家庭のブロードバンドルータや企業のネットワーク、マンションのISPやホテルのインターネット接続もNATで実現されています。また、モバイルキャリアでもNATは使われています。モバイル端末に設定されているIPv4アドレスはプライベートアドレスですので、これをキャリアグレードの大規模なNATでパブリックアドレスに変換してインターネット通信を実現しています。

NATでは、5-tuple(送信元IPアドレス/宛先IPアドレス/プロトコル/送信元ポート番号/宛先ポート番号)で通信を区別して状態を管理し、それぞれの通信をパブリックアドレスとポートにマッピングしています。これらのマッピング情報はNATテーブルとしてメモリなどに保持されますが、このテーブルのサイズには上限があります。上限を超えてしまう、つまりNATテーブルがあふれると、QUICだけでなくTCPも含めた新たな通信ができなくなってしまいます。

QUICを使うとNATテーブルがあふれやすくなる理由は、

1. UDPを使っていること
2. ヘッダが暗号化されていること

というQUICの新しい特徴によるものです。

NATエントリーは通信が終わったら削除することでNATテーブルがあふれないようにしています。TCPの場合はFINパケットでコネクションの終了を検知してNATエントリーを削除できますが、UDPの場合はコネクションの終了を検知する方法がないため、ルータが能動的にNATエントリーを削除できません。

そこで、無通信時間のタイマー(最後にそのコネクションでの通信が行われてからの経過時間)をもとにコネクションが終了したと判断し、NATエントリーを削除するしかありません。したがって、TCPを使うHTTP/2では即時に消えていたNATエントリーが、UDPを使うQUICではタイマーの時間だけNATエントリーが残り続けてテーブルを圧迫します。

さらに、パブリックIPアドレス1つに対して使用できるポートは6万程度に限られるため、QUICのNATエントリーが残っている間はポートが専有され、エントリーが消えないとポート番号を消費し続けてしまいます。最終的にはマッピング先のパブリックIPアドレス側の送信元ポート番号もなくなって、他の通信ができなくなってしまいます。

ネットワーク側のQUICへの対応

では「QUICヘッダを見てコネクションの終了を検知する」という対応はできないのでしょうか。QUICは最低限の部分をのぞき、ヘッダが暗号化されています。また、プロトコルの仕様上、クローズせずにコネクションが終了することもあります。そのため、QUICヘッダをもとにコネクションの終了を検知することはできません。

NATテーブルがあふれる問題へのネットワーク側での対応のひとつは、NATのUDPタイマー値を減らすことです。RFC 4787での推奨値は5分ですが最低2分まで許容されているので、変更可能であればUDPタイマー値を2分(120秒)まで減らすことで対応できます。ただし、これは一時的な対処で、根本的にはルータをセッション数上限が大きな新しいもの/高性能なものに置き換えることが必要です。こちらの表は日本でよく使われているルータ7社分(家庭用/キャリア用)を調査したもので、UDPタイマーのデフォルト値とセッション数上限をまとめています。

2つ目の対応方法はネットワークをIPv6対応にしておくことです。IPv6対応にすることで、NATの送信元ポートが枯渇する問題に対応できます。ただし、SPI(Stateful Packet Inspection; ファイアウォールの機能の一種)が有効な場合は、SPIのタイマーも考慮する必要があります。Manageability of QUIC Transport Protocolに30秒程度でQUICのコネクションが切れてしまうと書かれているのも、SPIのタイマーが原因です(下の表のC社、E社のルータもSPIのタイマーのデフォルト値は30秒)。SPIのタイマーがタイムアウトする前に、次のパケットを送らなければコネクションは切れてしまいます。また、ネットワーク側だけでなくアプリケーションがIPv6に対応していないと、効果がないことにも注意が必要です。

QUICを使うアプリケーション開発側の対応 - IPv6を使ってください!

これらの事情もあり、アプリケーションを開発する側のみなさまは、QUICを使う場合にはIPv6で使っていただけると、ネットワーク側は大変助かります。

また、ネットワーク業界でもQUICのような新しいプロトコルを積極的にサポートできるよう、対処方法やネットワーク設計上の注意点をJANOG(日本ネットワークオペレーターズグループ; ネットワーク運用者が集まるイベント)などで共有しています。

• QUICとNATと
• QUICについて話そう

ネットワーク側から見たQUICの利点

QUICには悪いところだけではなく、とても嬉しいところがあります。私の本業であるモバイルキャリアでは、端末の移動(例: 5Gエリア→LTEエリア→5Gエリア)の際のIPアドレスの変化によって通信が切断されるという課題があります。QUICであれば、モバイルキャリア側はIPアドレスの変化による影響を気にする必要がなくなるため、個人的にはすべての通信がQUICになればと思っています。

最後にもう一度、IPv6でQUICをどんどん使っていただくことをみなさまにお願いします。

ご清聴、ありがとうございました。

本記事は、TechFeed Experts Night#13 〜 HTTP3/QUIC…Webプロトコル最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。