図面 (/)

技術 コネクションオリエンテッドトランザクションにおけるURLオブジェクトのインテリジェントな需要に基づく認識

出願人 アバイアインコーポレイテッド
発明者 チュー,アルバート,ボンヤオジャスワ,ヴィジェイホング,ジャック,エル.
出願日 2001年8月3日 (20年3ヶ月経過) 出願番号 2002-518709
公開日 2004年7月29日 (17年3ヶ月経過) 公開番号 2004-523020
状態 特許登録済
技術分野 検索装置 計算機におけるファイル管理 計算機間の情報転送 オンライン・システム オンライン・システム 広域データ交換
主要キーワード 突発的変化 ルーティング要素 コンテントサーバ ヒットカウンタ 格納リスト リース条件 修正態様 パイプライン接続
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2004年7月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

トランザクション一貫性を維持しながらフロー負荷バランス知能的に遂行することができる網交換機を提供する。

解決手段

本発明は特定のコンテントホットであることを決定し、フローを一つ或いは複数のキャッシュサーバに向ける網交換機に係る。本発明のアーキテクチャは、キャッシュダイジェスト発生器を備え、このキャッシュ内にはダイジェスト発生器によって生成されたダイジェストに基づいて所定のオブジェクトが格納される。

概要

背景

概要

トランザクション一貫性を維持しながらフロー負荷バランス知能的に遂行することができる網交換機を提供する。本発明は特定のコンテントホットであることを決定し、フローを一つ或いは複数のキャッシュサーバに向ける網交換機に係る。本発明のアーキテクチャは、キャッシュダイジェスト発生器を備え、このキャッシュ内にはダイジェスト発生器によって生成されたダイジェストに基づいて所定のオブジェクトが格納される。

目的

ウェブ技術は様々なアプリケーションに対するユーザに優しいフロントエンドを提供する

効果

実績

技術文献被引用数
1件
牽制数
2件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

トランザクションリクエストを複数の情報サーバの間で交換するための網交換機であって、トランザクションリクエストを解析することで選択されたフィールドを見つけ、それ以降、解析されたトランザクションリクエストの少なくとも一部をおのおのの情報サーバに転送するためのルーティング要素と、該複数の情報サーバの少なくとも一つと関連するトランザクションリクエストに対応する複数のオブジェクトを格納するためのキャッシュであって、該複数のオブジェクトが該ルーティング要素によって見つけられ、これから受信される該選択されたフィールドの少なくとも一つ内のフィールド情報から成るようなキャッシュと、ある対応するトランザクションリクエストの少なくとも一つの選択されたフィールド内のフィールド情報の基づいてダイジェストを生成するためのダイジェスト発生器であって、該ダイジェストが、該キャッシュ内の、該対応するトランザクションリクエストに対応する少なくとも一つのオブジェクトがそこに格納されるべき位置に対応するようなダイジェスト発生器と、該ルーティング要素から受信される通信応答して該複数のオブジェクトにアクセスするためのキャッシュプロセッサとを備えることを特徴とする網交換機。

請求項2

更に、暗号テキストのトランザクションリクエストを復号し、平文テキストのトランザクションリクエストを該ルーティング要素に供給するための復号プロセッサを備える請求項1記載の網交換機。

請求項3

更に、該網交換機と一つ或いは複数のクライアントとの間に配置された少なくとも一つのトラフィックマネジャを備え、該ダイジェストがハッシング関数を用いて生成される請求項1記載の網交換機。

請求項4

該選択されたフィールドが少なくとも一つのユニバーサルリソースロケータ(URL)とクッキーを含む請求項1記載の網交換機。

請求項5

該ルーティング要素が情報サーバとクライアントとの間のアクティブな接続をリストする現接続テーブルを含む請求項1記載の網交換機。

請求項6

該キャッシュ内の複数のオブジェクトが特定のコンテントに対する複数のコンテントアドレスと、トランザクションリクエストによって特定のコンテントが所定の時間期間内にリクエストされた回数を示す対応するヒットカウンタを含む請求項1記載の網交換機。

請求項7

トランザクションリクエストを複数の情報サーバの間で交換するための方法であって、ある情報サーバに対応するトランザクションリクエストを受信するステップと、該トランザクションリクエスト内の一つ或いは複数の選択されたフィールドを解析するステップと、該選択されたフィールドの少なくとも一つ内のフィールド情報に基づいてダイジェスト値を決定するステップと、該トランザクションリクエストに対応する選択された情報を該ダイジェスト値に基づいてあるアドレスに格納するステップと、を含むことを特徴とする方法。

請求項8

該トランザクションリクエストがハイパテキスト転送プロトコルHTTP)の形式を有し、該ダイジェスト値がハッシング関数を用いて生成され、該ダイジェスト値を決定するために用いられるフィールド情報がユニバーサルリソースアロケータ(URL)とクッキーの少なくとも一つから成る請求項7記載の方法。

請求項9

該トランザクションリクエストが暗号テキストの形式を有し、更に、該受信ステップと該解析ステップとの間に、該トランザクションリクエストを復号するステップを含む請求項7記載の方法。

請求項10

格納ステップが:ヒットカウンタを増分或いは減分するステップ、つまり、ヒットカウンタが所定の閾値に達した或いはこれを超えるか決定し、その場合は、該ヒットカウンタを増分し、ヒットカウンタが該所定の閾値に等しいか或いはこれより低いかを決定し、その場合は、該ヒットカウンタを減分するステップと、該格納されている情報と関連するタイムスタンプ更新するステップと、を含む請求項7記載の方法。

請求項11

更に、該ヒットカウンタが所定の閾値に達した或いはこれを超える場合、該トランザクションリクエスト内に参照されるコンテントと関連する複数の網アドレスを決定するステップを含む請求項10記載の方法。

請求項12

更に、該ヒットカウンタが該所定の閾値に達した或いはこれを超える場合、該トランザクションリクエストを、該トランザクションリクエストに対応するオリジンサーバとは異なるキャッシュサーバに向けるステップを含む請求項10記載の方法。

請求項13

更に、該トランザクションリクエストが該オリジンサーバとクライアントとの間に現存する接続の一部であるか否かを決定するステップと、該トランザクションリクエストが現存する接続の一部であるときは、該トランザクションリクエストを対応するサーバに転送するステップと、該トランザクションリクエストが現存する接続の一部ではなく、ヒットカウンタが所定の値に等しい或いはこれを超えるときは、該トランザクションを該対応するサーバとは異なるキャッシュサーバに転送するステップと、を含む請求項7記載の方法。

請求項14

更に、該トランザクションリクエストがキャッシュサーバにて扱えるか否かを決定するステップと、該トランザクションリクエストが該キャッシュサーバにて扱えないときは、該トランザクションリクエストを該対応するサーバに転送するステップと、を含む請求項7記載の方法。

請求項15

更に、ヒットカウンタが所定の閾値に等しい或いはこれを超えるときは、該トランザクションリクエストと関連するコンテントを該対応するサーバからキャッシュサーバに転送するステップを含む請求項7記載の方法。

請求項16

トランザクションリクエストを複数のサーバ間で交換するためのシステムであって、オリジンサーバによって扱われている情報を要求するトランザクションリクエストを受信するための入力ポートと、該トランザクションリクエストを解析し、一つ或いは複数の選択されたフィールドを見つけるための解析手段と、該選択されたフィールドの少なくとも一つ内のフィールド情報に基づいてダイジェスト値を決定するための決定手段と、該トランザクションリクエストに対応する選択された情報を該ダイジェスト値に基づいてあるアドレスに格納するためのメモリ手段と、を備えることを特徴とするシステム。

請求項17

該トランザクションリクエストがハイパテキスト転送プロトコル(HTTP)の形式を有し、該決定手段が該ダイジェスト値を決定するためにハッシング関数を用い、該ダイジェスト値を決定するために用いられる該フィールド情報がユニバーサルリソースアロケータ(URL)とクッキーの少なくとも一つから成る請求項16記載のシステム。

請求項18

該トランザクションリクエストが暗号テキストの形式を有し、更に、該入力ポートと該解析手段との間に、該トランザクションリクエストを復号するための復号手段を備える請求項16記載のシステム。

請求項19

該メモリ手段が:ヒットカウンタを増分するための増分手段と、該ヒットカウンタが所定の閾値に達した或いはこれを超えたか否かを決定するための第二の決定手段と、該格納されている情報と関連するタイムスタンプを更新するための更新手段と、を備える請求項16記載のシステム。

請求項20

更に、該ヒットカウンタが該所定の閾値に達した或いはこれを超えた場合、該トランザクションリクエスト内に参照されるコンテントと関連する複数の網アドレスを決定するための第三の決定手段を備える請求項19記載のシステム。

請求項21

更に、該ヒットカウンタが該所定の閾値に達した或いはこれを超えた場合、該トランザクションリクエストを該オリジンサーバとは異なるキャッシュサーバに向けるためのダイレクティング手段を備える請求項19記載のシステム。

請求項22

