コネクションオリエンテッドトランザクションにおけるＵＲＬオブジェクトのインテリジェントな需要に基づく認識
【課題】トランザクションの一貫性を維持しながらフローの負荷バランスを知能的に遂行することができる網交換機を提供する。
【解決手段】特定のコンテントがホットであることを決定し、フローを一つ或いは複数のキャッシュサーバに向ける網交換機に係り、キャッシュとダイジェスト発生器を備え、このキャッシュ内にはダイジェスト発生器によって生成されたダイジェストに基づいて所定のオブジェクトが格納される。
【解決手段】特定のコンテントがホットであることを決定し、フローを一つ或いは複数のキャッシュサーバに向ける網交換機に係り、キャッシュとダイジェスト発生器を備え、このキャッシュ内にはダイジェスト発生器によって生成されたダイジェストに基づいて所定のオブジェクトが格納される。
【発明の詳細な説明】
【技術分野】
【０００１】
関連する特許出願
本出願は、２０００年８月４日付けで、Ｃｈｕ，Ｊａｓｗａ，及びＣｈａｇａｎｔｙらに付与された同名の合衆国仮特許出願Ｎｏ．６０／２２３，０８７の合衆国特許法（３５Ｕ．Ｓ．Ｃ§１１９（ｅ））の下での利益を主張する。本発明は、更に、両者とも本出願と同一の発明人により本出願と同時に出願された「Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｓｅｒｖｅｒ Ｆａｒｍ Ｗｉｔｈ Ｔａｇｇｉｎｇ ａｎｄ Ｐｉｐｅｌｉｎｉｎｇ」及び「Ｎｏｎ−Ｉｎｔｒｕｓｉｖｅ Ｍｕｌｔｉｐｌｅｘｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｐｅｒｓｉｓｔｅｎｃｙ ｉｎ Ｓｅｃｕｒｅ Ｃｏｍｍｅｒｃｅ Ｅｎｖｉｒｏｎｍｅｎｔｓ」なる名称の合衆国特許出願にも係る。
【０００２】
発明の技術分野
本発明は一般的には、負荷のバランス、網交換機、より詳細には、トランザクション一貫性（ｔｒａｎｓａｃｔｉｏｎ ｃｏｈｅｒｅｎｃｙ）を維持しながらフローの負荷バランスを知能的に遂行することができる網交換機に関する。
【０００３】
発明の背景
ビジネスはますます多くをコンピュータ及びネットワークに依存するようになりつつある。ウェブ技術は様々なアプリケーションに対するユーザに優しいフロントエンドを提供することで電子商取引（Ｅ−Ｃｏｍｍｅｒｃｅ）展開の推進力となっている。クライアント／サーバアプリケーションの成功には、ホストされるサービスへの連続（持続）的なアクセスとこれらからの即座の応答が必須である。長いダウン時間や遅い及び／或いは誤った応答は、顧客の不満を招き、商売の機会を逃しかねない。このため、利便性（ａｖａｉｌａｂｉｌｉｔｙ）が高く、性能の優れたサーバに対する要請はますます高まっている。
【０００４】
（ウェブサイト用途において遭遇される時間に依存する大きな需要の変動の観点から）サーバに要求されるレベルの利便性、性能、及びスケーラビリティを達成するためには、典型的には一つ或いは複数のインテリジェントインタネットプロトコル（ＩＰ）交換機を備えるサーバのファーム（ｆａｒｍ）、すなわちサーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）が採用される。ＩＰ交換機は、複数のサーバ間のインタネットプロトコル（ＩＰ）トラフィックの負荷バランシングを、ＯＳＩネットワークモデルの一つ或いは複数の層（つまり、層７すなわちアプリケーション層、層６すなわちプレゼェンテーション層、層５すなわちセッション層、層４すなわちトランスポート層、層３すなわちネットワーク層、層２すなわちデータリンク層、及び層１すなわち物理層）内に含まれる情報に基づいて遂行する。サーバのグループは典型的には単一のグローバルＩＰアドレスによって識別される。このグローバルＩＰアドレスに向けられたトラフィックは、ソースＩＰアドレスを有するこれらサーバの作業負荷と選択されたサーバのアドレス類似性に基づいて、そのグループ内のサーバ間で負荷バランスされる。これらサーバにアクセスする全てのクライアントは、グローバルＩＰアドレスのみを調べ、そのファーム内の複数の複製サーバについて及びそれらのトラフィックがどの特定のサーバに転送されているかは特に意識しない。
【０００５】
現在様々な異なるタイプのＩＰ交換機が用いられている。
層３及び／或いは層４交換機を含むあるタイプの交換機は、入りパケットを宛先ＩＰアドレス、或いはＩＰアドレス、プロトコルＩＤ及びトランスポートポート番号の組合せに基づいてルーティングする。このスイッチング技法はウェブ環境においては問題をはらむ。層４の負荷バランサにとっては、全てのウェブアプリケーションはＴＣＰポート８０（ＨＴＴＰに対する典型的なポート）を使用しているように見え、これらを互いに区別することはできない。このため、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）リクエストと、Ｗｅｂ−ｅｎａｂｌｅｄ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＳＡＰ）アプリケーション或いはストリーミングオーディオ（ｓｔｒｅａｍｉｎｇ ａｕｄｉｏ）リクエストとを、これらリクエストは全て非常に異なるＱｏＳ要件を有するのにもかかわらず、区別することができない。
【０００６】
もう一つのタイプのＩＰ交換機は、ウェブ交換機として知られており、これは、ウェブトラフィックの特有な要件に対処できるように特別に設計された新世代のネトワーク技術である。ウェブ交換機は、高度なユニバーサルリソースロケータ（ＵＲＬ）負荷バランス能力、Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）、及び埋め込まれたＤｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ（ＤＮＳ）知能を備える「スマート（ｓｍａｒｔ）」交換機であり、複雑な方針（ｐｏｌｉｃｉｅｓ）を用いてウェブトラフィックフローの管理及び高速化を図る。ウェブ交換機は、ウェブトラフィックを最適化するために、ＨＴＴＰペイロードを解析し、ＵＲＬとクッキーを調べることで、どのようなコンテントがリクエストされているかを決定する。ここで用いられる「クッキー（ｃｏｏｋｉｅ）」なる語句は、サーバのリクエストに答えて、クライアント或いはピア（ｐｅｅｒ）上に格納される情報を指す。クッキーは、典型的には、そのクッキーがそれに対して有効なＵＲＬのパスレンジ（ｐａｔｈ ｒａｎｇｅ）の記述から成り、サーバ応答に付加或いはタグ付けされる。クッキー内の情報は、勿論、サーバによって定義される。後に説明するように、ＵＲＬは、リクエストされたコンテントを識別するのみで、そのコンテントがどこで見つられるかは示さない。リクエストされたコンテントに関する知識に元に、ウェブ交換機は、ユーザにて定義された及び／或いは事前に設定された方針を用いて、特定のコンテント或いはユーザに対して、どのようなフローセキュリティ規則が施行されるべきか、どのようなコンテントが許容され、どのようなコンテントが拒絶されるべきか、及びどのようなＱｏＳ要件が必要とされるかを決定する。こうすることで、トラフィック優先付けに関する方針の定義における柔軟性が得られ、階層サービス（ｔｉｅｒｅｄ ｓｅｒｖｉｃｅｓ）を実現したり、Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔに合わせたり、電子商取引にとって非常に重要な要件である固着性接続（ｓｔｉｃｋｙ ｃｏｎｎｅｃｔｉｏｎ ）やユーザ認証を活用したりすることが可能となる。
【０００７】
ウェブ交換機は、高度にスケーラブルなマルチプロセッサフレームワークを用い、これは方針をフロー（セッション）の設定時にのみ評価する。フローがいったん設定されると、そのフロー内の、それ以降の全てのパケットは、高速転送回路を介してポートベースにてワイヤ速度（ｗｉｒｅ ｓｐｅｅｄ）にてカットスルー（ｃｕｔ−ｔｈｒｏｕｇｈ）される。「いったんフローを設定し、その後、全ての他のパケットを交換する」アプローチは、ＵＲＬレベルでのトラフィックの複雑な分類を可能にするとともに、ローカルエリア網（ＬＡＮ）交換機のコスト性能を向上させる。
【０００８】
ウェブ交換機は、ある瞬間においてどのウェブサーバ或いはキャッシュが特定のリクエストを最も良く扱うことができるかを、そのユーザからサーバまでの近接性（距離）、サーバの状態、網パスの状態、及びどのようなコンテントがリクエストされたか等の基準に基づいて決定する。ウェブ交換機は、あるウェブサイトに向かう全てのトラフィックを傍受する。こうすることで、ウェブ交換機は、コンテントリクエストを追跡し、ホットコンテント（ｈｏｔ ｃｏｎｔｅｎｔ）を予測し、サーバの負担を軽減することが可能になる。ウェブ交換機は、動的にホットコンテントをウェブキャッシュ内に複製し、キャッシュをかわるがわる用いて負荷をバランスされることで、ウェブサイトトラフィックが大きく変動した場合でも、ユーザが途切れのないサービスを受けられるようにする。ウェブ交換機は、更に、どのサーバが以前配信されたことのある特定のコンテントを有するかを追跡し、そのコンテントに対する新たなリクエストは、該当するサーバに直接に送るようにし、こうすることでサーバキャッシュの一貫性と性能の向上に寄与する。
【０００９】
ただし、ウェブ交換機は幾つかの問題を有する。例えば、ウェブ交換機も過多な計算資源を必要する、すなわち、計算効率が悪い。
【００１０】
発明の概要
これら及びその他の必要性が本発明のアーキテクチャ及び方法によって解決される。
【００１１】
一つの実施例においては、本発明は通信網とデータサーバファームとの間で結合可能な網フロー交換機を提供する。一つの構成においては、この網フロー交換機は、２，３，及び４層ウェブ交換機として構成され、サーバファームのグローバルＩＰアドレスを自身のアドレスとし、クライアントからの全てのトランザクションリクエストを、サーバファームに代って受信する。「トランザクションリクエスト（ｔｒａｎｓａｃｔｉｏｎ ｒｅｑｕｅｓｔ）」なる語句は、パケットの形式を有するか否かに関係なく、一つ或いは複数のサーバによる仕事或いは仕事の開始をリクエスト指示するあらゆる信号を意味する。より具体的には、ある信号（リクエスト）は、例えば、サーバに対してそのサーバのメモリ内に格納されているリクエストされた情報を供給することや、その信号によって参照或いは供給される情報に基づいて情報を計算することを指令する。この網フロー交換機はルーティングを備え、ルーティング要素は受信されたデータパケットに関して動作し、そのＩＰデータパケット内のソースと宛先に関する不変量を決定する。これら不変量は、それ以降、そのＩＰパケットに対する宛先デバイスを決定するための基礎として用いられる。
【００１２】
一つの構成においては、交換機は、ＵＲＬとコンテントタイプの任意の組合せを調べ、これに基づいてリクエストのルーティングとアクセス優先の設定を行い；これらを解析することでリクエストされたＵＲＬを決定し；そのコンテントを取り出すために最も有効なサーバを決定し；こうして参照カウント（或いはヒットカウンタ）と満了タイマ（或いはタイムスタンプ）を備えるソースサーバのＵＲＬデータベースを構築する。反復されるリクエストは同一サーバに向けられるが、これには一つの実施例においてはキャッシュ可能なサーバ（ｃａｃｈｅａｂｌｅ ｓｅｒｖｅｒ）が用いられる。この交換機は、コンテント参照カウントと満了タイマを用いて、アクセスの頻度と最近性（ｒｅｃｅｎｃｙ）の組み合わせを計算し、これによって「ホット（ｈｏｔ）」コンテントを検出する。これによって頻繁にリクエストされるコンテントが効率的に分別され、網フロー交換機のクラスタ構成間に均等にキャッシングされる。この交換機要素に、一つの実施例においては、オプションとして、サーバ側にキャッシュプロセッサが接続される。このキャッシュプロセッサは、頻繁にリクエストされるデータオブジェクトを格納するためのローカルオブジェクトキャッシュ（ｌｏｃａｌ ｏｂｊｅｃｔ ｃａｃｈｅ）と、このローカルオブジェクトキャッシュによって格納されるオブジェクトのＵＲＬに対応するダイジェストを格納するダイジェストメモリを備える。複数の網フロー交換機がクラスタ化される場合は、分散ダイジェストメモリのコンテントがクラスタ内で共有される。こうして、オブジェクト検索（ｏｂｊｅｃｔ ｌｏｏｋ−ｕｐｓ）がより完全なものとなることに加えて、参照されたオブジェクトを含む可能性のあるローカルオブジェクトキャッシュを識別することも可能となる。
【００１３】
一つの構成においては、キャッシュダイジェストは、キャッシュ内の頻繁にリクエストされるデータオブジェクトのメモリ位置を指すポインタから成る。典型的には、ダイジェストは少なくとも一部はＵＲＬに基づき、１を疎に含むビットベクトルから成る。このベクトルの次元によってキャッシュダイジェストの集合の容量が決まり、これはキャッシュ内のオブジェクトの数にキャッシュダイジェストの次元を乗じた値として設定される。キャッシュダイジェストの次元は、あるＵＲＬダイジェストと関連するハッシュ関数或いはハッシュ成分の数によって決まる。ハッシュ成分のあるキーに対する値は、そのベクトルへの対応するビットのみが１にセットされた索引（インデックス）を表す。全てのキャッシュダイジェストの集合は、全てのキャッシュされたオブジェクトのダイジェストベクトルの論理ＯＲから構成されるビットベクトルから成る。
【００１４】
本発明のアーキテクチャ及び方法は従来の技術と比較して幾つかの長所を有する。
第一に、この交換機は、他のタイプの網交換機と比較して、著しく計算効率が良いことに加えて、メモリを大幅に節約することができる。キャッシュを用いる従来のフロー交換機は、典型的にはその交換機によって処理された信号に対応するオブジェクトのテーブルを維持する。この交換機は、スイッチングの決定を行う度に、そのオブジェクトと関連するポインタを見つけるために、テーブルを上から下まで或いは下から上まで探索する。テーブルのどちら側が最初に探索されるかによって、テーブルの上側或いは下側に位置するオブジェクトはより短い探索時間を要し、テーブルの反対側に位置するオブジェクトはより長い探索時間を要する。各スイッチング決定のために過剰な計算資源が費やされ、このために交換機の容量が制限される。加えて、テーブルを収容するために過剰なメモリ空間が要求され、このため、定期的に、オブジェクトの有効寿命が満了する前に、オブジェクトをフラッシュ（除去）することが必要となる。本発明の方法においては、プロセッサはダイジェスト値から直接に探索されているオブジェクトの位置を知ることができるために、スイッチング決定が行われる度にデーブルを探索する必要はなくなる。
【００１５】
第二に、この交換機は、Ｐｏｒｔ ８０トラフィックリダイレクティング交換機（Ｐｏｒｔ ８０ ｔｒａｆｆｉｃ ｒｅｄｉｒｅｃｔｉｎｇ ｓｗｉｔｃｈｅｓ）と比較して、キャッシュサーバクラスタ（つまり、キャッシュされたページの単一の貯蔵庫として機能する複数のキャッシュサーバの相互接続された網）によって要求されるメモリ及び計算資源を削減でき、同時に、同程度の帯域幅の節約を維持することができる。「キャッシュサーバ（ｃａｃｈｅ ｓｅｒｖｅｒ）」は、オリジンサーバに向けられたトランザクションリクエストに割り込み、これらリクエストに答えて自身のメモリから要求された情報を供給する。ここで、「オリジンサーバ（ｏｒｉｇｉｎ ｓｅｒｖｅｒ）」とは、ある選択されたトランザクションリクエストが最初にそれに向けられた、或いはそのリクエストがそれから最初に発信されたサーバ（例えば、パケットクッキーにて識別されるサーバ）を表す。ポート８０交換機の場合は、これらキャッシュサーバの所で、キャッシュヒット或いはキャッシュミスが存在したか否かに関係なく、全ての接続を終端し、再び長期間アクセスされることはないようなオリジンサーバからのも含めて全てのページをキャッシングすることを要求される。これに対して、本発明による交換機は、これら二つの問題を解決するために、以前キャッシュヒットがあったリクエストに対してワイヤ速度のスイッチングを提供し、キャッシュミスがあったリクエストに対しても、それらの大多数に対してワイヤ速度スイッチングを提供することに加えて、ホットＵＲＬとオリジンＨＴＴＰサーバを識別することで、キャッシュサーバのキャッシュヒット率を向上させる。
【００１６】
第三に、この交換機はサーバファームに対する逆方向プロキシ（ｒｅｖｅｒｓｅ ｐｒｏｘｙ）として機能し、サーバファームに代ってクライアントからの全ての接続リクエストを傍受及び受理する。
【００１７】
第四に、ＨＴＴＰとＨＴＴＰＳ形式のリクエスト及び応答がこの逆方向プロキシを通過するとき、この交換機は、サーバにて生成されたクッキーを解析し、ユーザリクエストに答えてシームレスな処理を提供する。
【００１８】
第五に、この交換機は、入りトラフィックフローに関して、フローフィルタリング、分別、トラフィックパターン学習、及び優先シェーピング（ｐｒｉｏｒｉｔｙ ｓｈａｐｉｎｇ）を遂行することができる。
【００１９】
第六に、この交換機は、ブラウザからの全てのＨＴＴＰトラフィックを傍受し、これらをＨＴＴＰキャッシュサーバに向けられるように戦略的に配置され、クライアントに対してより高速な応答とより快適なウェブサーフィング体験を提供することができる。
【００２０】
最後に、これら交換機は高度にスケーラブルであるために、これら交換機を一つのクラスタに構成し、ダイジェスト情報及び／或いはタグ情報をそのクラスタ内の様々な交換機にて共有することができる。こうして情報を共有することで、冗長性のみでなく、スケーラビリティも向上される。
【００２１】
上に説明の実施形態及び構成は、完全なものでも、全てでもない。後の説明から明らかとなるように、上に説明した或いは以下に詳細に説明する一つ或いは複数の構成要件を単独にて或いは組合せて用いる他の形態も可能である。
詳細な説明
【００２２】
網交換機の構成要素
本発明は、好ましくは図１にコンテントダイレクタサーバ（ｃｏｎｔｅｎｔ ｄｉｒｅｃｔｏｒ ｓｅｒｖｅｒ）として示されるようなサーバコンピュータシステム（ｓｅｒｖｅｒ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ）として実現される。複数のコンテントダイレクタサーバａ−ｎが、一つの好ましい実施例においては電子商取引タイプのＨＴＴＰトランザクションをサポートするために一つのクラスタにグループ化される。サーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）１０４は、オリジンサーバ（ｏｒｉｇｉｎ ｓｅｒｖｅｒ）１０８、ダイナミックコンテントサーバ１１２及び／或いはキャッシュサーバ１１６を含む。トラフィックマネジャ１２０ ａ−ｎは、周知の技法を用いて、複数のコンテントダイレクタから構成されるクラスタ間の負荷バランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）を遂行する。ルータ１２８ ａ−ｎから構成されるルータプール（ｒｏｕｔｅｒ ｐｏｏｌ）１２４は、パケットを通信網１３２からのトラフィックマネジャ１２０ ａ−ｎへとルーティングする。
【００２３】
各コンテントダイレクタサーバは、図２にその概略を示すように、ＨＴＴＰトランザクションを、ＩＰデータパケット内のこれと関連する不変量に基づいて効率的にルーティングするためのインテリジェントフロースイッチ２００を含む。オプションとして、ＳＳＬプロセッサ２０４を設け、機密セッションの協議（ｓｅｃｕｒｅ ｓｅｓｓｉｏｎ ｎｅｇｏｔｉａｔｉｏｎ）と実際の計算（ａｃｔｕａｌ ｃｏｍｐｕｔａｔｉｏｎｓ）の両方において行われる暗号化及び復号動作をオフロードにて遂行することもできる。更に、オプションとして、キャッシュプロセッサ２０８を設け、頻繁にリクエストされるコンテントすなわち「ホット（ｈｏｔ）」コンテントをキャッシュ２１２内にキャッシュ（格納）することもできる。ダイジェスト発生器２１６によってＵＲＬダイジェストが生成され、ローカルダイジェストメモリ２２０内に格納されると共に、複製され、直接に或いは間接的に、同一クラスタ内の他の網フロースイッチに送られる。
【００２４】
コンテントダイレクタ１００は、ＨＴＴＰトラフィックをリダイレクティングする過程において、ＨＴＴＰリクエストのトラフィックパターンを、クライアントブラウザ（図示せず）によってリクエストされたＵＲＬ識別子を監視することで学習する。可変閾値（ホットＵＲＬ閾値）が超えられると、新たに見つけられたホットな（オリジン）サーバに向けられたＨＴＴＰリクエストの全てのトラフィックフローはキャッシュサーバ１１６にリダイレクトされる。「フロー（ｆｌｏｗ）」なる語句は、クライアントとサーバ間、或いはある接続セッションにおける二つのピア間の、全てのトランザクションを指す。他方、あまりアクセスされないＵＲＬに対するリクエストは、キャッシュサーバ１１６にではなく、直接にオリジンサーバ１０８にスイッチされる。一つの動作モードにおいては、コンテントダイレクタは全てのＨＴＴＰトラフィックを透明に傍受し、これをキャッシュサーバ１１６に、特別なプロトコル或いはパケットタグを付加することなく、リダイレクトする。キャッシュサーバ１１６はクライアント（図示せず）との間にスプーフ接続（ｓｐｏｏｆ ｃｏｎｎｅｃｔｉｏｎｓ）を形成する。コンテントダイレクタは、更に、キャッシュサーバのクラスタのメンバへのＨＴＴＰトラフィックを、周知の技法、例えばラルンドロビン方式或いは扱われた接続の数（ａ ｎｕｍｂｅｒ−ｏｆ−ｃｏｎｎｅｃｔｉｏｎｓ−ｓｅｒｖｅｄ）に基づいて負荷バランスする。
【００２５】
コンテントダイレクタ１００は、ＨＴＴＰでないトラフィックをその元の宛先にスイッチすると共に、最初は、全てのＨＴＴＰフローを、それらの自身のオリジンサーバ１０８にスイッチする。リクエストされたＵＲＬをワイヤ上でコンテントダイレクタにてスヌープ（監視）することで、トラフィックパターンのホットなＵＲＬのデータベースが構築される。ＵＲＬ識別子のメッセージダイジェストが、キャッシュ２１２内の、ホットなＵＲＬのデータベース或いはテーブル内に格納される。ある幾つかのサーバへのフローがホットになると（つまり、ある所定の時間期間内に受信されたサーバ内のあるオブジェクトに対するリクエストの数がホットＵＲＬ閾値に達する或いはこれを超えると）、そのサーバのＩＰアドレスがホットなＩＰのデータベース内に入れられ、その後は、そのホットウェブサーバへの新たな接続は、コンテントダイレクタによってＨＴＴＰキャッシュサーバ１１６にリダイレクトされる。こうしてリダイレクト或いはスイッチされたフローは、スイッチドフロー（ｓｗｉｔｃｈｅｄ ｆｌｏｗ）と呼ばれ、オリジンサーバに向かうスイッチされなかったフローは、転送フロー（ｆｏｒｗａｒｄｅｄ ｆｌｏｗ）と呼ばれる。
【００２６】
コンテントダイレクタ１００は、同一のオリジンサーバ１０８に向かう未処理のフローを、リダイレクトされるまで維持し、それらフローが互いに妨害しあうことなく完結できるようにする。ＨＴＴＰ接続の仮想回路が、ブラウザ（或いはそのプロキシ）（図示せず）とオリジンサーバ（或いはそのプロキシ１０８）との間、ブラウザ（図示せず）と透明なＨＴＴＰキャッシュサーバ１１２との間、及びＨＴＴＰキャッシュサーバ１１２とオリジンサーバ１０８との、全ての間で維持される。ここで用いられる「仮想回路（ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ）」なる語句は、二つのエンドポイント間に設定されたＴＣＰ／ＩＰ接続を意味する。
【００２７】
ホットなサーバへのトラフィックパターンが冷えると、そのＩＰアドレスは年齢が過ぎたものとしてキャッシュ２１２内のホットなＩＰ或いはＵＲＬデータベースから削除され、そのサーバへのトラフィックはその通常のフローへと戻される。以下ではコンテントダイレクタのこれら様々な構成要素についてより詳細に説明する。
【００２８】
ＳＳＬプロセッサ
ＳＳＬプロセッサ２０４は、認証及び機密アソシエーション（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）を遂行し；暗号アルゴリズムの協議に参加し、マスタシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）を確立し、セッションキーを計算し、セッションＩＤを割当て；ＨＴＴＰＳメッセージを暗号テキストにて扱い、これらを、トランザクションリクエストを平文テキストにて扱うＨＴＴＰサーバに中継し；セッションコンテクストをセッションＩＤと共に再接続に備えてキャッシングする。後に説明するように、初期ＳＳＬハンドシェークは、暗号器（ｃｉｐｈｅｒ）の選択、マスタキーの交換、及びサーバの認証を扱う。このハンドシェーク段階が完了した後に、クライアントとサーバは、暗号アルゴリズムに関して同意し、メッセージを暗号化するためのセッションキーを導くためにマスタシークレットに関して同意し、さらにサーバによって同意されたコンテクストを識別するために割当てられるセッションＩＤに関して同意する。後に説明するように、ＳＳＬプロセッサは、典型的には、クライアントとの保護されたセッションを開始する前に、クライアントとの無保護のセッションを終端する。
【００２９】
ＳＳＬセッションＩＤは、複数のＳＳＬセッションに共通なスレッドである（共通に用いられる）。ＳＳＬｖ３においては、セッションＩＤは、ＴＣＰ接続上を、第二及びその後の接続を通じて、平文にて輸送される。ＳＳＬｖ２においては、ＳＳＬサーバが初期ハンドシェークにおいてセッションＩＤを送り返す最初の時点から、セッションＩＤは暗号化される。セッションＩＤを見つけるためには、プロセッサは、機密コンテクスト（ｓｅｃｕｒｅ ｃｏｎｔｅｘｔ）の確立に関与することを要求されるが、サーバからこの暗号処理をオフロードすることで、暗号加速化資源（ｒｅｓｏｕｒｃｅｓ ｏｆ ｃｒｙｐｔｏｇｒａｐｈｉｃ ａｃｃｅｌｅｒａｔｉｏｎ）をファーム１０４内の全てのサーバによってより効率的に利用することが可能となる。
【００３０】
上述のように、ＳＳＬプロセッサ２０４は、再接続のために、セッションコンテクストとセッションＩＤ、機密アソシエーション、及び仮想ホット情報をキャッシュする。ＳＳＬプロセッサのキャッシュ（図示せず）内のエントリは典型的にはセッションＩＤを用いて索引付けされる。
【００３１】
ＳＳＬプロセッサは、認証及び／或いは暗号化／復号を遂行するための任意の従来のハードウェア／ソフトウェアであり得る。後に説明するように、用途によっては、例えば、Ｖｉｒｔｕａｌ Ｐｒｉｖａｃｙ Ｎｅｔｗｏｒｋｓ（「ＶＰＮ」）（或いはＩＰｓｅｃ）においては、クライアントとサーバ間にＳＳＬ以外の機密プロトコルを用いることもできる。
【００３２】
インテリジェントフロースイッチ
インテリジェントフロースイッチ（ｉｎｔｅｌｌｉｇｅｎｔ ｆｌｏｗ ｓｗｉｔｃｈ、ＩＦＳ）２００（スイッチ要素とも呼ばれる）は、サーバファーム１０４内のサーバの一つを、パケットのペイロード、例えば、埋め込まれた不変量に基づいて選択し、リクエストを選択されたサーバに転送し、サーバから応答を受信し、これらをクライアントに送り返す。これらリクエスト及び応答メッセージがＩＦＳを通過するとき、ＩＦＳはサーバにて生成された不変量或いは機密セッション不変量を解析することで、ファーム内の選択されたサーバへのクライアントリクエストをシームレスに途切れることなく処理する。ＩＦＳは、ＨＴＰＰ応答を、サーバ生成クッキーを見つけるために解析すると共に、ＨＴＰＰリクエストを、ユーザ返送クッキーを見つけるために解析する。ＩＦＳは、同一クッキーにてスレッドされた（送られた）全てのトランザクションを束ね、そのクッキー不変量を生成したサーバに向ける。不変量アソシエーション（ｉｎｖａｒｉａｎｔ ａｓｓｏｃｉａｔｉｏｎｓ）に関する知識を複数のコンテントダイレクタ１００間で共有し、ＣＰＵ時間を多量に消費する暗号計算を分散処理にオフロードすることで、ＩＦＳは、サーバファームの総合的な故障耐性と性能の向上に寄与すると共に、電子商取引インフラストラクチャを需要に応じて成長させることを可能にする。
【００３３】
ＩＦＳメモリは、ＩＦＳ動作を可能にするためにメモリ内に複数のデータオブジェクトを維持する。例えば、ＩＦＳは、オプションとして：網マネジャによって選択された、異なるタイプのパケット（例えば、「ホット」なパケット、「冷たい」パケット等）に対してサーバを選択するための規則及び／或いは方針のレコード；ＩＰアドレス検索用のテーブル；及び（ワイヤ速度パケット交換用の全ての現仮想回路のレコードを維持するために用いられる）現接続テーブルを含み、これには、ソース不変量（例えば、ＵＲＬ、ポートアドレス、及び他の決められたフィールド）、宛先不変量（例えば、ＵＲＬ、ソースソケット３−タプル、及び他の決められたフィールド）、セッションＩＤ、対象ＵＲＬに対してあるクライアントからの最後のパケットが受信した時刻を示す永続性タイムスタンプ（これはテーブルから所定の年齢に達した或いはこれを超えたエントリを除去するために用いられ、この年齢はクライアントが同一トランザクション或いはセッションの一部として送り返す尤度を最後のパケットが受信された時間に基づいて統計的に推定することで求められる）、クッキー名と値、及び／或いは他の選択された不変量が含まれる。ＩＦＳは、更にオプションとして、コンテントダイレクタによって生成されたタグを含むタグテーブルと、ソース及び宛先不変量を含む。現接続テーブル及び／或いはタグテーブル内の各エントリは、ソース不変量、宛先不変量、及び／或いはクッキー名と値の一つ或いは幾つかを用いて索引付けされる。
【００３４】
キャッシュプロセッサ及びキャッシュ
キャッシュプロセッサ２０８は、ＩＦＳ２００と、キャッシュ２１２、ダイジェスト発生器２１６及びダイジェストメモリ２２０との間のプロセッサインタフェースとして機能する。キャッシュプロセッサは、こうして、ＩＦＳ２００によってリクエストされた、パケット内に含まれ、ＩＦＳ２００によって解析され、キャッシュプロセッサ２０８に転送されたペイロード不変量に対応するキャッシュ２１２及び／或いはダイジェストメモリ２２０内に格納されているデータを取り出す。
【００３５】
キャッシュ２１２は、頻繁にリクエストされる「ホット」なコンテント（例えば、ＵＲＬ）と、それほど頻繁にはリクエストされないコンテント（例えば、ＵＲＬ）の両方を含むホットＵＲＬテーブルを含む。このホットＵＲＬテーブルは、典型的には、以下のフィールド、すなわち：ソース不変量（例えば、ＵＲＬ、ポートアドレス、及び他の関連するフィールド、例えば、ホットコンテント、一次ＵＲＬと対応する或いはこれと関連する二次ＵＲＬ、或いは他のタイプの修飾子）、宛先不変量（例えば、ＵＲＬ、ソースソケット３−タプル、及び他の決められたフィールド）、クッキー名と値、あるエントリが最後に更新されたときを示す（ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる）タイムスタンプ、ヒットカウンタ、オプションとしての（タグモードの際にスイッチによって生成される）タグ、及び／或いは他の選択された不変量を含む。ホットＵＲＬテーブル内の各エントリは、典型的には宛先不変量及び／或いはクッキー名と値を用いて索引付けされる。
【００３６】
リース条件（ｌｅａｓｅ ｔｅｒｍ）は典型的には網マネジャによって決められた規則或いは方針から成る。リース条件には、例えば、レコードの最大寿命、サーバ或いはサーバクラスタのクライアントによるアクセスに関しての制約或いは制限、パケットに対するホットな場合のルーティング指令、コンテントがどの程度ホットであるか、優先、選択されたコンテントへのアクセスに関する制限、ヒットカウンタのリセット方針などが含まれる。
【００３７】
ダイジェスト発生器及びダイジェストメモリ
ダイジェスト発生器２１６は、キャッシュプロセッサ２０８から宛先不変量（例えば、ＵＲＬ及びクッキー値）を受信し、これら不変量をダイジェストに変換する。どのようなダイジェスティング法を用いることもできるが、好ましくは、ハッシング法が用いられる。好ましいハッシングアルゴリズムは以下の通りである：
Ｌ ＝ ｈ（Ｋ）
ここで、全てのキーＫに対して、０≦Ｌ≦Ｍ
【００３８】
ここで、Ｋは選択されたＵＲＬ或いはＵＲＬ識別子の一部或いは全てを表し、ｈはメッセージダイジェスト（ｍｅｓｓａｇｅ ｄｉｇｅｓｔ、ＭＤ）「指紋（ｆｉｎｇｅｒｐｒｉｎｔ）」Ｋを入力引数として用いるハッシュ関数を表し、ＬはホットＵＲＬテーブル内のＫの位置を表し、ＭはホットＵＲＬテーブルのサイズを表す。
【００３９】
ｈは、計算が速くでき、衝突が最小となるように選択される。衝突は異なるキーＫ´から同一のＬが計算されるときに発生する。衝突が発生した場合は、ホットＵＲＬテーブルのボタムからのかわりの位置が見つけられ、ホーム位置からリンクされる。円形連結リストを用いて同一のハッシュ関数を有する全てのＭＤ「指紋」が連結される。ホーム位置の所のヘッドタグは円形リストのヘッドを指す。新たなレコードが見つかると、かわりの位置内のレコードがそのホーム位置を占拠するために、そのかわりの位置のレコードは撤去することを要求される。そのホーム位置内のレコードが削除されると、衝突チェーン内の別のレコードがそこに移動される。理解できるように、用途に応じて他のハッシング関数を用いることもできる。
【００４０】
ダイジェストメモリによって保持されるダイジェストレコードは、通常は、図３に示すような形式を有する。ダイジェストレコードが複製されるとき、キャッシュ識別子３００（これはハッシュ値と同一であり、図にはＭＤ５値として示されている）が、その後のダイジェスト検索においてもリクエストされたオブジェクトを含む特定のローカルオブジェクトキャッシュの識別が生成されるようにそれらダイジェストレコードに付加される。このレコードは、さらに、サーバの宛先ＩＰアドレスを参照する宛先ＩＰ３０４、リース条件３０８、ヒット或いはアクセスカウンタ、（ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる）あるエントリがいつ最後に更新された時刻を示すタイムスタンプ（図示せず）、及び／或いは他の選択された不変量を含む。
【００４１】
あるＵＲＬオブジェクトに対するリクエストが受信されると、コンテントダイレクタ１００は、そのピア（ｐｅｅｒ）からのキャッシュダイジェスト３００を用いて、そのピアのどれが所望のオブジェクトを有するかを見つけ、そのダイレクタのピアからそのオブジェクトを、全てのネーバ（ｎｅｉｇｈｂｏｒ）に照会を送ることなく、取り出す。上の説明から明らかなように、キャッシュダイジェスト３００は、キャッシュされているコンテンツのコンパクトな形式での要約、或いはある特定のＵＲＬがそのキャッシュ内に存在するか否かの指標から成る。換言すれば、キャッシュダイジェスト３００は、キャッシュ２１２のメモリ内の、そのハッシュに対応する一つ或いは複数のオブジェクトが置かれた特定の位置に対するポインタから成る。
【００４２】
入りパケットに対するコンテントダイレクタの動作
以下ではコンテントダイレクタの動作を図１−７との関連で説明する。
図４のステップ４００において、（トラフィックマネジャ１２０（図１）によって負荷バランスされた）入りパケットがＳＳＬプロセッサ２０４（図２）によって受信される。ＳＳＬプロセッサ２０４は、ステップ４０４において、最初に、周知の技法を用いて機密アソシエーションと認証を遂行することで、クライアントの識別及び／或いはクライアントのそのウエブサイトへのアクセス権を検証する。これは典型的にはデジタル証明認証を用いて遂行される。
【００４３】
ステップ４０８において、ＳＳＬプロセッサ２０４は、そのパケットが暗号化されているか否かを調べる。暗号化されているときは、プロセッサ２０４は、ステップ４１２において、そのパケットを周知の技法を用いて復号することで、暗号テキストを平文テキストに変換する。ステップ４１６において、平文テキストのパケットがＩＦＳ２００（図２）に、更なる処理のために送られる。ＳＳＬプロセッサ２０４は、その後、次のパケットを処理するためにステップ４００に戻る。
このパケットが、図５のステップ５００において、ＩＦＳ２００によって受信される。
【００４４】
ＩＦＳは、ステップ５１６において、そのパケットがＨＴＴＰ接続であるか否か調べる。そうでない場合は、ＩＦＳは、ステップ５２０において、そのパケットをオリジンサーバに送り、その後、ステップ５００に戻る。
【００４５】
そのパケットがＨＴＴＰ形式であるときは、ＩＦＳは、ステップ５２４において、そのパケットを解析し、選択されたフィールド、例えば、ＵＲＬやクッキー（存在する場合）などの宛先不変量、ソース不変量、及び／或いは他のペイロード不変量を得る。永続性ＨＴＴＰ接続（ｐｅｒｓｉｓｔｅｎｔ ＨＴＴＰ ｃｏｎｎｅｃｔｉｏｎ）においては、クライアントは、単一の接続にて、複数のリクエストを送り、同数の応答がサーバからリクエストの順番に送り返される。ＩＦＳは、各リクエストを走査することで、そのクッキーを得、そのクッキー永続性（ｃｏｏｋｉｅ ｐｅｒｓｉｓｔｅｎｃｅ）に基づいてサーバアソシエーション（ｓｅｒｖｅｒ ａｓｓｏｃｉａｔｉｏｎ）を作成する。ＩＦＳは、従って、単一のマルチリクエスト（ｓｉｎｇｌｅ ｍｕｌｔｉｐｌｅ ｒｅｑｕｅｓｔ）を、複数の単一リクエスト（ｍｕｌｔｉｐｌｅ ｓｉｎｇｌｅ ｒｅｑｕｅｓｔｓ）に分解し、これらを、それぞれ、各々のリクエスト内に埋め込まれているクッキーに基づいて正しく選択されたサーバに送ることを要求される。ＩＳＦは、加えて、サーバからの応答を追跡し、これらをリクエストと同一の順序にて、クライアントに送り返すことを要求される。
【００４６】
ステップ５０４において、コンテントダイレクタ１００が、タグモードであることが決定されたときは、コンテントダイレクタ１００は、ステップ５０８に進み、（そのパケット内にタグが既に存在しない場合は）タグを生成する。コンテントダイレクタ１００は、宛先不変量に基づいてタグを生成し、そのタグをクッキー上に連結する。クライアントに応答が送られたとき、これらクッキー及び付加されたタグは、ブラウザによってそのクライアントのメモリ内に保存される。クライアントによってさらなるリクエストが送られるとき、これらクッキーと付加されたタグがそのパケットリクエストのペイロード内に挿入される。コンテントダイレクタ１００は、これを解析することでクッキーを得、タグを識別し、パケットをそのタグと関連するサーバに直接に向ける（ダイレクトする）。そのクライアントがまだそのサーバファームに一度も訪問したことがないために、パケットがクッキーを有さないときは、そのサーバファームから応答がコンテントダイレクタ１００によって受信されたとき、タグが生成され、そのクッキー上に連結される。ある一つのリクエストに対して、ドメイン、パス、及び最大年齢（ｍａｘ−ａｇｅ）の選択基準を満たす複数のクッキーが送り返されたときは、サーバ永続性（ｓｅｒｖｅｒ ｐｅｒｓｉｓｔｅｎｃｅ）は最も制限的なパス属性を有するクッキーを用いて決定される。次に、ステップ５１２において、そのパケットがオリジンサーバに転送され、ＩＦＳは、ステップ５００に戻り、次のパケットを待つ。
【００４７】
一つの構成においては、タグは、トランザクションリクエスト内のＵＲＬを扱うキャッシュ或いはオリジンサーバに基づいて生成される。各サーバには、一意のサーバ識別子（アルファベット、数字、或いは英数字）が割り当てられる。ＩＦＳは、対象サーバに対応する一意なサーバ識別子を決定し、この識別子をそのパケット内の別のタグ、例えば、そのサーバによって生成されたクッキーに付加する。タグのビットサイズは、通常は、クッキーのサイズよりかなり小さい。一つの構成においては、タグは、前の応答がサーバによってクライアントに転送されたとき（或いはサーバからの出フローがスイッチを通過するとき）にのみ生成され、クッキーに付加される。
【００４８】
コンテントダイレクタは一つモードにて動作することも、複数のモードにて動作することもできる。一つの構成においては、コンテントダイレクタはタグモードのみにて動作する。もう一つの構成においては、コンテントダイレクタはダイジェスティング（ｄｉｇｅｓｔｉｎｇ ｍｏｄｅ）のみにて動作する。ダイジェスティングモードにおいては、ダイジェストが生成され、コンテントのホットさ（ｈｏｔｎｅｓｓ）が監視され、トランザクションリクエストは、ホットさ及び／或いはクッキーに基づいてサーバにルートされる。もう一つの構成においては、コンテントダイレクタは、同時に両モードにて動作する。換言すれば、最初に、あるトランザクションに対して、クライアントとサーバがリクエストされたコンテントのホットさに基づいてペアリングされ、同一クライアントからのその後のトランザクションリクエストは、そのクライアントに最初に割当てられた各々のサーバと関連するサーバタグを含み、各々のサーバに直接にルートされる。
【００４９】
スイッチクラスタ内では、スイッチクラスタがより効率よく動作できるように、ある一つのスイッチによって生成されたタグは、そのクラスタ内の他のスイッチに供給され、クラスタ内の他のスイッチは、埋め込まれたタグを含むその後送られるトランザクションリクエストを受信できるようにされる。
【００５０】
コンテントダイレクタがタグモードにないときは、ＩＦＳは、ステップ５２８において、不変量フィールドをキャッシュプロセッサ２０８に転送する。
【００５１】
キャッシュプロセッサは、図６のステップ６００において、ＩＦＳから、これら宛先、ソース、及び／或いは他のペイロード不変量を受信する。キャッシュプロセッサ２０８は、ステップ６０４において、これら不変量をキャッシュ２１２内のホットＵＲＬテーブルと比較し、ステップ６０８において、そのコンテントが以前所定の時間期間（永続性期間）内に受信されたか否か決定し、受信された場合は、ステップ６１２において、そのコンテントがホットであるか否か決定される。一つの構成においては、キャッシュプロセッサは、クッキーの名前とその値を、テーブル内にリストされているそれらと比較する。一致する場合は、そのパスがそのＵＲＬと比較され、ヘッドが一致するか調べられ、一致するエントリ（ｍａｔｃｈ ｅｎｔｒｙ）から宛先サーバが決定される。
【００５２】
そのコンテントが永続性期間内に以前リクエストされてないときは、キャッシュプロセッサ２０８は、ステップ６１６において、そのパケットが「ＨＴＴＰ ＧＥＴ」リクエストであるか否か決定する。「ＨＴＴＰ ＧＥＴ」リクエストでない場合は、キャッシュプロセッサ２０８は、ステップ６２０（後の説明）に進む。「ＨＴＴＰ ＧＥＴ」リクエストである場合は、キャッシュプロセッサ２０８は、ステップ６２４において、不変量をダイジェスト発生器２１６に送る。
【００５３】
ダイジェスト発生器２１６は、図７のステップ７００において、キャッシュプロセッサからダイジェストリクエストを受信する。ダイジェスト発生器は、ステップ７０４において、宛先関連不変量に対するダイジェストを生成し、ステップ７０８において、ダイジェスト、タイムスタンプ、宛先関連不変量、及びリース条件（ダイジェスト発生器はこれらリース条件をダイジェストメモリ内の規則／方針に基づいて決定する）をダイジェストメモリ２２０内にコピーし、ステップ７１２において、これらダイジェスト、タイムスタンプ、及びリース条件をキャッシュプロセッサ２０８に送る。ダイジェスト発生器は、次に、ステップ７００に戻る。
【００５４】
図６に戻り、キャッシュプロセッサは、ステップ６２８において、ダイジェスト発生器２１６からダイジェスト、タイムスタンプ、及びリース条件を受信し、ステップ６３２において、参照カウンタを初期化する。次に、キャッシュプロセッサ２０８は、ステップ６３４においてホットＵＲＬテーブルを更新し、ステップ６２０（後に説明）に進む。
【００５５】
ステップ６０８において、パケット情報がホットＵＲＬテーブル内に存在する場合は、キャッシュプロセッサは、次に、ステップ６１２において、パケットによってリクエストされたコンテントがホットであるか否か決定する。パケットのＵＲＬは、ヒットカウンタが所定のレベル、すなわち、ホットＵＲＬ閾値以上であるときはホットである。ＵＲＬがホットな場合は、ステップ６３６において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ６３８において、ホットＵＲＬテーブルがこれを反映するように更新される。キャッシュプロセッサ２０８は、次に、ステップ６２０（後に説明）において、関連する応答をＩＦＳに送る。ＵＲＬがホットでない場合は、ステップ６４２において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ６４６において、ホットＵＲＬテーブルが更新される。ステップ６５０において、キャッシュプロセッサは、再び、そのＵＲＬが（増分されたカウンタの観点から）ホットＵＲＬ閾値を超えるか否か決定する。超えない場合は、キャッシュプロセッサはステップ６２０（後に説明）に進む。超える場合は、キャッシュプロセッサは、ステップ６５４において、逆ドメイン名サービス（ｒｅｖｅｒｓｅ ｄｏｍａｉｎ ｎａｍｅ ｓｅｒｖｉｃｅ）すなわちＤＮＳ検索を遂行することで、そのホットＵＲＬページを扱った特定のドメインを扱っている全てのＩＰアドレスを見つける。ステップ６５８において、これらアドレスがホットＵＲＬテーブル内に書込まれる。キャッシュプロセッサは、ステップ６２０に進む。
【００５６】
ステップ６２０において、キャッシュプロセッサ２０８は、関連する応答をＩＦＳに送る。パケットによってリクエストされたコンテントがホットである場合は、キャッシュプロセッサは、ＩＦＳに、コンテントがホットであることを示とともに、パケット内のその特定のＵＲＬを扱っているＩＰアドレスのリストを与えるメッセージを送り、任意の関連するリース条件を供給する。一つの構成においては、キャッシュプロセッサは、加えて、ＩＦＳに、ホットさの程度（ｄｅｇｒｅｅ ｏｆ ｈｏｔｎｅｓｓ）、例えば、ヒットカウンタの値を知らせる。パケットによってリクエストされたコンテントがホットでない場合は、キャッシュプロセッサは、ＩＦＳに、そのコンテントがホットでないことを示すメッセージを送り、任意の関連するリース条件を供給する。
【００５７】
図５に戻り、ＩＦＳ２００は、ステップ５３０において、キャッシュプロセッサ２０８からの応答を受信する。ＩＦＳ２００は、次に、ステップ５３２において、そのペイロード内の解析されたフィールド（例えば、ソースＩＰ、宛先ＩＰ、ソースソケット３−タプル）を現接続テーブル内にリストされるそれらと比較する。ステップ５３４において、一致が存在しない場合は、ＩＦＳ２００は、ステップ５３６において、新たな接続が存在するか（すなわち、そのパケットが現存の仮想回路の一部であるか）否かを決定する。この決定は、ＩＦＳがその接続に対して受信した第一のパケット内のヘッダフラグ（ＳＹＮ）を調べることで遂行される。ＳＹＮフラグがセットされてないときは、そのパケットは現存の仮想回路には属さないものとみなされ、ＳＹＮフラグがセットされているときは、そのパケットは、そのサーバがホットになる前にクライアントとオリジンサーバとの間に設定された仮想回路に属するものとみなされる。接続が新たなものであるときは、ステップ５４０において、現接続テーブルが更新される。つまり、そのパケットペイロードの少なくともソースＩＰ、宛先ＩＰ、ソースソケット３−タプルを含む新たなエントリが追加される。
【００５８】
接続が新たなものであるか、古いものであるかに関係なく、ＩＦＳは、次に、ステップ５４４において、パケットペイロード内のＵＲＬがホットであるか否か決定する。ＵＲＬがホットでない場合は、ＩＦＳはステップ５４８に進む。ステップ５４８において、ＩＦＳは、パケットをリアセンブルし、ステップ５５２において、パケットをオリジンサーバに送る。ＩＦＳは、次に、次のパケットを処理するためにステップ５００に進む。
【００５９】
ステップ５４４において、パケットペイロードがホットであるときは、ＩＦＳは、ステップ５５６において、関連するホットなキャッシュサーバアドレスを決定する。これは、キャッシュプロセッサ２０８から受信されたホットＩＰアドレスとリース条件のリスト、各ＩＰアドレスに対応するキュー（どのキャッシュサーバが最も短いキューを有するかを決定するために用いられる）、及び／或いはＩＦＳのメモリ内の規則／方針を調べることで行われる。ステップ５６０において、パケットが関連するＩＰアドレスを有するようにリアセンブルされ、ステップ５６４において、関連するキャッシュサーバに送られる。一つの構成においては、ＩＦＳは、Ｃａｃｈｅ Ａｒｒａｙ Ｒｏｕｔｉｎｅ Ｐｒｏｔｏｃｏｌ（ＣＡＰＰ）を用いて、キャッシュ可能なＵＲＬオブジェクトをキャッシュサーバ間に分配する。キャッシュプロキシメンバ識別（ｃａｃｈｅ ｐｒｏｘｙ ｍｅｍｂｅｒ ｉｄｅｎｔｉｔｉｅｓ）とリクエストされたＵＲＬのハッシング計算を行い、最高値を有する経路がルーティング解として決定される。こうして、ＵＲＬは最高のハッシングスコアを有するキャッシュプロキシ（ｃａｃｈｅ ｐｒｏｘｙ）に向けられるために、ＵＲＬキャッシュ位置の再割当てを最小限に押さえることができる。
【００６０】
ＩＦＳは、次に、受信される次のパケットに対してステップ５００を反復する。
再びステップ５３４に戻り、現接続或いは現存する仮想回路が存在する場合は、ステップ５８０において、パケットがオリジンサーバに転送され、その後、ＩＦＳはステップ５００に戻る。
【００６１】
コンテントがホットになった後に、一つ或いは複数のキャッシュサーバがそのコンテントを含むオリジンサーバとの接続を設定することがある。この場合、これらキャッシュサーバは、オリジンサーバからＵＲＬのコピーを得、そのＵＲＬを自身のキャッシュから扱う。
【００６２】
以下では、このキャッシュサーバの動作について、図８との関連で説明する。ステップ８００において、キャッシュサーバはコンテントダイレクタからトランザクションリクエストを受信する。ステップ８０４において、受信キャッシュサーバは、そのパケットを自身で扱うことができるか否かを決定する。サーバは、キャッシュサーバがそのパケットを初めて受信し、まだそのパケット内の特定のＵＲＬをキャッシュ（格納）していないとき、そのパケットリクエスト法がＨＴＴＰ ＧＥＴリクエストではないとき、及び／或いはそのリクエストがキャッシュ可能なタイプのリクエストではないときは、そのパケットを扱うことはできない。キャッシュサーバがそのパケットを扱うことができないときは、キャッシュサーバは、ステップ８０６において、そのパケットをリアドレスし、そのパケットをオリジンサーバに送る。
【００６３】
キャッシュサーバがそのパケットを扱うことができるときは、キャッシュサーバは、ステップ８１０において、そのパケットを処理する。キャッシュサーバはそのパケットをリアドレスし、そのパケットを新たな或いは現存する接続を通じてオリジンサーバにリダイレクトする。オリジンサーバは、そのＵＲＬを（そのＵＲＬがキャッシュ可能であるときは）キャッシュサーバに送り返す。キャッシュサーバは、そのＵＲＬのコピーを保存し、もう一つのコピーをクライアントに送り返す。
【００６４】
キャッシュサーバは、ステップ８０８において、さらなるコンテント（或いはサブＵＲＬ）或いはパイプライン（ｐｉｐｅｌｉｎｅｓ）を、現トランザクションリクエスト内のＵＲＬに対応するコンテント内で参照されているサブＵＲＬのホットさに基づいて先取りする。一例として、そのコンテント内に二つのサブＵＲＬが参照されており、各サブＵＲＬが異なるホットさの程度（その対応するヒットカウンタ内に異なるヒットの数）を有する場合は、キャッシュサーバは最も大きなヒット数を有するサブＵＲＬがクライアントによって次にリクエストされるＵＲＬであるとみなす。キャッシュサーバは、クライアントからの次のトランザクションリクエストが受信される前に、そのＵＲＬに対応するコンテント（或いはそのＵＲＬ自体）を取り出し、こうすることで、後に受信されるリクエストを処理するために要求される時間を大幅に短縮することが可能となる。
【００６５】
ステップ８１２において、キャッシュサーバは、コンテントを、サーバファーム動作が最も効率的に遂行される位置内に格納（キャッシュ）する。例えば、地理的に分散するサーバクラスタにおいては、どのコンテントがホットであるかは、地域或いは位置によって異なる。例えば、ある選択されたコンテントは、第一の地域においては第一のレベルのホットさを有し、第二の異なる地域においては異なる第二のレベルのホットさを有し得る。コンテントは、従って、そのコンテントが最もホットな地域にキャッシュ（格納）される。このやり方においては、第一の地域内のキャッシュサーバと、第二の地域内のキャッシュサーバとは、異なるキャッシングされたコンテントを有することとなる。代替として、ホットなコンテントを、関連するホットなコンテントが格納されているのと同一のサーバクラスタの一部内に格納することもできる。このやり方においては、選択されたコンテントがホットな場合、そのコンテントと関連する全てのコンテントが（それがホットであるか否かに関係なく）コピーされ、そのホットなコンテントと同一のキャッシュサーバクラスタ内に格納される。もう一つの構成においては、あるホットなＵＲＬと関連する幾つかのＵＲＬが周知の技法を用いてそのホットなＵＲＬに連結される。もう一つの構成においては、複数のサーバクラスタが、幾つかのサーバクラスタは第一（或いはそれ以上）のホットさの情報を格納し、第二の異なるセットのサーバクラスタは（第一のホットさより低い）第二のホットさとの情報と、これよりホットな（ただし、第一のホットさよりは低い）コンテントを格納するように積重ねられる。もう一つの構成においては、ホットなコンテントと関連するコンテントは、（その関連するコンテントはホットでなくても）ホットなコンテントと接近して（例えば、同一のキャッシュサーバ或いはキャッシュサーバクラスタ内に）格納される。
【００６６】
一つの構成においては、キャッシュサーバ内のコンテントの位置は、そのコンテントのホットさの程度に基づく。換言すれば、コンテントがホットになるにつれて、そのコンテントは、キャッシュサーバ内の第一の最もアクセス性の良い項目が最も頻繁な（従って最高数の）ヒットを経験し、キャッシュ内の最もアクセス性の悪い或いは最も下の項目は最も少ない頻度（或いは最小数の）ヒットを経験するように、そのキャッシュサーバ内のよりアクセス性の良い或いはより高い位置に移動される。コンテントダイレクタ１００は、コンテントのホットさの程度が時間と共に変動するに基づいて、様々なキャッシュサーバに対して、コンテントのメモリアドレスを再配置（ｒｅｐｏｓｉｔｉｏｎ 或いはｒｅｌｏｃａｔｅ）するように指令する。換言すれば、コンテントダイレクタは、第一の時間において、キャッシュサーバに対して、第一のコンテントをそのサーバ内のコンテントのスタック（積み重ね）の第一に位置に移動するように指令し、コンテントのヒットの頻度が変動した後の第二の時間においては、そのキャッシュサーバに対して、その第一の項目（コンテント）をそのスタック内の第二のより低い或いはより高い位置に移動するように指令する。
【００６７】
後に説明するように、キャッシュサーバは、キャッシュコンテントの新鮮さを定期的にチェック或いは要求に答えて再検証する。キャッシュサーバは、満了タイマを各キャッシュ可能なオブジェクト毎にオブジェクトの人気度、最大年齢、及びコンテントサーバによって施された最後の修正時刻に基づいて調節する。
【００６８】
図１に戻り、複数のコンテントダイレクタ１００ａ−ｎによってクラスタが形成されるが、こうすることでサーバアプリケーションによって確立された不変量（例えば、ダイジェスト、タグ、及びクッキー）に関する知識を共有することができ、冗長性と性能を向上させることが可能となる。これら共有される情報は、図示されるようにリンク１３６によって、全てのクラスタメンバ間に分配される。どの一つのノードも故障の単一ポイントを形成しない。コンテントダイレクタの追加或いは削除などでクラスタが変更される場合、共有される情報の一部のみを再分配することで済む。
【００６９】
理解できるように、アプリケーション層のコンテントダイレクタの深い所にある情報にアクセスすることで、幾つかの予め定義されたトラフィック方針とサービスのクラスを管理することが可能となる。コンテントダイレクタは、サーバファームから設備へのフローパターンを学習し、サービスの提供を需要の突発的変化に適応させ、ユーザによって求められる情報を優先的に供給できるようにする。コンテントダイレクタは、フローフィルタリング、分類、学習、優先シェーピング、及び転送を遂行する。コンテントを意識した制御のために、コンテントダイレクタは、キャッシュ可能なＵＲＬリクエストとキャッシュ不能なＵＲＬリクエストとを分類し、これらを、それらをより良く扱うことができるサーバに向けたり、更には、それらリクエストを自身のキャッシュから処理する。
【００７０】
出パケットに対するコンテントダイレクタの動作
以下では図９との関連でＩＦＳの出パケットフローに対する動作について説明する。ステップ９００において、ＩＦＳは、対応するサーバから応答を受信する。ＩＦＳは、全ての出パケット或いはＨＴＴＰ応答を受信する。ステップ９０４において、ＩＦＳは、選択されたフィールドを解析する（典型的には入りパケットについても同一のフィールドが解析される）。ステップ９０８において、ＩＦＳは、コンテントダイレクタがタグモード（上述）であるか否か決定する。コンテントダイレクタがタグモードにあるときは、ＩＦＳは、ステップ９１２において、そのパケット内のクッキーが新たなクッキーであるか否か決定する。新たなクッキーであるときは、ＩＦＳは、ステップ９１６において、タグを生成し、そのタグを、ステップ９２０において、クッキーに付加し、そのタグを、ステップ９２４において、キャッシュプロセッサに送る。ＩＦＳは、次に、ステップ９２８（後に説明）に進む。クッキーが新たなものではないときは、ＩＦＳは、そのクッキーは既にタグを含むものとみなし、ステップ９２８（後に説明）に進む。コンテントダイレクタがタグモードでないときは、ＩＦＳは、ステップ９３２において、ソースと宛先に関する不変量をキャッシュプロセッサに送る。キャッシュプロセッサは、それら解析されたフィールドがホットＵＲＬテーブル内に存在するか否か調べ、存在しない場合は、それらフィールドをダイジェスト発生器に送る。ダイジェスト発生器は、ダイジェストを生成し、ダイジェストメモリ内にレコードを作成する。ダイジェストはキャッシュプロセッサに送り返され、キャッシュプロセッサは、ＵＲＬテーブル内のそのダイジェストに対応する位置にレコードを作成する。ＩＦＳは、ステップ９２８において、パケットをリアセンブルし、そのパケットを、ステップ９３６において、ＳＳＬプロセッサを介してクライアントに送る。
【００７１】
上では本発明がソフトウェアに基づく実現との関連で具体的に説明されたが、本発明は、ハードウェアに基づくデバイス（例えば、特定用途向け集積回路、ＡＳＩＣ）として実現することも、更には、ソフトウェアとハードウェアの両方に基づくデバイスとして実現することもできる。
【００７２】
上では本発明がインタネットとの関連で説明されたが、本発明は、その網が回路スイッチ網であるかパケットスイッチ網であるか、コネクションレス網であるかコネクションオリエンテッド網であるか、同期網であるか非同期網であるか、シリアル伝送を用いるかパラレル伝送を用いるか、クラスタ／サーバアーキテクチャを用いるかピア・ツウ・ピアアーキテクチャを用いるか、及び／或いは他の網アプリケーションを用いるかに関係なく、他の網トポロジ上でも採用できる。ホットさ或いはタグを決定するために、クッキー或いはＵＲＬ以外のアプリケーション不変量を用いることもできる。
【００７３】
本発明の様々な変形及び修正態様を用いることができる。本発明の幾つかの特徴の一部のみを、他の特徴は省略して、用いることもできる。例えば、一つの代替実施例においては、コンテントダイレクタは、サーバからクライアントへの応答についても、ペイロード情報（例えば、ソースＩＰ、宛先ＩＰ、クッキー名と値、等）に関して解析する。この情報が、一つ或いは複数の現接続テーブル及びホットＵＲＬテーブルに付加される。この実現は、サーバファームに出入りするトラフィックフローに関するより総合的な情報を提供できるという長所を有する。
もう一つの実施例においては、キープアライブスキームを備えるパイプライン接続がキャッシュサーバとコンテントサーバとの間に維持される。これにより、事前に設定された接続を再使用したり、キャッシュされてないコンテントの配信を高速化することが可能となる。更に、コンテントパイプラインにて複数のコンテントサーバへのパラレル接続を設定し、あるページ内に埋め込まれた全てのオブジェクトを同時にダウンロードし、ウェブの内容を前後にローディングする過程に起因する遅延を克服することもできる。多くのウェブページは埋め込まれた参照を有する。アンカページがプリントされている間に、ブラウザはこれら埋め込まれた参照を取り出すための新たなリクエストを行う。インテリジェントキャッシュプロセッサは、送り返されたコンテントを走査し、その後のリクエストに備えて、埋め込まれたオブジェクトを先取りする。
【００７４】
さらにもう一つの代替実施例においては、コンテントダイレクタは、ファーム内の静的コンテントサーバ（ｓｔａｔｉｃ ｃｏｎｔｅｎｔ ｓｅｒｖｅｒｓ）と動的コンテントサーバ（ｄｙｎａｍｉｃ ｃｏｎｔｅｎｔ ｓｅｒｖｅｒｓ）とを、リクエストするＵＲＬとコンテントタイプに基づいて分別する。再検証は静的コンテントサーバにのみ送られる。コンテントダイレクタは、コンテントの更新に関する方針を通知され、更新されたオブジェクトはその時点で除去される。サーバは、更新されたコンテントを自動的に或いは手動にてをコンテントダイレクタに送る。
さらにもう一つの実施例においては、コンテントダイレクタは、ソースＩＰアドレス、ＵＲＬ、コンテントタイプ或いはクッキーの幾つか或いは全てが一致するリクエストに対する動作（ロード／ダイレクト／キャッシュ）を指定する方針や規則を構成できるようにされる。「ロード（ｌｏａｄ）」規則は、ある幾つかのコンテントに対する全てのリクエストを、その瞬間におけるロード状態に基づいて、最も適するサーバに向けるために用いられる。「ダイレクタ（ｄｉｒｅｃｔ）」規則は、その他のコンテントに対するリクエストを、指定されたサーバに向けるために用いられ、「キャッシュ（ｃａｃｈｅ）」規則は、コンテントダイレクタが、コンテントをキャッシュプロキシ（ｃａｃｈｅ ｐｒｏｘｙ）から扱えるようにするために用いられる。
【００７５】
さらにもう一つの実施例においては、Ｓｑｕｉｄ Ｗｅｂ Ｐｒｏｘｙ Ｃａｃｈｅがコンテントダイレクタによって用いられる。Ｓｑｕｉｄコードは、プロセスの作成及び同期のオーバヘッドを回避するためにソケットとファイルの読出し／書込み用のＮｏｎ−ｂｌｏｃｋｉｎｇ Ｉ／Ｏ（非閉塞入出力）を用いる。コンテントダイレクタは、Ｃｏｏｋｉｅ ａｎｄ Ｓｅｔ Ｃｏｏｋｉｅ ＭＩＭＥヘッダを走査し、全てのクッキーをデータベース内に保存し、クッキー方針を維持する。全ての他のキャリア機能はこのコードから削除される。Ｓｑｕｉｄは、キャッシュされたオブジェクトを保存するために下層のファイルシステムを用いる。
【００７６】
さらにもう一つの実施例においては、このファイルシステムをバイパスするために、ＵＲＬとメモリ内の格納リスト（ｓｔｏｒａｇｅ ｌｉｓｔ）とがハッシュングされ、固定サイズのディスクメモリにマッピングされる。
【００７７】
本発明は、様々な実施例において、ここで説明されたものと概ね同一の要素、方法、プロセス、システム及び／或いは装置を包含し、これには、様々な異なる実現、一部のみからの組み合わせ、及びこれらのサブセットも包含される。当業者においては、上の説明を理解することで、本発明をいかに実現及び使用するかを容易に理解できるものと期待される。本発明の幾つか実施例においては、ここで説明された項目のみを用いてデバイス或いはプロセスが実現され、他の幾つかの実施例においては、説明のデバイス或いはプロセスに用いられた項目の内の性能を改善するための項目は省略され、これによって実現の簡単さ及び／或いはコストの削減が達成される。
【００７８】
上の説明は単に解説のためのもので、本発明を説明された形態に制限することを意図しない。上では、本発明の説明として、一つ或いは幾つかの実施例、幾つかの変形及び修正について説明したが、上の説明を読んだ後に明らかとなるような他の様々な変形及び修正も本発明の範囲に入る。許される範囲内の全ての代替を包含する権利を得ることが意図される。これらには、クレームにおいて主張されるそれらに対する、特許可能な主題として具体的に開示はされなかった、代替・互換可能或いは同等な構造、機能、レンジ或いはステップも含まれる。
【図面の簡単な説明】
【００７９】
【図１】本発明の一つの実施例によるフロースイッチを用いるサーバファームのブロック図である。
【図２】本発明の一つの実施例によるコンテントダイレクタの構成要素を示すブロック図である。
【図３】本発明の一つの実施例によるデータメモリ内のデータオブジェクトのデータ構造を示す図である。
【図４】本発明の一つの実施例によるＳＳＬプロセッサの動作を流れ図にて示す図である。
【図５】本発明の一つの実施例によるＩＦＳの動作を流れ図にて示す図である。
【図６】本発明の一つの実施例によるキャッシュプロセッサの動作を流れ図にて示す図である。
【図７】本発明の一つの実施例によるダイジェスト発生器の動作を流れ図にて示す図である。
【図８】本発明の一つの実施例による網交換機からトランザクションリクエストが受信された際のキャッシュサーバの動作を流れ図にて示す図である。
【図９】本発明の一つの実施例による応答が受信された際のインテリジェントフロースイッチの動作を流れ図にて示す図である。
【符号の説明】
【００８０】
１０４ サーバファーム
１０８ オリジンサーバ
１１２ ダイナミックコンテントサーバ
１１６ キャッシュサーバ
１２０ トラフィックマネジャ
１２４ ルータプール
１２８ ルータ
１３２ 通信網
２００ インテリジェントフロー交換機
２０４ ＳＳＬプロセッサ
２０８ キャッシュプロセッサ
２１２ キャッシュ
２１６ ダイジェスト発生器
２２０ ローカルダイジェストメモリ
２０８ キャッシュプロセッサ
３００ キャッシュ識別子
【技術分野】
【０００１】
関連する特許出願
本出願は、２０００年８月４日付けで、Ｃｈｕ，Ｊａｓｗａ，及びＣｈａｇａｎｔｙらに付与された同名の合衆国仮特許出願Ｎｏ．６０／２２３，０８７の合衆国特許法（３５Ｕ．Ｓ．Ｃ§１１９（ｅ））の下での利益を主張する。本発明は、更に、両者とも本出願と同一の発明人により本出願と同時に出願された「Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｓｅｒｖｅｒ Ｆａｒｍ Ｗｉｔｈ Ｔａｇｇｉｎｇ ａｎｄ Ｐｉｐｅｌｉｎｉｎｇ」及び「Ｎｏｎ−Ｉｎｔｒｕｓｉｖｅ Ｍｕｌｔｉｐｌｅｘｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｐｅｒｓｉｓｔｅｎｃｙ ｉｎ Ｓｅｃｕｒｅ Ｃｏｍｍｅｒｃｅ Ｅｎｖｉｒｏｎｍｅｎｔｓ」なる名称の合衆国特許出願にも係る。
【０００２】
発明の技術分野
本発明は一般的には、負荷のバランス、網交換機、より詳細には、トランザクション一貫性（ｔｒａｎｓａｃｔｉｏｎ ｃｏｈｅｒｅｎｃｙ）を維持しながらフローの負荷バランスを知能的に遂行することができる網交換機に関する。
【０００３】
発明の背景
ビジネスはますます多くをコンピュータ及びネットワークに依存するようになりつつある。ウェブ技術は様々なアプリケーションに対するユーザに優しいフロントエンドを提供することで電子商取引（Ｅ−Ｃｏｍｍｅｒｃｅ）展開の推進力となっている。クライアント／サーバアプリケーションの成功には、ホストされるサービスへの連続（持続）的なアクセスとこれらからの即座の応答が必須である。長いダウン時間や遅い及び／或いは誤った応答は、顧客の不満を招き、商売の機会を逃しかねない。このため、利便性（ａｖａｉｌａｂｉｌｉｔｙ）が高く、性能の優れたサーバに対する要請はますます高まっている。
【０００４】
（ウェブサイト用途において遭遇される時間に依存する大きな需要の変動の観点から）サーバに要求されるレベルの利便性、性能、及びスケーラビリティを達成するためには、典型的には一つ或いは複数のインテリジェントインタネットプロトコル（ＩＰ）交換機を備えるサーバのファーム（ｆａｒｍ）、すなわちサーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）が採用される。ＩＰ交換機は、複数のサーバ間のインタネットプロトコル（ＩＰ）トラフィックの負荷バランシングを、ＯＳＩネットワークモデルの一つ或いは複数の層（つまり、層７すなわちアプリケーション層、層６すなわちプレゼェンテーション層、層５すなわちセッション層、層４すなわちトランスポート層、層３すなわちネットワーク層、層２すなわちデータリンク層、及び層１すなわち物理層）内に含まれる情報に基づいて遂行する。サーバのグループは典型的には単一のグローバルＩＰアドレスによって識別される。このグローバルＩＰアドレスに向けられたトラフィックは、ソースＩＰアドレスを有するこれらサーバの作業負荷と選択されたサーバのアドレス類似性に基づいて、そのグループ内のサーバ間で負荷バランスされる。これらサーバにアクセスする全てのクライアントは、グローバルＩＰアドレスのみを調べ、そのファーム内の複数の複製サーバについて及びそれらのトラフィックがどの特定のサーバに転送されているかは特に意識しない。
【０００５】
現在様々な異なるタイプのＩＰ交換機が用いられている。
層３及び／或いは層４交換機を含むあるタイプの交換機は、入りパケットを宛先ＩＰアドレス、或いはＩＰアドレス、プロトコルＩＤ及びトランスポートポート番号の組合せに基づいてルーティングする。このスイッチング技法はウェブ環境においては問題をはらむ。層４の負荷バランサにとっては、全てのウェブアプリケーションはＴＣＰポート８０（ＨＴＴＰに対する典型的なポート）を使用しているように見え、これらを互いに区別することはできない。このため、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）リクエストと、Ｗｅｂ−ｅｎａｂｌｅｄ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＳＡＰ）アプリケーション或いはストリーミングオーディオ（ｓｔｒｅａｍｉｎｇ ａｕｄｉｏ）リクエストとを、これらリクエストは全て非常に異なるＱｏＳ要件を有するのにもかかわらず、区別することができない。
【０００６】
もう一つのタイプのＩＰ交換機は、ウェブ交換機として知られており、これは、ウェブトラフィックの特有な要件に対処できるように特別に設計された新世代のネトワーク技術である。ウェブ交換機は、高度なユニバーサルリソースロケータ（ＵＲＬ）負荷バランス能力、Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）、及び埋め込まれたＤｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ（ＤＮＳ）知能を備える「スマート（ｓｍａｒｔ）」交換機であり、複雑な方針（ｐｏｌｉｃｉｅｓ）を用いてウェブトラフィックフローの管理及び高速化を図る。ウェブ交換機は、ウェブトラフィックを最適化するために、ＨＴＴＰペイロードを解析し、ＵＲＬとクッキーを調べることで、どのようなコンテントがリクエストされているかを決定する。ここで用いられる「クッキー（ｃｏｏｋｉｅ）」なる語句は、サーバのリクエストに答えて、クライアント或いはピア（ｐｅｅｒ）上に格納される情報を指す。クッキーは、典型的には、そのクッキーがそれに対して有効なＵＲＬのパスレンジ（ｐａｔｈ ｒａｎｇｅ）の記述から成り、サーバ応答に付加或いはタグ付けされる。クッキー内の情報は、勿論、サーバによって定義される。後に説明するように、ＵＲＬは、リクエストされたコンテントを識別するのみで、そのコンテントがどこで見つられるかは示さない。リクエストされたコンテントに関する知識に元に、ウェブ交換機は、ユーザにて定義された及び／或いは事前に設定された方針を用いて、特定のコンテント或いはユーザに対して、どのようなフローセキュリティ規則が施行されるべきか、どのようなコンテントが許容され、どのようなコンテントが拒絶されるべきか、及びどのようなＱｏＳ要件が必要とされるかを決定する。こうすることで、トラフィック優先付けに関する方針の定義における柔軟性が得られ、階層サービス（ｔｉｅｒｅｄ ｓｅｒｖｉｃｅｓ）を実現したり、Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔに合わせたり、電子商取引にとって非常に重要な要件である固着性接続（ｓｔｉｃｋｙ ｃｏｎｎｅｃｔｉｏｎ ）やユーザ認証を活用したりすることが可能となる。
【０００７】
ウェブ交換機は、高度にスケーラブルなマルチプロセッサフレームワークを用い、これは方針をフロー（セッション）の設定時にのみ評価する。フローがいったん設定されると、そのフロー内の、それ以降の全てのパケットは、高速転送回路を介してポートベースにてワイヤ速度（ｗｉｒｅ ｓｐｅｅｄ）にてカットスルー（ｃｕｔ−ｔｈｒｏｕｇｈ）される。「いったんフローを設定し、その後、全ての他のパケットを交換する」アプローチは、ＵＲＬレベルでのトラフィックの複雑な分類を可能にするとともに、ローカルエリア網（ＬＡＮ）交換機のコスト性能を向上させる。
【０００８】
ウェブ交換機は、ある瞬間においてどのウェブサーバ或いはキャッシュが特定のリクエストを最も良く扱うことができるかを、そのユーザからサーバまでの近接性（距離）、サーバの状態、網パスの状態、及びどのようなコンテントがリクエストされたか等の基準に基づいて決定する。ウェブ交換機は、あるウェブサイトに向かう全てのトラフィックを傍受する。こうすることで、ウェブ交換機は、コンテントリクエストを追跡し、ホットコンテント（ｈｏｔ ｃｏｎｔｅｎｔ）を予測し、サーバの負担を軽減することが可能になる。ウェブ交換機は、動的にホットコンテントをウェブキャッシュ内に複製し、キャッシュをかわるがわる用いて負荷をバランスされることで、ウェブサイトトラフィックが大きく変動した場合でも、ユーザが途切れのないサービスを受けられるようにする。ウェブ交換機は、更に、どのサーバが以前配信されたことのある特定のコンテントを有するかを追跡し、そのコンテントに対する新たなリクエストは、該当するサーバに直接に送るようにし、こうすることでサーバキャッシュの一貫性と性能の向上に寄与する。
【０００９】
ただし、ウェブ交換機は幾つかの問題を有する。例えば、ウェブ交換機も過多な計算資源を必要する、すなわち、計算効率が悪い。
【００１０】
発明の概要
これら及びその他の必要性が本発明のアーキテクチャ及び方法によって解決される。
【００１１】
一つの実施例においては、本発明は通信網とデータサーバファームとの間で結合可能な網フロー交換機を提供する。一つの構成においては、この網フロー交換機は、２，３，及び４層ウェブ交換機として構成され、サーバファームのグローバルＩＰアドレスを自身のアドレスとし、クライアントからの全てのトランザクションリクエストを、サーバファームに代って受信する。「トランザクションリクエスト（ｔｒａｎｓａｃｔｉｏｎ ｒｅｑｕｅｓｔ）」なる語句は、パケットの形式を有するか否かに関係なく、一つ或いは複数のサーバによる仕事或いは仕事の開始をリクエスト指示するあらゆる信号を意味する。より具体的には、ある信号（リクエスト）は、例えば、サーバに対してそのサーバのメモリ内に格納されているリクエストされた情報を供給することや、その信号によって参照或いは供給される情報に基づいて情報を計算することを指令する。この網フロー交換機はルーティングを備え、ルーティング要素は受信されたデータパケットに関して動作し、そのＩＰデータパケット内のソースと宛先に関する不変量を決定する。これら不変量は、それ以降、そのＩＰパケットに対する宛先デバイスを決定するための基礎として用いられる。
【００１２】
一つの構成においては、交換機は、ＵＲＬとコンテントタイプの任意の組合せを調べ、これに基づいてリクエストのルーティングとアクセス優先の設定を行い；これらを解析することでリクエストされたＵＲＬを決定し；そのコンテントを取り出すために最も有効なサーバを決定し；こうして参照カウント（或いはヒットカウンタ）と満了タイマ（或いはタイムスタンプ）を備えるソースサーバのＵＲＬデータベースを構築する。反復されるリクエストは同一サーバに向けられるが、これには一つの実施例においてはキャッシュ可能なサーバ（ｃａｃｈｅａｂｌｅ ｓｅｒｖｅｒ）が用いられる。この交換機は、コンテント参照カウントと満了タイマを用いて、アクセスの頻度と最近性（ｒｅｃｅｎｃｙ）の組み合わせを計算し、これによって「ホット（ｈｏｔ）」コンテントを検出する。これによって頻繁にリクエストされるコンテントが効率的に分別され、網フロー交換機のクラスタ構成間に均等にキャッシングされる。この交換機要素に、一つの実施例においては、オプションとして、サーバ側にキャッシュプロセッサが接続される。このキャッシュプロセッサは、頻繁にリクエストされるデータオブジェクトを格納するためのローカルオブジェクトキャッシュ（ｌｏｃａｌ ｏｂｊｅｃｔ ｃａｃｈｅ）と、このローカルオブジェクトキャッシュによって格納されるオブジェクトのＵＲＬに対応するダイジェストを格納するダイジェストメモリを備える。複数の網フロー交換機がクラスタ化される場合は、分散ダイジェストメモリのコンテントがクラスタ内で共有される。こうして、オブジェクト検索（ｏｂｊｅｃｔ ｌｏｏｋ−ｕｐｓ）がより完全なものとなることに加えて、参照されたオブジェクトを含む可能性のあるローカルオブジェクトキャッシュを識別することも可能となる。
【００１３】
一つの構成においては、キャッシュダイジェストは、キャッシュ内の頻繁にリクエストされるデータオブジェクトのメモリ位置を指すポインタから成る。典型的には、ダイジェストは少なくとも一部はＵＲＬに基づき、１を疎に含むビットベクトルから成る。このベクトルの次元によってキャッシュダイジェストの集合の容量が決まり、これはキャッシュ内のオブジェクトの数にキャッシュダイジェストの次元を乗じた値として設定される。キャッシュダイジェストの次元は、あるＵＲＬダイジェストと関連するハッシュ関数或いはハッシュ成分の数によって決まる。ハッシュ成分のあるキーに対する値は、そのベクトルへの対応するビットのみが１にセットされた索引（インデックス）を表す。全てのキャッシュダイジェストの集合は、全てのキャッシュされたオブジェクトのダイジェストベクトルの論理ＯＲから構成されるビットベクトルから成る。
【００１４】
本発明のアーキテクチャ及び方法は従来の技術と比較して幾つかの長所を有する。
第一に、この交換機は、他のタイプの網交換機と比較して、著しく計算効率が良いことに加えて、メモリを大幅に節約することができる。キャッシュを用いる従来のフロー交換機は、典型的にはその交換機によって処理された信号に対応するオブジェクトのテーブルを維持する。この交換機は、スイッチングの決定を行う度に、そのオブジェクトと関連するポインタを見つけるために、テーブルを上から下まで或いは下から上まで探索する。テーブルのどちら側が最初に探索されるかによって、テーブルの上側或いは下側に位置するオブジェクトはより短い探索時間を要し、テーブルの反対側に位置するオブジェクトはより長い探索時間を要する。各スイッチング決定のために過剰な計算資源が費やされ、このために交換機の容量が制限される。加えて、テーブルを収容するために過剰なメモリ空間が要求され、このため、定期的に、オブジェクトの有効寿命が満了する前に、オブジェクトをフラッシュ（除去）することが必要となる。本発明の方法においては、プロセッサはダイジェスト値から直接に探索されているオブジェクトの位置を知ることができるために、スイッチング決定が行われる度にデーブルを探索する必要はなくなる。
【００１５】
第二に、この交換機は、Ｐｏｒｔ ８０トラフィックリダイレクティング交換機（Ｐｏｒｔ ８０ ｔｒａｆｆｉｃ ｒｅｄｉｒｅｃｔｉｎｇ ｓｗｉｔｃｈｅｓ）と比較して、キャッシュサーバクラスタ（つまり、キャッシュされたページの単一の貯蔵庫として機能する複数のキャッシュサーバの相互接続された網）によって要求されるメモリ及び計算資源を削減でき、同時に、同程度の帯域幅の節約を維持することができる。「キャッシュサーバ（ｃａｃｈｅ ｓｅｒｖｅｒ）」は、オリジンサーバに向けられたトランザクションリクエストに割り込み、これらリクエストに答えて自身のメモリから要求された情報を供給する。ここで、「オリジンサーバ（ｏｒｉｇｉｎ ｓｅｒｖｅｒ）」とは、ある選択されたトランザクションリクエストが最初にそれに向けられた、或いはそのリクエストがそれから最初に発信されたサーバ（例えば、パケットクッキーにて識別されるサーバ）を表す。ポート８０交換機の場合は、これらキャッシュサーバの所で、キャッシュヒット或いはキャッシュミスが存在したか否かに関係なく、全ての接続を終端し、再び長期間アクセスされることはないようなオリジンサーバからのも含めて全てのページをキャッシングすることを要求される。これに対して、本発明による交換機は、これら二つの問題を解決するために、以前キャッシュヒットがあったリクエストに対してワイヤ速度のスイッチングを提供し、キャッシュミスがあったリクエストに対しても、それらの大多数に対してワイヤ速度スイッチングを提供することに加えて、ホットＵＲＬとオリジンＨＴＴＰサーバを識別することで、キャッシュサーバのキャッシュヒット率を向上させる。
【００１６】
第三に、この交換機はサーバファームに対する逆方向プロキシ（ｒｅｖｅｒｓｅ ｐｒｏｘｙ）として機能し、サーバファームに代ってクライアントからの全ての接続リクエストを傍受及び受理する。
【００１７】
第四に、ＨＴＴＰとＨＴＴＰＳ形式のリクエスト及び応答がこの逆方向プロキシを通過するとき、この交換機は、サーバにて生成されたクッキーを解析し、ユーザリクエストに答えてシームレスな処理を提供する。
【００１８】
第五に、この交換機は、入りトラフィックフローに関して、フローフィルタリング、分別、トラフィックパターン学習、及び優先シェーピング（ｐｒｉｏｒｉｔｙ ｓｈａｐｉｎｇ）を遂行することができる。
【００１９】
第六に、この交換機は、ブラウザからの全てのＨＴＴＰトラフィックを傍受し、これらをＨＴＴＰキャッシュサーバに向けられるように戦略的に配置され、クライアントに対してより高速な応答とより快適なウェブサーフィング体験を提供することができる。
【００２０】
最後に、これら交換機は高度にスケーラブルであるために、これら交換機を一つのクラスタに構成し、ダイジェスト情報及び／或いはタグ情報をそのクラスタ内の様々な交換機にて共有することができる。こうして情報を共有することで、冗長性のみでなく、スケーラビリティも向上される。
【００２１】
上に説明の実施形態及び構成は、完全なものでも、全てでもない。後の説明から明らかとなるように、上に説明した或いは以下に詳細に説明する一つ或いは複数の構成要件を単独にて或いは組合せて用いる他の形態も可能である。
詳細な説明
【００２２】
網交換機の構成要素
本発明は、好ましくは図１にコンテントダイレクタサーバ（ｃｏｎｔｅｎｔ ｄｉｒｅｃｔｏｒ ｓｅｒｖｅｒ）として示されるようなサーバコンピュータシステム（ｓｅｒｖｅｒ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ）として実現される。複数のコンテントダイレクタサーバａ−ｎが、一つの好ましい実施例においては電子商取引タイプのＨＴＴＰトランザクションをサポートするために一つのクラスタにグループ化される。サーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）１０４は、オリジンサーバ（ｏｒｉｇｉｎ ｓｅｒｖｅｒ）１０８、ダイナミックコンテントサーバ１１２及び／或いはキャッシュサーバ１１６を含む。トラフィックマネジャ１２０ ａ−ｎは、周知の技法を用いて、複数のコンテントダイレクタから構成されるクラスタ間の負荷バランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）を遂行する。ルータ１２８ ａ−ｎから構成されるルータプール（ｒｏｕｔｅｒ ｐｏｏｌ）１２４は、パケットを通信網１３２からのトラフィックマネジャ１２０ ａ−ｎへとルーティングする。
【００２３】
各コンテントダイレクタサーバは、図２にその概略を示すように、ＨＴＴＰトランザクションを、ＩＰデータパケット内のこれと関連する不変量に基づいて効率的にルーティングするためのインテリジェントフロースイッチ２００を含む。オプションとして、ＳＳＬプロセッサ２０４を設け、機密セッションの協議（ｓｅｃｕｒｅ ｓｅｓｓｉｏｎ ｎｅｇｏｔｉａｔｉｏｎ）と実際の計算（ａｃｔｕａｌ ｃｏｍｐｕｔａｔｉｏｎｓ）の両方において行われる暗号化及び復号動作をオフロードにて遂行することもできる。更に、オプションとして、キャッシュプロセッサ２０８を設け、頻繁にリクエストされるコンテントすなわち「ホット（ｈｏｔ）」コンテントをキャッシュ２１２内にキャッシュ（格納）することもできる。ダイジェスト発生器２１６によってＵＲＬダイジェストが生成され、ローカルダイジェストメモリ２２０内に格納されると共に、複製され、直接に或いは間接的に、同一クラスタ内の他の網フロースイッチに送られる。
【００２４】
コンテントダイレクタ１００は、ＨＴＴＰトラフィックをリダイレクティングする過程において、ＨＴＴＰリクエストのトラフィックパターンを、クライアントブラウザ（図示せず）によってリクエストされたＵＲＬ識別子を監視することで学習する。可変閾値（ホットＵＲＬ閾値）が超えられると、新たに見つけられたホットな（オリジン）サーバに向けられたＨＴＴＰリクエストの全てのトラフィックフローはキャッシュサーバ１１６にリダイレクトされる。「フロー（ｆｌｏｗ）」なる語句は、クライアントとサーバ間、或いはある接続セッションにおける二つのピア間の、全てのトランザクションを指す。他方、あまりアクセスされないＵＲＬに対するリクエストは、キャッシュサーバ１１６にではなく、直接にオリジンサーバ１０８にスイッチされる。一つの動作モードにおいては、コンテントダイレクタは全てのＨＴＴＰトラフィックを透明に傍受し、これをキャッシュサーバ１１６に、特別なプロトコル或いはパケットタグを付加することなく、リダイレクトする。キャッシュサーバ１１６はクライアント（図示せず）との間にスプーフ接続（ｓｐｏｏｆ ｃｏｎｎｅｃｔｉｏｎｓ）を形成する。コンテントダイレクタは、更に、キャッシュサーバのクラスタのメンバへのＨＴＴＰトラフィックを、周知の技法、例えばラルンドロビン方式或いは扱われた接続の数（ａ ｎｕｍｂｅｒ−ｏｆ−ｃｏｎｎｅｃｔｉｏｎｓ−ｓｅｒｖｅｄ）に基づいて負荷バランスする。
【００２５】
コンテントダイレクタ１００は、ＨＴＴＰでないトラフィックをその元の宛先にスイッチすると共に、最初は、全てのＨＴＴＰフローを、それらの自身のオリジンサーバ１０８にスイッチする。リクエストされたＵＲＬをワイヤ上でコンテントダイレクタにてスヌープ（監視）することで、トラフィックパターンのホットなＵＲＬのデータベースが構築される。ＵＲＬ識別子のメッセージダイジェストが、キャッシュ２１２内の、ホットなＵＲＬのデータベース或いはテーブル内に格納される。ある幾つかのサーバへのフローがホットになると（つまり、ある所定の時間期間内に受信されたサーバ内のあるオブジェクトに対するリクエストの数がホットＵＲＬ閾値に達する或いはこれを超えると）、そのサーバのＩＰアドレスがホットなＩＰのデータベース内に入れられ、その後は、そのホットウェブサーバへの新たな接続は、コンテントダイレクタによってＨＴＴＰキャッシュサーバ１１６にリダイレクトされる。こうしてリダイレクト或いはスイッチされたフローは、スイッチドフロー（ｓｗｉｔｃｈｅｄ ｆｌｏｗ）と呼ばれ、オリジンサーバに向かうスイッチされなかったフローは、転送フロー（ｆｏｒｗａｒｄｅｄ ｆｌｏｗ）と呼ばれる。
【００２６】
コンテントダイレクタ１００は、同一のオリジンサーバ１０８に向かう未処理のフローを、リダイレクトされるまで維持し、それらフローが互いに妨害しあうことなく完結できるようにする。ＨＴＴＰ接続の仮想回路が、ブラウザ（或いはそのプロキシ）（図示せず）とオリジンサーバ（或いはそのプロキシ１０８）との間、ブラウザ（図示せず）と透明なＨＴＴＰキャッシュサーバ１１２との間、及びＨＴＴＰキャッシュサーバ１１２とオリジンサーバ１０８との、全ての間で維持される。ここで用いられる「仮想回路（ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ）」なる語句は、二つのエンドポイント間に設定されたＴＣＰ／ＩＰ接続を意味する。
【００２７】
ホットなサーバへのトラフィックパターンが冷えると、そのＩＰアドレスは年齢が過ぎたものとしてキャッシュ２１２内のホットなＩＰ或いはＵＲＬデータベースから削除され、そのサーバへのトラフィックはその通常のフローへと戻される。以下ではコンテントダイレクタのこれら様々な構成要素についてより詳細に説明する。
【００２８】
ＳＳＬプロセッサ
ＳＳＬプロセッサ２０４は、認証及び機密アソシエーション（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）を遂行し；暗号アルゴリズムの協議に参加し、マスタシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）を確立し、セッションキーを計算し、セッションＩＤを割当て；ＨＴＴＰＳメッセージを暗号テキストにて扱い、これらを、トランザクションリクエストを平文テキストにて扱うＨＴＴＰサーバに中継し；セッションコンテクストをセッションＩＤと共に再接続に備えてキャッシングする。後に説明するように、初期ＳＳＬハンドシェークは、暗号器（ｃｉｐｈｅｒ）の選択、マスタキーの交換、及びサーバの認証を扱う。このハンドシェーク段階が完了した後に、クライアントとサーバは、暗号アルゴリズムに関して同意し、メッセージを暗号化するためのセッションキーを導くためにマスタシークレットに関して同意し、さらにサーバによって同意されたコンテクストを識別するために割当てられるセッションＩＤに関して同意する。後に説明するように、ＳＳＬプロセッサは、典型的には、クライアントとの保護されたセッションを開始する前に、クライアントとの無保護のセッションを終端する。
【００２９】
ＳＳＬセッションＩＤは、複数のＳＳＬセッションに共通なスレッドである（共通に用いられる）。ＳＳＬｖ３においては、セッションＩＤは、ＴＣＰ接続上を、第二及びその後の接続を通じて、平文にて輸送される。ＳＳＬｖ２においては、ＳＳＬサーバが初期ハンドシェークにおいてセッションＩＤを送り返す最初の時点から、セッションＩＤは暗号化される。セッションＩＤを見つけるためには、プロセッサは、機密コンテクスト（ｓｅｃｕｒｅ ｃｏｎｔｅｘｔ）の確立に関与することを要求されるが、サーバからこの暗号処理をオフロードすることで、暗号加速化資源（ｒｅｓｏｕｒｃｅｓ ｏｆ ｃｒｙｐｔｏｇｒａｐｈｉｃ ａｃｃｅｌｅｒａｔｉｏｎ）をファーム１０４内の全てのサーバによってより効率的に利用することが可能となる。
【００３０】
上述のように、ＳＳＬプロセッサ２０４は、再接続のために、セッションコンテクストとセッションＩＤ、機密アソシエーション、及び仮想ホット情報をキャッシュする。ＳＳＬプロセッサのキャッシュ（図示せず）内のエントリは典型的にはセッションＩＤを用いて索引付けされる。
【００３１】
ＳＳＬプロセッサは、認証及び／或いは暗号化／復号を遂行するための任意の従来のハードウェア／ソフトウェアであり得る。後に説明するように、用途によっては、例えば、Ｖｉｒｔｕａｌ Ｐｒｉｖａｃｙ Ｎｅｔｗｏｒｋｓ（「ＶＰＮ」）（或いはＩＰｓｅｃ）においては、クライアントとサーバ間にＳＳＬ以外の機密プロトコルを用いることもできる。
【００３２】
インテリジェントフロースイッチ
インテリジェントフロースイッチ（ｉｎｔｅｌｌｉｇｅｎｔ ｆｌｏｗ ｓｗｉｔｃｈ、ＩＦＳ）２００（スイッチ要素とも呼ばれる）は、サーバファーム１０４内のサーバの一つを、パケットのペイロード、例えば、埋め込まれた不変量に基づいて選択し、リクエストを選択されたサーバに転送し、サーバから応答を受信し、これらをクライアントに送り返す。これらリクエスト及び応答メッセージがＩＦＳを通過するとき、ＩＦＳはサーバにて生成された不変量或いは機密セッション不変量を解析することで、ファーム内の選択されたサーバへのクライアントリクエストをシームレスに途切れることなく処理する。ＩＦＳは、ＨＴＰＰ応答を、サーバ生成クッキーを見つけるために解析すると共に、ＨＴＰＰリクエストを、ユーザ返送クッキーを見つけるために解析する。ＩＦＳは、同一クッキーにてスレッドされた（送られた）全てのトランザクションを束ね、そのクッキー不変量を生成したサーバに向ける。不変量アソシエーション（ｉｎｖａｒｉａｎｔ ａｓｓｏｃｉａｔｉｏｎｓ）に関する知識を複数のコンテントダイレクタ１００間で共有し、ＣＰＵ時間を多量に消費する暗号計算を分散処理にオフロードすることで、ＩＦＳは、サーバファームの総合的な故障耐性と性能の向上に寄与すると共に、電子商取引インフラストラクチャを需要に応じて成長させることを可能にする。
【００３３】
ＩＦＳメモリは、ＩＦＳ動作を可能にするためにメモリ内に複数のデータオブジェクトを維持する。例えば、ＩＦＳは、オプションとして：網マネジャによって選択された、異なるタイプのパケット（例えば、「ホット」なパケット、「冷たい」パケット等）に対してサーバを選択するための規則及び／或いは方針のレコード；ＩＰアドレス検索用のテーブル；及び（ワイヤ速度パケット交換用の全ての現仮想回路のレコードを維持するために用いられる）現接続テーブルを含み、これには、ソース不変量（例えば、ＵＲＬ、ポートアドレス、及び他の決められたフィールド）、宛先不変量（例えば、ＵＲＬ、ソースソケット３−タプル、及び他の決められたフィールド）、セッションＩＤ、対象ＵＲＬに対してあるクライアントからの最後のパケットが受信した時刻を示す永続性タイムスタンプ（これはテーブルから所定の年齢に達した或いはこれを超えたエントリを除去するために用いられ、この年齢はクライアントが同一トランザクション或いはセッションの一部として送り返す尤度を最後のパケットが受信された時間に基づいて統計的に推定することで求められる）、クッキー名と値、及び／或いは他の選択された不変量が含まれる。ＩＦＳは、更にオプションとして、コンテントダイレクタによって生成されたタグを含むタグテーブルと、ソース及び宛先不変量を含む。現接続テーブル及び／或いはタグテーブル内の各エントリは、ソース不変量、宛先不変量、及び／或いはクッキー名と値の一つ或いは幾つかを用いて索引付けされる。
【００３４】
キャッシュプロセッサ及びキャッシュ
キャッシュプロセッサ２０８は、ＩＦＳ２００と、キャッシュ２１２、ダイジェスト発生器２１６及びダイジェストメモリ２２０との間のプロセッサインタフェースとして機能する。キャッシュプロセッサは、こうして、ＩＦＳ２００によってリクエストされた、パケット内に含まれ、ＩＦＳ２００によって解析され、キャッシュプロセッサ２０８に転送されたペイロード不変量に対応するキャッシュ２１２及び／或いはダイジェストメモリ２２０内に格納されているデータを取り出す。
【００３５】
キャッシュ２１２は、頻繁にリクエストされる「ホット」なコンテント（例えば、ＵＲＬ）と、それほど頻繁にはリクエストされないコンテント（例えば、ＵＲＬ）の両方を含むホットＵＲＬテーブルを含む。このホットＵＲＬテーブルは、典型的には、以下のフィールド、すなわち：ソース不変量（例えば、ＵＲＬ、ポートアドレス、及び他の関連するフィールド、例えば、ホットコンテント、一次ＵＲＬと対応する或いはこれと関連する二次ＵＲＬ、或いは他のタイプの修飾子）、宛先不変量（例えば、ＵＲＬ、ソースソケット３−タプル、及び他の決められたフィールド）、クッキー名と値、あるエントリが最後に更新されたときを示す（ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる）タイムスタンプ、ヒットカウンタ、オプションとしての（タグモードの際にスイッチによって生成される）タグ、及び／或いは他の選択された不変量を含む。ホットＵＲＬテーブル内の各エントリは、典型的には宛先不変量及び／或いはクッキー名と値を用いて索引付けされる。
【００３６】
リース条件（ｌｅａｓｅ ｔｅｒｍ）は典型的には網マネジャによって決められた規則或いは方針から成る。リース条件には、例えば、レコードの最大寿命、サーバ或いはサーバクラスタのクライアントによるアクセスに関しての制約或いは制限、パケットに対するホットな場合のルーティング指令、コンテントがどの程度ホットであるか、優先、選択されたコンテントへのアクセスに関する制限、ヒットカウンタのリセット方針などが含まれる。
【００３７】
ダイジェスト発生器及びダイジェストメモリ
ダイジェスト発生器２１６は、キャッシュプロセッサ２０８から宛先不変量（例えば、ＵＲＬ及びクッキー値）を受信し、これら不変量をダイジェストに変換する。どのようなダイジェスティング法を用いることもできるが、好ましくは、ハッシング法が用いられる。好ましいハッシングアルゴリズムは以下の通りである：
Ｌ ＝ ｈ（Ｋ）
ここで、全てのキーＫに対して、０≦Ｌ≦Ｍ
【００３８】
ここで、Ｋは選択されたＵＲＬ或いはＵＲＬ識別子の一部或いは全てを表し、ｈはメッセージダイジェスト（ｍｅｓｓａｇｅ ｄｉｇｅｓｔ、ＭＤ）「指紋（ｆｉｎｇｅｒｐｒｉｎｔ）」Ｋを入力引数として用いるハッシュ関数を表し、ＬはホットＵＲＬテーブル内のＫの位置を表し、ＭはホットＵＲＬテーブルのサイズを表す。
【００３９】
ｈは、計算が速くでき、衝突が最小となるように選択される。衝突は異なるキーＫ´から同一のＬが計算されるときに発生する。衝突が発生した場合は、ホットＵＲＬテーブルのボタムからのかわりの位置が見つけられ、ホーム位置からリンクされる。円形連結リストを用いて同一のハッシュ関数を有する全てのＭＤ「指紋」が連結される。ホーム位置の所のヘッドタグは円形リストのヘッドを指す。新たなレコードが見つかると、かわりの位置内のレコードがそのホーム位置を占拠するために、そのかわりの位置のレコードは撤去することを要求される。そのホーム位置内のレコードが削除されると、衝突チェーン内の別のレコードがそこに移動される。理解できるように、用途に応じて他のハッシング関数を用いることもできる。
【００４０】
ダイジェストメモリによって保持されるダイジェストレコードは、通常は、図３に示すような形式を有する。ダイジェストレコードが複製されるとき、キャッシュ識別子３００（これはハッシュ値と同一であり、図にはＭＤ５値として示されている）が、その後のダイジェスト検索においてもリクエストされたオブジェクトを含む特定のローカルオブジェクトキャッシュの識別が生成されるようにそれらダイジェストレコードに付加される。このレコードは、さらに、サーバの宛先ＩＰアドレスを参照する宛先ＩＰ３０４、リース条件３０８、ヒット或いはアクセスカウンタ、（ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる）あるエントリがいつ最後に更新された時刻を示すタイムスタンプ（図示せず）、及び／或いは他の選択された不変量を含む。
【００４１】
あるＵＲＬオブジェクトに対するリクエストが受信されると、コンテントダイレクタ１００は、そのピア（ｐｅｅｒ）からのキャッシュダイジェスト３００を用いて、そのピアのどれが所望のオブジェクトを有するかを見つけ、そのダイレクタのピアからそのオブジェクトを、全てのネーバ（ｎｅｉｇｈｂｏｒ）に照会を送ることなく、取り出す。上の説明から明らかなように、キャッシュダイジェスト３００は、キャッシュされているコンテンツのコンパクトな形式での要約、或いはある特定のＵＲＬがそのキャッシュ内に存在するか否かの指標から成る。換言すれば、キャッシュダイジェスト３００は、キャッシュ２１２のメモリ内の、そのハッシュに対応する一つ或いは複数のオブジェクトが置かれた特定の位置に対するポインタから成る。
【００４２】
入りパケットに対するコンテントダイレクタの動作
以下ではコンテントダイレクタの動作を図１−７との関連で説明する。
図４のステップ４００において、（トラフィックマネジャ１２０（図１）によって負荷バランスされた）入りパケットがＳＳＬプロセッサ２０４（図２）によって受信される。ＳＳＬプロセッサ２０４は、ステップ４０４において、最初に、周知の技法を用いて機密アソシエーションと認証を遂行することで、クライアントの識別及び／或いはクライアントのそのウエブサイトへのアクセス権を検証する。これは典型的にはデジタル証明認証を用いて遂行される。
【００４３】
ステップ４０８において、ＳＳＬプロセッサ２０４は、そのパケットが暗号化されているか否かを調べる。暗号化されているときは、プロセッサ２０４は、ステップ４１２において、そのパケットを周知の技法を用いて復号することで、暗号テキストを平文テキストに変換する。ステップ４１６において、平文テキストのパケットがＩＦＳ２００（図２）に、更なる処理のために送られる。ＳＳＬプロセッサ２０４は、その後、次のパケットを処理するためにステップ４００に戻る。
このパケットが、図５のステップ５００において、ＩＦＳ２００によって受信される。
【００４４】
ＩＦＳは、ステップ５１６において、そのパケットがＨＴＴＰ接続であるか否か調べる。そうでない場合は、ＩＦＳは、ステップ５２０において、そのパケットをオリジンサーバに送り、その後、ステップ５００に戻る。
【００４５】
そのパケットがＨＴＴＰ形式であるときは、ＩＦＳは、ステップ５２４において、そのパケットを解析し、選択されたフィールド、例えば、ＵＲＬやクッキー（存在する場合）などの宛先不変量、ソース不変量、及び／或いは他のペイロード不変量を得る。永続性ＨＴＴＰ接続（ｐｅｒｓｉｓｔｅｎｔ ＨＴＴＰ ｃｏｎｎｅｃｔｉｏｎ）においては、クライアントは、単一の接続にて、複数のリクエストを送り、同数の応答がサーバからリクエストの順番に送り返される。ＩＦＳは、各リクエストを走査することで、そのクッキーを得、そのクッキー永続性（ｃｏｏｋｉｅ ｐｅｒｓｉｓｔｅｎｃｅ）に基づいてサーバアソシエーション（ｓｅｒｖｅｒ ａｓｓｏｃｉａｔｉｏｎ）を作成する。ＩＦＳは、従って、単一のマルチリクエスト（ｓｉｎｇｌｅ ｍｕｌｔｉｐｌｅ ｒｅｑｕｅｓｔ）を、複数の単一リクエスト（ｍｕｌｔｉｐｌｅ ｓｉｎｇｌｅ ｒｅｑｕｅｓｔｓ）に分解し、これらを、それぞれ、各々のリクエスト内に埋め込まれているクッキーに基づいて正しく選択されたサーバに送ることを要求される。ＩＳＦは、加えて、サーバからの応答を追跡し、これらをリクエストと同一の順序にて、クライアントに送り返すことを要求される。
【００４６】
ステップ５０４において、コンテントダイレクタ１００が、タグモードであることが決定されたときは、コンテントダイレクタ１００は、ステップ５０８に進み、（そのパケット内にタグが既に存在しない場合は）タグを生成する。コンテントダイレクタ１００は、宛先不変量に基づいてタグを生成し、そのタグをクッキー上に連結する。クライアントに応答が送られたとき、これらクッキー及び付加されたタグは、ブラウザによってそのクライアントのメモリ内に保存される。クライアントによってさらなるリクエストが送られるとき、これらクッキーと付加されたタグがそのパケットリクエストのペイロード内に挿入される。コンテントダイレクタ１００は、これを解析することでクッキーを得、タグを識別し、パケットをそのタグと関連するサーバに直接に向ける（ダイレクトする）。そのクライアントがまだそのサーバファームに一度も訪問したことがないために、パケットがクッキーを有さないときは、そのサーバファームから応答がコンテントダイレクタ１００によって受信されたとき、タグが生成され、そのクッキー上に連結される。ある一つのリクエストに対して、ドメイン、パス、及び最大年齢（ｍａｘ−ａｇｅ）の選択基準を満たす複数のクッキーが送り返されたときは、サーバ永続性（ｓｅｒｖｅｒ ｐｅｒｓｉｓｔｅｎｃｅ）は最も制限的なパス属性を有するクッキーを用いて決定される。次に、ステップ５１２において、そのパケットがオリジンサーバに転送され、ＩＦＳは、ステップ５００に戻り、次のパケットを待つ。
【００４７】
一つの構成においては、タグは、トランザクションリクエスト内のＵＲＬを扱うキャッシュ或いはオリジンサーバに基づいて生成される。各サーバには、一意のサーバ識別子（アルファベット、数字、或いは英数字）が割り当てられる。ＩＦＳは、対象サーバに対応する一意なサーバ識別子を決定し、この識別子をそのパケット内の別のタグ、例えば、そのサーバによって生成されたクッキーに付加する。タグのビットサイズは、通常は、クッキーのサイズよりかなり小さい。一つの構成においては、タグは、前の応答がサーバによってクライアントに転送されたとき（或いはサーバからの出フローがスイッチを通過するとき）にのみ生成され、クッキーに付加される。
【００４８】
コンテントダイレクタは一つモードにて動作することも、複数のモードにて動作することもできる。一つの構成においては、コンテントダイレクタはタグモードのみにて動作する。もう一つの構成においては、コンテントダイレクタはダイジェスティング（ｄｉｇｅｓｔｉｎｇ ｍｏｄｅ）のみにて動作する。ダイジェスティングモードにおいては、ダイジェストが生成され、コンテントのホットさ（ｈｏｔｎｅｓｓ）が監視され、トランザクションリクエストは、ホットさ及び／或いはクッキーに基づいてサーバにルートされる。もう一つの構成においては、コンテントダイレクタは、同時に両モードにて動作する。換言すれば、最初に、あるトランザクションに対して、クライアントとサーバがリクエストされたコンテントのホットさに基づいてペアリングされ、同一クライアントからのその後のトランザクションリクエストは、そのクライアントに最初に割当てられた各々のサーバと関連するサーバタグを含み、各々のサーバに直接にルートされる。
【００４９】
スイッチクラスタ内では、スイッチクラスタがより効率よく動作できるように、ある一つのスイッチによって生成されたタグは、そのクラスタ内の他のスイッチに供給され、クラスタ内の他のスイッチは、埋め込まれたタグを含むその後送られるトランザクションリクエストを受信できるようにされる。
【００５０】
コンテントダイレクタがタグモードにないときは、ＩＦＳは、ステップ５２８において、不変量フィールドをキャッシュプロセッサ２０８に転送する。
【００５１】
キャッシュプロセッサは、図６のステップ６００において、ＩＦＳから、これら宛先、ソース、及び／或いは他のペイロード不変量を受信する。キャッシュプロセッサ２０８は、ステップ６０４において、これら不変量をキャッシュ２１２内のホットＵＲＬテーブルと比較し、ステップ６０８において、そのコンテントが以前所定の時間期間（永続性期間）内に受信されたか否か決定し、受信された場合は、ステップ６１２において、そのコンテントがホットであるか否か決定される。一つの構成においては、キャッシュプロセッサは、クッキーの名前とその値を、テーブル内にリストされているそれらと比較する。一致する場合は、そのパスがそのＵＲＬと比較され、ヘッドが一致するか調べられ、一致するエントリ（ｍａｔｃｈ ｅｎｔｒｙ）から宛先サーバが決定される。
【００５２】
そのコンテントが永続性期間内に以前リクエストされてないときは、キャッシュプロセッサ２０８は、ステップ６１６において、そのパケットが「ＨＴＴＰ ＧＥＴ」リクエストであるか否か決定する。「ＨＴＴＰ ＧＥＴ」リクエストでない場合は、キャッシュプロセッサ２０８は、ステップ６２０（後の説明）に進む。「ＨＴＴＰ ＧＥＴ」リクエストである場合は、キャッシュプロセッサ２０８は、ステップ６２４において、不変量をダイジェスト発生器２１６に送る。
【００５３】
ダイジェスト発生器２１６は、図７のステップ７００において、キャッシュプロセッサからダイジェストリクエストを受信する。ダイジェスト発生器は、ステップ７０４において、宛先関連不変量に対するダイジェストを生成し、ステップ７０８において、ダイジェスト、タイムスタンプ、宛先関連不変量、及びリース条件（ダイジェスト発生器はこれらリース条件をダイジェストメモリ内の規則／方針に基づいて決定する）をダイジェストメモリ２２０内にコピーし、ステップ７１２において、これらダイジェスト、タイムスタンプ、及びリース条件をキャッシュプロセッサ２０８に送る。ダイジェスト発生器は、次に、ステップ７００に戻る。
【００５４】
図６に戻り、キャッシュプロセッサは、ステップ６２８において、ダイジェスト発生器２１６からダイジェスト、タイムスタンプ、及びリース条件を受信し、ステップ６３２において、参照カウンタを初期化する。次に、キャッシュプロセッサ２０８は、ステップ６３４においてホットＵＲＬテーブルを更新し、ステップ６２０（後に説明）に進む。
【００５５】
ステップ６０８において、パケット情報がホットＵＲＬテーブル内に存在する場合は、キャッシュプロセッサは、次に、ステップ６１２において、パケットによってリクエストされたコンテントがホットであるか否か決定する。パケットのＵＲＬは、ヒットカウンタが所定のレベル、すなわち、ホットＵＲＬ閾値以上であるときはホットである。ＵＲＬがホットな場合は、ステップ６３６において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ６３８において、ホットＵＲＬテーブルがこれを反映するように更新される。キャッシュプロセッサ２０８は、次に、ステップ６２０（後に説明）において、関連する応答をＩＦＳに送る。ＵＲＬがホットでない場合は、ステップ６４２において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ６４６において、ホットＵＲＬテーブルが更新される。ステップ６５０において、キャッシュプロセッサは、再び、そのＵＲＬが（増分されたカウンタの観点から）ホットＵＲＬ閾値を超えるか否か決定する。超えない場合は、キャッシュプロセッサはステップ６２０（後に説明）に進む。超える場合は、キャッシュプロセッサは、ステップ６５４において、逆ドメイン名サービス（ｒｅｖｅｒｓｅ ｄｏｍａｉｎ ｎａｍｅ ｓｅｒｖｉｃｅ）すなわちＤＮＳ検索を遂行することで、そのホットＵＲＬページを扱った特定のドメインを扱っている全てのＩＰアドレスを見つける。ステップ６５８において、これらアドレスがホットＵＲＬテーブル内に書込まれる。キャッシュプロセッサは、ステップ６２０に進む。
【００５６】
ステップ６２０において、キャッシュプロセッサ２０８は、関連する応答をＩＦＳに送る。パケットによってリクエストされたコンテントがホットである場合は、キャッシュプロセッサは、ＩＦＳに、コンテントがホットであることを示とともに、パケット内のその特定のＵＲＬを扱っているＩＰアドレスのリストを与えるメッセージを送り、任意の関連するリース条件を供給する。一つの構成においては、キャッシュプロセッサは、加えて、ＩＦＳに、ホットさの程度（ｄｅｇｒｅｅ ｏｆ ｈｏｔｎｅｓｓ）、例えば、ヒットカウンタの値を知らせる。パケットによってリクエストされたコンテントがホットでない場合は、キャッシュプロセッサは、ＩＦＳに、そのコンテントがホットでないことを示すメッセージを送り、任意の関連するリース条件を供給する。
【００５７】
図５に戻り、ＩＦＳ２００は、ステップ５３０において、キャッシュプロセッサ２０８からの応答を受信する。ＩＦＳ２００は、次に、ステップ５３２において、そのペイロード内の解析されたフィールド（例えば、ソースＩＰ、宛先ＩＰ、ソースソケット３−タプル）を現接続テーブル内にリストされるそれらと比較する。ステップ５３４において、一致が存在しない場合は、ＩＦＳ２００は、ステップ５３６において、新たな接続が存在するか（すなわち、そのパケットが現存の仮想回路の一部であるか）否かを決定する。この決定は、ＩＦＳがその接続に対して受信した第一のパケット内のヘッダフラグ（ＳＹＮ）を調べることで遂行される。ＳＹＮフラグがセットされてないときは、そのパケットは現存の仮想回路には属さないものとみなされ、ＳＹＮフラグがセットされているときは、そのパケットは、そのサーバがホットになる前にクライアントとオリジンサーバとの間に設定された仮想回路に属するものとみなされる。接続が新たなものであるときは、ステップ５４０において、現接続テーブルが更新される。つまり、そのパケットペイロードの少なくともソースＩＰ、宛先ＩＰ、ソースソケット３−タプルを含む新たなエントリが追加される。
【００５８】
接続が新たなものであるか、古いものであるかに関係なく、ＩＦＳは、次に、ステップ５４４において、パケットペイロード内のＵＲＬがホットであるか否か決定する。ＵＲＬがホットでない場合は、ＩＦＳはステップ５４８に進む。ステップ５４８において、ＩＦＳは、パケットをリアセンブルし、ステップ５５２において、パケットをオリジンサーバに送る。ＩＦＳは、次に、次のパケットを処理するためにステップ５００に進む。
【００５９】
ステップ５４４において、パケットペイロードがホットであるときは、ＩＦＳは、ステップ５５６において、関連するホットなキャッシュサーバアドレスを決定する。これは、キャッシュプロセッサ２０８から受信されたホットＩＰアドレスとリース条件のリスト、各ＩＰアドレスに対応するキュー（どのキャッシュサーバが最も短いキューを有するかを決定するために用いられる）、及び／或いはＩＦＳのメモリ内の規則／方針を調べることで行われる。ステップ５６０において、パケットが関連するＩＰアドレスを有するようにリアセンブルされ、ステップ５６４において、関連するキャッシュサーバに送られる。一つの構成においては、ＩＦＳは、Ｃａｃｈｅ Ａｒｒａｙ Ｒｏｕｔｉｎｅ Ｐｒｏｔｏｃｏｌ（ＣＡＰＰ）を用いて、キャッシュ可能なＵＲＬオブジェクトをキャッシュサーバ間に分配する。キャッシュプロキシメンバ識別（ｃａｃｈｅ ｐｒｏｘｙ ｍｅｍｂｅｒ ｉｄｅｎｔｉｔｉｅｓ）とリクエストされたＵＲＬのハッシング計算を行い、最高値を有する経路がルーティング解として決定される。こうして、ＵＲＬは最高のハッシングスコアを有するキャッシュプロキシ（ｃａｃｈｅ ｐｒｏｘｙ）に向けられるために、ＵＲＬキャッシュ位置の再割当てを最小限に押さえることができる。
【００６０】
ＩＦＳは、次に、受信される次のパケットに対してステップ５００を反復する。
再びステップ５３４に戻り、現接続或いは現存する仮想回路が存在する場合は、ステップ５８０において、パケットがオリジンサーバに転送され、その後、ＩＦＳはステップ５００に戻る。
【００６１】
コンテントがホットになった後に、一つ或いは複数のキャッシュサーバがそのコンテントを含むオリジンサーバとの接続を設定することがある。この場合、これらキャッシュサーバは、オリジンサーバからＵＲＬのコピーを得、そのＵＲＬを自身のキャッシュから扱う。
【００６２】
以下では、このキャッシュサーバの動作について、図８との関連で説明する。ステップ８００において、キャッシュサーバはコンテントダイレクタからトランザクションリクエストを受信する。ステップ８０４において、受信キャッシュサーバは、そのパケットを自身で扱うことができるか否かを決定する。サーバは、キャッシュサーバがそのパケットを初めて受信し、まだそのパケット内の特定のＵＲＬをキャッシュ（格納）していないとき、そのパケットリクエスト法がＨＴＴＰ ＧＥＴリクエストではないとき、及び／或いはそのリクエストがキャッシュ可能なタイプのリクエストではないときは、そのパケットを扱うことはできない。キャッシュサーバがそのパケットを扱うことができないときは、キャッシュサーバは、ステップ８０６において、そのパケットをリアドレスし、そのパケットをオリジンサーバに送る。
【００６３】
キャッシュサーバがそのパケットを扱うことができるときは、キャッシュサーバは、ステップ８１０において、そのパケットを処理する。キャッシュサーバはそのパケットをリアドレスし、そのパケットを新たな或いは現存する接続を通じてオリジンサーバにリダイレクトする。オリジンサーバは、そのＵＲＬを（そのＵＲＬがキャッシュ可能であるときは）キャッシュサーバに送り返す。キャッシュサーバは、そのＵＲＬのコピーを保存し、もう一つのコピーをクライアントに送り返す。
【００６４】
キャッシュサーバは、ステップ８０８において、さらなるコンテント（或いはサブＵＲＬ）或いはパイプライン（ｐｉｐｅｌｉｎｅｓ）を、現トランザクションリクエスト内のＵＲＬに対応するコンテント内で参照されているサブＵＲＬのホットさに基づいて先取りする。一例として、そのコンテント内に二つのサブＵＲＬが参照されており、各サブＵＲＬが異なるホットさの程度（その対応するヒットカウンタ内に異なるヒットの数）を有する場合は、キャッシュサーバは最も大きなヒット数を有するサブＵＲＬがクライアントによって次にリクエストされるＵＲＬであるとみなす。キャッシュサーバは、クライアントからの次のトランザクションリクエストが受信される前に、そのＵＲＬに対応するコンテント（或いはそのＵＲＬ自体）を取り出し、こうすることで、後に受信されるリクエストを処理するために要求される時間を大幅に短縮することが可能となる。
【００６５】
ステップ８１２において、キャッシュサーバは、コンテントを、サーバファーム動作が最も効率的に遂行される位置内に格納（キャッシュ）する。例えば、地理的に分散するサーバクラスタにおいては、どのコンテントがホットであるかは、地域或いは位置によって異なる。例えば、ある選択されたコンテントは、第一の地域においては第一のレベルのホットさを有し、第二の異なる地域においては異なる第二のレベルのホットさを有し得る。コンテントは、従って、そのコンテントが最もホットな地域にキャッシュ（格納）される。このやり方においては、第一の地域内のキャッシュサーバと、第二の地域内のキャッシュサーバとは、異なるキャッシングされたコンテントを有することとなる。代替として、ホットなコンテントを、関連するホットなコンテントが格納されているのと同一のサーバクラスタの一部内に格納することもできる。このやり方においては、選択されたコンテントがホットな場合、そのコンテントと関連する全てのコンテントが（それがホットであるか否かに関係なく）コピーされ、そのホットなコンテントと同一のキャッシュサーバクラスタ内に格納される。もう一つの構成においては、あるホットなＵＲＬと関連する幾つかのＵＲＬが周知の技法を用いてそのホットなＵＲＬに連結される。もう一つの構成においては、複数のサーバクラスタが、幾つかのサーバクラスタは第一（或いはそれ以上）のホットさの情報を格納し、第二の異なるセットのサーバクラスタは（第一のホットさより低い）第二のホットさとの情報と、これよりホットな（ただし、第一のホットさよりは低い）コンテントを格納するように積重ねられる。もう一つの構成においては、ホットなコンテントと関連するコンテントは、（その関連するコンテントはホットでなくても）ホットなコンテントと接近して（例えば、同一のキャッシュサーバ或いはキャッシュサーバクラスタ内に）格納される。
【００６６】
一つの構成においては、キャッシュサーバ内のコンテントの位置は、そのコンテントのホットさの程度に基づく。換言すれば、コンテントがホットになるにつれて、そのコンテントは、キャッシュサーバ内の第一の最もアクセス性の良い項目が最も頻繁な（従って最高数の）ヒットを経験し、キャッシュ内の最もアクセス性の悪い或いは最も下の項目は最も少ない頻度（或いは最小数の）ヒットを経験するように、そのキャッシュサーバ内のよりアクセス性の良い或いはより高い位置に移動される。コンテントダイレクタ１００は、コンテントのホットさの程度が時間と共に変動するに基づいて、様々なキャッシュサーバに対して、コンテントのメモリアドレスを再配置（ｒｅｐｏｓｉｔｉｏｎ 或いはｒｅｌｏｃａｔｅ）するように指令する。換言すれば、コンテントダイレクタは、第一の時間において、キャッシュサーバに対して、第一のコンテントをそのサーバ内のコンテントのスタック（積み重ね）の第一に位置に移動するように指令し、コンテントのヒットの頻度が変動した後の第二の時間においては、そのキャッシュサーバに対して、その第一の項目（コンテント）をそのスタック内の第二のより低い或いはより高い位置に移動するように指令する。
【００６７】
後に説明するように、キャッシュサーバは、キャッシュコンテントの新鮮さを定期的にチェック或いは要求に答えて再検証する。キャッシュサーバは、満了タイマを各キャッシュ可能なオブジェクト毎にオブジェクトの人気度、最大年齢、及びコンテントサーバによって施された最後の修正時刻に基づいて調節する。
【００６８】
図１に戻り、複数のコンテントダイレクタ１００ａ−ｎによってクラスタが形成されるが、こうすることでサーバアプリケーションによって確立された不変量（例えば、ダイジェスト、タグ、及びクッキー）に関する知識を共有することができ、冗長性と性能を向上させることが可能となる。これら共有される情報は、図示されるようにリンク１３６によって、全てのクラスタメンバ間に分配される。どの一つのノードも故障の単一ポイントを形成しない。コンテントダイレクタの追加或いは削除などでクラスタが変更される場合、共有される情報の一部のみを再分配することで済む。
【００６９】
理解できるように、アプリケーション層のコンテントダイレクタの深い所にある情報にアクセスすることで、幾つかの予め定義されたトラフィック方針とサービスのクラスを管理することが可能となる。コンテントダイレクタは、サーバファームから設備へのフローパターンを学習し、サービスの提供を需要の突発的変化に適応させ、ユーザによって求められる情報を優先的に供給できるようにする。コンテントダイレクタは、フローフィルタリング、分類、学習、優先シェーピング、及び転送を遂行する。コンテントを意識した制御のために、コンテントダイレクタは、キャッシュ可能なＵＲＬリクエストとキャッシュ不能なＵＲＬリクエストとを分類し、これらを、それらをより良く扱うことができるサーバに向けたり、更には、それらリクエストを自身のキャッシュから処理する。
【００７０】
出パケットに対するコンテントダイレクタの動作
以下では図９との関連でＩＦＳの出パケットフローに対する動作について説明する。ステップ９００において、ＩＦＳは、対応するサーバから応答を受信する。ＩＦＳは、全ての出パケット或いはＨＴＴＰ応答を受信する。ステップ９０４において、ＩＦＳは、選択されたフィールドを解析する（典型的には入りパケットについても同一のフィールドが解析される）。ステップ９０８において、ＩＦＳは、コンテントダイレクタがタグモード（上述）であるか否か決定する。コンテントダイレクタがタグモードにあるときは、ＩＦＳは、ステップ９１２において、そのパケット内のクッキーが新たなクッキーであるか否か決定する。新たなクッキーであるときは、ＩＦＳは、ステップ９１６において、タグを生成し、そのタグを、ステップ９２０において、クッキーに付加し、そのタグを、ステップ９２４において、キャッシュプロセッサに送る。ＩＦＳは、次に、ステップ９２８（後に説明）に進む。クッキーが新たなものではないときは、ＩＦＳは、そのクッキーは既にタグを含むものとみなし、ステップ９２８（後に説明）に進む。コンテントダイレクタがタグモードでないときは、ＩＦＳは、ステップ９３２において、ソースと宛先に関する不変量をキャッシュプロセッサに送る。キャッシュプロセッサは、それら解析されたフィールドがホットＵＲＬテーブル内に存在するか否か調べ、存在しない場合は、それらフィールドをダイジェスト発生器に送る。ダイジェスト発生器は、ダイジェストを生成し、ダイジェストメモリ内にレコードを作成する。ダイジェストはキャッシュプロセッサに送り返され、キャッシュプロセッサは、ＵＲＬテーブル内のそのダイジェストに対応する位置にレコードを作成する。ＩＦＳは、ステップ９２８において、パケットをリアセンブルし、そのパケットを、ステップ９３６において、ＳＳＬプロセッサを介してクライアントに送る。
【００７１】
上では本発明がソフトウェアに基づく実現との関連で具体的に説明されたが、本発明は、ハードウェアに基づくデバイス（例えば、特定用途向け集積回路、ＡＳＩＣ）として実現することも、更には、ソフトウェアとハードウェアの両方に基づくデバイスとして実現することもできる。
【００７２】
上では本発明がインタネットとの関連で説明されたが、本発明は、その網が回路スイッチ網であるかパケットスイッチ網であるか、コネクションレス網であるかコネクションオリエンテッド網であるか、同期網であるか非同期網であるか、シリアル伝送を用いるかパラレル伝送を用いるか、クラスタ／サーバアーキテクチャを用いるかピア・ツウ・ピアアーキテクチャを用いるか、及び／或いは他の網アプリケーションを用いるかに関係なく、他の網トポロジ上でも採用できる。ホットさ或いはタグを決定するために、クッキー或いはＵＲＬ以外のアプリケーション不変量を用いることもできる。
【００７３】
本発明の様々な変形及び修正態様を用いることができる。本発明の幾つかの特徴の一部のみを、他の特徴は省略して、用いることもできる。例えば、一つの代替実施例においては、コンテントダイレクタは、サーバからクライアントへの応答についても、ペイロード情報（例えば、ソースＩＰ、宛先ＩＰ、クッキー名と値、等）に関して解析する。この情報が、一つ或いは複数の現接続テーブル及びホットＵＲＬテーブルに付加される。この実現は、サーバファームに出入りするトラフィックフローに関するより総合的な情報を提供できるという長所を有する。
もう一つの実施例においては、キープアライブスキームを備えるパイプライン接続がキャッシュサーバとコンテントサーバとの間に維持される。これにより、事前に設定された接続を再使用したり、キャッシュされてないコンテントの配信を高速化することが可能となる。更に、コンテントパイプラインにて複数のコンテントサーバへのパラレル接続を設定し、あるページ内に埋め込まれた全てのオブジェクトを同時にダウンロードし、ウェブの内容を前後にローディングする過程に起因する遅延を克服することもできる。多くのウェブページは埋め込まれた参照を有する。アンカページがプリントされている間に、ブラウザはこれら埋め込まれた参照を取り出すための新たなリクエストを行う。インテリジェントキャッシュプロセッサは、送り返されたコンテントを走査し、その後のリクエストに備えて、埋め込まれたオブジェクトを先取りする。
【００７４】
さらにもう一つの代替実施例においては、コンテントダイレクタは、ファーム内の静的コンテントサーバ（ｓｔａｔｉｃ ｃｏｎｔｅｎｔ ｓｅｒｖｅｒｓ）と動的コンテントサーバ（ｄｙｎａｍｉｃ ｃｏｎｔｅｎｔ ｓｅｒｖｅｒｓ）とを、リクエストするＵＲＬとコンテントタイプに基づいて分別する。再検証は静的コンテントサーバにのみ送られる。コンテントダイレクタは、コンテントの更新に関する方針を通知され、更新されたオブジェクトはその時点で除去される。サーバは、更新されたコンテントを自動的に或いは手動にてをコンテントダイレクタに送る。
さらにもう一つの実施例においては、コンテントダイレクタは、ソースＩＰアドレス、ＵＲＬ、コンテントタイプ或いはクッキーの幾つか或いは全てが一致するリクエストに対する動作（ロード／ダイレクト／キャッシュ）を指定する方針や規則を構成できるようにされる。「ロード（ｌｏａｄ）」規則は、ある幾つかのコンテントに対する全てのリクエストを、その瞬間におけるロード状態に基づいて、最も適するサーバに向けるために用いられる。「ダイレクタ（ｄｉｒｅｃｔ）」規則は、その他のコンテントに対するリクエストを、指定されたサーバに向けるために用いられ、「キャッシュ（ｃａｃｈｅ）」規則は、コンテントダイレクタが、コンテントをキャッシュプロキシ（ｃａｃｈｅ ｐｒｏｘｙ）から扱えるようにするために用いられる。
【００７５】
さらにもう一つの実施例においては、Ｓｑｕｉｄ Ｗｅｂ Ｐｒｏｘｙ Ｃａｃｈｅがコンテントダイレクタによって用いられる。Ｓｑｕｉｄコードは、プロセスの作成及び同期のオーバヘッドを回避するためにソケットとファイルの読出し／書込み用のＮｏｎ−ｂｌｏｃｋｉｎｇ Ｉ／Ｏ（非閉塞入出力）を用いる。コンテントダイレクタは、Ｃｏｏｋｉｅ ａｎｄ Ｓｅｔ Ｃｏｏｋｉｅ ＭＩＭＥヘッダを走査し、全てのクッキーをデータベース内に保存し、クッキー方針を維持する。全ての他のキャリア機能はこのコードから削除される。Ｓｑｕｉｄは、キャッシュされたオブジェクトを保存するために下層のファイルシステムを用いる。
【００７６】
さらにもう一つの実施例においては、このファイルシステムをバイパスするために、ＵＲＬとメモリ内の格納リスト（ｓｔｏｒａｇｅ ｌｉｓｔ）とがハッシュングされ、固定サイズのディスクメモリにマッピングされる。
【００７７】
本発明は、様々な実施例において、ここで説明されたものと概ね同一の要素、方法、プロセス、システム及び／或いは装置を包含し、これには、様々な異なる実現、一部のみからの組み合わせ、及びこれらのサブセットも包含される。当業者においては、上の説明を理解することで、本発明をいかに実現及び使用するかを容易に理解できるものと期待される。本発明の幾つか実施例においては、ここで説明された項目のみを用いてデバイス或いはプロセスが実現され、他の幾つかの実施例においては、説明のデバイス或いはプロセスに用いられた項目の内の性能を改善するための項目は省略され、これによって実現の簡単さ及び／或いはコストの削減が達成される。
【００７８】
上の説明は単に解説のためのもので、本発明を説明された形態に制限することを意図しない。上では、本発明の説明として、一つ或いは幾つかの実施例、幾つかの変形及び修正について説明したが、上の説明を読んだ後に明らかとなるような他の様々な変形及び修正も本発明の範囲に入る。許される範囲内の全ての代替を包含する権利を得ることが意図される。これらには、クレームにおいて主張されるそれらに対する、特許可能な主題として具体的に開示はされなかった、代替・互換可能或いは同等な構造、機能、レンジ或いはステップも含まれる。
【図面の簡単な説明】
【００７９】
【図１】本発明の一つの実施例によるフロースイッチを用いるサーバファームのブロック図である。
【図２】本発明の一つの実施例によるコンテントダイレクタの構成要素を示すブロック図である。
【図３】本発明の一つの実施例によるデータメモリ内のデータオブジェクトのデータ構造を示す図である。
【図４】本発明の一つの実施例によるＳＳＬプロセッサの動作を流れ図にて示す図である。
【図５】本発明の一つの実施例によるＩＦＳの動作を流れ図にて示す図である。
【図６】本発明の一つの実施例によるキャッシュプロセッサの動作を流れ図にて示す図である。
【図７】本発明の一つの実施例によるダイジェスト発生器の動作を流れ図にて示す図である。
【図８】本発明の一つの実施例による網交換機からトランザクションリクエストが受信された際のキャッシュサーバの動作を流れ図にて示す図である。
【図９】本発明の一つの実施例による応答が受信された際のインテリジェントフロースイッチの動作を流れ図にて示す図である。
【符号の説明】
【００８０】
１０４ サーバファーム
１０８ オリジンサーバ
１１２ ダイナミックコンテントサーバ
１１６ キャッシュサーバ
１２０ トラフィックマネジャ
１２４ ルータプール
１２８ ルータ
１３２ 通信網
２００ インテリジェントフロー交換機
２０４ ＳＳＬプロセッサ
２０８ キャッシュプロセッサ
２１２ キャッシュ
２１６ ダイジェスト発生器
２２０ ローカルダイジェストメモリ
２０８ キャッシュプロセッサ
３００ キャッシュ識別子
【特許請求の範囲】
【請求項１】
システムであって、
同じ網アドレスを有し、共通の複製された情報をとり扱う複数の情報サーバ手段と、
該複数のサーバ手段によりとり扱われる複製された情報を要求する、クライアントからの暗号化トランザクションリクエストを受信するための入力ポートと、
該トランザクションリクエストを特定のサーバ手段に転送する前に、該トランザクションリクエストを復号するための復号手段と、
該選択されたフィールドの少なくとも一つの中のフィールド情報に基づいてダイジェスト値を決定するための決定手段と、
該トランザクションリクエストに対応する選択された情報を該ダイジェスト値に関係するアドレスに記憶するためのメモリ手段と、を備えることを特徴とするシステム。
【請求項２】
請求項１に記載のシステムにおいて、
該トランザクションリクエストがハイパテキスト転送プロトコルの形式を有し、該決定する手段がハッシング関数を用いて該ダイジェスト値を決定し、および該ダイジェスト値を決定するのに用いられるフィールド情報がユニバーサルリソースアロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つであり、ならびに該トランザクションリクエストが、クッキーよりも短い、該サーバ手段の１つを一義的に識別する、クッキーに付加されるタグを有するものであるシステム。
【請求項３】
請求項１に記載のシステムにおいて、
該復号手段が、該入力ポートと該解析手段の間に位置づけられているシステム。
【請求項４】
請求項１に記載のシステムにおいて、該メモリ手段が、
該トランザクションリクエストによる第１の情報リクエストがクライアントにより要求されたことを示すヒットカウンタを増分するための増分手段と、
該第１の情報が頻繁に要求されているかどうかを、該ヒットカウンタに基づいて決定するための第２の決定手段と、
該記憶された選択情報と関連するタイムスタンプを更新するための更新手段と、を備えるシステム。
【請求項５】
請求項４に記載のシステムにおいて、
該情報コンテントが頻繁に要求されていたことを該ヒットカウンタが示すときに、該システムが、さらに該第１の情報と関連する複数の網アドレスを決定するための第３の決定手段を備えるシステム。
【請求項６】
請求項４に記載のシステムにおいて、
該第１の情報が頻繁に要求されていたことを該ヒットカウンタが示すときに、該システムが、さらに該トランザクションリクエストをキャッシュサーバに対して向ける手段を備えるシステム。
【請求項７】
請求項４に記載のシステムにおいて、さらに
該トランザクションリクエストがオリジンサーバとクライアントの間の現存する接続の一部であるかどうかを、現接続テーブルから決定するための第２の決定手段であって、該現接続テーブルがコンテントと関連する不変量、セッション識別子、永続性タイムスタンプおよびクッキー名と値からなる第２の手段と、
該トランザクションリクエストが現存する接続の一部であるときに、該トランザクションリクエストを該オリジンサーバに対して転送するための転送手段と、
該トランザクションリクエストが現存する接続の一部でなく、該第１の情報が頻繁に要求されていたことをヒットカウンタが示すときに、該転送手段が該トランザクションリクエストを該オリジンサーバとは異なるキャッシュサーバに対して転送するようになっているシステム。
【請求項８】
請求項１に記載のシステムにおいて、さらに
該トランザクションリクエストをキャッシュサーバによってとり扱うことができるかどうかを決定するための第２の決定手段と、
該トランザクションリクエストを該キャッシュサーバによりとり扱うことができない場合に、該トランザクションリクエストを該オリジンサーバに対して転送するための転送手段を備えているシステム。
【請求項９】
請求項１に記載のシステムにおいて、さらに
該ヒットカウンタが、該第１の情報が頻繁に要求されていたことを示すときに、該トランザクションリクエストと関連するコンテントを該オリジンサーバからキャッシュサーバに対して転送するための転送手段と、を備えるシステム。
【請求項１０】
トランザクションリクエストを複数のサーバの間で交換する網交換機であって、
複数のサーバのうちの少なくとも１つと関連するトランザクションリクエストにより要求される情報に対応する複数のオブジェクトをホット不変量テーブルに記憶するキャッシュであって、該ホット不変量テーブルが該情報サーバから頻繁に要求された情報を識別するものであり、また該ホット不変量テーブルが、該テーブル内の各エントリについて、対応する情報と関連する宛先不変量および決定された時間期間にわたり受信された、該対応する情報を要求するトランザクションリクエストの数を示すヒットカウンタを含むものであるキャッシュと、
宛先不変量についてのヒットカウンタが少なくともしきい値トランザクションリクエストの受信頻度を示すときに、該宛先不変量を含むエントリの、該ホット不変量テーブル内の該宛先不変量およびロケーションの関数であるダイジェスト値を発生するダイジェスト発生器と、
該複数のオブジェクトにアクセスするキャッシュプロセッサと、を備えることを特徴とする網変換機。
【請求項１１】
請求項１０に記載の網交換機において、さらに
該トランザクションリクエストを解析して該選択されたフィールドを見つけ、その後それぞれのサーバに対して解析されたトランザクションリクエストの少なくとも部分を転送するルーティング要素であって、該キャッシュプロセッサが該ルーティング要素から受信された通信に応答して該複数のオブジェクトをアクセスするようになっているルーティング要素と、
暗号テキストのトランザクションリクエストを復号して該ルーティング要素に対して平分テキストのトランザクションリクエストを提供するセキュリティプロセッサと、を備える網交換機。
【請求項１２】
請求項１１に記載の網交換機において、
該セキュリティプロセッサが、トランザクションリクエストがサーバに割り当てられる前に、暗号テキストのトランザクション要求を復号するよう動作する網交換機。
【請求項１３】
請求項１１に記載の網交換機において、
情報サーバとクライアントの間のアクティブな接続をリストする現接続テーブルをさらに備え、該ダイジェストがハッシング関数により発生され、また該ダイジェストが該ホット不変量テーブルのサイズの関数でもあり、さらに該ホット不変量でもあり、さらに該ホット不変量テーブル内の各エントリがクッキー名と値および該エントリが最後に更新されたときを示すタイムスタンプを含む網交換機。
【請求項１４】
請求項１１に記載の網交換機において、
該宛先不変量がユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つであり、該ダイジェストメモリが、各ダイジェスト値について、リース期間、ヒットもしくはアクセスカウンタ、およびタイムスタンプを含み、ならびにトランザクションリクエストが受信されたときに、該リクエスト中のクッキー名と値を該ホット不変量テーブル内のエントリに対してマッチングさせるようになっている網交換機。
【請求項１５】
請求項１３に記載の網交換機において、
該現接続テーブルが、各エントリについて、ソースおよび宛先不変量、セッション識別子、永続性タイムスタンプおよびクッキー名と値を含む網交換機。
【請求項１６】
請求項１０に記載の網交換機において、
選択された情報が頻繁に要求されるものであると決定されたときに、該選択された情報がその後にキャッシュサーバから取り扱われるようになっており、該リクエストに応答するトランザクションが該応答を提供する情報サーバを識別するタグを含み、および該クッキーよりも短い長さを有するタグが該応答中のクッキーに付加されるようになっている網交換機。
【請求項１７】
網パケット内の選択された情報を処理するための方法であって、
暗号テキストトランザクションリクエストを受信するステップと、
該暗号テキストトランザクションリクエストを復号して、平分テキストトランザクションリクエストを形成するステップと、
その後に、該平分トランザクションリクエストを解析して、ユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つを見つけるステップであって、該トランザクションリクエストが処理を行う情報サーバに向けられる前に該復号する処理が行われるようになっているステップと、
ユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの該少なくとも１つの少なくとも一部分からダイジェスト値を決定するステップと、
該ダイジェスト値に関係する位置に該トランザクションリクエストと関連する選択された情報を記憶するステップと、を含むことを特徴とする方法。
【請求項１８】
請求項１７に記載の方法において、
該ダイジェスト値が、ユニバーサルリソースロケータ、クッキー、および該選択された情報の記憶された位置のうちの少なくとも１つの関数であるハッシュ関数に基づいたハッシュ値である方法。
【請求項１９】
請求項１８に記載の方法において、
該ユニバーサルリソースロケータ（ＵＲＬ）の一部分のみが該ハッシュ関数において用いられて、該ハッシュ値を決定するようになっており、該記憶位置が、複数のエントリを含むホット不変量テーブル内に存在し、各エントリが、ユニバーサルリソースロケータ（ＵＲＬ）、クッキー名と値、そのエントリが最後に更新されたときを示すタイムスタンプ、および該ユニバーサルリソースロケータ（ＵＲＬ）の要求頻度を示すヒットカウンタから成るものである方法。
【請求項２０】
請求項１７に記載の方法において、
該選択された情報がキャッシュ内に記憶され、該情報が該ユニバーサルリソースロケータに対応する内容のホット性に関係するヒットカウンタを含み、そしてさらに該記憶された情報に基づいて該パケットについてのサーバ宛先を決定するステップを含む方法。
【請求項１】
システムであって、
同じ網アドレスを有し、共通の複製された情報をとり扱う複数の情報サーバ手段と、
該複数のサーバ手段によりとり扱われる複製された情報を要求する、クライアントからの暗号化トランザクションリクエストを受信するための入力ポートと、
該トランザクションリクエストを特定のサーバ手段に転送する前に、該トランザクションリクエストを復号するための復号手段と、
該選択されたフィールドの少なくとも一つの中のフィールド情報に基づいてダイジェスト値を決定するための決定手段と、
該トランザクションリクエストに対応する選択された情報を該ダイジェスト値に関係するアドレスに記憶するためのメモリ手段と、を備えることを特徴とするシステム。
【請求項２】
請求項１に記載のシステムにおいて、
該トランザクションリクエストがハイパテキスト転送プロトコルの形式を有し、該決定する手段がハッシング関数を用いて該ダイジェスト値を決定し、および該ダイジェスト値を決定するのに用いられるフィールド情報がユニバーサルリソースアロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つであり、ならびに該トランザクションリクエストが、クッキーよりも短い、該サーバ手段の１つを一義的に識別する、クッキーに付加されるタグを有するものであるシステム。
【請求項３】
請求項１に記載のシステムにおいて、
該復号手段が、該入力ポートと該解析手段の間に位置づけられているシステム。
【請求項４】
請求項１に記載のシステムにおいて、該メモリ手段が、
該トランザクションリクエストによる第１の情報リクエストがクライアントにより要求されたことを示すヒットカウンタを増分するための増分手段と、
該第１の情報が頻繁に要求されているかどうかを、該ヒットカウンタに基づいて決定するための第２の決定手段と、
該記憶された選択情報と関連するタイムスタンプを更新するための更新手段と、を備えるシステム。
【請求項５】
請求項４に記載のシステムにおいて、
該情報コンテントが頻繁に要求されていたことを該ヒットカウンタが示すときに、該システムが、さらに該第１の情報と関連する複数の網アドレスを決定するための第３の決定手段を備えるシステム。
【請求項６】
請求項４に記載のシステムにおいて、
該第１の情報が頻繁に要求されていたことを該ヒットカウンタが示すときに、該システムが、さらに該トランザクションリクエストをキャッシュサーバに対して向ける手段を備えるシステム。
【請求項７】
請求項４に記載のシステムにおいて、さらに
該トランザクションリクエストがオリジンサーバとクライアントの間の現存する接続の一部であるかどうかを、現接続テーブルから決定するための第２の決定手段であって、該現接続テーブルがコンテントと関連する不変量、セッション識別子、永続性タイムスタンプおよびクッキー名と値からなる第２の手段と、
該トランザクションリクエストが現存する接続の一部であるときに、該トランザクションリクエストを該オリジンサーバに対して転送するための転送手段と、
該トランザクションリクエストが現存する接続の一部でなく、該第１の情報が頻繁に要求されていたことをヒットカウンタが示すときに、該転送手段が該トランザクションリクエストを該オリジンサーバとは異なるキャッシュサーバに対して転送するようになっているシステム。
【請求項８】
請求項１に記載のシステムにおいて、さらに
該トランザクションリクエストをキャッシュサーバによってとり扱うことができるかどうかを決定するための第２の決定手段と、
該トランザクションリクエストを該キャッシュサーバによりとり扱うことができない場合に、該トランザクションリクエストを該オリジンサーバに対して転送するための転送手段を備えているシステム。
【請求項９】
請求項１に記載のシステムにおいて、さらに
該ヒットカウンタが、該第１の情報が頻繁に要求されていたことを示すときに、該トランザクションリクエストと関連するコンテントを該オリジンサーバからキャッシュサーバに対して転送するための転送手段と、を備えるシステム。
【請求項１０】
トランザクションリクエストを複数のサーバの間で交換する網交換機であって、
複数のサーバのうちの少なくとも１つと関連するトランザクションリクエストにより要求される情報に対応する複数のオブジェクトをホット不変量テーブルに記憶するキャッシュであって、該ホット不変量テーブルが該情報サーバから頻繁に要求された情報を識別するものであり、また該ホット不変量テーブルが、該テーブル内の各エントリについて、対応する情報と関連する宛先不変量および決定された時間期間にわたり受信された、該対応する情報を要求するトランザクションリクエストの数を示すヒットカウンタを含むものであるキャッシュと、
宛先不変量についてのヒットカウンタが少なくともしきい値トランザクションリクエストの受信頻度を示すときに、該宛先不変量を含むエントリの、該ホット不変量テーブル内の該宛先不変量およびロケーションの関数であるダイジェスト値を発生するダイジェスト発生器と、
該複数のオブジェクトにアクセスするキャッシュプロセッサと、を備えることを特徴とする網変換機。
【請求項１１】
請求項１０に記載の網交換機において、さらに
該トランザクションリクエストを解析して該選択されたフィールドを見つけ、その後それぞれのサーバに対して解析されたトランザクションリクエストの少なくとも部分を転送するルーティング要素であって、該キャッシュプロセッサが該ルーティング要素から受信された通信に応答して該複数のオブジェクトをアクセスするようになっているルーティング要素と、
暗号テキストのトランザクションリクエストを復号して該ルーティング要素に対して平分テキストのトランザクションリクエストを提供するセキュリティプロセッサと、を備える網交換機。
【請求項１２】
請求項１１に記載の網交換機において、
該セキュリティプロセッサが、トランザクションリクエストがサーバに割り当てられる前に、暗号テキストのトランザクション要求を復号するよう動作する網交換機。
【請求項１３】
請求項１１に記載の網交換機において、
情報サーバとクライアントの間のアクティブな接続をリストする現接続テーブルをさらに備え、該ダイジェストがハッシング関数により発生され、また該ダイジェストが該ホット不変量テーブルのサイズの関数でもあり、さらに該ホット不変量でもあり、さらに該ホット不変量テーブル内の各エントリがクッキー名と値および該エントリが最後に更新されたときを示すタイムスタンプを含む網交換機。
【請求項１４】
請求項１１に記載の網交換機において、
該宛先不変量がユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つであり、該ダイジェストメモリが、各ダイジェスト値について、リース期間、ヒットもしくはアクセスカウンタ、およびタイムスタンプを含み、ならびにトランザクションリクエストが受信されたときに、該リクエスト中のクッキー名と値を該ホット不変量テーブル内のエントリに対してマッチングさせるようになっている網交換機。
【請求項１５】
請求項１３に記載の網交換機において、
該現接続テーブルが、各エントリについて、ソースおよび宛先不変量、セッション識別子、永続性タイムスタンプおよびクッキー名と値を含む網交換機。
【請求項１６】
請求項１０に記載の網交換機において、
選択された情報が頻繁に要求されるものであると決定されたときに、該選択された情報がその後にキャッシュサーバから取り扱われるようになっており、該リクエストに応答するトランザクションが該応答を提供する情報サーバを識別するタグを含み、および該クッキーよりも短い長さを有するタグが該応答中のクッキーに付加されるようになっている網交換機。
【請求項１７】
網パケット内の選択された情報を処理するための方法であって、
暗号テキストトランザクションリクエストを受信するステップと、
該暗号テキストトランザクションリクエストを復号して、平分テキストトランザクションリクエストを形成するステップと、
その後に、該平分トランザクションリクエストを解析して、ユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの少なくとも１つを見つけるステップであって、該トランザクションリクエストが処理を行う情報サーバに向けられる前に該復号する処理が行われるようになっているステップと、
ユニバーサルリソースロケータ（ＵＲＬ）およびクッキーのうちの該少なくとも１つの少なくとも一部分からダイジェスト値を決定するステップと、
該ダイジェスト値に関係する位置に該トランザクションリクエストと関連する選択された情報を記憶するステップと、を含むことを特徴とする方法。
【請求項１８】
請求項１７に記載の方法において、
該ダイジェスト値が、ユニバーサルリソースロケータ、クッキー、および該選択された情報の記憶された位置のうちの少なくとも１つの関数であるハッシュ関数に基づいたハッシュ値である方法。
【請求項１９】
請求項１８に記載の方法において、
該ユニバーサルリソースロケータ（ＵＲＬ）の一部分のみが該ハッシュ関数において用いられて、該ハッシュ値を決定するようになっており、該記憶位置が、複数のエントリを含むホット不変量テーブル内に存在し、各エントリが、ユニバーサルリソースロケータ（ＵＲＬ）、クッキー名と値、そのエントリが最後に更新されたときを示すタイムスタンプ、および該ユニバーサルリソースロケータ（ＵＲＬ）の要求頻度を示すヒットカウンタから成るものである方法。
【請求項２０】
請求項１７に記載の方法において、
該選択された情報がキャッシュ内に記憶され、該情報が該ユニバーサルリソースロケータに対応する内容のホット性に関係するヒットカウンタを含み、そしてさらに該記憶された情報に基づいて該パケットについてのサーバ宛先を決定するステップを含む方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００８−１４６６５８（Ｐ２００８−１４６６５８Ａ）
【公開日】平成２０年６月２６日（２００８．６．２６）
【国際特許分類】
【出願番号】特願２００７−３２６７５７（Ｐ２００７−３２６７５７）
【出願日】平成１９年１２月１９日（２００７．１２．１９）
【分割の表示】特願２００２−５１８７０９（Ｐ２００２−５１８７０９）の分割
【原出願日】平成１３年８月３日（２００１．８．３）
【出願人】（５００５０００４４）アバイア テクノロジー コーポレーション (53)
【Ｆターム（参考）】
【公開日】平成２０年６月２６日（２００８．６．２６）
【国際特許分類】
【出願日】平成１９年１２月１９日（２００７．１２．１９）
【分割の表示】特願２００２−５１８７０９（Ｐ２００２−５１８７０９）の分割
【原出願日】平成１３年８月３日（２００１．８．３）
【出願人】（５００５０００４４）アバイア テクノロジー コーポレーション (53)
【Ｆターム（参考）】
[ Back to top ]