JP2019522416A - Ｄｎｓリクエストの抑制のためのシステム及び方法 - Google Patents

Abstract

仮想プライベートルータ（ＶＰＲ）は、ＤＮＳリクエストを傍受し、リクエストするアプリケーションに疑似ＩＰアドレスを返信し、疑似ＩＰアドレスはリクエスト中のドメイン名にマッピングされる。疑似ＩＰアドレスを含むコンテンツに対するリクエストは、対応するドメイン名を含むように修正され、中間サーバに送信され、中間サーバは、ドメイン名を実ＩＰアドレスに解決し、そのコンテンツリクエストを転送する。コンテンツは中間サーバにより受信され、中間サーバは、ＶＰＲ経由等で、リクエストするアプリケーションにそれを返信する。そのドメイン名に対する後続のコンテンツリクエストが中間サーバをバイパスできるように、実ＩＰアドレスが中間サーバにより返信されてよい。ＶＰＲがドメイン名を実ＩＰアドレスに解決するように、幾つかのドメイン、ポート、及び／又はプロトコルに対するリクエストは中間サーバをバイパスしてもよい。【選択図】図１

Description

インターネット上で利用可能なコンテンツの大部分は、ユニバーサルリソースロケータ（ＵＲＬ）と関連付けられており、該ＵＲＬはドメイン名によってコンテンツサーバを参照する。ある特定のコンテンツサーバからコンテンツをリクエストするために、そのドメイン名は数字からなるＩＰアドレスに変換される必要がある。この変換はドメインネームサービス（ＤＮＳ）によって行われる。コンテンツリクエストを発行する前に、クライアントコンピュータは、リクエストされたドメイン名をＩＰアドレスにマッピングするようＤＮＳサーバに依頼する。クライアントは、ＤＮＳ応答を一定の許可時間（タイムトゥーリブ、ＴＴＬ）の間キャッシュし得るが、キャッシュ時間が時間切れになった場合、又は、リクエストされたドメインがＤＮＳキャッシュに格納されていない場合、新たなＤＮＳリクエストを発行しなければならない。

ＤＮＳリクエストの度に、コンテンツをフェッチするために必要な時間が増加し、クライアントは、コンテンツリクエストを発行する前にＤＮＳ応答の受信を待たなければならない。ＤＮＳサーバが遅いと、コンテンツサーバが速くても、インターネットの体感速度が低下しうる。ＤＮＳ応答がＣＮＡＭＥレコード（あるドメイン名の別名の指定）を含む場合、クライアントは、別のＤＮＳリクエストを発行する必要がある可能性があり、コンテンツの検索（retrieval）は更に遅れる。ＤＮＳのレイテンシは、モバイルネットワークで特に大きくなり、３Ｇネットワークで２００〜３００ｍｓに達しうる。

クライアント側のＤＮＳリクエストを抑制する周知の方法は、コンテンツリクエスト毎にドメイン名を提供つつ、クライアントコンピュータからプロキシサーバを通じてＨＴＴＰ又はＨＴＴＰＳトラフィックを送信する方法である。クライアント側アプリケーションは、プロキシサーバ（例えばマイクロソフト社が提供するインターネットエクスプローラーはプロキシ設定に対応）を通じてそれが接続されていることを認識している場合、ＤＮＳリクエストを発行しない。その代わりに、プロキシサーバが、指定されたドメインに自身のＤＮＳリクエストを発行する。

ＤＮＳ解決をプロキシサーバに移すと、全体的なレイテンシ（特にクライアントがモバイルネットワークに接続されている場合）及びクライアント側のデータトラフィックは一般的に減少する。大きなＤＮＳキャッシュを持つ同一のプロキシサーバに複数のユーザが接続される場合、リクエストされたＤＮＳ応答が既にキャッシュされている可能性が大きく、パフォーマンスが更に改善しうる。しかしながら、特にモバイルデバイス上の複数のクライアントアプリケーションは、プロキシ設定をサポートせず、クライアント側のＤＮＳ結果を廃棄し自身のＤＮＳリクエストを発行するプロキシサーバを通じて接続されていたとしても、ＤＮＳリクエストを発行し続ける。クライアント側のＤＮＳリクエストはまた、ＨＴＴＰ及び／又はＨＴＴＰＳ接続を終了し独自のＤＮＳリゾルバを用いるＶＰＮサーバを通じてクライアントが接続されている場合にも破棄される。

従って、特にクライアントコンピュータがプロキシ又はＶＰＮサーバに接続されてる場合に、コンピュータネットワーク上でのクライアントからのＤＮＳリクエストの数を減少させる必要がある。

本発明の利点の理解を促す目的で、添付の図面に示される具体的な実施形態を参照しながら、簡潔に上述した本発明を更に詳細に説明する。図面が示すのは本発明の典型的な実施形態でありその範囲を限定すると考えられるべきものではないとの理解に基づき、添付の図面を使用し、本発明について更に具体的、詳細に述べ、説明する。

本発明の実施形態に従った方法を実行するためのネットワーク環境を示す概略ブロック図である。 本発明の実施形態に従った、ＤＮＳリクエストを抑制するための方法のプロセスフロー図である。 本発明の実施形態に従った、幾つかのドメイン名に対するＤＮＳリクエスト抑制をバイパスするプロセスフロー図である。 本発明の実施形態に従った、ルーティング不可ＩＰアドレスを含むコンテンツリクエストを処理するための方法のプロセスフロー図である。 本発明の実施形態に従った、中間サーババイパス規則を適用してルーティング不可ＩＰアドレスを伴うコンテンツリクエストを処理する方法のプロセスフロー図である。 本発明の実施形態に従った、ＴＣＰコンテンツリクエストを処理するための方法のプロセスフロー図である。 本発明の実施形態に従った、中間サーバのバイパスを含む、ルーティング不可ＩＰアドレスを含むコンテンツリクエストを処理するための方法のプロセスフロー図である。 本発明の実施形態に従った、様々なプロトコルに対し中間サーバによりコンテンツを転送する方法のプロセスフロー図である。 本発明の実施形態に従った、様々なプロトコルに対して中間サーバによりコンテンツを転送する方法のプロセスフロー図である。 本発明の実施形態に従った、様々なプロトコルに対して中間サーバによりコンテンツを転送する方法のプロセスフロー図である。 本発明の実施形態に従った、ＶＰＮトラフィックを処理するためのプロセスフロー図である。 本発明の実施形態に従った、ＶＰＮセッションのレイテンシを低下させるためのプロセスフロー図である。 本発明の実施形態に従った、クライアント装置のＩＰアドレステーブルを追加（populate）しつつ、ＤＮＳリクエストを抑制する方法のプロセスフロー図である。 本発明の実施形態に従った、ＤＮＳリクエストを予期してＩＰアドレスを提供するための方法のプロセスフロー図である。 本発明の実施形態に従った方法の実装に適したコンピュータシステムの概略的ブロック図である。

本明細書において概観的に述べられ図面に例示される本発明のコンポーネントは、幅広く様々に異なる構成で配置、設計されうることが容易に理解されるであろう。従って、下記の、図面に示される本発明の実施形態の詳細な説明は、請求項に記載される発明の範囲の限定を意図するものではなく、単に本明細書において考察される本発明に係る実施形態の幾つかの例を代表するにすぎない。本明細書において述べられる実施形態は図面への参照により最もよく理解され、図面において、同様の要素は同じ参照番号で表される。

バーチャルプライベートルータ（ＶＰＲ）と更に称されるクライアントコンピュータ上のソフトウェアは、１つ以上のクライアントアプリケーションにより開始された１つ以上のＤＮＳリクエストを傍受し、リクエストされたドメイン名に対する疑似ＩＰアドレスを返信し、リクエストされたドメイン名と返信された疑似IPアドレスとの対応関係を格納する。疑似ＩＰアドレスは、リクエストされたドメイン名を実体コンテンツサーバに正確にマッピングする必要はない。

１つ以上の疑似ＩＰアドレスを返信した後、ＶＰＲは、宛先として疑似ＩＰアドレスを有する１つ以上のコンテンツリクエストを検出し、検出された疑似ＩＰアドレスに対応するドメイン名を検索し、検索されたドメイン名の記述子と共にコンテンツリクエストを中間サーバに提出する。中間サーバは、提示されたドメイン名の記述子を実体コンテンツサーバに対応するＩＰアドレスに解決し、該サーバにコンテンツリクエストを転送し、クライアントコンピュータにコンテンツ応答を返信する。結果として、クライアントアプリケーションは、コンピュータネットワーク上でＤＮＳリクエストを送信することなく、リクエストされたコンテンツを受信し、それにより、レイテンシ及びデータトラフィックの量を減少させる。

一実施形態において、ＶＰＲは、コンテンツリクエストが中間サーバを通じて送信されるべきか、それとも中間サーバをバイパスすべきかを判定する。コンテンツリクエストが中間サーバをバイパスすべき場合、ＶＰＲは、コンピュータネットワーク上でＤＮＳリクエストを発行し、実ＩＰアドレスを返信し、コンテンツリクエストが中間サーバを通じて送信されるべき場合、ＶＰＲは、コンピュータネットワーク上でＤＮＳリクエストを発行することなく、疑似ＩＰアドレスを返信する。

コンテンツリクエストを中間サーバを通じて送信するか否かかの判断は、ドメイン名、ポート、プロトコルのグループからの１つ以上のパラメータと関連づけられた一組のルーティング規則に依存してもよい。一実装において、ＶＰＲは、傍受されたＤＮＳリクエストに応答を返信する前に、リクエストが中間サーバをバイパスすべきか否かを判定し、この判定は、リクエストされたドメイン名を１つ以上のルーティング規則に整合させることにより行われる。

別の実装では、ＶＰＲは、ＤＮＳリクエストを傍受した後、疑似ＩＰアドレスを常に返信し、その後、疑似ＩＰアドレスを宛先として有するコンテンツパケットを受信すると、そのＩＰアドレス、ポート、プロトコルと関連付けられたドメイン名のグループから１つ以上のパラメータを取得し、取得されたパラメータを１つ以上のルーティング規則に整合させ、コンテンツリクエストが中間サーバをバイパスすべき場合、取得されたドメイン名の実ＩＰアドレスに対する自身のＤＮＳリクエストを発行し、取得された実ＩＰアドレスを用いてコンテンツリクエストをその後直接発行する。

一実施形態において、疑似ＩＰアドレスはルーティング不可ＩＰアドレスである。一実装において、ルーティング不可ＩＰアドレスは、１０．０．０．０−１０．２５５．２５５．２５５、１７２．１６．０．０−１７２．３１．２５５．２５５、及び１９２．１６８．０．０−１９２．１６８．２５５．２５５の範囲の少なくとも１つの内のルーティング不可ＩＰｖ４アドレスのグループから選択される。別の実装において、疑似ＩＰアドレスはルーティング不可ＩＰｖ６アドレスである。別の実装において、疑似ＩＰアドレスとして用いられるルーティング不可ＩＰアドレスは、クライアントコンピュータが接続されるローカルネットワーにより使用される範囲とは異なる１つ以上の範囲から選択される。別の実装において、疑似ＩＰアドレスは、ＩＰｖ４又はＩＰｖ６以外のトランスポートプロトコルと関連付けられたネットワークアドレスである。

幾つかの実施形態において、クライアントがＶＰＮトンネルを通じてコンテンツリクエストを送信した後、ＶＰＮサーバは、リクエストされたドメイン名に対する自身のＤＮＳリクエストを発行し、宛先ＩＰアドレスをＤＮＳリクエストから取得したものに置き換える。一実施形態において、この置き換えは、ＶＰＮトンネルからのトラフィックのデカプセル化（dis-encapsulate）後に行われる。別の実施形態においては、ＶＰＮトンネル内でトラフィックが依然としてカプセル化されている間に行われる。典型的には、ＨＴＴＰ及びＨＴＴＰＳプロキシサーバは、それらのデータパケットが実宛先ＩＰアドレスを含まない（幾つかの実施形態において、プロキシサーバのアドレスにそれは置き換えられる）ため、自身のＤＮＳリクエストを発行する必要がある。先行技術におけるＶＰＮサーバは、宛先ＩＰアドレスを既に含むデータパケットに対する追加のＤＮＳリクエストを行わず、カプセル化ヘッダを単に削除し、元のパケットをそれらの宛先に転送する。

一実施形態において、検出されたＩＰアドレスに対応するドメインの検索は、疑似ＩＰアドレスのサブセットを抽出することと、格納されたドメイン名を参照するために該サブセットを用いることと、それにより、異なる範囲の疑似ＩＰアドレスに対して、ＩＰアドレスとドメイン名との間で同じ参照を維持可能にする。一実装において、検索された疑似ＩＰアドレスのサブセットは、ＩＰｖ４疑似ＩＰアドレスの３２ビット整数表現の下位ビット２０桁以下を含む。

一実施形態において、ＶＰＲは、大きなＴＴＬ値を有する疑似ＩＰアドレスを返信し、それにより、傍受される必要があるＤＮＳリクエストの数を減少させる。

一実施形態において、中間サーバは少なくとも１つのプロキシサーバを含み、ＶＰＲは、１つ以上のクライアント側アプリケーションからのコンテンツリクエストをクライアント側プロキシにリダイレクトし、クライアント側プロキシは、リクエストを、リクエストされたドメインと共に、コンピュータネットワーク上でプロキシサーバに転送する。一実装において、１つ以上のＨＴＴＰコンテンツリクエストがクライアント側ＨＴＴＰプロキシに提示され、クライアント側ＨＴＴＰプロキシはＨＯＳＴヘッダ内のリクエストされたドメインを転送する。別の実装において、１つ以上のＨＴＴＰＳコンテンツリクエストがクライアント側ＨＴＴＰＳプロキシに提示され、クライアント側ＨＴＴＰＳプロキシは、ＳＮＩヘッダ内のリクエストされたドメインを転送する。別の実装において、１つ以上のＴＣＰコンテンツリクエストがクライアント側接続プロキシに提示され、クライアント側プロキシはＣＯＮＮＥＣＴヘッダ内のリクエストされたドメインを転送する。

一実施形態において、中間サーバは、ＤＮＳリクエストを発行することによって、リクエストされたドメイン名の記述子をＩＰアドレスに解決する。一実装において、ドメイン名の記述子は、ＶＰＲによって傍受されたＤＮＳリクエスト中で特定されるテキスト列（string）を含む。別の実装では、ドメイン名の記述子はテキスト列へのポインタであり、中間サーバは、リクエストされたドメイン名をＩＰアドレスに解決する前に、記述子によって指し示されたデータストレージからテキスト列の値を取得する。

一実施形態において、ＶＰＲは、２つ以上のコンテンツリクエストを少なくとも２つの異なる中間サーバに提示し、各コンテンツリクエストに対する中間サーバは、そのＩＰアドレス、ポート、及びプロトコルと関連付けられたドメイン名のグループからコンテンツリクエストの１つ以上のパラメータを取得し、これらのパラメータを１つ以上のルーティング規則とその後整合させることによって判定される。

