JP5640649B2 - データ通信方法及び情報処理装置 - Google Patents

Description

本発明は、サーバ装置とクライアント装置との間で複数のＴＣＰ（Transmission Control Protocol）コネクションを確立し、所定の単位毎に分割された各データを複数のＴＣＰコネクションを用いて通信するデータ通信方法及び情報処理装置に関する。

従来より、ＨＴＴＰ（HyperText Transfer Protocol）によりインターネット上のサービスからウェブページやコンテンツなどを通信することが広く行われている。たとえば、ＨＴＴＰによりデータのダウンロード（ＧＥＴ）やアップロード（ＰＵＴ）を行うことができる。

一般に、ＨＴＴＰは一本のＴＣＰ上で行われる。ＴＣＰは非同期に双方向通信が可能なトランスポートである。ＨＴＴＰでは、クライアントとしての情報処理装置とサーバとしての情報処理装置との間で、データのダウンロード（ＧＥＴ）やアップロード（ＰＵＴ）の要求や、この要求に対する返事のやり取りが一本のＴＣＰコネクション上で行われる。具体的には、クライアントは、アップロード要求（ＰＵＴ要求）を送信すると、ＰＵＴ要求に続いてアップロードするデータを送信する。一方、クライアントがダウンロード要求（ＧＥＴ要求）を送信すると、サーバは、ＧＥＴ要求に対する返事を送信し、この返事に続いてダウンロードされるデータを送信する。

ここで、十分に広帯域であり、遅延の大きい環境でのＴＣＰの一本あたりのスループットは、ＴＣＰのフロー制御の仕組みによって決定される。ここで、最大スループットは、ソケットあたりの受信バッファサイズ／ＲＴＴ（Round Trip Time、パケット往復にかかる時間）により求められる。ＴＣＰの最大スループットが上記によって制限される場合、十分に広帯域であり、遅延の大きい環境では、リンクの本来の能力が十分に活かされないおそれがある。

そこで、インターネットコンテンツの通信プロトコルとして、ＨＴＴＰを代替する規格であるＳＰＤＹが提案されている（例えば、非特許文献１参照。）。ＳＰＤＹにおいては、ＨＴＴＰのレイヤが変更され、一本のＴＣＰでも効率的にさまざまなインターネットコンテンツを送信できるように改良されている。ＳＰＤＹは、ＨＴＴＰ由来の問題（例えば、要求された順番でデータの通信を完了する必要がある等）の解決や、ブラウザによる効率的な先読みを可能にするヒントを提供している。

また、複数のＴＣＰコネクションを用いてＨＴＴＰによりデータの並列転送を行う方式も提案されている（例えば、特許文献１参照。）。

特開２００５−５７４８２号公報

"ＳＰＤＹ"、［online］、［平成２２年１０月１８日検索］、インターネット〈ＵＲＬ：http://www.chromium.org/spdy〉

しかしながら、先読みとは、先読みが可能であるコンテキストでのみ有効であり、先読みが不可能なシチュエーションも多い。非特許文献１に記載の技術では、ＴＣＰのスループットの上限を超えたデータ送信はできない。

また、特許文献１では、同時に送るデータストリームは一つであることが想定されており、複数の要求を同時に処理したり、順序を入れ替えたりすることはできない。また、ＴＣＰコネクションの接続本数が固定であるため、動的にリソースの制限や、環境の変化に対応できない。また、特許文献１では、ＴＣＰが切断された場合のデータの復帰が考慮されていない。

以上のような事情に鑑み、本発明の目的は、ＨＴＴＰによるデータ通信を高速化することが可能なデータ通信方法及び情報処理装置を提供することにある。

上記目的を達成するため、本発明の一形態に係るデータ通信方法は、第１の情報処理装置と第２の情報処理装置との間で複数のＴＣＰ（Transmission Control Protocol）コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のＴＣＰコネクションを用いて通信するデータ通信方法である。
上記第１の情報処理装置は、上記第２の情報処理装置との間で確立すべきＴＣＰコネクションの数の上限を示すコネクション上限情報を上記第２の情報処理装置に通知し、上記通知するコネクション上限情報を変更して、上記第２の情報処理装置との間でのＴＣＰコネクションの数を動的に変更する。

本発明によれば、ＴＣＰコネクションの本数を動的に増減することでスループットを調節することができる。ＴＣＰコネクションの本数の動的な制御は、例えば、以下のような場合に有用である。１つの第１の情報処理装置（サーバ装置）と複数の第２の情報処理装置（クライアント装置）とが同時期に通信を行うケースでは、第１の情報処理装置の処理能力の制限のため、第２の情報処理装置一つあたりに提供できるスループットが制限される。第２の情報処理装置の数が増えてきたときには既接続の第２の情報処理装置へのスループットを下げることにより、新規の第２の情報処理装置へのスループットと同等にすることができる。これにより、複数の第２の情報処理装置間で公平にサービスを行うことができる。

上記第１の情報処理装置は、上記コネクション上限情報の変更に伴いコマンドシーケンス情報を順次更新して上記第２の情報処理装置に送信する。
上記第２の情報処理装置は、受信した上記コマンドシーケンス情報をもとに、上記第１の情報処理装置からの最新のコネクション上限情報を認識する。

第１の情報処理装置が送信した異なる複数のコネクション上限情報が、異なるＴＣＰコネクションを経由して第２の情報処理装置に届いたとき、複数のコネクション上限情報の到達順序が送信順序と異なる可能性がある。この場合、第２の情報処理装置は、後で送信された最新のコネクション上限情報が先に送信されたコネクション上限情報より先に到達した場合であっても、コマンドシーケンス情報をもとに最新のコネクション上限情報の通知を認識できる。

上記第１の情報処理装置は、上記コネクション上限情報及び上記コマンドシーケンス情報を、分割された各データのヘッダに付加して上記第２の情報処理装置に送信する。

コネクション上限情報及びコマンドシーケンス情報をヘッダに付加すれば、第１の情報処理装置は、第２の情報処理装置にコネクション上限情報を通知するための要求を、分割されたデータとは別個に送信する必要がなくなる。また、第２の情報処理装置は、随時受信する分割されたデータのヘッダを参照すれば、コネクション情報の更新を直ちに認識することができる。

上記第２の情報処理装置は、データを特定するデータ特定情報を含む送信要求を上記第１の情報処理装置に送信する。
上記第１の情報処理装置は、受信した上記送信要求に含まれる上記データ特定情報により特定される上記データを所定の単位毎に分割し、上記分割された各データのヘッダにそれぞれ上記データ特定情報を付加して上記第２の情報処理装置に送信する。

第２の情報処理装置は、分割されたデータのヘッダに付加されたデータ特定情報を参照することで、分割されたデータを受信する順番に関わらず、同一のデータ特定情報を有する分割されたデータ毎にデータを復元することができる。例えば、第２の情報処理装置は、複数のデータをダウンロードする際、一方のデータから分割されたデータ及び他方のデータから分割されたデータを、これらが混在するような順番で受信する可能性がある。このような場合であっても、第２の情報処理装置は、それぞれのデータを特定するデータ特定情報を参照することで、同一のデータ特定情報を有する分割されたデータ毎に複数のデータをそれぞれ復元することができる。

上記第１の情報処理装置は、上記分割されたデータのヘッダにそれぞれ、分割前の上記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する。

これにより、分割されたデータを受信する順番に関わらず、第２の情報処理装置は、前後関係識別情報を参照して正しい順序でデータを復元することができる。

本発明の一形態に係るデータ通信方法は、ネットワークに接続可能なネットワーク接続部と、変更手段とを有する。
上記変更手段は、上記ネットワーク接続部を通じて他の情報処理との間で複数のＴＣＰ（Transmission Control Protocol）コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のＴＣＰコネクションを用いて通信するとき、上記他の情報処理との間で確立すべきＴＣＰコネクションの数の上限を示すコネクション上限情報を上記他の情報処理に通知し、この通知するコネクション上限情報を変更して、上記他の情報処理との間でのＴＣＰコネクションの数を動的に変更する。

本発明によれば、ＨＴＴＰによるデータ通信を高速化することができる。

本発明の一実施形態に係るデータ通信システムの構成を示す図である。 クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。 クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。 クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。 データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。 データ通信（アップロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。 データ通信の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。 クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置からの応答を取得する前に、ＰＵＴ要求をさらに送信する場合のデータ通信方法（パイプライン）を示すシーケンス図である。 クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置からの応答を取得する前に、別のＧＥＴ要求をさらに送信する場合のデータ通信方法（パイプライン）を示すシーケンス図である。 クライアント装置のハードウェア構成を示すブロック図である。 サーバ装置のハードウェア構成を示すブロック図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［データ通信システムの構成］
図１は、本発明の一実施形態に係るデータ通信システムの構成を示す図である。
情報処理システム１００は、１以上のクライアント装置２００と、サーバ装置３００とを有する。クライアント装置２００とサーバ装置３００とは、グローバルなネットワーク１０１を介して相互に通信可能なように接続されている。なお、以下、複数のクライアント装置２００のうち１つのクライアント装置２００についてのみ説明することとする。

クライアント装置２００及びサーバ装置３００はそれぞれ、例えばＰＣ（Personal Computer）等の情報処理装置によって構成され、ＴＣＰコネクションを用いてＨＴＴＰによりデータを通信することが可能である。

例えば、クライアント装置２００は、ＨＴＴＰによりデータのアップロード要求（以下「ＨＴＴＰ ＰＵＴ要求」又は単に「ＰＵＴ要求」と呼ぶ。）をサーバ装置３００に送信し、続いて、アップロードするデータをサーバ装置３００に送信する。また、クライアント装置２００は、ＨＴＴＰによりデータのダウンロード要求（以下「ＨＴＴＰ ＧＥＴ要求」又は単に「ＧＥＴ要求」と呼ぶ。）をサーバ装置３００に送信する。サーバ装置３００は、ＧＥＴ要求を受信すると、ダウンロードされるデータをクライアント装置２００に送信する。このようにして、クライアント装置２００はサーバ装置３００にデータをアップロードするともに、サーバ装置３００からデータをダウンロードすることが可能となる（所謂クラウドコンピューティング）。

［クライアント装置及びサーバ装置の機能的な構成］
図２は、クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。
クライアント装置２００は、クライアント側並列通信部２０１と、クライアント側通信集積部２０２と、クライアント側通信分散部２０３と、クライアント側通信部２０４と、ブラウザ２０５と、ＵＩ（User Interface）２０６とを有する。

ＵＩ２０６は、クライアント装置２００とユーザの間での情報をやりとりするためのインタフェースである。

ブラウザ２０５は、ＵＩ２０６を通して入力されるユーザからの要求を受け入れてＨＴＴＰ処理し、コンテンツを解釈する等の処理を行う。

クライアント側並列通信部２０１は、複数のＴＣＰコネクションを確立して並列通信をイニシエートする等の処理を行う。

クライアント側通信分散部２０３は、クライアント側通信部２０４により、ＨＴＴＰトランザクションを複数のＴＣＰコネクションを用いて分散して送信させる等の処理を行う。

クライアント側通信集積部２０２は、クライアント側通信部２０４を介して複数のＴＣＰコネクションを通して受信したコンテンツ（チャンク）を集積して元の姿に戻す等の処理を行う。

サーバ装置３００は、サーバ側並列通信部３０１と、サーバ側通信集積部３０２と、サーバ側通信分散部３０３と、サーバ側通信部３０４と、ウェブサーバ３０６と、バックエンドサービス３０５とを有する。

ウェブサーバ３０６は、ＨＴＴＰに則り、クライアント装置２００のブラウザ２０５に対して、データの表示を提供する等の処理を行う。

バックエンドサービス３０５は、ユーザがブラウザ２０５を通して要求した命令を処理する等の処理を行う。

サーバ側並列通信部３０１（変更手段）は、クライアント側並列通信部２０１からの並列通信の要求を受けてデータを送受信するのに適切なＴＣＰコネクションの上限数を指定する等の処理を行う。

サーバ側通信分散部３０３は、サーバ側通信部３０４により、ＨＴＴＰトランザクションを複数のＴＣＰコネクションを用いて分散して送信させる等の処理を行う。

サーバ側通信集積部３０２は、サーバ側通信部３０４を介して複数のＴＣＰコネクションを通して受信したコンテンツ（チャンク）を集積して元の姿に戻す等の処理を行う。

［データ通信方法］
次に、本実施形態に係るデータ通信方法について説明する。説明は、以下の順に行うものとする。
１．クライアント装置２００がサーバ装置３００からデータをダウンロードする場合のデータ通信方法
２．クライアント装置２００がサーバ装置３００にデータをアップロードする場合のデータ通信方法
３．データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法
４．データ通信（アップロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法
５．データ通信の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法
６．クライアント装置２００がサーバ装置３００にＧＥＴ要求を送信し、サーバ装置３００からの応答を取得する前に、ＰＵＴ要求をさらに送信する場合のデータ通信方法（パイプライン）
７．クライアント装置２００がサーバ装置３００にＧＥＴ要求を送信し、サーバ装置３００からの応答を取得する前に、別のＧＥＴ要求をさらに送信する場合のデータ通信方法（パイプライン）
８．意図しないＴＣＰコネクション切断からのデータ復帰方法（ダウンロード時）
９．意図しないＴＣＰコネクション切断からのデータ復帰方法（アップロード時）

［１．クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法］
クライアント側並列通信部２０１は、ブラウザ２０５からＨＴＴＰ要求（コンテンツ受信要求）を受けると、ＨＴＴＰ ＧＥＴ要求送信（ステップＳ１０１）、ＨＴＴＰ応答ヘッダ部受信（ステップＳ１０２）、２つ目以降のＴＣＰコネクション確立（ステップＳ１０５〜Ｓ１０７）、確立したＴＣＰコネクションをクライアント側通信集積部２０２及びクライアント側通信分散部２０３に通知、の手順で並列通信を開始する。

なお、以下に説明するＴＣＰコネクションの確立のイニシエートは、常にクライアント装置２００からサーバ装置３００に対して行う。これは、クライアント装置２００からサーバ装置３００へのコネクションの確立可能性を高めるためである。一般にコネクションを待ち受けるための環境条件より、コネクションを確立しに行くことを可能にする環境条件の方が緩い。たとえば、機器とネットワーク１０１の間に、外から内への通信を制御するゲートウェイがある環境を想定する。ゲートウェイは不適切な通信を遮断することで内側の環境を健全に保つ。コネクションを待ち受けることを可能にするためには、ゲートウェイは常に固定のポートへの通信を許可しなければならず、そのポート宛ての意図しない通信を遮断するために別の対策を講じる必要がある。一方、確立しに行くことを可能にするためには、内側から外側へ通信があったタイミングでのみ、その返事用の、外から内への通信を許可するだけでよい。その返事としてふさわしくない発信者からの通信を遮断するのは容易である。このように、構築しやすい環境をクライアント側の条件にすることで、一般ユーザーがアクセスするサービスといったモデルに適用しやすくしている。

図３は、クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。
なお、本図において実線の矢印は、クライアント側並列通信部２０１とサーバ側並列通信部３０１との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信を示す。一点鎖線の矢印は、クライアント側通信集積部２０２とサーバ側通信分散部３０３との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信を示す。

クライアント側並列通信部２０１は、ブラウザ２０５からコンテンツ受信要求を受けると、一つ目のＴＣＰコネクション＃０（以下「プライマリコネクション＃０」と呼ぶ。）を確立する。クライアント側並列通信部２０１は、Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇヘッダ（以下単に「ＴＥヘッダ」と呼ぶ。）に値"ｍｔｃｐ"を指定したＨＴＴＰ ＧＥＴ要求を生成する。クライアント側並列通信部２０１は、生成したＨＴＴＰ ＧＥＴ要求を、クライアント側通信部２０４によりプライマリコネクション＃０を用いてサーバ装置３００へ送信させる（ステップＳ１０１）。

サーバ側並列通信部３０１は、サーバ側通信部３０４を介してクライアント側並列通信部２０１からＨＴＴＰ ＧＥＴ要求を受信すると、バックエンドサービス３０５にデータの送信要求を行う。ターゲットデータの場所はリクエストのＵＲＬで特定される。バックエンドサービス３０５は、クライアント装置２００に要求されたデータをサーバ側通信分散部３０３の送信バッファ（図示せず。）に格納する。

そして、サーバ側並列通信部３０１は、そのサーバ装置３００でユニークであるｓｅｓｓｉｏｎ‐ｉｄを発行する。また、サーバ側並列通信部３０１は、ＨＴＴＰ ＧＥＴ要求によってダウンロードが要求されたデータを送信するのに適切なＴＣＰコネクションの上限数を定める（たとえば８Ｍｂｐｓストリーミングコンテンツで、ＴＣＰ１本あたり３Ｍｂｐｓの環境であれば３本）。サーバ側並列通信部３０１は、ＨＴＴＰ ＧＥＴ要求に対する応答として、ｓｅｓｓｉｏｎ‐ｉｄ及びＴＣＰコネクションの上限の値を示したＨＴＴＰ応答（２００ ＯＫ）を生成する。このＨＴＴＰ応答（２００ ＯＫ）のＴＥヘッダには、値"ｍｔｃｐ"が指定される。サーバ側並列通信部３０１は、生成したＨＴＴＰ応答（２００ ＯＫ）を、サーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる（ステップＳ１０２）。そして、サーバ側並列通信部３０１は、受信したＨＴＴＰ ＧＥＴ要求によってダウンロードが要求されたデータをサーバ側通信分散部３０３に通知する。

