IPv6およびSCTPを使用してユーザーの生活を改善する

翻訳者から：ハブで適切な「低レベルネットワーク」ブログを見つけられず、最初はこの翻訳を行うべきかどうかさえ疑いました。 それでも、私たちは全員開発者であり（少なくとも大多数）、この記事で説明されているIPv6の問題は今まで以上に重要になっています。 これまで、私はお気に入りのロシアのDebianミラー（ftp.chg.ru）を放棄する必要がありました。これは、あまりにも高度なミラーがIPv6で正常に機能し、プロバイダーがIPv6アドレスを発行するためですが、IPv6トラフィックはルーティングされません。 一般に、私はThe Internet Protocol Journalの編集長であるOle J. Jacobsenに連絡し、彼の祝福でこの記事を公開しています。 行こう



成功するには、新しいテクノロジーがユーザーに喜びをもたらす必要があります。 技術を導入する最良の方法を見つける過程で、原則として、いくつかのアプローチが発明され、研究され、試され、廃棄されます。 この記事では、IPv6およびStream Control Transmission Protocol（SCTP）[10]のこのような2つのアプローチについて説明します。



最新のブラウザ、Webサーバー、およびオペレーティングシステムは、IPv4およびIPv6をサポートしています。 IPv6は、Google、NetFlix、Facebookなど、いくつかの主要なコンテンツプロバイダーでもサポートされています。 ただし、それらのコンテンツは、IPv6テクノロジーとビジネスの現実との競合のため、IPv6で広く利用できるとは言えません。



Webブラウザーおよびオペレーティングシステムへの接続には、AAAA（IPv6- 約Per。 ）およびA（IPv4- 約Per。 ）レコードへのDNSクエリの作成、および結果のIPv6およびIPv4アドレスとの直列接続の試行が含まれます。 IPv6パスが使用できない（または遅い）場合、プログラムが従来のIPv4の試行を開始する前に、接続がかなり長くなることがあります。 このプロセスは、さまざまなサイトからオブジェクトを要求する平均的なWebサイトで特に苦痛になります。IPv6の問題はすべて遅延を引き起こします。 オペレーティングシステムとブラウザとの組み合わせで、IPv6が利用できない場合、遅延により20秒から数分にブレーキがかかることがあります[2]。 TCPクライアントからの一般的なメッセージフローを図1に示します。明らかに、このような遅延は、IPv6プロトコルサポート[3]を無効にするか、IPv6対応サイトを回避することでブレーキから逃れるユーザーには受け入れられません。





図1：通常のWebブラウザーの動作



「壊れた」IPv6ネットワークの問題は広まっています[6]。 コンテンツの提供は、直接的（ストリーミングビデオの再生など）と間接的（広告インプレッションの販売）の両方のビジネスです。 ユーザーがIPv6対応コンテンツの表示中に遅延が発生した場合（上記の技術的理由により）、他のサイトにアクセスするインセンティブがすぐに得られます。 このシナリオは、利益の損失を意味し、ビジネスには適切ではありません。 今日のインターネットのすべての消費者がIPv6を含むIPv4を介してコンテンツにアクセスできることを考えると、一部の消費者はIPv6に苦しむため、大きなビジネスリスクです。 大規模なコンテンツプロバイダーはしばらくの間状況を調査し、最終的にIPv6障害の数が多すぎてコンテンツにIPv6 AAAAを含めることができないことを示す結果[7]を公開しました。



IPv6の問題は、いくつかの理由により発生します。 これは新しいテクノロジーであり、IPv6ネットワークの品質は、ポイントトンネル、制御されていないトンネル[11]（通常6to4）、誤って設定されたファイアウォール、さらに個々のルーターの障害により、依然としてIPv4と同じレベルではありませんまた、接続も非常に簡単にIPv6障害を引き起こします。 多くのアプリケーションは引き続きIPv4のみをサポートし、ネットワーク管理者はデュアルスタック機器に依存して、IPv6の障害時に透過的にIPv4に切り替えます。



ただし、このようなスイッチはユーザーには透過的ではありません。数秒から数分かかります。 これらの問題を回避するために、コンテンツプロバイダーには1つの方法しかありません。IPv6接続が切断または低速になっている可能性があるAAAAレコードを提供しないでください。



この問題を回避するために、GoogleはAAAAレコードを提供するDNSサーバーのホワイトリストを作成しました[8]。 ただし、インターネットプロバイダーはまずGoogleとの良好なIPv6接続を証明する必要があり、その後GoogleがプロバイダーのDNSサーバーをホワイトリストに登録するため、現在の化身では、DNSホワイトリストはうまくスケールしません。 スケーラビリティの問題は、世界中に数千のインターネットプロバイダーが存在することであり、ホワイトリストはプロバイダーとGoogleの両方にとって手間のかかる手作業になりつつあります。 さらに、各コンテンツプロバイダーがDNSのホワイトリストを入力した場合、各インターネットプロバイダーは複数のコンテンツプロバイダーと一度に連携して、ユーザー間に展開されたIPv6ネットワークの収益性を確保する必要があります。 したがって、コンテンツプロバイダーは、DNSのホワイトリストの要件を承認し、このプロセスを自動化するためのある種の共通サービスを作成するために協力し始めました[5]。



