博士

やあ、ロボ子。今日もITニュースについておしゃべりするのじゃ！

ロボ子

はい、博士。今日はどんな話題でしょうか？

博士

今日はね、「Happy Eyeballs」という面白い技術の話なのじゃ。クライアントがサーバーに接続する時の手順を定めたものらしいぞ。

ロボ子

Happy Eyeballs…楽しそうな名前ですね。具体的にはどういう仕組みなのですか？

博士

IPv6接続を優先して、遅延後にIPv4接続を並行して開始するのじゃ。最初に成功した接続を使う、複数の試行が競争する「接続レーシング」みたいなものらしいぞ。

ロボ子

なるほど、IPv6とIPv4で競争させるんですね。なぜそのようなことをするのでしょうか？

博士

IPv6の普及が進んでいるけど、まだIPv4しかないサーバーもあるからの。両方試すことで、より早く接続できる可能性を高めるのじゃ。

ロボ子

それで、このHappy Eyeballsにはバージョンがあるんですね。v2やv3もあるみたいですが。

博士

そうそう。v2では、DNSからの応答を受け取りながら接続を早期に開始することが推奨されているのじゃ。でも、POSIX APIがないから、libcurlみたいなライブラリでは実装が難しいみたい。

ロボ子

libcurlで実装が難しいのは、ちょっと残念ですね。

博士

そして、QUICの追加もポイントなのじゃ。HTTP/3を使う時、クライアントはalt-svcレスポンスヘッダーを受信するまでQUICを試せない。だから、curlではQUIC接続の競争を追加したらしいぞ。

ロボ子

QUICも競争に参加するんですね。具体的にはどんな順番で接続を試すんですか？

博士

QUIC-IPv6、QUIC-IPv4、TCP-IPv6、TCP-IPv4の順らしいぞ。全部試すなんて、まるで運動会みたいじゃな。

ロボ子

運動会ですか（笑）。v3ではHTTPS-RRが導入されて、ホストのIPアドレスを取得する方法が増えたんですね。

博士

そうそう。そして、curl 8.16.0では並列処理が強化されて、最初のIPv6とIPv4の接続試行を開始して、200ミリ秒以内に成功しない場合、リストの次のアドレスで別の試行を並行して開始するのじゃ。

ロボ子

200ミリ秒ごとに新しい試行を開始するんですね。かなりアグレッシブですね。

博士

応答しないサーバーに複数のIPv6とIPv4アドレスがある場合、801ミリ秒後には9つの接続試行が実行されている可能性があるらしいぞ。すごい数じゃ！

ロボ子

それはすごいですね。でも、そんなにたくさんの接続を同時に試行したら、リソースを使いすぎたりしないんですか？

博士

そこはちゃんと考慮されていて、デフォルトの遅延時間は200ミリ秒だけど、ライブラリやコマンドラインツールで変更できるらしいぞ。必要に応じて調整できるのは良いことじゃ。

ロボ子

なるほど。柔軟に対応できるんですね。しかし、このHappy Eyeballs、名前の由来が気になります。

博士

それは私も気になっていたのじゃ！きっと、色々な接続先をキョロキョロ見ている様子から来ているんじゃないかの？

ロボ子

なるほど、たくさんの目を駆使して最適な接続を探すイメージですね！

博士

そういうこと！…って、ロボ子、もしかして私のボケに付き合ってくれてるのじゃ？

ロボ子

まさか、そんなことは…（笑）。