ここで、ＨＴＴＰ応答（２００ ＯＫ）は、ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダを含む。ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダのシンタックスは、"MTCP-Session" ":" session-id "," tid["," con]である。ここで、"ｓｅｓｓｉｏｎ−ｉｄ"は、同一のセッションに属するコネクションを特定する整数である。"ｔｉｄ"（トランザクションＩＤ、データ特定情報）は、送信すべきデータを識別するための整数すなわちトランザクションを特定する整数であり、一つのセッションの存続期間中固有の値が用いられる。"ｃｏｎ"（コネクション上限情報）は、サーバ装置３００が当該クライアント装置２００に対して対応可能なＴＣＰコネクションの上限（最大本数）を示す整数である。なお、"ｃｏｎ"は、特定のセッション中初回のトランザクションの場合には必ず必要であるが、以前の値と等しい値を用いる場合には省略してもよい。また、サーバ装置３００が適切なコネクションの本数（コネクションの上限）を決定するものとする。これは、複数のクライアント装置２００に対する多数の接続を処理しなければならないサーバ装置３００の方が、クライアント装置２００に比べて処理能力の制限の影響が出やすいためである。

本図のステップＳ１０２では、"ｔｉｄ＝１"及び"ｃｏｎ＝４"が設定された例を示している。すなわち、このトランザクションは１つ目のトランザクションであり（"ｔｉｄ＝１"）、サーバ装置３００がクライアント装置２００に対して対応可能なＴＣＰコネクションの上限は４本である（"ｃｏｎ＝４"）、ということが示されている。

サーバ側通信分散部３０３は、バックエンドサービス３０５により送信バッファに格納されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、サーバ側通信分散部３０３は、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４によりプライマリコネクション＃０を用いて装置２００へ送信させる（ステップＳ１０３、Ｓ１０４）。なお、サーバ側通信分散部３０３は、クライアント側並列通信部２０１により２つ目以降（本例では最大４本）のＴＣＰコネクションが確立されるまでの間、各チャンクをサーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる。

ここで、各チャンクにはチャンクヘッダが記載されている。チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。ここで、"ｃｈｕｎｋ‐ｓｉｚｅ"は、当該チャンクの長さを示す。"ｃｈｕｎｋ‐ｓｅｑ"（前後関係識別情報）は、分割元のデータにおける位置関係を識別するための、チャンクのシーケンス番号（通し番号）を示す。なお、最初のチャンクの"ｃｈｕｎｋ‐ｓｅｑ"はランダム値であり、それ以降のチャンクはどのＴＣＰコネクションを通ったとしても（ここではプライマリコネクション＃０）、データ分割前の順番でインクリメントされた値が記載される。ｓｔａｒｔ ｄｉｒｅｃｔｉｖｅとして記載される値である"ｓｔａｒｔ‐ｓｅｑ"は、そのトランザクションで最初のチャンクのｃｈｕｎｋ‐ｓｅｑを示す。"ｔｉｄ"は、ＨＴＴＰ応答（２００ ＯＫ）に含まれるｔｉｄの値を示す。なお、"ｎ"、"ｃｍｄ‐ｓｅｑ"に関してはのちに説明する。

本図のステップＳ１０３では、"ｃｈｕｎｋ‐ｓｅｑ：１ａ２１"、"ｓｔａｒｔ‐ｓｅｑ：１ａ２１"及び"ｔｉｄ＝１"が設定された例を示している。すなわち、このチャンクのシーケンス番号は１ａ２１であり（"ｃｈｕｎｋ‐ｓｅｑ：１ａ２１"）、このトランザクションで最初のチャンクのシーケンス番号は１ａ２１であり（"ｓｔａｒｔ‐ｓｅｑ：１ａ２１"）、このトランザクションは１つ目のトランザクションである（"ｔｉｄ＝１"）、ということが示されている。そして、本図のステップＳ１０４では、シーケンス番号１ａ２１のチャンクに続いて、シーケンス番号１ａ２２のチャンク（"ｃｈｕｎｋ‐ｓｅｑ：１ａ２２"）が送信される。なお、本図では、ステップＳ１０４で送信するチャンクのチャンクヘッダの記載を一部省略している。

クライアント側通信集積部２０２は、クライアント側通信部２０４を介して、サーバ装置３００よりプライマリコネクション＃０を用いて送信された各チャンクを受信する。クライアント側通信集積部２０２は受信バッファ（図示せず。）を有し、受信したチャンクを一旦受信バッファに保存する。

一方、クライアント側並列通信部２０１は、クライアント側通信部２０４を介してサーバ側並列通信部３０１からＨＴＴＰ応答（２００ ＯＫ）（ステップＳ１０２）を受信すると、ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダに含まれる"ｃｏｎ"の値を確認する。すなわちクライアント側並列通信部２０１は、サーバ装置３００がクライアント装置２００に対してに対して対応可能なＴＣＰコネクションの上限を確認する。クライアント側並列通信部２０１は、"ｃｏｎ"が２以上と判定すると、２本目以降のＴＣＰコネクション（以下「セカンダリコネクション」と呼ぶ。）を確立する。本例では、"ｃｏｎ＝４"であるので、クライアント側並列通信部２０１は、プライマリコネクション＃０を含めて計４本のＴＣＰコネクションを確立する。すなわちクライアント側並列通信部２０１は、３本のセカンダリコネクション＃１、＃２、＃３を確立する。クライアント側並列通信部２０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、クライアント側通信部２０４により、確立したセカンダリコネクション＃１、＃２、＃３それぞれを用いてサーバ側並列通信部３０１へ並列に送信させる（ステップＳ１０５〜Ｓ１０７）。

なお、通常、クライアント側並列通信部２０１は、ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダに含まれる"ｃｏｎ"の値によって指定された上限になるようにセカンダリコネクションを確立する。しかしながら、たとえば別処理のため十分な処理能力がない場合など、指定された本数のセカンダリコネクションを確立することができない場合には、クライアント側並列通信部２０１は、この上限の範囲で可能な本数のセカンダリコネクションを確立すればよい。

ここで、クライアント側並列通信部２０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求のＭＴＣＰ−ｓｅｓｓｉｏｎヘッダの値には、ステップＳ１０２で受信したｓｅｓｓｉｏｎ‐ｉｄを指定し、ＴＥヘッダに"ｍｔｃｐ"を指定する。

サーバ側並列通信部３０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、セカンダリコネクション＃１、＃２、＃３それぞれを通じてサーバ側通信部３０４を介して受信する。サーバ側並列通信部３０１は、受信したＨＴＴＰ ＣＯＮＮＥＣＴ要求に示されるｓｅｓｓｉｏｎ‐ｉｄを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。本例では、サーバ側並列通信部３０１は、セカンダリコネクション＃１、＃２、＃３それぞれを通じて受信したＨＴＴＰ ＣＯＮＮＥＣＴ要求に示されるｓｅｓｓｉｏｎ‐ｉｄを参照し、これらのセカンダリコネクション＃１、＃２、＃３がプライマリコネクション＃０に属すると判断する。なお、該当するｓｅｓｓｉｏｎ‐ｉｄが存在しない場合や、セカンダリコネクションの本数が上限を超えている場合には、サーバ側並列通信部３０１は、サーバ側通信部３０４により、エラーをクライアント装置２００に送信させる。続いて、サーバ側並列通信部３０１は、ＨＴＴＰ応答（２００ ＯＫ）を、サーバ側通信部３０４により、セカンダリコネクション＃１、＃２、＃３それぞれを用いてクライアント装置２００に並列に送信させる（ステップＳ１０８〜Ｓ１１０）。そして、サーバ側並列通信部３０１は、確立されたセカンダリコネクション＃１、＃２、＃３をサーバ側通信集積部３０２及びサーバ側通信分散部３０３に通知する。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してＨＴＴＰ応答（２００ ＯＫ）をそれぞれ受信すると、確立したセカンダリコネクション＃１、＃２、＃３をクライアント側通信集積部２０２及びクライアント側通信分散部２０３に通知する。以上で、並列通信の開始処理が完了する。

サーバ側通信分散部３０３は、サーバ側並列通信部３０１からセカンダリコネクション＃１、＃２、＃３の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を用いてクライアント装置２００に並列に送信させる（ステップＳ１１１〜Ｓ１２０）。

なお、サーバ側通信分散部３０３は、各ＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）毎の送信ソケットバッファを監視し、何れかのＴＣＰコネクションの送信ソケットバッファに空きができたら、サーバ側通信分散部３０３が持つ送信バッファの未送信データをさらにチャンクに分割して、その空きができた送信ソケットバッファに移動してもよい。

本図では、サーバ側通信分散部３０３は、ステップＳ１０３、Ｓ１０４で既に"ｃｈｕｎｋ‐ｓｅｑ：１ａ２１"、"ｃｈｕｎｋ‐ｓｅｑ：１ａ２２"により示される各チャンクをサーバ側通信部３０４に送信させている。したがって、サーバ側通信分散部３０３が続いてサーバ側通信部３０４に送信させるチャンクの"ｃｈｕｎｋ‐ｓｅｑ"（シーケンス番号）は、順に、１ａ２３、１ａ２４、１ａ２５…１ａ２ａ、１ａ２ｂ、１ａ２ｃのようになる。例えば、ステップＳ１１２で送信するチャンクのチャンクヘッダとして、"ｃｈｕｎｋ‐ｓｅｑ：１ａ２４"、"ｓｔａｒｔ‐ｓｅｑ：１ａ２１"、"ｔｉｄ＝１"が設定されている。すなわち、このチャンクのシーケンス番号は１ａ２４であり（"ｃｈｕｎｋ‐ｓｅｑ：１ａ２４"）、このトランザクションで最初のチャンクのシーケンス番号は１ａ２１であり（"ｓｔａｒｔ‐ｓｅｑ：１ａ２１"）、このトランザクションは１つ目のトランザクションである（"ｔｉｄ＝１"）、ということが示されている。なお、本図では、ステップＳ１１１〜Ｓ１２０で送信するチャンクのチャンクヘッダの記載を一部省略している。また、以下の図においてもチャンクヘッダの記載を一部省略している箇所がある。