更に、該トランザクションリクエストが該オリジンサーバとクライアントとの間に現存する接続の一部であるか否かを決定するための第二の決定手段と、該トランザクションリクエストが現存する接続の一部である場合、該トランザクションリクエストを該オリジンサーバに転送するための転送手段とを備え、該トランザクションリクエストが現存する接続の一部ではなく、ヒットカウンタが所定の値に達した或いはこれを超えるとき、該転送手段が該トランザクションを該オリジンサーバとは異なるキャッシュサーバに転送する請求項16記載のシステム。

請求項23

更に、該トランザクションリクエストがキャッシュサーバにて処理できるか否かを決定するための第二の決定手段と、該トランザクションリクエストが該キャッシュサーバにて処理できないとき、該トランザクションリクエストを該オリジンサーバに転送するための転送手段と、を備える請求項16記載のシステム。

請求項24

更に、ヒットカウンタが所定の閾値に達した或いはこれを超えたとき、該トランザクションリクエストと関連するコンテントを該オリジンサーバからキャッシュサーバに転送するための転送手段を備える請求項16記載のシステム。

請求項25

トランザクションリクエストを複数のサーバの間で交換するための網交換機であって、複数のサーバの少なくとも一つと関連するトランザクションリクエストに対応する複数のオブジェクトを格納するためのキャッシュであって、該複数のオブジェクトが該トランザクションリクエスト内の選択されたフィールド内のフィールド情報から成るようなキャッシュとダイジェスト値をある対応するトランザクションリクエストの少なくとも一つの選択されたフィールド内のフィールド情報の基づいて生成するためのダイジェスト発生器であって、該ダイジェストが、該キャッシュ内の、該トランザクションリクエストに対応する少なくとも一つのオブジェクトがそこに格納されるべき位置に対応しているようなダイジェスト発生器と、該複数のオブジェクトにアクセスするためのキャッシュプロセッサとを備える、ことを特徴とする網交換機。

請求項26

更に、該トランザクションリクエストを解析することで該選択されたフィールドを見つけ、その後は、解析されたトランザクションリクエストの少なくとも一部をおのおののサーバに転送するためのルーティング要素を備え、該キャッシュプロセッサが該ルーティング要素から受信される通信に応答して該複数のオブジェクトにアクセスする請求項25記載の網交換機。

請求項27

更に、暗号テキストのトランザクションリクエストを復号し、平文テキストのトランザクションリクエストを該ルーティング要素に供給するためのセキュリティプロセッサを備える請求項26記載の網交換機。

請求項28

更に、該網交換機と一つ或いは複数のクライアントとの間に配置された少なくとも一つのトラフィックマネジャを備え、該ダイジェスト値がハッシング関数を用いて生成される請求項26記載の網交換機。

請求項29

該選択されたフィールドがユニバーサルリソースロケータ(URL)とクッキーの少なくとも一つを含む請求項26記載の網交換機。

請求項30

該ルーティング要素がサーバとクライアントとの間のアクティブな接続をリストする現接続テーブルを含む請求項26記載の網交換機。

請求項31

該キャッシュ内の該複数のオブジェクトが特定のコンテントに対する複数のコンテントアドレスと、トランザクションリクエストによって特定のコンテントが所定の時間期間内にリクエストされた回数を示す対応するヒットカウンタを含む請求項26記載の網交換機。

請求項32

パケット内の選択された情報を処理するための方法であって、該パケットを解析することで、ユニバーサルリソースロケータ(URL)とクッキーの少なくとも一つを見つけるためのステップと、ユニバーサルリソースロケータ(URL)とクッキーの少なくとも一つの少なくとも一部からハッシュ値を決定するステップと、該パケットと関連する情報を該ハッシュ値に対応する位置に格納するステップと、を含むことを特徴とする方法。

請求項33

該ハッシュ値がハッシュ関数に基づく請求項32記載の方法。

請求項34

該ハッシュ関数を用いて該ハッシュ値を決定する際に、該ユニバーサルリソースロケータ(URL)の一部のみが用いられる請求項33記載の方法。

請求項35

該情報がキャッシュ内に格納され、該情報が該ユニバーサルリソースロケータ(URL)に対応するコンテントのホットさに係るヒットカウンタを備え、更に該格納されている情報に基づいて該パケットに対する宛先サーバを決定するステップを備える請求項32記載の方法。

請求項36

通信網と、該通信網に接続された複数の複製サーバであって、その全てが同一の網アドレスを有し、該複製サーバの全てが同一の複製情報を扱い、該複製サーバの各々が個別のトランザクションと関連する第一のトランザクションリクエストを受信し、該第一のトランザクションリクエストに対して、該トランザクションに対応するタグを含む応答を供給するように構成されているような複数の複製サーバと、該複数のサーバを該網に接続する網交換機であって、該網アドレスに宛てられた全てのトランザクションリクエストを受信し、これら複数のサーバの中から該第一のトランザクションリクエストを扱うための一つを選択し、該トランザクションと関連するタグをある選択されたサーバと関連させて格納し、それ以降に受信される該タグを含むトランザクションリクエストを該選択されたサーバに向けるように構成され、この網交換機が該タグをダイジェスト値に基づいてあるメモリ位置に格納し、このダイジェスト値が少なくとも一部該タグの少なくとも一部分に基づいて決定されるようになっている網交換機とを備えることを特徴とするシステム。

請求項37

該網交換機が該第一のトランザクションリクエストを解析するように構成されたパーサを備え、該タグがユニバーサルリソースロケータ(URL)とクッキーの少なくとも一つから成る請求項36記載のシステム。

請求項38

該網交換機が、該第一のトランザクションリクエストを該パーサによって解析する前に該第一のトランザクションリクエストを復号するように構成された復号プロセッサを備える請求項37記載のシステム。

請求項39

該タグが複数の格納されたオブジェクトの一部から成り、該複数の格納されたオブジェクトが該第一のトランザクションリクエストに対応し、該複数の格納されたオブジェクトが該第一のトランザクションリクエストと関連するコンテントに対するトランザクションリクエストの頻度を示すヒットカウンタを含む請求項37記載のシステム。

--

0001

関連する特許出願
本出願は、2000年8月4日付けで、Chu,Jaswa,及びChagantyらに付与された同名の合衆国仮特許出願No.60/223,087の合衆国特許法(35U.S.C§119(e))の下での利益を主張する。本発明は、更に、両者とも本出願と同一の発明人により本出願と同時に出願された「High Performance Server Farm With Tagging and Pipelining」及び「Non−Intrusive Multiplexed Transaction Persistency in Secure Commerce Environments」なる名称の合衆国特許出願にも係る。

0002

発明の技術分野
本発明は一般的には、負荷バランス網交換機、より詳細には、トランザクション一貫性(transaction coherency)を維持しながらフロー負荷バランス知能的に遂行することができる網交換機に関する。

0003

発明の背景
ビジネスはますます多くをコンピュータ及びネットワークに依存するようになりつつある。ウェブ技術は様々なアプリケーションに対するユーザに優しいフロントエンドを提供することで電子商取引(E−Commerce)展開推進力となっている。クライアントサーバアプリケーション成功には、ホストされるサービスへの連続(持続)的なアクセスとこれらからの即座の応答が必須である。長いダウン時間や遅い及び/或いは誤った応答は、顧客の不満を招き、商売の機会を逃しかねない。このため、利便性(availability)が高く、性能の優れたサーバに対する要請はますます高まっている。

0004

ウェブサイト用途において遭遇される時間に依存する大きな需要の変動の観点から)サーバに要求されるレベルの利便性、性能、及びスケーラビリティを達成するためには、典型的には一つ或いは複数のインテリジェントインタネットプロトコル(IP)交換機を備えるサーバのファーム(farm)、すなわちサーバファーム(server farm)が採用される。IP交換機は、複数のサーバ間のインタネットプロトコル(IP)トラフィック負荷バランシングを、OSIネットワークモデルの一つ或いは複数の層(つまり、層7すなわちアプリケーション層、層6すなわちプレゼェンテーション層、層5すなわちセッション層、層4すなわちトランスポート層、層3すなわちネットワーク層、層2すなわちデータリンク層、及び層1すなわち物理層)内に含まれる情報に基づいて遂行する。サーバのグループは典型的には単一のグローバルIPアドレスによって識別される。このグローバルIPアドレスに向けられたトラフィックは、ソースIPアドレスを有するこれらサーバの作業負荷と選択されたサーバのアドレス類似性に基づいて、そのグループ内のサーバ間で負荷バランスされる。これらサーバにアクセスする全てのクライアントは、グローバルIPアドレスのみを調べ、そのファーム内の複数の複製サーバについて及びそれらのトラフィックがどの特定のサーバに転送されているかは特に意識しない。

0005

