Webサイトを開くとき、同じ名前から複数の接続先が見つかることがあります。IPv6とIPv4の両方のアドレスが分かっていても、両方の経路が正常に使えるとは限りません。最初に選んだ宛先から返事が来ないとき、その失敗が確定するまで次の宛先を試せなければ、画面が表示されるまでの待ち時間も長くなります。
Happy Eyeballs v2は、接続先を順番に試しながら、試行の時間を少しずつ重ねる仕組みです。RFC 8305で説明されているこの方法を、DNSで宛先を調べる段階と、実際につながるか確かめる段階に分けて見ていきます。
簡単にまとめると？
- IPv6とIPv4の候補を使い、先の接続試行の失敗を待ち切らずに、次の候補への試行を始めます。
- DNS応答を待つ50ミリ秒と、接続試行をずらす250ミリ秒は、RFCが示す別々の推奨値です。どの実装でも固定の値ではありません。
- 接続開始時の待ち時間を減らせても、その後の通信品質やWebサービスの正常動作まで保証する仕組みではありません。
宛先が分かることと、そこへつながること
DNSは、サイトの名前に対応するIPアドレスを調べる仕組みです。IPv6のアドレスはAAAAレコード、IPv4のアドレスはAレコードとして得られます。名前に住所が載っていても、途中の経路や宛先のサービスに問題があれば、通信は成立しません。
たとえば、IPv6側に設定の誤りがあり、IPv4側は正常なサイトを考えます。IPv6を先に試した端末が「返事が来ない」という理由だけで長く待つと、すでに使えるIPv4の経路があるのに利用者を待たせます。Happy Eyeballsは、この待ち方を変えます。
RFC 8305では、IPv6を優先する端末を基本の例にしつつ、IPv4の候補も交ぜて接続先を並べます。一つの種類のアドレスを全部試してから、もう一方へ移る並べ方を避けるためです。候補が多い場合も、最初のIPv6とIPv4の一組だけで終わる考え方ではありません。
少し遅れて始めた接続が先に通ることもある
接続試行は、全候補に一斉に送るのではなく、開始時刻をずらします。後の試行を始めても、進行中の先の試行はすぐには取り消しません。どれか一つの接続が成立したところで、残る試行をやめます。
次の表は、その違いを考えるための仮の例です。DNSで両方の宛先がすでに分かっており、次の試行まで250ミリ秒、IPv4の接続成立まで40ミリ秒かかると置いています。実測値や、すべての端末の動作を示すものではありません。
| 経過時間 | 端末の動き | ここで分かること |
|---|---|---|
| 0ミリ秒 | IPv6宛ての接続を開始 | 返事を待っている段階では、成否は未確定 |
| 250ミリ秒 | IPv4宛ての試行も開始 | IPv6の失敗が確定する前に次へ進める |
| 290ミリ秒 | IPv4の接続が成立 | 成立した接続を使い、残る試行を終了 |
この例で短くなるのは、使えない経路の結果を待っている時間です。回線そのものの速度が上がったわけではありません。一方、先の接続が次の試行を始める前に成立すれば、余分な接続試行を増やさずに済みます。開始をずらすことには、待ち時間と通信負荷の両方を考える意味があります。
50ミリ秒と250ミリ秒は、違う場面の待ち時間
接続前のDNS問い合わせにも、応答の順番という問題があります。RFCの推奨では、AAAAとAの問い合わせをほぼ続けて送り、両方の回答がそろうまで必ず待つことは避けます。AAAAの有効な応答が先なら、IPv6の接続試行へ進めます。
Aの有効な応答が先に届いた場合は、少し後にAAAAの応答が届く可能性を見込み、短く待ちます。この「Resolution Delay」の推奨値が50ミリ秒です。待っている間に有効なAAAA応答が来ればIPv6を試し、時間内に来なければ、得られたIPv4の候補で先へ進めます。AAAAが存在しないという正常な応答が来た場合も、その時点で進めます。
これに対して250ミリ秒は、経路の往復時間の履歴がない場合に、次の接続試行を始めるまでの「Connection Attempt Delay」の推奨値です。DNSの回答待ちとは開始点も役割も異なります。両方を足した時間が、常に接続完了までの待ち時間になるわけではありません。
値を短くすると次の候補を早く試せますが、不要な試行も増えやすくなります。RFC自身もこれらを調整可能な値として扱っています。実際の待ち方を調べるときは、数値だけを比較するより、どの段階から測った値か、端末やライブラリが何を採用しているかをそろえる必要があります。
サイトが開けても、両方の経路が正常とは限らない
Happy Eyeballsが扱うのは、主に接続の開始です。TCPの接続確認が通った後で、大きなデータを送れない、TLSによる暗号化の確立に失敗する、HTTPのサービスが正しく応答しない、といった問題は残り得ます。先に成立した接続が、その後も最も速いという保証もありません。
利用者にはサイトが普通に開けていても、裏ではIPv6の失敗をIPv4が補っている場合があります。運用側が画面の表示成功だけを見ていると、片側の問題を見落としかねません。IPv4とIPv6を分けた到達性の確認や、接続開始後の処理を含む監視が役立ちます。
「宛先を調べられたか」「接続できたか」「その後のサービスが動いたか」を分けると、この仕組みが助ける範囲も見えやすくなります。Happy Eyeballs v2は、使える候補へ早めに進めるようにする接続の工夫です。RFC 8305は2017年12月発行で、確認時のRFC Editorの区分はProposed Standardです。
出典
- RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency（2017年12月、§2〜5・8〜9）
- RFC Editor：RFC 8305の状態と関連情報（2026年10月26日確認）