クライアント側通信集積部２０２は、クライアント側通信部２０４を介して、サーバ装置３００よりプライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３を用いて送信された各チャンクを受信する。クライアント側通信集積部２０２は、何れのＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。クライアント側通信集積部２０２は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをブラウザ２０５に受信データとして供給する。クライアント側通信集積部２０２は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、クライアント側通信集積部２０２は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがサーバ装置３００より届くのを待つ。

サーバ側通信分散部３０３は、サーバ側通信部３０４に、１つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをクライアント装置２００へ送信させる（ステップＳ１２０）。続いて、サーバ側通信分散部３０３は、サーバ側通信部３０４に、プライマリコネクション＃０を用いてｚｅｒｏチャンクをクライアント装置２００へ送信させる（ステップＳ１２１）。

ここで、ｚｅｒｏチャンクとは、チャンクヘッダのみでデータをもたないチャンクである。ｚｅｒｏチャンクの書式は、例えば、0; [con=n;cseq=cmd-seq];last=last-seqである。"ｌａｓｔ‐ｓｅｑ"は、１つのデータより分割された複数のチャンクの末尾のシーケンス番号、すなわち１つのトランザクションで最後のチャンクのシーケンス番号を示す。なお、"ｎ"、"ｃｍｄ‐ｓｅｑ"は後述する。

クライアント側通信集積部２０２は、クライアント側通信部２０４を介して、サーバ装置３００より送信されたｚｅｒｏチャンクを受信する。クライアント側通信集積部２０２は、ｚｅｒｏチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をブラウザ２０５に通知する。これにより、１つのトランザクションが終了する。

続いて、さらに別のトランザクションが行われる（ステップＳ１２２〜Ｓ１２７）。以下の説明において、既に説明したデータ通信方法と同様の工程等については説明を省略又は簡略化し、異なる点を中心に説明する。

本図のステップＳ１２３では、ＨＴＴＰ応答（２００ ＯＫ）に"ｔｉｄ＝２"及び"ｃｏｎ＝４"が設定された例を示している。すなわち、このトランザクションは２つ目のトランザクションであり（"ｔｉｄ＝２"）、サーバ装置３００がクライアント装置２００に対して対応可能なＴＣＰコネクションの上限は従来と同じ４本である（"ｃｏｎ＝４"）、ということが示されている。したがって、クライアント装置２００は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ４本のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を引き続き用いればよい。

［２．クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法］
図４は、クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。
ブラウザ２０５は、ＵＩ２０６を通して入力されるユーザからのコンテンツ送信要求を受け、クライアント側並列通信部２０１にコンテンツ送信要求を通知すると共に、クライアント側通信分散部２０３の送信バッファ（図示せず。）に送信すべきデータを配置する。クライアント側並列通信部２０１は、ブラウザ２０５からコンテンツ送信要求を受けると、一つ目のＴＣＰコネクション＃０（プライマリコネクション＃０）を確立する。クライアント側並列通信部２０１は、ＴＥヘッダに値"ｍｔｃｐ"を指定したＨＴＴＰ ＰＵＴ要求を生成する。クライアント側並列通信部２０１は、生成したＨＴＴＰ ＰＵＴ要求を、クライアント側通信部２０４によりプライマリコネクション＃０を用いてサーバ装置３００へ送信させる（ステップＳ２０１）。

ここで、プライマリコネクション＃０確立後最初のＨＴＴＰ ＰＵＴ要求は、Ｅｘｐｅｃｔヘッダを含む。このＥｘｐｅｃｔヘッダの値は、"１００‐Ｃｏｎｔｉｎｕｅ"である。

サーバ側並列通信部３０１は、サーバ側通信部３０４を介してクライアント側並列通信部２０１からＨＴＴＰ ＰＵＴ要求を受信すると、そのサーバ装置３００でユニークであるｓｅｓｓｉｏｎ‐ｉｄを発行する。また、サーバ側並列通信部３０１は、ＨＴＴＰ ＰＵＴ要求によってアップロードが要求されたデータを送信するのに適切なＴＣＰコネクションの上限を定める。サーバ側並列通信部３０１は、ＨＴＴＰ ＰＵＴ要求に対する応答として、上記ｓｅｓｓｉｏｎ‐ｉｄ、ｔｉｄ、ｃｏｎ（ＴＣＰコネクションの本数の上限）を示したＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）を生成する。このＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）のＴＥヘッダには、値"ｍｔｃｐ"が指定される。サーバ側並列通信部３０１は、生成したＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）を、サーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる（ステップＳ２０２）。

ここで、ＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）は、同一のセッションに属するコネクションを特定する"ｓｅｓｓｉｏｎ−ｉｄ"、トランザクションを特定する"ｔｉｄ"、ＴＣＰコネクションの上限を示す"ｃｏｎ"等を含む。

本図のステップＳ２０２では、"ｔｉｄ＝３"及び"ｃｏｎ＝４"が設定された例を示している。すなわち、このトランザクションは３つ目のトランザクションであり（"ｔｉｄ＝３"）、サーバ装置３００がクライアント装置２００に対して対応可能なＴＣＰコネクションの上限は４本である（"ｃｏｎ＝４"）、ということが示されている。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してサーバ側並列通信部３０１からＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）（ステップＳ２０２）を受信すると、ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダに含まれる"ｃｏｎ"の値を確認し、２本目以降のＴＣＰコネクションを確立する。クライアント側並列通信部２０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、クライアント側通信部２０４により、確立したセカンダリコネクション＃１、＃２、＃３それぞれを用いてサーバ側並列通信部３０１へ並列に送信させる（ステップＳ２０３〜Ｓ２０５）。

サーバ側並列通信部３０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、セカンダリコネクション＃１、＃２、＃３それぞれを通じてサーバ側通信部３０４を介して受信する。サーバ側並列通信部３０１は、受信したＨＴＴＰ ＣＯＮＮＥＣＴ要求に示されるｓｅｓｓｉｏｎ‐ｉｄを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。続いて、サーバ側並列通信部３０１は、ＨＴＴＰ応答（２００ ＯＫ）を、サーバ側通信部３０４により、セカンダリコネクション＃１、＃２、＃３それぞれを用いてクライアント装置２００に並列に送信させる（ステップＳ２０６〜Ｓ２０８）。そして、サーバ側並列通信部３０１は、確立されたセカンダリコネクション＃１、＃２、＃３をサーバ側通信集積部３０２及びサーバ側通信分散部３０３に通知する。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してＨＴＴＰ応答（２００ ＯＫ）をそれぞれ受信すると、確立したセカンダリコネクション＃１、＃２、＃３をクライアント側通信集積部２０２及びクライアント側通信分散部２０３に通知する。以上で、並列通信の開始処理が完了する。

クライアント側通信分散部２０３は、通知を受けると、ブラウザ２０５によって送信バッファに配置されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、クライアント側通信分散部２０３は、シーケンス番号を付した複数のチャンクを、クライアント側通信部２０４によりプライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３を用いてサーバ装置３００へ送信させる（ステップＳ２０９〜Ｓ２１８）。

サーバ側通信集積部３０２は、サーバ側通信部３０４を介して、クライアント装置２００よりプライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３を用いて送信された各チャンクを受信する。サーバ側通信集積部３０２は、何れのＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。サーバ側通信集積部３０２は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをウェブサーバ３０６に受信データとして供給する。サーバ側通信集積部３０２は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、サーバ側通信集積部３０２は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがクライアント装置２００より届くのを待つ。

クライアント側通信分散部２０３は、クライアント側通信部２０４に、１つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをサーバ装置３００へ送信させる（ステップＳ２１８）。続いて、クライアント側通信分散部２０３は、クライアント側通信部２０４に、プライマリコネクション＃０を用いてｚｅｒｏチャンクをサーバ装置３００へ送信させる（ステップＳ２１９）。

サーバ側通信集積部３０２は、サーバ側通信部３０４を介して、クライアント装置２００より送信されたｚｅｒｏチャンクを受信する。サーバ側通信集積部３０２は、ｚｅｒｏチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部３０１に通知する。

サーバ側並列通信部３０１は、データ受信完了の通知を受けると、ＨＴＴＰ応答（２００ ＯＫ）を生成し、サーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる（ステップＳ２２０）。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してＨＴＴＰ応答（２００ ＯＫ）をそれぞれ受信すると、データのアップロードの完了を判断する。これにより、１つのトランザクションが終了する。

