JP4201550B2 - 負荷分散装置 - Google Patents
負荷分散装置 Download PDFInfo
- Publication number
- JP4201550B2 JP4201550B2 JP2002254233A JP2002254233A JP4201550B2 JP 4201550 B2 JP4201550 B2 JP 4201550B2 JP 2002254233 A JP2002254233 A JP 2002254233A JP 2002254233 A JP2002254233 A JP 2002254233A JP 4201550 B2 JP4201550 B2 JP 4201550B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- client
- data
- server
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000004044 response Effects 0.000 claims description 84
- 238000012546 transfer Methods 0.000 claims description 57
- 238000012790 confirmation Methods 0.000 claims description 34
- 238000013500 data storage Methods 0.000 claims description 6
- 238000002360 preparation method Methods 0.000 claims description 5
- 239000000872 buffer Substances 0.000 description 107
- 230000005540 biological transmission Effects 0.000 description 52
- 238000000605 extraction Methods 0.000 description 39
- 238000010586 diagram Methods 0.000 description 31
- 238000007726 management method Methods 0.000 description 30
- 238000001514 detection method Methods 0.000 description 11
- 238000000034 method Methods 0.000 description 11
- 239000000284 extract Substances 0.000 description 10
- 230000007246 mechanism Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000010365 information processing Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000020169 heat generation Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1014—Server selection for load balancing based on the content of a request
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のサーバを仮想的に一台のサーバのように見せて動作させる負荷分散装置に関する。
【０００２】
【従来の技術】
任意の端末間におけるデータの送受信では、データ到着の保証を図るため、再送管理が行われている。再送管理を行う送信元端末は、送信バッファを有し、送信先端末へ送信したデータを、送信バッファに記憶しておく。そして、データの異常や消失が検出された場合に、送信元端末は送信先端末へ、送信バッファに記憶しておいたデータを再送する。送信先端末は、送信元端末から送信されたデータを正しく受信した場合に、確認応答データを送信元端末に送信する。送信元端末は、送信先端末から確認応答データを受信した場合に、送信バッファに記憶しておいたデータを消去し、送信バッファを解放する。このような再送管理を行うプロトコルの例として、ＴＣＰ（Transport Control Protocol）がある。
【０００３】
このような再送管理は、負荷分散装置でも行われる。負荷分散装置とは、複数のサーバに対して、クライアントからのリクエストを振り分ける装置である。負荷分散装置を用いることにより、クライアントからのリクエストが一定のサーバに集中することが回避される。
【０００４】
このような負荷分散装置にとって、送信バッファを構成するメモリ領域は、有限のリソースである。一つのセッションにおける送信バッファの使用時間（保留時間）を減少させることにより、リソースの有効利用を図ることが可能となる。リソースの有効利用の結果として、例えばセッションの多重度の向上や、消費電力の減少などを図ることが可能となる。
【０００５】
従来、ＴＣＰに対応する負荷分散装置において、再送管理を省略することにより送信バッファから早期にデータを消去し送信バッファの使用時間を減少させる技術がある。この技術では、負荷分散装置は、再送管理を省略する場合には、本来行う必要がある再送管理を、サーバ又はクライアントに任せる。この場合、負荷分散装置は、サーバからレスポンスを受信した際に、サーバに対しＡｃｋ（確認応答）の送信を行わない。負荷分散装置は、サーバから受信したレスポンスをクライアントへ転送し、送信バッファに記憶しているレスポンスを消去する。
【０００６】
図１は、従来技術における負荷分散装置Ｐ３が、再送管理を省略した場合の、クライアントＰ２，負荷分散装置Ｐ３，及びサーバＰ４の動作シーケンスを示す図である。図１を用いて、負荷分散装置Ｐ３が再送管理を省略する場合の、クライアントＰ２，負荷分散装置Ｐ３，及びサーバＰ４の動作について説明する。
【０００７】
データが、サーバＰ４からクライアントＰ２に、正常に転送された場合（図１（ａ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。負荷分散装置Ｐ３は、クライアントＰ２にレスポンスを転送する。クライアントＰ２は、レスポンスを受信し、負荷分散装置Ｐ３にＡｃｋを送信する。負荷分散装置Ｐ３は、サーバＰ４にＡｃｋを転送する。そして、サーバＰ４はＡｃｋを含むパケット（Ａｃｋパケット）を、負荷分散装置Ｐ３から受信する。このような動作によって、サーバＰ４は、データがクライアントＰ２に正常に受信されたことを確認する。
【０００８】
次に、データがサーバＰ４−負荷分散装置Ｐ３間で消失した場合（図１（ｂ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。このとき、データが消失したと仮定する。この場合、負荷分散装置Ｐ３は何も受信せず、何の処理も行わない。そして、サーバＰ４は、タイムアウト秒が経過するまで待機しても、負荷分散装置Ｐ３からＡｃｋを受信できないため、レスポンスを再送する。
【０００９】
次に、パケットが、負荷分散装置Ｐ３−クライアントＰ２間で消失した場合（図１（ｃ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。負荷分散装置Ｐ３は、受信したレスポンスをクライアントＰ２に転送する。このとき、データが消失したと仮定する。この場合、クライアントＰ２は何も受信せず、何の処理も行わない。そして、サーバＰ４はタイムアウト秒が経過するまで待機しても、負荷分散装置Ｐ３からＡｃｋを受信できないため、負荷分散装置Ｐ３へレスポンスを再送する。
【００１０】
【発明が解決しようとする課題】
上記技術では、負荷分散装置は、サーバから受信するレスポンスについての再送管理を省略している。ここで、負荷分散装置は、クライアントから受信するリクエストについても、再送管理を省略することにより、送信バッファの使用時間をさらに減少させることができる。
【００１１】
しかし、クライアントがデータ送信においてスロースタートメカニズムを用いている場合、負荷分散装置は、クライアントから受信するリクエストについての再送管理を省略することができない。
【００１２】
図２は、スロースタートメカニズムを示す図である。図２を用いて、スロースタートメカニズムについて説明する。スロースタートメカニズムを用いた送信端末（クライアント）が受信端末（負荷分散装置）にデータを送信する場合、送信端末は、同時に送信するデータ数（同時送信データ数）を、１から指数関数的に増加させる（図２（ａ）参照）。このとき、送信端末は、受信端末から前のデータのＡｃｋを受信するまで、次のデータの送信を待機する。
【００１３】
クライアントＰ２が、スロースタートメカニズムを用いて、負荷分散装置Ｐ３に対し、データを送信すると仮定する。このとき、リクエストが単独のデータで構成されている場合、負荷分散装置Ｐ３は受信したデータについて、ＵＲＬを抽出し、振り分け先を決定し、決定したサーバＰ４に対して転送処理を行うことが可能である。従って、最終的に、クライアントＰ２はサーバＰ４から、負荷分散装置Ｐ３を経由してレスポンスを受信できる。
【００１４】
一方、リクエストが複数のデータに分割されて構成されている場合、クライアントＰ２は、リクエストを構成する１以上のデータを負荷分散装置Ｐ３に送信する毎に、そのデータに対するＡｃｋの受信を待機する状態となる（図２（ｂ）参照）。図２（ｂ）では、一つのリクエストが、データＤｃとデータＤｄとに分割されている。そして、クライアントＰ２は、データＤｃに対するＡｃｋを、負荷分散装置Ｐ３から受信するまで、データＤｄを送信しない。
【００１５】
ここで、負荷分散装置Ｐ３がクライアントＰ２から受信するリクエストについての再送管理を省略している場合、クライアントＰ２は、送信したデータＤｃに対するＡｃｋを負荷分散装置Ｐ３から受信できない。このため、クライアントＰ２は、負荷分散装置Ｐ３へ、データＤｃの再送を繰り返す。再送が繰り返されても、負荷分散装置Ｐ３は、クライアントＰ２にＡｃｋを送信しない。この結果、負荷分散装置Ｐ３は、データＤｄを受信できず、リクエストを完全に受信することができない。このため、負荷分散装置Ｐ３は、リクエストについて、ＵＲＬの抽出や、振り分け先の決定などを実行できない。従って、負荷分散装置Ｐ３は、クライアントＰ２から受信したリクエストを、サーバＰ４に転送できず、全体としてデータの送受信が滞ってしまう。
【００１６】
負荷分散装置Ｐ３は、上記したようなリクエストを受信できなくなることを避けるため、クライアントＰ２から受信するリクエストについては、そのリクエストの内容に関わらず、クライアントＰ２にＡｃｋを送信する。この場合、負荷分散装置Ｐ３は、クライアントＰ２から受信したリクエストについて再送管理を行う必要がある。即ち、負荷分散装置Ｐ３は、サーバＰ４から、リクエストに対するＡｃｋを受信するまで、クライアントＰ２から受信したリクエストを送信バッファに記憶しておく必要がある。
【００１７】
図３は、従来技術の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。図３を用いて、負荷分散装置Ｐ３がクライアントＰ２から受信したリクエストに対してＡｃｋを送信するにも関わらずこのリクエストを送信バッファに記憶しない場合に発生する問題について説明する。負荷分散装置Ｐ３からサーバＰ４に転送されたリクエストが、正常にサーバＰ４で受信された場合（図３（ａ）参照）には、問題は生じない。
【００１８】
一方、負荷分散装置Ｐ３からサーバＰ４に転送されたリクエストがサーバＰ４に受信される前に消失した場合（図３（ｂ）参照）には、次のような問題が発生する。即ち、負荷分散装置Ｐ３は、送信バッファにリクエストを記憶していないため、サーバＰ４にリクエストを再送できない。一方、クライアントＰ２は、負荷分散装置Ｐ３からＡｃｋを受信した時点で、リクエストを送信バッファから消去する。このため、クライアントＰ２は、負荷分散装置Ｐ３にリクエストを再送できない。
【００１９】
従って、負荷分散装置Ｐ３は、リクエストの消失に備え、サーバＰ４からＡｃｋを受信するまで、リクエストを送信バッファから消去せずに記憶しておかなければならない。このように、従来技術における負荷分散装置Ｐ３は、クライアントＰ２から受信するリクエストに対する再送管理を省略できない。このため、従来技術における負荷分散装置Ｐ３は、送信バッファの使用時間を減少できない。
【００２０】
本発明は、このような問題を解決し、クライアントから受信するリクエストに対する再送管理を省略することにより、送信バッファの使用時間を減少することが可能な負荷分散装置を提供することを目的とする。
【００２１】
【課題を解決するための手段】
上記問題を解決するため、本発明は以下のような構成をとる。本発明の第一の態様は、負荷分散装置であって、クライアントから受信したデータの内容に応じて、クライアントへ当該データの確認応答を送信するか否かを判断する判断手段と、前記判断手段の判断結果に応じて、クライアントへ確認応答を送信する確認応答手段と、前記クライアントから受信したデータを複数のサーバのいずれかへ転送する転送手段と、前記サーバへ転送されたデータのうち、このデータについてクライアントへ確認応答が送信されたデータのみを、前記サーバへの再送に備えて記憶する再送データ記憶手段と、を備える。
【００２２】
本発明の第一の態様によれば、判断手段は、クライアントから受信したデータの内容を解析し、このデータの内容に応じてクライアントへ確認応答を送信するか否かを判断する。この確認応答は、クライアントから受信したデータに対する確認応答である。判断手段が上記判断を実行すると、確認応答手段は、この判断結果に基づいて、クライアントへ確認応答を送信する。転送手段はクライアントから受信したデータを複数のサーバのいずれかへ転送する。再送データ記憶手段は、サーバへ転送されたデータを、このサーバへのデータ再送に備えて記憶する。
【００２３】
このため、再送データ記憶手段は、確認応答がクライアントに送信されないデータを記憶しない。従って、再送データ記憶手段は、サーバに転送されるデータ全てを記憶するわけではなく、使用される記憶領域が削減される。
【００２４】
また、本発明の第一の態様における前記判断手段は、クライアントから受信したデータがデリミタを含まない場合にクライアントへ確認応答を送信すると判断し、前記データがデリミタを含む場合にクライアントへ確認応答を送信しないと判断するように構成されても良い。
【００２５】
このように構成された本発明の第一の態様によれば、判断手段は、クライアントから受信したデータがデリミタを含むか否かに応じて、クライアントへこのデータの確認応答を送信するか否かを判断する。そして、確認応答手段は、デリミタを含まないデータが受信された場合、このデータに対する確認応答をクライアントへ送信する。
【００２６】
このため、クライアントがスロースタートメカニズムを採用している場合であっても、負荷分散装置はクライアントからデリミタを含まないデータの次のデータを受信することが可能となる。
【００２７】
また、本発明の第一の態様は、連続する複数のデータをサーバへ転送する場合に、最後にサーバに転送されたデータに対する確認応答をサーバから受信したときに、次のデータをサーバへ転送することを許可する確認応答判断手段をさらに備えるように構成されても良い。
【００２８】
また、本発明の第一の態様は、サーバから受信されたデータを、クライアントへ転送すべきか否かを判断する転送判断手段をさらに備えるように構成されても良い。
【００２９】
また、本発明の第一の態様における前記転送判断手段は、前記サーバから受信されたデータが、確認応答のためのデータのみからなる場合に転送すべきでないと判断するように構成されても良い。
【００３０】
【発明の実施の形態】
次に、図を用いて本発明の実施形態における負荷分散装置を用いた負荷分散システムについて説明する。なお、本実施形態の説明は例示であり、本発明は以下の説明する構成に限定されない。
【００３１】
〔第一実施形態〕
〈システム構成〉
図４は、負荷分散システム１の概略を示す図である。第一実施形態における負荷分散装置３を用いた負荷分散システム１は、複数のクライアント２，負荷分散装置３，複数のサーバ４，及び複数のクライアント２と負荷分散装置３とを通信可能に接続するネットワーク５を用いて構成される。本実施形態における負荷分散装置３は、例として、ＴＣＰ／ＩＰ（Transport Control Protocol / Internet Protocol）を用いてＨＴＴＰを取り扱う。これに従い、クライアント２とサーバ４とは、少なくとも、ＴＣＰ／ＩＰを用いてＨＴＴＰを取り扱う。負荷分散装置３は、確認応答を行うプロトコルを扱う装置であれば良く、ＴＣＰ／ＩＰを取り扱う装置に限定されない。以下、負荷分散システム１の各構成について説明する。
【００３２】
〈〈クライアント〉〉
クライアント２は、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。クライアント２は、ネットワークカード等の通信装置を用いて、ネットワーク５を介して負荷分散装置３と通信可能に構成される。クライアント２は、ブラウザソフトがインストールされており、負荷分散装置３に対し、ＨＴＴＰリクエストを含むパケットを送信する。そして、クライアント２は、負荷分散装置３から、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスを含むパケットを受信する。クライアント２は、受信したＨＴＴＰレスポンスの内容を、ブラウザソフトを用いて表示する。また、クライアント２は、スロースタートメカニズムを用いてパケットを送信する。
【００３３】
〈〈負荷分散装置〉〉
負荷分散装置３は、パーソナルコンピュータやワークステーション等の情報処理装置や、負荷分散処理を行うことを前提とした専用ハードウェア等によって構成される。図５は、負荷分散装置３のブロック図である。図５を用いて負荷分散装置３について説明する。負荷分散装置３は、ハードウェア的には、バスを介して接続されたＣＰＵ，主記憶（ＲＡＭ），補助記憶装置（ハードディスク），通信制御装置（ネットワークカード等）等を備えている。あるいは、専用のパケット処理プロセッサ，パケット処理のための記憶装置（ＲＡＭ），通信制御装置（ネットワークカード等）等から構成される場合もある。負荷分散装置３は、補助記憶装置に記憶された各種のプログラム（ＯＳ，アプリケーション等）が主記憶にロードされＣＰＵにより実行されることによって、あるいはパケット処理プロセッサがあらかじめ組み込まれた処理に従って動作することによって、ネットワークインタフェース６，７，パケットバッファ８，９，Ａｃｋ番号抽出部１０，１８，再送管理タイマ１１，１９，シーケンス番号・データ長抽出部１２，１３，Ａｃｋ応答生成部１４，１５，ＨＴＴＰデリミタ検出部１６，及び振り分け先決定部１７等を含む装置として機能する。
【００３４】
ネットワークインタフェース６，７は、ネットワークカード等を用いて構成される。ネットワークインタフェース６は、クライアント２から送信されたパケットを、ネットワーク５を介して受信し、パケットバッファ８に書き込む。また、ネットワークインタフェース６は、パケットバッファ９から受信するパケットを、ネットワーク５を介してクライアント２に送信する。ネットワークインタフェース７は、サーバ４から送信されたパケットを受信し、パケットバッファ９に書き込む。また、ネットワークインタフェース７は、パケットバッファ８から受信するパケットを、サーバ４に送信する。
【００３５】
パケットバッファ８，９は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。パケットバッファ８は、再送管理タイマ１１から再送信号を受信すると、この再送信号に含まれる識別子に対応するパケットを、ネットワークインタフェース７へ送信する。パケットバッファ８は、クライアント２から送信されたパケット、あるいは負荷分散装置３によって生成されたパケットをバッファリングする。そして、パケットバッファ８は、バッファリングしているパケットをネットワークインタフェース７へ送信する。また、パケットバッファ８は、Ａｃｋ応答生成部１５によってパケットをバッファリングされると、このパケットをネットワークインタフェース７へ送信する。また、パケットバッファ８は、振り分け先決定部１７から消去信号を受信すると、この消去信号に含まれる識別子に対応するパケットが転送されたことを確認し、このパケットを消去する。
【００３６】
パケットバッファ９は、再送管理タイマ１９から再送信号を受信すると、この再送信号に含まれる識別子に対応するパケットを、ネットワークインタフェース６へ送信する。パケットバッファ９は、サーバ４から送信されたパケット、あるいは負荷分散装置３によって生成されたパケットをバッファリングする。そして、パケットバッファ９は、バッファリングしているパケットをネットワークインタフェース６へ送信する。また、パケットバッファ９は、Ａｃｋ応答生成部１４によってパケットをバッファリングされると、このパケットをネットワークインタフェース６へ送信する。
【００３７】
Ａｃｋ番号抽出部１０，１８は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。Ａｃｋ番号抽出部１０は、パケットバッファ８にバッファリングされたパケットのＡｃｋ番号を抽出する。また、Ａｃｋ番号抽出部１０は、シーケンス番号・データ長抽出部１３から、シーケンス番号及びデータ長を受信する。即ち、Ａｃｋ番号抽出部１０は、パケットバッファ９にバッファリングされたパケットのシーケンス番号及びデータ長を受信する。そして、Ａｃｋ番号抽出部１０は、Ａｃｋ番号の値と、シーケンス番号及びデータ長の和とを比較する。Ａｃｋ番号抽出部１０は、Ａｃｋ番号の方が大きい値又は同じ値である場合、パケットバッファ９に、このシーケンス番号及びデータ長の値を含むパケットの識別子を含む消去信号を送信する。消去信号は、消去すべきパケットの識別子を含む。
【００３８】
Ａｃｋ番号抽出部１８は、パケットバッファ９にバッファリングされたパケットのＡｃｋ番号を抽出する。また、Ａｃｋ番号抽出部１８は、シーケンス番号・データ長抽出部１２から、シーケンス番号及びデータ長を受信する。即ち、Ａｃｋ番号抽出部１８は、パケットバッファ８にバッファリングされたパケットのシーケンス番号及びデータ長を受信する。そして、Ａｃｋ番号抽出部１８は、Ａｃｋ番号の値と、シーケンス番号とデータ長とを加算した値とを比較する。Ａｃｋ番号抽出部１８は、Ａｃｋ番号の方が大きい値又は同じ値である場合、パケットバッファ８に消去信号を送信する。消去信号は、消去すべきパケットの識別子を含む。
【００３９】
再送管理タイマ１１，１９は、クロックやＣＰＵ等、あるいは専用パケット処理プロセッサ等を用いて構成される。再送管理タイマ１１は、パケットバッファ８にバッファリングされたパケットが、ネットワークインタフェース７によって送信されてからの経過時間を計時する。再送管理タイマ１１は、送信されてから一定時間以上経過した（タイムアウトの）パケットがある場合、このパケットの識別子を含む再送信号を、パケットバッファ８へ送信する。
【００４０】
再送管理タイマ１９は、パケットバッファ９にバッファリングされたパケットが、ネットワークインタフェース６によって送信されてからの経過時間を計時する。再送管理タイマ１９は、送信されてから一定時間以上経過したパケットがある場合、このパケットの識別子を含む再送信号を、パケットバッファ９へ送信する。
【００４１】
シーケンス番号・データ長抽出部１２，１３は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。シーケンス番号・データ長抽出部１２は、パケットバッファ８にバッファリングされているパケットのシーケンス番号及びデータ長を抽出する。そして、シーケンス番号・データ長抽出部１２は、シーケンス番号及びデータ長を、Ａｃｋ応答生成部１４及びＡｃｋ番号抽出部１８に送信する。
【００４２】
シーケンス番号・データ長抽出部１３は、パケットバッファ９にバッファリングされているパケットのシーケンス番号及びデータ長を抽出する。そして、シーケンス番号・データ長抽出部１３は、シーケンス番号及びデータ長を、Ａｃｋ応答生成部１５及びＡｃｋ番号抽出部１０に送信する。
【００４３】
Ａｃｋ応答生成部１４，１５は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。Ａｃｋ応答生成部１４は、シーケンス番号・データ長抽出部１２から受信した二つの値の和をＡｃｋ番号として持つパケットを生成する。そして、Ａｃｋ応答生成部１４は、生成したパケットをパケットバッファ９にバッファリングする。
【００４４】
Ａｃｋ応答生成部１５は、シーケンス番号・データ長抽出部１３から受信した二つの値の和をＡｃｋ番号として持つパケットを生成する。そして、Ａｃｋ応答生成部１５は、生成したパケットをパケットバッファ８にバッファリングする。
【００４５】
ＨＴＴＰデリミタ検出部１６は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。ＨＴＴＰデリミタ検出部１６は、パケットバッファ８にバッファリングされるＨＴＴＰリクエストを含むパケット（リクエストパケット）のペイロードに、ＨＴＴＰのデリミタ（Delimiter：例えば空行）が存在するか否かを判断する。ＨＴＴＰデリミタ検出部１６は、デリミタが存在する場合、振り分け先決定部１７へ、転送信号を送信する。この転送信号は、ＨＴＴＰデリミタ検出部１６がデリミタを検出したリクエストパケットの識別子を含む。
【００４６】
また、ＨＴＴＰデリミタ検出部１６は、リクエストパケットにデリミタが存在しない場合、シーケンス番号・データ長抽出部１２へ指示を出し、クライアント２に対し、Ａｃｋを含むパケット（Ａｃｋパケット）を送信する処理を実行させる。
【００４７】
振り分け先決定部１７は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。振り分け先決定部１７は、ＨＴＴＰデリミタ検出部１６から転送信号を受信すると、転送信号に含まれる識別子に対応するリクエストパケットに含まれるＵＲＬを抽出し、このＵＲＬが示すコンテンツを保有する最適なサーバ４を選択する。その上でそのリクエストパケットを、選択したサーバ４へ転送する。即ち、振り分け先決定部１７は、転送対象となるリクエストパケットの送信先アドレスや送信元アドレス等の情報を書き換えることにより、このリクエストパケットをサーバ４へ転送する。また、振り分け先決定部１７は、転送対象となるリクエストパケットのうち、デリミタを有するリクエストパケットの識別子を含む消去信号をパケットバッファ８へ送信する。
【００４８】
なお、Ａｃｋ番号抽出部１０，１８，シーケンス番号・データ長抽出部１２，１３，ＨＴＴＰデリミタ検出部１６，振り分け先決定部１７，及びＡｃｋ応答生成部１４，１５は、各々独立に動作するのではなく、パケットの到着に伴い順に動作する。また、パケット受信、送信に伴う上記記載以外に必要となる処理については、従来行われている処理であるため、説明を省略する。
【００４９】
〈〈サーバ〉〉
図４に戻って、サーバ４は、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。サーバ４は、ネットワークカード等の通信装置を用いて、負荷分散装置３と通信可能に構成される。サーバ４では、ＨＴＴＰＤ（HTTP Daemon）が実行される。サーバ４は、負荷分散装置３から受信するリクエストパケットに対し、ＨＴＴＰレスポンスを含むパケット（レスポンスパケット）を返信する。
【００５０】
〈動作例〉
図６〜８は、負荷分散装置３の動作例を示すフローチャートである。図５，図６〜８を用いて、負荷分散装置３の動作例について説明する。ここでは、負荷分散装置３は、クライアント２からリクエストパケットを受信し、サーバ４からレスポンスパケットを受信するものとして説明する。
【００５１】
負荷分散装置３のネットワークインタフェース６は、クライアント２からリクエストパケットを受信する（図６参照：Ｓ０１）。パケットバッファ８は、受信したリクエストパケットをバッファリングする（Ｓ０２）。Ａｃｋ番号抽出部１０は、このリクエストパケットからＡｃｋ番号を抽出する（Ｓ０３）。また、シーケンス番号・データ長抽出部１３は、パケットバッファ９にバッファリングされたパケットのシーケンス番号及びデータ長を抽出し、Ａｃｋ番号抽出部１０へ送信する（Ｓ０４）。Ａｃｋ番号抽出部１０は、抽出したＡｃｋ番号と、シーケンス番号及びデータ長の和とを比較する（Ｓ０５）。Ａｃｋ番号よりもシーケンス番号及びデータ長の和が小さな値となるパケットがパケットバッファ９にバッファリングされている場合（Ｓ０５−ＹＥＳ）、パケットバッファ９は、そのパケットを消去する（Ｓ０６）。
【００５２】
次に、ＨＴＴＰデリミタ検出部１６は、パケットバッファ８にバッファリングされたリクエストパケットがデリミタを含むか否かを判断する（Ｓ０７）。ＨＴＴＰデリミタ検出部１６がデリミタを検出しない場合（Ｓ０７−ＮＯ）、シーケンス番号・データ長抽出部１２は、Ａｃｋ応答生成部１４へ、抽出したシーケンス番号及びデータ長を送信する。Ａｃｋ番号応答生成部１４は、受信したシーケンス番号及びデータ長を加算する。そして、Ａｃｋ番号応答生成部１４は、この値をＡｃｋ番号として持つパケットを生成し、パケットバッファ９にこのパケットをバッファリングする（Ｓ０８）。パケットバッファ９は、バッファリングされたパケットを、ネットワークインタフェース６を介して、クライアント２へ送信する（Ｓ０９）。この後、負荷分散装置３は、新たなリクエストパケットをクライアント２から受信すると、改めてＳ０１〜Ｓ０７の処理を実行する。
【００５３】
一方、ＨＴＴＰデリミタ検出部１６は、デリミタを検出した場合（Ｓ０７−Ｙｅｓ）、振り分け先決定部１７へ転送信号を送信する。振り分け先決定部１７は、パケットバッファ８からリクエストパケットのペイロード部を読み込み、そこに示されているＵＲＬをコンテンツとして持つ適当なサーバ４を決定する（Ｓ１０）。振り分け先決定部１７は、決定されたサーバ４に対するＴＣＰコネクションがオープンされると、サーバ４に対し、リクエストパケット全てを転送する（Ｓ１１）。このとき、振り分け先決定部１７は、転送対象となるリクエストパケットのうち、デリミタを有するリクエストパケットの識別子を含む消去信号をパケットバッファ８へ送信する。そして、パケットバッファ８はこのリクエストパケットを消去する。
【００５４】
再送管理タイマ１１は、タイムアウトのリクエストパケットがある場合（図７参照：Ｓ１２−Ｙｅｓ）、このリクエストパケットの識別子を含む再送信号を、パケットバッファ８へ送信する。そして、パケットバッファ８は、この再送信号に含まれる識別子が示すリクエストパケットを、サーバ４へ再送する（Ｓ１３）。
【００５５】
一方、タイムアウトのリクエストパケットが無い場合（Ｓ１２−Ｎｏ）、ネットワークインタフェース７がサーバ４からパケットを受信したか否かを判断する（Ｓ１４）。ネットワークインタフェース７がパケットを受信していない場合（Ｓ１４−Ｎｏ）、再びタイムアウトの判断に戻る。一方、ネットワークインタフェース７がサーバ４からパケットを受信した場合（Ｓ１４−Ｙｅｓ）、パケットバッファ９は、このパケットをバッファリングする（Ｓ１５）。
【００５６】
パケットバッファ９がパケットをバッファリングした後、Ａｃｋ番号抽出部１８は、バッファリングされたパケットのＡｃｋ番号を抽出する（図８参照：Ｓ１６）。また、シーケンス番号・データ長抽出部１２は、パケットバッファ８にバッファリングされたパケットのシーケンス番号及びデータ長を抽出し、Ａｃｋ番号抽出部１８へ送信する（Ｓ１７）。Ａｃｋ番号抽出部１８は、シーケンス番号及びデータ長の和が、抽出されたＡｃｋ番号と同じ又は小さい値であるパケットの存在を判断する（Ｓ１８）。このようなパケットがパケットバッファ８にバッファリングされている場合（Ｓ１８−Ｙｅｓ）、パケットバッファ８は、そのパケットを消去する（Ｓ１９）。
【００５７】
パケットバッファ９は、バッファリングしたパケット（サーバ４から受信されたパケット）を、クライアント２に転送する（Ｓ２０）。そして、パケットバッファ９は、転送したパケットを消去する（Ｓ２１）。
【００５８】
〈動作シーケンス〉
次に、第一実施形態における負荷分散システム１の動作シーケンスについて説明する。図９（ａ），（ｂ）は、ＨＴＴＰリクエストが一つのリクエストパケットで構成される場合の、負荷分散システム１の動作シーケンスを示す図である。第一に、図９（ａ）を用いて、ＨＴＴＰリクエストが一つのリクエストパケットで構成され、リクエストパケットが消失しない場合の動作シーケンスについて説明する。
【００５９】
まず、クライアント２と負荷分散装置３とは、ＴＣＰのコネクションをオープンする（オープンフェーズ：図９（ａ）参照）。クライアント２は、コネクションをオープンした後、データ転送フェーズの処理として、負荷分散装置３にリクエストパケット（ＨＴＴＰリクエストを含むパケット）を送信する。
【００６０】
負荷分散装置３は、クライアント２からリクエストパケットを受信する。負荷分散装置３は、受信したリクエストパケットがデリミタを含むか否かを判断する。この場合、リクエストパケットは一つのパケットで構成されるため、リクエストパケットはデリミタを含む。このため、負荷分散装置３は、リクエストパケットに示されているＵＲＬをコンテンツとして持つ適当なサーバ４を決定する。そして、負荷分散装置３は、決定されたサーバ４に対するＴＣＰコネクションをオープンし、サーバ４に対し、リクエストパケットを転送する。このとき、負荷分散装置３は、このリクエストパケットを、パケットバッファ８から消去する。
【００６１】
サーバ４は、負荷分散装置３からリクエストパケットを受信する。サーバ４は、受信したリクエストパケットに対するレスポンスパケット（ＨＴＴＰレスポンスを含むパケット）を生成する。そして、サーバ４は、負荷分散装置３に対し、レスポンスパケットを送信する。
【００６２】
負荷分散装置３は、レスポンスパケットを受信する。負荷分散装置３は、受信したレスポンスパケットを、クライアント２に転送する。このとき、負荷分散装置３は、このレスポンスパケットをパケットバッファ９から消去する。そして、クライアント２は、クローズフェーズの処理を実行する。
【００６３】
第二に、図９（ｂ）を用いて、ＨＴＴＰリクエストが一つのリクエストパケットで構成され、リクエストパケットが消失する場合の動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスにおけるオープンフェーズとクローズフェーズとは、どのような場合であっても同じであるため、以後、オープンフェーズとクローズフェーズとについての説明を省略する。
【００６４】
まず、クライアント２はリクエストパケットを負荷分散装置３へ送信する。負荷分散装置３は、リクエストパケットのペイロードを解析し、振り分け先サーバ４を決定し、サーバ４に対してＴＣＰコネクションをオープンする。負荷分散装置３はリクエストパケットを、決定されたサーバ４に転送する。このとき、転送されたリクエストパケットが消失したとする。この場合、サーバ４は、負荷分散装置３から、転送されたリクエストパケットを受信しない。従って、サーバ４は、リクエストパケットに対するＡｃｋパケットを、負荷分散装置３へ送信しない。このため、この場合、クライアント２は、リクエストパケットに対するＡｃｋパケットを、負荷分散装置３から受信できない。クライアント２は、タイムアウトとなると（タイムアウト秒待つと）、リクエストパケットを、負荷分散装置３へ再送する。そして、負荷分散装置３は、再送されたリクエストパケットを受信し、サーバ４へ転送する。クライアント２は、送信したリクエストパケットに対するＡｃｋを受信するまでこの動作を繰り返す。そして、最終的に、クライアント２は、負荷分散装置３から、レスポンスパケットを受信する。
【００６５】
図１０，１１（ａ），１１（ｂ）は、ＨＴＴＰリクエストが複数のリクエストパケットで構成される場合の、負荷分散システム１の動作シーケンスを示す図である。第三に、図１０を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットが消失しない場合の動作シーケンスについて説明する。
【００６６】
ここではデリミタを含まないリクエストパケットをリクエストパケットａ（ＨＴＴＰリクエストａを含むリクエストパケット）、デリミタを含むリクエストパケットをリクエストパケットｂ（ＨＴＴＰリクエストｂを含むリクエストパケット）とする。即ち、一つのＨＴＴＰリクエストが、ＨＴＴＰリクエストａとＨＴＴＰリクエストｂとに分かれて構成される。ＨＴＴＰリクエストが、三つ以上のリクエストパケットで構成されている場合、最後のリクエストパケットをリクエストパケットｂ、その直前までのリクエストパケットをリクエストパケットａとみなせばよい。
【００６７】
クライアント２は、リクエストパケットａを、負荷分散装置３へ送信する。負荷分散装置３はリクエストパケットａのペイロードを解析し、リクエストパケットａにデリミタが含まれていないと判断する。このため、負荷分散装置３は、クライアント２に対しＡｃｋを含むパケット（Ａｃｋパケット）を送信する。
【００６８】
クライアント２は、負荷分散装置３から、Ａｃｋパケットを受信する。そして、クライアント２は、負荷分散装備３へ、リクエストパケットｂを送信する。負荷分散装置３は、リクエストパケットｂのペイロードを解析し、デリミタが含まれていると判断する。このため、負荷分散装置３は、先に受信したリクエストパケットａとリクエストパケットｂとを用いて、振り分け先サーバ４を決定する。そして、負荷分散装置３は、決定したサーバ４に対してＴＣＰコネクションをオープンし、リクエストパケットａ，ｂをサーバ４に転送する。
【００６９】
サーバ４は、リクエストパケットａ，ｂを、負荷分散装置３から受信する。サーバ４は、受信したリクエストパケットに対するレスポンスパケットを生成する。そして、サーバ４は、生成したレスポンスパケットを、負荷分散装置３へ送信する。
【００７０】
負荷分散装置３は、レスポンスパケットに含まれるＡｃｋ番号を用いて、リクエストパケットａに対する受信確認をする。負荷分散装置３は、レスポンスパケットをクライアント２に転送する。
【００７１】
クライアント２は、レスポンスパケットを受信する。そして、クライアント２は、受信したレスポンスパケットにより、受信確認をする。
【００７２】
第四に、図１１（ａ）を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットａが消失する場合の動作シーケンスについて説明する。ただし、負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送するまでの動作シーケンスは、第三の場合と同じであるため、その説明を省略する。
【００７３】
負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送した後に、リクエストパケットａが消失したものとする。この場合、サーバ４は、リクエストパケットｂを受信するが、リクエストパケットａを受信しない。このため、サーバ４は、リクエストパケットａに対するＡｃｋを含むパケットを送信しない。
【００７４】
負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信できないため、タイムアウト秒経過後、リクエストパケットａをサーバ４に再送する。負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信するまでこの処理を繰り返す。最終的に、負荷分散装置３は、サーバ４からレスポンスパケットを受信し、受信したレスポンスパケットをクライアント２へ転送する。このとき、このレスポンスパケットは、リクエストパケットａに対するＡｃｋを含む。このため、負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信したこととなる。
【００７５】
第五に、図１１（ｂ）を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットｂが消失する場合の動作シーケンスについて説明する。ただし、負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送するまでの動作シーケンスは、第三の場合と同じであるため省略する。
【００７６】
負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送した後に、リクエストパケットｂが消失したものとする。この場合、サーバ４は、リクエストパケットａのみを受信する。このため、サーバ４はリクエストパケットａのみに対するＡｃｋを含むパケットを、負荷分散装置３へ送信する。
【００７７】
負荷分散装置３は、リクエストパケットａに対するＡｃｋを含むパケットを受信する。その後、負荷分散装置３は、このＡｃｋを含むパケットをクライアント２へ転送する。
【００７８】
クライアント２は、リクエストパケットａに対するＡｃｋを含むパケットを受信する。しかし、クライアント２は、リクエストパケットａに対するＡｃｋを含むパケットは既に受信済みであるため、何も実行しない。即ち、クライアント２は、既に負荷分散装置３から、リクエストパケットａに対するＡｃｋを含むパケットを受信しているため、何の処理も実行しない。ただし、クライアント２は、リクエストパケットｂに対するＡｃｋを含むパケットを受信できない。このため、クライアント２は、タイムアウト秒経過後、リクエストパケットｂを、負荷分散装置３へ再送する。
【００７９】
クライアント２は、負荷分散装置３からレスポンスパケットを受信するまでこの処理を繰り返す。このとき、レスポンスパケットは、リクエストパケットｂに対するＡｃｋを含む。このため、クライアント２は、負荷分散装置３からＡｃｋパケットを受信したこととなる。
【００８０】
〈作用〉
本発明の第一実施形態における負荷分散装置３は、ＨＴＴＰリクエストが一つのリクエストパケットにより構成される場合、リクエストパケットに対するＡｃｋをクライアント２に送信しない。従って、負荷分散装置３は、リクエストパケットについて再送管理を実行する必要が無い。このため、このリクエストパケットを、パケットバッファ８から早期に消去することが可能となる。即ち、負荷分散装置３は、パケットバッファ８の記憶領域を、早期に解放することが可能となる。
【００８１】
図１２（ａ）は、ＨＴＴＰリクエストが一つのリクエストパケットにより構成される場合に、パケットバッファ８の記憶領域が解放されるタイミングを示す図である。従来の負荷分散装置は、リクエストパケットに対するＡｃｋをサーバから受信した時点（レスポンスパケットを受信した時点）で、リクエストパケットをパケットバッファから消去する。一方、負荷分散装置３は、リクエストパケットをサーバ４に転送した時点で、リクエストパケットをパケットバッファ８から消去する。このタイミングの差分を、図１２（ａ）に太線として示す。このように、本発明による負荷分散装置３によれば、パケットバッファ８の記憶領域を早期に解放することが可能となる。
【００８２】
また、ＨＴＴＰリクエストが複数のリクエストパケットにより構成される場合、負荷分散装置３は、最後のリクエストパケット（デリミタを含むリクエストパケット）に対するＡｃｋをクライアント２に送信しない。このため、負荷分散装置３は、最後のリクエストパケットについて再送管理を実行する必要が無い。従って、最後のリクエストパケットをパケットバッファ８から早期に消去することが可能となる。即ち、負荷分散装置３は、パケットバッファ８の記憶領域を早期に解放することが可能となる。
【００８３】
図１２（ｂ）は、ＨＴＴＰリクエストが複数のリクエストパケットにより構成される場合に、パケットバッファ８の記憶領域が解放されるタイミングを示す図である。従来の負荷分散装置は、最後のリクエストパケットに対するＡｃｋをサーバから受信した時点（レスポンスパケットを受信した時点）で、パケットバッファから最後のリクエストパケットを消去する。しかし、負荷分散装置３は、最後のリクエストパケットをサーバ４に転送した時点で、パケットバッファ８から最後のリクエストパケットを消去する。このタイミングの差分を、図１２（ｂ）に太線として示す。
【００８４】
このように、第一実施形態の負荷分散装置３は、パケットバッファ８の記憶領域を早期に開放する。このため、負荷分散装置３におけるセッションの多重率の向上、それに伴う負荷分散装置３におけるレイテンシの向上、発熱量、消費電力、実装面積の縮小などが実現される。
【００８５】
〈変形例〉
本発明の第一実施形態による負荷分散装置３は、パケットバッファ８，９がそれぞれ別に構成されているが、一つの記憶装置を用いて構成されても良い。
【００８６】
〔第二実施形態〕
〈システム構成〉
第二実施形態における負荷分散装置３ａを用いた負荷分散システム１ａについて説明する。負荷分散システム１ａのシステム構成は、基本的に、第一実施形態における負荷分散装置３を用いた負荷分散システム１と同じである。即ち、負荷分散システム１ａは、複数のクライアント２，負荷分散装置３ａ，複数のサーバ４，及び複数のクライアント２と負荷分散装置３ａとを通信可能に接続するネットワーク５とを用いて構成される。クライアント２とサーバ４とは、上記した第一実施形態においてすでに説明したため、以下では負荷分散装置３ａの構成について説明する。
【００８７】
〈〈負荷分散装置〉〉
図１３は、本発明による第二実施形態の負荷分散装置３ａのブロック図である。
図１３を用いて、負荷分散装置３ａの構成について説明する。ただし、負荷分散装置３ａについて、負荷分散装置３と異なる構成についてのみ説明する。負荷分散装置３ａは、パケット送信許可部２０をさらに備える。
【００８８】
パケット送信許可部２０は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。パケット送信許可部２０は、サーバ４に転送されたリクエストパケットのシーケンス番号とデータ長とを記憶する。また、パケット送信許可部２０は、サーバ４から受信したパケットのＡｃｋ番号と、シーケンス番号及びデータ長の和とを比較する。パケット送信許可部２０は、二つの値が一致した場合、パケットバッファ８に対し、後続のリクエストパケットをサーバ４に転送することを許可する。
【００８９】
〈動作例〉
図１４は、第二実施形態における負荷分散装置３ａの動作例のうち、負荷分散装置３と異なる部分のみを示したフローチャートである。図１４を用いて、負荷分散装置３ａの動作例について説明する。ただし、負荷分散装置３の動作と異なる動作についてのみ説明する。
【００９０】
振り分け先決定部１７は、振り分け先となるサーバ４を決定すると（Ｓ１０）、決定されたサーバ４に対し、最初のリクエストパケットを一つ転送する（Ｓ２２）。このとき、パケット送信許可部２０は、転送されたリクエストパケットにおけるシーケンス番号及びデータ長を記憶する。
【００９１】
パケットバッファ９にＡｃｋを含むパケットがバッファリングされると、パケット送信許可部２０は、このパケットのＡｃｋ番号と、自身が記憶するシーケンス番号及びデータ長の和とを比較する。この値が一致した場合、パケット送信許可部２０は、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信したと判断する（Ｓ２３）。
【００９２】
パケット送信許可部２０が、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信していないと判断した場合、又はパケットバッファ９にＡｃｋを含むパケットがバッファリングされていない場合（Ｓ２３−Ｎｏ）、再送管理タイマ１１は、転送されたリクエストパケットについてタイムアウトか否かを判断する（Ｓ２４）。タイムアウトである場合（Ｓ２４−Ｙｅｓ）、パケットバッファ８は、タイムアウトと判断されたリクエストパケットを、サーバ４へ再送する（Ｓ２２）。一方、タイムアウトでない場合（Ｓ２４−Ｎｏ）、負荷分散装置３ａは、転送されたリクエストパケットに対するＡｃｋが受信されるまで待機する。
【００９３】
パケット送信許可部２０が、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信したと判断した場合（Ｓ２３−Ｙｅｓ）、パケット送信許可部２０は、全てのリクエストパケットが転送されたか否かを判断する（Ｓ２５）。転送されていないリクエストパケットがある場合（Ｓ２５−Ｎｏ）、パケット送信許可部２０は、後続のリクエストパケットが転送されることを許可する。一方、全てのリクエストパケットが転送された場合（Ｓ２５−Ｙｅｓ）、Ｓ１２以降の処理が実行される（図６参照）。
【００９４】
〈動作シーケンス〉
図１５は、第二実施形態における負荷分散装置３ａを用いた負荷分散システム１ａの動作シーケンスを示す図である。図１５を用いて、負荷分散システム１ａの動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスと異なる動作シーケンスについてのみ説明する。
【００９５】
負荷分散装置３ａは、リクエストパケットの転送先となるサーバ４を決定した後、決定したサーバ４に対し、リクエストパケットａを転送する。サーバ４は、負荷分散装置３ａからリクエストパケットａを受信する。そして、サーバ４は、受信したリクエストパケットａに対するＡｃｋを含むパケットを、負荷分散装置３ａに送信する。
【００９６】
負荷分散装置３ａは、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信すると、このパケットをクライアント２へ転送する。そして、負荷分散装置３ａは、後続のリクエストパケット、即ちリクエストパケットｂをサーバ４へ転送する。
【００９７】
〈作用〉
図１６は、従来技術における負荷分散装置Ｐ３と本発明の第二実施形態における負荷分散装置３ａとの動作の差異を示す図である。図１６を用いて、本発明の第二実施形態における負荷分散装置３ａの作用について説明する。従来技術における負荷分散装置Ｐ３は、複数のリクエストパケットで構成されるＨＴＴＰリクエストをサーバＰ４へ転送する場合、リクエストパケットを連続して転送する。このため、負荷分散装置Ｐ３とサーバＰ４との間で輻輳が発生し、リクエストパケットが消失することがあった。
【００９８】
一方、本発明の第二実施形態における負荷分散装置３ａは、複数のリクエストパケットで構成されるＨＴＴＰリクエストをサーバ４に転送する場合、先に転送されたリクエストパケットに対するＡｃｋを含むパケットを受信した後、後続のリクエストパケットを転送する。このため、負荷分散装置３ａとサーバ４との間において、輻輳の発生が防止される。従って、輻輳発生によるリクエストパケットの消失が防止される。
【００９９】
〈変形例〉
パケット送信許可部２０は、送信を許可するリクエストパケットの数を指数関数的に増加させても良い。即ち、パケット送信許可部２０は、送信を許可するリクエストパケットの数を、スロースタートメカニズムに従って決定しても良い。
【０１００】
〔第三実施形態〕
〈システム構成〉
第三実施形態における負荷分散装置３ｂを用いた負荷分散システム１ｂについて説明する。負荷分散システム１ｂのシステム構成は、基本的に、第一実施形態における負荷分散装置３を用いた負荷分散システム１と同じである。即ち、負荷分散システム１ｂは、複数のクライアント２，負荷分散装置３ｂ，複数のサーバ４，及び複数のクライアント２と負荷分散装置３ｂとを通信可能に接続するネットワーク５とを用いて構成される。クライアント２とサーバ４とは、上記した第一実施形態の欄ですでに説明したため、以下では負荷分散装置３ｂの構成について説明する。
【０１０１】
〈〈負荷分散装置〉〉
図１７は、本発明による第三実施形態の負荷分散装置３ｂのブロック図である。
図１７を用いて、負荷分散装置３ｂの構成について説明する。ただし、負荷分散装置３ｂについて、負荷分散装置３と異なる構成についてのみ説明する。負荷分散装置３ｂは、ペイロード有無確認部２１をさらに備える。
【０１０２】
ペイロード有無確認部２１は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。ペイロード有無確認部２１は、パケットバッファ９に記憶されているパケットがペイロードを含むか否かを確認する。このパケットにペイロードが含まれていない場合、ペイロード有無確認部２１は、このパケットを消去するように、パケットバッファ９に指示を出す。一方、このパケットにペイロードが含まれている場合、ペイロード有無確認部２１は、このパケットをクライアント２へ転送するようにパケットバッファ９に指示を出す。
【０１０３】
〈動作例〉
図１８は、第三実施形態における負荷分散装置３ｂの動作例のうち、負荷分散装置３と異なる部分のみを示した図である。図１８を用いて、負荷分散装置３ｂの動作例について説明する。ただし、負荷分散装置３の動作と異なる動作についてのみ説明する。
【０１０４】
サーバ４から新たなパケットが受信されると、Ａｃｋ番号抽出部１８は、パケットバッファ８において、このパケットのＡｃｋ番号よりもシーケンス番号及びデータ長の和が小さな値となるパケットの有無を確認する（Ｓ１８）。このようなパケットがパケットバッファ８にバッファリングされている場合（Ｓ１８−Ｙｅｓ）、パケットバッファ８は、そのパケットを消去する（Ｓ１９）。
【０１０５】
次に、ペイロード有無確認部２１は、このパケットがペイロードを含むか否かを判断する（Ｓ２６）。このパケットがペイロードを含まない場合（Ｓ２６−Ｎｏ）、ペイロード有無確認部２１は、パケットバッファ９に、このパケットをクライアント２に転送せずに消去するように指示を出す。一方、このパケットがペイロードを含む場合（Ｓ２６−Ｙｅｓ）、ペイロード有無確認部２１は、このパケットをクライアント２へ転送するようにパケットバッファ９に指示を出す。
【０１０６】
〈動作シーケンス〉
図１９は、第三実施形態における負荷分散装置３ｂを用いた負荷分散システム１ｂの動作シーケンスを示す図である。図１９を用いて、負荷分散システム１ｂの動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスと異なる動作シーケンスについてのみ説明する。
【０１０７】
負荷分散装置３ｂは、サーバ４に対し、リクエストパケットａ，ｂを転送する。サーバ４は、リクエストパケットａに対するＡｃｋを含むパケットや、リクエストパケットｂに対するＡｃｋを含むパケット（この場合はレスポンスパケット）を、負荷分散装置３ｂに対し送信する。負荷分散装置３ｂは、リクエストパケットａに対するＡｃｋを含むパケットを受信した場合、このＡｃｋパケットをクライアント２に転送せずに消去する。即ち、負荷分散装置３ｂは、ＨＴＴＰレスポンスを含まないパケットを受信した場合、このパケットをクライアント２に転送せずに消去する。一方、負荷分散装置３ｂは、レスポンスパケットを受信した場合、このレスポンスパケットをクライアント２に転送する。
【０１０８】
〈作用〉
図２０は、従来技術における負荷分散装置Ｐ３と本発明の第三実施形態における負荷分散装置３ｂとの動作の差異を示す図である。図２０を用いて、本発明の第三実施形態における負荷分散装置３ｂの作用について説明する。従来技術における負荷分散装置Ｐ３は、サーバＰ４から受信する全てのパケットをクライアントＰ２へ転送する。よって、従来技術における負荷分散装置Ｐ３は、ＨＴＴＰレスポンスを含まないパケット（この場合、Ａｃｋのためのパケット）、即ちクライアントＰ２に転送される必要のないパケットをクライアントＰ２に転送する。このため、クライアントＰ２と負荷分散装置Ｐ３とを接続するネットワークの帯域が不必要に消費されていた。
【０１０９】
一方、本発明の第三実施形態における負荷分散装置３ｂは、ＨＴＴＰレスポンスを含まないパケット、即ちペイロードを含まないパケットを、クライアント２に転送せずに消去する。このため、ネットワーク５において、帯域が無駄に消費されない。
【０１１０】
〈変形例〉
ペイロード有無確認部２１は、本発明の第二実施形態における負荷分散装置３ａに適用されても良い。本発明の第二実施形態における負荷分散装置３ａでは、リクエストパケットａの転送とリクエストパケットｂの転送との間に、必ずサーバ４からＡｃｋを含むパケット（ペイロードを含まないパケット）を受信する。このとき、ペイロード有無確認部２１が適用されることにより、このパケットをクライアント２に送信することがなくなる。このため、ネットワーク５において、帯域を節約することが可能となる。
【０１１１】
〔その他〕
本発明は、以下のように特定することができる。
（付記１） クライアントから受信したデータの内容に応じて、クライアントへ当該データの確認応答を送信するか否かを判断する判断手段と、
前記判断手段の判断結果に応じて、クライアントへ確認応答を送信する確認応答手段と、
前記クライアントから受信したデータを複数のサーバのいずれかへ転送する転送手段と、
前記サーバへ転送されたデータのうち、このデータについてクライアントへ確認応答が送信されたデータのみを、前記サーバへの再送に備えて記憶する再送デ一夕記憶手段と、
を備える負荷分散装置。
（付記２）前記判断手段は、クライアントから受信したデータがデリミタを含まない場合にクライアントへ確認応答を送信すると判断し、前記データがデリミタを含む場合にクライアントへ確認応答を送信しないと判断する付記１に記載の負荷分散装置。
（付記３）連続する複数のデータをサーバへ転送する場合に、最後にサーバに転送されたデータに対する確認応答をサーバから受信したときに、次のデータをサーバヘ転送することを許可する確認応答判断手段をさらに備える付記１又は２に記載の負荷分散装置。
（付記４）サーバから受信されたデータを、クライアントへ転送すべきか否かを判断する転送判断手段をさらに備える付記１〜３のいずれかに記載の負荷分散装置。
（付記５）前記転送判断手段は、前記サーバから受信されたデータが、確認応答のためのデータのみからなる場合に転送すべきでないと判断する付記４に記載の負荷分散装置。
（付記６）前記判断手段は、前記クライアントから受信したデータが一つのパケットからなるＨＴＴＰリクエストである場合に確認応答を送信しないと判断する付記１に記載の負荷分散装置。
（付記７）前記判断手段は、前記クライアントから受信したデニタが複数のパケットからなるＨＴＴＰリクエストである場合に、このＨＴＴＰリクエストを構成する最後のパケットを受信した際に確認応答を送信しないと判断する付記１又は２に記載の負荷分散装置。
【０１１２】
【発明の効果】
本発明によれば、クライアントからサーバへ転送するデータを、早期に送信バッファから消去することにより、送信バッファの使用時間を減少させることが可能となる。
【図面の簡単な説明】
【図１】 従来技術における再送管理省略の動作シーケンスを示す図である。
【図２】 スロースタートメカニズムを示す図である。
【図３】 従来技術の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図４】 負荷分散システムの概略を示す図である。
【図５】 第一実施形態の負荷分散装置のブロック図である。
【図６】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図７】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図８】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図９】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１０】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１１】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１２】 負荷分散装置の記憶領域が解放されるタイミングを示す図である。
【図１３】 第二実施形態の負荷分散装置のブロック図である。
【図１４】 第二実施形態の負荷分散装置の動作例を示すフローチャートである。
【図１５】 第二実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１６】 従来技術における負荷分散装置と本発明の第二実施形態における負荷分散装置との動作の差異を示す図である。
【図１７】 第三実施形態の負荷分散装置のブロック図である。
【図１８】 第三実施形態の負荷分散装置の動作例を示すフローチャートである。
【図１９】 第三実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図２０】 従来技術における負荷分散装置と本発明の第三実施形態における負荷分散装置との動作の差異を示す図である。
【符号の説明】
１ 負荷分散システム
２ クライアント
３，３ａ，３ｂ 負荷分散装置
４ サーバ
５ ネットワーク
６，７ ネットワークインタフェース
８，９ パケットバッファ
１０，１８ Ａｃｋ番号抽出部
１１，１９ 再送管理タイマ
１２，１３ シーケンス番号・データ長抽出部
１４，１５ Ａｃｋ応答生成部
１６ ＨＴＴＰデリミタ検出部
１７ 振り分け先決定部
２０ パケット送信許可部
２１ ペイロード有無確認部
【発明の属する技術分野】
本発明は、複数のサーバを仮想的に一台のサーバのように見せて動作させる負荷分散装置に関する。
【０００２】
【従来の技術】
任意の端末間におけるデータの送受信では、データ到着の保証を図るため、再送管理が行われている。再送管理を行う送信元端末は、送信バッファを有し、送信先端末へ送信したデータを、送信バッファに記憶しておく。そして、データの異常や消失が検出された場合に、送信元端末は送信先端末へ、送信バッファに記憶しておいたデータを再送する。送信先端末は、送信元端末から送信されたデータを正しく受信した場合に、確認応答データを送信元端末に送信する。送信元端末は、送信先端末から確認応答データを受信した場合に、送信バッファに記憶しておいたデータを消去し、送信バッファを解放する。このような再送管理を行うプロトコルの例として、ＴＣＰ（Transport Control Protocol）がある。
【０００３】
このような再送管理は、負荷分散装置でも行われる。負荷分散装置とは、複数のサーバに対して、クライアントからのリクエストを振り分ける装置である。負荷分散装置を用いることにより、クライアントからのリクエストが一定のサーバに集中することが回避される。
【０００４】
このような負荷分散装置にとって、送信バッファを構成するメモリ領域は、有限のリソースである。一つのセッションにおける送信バッファの使用時間（保留時間）を減少させることにより、リソースの有効利用を図ることが可能となる。リソースの有効利用の結果として、例えばセッションの多重度の向上や、消費電力の減少などを図ることが可能となる。
【０００５】
従来、ＴＣＰに対応する負荷分散装置において、再送管理を省略することにより送信バッファから早期にデータを消去し送信バッファの使用時間を減少させる技術がある。この技術では、負荷分散装置は、再送管理を省略する場合には、本来行う必要がある再送管理を、サーバ又はクライアントに任せる。この場合、負荷分散装置は、サーバからレスポンスを受信した際に、サーバに対しＡｃｋ（確認応答）の送信を行わない。負荷分散装置は、サーバから受信したレスポンスをクライアントへ転送し、送信バッファに記憶しているレスポンスを消去する。
【０００６】
図１は、従来技術における負荷分散装置Ｐ３が、再送管理を省略した場合の、クライアントＰ２，負荷分散装置Ｐ３，及びサーバＰ４の動作シーケンスを示す図である。図１を用いて、負荷分散装置Ｐ３が再送管理を省略する場合の、クライアントＰ２，負荷分散装置Ｐ３，及びサーバＰ４の動作について説明する。
【０００７】
データが、サーバＰ４からクライアントＰ２に、正常に転送された場合（図１（ａ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。負荷分散装置Ｐ３は、クライアントＰ２にレスポンスを転送する。クライアントＰ２は、レスポンスを受信し、負荷分散装置Ｐ３にＡｃｋを送信する。負荷分散装置Ｐ３は、サーバＰ４にＡｃｋを転送する。そして、サーバＰ４はＡｃｋを含むパケット（Ａｃｋパケット）を、負荷分散装置Ｐ３から受信する。このような動作によって、サーバＰ４は、データがクライアントＰ２に正常に受信されたことを確認する。
【０００８】
次に、データがサーバＰ４−負荷分散装置Ｐ３間で消失した場合（図１（ｂ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。このとき、データが消失したと仮定する。この場合、負荷分散装置Ｐ３は何も受信せず、何の処理も行わない。そして、サーバＰ４は、タイムアウト秒が経過するまで待機しても、負荷分散装置Ｐ３からＡｃｋを受信できないため、レスポンスを再送する。
【０００９】
次に、パケットが、負荷分散装置Ｐ３−クライアントＰ２間で消失した場合（図１（ｃ）参照）について説明する。まず、サーバＰ４は、負荷分散装置Ｐ３にレスポンスを送信する。負荷分散装置Ｐ３は、受信したレスポンスをクライアントＰ２に転送する。このとき、データが消失したと仮定する。この場合、クライアントＰ２は何も受信せず、何の処理も行わない。そして、サーバＰ４はタイムアウト秒が経過するまで待機しても、負荷分散装置Ｐ３からＡｃｋを受信できないため、負荷分散装置Ｐ３へレスポンスを再送する。
【００１０】
【発明が解決しようとする課題】
上記技術では、負荷分散装置は、サーバから受信するレスポンスについての再送管理を省略している。ここで、負荷分散装置は、クライアントから受信するリクエストについても、再送管理を省略することにより、送信バッファの使用時間をさらに減少させることができる。
【００１１】
しかし、クライアントがデータ送信においてスロースタートメカニズムを用いている場合、負荷分散装置は、クライアントから受信するリクエストについての再送管理を省略することができない。
【００１２】
図２は、スロースタートメカニズムを示す図である。図２を用いて、スロースタートメカニズムについて説明する。スロースタートメカニズムを用いた送信端末（クライアント）が受信端末（負荷分散装置）にデータを送信する場合、送信端末は、同時に送信するデータ数（同時送信データ数）を、１から指数関数的に増加させる（図２（ａ）参照）。このとき、送信端末は、受信端末から前のデータのＡｃｋを受信するまで、次のデータの送信を待機する。
【００１３】
クライアントＰ２が、スロースタートメカニズムを用いて、負荷分散装置Ｐ３に対し、データを送信すると仮定する。このとき、リクエストが単独のデータで構成されている場合、負荷分散装置Ｐ３は受信したデータについて、ＵＲＬを抽出し、振り分け先を決定し、決定したサーバＰ４に対して転送処理を行うことが可能である。従って、最終的に、クライアントＰ２はサーバＰ４から、負荷分散装置Ｐ３を経由してレスポンスを受信できる。
【００１４】
一方、リクエストが複数のデータに分割されて構成されている場合、クライアントＰ２は、リクエストを構成する１以上のデータを負荷分散装置Ｐ３に送信する毎に、そのデータに対するＡｃｋの受信を待機する状態となる（図２（ｂ）参照）。図２（ｂ）では、一つのリクエストが、データＤｃとデータＤｄとに分割されている。そして、クライアントＰ２は、データＤｃに対するＡｃｋを、負荷分散装置Ｐ３から受信するまで、データＤｄを送信しない。
【００１５】
ここで、負荷分散装置Ｐ３がクライアントＰ２から受信するリクエストについての再送管理を省略している場合、クライアントＰ２は、送信したデータＤｃに対するＡｃｋを負荷分散装置Ｐ３から受信できない。このため、クライアントＰ２は、負荷分散装置Ｐ３へ、データＤｃの再送を繰り返す。再送が繰り返されても、負荷分散装置Ｐ３は、クライアントＰ２にＡｃｋを送信しない。この結果、負荷分散装置Ｐ３は、データＤｄを受信できず、リクエストを完全に受信することができない。このため、負荷分散装置Ｐ３は、リクエストについて、ＵＲＬの抽出や、振り分け先の決定などを実行できない。従って、負荷分散装置Ｐ３は、クライアントＰ２から受信したリクエストを、サーバＰ４に転送できず、全体としてデータの送受信が滞ってしまう。
【００１６】
負荷分散装置Ｐ３は、上記したようなリクエストを受信できなくなることを避けるため、クライアントＰ２から受信するリクエストについては、そのリクエストの内容に関わらず、クライアントＰ２にＡｃｋを送信する。この場合、負荷分散装置Ｐ３は、クライアントＰ２から受信したリクエストについて再送管理を行う必要がある。即ち、負荷分散装置Ｐ３は、サーバＰ４から、リクエストに対するＡｃｋを受信するまで、クライアントＰ２から受信したリクエストを送信バッファに記憶しておく必要がある。
【００１７】
図３は、従来技術の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。図３を用いて、負荷分散装置Ｐ３がクライアントＰ２から受信したリクエストに対してＡｃｋを送信するにも関わらずこのリクエストを送信バッファに記憶しない場合に発生する問題について説明する。負荷分散装置Ｐ３からサーバＰ４に転送されたリクエストが、正常にサーバＰ４で受信された場合（図３（ａ）参照）には、問題は生じない。
【００１８】
一方、負荷分散装置Ｐ３からサーバＰ４に転送されたリクエストがサーバＰ４に受信される前に消失した場合（図３（ｂ）参照）には、次のような問題が発生する。即ち、負荷分散装置Ｐ３は、送信バッファにリクエストを記憶していないため、サーバＰ４にリクエストを再送できない。一方、クライアントＰ２は、負荷分散装置Ｐ３からＡｃｋを受信した時点で、リクエストを送信バッファから消去する。このため、クライアントＰ２は、負荷分散装置Ｐ３にリクエストを再送できない。
【００１９】
従って、負荷分散装置Ｐ３は、リクエストの消失に備え、サーバＰ４からＡｃｋを受信するまで、リクエストを送信バッファから消去せずに記憶しておかなければならない。このように、従来技術における負荷分散装置Ｐ３は、クライアントＰ２から受信するリクエストに対する再送管理を省略できない。このため、従来技術における負荷分散装置Ｐ３は、送信バッファの使用時間を減少できない。
【００２０】
本発明は、このような問題を解決し、クライアントから受信するリクエストに対する再送管理を省略することにより、送信バッファの使用時間を減少することが可能な負荷分散装置を提供することを目的とする。
【００２１】
【課題を解決するための手段】
上記問題を解決するため、本発明は以下のような構成をとる。本発明の第一の態様は、負荷分散装置であって、クライアントから受信したデータの内容に応じて、クライアントへ当該データの確認応答を送信するか否かを判断する判断手段と、前記判断手段の判断結果に応じて、クライアントへ確認応答を送信する確認応答手段と、前記クライアントから受信したデータを複数のサーバのいずれかへ転送する転送手段と、前記サーバへ転送されたデータのうち、このデータについてクライアントへ確認応答が送信されたデータのみを、前記サーバへの再送に備えて記憶する再送データ記憶手段と、を備える。
【００２２】
本発明の第一の態様によれば、判断手段は、クライアントから受信したデータの内容を解析し、このデータの内容に応じてクライアントへ確認応答を送信するか否かを判断する。この確認応答は、クライアントから受信したデータに対する確認応答である。判断手段が上記判断を実行すると、確認応答手段は、この判断結果に基づいて、クライアントへ確認応答を送信する。転送手段はクライアントから受信したデータを複数のサーバのいずれかへ転送する。再送データ記憶手段は、サーバへ転送されたデータを、このサーバへのデータ再送に備えて記憶する。
【００２３】
このため、再送データ記憶手段は、確認応答がクライアントに送信されないデータを記憶しない。従って、再送データ記憶手段は、サーバに転送されるデータ全てを記憶するわけではなく、使用される記憶領域が削減される。
【００２４】
また、本発明の第一の態様における前記判断手段は、クライアントから受信したデータがデリミタを含まない場合にクライアントへ確認応答を送信すると判断し、前記データがデリミタを含む場合にクライアントへ確認応答を送信しないと判断するように構成されても良い。
【００２５】
このように構成された本発明の第一の態様によれば、判断手段は、クライアントから受信したデータがデリミタを含むか否かに応じて、クライアントへこのデータの確認応答を送信するか否かを判断する。そして、確認応答手段は、デリミタを含まないデータが受信された場合、このデータに対する確認応答をクライアントへ送信する。
【００２６】
このため、クライアントがスロースタートメカニズムを採用している場合であっても、負荷分散装置はクライアントからデリミタを含まないデータの次のデータを受信することが可能となる。
【００２７】
また、本発明の第一の態様は、連続する複数のデータをサーバへ転送する場合に、最後にサーバに転送されたデータに対する確認応答をサーバから受信したときに、次のデータをサーバへ転送することを許可する確認応答判断手段をさらに備えるように構成されても良い。
【００２８】
また、本発明の第一の態様は、サーバから受信されたデータを、クライアントへ転送すべきか否かを判断する転送判断手段をさらに備えるように構成されても良い。
【００２９】
また、本発明の第一の態様における前記転送判断手段は、前記サーバから受信されたデータが、確認応答のためのデータのみからなる場合に転送すべきでないと判断するように構成されても良い。
【００３０】
【発明の実施の形態】
次に、図を用いて本発明の実施形態における負荷分散装置を用いた負荷分散システムについて説明する。なお、本実施形態の説明は例示であり、本発明は以下の説明する構成に限定されない。
【００３１】
〔第一実施形態〕
〈システム構成〉
図４は、負荷分散システム１の概略を示す図である。第一実施形態における負荷分散装置３を用いた負荷分散システム１は、複数のクライアント２，負荷分散装置３，複数のサーバ４，及び複数のクライアント２と負荷分散装置３とを通信可能に接続するネットワーク５を用いて構成される。本実施形態における負荷分散装置３は、例として、ＴＣＰ／ＩＰ（Transport Control Protocol / Internet Protocol）を用いてＨＴＴＰを取り扱う。これに従い、クライアント２とサーバ４とは、少なくとも、ＴＣＰ／ＩＰを用いてＨＴＴＰを取り扱う。負荷分散装置３は、確認応答を行うプロトコルを扱う装置であれば良く、ＴＣＰ／ＩＰを取り扱う装置に限定されない。以下、負荷分散システム１の各構成について説明する。
【００３２】
〈〈クライアント〉〉
クライアント２は、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。クライアント２は、ネットワークカード等の通信装置を用いて、ネットワーク５を介して負荷分散装置３と通信可能に構成される。クライアント２は、ブラウザソフトがインストールされており、負荷分散装置３に対し、ＨＴＴＰリクエストを含むパケットを送信する。そして、クライアント２は、負荷分散装置３から、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスを含むパケットを受信する。クライアント２は、受信したＨＴＴＰレスポンスの内容を、ブラウザソフトを用いて表示する。また、クライアント２は、スロースタートメカニズムを用いてパケットを送信する。
【００３３】
〈〈負荷分散装置〉〉
負荷分散装置３は、パーソナルコンピュータやワークステーション等の情報処理装置や、負荷分散処理を行うことを前提とした専用ハードウェア等によって構成される。図５は、負荷分散装置３のブロック図である。図５を用いて負荷分散装置３について説明する。負荷分散装置３は、ハードウェア的には、バスを介して接続されたＣＰＵ，主記憶（ＲＡＭ），補助記憶装置（ハードディスク），通信制御装置（ネットワークカード等）等を備えている。あるいは、専用のパケット処理プロセッサ，パケット処理のための記憶装置（ＲＡＭ），通信制御装置（ネットワークカード等）等から構成される場合もある。負荷分散装置３は、補助記憶装置に記憶された各種のプログラム（ＯＳ，アプリケーション等）が主記憶にロードされＣＰＵにより実行されることによって、あるいはパケット処理プロセッサがあらかじめ組み込まれた処理に従って動作することによって、ネットワークインタフェース６，７，パケットバッファ８，９，Ａｃｋ番号抽出部１０，１８，再送管理タイマ１１，１９，シーケンス番号・データ長抽出部１２，１３，Ａｃｋ応答生成部１４，１５，ＨＴＴＰデリミタ検出部１６，及び振り分け先決定部１７等を含む装置として機能する。
【００３４】
ネットワークインタフェース６，７は、ネットワークカード等を用いて構成される。ネットワークインタフェース６は、クライアント２から送信されたパケットを、ネットワーク５を介して受信し、パケットバッファ８に書き込む。また、ネットワークインタフェース６は、パケットバッファ９から受信するパケットを、ネットワーク５を介してクライアント２に送信する。ネットワークインタフェース７は、サーバ４から送信されたパケットを受信し、パケットバッファ９に書き込む。また、ネットワークインタフェース７は、パケットバッファ８から受信するパケットを、サーバ４に送信する。
【００３５】
パケットバッファ８，９は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。パケットバッファ８は、再送管理タイマ１１から再送信号を受信すると、この再送信号に含まれる識別子に対応するパケットを、ネットワークインタフェース７へ送信する。パケットバッファ８は、クライアント２から送信されたパケット、あるいは負荷分散装置３によって生成されたパケットをバッファリングする。そして、パケットバッファ８は、バッファリングしているパケットをネットワークインタフェース７へ送信する。また、パケットバッファ８は、Ａｃｋ応答生成部１５によってパケットをバッファリングされると、このパケットをネットワークインタフェース７へ送信する。また、パケットバッファ８は、振り分け先決定部１７から消去信号を受信すると、この消去信号に含まれる識別子に対応するパケットが転送されたことを確認し、このパケットを消去する。
【００３６】
パケットバッファ９は、再送管理タイマ１９から再送信号を受信すると、この再送信号に含まれる識別子に対応するパケットを、ネットワークインタフェース６へ送信する。パケットバッファ９は、サーバ４から送信されたパケット、あるいは負荷分散装置３によって生成されたパケットをバッファリングする。そして、パケットバッファ９は、バッファリングしているパケットをネットワークインタフェース６へ送信する。また、パケットバッファ９は、Ａｃｋ応答生成部１４によってパケットをバッファリングされると、このパケットをネットワークインタフェース６へ送信する。
【００３７】
Ａｃｋ番号抽出部１０，１８は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。Ａｃｋ番号抽出部１０は、パケットバッファ８にバッファリングされたパケットのＡｃｋ番号を抽出する。また、Ａｃｋ番号抽出部１０は、シーケンス番号・データ長抽出部１３から、シーケンス番号及びデータ長を受信する。即ち、Ａｃｋ番号抽出部１０は、パケットバッファ９にバッファリングされたパケットのシーケンス番号及びデータ長を受信する。そして、Ａｃｋ番号抽出部１０は、Ａｃｋ番号の値と、シーケンス番号及びデータ長の和とを比較する。Ａｃｋ番号抽出部１０は、Ａｃｋ番号の方が大きい値又は同じ値である場合、パケットバッファ９に、このシーケンス番号及びデータ長の値を含むパケットの識別子を含む消去信号を送信する。消去信号は、消去すべきパケットの識別子を含む。
【００３８】
Ａｃｋ番号抽出部１８は、パケットバッファ９にバッファリングされたパケットのＡｃｋ番号を抽出する。また、Ａｃｋ番号抽出部１８は、シーケンス番号・データ長抽出部１２から、シーケンス番号及びデータ長を受信する。即ち、Ａｃｋ番号抽出部１８は、パケットバッファ８にバッファリングされたパケットのシーケンス番号及びデータ長を受信する。そして、Ａｃｋ番号抽出部１８は、Ａｃｋ番号の値と、シーケンス番号とデータ長とを加算した値とを比較する。Ａｃｋ番号抽出部１８は、Ａｃｋ番号の方が大きい値又は同じ値である場合、パケットバッファ８に消去信号を送信する。消去信号は、消去すべきパケットの識別子を含む。
【００３９】
再送管理タイマ１１，１９は、クロックやＣＰＵ等、あるいは専用パケット処理プロセッサ等を用いて構成される。再送管理タイマ１１は、パケットバッファ８にバッファリングされたパケットが、ネットワークインタフェース７によって送信されてからの経過時間を計時する。再送管理タイマ１１は、送信されてから一定時間以上経過した（タイムアウトの）パケットがある場合、このパケットの識別子を含む再送信号を、パケットバッファ８へ送信する。
【００４０】
再送管理タイマ１９は、パケットバッファ９にバッファリングされたパケットが、ネットワークインタフェース６によって送信されてからの経過時間を計時する。再送管理タイマ１９は、送信されてから一定時間以上経過したパケットがある場合、このパケットの識別子を含む再送信号を、パケットバッファ９へ送信する。
【００４１】
シーケンス番号・データ長抽出部１２，１３は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。シーケンス番号・データ長抽出部１２は、パケットバッファ８にバッファリングされているパケットのシーケンス番号及びデータ長を抽出する。そして、シーケンス番号・データ長抽出部１２は、シーケンス番号及びデータ長を、Ａｃｋ応答生成部１４及びＡｃｋ番号抽出部１８に送信する。
【００４２】
シーケンス番号・データ長抽出部１３は、パケットバッファ９にバッファリングされているパケットのシーケンス番号及びデータ長を抽出する。そして、シーケンス番号・データ長抽出部１３は、シーケンス番号及びデータ長を、Ａｃｋ応答生成部１５及びＡｃｋ番号抽出部１０に送信する。
【００４３】
Ａｃｋ応答生成部１４，１５は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。Ａｃｋ応答生成部１４は、シーケンス番号・データ長抽出部１２から受信した二つの値の和をＡｃｋ番号として持つパケットを生成する。そして、Ａｃｋ応答生成部１４は、生成したパケットをパケットバッファ９にバッファリングする。
【００４４】
Ａｃｋ応答生成部１５は、シーケンス番号・データ長抽出部１３から受信した二つの値の和をＡｃｋ番号として持つパケットを生成する。そして、Ａｃｋ応答生成部１５は、生成したパケットをパケットバッファ８にバッファリングする。
【００４５】
ＨＴＴＰデリミタ検出部１６は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。ＨＴＴＰデリミタ検出部１６は、パケットバッファ８にバッファリングされるＨＴＴＰリクエストを含むパケット（リクエストパケット）のペイロードに、ＨＴＴＰのデリミタ（Delimiter：例えば空行）が存在するか否かを判断する。ＨＴＴＰデリミタ検出部１６は、デリミタが存在する場合、振り分け先決定部１７へ、転送信号を送信する。この転送信号は、ＨＴＴＰデリミタ検出部１６がデリミタを検出したリクエストパケットの識別子を含む。
【００４６】
また、ＨＴＴＰデリミタ検出部１６は、リクエストパケットにデリミタが存在しない場合、シーケンス番号・データ長抽出部１２へ指示を出し、クライアント２に対し、Ａｃｋを含むパケット（Ａｃｋパケット）を送信する処理を実行させる。
【００４７】
振り分け先決定部１７は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。振り分け先決定部１７は、ＨＴＴＰデリミタ検出部１６から転送信号を受信すると、転送信号に含まれる識別子に対応するリクエストパケットに含まれるＵＲＬを抽出し、このＵＲＬが示すコンテンツを保有する最適なサーバ４を選択する。その上でそのリクエストパケットを、選択したサーバ４へ転送する。即ち、振り分け先決定部１７は、転送対象となるリクエストパケットの送信先アドレスや送信元アドレス等の情報を書き換えることにより、このリクエストパケットをサーバ４へ転送する。また、振り分け先決定部１７は、転送対象となるリクエストパケットのうち、デリミタを有するリクエストパケットの識別子を含む消去信号をパケットバッファ８へ送信する。
【００４８】
なお、Ａｃｋ番号抽出部１０，１８，シーケンス番号・データ長抽出部１２，１３，ＨＴＴＰデリミタ検出部１６，振り分け先決定部１７，及びＡｃｋ応答生成部１４，１５は、各々独立に動作するのではなく、パケットの到着に伴い順に動作する。また、パケット受信、送信に伴う上記記載以外に必要となる処理については、従来行われている処理であるため、説明を省略する。
【００４９】
〈〈サーバ〉〉
図４に戻って、サーバ４は、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。サーバ４は、ネットワークカード等の通信装置を用いて、負荷分散装置３と通信可能に構成される。サーバ４では、ＨＴＴＰＤ（HTTP Daemon）が実行される。サーバ４は、負荷分散装置３から受信するリクエストパケットに対し、ＨＴＴＰレスポンスを含むパケット（レスポンスパケット）を返信する。
【００５０】
〈動作例〉
図６〜８は、負荷分散装置３の動作例を示すフローチャートである。図５，図６〜８を用いて、負荷分散装置３の動作例について説明する。ここでは、負荷分散装置３は、クライアント２からリクエストパケットを受信し、サーバ４からレスポンスパケットを受信するものとして説明する。
【００５１】
負荷分散装置３のネットワークインタフェース６は、クライアント２からリクエストパケットを受信する（図６参照：Ｓ０１）。パケットバッファ８は、受信したリクエストパケットをバッファリングする（Ｓ０２）。Ａｃｋ番号抽出部１０は、このリクエストパケットからＡｃｋ番号を抽出する（Ｓ０３）。また、シーケンス番号・データ長抽出部１３は、パケットバッファ９にバッファリングされたパケットのシーケンス番号及びデータ長を抽出し、Ａｃｋ番号抽出部１０へ送信する（Ｓ０４）。Ａｃｋ番号抽出部１０は、抽出したＡｃｋ番号と、シーケンス番号及びデータ長の和とを比較する（Ｓ０５）。Ａｃｋ番号よりもシーケンス番号及びデータ長の和が小さな値となるパケットがパケットバッファ９にバッファリングされている場合（Ｓ０５−ＹＥＳ）、パケットバッファ９は、そのパケットを消去する（Ｓ０６）。
【００５２】
次に、ＨＴＴＰデリミタ検出部１６は、パケットバッファ８にバッファリングされたリクエストパケットがデリミタを含むか否かを判断する（Ｓ０７）。ＨＴＴＰデリミタ検出部１６がデリミタを検出しない場合（Ｓ０７−ＮＯ）、シーケンス番号・データ長抽出部１２は、Ａｃｋ応答生成部１４へ、抽出したシーケンス番号及びデータ長を送信する。Ａｃｋ番号応答生成部１４は、受信したシーケンス番号及びデータ長を加算する。そして、Ａｃｋ番号応答生成部１４は、この値をＡｃｋ番号として持つパケットを生成し、パケットバッファ９にこのパケットをバッファリングする（Ｓ０８）。パケットバッファ９は、バッファリングされたパケットを、ネットワークインタフェース６を介して、クライアント２へ送信する（Ｓ０９）。この後、負荷分散装置３は、新たなリクエストパケットをクライアント２から受信すると、改めてＳ０１〜Ｓ０７の処理を実行する。
【００５３】
一方、ＨＴＴＰデリミタ検出部１６は、デリミタを検出した場合（Ｓ０７−Ｙｅｓ）、振り分け先決定部１７へ転送信号を送信する。振り分け先決定部１７は、パケットバッファ８からリクエストパケットのペイロード部を読み込み、そこに示されているＵＲＬをコンテンツとして持つ適当なサーバ４を決定する（Ｓ１０）。振り分け先決定部１７は、決定されたサーバ４に対するＴＣＰコネクションがオープンされると、サーバ４に対し、リクエストパケット全てを転送する（Ｓ１１）。このとき、振り分け先決定部１７は、転送対象となるリクエストパケットのうち、デリミタを有するリクエストパケットの識別子を含む消去信号をパケットバッファ８へ送信する。そして、パケットバッファ８はこのリクエストパケットを消去する。
【００５４】
再送管理タイマ１１は、タイムアウトのリクエストパケットがある場合（図７参照：Ｓ１２−Ｙｅｓ）、このリクエストパケットの識別子を含む再送信号を、パケットバッファ８へ送信する。そして、パケットバッファ８は、この再送信号に含まれる識別子が示すリクエストパケットを、サーバ４へ再送する（Ｓ１３）。
【００５５】
一方、タイムアウトのリクエストパケットが無い場合（Ｓ１２−Ｎｏ）、ネットワークインタフェース７がサーバ４からパケットを受信したか否かを判断する（Ｓ１４）。ネットワークインタフェース７がパケットを受信していない場合（Ｓ１４−Ｎｏ）、再びタイムアウトの判断に戻る。一方、ネットワークインタフェース７がサーバ４からパケットを受信した場合（Ｓ１４−Ｙｅｓ）、パケットバッファ９は、このパケットをバッファリングする（Ｓ１５）。
【００５６】
パケットバッファ９がパケットをバッファリングした後、Ａｃｋ番号抽出部１８は、バッファリングされたパケットのＡｃｋ番号を抽出する（図８参照：Ｓ１６）。また、シーケンス番号・データ長抽出部１２は、パケットバッファ８にバッファリングされたパケットのシーケンス番号及びデータ長を抽出し、Ａｃｋ番号抽出部１８へ送信する（Ｓ１７）。Ａｃｋ番号抽出部１８は、シーケンス番号及びデータ長の和が、抽出されたＡｃｋ番号と同じ又は小さい値であるパケットの存在を判断する（Ｓ１８）。このようなパケットがパケットバッファ８にバッファリングされている場合（Ｓ１８−Ｙｅｓ）、パケットバッファ８は、そのパケットを消去する（Ｓ１９）。
【００５７】
パケットバッファ９は、バッファリングしたパケット（サーバ４から受信されたパケット）を、クライアント２に転送する（Ｓ２０）。そして、パケットバッファ９は、転送したパケットを消去する（Ｓ２１）。
【００５８】
〈動作シーケンス〉
次に、第一実施形態における負荷分散システム１の動作シーケンスについて説明する。図９（ａ），（ｂ）は、ＨＴＴＰリクエストが一つのリクエストパケットで構成される場合の、負荷分散システム１の動作シーケンスを示す図である。第一に、図９（ａ）を用いて、ＨＴＴＰリクエストが一つのリクエストパケットで構成され、リクエストパケットが消失しない場合の動作シーケンスについて説明する。
【００５９】
まず、クライアント２と負荷分散装置３とは、ＴＣＰのコネクションをオープンする（オープンフェーズ：図９（ａ）参照）。クライアント２は、コネクションをオープンした後、データ転送フェーズの処理として、負荷分散装置３にリクエストパケット（ＨＴＴＰリクエストを含むパケット）を送信する。
【００６０】
負荷分散装置３は、クライアント２からリクエストパケットを受信する。負荷分散装置３は、受信したリクエストパケットがデリミタを含むか否かを判断する。この場合、リクエストパケットは一つのパケットで構成されるため、リクエストパケットはデリミタを含む。このため、負荷分散装置３は、リクエストパケットに示されているＵＲＬをコンテンツとして持つ適当なサーバ４を決定する。そして、負荷分散装置３は、決定されたサーバ４に対するＴＣＰコネクションをオープンし、サーバ４に対し、リクエストパケットを転送する。このとき、負荷分散装置３は、このリクエストパケットを、パケットバッファ８から消去する。
【００６１】
サーバ４は、負荷分散装置３からリクエストパケットを受信する。サーバ４は、受信したリクエストパケットに対するレスポンスパケット（ＨＴＴＰレスポンスを含むパケット）を生成する。そして、サーバ４は、負荷分散装置３に対し、レスポンスパケットを送信する。
【００６２】
負荷分散装置３は、レスポンスパケットを受信する。負荷分散装置３は、受信したレスポンスパケットを、クライアント２に転送する。このとき、負荷分散装置３は、このレスポンスパケットをパケットバッファ９から消去する。そして、クライアント２は、クローズフェーズの処理を実行する。
【００６３】
第二に、図９（ｂ）を用いて、ＨＴＴＰリクエストが一つのリクエストパケットで構成され、リクエストパケットが消失する場合の動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスにおけるオープンフェーズとクローズフェーズとは、どのような場合であっても同じであるため、以後、オープンフェーズとクローズフェーズとについての説明を省略する。
【００６４】
まず、クライアント２はリクエストパケットを負荷分散装置３へ送信する。負荷分散装置３は、リクエストパケットのペイロードを解析し、振り分け先サーバ４を決定し、サーバ４に対してＴＣＰコネクションをオープンする。負荷分散装置３はリクエストパケットを、決定されたサーバ４に転送する。このとき、転送されたリクエストパケットが消失したとする。この場合、サーバ４は、負荷分散装置３から、転送されたリクエストパケットを受信しない。従って、サーバ４は、リクエストパケットに対するＡｃｋパケットを、負荷分散装置３へ送信しない。このため、この場合、クライアント２は、リクエストパケットに対するＡｃｋパケットを、負荷分散装置３から受信できない。クライアント２は、タイムアウトとなると（タイムアウト秒待つと）、リクエストパケットを、負荷分散装置３へ再送する。そして、負荷分散装置３は、再送されたリクエストパケットを受信し、サーバ４へ転送する。クライアント２は、送信したリクエストパケットに対するＡｃｋを受信するまでこの動作を繰り返す。そして、最終的に、クライアント２は、負荷分散装置３から、レスポンスパケットを受信する。
【００６５】
図１０，１１（ａ），１１（ｂ）は、ＨＴＴＰリクエストが複数のリクエストパケットで構成される場合の、負荷分散システム１の動作シーケンスを示す図である。第三に、図１０を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットが消失しない場合の動作シーケンスについて説明する。
【００６６】
ここではデリミタを含まないリクエストパケットをリクエストパケットａ（ＨＴＴＰリクエストａを含むリクエストパケット）、デリミタを含むリクエストパケットをリクエストパケットｂ（ＨＴＴＰリクエストｂを含むリクエストパケット）とする。即ち、一つのＨＴＴＰリクエストが、ＨＴＴＰリクエストａとＨＴＴＰリクエストｂとに分かれて構成される。ＨＴＴＰリクエストが、三つ以上のリクエストパケットで構成されている場合、最後のリクエストパケットをリクエストパケットｂ、その直前までのリクエストパケットをリクエストパケットａとみなせばよい。
【００６７】
クライアント２は、リクエストパケットａを、負荷分散装置３へ送信する。負荷分散装置３はリクエストパケットａのペイロードを解析し、リクエストパケットａにデリミタが含まれていないと判断する。このため、負荷分散装置３は、クライアント２に対しＡｃｋを含むパケット（Ａｃｋパケット）を送信する。
【００６８】
クライアント２は、負荷分散装置３から、Ａｃｋパケットを受信する。そして、クライアント２は、負荷分散装備３へ、リクエストパケットｂを送信する。負荷分散装置３は、リクエストパケットｂのペイロードを解析し、デリミタが含まれていると判断する。このため、負荷分散装置３は、先に受信したリクエストパケットａとリクエストパケットｂとを用いて、振り分け先サーバ４を決定する。そして、負荷分散装置３は、決定したサーバ４に対してＴＣＰコネクションをオープンし、リクエストパケットａ，ｂをサーバ４に転送する。
【００６９】
サーバ４は、リクエストパケットａ，ｂを、負荷分散装置３から受信する。サーバ４は、受信したリクエストパケットに対するレスポンスパケットを生成する。そして、サーバ４は、生成したレスポンスパケットを、負荷分散装置３へ送信する。
【００７０】
負荷分散装置３は、レスポンスパケットに含まれるＡｃｋ番号を用いて、リクエストパケットａに対する受信確認をする。負荷分散装置３は、レスポンスパケットをクライアント２に転送する。
【００７１】
クライアント２は、レスポンスパケットを受信する。そして、クライアント２は、受信したレスポンスパケットにより、受信確認をする。
【００７２】
第四に、図１１（ａ）を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットａが消失する場合の動作シーケンスについて説明する。ただし、負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送するまでの動作シーケンスは、第三の場合と同じであるため、その説明を省略する。
【００７３】
負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送した後に、リクエストパケットａが消失したものとする。この場合、サーバ４は、リクエストパケットｂを受信するが、リクエストパケットａを受信しない。このため、サーバ４は、リクエストパケットａに対するＡｃｋを含むパケットを送信しない。
【００７４】
負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信できないため、タイムアウト秒経過後、リクエストパケットａをサーバ４に再送する。負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信するまでこの処理を繰り返す。最終的に、負荷分散装置３は、サーバ４からレスポンスパケットを受信し、受信したレスポンスパケットをクライアント２へ転送する。このとき、このレスポンスパケットは、リクエストパケットａに対するＡｃｋを含む。このため、負荷分散装置３は、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信したこととなる。
【００７５】
第五に、図１１（ｂ）を用いて、ＨＴＴＰリクエストが複数のリクエストパケットで構成され、リクエストパケットｂが消失する場合の動作シーケンスについて説明する。ただし、負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送するまでの動作シーケンスは、第三の場合と同じであるため省略する。
【００７６】
負荷分散装置３がリクエストパケットａ，ｂをサーバ４に転送した後に、リクエストパケットｂが消失したものとする。この場合、サーバ４は、リクエストパケットａのみを受信する。このため、サーバ４はリクエストパケットａのみに対するＡｃｋを含むパケットを、負荷分散装置３へ送信する。
【００７７】
負荷分散装置３は、リクエストパケットａに対するＡｃｋを含むパケットを受信する。その後、負荷分散装置３は、このＡｃｋを含むパケットをクライアント２へ転送する。
【００７８】
クライアント２は、リクエストパケットａに対するＡｃｋを含むパケットを受信する。しかし、クライアント２は、リクエストパケットａに対するＡｃｋを含むパケットは既に受信済みであるため、何も実行しない。即ち、クライアント２は、既に負荷分散装置３から、リクエストパケットａに対するＡｃｋを含むパケットを受信しているため、何の処理も実行しない。ただし、クライアント２は、リクエストパケットｂに対するＡｃｋを含むパケットを受信できない。このため、クライアント２は、タイムアウト秒経過後、リクエストパケットｂを、負荷分散装置３へ再送する。
【００７９】
クライアント２は、負荷分散装置３からレスポンスパケットを受信するまでこの処理を繰り返す。このとき、レスポンスパケットは、リクエストパケットｂに対するＡｃｋを含む。このため、クライアント２は、負荷分散装置３からＡｃｋパケットを受信したこととなる。
【００８０】
〈作用〉
本発明の第一実施形態における負荷分散装置３は、ＨＴＴＰリクエストが一つのリクエストパケットにより構成される場合、リクエストパケットに対するＡｃｋをクライアント２に送信しない。従って、負荷分散装置３は、リクエストパケットについて再送管理を実行する必要が無い。このため、このリクエストパケットを、パケットバッファ８から早期に消去することが可能となる。即ち、負荷分散装置３は、パケットバッファ８の記憶領域を、早期に解放することが可能となる。
【００８１】
図１２（ａ）は、ＨＴＴＰリクエストが一つのリクエストパケットにより構成される場合に、パケットバッファ８の記憶領域が解放されるタイミングを示す図である。従来の負荷分散装置は、リクエストパケットに対するＡｃｋをサーバから受信した時点（レスポンスパケットを受信した時点）で、リクエストパケットをパケットバッファから消去する。一方、負荷分散装置３は、リクエストパケットをサーバ４に転送した時点で、リクエストパケットをパケットバッファ８から消去する。このタイミングの差分を、図１２（ａ）に太線として示す。このように、本発明による負荷分散装置３によれば、パケットバッファ８の記憶領域を早期に解放することが可能となる。
【００８２】
また、ＨＴＴＰリクエストが複数のリクエストパケットにより構成される場合、負荷分散装置３は、最後のリクエストパケット（デリミタを含むリクエストパケット）に対するＡｃｋをクライアント２に送信しない。このため、負荷分散装置３は、最後のリクエストパケットについて再送管理を実行する必要が無い。従って、最後のリクエストパケットをパケットバッファ８から早期に消去することが可能となる。即ち、負荷分散装置３は、パケットバッファ８の記憶領域を早期に解放することが可能となる。
【００８３】
図１２（ｂ）は、ＨＴＴＰリクエストが複数のリクエストパケットにより構成される場合に、パケットバッファ８の記憶領域が解放されるタイミングを示す図である。従来の負荷分散装置は、最後のリクエストパケットに対するＡｃｋをサーバから受信した時点（レスポンスパケットを受信した時点）で、パケットバッファから最後のリクエストパケットを消去する。しかし、負荷分散装置３は、最後のリクエストパケットをサーバ４に転送した時点で、パケットバッファ８から最後のリクエストパケットを消去する。このタイミングの差分を、図１２（ｂ）に太線として示す。
【００８４】
このように、第一実施形態の負荷分散装置３は、パケットバッファ８の記憶領域を早期に開放する。このため、負荷分散装置３におけるセッションの多重率の向上、それに伴う負荷分散装置３におけるレイテンシの向上、発熱量、消費電力、実装面積の縮小などが実現される。
【００８５】
〈変形例〉
本発明の第一実施形態による負荷分散装置３は、パケットバッファ８，９がそれぞれ別に構成されているが、一つの記憶装置を用いて構成されても良い。
【００８６】
〔第二実施形態〕
〈システム構成〉
第二実施形態における負荷分散装置３ａを用いた負荷分散システム１ａについて説明する。負荷分散システム１ａのシステム構成は、基本的に、第一実施形態における負荷分散装置３を用いた負荷分散システム１と同じである。即ち、負荷分散システム１ａは、複数のクライアント２，負荷分散装置３ａ，複数のサーバ４，及び複数のクライアント２と負荷分散装置３ａとを通信可能に接続するネットワーク５とを用いて構成される。クライアント２とサーバ４とは、上記した第一実施形態においてすでに説明したため、以下では負荷分散装置３ａの構成について説明する。
【００８７】
〈〈負荷分散装置〉〉
図１３は、本発明による第二実施形態の負荷分散装置３ａのブロック図である。
図１３を用いて、負荷分散装置３ａの構成について説明する。ただし、負荷分散装置３ａについて、負荷分散装置３と異なる構成についてのみ説明する。負荷分散装置３ａは、パケット送信許可部２０をさらに備える。
【００８８】
パケット送信許可部２０は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。パケット送信許可部２０は、サーバ４に転送されたリクエストパケットのシーケンス番号とデータ長とを記憶する。また、パケット送信許可部２０は、サーバ４から受信したパケットのＡｃｋ番号と、シーケンス番号及びデータ長の和とを比較する。パケット送信許可部２０は、二つの値が一致した場合、パケットバッファ８に対し、後続のリクエストパケットをサーバ４に転送することを許可する。
【００８９】
〈動作例〉
図１４は、第二実施形態における負荷分散装置３ａの動作例のうち、負荷分散装置３と異なる部分のみを示したフローチャートである。図１４を用いて、負荷分散装置３ａの動作例について説明する。ただし、負荷分散装置３の動作と異なる動作についてのみ説明する。
【００９０】
振り分け先決定部１７は、振り分け先となるサーバ４を決定すると（Ｓ１０）、決定されたサーバ４に対し、最初のリクエストパケットを一つ転送する（Ｓ２２）。このとき、パケット送信許可部２０は、転送されたリクエストパケットにおけるシーケンス番号及びデータ長を記憶する。
【００９１】
パケットバッファ９にＡｃｋを含むパケットがバッファリングされると、パケット送信許可部２０は、このパケットのＡｃｋ番号と、自身が記憶するシーケンス番号及びデータ長の和とを比較する。この値が一致した場合、パケット送信許可部２０は、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信したと判断する（Ｓ２３）。
【００９２】
パケット送信許可部２０が、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信していないと判断した場合、又はパケットバッファ９にＡｃｋを含むパケットがバッファリングされていない場合（Ｓ２３−Ｎｏ）、再送管理タイマ１１は、転送されたリクエストパケットについてタイムアウトか否かを判断する（Ｓ２４）。タイムアウトである場合（Ｓ２４−Ｙｅｓ）、パケットバッファ８は、タイムアウトと判断されたリクエストパケットを、サーバ４へ再送する（Ｓ２２）。一方、タイムアウトでない場合（Ｓ２４−Ｎｏ）、負荷分散装置３ａは、転送されたリクエストパケットに対するＡｃｋが受信されるまで待機する。
【００９３】
パケット送信許可部２０が、転送されたリクエストパケットに対するＡｃｋを含むパケットを受信したと判断した場合（Ｓ２３−Ｙｅｓ）、パケット送信許可部２０は、全てのリクエストパケットが転送されたか否かを判断する（Ｓ２５）。転送されていないリクエストパケットがある場合（Ｓ２５−Ｎｏ）、パケット送信許可部２０は、後続のリクエストパケットが転送されることを許可する。一方、全てのリクエストパケットが転送された場合（Ｓ２５−Ｙｅｓ）、Ｓ１２以降の処理が実行される（図６参照）。
【００９４】
〈動作シーケンス〉
図１５は、第二実施形態における負荷分散装置３ａを用いた負荷分散システム１ａの動作シーケンスを示す図である。図１５を用いて、負荷分散システム１ａの動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスと異なる動作シーケンスについてのみ説明する。
【００９５】
負荷分散装置３ａは、リクエストパケットの転送先となるサーバ４を決定した後、決定したサーバ４に対し、リクエストパケットａを転送する。サーバ４は、負荷分散装置３ａからリクエストパケットａを受信する。そして、サーバ４は、受信したリクエストパケットａに対するＡｃｋを含むパケットを、負荷分散装置３ａに送信する。
【００９６】
負荷分散装置３ａは、サーバ４から、リクエストパケットａに対するＡｃｋを含むパケットを受信すると、このパケットをクライアント２へ転送する。そして、負荷分散装置３ａは、後続のリクエストパケット、即ちリクエストパケットｂをサーバ４へ転送する。
【００９７】
〈作用〉
図１６は、従来技術における負荷分散装置Ｐ３と本発明の第二実施形態における負荷分散装置３ａとの動作の差異を示す図である。図１６を用いて、本発明の第二実施形態における負荷分散装置３ａの作用について説明する。従来技術における負荷分散装置Ｐ３は、複数のリクエストパケットで構成されるＨＴＴＰリクエストをサーバＰ４へ転送する場合、リクエストパケットを連続して転送する。このため、負荷分散装置Ｐ３とサーバＰ４との間で輻輳が発生し、リクエストパケットが消失することがあった。
【００９８】
一方、本発明の第二実施形態における負荷分散装置３ａは、複数のリクエストパケットで構成されるＨＴＴＰリクエストをサーバ４に転送する場合、先に転送されたリクエストパケットに対するＡｃｋを含むパケットを受信した後、後続のリクエストパケットを転送する。このため、負荷分散装置３ａとサーバ４との間において、輻輳の発生が防止される。従って、輻輳発生によるリクエストパケットの消失が防止される。
【００９９】
〈変形例〉
パケット送信許可部２０は、送信を許可するリクエストパケットの数を指数関数的に増加させても良い。即ち、パケット送信許可部２０は、送信を許可するリクエストパケットの数を、スロースタートメカニズムに従って決定しても良い。
【０１００】
〔第三実施形態〕
〈システム構成〉
第三実施形態における負荷分散装置３ｂを用いた負荷分散システム１ｂについて説明する。負荷分散システム１ｂのシステム構成は、基本的に、第一実施形態における負荷分散装置３を用いた負荷分散システム１と同じである。即ち、負荷分散システム１ｂは、複数のクライアント２，負荷分散装置３ｂ，複数のサーバ４，及び複数のクライアント２と負荷分散装置３ｂとを通信可能に接続するネットワーク５とを用いて構成される。クライアント２とサーバ４とは、上記した第一実施形態の欄ですでに説明したため、以下では負荷分散装置３ｂの構成について説明する。
【０１０１】
〈〈負荷分散装置〉〉
図１７は、本発明による第三実施形態の負荷分散装置３ｂのブロック図である。
図１７を用いて、負荷分散装置３ｂの構成について説明する。ただし、負荷分散装置３ｂについて、負荷分散装置３と異なる構成についてのみ説明する。負荷分散装置３ｂは、ペイロード有無確認部２１をさらに備える。
【０１０２】
ペイロード有無確認部２１は、ＣＰＵやＲＡＭ等、あるいは専用パケット処理プロセッサ等を用いて構成される。ペイロード有無確認部２１は、パケットバッファ９に記憶されているパケットがペイロードを含むか否かを確認する。このパケットにペイロードが含まれていない場合、ペイロード有無確認部２１は、このパケットを消去するように、パケットバッファ９に指示を出す。一方、このパケットにペイロードが含まれている場合、ペイロード有無確認部２１は、このパケットをクライアント２へ転送するようにパケットバッファ９に指示を出す。
【０１０３】
〈動作例〉
図１８は、第三実施形態における負荷分散装置３ｂの動作例のうち、負荷分散装置３と異なる部分のみを示した図である。図１８を用いて、負荷分散装置３ｂの動作例について説明する。ただし、負荷分散装置３の動作と異なる動作についてのみ説明する。
【０１０４】
サーバ４から新たなパケットが受信されると、Ａｃｋ番号抽出部１８は、パケットバッファ８において、このパケットのＡｃｋ番号よりもシーケンス番号及びデータ長の和が小さな値となるパケットの有無を確認する（Ｓ１８）。このようなパケットがパケットバッファ８にバッファリングされている場合（Ｓ１８−Ｙｅｓ）、パケットバッファ８は、そのパケットを消去する（Ｓ１９）。
【０１０５】
次に、ペイロード有無確認部２１は、このパケットがペイロードを含むか否かを判断する（Ｓ２６）。このパケットがペイロードを含まない場合（Ｓ２６−Ｎｏ）、ペイロード有無確認部２１は、パケットバッファ９に、このパケットをクライアント２に転送せずに消去するように指示を出す。一方、このパケットがペイロードを含む場合（Ｓ２６−Ｙｅｓ）、ペイロード有無確認部２１は、このパケットをクライアント２へ転送するようにパケットバッファ９に指示を出す。
【０１０６】
〈動作シーケンス〉
図１９は、第三実施形態における負荷分散装置３ｂを用いた負荷分散システム１ｂの動作シーケンスを示す図である。図１９を用いて、負荷分散システム１ｂの動作シーケンスについて説明する。ただし、負荷分散システム１の動作シーケンスと異なる動作シーケンスについてのみ説明する。
【０１０７】
負荷分散装置３ｂは、サーバ４に対し、リクエストパケットａ，ｂを転送する。サーバ４は、リクエストパケットａに対するＡｃｋを含むパケットや、リクエストパケットｂに対するＡｃｋを含むパケット（この場合はレスポンスパケット）を、負荷分散装置３ｂに対し送信する。負荷分散装置３ｂは、リクエストパケットａに対するＡｃｋを含むパケットを受信した場合、このＡｃｋパケットをクライアント２に転送せずに消去する。即ち、負荷分散装置３ｂは、ＨＴＴＰレスポンスを含まないパケットを受信した場合、このパケットをクライアント２に転送せずに消去する。一方、負荷分散装置３ｂは、レスポンスパケットを受信した場合、このレスポンスパケットをクライアント２に転送する。
【０１０８】
〈作用〉
図２０は、従来技術における負荷分散装置Ｐ３と本発明の第三実施形態における負荷分散装置３ｂとの動作の差異を示す図である。図２０を用いて、本発明の第三実施形態における負荷分散装置３ｂの作用について説明する。従来技術における負荷分散装置Ｐ３は、サーバＰ４から受信する全てのパケットをクライアントＰ２へ転送する。よって、従来技術における負荷分散装置Ｐ３は、ＨＴＴＰレスポンスを含まないパケット（この場合、Ａｃｋのためのパケット）、即ちクライアントＰ２に転送される必要のないパケットをクライアントＰ２に転送する。このため、クライアントＰ２と負荷分散装置Ｐ３とを接続するネットワークの帯域が不必要に消費されていた。
【０１０９】
一方、本発明の第三実施形態における負荷分散装置３ｂは、ＨＴＴＰレスポンスを含まないパケット、即ちペイロードを含まないパケットを、クライアント２に転送せずに消去する。このため、ネットワーク５において、帯域が無駄に消費されない。
【０１１０】
〈変形例〉
ペイロード有無確認部２１は、本発明の第二実施形態における負荷分散装置３ａに適用されても良い。本発明の第二実施形態における負荷分散装置３ａでは、リクエストパケットａの転送とリクエストパケットｂの転送との間に、必ずサーバ４からＡｃｋを含むパケット（ペイロードを含まないパケット）を受信する。このとき、ペイロード有無確認部２１が適用されることにより、このパケットをクライアント２に送信することがなくなる。このため、ネットワーク５において、帯域を節約することが可能となる。
【０１１１】
〔その他〕
本発明は、以下のように特定することができる。
（付記１） クライアントから受信したデータの内容に応じて、クライアントへ当該データの確認応答を送信するか否かを判断する判断手段と、
前記判断手段の判断結果に応じて、クライアントへ確認応答を送信する確認応答手段と、
前記クライアントから受信したデータを複数のサーバのいずれかへ転送する転送手段と、
前記サーバへ転送されたデータのうち、このデータについてクライアントへ確認応答が送信されたデータのみを、前記サーバへの再送に備えて記憶する再送デ一夕記憶手段と、
を備える負荷分散装置。
（付記２）前記判断手段は、クライアントから受信したデータがデリミタを含まない場合にクライアントへ確認応答を送信すると判断し、前記データがデリミタを含む場合にクライアントへ確認応答を送信しないと判断する付記１に記載の負荷分散装置。
（付記３）連続する複数のデータをサーバへ転送する場合に、最後にサーバに転送されたデータに対する確認応答をサーバから受信したときに、次のデータをサーバヘ転送することを許可する確認応答判断手段をさらに備える付記１又は２に記載の負荷分散装置。
（付記４）サーバから受信されたデータを、クライアントへ転送すべきか否かを判断する転送判断手段をさらに備える付記１〜３のいずれかに記載の負荷分散装置。
（付記５）前記転送判断手段は、前記サーバから受信されたデータが、確認応答のためのデータのみからなる場合に転送すべきでないと判断する付記４に記載の負荷分散装置。
（付記６）前記判断手段は、前記クライアントから受信したデータが一つのパケットからなるＨＴＴＰリクエストである場合に確認応答を送信しないと判断する付記１に記載の負荷分散装置。
（付記７）前記判断手段は、前記クライアントから受信したデニタが複数のパケットからなるＨＴＴＰリクエストである場合に、このＨＴＴＰリクエストを構成する最後のパケットを受信した際に確認応答を送信しないと判断する付記１又は２に記載の負荷分散装置。
【０１１２】
【発明の効果】
本発明によれば、クライアントからサーバへ転送するデータを、早期に送信バッファから消去することにより、送信バッファの使用時間を減少させることが可能となる。
【図面の簡単な説明】
【図１】 従来技術における再送管理省略の動作シーケンスを示す図である。
【図２】 スロースタートメカニズムを示す図である。
【図３】 従来技術の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図４】 負荷分散システムの概略を示す図である。
【図５】 第一実施形態の負荷分散装置のブロック図である。
【図６】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図７】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図８】 第一実施形態の負荷分散装置の動作例を示すフローチャートである。
【図９】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１０】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１１】 第一実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１２】 負荷分散装置の記憶領域が解放されるタイミングを示す図である。
【図１３】 第二実施形態の負荷分散装置のブロック図である。
【図１４】 第二実施形態の負荷分散装置の動作例を示すフローチャートである。
【図１５】 第二実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図１６】 従来技術における負荷分散装置と本発明の第二実施形態における負荷分散装置との動作の差異を示す図である。
【図１７】 第三実施形態の負荷分散装置のブロック図である。
【図１８】 第三実施形態の負荷分散装置の動作例を示すフローチャートである。
【図１９】 第三実施形態の負荷分散装置を用いた負荷分散システムの動作シーケンスを示す図である。
【図２０】 従来技術における負荷分散装置と本発明の第三実施形態における負荷分散装置との動作の差異を示す図である。
【符号の説明】
１ 負荷分散システム
２ クライアント
３，３ａ，３ｂ 負荷分散装置
４ サーバ
５ ネットワーク
６，７ ネットワークインタフェース
８，９ パケットバッファ
１０，１８ Ａｃｋ番号抽出部
１１，１９ 再送管理タイマ
１２，１３ シーケンス番号・データ長抽出部
１４，１５ Ａｃｋ応答生成部
１６ ＨＴＴＰデリミタ検出部
１７ 振り分け先決定部
２０ パケット送信許可部
２１ ペイロード有無確認部
Claims (8)
- クライアントから受信したデータの内容に応じて、クライアントへ当該データの確認応答を送信するか否かを判断する判断手段と、
前記判断手段の判断結果に応じて、クライアントへ確認応答を送信する確認応答手段と、
前記クライアントから受信したデータを複数のサーバのいずれかへ転送する転送手段と、
前記サーバへ転送されたデータのうち、前記転送されたデータについてクライアントへ確認応答が送信されたデータのみを、前記サーバへの再送に備えて記憶する再送データ記憶手段と、
を備える負荷分散装置。 - 前記判断手段は、クライアントから受信したデータがデリミタを含まない場合にクライアントへ確認応答を送信すると判断し、前記データがデリミタを含む場合にクライアントへ確認応答を送信しないと判断する請求項１に記載の負荷分散装置。
- 連続する複数のデータをサーバへ転送する場合に、最後にサーバに転送されたデータに対する確認応答をサーバから受信したときに、次のデータをサーバへ転送することを許可する確認応答判断手段をさらに備える請求項１又は２に記載の負荷分散装置。
- サーバから受信されたデータを、クライアントへ転送すべきか否かを判断する転送判断手段をさらに備える請求項１〜３のいずれかに記載の負荷分散装置。
- 前記転送判断手段は、前記サーバから受信されたデータが、確認応答のためのデータのみからなる場合に転送すべきでないと判断する請求項４に記載の負荷分散装置。
- クライアントと複数のサーバとの間に設けられる負荷分散装置において、
クライアントから受信したデータを記憶する記憶手段と、
前記クライアントから受信したデータが、前記クライアントに対する確認応答を要するデータか否かを判断する判断手段と、を備え、
前記判断手段により、前記クライアントから受信したデータが前記確認応答を要しないデータであると判断された場合、前記記憶手段に記憶されたデータをサーバに転送した時点で消去することを特徴とする、負荷分散装置。 - 前記判断手段は、前記クライアントから受信したデータにデリミタが含まれているか否かを判別し、前記データにデリミタが含まれる場合に、当該データが前記確認応答を要しないデータであると判断することを特徴とする、請求項６に記載の負荷分散装置。
- クライアントから受信したデータを記憶する記憶手段と、
前記クライアントから受信したデータが、複数のパケットから構成されるか否かを判断する判断手段と、
前記判断手段により、受信したデータが複数のパケットから構成され、且つ受信したパケットが最後のパケットではないと判断された場合、当該データに対する確認応答を前記クライアントに送信するとともに、受信したデータが一つのパケットから構成されると判断された場合、あるいは受信したデータが複数のパケットから構成され、且つ受信したパケットが最後のパケットであると判断された場合、前記クライアントに対する確認応答を送信しない確認応答手段と、を備え、
前記確認応答手段から前記クライアントに対する確認応答が送信されない場合、パケットをサーバに転送した時点で前記記憶手段に記憶されたデータを消去することを特徴とす る負荷分散装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002254233A JP4201550B2 (ja) | 2002-08-30 | 2002-08-30 | 負荷分散装置 |
| US10/640,144 US20040054796A1 (en) | 2002-08-30 | 2003-08-13 | Load balancer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002254233A JP4201550B2 (ja) | 2002-08-30 | 2002-08-30 | 負荷分散装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004094555A JP2004094555A (ja) | 2004-03-25 |
| JP4201550B2 true JP4201550B2 (ja) | 2008-12-24 |
Family
ID=31986291
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002254233A Expired - Fee Related JP4201550B2 (ja) | 2002-08-30 | 2002-08-30 | 負荷分散装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040054796A1 (ja) |
| JP (1) | JP4201550B2 (ja) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BR0315624A (pt) | 2002-10-22 | 2005-08-23 | Jason A Sullivan | Sistema de processamento em computador personalizável robusto |
| CN1729734B (zh) | 2002-10-22 | 2011-01-05 | 贾森·A·沙利文 | 用于提供动态模块处理单元的系统及方法 |
| EP1557075A4 (en) | 2002-10-22 | 2010-01-13 | Sullivan Jason | CONTROL MODULE NOT ASSOCIATED WITH PERIPHERALS HAVING IMPROVED HEAT DISSIPATION PROPERTIES |
| US20140250267A1 (en) * | 2002-10-22 | 2014-09-04 | Jason A. Sullivan | Systems and methods for providing dynamic hybrid storage |
| JP4335090B2 (ja) | 2004-05-14 | 2009-09-30 | シャープ株式会社 | 移動端末装置 |
| JP4597583B2 (ja) | 2004-05-31 | 2010-12-15 | シャープ株式会社 | データ送信装置、データ受信装置、通信システム、データ送信装置の制御プログラム、データ受信装置の制御プログラム、および、コンピュータ読み取り可能な記録媒体 |
| US8036244B2 (en) * | 2004-08-06 | 2011-10-11 | Sharp Kabushiki Kaisha | Transmitter, receiver, communication system, communication method, non-transitory computer readable medium |
| JP2006086611A (ja) * | 2004-09-14 | 2006-03-30 | Sony Corp | 情報処理装置、情報処理システム、情報処理方法及びそのプログラム |
| US7752670B2 (en) * | 2004-09-23 | 2010-07-06 | Xiangrong Cai | Detecting an attack of a network connection |
| US8051182B2 (en) * | 2005-01-28 | 2011-11-01 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
| JP4198741B2 (ja) * | 2005-01-28 | 2008-12-17 | シャープ株式会社 | 通信機器、通信システム、通信方法、通信プログラム、通信回路 |
| KR100902341B1 (ko) * | 2005-01-28 | 2009-06-12 | 샤프 가부시키가이샤 | 통신기기, 통신시스템, 통신방법, 통신 프로그램을 기록한 컴퓨터독취가능한 기록매체, 통신회로 |
| US7787391B2 (en) * | 2005-01-28 | 2010-08-31 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
| JP2006324973A (ja) * | 2005-05-19 | 2006-11-30 | Murata Mach Ltd | ルータ装置および通信システム |
| US20090262661A1 (en) * | 2005-11-10 | 2009-10-22 | Sharp Kabushiki Kaisha | Data transmission device and method of controlling same, data receiving device and method of controlling same, data transfer system, data transmission device control program, data receiving device control program, and storage medium containing the programs |
| CN101026617B (zh) * | 2006-02-18 | 2010-09-15 | 华为技术有限公司 | 一种ims网络中媒体资源调度方法 |
| US8576712B2 (en) * | 2006-05-31 | 2013-11-05 | At&T Intellectual Property Ii, L.P. | Method and apparatus for providing a reliable voice extensible markup language service |
| JP4664243B2 (ja) * | 2006-06-29 | 2011-04-06 | 富士通株式会社 | 通信装置 |
| JP4219950B2 (ja) * | 2006-10-16 | 2009-02-04 | シャープ株式会社 | 通信機器、通信方法、通信回路、携帯電話機、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体 |
| CN101335603B (zh) * | 2008-07-17 | 2011-03-30 | 华为技术有限公司 | 数据传输方法和装置 |
| US9025475B1 (en) * | 2012-01-16 | 2015-05-05 | Amazon Technologies, Inc. | Proactively retransmitting data packets in a low latency packet data network |
| WO2014172896A1 (zh) * | 2013-04-26 | 2014-10-30 | 华为技术有限公司 | 一种数据传输的方法、基站和无线通信设备 |
| JP6038326B2 (ja) * | 2013-07-30 | 2016-12-07 | 三菱電機株式会社 | データ処理装置及びデータ通信装置及び通信システム及びデータ処理方法及びデータ通信方法及びプログラム |
| US10069727B2 (en) * | 2015-04-17 | 2018-09-04 | International Business Machines Corporation | Data packet retransmission processing |
| CN110971535B (zh) * | 2020-03-03 | 2020-07-14 | 友刻(北京)通讯技术有限公司 | 一种通信拥塞控制方法及装置、设备和存储介质 |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN86101893A (zh) * | 1985-02-28 | 1986-11-05 | 佳能株式会社 | 数据通信设备 |
| US5163054A (en) * | 1990-12-31 | 1992-11-10 | International Business Machines Corp. | Method for data transmission using a modified high level data link control protocal |
| US5819045A (en) * | 1995-12-29 | 1998-10-06 | Intel Corporation | Method for determining a networking capability index for each of a plurality of networked computers and load balancing the computer network using the networking capability indices |
| JP3715991B2 (ja) * | 1996-02-09 | 2005-11-16 | 株式会社日立製作所 | 並列プロセッサ |
| US6003064A (en) * | 1996-02-22 | 1999-12-14 | Fujitsu Limited | System and method for controlling data transmission between network elements |
| US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
| US6775692B1 (en) * | 1997-07-31 | 2004-08-10 | Cisco Technology, Inc. | Proxying and unproxying a connection using a forwarding agent |
| US6128279A (en) * | 1997-10-06 | 2000-10-03 | Web Balance, Inc. | System for balancing loads among network servers |
| US6018516A (en) * | 1997-11-14 | 2000-01-25 | Packeteer, Inc. | Method for minimizing unneeded retransmission of packets in a packet communication environment supporting a plurality of data link rates |
| US6327622B1 (en) * | 1998-09-03 | 2001-12-04 | Sun Microsystems, Inc. | Load balancing in a network environment |
| US6671259B1 (en) * | 1999-03-30 | 2003-12-30 | Fujitsu Limited | Method and system for wide area network load balancing |
| US6700871B1 (en) * | 1999-05-04 | 2004-03-02 | 3Com Corporation | Increased throughput across data network interface by dropping redundant packets |
| US6628654B1 (en) * | 1999-07-01 | 2003-09-30 | Cisco Technology, Inc. | Dispatching packets from a forwarding agent using tag switching |
| US6742045B1 (en) * | 1999-07-02 | 2004-05-25 | Cisco Technology, Inc. | Handling packet fragments in a distributed network service environment |
| US6735169B1 (en) * | 1999-07-02 | 2004-05-11 | Cisco Technology, Inc. | Cascading multiple services on a forwarding agent |
| US6687222B1 (en) * | 1999-07-02 | 2004-02-03 | Cisco Technology, Inc. | Backup service managers for providing reliable network services in a distributed environment |
| US6633560B1 (en) * | 1999-07-02 | 2003-10-14 | Cisco Technology, Inc. | Distribution of network services among multiple service managers without client involvement |
| US6650641B1 (en) * | 1999-07-02 | 2003-11-18 | Cisco Technology, Inc. | Network address translation using a forwarding agent |
| US6606315B1 (en) * | 1999-07-02 | 2003-08-12 | Cisco Technology, Inc. | Synchronizing service instructions among forwarding agents using a service manager |
| US6549516B1 (en) * | 1999-07-02 | 2003-04-15 | Cisco Technology, Inc. | Sending instructions from a service manager to forwarding agents on a need to know basis |
| IL142969A (en) * | 2000-05-04 | 2007-02-11 | Comverse Ltd | Load balancing |
| US6836462B1 (en) * | 2000-08-30 | 2004-12-28 | Cisco Technology, Inc. | Distributed, rule based packet redirection |
| US20030046394A1 (en) * | 2000-11-03 | 2003-03-06 | Steve Goddard | System and method for an application space server cluster |
| US7984147B2 (en) * | 2000-12-29 | 2011-07-19 | Hewlett-Packard Development Company, L.P. | Apparatus and method for identifying a requested level of service for a transaction |
| US7523454B2 (en) * | 2001-03-06 | 2009-04-21 | Hewlett-Packard Development Company, L.P. | Apparatus and method for routing a transaction to a partitioned server |
| US20030014524A1 (en) * | 2001-07-11 | 2003-01-16 | Alexander Tormasov | Balancing shared servers in virtual environments |
| US7321926B1 (en) * | 2002-02-11 | 2008-01-22 | Extreme Networks | Method of and system for allocating resources to resource requests |
| US7194621B1 (en) * | 2002-02-28 | 2007-03-20 | Cisco Technology, Inc. | Method and apparatus for encrypting data communicated between a client and a server that use an unencrypted data transfer protocol |
| US7058717B2 (en) * | 2002-07-25 | 2006-06-06 | International Business Machines Corporation | Method and system for providing highly available services based on a load balancing policy and a reusable connection context object |
-
2002
- 2002-08-30 JP JP2002254233A patent/JP4201550B2/ja not_active Expired - Fee Related
-
2003
- 2003-08-13 US US10/640,144 patent/US20040054796A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20040054796A1 (en) | 2004-03-18 |
| JP2004094555A (ja) | 2004-03-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4201550B2 (ja) | 負荷分散装置 | |
| JP3833847B2 (ja) | パケットベースの通信ネットワークにおけるメッセージ受信の肯定応答システム及び方法 | |
| JP4575435B2 (ja) | ネットワーク・リンク上でのｈｔｔｐの加速 | |
| US7720063B2 (en) | Method apparatus and system for accelerated communication | |
| US7197571B2 (en) | System and method for improving backup performance of media and dynamic ready to transfer control mechanism | |
| US20030208600A1 (en) | System and method for managing persistent connections in HTTP | |
| US7970925B2 (en) | Method and apparatus for an improved bulk read socket call | |
| US7624184B1 (en) | Methods and apparatus for managing access to data through a network device | |
| US20060031520A1 (en) | Allocation of common persistent connections through proxies | |
| US20030033520A1 (en) | HTTP multiplexor/demultiplexor system for use in secure transactions | |
| KR20080015422A (ko) | 긴 지연 링크를 통한 ｈｔｔｐ의 성능을 향상시키는 방법및 장치 | |
| US20090080332A1 (en) | Method and System for a Fast Drop Recovery for a TCP Connection | |
| KR20060085241A (ko) | 차동 확인 응답 프로세싱 버퍼 관리자 및 이를 위한 방법 | |
| Savage et al. | The case for informed transport protocols | |
| US7979526B2 (en) | Connection management system and method for a transport offload engine | |
| US7388836B2 (en) | System and method for communicating data in a network environment | |
| CN109067506A (zh) | 一种基于多滑动窗口并发的轻量级异步消息实现方法 | |
| US7672239B1 (en) | System and method for conducting fast offloading of a connection onto a network interface card | |
| JP3648211B2 (ja) | パケット中継プログラム、パケット中継装置および記録媒体 | |
| Iyengar et al. | Dealing with short TCP flows: A survey of mice in elephant shoes | |
| JPWO2018142866A1 (ja) | 転送装置、転送方法及びプログラム | |
| Kruse et al. | HTTP page transfer rates over geo-stationary satellite links | |
| Rhee et al. | Heuristic connection management for improving server-side performance on the Web | |
| JP2002290442A (ja) | 通信装置、プログラム、情報記憶媒体および通信制御方法 | |
| Pandey et al. | Intermediate processing protocol for processing within IP-routed networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050816 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071211 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080212 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080924 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081007 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131017 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |