(57)【要約】【課題】通信装置の処理によって、無駄に維持されるセッションを低減することが可能なコンテンツ転送方法および装置を提供する。【解決手段】クライアントからコンテンツ転送要求を受け取った通信装置が、コンテンツ転送要求を宛先のサーバに中継する際に、コンテンツ転送要求に、コンテンツ転送要求の要求元のクライアントとサーバとの間に設定されるセッションをコンテンツ転送要求に対するレスポンスの転送後も継続する旨の情報が含まれていた場合に、継続する旨の情報が含まれていたコンテンツ転送要求の少なくとも一部について、継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える。【選択図】      図１
2010122933.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからコンテンツ転送要求を受け取った通信装置が、前記コンテンツ転送要求を宛先のサーバに中継する際に、
前記コンテンツ転送要求に、前記コンテンツ転送要求の要求元のクライアントと前記サーバとの間に設定されるセッションを前記コンテンツ転送要求に対するレスポンスの転送後も継続する旨の情報が含まれていた場合に、前記継続する旨の情報が含まれていたコンテンツ転送要求の少なくとも一部について、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える
ことを特徴とするコンテンツ転送方法。
【請求項２】
クライアントからコンテンツ転送要求を受け取って、前記コンテンツ転送要求を宛先のサーバに中継する中継手段と、
前記コンテンツ転送要求から、前記コンテンツ転送要求の要求元のクライアントと前記サーバとの間に設定されたセッションを前記コンテンツ転送要求に対するレスポンスの転送後も継続する旨の情報を検出する検出手段と、
前記継続する旨の情報が含まれていたコンテンツ転送要求の少なくとも一部について、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換えて、前記中継手段による中継処理に供する置換手段と
を備えたことを特徴とするコンテンツ転送装置。  
【請求項３】
請求項２に記載のコンテンツ転送装置において、
前記置換手段は、
前記継続する旨の情報が検出されたコンテンツ転送要求の中から、コンテンツの転送が継続的になされていない待機状態のまま設定が維持されているセッションに対応するクライアントを要求元とするコンテンツ転送要求を判別する判別手段と、
判別されたコンテンツ転送要求を、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える対象として選択する選択手段とを備えた
ことを特徴とするコンテンツ転送装置。
【請求項４】
請求項２に記載のコンテンツ転送装置において、
前記置換手段は、
前記継続する旨の情報が検出されたコンテンツ転送要求の中から、コンテンツの転送が継続的になされていない待機状態のまま設定が維持されているセッションに対応する要求元のクライアントと宛先のサーバとが一致するコンテンツ転送要求を判別する判別手段と、
判別されたコンテンツ転送要求を、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える対象として選択する選択手段とを備えた
ことを特徴とするコンテンツ転送装置。
【請求項５】
請求項２に記載のコンテンツ転送装置において、
前記置換手段は、
前記継続する旨の情報が検出されたコンテンツ転送要求の中から、コンテンツの転送が継続的になされていない待機状態となってから切断されたセッションに対応するクライアントを要求元とするコンテンツ転送要求を判別する判別手段と、
判別されたコンテンツ転送要求を、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える対象として選択する選択手段とを備えた
ことを特徴とするコンテンツ転送装置。
【請求項６】
請求項２に記載のコンテンツ転送装置において、
前記置換手段は、
前記中継手段により処理可能な処理リソース容量からコンテンツ転送のためのセッションの設定に割当済みの処理リソースを差し引いたリソース残容量を取得する残容量取得手段と、
取得されたリソース残容量の大きさに対応する確率に従って、前記継続する旨の情報が検出されたコンテンツ転送要求の中から、前記継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える対象となるコンテンツ転送要求を選択する選択手段とを備えた
ことを特徴とするコンテンツ転送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザのパソコンなどのクライアントがＷＥＢサーバなどからコンテンツをダウンロードする際にコンテンツの転送を行う通信装置において、コンテンツを転送するためのコンテンツ転送方法および装置に関する。
【背景技術】
【０００２】
ユーザのパソコンなどのクライアントからのリクエストは、通常、一つ以上の通信装置(例えばルータ)を介してＷＥＢサーバなどのサーバ装置に渡され、このリクエストに対するレスポンスとして、サーバ装置から要求されたコンテンツがクライアントを宛先として転送される。
【０００３】
クライアントからのリクエストをサーバ装置に転送し、また、サーバ装置からのレスポンスをクライアントに転送する通信経路上の各通信装置では、個々のリクエストに対応するセッションに、通信処理のための処理リソース(例えば、ＣＰＵのスレッドリソース)を割り当てて処理を行っている。
【０００４】
例えば、ＨＴＴＰ−ＧＥＴリクエストには、レスポンスの転送後にもセッションを継続させる選択を示す継続オプション(keep-alive)とレスポンスの転送後に自動的にセッションを切断させる選択を示す切断オプション(close)とがあり、これらのオプションがＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダで示されている。
【０００５】
通常は、同じセッションを利用してリクエストとレスポンスのやり取りが繰り返される可能性を考慮して、ＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダではkeep-aliveオプションが設定される場合が多い。
【０００６】
しかしながら、keep-aliveオプションが設定されたＨＴＴＰ−ＧＥＴリクエストに対応するセッションであっても、必ずしも、続けてダウンロードが実行されるとは限らないので、使われなくなったセッションを切断する仕組みも提供されている。具体的には、サーバ側で各セッションを監視し、新たなリクエストが一定時間にわたって到来しなかったことを検出したときに、サーバ側からそのセッションを切断する手順(ＴＣＰ切断シーケンス)を実行している。
【０００７】
このように、サーバ側のタイムアウトでセッションが切断されたときに、そのセッションにかかわっていた各通信装置のスレッドリソースが解放され、以降のコンテンツ転送処理に使用可能になる。
【特許文献１】特開２００５−３１８４７３号公報
【非特許文献１】「セキュアＷｅｂプログラミング  ＡＳＰ(Active Server Pages)編  Part ２」、佐名木智貴著、www.trusnet.com/secinfo/docs/webprog2/index.html、2008年10月21日検索
【発明の開示】
【発明が解決しようとする課題】
【０００８】
現状では、ＨＴＴＰ１．１でkeep-aliveオプションがデフォルトとなっていることもあり、単発のコンテンツのダウンロードを要求するＨＴＴＰ−ＧＥＴリクエストでも、コネクションヘッダにkeep-aliveオプションが設定され、レスポンスの転送後にサーバ装置側のタイムアウトまで待機状態のセッションが維持されている。
【０００９】
一方、通信装置において、セッションの維持のために割り当てることができるＣＰＵのスレッドリソースは有限である。このため、上述したようにして、待機状態とまま無駄に維持されるセッションが増加すると、新規のリクエストに対応するセッションに割り当てる未使用のＣＰＵスレッドリソースが枯渇し、新たなセッションを確立できなくなってしまう。
【００１０】
本発明は、通信装置の処理によって、無駄に維持されるセッションを低減することが可能なコンテンツ転送方法および装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した目的は、以下に開示するコンテンツ転送方法および装置によって達成することができる。
【００１２】
一つの観点に基づくコンテンツ転送方法は、クライアントからコンテンツ転送要求を受け取った通信装置が、コンテンツ転送要求を宛先のサーバに中継する際に、コンテンツ転送要求に、コンテンツ転送要求の要求元のクライアントとサーバとの間に設定されるセッションをコンテンツ転送要求に対するレスポンスの転送後も継続する旨の情報が含まれていた場合に、継続する旨の情報が含まれていたコンテンツ転送要求の少なくとも一部について、継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換える。
【００１３】
このように構成されたコンテンツ転送方法では、ＨＴＴＰ−ＧＥＴリクエストのようなコンテンツ転送要求を通信装置が中継する際に、少なくとも一部のコンテンツ転送要求のコネクションヘッダにkeep-aliveオプションなどとして含まれているセッションを継続させる旨の情報がコンテンツの転送後にセッションを切断する旨の情報(例えば、closeオプション)に置き換えられる。
【００１４】
別の観点に基づくコンテンツ転送装置は、クライアントからコンテンツ転送要求を受け取って、コンテンツ転送要求を宛先のサーバに中継する中継手段と、コンテンツ転送要求から、コンテンツ転送要求の要求元のクライアントとサーバとの間に設定されたセッションをコンテンツ転送要求に対するレスポンスの転送後も継続する旨の情報を検出する検出手段と、継続する旨の情報が含まれていたコンテンツ転送要求の少なくとも一部について、継続する旨の情報をレスポンスの転送後に切断する旨の情報に置き換えて、中継手段による中継処理に供する置換手段とを備える。
【００１５】
このように構成されたコンテンツ転送装置では、ＨＴＴＰ−ＧＥＴリクエストのようなコンテンツ転送要求が中継手段によって中継される過程で、コネクションヘッダにkeep-aliveオプションなどとして含まれているセッションを継続させる旨の情報を含むコンテンツ転送要求が検出手段によって検出される。この検出手段によって検出されたコンテンツ転送要求の少なくとも一部に含まれるセッションを継続する旨の情報は、置換手段により、コンテンツ転送後にセッションを切断する旨の情報に置き換えられ、その後、コンテンツ転送要求で指定されたサーバを宛先として送出される。
【発明の効果】
【００１６】
以上に基本構成を開示したコンテンツ転送方法および装置によれば、クライアントからのコンテンツ転送要求をサーバに転送する過程で上述した置き換えを行うことにより、コンテンツ転送要求に応じてサーバからコンテンツが転送された後に待機状態のまま維持されるセッションを削減することができる。
【００１７】
これにより、ルータなどの通信装置において、新規のコンテンツ転送要求に対応するセッションに割り当てる未使用のＣＰＵスレッドリソースの枯渇を防ぐリソース管理を実現することができる。
【発明を実施するための最良の形態】
【００１８】
以下、図面に基づいて、本発明の実施形態について詳細に説明する。
(実施形態１)
図１に、コンテンツ転送装置の一実施形態を示す。
【００１９】
図1に示す通信装置(例えば、ルータ)２１０ａにおいて、ＩＰフォワーディング部２１１に到来したＩＰパケットのうち、ＨＴＴＰプロトコルに従ってコンテンツの授受を行うためのＩＰパケットは、ＩＰフィルタ機能部２１２を介してＨＴＴＰプロキシ機能部２１３に渡される。例えば、クライアント２０１から送出されたＨＴＴＰ−ＧＥＴリクエストは、ＩＰフォワーディング部２１１によって宛先となるコンテンツサーバ２０２側の通信装置２１０ｂに中継される前に、ＩＰフィルタ機能部２１２を介してＨＴＴＰプロキシ機能部２１３の処理に供される。
【００２０】
このＨＴＴＰプロキシ機能部２１３では、セッション管理部２２１により、ＩＰフィルタ機能部２１２から受け取ったＩＰパケットに基づいて、コンテンツの転送などをＨＴＴＰプロトコルに従って行うためのセッション管理処理が行われる。また、リクエスト抽出部２２２により、ＩＰフィルタ機能部２１２から渡されたＩＰパケットからkeep-aliveオプションが設定されたＨＴＴＰ−ＧＥＴリクエストが抽出され、ヘッダ変換処理部２２３に渡される。ヘッダ変換処理部２２３は、後述する状態管理テーブル２２４および履歴管理テーブル２２５に蓄積された情報とセッション管理部２２１から得られる情報とに基づいて、抽出されたＨＴＴＰ−ＧＥＴリクエストについて、後述するようにしてヘッダ情報の変換の必要があると判断した場合に、コネクションヘッダ内のkeep-aliveオプションをcloseオプションに置き換える変換を行い、ＩＰフォワーディング機能部２１１に渡す。
【００２１】
このように、図１に示した実施形態では、通信装置２１０ａに備えられたＨＴＴＰプロキシ機能部２１３に備えられたリクエスト抽出部２２２、ヘッダ変換処理部２２３、状態管理テーブル２２４および履歴管理テーブル２２５を含む構成によって、課題を解決するための手段の項で基本構成を開示したコンテンツ転送装置の機能が実現される。
【００２２】
また、図１に示したサーチエンジン機能部２１４、通信規則管理機能部２１５および通信ログ管理機能部２１６は、ＨＴＴＰプロトコルに従って転送されるコンテンツについて、例えば、通信規則サーバ２０３に保持された通信規則に基づいて、要求元のクライアントへの転送が許可されるか否かを判定する処理およびこの判定処理に関するログ情報をログサーバ２０４に記録する処理を行う。
【００２３】
また、図１に示した通信装置２１０ｂは、通信装置２１０ａと同様のＨＴＴＰプロキシ機能部を備えて構成することができる。
【００２４】
以下、図１に示したＨＴＴＰプロキシ機能部２１３において、ＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダを変換する方法について詳細に説明する。
【００２５】
図２に、ヘッダ変換処理部の詳細構成を示す。また、図３に、状態管理テーブル２２４および履歴管理テーブル２２５の例を示す。
【００２６】
図２に示したヘッダ変換処理部２２３において、テーブル管理部２２６は、セッション管理部２２１から得られる情報に基づいて、状態管理テーブル２２４および履歴管理テーブル２２５への情報の登録および更新を行う。
【００２７】
例えば、セッション管理部２２１から新たなセッションの設定が通知されるごとに、テーブル管理部２２６は、そのセッションに割り当てられたスレッドリソースを示すスレッドＩＤに対応して、コンテンツ転送要求の送信元であるクライアントの送信元ＩＰアドレス(Ｃ１、Ｃ２，Ｃ３)と要求先のコンテンツを示すリクエストＵＲＩ（Ｓ１，Ｓ２，Ｓ３）を状態管理テーブル２２４に格納する(図３(ａ)参照)。また、図３(ａ)に示した状態管理テーブル２２４の例では、各スレッドＩＤに対応するエントリは、対応するセッションを介して転送されたコンテンツの数(コンテンツ転送数)と、転送中か否かを示す転送中フラグを含んでいる。これらの項目の内容は、セッション管理部２２１から得られる情報に基づいて、テーブル管理部２２６によって更新される。また、図３(ａ)に示した状態管理テーブル２２４の例において、各スレッドＩＤに対応する待機フラグは、上述したコンテンツ転送数および転送中フラグの更新に応じて、コンテンツ転送数が１以上となった後に転送中フラグが転送中でない旨を示すOFFとなったときに、テーブル管理部２２６により、セッションが使用中である旨を示すOFFから対応するセッションが待機状態である旨を示すONに更新される。
【００２８】
また、テーブル管理部２２６は、セッション管理部２２１からセッションの切断が通知されたときに、状態管理テーブル２２４から切断が通知されたセッションに対応するエントリを削除する。このとき、テーブル管理部２２６は、削除対象のエントリに含まれる待機フラグを参照し、待機フラグにONが設定されているエントリについては、送信元アドレスとリクエストＵＲＩとを履歴管理テーブル２２５に登録する。
【００２９】
図２に示した変換制御部２２７は、セッション管理部２２１から得られるスレッドリソースの使用状況と、状態検索部２２８および履歴検索部２２９を介して得られる状態管理テーブル２２４および履歴管理テーブル２２５の検索結果に基づいて、リクエスト抽出部２２２によって抽出されたＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダに設定されたkeep-aliveオプションの必要性を判断し、判断結果に応じてcloseオプションによる置き換えを実行する。
【００３０】
図４に、ヘッダ変換処理を表す流れ図を示す。また、図５に、コンテンツ転送動作を説明するシーケンス図を示す。
【００３１】
リクエスト抽出部２２２からＨＴＴＰ−ＧＥＴリクエストを受け取ると(ステップ３０１)、変換制御部２２７は、まず、状態管理テーブル２２４から、ＨＴＴＰ−ＧＥＴリクエストの送信元に一致する送信元ＩＰアドレスを含むエントリを見つけ、待機フラグを参照する(ステップ３０２)。
【００３２】
待機フラグによって待機中である旨が示されていた場合に(ステップ３０３の肯定判定)、変換制御部２２７は、ステップ３０１で受け取ったＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダに含まれるkeep-aliveオプションをcloseオプションに置き換えて(ステップ３０４)、処理を終了する。
【００３３】
一方、ステップ３０３の否定判定の場合に、変換制御部２２７は、履歴管理テーブル２２５を参照し(ステップ３０５)、ＨＴＴＰ−ＧＥＴリクエストの送信元に一致する送信元ＩＰアドレスを含むエントリが登録されていた場合に(ステップ３０６の肯定判定)、ステップ３０４と同様にコネクションヘッダの書き換え処理を行って処理を終了する。
【００３４】
このようにして、状態管理テーブル２２４に反映された現在のセッションの待機状態および履歴管理テーブル２２５に反映された待機履歴に基づいて、新たに受け取ったＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダを変換することにより、ＨＴＴＰ−ＧＥＴリクエストに設定されたkeep-aliveオプションのために、無駄に待機状態が維持されるセッションを削減することができる。
【００３５】
例えば、クライアントＣ１がコンテンツサーバＳ１のコンテンツの初めてダウンロードする際には、ＨＴＴＰ−ＧＥＴリクエストを中継する各通信装置の状態管理テーブル２２４にも、履歴管理テーブル２２５にも、まだクライアントＣ１のＩＰアドレスを含むエントリが登録されていないので、コネクションヘッダの変換は不要と判断される。この場合に、ＨＴＴＰ−ＧＥＴリクエストは、コネクションヘッダにkeep-aliveオプションが設定されたまま、図５に示すように、従来と同様に、各通信装置によって、そのまま中継されてコンテンツサーバＳ１に到達する。これに応じて、コンテンツサーバＳ１により、要求されたコンテンツを返却する処理が行われ、このコンテンツが要求元のクライアントＣ１に転送される過程で、各中継装置により、通信規則に基づく転送可否の判断が行われる。なお、図５の例では、各通信装置により、コンテンツの転送が通信規則に基づいて可とされ、クライアントＣ１までコンテンツが到達している。
【００３６】
このようにして、コンテンツの転送が完了したときに、各通信装置において、セッション管理部２２１からの通知に応じて、テーブル管理部２２６により、状態管理テーブル(図５において、状態管理Ｔとして示した)２２４が更新され、クライアントＣ１のＩＰアドレスとコンテンツサーバＳ１のＵＲＩとを含むエントリの待機フラグにONが設定される。
【００３７】
このように状態管理テーブル２２４が更新された後に、同じクライアントＣ１からコンテンツサーバＳ１へのＨＴＴＰ−ＧＥＴリクエスト(keep-aliveオプション)が発行された場合に、このＨＴＴＰ−ＧＥＴリクエストを最初に中継する通信装置において、上述したコネクションヘッダの変換が行われ、次の通信装置以降には、コネクションヘッダにcloseオプションが設定されたＨＴＴＰ−ＧＥＴリクエストが中継される(図５参照)。
【００３８】
この場合は、コンテンツサーバＳ１から返却されたコンテンツが、同様にして各通信装置によって中継され、要求元のクライアントＣ１に到達すると、コンテンツサーバＳ１により、ＴＣＰ切断シーケンスが実行され、このセッションは待機中となることなく切断される。
【００３９】
このように、図１，２に示した状態管理テーブル２２４に保持された情報に基づいて、コネクションヘッダの変換を行うことにより、セッションを待機状態で維持させているクライアント(例えば、図５のクライアントＣ１)が、新たなコンテンツのダウンロードを要求するＨＴＴＰ−ＧＥＴリクエストを発行した際に、このリクエストに応じて設定されたセッションが待機状態となることを防ぐことができる。
【００４０】
なお、図４に示したステップ３０２において、変換制御部２２７により、状態管理テーブル２２４から、ＨＴＴＰ−ＧＥＴリクエストに含まれる送信元ＩＰアドレスおよびコンテンツＵＲＩの双方が一致するエントリを見つけ、そのエントリの待機フラグに基づいて、ヘッダ変換を適用するか否かを判定することもできる。
【００４１】
また一方、コンテンツサーバ側のタイムアウトに応じてセッションが切断された場合には、図６に示すセッション切断時のテーブル管理部２２６の処理において、ステップ３１４の状態管理テーブル２２４からの対応エントリの削除に先立って、ステップ３１１〜ステップ３１３に示すように、状態管理テーブル２２４に切断されたセッションに対応して登録されたエントリの待機フラグに応じて、履歴管理テーブル２２５への登録が行われる。
【００４２】
したがって、図１，２に示した履歴管理テーブル２２５に保持された情報に基づいて、コネクションヘッダの変換を行うことにより、セッションを待機状態で維持させた履歴を持つクライアント(例えば、図５のクライアントＣ１)が、新たなコンテンツのダウンロードを要求するＨＴＴＰ−ＧＥＴリクエストを発行した際に、このリクエストに応じて設定されたセッションが待機状態となることを防ぐことができる。
【００４３】
なお、図６に示したセッション切断時のテーブル管理部２２６の処理において、状態管理テーブル２２４を参照した際に、削除対象のエントリの待機フラグがOFFに設定されていた場合に(ステップ３１２の否定判定)、この削除対象に対応する待機履歴を履歴管理テーブル２２５から削除することもできる。例えば、上述したようにして、セッションを待機させた履歴が履歴管理テーブル２２５に登録された後に、同じクライアントとコンテンツサーバとの組み合わせについて設定されたセッションが待機状態にならないで切断された場合に、テーブル管理部２２６は、履歴管理テーブル２２５を参照して(ステップ３１５)、このセッションに対応する送信元ＩＰアドレスとコンテンツＵＲＩとの組み合わせを探す。一致する組み合わせが履歴管理テーブル２２５に登録されていた場合に(ステップ３１６の肯定判定)、テーブル管理部２２６により、履歴管理テーブル２２５の対応するエントリが削除される。このようにして、上述した送信元ＩＰアドレスとコンテンツＵＲＩとの組み合わせが含まれるＨＴＴＰ−ＧＥＴリクエストは、再びセッションの待機状態を発生させるまでは、ヘッダ変換の対象から外される。
【００４４】
上述したように、待機中のセッションとは別に新たなセッションの設定を要求するクライアントや、サーバ側のタイムアウトに応じて待機中のまま切断されたセッションを設定させたクライアントは、新たに発行するＨＴＴＰ−ＧＥＴリクエストに応じて設定されるセッションについても、待機状態のまま無用に維持させてしまう可能性が高い。
【００４５】
したがって、上述したような送信元のクライアントの振舞いに基づいて、ＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダを、デフォルトのkeep-aliveオプションからcloseオプションに変換することにより、待機状態のまま無用に維持されるセッションの数を大幅に削減することができる。
(実施形態２)
一方、送信元のクライアントの振舞いにかかわらず上述したようなコネクションヘッダの変換を適用することもできる。
【００４６】
図７に、ヘッダ変換処理を表す別の流れ図を示す。
【００４７】
図２に示した変換制御部２２７は、セッション管理部２２１からスレッドリソース使用状況の通知を受け(図７のステップ３２１)、未使用のスレッドリソースの量に応じた確率でコネクションヘッダの変換を適用するか否かを決定する(ステップ３２２)。
【００４８】
例えば、変換制御部２２７の内部に、スレッドリソースの残量と変換を適用する確率(変換確率)との対応関係を示す表を保持しておき(図８参照)、セッション管理部２２１から通知されたスレッドリソースの使用状況に基づいて、リソース残量に対応する変換確率を決定し、この変換確率に従って、コネクションヘッダを変換するか否かを決定することができる。図８に示した例では、スレッドリソースの残量が全体の８０％以上である場合には、コネクションヘッダの変換は行われないが、セッションに割り当て可能なスレッドリソースの残量が５０％以上８０％未満では、５０％の確率でコネクションヘッダの変換が行われ、スレッドリソースの残量が５０％以下では、８０％の確率でコネクションヘッダの変換が行われる。
【００４９】
変換が適用される場合に(ステップ３２３の肯定判定)、変換制御部２２７は、図４に示したステップ３０４と同様にコネクションヘッダの変換を実行した後に処理を終了し、一方、変換が適用されない場合は(ステップ３２３の否定判定)、コネクションヘッダのkeep-aliveオプションはそのまま残される。
【００５０】
このように、ＨＴＴＰ−ＧＥＴリクエストの送信元や宛先にかかわらず、セッションへの割当が可能なスレッドリソースの残量に応じた確率でコネクションヘッダの変換対象とすることにより、確実に待機状態のまま無用に維持されるセッションの数を制限することが可能となる。
【００５１】
なお、スレッドリソースの残量と変換確率との対応関係は、個々の通信装置２１０が配置されるシステムの構成などによって、様々に設定することができる。例えば、変換確率を設定する区分を図８に示した例(３個)より多くしても良いし、逆に少なくすることもできる。また、各区分に対応させる変換確率も自由に設定することができる。更に、スレッドリソースの残量を変数とする関数によって変換確率を求めることもできる。
【００５２】
上述した実施形態１で説明した、送信元のクライアントの振舞いに基づいてＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダを変換する手法と、実施形態２で説明したスレッドリソースの残量に対応する変換確率でコネクションヘッダを変換する手法とを組み合わせることもできる。
【００５３】
一方、図１に示したリクエスト抽出部２２２によって抽出された全てのＨＴＴＰ−ＧＥＴリクエストのコネクションヘッダを変換対象として、keep-aliveオプションからcloseオプションへの置き換えを行うように、コンテンツ転送装置を構成することもできる。
【図面の簡単な説明】
【００５４】
【図１】コンテンツ転送装置の実施形態を示す図である。
【図２】ヘッダ変換処理部の詳細構成を示す図である。
【図３】状態管理テーブルおよび履歴管理テーブルの例を示す図である。
【図４】ヘッダ変換処理を表す流れ図である。
【図５】コンテンツ転送動作を説明するシーケンス図である。
【図６】セッション切断時のテーブル管理動作を表す流れ図である。
【図７】ヘッダ変換処理を表す別の流れ図である。
【図８】スレッドリソースの残量とヘッダ変換確率との関係を説明する図である。
【符号の説明】
【００５５】
２０１  クライアント
２０２  コンテンツサーバ
２０３  通信規則サーバ
２０４  ログサーバ
２１０  通信装置
２１１  ＩＰフォワーディング機能部
２１２  ＩＰフィルタ機能部
２１３  ＨＴＴＰプロキシ機能部
２１４  サーチエンジン機能部
２１５  通信規則管理機能部
２１６  通信ログ管理機能部
２２１  セッション管理部
２２２  リクエスト抽出部
２２３  ヘッダ変換処理部
２２４  状態管理テーブル
２２５  履歴管理テーブル
２２６  テーブル管理部
２２７  変換制御部
２２８  状態検索部
２２９  履歴検索部
【図１】
2010122933.tif 000003
【図２】
2010122933.tif 000004
【図３】
2010122933.tif 000005
【図４】
2010122933.tif 000006
【図５】
2010122933.tif 000007
【図６】
2010122933.tif 000008
【図７】
2010122933.tif 000009
【図８】
2010122933.tif 000010