続いて、さらに別のトランザクションが行われる（ステップＳ２２１〜Ｓ２２７）。本図のステップＳ２２２では、ＨＴＴＰ応答（１００−Ｃｏｎｔｉｎｕｅ）に"ｔｉｄ＝４"及び"ｃｏｎ＝４"が設定された例を示している。すなわち、このトランザクションは４つ目のトランザクションであり（"ｔｉｄ＝４"）、サーバ装置３００がクライアント装置２００に対して対応可能なＴＣＰコネクションの上限は従来と同じ４本である（"ｃｏｎ＝４"）、ということが示されている。したがって、クライアント装置２００は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ４本のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を引き続き用いればよい。

［３．データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法］
図５は、データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置２００及びサーバ装置３００は、並列通信の開始処理を行う（ステップＳ１０１〜Ｓ１１０）。そして、サーバ側通信分散部３０３は、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を用いてクライアント装置２００へ並列に送信させる（ステップＳ１１１〜Ｓ１１４）。

ここで、バックエンドサービス３０６が、クライアント装置２００向けに処理可能なＴＣＰコネクションの上限が増えたと判断したとする。その場合、バックエンドサービス３０６は、サーバ側並列通信部３０１にＴＣＰコネクションの上限の増加を通知し、サーバ側並列通信部３０１は、サーバ側通信分散部３０３にＴＣＰコネクションの上限の増加を通知する。サーバ側通信分散部３０３は、通知を受けると、次回クライアント装置２００へ送信すべきチャンクに付随するチャンクヘッダを次のように書き換える。上述のように、チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。サーバ側通信分散部３０３は、"ｃｏｎ＝ｎ"に、サーバ側並列通信部３０１からの通知に含まれるＴＣＰコネクションの上限（例えば"ｃｏｎ＝５"）を指定する。さらに、サーバ側通信分散部３０３は、"ｃｍｄ‐ｓｅｑ"に、前回のｃｍｄ‐ｓｅｑの値をインクリメントした値を指定する。なお、最初はランダム値とする。サーバ側通信分散部３０３は、このように書き換えたチャンクヘッダを付したチャンクを、任意のＴＣＰコネクション（例えば、プライマリコネクション＃０）を用いてクライアント装置２００に送信させる（ステップＳ３０１）。

ここで、"ｃｍｄ‐ｓｅｑ"とは、コネクション上限情報の変更に伴い順次更新される、コネクション本数の変更の要求の順番を示す整数である。本実施形態のような並列通信では、サーバ側通信分散部３０３がサーバ側通信部３０４に送信させたデータ（複数のチャンク）が、異なるＴＣＰコネクションを経由してクライアント側通信集積部２０２に届いたとき、データの到達順序が変わってしまう可能性がある。たとえばサーバ側通信分散部３０３は、"ｃｏｎ＝１"及び"ｃｍｄ‐ｓｅｑ＝１"を指定したチャンクヘッダを含むチャンクＡ、"ｃｏｎ＝４"及び"ｃｍｄ‐ｓｅｑ＝２"を指定したチャンクヘッダを含むチャンクＢ、"ｃｏｎ＝２"及び"ｃｍｄ‐ｓｅｑ＝３"を指定したチャンクヘッダを含むチャンクＣをこの順にサーバ側通信部３０４に送信させるとする。しかし、クライアント側通信集積部２０２は、チャンクＡ（"ｃｏｎ＝１"、"ｃｍｄ‐ｓｅｑ＝１"）、チャンクＣ（"ｃｏｎ＝２"、"ｃｍｄ‐ｓｅｑ＝３"）、チャンクＢ（"ｃｏｎ＝４"、"ｃｍｄ‐ｓｅｑ＝２"）の順で、クライアント側通信部２０４を介してこれらのチャンクを受信したとする。クライアント側通信集積部２０２は、受信した複数のチャンクに含まれるｃｍｄ‐ｓｅｑの値を比較し、もっとも大きい値が設定されたｃｍｄ‐ｓｅｑを判定する。そして、クライアント側通信集積部２０２は、もっとも大きい値が設定されたｃｍｄ‐ｓｅｑを含むチャンクヘッダが、最新のｃｏｎを示すものと判断する。このように、ｃｍｄ‐ｓｅｑを設定することで、データの到達順序が変わっても、クライアント側通信集積部２０２は、最新のＴＣＰコネクションの上限を判断することができる。

クライアント側通信集積部２０２は、クライアント側通信部２０４を介してサーバ側通信分散部３０３よりチャンクを受信すると、チャンクヘッダのｃｍｄ‐ｓｅｑの値を確認する。クライアント側通信集積部２０２は、ｃｍｄ‐ｓｅｑに従来の値と異なる値が設定されていると判定すると、そのチャンクヘッダのｃｏｎの値すなわちＴＣＰコネクションの上限をクライアント側並列通信部２０１に通知する。

クライアント側並列通信部２０１は、クライアント側通信集積部２０２からＴＣＰコネクションの上限を取得すると、新たなＴＣＰコネクション（セカンダリコネクション＃４）を確立する。クライアント側並列通信部２０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、クライアント側通信部２０４により、新たに確立したセカンダリコネクション＃４を用いてサーバ側並列通信部３０１へ並列に送信させる（ステップＳ３０２）。

サーバ側並列通信部３０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求をセカンダリコネクション＃４を通じてサーバ側通信部３０４を介して受信すると、ＨＴＴＰ応答（２００ ＯＫ）を、サーバ側通信部３０４により、セカンダリコネクション＃４を用いてクライアント装置２００に送信させる（ステップＳ３０３）。そして、サーバ側並列通信部３０１は、確立されたセカンダリコネクション＃４をサーバ側通信集積部３０２及びサーバ側通信分散部３０３に通知する。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してＨＴＴＰ応答（２００ ＯＫ）をそれぞれ受信すると、確立したセカンダリコネクション＃４をクライアント側通信集積部２０２及びクライアント側通信分散部２０３に通知する。

サーバ側通信分散部３０３は、サーバ側並列通信部３０１からセカンダリコネクション＃４の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３、＃４）を用いてクライアント装置２００へ並列に送信させ、最後にプライマリコネクション＃０を用いてｚｅｒｏチャンクをクライアント装置２００へ送信させる（ステップＳ３０４〜Ｓ３０９）。

［４．データ通信（アップロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法］
図６は、データ通信（アップロード）の最中にＴＣＰコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置２００及びサーバ装置３００は、並列通信の開始処理を行う（ステップＳ２０１〜Ｓ２０８）。そして、クライアント側通信分散部２０３は、シーケンス番号を付した複数のチャンクを、クライアント側通信部２０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を用いてサーバ装置３００へ並列に送信させる（ステップＳ２０９〜Ｓ２１２）。

ここで、サーバ側並列通信部３０１が、サーバ装置３００側でクライアント装置２００向けに処理可能なＴＣＰコネクションの上限が増えたと判断したとする。その場合、サーバ側並列通信部３０１は、この新しいＴＣＰコネクションの上限をｃｏｎに指定したＭＴＣＰ‐ｓｅｓｓｉｏｎヘッダを有するＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）を生成する。サーバ側並列通信部３０１は、生成したＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）を、サーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる（ステップＳ４０１）。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してサーバ側並列通信部３０１からＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）（ステップＳ４０１）を受信すると、ＭＴＣＰ−ｓｅｓｓｉｏｎヘッダに含まれる"ｃｏｎ"の値を確認する。すなわちクライアント側並列通信部２０１は、サーバ装置３００が対応可能なＴＣＰコネクションの上限を確認し、新たなＴＣＰコネクション（本例ではセカンダリコネクション＃４）を確立する。クライアント側並列通信部２０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、クライアント側通信部２０４により、新たに確立したセカンダリコネクション＃４を用いてサーバ側並列通信部３０１へ並列に送信させる（ステップＳ４０２）。

サーバ側並列通信部３０１は、ＨＴＴＰ ＣＯＮＮＥＣＴ要求を、セカンダリコネクション＃４を通じてサーバ側通信部３０４を介して受信する。続いて、サーバ側並列通信部３０１は、ＨＴＴＰ応答（２００ ＯＫ）を、サーバ側通信部３０４により、セカンダリコネクション＃４を用いてクライアント装置２００に並列に送信させる（ステップＳ４０３）。そして、サーバ側並列通信部３０１は、新たに確立されたセカンダリコネクション＃４をサーバ側通信集積部３０２及びサーバ側通信分散部３０３に通知する。

クライアント側並列通信部２０１は、クライアント側通信部２０４を介してＨＴＴＰ応答（２００ ＯＫ）をそれぞれ受信すると、確立したセカンダリコネクション＃４をクライアント側通信集積部２０２及びクライアント側通信分散部２０３に通知する。

クライアント側通信分散部２０３は、クライアント側並列通信部２０１からセカンダリコネクション＃４の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３、＃４）を用いてクライアント装置２００へ並列に送信させ、最後にクライアント側通信部２０４に、プライマリコネクション＃０を用いてｚｅｒｏチャンクをサーバ装置３００へ送信させる（ステップＳ４０４〜Ｓ４０９）。

