PS: 人生はコードと同じで、反省や反復がなければ成長は得られない。
最近、双スタックと単スタックの問題に触れたので、簡単に整理してみます。双スタックと単スタック、つまり IPV4 と比較して、双スタッククライアントのアプリケーションは明らかな接続遅延に直面し、双スタッククライアントのユーザー体験が悪化します。以下に双スタックの問題とその解決方法について理解を深めていきます。主な内容は以下の通りです：
- 双スタック選択問題
- IPV6 にアクセスできない場合の遅延
- Happy Eyeballs
- 実際の応用
双スタック選択問題#
双スタック選択問題および IPV6/IPV4 選択問題は、RFC1671 文書に初めて登場しました。IPV6（Internet Protocol version 6）はインターネットプロトコルの第 6 版であり、IPV4（Internet Protocol version 4）はインターネットプロトコルの第 4 版です。IPV6 が主に解決する問題は、IPV4 のアドレス資源がますます枯渇していることです。IPv6 の強化の鍵は、IP アドレス空間を 32 ビットから 128 ビットに拡張し、根本的に制限のないユニークな IP アドレスを実現することです。双スタック選択問題は、インターネットが急速に発展する背景の中で発生します。双スタック状態にあるとき、DNS が解決するアドレスには 2 種類のアドレスがあります。単スタック状態では、DNS が解決するのは IPV4 または IPV6 アドレスです。もちろん、現在単スタックと言えば、一般的には単スタック IPV4 を指します。
IPV6 にアクセスできない場合の遅延#
IPV6 にアクセスできない場合、IPV6 をサポートするプログラムは、正常に IPV4 に切り替えるために数秒の遅延が必要です。これがユーザー体験に影響を与えます。ユーザー体験に影響を与えないように、一部のシステムでは IPV6 を直接無効にすることがあります。
IPV6 にアクセスできない理由は以下の通りです：
その失敗の理由には、IPv6 インターネットへの接続がないこと、壊れた 6to4 または Teredo トンネル、壊れた IPv6 ピアリングが含まれます。
以下に IPV6 接続失敗のフローチャートを見てみましょう：
上の図のように、クライアントはドメイン名解決によって IPV6 および IPV4 アドレスを取得し、最初に IPV6 に接続を試みますが接続に失敗し、数秒後に IPV4 に切り替えて接続に成功します。この間、IPV6 が接続を待っている時間が IPV6 にアクセスできないときの遅延です。
Happy Eyeballs#
RFC6555では、可視遅延を減少させるアルゴリズムとして Happy Eyeballs が定義されています。その基本的な 2 つの目標は以下の通りです：
- ユーザーに IPV6 および IPV4 への迅速な接続能力を提供すること、つまり IPV6 での接続を迅速に試み、成功しなければ IPV4 に切り替えて接続すること。
- IPV6 と IPV4 を同時に接続することによるネットワークへの影響を避けること。
以下は上記の考え方の示意図です：
上の図のように、クライアントは同時に IPV6 と IPV4 を通じて 2 つの TCP SYN パケットを送信します。IPV6 は接続に失敗し、IPV4 は成功します。IPV6 の再試行は、ユーザーが IPV6 への接続を放棄して IPV4 に直接切り替えるまで続きます。
上記のプロセスを実行した後、クライアントは IPV6 と IPV4 アドレスが接続に成功したかどうかを知ることができます。クライアントは結果をキャッシュして、後続の接続試行でネットワークに影響を与えないようにできます。例えば、上の例では IPV6 接続が失敗したため、後続の接続では直接 IPV4 に切り替えて接続できます。キャッシュされた接続結果には有効期限を設定することができ、例えば 10 分後に接続状態を更新することができます。これにより、IPV6 接続の異常時の遅延がある程度減少し、ユーザー体験の向上に寄与します。
以下は IPV6 が正常に機能している示意図です：
上の図のように、クライアントは同時に IPV6 と IPV4 を通じて 2 つの TCP SYN パケットを送信します。IPV6 と IPV4 の両方が接続に成功し、IPV6 が直接接続に成功した場合、IPV6 を使用し、IPV4 は無視します。同様に、IPV6 接続状態を記録し、設定された有効期限内に直接 IPV6 で接続できます。
クライアントホストが双スタックをサポートしている限り、Happy Eyeballs メカニズムは常に存在します。IPV4 のみをサポートするサーバーが存在する限り、Happy Eyeballs は常に存在します。時間が経つにつれて、IPV4 は徐々に歴史の舞台から退くことになります。Happy Eyeballs の実現シーンは異なるかもしれませんが、基本的には上記の要件に従います。
実際の応用#
一般的に、アプリケーション層で使用されるドメイン名解決 API は以下の通りです：
public static InetAddress[] getAllByName(String host)
上記のメソッドは、ドメイン名 host に対応する IP アドレスを返します。この時、IP アドレスが IPV6 アドレスか IPV4 アドレスかに基づいて双スタック問題の適応が可能です。具体的な実装はニーズに応じて調整および改善できます。上で紹介した Happy Eyeballs は、双スタック時に生じる遅延問題を解決するためのものです。大規模なアプリはそれぞれ独自のアルゴリズム実装を持っているはずであり、DNS 部分も独自に実装している場合があります。ここで少し理解を深めておきましょう。