別の実施形態において、中間サーバはＶＰＮサーバであり、ＶＰＲは、クライアントコンピュータとＶＰＮサーバとの間のＶＰＮトンネル内において１つ以上のコンテンツリクエストをカプセル化する。一実装において、ＶＰＲは、ＶＰＮトンネル内において、リクエストされたドメイン名の記述子を提示する。一実装において、リクエストされたドメイン名の記述子は、宛先ＩＰアドレスとして疑似ＡＰアドレスを有するＴＣＰ又はＵＤＰ接続の一組のデータパケットに、これらのデータパケットがＶＰＮパケット内でカプセル化される前に追加される。

幾つかの実施形態において、中間サーバは、（自身のＤＮＳリクエストを発行することにより解決された）実ＩＰアドレスをコンテンツデータと共にクライアントに返送する。クライアントは、自身のＤＮＳリクエストを発行せずに、中間サーバのバイパスにおいてリクエストを発行するためにそのアドレスを後で用いる。これにより、クライアントは、この実施形態においてＤＮＳリクエストの発行を避けるために中間サーバを用いるが、それは実ＩＰアドレスを取得するまでのみである。結果として、クライアントは、自身のＤＮＳリクエストの代わりに疑似ＩＰアドレスを依然として用いながら、中間サーバを通じた追加のホップに起因するパフォーマンス悪化を軽減する。

本発明に従った実施形態は、装置、方法、又はコンピュータプログラム製品として具体化されてもよい。従って、本発明は、全体がハードウェアという実施形態、全体がソフトウェアという実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又は本明細書において概して“モジュール”又は“システム”と言及されるソフトウェア及びハードウェアの側面を組み合わせた実施形態の形式をとってもよい。更に、本発明は、媒体において具体化されるコンピュータ使用可能プログラムコードを有する、任意の有体の表現媒体で具体化されたコンピュータプログラム製品の形式をとってもよい。

１つ以上のコンピュータ使用可能又はコンピュータ読み取り可能な媒体の任意の組み合わせが利用されてもよい。例えば、コンピュータ読み取り可能媒体は、ポータブルコンピュータフロッピーディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）デバイス、リードオンリーメモリ（ＲＯＭ）デバイス、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ又はフラッシュメモリ）デバイス、ポータブルコンパクトディスクリードオンリメモリ（ＣＤＲＯＭ）、光学ストレージデバイス、及び磁気ストレージデバイスの内の１つ以上を含んでもよい。幾つかの選ばれた実施形態において、コンピュータ読み取り可能媒体は、命令実行システム、装置、もしくはデバイスにより、又はこれらに接続して使用されるプログラムを保持、格納、通信、伝播、又は移動できる任意の非一時的媒体を含んでもよい。

本発明の動作を実行するためのコンピュータプログラムコードは、例えば、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、又はＣ＋＋等のオブジェクト指向型プログラム言語、及びＣプログラム言語又は同様のプログラミング言語等の従来の手続き型プログラム言語を含む、１つ以上のプログラム言語の任意の組み合わせで記述されてもよく、ＨＴＭＬ、ＸＭＬ、及びＪＳＯＮ等の記述言語又はマークアップ言語をも用いてもよい。プログラムコードは、その全体がコンピュータシステム上で、スタンドアロン型ソフトウェアパッケージとして実行されてもよく、コンピュータからいくらかの距離をおいた場所にあるリモートコンピュータ上で部分的に実行されてもよく、又は、その全体がリモートコンピュータ若しくはサーバ上で実行されてもよい。後者の場合、リモートコンピュータは、例えば、ローカルエリアネットワーク（ＬＡＮ）若しくはワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを通じてコンピュータに接続されてもよく、又は、（例えば、インターネットサービスプロバイダを用いてインターネットを通じて）外部コンピュータに接続されてもよい。コンピュータネットワークは、インターネットプロトコル以外のトランスポートプロトコルを用いてもよい。それに応じて、本発明は、ＩＰアドレス以外の種類のネットワークアドレスに対して実装されてもよい。

以下、本発明の実施形態に従った方法、装置（システム）、及びコンピュータプログラム製品のフローチャート図及び／又はブロック図を参照しながら本発明を説明する。フローチャート図及び／又はブロック図中の各ブロック、並びにフローチャート図及び／又はブロック図中のブロックの組み合わせは、コンピュータプログラム命令又はコードとして実装できることが理解されるであろう。これらのコンピュータプログラム命令は、コンピュータ又はその他のプログラマブルデータ処理装置のプロセッサを通じて実行される命令がフローチャート及び／又はブロック図の１つ以上のブロックに特定される機能／行為を実装する手段を作り出すように、マシンを生み出す汎用コンピュータ、専用コンピュータ、又はその他のプログラマブルデータ処理装置のプロセッサに提供されてもよい。

これらのコンピュータプログラム命令はまた、コンピュータ読み取り可能媒体に格納される命令がフローチャート及び／又はブロック図の１つ以上のブロック中でに特定される機能／行為を実装する命令手段を含む製品を生み出すように、コンピュータ又はその他のプログラマブルデータ処理装置を特定の方法で機能させることができる非一時的コンピュータ読み取り可能媒体に格納されてもよい。

コンピュータプログラム命令はまた、コンピュータ又はその他のプログラマブルデータ処理装置上で実行される命令がフローチャート及び／又はブロック図の１つ以上のブロック中で特定される機能／行為を実装するためのプロセスを提供するように、コンピュータ又はその他のプログラマブル装置で実施される一連の動作ステップがコンピュータ実装プロセスを生み出させるために、コンピュータ又はそのたのプログラマブルデータ処理装置上にロードされてもよい。

図１は、本明細書に開示される方法が実装されてもよい例示的ネットワークアーキテクチャ１００を説明する。具体的には、図１３のコンピューティング装置１３００等のコンピューティング装置は、１つ以上のアプリケーション１０２を格納及び実行することができる。具体的には、アプリケーション１０２は、そのようなアプリケーションを、ネットワーク上でデータを送信し又はリモートデバイスから受信するウェブブラウザ又はその他のアプリケーションとして含んでもよい。

コンピューティング装置１３００は同様に、バーチャルプライベートルータ（ＶＰＲ）１０４（その機能は後に詳しく述べる）をホストしてもよい。具体的には、ＶＰＲ１０４は、ドメイン名の解決に対するリクエスト（例えばドメインネームサービス（ＤＮＳ）リクエスト）と、コンテンツ又はコンテンツ送信に対するリクエストとの両方をアプリケーション１０２から傍受するトラフィックインターセプタ１０６を含んでもよい。

ＤＮＳ解決リクエストはリゾルバ１０８によって処理されてよい。後に詳述するように、ＤＮＳリゾルバ１０８は、アプリケーション１０２からＤＮＳ解決リクエストを受信し、応答において、ルーティング不可ＩＰアドレス（以下、「疑似ＩＰアドレス」）をアプリケーション１０２に返信してもよい。幾つかの実施形態及び環境において、ＤＮＳリゾルバ１０８は、その実際のＤＮＳリクエストをＤＮＳサーバに送信し、ルーティング可能ＩＰアドレス（以下、「実ＩＰアドレス」）を受信し、そのルーティング可能ＩＰアドレスをアプリケーション１０２に返信することで、アプリケーション１０２からのＤＮＳリクエストに応答してもよい。ＤＮＳリゾルバ１０８は、ドメイン名を解決するためのリクエストに応答して、ドメイン名と、ＤＮＳリゾルバ１０８により生成された疑似ＩＰアドレスと間のマッピングを記録してもよい。ＤＮＳリゾルバ１０８また、ドメインとＤＮＳリゾルバ１０８によって解決された実ＩＰアドレスとの間のマッピングを格納してもよい。

ＶＰＲ１０４は更に、コンテンツルータ１１０を含んでもよい。アプリケーション１０２から受信されたコンテンツに対するリクエストは、コンテンツルータ１１０によって、コンテンツリクエスト中の疑似ＩＰアドレスを識別し、該疑似ＩＰアドレスにマッピングされたドメイン名を検索し、該ドメイン名を含む修正済みコンテンツリクエストを出力することで処理される。コンテンツリクエストに対する応答は、コンテンツルータ１１０によって受信され、アプリケーション１０２に返信されてもよい。

修正済みコンテンツリクエストは、コンテンツリクエストに対応する適切なモジュール１１２〜１１６により処理されてもよい。例えば、ＨＴＴＰコンテンツリクエストはＨＴＴＰプロキシ１１２によって処理されてもよく、ＣＯＮＮＥＣＴコンテンツリクエストはＣＯＮＮＥＣＴプロキシ１１４によって処理されてもよい。ＶＰＮトンネル内の通信はＶＰＮモジュール１１６によって処理されてもよい。コンテンツリクエスト及びその他の通信は、モジュール１１２〜１１６によって中間サーバ１１８にその後送信されてもよい。幾つかの実施形態において、ＶＰＲ１０４は、例示したモジュール１１２〜１１６よりも多い、又は少ないモジュールを実装してもよい。幾つかの実施形態において、ＶＰＲは更に、不正アクセスを防ぐためのファイアウォールを実装してもよい。

一実施形態において、中間サーバ１１８は少なくとも１つのプロキシサーバを含む。ＶＰＲ１０４は、リクエストされたドメイン名を含むＤＮＳリクエストを、１つ以上のクライアント側アプリケーションからクライアント側プロキシ（例えば、モジュール１１２〜１１６のうちの１つ）にリダイレクトし、クライアント側プロキシは、リクエストされたドメインと共に、そのリクエストをコンピュータネットワーク上で、プロキシサーバとして動作する中間サーバ１１８に転送する。一実装において、１つ以上のＨＴＴＰコンテンツリクエストがクライアント側ＨＴＴＰプロキシ１１２に提示され、ＨＴＴＰプロキシ１１２は、ＨＯＳＴヘッダ内のリクエストされたドメインを転送する。別の実装において、１つ以上のＨＴＴＰＳコンテンツリクエストがクライアント側ＨＴＴＰＳプロキシに提示され、クライアント側ＨＴＴＰＳプロキシはＳＮＩ（サーバネームアイデンティフィケーション）ヘッダ内のリクエストされたドメインを転送する。別の実装において、１つ以上のＴＣＰコンテンツリクエストがクライアント側ＣＯＮＮＥＣＴプロキシ１１４に提示され、クライアント側ＣＯＮＮＥＣＴプロキシ１１４は、ＣＯＮＮＥＣＴヘッダ内のリクエストされたドメインを転送する。

一実装において、ＶＰＲは、２つ以上のコンテンツリクエストを少なくとも２つの異なる中間サーバに提示し、各コンテンツリクエストに対する中間サーバは、そのＩＰアドレス、ポート、及びプロトコルと関連付けられたドメイン名のグループからコンテンツリクエストの１つ以上のパラメータを取得し、これらのパラメータを１つ以上のルーティング規則と整合させることにより判定される。例えば、リクエストされたドメインに対する中間サーバは、中間サーバの位置に特有のコンテンツ（ローカルニュース等）を検索するため、又は、パフォーマンス改善のため（例えば、クライアントとコンテンツサーバとの間の直接ルートからの逸脱を最小化するため）に選択される。

ＶＰＲ１０４の例示されたコンポーネントは、単一のクライアント装置１３００によって格納及び実行されてもよいし、又は、ローカルネットワーク若しくはその他のネットワークによってクライアント装置１３００に接続されたゲートウェイコンピュータ若しくはルータ等の複数のコンピューティング装置１３００に分散されてもよい。

中間サーバ１１８は、修正済みコンテンツリクエスト及びその他の通信を受信し、ドメイン名を抽出し、ドメイン名をＩＰアドレスに解決し、そのＩＰアドレスに修正済みコンテンツリクエストを転送してもよい。幾つかの実施形態において、中間サーバ１２０は、コンテンツリクエストを受信してもよく、後に詳述するように、ＤＮＳリクエストを削減しつつＶＰＮ接続を管理するＶＰＮサーバとして実施されてもよい。中間サーバ１１８はまた、ＶＰＮサーバとして機能してもよく、又はＶＰＮトンネル内のコンテンツリクエスト及びその他の通信を他のＶＰＮサーバに転送してもよい。

中間サーバ１１８、１２０はインターネット１２２、又は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、若しくはその他のネットワーク等のその他のネットワークに結合されてもよい。インターネット１２２への接続は、任意の有線又は無線の接続手段によってなされてもよい。コンテンツリクエストの対象であり、それらに対する応答を送信するサーバは、インターネット１２２に含まれるものと理解されてもよく、ネットワーク通信の対象であり、それらに対する応答を送信できる任意の装置を含んでよい。アプリケーション１０２及びＶＰＲ１０４を格納及び実行するコンピューティング装置１３００（図１３を参照）は、ＤＮＳ名解決のリクエスト等のデータをインターネットから受信してもよく、それらに応答を送信してもよい。

図２は、ＶＰＲ１０４、具体的にはＤＮＳリゾルバ１０８によって実行されうる方法２００を説明する。方法２００は、ＤＮＳリクエストを傍受２０２することと、該ＤＮＳリクエストから、完全修飾ドメイン名（ＦＱＤＮ）をＤＮＳから取得２０４することとを含んでよい。ＦＱＤＮを疑似ＩＰにマッピングするテーブル（ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル）から該ＦＱＤＮに対応する疑似ＩＰを取得２０６するための試行がなされる。ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブルは、ＦＱＤＮをキーとし、対応するＩＰアドレスをそのキーに対応する値とするハッシュテーブルであってもよい。本明細書にて説明されるその他のテーブルも同様にハッシュテーブルとして具体化されてもよい。

テーブル中にエントリが発見されないと判定された２０８場合、新しい疑似ＩＰアドレス（ｎｒ＿ＩＰ）が割り当て２１０られる。割り当てられた疑似ＩＰアドレスは、該疑似ＩＰアドレスがステップ２０４で取得されたＦＱＤＮに一意に解決するように、ＶＰＲの範囲内、又はＶＰＲ内の他のネーム空間内で一意であってもよい。一実装において、疑似ＩＰアドレスは、１０．０．０．−１０．２５５．２５５．２５５、１７２．１６．０．０−１７２．３１．２５５．２５５、及び１９２．１６８．０．０−１９２．１６８．２５５．２５５の内の少なくとも１つの内のルーティング不可ＩＰｖ４アドレスのグループから割り当て２１０られる。別の実装において、疑似ＩＰアドレスはルーティング不可ＩＰｖ６アドレスである。別の実装において、疑似ＩＰアドレスとして用いられるルーティング不可ＩＰアドレスは、クライアントコンピュータが接続されるローカルネットワークによって用いられる範囲とは異なる１つ以上の範囲から選択される。