サーバ側通信集積部３０２は、サーバ側通信部３０４を介して、クライアント装置２００より送信されたｚｅｒｏチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部３０１に通知する。サーバ側並列通信部３０１は、データ受信完了の通知を受けると、ＨＴＴＰ応答（２００ ＯＫ）を生成し、サーバ側通信部３０４によりプライマリコネクション＃０を用いてクライアント装置２００へ送信させる（ステップＳ４１０）。

［５．データ通信の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法］
図７は、データ通信の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。
ここでは、データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法について説明する。

まず、クライアント装置２００及びサーバ装置３００は、並列通信の開始処理を行う（ステップＳ１０１〜Ｓ１１０）。そして、サーバ側通信分散部３０３は、シーケンス番号を付した複数のチャンクを、サーバ側通信部３０４に、任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１、＃２、＃３）を用いてクライアント装置２００へ並列に送信させる（ステップＳ１１１〜Ｓ１１４）。

ここで、サーバ側並列通信部３０１が、サーバ装置３００側でクライアント装置２００向けに処理可能なＴＣＰコネクションの本数を減らすよう判断したとする。ここで、ＴＣＰコネクションの本数を減らすためには、減らす対象のＴＣＰコネクションで通信されているデータを止めてからでないと、データの欠損が起きてしまう。それを防ぐため、以下の方法でＴＣＰコネクションの本数を減らす。

サーバ側並列通信部３０１は、サーバ側通信分散部３０３に、ＴＣＰコネクションの本数を減少するよう通知する。サーバ側通信分散部３０３は、通知を受けると、サーバ側通信部３０４により、減らす対象のセカンダリコネクションを用いて、クライアント装置２００に、ｚｅｒｏチャンクを送信する。ここで、ｚｅｒｏチャンクの書式は、例えば、"0; con=n;cseq=cmd-seq"である。

本例では、現在４本のＴＣＰコネクション（プライマリコネクションを含む）を用いていて、そのうち２本セカンダリコネクションを切断して２本のＴＣＰコネクションにする場合を示す。サーバ側通信分散部３０３は、切断対象の２本のセカンダリコネクション（例えばセカンダリコネクション＃２、＃３）を任意に選択する。サーバ側通信分散部３０３は、サーバ側通信部３０４により、選択したセカンダリコネクション＃２、＃３を用いて、ｃｏｎ＝２を指定した上記ｚｅｒｏチャンクをクライアント装置２００へ送信する（ステップＳ５０１、Ｓ５０２）。

なお、通常チャンクはプライマリコネクションでダウンロード／アップロードが行われた後に通信される。しかし、上記ｚｅｒｏチャンクは、ダウンロード／アップロードが完了した後でも、任意のタイミングでサーバ装置３００からクライアント装置２００に対して送信してよい。

サーバ側通信分散部３０３は、サーバ側通信部３０４によりｚｅｒｏチャンクをクライアント装置２００へ送信すると、切断対象のセカンダリコネクション＃２、＃３を用いた新たなチャンクの送信を停止する。そして、サーバ側通信分散部３０３は、クライアント装置２００によりセカンダリコネクション＃２、＃３が切断されるのを待つ。しかしながら、ＰＵＴ用のチャンクがクライアント側通信分散部２０３からサーバ側通信集積部３０２に届く可能性があるので、サーバ側通信集積部３０２は、セカンダリコネクション＃２、＃３が切断されるまではチャンク受信に備えておく。これは、サーバ側通信分散部３０３が上記ｚｅｒｏチャンクを送信するのとほぼ同じタイミングでクライアント装置２００がアップロード処理を開始した場合を考慮したものである。すなわちこのような場合、ｚｅｒｏチャンクがクライアント装置２００に届く前に、クライアント側通信分散部２０３がクライアント側通信部２０４にアップロード用のチャンクをセカンダリコネクション＃２、＃３を用いて送信させる可能性があるからである。

その後、サーバ側通信分散部３０３は、複数のチャンクを、サーバ側通信部３０４に、切断したセカンダリコネクション＃２、＃３を除く任意のＴＣＰコネクション（プライマリ及びセカンダリコネクション＃０、＃１）を用いてクライアント装置２００へ並列に送信させる（ステップＳ５０３、Ｓ５０４）。続いて、サーバ側通信分散部３０３は、サーバ側通信部３０４に、プライマリコネクション＃０を用いてｚｅｒｏチャンクをクライアント装置２００へ送信させる（ステップＳ５０５）。

以上、データ通信（ダウンロード）の最中にＴＣＰコネクションの接続本数を減少する場合のデータ通信方法について説明したが、データ通信（アップロード）の最中であれば、以下のように処理を行えばよい。すなわち、クライアント側通信分散部２０３は、上記ｚｅｒｏチャンクを受けて、もしアップロード用のチャンクの送信中であれば、新たなチャンクの送信を停止する。そして、クライアント側通信分散部２０３は、送信済みのチャンクがサーバ装置３００に到着したのを確認してから切断対象のコネクションを切断する。なお、クライアント側通信分散部２０３は、送信済みのチャンクがサーバ装置３００に到着したのを確認する技術については、ＴＣＰ等、信頼性のあるトランスポートが前提であれば可能である。

本実施形態によれば、セカンダリコネクションの本数を動的に増減することでスループットを調節することができる。動的なセカンダリコネクションの本数の制御は、例えば、以下のような場合に有用である。

経路のリンク速度をＬ、１本あたりのＴＣＰコネクションのスループットをＴとするとき、ｎＴ＜Ｌである最大の自然数ｎ本のコネクションを確立すれば、最大のスループットを得ることができる。なお、ｎをそれ以上大きくしてもリンク速度Ｌの制約のためエラーが起こってしまい、スループットを得ることはできない。

また、たとえばストリーミングのように必要なスループット（Ｑとする、また、Ｑ＜Ｌとする）が決まっている場合には、それに必要なスループット以上の本数を確立しても意味がない。この場合、ｍＴ＞Ｑとなる最小のｍ本のＴＣＰコネクションを確立すればよい。

また、１つのサーバ装置３００と複数のクライアント装置２００とが同時期に通信を行うケースでは、サーバ装置３００の処理能力の制限のため、クライアント装置２００一つあたりに提供できるスループットが制限される。クライアント装置２００の数が増えてきたときには既接続クライアント装置２００へのスループットを下げることにより、新規クライアント装置２００へのスループットと同等にすることができる。これにより、複数のクライアント装置２００間で公平にサービスを行うことができる。

［６．クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置３００からの応答を取得する前に、ＰＵＴ要求をさらに送信する場合のデータ通信方法（パイプライン）］
まず、従来のＨＴＴＰのパイプラインについて説明しておくこととする。ＨＴＴＰのパイプラインとは、クライアントがあるＨＴＴＰリクエストを送信し、それに対応するレスポンスが到着する前に、さらに次以降のＨＴＴＰリクエストを送信するものである。サーバがパイプラインに対応していれば、次以降のＨＴＴＰリクエストはサーバ側でキューイングされ、順番に処理されてＨＴＴＰレスポンスが返る。

このように、レスポンスを待たずに次のリクエストを送ることができるのがＨＴＴＰのパイプラインであるが、レスポンスの順番はリクエストの順番通りであった。これは、一本のＴＣＰ上で異なるリクエストのための情報を同時に扱うことができないためである。このため、たとえばひとつのリクエストの処理に時間がかかると、他の本来処理時間が短くて済むはずのリクエストも応答に時間がかかってしまうという問題があった。

図８は、クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置からの応答を取得する前に、ＰＵＴ要求をさらに送信する場合のデータ通信方法（パイプライン）を示すシーケンス図である。
本図において実線の矢印は、クライアント側並列通信部２０１とサーバ側並列通信部３０１との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信（ダウンロード）を示す。一点鎖線の矢印は、クライアント側通信集積部２０２とサーバ側通信分散部３０３との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信（ダウンロード）を示す。点線の矢印は、クライアント側並列通信部２０１とサーバ側並列通信部３０１との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信（アップロード）を示す。破線の矢印は、クライアント側通信分散部２０３とサーバ側通信集積部３０２との、クライアント側通信部２０４及びサーバ側通信部３０４を介しての通信（アップロード）を示す。

まず、クライアント側並列通信部２０１は、ＨＴＴＰ ＧＥＴ要求をクライアント側通信部２０４によりサーバ装置３００へ送信させる（ステップＳ６０１）。クライアント側並列通信部２０１は、ＨＴＴＰ ＧＥＴ要求に対する応答をサーバ装置３００から取得する前に、ＨＴＴＰ ＰＵＴ要求をクライアント側通信部２０４によりサーバ装置３００へ送信させたとする（ステップＳ６０２）。

本例のステップＳ６０３では、ＨＴＴＰ応答（２００ ＯＫ）に"ｔｉｄ＝５"が設定された例を示している。すなわち、このトランザクションは５つ目のトランザクションである（"ｔｉｄ＝５"）、ということが示されている。また、ステップＳ６０７、Ｓ６０８、Ｓ６１７〜Ｓ６２２では、ダウンロードされるデータの各チャンクに"ｔｉｄ＝５"が設定されている。

