エニーキャストはtcpでどのように機能しますか？

Question

TCPはステートフルであるため、同じサーバーに到達するには後続のパケットが必要です。（ステートレス）HTTPはTCP上で実行され、CDNはエニーキャストを使用できます。

では、TCPエニーキャストでどのように機能しますか？synとackが異なるサーバーに移動した場合はどうなりますか？Googleがこれに対する解決策を持っていると聞きましたが、よくわかりません。

違いがあれば、IPv4とIPv6の両方に答えてください。

kasperd · Accepted Answer

これは、さまざまな方法で取り組むことができる多くの課題の1つです。最も簡単なアプローチは、それを無視して最善を期待することです。接続中にルーティングが変更されない限り、問題はありません。ただし、ルーティングが変更されると、ルーティングの変更によって影響を受けるすべての接続が切断されます。他の答えは、このアプローチですでにより深く掘り下げられています。

別のアプローチは、接続がどこにルーティングされているかを追跡することです。パケットが間違ったPOPにルーティングされた場合、CDNはパケットを正しいPOPにトンネリングして、さらに処理することができます。これにより追加のオーバーヘッドが発生します。発生すると、クライアントの遅延が増加します。この待ち時間の増加は、接続の存続期間中持続します。ただし、接続が切断されるよりも、ユーザーエクスペリエンスの方が優れている可能性があります。

帯域幅の消費に関しては、オーバーヘッドは一方向のパケットにのみ影響し、帯域幅の使用量が最も少ない方向になる傾向があるため、それほど重要ではありません。

追跡は、接続レベルで実行することも、個々のクライアントIPアドレスにサービスを提供するために優先されるPOPを追跡することによって実行することもできます。接続を追跡するための最も明白なデータ構造は、分散ハッシュテーブルです。

クライアントがMPTCPをサポートしている場合は、別の解決策を使用できます。接続が確立されるとすぐに、サーバーはユニキャストIPアドレスを使用して別のサブフローを開きます。このようなサブフローが正常に確立された場合、接続は、接続の残りの存続期間中、ユニキャストアドレスを使用するだけで、エニーキャストアドレスのルーティングの変更に耐えることができます。

原則として、上記のアプローチはすべてIPv4とIPv6で同じです。ただし、実際には、IPアドレスが不足しているため、一部のソリューションはIPv4ではうまく機能しない場合があります。

たとえば、MPTCPアプローチでは、正常に機能するために、各サーバーにパブリックIPアドレスが必要です。大規模な負荷分散のセットアップでは、サーバーが多すぎて、それぞれにパブリックIPアドレスを割り当てることができない場合があります。さらに、クライアントがNATの背後にある場合、新しいサブフローの確立をサーバーで開始することはできません。これは、IPv4の場合によくあります。つまり、サーバーは代わりに、最初のサブフローを介してオプションとしてユニキャストIPアドレスを送信し、クライアントに追加のサブフローを開始させる必要があります。

上記のアプローチのどれがCDNによって使用されているのかわかりません。

sysadmin1138 · Answer

特に、HTTPクライアントによって生成されるセッションなど、通常はかなり短命なTCPセッションの場合、予想よりもうまく機能します。

エニーキャストは、セッションの間、ネットワークトポロジが変更されないことを前提としています。変更された場合、別のエンドポイントがセッションをネゴシエートしたエンドポイントよりも突然近くなる可能性はほとんどありません。アプリケーションプロトコルは、この種の切断/再接続アクティビティを処理する必要があります。

CDNは、ビジネスモデル全体が短命であるため、エニーキャストで非常にうまく機能しますTCPネットワークの大幅に単方向のネットワーク転送を伴うセッションout。ACKストリームが終了した場合最初にネゴシエートしたエンドポイント以外の場所で、その1つのアセットの接続がハングします。

HopelessN00b · Answer

エニーキャストは「1対最も近い」ルーティングスキームとして最もよく説明され、通常、BGP（ボーダーゲートウェイプロトコル）に複数の送信元からの宛先IPをアナウンスさせることで機能し、パケットはリストされている最も近い宛先IPにルーティングされます。

したがって、広い意味では、エニーキャストは接続するサーバーを特定するために使用されるだけであり、TCPやステートフルネットワーキングに適さないものは何もありません。

エニーキャストの主な使用例はCDN（コンテンツ配信ネットワーク）です。CDN（コンテンツ配信ネットワーク）は、通常、短命またはステートレス接続、あるいはその両方があります。これは、小さな静的なWebページコンテンツを大量に配信する場合に予想されるとおりです。このユースケースでは、ネットワークトポロジが少なくともセッションの長さの間同じままであるというanycastの仮定は、通常のセッションの長さが短いことを考えるとかなり安全な仮定であり、その仮定の最小限の結果が誤ってしまう-最悪の場合、セッションは途中で失敗し、ユーザーはWebページをリロードします。

より長いセッション、または中断に耐えられない用途にエニーキャストを使用することの欠点は、ネットワークトポロジがより長い時間枠で変更される可能性が高く、その場合、接続がサイレントに切断されることです。（ポップスイッチング。）あなたがあなたの質問でほのめかしているように、グーグル（そして他のもの）はこの問題を解決する独自の方法に取り組んでいます、しかし今のところ、それはすべて独占的で秘密です。

したがって、エニーキャストがTCPでどのように機能するかという質問に対する答えは、ネットワークトポロジが変更されない限り、実際には問題なく機能するということです...トポロジが変更されると、[潜在的に]壊れます。

ここで興味深いプレゼンテーション（警告、pdf）エニーキャストの使用に関する実世界のデータ（いくつかの長命のセッションを含む）があり、実世界では「ポップスイッチング」（ここでセッションの途中でネットワークトポロジが変更され、接続が切断される）は非常にまれなエクスペリエンスです。1つのデータセットでは、683,204セッションと10分を超える23,795セッションで、4セッションのみがポップ切り替えされました。