一実装において、疑似ＩＰアドレスとして用いられるルーティング不可ＩＰアドレスは、クライアントコンピュータが接続されるローカルネットワークによって用いられる範囲とは異なる１つ以上の範囲から選択される。一実施形態において、検出されたＩＰアドレスに対応するドメインの検索は、疑似ＩＰアドレスのサブセットを抽出することと、格納されたドメイン名を参照するために該サブセットを用いることと、これにより、異なる範囲の疑似ＩＰアドレスに対するＩＰアドレスとドメイン名との間の同じ参照を維持することとを含む。例えば、Ｍビットの長さの疑似ＩＰアドレスは、最下位ビットＮビット（Ｎ＜Ｍ）のみとして格納されてもよい。一実装において、疑似ＩＰアドレスの検索されたサブセットは、ＩＰｖ４疑似ＩＰアドレスの３２ビット整数表現の下位ビット２０以下を含む。

例えば、ＶＰＲ１０４は、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル中に有効なエントリを有しない、”ｅｘａｍｐｌｅ．ｃｏｍ”というドメインに対するＤＮＳリクエストを受信する。ローカルネットワーク上の他のリソースとの競合を避けるために、ＶＰＲは、現在のローカルネットワークが使用する範囲とは別のＩＰ範囲内の疑似ＩＰアドレスを返信すべきである。例えば、ユーザが１９２．１６８．０．０−１９２．１６８．２５５．２５５の範囲内のＩＰアドレスを有するローカルネットワークに現在接続している場合、ＶＰＲは、１０．０．０．０−１０．２５５．２５５．２５５の範囲内の疑似ＩＰアドレス（例えば、０ｘ１１２１３に等しい最下位２０ビットを有する１０．１７．１８．１９）を、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰ又はｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中に同じ最下位２０ビットを持つ疑似ＩＰアドレスと他のＦＱＤＮが関連付けられていないことを確認した後に返信する。一意の対である＜ＦＱＤＮ−＞疑似ＩＰアドレスの最下位２０ビット”＞は、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル（ドメインをキーとする）とｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル（疑似ＩＰアドレスの最下位２０ビットをキーとする）の両方に格納される。

その後何らかの時点で、ユーザは、例えば１０．０．０．０−１０．２５５．２５５．２５５の範囲内のＩＰアドレスで、別のローカルネットワークに切り替えてもよい。ドメイン名“ｅｘａｍｐｌｅ．ｃｏｍ”に対する別のＤＮＳリクエストを受信した後、ＶＰＲは、ｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルから疑似ＩＰの最下位２０ビットを検索し、異なる範囲（例えば、１７２．１６．０．０−１７２．３１．２５５．２５５）の疑似ＩＰ、例えば最下位２０ビット０ｘ１１２１３を有する疑似ＩＰ１７２．１７．１８．１８をその後返信する。この方法では、ユーザが別の範囲のローカルＩＰアドレスに切り替えることに応じて、テーブルが変更される必要がない。別の例において、格納され得る疑似ＩＰアドレスのビットは、実ＩＰを記述するビット数よりも小さい範囲で、異なる数であってもよい。例えば、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰ及びｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルは、ＩＰｖ４アドレスの最下位１６ビットを格納してもよく、又は、ＩＰｖ６アドレスの、ルーティングプレフィックス、サブネット識別子、若しくはインターフェース識別子の少なくとも数ビットを除いた部分を格納してもよい。

別の例において、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰ及びｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮの両方が疑似ＩＰアドレス（１０．１７．１８．１９）全体を格納するが、同じ下位ビットを有する別の範囲内の疑似ＩＰアドレスを生成つつ、最上位ビット又はその他のビットは無視される。結果として、ローカルリソースに割り当てられたルーティング不可ＩＰアドレスと競合するリスクなしに、異なるローカルネットワークにおいて、疑似ＩＰとドメイン名との間の同じ参照を用いることができる。このことは、ローカルネットワークの切り替えを検出した後、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰ及びｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルの一部を消去することに代えて、格納された参照をより長く維持することが可能となる。

方法２００は更に、ステップ２０４で取得したＦＱＤＮを、割り当て２１０られた疑似ＩＰアドレスにマッピングするために、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブルを更新２１２することを含む。同様に、割り当て２１０られた疑似ＩＰアドレスをステップ２０４で取得したＦＱＤＮにマッピングするエントリがｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮ中に作成される。

疑似ＩＰアドレスに対するタイムトゥーリブ（ＴＴＬ）は、ＶＰＲ１０４及び／若しくはアプリケーションによって実装される所定のＤＮＳプロトコルに対する最大許容値に、又は同一のＦＱＤＮに対するＤＮＳリクエストの頻度を低減するのに十分大きな別の値、例えば実ＩＰアドレスに対して用いられるＴＴＬ値よりも大きな値に設定２１４される。このことは、ＴＴＬの期限切れに起因するアプリケーションによるＤＮＳリクエストの数を減少させる。ステップ２１０で割り当てられた疑似ＩＰアドレスとステップ３１４で設定されたＴＴＬとを含むＤＮＳ応答が作成３１６され、傍受２０２されたＤＮＳリクエストを生成したアプリケーションにＤＮＳ応答が返信２１８される。

幾つかの例において、アプリケーションがドメイン名を解決するための別のリクエストを再度発行してもよいように、又は、別のアプリケーションが、過去の解決リクエストが傍受２０２されたドメイン名の解決をリクエストしてもよいように、疑似ＩＰアドレスのＴＴＬは期限が切れてもよい。どちらにせよ、ステップ２０４で識別されたＦＱＤＮは、ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル中に対応するエントリを有すると発見２０８されるであろう。これに応じて、方法２００は、ステップでＦＱＤＮに対応するテーブルから疑似ＩＰアドレスに対するＴＴＬの最大値に設定２１４することと、テーブル中のＦＱＤＮにマッピングされた疑似ＩＰアドレスとステップ２１４で設定されたＴＴＬとを含むＤＮＳ応答を作成２１６することと、傍受２０２されたＤＮＳリクエストを生成したアプリケーションに該ＤＮＳ応答を返信２１８することとを含んでもよい。ＴＴＬはまた、同一のＦＱＤＮに対するＤＮＳリクエストの頻度を低減するのに十分大きなその他の値、例えば実ＩＰアドレスに対して用いられるＴＴＬ値よりも大きな値に設定されてもよい。

図２の方法は、ＤＮＳリクエストを有利に抑制し、それにより、特にモバイルデバイスに対するレイテンシを減少させる。

図３を参照すると、幾つかの実施形態において、ＶＰＲ１０４、具体的にはＤＮＳリゾルバ１０８は、図２で説明されたプロセスからの幾つかのＤＮＳリクエストをバイパスしてもよい。例えば、中間サーバ１１８、１２０は、ＶＰＲ１０４をホストするコンピューティング装置１３００と地理的に近接していない可能性がある。従って、幾つかのドメインは、ローカルニュース、スポーツ、天気、小売店等、位置に特有のコンテンツへのアクセスを提供しうる。このため、リモート中間サーバ１１８、１２０よりもむしろＶＰＲ１０４にＤＮＳリクエストを解決させることが有利となる場合がある。

例えば、方法３００は、図２を参照しながら上述したように、ＤＮＳリクエストを傍受２０２することと、該ＤＮＳリクエストからＦＱＤＮを取得２０４することとを含んでもよい。方法３００は更に、ＦＱＤＮをルーティング規則にマッピングするＦＱＤＮ＿ｔｏ＿ｒｕｌｅｓテーブル等から、ＦＱＤＮに対応するルーティング規則を取得３０２することを試行することを含んでもよい。規則が発見されないと判定３０４された場合、方法３００はデフォルトのルーティング規則の取得３０６を含んでもよい。テーブルからの規則、又はデフォルトの規則が中間サーバ１１８、１２０のバイパスを必要としないと判定３０８された場合、方法３００は、図２を参照しながら上述したように、傍受２０２されたＤＮＳリクエストを発行したアプリケーションに疑似ＩＰアドレスを返信するステップ２０６〜２１８を実行することを含んでもよい。

テーブルからの規則、又はデフォルトの規則がバイパスを必要とすると発見３０８した場合、方法３００は、ＦＱＤＮを対応する実ＩＰアドレスにマッピングするＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰテーブル等から、ステップ２０４のＦＱＤＮに対応する実ＩＰアドレスを取得３１０することを試行することを含んでもよい。エントリが発見されない場合、そのエントリに対するＴＴＬは、実ＩＰアドレスに対する残存ＴＴＬ、例えば、実ＩＰアドレスを受信してからまだ経過していないＤＮＳサーバから実ＩＰアドレスに対して受信されたＴＴＬの量に設定される。実ＩＰアドレスとＴＴＬとを含むＤＮＳ応答が作成２１６されてもよく、リクエスト元のアプリケーションに返信２１８されてもよい。

ステップ２０４のＦＱＤＮに対応する実ＩＰアドレスが発見されない場合、方法３１６は、ステップ２０４のＦＱＤＮを含むＤＮＳリクエストをＤＮＳサーバに送信３１６することと、ステップ２０４のＦＱＤＮに対する実ＩＰアドレスとＴＴＬとを含む応答を受信３１８することと、ＦＱＤＮを実ＩＰアドレスに、実ＩＰアドレスをＦＱＤＮに、それぞれマッピングするためにＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰ及びｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルを更新することと、ステップ３１８で受信したＤＮＳ応答をリクエスト元のアプリケーションに返信２１８することとを含んでよい。実ＩＰアドレスに対するＴＴＬも、ＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰ及びｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中のエントリと関連付けて格納されてもよい。ＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰテーブルは同一のＦＱＤＮに対する２つ以上のＩＰアドレスを格納してもよく、ｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルは同一の実ＩＰに対する２つ以上のＦＱＤＮを格納してもよい。そのような場合、同一のキーと関連付けられた複数の値の内の１つが、ランダムセレクション、ラウンドロビン、又はその他のアルゴリズムによって選択されてもよい。

別の実装において、ＶＰＲ１０４は、ＤＮＳリクエストを傍受した後に疑似ＩＰアドレスを常に返信する。例えば、ルーティング規則が中間サーバ１１８、１２０のバイパスを必要とすると判断３０８されるか否かにかかわらず、ステップ２０６〜２１８を例外なく実行してよい。そのような実施形態において、ルーティング規則が中間サーバのバイパスを必要とすると判断３０８された場合、当該ＦＱＤＮを参照するコンテンツリクエストが受信されるまで実ＩＰアドレスが取得されないように、ステップ３１６〜３２０は省略されてもよい。

ルーティング規則によってバイパスが命じられていても疑似ＩＰアドレスが割り当て２１０される場合、ＶＰＲは、疑似アドレスＩＰを宛先として有するコンテンツパケットを受信すると、当該疑似ＩＰアドレスに関連付けられたドメイン名、ポート、プロトコルの内の幾つか又は全て等、１つ以上のパラメータを該パケットからを取得してもよい。ＶＰＲ１０４は、取得したパラメータを１つ以上のルーティング規則とその後整合させ、コンテンツリクエストがルーティング規則毎の中間サーバをバイパスすべき場合、ＶＰＲ１０４は、取得されたドメイン名の実ＩＰアドレスに対する自身のＤＮＳリクエストをその後発行し、取得された実ＩＰアドレスを用いてコンテンツリクエストをその後直接発行する、すなわち、コンテンツリクエストを中間サーバ１１８、１２０にまず送信することなく、そのコンテンツリクエストを、実アドレスＩＰによりアドレス指定されたサーバに送信する。

図４は、ＶＰＲ１０４により、例えばコンテンツルータ１１０により実行されてもよい方法４００を説明する。方法４００は、コンテンツリクエストが、コンテンツリクエストの宛先ＩＰフィールド中等に、疑似ＩＰアドレス（つまりルーティング不可ＩＰアドレス）を含むか否かを判定４０２することを含んでよい。そうである場合、方法４００は、その疑似ＩＰアドレスに対応するＦＱＤＮを、ｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルから取得４０４することを試行することを含む。テーブル中に疑似ＩＰアドレスが発見４０６された場合、テーブルからの対応するＦＱＤＮは、コンテンツリクエストに追加４０８され、コンテンツリクエストは中間サーバ１１８、１２０に送信４１０される。疑似ＩＰアドレスに対するエントリが発見４０６されない場合、その後エラーが返信４１２される。

コンテンツリクエストが疑似ＩＰアドレスを含まず、実ＩＰアドレスを含むと発見４０２された場合、ｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中の該実ＩＰアドレスに対応するＦＱＤＮを取得４１４する試行がなされる。テーブル中に実ＩＰアドレスに対応するＦＱＤＮの発見４１６されない場合、又は同一の実ＩＰアドレスに対する複数のＦＱＤＮが発見された場合、その後コンテンツリクエストは、単に該実ＩＰアドレスで中間サーバ１１８、１２０に送信４１０されてよい。一意なＦＱＤＮが発見された場合、その後ＦＱＤＮがコンテンツリクエストに追加４０８され、コンテンツリクエストは中間サーバ１１８、１２０にその後送信４１０される。

方法４００は、コンテンツリクエストが疑似ＩＰアドレスを含まない場合でも例外なくコンテンツリクエストを中間サーバ１１８、１２０に送信することを含む。コンテンツリクエストを受信すると、コンテンツリクエストに含まれるＦＱＤＮに対応する実ＩＰアドレスが中間サーバ１１８、１２０により取得されてよく、幾つかの実施形態では、実ＩＰアドレスを含むコンテンツリクエストに対しても同様である。

代替的な実施形態において、ＦＱＤＮをコンテンツリクエストに追加４０８することよりもむしろ、ＶＰＲ１０４は、コンテンツリクエストを疑似ＩＰアドレスと共に中間サーバ１１８、１２０に送信する。ＶＰＲ１０４は更に、コンテンツリクエストの傍受及び／又はコンテンツリクエストの中間サーバ１１８、１２０への転送の前に、中間サーバ１１８、１２０にｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルの現在のコピーを通信するために中間サーバ１１８、１２０と連絡する。ｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮに対する更新は、定期的に、又は変更がある度、例えば新しい疑似ＩＰアドレスが割り当て２１０られる度に、又はＸミリ秒毎に送信されてよい。コンテンツリクエストの受信に応答して、中間サーバ１１８、１２０は、ＦＱＤＮを検索して実ＩＰアドレスに解決するために、自身のｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮのコピーを用いてもよい。

図５は、コンテンツルータ１１０による等、ＶＰＲ１０４により実行されてもよい、ある一定の環境下で中間サーバ１１８、１２０をバイパスすることを含む方法５００を説明する。上記のように、中間サーバ１１８、１２０をバイパスすることは、コンテンツリクエストに応答して場所的に関連性のあるコンテンツが返信されるようにするため等、様々な理由のために、幾つかのドメインに対して有利に行われてよい。