一方、本例のステップＳ６１２では、ＨＴＴＰ応答（１００‐Ｃｏｎｔｉｎｕｅ）に"ｔｉｄ＝６"が設定された例を示している。すなわち、このトランザクションは６つ目のトランザクションである（"ｔｉｄ＝６"）、ということが示されている。また、ステップＳ６１３〜Ｓ６１５では、アップロードされるデータの各チャンクに"ｔｉｄ＝６"が設定されている。

ここで、通信されるチャンクに着目すると、まず、ステップＳ６０７、Ｓ６０８で、ダウンロード対象のデータのうち一部のチャンク（ｔｉｄ＝５）がダウンロードされる。次に、ステップＳ６１３〜Ｓ６１６で、アップロード対象のデータのうち全てのチャンク（ｔｉｄ＝６）がアップロードされる。最後に、ステップＳ６１７〜Ｓ６２３で、ダウンロード対象のデータのうち残りのチャンク（ｔｉｄ＝５）がダウンロードされる。本実施形態では、ダウンロード対象のデータに属するチャンクを全てダウンロードし、その後アップロード対象のデータに属するチャンクを全てアップロードする、という順序でデータの通信を必ずしも行う必要がない。

本実施形態では各チャンクそれぞれにトランザクションＩＤ（ｔｉｄ）を付与している。これにより、受信側（アップロードの場合サーバ装置３００、ダウンロードの場合クライアント装置２００）がトランザクションＩＤを参照すれば、データ通信の順番に関わらず、同一のトランザクションＩＤ（ｔｉｄ）を有するチャンク毎にデータを復元することができる。例えば、クライアント装置２００は、複数のデータをダウンロードする際、一方のデータから分割されたデータであるチャンク及び他方のデータから分割されたデータであるチャンクを、これらが混在するような順番で受信する可能性がある。このような場合であっても、クライアント装置２００は、それぞれのデータを特定するｔｉｄを参照することで、同一のｔｉｄを有するチャンク毎に複数のデータをそれぞれ復元することができる。

本実施形態によれば、ＨＴＴＰ要求がパイプラインされたあと、コネクションがどのトランザクション（どの要求）のために使用されているかをトランザクションＩＤ（ｔｉｄ）で示している。これにより、従来のＨＴＴＰレスポンスのヘッダに関してはリクエストの順序通りに返されなければならなかったが、本実施形態では必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送受信したりできる。

［７．クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置からの応答を取得する前に、別のＧＥＴ要求をさらに送信する場合のデータ通信方法（パイプライン）］
図９は、クライアント装置がサーバ装置にＧＥＴ要求を送信し、サーバ装置からの応答を取得する前に、別のＧＥＴ要求をさらに送信する場合のデータ通信方法（パイプライン）を示すシーケンス図である。
本図において実線の矢印は、クライアント装置２００とサーバ装置３００とのデータ通信（あるデータをダウンロード）を示す。二点鎖線の矢印は、クライアント装置２００とサーバ装置３００とのデータ通信（別のデータをダウンロード）を示す。一点鎖線の矢印は、セカンダリコネクション確立処理を示す。

まず、クライアント側並列通信部２０１は、１つ目のＨＴＴＰ ＧＥＴ要求（ＨＴＴＰ ＧＥＴ要求１とする。）をクライアント側通信部２０４によりサーバ装置３００へ送信させる（ステップＳ７０１）。クライアント側並列通信部２０１は、ＨＴＴＰ ＧＥＴ要求１に対する応答を取得する前に、２つ目のＨＴＴＰ ＧＥＴ要求（ＨＴＴＰ ＧＥＴ要求２とする。）をクライアント側通信部２０４によりサーバ装置３００へ送信させたとする（ステップＳ７０２）。

本例のステップＳ７０３では、ＨＴＴＰ応答（２００ ＯＫ）に"ｔｉｄ＝１"が設定された例を示している。すなわち、このトランザクションは１つ目のトランザクションである（"ｔｉｄ＝１"）、ということが示されている。また、ステップＳ７１６〜Ｓ７２０では、ダウンロードされるデータの各チャンクに"ｔｉｄ＝１"が設定されている。

一方、本例のステップＳ７１０では、ＨＴＴＰ応答（２００ ＯＫ）に"ｔｉｄ＝２"が設定された例を示している。すなわち、このトランザクションは２つ目のトランザクションである（"ｔｉｄ＝２"）、ということが示されている。また、ステップＳ７１１〜Ｓ７１４では、ダウンロードされるデータの各チャンクに"ｔｉｄ＝２"が設定されている。

これらＨＴＴＰ応答（２００ ＯＫ）は、ＨＴＴＰ ＧＥＴ要求の順序通りに返される。したがって、クライアント側並列通信部２０１は、自分の発行したＨＴＴＰ ＧＥＴ要求にどのようなトランザクションＩＤが付与されたかを、ＨＴＴＰ応答（２００ ＯＫ）のヘッダを参照することで知ることができる。

ここで、通信されるチャンクに着目すると、まず、ステップＳ７１１〜Ｓ７１５で、ＨＴＴＰ ＧＥＴ要求２で指定されたダウンロード対象のデータのチャンク（ｔｉｄ＝２）がダウンロードされる。次に、ステップＳ７１６〜Ｓ７２０で、ＨＴＴＰ ＧＥＴ要求１で指定されたダウンロード対象のデータのチャンク（ｔｉｄ＝１）がダウンロードされる。本実施形態では、ＨＴＴＰ ＧＥＴ要求１で指定されたダウンロード対象のデータに属するチャンクをダウンロードし、その後ＨＴＴＰ ＧＥＴ要求２で指定されたダウンロード対象のデータに属するチャンクをダウンロードする、という順序でデータの通信を必ずしも行う必要がない。本実施形態では各チャンクそれぞれにトランザクションＩＤ（ｔｉｄ）を付与しているので、受信側であるクライアント装置２００がトランザクションＩＤ（ｔｉｄ）を参照すれば、データ通信の順番に関わらず、同一のトランザクションＩＤを有するチャンク毎にデータを復元することができる。

より具体的に、セカンダリコネクション＃１を用いた通信に注目して説明する。まず、クライアント側通信集積部２０２は、クライアント側通信部２０４を介してseq:1a26 start:1a25 tid:2 のチャンクを受信する（ステップＳ７１２）。クライアント側通信集積部２０２は、このチャンクがＨＴＴＰ ＧＥＴ要求２の、２つ目のチャンクであると判断する。続いて、クライアント側通信集積部２０２は、クライアント側通信部２０４を介してseq:1a22 start:1a21 tid:1 を受信する（ステップＳ７１７）。クライアント側通信集積部２０２は、この一つ前まででセカンダリコネクション＃１上ではＨＴＴＰ ＧＥＴ要求２に関するデータ（チャンク）の受信は完了し、今届いたチャンクはＨＴＴＰ ＧＥＴ要求１の２番目のチャンクであると判断する。

本実施形態では、送られるデータがどのリクエストに対応するものかを示すため、あるコネクション上で送られるデータがどのトランザクションのためのものかを示すｔｉｄを、チャンクに付記している。これにより、ＨＴＴＰリクエストがパイプラインされたあと、コネクションがどのトランザクション（どのリクエスト）のために使用されているかをトランザクションＩＤ（ｔｉｄ）で示すことによって、受信側装置は、データ通信の順番に関わらずデータを復元することができる。これにより、送信側装置は、必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送ったりできるようにしている。

［８．意図しないＴＣＰコネクション切断からのデータ復帰方法（ダウンロード時）］
次に、通信障害等や、通信相手機器の事情により、複数のセカンダリコネクションのうち一部が意図せずに切断されてしまった場合について説明する。このような場合、以下のようにデータの完全性を保つことができる。

まず、サーバ装置３００の処理について説明する。１以上のセカンダリコネクションが切断されたとき、サーバ側通信分散部３０３は、サーバ側通信部３０４により、切断されたセカンダリコネクションで送信中であったチャンクを、改めて他のコネクションに振り分けてクライアント装置２００へ送信させる。一方、クライアント側通信集積部２０２は、クライアント側通信部２０４を介して受信したチャンクの"chunk-seq"を参照する。サーバ側通信分散部３０３がチャンクの送信が失敗したと判断して同一のチャンクを再送信した場合、実は両方の送信が成功しており、クライアント側通信集積部２０２が同一のチャンクを重複して取得してしまうような場合がある。しかしながら、クライアント側通信集積部２０２は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。

次に、クライアント装置２００の処理について説明する。１以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部２０１は、その時点で確立してもよい上限を超えない限り、ＨＴＴＰ ＣＯＮＮＥＣＴを用いて最初に張ったときと同じＳｅｓｓｉｏｎ ｉｄを指定してセカンダリコネクションを再確立する。切断されたコネクションを用いて送信中であったチャンクがあった場合は、サーバ装置３００により新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いて再転送されることが期待される。上述のように、クライアント側通信集積部２０２は、チャンクの"chunk-seq"を参照することにより重複したチャンクを検出できる。転送されない場合は、ＨＴＴＰ ＧＥＴ要求を改めてRangeヘッダでその欠損チャンクの位置のみを指定して行うことで解決することができる。なお、上記説明したパイプラインの処理により、クライアント側並列通信部２０１は、元のＨＴＴＰ ＧＥＴ要求が終了する前にでも、クライアント側通信部２０４により穴埋めのためのＨＴＴＰ ＧＥＴ要求を並列に送信させることができる。