現在様々な異なるタイプのIP交換機が用いられている。
層3及び/或いは層4交換機を含むあるタイプの交換機は、入りパケット宛先IPアドレス、或いはIPアドレスプロトコルID及びトランスポートポート番号の組合せに基づいてルーティングする。このスイッチング技法ウェブ環境においては問題をはらむ。層4の負荷バランサにとっては、全てのウェブアプリケーションはTCPポート80(HTTPに対する典型的なポート)を使用しているように見え、これらを互いに区別することはできない。このため、Common Gateway Interface(CGIリクエストと、Web−enabled Service Access Point(SAP)アプリケーション或いはストリーミングオーディオ(streaming audio)リクエストとを、これらリクエストは全て非常に異なるQoS要件を有するのにもかかわらず、区別することができない。

0006

もう一つのタイプのIP交換機は、ウェブ交換機として知られており、これは、ウェブトラフィックの特有要件対処できるように特別に設計された新世代のネトワーク技術である。ウェブ交換機は、高度なユニバーサルリソースロケータ(URL)負荷バランス能力、Network Address Translation(NAT)、及び埋め込まれたDomain Name Server(DNS)知能を備える「スマート(smart)」交換機であり、複雑な方針(policies)を用いてウェブトラフィックフローの管理及び高速化を図る。ウェブ交換機は、ウェブトラフィックを最適化するために、HTTPペイロード解析し、URLとクッキーを調べることで、どのようなコンテントがリクエストされているかを決定する。ここで用いられる「クッキー(cookie)」なる語句は、サーバのリクエストに答えて、クライアント或いはピア(peer)上に格納される情報を指す。クッキーは、典型的には、そのクッキーがそれに対して有効なURLのパスレンジ(path range)の記述から成り、サーバ応答に付加或いはタグ付けされる。クッキー内の情報は、勿論、サーバによって定義される。後に説明するように、URLは、リクエストされたコンテントを識別するのみで、そのコンテントがどこで見つられるかは示さない。リクエストされたコンテントに関する知識に元に、ウェブ交換機は、ユーザにて定義された及び/或いは事前に設定された方針を用いて、特定のコンテント或いはユーザに対して、どのようなフローセキュリティ規則施行されるべきか、どのようなコンテントが許容され、どのようなコンテントが拒絶されるべきか、及びどのようなQoS要件が必要とされるかを決定する。こうすることで、トラフィック優先付けに関する方針の定義における柔軟性が得られ、階層サービス(tiered services)を実現したり、Service Level Agreementに合わせたり、電子商取引にとって非常に重要な要件である固着性接続(sticky connection )やユーザ認証活用したりすることが可能となる。

0007

ウェブ交換機は、高度にスケーラブルマルチプロセッサフレームワークを用い、これは方針をフロー(セッション)の設定時にのみ評価する。フローがいったん設定されると、そのフロー内の、それ以降の全てのパケットは、高速転送回路を介してポートベースにてワイヤ速度(wire speed)にてカットスルー(cut−through)される。「いったんフローを設定し、その後、全ての他のパケットを交換する」アプローチは、URLレベルでのトラフィックの複雑な分類を可能にするとともに、ローカルエリア網(LAN)交換機のコスト性能を向上させる。

0008

ウェブ交換機は、ある瞬間においてどのウェブサーバ或いはキャッシュが特定のリクエストを最も良く扱うことができるかを、そのユーザからサーバまでの近接性(距離)、サーバの状態、網パスの状態、及びどのようなコンテントがリクエストされたか等の基準に基づいて決定する。ウェブ交換機は、あるウェブサイトに向かう全てのトラフィックを傍受する。こうすることで、ウェブ交換機は、コンテントリクエストを追跡し、ホットコンテント(hot content)を予測し、サーバの負担を軽減することが可能になる。ウェブ交換機は、動的にホットコンテントをウェブキャッシュ内に複製し、キャッシュをかわるがわる用いて負荷をバランスされることで、ウェブサイトトラフィックが大きく変動した場合でも、ユーザが途切れのないサービスを受けられるようにする。ウェブ交換機は、更に、どのサーバが以前配信されたことのある特定のコンテントを有するかを追跡し、そのコンテントに対する新たなリクエストは、該当するサーバに直接に送るようにし、こうすることでサーバキャッシュの一貫性と性能の向上に寄与する。

0009

ただし、ウェブ交換機は幾つかの問題を有する。例えば、ウェブ交換機も過多計算資源を必要する、すなわち、計算効率が悪い。

0010

発明の概要
これら及びその他の必要性が本発明のアーキテクチャ及び方法によって解決される。

0011

一つの実施例においては、本発明は通信網データサーバファームとの間で結合可能な網フロー交換機を提供する。一つの構成においては、この網フロー交換機は、2,3,及び4層ウェブ交換機として構成され、サーバファームのグローバルIPアドレスを自身のアドレスとし、クライアントからの全てのトランザクションリクエストを、サーバファームに代って受信する。「トランザクションリクエスト(transaction request)」なる語句は、パケットの形式を有するか否かに関係なく、一つ或いは複数のサーバによる仕事或いは仕事の開始をリクエスト指示するあらゆる信号を意味する。より具体的には、ある信号(リクエスト)は、例えば、サーバに対してそのサーバのメモリ内に格納されているリクエストされた情報を供給することや、その信号によって参照或いは供給される情報に基づいて情報を計算することを指令する。この網フロー交換機はルーティングを備え、ルーティング要素は受信されたデータパケットに関して動作し、そのIPデータパケット内のソースと宛先に関する不変量を決定する。これら不変量は、それ以降、そのIPパケットに対する宛先デバイスを決定するための基礎として用いられる。

0012

一つの構成においては、交換機は、URLとコンテントタイプの任意の組合せを調べ、これに基づいてリクエストのルーティングとアクセス優先の設定を行い;これらを解析することでリクエストされたURLを決定し;そのコンテントを取り出すために最も有効なサーバを決定し;こうして参照カウント(或いはヒットカウンタ)と満了タイマ(或いはタイムスタンプ)を備えるソースサーバURLデータベースを構築する。反復されるリクエストは同一サーバに向けられるが、これには一つの実施例においてはキャッシュ可能なサーバ(cacheable server)が用いられる。この交換機は、コンテント参照カウントと満了タイマを用いて、アクセスの頻度と最近性(recency)の組み合わせを計算し、これによって「ホット(hot)」コンテントを検出する。これによって頻繁にリクエストされるコンテントが効率的に分別され、網フロー交換機のクラスタ構成間に均等にキャッシングされる。この交換機要素に、一つの実施例においては、オプションとして、サーバ側にキャッシュプロセッサが接続される。このキャッシュプロセッサは、頻繁にリクエストされるデータオブジェクトを格納するためのローカルオブジェクトキャッシュ(local object cache)と、このローカルオブジェクトキャッシュによって格納されるオブジェクトのURLに対応するダイジェストを格納するダイジェストメモリを備える。複数の網フロー交換機がクラスタ化される場合は、分散ダイジェストメモリのコンテントがクラスタ内共有される。こうして、オブジェクト検索(object look−ups)がより完全なものとなることに加えて、参照されたオブジェクトを含む可能性のあるローカルオブジェクトキャッシュを識別することも可能となる。

0013

一つの構成においては、キャッシュダイジェストは、キャッシュ内の頻繁にリクエストされるデータオブジェクトのメモリ位置を指すポインタから成る。典型的には、ダイジェストは少なくとも一部はURLに基づき、1を疎に含むビットベクトルから成る。このベクトル次元によってキャッシュダイジェストの集合の容量が決まり、これはキャッシュ内のオブジェクトの数にキャッシュダイジェストの次元を乗じた値として設定される。キャッシュダイジェストの次元は、あるURLダイジェストと関連するハッシュ関数或いはハッシュ成分の数によって決まる。ハッシュ成分のあるキーに対する値は、そのベクトルへの対応するビットのみが1にセットされた索引インデックス)を表す。全てのキャッシュダイジェストの集合は、全てのキャッシュされたオブジェクトのダイジェストベクトルの論理ORから構成されるビットベクトルから成る。

0014

本発明のアーキテクチャ及び方法は従来の技術と比較して幾つかの長所を有する。
第一に、この交換機は、他のタイプの網交換機と比較して、著しく計算効率が良いことに加えて、メモリを大幅に節約することができる。キャッシュを用いる従来のフロー交換機は、典型的にはその交換機によって処理された信号に対応するオブジェクトのテーブルを維持する。この交換機は、スイッチングの決定を行う度に、そのオブジェクトと関連するポインタを見つけるために、テーブルを上から下まで或いは下から上まで探索する。テーブルのどちら側が最初に探索されるかによって、テーブルの上側或いは下側に位置するオブジェクトはより短い探索時間を要し、テーブルの反対側に位置するオブジェクトはより長い探索時間を要する。各スイッチング決定のために過剰な計算資源が費やされ、このために交換機の容量が制限される。加えて、テーブルを収容するために過剰なメモリ空間が要求され、このため、定期的に、オブジェクトの有効寿命が満了する前に、オブジェクトをフラッシュ(除去)することが必要となる。本発明の方法においては、プロセッサダイジェスト値から直接に探索されているオブジェクトの位置を知ることができるために、スイッチング決定が行われる度にデーブルを探索する必要はなくなる。

0015