方法５００は、コンテンツリクエストが疑似ＩＰアドレス（すなわち、ルーティング不可ＩＰアドレス）を含むか否かを判定５０２することを含んでもよい。そうである場合、方法５００は、その疑似ＩＰアドレスに対応するＦＱＤＮをｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルから取得５０４することの試行を含む。テーブル中に疑似ＩＰアドレスが発見５０６された場合、ステップ５０４で取得されたＦＱＤＮに対応するルーティング規則を、ルーティング規則をＦＱＤＮにマッピングするＦＱＤＮ＿ｔｏ＿ｒｕｌｅｓテーブル等のテーブルから取得５１２することの試行がなされてよい。

コンテンツリクエストが疑似ＩＰアドレスを含まないが、実ＩＰアドレスを含むと発見５０２された場合、ｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中の実ＩＰアドレスに対応するＦＱＤＮを取得５０８することの試行がなされる。テーブル中に実ＩＰアドレスに対応するＦＱＤＮが発見５１０された場合、ステップ５０８で取得されたＦＱＤＮに対応するルーティング規則を、ＦＱＤＮ＿ｔｏ＿ｒｕｌｅｓテーブル等のテーブルから取得５１２することの試行がその後なされる。ｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルが同一の実ＩＰに対する複数のＦＱＤＮを含む場合、規則はこれらのＦＱＤＮに対する一組の規則から選択することができる。例えば、これらのＦＱＤＮの内の少なくとも１つがこの規則と関連付けられている場合、中間サーバを通じてコンテンツリクエストが送信される。

ステップ５０４又はステップ５０８で取得されたＦＱＤＮに対するルーティング規則が発見５１４された場合、その後方法５００は、ルーティング規則がコンテンツリクエストにより中間サーバ１１８、１２０のバイパスを必要とするか否かを判定５１６することを含んでよい。そうである場合、コンテンツリクエスト中で特定された宛先に、コンテンツリクエストがその後送信５１８される。具体的には、コンテンツリクエストが実ＩＰアドレスを含む場合、コンテンツリクエストは、その実ＩＰアドレスに送信される。コンテンツリクエストが疑似ＩＰアドレスを含む場合は、ＤＮＳリクエストを発行し、実ＩＰアドレスを含む応答を受信し、実ＩＰアドレスを含むようにコンテンツリクエストを修正し、その実ＩＰアドレスに修正済みコンテンツリクエストを送信することによって、疑似ＩＰアドレスに対応するＦＱＤＮ（ＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル中のＦＱＤＮにマッピングされたＦＱＤＮ等）が実ＩＰアドレスに解決されてもよい。中間サーバ１１８、１２０のバイパス中にコンテンツリクエストを送信する方法の例は、図７に関して後述する。

ルーティング規則が中間サーバ１１８、１２０のバイパスを必要としないと判定５１６された場合、ステップ５０４及び５０８の内の１つで判定されたＦＱＤＮを含むコンテンツリクエストは中間サーバ１１８、１２０にその後送信５２０される。

ステップ５０４及び５０８の内の１つで判断されたＦＱＤＮに対するルーティング規則が発見５１２されない場合、コンテンツリクエストに対応するポート及びプロトコル（ＨＴＴＰ、ＴＣＰ、ＶＰＮ、ＣＯＮＮＥＣＴ等）の一方又は両方に対応するルーティング規則、例えば各ポート及び／又はプロトコルを、各ポート及び／又はプロトコルに対応するルーティング規則にマッピングするｐｏｒｔ＿ｐｒｏｔｏ＿ｔｏ＿ｒｕｌｅｓテーブル中等から取得５２２することの試行がなされてよい。ルーティング規則が発見されたと判定５２４された場合、上述のようにステップ５１６においてルーティング規則がその後適用される。規則が発見されないと判断５２４された場合、デフォルトの規則が設定５２６され、上述のようにステップ５１６においてデフォルトの規則が適用される。

幾つかの実施形態において、特定のＦＱＤＮ、プロトコル、及び／又はポートと関連付けられたルーティング規則は、例えば、リクエストされたＦＱＤＮに対する追加的なテストに基づいて、動的に変更されてもよい。例えば、コンテンツリクエストに対するテスト応答時間から判定されると、コンテンツリクエストは、クライアントから遠いが中間サーバの近くに格納されたコンテンツに対しては中間サーバ１１８、１２０を通じて送信されてもよく、又は、中間サーバよりもクライアントの近くに格納されたコンテンツに対してはバイパスされてよい。

幾つかの実施形態において、コンテンツリクエストが中間サーバ１１８、１２０をバイパスすべきかに加えて、ルーティング規則は更に、コンテンツリクエストの属性に基づき、コンテンツリクエストのその他の側面を特定してもよい。例えば、ルーティング規則は、コンテンツリクエストをプロキシを通じて送るか、それともＶＰＮを通じて送るか、又はいづれの中間サーバ１１８、１２０を用いるか等の、追加的な情報を特定してよい。一実装において、ＶＰＲ１０４は、２つ以上のコンテンツリクエストを、少なくとも２つの異なる中間サーバに提示する。各コンテンツリクエストに対する中間サーバ１１８、１２０は、そのＩＰアドレス、ポート、及びプロトコルと関連付けられたドメイン名のグループからコンテンツリクエストの１つ以上のパラメータを取得し、これらのパラメータを１つ以上のルーティング規則と整合させることにより判定される。例えば、リクエストされたドメインに対する中間サーバ１１８、１２０は、中間サーバの位置に特有のコンテンツ（ローカルニュース等）を検索するため、又は、パフォーマンス改善のため（例えば、クライアントとコンテンツサーバとの間の直接ルートからの逸脱を最小化するため）に選択される。

幾つかの実施形態において、ＤＮＳリゾルバ１０８は、中間サーバをバイパスするか否かを特定する規則のみを用いてもよく、一方、コンテンツルータ１１０は、コンテンツリクエストをリクエストされたモジュール１１２〜１１６又はその他のモジュールを通じてルーティングするための追加情報を用いてよい。一例において、ルーティング規則は、宛先ポート８０へのＴＣＰトラフィックをＨＴＴＰプロキシ１１２を通じて、その他の全てのＴＣＰトラフィックをＣＯＮＮＥＣＴプロキシ１１４を通じて送ることを特定してもよく、その他の任意のプロトコルを用いるトラフィックは、ＶＰＮモジュール１１６を通じてルーティングされる。別の例において、ルーティング規則は、暗号化されていないデータ交換が第三者により傍受されうる公衆ＷｉＦｉホットスポットにおいて、セキュリティを高めるために動的に変更されてもよい。例えば、ＨＴＴＰトラフィック（ＴＣＰポート８０）は、セキュアなＷｉＦｉホットスポットにおいてパフォーマンスを改善するためにＨＴＴＰプロキシを通じて、又は、公衆ＷｉＦｉホットスポットでユーザを保護するためにセキュアなＶＰＮを通じて、送信できる。ＷｉＦｉホットスポットのセキュリティを判定する方法は、参照によってその全体が全ての目的に対し本明細書に組み込まれる、２０１３年１２月３０日に出願された、ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＳＥＣＵＲＩＴＹ ＡＮＤ ＱＵＡＬＩＴＹ ＡＳＳＥＳＳＭＥＮＴ ＯＦ ＷＩＲＥＬＥＳＳ ＡＣＣＥＳＳ ＰＯＩＮＴＳを名称とする、米国特許出願番号６１／９２１，７８１に従ってもよい。ＷｉＦｉホットスポットのセキュリティを判定する方法はまた、参照によってその全体が全ての目的に対し本明細書に組み込まれる、２０１４年１２月１７日に出願された、ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＳＥＣＵＲＩＴＹ ＡＮＤ ＱＵＡＬＩＴＹ ＡＳＳＥＳＳＭＥＮＴ ＯＦ ＷＩＲＥＬＥＳＳ ＡＣＣＥＳＳ ＰＯＩＮＴＳを名称とする、米国特許出願番号１４／５７４，２４０に従ってもよい。

図６は、トラフィックインターセプタ１０６により傍受されたコンテンツリクエストに関するコンテンツルータ１１０による等、ＶＰＲ１０４により実行されてもよい方法６００を説明する。方法６００は図３〜５の方法と組み合わせて実行されてもよい。具体的には、コンテンツリクエストは、それらに対応するＦＱＤＮがコンテンツリクエストに含まれるか、又は図３〜５の方法により追加される場合、方法３００〜５００の内の幾つか又は全てに従って中間サーバ１１８、１２０にルーティングされると判定され、コンテンツリクエストが生成されたプロトコルに基づいて処理されてよい。

例えば、方法６００は、傍受されたコンテンツリクエストに関して行われてよい。方法６００は、コンテンツリクエストがトランスミッションコントロールプロトコル（ＴＣＰ）コンテンツリクエストであるか否かを判定６０２することを含んでもよい。そうである場合、コンテンツリクエストがＨＴＴＰ（ハイパーテキストトランスミッションプロトコル）リクエストであるか否かがステップ６０４で評価される。そうである場合、コンテンツリクエストはＨＴＴＰプロキシ１１２を通じて中間サーバ１１８に送信６０６される。

コンテンツリクエストがＨＴＴＰリクエストではないと判定６０４された場合、その後ＦＱＤＮがコンテンツリクエスト中に発見されたか、それとも上述のように疑似ＩＰアドレスに従ってコンテンツリクエストに解決されたか。そうである場合、コンテンツリクエストのＣＯＮＮＥＣＴヘッダにそのＦＱＤＮが追加され、修正された状態のコンテンツリクエストがＣＯＮＮＥＣＴプロキシ１１４を通じて送信６１２される。ＦＱＤＮが発見されいと判定６０８された場合、その後方法６００は、コンテンツリクエストが疑似ＩＰアドレスを含んだか否かを評価６１４することを含む。そうでない場合、実ＩＰを含んだコンテンツリクエストがＣＯＮＮＥＣＴプロキシ１１４を通じて送信６１２されてもよい。コンテンツリクエストが疑似ＩＰアドレスを含むと発見６１４した場合、その後エラーが返信６１６される。一実施形態において、ＦＱＤＮがＩＰアドレスと一意に関連付けられている場合にのみ、ＦＱＤＮがＣＯＮＮＥＣＴリクエストに追加される。そのような実施形態では、２つ以上のＦＱＤＮが同一の実ＩＰと関連付けられる場合、ＦＱＤＮを追加することなく、該リクエストはＣＯＮＮＥＣＴプロキシを通じて送信される。

コンテンツリクエストがＴＣＰコンテンツリクエスト以外であると判定６０２された場合、方法６００は、ＦＱＤＮがコンテンツリクエスト中で発見されたか、それとも上述のように疑似ＩＰアドレスに従ってコンテンツリクエストに解決されたかを評価６１８することを含んでもよい。そうである場合、その後ＦＱＤＮがコンテンツリクエストに追加６２０され、コンテンツリクエストはＶＰＮモジュール１１６を通じて送信６２２される。ＦＱＤＮがコンテンツリクエスト中又はコンテンツリクエストに対して発見されないと判定６１８された場合、その後ステップ６２４において、コンテンツリクエストが疑似ＩＰアドレスを含むか否かが評価される。そうである場合、その後エラーが返信６１６される。そうでない場合、その後コンテンツリクエストはＶＰＮモジュール６２２を通じて送信６２２される。

図６は、コンテンツリクエストが受信されてもよい３つの可能なプロトコル（ＨＴＴＰ、ＣＯＮＮＥＣＴ、ＶＰＮ）の一例である。他の実施形態では、他のプロトコルがが使用されてもよく、コンテンツリクエストは、そうしたコンテンツリクエストの送信を実装するための対応するモジュールを通じてルーティングされる。

図７は、ＶＰＲ１０４、具体的にはコンテンツルータ１１０が、図５の方法５００等に従って、中間サーバをバイパスするように選択されたコンテンツリクエストを処理してもよい例示的方法７００を説明する。方法７００は、コンテンツリクエストが疑似ＩＰアドレスを含むか否かを判定７０２することを含んでもよい。そうでない場合、その後コンテンツリクエストは、コンテンツリクエストに含まれる実ＩＰアドレスに単に送信７０４される。そうである場合、その後方法７００は、疑似アドレスに対応するＦＱＤＮが、ｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中等で発見されるか否かを評価７０６することを含んでもよい。そうでない場合、その後エラーが返信７０８される。そうである場合、その後ＦＱＤＮに対する実ＩＰアドレスは、ＦＱＤＮと共にＤＮＳリクエストを送信７１０し、実ＩＰアドレスと共にＤＮＳリクエストに対する応答を取得７１２し、ＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰ及びｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルをＦＱＤＮと実ＩＰアドレスとの間のマッピングを含むように更新７１４し、コンテンツリクエスト中の疑似ＩＰアドレスを実ＩＰアドレスに置き換える７１６ことによって取得される。修正済みのコンテンツリクエストは実ＩＰアドレスにその後送信７０４されてもよい。ドメイン名とＩＰアドレスとの間のマッピングを格納することに加えて、コンテンツルータはルーティング不可ＩＰアドレスと実ＩＰアドレスとの間のマッピングをも格納し、これを、ルーティング不可ＩＰアドレスが同じドメインに既に割り当てられた後に実ＩＰを受信すると、このマッピングを更新する。

図８Ａ〜８Ｄは、様々なプロトコルのコンテンツリクエストに対して中間サーバ１１８、１２０により実行されてもよい方法８００を説明する。図８ＡのステップはＨＴＴＰコンテンツリクエストに対して実行されてもよい。ＨＴＴＰリクエストに対しては、方法８００は、コンテンツリクエストが疑似ＩＰアドレスを含むか否かを判定７０２することを含んでもよい。そうでない場合、コンテンツリクエストは、該コンテンツリクエストに含まれる実ＩＰに単に送信８０４される。そうである場合、その後方法８００は、ＨＴＴＰコンテンツリクエストのホストヘッダからＦＱＤＮを取得８０６することを含んでもよい。そのＦＱＤＮに対する実ＩＰアドレスは、ＦＱＤＮと共にＤＮＳリクエストを送信８０８し、実ＩＰアドレスと共にＤＮＳリクエストに対する応答を取得８１０し、ＨＴＴＰコンテンツリクエスト中の疑似ＩＰアドレスを実ＩＰアドレスに置き換える８１２ことによって取得される。修正済みのＨＴＴＰコンテンツリクエストは、実ＩＰアドレスにその後送信８０４されてもよい。

図８Ａから理解されるように、また、図８Ｂ〜図８Ｄに関して理解されるように、本明細書の他の方法において説明されるように疑似ＩＰアドレスを含むことに起因してＦＱＤＮを含むように修正されたコンテンツリクエストは、中間サーバ１１８、１１０に送信される場合に、疑似ＩＰアドレスを宛先ＩＰフィールド中等に依然として含んでもよく、これにより、中間サーバ１１８、１２０によるＤＮＳ解決が必要か否かかの判定を容易にするようにしてもよい。