［９．意図しないＴＣＰコネクション切断からのデータ復帰方法（アップロード時）］
まず、クライアント装置２００の処理について説明する。１以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部２０１は、その時点で確立してもよい上限を超えない限り、ＨＴＴＰ ＣＯＮＮＥＣＴを用いて最初に張ったときと同じＳｅｓｓｉｏｎ ｉｄを指定してセカンダリコネクションを再確立する。切断コネクションを用いて送信中であったチャンクがあった場合は、クライアント側通信分散部２０３は、クライアント側通信部２０４により、新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いてそのチャンクを再送信させる。サーバ側通信集積部３０２は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。

次に、サーバ装置３００の処理について説明する。サーバ側通信集積部３０２は、１以上のセカンダリコネクションが切断されたときでも、残ったコネクションを用いてサーバ側通信部３０４を介してそのままデータ受信を続ける。切断されたコネクションで送信中であったチャンクがあった場合は、クライアント装置２００により残ったコネクションを用いて再転送されることが期待される。サーバ側通信集積部３０２は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。サーバ側通信集積部３０２は、ｚｅｒｏチャンクを受信した時点でデータ（チャンク）に欠損があった場合には、ＨＴＴＰのエラーをサーバ側通信部３０４によりクライアント装置２００へ送信させる。

［クライアント装置のハードウェア構成］
次に、クライアント装置２００及びサーバ装置３００のハードウェア構成について説明する。

図１０は、クライアント装置のハードウェア構成を示すブロック図である。
クライアント装置２００において、ＣＰＵ（Central Processing Unit）６１２には、システムバス６１３を介して、入力操作部６０１と、クライアント側通信部２０４と、記憶部６０４と、デコード部６０５と、表示部６０６と、メディアインターフェース部６０８と、ＲＯＭ（Read Only Memory）６１０と、ＲＡＭ（Random Access Memory）６１１とが接続されている。

入力操作部６０１は、各種のキーなどを備える。利用者は、入力操作部６０１を用いて各種の命令やデータの入力を処理する。利用者により入力操作部６０１より入力された各種の命令は、システムバス６１３を通じてＣＰＵ６１２に供給される。

クライアント側通信部２０４は、グローバルなネットワーク１０１との接続を処理する。

記憶部６０４は、ＨＤＤ、ＳＳＤ等よりなる。記憶部６０４には、クライアント側通信部２０４によりネットワーク１０１を通じてダウンロードされたコンテンツデータ等が記録される。

デコード部６０５は、記憶部６０４から読み出されたコンテンツのデータをデコードして、デジタルビデオデータ及びデジタルオーディオデータを復元する。復元されたデジタルビデオデータはシステムバス６１３を通じて表示部６０６に供給され、デジタルオーディオデータはシステムバス６１３を通じてスピーカ部６０７に供給される。

表示部６０６は、例えば、ＬＣＤ（Liquid Crystal Display）などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部６０６は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。

メディアインターフェース部６０８には、光ディスクなどのリムーバブルメディア６１４の装着が可能とされ、このリムーバブルメディア６１４にコンテンツデータなどを記録することが可能である。リムーバブルメディア６１４としては、例えば、追記型、書換型のＤＶＤ、ブルーレイディスクなどがある。

ＲＯＭ６１０には、クライアント装置２００が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部６０４に格納されていてもよい。

ＲＡＭ６１１は、ＣＰＵ６１２によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。

ＣＰＵ６１２は、クライアント装置２００の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。ＣＰＵ６１２は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。ＣＰＵ６１２は、クライアント装置２００が実行すべきソフトウェア処理を実行するために、必要なプログラムをＲＯＭ６１０からＲＡＭ６１１へロードし、解釈して実行する。

このように、クライアント装置２００は、典型的なコンピュータ・ハードウェアを用いて構成される。そして、ＲＯＭ６１０に記憶されたプログラムは、クライアント装置２００のコンピュータ・ハードウェアを、図２に示す各モジュールとして機能させる。

［サーバ装置のハードウェア構成］
図１１は、サーバ装置のハードウェア構成を示すブロック図である。
サーバ装置３００において、ＣＰＵ（Central Processing Unit）５１２には、システムバス５１３を介して、入力操作部５０１と、サーバ側通信部３０４と、記憶部５０４と、表示部５０６と、ＲＯＭ（Read Only Memory）５１０と、ＲＡＭ（Random Access Memory）５１１とが接続されている。

入力操作部５０１は、各種のキーなどを備える。サーバ管理者は、入力操作部５０１を用いて各種の命令やデータの入力を処理する。サーバ管理者により入力操作部５０１より入力された各種の命令は、システムバス５１３を通じてＣＰＵ５１２に供給される。

サーバ側通信部３０４（ネットワーク接続部）は、グローバルなネットワーク１０１との接続を処理する。

記憶部５０４は、ＨＤＤ、ＳＳＤ等よりなる。記憶部５０４には、サーバ側通信部３０４によりネットワーク１０１を通じてアップロードされたコンテンツデータ等が記録される。

表示部５０６は、例えば、ＬＣＤ（Liquid Crystal Display）などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部５０６は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。

メディアインターフェース部５０８には、光ディスクなどのリムーバブルメディア６１４の装着が可能とされる。リムーバブルメディア６１４としては、例えば、追記型、書換型のＤＶＤ、ブルーレイディスクなどがある。

ＲＯＭ５１０には、サーバ装置３００が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部５０４に格納されていてもよい。

ＲＡＭ５１１は、ＣＰＵ５１２によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。

ＣＰＵ５１２は、サーバ装置３００の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。ＣＰＵ５１２は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。ＣＰＵ５１２は、サーバ装置３００が実行すべきソフトウェア処理を実行するために、必要なプログラムをＲＯＭ５１０からＲＡＭ５１１へロードし、解釈して実行する。

ＲＯＭ５１０に記憶されたプログラムは、サーバ装置３００のコンピュータ・ハードウェアを、図２に示す各モジュールとして機能させる。

１０１…ネットワーク
２００…クライアント装置
２０１…クライアント側並列通信部
２０２…クライアント側通信集積部
２０３…クライアント側通信分散部
２０４…クライアント側通信部
３００…サーバ装置
３０１…サーバ側並列通信部
３０２…サーバ側通信集積部
３０３…サーバ側通信分散部
３０４…サーバ側通信部

Claims (5)

1. 第１の情報処理装置と第２の情報処理装置との間で複数のＴＣＰ（Transmission Control Protocol）コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のＴＣＰコネクションを用いて通信するデータ通信方法であって、
   前記第１の情報処理装置は、
   前記第２の情報処理装置との間で確立すべきＴＣＰコネクションの数の上限を示すコネクション上限情報を前記第２の情報処理装置に通知し、
   前記通知するコネクション上限情報を変更するとき、コマンドシーケンス情報を更新して最新の前記コネクション上限情報とともに前記第２の情報処理装置に送信し、前記第２の情報処理装置は、受信した前記コマンドシーケンス情報をもとに、前記第１の情報処理装置からの前記最新のコネクション上限情報を認識する
   データ通信方法。
2. 請求項１に記載のデータ通信方法であって、
   前記第１の情報処理装置は、前記コネクション上限情報及び前記コマンドシーケンス情報を、分割された各データのヘッダに付加して前記第２の情報処理装置に送信する
   データ通信方法。
3. 請求項１または２に記載のデータ通信方法であって、
   前記第２の情報処理装置は、データを特定するデータ特定情報を含む送信要求を前記第１の情報処理装置に送信し、
   前記第１の情報処理装置は、受信した前記送信要求に含まれる前記データ特定情報により特定される前記データを所定の単位毎に分割し、前記分割された各データのヘッダにそれぞれ前記データ特定情報を付加して前記第２の情報処理装置に送信する
   データ通信方法。
4. 請求項３に記載のデータ通信方法であって、
   前記第１の情報処理装置は、前記分割されたデータのヘッダにそれぞれ、分割前の前記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する
   データ通信方法。
5. ネットワークに接続可能なネットワーク接続部と、
   前記ネットワーク接続部を通じて他の情報処理装置との間で複数のＴＣＰ（Transmission Control Protocol）コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のＴＣＰコネクションを用いて通信するとき、前記他の情報処理装置との間で確立すべきＴＣＰコネクションの数の上限を示すコネクション上限情報を前記他の情報処理に通知し、前記通知するコネクション上限情報を変更するとき、コマンドシーケンス情報を更新して最新の前記コネクション上限情報とともに前記他の情報処理装置に送信し、前記他の情報処理装置に、前記コマンドシーケンス情報をもとに前記第１の情報処理装置からの前記最新のコネクション上限情報を認識させる変更手段と
   を具備する情報処理装置。

Images