(57)【要約】      （修正有）【課題】サーバ装置とクライアント装置間の通信路で高い伝送レートを維持するサーバ装置を提供する。【解決手段】ネットワーク３を介しクライアント装置２と接続しデータ通信を行うサーバ装置１は、クライアント装置２へデータを送信する複数の通信路と、複数の通信路の所定の通信路にクライアント装置２へ送信するデータを振り分ける振分部１０３ａ、１０３ｂと、通信路で送信するデータの送信レートを検出する検出部１０５ａ、１０５ｂと、検出部で検出した送信レートに基づいて、振分部で振り分けたデータを送信する所定の通信路から、所定の通信路以外の通信路へ通信路を切り替えることを指示する指示部１０４ａ、１０４bとを備える。【選択図】図１
2014078895.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介しクライアント装置と接続しデータ通信を行うサーバ装置であって、
前記クライアント装置へデータを送信する複数の通信路と、
前記通信路の所定の通信路に前記クライアント装置へ送信するデータを振り分ける振分部と、
前記通信路で送信するデータの送信レートを検出する検出部と、
前記検出部で検出した送信レートに基づいて、前記振分部で振り分けた前記データを送信する所定の通信路から、所定の通信路以外の通信路へ通信路を切り替えることを指示する指示部と、
を具備することを特徴とするサーバ装置。
【請求項２】
前記指示部は、前記検出部で検出した送信レートが所定の閾値よりも下回ることにより前記所定の通信路から、所定の通信路以外の通信路のいずれかへ切り替えるよう指示することを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記検出部は、前記通信路の送信レートが任意の閾値よりも下回ることにより送信レートの低下を検出することを特徴とする請求項１記載のサーバ装置。
【請求項４】
前記検出部は、前記通信路の送信レートの減少幅が閾値を上回ることにより送信レートの低下を検出することを特徴とする請求項１記載のサーバ装置。
【請求項５】
前記検出部は、前記通信路の輻輳ウィンドウの値が閾値を下回ることにより送信レートの低下を検出することを特徴とする請求項１記載のサーバ装置。
【請求項６】
前記検出部は、前記通信路の輻輳ウィンドウの減少幅が閾値を上回ることにより送信レートの低下を検出することを特徴とする請求項１記載のサーバ装置。
【請求項７】
前記指示部は、前記通信路のうち輻輳ウィンドウの値が最も高いものを切替先とすることを特徴とする請求項１記載のサーバ装置。
【請求項８】
前記クライアント装置との間でＴＣＰ／ＩＰ接続の確立を行い、
前記所定の通信路以外の通信路でデータ送信を行うことで輻輳ウィンドウの値を増加させることを特徴とする請求項１記載のサーバ装置。
【請求項９】
前記複数の通信路を組に束ねる複数の送信部を有し、各送信部における前記通信路の数を管理部により管理することを特徴とする請求項１記載のサーバ装置。
【請求項１０】
前記管理部は、前記通信路の送信レートの総和に基づき前記通信路の数を増減することを特徴とする請求項９記載のサーバ装置。
【請求項１１】
前記管理部は、前記各送信部における通信路の送信レートに基づき前記通信路の個数を増減することを特徴とする請求項９記載のサーバ装置。
【請求項１２】
前記管理部は、前記クライアント装置の平均個数に基づき前記通信路の個数を増減することを特徴とする請求項９記載のサーバ装置。
【請求項１３】
前記クライアント装置との間でＴＣＰ／ＩＰ接続の確立を行うものであり、前記管理部は、ＴＣＰ接続を維持する時間に基づき前記通信路の個数を増減することを特徴とする請求項９記載のサーバ装置。
【請求項１４】
前記クライアント装置との間でＴＣＰ／ＩＰ接続の確立を行うものであり、前記管理部は、接続か切断までに受け付けるリクエスト数に基づき前記通信路の個数を増減することを特徴とする請求項９記載のサーバ装置。
【請求項１５】
ネットワークを介しクライアント装置とサーバ装置が接続しデータ通信を行う通信システムであって、
前記サーバ装置は、
前記クライアント装置へデータを送信する複数の通信路と、
前記通信路の所定の通信路に前記クライアント装置へ送信するデータを振り分ける振分部と、
前記通信路で送信するデータの送信レートを検出する検出部と、
前記検出部で検出した送信レートに基づいて、前記振分部で振り分けた前記データを送信する所定の通信路から、所定の通信路以外の通信路へ通信路を切り替えることを指示する指示部と、を具備し、
前記クライアント装置は、
前記サーバ装置から前記複数の通信路を通してデータを受信する受信部と、
前記受信部で受け取ったデータを集約する集約部と、
を具備することを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、クライアント装置と接続しデータの通信を行うサーバ装置及び通信システムに関する。
【背景技術】
【０００２】
ネットワークを介して接続されたサーバ装置とクライアント装置との間でデータの送受信を行う情報通信システム。サーバ装置とクライアント装置はコネクション型の伝送方式を用いて情報の送受信を行う。
【０００３】
代表的な伝送方式にはＴＣＰ／ＩＰを用いるものがある。ＴＣＰ／ＩＰを用いる場合、送信側はＴＣＰストリームを受信側との間で確立し、シーケンス番号やウィンドウサイズ等を含むＴＣＰヘッダをデータに付加しパケット化して受信側へ送出する。これにより、データ到着の信頼性と順序性が保証された転送が可能となる。またＴＣＰは、ネットワークが輻輳状態に陥るのを防止するため、ネットワークに送出するデータレートを制御する輻輳制御の機構を備える。
【０００４】
さらに、複数のＴＣＰストリームを用いる伝送方式が存在する。この伝送方式では、送信側は複数のＴＣＰストリームを受信側との間で確立する。送信側はデータを任意サイズに分割し、分割順序を表すヘッダを付加した上で複数のＴＣＰストリームへ渡し、並列的にデータ送出を行う。複数のＴＣＰストリームを用いると、特に広帯域高遅延の特徴を持つネットワークにおいて、データの伝送レートを向上することが可能である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平０９−３２６８１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
さて、ＴＣＰストリームによるデータ伝送では、ＴＣＰの輻輳制御の動作により、伝送レートが一時的に低下する現象が存在する。伝送中のデータにパケットロスが生じたことを検出すると、送信側は輻輳ウィンドウの値（受信側からの確認応答無しに連続送信できる最大のパケットの個数）を大幅に縮小し、ネットワークに送出するデータ量を抑制する。この動作により伝送レートが低下する。
【０００７】
特に、多くの中継装置を経由する広域ネットワーク環境や、信号減衰等の影響を受ける無線ネットワーク環境では、一般にパケットロスが生じる確率（パケットロス率）が高い。このため、ＴＣＰストリームの伝送レートが一時的に低くなる現象が頻繁に発生する。
【０００８】
このような現象は、例えばファイル転送を行う場合では、転送の所要時間に遅れをもたらす。また、リアルタイム映像の配信を行う場合では、瞬間的な再生の詰まり等を生じることとなり、好ましくない。
【０００９】
そこで本発明が解決する課題は、サーバ装置とクライアント装置の間で通信路の伝送レートの高い状態を維持することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明の実施形態に係るサーバ装置は、ネットワークを介しクライアント装置と接続しデータ通信を行うサーバ装置であって、前記クライアント装置へデータを送信する複数の通信路と、前記通信路の所定の通信路に前記クライアント装置へ送信するデータを振り分ける振分部と、前記通信路で送信するデータの送信レートを検出する検出部と、前記検出部で検出した送信レートに基づいて、前記振分部で振り分けた前記データを送信する所定の通信路から、所定の通信路以外の通信路へ通信路を切り替えることを指示する指示部とを備えるサーバ装置を提供する。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態に係る通信システムの構成例を示す図。
【図２】第１の実施形態に係る通信システムにおけるストリーム作成の例を示す図。
【図３】第１の実施形態に係るストリームとその状態との対応表を表す図。
【図４】第１の実施形態に係るデータの分割情報の例を表す。
【図５】第１の実施形態に係るストリーム切り替えの処理の流れを示すフローチャート。
【図６】第１の実施形態に係る検出部が取得する情報の例を表す図。
【図７】第１の実施形態に係るストリーム切り替え後の状態を示す図。
【図８】第２の実施形態に係るストリームの状態を示す図。
【図９】第２の実施形態に係るストリームの状態を示す図。
【図１０】第３の実施形態に係る通信システムの構成例を示す図。
【発明を実施するための形態】
【００１２】
（第１の実施形態）
以下、第１の実施形態に係るサーバ装置を図面を参照して実施例を説明する。
【００１３】
図１は、本発明の実施形態としてのシステムの構成を示す。本構成は、サーバとして機能する情報処理端末（サーバ装置１）と、クライアントとして機能する情報処理端末（クライアント装置２）とが、ネットワーク３を介して接続されている。両者はＨＴＴＰによるデータ送受信を行う。
【００１４】
サーバ装置１は、その構成要素として、ＨＴＴＰサーバアプリケーション１０１と、送信部１０２を含む。さらに送信部１０２は振分部１０３と、指示部１０４と、検出部１０５とを含む。
【００１５】
ＨＴＴＰサーバアプリケーション１０１は、クライアント装置２からのＨＴＴＰリクエストに応じて、要求されたコンテンツをＨＴＴＰレスポンスとしてクライアント装置２へ送出する。
【００１６】
送信部１０２は、ＨＴＴＰサーバアプリケーション１０１が提供するコンテンツをデータストリームとして受け取り、ＴＣＰストリームを用いてクライアント装置２の受信部２０１へ送信する。
【００１７】
振分部１０３は、ＨＴＴＰサーバアプリケーション１０１から受け取ったデータストリームを、ＴＣＰストリームのいずれかへと振り分ける。
【００１８】
指示部１０４は、振分部１０３がデータストリームを振り分ける先を、輻輳ウィンドウの値の低下したＴＣＰストリームから、高い状態にあるＴＣＰストリームへと切り替えるよう指示する。
【００１９】
検出部１０５は、送信部１０２が有するＴＣＰストリームのいずれかの輻輳ウィンドウの値が低下したことを検出する。
【００２０】
クライアント装置２は、その構成要素として、受信部２０１と、ＨＴＴＰクライアントアプリケーション２０３を含む。さらに受信部２０１は集約部２０２を含む。
【００２１】
受信部２０１は、ＴＣＰストリームを用いてサーバ装置１の送信部１０２からデータストリームを受信し、ＨＴＴＰクライアントアプリケーション２０３へ提供する。
【００２２】
集約部２０２は、複数のＴＣＰストリームを用いて受信したデータストリームを単一のデータストリームへと集約する。
【００２３】
ＨＴＴＰクライアントアプリケーション２０３は、サーバ装置１に対してＨＴＴＰリクエストを送出してコンテンツを要求し、ＨＴＴＰレスポンスにより受信したコンテンツを任意の方法で利用する。例えばＨＴＴＰクライアントアプリケーション２０３はブラウザアプリケーションである。
【００２４】
次に、本実施形態に係る情報通信システムにより行われる処理について、図面を適宜参照しながら説明する。
【００２５】
始めに、クライアント装置２からサーバ装置１に対しＨＴＴＰによるコンテンツの取得要求を行う。サーバ装置１においてＨＴＴＰサーバアプリケーション１０１が起動すると、ＨＴＴＰサーバアプリケーション１０１はＨＴＴＰ用のポートをオープンしＴＣＰ接続の待受け状態に入る。次に、クライアント装置２は、例えばユーザからのＵＲＬ入力等の動作を契機として、サーバ装置１との間で３ウェイハンドシェイクによるＴＣＰ接続の確立を行う。これにより両者間でＴＣＰストリームが作成される。ＴＣＰ接続の確立に伴い、サーバ装置１とクライアント装置２はそれぞれ接続に相当する送信部１０２と受信部２０１を作成する。さらに送信部１０２と受信部２０１は、両者の間で、同様のＴＣＰ接続の確立を複数回実施し、複数個のＴＣＰストリームを作成する。図２では、送信部１０２と受信部２０１の間で８個のＴＣＰストリーム１００１〜１００８が作成される様子が例示されている。
【００２６】
ＨＴＴＰクライアントアプリケーション２０３は、ユーザから指定されたコンテンツのＵＲＬを含むＨＴＴＰリクエストを作成し、ＨＴＴＰサーバアプリケーション１０１に向けて送信する。送信はＴＣＰストリーム１００１〜１００８のいずれかを用いて行われる。ＨＴＴＰリクエストを受信すると、ＨＴＴＰサーバアプリケーション１０１は、要求されたコンテンツを含むＨＴＴＰレスポンスを作成し、データストリームとして送信部１０２に渡す。当該のデータは始めに振分部１０３に渡される。振分部１０３は入力されたデータを各ＴＣＰストリーム１００１〜１００８に振り分ける。振分部１０３は内部に、各ＴＣＰストリームとその状態との対応表を有する。対応表の例を図３に示す。
【００２７】
対応表では、ＴＣＰストリームの識別子（ＩＤ）と状態との対応が記憶されている。各ＴＣＰストリームの状態は「使用中」と「待機中」の二種類である。初期化直後の状態の決定の仕方は任意である。本実施例では、ＩＤ＝１〜４のストリームの初期状態を「使用中」、ＩＤ＝５〜８のストリームの初期状態を「待機中」としている。振分部１０３は、入力されたデータを、状態が「使用中」であるＴＣＰストリームのみに対して振り分ける。振分部１０３は、データを規定のサイズ（８ＫＢ等）に分割する。振分部１０３は、各々の分割されたデータを分割し、分割順序を表す分割情報を付与する。
【００２８】
分割情報の例を図４に示す。図４では、データが４分割され、それぞれに１から４までの通し番号と分割数からなる分割情報が付加されている。分割後のデータは任意の方法で複数のＴＣＰストリームに振り分けされる。図３の例では、「使用中」のＴＣＰストリームはＩＤ＝１〜４の４個である。図４のように４個の分割されたデータは、それぞれＴＣＰストリームに１個ずつ振り分けられる。ＴＣＰストリームでは、入力の分割されたデータに対しＴＣＰ／ＩＰのヘッダが付与されて、並列的にそれぞれ集約部２０２に向けて送信される。
【００２９】
受信後のデータはそれぞれのＴＣＰストリームから集約部２０２へ渡される。単一のＴＣＰストリームにおいて送信されたデータはその順序性が保証されるが、複数のＴＣＰストリームに分けられた場合、個々のストリーム内での順序性は保証されても、ストリーム間の順序性は保証されない。そこで、集約部２０２は、分割情報を参照し、順序が元の順序に正しくなるよう並び替えを行い、さらに分割情報を除去し、元のデータストリームを再構成する。以上のようにして得られたデータを、集約部２０２はＨＴＴＰクライアントアプリケーション２０３へ出力する。ＨＴＴＰクライアントアプリケーション２０３は、得られたコンテンツのデータを任意の方法で利用する。
【００３０】
なお、本実施例では、ＨＴＴＰサーバアプリケーション１０１から提供されたデータを４個のＴＣＰストリームを用いて並列的に伝送する場合について述べているが、必ずしも並列伝送を行う必要はない。状態が「使用中」であるＴＣＰストリームの個数を１個に限っておいてもよい。この場合、上述した分割情報の付与の手続きは省略して構わない。
【００３１】
以上、クライアント装置２からサーバ装置１へＨＴＴＰによるコンテンツの取得要求を行ってから取得が完了するまでの処理の流れについて説明した。
【００３２】
次に、検出部１０５が、使用中のＴＣＰストリームの一部で輻輳ウィンドウの値（ＣＷＮＤ）が低下したことを検出したことにもとづき、当該のＴＣＰストリームを別の待機中のＴＣＰストリームに切り替える際の処理の流れを図５を用いて説明する。
【００３３】
検出部１０５は、定期的なタイミング（１秒ごと等）で、ＴＣＰストリーム１００１〜１００８のそれぞれのＣＷＮＤの値を取得する（ステップＳ１１０１）。ＣＷＮＤの値の取得は、例えばＯＳが提供するＡＰＩの利用などを通じて行われる。また検出部１０５は振分部１０３に問い合わせをして、各ＴＣＰストリームのＩＤと状態を取得する（ステップＳ１１０２）。検出部１０５が取得する情報の例を図６に示す。
【００３４】
次に検出部１０５は、ＣＷＮＤの値と閾値（例えば２０パケット）との比較を行い、ＣＷＮＤが閾値を下回り、かつ状態が「使用中」であるストリームを特定する（ステップＳ１１０３）。もしそのようなストリームが存在していなければ、１秒待機した後で再びステップＳ１１０１からの処理を行う（ステップＳ１１０４）。もし存在していれば、図６の情報を指示部１０４に渡し、ストリームの切り替え指示を行うよう依頼する。
【００３５】
指示部１０４は、入力を受け取ると、ＴＣＰストリーム１００１〜１００８のうち、ＣＷＮＤが最小となる使用中のストリームを選択する（ステップＳ１１０５）。図６の例では、ＩＤ＝２のストリームに相当する。なお、選択するストリームは必ずしもＣＷＮＤが最小となるストリームを選択しなくともよいが、最小に近いストリームであれば効率的である。
【００３６】
また指示部１０４は同様にＣＷＮＤが最大となる待機中のストリームを選択する（ステップＳ１１０６）。なお、選択するストリームは必ずしもＣＷＮＤが最大となるストリームを選択しなくともよいが、最大に近いストリームであれば効率的である。
【００３７】
図６の例では、ＩＤ＝７のストリームに相当する。以上の選択を行うと、指示部１０４は、振分部１０３に対し、前者のＩＤ（２）を切り替え元、後者のＩＤ（７）を切り替え先として、両方のＩＤを通知し、振分先のストリームを切り替えるよう依頼する。
【００３８】
振分部１０３は、入力を受け取ると、指定された切り替え元のストリームの状態を「使用中」から「待機中」へ切り替え、また切り替え先のストリームの状態を「待機中」から「使用中」へ切り替える（ステップＳ１１０７）。切り替え後の各ストリームの状態を図７に示す。
【００３９】
ＣＷＮＤの低下を検出したときの処理の流れを説明した。
【００４０】
以後、ＨＴＴＰサーバアプリケーション１０１から提供されるデータストリームは、振分部１０３において、ＩＤ＝１，３，４，７に対応するＴＣＰストリームに対して振り分けられる。
【００４１】
以上述べた方法により、輻輳ウィンドウの値が低下し、十分な伝送レートが得られなくなったＴＣＰストリームを、待機中の輻輳ウィンドウの値の高いＴＣＰストリームに適宜切り替えて伝送を行うことが可能となる。これにより、伝送レートが低い状態に陥ることを回避できるようになる。
【００４２】
なお、本実施例では、検出部１０５は、輻輳ウィンドウの値が閾値を下回ったことを契機としてストリームの切り替えを開始していたが、必ずしもこれに限らなくともよい。当該のＴＣＰストリームにおける伝送レートを見積もることができる任意の方法を用いることができる。以下、他の例を示す。
【００４３】
検出部１０５は、状態が使用中であるストリームのＣＷＮＤの平均値を算出し、あるストリームのＣＷＮＤと平均値との差が規定の閾値を超えて減少したことをもってストリームの切り替え開始の契機としてよい。この方法でも上記と同様に伝送レートの低下を検出することができる。
【００４４】
あるいは、検出部１０５は、各ＴＣＰストリーム１００１〜１００８の輻輳ウィンドウの前回取得時の値を記憶し、今回取得した値との差を計算することにより輻輳ウィンドウの変動幅を得ることができる。検出部１０５は、この変動幅が規定の閾値を超えて減少したことをもってストリームの切り替え開始の契機としてよい。このように輻輳ウィンドウの値の急変によっても伝送レートの低下を検出することができる。
【００４５】
あるいは、検出部１０５は、各ＴＣＰストリーム１００１〜１００８の直近の規定時間における伝送レートの値を取得し、これを利用することでストリームの切り替えの開始を判断してもよい。
【００４６】
この場合、検出部１０５は、例えばＯＳ提供のＡＰＩを通じて、各ストリームの累積の送信データ量を取得し、前回取得時の送信データ量との差をとり、さらにこれを前回取得時からの経過時間で割ることにより、この期間の伝送レートの値を算出することができる。この値が規定の閾値を下回っていたことをもってストリームの切り替えの開始の契機としてよい。あるいは、前回の伝送レートの値との差をとることで変動幅を得て、この変動幅が規定の閾値を超えて減少したことをもってストリームの切り替え開始の契機としても良い。
【００４７】
あるいは、検出部１０５は、各ＴＣＰストリームで行われた再送の回数を取得し、これを利用してストリームの切り替えの開始を判断しても良い。この場合、検出部１０５は、例えばＯＳ提供のＡＰＩを通じて、各ストリームで行われた再送の回数を取得する。前回取得時の値との差をとることにより、再送の回数の増加分を知ることができる。この増加分が規定の閾値を上回っていたことをもってストリームの切り替えの開始の契機としてよい。
【００４８】
また、以上の例は検出部１０５が定期的なタイミングでＴＣＰストリーム１００１〜１００８に関する各種パラメータの値を取得するというものであったが、これに限る必要はない。以上の検出に相当する事象が発生したタイミングでそのことを通知可能な機構がＯＳにおいて利用可能である場合にはこれを利用しても良い。
【００４９】
以上、検出部１０５の検出のバリエーションを説明した。
【００５０】
以上述べた方法により、送信部１０２は、使用中のＴＣＰストリームの輻輳ウィンドウが低下し十分な伝送レートが得られなくなったときに、輻輳ウィンドウの値の高い他のストリームを使用するよう切り替えを行うことができるようになるため、伝送レートの高い状態を維持することが可能となる。予備としてのストリームを既に接続確立が完了した状態で待機させておくため、切り替えの際に一時的に通信不可状態に陥ることを回避することが可能となる。
【００５１】
また、本実施例のようにＴＣＰストリームを複数用いて並列的にデータ伝送を行う場合においては、ネットワークの帯域幅や往復遅延時間、パケットロス率などの値に応じて、データ伝送で使用するＴＣＰストリームの並列の数（状態が「使用中」であるストリームの数：並列数）の最適値が存在する場合がある。最適値より並列数が小さければ、十分な伝送レートが得られない。最適値より並列数が大きければ、パケットロスの頻度が高くなり、帯域の利用効率が悪くなるほか、受信側において順序性の確保のための待ち合わせの時間が増加することにより、クライアントアプリケーションにデータが供給されるレートに短時間的な変動が大きくなるという弊害が生じる。本実施例によれば、並列数は一定の状態を維持できるため、そのような伝送レートの変動を回避できるという利点がある。
【００５２】
（第２の実施形態）
本発明の第２の実施例を説明する。第１の実施例では、振分部１０３は、状態が「使用中」でないＴＣＰストリームにはデータを振り分けないとしていたが、必ずしもこれに限らなくともよい。特に輻輳ウィンドウが小さな値となる非使用中のストリームに対して、データの一部分を振り分けることにより、当該のストリームの輻輳ウィンドウの値を増加させ、以降の切り替えの際に備えることができる。
【００５３】
第２の実施例は、第１の実施例とほぼ同じ動作をするが、第１の実施例では、ＴＣＰストリーム１００１〜１００８の状態を「使用中」「待機中」の２状態としていたのに対して、第２の実施例では、さらにこれらに加えて、「調整中」という状態を持つ。以下、第１の実施例との差分を説明する。
【００５４】
第１の実施例では、振分部１０３は、指示部１０４からストリームの切り替えの依頼を受けると、切り替え元と切り替え先のストリームの状態をそれぞれ「待機中」と「使用中」へ切り替えていた。第２の実施例では、切り替え元のストリームの状態を「調整中」へと切り替え、切り替え先のストリームの状態を「使用中」へと切り替える。つまり、輻輳ウィンドウの値が低下したと判断されたストリームを「調整中」の状態へと変更する。調整中となったストリームは、以後、振分部１０３からデータの一部分のみが振り分けられ、これを伝送することで輻輳ウィンドウの値を増加させる。輻輳ウィンドウが規定の閾値以上となった時点で状態は「調整中」から「待機中」へとさらに更新され、以降の切り替えに備える。
【００５５】
例えば、第１の実施例では、図５のステップＳ１１０７の処理の結果、各ストリームの状態が図７のような状態に変更されると説明した。第２の実施例では、代わりに、各ストリームの状態が図９のような状態に変更される。
【００５６】
振分部１０３は、ＨＴＴＰサーバアプリケーション１０１から入力されたデータを、状態が「使用中」となるストリームを用いて並列的に送信するほか、データの少量の一部分を、状態が「調整中」となるストリームを用いて同様に送信する。例えば、調整中のストリームに渡されるデータのレートが既定の閾値（１０キロバイト／秒など）を超えない範囲でデータを渡す。あるいは、ストリーム１００１〜１００８の全体で送信されるレートのうち規定の割合を超えない範囲でデータを渡す。調整中のストリームでは、クライアント装置２からの確認応答を受けるごとに輻輳ウィンドウの値が増加する。このように、調整中のストリームを用いて少量のデータ送信を行わせることにより、輻輳ウィンドウの値を低い状態から高い状態へと増加させる。
【００５７】
なお、上記ではＨＴＴＰサーバアプリケーション１０１から入力されたデータの一部を調整中のストリームに渡すとしていたが、必ずしもこれに限る必要は無い。振分部１０３はダミーのデータを作成して調整中のストリームに渡しても良い。クライアント装置２の受信部２０１は受信したダミーデータをそのまま破棄する。このような方法によっても、当該の調整中のストリームの輻輳ウィンドウの値を増加させることができる。
【００５８】
輻輳ウィンドウの値が規定の閾値を超えた場合、調整中のストリームの状態は「待機中」へと移行する。検出部１０５は、調整中のストリームの輻輳ウィンドウの値を定期的に取得し、値が規定の閾値（２０パケットなど）を超えたことを検出したときに、当該のストリームのＩＤを指示部１０４に通知する。指示部１０４は、これを受けて、当該のストリームの調整処理を終了することを振分部１０３に通知する。振分部１０３は、これを受けて、当該のストリームに対する状態を「調整中」から「待機中」に変更する。例えば検出部１０５が検出した輻輳ウィンドウが図８のような値であった場合、ＩＤ＝２のストリームの状態が「待機中」へと更新される。
【００５９】
以上述べたように、第２の実施例では、待機状態にあるストリームの輻輳ウィンドウの値を常に規定の閾値以上となる状態で保持するため、送信部１０２は、輻輳ウィンドウの値が低下したストリームを高いストリームに切り替えるという動作を継続的に行うことが可能となる。
【００６０】
（第３の実施形態）
図１０を参照しながら本発明の第３の実施例を説明する。
【００６１】
第１および第２の実施例では、サーバ装置１は単一の送信部１０２を保持する場合について述べた。第３の実施例では、サーバ装置１は、複数の送信部１０２を保持し、複数のクライアント装置２からの接続を同時に受け付けることができる場合を説明する。
【００６２】
図１０における本実施例のサーバ装置１は、第１または第２の実施例で述べた送信部１０２を複数個保持する（送信部１０２ａ、送信部１０２ｂとする）。さらに、それぞれの送信部１０２が有するＴＣＰストリームの個数を管理する管理部１０６を有する。管理部１０６は、送信部１０２が有するＴＣＰストリームの個数を監視し、その総数が規定の閾値を超えた場合に、使用するＴＣＰストリームの個数を減らすよう、各送信部１０２に依頼を出す役割を持つ。
【００６３】
管理部１０６は、定期的なタイミングで、各送信部１０２に対し、現在「使用中」の状態にあるストリームの数（並列数）の取得要求を出す。並列数を得ると、管理部１０６は、その総和が規定の上限値を超えるかを調べる。超えている場合、管理部１０６は、いずれかの送信部１０２に対して、総和が上限値以下に収まるよう、並列数の変更を指示する。これを受けて、送信部１０２は、振分部１０３が保持する各ストリームと状態との対応表において、「使用中」であるストリームの数が、指定された並列数に等しくなるよう、いくつかのストリームに対する状態を「待機中」へと変更する。以後、残りの「使用中」の状態のストリームによりデータ伝送が継続される。
【００６４】
具体例を示す。いま、サーバ装置１、２台のクライアント装置２（２ａ，２ｂ）との間で接続が確立し、サーバ装置１からのデータ送信が行われている状況であると仮定する。サーバ装置１は、２つの送信部１０２ａ〜ｂを保持しており、それぞれ、使用中の状態のストリームを３個、待機中のストリームを３個、保持するものとする。また、管理部１０６は、並列数の上限値として６という値を持つものとする。この状態において、管理部１０６は、それぞれの送信部１０２の並列数が３であり、その総和が３×２＝６≦６であることから、総和が上限値以下に収まっていると判断し、特に並列数の変更の指示は行わない。
【００６５】
この状態で、第３のクライアント装置２ｃからサーバ装置１へ、新規の接続確立が行われたとする。このときサーバ装置１において送信部１０２ｃが新たに作成され、使用中の状態のストリームが３個、待機中の状態のストリームが３個、新たに作成される。
【００６６】
管理部１０６は定期的な並列数の取得により、並列数の総和が３増加して９に変わり、上限値（６）を超えたことを知る。管理部１０６は、並列数の総和が６以下となるよう、ここでは各送信部１０２から均等に並列数を減らす方針を採用し、それぞれの並列数を３から２へ減らすことを決定する。管理部１０６は、各送信部１０２ａ〜ｃに対し、並列数を２へ変更するよう指示を出す。各送信部１０２は、この指示を受けて、振分部１０３が有する対応表において、状態が「使用中」となる任意のストリームを１個選択し、その状態を「待機中」に変更する。  以上述べた方法により、サーバ装置１において使用されるＴＣＰストリームの総数が極度に増加するという現象を回避することができる。これによりサーバ装置１が過負荷状態となることを回避できる。
【００６７】
なお、本実施例では、管理部１０６が変更を指示する対象を「使用中」にあるストリームの数であるとしたが、必ずしもこれに限らなくともよく、「調整中」にあるストリームの数であってもよい。あるいは、状態を変更するのでなく、ＴＣＰの接続を終了させてもよい。これらの数を減らすことによって、サーバ装置１におけるメモリ等のリソース使用量を削減することが可能となる。
【００６８】
また、本実施例では、各送信部１０２の並列数が均等になるよう、それぞれの並列数を決定したが、必ずしもこれに限らなくともよい。以下、その他の具体的な例を示す。
【００６９】
管理部１０６は、各送信部１０２において行われる伝送レートの値を取得し、この値にもとづいて各送信部１０２の並列数を決定してもよい。例えば、伝送レートの値が大きな送信部１０２から優先的に並列数を減らしても良い。これにより、並列数を優先的に減らした送信部１０２で伝送レートの現象が予期できる。よって、各クライアント装置２に提供するデータの伝送レートを均等化でき、サービス提供の公平性を確保することが可能となる。
【００７０】
あるいは、管理部１０６は、サーバ装置１において接続確立が行われる単位時間あたりの平均回数にもとづいて各送信部１０２の並列数を決定しても良い。接続確立の単位時間あたりの平均回数が多い状況では、並列数の総和が上限値に達する可能性が高いと予期されるため、各送信部１０２の並列数を抑えるよう指示することができる。これにより、各送信部１０２の並列数の変更を行う回数を削減することができ、余計な処理負荷が削減できるほか、伝送レートの頻繁な変動を回避することが可能となる。
【００７１】
あるいは、管理部１０６は、ＨＴＴＰサーバアプリケーション１０１における各種の設定値にもとづいて各送信部１０２の並列数を決定してもよい。例えば、ＨＴＴＰパーシステントコネクションに関する設定値を利用することができる。ＫｅｅｐＡｌｉｖｅＴｉｍｅｏｕｔ値は、ＴＣＰ接続を維持する時間を示す。この設定値が高ければ、並列数の総和が上限値に達する可能性が高いと予期されるため、各送信部１０２の並列数を抑えるよう指示することができる。またＭａｘＫｅｅｐＡｌｉｖｅＲｅｑｕｅｓｔ値は、接続から切断までに受け付けるリクエストの数を示す。この設定値についても同様に、値が高ければ、各送信部１０２の並列数を抑えるよう指示することができる。これにより、各送信部１０２の並列数の変更を行う回数を削減することが可能となる。
【００７２】
以上のように本実施の形態によれば、サーバ装置とクライアント装置の間でＴＣＰストリームの伝送レートの高い状態を維持することが可能となる。
【００７３】
以上、具体的な手順を挙げながら、本発明の実施形態について説明を行った。なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。その一例は上記手順中においていくつか述べてきた。
【符号の説明】
【００７４】
１００  通信システム
１０２  送信部
１０３  振分部
１０４  指示部
１０５  検出部
２０１  受信部
２０２  集約部。
【図１】
2014078895.tif 000003
【図２】
2014078895.tif 000004
【図３】
2014078895.tif 000005
【図４】
2014078895.tif 000006
【図５】
2014078895.tif 000007
【図６】
2014078895.tif 000008
【図７】
2014078895.tif 000009
【図８】
2014078895.tif 000010
【図９】
2014078895.tif 000011
【図１０】
2014078895.tif 000012