図８Ｂを参照すると、非ＨＴＴＰ ＴＣＰコンテンツリクエストに対しては、方法８０は、コンテンツリクエストが疑似ＩＰアドレスを含むか否かを判定８１４することを含んでもよい。そうでない場合、その後コンテンツリクエストは、該コンテンツリクエストに含まれる実ＩＰアドレスに単に送信８１６される。そうである場合、その後方法８００は、ＣＯＮＮＥＣＴヘッダからＦＱＤＮを取得８１８することを試行することと、ＦＱＤＮがＣＯＮＮＥＣＴヘッダ中に発見されるか否かを評価８２０することとを含んでもよい。そうでない場合、その後エラーが返信８２２される。そうである場合、その後ＦＱＤＮに対する実ＩＰアドレスは、ＦＱＤＮと共にＤＮＳリクエストを送信８２４し、実ＩＰアドレスと共にＤＮＳリクエストに対する応答を取得８２６し、コンテンツリクエスト中の疑似ＩＰアドレスを実ＩＰアドレスに置き換える８２８ことによって取得される。修正済みのコンテンツリクエストは実ＩＰアドレスにその後送信８１６されてもよい。

図８Ｃを参照すると、ＶＰＮコンテンツリクエストに対しては、方法８０は、コンテンツリクエストが疑似ＩＰアドレスを含むか否かを判定８３０することを含んでもよい。そうでない場合、その後コンテンツリクエストは、該コンテンツリクエストに含まれる実ＩＰアドレスに単に送信８３２される。そうである場合、その後方法８００は、コンテンツリクエストに含まれるデータからＦＱＤＮを取得８３４することを試行することと、ＦＱＤＮがリクエストデータ中で発見されるか否かを評価８３６することとを含んでもよい。そうでない場合、その後エラーが返信８３８される。そうである場合、その後ＦＱＤＮに対する実ＩＰアドレスは、ＦＱＤＮと共にＤＮＳリクエストを送信８４０し、実ＩＰアドレスと共にＤＮＳリクエストに対する応答を取得８４２し、コンテンツリクエスト中の疑似ＩＰアドレスを実ＩＰアドレスに置き換える８４４ことで取得される。修正済みのコンテンツリクエストは、実ＩＰアドレスにその後送信８３２されてもよい。

図８Ａ〜図８Cは、ＤＮＳサーバからＤＮＳ名をリクエストすることによりＤＮＳ解決が行われる方法を記述する。しかしながら、方法８００は更に、各ＦＱＤＮを、そのＦＱＤＮに対して過去に受信した実ＩＰアドレスにマッピングするＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰテーブル中等に、ドメイン名をキャッシュすることを含んでもよい。従って、コンテンツリクエストに対するＦＱＤＮが特定されると、このテーブルから実ＩＰが検索されてもよい。

幾つかの実施形態において、実際のドメイン名を含まないがドメイン名を表す列へのポインタを含むコンテンツリクエストがＶＰＲによって生成されてもよい。ドメイン名を含むテーブルは、各ポインタをテーブル中のテキスト列に解決することによって中間サーバがポインタをドメイン名に解決するように、ＶＰＲ１０４と中間サーバ１１８、１２０との間で共有されてもよい。

図９は、ＶＰＲ１０４と、ＶＰＮサーバ１２０として機能する中間サーバ１２０とにより実行されてもよい方法９００を説明する。方法９００は、ＶＰＲ１０４によってＶＰＮトラフィックを傍受９０２することと、そのトラフィックが疑似ＩＰアドレスを含むか否かを評価９０４することとを含んでもよい。そうでない場合、その後トラフィックは、該トラフィックのアドレス指定を修正することなく、ＶＰＮサーバ１２０に送信９０６されてもよい。

そうである場合、その後方法９００は、その疑似ＩＰアドレスに対するＦＱＤＮを上述のＦＱＤＮ＿ｔｏ＿ｎｒ＿ＩＰテーブル等から検索９０８することを含んでもよい。ＦＱＤＮは、ＶＰＮトンネル内でトラフィックにその後追加９１０されてもよく、修正済みのトラフィックがＶＰＮサーバ１２０に送信９１２されてもよい。ＦＱＤＮを追加９１０することは、トラフィックに追加のパケットを挿入すること、又は傍受９０２されたトラフィックの幾つか又は全てのパケットのフィールドにＦＱＤＮを追加することを含んでもよい。一実施形態において、ＦＱＤＮの記述子は、疑似ＩＰを宛先ＩＰアドレスとして有するＴＣＰ又はＵＤＰ接続の一組のデータパケットに、これらのデータパケットがＶＰＮパケット内にカプセル化される前に追加される。

トラフィックを送信９１２することは、ＶＰＮトンネル内で修正済みのトラフィックをまずカプセル化することを含んでもよい。当技術分野で周知のように、ＶＰＮトンネルは、パケットを暗号化することと、ＶＰＮサーバ１２０にその後送信される対応するＶＰＮヘッダと共に、暗号化されたパケットをＶＰＮパケット内に含むこととを含んでもよい。幾つかの例において、傍受９０２されたＶＰＮトラフィックは、ＨＯＳＴ、ＳＮＩ、又はＣＯＮＮＥＣＴヘッダ中等にＦＱＤＮをに既に含んでもよく、この場合ステップ９０８〜９１０は省略でき、トラフィックは、ＦＱＤＮの追加なしに、カプセル化されてＶＰＮサーバ１２０に送信９１２されてもよい。

ＶＰＮサーバ１２０は、修正済みのトラフィックを受信９１４してもよく、修正済みのトラフィックを取得するためＶＰＮパケットをデカプセル化してもよい。当技術分野で周知のように、デカプセル化は、ＶＰＮヘッダを取り除くことと、カプセル化されたトラフィックを復号化することとを含んでもよい。ＦＱＤＮは、ＶＰＮサーバ１２０によって修正済みのトラフィックから抽出９１６され、実ＩＰアドレスに解決９１８されてよい。ＦＱＤＮを実ＩＰアドレスに解決９１８することは、ＦＱＤＮと共にＤＮＳリクエストを発行することと、その応答として実ＩＰアドレスを受信することを含んでよい。解決９１８することは、過去に解決されたＦＱＤＮを実ＩＰアドレスにマッピングするテーブルから実ＩＰアドレスを検索することを含んでもよい。

幾つかの実施形態において、ＶＰＲ１０４は、ＦＱＤＮではなくむしろ、修正済みのトラフィック中のテキスト列へのポインタを含んでもよく、該テキスト列はＦＱＤＮを含む。これに従い、ＦＱＤＮを抽出９１６することは、ポインタに対応するテキスト列を検索することを含んでもよい。

幾つかの実施形態において、ＶＰＲ１０４及びＶＰＮサーバ１２０はｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルを共有してもよく、すなわち、ＶＰＮサーバ１２０がテーブルの現在のコピーを有するように、ＶＰＲ１０４は定期的にテーブルを送信してもよく、又はテーブルを更新をしてもよい。従って、トラフィックはＶＰＲ１０４によって修正される必要がなく、ＶＰＮサーバ１２０はトラフィックを受信し、自身のバージョンのｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブルを用いて疑似ＩＰアドレスをＦＱＤＮに解決する。

実ＩＰアドレスが一旦取得されると、ＶＰＮサーバ１２０は、受信９１４されたトラフィック中の疑似ＩＰアドレスを実ＩＰアドレスに置き換え９２０、ステップ９２０で修正済みのトラフィックを実ＩＰアドレス、すなわち、実ＩＰアドレスが割り当てられたコンピュータシステムに送信９２２してもよい。

図９の方法は、ＶＰＮサーバへの従来のアプローチとは異なる。ＨＴＴＰ及びＨＴＴＰＳプロキシサーバは、それらのデータパケットが実宛先ＩＰアドレスを含まない（それはプロキシサーバのアドレスにより置き換えられる）ため、自身のＤＮＳリクエストを発行する必要がある。しかしながら、従来技術のＶＰＮサーバは、宛先ＩＰアドレスを既に含むデータパケットに対して追加のＤＮＳリクエストを行わなわず、カプセル化ヘッダを取り除き、元のパケットをそれらの宛先に送るだけである。

図１０を参照すると、幾つかの実施形態において、ＶＰＮサーバ１２０は、それに接続するクライアント装置に対するレイテンシを、クライアント装置が本明細書に記載されるようにＶＰＲ１０４を実行するか否かにかかわらず、低減してもよい。例えば、ＶＰＮサーバ１２０は、ＶＰＮ接続内で受信されたコンテンツリクエストに関して、図示された方法１０００を実行してよい。方法１０００は、ルーティング可能ＩＰアドレスを含むコンテンツリクエストを受信１００２することと、逆ＤＮＳ（ｒＤＮＳ）リクエストをＤＮＳサーバに発行すること、又は過去のＤＮＳ又はｒＤＮＳリクエストに対する応答に従ってルーティング可能ＩＰアドレスをドメイン名にマッピングするキャッシュからルーティング可能ＩＰアドレスを検索すること等によってルーティング可能ＩＰアドレスに対応するドメイン名を識別１００４することを含んでよい。

方法１０００は更に、ステップ１００４で識別されたドメイン名に対するＤＮＳリクエストを発行１００６することと、その返答に、ステップ１００４で識別されたものとは異なりうるルーティング可能ＩＰアドレスを受信１００８することとを含んでよい。該異なるルーティング可能ＩＰアドレスを受信すると、コンテンツリクエストは、その異なるルーティング可能ＩＰアドレスを含むように修正されてもよく、その異なるルーティング可能ＩＰアドレスを有するサーバシステムに送信１０１２されてもよい。

例えば、ヨーロッパのクライアント装置がヨーロッパ及び米国の両方のコンテンツサーバに対応するドメインに対するＤＮＳリクエストを発行し、ヨーロッパのコンテンツサーバに対する実ＩＰアドレスをその後受信する。このＩＰアドレスは、コンテンツリクエストがヨーロッパ内においてクライアントから直接発行された場合のアクセスレイテンシを低減する。しかしながら、ヨーロッパのクライアントが米国のＶＰＮサーバ１２０とＶＰＮ接続を確立した場合、提供された実ＩＰアドレスは、著しいパフォーマンス悪化の生じさせることがあり、クライアントリクエストは、米国のＶＰＮサーバ１２０からヨーロッパのコンテンツサーバに送られるであろう。応答は米国のＶＰＮサーバ１２０から送られ、ヨーロッパのクライアントにその後返される。ＶＰＮサーバ１２０がＤＮＳリクエストを発行１００６することにより、ドメイン名は、同一のドメイン名に対応するより近いサーバシステムのＩＰアドレスに解決されてもよく、それによりレイテンシを低減する。

幾つかの実施形態において、本発明に従うと、ＶＰＮサーバ１２０は、追加のＤＮＳリクエストを発行１００６する必要があると検出し、提供された宛先ＩＰアドレスをＤＮＳ応答から取得されたものにより置き換える。上記の例において、ＶＰＮサーバ１２０は実ＩＰアドレスを評価し、その提供された実ＩＰアドレスがヨーロッパのコンテンツサーバを参照することを検出する。その応答として、ＶＰＮサーバ１２０は、自身のＤＮＳリクエストを発行１００６し、より近くの、例えば上記の例では米国の、より近くのコンテンツサーバを参照する応答を受信１００８してもよく、それによりパフォーマンスが改善される。一実装において、追加のＤＮＳリクエストが必要であるとの検出は、（ａ）ステップ１００２で受信した、リクエストされた実ＩＰアドレスの地理的位置を解決し、（ｂ）リクエストされた実ＩＰアドレスがＶＰＮサーバ１２０のものとは異なる地理的地域に設置されたコンテンツサーバを参照すると判断された場合、例えばコンテンツサーバが、ある政治的若しくは地理的地域（国、州、大陸）の外にある、又はＶＰＮサーバ１２０からの閾値距離を超える場合、追加のＤＮＳリクエストが発行されるようにすることを含む。ＶＰＮサーバ１２０は、それ故、この比較を容易にするために、自身の位置を格納させられるか、又は取得するようにプログラムされてもよい。ＶＰＮサーバ１２０及びコンテンツサーバの地理的地域が同じか、又は互いから閾値距離内にあると判断される例では、ステップ１００２で受信された実ＩＰアドレスはＶＰＮサーバ１２０によってその後変更されず、コンテンツリクエストは、ステップ１００２で受信された実ＩＰアドレスに対応するコンテンツサーバに送信される。

図１１は、ＶＰＲ１０４及び中間サーバ１１８の双方によるＤＮＳリクエストを減らすために、ＶＰＲ１０４及び中間サーバ１１８によって実行されてもよい方法１１００を説明する。方法１１００は、コンテンツリクエストを受信１１０２することと、コンテンツリクエストが（ａ）実ＩＰアドレスを含むこと、（ｂ）ＶＰＲ１０４により実ＩＰアドレスが格納されるＦＱＤＮにマッピングされる疑似ＩＰアドレスを含むこと、又は（ｃ）ＶＰＲ１０４が対応するＩＰアドレスを格納しているＦＱＤＮを含むこと、の内の少なくとも１つであるか否かを判定することとを含む。例えば、コンテンツリクエストが疑似ＩＰアドレスを含む場合、対応するＦＱＤＮがｎｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中で検索されてよい。コンテンツリクエストに含まれる、又は疑似ＩＰアドレスから判定されるＦＱＤＮに対応する実ＩＰアドレスは、そのＦＱＤＮに対するエントリが存在する場合、ＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰテーブルから検索されてもよい。言い換えると、ステップ１１０４は、ＤＮＳリクエストを発行することなく、ＶＰＲ１０４によってコンピュータシステム１３００にキャッシュされたデータのみを用いて、ＶＰＲ１０４によって実ＩＰアドレスが判定されうるか否かを判定することを含んでもよい。

コンテンツリクエストがアドレス指定される実ＩＰアドレスが、ステップ１１０４に関して上述したようにＶＰＲによって解決されてもよい場合、その後コンテンツリクエストは、そのコンテンツリクエストを中間サーバ１１８にまず送信することなく、ＶＰＲ１０４によって、該実ＩＰアドレスに対応するサーバシステムに直接送信１１０６される。

実ＩＰアドレスがコンピュータシステム１３００上に格納されたキャッシュデータのみを用いて判定できない疑似ＩＰアドレス又はＦＱＤＮを含むとコンテンツリクエストが発見１１０４された場合、その後コンテンツリクエストは、リクエストに含まれるＦＱＤＮ又はリクエストに含まれる疑似ＩＰアドレスに対応するＦＱＤＮと共に中間サーバ１１８に送信１１０８されてもよい。

中間サーバ１１８は、ＦＱＤＮと共にリクエストを受信１１１０し、そのＦＱＤＮと共にＤＮＳリクエストを発行して応答を受信することによって、又は中間サーバ１１８にローカルに格納されたデータ中の実ＩＰアドレスへのＦＱＤＮのマッピングを発見することによって、ＦＱＤＮを実ＩＰアドレスに解決１１１０する。中間サーバは、実ＩＰアドレスをコンテンツリクエストにその後追加し、コンテンツリクエストを実ＩＰアドレス、すなわち実ＩＰアドレスを割り当てられたサーバに転送１１１４し、該サーバは、コンテンツリクエストを処理し、中間サーバ１１８に応答を返信する。中間サーバ１１８は、コンテンツリクエストに対する応答を受信１１１６し、ステップ１１１２で判断されたＦＱＤＮに対する実ＩＰアドレスと共に、ＶＰＲ１０４に応答を返信１１１８する。ＤＮＳリクエストに対する応答中に含まれるその他のデータ、例えばＦＱＤＮに対する実ＩＰアドレスやＦＱＤＮ又はリクエストされたコンテンツと関連付けられた他の実ＩＰアドレスのＴＴＬも返信されてよい（例えば図１２及び対応する説明を参照）。

例えば、１つ以上の実ＩＰアドレスと任意の追加データ（例えばＴＴＬ）は、リクエストされたコンテンツと共に返信１１１８されるＨＴＴＰヘッダ内において返信されてもよい。別の実装において、実ＩＰアドレスは、そのデータパターン又は返信されるデータセット内での位置によりＶＰＲ１０４によって認識されるデータパケット中で返信される。例えば、実ＩＰアドレスは、リクエストされたコンテンツのパケットの前に挿入される最初のコンテンツパケット中で返信されることができる。ＶＰＲ１０４は、リクエスト元のアプリケーションに応答を返信する前に、実ＩＰアドレスを検索し、最初のパケットを除去する。

別の実装において、あるコンテンツリクエストに対する実ＩＰアドレスは、別のコンテンツリクエストに対するデータと共に返信される。一実施形態において、中間サーバ１１８、１２０は、複数のドメイン名とそれらの実ＩＰとの間の一組の対応関係を、コンテンツデータと共に返信する。リストされたＩＰに対応するドメイン名は、過去に発行されたコンテンツリクエスト、又は将来発行されると予想されるコンテンツリクエストを参照することができる。

例えば、ドメインＡからコンテンツへのリクエストを受信した後、中間サーバ１１８、１２０は、メインサイトＡ（サーバに既知の、又はドメインＡからのＨＴＭＬ応答を解析することで得られるドメイン）により参照されるドメインに対するＤＮＳリクエストを発行してもよく、そのようなドメインと実ＩＰとの組を、ドメインＡからのコンテンツリクエストに対する応答と共に提供してもよい。結果として、ＶＰＲ１０４は、未知のドメインへの少量のコンテンツリクエストのみのために中間サーバ１１８、１２０を使う必要があり、それにより、パフォーマンスが更に改善される。

ＶＰＲ１０４は、応答を受信し、ＦＱＤＮと実ＩＰアドレスとの対応関係をＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰ及びｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中に格納すること等によって、１つのＦＱＤＮ（又は複数のＦＱＤＮ）にマッピングされた１つの実ＩＰアドレス（又は複数の実アドレス）を格納１１２２する。応答は更に、受信１１０２されたコンテンツリクエストを発行したアプリケーションに、ＶＰＲ１０４によって返信されてよい。応答は実ＩＰアドレスを含んでもよく、又は除外してもよい。

同一又は異なるアプリケーションによるその他のコンテンツリクエストに関する方法１１００の後続の反復において、ＦＱＤＮに対する実ＩＰアドレスはステップ１１０４において発見され、ステップ１１０８〜１１２２は省略でき、それによって、後続のコンテンツリクエストに対するレイテンシが低減され、中間サーバ１１８、１２０がバイパスされる。

図１２を参照すると、図示の方法１２００は、本明細書に記載されるように、ＶＰＲ１０４を実行してもしなくてよいクライアント装置に対するプロキシサーバとして機能する中間サーバ１１８により実行されてもよい。方法１２００は、中間サーバが後続のＤＮＳリクエストの少なくとも一部を予期することを可能とし、クライアント装置のキャッシュに実ＩＰアドレスを追加することでレイテンシを低減する。

方法１２００は、ドメイン名又は実ＩＰアドレスにアドレス指定されるコンテンツに対するリクエストを受信１２０２することと、その実ＩＰアドレスにアドレス指定されたコンテンツリクエストを送信しその実ＩＰアドレスと関連付けられたサーバからコンテンツリクエストに対する応答を受信すること等によって、そのドメイン名又は実ＩＰアドレスによりアドレス指定されたサーバからリクエストされたコンテンツを検索１２０４することとを含んでもよい。

方法１２００は更に、そのコンテンツに対する関連するドメインを識別１２０６することを含んでもよい。例えば、検索１２０４されたコンテンツがウェブページである場合、ウェブページ中のリンクによる参照ドメインが識別１２０６されてもよい。別の例において、元のドメインリクエストに追随するドメインリクエストの過去の組を観察することによって、関連ドメインのリストを作成することができ、この方法は、中間サーバによって解析できないＨＴＴＰＳコンテンツに対して用いることができる。方法１２００は更に、関連ドメインに対するＤＮＳリクエストを発行１２０８することと、関連ドメインに対する実ＩＰアドレスを受信１２１０することとを含んでもよい。方法１２００は更に、関連ドメインに対する実ＩＰアドレスを返信することと、コンテンツが受信１２０４されたクライアント装置に、検索１２０４されたコンテンツを返信１２１４することとを含んでもよい。コンテンツリクエストがドメインを含む場合、そのドメインに対する実ＩＰアドレス及び関連ドメインが返信１２１２されてもよい。実ＩＰアドレス及びコンテンツは、同一又は異なるメッセージ中に含まれてもよい。

実ＩＰアドレスを受信すると、クライアント装置は、後続のコンテンツリクエストを中間サーバ１１８に送信することなく、ＩＰアドレスに対応するサーバに直接送信されるように、それらをキャッシュしてもよい。例えば、クライアント装置は、関連ドメインと実ＩＰアドレスの間の対応関係をＦＱＤＮ＿ｔｏ＿ｒ＿ＩＰ及びｒ＿ＩＰ＿ｔｏ＿ＦＱＤＮテーブル中に格納してもよい。

方法１２００は更に、関連ドメインの１つ以上の実ＩＰアドレスへのＴＣＰ接続を、クライアントがこれらのドメインにコンテンツリクエストを送信するのを待たずに、サーバが先制して確立することを含んでよい。

方法１２００は更に、サーバが１つ以上の関連ドメイン、例えば、コンテンツリクエストに対してＨＴＴＰＳプロトコルを使用すると知られているものに対するＴＬＳハンドシェイクを先制して行うことを含んでもよい。これを行うために、サーバは、クライアントによって特定のドメインに対し行われたＴＬＳハンドシェイクから、セッションＩＤ又はセッションチケットを取得し、同じドメインに対する別のＴＬＳハンドシェイクを先制して開始するために取得した値を用い、ＴＬＳ応答をクライアントにその後渡す。クライアントは、ＴＬＳ応答をキャッシュし、同一のセッションＩＤ又はチケットで同一のドメインに対するＴＬＳリクエストを発行した後にそれをアプリケーションに返信することで、更にパフォーマンスを改善させる。サーバは、セッションＩＤ又はセッションチケットを、クライアントにより開始されたＴＬＳハンドシェイクを観察することによって、又はそうした値をクライアントから受信することによって、取得でき、ＴＬＳセッションＩＤ又はセッションチケットのどちらも、クライアントとコンテンツプロバイダにのみ知られるべきである暗号鍵を開示しないので、秘匿される必要はない。

図１３は、ＶＰＲ１０４をホストしてよい例示的コンピューティング装置１３００を説明するブロック図である。中間サーバ１１８、１２０も、コンピューティング装置１３００の幾つか又は全体の属性を有してよい。コンピューティング装置１３００は、例えば本明細書に述べられるような、様々な手順を実行するために用いられてよい。コンピューティング装置１３００は、サーバ、クライアント、又はその他の任意のコンピューティングエンティティとして機能できる。コンピューティング装置は本明細書に述べられるような様々な監視機能を実行でき、例えば本明細書に述べられるアプリケーション等の、１つ以上のアプリケーションプログラムを実行できる。コンピューティング装置１３００は、、デスクトップコンピュータ、ノートブックコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、タブレットコンピュータ等の多様な種類のコンピューティング装置の何れかであってもよい。

コンピューティング装置１３００は、１つ以上のプロセッサ１３０２、１つ以上の記憶装置１３０４、１つ以上のインターフェース１３０６、１つ以上の大容量記憶装置１３０８、１つ以上の入出力（Ｉ／Ｏ）装置１３１０、及び表示装置１３３０を含み、これらの全てはバス１３１２に結合される。プロセッサ１３０２は、記憶装置１３０４及び／又は大容量記憶装置１３０８に格納された１つ以上の命令を実行するプロセッサ又はコントローラを含む。プロセッサ１３０２はまた、キャッシュメモリ等の、様々な種類のコンピュータ読み取り可能媒体を含んでもよい。

記憶装置１３０４は、揮発性メモリ（例えばランダムアクセスメモリ（ＲＡＭ））及び／又は不揮発性メモリ（例えばリードオンリメモリ（ＲＯＭ）１３１６）等の様々なコンピュータ読み取り可能媒体を含む。記憶装置１３０４はまた、フラッシュメモリ等の書き換え可能なＲＯＭを含んでもよい。

大容量記憶装置１３０８は、磁気テープ、磁気ディスク、光学ディスク、及び固体メモリ（例えばフラッシュメモリ）等の様々なコンピュータ読み取り可能媒体を含む。図１３に示されるように、具体的な大容量記憶装置はハードディスクドライブ１３２４である。様々なドライブがまた、大容量記憶装置１３０８に含まれてもよく、様々なコンピュータ読み取り可能媒体との間での読み取り／書き込みを可能にしてよい。大容量記憶装置１３０８は可換型媒体１３２６及び／又は固定型媒体を含む。

入出力装置１３１０は、データ及び／又はその他の情報を、コンピューティング装置１３００との間で入力又は検索可能にする様々な装置を含む。例示的な入出力装置１３１０は、カーソル制御装置、キーボード、キーパッド、マイク、モニタ若しくはその他の表示装置、スピーカ、プリンタ、ネットワークインターフェースカード、モデム、レンズ、及びＣＣＤ若しくはその他の画像取得装置等を含む。

表示装置１３３０は、コンピューティング装置１３００の１人以上のユーザに、情報を表示できる任意の種類の装置を含む。表示装置１３３０の例は、モニタ、表示端末、及び映像投影装置等を含む。

インターフェース１３０６は、コンピューティング装置１３００が他のシステム、装置、又はコンピューティング環境と相互作用すること可能にする様々なインターフェースを含む。例示的なインターフェース１３０６は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワーク、及びインターネット等の任意の数の異なるネットワークインターフェース１３２０を含む。その他のインターフェースはユーザインターフェース１３１８及び周辺装置インターフェース１３２２を含む。インターフェース１３０６はまた、１つ以上のユーザインターフェース要素１３１８を含む。インターフェース１３０６はまた、プリンタ、ポインティング装置（マウス、トラックパッド等）、及びキーボードに対するインタフェース等の１つ以上の周辺インターフェースを含む。

バス１３１２は、プロセッサ１３０２、記憶装置１３０４、インターフェース１３０６、大容量記憶装置１３０８、及び入出力装置１３１０が、バス１３１２に結合されたその他の装置又はコンポーネントと共に相互に通信することを可能とする。バス１３１２は、システムバス、ＰＣＩバス、ＩＥＥＥ １３９４バス、及びＵＳＢバス等の幾つかの種類のバス構成の内の１つ以上を表す。

例示の目的で、プログラム及びその他の実行可能なプログラムコンポーネントは本明細書において個別のブロックとして示されているが、そのようなプログラム及びコンポーネントはコンピューティング装置１３００の異なる記憶要素内に、様々なタイミングで存在し、プロセッサ１３０２により実行されてもよいことが理解される。代替的に、本明細書に述べられるシステム及び手順は、ハードウェア、又はハードウェア、ソフトウェア、及び／若しくはファームウェアの組み合わせにより実行することができる。例えば、１つ以上の特定用途集積回路（ＡＳＩＣ）が、１つ以上の本明細書に述べられるシステム及び手順を実行するようプログラムされることが可能である。

Claims (58)

1. ドメイン解決の抑制のための方法であって、
   コンピューティング装置上で実行するアプリケーションから、同じ前記コンピューティング装置上で実行するモジュールによって、ドメイン名を含むドメイン解決リクエストであって、第１の外部サーバにアドレス指定された前記ドメイン解決リクエストを傍受することと、
   前記モジュールによって、前記ドメイン解決リクエストの前記外部サーバへの送信を抑制することと、
   前記モジュールによって、前記アプリケーションに、疑似インターネットプロトコル（ＩＰ）アドレスを前記ドメイン解決リクエストに対する応答として返信することと、
   前記モジュールによって、前記疑似ＩＰアドレスを前記ドメイン解決リクエストの前記ドメイン名にマッピングするエントリを格納することと
   を含む、方法。
2. 前記モジュールによって、前記アプリケーションから、前記疑似ＩＰアドレスを含むコンテンツリクエストを傍受することと、
   前記モジュールにより前記アプリケーションから前記疑似ＩＰアドレスを含む前記コンテンツリクエストを傍受することに応答して、前記エントリ中の疑似ＩＰアドレスにマッピングされた前記ドメイン名を含む修正済みコンテンツリクエストを生成することと、
   前記修正済みコンテンツリクエストを、前記第１の外部サーバ及び異なる外部サーバの内の１つに送信することと
   を更に含む、請求項１に記載の方法。
3. 前記第１の外部サーバ及び前記異なる外部サーバの内の前記１つによって、
   前記修正済みコンテンツリクエストを受信することと、
   前記ドメイン名に対応する実ＩＰアドレスを取得することと、
   前記修正済みコンテンツリクエストに従って前記実ＩＰアドレスからコンテンツをリクエストすることと、
   前記修正済みコンテンツリクエストに従って前記コンテンツを受信することと、
   前記修正済みコンテンツリクエストに従って前記コンテンツを前記コンピューティング装置に送信することと
   を更に含む、請求項２に記載の方法。
4. 前記ドメイン解決リクエストに対する応答として、前記モジュールによって、前記アプリケーションに前記疑似インターネットプロトコル（ＩＰ）アドレスを返信することは、前記実ＩＰアドレスに用いられたＴＴＬ値よりも大きな値に設定されたタイムトゥーリブ（ＴＴＬ）属性を有する疑似ＩＰアドレスを返信することを含む、請求項３に記載の方法。
5. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、前記方法は、
   前記モジュールによって、前記第１のアプリケーション、及び前記コンピューティング装置上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
   前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
   前記コンピューティング装置によって、前記第２のドメイン名を解決するためのリクエストを、前記コンピューティング装置から前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
   前記コンピューティング装置によって、前記第２のドメイン名を解決するための前記リクエストに対する応答を受信することと、
   前記コンピューティング装置によって、前記第２のドメイン名を解決するための前記リクエストに対する前記応答を、前記アプリケーションに返信することと
   を更に含む、請求項１に記載の方法。
6. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、疑似ＩＰアドレスは第１の疑似ＩＰアドレスであり、前記方法は、
   前記モジュールによって、前記第１のアプリケーション、及び前記コンピューティング装置上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
   前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
   前記第２のドメイン名に適用される前記ドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することに応答して、
   第２の疑似ＩＰアドレスを、前記第１のアプリケーション及び前記第２のアプリケーションの内の前記１つに返信することと、
   前記モジュールによって、前記第２のドメイン名を解決するためのリクエストを、前記コンピューティング装置から前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
   前記モジュールによって、前記第２のドメイン名を解決するための前記リクエストに対する応答であって、前記第２のドメイン名に対応する実ＩＰアドレスを含む前記応答を受信することと、
   前記モジュールによって、前記実ＩＰアドレスを前記第２の疑似ＩＰアドレスにマッピングすることと
   を更に含む、請求項１に記載の方法。
7. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、疑似ＩＰアドレスは第１の疑似ＩＰアドレスであり、前記方法は、
   前記モジュールによって、前記第１のアプリケーション、及び前記コンピューティング装置上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
   前記モジュールによって、前記アプリケーションに、前記第２のドメイン解決リクエストに対する応答として第２の疑似ＩＰアドレスを返信することと、
   前記モジュールによって、前記第２の疑似ＩＰアドレスを前記第２のドメイン名にマッピングするエントリを格納場所中に格納することと、前記モジュールによって、前記第１のアプリケーション及び前記第２のアプリケーションの内の前記１つから、前記第２の疑似ＩＰアドレスを含むコンテンツリクエストを傍受することと、
   前記格納場所から、前記第２の疑似ＩＰアドレスに対応する前記第２のドメイン名を取得することと、
   前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
   前記モジュールによって、前記第２のドメイン名を解決するためのリクエストを、前記コンピューティング装置から前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
   前記モジュールによって、前記第２のドメイン名を解決するための前記リクエストに対する応答であって、前記第２のドメイン名に対応する実ＩＰアドレスを含む前記応答を受信することと、
   前記実ＩＰアドレスを含む修正済みリクエストを生成することと、
   前記第１の外部サーバ及び異なる外部サーバの内の１つに、前記修正済みリクエストを送信することと
   を更に含む、請求項１に記載の方法。
8. 疑似ＩＰアドレスを前記ドメイン名にマッピングする前記エントリは、実ＩＰアドレスよりも少ないビット数を含む、請求項１に記載の方法。
9. 前記ドメイン解決リクエストはハイパーテキストトランスファープロトコル（ＨＴＴＰ）リクエストであり、前記方法は、前記ＨＴＴＰリクエストのＨＯＳＴヘッダから前記ドメイン名を抽出することを更に含む、請求項１に記載の方法。
10. 前記ドメイン解決リクエストはトランスミッションコントロールプロトコル（ＴＣＰ）リクエストであり、前記方法は、前記ＴＣＰリクエストのＣＯＮＮＥＣＴヘッダから前記ドメイン名を抽出することを更に含む、請求項１に記載の方法。
11. １つ以上のプロセッサと、前記１つ以上のプロセッサに動作可能に結合された１つ以上の記憶装置とを含むシステムであって、
    前記システム上で実行するモジュールによって、前記システムにより実行されるアプリケーションから、ドメイン名を含むドメイン解決リクエストであって、第１の外部サーバにアドレス指定された前記ドメイン解決リクエストを傍受することと、
    前記モジュールによって、前記ドメイン解決リクエストの前記外部サーバへの送信を抑制することと、
    前記モジュールによって、前記アプリケーションに、前記ドメイン解決リクエストに対する応答として疑似インターネットプロトコル（ＩＰ）アドレスを返信することと、
    前記モジュールによって、前記疑似ＩＰアドレスを前記ドメイン解決リクエストの前記ドメイン名にマッピングするエントリを格納することと
    を前記１つ以上のプロセッサにさせるのに有効な実行可能で動作可能なデータを前記１つ以上の記憶装置が含む、システム。
12. 前記実行可能で動作可能なデータは、
    前記モジュールによって、前記アプリケーションから、前記疑似ＩＰアドレスを含むコンテンツリクエストを傍受することと、
    前記モジュールによって前記アプリケーションから前記疑似ＩＰアドレスを含む前記コンテンツリクエストを傍受することに応答して、前記エントリ中の前記疑似ＩＰアドレスにマッピングされた前記ドメイン名を含む修正済みコンテンツリクエストを生成することと、
    前記修正済みコンテンツリクエストを、前記第１の外部サーバ及び異なる外部サーバの内の１つに送信することと
    を前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１に記載のシステム。
13. 前記第１の外部サーバ及び前記異なる外部サーバの内の１つであって、
    前記修正済みコンテンツリクエストを受信することと、
    前記ドメイン名に対応する実ＩＰアドレスを取得することと、
    前記修正済みコンテンツリクエストに従って前記実ＩＰアドレスからコンテンツをリクエストすることと、
    前記修正済みコンテンツリクエストに従って前記コンテンツを受信することと、
    前記修正済みコンテンツリクエストに従って前記コンテンツを前記コンピューティング装置に送信することと
    をするようにプログラムされた、前記第１の外部サーバ及び前記異なる外部サーバの内の前記１つを更に含む、請求項１２に記載のシステム。
14. 前記モジュールによって、前記アプリケーションに、前記ドメイン解決リクエストに対する応答として前記疑似インターネットプロトコル（ＩＰ）アドレスを返信することは、前記実ＩＰアドレスに用いられたＴＴＬ値よりも大きな値に設定されたタイムトゥーリブ（ＴＴＬ）属性を有する疑似ＩＰアドレスを返信することを含むことを前記１つ以上のプロセッサにさせるのに前記実行可能で動作可能なデータは更に有効である、請求項１３に記載のシステム。
15. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、前記実行可能で動作可能なデータは、
    前記モジュールによって、前記第１のアプリケーション、及び前記システム上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
    前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
    前記第２のドメイン名を解決するためのリクエストを、前記システムから前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
    前記第２のドメイン名を解決するための前記リクエストに対する応答を受信することと、
    前記第２のドメイン名を解決するための前記リクエストに対する前記応答を、前記アプリケーションに返信することと
    を前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１に記載のシステム。
16. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、疑似ＩＰアドレスは第１の疑似ＩＰアドレスであり、前記実行可能で動作可能なデータは、
    前記モジュールによって、前記第１のアプリケーション、及び前記システム上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
    前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
    前記第２のドメイン名に適用される前記ドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判断することに応答して、
    第２の疑似ＩＰアドレスを、前記第１のアプリケーション及び前記第２のアプリケーションの内の前記１つに返信することと、
    前記モジュールによって、前記第２のドメイン名を解決するためのリクエストを、前記システムから前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
    前記モジュールによって、前記第２のドメイン名を解決するための前記リクエストに対する応答であって、前記第２のドメイン名に対応する実ＩＰアドレスを含む前記応答を受信することと、
    前記モジュールによって、前記実ＩＰアドレスを前記第２の疑似ＩＰアドレスにマッピングすることと
    を前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１のシステム。
17. 前記アプリケーションは第１のアプリケーションであり、前記ドメイン解決リクエストは第１のドメイン解決リクエストであり、前記ドメイン名は第１のドメイン名であり、疑似ＩＰアドレスは第１の疑似ＩＰアドレスであり、前記実行可能で動作可能なデータは、
    前記モジュールによって、前記第１のアプリケーション、及び前記コンピューティング装置上で実行する第２のアプリケーションの内の１つから、第２のドメイン名を含む第２のドメイン解決リクエストを傍受することと、
    前記モジュールによって、前記アプリケーションに、前記第２のドメイン解決リクエストに対する応答として第２の疑似インターネットプロトコル（ＩＰ）アドレスを返信することと、
    前記モジュールによって、前記第２の疑似ＩＰアドレスを前記第２のドメイン名にマッピングするエントリを格納することと、
    前記モジュールによって、前記第１のアプリケーション及び前記第２のアプリケーションの内の前記１つから、前記第２の疑似ＩＰアドレスを含むコンテンツリクエストを傍受することと、
    前記ストレージから、前記第２の疑似ＩＰアドレスに対応する前記第２のドメイン名を取得することと、
    前記モジュールよって、前記第２のドメイン名に適用されるドメイン名規則に従って、前記第２のドメイン名リクエストは抑制されるべきでないと判定することと、
    前記モジュールによって、前記第２のドメイン名を解決するためのリクエストを、前記コンピューティング装置から前記第１の外部サーバ及び第２の外部サーバの内の１つに送信することと、
    前記モジュールによって、前記第２のドメイン名を解決するための前記リクエストに対する応答であって、前記第２のドメイン名に対応する実ＩＰアドレスを含む前記応答を受信することと、
    前記モジュールによって前記第１のアプリケーション及び前記第２のアプリケーションの内の前記１つから前記第２のドメイン名を含む前記コンテンツリクエストを傍受することに応答して、前記第２の疑似ＩＰアドレスにマッピングされた前記実ＩＰアドレスを含む修正済みコンテンツリクエストを生成することと、
    前記第１の外部サーバ及び異なる外部サーバの内の１つに、前記修正済みリクエストを送信することと
    を前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１に記載のシステム。
18. 前記疑似ＩＰアドレスを前記ドメイン名にマッピングする前記エントリは、前記実ＩＰアドレスよりも少ないビット数を含む、請求項１７に記載のシステム。
19. 前記ドメイン解決リクエストはハイパーテキストトランスファープロトコル（ＨＴＴＰ）リクエストであり、前記実行可能で動作可能なデータは、前記ＨＴＴＰリクエストのＨＯＳＴヘッダから前記ドメイン名を抽出することを前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１に記載のシステム。
20. 前記ドメイン解決リクエストはトランスミッションコントロールプロトコル（ＴＣＰ）リクエストであり、前記実行可能で動作可能なデータは、前記ＴＣＰリクエストのＣＯＮＮＥＣＴヘッダから前記ドメイン名を抽出することを前記１つ以上のプロセッサにさせるのに更に有効である、請求項１１に記載のシステム。
21. 仮想プライベートネットワーク（ＶＰＮ）接続を管理するための方法であって、
    ＶＰＮサーバコンピュータによって、コンピューティング装置から、カプセル化された第１のトラフィックを受信することと、
    前記ＶＰＮサーバコンピュータによって、第１のトラフィックを取得するために、カプセル化された前記第１のトラフィックをデカプセル化するために
    前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の第１のインターネットプロトコル（ＩＰ）アドレスを第２のインターネットプロトコルアドレスに置き換えることと、
    前記ＶＰＮサーバコンピュータによって、前記第１のトラフィックを前記第２のＩＰアドレスに送信すること
    を含む、方法。
22. 前記第１のＩＰアドレスはルーティング不可ＩＰアドレスであり、前記第２のＩＰアドレスはルーティング可能ＩＰアドレスである、請求項２１に記載の方法。
23. 前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることは、
    カプセル化された前記第１のトラフィックに対して、前記第１のＩＰアドレスに対応するドメイン名を識別することと、
    前記第２のＩＰアドレスを取得するために前記ドメイン名を解決することと
    を更に含む、請求項２２に記載の方法。
24. 前記ドメイン名を前記第２のＩＰアドレスに解決することは、前記ＶＰＮサーバコンピュータによって、前記ドメイン名を含むドメインネームサービス（ＤＮＳ）リクエストをＤＮＳサーバに発行することと、前記ＤＮＳサーバから前記第２のＩＰアドレスと共に応答を受信することとを含む、請求項２３に記載の方法。
25. 前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の前記第１のインターネットプロトコル（ＩＰ）アドレスを前記第２のインターネットプロトコルアドレスに置き換えることは、
    前記ＶＰＮサーバコンピュータによって、カプセル化された前記第１のトラフィック中でポインタを識別することと、
    前記ＶＰＮサーバコンピュータによって、前記ポインタにより参照されるテキスト列を検索することと、
    前記第２のＩＰアドレスを取得するために前記テキスト列を解決することと
    を更に含む請求項２２に記載の方法。
26. 前記コンピューティング装置上で実行するモジュールによって、前記コンピューティング装置上で実行するアプリケーションから、ドメイン名を含むドメイン解決リクエストであって、第１の外部サーバにアドレス指定された前記ドメイン解決リクエストを傍受することと、
    前記モジュールによって、前記ドメイン解決リクエストの前記外部サーバへの送信を抑制することと、
    前記モジュールによって、前記アプリケーションに、前記ドメイン解決リクエストに対する応答として前記ルーティング不可ＩＰアドレスを返信することと
    を更に含む、請求項２２に記載の方法。
27. 前記モジュールによって、前記アプリケーションから、前記ＶＰＮサーバにアドレスしてされたＶＰＮ通信であって、前記ルーティング不可ＩＰアドレスを含む前記ＶＰＮ通信を傍受することと、
    前記モジュールによって前記アプリケーションから前記ＶＰＮサーバにアドレス指定された前記ＶＰＮ通信を傍受することに応答して、前記モジュールによって、前記ドメイン名及び前記ルーティング不可ＩＰアドレスの両方を宛先アドレスフィールド中に含む修正済みＶＰＮ通信を生成することと、
    前記モジュールによって、カプセル化された前記第１のトラフィックを生成するために前記修正済みＶＰＮ通信をカプセル化することと、
    前記モジュールによって、前記修正済みコンテンツリクエストを前記ＶＰＮサーバに送信することと、
    を更に含む、請求項２６に記載の方法。
28. 前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることは、
    前記ＶＰＮサーバによって、前記第１のＩＰアドレスをドメイン名にマッピングすることと、
    前記ドメイン名を前記第２のＩＰアドレスであって、前記第１のＩＰアドレスに対応する第１のコンテンツサーバよりも前記ＶＰＮに近い第２のコンテンツサーバに対応する前記第２のＩＰアドレスに解決することと
    を更に含む、請求項２１に記載の方法。
29. 前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることは、
    前記ＶＰＮサーバによって、前記第１のＩＰアドレスは、前記ＶＰＮサーバから閾値距離を超える第１のコンテンツサーバに対応すると判定することと、
    前記ＶＰＮサーバによって前記第１のＩＰアドレスは前記ＶＰＮサーバから閾値距離を超える前記第１のコンテンツサーバに対応すると判定することに応答して、
    前記ＶＰＮサーバによって、前記第１のＩＰアドレスをドメイン名にマッピングすることと、
    前記ドメイン名を前記第２のＩＰアドレスであって、前記第１のコンテンツサーバよりも前記ＶＰＮサーバに近い第２のコンテンツサーバに対応する前記第２のＩＰアドレスに解決することと、
    を更に含む、請求項２１に記載の方法。
