(57)【特許請求の範囲】
【請求項１】
複数の端末が１つのサーバに対してＴＣＰ(Transmission Control Protocol)のコネクションを確立している際に、前記端末からのデータの送信レートを制御するサーバのレート制御方法において、
前記サーバが、各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
前記サーバが、回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する第１のステップと、
前記サーバが、前記回線帯域幅BandWidthを、前記接続中のコネクション数NumConncetionsで除算したレートRateを算出し、前記レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出する第２のステップと、
前記サーバが、前記端末からデータを受信することによって前記最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、前記算出ウィンドウサイズkwndが前記空き受信バッファサイズbuffszよりも小さい場合に、前記算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する第３のステップと
前記サーバが、前記受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACK(Acknowledge)を、前記端末へ送信する第４のステップと
を有し、
前記端末が、前記確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とするレート制御方法。
【請求項２】
複数の端末が１つのサーバに対してＴＣＰのコネクションを確立している際に、前記端末からのデータの送信レートを制御するサーバにおいて、
各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する負荷状態測定手段と、
前記回線帯域幅BandWidthを、前記接続中のコネクション数NumConncetionsで除算したレートRateを算出し、前記レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出するウィンドウサイズ算出手段と、
前記端末からデータを受信することによって前記最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、前記算出ウィンドウサイズkwndが前記空き受信バッファサイズbuffszよりも小さい場合に、前記算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する受信ウィンドウサイズ決定手段と、
前記受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACKを生成し、前記端末へ送信する確認応答生成手段と
を有し、
前記端末が、前記確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とするサーバ。
【請求項３】
複数の端末が１つのサーバに対してＴＣＰのコネクションを確立している際に、前記端末からのデータの送信レートを制御するサーバに搭載されたコンピュータを機能させるプログラムにおいて、
各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する負荷状態測定手段と、
前記回線帯域幅BandWidthを、前記接続中のコネクション数NumConncetionsで除算したレートRateを算出し、前記レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出するウィンドウサイズ算出手段と、
前記端末からデータを受信することによって前記最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、前記算出ウィンドウサイズkwndが前記空き受信バッファサイズbuffszよりも小さい場合に、前記算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する受信ウィンドウサイズ決定手段と、
前記受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACKを生成し、前記端末へ送信する確認応答生成手段と
してコンピュータを機能させ、
前記端末が、前記確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とするサーバ用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ(Transmission Control Protocol)を用いたレート制御方法、サーバ及びプログラムに関する。
【背景技術】
【０００２】
通信回線としてはインターネットが一般化し、ユーザは、パーソナルコンピュータ又は携帯電話機のような端末を用いて、インターネットに接続することができる。インターネットには、ＷＷＷサーバのようなサーバが接続されており、端末は、サーバとの間でデータを送受信することができる。
【０００３】
サーバと端末との間でファイルデータを転送する場合、通常、ＴＣＰ／ＩＰ(Transmission Control Protocol / Internet Protocol)のコネクションが設定される。ＴＣＰは、フロー制御機能、再送制御機能、コネクション管理機能、セッション多重化機能等を有する。
【０００４】
フロー制御については、ＴＣＰヘッダに含まれる受信ウィンドウサイズrwndを用いて、相手方装置の受信バッファサイズに応じて、データの送信が制御される。これにより、コネクション間のスループットのバラつきを抑えると共に、不要なフロー制御を回避する。例えば、適応的にＴＣＰのウィンドウサイズを変更する技術（例えば特許文献１及び２参照）や、ルータによって輻輳制御をする技術（例えば特許文献３参照）がある。
【０００５】
【特許文献１】特開２００５−２４４５１７号公報
【特許文献２】特開２００６−１４３２９号公報
【特許文献３】特開２００２−３１４５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前述した特許文献に記載された技術は、コネクション毎のレート制御にすぎず、複数の端末と１つのサーバとの間のレート制御を対象としたものではない。
【０００７】
一方で、膨大な数の端末と１つのサーバとの間のレート制御については、端末側でレート制御を有効に動作させなければ、サーバは大量のトラヒックを処理することが困難となる。また、サーバに対して、特定の端末からの多くのトラヒックに処理負荷がかかることも回避する必要がある。
【０００８】
そこで、本発明は、膨大な数の端末と通信するサーバに、大量のトラヒックが集中することによる輻輳負荷状態をできる限り低減し、端末間のリソース利用の公平性を確保することができる、レート制御方法、サーバ及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明によれば、複数の端末が１つのサーバに対してＴＣＰのコネクションを確立している際に、端末からのデータの送信レートを制御するサーバのレート制御方法において、
サーバが、各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
サーバが、回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する第１のステップと、
サーバが、回線帯域幅BandWidthを、接続中のコネクション数NumConncetionsで除算したレートRateを算出し、レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出する第２のステップと、
サーバが、端末からデータを受信することによって最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、算出ウィンドウサイズkwndが空き受信バッファサイズbuffszよりも小さい場合に、算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する第３のステップと
サーバが、受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACK(Acknowledge)を、端末へ送信する第４のステップと
を有し、
端末が、確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とする。
【００１２】
本発明によれば、複数の端末が１つのサーバに対してＴＣＰのコネクションを確立している際に、端末からのデータの送信レートを制御するサーバにおいて、
各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する負荷状態測定手段と、
回線帯域幅BandWidthを、接続中のコネクション数NumConncetionsで除算したレートRateを算出し、レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出するウィンドウサイズ算出手段と、
端末からデータを受信することによって最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、算出ウィンドウサイズkwndが空き受信バッファサイズbuffszよりも小さい場合に、算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する受信ウィンドウサイズ決定手段と、
受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACKを生成し、端末へ送信する確認応答生成手段と
を有し、
端末が、確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とする。
【００１５】
本発明によれば、複数の端末が１つのサーバに対してＴＣＰのコネクションを確立している際に、端末からのデータの送信レートを制御するサーバに搭載されたコンピュータを機能させるプログラムにおいて、
各端末からのコネクション確立時に、当該サーバの使用可能なメモリ量に応じて、コネクション当たりの最大受信バッファサイズmax-buffszを設定し、
回線帯域幅BandWidthと、接続中のコネクション数NumConncetionsとを測定する負荷状態測定手段と、
回線帯域幅BandWidthを、接続中のコネクション数NumConncetionsで除算したレートRateを算出し、レートRateに基づいて算出ウィンドウサイズkwnd（＝Rate×RTT、RTT：転送遅延時間）を算出するウィンドウサイズ算出手段と、
端末からデータを受信することによって最大受信バッファサイズmax-buffsz以下となる空き受信バッファサイズbuffszを計測し、算出ウィンドウサイズkwndが空き受信バッファサイズbuffszよりも小さい場合に、算出ウィンドウサイズkwndを受信ウィンドウサイズrwndとして決定する受信ウィンドウサイズ決定手段と、
受信ウィンドウサイズrwndをＴＣＰヘッダに含めた確認応答ACKを生成し、端末へ送信する確認応答生成手段と
してコンピュータを機能させ、
端末が、確認応答ACKに含まれる受信ウィンドウサイズに応じて、データの送信レートを制御することによって、各端末における当該サーバのリソース利用の公平性を確保することを特徴とする。
【発明の効果】
【００１８】
本発明におけるレート制御方法、サーバ及びプログラムによれば、膨大な数の端末と通信するサーバに、大量のトラヒックが集中することによる輻輳負荷状態をできる限り低減し、端末間のリソース利用の公平性を確保することができる。
【発明を実施するための最良の形態】
【００１９】
以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。
【００２０】
最初に、ウィンドウ制御を用いた、ＴＣＰのフロー制御について簡単に説明する。ウィンドウ制御によれば、ウィンドウサイズ（バイト数）だけのデータを、受信装置からの確認応答ＡＣＫを受信することなく連続的に送信することができる。送信装置は、受信装置から確認応答ＡＣＫを受信することにより、受信が確認された分だけ、ウィンドウをスライドさせる（スライディングウィンドウサイズ）。
【００２１】
ＴＣＰにおけるデータ送信には、「受信ウィンドウサイズrwnd(Receive Windows Size)」と「輻輳ウィンドウサイズcwnd(Congestion Windows Size)」との２つのウィンドウを用いる。
【００２２】
「受信ウィンドウサイズ」rwndは、受信装置が、確認応答ＡＣＫによって送信装置へ送信するものであり、受信装置の空き受信バッファサイズbuffszを表す。受信装置の空き受信バッファサイズbuffszが少なくなると、受信装置は、送信装置へ送信する受信ウィンドウサイズrwndを小さくする。本発明によれば、確認応答ＡＣＫに含まれる受信ウィンドウサイズrwndは、空き受信バッファサイズbuffszに対して更に輻輳負荷状態を反映したものとなる。
【００２３】
「輻輳ウィンドウサイズ」cwndは、送信装置によって決定されるものであり、受信装置へ送信するものではない。輻輳ウィンドウサイズは、確認応答ＡＣＫの受信状況に基づいて制御されるものであり、ＴＣＰのバージョンによって様々な計算方法で算出される。
【００２４】
実際に確認応答なしに送信できるデータサイズは、確認応答ＡＣＫによって受信した「受信ウィンドウサイズ」と、算出された「輻輳ウィンドウサイズ」とを比較して、小さい方のデータサイズとなる。
【００２５】
また、ＴＣＰにおけるデータ受信には、コネクション確立時には、コネクション当たりの最大受信バッファサイズmax-buffszが設定される。最大受信バッファサイズmax-buffszは、サーバが使用可能なメモリ量などに応じて、事前に設定される固定値である。また、最大受信バッファサイズmax-buffszは、コネクション確立後、コネクションが確立している間に変更されることはない。従って、空き受信バッファサイズbuffszは、最大受信バッファサイズmax-buffszを越えることはない。即ち、確認応答ＡＣＫのヘッダに含まれる受信ウィンドウサイズrwndは、最大受信バッファサイズbuffszを越えることはない。
【００２６】
図１は、本発明におけるシステム構成図である。
【００２７】
サーバ１は、インターネット３を介して確立されたＴＣＰコネクションを用いて、複数の端末２とデータを送受信する。
【００２８】
最初に、サーバ１の機能構成について説明する。サーバ１は、コンテンツ蓄積部１００と、レート制御可能なデータ送信部１１１と、データ受信部１２１と、輻輳負荷状態測定部１０１と、ウィンドウサイズ算出部１０２と、輻輳ウィンドウサイズ導出部１１２と、第１送信ウィンドウサイズ決定部１１３と、第２送信ウィンドウサイズ決定部１１４と、確認応答生成部１２２と、受信ウィンドウサイズ決定部１２３とを有する。これら機能部は、サーバに搭載されたコンピュータを機能させるプログラムを実行することによっても実現できる。
【００２９】
コンテンツ蓄積部１００は、コンテンツデータを蓄積する。データ受信部１２１から通知された要求に応じて、コンテンツデータをデータ送信部１１１へ通知する。
【００３０】
データ送信部１１１は、端末２へデータを送信し、それに対して確認応答ＡＣＫを受信する。尚、データ送信部１１１は、確認応答ＡＣＫを受信すると、その中から受信ウィンドウサイズrwndを取得する。受信ウィンドウサイズrwndは、第２送信ウィンドウサイズ決定部１１４へ通知される。
【００３１】
データ受信部１２１は、端末２からデータを受信し、それに対して確認応答ＡＣＫを返信する。また、データ受信部１２１は、受信したデータをコンテンツ蓄積部１００へ通知すると共に、現在の空き受信バッファサイズbuffszを受信ウィンドウサイズ決定部１２３へ通知する。
【００３２】
輻輳負荷状態測定部１０１は、データ送信部１１１及びデータ受信部１２１を監視し、複数の端末２からのアクセスによる輻輳負荷状態を測定する。輻輳負荷状態は、回線帯域幅BandWidth[bit/s]を、接続中のコネクション数NumConncetionsで除算したレートRateである。
【００３３】
ウィンドウサイズ算出部１０２は、輻輳負荷状態に基づいて、以下の式によって算出ウィンドウサイズkwndを算出する。算出ウィンドウサイズkwndは、１本のコネクション当たりで使用可能なウィンドウサイズを表し、端末間のリソース利用の公平性を確保する。
kwnd[byte]＝Rate[bit/s]×RTT[s]／８
Rate[bit/s]＝BandWidth[bit/s]／NumConncetions
RTT：コネクション確立時又は確立後に観測した転送遅延値[second]
算出ウィンドウサイズkwndは、データ送信については第１送信ウィンドウサイズ決定部１１３へ通知され、データ受信については受信ウィンドウサイズ決定部１２３へ通知される。
【００３４】
受信ウィンドウサイズ決定部１２３は、ウィンドウサイズ算出部１０２から算出ウィンドウサイズkwndを受け取り、データ受信部１２１から空き受信バッファサイズbuffszを受け取る。そして、受信ウィンドウサイズ決定部１２３は、算出ウィンドウサイズkwndと空き受信バッファサイズbuffszとを比較し、小さい方のサイズを受信ウィンドウサイズrwndとして決定する。決定された受信ウィンドウサイズrwndは、確認応答生成部１２２へ通知される。
【００３５】
空き受信バッファサイズbuffszは、コネクション確立時に設定された最大受信バッファサイズmax-buffszを越えることはない。従って、受信ウィンドウサイズrwndも、最大受信バッファサイズmax-buffszを越えることはない。更に、本発明によれば、受信ウィンドウサイズrwndは、空き受信バッファサイズbuffszを越えることもない。即ち、本発明の特徴的機能は、算出ウィンドウサイズkwndが、空き受信バッファサイズbuffszよりも小さい場合にのみ有効となる。この場合にのみ、通常のＴＣＰにおける受信ウィンドウサイズrwndと、本発明における受信ウィンドウサイズrwnd（＝算出ウィンドウサイズkwnd）とが異なる。
【００３６】
確認応答生成部１２２は、確認応答ＡＣＫのＴＣＰヘッダに、受信ウィンドウサイズrwndを含める。生成された確認応答ＡＣＫは、データ受信部１２１へ通知され、端末２へ送信される。これにより、端末２は、受信した確認応答ＡＣＫにおけるＴＣＰヘッダの受信ウィンドウサイズrwndに応じて、サーバ１へのデータの送信レートが制御される。
【００３７】
図２は、ＴＣＰヘッダのフォーマットである。確認応答ＡＣＫのビットと、受信ウィンドウサイズrwndとが表されている。
【００３８】
輻輳ウィンドウサイズ導出部１１２は、ＴＣＰの輻輳ウィンドウサイズcwndを算出する。輻輳ウィンドウサイズcwndは、ＴＣＰのバージョンによって様々な計算方法で算出される。
【００３９】
第１送信ウィンドウサイズ決定部１１３は、ウィンドウサイズ算出部１０２から出力された算出ウィンドウサイズkwndと、輻輳ウィンドウサイズ導出部１１２から出力された輻輳ウィンドウサイズcwndとを比較する。そして、小さい方のサイズを第１送信ウィンドウサイズwnd1とする。決定された第１送信ウィンドウサイズwnd1は、第２送信ウィンドウサイズ決定部１１４へ通知される。
【００４０】
第２送信ウィンドウサイズ決定部１１４は、データ送信部１１１から通知された受信ウィンドウサイズrwndと、第１送信ウィンドウサイズwnd1とを比較する。そして、小さい方のサイズを第２送信ウィンドウサイズwnd2とする。決定された第２送信ウィンドウサイズwnd2は、データ送信部１１１へ通知される。データ送信部１１１は、第２送信ウィンドウサイズwnd2に応じて、データの送信レートを制御する。
【００４１】
次に、端末２の機能構成について説明する。端末２は、レート制御可能なデータ送信部２１と、データ受信部２２とを有する。これら機能部は、端末に搭載されたコンピュータを機能させるプログラムを実行することによっても実現できる。
【００４２】
データ送信部２１は、サーバ１へデータを送信し、それに対して確認応答ＡＣＫを受信する。尚、データ送信部２１は、確認応答ＡＣＫを受信すると、その中から受信ウィンドウサイズrwndを取得する。受信ウィンドウサイズrwndに応じて、データの送信レートが制御される。
【００４３】
データ受信部２２は、端末２からデータを受信し、それに対して確認応答ＡＣＫを返信する。尚、データ受信部２２は、輻輳負荷状態と空きバッファサイズに応じて算出した受信ウィンドウサイズrwndを、確認応答ＡＣＫのＴＣＰヘッダに含め、その確認応答ＡＣＫを送信する。
【００４４】
図３は、本発明におけるシーケンス図である。
【００４５】
最初に、端末２からサーバ１へ送信されるデータのレート制御について説明する。
【００４６】
（Ｓ３０１）端末２とサーバ１との間で、コネクションが確立される。ＴＣＰコネクションを確立する場合には、ＳＹＮの交換による３ウェイハンドシェイクがなされる。サーバ１は、このコネクション確立時及びその後、データの送受信に対して転送遅延値ＲＴＴを測定する。コネクション確立時の受信バッファは空であるために、空き受信バッファサイズbuffszは、必然的に最大受信バッファサイズmax-buffszとして決定される。図３によれば、例えば、サーバ１の最大受信ウィンドウサイズmax-buffszが５００Byteに決定されている。
【００４７】
（Ｓ３０２）端末２は、受信ウィンドウサイズ５００Byte以下となる４００Byteのデータを、シーケンス番号６００１を用いてサーバ１へ送信する。
（Ｓ３０３）サーバ１は、受信ウィンドウサイズ５００Byteのうち４００Byteを受信したので、残りの受信バッファサイズは１００Byteである。サーバ１は、シーケンス番号６４０１で且つ受信ウィンドウサイズrwnd＝１００Byteとなる確認応答ＡＣＫを端末２へ返信する。
（Ｓ３０４）端末２は、受信ウィンドウサイズ１００Byteのうち１００Byteのデータを、シーケンス番号６４０１を用いてサーバ１へ送信する。
（Ｓ３０５）サーバ１は、受信ウィンドウサイズ１００Byteのうち１００Byteを受信したので、残りの受信バッファサイズは０Byteである。サーバ１は、確認シーケンス番号６５０１で且つ受信ウィンドウサイズrwnd＝０Byteとなる確認応答ＡＣＫを端末２へ返信する。
【００４８】
ここで、サーバ１は、コネクション確立時よりも輻輳負荷状態が増加したとする。輻輳負荷状態の増加としては、例えば、サーバ１へ接続する端末数が増えた場合がある。
【００４９】
サーバ１は、輻輳負荷状態（回線帯域幅BandWidth[bit/s]、接続中のコネクション数NumConncetions）から、端末２に対する算出ウィンドウサイズkwndを算出する。例えば、算出ウィンドウサイズkwnd＝３００Byteとなったとする。また、サーバ１は、先に受信したデータに対する受信処理が全て終了しているとする。そうすると、ここで、算出ウィンドウサイズkwnd＝３００Byteと、最大受信バッファサイズmax-buffsz＝５００Byteとを比較し、小さい方の３００Byteが、受信ウィンドウサイズrwndとして更新される。
【００５０】
（Ｓ３０６）サーバ１は、確認シーケンス番号６５０１で且つ受信ウィンドウサイズrwnd＝３００Byteとなる確認応答ＡＣＫを端末２へ送信する。これにより、端末２は、再び、サーバ１に対してデータを送信する。
【００５１】
次に、サーバ１から端末２へ送信されるデータのレート制御について説明する。
【００５２】
（Ｓ３１１）サーバ１は、データを端末２へ送信する。このとき、サーバ１は、輻輳負荷状態（回線帯域幅BandWidth[bit/s]、接続中のコネクション数NumConncetions）から、端末２に対する算出ウィンドウサイズkwndを算出する。一方で、サーバ１は、輻輳ウィンドウサイズcwndを導出する。
【００５３】
図４は、輻輳ウィンドウサイズcwndの一般的な決定方法のグラフである。
【００５４】
輻輳ウィンドウサイズは、初期値１Byteからスロースタートさせ、閾値（輻輳ａ）以下のときは指数関数的に、輻輳ウィンドウサイズcwndを増加させる。ここで、確認応答ＡＣＫを受信しなくても送信できる最大の輻輳ウィンドウサイズcwndは、輻輳ａである。輻輳ａに達し、その後、再送制御によって受信が確認され、輻輳が回避されると、再びスロースタートさせ、輻輳ウィンドウサイズcwndを指数関数的に増加させていく。そして、輻輳ａ／２に達すると、輻輳ウィンドウサイズcwndは、線形的に増加させていく。線形増加における最大の輻輳ウィンドウサイズcwndは、輻輳ｂ（＜輻輳ａ）となる。このとき、輻輳回避しても、輻輳ウィンドウサイズcwndは、輻輳ｂ／２までにしか減少しない。その後、再び、線形増加によって増加する。
【００５５】
図３のＳ３１１に戻って、算出ウィンドウサイズkwndと、輻輳ウィンドウサイズcwndとを比較し小さい方のサイズを、第１送信ウィンドウサイズwnd1とする。
【００５６】
（Ｓ３１２）サーバ１は、端末２から、シーケンス番号６４０１及び受信ウィンドウサイズrwnd＝１００となる確認応答ＡＣＫを受信する。ここで、サーバ１は、受信ウィンドウサイズrwndと、第１送信ウィンドウサイズwnd1とを比較し、小さい方のサイズを、第２送信ウィンドウサイズwnd2とする。
【００５７】
（Ｓ３１３）サーバ１は、第２送信ウィンドウサイズwnd2に応じて、送信レートを制御する。
【００５８】
以上、詳細に説明したように、本発明におけるレート制御方法、サーバ及びプログラムによれば、膨大な数の端末と通信するサーバに、大量のトラヒックが集中することによる輻輳負荷状態をできる限り低減し、端末間のリソース利用の公平性を確保することができる。
【００５９】
本発明のシステムは、特に、視聴者参加型放送番組が放送されるような通信放送連携システムに有効に作用する。放送番組の内容によっては、視聴者が操作する端末から、ある時間帯に、特定のサーバへ集中してアクセスされる場合がある。このような場合に、本発明を適用することによって、端末側のレート制御が有効に働き、サーバの輻輳負荷状態が回避される。
【００６０】
前述した本発明における種々の実施形態によれば、当業者は、本発明の技術思想及び見地の範囲における種々の変更、修正及び省略を容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【図面の簡単な説明】
【００６１】
【図１】本発明におけるシステム構成図である。
【図２】ＴＣＰヘッダのフォーマットである。
【図３】本発明におけるシーケンス図である。
【図４】輻輳ウィンドウサイズcwndの一般的な決定方法のグラフである。
【符号の説明】
【００６２】
１  サーバ
１００  コンテンツ蓄積部
１０１  輻輳負荷状態測定部
１０２  ウィンドウサイズ算出部
１１１  データ送信部
１１２  輻輳ウィンドウサイズ導出部
１１３  第１送信ウィンドウサイズ決定部
１１４  第２送信ウィンドウサイズ決定部
１２１  データ受信部
１２２  確認応答生成部
１２３  受信ウィンドウサイズ決定部
２  端末
２１  データ送信部
２２  データ受信部
３  インターネット
【図１】
0004627290.tif 000002
【図２】
0004627290.tif 000003
【図３】
0004627290.tif 000004
【図４】
0004627290.tif 000005