さらに、DNSをホワイトリストに登録しても、正常な（または高速の）IPv6ネットワークが保証されません。これは、良好なIPv6接続とユーザーインターネットプロバイダーのDNSサーバーでのAAAAレコードの可用性との直接接続がないためです。 最適な設計とネットワーク設計であっても、1つのパス（IPv4またはIPv6）しか使用できない場合でも、2番目のトランスポートモードは使用できません。 その結果、発生した障害の種類に応じて、IPv4または両方のスタックをサポートするクライアントの過度の遅延が発生します。



この状況は、インターネットまたは特定のサイトが「落ちた」というユーザーエクスペリエンスに貢献します。 ユーザーは別のサイトに行くことを好みますが、おそらく「落ちた」サイトには決して戻りません。

幸せな目

ご注意 transl .:オリジナルは文字通り「ハッピーアイボール」と翻訳される「ハッピーアイボール」を使用しますが、西洋のテレコムでは「アイボール」は通常「インターネットユーザー」を意味します。



この問題は別のアプローチで解決されます。 IPv6経由で接続を確立してからIPv4経由で接続を確立する代わりに、アプリケーションはIPv4とIPv6を介してすぐに接続を確立しようとします。



同時接続試行は、チャネルのわずかに大きな部分を消費し、サーバーへの接続試行回数を2倍にします。 不要なトラフィックを減らすために、IPv4 / 6を介した接続試行の成功および失敗の履歴を保存するキャッシュも使用されます。 私たちはこのアプローチを「Happy Eyes」[1]と呼んでいます。なぜなら、ネットワークの速度は低下しますが、コンピューターはすぐにコンテンツを表示するからです（図2）。





図2：Happy Eyesを実装する2スタックブラウザ



明らかに、TCP SYNをIPv6およびIPv4で送信すると、クライアントが行う接続試行の回数が2倍になります。 この過剰な接続は、アプリケーションが以前の接続（IPv6またはIPv4）で使用されたプロトコルを記憶し、その後の試行でこの情報を使用することで削減できます。 このキャッシュの複雑化の可能性はメモリ（またはディスク）に依存しますが、単純なキャッシュでさえ非常に効果的です。 新しいネットワーク（3G、さまざまなWi-Fiネットワーク、または物理イーサネット）に接続すると、このネットワークの接続を確認し、必要に応じて、試行キャッシュを部分的または完全にクリアできます。



したがって、接続試行回数が2倍になるのは、新しいネットワークに接続する場合のみです。 この場合、最初の接続試行は、IPv6（またはIPv4）が最初に試行されるという事実により遅延します。 いずれにせよ、IPv6（またはIPv4）ルートが利用できない場合、ユーザーが気付くほどの大きなブレーキはありません。 Happy Eyeの目標は、IPv6を有効にしたまま、ユーザーをクラッシュから保護して、IPv6でサイトにアクセスしてもブレーキがかからないようにすることです。



このアプローチでは、ユーザーは徐々にIPv4からIPv6に移行し、必要に応じてすぐにIPv4に戻ります。 このソリューションは、既存のWebブラウザーに比べて大幅な改善を示しています。 このアイデアの障害は、個々のアプリケーションごとに実装する必要があることです。 ブラウザーの更新は追加のハードワークですが、主要なブラウザーは5つしかありません[9]。さらに、ブラウザーはそのようなアクティブな接続試行からすぐに利益を得ます。 さらに、ブラウザは高速なJavaScriptエンジンやその他の新機能の名前で更新されることがよくあります。



IPv6の健全性を判断する別のアイデアは、インターネット上の一部のIPv6リソースにpingまたはその他の単純な要求を送信し、リソースが応答しない場合はIPv6を無効にすることです。 このアプローチは、企業の内部IPv6トラフィック（IPv6インターネットへのアクセスがない場合でも非常にうまくいく可能性があります）の障害であり、IPv6を無効にすると、オペレーティングシステムに組み込まれたIPv6機能が壊れます（たとえば、WindowsのDirectAccessまたはBack to Mac OS X上の私のMac ）。 利点は、IPv6が無効になっている場合、IPv4への切り替えに関連するクラッシュや遅延の影響を受けるアプリケーションがないことです。

新しいトランスポート-SCTP