30. 前記ＶＰＮサーバコンピュータによって、前記第１のトラフィック中の前記第１のインターネットプロトコル（ＩＰ）アドレスを第２のＩＰアドレスに置き換えることは、カプセル化された前記第１のトラフィックのＶＰＮトンネル内で行われる、請求項２１に記載の方法。
31. 仮想プライベートネットワーク（ＶＰＮ）接続を管理するためのシステムであって、１つ以上のプロセッサと、前記１つ以上のプロセッサに動作可能に結合された１つ以上の記憶装置を含む前記システムであって、
    コンピューティング装置から、カプセル化された第１のトラフィックを受信することと、
    第１のトラフィックを取得するために、カプセル化された前記第１のトラフィックをデカプセル化することと
    前記第１のトラフィック中の第１のインターネットプロトコル（ＩＰ）アドレスを第２のインターネットプロトコルアドレスに置き換えることと、
    前記第１のトラフィックを前記第２のＩＰアドレスに送信することと
    を前記１つ以上のプロセッサにさせるのに有効な実行可能で動作可能なデータを前記１つ以上の記憶装置が含む、システム。
32. 前記第１のＩＰアドレスはルーティング不可ＩＰアドレスであり、前記第２のＩＰアドレスはルーティング可能ＩＰアドレスである、請求項３１に記載のシステム。
33. 前記実行可能で動作可能なデータは、
    カプセル化された前記第１のトラフィック中でドメイン名を識別することと、
    第２のＩＰアドレスを取得するために前記ドメインを解決することと
    によって、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることを前記１つ以上のプロセッサにさせるのに有効である、請求項３２に記載の方法。
34. 前記実行可能で動作可能なデータは、前記ドメイン名を含むドメインネームサービス（ＤＮＳ）リクエストをＤＮＳサーバに発行することと、前記ＤＮＳサーバから前記第２のＩＰアドレスと共に応答を受信することによって、前記ドメイン名を前記第２のＩＰアドレスに解決することを前記１つ以上のプロセッサにさせるのに有効である、請求項３３に記載の方法。
35. 前記実行可能で動作可能なデータは、
    前記ＶＰＮサーバコンピュータによって、カプセル化された前記第１のトラフィック中でポインタを識別することと、
    前記ＶＰＮサーバコンピュータによって、前記ポインタにより参照されるテキスト列を検索することと、
    前記第２のＩＰアドレスを取得するために前記テキスト列を解決することと
    によって、前記第１のトラフィック中の前記第１のインターネットプロトコル（ＩＰ）アドレスを前記第２のインターネットプロトコルアドレスに置き換えることを前記１つ以上のプロセッサにさせるのに有効である、請求項３２に記載の方法。
36. 前記コンピューティング装置を更に含み、コンピューティング装置は、
    前記コンピューティング装置上で実行するモジュールによって、前記コンピューティング装置上でするアプリケーションから、ドメイン名を含むドメイン解決リクエストであって、第１の外部サーバにアドレス指定された前記ドメイン解決リクエストを傍受することと、
    前記モジュールによって、前記ドメイン解決リクエストの前記外部サーバへの送信を抑制することと、
    前記モジュールによって、前記アプリケーションに、前記ドメイン解決リクエストに対する応答として前記ルーティング不可ＩＰアドレスを返信することと
    をするようにプログラムされる、請求項３２に記載のシステム。
37. 前記コンピューティング装置は、
    前記モジュールによって、前記アプリケーションから、前記ＶＰＮサーバにアドレス指定されたＶＰＮ通信であって、前記ルーティング不可ＩＰアドレスを含む前記ＶＰＮ通信を傍受することと、
    前記モジュールによって前記アプリケーションから前記ＶＰＮサーバにアドレス指定された前記ＶＰＮ通信を傍受することに応答して、前記モジュールによって、前記ドメイン名及び前記ルーティング不可ＩＰアドレスの両方を宛先アドレスフィールド中に含む修正済みＶＰＮ通信を生成することと、
    前記モジュールによって、カプセル化された前記第１のトラフィックを生成するために、前記修正済みＶＰＮ通信をカプセル化することと、
    前記モジュールによって、前記修正済みコンテンツリクエストを前記ＶＰＮサーバに送信することと
    をするように更にプログラムされる、請求項３６に記載のシステム。
38. 前記実行可能で動作可能なデータは、
    前記ＶＰＮサーバによって、前記第１のＩＰアドレスをドメイン名にマッピングすることと、
    前記ドメイン名を前記第２のＩＰアドレスであって、前記第１のＩＰアドレスに対応する第１のコンテンツサーバよりも前記コンピューティング装置に近い第２のコンテンツサーバに対応する前記第２のＩＰアドレスに解決することと
    によって、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることを前記１つ以上のプロセッサにさせるのに更に有効である、請求項３１に記載のシステム。
39. 前記実行可能で動作可能なデータは、
    前記第１のＩＰアドレスによってアドレス指定された第１のコンテンツサーバの位置を判定することと、
    前記第１のコンテンツサーバの位置が前記システムから閾値距離を超える場合に、
    前記第１のＩＰアドレスをドメイン名にマッピングすることと、
    前記ドメイン名を前記第２のＩＰアドレスであって、前記第１のコンテンツサーバよりも前記コンピューティング装置に近い第２のコンテンツサーバをアドレス指定する前記第２のＩＰアドレスに解決することと
    を前記１つ以上のプロセッサにさせるのに更に有効である、請求項３１に記載のシステム。
40. 前記実行可能で動作可能なデータは、カプセル化された前記第１のトラフィックのＶＰＮトンネル内において、前記第１のトラフィック中の前記第１のＩＰアドレスを前記第２のＩＰアドレスに置き換えることを前記１つ以上のプロセッサにさせるのに更に有効である、請求項３１に記載の方法。
41. ドメイン解決の抑制のための方法であって、
    コンピューティング装置上で実行するアプリケーションから、前記コンピューティング装置上で実行するモジュールによって、疑似ＩＰアドレスを含むコンテンツリクエストを傍受することと、
    前記モジュールによって前記アプリケーションから前記疑似ＩＰアドレスを含む前記コンテンツリクエストを傍受することに応答して、第１のデータテーブルのエントリ中の前記疑似ＩＰアドレスにマッピングされたドメイン名を含む修正済みコンテンツリクエストを生成することと、
    前記コンピューティング装置によって、前記修正済みコンテンツリクエストを第１のサーバに送信することと、
    前記コンピューティング装置によって、前記修正済みコンテンツリクエストに対する応答であって、前記ドメイン名に対応するルーティング可能ＩＰアドレスを含む前記応答を受信することと、
    前記コンピューティング装置によって、前記ＩＰアドレス及びドメイン名を第２のデータテーブル中に格納することと
    を含む、方法。
42. 前記コンピューティング装置によって、前記アプリケーションからの第２のコンテンツであって、前記ドメイン名を含む前記第２のコンテンツリクエストを検出することと、
    前記アプリケーションからの前記第２のコンテンツリクエストであって、前記ドメイン名を含む前記第２のコンテンツリクエストを検出することに応じて、前記コンピューティング装置によって、前記第２のデータテーブルから前記ルーティング可能ＩＰアドレスを検索することと、
    前記コンピューティング装置によって、前記ルーティング可能ＩＰアドレスを含む前記第２のコンテンツリクエストを、前記第１のサーバ、及び前記ルーティング可能ＩＰアドレスでアドレスされる第２のサーバの内の１つに送信すること、
    を更に含む、請求項４１に記載の方法。
43. 前記コンピューティング装置によって、前記ルーティング可能アドレスでアドレス指定された前記第２のサーバに前記第２のコンテンツリクエストを第１のサーバをバイパスすることにより送信することを含む、請求項４１に記載の方法。
44. 前記モジュールによって、前記アプリケーションから、前記ドメイン名を含むドメイン解決リクエストであって、前記第１のサーバ及び第３のサーバの内の１つにアドレス指定された前記ドメイン解決リクエストを傍受することと、
    前記モジュールによって、前記ドメイン解決リクエストの送信を抑制することと、
    前記モジュールによって、前記アプリケーションに、前記ドメイン解決リクエストに対する応答として疑似ＩＰアドレスを返信することと、
    前記モジュールによって、疑似ＩＰアドレスを前記ドメイン解決リクエストの前記ドメイン名にマッピングする前記エントリを前記第１データテーブル中に格納することと
    を更に含む、請求項４１に記載の方法。
45. 前記モジュールによって前記アプリケーションに前記ドメイン解決リクエストに対する応答として前記疑似インターネットプロトコル（ＩＰ）アドレスを返信することは、前記実ＩＰアドレスに用いられたＴＴＬ値よりも大きな値に設定されたタイムトゥーリブ（ＴＴＬ）属性を有する疑似ＩＰアドレスを返信することを含む、請求項４４に記載の方法。
46. ドメイン解決の抑制のための方法であって、
    第１のサーバによって、クライアント装置からドメイン名を含むコンテンツリクエストを受信することと、
    前記第１のサーバによって、前記ドメイン名をルーティング可能インターネットプロトコル（ＩＰ）アドレスに解決することと、
    前記第１のサーバによって、前記コンテンツリクエストにより参照されるコンテンツを、前記ルーティング可能ＩＰアドレスに対応するリモートサーバから検索することと、
    前記第１のサーバによって、前記クライアント装置に、前記コンテンツリクエストにより参照される前記コンテンツと前記ルーティング可能ＩＰアドレスとを送信することと
    を含む、方法。
47. 前記ドメイン名をルーティング可能ＩＰアドレスに解決することは、ドメインネームサービス（ＤＮＳ）リクエストを発行することと、前記ＩＰアドレスを含む前記ＤＮＳリクエストに対する応答を受信することとを含む、請求項４６に記載の方法。
48. 前記ドメイン名をルーティング可能ＩＰアドレスに解決することは、前記ドメイン名を前記ルーティングＩＰアドレスにマッピングするデータベースから、前記ルーティング可能ＩＰアドレスを検索することを含む、請求項４６に記載の方法。
49. 前記コンテンツリクエストにより参照される前記コンテンツと関連付けられた１つ以上の追加のドメイン名を識別することと、
    前記追加のドメイン名に対するルーティング可能ＩＰアドレスを検索することと、
    前記追加のドメイン名に対する前記ルーティング可能ＩＰアドレスを、前記コンテンツリクエストにより参照される前記コンテンツと共に返信することと
    を更に含む、請求項４６に記載の方法。
50. 前記追加のドメイン名は、前記コンテンツリクエストにより参照される前記コンテンツにリンクされたドメイン名である、請求項４６に記載の方法。
51. 前記クライアント装置上で実行するアプリケーションから、前記クライアント装置上で実行するモジュールによって、疑似ＩＰアドレスを含む元のコンテンツリクエストを傍受することと、
    前記モジュールによって前記アプリケーションから前記疑似ＩＰアドレスを含む前記元のコンテンツリクエストを傍受することに応答して、第１のデータテーブルのエントリ中の前記疑似ＩＰアドレスにマッピングされたドメイン名を含む前記コンテンツリクエストを生成することと、
    前記コンピューティング装置によって、前記コンテンツリクエストを前記第１のサーバに送信することと、
    前記コンピューティング装置によって、前記コンテンツリクエストにより参照される前記コンテンツと前記ルーティング可能ＩＰアドレスとを受信することと、
    前記コンピューティング装置によって、前記ＩＰアドレス及びドメイン名を、第２のデータテーブル中に格納することと
    を更に含む、請求項４６に記載の方法。
52. 前記クライアント装置によって、前記アプリケーションからの第２のコンテンツリクエストであって、前記ドメイン名を含む前記第２のコンテンツリクエストを検出することと、
    前記アプリケーションからの第２のコンテンツリクエストであって、前記ドメイン名を含む前記第２のコンテンツリクエストを検出することに応答して、前記クライアント装置によって、前記第２のデータテーブルから前記ルーティング可能ＩＰアドレスを検索することと、
    前記クライアント装置によって、前記ルーティング可能ＩＰアドレスを含む前記第２のコンテンツリクエストを、前記第１のサーバ、及び前記ルーティング可能ＩＰアドレスに対応する第２のサーバの内の１つに送信することと
    を更に含む、請求項４６に記載の方法。
53. ドメイン解決の抑制のための方法であって、
    第１のサーバによって、クライアント装置から、ルーティング可能ＩＰアドレス及びドメイン名の内の１つを含むコンテンツリクエストを受信することと、
    前記第１のサーバによって、前記コンテンツリクエストにより参照されるコンテンツを、前記ルーティング可能ＩＰアドレス及び前記ドメイン名の内の前記１つに対応するリモートサーバから検索することと、
    前記第１のサーバによって、前記コンテンツリクエストと関連付けられた１つ以上の関連ドメイン名を識別することと、
    前記第１のサーバによって、前記１つ以上の関連ドメイン名を１つ以上の関連ＩＰアドレスに解決することと、
    前記第１のサーバによって、前記クライアント装置に、前記コンテンツリクエストにより参照される前記コンテンツと、前記１つ以上の関連ドメイン名にマッピングされた前記１つ以上の関連ＩＰアドレスとを返信することと
    含む、方法。
54. 前記コンテンツリクエストは、前記ルーティング可能ＩＰアドレスを含む、請求項５３に記載の方法。
55. 前記コンテンツリクエストは前記ドメイン名を含み、
    前記第１のサーバによって、前記コンテンツリクエストにより参照される前記コンテンツを、前記ルーティング可能ＩＰアドレスと前記ドメイン名の内の前記１つに対応する前記リモートサーバから検索することは、前記ドメイン名を対応するＩＰアドレスに解決することと、前記コンテンツリクエストを対応する前記ＩＰアドレスに送信することとを含む、
    請求項５３に記載の方法。
56. 前記コンテンツリクエストにより参照される前記コンテンツはウェブページであり、前記１つ以上の関連ドメイン名は、前記ウェブページにリンクされたドメイン名である、請求項５３に記載の方法。
57. 前記クライアント装置によって、前記１つ以上の関連ＩＰアドレスにマッピングされた前記関連ＩＰアドレスを格納することと、
    前記クライアント装置によって、前記アプリケーションからの第２のコンテンツリクエストであって、前記１つ以上の関連ドメイン名の内の１つを含む前記第２のコンテンツリクエストを検出することと、
    前記アプリケーションからの第２のコンテンツリクエストであって、前記１つ以上の関連ドメイン名の内の１つを含む前記第２のコンテンツリクエストを検出することに応答して、前記クライアント装置によって、前記１つ以上のドメイン名の内の前記１つに対応する前記ルーティング可能ＩＰアドレスを検索することと、
    前記クライアント装置によって、前記第１のサーバ及び第２のサーバの内の１つに、前記１つ以上のドメイン名の内の前記１つに対応する前記ルーティング可能ＩＰアドレスを含む前記第２のコンテンツリクエストを送信すること
    を更に含む、請求項５３に記載の方法。
58. 前記クライアント装置によって、前記１つ以上のドメイン名の内の前記１つに対応する前記ルーティング可能ＩＰアドレスによりアドレスされた前記第２のサーバの１つに前記第１のサーバをバイパスすることにより送信することを更に含む、請求項５７に記載の方法。