要約

  • Happy Eyeballs は、遅い、または壊れたアドレスファミリーを長く待たずに利用可能な接続を選び、利用者を守る。その仕組みは、IPv6 が失敗していても全体の成功率を緑に保ち得る。
  • 必要なのはファミリー別の証拠である。DNS 応答、候補、実際の試行、勝ったファミリー、失敗理由、代表的なアクセス網での強制接続を記録する。

明示的に仮定した場面を考える。主系の合成監視は緑で、取引完了率も安定し、障害の問い合わせもない。一方、あるアクセス網から IPv6 のみを使う監視は接続できない。両方は同時に成立する。通常のクライアントは A と AAAA を受け取り、IPv6 を試した後、利用者が大きな遅延を感じる前に IPv4 で接続した。

これは特定事業者の障害を示す話ではない。測定の限界を示している。一つの取引が成功したことは、少なくとも一つの経路が機能した証拠であり、公開されたすべてのアドレスファミリーが正常だった証拠ではない。

RFC 8305 は Happy Eyeballs v2 を定義する。アドレスやファミリー全体が遮断、故障、または低性能なときに、利用者が感じる遅延を減らすための仕様だ。A と AAAA を非同期に問い合わせ、宛先候補を並べ、間隔を置いて接続を開始し、成功した接続を残して他を中止する。通常は IPv6 を優先するが、直近の目的は可用性である。

仕様が示す推奨値も、障害が隠れる理由を説明する。RFC 8305 は名前解決の待ち時間に 50 ミリ秒、過去の RTT 情報がない場合の接続試行間隔に 250 ミリ秒を例示する。実装は値を変え、履歴を使える。これは全クライアント共通の保証ではない。重要なのは競争が起きることだ。負けた試行を記録しなければ、成功した接続だけから故障内容は分からない。

RFC 6724 のアドレス選択も結果を左右する。IPv6 と IPv4 の送信元・宛先候補を並べ、管理者による方針変更も認める。同じホスト名を解決する二つの端末でも、送信元アドレス、範囲、設定、既知の可用性によって順序と経路が変わり得る。

HTTP 成功率は、これらを一つの値に潰す。AAAA が届いたか、どの IPv6 アドレスを試したか、どれだけ待ったか、DNS、近隣探索、経路、フィルタ、Path MTU、宛先サービスのどこで失敗したかを示さない。IPv4 が方針で選ばれたのか、救済として勝ったのかも区別できない。

接続時の最小記録には、A/AAAA の内容と到着時刻、並べた候補、各試行のファミリー・開始・終了・エラー、勝ったファミリー、リゾルバ経路、アクセス ASN またはコホート、宛先エッジ、アプリ結果、クライアント実装、観測時刻を含める。フォールバックだけから原因を断定してはならない。

通常のデュアルスタック監視に、IPv6 固定と IPv4 固定の監視を組み合わせる。通常監視は利用者の導線を守り、固定監視は個別の制御面を検証する。デュアルスタックが成功し IPv6 固定が失敗した状態は「利用可能だが劣化中」であり、「全面的に正常」ではない。

出典