第二に、この交換機は、Port 80トラフィックリダイレクティング交換機(Port 80 traffic redirecting switches)と比較して、キャッシュサーバクラスタ(つまり、キャッシュされたページの単一の貯蔵庫として機能する複数のキャッシュサーバの相互接続された網)によって要求されるメモリ及び計算資源を削減でき、同時に、同程度の帯域幅の節約を維持することができる。「キャッシュサーバ(cache server)」は、オリジンサーバに向けられたトランザクションリクエストに割り込み、これらリクエストに答えて自身のメモリから要求された情報を供給する。ここで、「オリジンサーバ(origin server)」とは、ある選択されたトランザクションリクエストが最初にそれに向けられた、或いはそのリクエストがそれから最初に発信されたサーバ(例えば、パケットクッキーにて識別されるサーバ)を表す。ポート80交換機の場合は、これらキャッシュサーバの所で、キャッシュヒット或いはキャッシュミスが存在したか否かに関係なく、全ての接続を終端し、再び長期間アクセスされることはないようなオリジンサーバからのも含めて全てのページをキャッシングすることを要求される。これに対して、本発明による交換機は、これら二つの問題を解決するために、以前キャッシュヒットがあったリクエストに対してワイヤ速度のスイッチングを提供し、キャッシュミスがあったリクエストに対しても、それらの大多数に対してワイヤ速度スイッチングを提供することに加えて、ホットURLとオリジンHTTPサーバを識別することで、キャッシュサーバのキャッシュヒット率を向上させる。

0016

第三に、この交換機はサーバファームに対する逆方向プロキシ(reverse proxy)として機能し、サーバファームに代ってクライアントからの全ての接続リクエストを傍受及び受理する。

0017

第四に、HTTPとHTTPS形式のリクエスト及び応答がこの逆方向プロキシを通過するとき、この交換機は、サーバにて生成されたクッキーを解析し、ユーザリクエストに答えてシームレスな処理を提供する。

0018

第五に、この交換機は、入りトラフィックフローに関して、フローフィルタリング、分別、トラフィックパターン学習、及び優先シェーピング(priority shaping)を遂行することができる。

0019

第六に、この交換機は、ブラウザからの全てのHTTPトラフィックを傍受し、これらをHTTPキャッシュサーバに向けられるように戦略的に配置され、クライアントに対してより高速な応答とより快適なウェブサーフィング体験を提供することができる。

0020

最後に、これら交換機は高度にスケーラブルであるために、これら交換機を一つのクラスタに構成し、ダイジェスト情報及び/或いはタグ情報をそのクラスタ内の様々な交換機にて共有することができる。こうして情報を共有することで、冗長性のみでなく、スケーラビリティも向上される。

0021

上に説明の実施形態及び構成は、完全なものでも、全てでもない。後の説明から明らかとなるように、上に説明した或いは以下に詳細に説明する一つ或いは複数の構成要件を単独にて或いは組合せて用いる他の形態も可能である。

0022

詳細な説明
網交換機の構成要素
本発明は、好ましくは図1コンテントダイレクタサーバ(content director server)として示されるようなサーバコンピュータシステム(server computer system)として実現される。複数のコンテントダイレクタサーバa−nが、一つの好ましい実施例においては電子商取引タイプのHTTPトランザクションをサポートするために一つのクラスタにグループ化される。サーバファーム(server farm)104は、オリジンサーバ(origin server)108、ダイナミックコンテントサーバ112及び/或いはキャッシュサーバ116を含む。トラフィックマネジャ120 a−nは、周知の技法を用いて、複数のコンテントダイレクタから構成されるクラスタ間の負荷バランシング(load balancing)を遂行する。ルータ128 a−nから構成されるルータプール(router pool)124は、パケットを通信網132からのトラフィックマネジャ120 a−nへとルーティングする。

0023

各コンテントダイレクタサーバは、図2にその概略を示すように、HTTPトランザクションを、IPデータパケット内のこれと関連する不変量に基づいて効率的にルーティングするためのインテリジェントフロースイッチ200を含む。オプションとして、SSLプロセッサ204を設け、機密セッション協議(secure session negotiation)と実際の計算(actual computations)の両方において行われる暗号化及び復号動作オフロードにて遂行することもできる。更に、オプションとして、キャッシュプロセッサ208を設け、頻繁にリクエストされるコンテントすなわち「ホット(hot)」コンテントをキャッシュ212内にキャッシュ(格納)することもできる。ダイジェスト発生器216によってURLダイジェストが生成され、ローカルダイジェストメモリ220内に格納されると共に、複製され、直接に或いは間接的に、同一クラスタ内の他の網フロースイッチに送られる。

0024

コンテントダイレクタ100は、HTTPトラフィックをリダイレクティングする過程において、HTTPリクエストのトラフィックパターンを、クライアントブラウザ(図示せず)によってリクエストされたURL識別子を監視することで学習する。可変閾値(ホットURL閾値)が超えられると、新たに見つけられたホットな(オリジン)サーバに向けられたHTTPリクエストの全てのトラフィックフローはキャッシュサーバ116にリダイレクトされる。「フロー(flow)」なる語句は、クライアントとサーバ間、或いはある接続セッションにおける二つのピア間の、全てのトランザクションを指す。他方、あまりアクセスされないURLに対するリクエストは、キャッシュサーバ116にではなく、直接にオリジンサーバ108にスイッチされる。一つの動作モードにおいては、コンテントダイレクタは全てのHTTPトラフィックを透明に傍受し、これをキャッシュサーバ116に、特別なプロトコル或いはパケットタグを付加することなく、リダイレクトする。キャッシュサーバ116はクライアント(図示せず)との間にスプーフ接続(spoof connections)を形成する。コンテントダイレクタは、更に、キャッシュサーバのクラスタのメンバへのHTTPトラフィックを、周知の技法、例えばラルンドビン方式或いは扱われた接続の数(a number−of−connections−served)に基づいて負荷バランスする。

0025

コンテントダイレクタ100は、HTTPでないトラフィックをその元の宛先にスイッチすると共に、最初は、全てのHTTPフローを、それらの自身のオリジンサーバ108にスイッチする。リクエストされたURLをワイヤ上でコンテントダイレクタにてスヌープ(監視)することで、トラフィックパターンのホットなURLのデータベースが構築される。URL識別子のメッセージダイジェストが、キャッシュ212内の、ホットなURLのデータベース或いはテーブル内に格納される。ある幾つかのサーバへのフローがホットになると(つまり、ある所定の時間期間内に受信されたサーバ内のあるオブジェクトに対するリクエストの数がホットURL閾値に達する或いはこれを超えると)、そのサーバのIPアドレスがホットなIPのデータベース内に入れられ、その後は、そのホットウェブサーバへの新たな接続は、コンテントダイレクタによってHTTPキャッシュサーバ116にリダイレクトされる。こうしてリダイレクト或いはスイッチされたフローは、スイッチドフロー(switched flow)と呼ばれ、オリジンサーバに向かうスイッチされなかったフローは、転送フロー(forwarded flow)と呼ばれる。

0026

コンテントダイレクタ100は、同一のオリジンサーバ108に向かう未処理のフローを、リダイレクトされるまで維持し、それらフローが互いに妨害しあうことなく完結できるようにする。HTTP接続仮想回路が、ブラウザ(或いはそのプロキシ)(図示せず)とオリジンサーバ(或いはそのプロキシ108)との間、ブラウザ(図示せず)と透明なHTTPキャッシュサーバ112との間、及びHTTPキャッシュサーバ112とオリジンサーバ108との、全ての間で維持される。ここで用いられる「仮想回路(virtual circuit)」なる語句は、二つのエンドポイント間に設定されたTCP/IP接続を意味する。

0027

ホットなサーバへのトラフィックパターンが冷えると、そのIPアドレスは年齢が過ぎたものとしてキャッシュ212内のホットなIP或いはURLデータベースから削除され、そのサーバへのトラフィックはその通常のフローへと戻される。以下ではコンテントダイレクタのこれら様々な構成要素についてより詳細に説明する。

0028

SSLプロセッサ
SSLプロセッサ204は、認証及び機密アソシエーション(security association)を遂行し;暗号アルゴリズムの協議に参加し、マスタシークレット(master secret)を確立し、セッションキーを計算し、セッションIDを割当て;HTTPSメッセージ暗号テキストにて扱い、これらを、トランザクションリクエストを平文テキストにて扱うHTTPサーバに中継し;セッションコンテクストをセッションIDと共に再接続に備えてキャッシングする。後に説明するように、初期SSLハンドシェークは、暗号器(cipher)の選択、マスタキーの交換、及びサーバの認証を扱う。このハンドシェーク段階が完了した後に、クライアントとサーバは、暗号アルゴリズムに関して同意し、メッセージを暗号化するためのセッションキーを導くためにマスタシークレットに関して同意し、さらにサーバによって同意されたコンテクストを識別するために割当てられるセッションIDに関して同意する。後に説明するように、SSLプロセッサは、典型的には、クライアントとの保護されたセッションを開始する前に、クライアントとの無保護のセッションを終端する。

0029

SSLセッションIDは、複数のSSLセッションに共通なスレッドである(共通に用いられる)。SSLv3においては、セッションIDは、TCP接続上を、第二及びその後の接続を通じて、平文にて輸送される。SSLv2においては、SSLサーバが初期ハンドシェークにおいてセッションIDを送り返す最初の時点から、セッションIDは暗号化される。セッションIDを見つけるためには、プロセッサは、機密コンテクスト(secure context)の確立に関与することを要求されるが、サーバからこの暗号処理をオフロードすることで、暗号加速資源(resources of cryptographic acceleration)をファーム104内の全てのサーバによってより効率的に利用することが可能となる。