ネットワーク層プロトコルを選択する問題に加えて、同様の問題がトランスポートレベルに存在します。 おそらくこれは誰かにとって驚きになるでしょうが、TCPのほかに、フロー制御プロトコル（SCTP）という別のトランスポートプロトコルがあります。 SCTPはTCPに比べて大きな利点を提供し、TCPの実装と実装で遭遇しなければならない問題を考慮して設計されました[4]。



異なるDNSレコード（AAAAとA）があるIPv6とIPv4とは異なり、アプリケーションが異なるトランスポートプロトコルを使用できる、または使用する必要があることを示す特別なレコードはありません。 しかし、ルートをたどる途中でDNSでSCTPサポートを指定できたとしても、SCTPがブロックされ、このDNSレコードの有用性が低下する可能性があります。 ルートは、TCPまたはUDPのみを想定して、NATまたはファイアウォールによってブロックすることもできます。



Happy Eyesでは、クライアントがTCPとSCTPの両方を使用して同時に接続を試みることができる手法についても説明しています。 必要に応じて、これらの試行はアプリケーションによって行われます。アプリケーションは、このサーバーに接続しようとする後続の試行中のフラッドを減らすために、応答の速いトランスポートを選択してこの情報をキャッシュする必要があります 接続シナリオを図3に示します。





図3：Lucky Eyesを実装してTCPとSCTPを選択するクライアント



IPv6 / IPv4の選択とSCTP / TCPの選択を組み合わせると、新しいデュアルスタックネットワークに接続されたコンピューターで実行されているWebブラウザーは、IPv4 TCP SYN、IPv6 TCP SYN、IPv4 SCTP INIT、IPv6 SCTP INITの4つのパケットを送信します。 答えに基づいて、ブラウザは優先するトランスポートプロトコルとアドレススペース（IPv6またはIPv4）を決定し、残りの接続をドロップします。 前に説明したように、消費されるチャネル帯域幅とサーバーリソースを削減するために、接続情報は後で使用するためにキャッシュされます。

おわりに

ユーザーの生活を改善することを目的とした新しいテクノロジーは、期待に応える場合にのみ成功します。これはまさにこの生活を改善します。 多くの企業はインターネットで仕事をすることですべての利益を得るため、サービスの低下は利益の損失を意味します。 したがって、新しいテクノロジの展開がユーザーエクスペリエンスに悪影響を与えることはありません。 この記事では、ユーザーの否定的な反応を避けるために開発者が使用できるメカニズムの1つについて説明します。

参照資料

[1] Dan Wing、Andrew Yourtchenko、およびPreethi Natarajan、「Happy Eyeballs：Trending Towards To Success（IPv6 and SCTP）」、Internet-Draft、Work-in-Progress、2009年7月： http : //tools.ietf.org/ html / draft-wing-http-new-tech

[2]「壊れたIPv6クライアント」、ロレンツォコリッティ、2010年6月： https ://sites.google.com/site/ipv6implementors/2010/agenda

[3] Googleトレンド： http : //www.google.com/trends? q = enable+ipv6%2C+disable+ ipv6

[4] P. Natarajan、「アプリケーションパフォーマンスの向上のための革新的なトランスポートレイヤーサービスの活用」、2009年2月： http : //www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf

[5] Carolyn Duffy Marsan、「Google、Microsoft、IPv6ユーザーの共有リストを作成するための協議中のNetflix」、Network World、2010年3月： http : //www.networkworld.com/news/2010/032610-dns-ipv6- whitelist.html

[6] Tore Anderson、「IPv6破損実験、11月の結果」、2009年11月： http ://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html

[7] Igor Gashinsky、「IPv6と再帰リゾルバー：移行の痛みを軽減する方法」2010年3月： http : //www.ietf.org/proceedings/77/slides/dnsop-7.pdf

[8]「IPv6を介したGoogleサービスへのアクセス」： http : //www.google.com/intl/en/ipv6

[9]「Webブラウザーの使用率」： http : //en.wikipedia.org/wiki/Usage_share_of_web_browsers

[10] R.スチュワート編、「ストリーム制御伝送プロトコル」RFC 4960、2007年9月。

[11] Gunter Van de Velde、Ole Troan、Tim Chown、「管理対象外のIPv6トンネルは有害と見なされる」2009年7月： http : //tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels

翻訳者からの最終

過度に科学的な記事のスタイルと重複する私の舌で縛られた言葉を許してください。 あなたが興味を持っていたことを願っています。 そして今、1分間の必須情報：



2010年9月、第13巻、第3巻からのインターネットプロトコルジャーナル（IPJ）の許可を得て転載。IPJは、シスコシステムズが発行する四半期ごとの技術ジャーナルです。 www.cisco.com/ipjを参照してください



インターネットプロトコルジャーナル（IPJ）第13巻、No。 3、2010年9月。IPJは、シスコシステムズが発行する季刊誌です。 www.cisco.com/ipjを参照してください