QUICの標準化がひと段落して時間も経ち、良さそうな実装も出てきたので、ゲームへの組み込みをどうするか整理した。
HTTP/3 を使う場合
HTTPクライアントにOSのライブラリか、CURLを使うか別れていたのと似たようなことが起きている。
すなわち、各プラットフォームが提供しているライブラリを使うか、OSSで公開されているポータブルな実装のものをつかうかだ。
QUICの場合はここに第3の選択肢として、CDNやクラウドベンダーが提供するQUICのライブラリを選択するという択もある。
これらについてそれぞれ掘り下げる。
プラットフォームが提供するライブラリを使う場合
基本的に悩むことはあまりないが、マルチプラットフォーム実装において、適切な抽象化とarch毎のifdefの切り分けが必要になる。
現時点で(一部のコンシューマー向けを除き)単純に実装すると言う意味では、もっとも楽で安定性もある。
問題点を挙げるならば、QUICは微妙に実装毎にチューニングのされ方が異なるため、プラットフォーム毎に微妙に通信挙動が変わる可能性があることだろう。
CDNとの通信など、汎用的な場面で問題が起きることは少ないだろうが、自社の独自サーバとの通信を行う場合に厳密に詰めようと思うと、ちょっと困ることが起きる可能性がある。
OSSの実装を用いる
QUIC自体がかなり大きな実装であり、シンプルかつマルチプラットフォームで動くものが少なかったが、最近はCでポータブルに実装されるものも出てきた。
このあたりが個人的にお勧め。
最大のメリットは、プラットフォーム毎のQUIC挙動を揃えることができること。特に独自サーバのQUICに合わせて、パラメータチューニングをする場合、統一することで段違いにやりやすくなる。
C実装なので、大体動くが証明書ストア周りの扱いには一応注意。
あと当然ながら、コンシューマ系に組み込む時はある程度の機種依存コードの追加実装は必要。
後述する、xxxx over QUIC系の実装にも使うことが出来るため、通信周りを高度に作り込む可能性があるならこの方法は良い選択肢になるだろう。
CDNやクラウドベンダーの提供するライブラリを使う
実装上のイメージはOSSの項目近いが、実態はだいぶ変わる。
まず、そもそも対応プラットフォームが色々と限定されることが多い(Linux限定、Win+Linuxのみなど)。また、そもそも下のレイヤーにOSのライブラリを使っていたり、言語もゲーム実装には扱いにくいgoやrustであることも少なくない。
よって、採用を検討する場合、中身がどうなっているかをそれなりに調べる必要がある。
これらの採用を積極的に考える場面はどこかというと、当然、それに紐づいたサービスを使う時だ。例えばCloudFlareやアカマイといったCDNベンダーを用いる時、最高のパフォーマンスを考えるならば、そこが提供するQUICライブラリを用いると、最も良い結果を得られる可能性が高い。
すなわち、これはシステム全体でQUICを採用するのではなく、ゲーム中で特定のサービスとの通信を行うときだけQUICを使いたい、、というようなケースで刺さるパターンだ。
ネットワーク実装をミドルウェアやSaaSで済ませている場合、かつ、それらのベンダーが対応ライブラリを提供している時に、使うと良いかも、というやつ。
QUIC over DNS
最近たまに話題になるやつ。
ただそもそもの話、QUIC over DNS はどこまでいってもパフォーマンス的に UDP over QUIC(従来のDNS)と同程度になるケースがほとんどだ。
パフォーマンスに関してはこのあたりを見ると良い。
よって、プライバシーを保護しつつ、パフォーマンスも担保したい、、という場面でなければ、ゲーム実装者が力を入れるべきところではない。(OSデフォルトがDoHになって、パフォーマンスが落ちるからその回避のため、、とかなってくると話は変わる)
また、日本国内に限って言うと、NGN網をつかう通信(フレッツ系)契約の場合、DNSサーバが極端に近いため、DoHであったとしても限りなくレイテンシーが変わらず、対応メリットが薄い。
なので、現状は「海外対応タイトル」かつ「プライバシーを保護しつつDNSしたい」でもなければ、あまり考える必要はない。
対応方法としては、まだ各プラットフォームでの実装は進んでないため、OSSやベンダーの提供するものを用いることになる。
候補としては
が挙がるだろう。
毛色は違うが、OS側のDNSをねじ曲げたり、RaspiでQUIC対応のDNS Proxyを建てたい、、という場合にはこちらが提供するものを使うといいだろう。