0030

上述のように、SSLプロセッサ204は、再接続のために、セッションコンテクストとセッションID、機密アソシエーション、及び仮想ホット情報をキャッシュする。SSLプロセッサのキャッシュ(図示せず)内のエントリは典型的にはセッションIDを用いて索引付けされる。

0031

SSLプロセッサは、認証及び/或いは暗号化/復号を遂行するための任意の従来のハードウェアソフトウェアであり得る。後に説明するように、用途によっては、例えば、Virtual Privacy Networks(「VPN」)(或いはIPsec)においては、クライアントとサーバ間にSSL以外の機密プロトコルを用いることもできる。

0032

インテリジェントフロースイッチ
インテリジェントフロースイッチ(intelligent flow switch、IFS)200(スイッチ要素とも呼ばれる)は、サーバファーム104内のサーバの一つを、パケットのペイロード、例えば、埋め込まれた不変量に基づいて選択し、リクエストを選択されたサーバに転送し、サーバから応答を受信し、これらをクライアントに送り返す。これらリクエスト及び応答メッセージがIFSを通過するとき、IFSはサーバにて生成された不変量或いは機密セッション不変量を解析することで、ファーム内の選択されたサーバへのクライアントリクエストをシームレスに途切れることなく処理する。IFSは、HTPP応答を、サーバ生成クッキーを見つけるために解析すると共に、HTPPリクエストを、ユーザ返送クッキーを見つけるために解析する。IFSは、同一クッキーにてスレッドされた(送られた)全てのトランザクションを束ね、そのクッキー不変量を生成したサーバに向ける。不変量アソシエーション(invariant associations)に関する知識を複数のコンテントダイレクタ100間で共有し、CPU時間を多量に消費する暗号計算分散処理にオフロードすることで、IFSは、サーバファームの総合的な故障耐性と性能の向上に寄与すると共に、電子商取引インフラストラクチャを需要に応じて成長させることを可能にする。

0033

IFSメモリは、IFS動作を可能にするためにメモリ内に複数のデータオブジェクトを維持する。例えば、IFSは、オプションとして:網マネジャによって選択された、異なるタイプのパケット(例えば、「ホット」なパケット、「冷たい」パケット等)に対してサーバを選択するための規則及び/或いは方針のレコード;IPアドレス検索用のテーブル;及び(ワイヤ速度パケット交換用の全ての現仮想回路のレコードを維持するために用いられる)現接続テーブルを含み、これには、ソース不変量(例えば、URL、ポートアドレス、及び他の決められたフィールド)、宛先不変量(例えば、URL、ソースソケット3−タプル、及び他の決められたフィールド)、セッションID、対象URLに対してあるクライアントからの最後のパケットが受信した時刻を示す永続性タイムスタンプ(これはテーブルから所定の年齢に達した或いはこれを超えたエントリを除去するために用いられ、この年齢はクライアントが同一トランザクション或いはセッションの一部として送り返す尤度を最後のパケットが受信された時間に基づいて統計的に推定することで求められる)、クッキー名と値、及び/或いは他の選択された不変量が含まれる。IFSは、更にオプションとして、コンテントダイレクタによって生成されたタグを含むタグテーブルと、ソース及び宛先不変量を含む。現接続テーブル及び/或いはタグテーブル内の各エントリは、ソース不変量、宛先不変量、及び/或いはクッキー名と値の一つ或いは幾つかを用いて索引付けされる。

0034

キャッシュプロセッサ及びキャッシュ
キャッシュプロセッサ208は、IFS200と、キャッシュ212、ダイジェスト発生器216及びダイジェストメモリ220との間のプロセッサインタフェースとして機能する。キャッシュプロセッサは、こうして、IFS200によってリクエストされた、パケット内に含まれ、IFS200によって解析され、キャッシュプロセッサ208に転送されたペイロード不変量に対応するキャッシュ212及び/或いはダイジェストメモリ220内に格納されているデータを取り出す。

0035

キャッシュ212は、頻繁にリクエストされる「ホット」なコンテント(例えば、URL)と、それほど頻繁にはリクエストされないコンテント(例えば、URL)の両方を含むホットURLテーブルを含む。このホットURLテーブルは、典型的には、以下のフィールド、すなわち:ソース不変量(例えば、URL、ポートアドレス、及び他の関連するフィールド、例えば、ホットコンテント、一次URLと対応する或いはこれと関連する二次URL、或いは他のタイプの修飾子)、宛先不変量(例えば、URL、ソースソケット3−タプル、及び他の決められたフィールド)、クッキー名と値、あるエントリが最後に更新されたときを示す(ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる)タイムスタンプ、ヒットカウンタ、オプションとしての(タグモードの際にスイッチによって生成される)タグ、及び/或いは他の選択された不変量を含む。ホットURLテーブル内の各エントリは、典型的には宛先不変量及び/或いはクッキー名と値を用いて索引付けされる。

0036

リース条件(lease term)は典型的には網マネジャによって決められた規則或いは方針から成る。リース条件には、例えば、レコードの最大寿命、サーバ或いはサーバクラスタのクライアントによるアクセスに関しての制約或いは制限、パケットに対するホットな場合のルーティング指令、コンテントがどの程度ホットであるか、優先、選択されたコンテントへのアクセスに関する制限、ヒットカウンタのリセット方針などが含まれる。

0037

ダイジェスト発生器及びダイジェストメモリ
ダイジェスト発生器216は、キャッシュプロセッサ208から宛先不変量(例えば、URL及びクッキー値)を受信し、これら不変量をダイジェストに変換する。どのようなダイジェスティング法を用いることもできるが、好ましくは、ハッシング法が用いられる。好ましいハッシングアルゴリズムは以下の通りである:
L = h(K)
ここで、全てのキーKに対して、0≦L≦M

0038

ここで、Kは選択されたURL或いはURL識別子の一部或いは全てを表し、hはメッセージダイジェスト(message digest、MD)「指紋(fingerprint)」Kを入力引数として用いるハッシュ関数を表し、LはホットURLテーブル内のKの位置を表し、MはホットURLテーブルのサイズを表す。

0039

hは、計算が速くでき、衝突が最小となるように選択される。衝突は異なるキーK’から同一のLが計算されるときに発生する。衝突が発生した場合は、ホットURLテーブルのボタムからのかわりの位置が見つけられ、ホーム位置からリンクされる。円形連結リストを用いて同一のハッシュ関数を有する全てのMD「指紋」が連結される。ホーム位置の所のヘッドタグは円形リストのヘッドを指す。新たなレコードが見つかると、かわりの位置内のレコードがそのホーム位置を占拠するために、そのかわりの位置のレコードは撤去することを要求される。そのホーム位置内のレコードが削除されると、衝突チェーン内の別のレコードがそこに移動される。理解できるように、用途に応じて他のハッシング関数を用いることもできる。

0040

ダイジェストメモリによって保持されるダイジェストレコードは、通常は、図3に示すような形式を有する。ダイジェストレコードが複製されるとき、キャッシュ識別子300(これはハッシュ値と同一であり、図にはMD5値として示されている)が、その後のダイジェスト検索においてもリクエストされたオブジェクトを含む特定のローカルオブジェクトキャッシュの識別が生成されるようにそれらダイジェストレコードに付加される。このレコードは、さらに、サーバの宛先IPアドレスを参照する宛先IP304、リース条件308、ヒット或いはアクセスカウンタ、(ある所定の年齢に達した或いはこれを超えたエントリをテーブルから削除するために用いられる)あるエントリがいつ最後に更新された時刻を示すタイムスタンプ(図示せず)、及び/或いは他の選択された不変量を含む。

0041

あるURLオブジェクトに対するリクエストが受信されると、コンテントダイレクタ100は、そのピア(peer)からのキャッシュダイジェスト300を用いて、そのピアのどれが所望のオブジェクトを有するかを見つけ、そのダイレクタのピアからそのオブジェクトを、全てのネーバ(neighbor)に照会を送ることなく、取り出す。上の説明から明らかなように、キャッシュダイジェスト300は、キャッシュされているコンテンツコンパクトな形式での要約、或いはある特定のURLがそのキャッシュ内に存在するか否かの指標から成る。換言すれば、キャッシュダイジェスト300は、キャッシュ212のメモリ内の、そのハッシュに対応する一つ或いは複数のオブジェクトが置かれた特定の位置に対するポインタから成る。

0042

入りパケットに対するコンテントダイレクタの動作
以下ではコンテントダイレクタの動作を図1−7との関連で説明する。
図4のステップ400において、(トラフィックマネジャ120(図1)によって負荷バランスされた)入りパケットがSSLプロセッサ204(図2)によって受信される。SSLプロセッサ204は、ステップ404において、最初に、周知の技法を用いて機密アソシエーションと認証を遂行することで、クライアントの識別及び/或いはクライアントのそのウエブサイトへのアクセス権を検証する。これは典型的にはデジタル証明認証を用いて遂行される。

0043

ステップ408において、SSLプロセッサ204は、そのパケットが暗号化されているか否かを調べる。暗号化されているときは、プロセッサ204は、ステップ412において、そのパケットを周知の技法を用いて復号することで、暗号テキストを平文テキストに変換する。ステップ416において、平文テキストのパケットがIFS200(図2)に、更なる処理のために送られる。SSLプロセッサ204は、その後、次のパケットを処理するためにステップ400に戻る。
このパケットが、図5のステップ500において、IFS200によって受信される。

0044

IFSは、ステップ516において、そのパケットがHTTP接続であるか否か調べる。そうでない場合は、IFSは、ステップ520において、そのパケットをオリジンサーバに送り、その後、ステップ500に戻る。

0045

そのパケットがHTTP形式であるときは、IFSは、ステップ524において、そのパケットを解析し、選択されたフィールド、例えば、URLやクッキー(存在する場合)などの宛先不変量、ソース不変量、及び/或いは他のペイロード不変量を得る。永続性HTTP接続(persistent HTTP connection)においては、クライアントは、単一の接続にて、複数のリクエストを送り、同数の応答がサーバからリクエストの順番に送り返される。IFSは、各リクエストを走査することで、そのクッキーを得、そのクッキー永続性(cookie persistence)に基づいてサーバアソシエーション(server association)を作成する。IFSは、従って、単一のマルチリクエスト(single multiple request)を、複数の単一リクエスト(multiple single requests)に分解し、これらを、それぞれ、各々のリクエスト内に埋め込まれているクッキーに基づいて正しく選択されたサーバに送ることを要求される。ISFは、加えて、サーバからの応答を追跡し、これらをリクエストと同一の順序にて、クライアントに送り返すことを要求される。

0046

ステップ504において、コンテントダイレクタ100が、タグモードであることが決定されたときは、コンテントダイレクタ100は、ステップ508に進み、(そのパケット内にタグが既に存在しない場合は)タグを生成する。コンテントダイレクタ100は、宛先不変量に基づいてタグを生成し、そのタグをクッキー上に連結する。クライアントに応答が送られたとき、これらクッキー及び付加されたタグは、ブラウザによってそのクライアントのメモリ内に保存される。クライアントによってさらなるリクエストが送られるとき、これらクッキーと付加されたタグがそのパケットリクエストのペイロード内に挿入される。コンテントダイレクタ100は、これを解析することでクッキーを得、タグを識別し、パケットをそのタグと関連するサーバに直接に向ける(ダイレクトする)。そのクライアントがまだそのサーバファームに一度も訪問したことがないために、パケットがクッキーを有さないときは、そのサーバファームから応答がコンテントダイレクタ100によって受信されたとき、タグが生成され、そのクッキー上に連結される。ある一つのリクエストに対して、ドメイン、パス、及び最大年齢(max−age)の選択基準を満たす複数のクッキーが送り返されたときは、サーバ永続性(server persistence)は最も制限的なパス属性を有するクッキーを用いて決定される。次に、ステップ512において、そのパケットがオリジンサーバに転送され、IFSは、ステップ500に戻り、次のパケットを待つ。

0047

一つの構成においては、タグは、トランザクションリクエスト内のURLを扱うキャッシュ或いはオリジンサーバに基づいて生成される。各サーバには、一意サーバ識別子アルファベット数字、或いは英数字)が割り当てられる。IFSは、対象サーバに対応する一意なサーバ識別子を決定し、この識別子をそのパケット内の別のタグ、例えば、そのサーバによって生成されたクッキーに付加する。タグのビットサイズは、通常は、クッキーのサイズよりかなり小さい。一つの構成においては、タグは、前の応答がサーバによってクライアントに転送されたとき(或いはサーバからの出フローがスイッチを通過するとき)にのみ生成され、クッキーに付加される。

0048

コンテントダイレクタは一つモードにて動作することも、複数のモードにて動作することもできる。一つの構成においては、コンテントダイレクタはタグモードのみにて動作する。もう一つの構成においては、コンテントダイレクタはダイジェスティング(digesting mode)のみにて動作する。ダイジェスティングモードにおいては、ダイジェストが生成され、コンテントのホットさ(hotness)が監視され、トランザクションリクエストは、ホットさ及び/或いはクッキーに基づいてサーバにルートされる。もう一つの構成においては、コンテントダイレクタは、同時に両モードにて動作する。換言すれば、最初に、あるトランザクションに対して、クライアントとサーバがリクエストされたコンテントのホットさに基づいてペアリングされ、同一クライアントからのその後のトランザクションリクエストは、そのクライアントに最初に割当てられた各々のサーバと関連するサーバタグを含み、各々のサーバに直接にルートされる。

0049

スイッチクラスタ内では、スイッチクラスタがより効率よく動作できるように、ある一つのスイッチによって生成されたタグは、そのクラスタ内の他のスイッチに供給され、クラスタ内の他のスイッチは、埋め込まれたタグを含むその後送られるトランザクションリクエストを受信できるようにされる。

0050

コンテントダイレクタがタグモードにないときは、IFSは、ステップ528において、不変量フィールドをキャッシュプロセッサ208に転送する。

0051

キャッシュプロセッサは、図6のステップ600において、IFSから、これら宛先、ソース、及び/或いは他のペイロード不変量を受信する。キャッシュプロセッサ208は、ステップ604において、これら不変量をキャッシュ212内のホットURLテーブルと比較し、ステップ608において、そのコンテントが以前所定の時間期間(永続性期間)内に受信されたか否か決定し、受信された場合は、ステップ612において、そのコンテントがホットであるか否か決定される。一つの構成においては、キャッシュプロセッサは、クッキーの名前とその値を、テーブル内にリストされているそれらと比較する。一致する場合は、そのパスがそのURLと比較され、ヘッドが一致するか調べられ、一致するエントリ(match entry)から宛先サーバが決定される。

0052

そのコンテントが永続性期間内に以前リクエストされてないときは、キャッシュプロセッサ208は、ステップ616において、そのパケットが「HTTPGET」リクエストであるか否か決定する。「HTTP GET」リクエストでない場合は、キャッシュプロセッサ208は、ステップ620(後の説明)に進む。「HTTP GET」リクエストである場合は、キャッシュプロセッサ208は、ステップ624において、不変量をダイジェスト発生器216に送る。

0053

ダイジェスト発生器216は、図7のステップ700において、キャッシュプロセッサからダイジェストリクエストを受信する。ダイジェスト発生器は、ステップ704において、宛先関連不変量に対するダイジェストを生成し、ステップ708において、ダイジェスト、タイムスタンプ、宛先関連不変量、及びリース条件(ダイジェスト発生器はこれらリース条件をダイジェストメモリ内の規則/方針に基づいて決定する)をダイジェストメモリ220内にコピーし、ステップ712において、これらダイジェスト、タイムスタンプ、及びリース条件をキャッシュプロセッサ208に送る。ダイジェスト発生器は、次に、ステップ700に戻る。

0054

図6に戻り、キャッシュプロセッサは、ステップ628において、ダイジェスト発生器216からダイジェスト、タイムスタンプ、及びリース条件を受信し、ステップ632において、参照カウンタを初期化する。次に、キャッシュプロセッサ208は、ステップ634においてホットURLテーブルを更新し、ステップ620(後に説明)に進む。

0055

ステップ608において、パケット情報がホットURLテーブル内に存在する場合は、キャッシュプロセッサは、次に、ステップ612において、パケットによってリクエストされたコンテントがホットであるか否か決定する。パケットのURLは、ヒットカウンタが所定のレベル、すなわち、ホットURL閾値以上であるときはホットである。URLがホットな場合は、ステップ636において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ638において、ホットURLテーブルがこれを反映するように更新される。キャッシュプロセッサ208は、次に、ステップ620(後に説明)において、関連する応答をIFSに送る。URLがホットでない場合は、ステップ642において、ヒットカウンタが増分され、タイムスタンプが更新され、ステップ646において、ホットURLテーブルが更新される。ステップ650において、キャッシュプロセッサは、再び、そのURLが(増分されたカウンタの観点から)ホットURL閾値を超えるか否か決定する。超えない場合は、キャッシュプロセッサはステップ620(後に説明)に進む。超える場合は、キャッシュプロセッサは、ステップ654において、逆ドメイン名サービス(reverse domain name service)すなわちDNS検索を遂行することで、そのホットURLページを扱った特定のドメインを扱っている全てのIPアドレスを見つける。ステップ658において、これらアドレスがホットURLテーブル内に書込まれる。キャッシュプロセッサは、ステップ620に進む。

0056

ステップ620において、キャッシュプロセッサ208は、関連する応答をIFSに送る。パケットによってリクエストされたコンテントがホットである場合は、キャッシュプロセッサは、IFSに、コンテントがホットであることを示とともに、パケット内のその特定のURLを扱っているIPアドレスのリストを与えるメッセージを送り、任意の関連するリース条件を供給する。一つの構成においては、キャッシュプロセッサは、加えて、IFSに、ホットさの程度(degree of hotness)、例えば、ヒットカウンタの値を知らせる。パケットによってリクエストされたコンテントがホットでない場合は、キャッシュプロセッサは、IFSに、そのコンテントがホットでないことを示すメッセージを送り、任意の関連するリース条件を供給する。

0057

図5に戻り、IFS200は、ステップ530において、キャッシュプロセッサ208からの応答を受信する。IFS200は、次に、ステップ532において、そのペイロード内の解析されたフィールド(例えば、ソースIP、宛先IP、ソースソケット3−タプル)を現接続テーブル内にリストされるそれらと比較する。ステップ534において、一致が存在しない場合は、IFS200は、ステップ536において、新たな接続が存在するか(すなわち、そのパケットが現存の仮想回路の一部であるか)否かを決定する。この決定は、IFSがその接続に対して受信した第一のパケット内のヘッダフラグSYN)を調べることで遂行される。SYNフラグがセットされてないときは、そのパケットは現存の仮想回路には属さないものとみなされ、SYNフラグがセットされているときは、そのパケットは、そのサーバがホットになる前にクライアントとオリジンサーバとの間に設定された仮想回路に属するものとみなされる。接続が新たなものであるときは、ステップ540において、現接続テーブルが更新される。つまり、そのパケットペイロードの少なくともソースIP、宛先IP、ソースソケット3−タプルを含む新たなエントリが追加される。

0058

接続が新たなものであるか、古いものであるかに関係なく、IFSは、次に、ステップ544において、パケットペイロード内のURLがホットであるか否か決定する。URLがホットでない場合は、IFSはステップ548に進む。ステップ548において、IFSは、パケットをリアセンブルし、ステップ552において、パケットをオリジンサーバに送る。IFSは、次に、次のパケットを処理するためにステップ500に進む。

0059

ステップ544において、パケットペイロードがホットであるときは、IFSは、ステップ556において、関連するホットなキャッシュサーバアドレスを決定する。これは、キャッシュプロセッサ208から受信されたホットIPアドレスとリース条件のリスト、各IPアドレスに対応するキュー(どのキャッシュサーバが最も短いキューを有するかを決定するために用いられる)、及び/或いはIFSのメモリ内の規則/方針を調べることで行われる。ステップ560において、パケットが関連するIPアドレスを有するようにリアセンブルされ、ステップ564において、関連するキャッシュサーバに送られる。一つの構成においては、IFSは、Cache Array Routine Protocol(CAPP)を用いて、キャッシュ可能なURLオブジェクトをキャッシュサーバ間に分配する。キャッシュプロキシメンバ識別(cache proxy member identities)とリクエストされたURLのハッシング計算を行い、最高値を有する経路がルーティング解として決定される。こうして、URLは最高のハッシングスコアを有するキャッシュプロキシ(cache proxy)に向けられるために、URLキャッシュ位置再割当てを最小限に押さえることができる。

0060

IFSは、次に、受信される次のパケットに対してステップ500を反復する。
再びステップ534に戻り、現接続或いは現存する仮想回路が存在する場合は、ステップ580において、パケットがオリジンサーバに転送され、その後、IFSはステップ500に戻る。

0061

コンテントがホットになった後に、一つ或いは複数のキャッシュサーバがそのコンテントを含むオリジンサーバとの接続を設定することがある。この場合、これらキャッシュサーバは、オリジンサーバからURLのコピーを得、そのURLを自身のキャッシュから扱う。

0062

以下では、このキャッシュサーバの動作について、図8との関連で説明する。ステップ800において、キャッシュサーバはコンテントダイレクタからトランザクションリクエストを受信する。ステップ804において、受信キャッシュサーバは、そのパケットを自身で扱うことができるか否かを決定する。サーバは、キャッシュサーバがそのパケットを初めて受信し、まだそのパケット内の特定のURLをキャッシュ(格納)していないとき、そのパケットリクエスト法がHTTPGETリクエストではないとき、及び/或いはそのリクエストがキャッシュ可能なタイプのリクエストではないときは、そのパケットを扱うことはできない。キャッシュサーバがそのパケットを扱うことができないときは、キャッシュサーバは、ステップ806において、そのパケットをリアドレスし、そのパケットをオリジンサーバに送る。

0063

キャッシュサーバがそのパケットを扱うことができるときは、キャッシュサーバは、ステップ810において、そのパケットを処理する。キャッシュサーバはそのパケットをリアドレスし、そのパケットを新たな或いは現存する接続を通じてオリジンサーバにリダイレクトする。オリジンサーバは、そのURLを(そのURLがキャッシュ可能であるときは)キャッシュサーバに送り返す。キャッシュサーバは、そのURLのコピーを保存し、もう一つのコピーをクライアントに送り返す。

0064

キャッシュサーバは、ステップ808において、さらなるコンテント(或いはサブURL)或いはパイプライン(pipelines)を、現トランザクションリクエスト内のURLに対応するコンテント内で参照されているサブURLのホットさに基づいて先取りする。一例として、そのコンテント内に二つのサブURLが参照されており、各サブURLが異なるホットさの程度(その対応するヒットカウンタ内に異なるヒットの数)を有する場合は、キャッシュサーバは最も大きなヒット数を有するサブURLがクライアントによって次にリクエストされるURLであるとみなす。キャッシュサーバは、クライアントからの次のトランザクションリクエストが受信される前に、そのURLに対応するコンテント(或いはそのURL自体)を取り出し、こうすることで、後に受信されるリクエストを処理するために要求される時間を大幅に短縮することが可能となる。

0065

ステップ812において、キャッシュサーバは、コンテントを、サーバファーム動作が最も効率的に遂行される位置内に格納(キャッシュ)する。例えば、地理的に分散するサーバクラスタにおいては、どのコンテントがホットであるかは、地域或いは位置によって異なる。例えば、ある選択されたコンテントは、第一の地域においては第一のレベルのホットさを有し、第二の異なる地域においては異なる第二のレベルのホットさを有し得る。コンテントは、従って、そのコンテントが最もホットな地域にキャッシュ(格納)される。このやり方においては、第一の地域内のキャッシュサーバと、第二の地域内のキャッシュサーバとは、異なるキャッシングされたコンテントを有することとなる。代替として、ホットなコンテントを、関連するホットなコンテントが格納されているのと同一のサーバクラスタの一部内に格納することもできる。このやり方においては、選択されたコンテントがホットな場合、そのコンテントと関連する全てのコンテントが(それがホットであるか否かに関係なく)コピーされ、そのホットなコンテントと同一のキャッシュサーバクラスタ内に格納される。もう一つの構成においては、あるホットなURLと関連する幾つかのURLが周知の技法を用いてそのホットなURLに連結される。もう一つの構成においては、複数のサーバクラスタが、幾つかのサーバクラスタは第一(或いはそれ以上)のホットさの情報を格納し、第二の異なるセットのサーバクラスタは(第一のホットさより低い)第二のホットさとの情報と、これよりホットな(ただし、第一のホットさよりは低い)コンテントを格納するように積重ねられる。もう一つの構成においては、ホットなコンテントと関連するコンテントは、(その関連するコンテントはホットでなくても)ホットなコンテントと接近して(例えば、同一のキャッシュサーバ或いはキャッシュサーバクラスタ内に)格納される。

0066

一つの構成においては、キャッシュサーバ内のコンテントの位置は、そのコンテントのホットさの程度に基づく。換言すれば、コンテントがホットになるにつれて、そのコンテントは、キャッシュサーバ内の第一の最もアクセス性の良い項目が最も頻繁な(従って最高数の)ヒットを経験し、キャッシュ内の最もアクセス性の悪い或いは最も下の項目は最も少ない頻度(或いは最小数の)ヒットを経験するように、そのキャッシュサーバ内のよりアクセス性の良い或いはより高い位置に移動される。コンテントダイレクタ100は、コンテントのホットさの程度が時間と共に変動するに基づいて、様々なキャッシュサーバに対して、コンテントのメモリアドレス再配置(reposition 或いはrelocate)するように指令する。換言すれば、コンテントダイレクタは、第一の時間において、キャッシュサーバに対して、第一のコンテントをそのサーバ内のコンテントのスタック積み重ね)の第一に位置に移動するように指令し、コンテントのヒットの頻度が変動した後の第二の時間においては、そのキャッシュサーバに対して、その第一の項目(コンテント)をそのスタック内の第二のより低い或いはより高い位置に移動するように指令する。

0067

後に説明するように、キャッシュサーバは、キャッシュコンテントの新鮮さを定期的にチェック或いは要求に答えて再検証する。キャッシュサーバは、満了タイマを各キャッシュ可能なオブジェクト毎にオブジェクトの人気度、最大年齢、及びコンテントサーバによって施された最後の修正時刻に基づいて調節する。

0068

図1に戻り、複数のコンテントダイレクタ100a−nによってクラスタが形成されるが、こうすることでサーバアプリケーションによって確立された不変量(例えば、ダイジェスト、タグ、及びクッキー)に関する知識を共有することができ、冗長性と性能を向上させることが可能となる。これら共有される情報は、図示されるようにリンク136によって、全てのクラスタメンバ間に分配される。どの一つのノード故障単一ポイントを形成しない。コンテントダイレクタの追加或いは削除などでクラスタが変更される場合、共有される情報の一部のみを再分配することで済む。

0069

理解できるように、アプリケーション層のコンテントダイレクタの深い所にある情報にアクセスすることで、幾つかの予め定義されたトラフィック方針とサービスのクラスを管理することが可能となる。コンテントダイレクタは、サーバファームから設備へのフローパターンを学習し、サービスの提供を需要の突発的変化適応させ、ユーザによって求められる情報を優先的に供給できるようにする。コンテントダイレクタは、フローフィルタリング、分類、学習、優先シェーピング、及び転送を遂行する。コンテントを意識した制御のために、コンテントダイレクタは、キャッシュ可能なURLリクエストとキャッシュ不能なURLリクエストとを分類し、これらを、それらをより良く扱うことができるサーバに向けたり、更には、それらリクエストを自身のキャッシュから処理する。

0070

出パケットに対するコンテントダイレクタの動作
以下では図9との関連でIFSの出パケットフローに対する動作について説明する。ステップ900において、IFSは、対応するサーバから応答を受信する。IFSは、全ての出パケット或いはHTTP応答を受信する。ステップ904において、IFSは、選択されたフィールドを解析する(典型的には入りパケットについても同一のフィールドが解析される)。ステップ908において、IFSは、コンテントダイレクタがタグモード(上述)であるか否か決定する。コンテントダイレクタがタグモードにあるときは、IFSは、ステップ912において、そのパケット内のクッキーが新たなクッキーであるか否か決定する。新たなクッキーであるときは、IFSは、ステップ916において、タグを生成し、そのタグを、ステップ920において、クッキーに付加し、そのタグを、ステップ924において、キャッシュプロセッサに送る。IFSは、次に、ステップ928(後に説明)に進む。クッキーが新たなものではないときは、IFSは、そのクッキーは既にタグを含むものとみなし、ステップ928(後に説明)に進む。コンテントダイレクタがタグモードでないときは、IFSは、ステップ932において、ソースと宛先に関する不変量をキャッシュプロセッサに送る。キャッシュプロセッサは、それら解析されたフィールドがホットURLテーブル内に存在するか否か調べ、存在しない場合は、それらフィールドをダイジェスト発生器に送る。ダイジェスト発生器は、ダイジェストを生成し、ダイジェストメモリ内にレコードを作成する。ダイジェストはキャッシュプロセッサに送り返され、キャッシュプロセッサは、URLテーブル内のそのダイジェストに対応する位置にレコードを作成する。IFSは、ステップ928において、パケットをリアセンブルし、そのパケットを、ステップ936において、SSLプロセッサを介してクライアントに送る。

0071

上では本発明がソフトウェアに基づく実現との関連で具体的に説明されたが、本発明は、ハードウェアに基づくデバイス(例えば、特定用途向け集積回路ASIC)として実現することも、更には、ソフトウェアとハードウェアの両方に基づくデバイスとして実現することもできる。

0072

上では本発明がインタネットとの関連で説明されたが、本発明は、その網が回路スイッチ網であるかパケットスイッチ網であるか、コネクションレス網であるかコネクションオリエンテッド網であるか、同期網であるか非同期網であるか、シリアル伝送を用いるかパラレル伝送を用いるか、クラスタ/サーバアーキテクチャを用いるかピア・ツウ・ピアアーキテクチャを用いるか、及び/或いは他の網アプリケーションを用いるかに関係なく、他の網トポロジ上でも採用できる。ホットさ或いはタグを決定するために、クッキー或いはURL以外のアプリケーション不変量を用いることもできる。

0073

本発明の様々な変形及び修正態様を用いることができる。本発明の幾つかの特徴の一部のみを、他の特徴は省略して、用いることもできる。例えば、一つの代替実施例においては、コンテントダイレクタは、サーバからクライアントへの応答についても、ペイロード情報(例えば、ソースIP、宛先IP、クッキー名と値、等)に関して解析する。この情報が、一つ或いは複数の現接続テーブル及びホットURLテーブルに付加される。この実現は、サーバファームに出入りするトラフィックフローに関するより総合的な情報を提供できるという長所を有する。

0074

もう一つの実施例においては、キープアライブスキームを備えるパイプライン接続がキャッシュサーバとコンテントサーバとの間に維持される。これにより、事前に設定された接続を再使用したり、キャッシュされてないコンテントの配信を高速化することが可能となる。更に、コンテントパイプラインにて複数のコンテントサーバへのパラレル接続を設定し、あるページ内に埋め込まれた全てのオブジェクトを同時にダウンロードし、ウェブの内容を前後にローディングする過程に起因する遅延を克服することもできる。多くのウェブページは埋め込まれた参照を有する。アンカページがプリントされている間に、ブラウザはこれら埋め込まれた参照を取り出すための新たなリクエストを行う。インテリジェントキャッシュプロセッサは、送り返されたコンテントを走査し、その後のリクエストに備えて、埋め込まれたオブジェクトを先取りする。

0075

さらにもう一つの代替実施例においては、コンテントダイレクタは、ファーム内の静的コンテントサーバ(static content servers)と動的コンテントサーバ(dynamic content servers)とを、リクエストするURLとコンテントタイプに基づいて分別する。再検証は静的コンテントサーバにのみ送られる。コンテントダイレクタは、コンテントの更新に関する方針を通知され、更新されたオブジェクトはその時点で除去される。サーバは、更新されたコンテントを自動的に或いは手動にてをコンテントダイレクタに送る。

0076

さらにもう一つの実施例においては、コンテントダイレクタは、ソースIPアドレス、URL、コンテントタイプ或いはクッキーの幾つか或いは全てが一致するリクエストに対する動作(ロード/ダイレクト/キャッシュ)を指定する方針や規則を構成できるようにされる。「ロード(load)」規則は、ある幾つかのコンテントに対する全てのリクエストを、その瞬間におけるロード状態に基づいて、最も適するサーバに向けるために用いられる。「ダイレクタ(direct)」規則は、その他のコンテントに対するリクエストを、指定されたサーバに向けるために用いられ、「キャッシュ(cache)」規則は、コンテントダイレクタが、コンテントをキャッシュプロキシ(cache proxy)から扱えるようにするために用いられる。

0077

さらにもう一つの実施例においては、Squid Web Proxy Cacheがコンテントダイレクタによって用いられる。Squidコードは、プロセスの作成及び同期のオーバヘッドを回避するためにソケットとファイル読出し書込み用のNon−blocking I/O(非閉塞入出力)を用いる。コンテントダイレクタは、Cookie and Set CookieMIMEヘッダを走査し、全てのクッキーをデータベース内に保存し、クッキー方針を維持する。全ての他のキャリア機能はこのコードから削除される。Squidは、キャッシュされたオブジェクトを保存するために下層ファイルシステムを用いる。

0078

さらにもう一つの実施例においては、このファイルシステムをバイパスするために、URLとメモリ内の格納リスト(storage list)とがハッシュングされ、固定サイズディスクメモリマッピングされる。

0079

本発明は、様々な実施例において、ここで説明されたものと概ね同一の要素、方法、プロセス、システム及び/或いは装置を包含し、これには、様々な異なる実現、一部のみからの組み合わせ、及びこれらのサブセットも包含される。当業者においては、上の説明を理解することで、本発明をいかに実現及び使用するかを容易に理解できるものと期待される。本発明の幾つか実施例においては、ここで説明された項目のみを用いてデバイス或いはプロセスが実現され、他の幾つかの実施例においては、説明のデバイス或いはプロセスに用いられた項目の内の性能を改善するための項目は省略され、これによって実現の簡単さ及び/或いはコストの削減が達成される。

図面の簡単な説明

0080

上の説明は単に解説のためのもので、本発明を説明された形態に制限することを意図しない。上では、本発明の説明として、一つ或いは幾つかの実施例、幾つかの変形及び修正について説明したが、上の説明を読んだ後に明らかとなるような他の様々な変形及び修正も本発明の範囲に入る。許される範囲内の全ての代替を包含する権利を得ることが意図される。これらには、クレームにおいて主張されるそれらに対する、特許可能な主題として具体的に開示はされなかった、代替・互換可能或いは同等な構造、機能、レンジ或いはステップも含まれる。

図1
本発明の一つの実施例によるフロースイッチを用いるサーバファームのブロック図である。
図2
本発明の一つの実施例によるコンテントダイレクタの構成要素を示すブロック図である。
図3
本発明の一つの実施例によるデータメモリ内のデータオブジェクトのデータ構造を示す図である。
図4
本発明の一つの実施例によるSSLプロセッサの動作を流れ図にて示す図である。
図5
本発明の一つの実施例によるIFSの動作を流れ図にて示す図である。
図6
本発明の一つの実施例によるキャッシュプロセッサの動作を流れ図にて示す図である。
図7
本発明の一つの実施例によるダイジェスト発生器の動作を流れ図にて示す図である。
図8
本発明の一つの実施例による網交換機からトランザクションリクエストが受信された際のキャッシュサーバの動作を流れ図にて示す図である。
図9
本発明の一つの実施例による応答が受信された際のインテリジェントフロースイッチの動作を流れ図にて示す図である。
【符号の説明】
104 サーバファーム
108オリジンサーバ
112ダイナミックコンテントサーバ
116 キャッシュサーバ
120トラフィックマネジャ
124ルータプール
128 ルータ
132通信網
200 インテリジェントフロー交換機
204 SSLプロセッサ
208 キャッシュプロセッサ
212キャッシュ
216 ダイジェスト発生器
220ローカルダイジェストメモリ
208 キャッシュプロセッサ
300 キャッシュ識別子

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