データ通信方法及び情報処理装置
【課題】HTTP(HyperText Transfer Protocol)によるデータ通信を高速化することが可能なデータ通信方法を提供する。
【解決手段】サーバ装置300とクライアント装置200との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを確立された複数のTCPコネクションを用いて通信する。サーバ装置300は、クライアント装置200との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報をクライアント装置200に通知し、通知するコネクション上限情報を変更して、クライアント装置200との間でのTCPコネクションの数を動的に変更する。
【解決手段】サーバ装置300とクライアント装置200との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを確立された複数のTCPコネクションを用いて通信する。サーバ装置300は、クライアント装置200との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報をクライアント装置200に通知し、通知するコネクション上限情報を変更して、クライアント装置200との間でのTCPコネクションの数を動的に変更する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ装置とクライアント装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを複数のTCPコネクションを用いて通信するデータ通信方法及び情報処理装置に関する。
【背景技術】
【0002】
従来より、HTTP(HyperText Transfer Protocol)によりインターネット上のサービスからウェブページやコンテンツなどを通信することが広く行われている。たとえば、HTTPによりデータのダウンロード(GET)やアップロード(PUT)を行うことができる。
【0003】
一般に、HTTPは一本のTCP上で行われる。TCPは非同期に双方向通信が可能なトランスポートである。HTTPでは、クライアントとしての情報処理装置とサーバとしての情報処理装置との間で、データのダウンロード(GET)やアップロード(PUT)の要求や、この要求に対する返事のやり取りが一本のTCPコネクション上で行われる。具体的には、クライアントは、アップロード要求(PUT要求)を送信すると、PUT要求に続いてアップロードするデータを送信する。一方、クライアントがダウンロード要求(GET要求)を送信すると、サーバは、GET要求に対する返事を送信し、この返事に続いてダウンロードされるデータを送信する。
【0004】
ここで、十分に広帯域であり、遅延の大きい環境でのTCPの一本あたりのスループットは、TCPのフロー制御の仕組みによって決定される。ここで、最大スループットは、ソケットあたりの受信バッファサイズ/RTT(Round Trip Time、パケット往復にかかる時間)により求められる。TCPの最大スループットが上記によって制限される場合、十分に広帯域であり、遅延の大きい環境では、リンクの本来の能力が十分に活かされないおそれがある。
【0005】
そこで、インターネットコンテンツの通信プロトコルとして、HTTPを代替する規格であるSPDYが提案されている(例えば、非特許文献1参照。)。SPDYにおいては、HTTPのレイヤが変更され、一本のTCPでも効率的にさまざまなインターネットコンテンツを送信できるように改良されている。SPDYは、HTTP由来の問題(例えば、要求された順番でデータの通信を完了する必要がある等)の解決や、ブラウザによる効率的な先読みを可能にするヒントを提供している。
【0006】
また、複数のTCPコネクションを用いてHTTPによりデータの並列転送を行う方式も提案されている(例えば、特許文献1参照。)。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2005−57482号公報
【非特許文献】
【0008】
【非特許文献1】"SPDY"、[online]、[平成22年10月18日検索]、インターネット〈URL:http://www.chromium.org/spdy〉
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、先読みとは、先読みが可能であるコンテキストでのみ有効であり、先読みが不可能なシチュエーションも多い。非特許文献1に記載の技術では、TCPのスループットの上限を超えたデータ送信はできない。
【0010】
また、特許文献1では、同時に送るデータストリームは一つであることが想定されており、複数の要求を同時に処理したり、順序を入れ替えたりすることはできない。また、TCPコネクションの接続本数が固定であるため、動的にリソースの制限や、環境の変化に対応できない。また、特許文献1では、TCPが切断された場合のデータの復帰が考慮されていない。
【0011】
以上のような事情に鑑み、本発明の目的は、HTTPによるデータ通信を高速化することが可能なデータ通信方法及び情報処理装置を提供することにある。
【課題を解決するための手段】
【0012】
上記目的を達成するため、本発明の一形態に係るデータ通信方法は、第1の情報処理装置と第2の情報処理装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のTCPコネクションを用いて通信するデータ通信方法である。
上記第1の情報処理装置は、上記第2の情報処理装置との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を上記第2の情報処理装置に通知し、上記通知するコネクション上限情報を変更して、上記第2の情報処理装置との間でのTCPコネクションの数を動的に変更する。
【0013】
本発明によれば、TCPコネクションの本数を動的に増減することでスループットを調節することができる。TCPコネクションの本数の動的な制御は、例えば、以下のような場合に有用である。1つの第1の情報処理装置(サーバ装置)と複数の第2の情報処理装置(クライアント装置)とが同時期に通信を行うケースでは、第1の情報処理装置の処理能力の制限のため、第2の情報処理装置一つあたりに提供できるスループットが制限される。第2の情報処理装置の数が増えてきたときには既接続の第2の情報処理装置へのスループットを下げることにより、新規の第2の情報処理装置へのスループットと同等にすることができる。これにより、複数の第2の情報処理装置間で公平にサービスを行うことができる。
【0014】
上記第1の情報処理装置は、上記コネクション上限情報の変更に伴いコマンドシーケンス情報を順次更新して上記第2の情報処理装置に送信する。
上記第2の情報処理装置は、受信した上記コマンドシーケンス情報をもとに、上記第1の情報処理装置からの最新のコネクション上限情報を認識する。
【0015】
第1の情報処理装置が送信した異なる複数のコネクション上限情報が、異なるTCPコネクションを経由して第2の情報処理装置に届いたとき、複数のコネクション上限情報の到達順序が送信順序と異なる可能性がある。この場合、第2の情報処理装置は、後で送信された最新のコネクション上限情報が先に送信されたコネクション上限情報より先に到達した場合であっても、コマンドシーケンス情報をもとに最新のコネクション上限情報の通知を認識できる。
【0016】
上記第1の情報処理装置は、上記コネクション上限情報及び上記コマンドシーケンス情報を、分割された各データのヘッダに付加して上記第2の情報処理装置に送信する。
【0017】
コネクション上限情報及びコマンドシーケンス情報をヘッダに付加すれば、第1の情報処理装置は、第2の情報処理装置にコネクション上限情報を通知するための要求を、分割されたデータとは別個に送信する必要がなくなる。また、第2の情報処理装置は、随時受信する分割されたデータのヘッダを参照すれば、コネクション情報の更新を直ちに認識することができる。
【0018】
上記第2の情報処理装置は、データを特定するデータ特定情報を含む送信要求を上記第1の情報処理装置に送信する。
上記第1の情報処理装置は、受信した上記送信要求に含まれる上記データ特定情報により特定される上記データを所定の単位毎に分割し、上記分割された各データのヘッダにそれぞれ上記データ特定情報を付加して上記第2の情報処理装置に送信する。
【0019】
第2の情報処理装置は、分割されたデータのヘッダに付加されたデータ特定情報を参照することで、分割されたデータを受信する順番に関わらず、同一のデータ特定情報を有する分割されたデータ毎にデータを復元することができる。例えば、第2の情報処理装置は、複数のデータをダウンロードする際、一方のデータから分割されたデータ及び他方のデータから分割されたデータを、これらが混在するような順番で受信する可能性がある。このような場合であっても、第2の情報処理装置は、それぞれのデータを特定するデータ特定情報を参照することで、同一のデータ特定情報を有する分割されたデータ毎に複数のデータをそれぞれ復元することができる。
【0020】
上記第1の情報処理装置は、上記分割されたデータのヘッダにそれぞれ、分割前の上記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する。
【0021】
これにより、分割されたデータを受信する順番に関わらず、第2の情報処理装置は、前後関係識別情報を参照して正しい順序でデータを復元することができる。
【0022】
本発明の一形態に係るデータ通信方法は、ネットワークに接続可能なネットワーク接続部と、変更手段とを有する。
上記変更手段は、上記ネットワーク接続部を通じて他の情報処理との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のTCPコネクションを用いて通信するとき、上記他の情報処理との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を上記他の情報処理に通知し、この通知するコネクション上限情報を変更して、上記他の情報処理との間でのTCPコネクションの数を動的に変更する。
【発明の効果】
【0023】
本発明によれば、HTTPによるデータ通信を高速化することができる。
【図面の簡単な説明】
【0024】
【図1】本発明の一実施形態に係るデータ通信システムの構成を示す図である。
【図2】クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。
【図3】クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。
【図4】クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。
【図5】データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
【図6】データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
【図7】データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。
【図8】クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
【図9】クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
【図10】クライアント装置のハードウェア構成を示すブロック図である。
【図11】サーバ装置のハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【0025】
以下、図面を参照しながら、本発明の実施形態を説明する。
【0026】
[データ通信システムの構成]
図1は、本発明の一実施形態に係るデータ通信システムの構成を示す図である。
情報処理システム100は、1以上のクライアント装置200と、サーバ装置300とを有する。クライアント装置200とサーバ装置300とは、グローバルなネットワーク101を介して相互に通信可能なように接続されている。なお、以下、複数のクライアント装置200のうち1つのクライアント装置200についてのみ説明することとする。
【0027】
クライアント装置200及びサーバ装置300はそれぞれ、例えばPC(Personal Computer)等の情報処理装置によって構成され、TCPコネクションを用いてHTTPによりデータを通信することが可能である。
【0028】
例えば、クライアント装置200は、HTTPによりデータのアップロード要求(以下「HTTP PUT要求」又は単に「PUT要求」と呼ぶ。)をサーバ装置300に送信し、続いて、アップロードするデータをサーバ装置300に送信する。また、クライアント装置200は、HTTPによりデータのダウンロード要求(以下「HTTP GET要求」又は単に「GET要求」と呼ぶ。)をサーバ装置300に送信する。サーバ装置300は、GET要求を受信すると、ダウンロードされるデータをクライアント装置200に送信する。このようにして、クライアント装置200はサーバ装置300にデータをアップロードするともに、サーバ装置300からデータをダウンロードすることが可能となる(所謂クラウドコンピューティング)。
【0029】
[クライアント装置及びサーバ装置の機能的な構成]
図2は、クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。
クライアント装置200は、クライアント側並列通信部201と、クライアント側通信集積部202と、クライアント側通信分散部203と、クライアント側通信部204と、ブラウザ205と、UI(User Interface)206とを有する。
【0030】
UI206は、クライアント装置200とユーザの間での情報をやりとりするためのインタフェースである。
【0031】
ブラウザ205は、UI206を通して入力されるユーザからの要求を受け入れてHTTP処理し、コンテンツを解釈する等の処理を行う。
【0032】
クライアント側並列通信部201は、複数のTCPコネクションを確立して並列通信をイニシエートする等の処理を行う。
【0033】
クライアント側通信分散部203は、クライアント側通信部204により、HTTPトランザクションを複数のTCPコネクションを用いて分散して送信させる等の処理を行う。
【0034】
クライアント側通信集積部202は、クライアント側通信部204を介して複数のTCPコネクションを通して受信したコンテンツ(チャンク)を集積して元の姿に戻す等の処理を行う。
【0035】
サーバ装置300は、サーバ側並列通信部301と、サーバ側通信集積部302と、サーバ側通信分散部303と、サーバ側通信部304と、ウェブサーバ306と、バックエンドサービス305とを有する。
【0036】
ウェブサーバ306は、HTTPに則り、クライアント装置200のブラウザ205に対して、データの表示を提供する等の処理を行う。
【0037】
バックエンドサービス305は、ユーザがブラウザ205を通して要求した命令を処理する等の処理を行う。
【0038】
サーバ側並列通信部301(変更手段)は、クライアント側並列通信部201からの並列通信の要求を受けてデータを送受信するのに適切なTCPコネクションの上限数を指定する等の処理を行う。
【0039】
サーバ側通信分散部303は、サーバ側通信部304により、HTTPトランザクションを複数のTCPコネクションを用いて分散して送信させる等の処理を行う。
【0040】
サーバ側通信集積部302は、サーバ側通信部304を介して複数のTCPコネクションを通して受信したコンテンツ(チャンク)を集積して元の姿に戻す等の処理を行う。
【0041】
[データ通信方法]
次に、本実施形態に係るデータ通信方法について説明する。説明は、以下の順に行うものとする。
1.クライアント装置200がサーバ装置300からデータをダウンロードする場合のデータ通信方法
2.クライアント装置200がサーバ装置300にデータをアップロードする場合のデータ通信方法
3.データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法
4.データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法
5.データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法
6.クライアント装置200がサーバ装置300にGET要求を送信し、サーバ装置300からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)
7.クライアント装置200がサーバ装置300にGET要求を送信し、サーバ装置300からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)
8.意図しないTCPコネクション切断からのデータ復帰方法(ダウンロード時)
9.意図しないTCPコネクション切断からのデータ復帰方法(アップロード時)
【0042】
[1.クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法]
クライアント側並列通信部201は、ブラウザ205からHTTP要求(コンテンツ受信要求)を受けると、HTTP GET要求送信(ステップS101)、HTTP応答ヘッダ部受信(ステップS102)、2つ目以降のTCPコネクション確立(ステップS105〜S107)、確立したTCPコネクションをクライアント側通信集積部202及びクライアント側通信分散部203に通知、の手順で並列通信を開始する。
【0043】
なお、以下に説明するTCPコネクションの確立のイニシエートは、常にクライアント装置200からサーバ装置300に対して行う。これは、クライアント装置200からサーバ装置300へのコネクションの確立可能性を高めるためである。一般にコネクションを待ち受けるための環境条件より、コネクションを確立しに行くことを可能にする環境条件の方が緩い。たとえば、機器とネットワーク101の間に、外から内への通信を制御するゲートウェイがある環境を想定する。ゲートウェイは不適切な通信を遮断することで内側の環境を健全に保つ。コネクションを待ち受けることを可能にするためには、ゲートウェイは常に固定のポートへの通信を許可しなければならず、そのポート宛ての意図しない通信を遮断するために別の対策を講じる必要がある。一方、確立しに行くことを可能にするためには、内側から外側へ通信があったタイミングでのみ、その返事用の、外から内への通信を許可するだけでよい。その返事としてふさわしくない発信者からの通信を遮断するのは容易である。このように、構築しやすい環境をクライアント側の条件にすることで、一般ユーザーがアクセスするサービスといったモデルに適用しやすくしている。
【0044】
図3は、クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。
なお、本図において実線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信を示す。一点鎖線の矢印は、クライアント側通信集積部202とサーバ側通信分散部303との、クライアント側通信部204及びサーバ側通信部304を介しての通信を示す。
【0045】
クライアント側並列通信部201は、ブラウザ205からコンテンツ受信要求を受けると、一つ目のTCPコネクション#0(以下「プライマリコネクション#0」と呼ぶ。)を確立する。クライアント側並列通信部201は、Transfer−Encodingヘッダ(以下単に「TEヘッダ」と呼ぶ。)に値"mtcp"を指定したHTTP GET要求を生成する。クライアント側並列通信部201は、生成したHTTP GET要求を、クライアント側通信部204によりプライマリコネクション#0を用いてサーバ装置300へ送信させる(ステップS101)。
【0046】
サーバ側並列通信部301は、サーバ側通信部304を介してクライアント側並列通信部201からHTTP GET要求を受信すると、バックエンドサービス305にデータの送信要求を行う。ターゲットデータの場所はリクエストのURLで特定される。バックエンドサービス305は、クライアント装置200に要求されたデータをサーバ側通信分散部303の送信バッファ(図示せず。)に格納する。
【0047】
そして、サーバ側並列通信部301は、そのサーバ装置300でユニークであるsession‐idを発行する。また、サーバ側並列通信部301は、HTTP GET要求によってダウンロードが要求されたデータを送信するのに適切なTCPコネクションの上限数を定める(たとえば8Mbpsストリーミングコンテンツで、TCP1本あたり3Mbpsの環境であれば3本)。サーバ側並列通信部301は、HTTP GET要求に対する応答として、session‐id及びTCPコネクションの上限の値を示したHTTP応答(200 OK)を生成する。このHTTP応答(200 OK)のTEヘッダには、値"mtcp"が指定される。サーバ側並列通信部301は、生成したHTTP応答(200 OK)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS102)。そして、サーバ側並列通信部301は、受信したHTTP GET要求によってダウンロードが要求されたデータをサーバ側通信分散部303に通知する。
【0048】
ここで、HTTP応答(200 OK)は、MTCP−sessionヘッダを含む。MTCP−sessionヘッダのシンタックスは、"MTCP-Session" ":" session-id "," tid["," con]である。ここで、"session−id"は、同一のセッションに属するコネクションを特定する整数である。"tid"(トランザクションID、データ特定情報)は、送信すべきデータを識別するための整数すなわちトランザクションを特定する整数であり、一つのセッションの存続期間中固有の値が用いられる。"con"(コネクション上限情報)は、サーバ装置300が当該クライアント装置200に対して対応可能なTCPコネクションの上限(最大本数)を示す整数である。なお、"con"は、特定のセッション中初回のトランザクションの場合には必ず必要であるが、以前の値と等しい値を用いる場合には省略してもよい。また、サーバ装置300が適切なコネクションの本数(コネクションの上限)を決定するものとする。これは、複数のクライアント装置200に対する多数の接続を処理しなければならないサーバ装置300の方が、クライアント装置200に比べて処理能力の制限の影響が出やすいためである。
【0049】
本図のステップS102では、"tid=1"及び"con=4"が設定された例を示している。すなわち、このトランザクションは1つ目のトランザクションであり("tid=1")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は4本である("con=4")、ということが示されている。
【0050】
サーバ側通信分散部303は、バックエンドサービス305により送信バッファに格納されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304によりプライマリコネクション#0を用いて装置200へ送信させる(ステップS103、S104)。なお、サーバ側通信分散部303は、クライアント側並列通信部201により2つ目以降(本例では最大4本)のTCPコネクションが確立されるまでの間、各チャンクをサーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる。
【0051】
ここで、各チャンクにはチャンクヘッダが記載されている。チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。ここで、"chunk‐size"は、当該チャンクの長さを示す。"chunk‐seq"(前後関係識別情報)は、分割元のデータにおける位置関係を識別するための、チャンクのシーケンス番号(通し番号)を示す。なお、最初のチャンクの"chunk‐seq"はランダム値であり、それ以降のチャンクはどのTCPコネクションを通ったとしても(ここではプライマリコネクション#0)、データ分割前の順番でインクリメントされた値が記載される。start directiveとして記載される値である"start‐seq"は、そのトランザクションで最初のチャンクのchunk‐seqを示す。"tid"は、HTTP応答(200 OK)に含まれるtidの値を示す。なお、"n"、"cmd‐seq"に関してはのちに説明する。
【0052】
本図のステップS103では、"chunk‐seq:1a21"、"start‐seq:1a21"及び"tid=1"が設定された例を示している。すなわち、このチャンクのシーケンス番号は1a21であり("chunk‐seq:1a21")、このトランザクションで最初のチャンクのシーケンス番号は1a21であり("start‐seq:1a21")、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。そして、本図のステップS104では、シーケンス番号1a21のチャンクに続いて、シーケンス番号1a22のチャンク("chunk‐seq:1a22")が送信される。なお、本図では、ステップS104で送信するチャンクのチャンクヘッダの記載を一部省略している。
【0053】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300よりプライマリコネクション#0を用いて送信された各チャンクを受信する。クライアント側通信集積部202は受信バッファ(図示せず。)を有し、受信したチャンクを一旦受信バッファに保存する。
【0054】
一方、クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(200 OK)(ステップS102)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認する。すなわちクライアント側並列通信部201は、サーバ装置300がクライアント装置200に対してに対して対応可能なTCPコネクションの上限を確認する。クライアント側並列通信部201は、"con"が2以上と判定すると、2本目以降のTCPコネクション(以下「セカンダリコネクション」と呼ぶ。)を確立する。本例では、"con=4"であるので、クライアント側並列通信部201は、プライマリコネクション#0を含めて計4本のTCPコネクションを確立する。すなわちクライアント側並列通信部201は、3本のセカンダリコネクション#1、#2、#3を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、確立したセカンダリコネクション#1、#2、#3それぞれを用いてサーバ側並列通信部301へ並列に送信させる(ステップS105〜S107)。
【0055】
なお、通常、クライアント側並列通信部201は、MTCP−sessionヘッダに含まれる"con"の値によって指定された上限になるようにセカンダリコネクションを確立する。しかしながら、たとえば別処理のため十分な処理能力がない場合など、指定された本数のセカンダリコネクションを確立することができない場合には、クライアント側並列通信部201は、この上限の範囲で可能な本数のセカンダリコネクションを確立すればよい。
【0056】
ここで、クライアント側並列通信部201は、HTTP CONNECT要求のMTCP−sessionヘッダの値には、ステップS102で受信したsession‐idを指定し、TEヘッダに"mtcp"を指定する。
【0057】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#1、#2、#3それぞれを通じてサーバ側通信部304を介して受信する。サーバ側並列通信部301は、受信したHTTP CONNECT要求に示されるsession‐idを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。本例では、サーバ側並列通信部301は、セカンダリコネクション#1、#2、#3それぞれを通じて受信したHTTP CONNECT要求に示されるsession‐idを参照し、これらのセカンダリコネクション#1、#2、#3がプライマリコネクション#0に属すると判断する。なお、該当するsession‐idが存在しない場合や、セカンダリコネクションの本数が上限を超えている場合には、サーバ側並列通信部301は、サーバ側通信部304により、エラーをクライアント装置200に送信させる。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#1、#2、#3それぞれを用いてクライアント装置200に並列に送信させる(ステップS108〜S110)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#1、#2、#3をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0058】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#1、#2、#3をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。以上で、並列通信の開始処理が完了する。
【0059】
サーバ側通信分散部303は、サーバ側並列通信部301からセカンダリコネクション#1、#2、#3の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200に並列に送信させる(ステップS111〜S120)。
【0060】
なお、サーバ側通信分散部303は、各TCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)毎の送信ソケットバッファを監視し、何れかのTCPコネクションの送信ソケットバッファに空きができたら、サーバ側通信分散部303が持つ送信バッファの未送信データをさらにチャンクに分割して、その空きができた送信ソケットバッファに移動してもよい。
【0061】
本図では、サーバ側通信分散部303は、ステップS103、S104で既に"chunk‐seq:1a21"、"chunk‐seq:1a22"により示される各チャンクをサーバ側通信部304に送信させている。したがって、サーバ側通信分散部303が続いてサーバ側通信部304に送信させるチャンクの"chunk‐seq"(シーケンス番号)は、順に、1a23、1a24、1a25…1a2a、1a2b、1a2cのようになる。例えば、ステップS112で送信するチャンクのチャンクヘッダとして、"chunk‐seq:1a24"、"start‐seq:1a21"、"tid=1"が設定されている。すなわち、このチャンクのシーケンス番号は1a24であり("chunk‐seq:1a24")、このトランザクションで最初のチャンクのシーケンス番号は1a21であり("start‐seq:1a21")、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。なお、本図では、ステップS111〜S120で送信するチャンクのチャンクヘッダの記載を一部省略している。また、以下の図においてもチャンクヘッダの記載を一部省略している箇所がある。
【0062】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300よりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いて送信された各チャンクを受信する。クライアント側通信集積部202は、何れのTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。クライアント側通信集積部202は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをブラウザ205に受信データとして供給する。クライアント側通信集積部202は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、クライアント側通信集積部202は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがサーバ装置300より届くのを待つ。
【0063】
サーバ側通信分散部303は、サーバ側通信部304に、1つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをクライアント装置200へ送信させる(ステップS120)。続いて、サーバ側通信分散部303は、サーバ側通信部304に、プライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS121)。
【0064】
ここで、zeroチャンクとは、チャンクヘッダのみでデータをもたないチャンクである。zeroチャンクの書式は、例えば、0; [con=n;cseq=cmd-seq];last=last-seqである。"last‐seq"は、1つのデータより分割された複数のチャンクの末尾のシーケンス番号、すなわち1つのトランザクションで最後のチャンクのシーケンス番号を示す。なお、"n"、"cmd‐seq"は後述する。
【0065】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300より送信されたzeroチャンクを受信する。クライアント側通信集積部202は、zeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をブラウザ205に通知する。これにより、1つのトランザクションが終了する。
【0066】
続いて、さらに別のトランザクションが行われる(ステップS122〜S127)。以下の説明において、既に説明したデータ通信方法と同様の工程等については説明を省略又は簡略化し、異なる点を中心に説明する。
【0067】
本図のステップS123では、HTTP応答(200 OK)に"tid=2"及び"con=4"が設定された例を示している。すなわち、このトランザクションは2つ目のトランザクションであり("tid=2")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は従来と同じ4本である("con=4")、ということが示されている。したがって、クライアント装置200は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ4本のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を引き続き用いればよい。
【0068】
[2.クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法]
図4は、クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。
ブラウザ205は、UI206を通して入力されるユーザからのコンテンツ送信要求を受け、クライアント側並列通信部201にコンテンツ送信要求を通知すると共に、クライアント側通信分散部203の送信バッファ(図示せず。)に送信すべきデータを配置する。クライアント側並列通信部201は、ブラウザ205からコンテンツ送信要求を受けると、一つ目のTCPコネクション#0(プライマリコネクション#0)を確立する。クライアント側並列通信部201は、TEヘッダに値"mtcp"を指定したHTTP PUT要求を生成する。クライアント側並列通信部201は、生成したHTTP PUT要求を、クライアント側通信部204によりプライマリコネクション#0を用いてサーバ装置300へ送信させる(ステップS201)。
【0069】
ここで、プライマリコネクション#0確立後最初のHTTP PUT要求は、Expectヘッダを含む。このExpectヘッダの値は、"100‐Continue"である。
【0070】
サーバ側並列通信部301は、サーバ側通信部304を介してクライアント側並列通信部201からHTTP PUT要求を受信すると、そのサーバ装置300でユニークであるsession‐idを発行する。また、サーバ側並列通信部301は、HTTP PUT要求によってアップロードが要求されたデータを送信するのに適切なTCPコネクションの上限を定める。サーバ側並列通信部301は、HTTP PUT要求に対する応答として、上記session‐id、tid、con(TCPコネクションの本数の上限)を示したHTTP応答(100‐Continue)を生成する。このHTTP応答(100‐Continue)のTEヘッダには、値"mtcp"が指定される。サーバ側並列通信部301は、生成したHTTP応答(100‐Continue)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS202)。
【0071】
ここで、HTTP応答(100‐Continue)は、同一のセッションに属するコネクションを特定する"session−id"、トランザクションを特定する"tid"、TCPコネクションの上限を示す"con"等を含む。
【0072】
本図のステップS202では、"tid=3"及び"con=4"が設定された例を示している。すなわち、このトランザクションは3つ目のトランザクションであり("tid=3")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は4本である("con=4")、ということが示されている。
【0073】
クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(100‐Continue)(ステップS202)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認し、2本目以降のTCPコネクションを確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、確立したセカンダリコネクション#1、#2、#3それぞれを用いてサーバ側並列通信部301へ並列に送信させる(ステップS203〜S205)。
【0074】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#1、#2、#3それぞれを通じてサーバ側通信部304を介して受信する。サーバ側並列通信部301は、受信したHTTP CONNECT要求に示されるsession‐idを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#1、#2、#3それぞれを用いてクライアント装置200に並列に送信させる(ステップS206〜S208)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#1、#2、#3をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0075】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#1、#2、#3をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。以上で、並列通信の開始処理が完了する。
【0076】
クライアント側通信分散部203は、通知を受けると、ブラウザ205によって送信バッファに配置されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、クライアント側通信分散部203は、シーケンス番号を付した複数のチャンクを、クライアント側通信部204によりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いてサーバ装置300へ送信させる(ステップS209〜S218)。
【0077】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200よりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いて送信された各チャンクを受信する。サーバ側通信集積部302は、何れのTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。サーバ側通信集積部302は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをウェブサーバ306に受信データとして供給する。サーバ側通信集積部302は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、サーバ側通信集積部302は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがクライアント装置200より届くのを待つ。
【0078】
クライアント側通信分散部203は、クライアント側通信部204に、1つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをサーバ装置300へ送信させる(ステップS218)。続いて、クライアント側通信分散部203は、クライアント側通信部204に、プライマリコネクション#0を用いてzeroチャンクをサーバ装置300へ送信させる(ステップS219)。
【0079】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200より送信されたzeroチャンクを受信する。サーバ側通信集積部302は、zeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部301に通知する。
【0080】
サーバ側並列通信部301は、データ受信完了の通知を受けると、HTTP応答(200 OK)を生成し、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS220)。
【0081】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、データのアップロードの完了を判断する。これにより、1つのトランザクションが終了する。
【0082】
続いて、さらに別のトランザクションが行われる(ステップS221〜S227)。本図のステップS222では、HTTP応答(100−Continue)に"tid=4"及び"con=4"が設定された例を示している。すなわち、このトランザクションは4つ目のトランザクションであり("tid=4")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は従来と同じ4本である("con=4")、ということが示されている。したがって、クライアント装置200は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ4本のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を引き続き用いればよい。
【0083】
[3.データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法]
図5は、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS101〜S110)。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200へ並列に送信させる(ステップS111〜S114)。
【0084】
ここで、バックエンドサービス306が、クライアント装置200向けに処理可能なTCPコネクションの上限が増えたと判断したとする。その場合、バックエンドサービス306は、サーバ側並列通信部301にTCPコネクションの上限の増加を通知し、サーバ側並列通信部301は、サーバ側通信分散部303にTCPコネクションの上限の増加を通知する。サーバ側通信分散部303は、通知を受けると、次回クライアント装置200へ送信すべきチャンクに付随するチャンクヘッダを次のように書き換える。上述のように、チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。サーバ側通信分散部303は、"con=n"に、サーバ側並列通信部301からの通知に含まれるTCPコネクションの上限(例えば"con=5")を指定する。さらに、サーバ側通信分散部303は、"cmd‐seq"に、前回のcmd‐seqの値をインクリメントした値を指定する。なお、最初はランダム値とする。サーバ側通信分散部303は、このように書き換えたチャンクヘッダを付したチャンクを、任意のTCPコネクション(例えば、プライマリコネクション#0)を用いてクライアント装置200に送信させる(ステップS301)。
【0085】
ここで、"cmd‐seq"とは、コネクション上限情報の変更に伴い順次更新される、コネクション本数の変更の要求の順番を示す整数である。本実施形態のような並列通信では、サーバ側通信分散部303がサーバ側通信部304に送信させたデータ(複数のチャンク)が、異なるTCPコネクションを経由してクライアント側通信集積部202に届いたとき、データの到達順序が変わってしまう可能性がある。たとえばサーバ側通信分散部303は、"con=1"及び"cmd‐seq=1"を指定したチャンクヘッダを含むチャンクA、"con=4"及び"cmd‐seq=2"を指定したチャンクヘッダを含むチャンクB、"con=2"及び"cmd‐seq=3"を指定したチャンクヘッダを含むチャンクCをこの順にサーバ側通信部304に送信させるとする。しかし、クライアント側通信集積部202は、チャンクA("con=1"、"cmd‐seq=1")、チャンクC("con=2"、"cmd‐seq=3")、チャンクB("con=4"、"cmd‐seq=2")の順で、クライアント側通信部204を介してこれらのチャンクを受信したとする。クライアント側通信集積部202は、受信した複数のチャンクに含まれるcmd‐seqの値を比較し、もっとも大きい値が設定されたcmd‐seqを判定する。そして、クライアント側通信集積部202は、もっとも大きい値が設定されたcmd‐seqを含むチャンクヘッダが、最新のconを示すものと判断する。このように、cmd‐seqを設定することで、データの到達順序が変わっても、クライアント側通信集積部202は、最新のTCPコネクションの上限を判断することができる。
【0086】
クライアント側通信集積部202は、クライアント側通信部204を介してサーバ側通信分散部303よりチャンクを受信すると、チャンクヘッダのcmd‐seqの値を確認する。クライアント側通信集積部202は、cmd‐seqに従来の値と異なる値が設定されていると判定すると、そのチャンクヘッダのconの値すなわちTCPコネクションの上限をクライアント側並列通信部201に通知する。
【0087】
クライアント側並列通信部201は、クライアント側通信集積部202からTCPコネクションの上限を取得すると、新たなTCPコネクション(セカンダリコネクション#4)を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、新たに確立したセカンダリコネクション#4を用いてサーバ側並列通信部301へ並列に送信させる(ステップS302)。
【0088】
サーバ側並列通信部301は、HTTP CONNECT要求をセカンダリコネクション#4を通じてサーバ側通信部304を介して受信すると、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#4を用いてクライアント装置200に送信させる(ステップS303)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#4をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0089】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#4をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。
【0090】
サーバ側通信分散部303は、サーバ側並列通信部301からセカンダリコネクション#4の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3、#4)を用いてクライアント装置200へ並列に送信させ、最後にプライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS304〜S309)。
【0091】
[4.データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法]
図6は、データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS201〜S208)。そして、クライアント側通信分散部203は、シーケンス番号を付した複数のチャンクを、クライアント側通信部204に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてサーバ装置300へ並列に送信させる(ステップS209〜S212)。
【0092】
ここで、サーバ側並列通信部301が、サーバ装置300側でクライアント装置200向けに処理可能なTCPコネクションの上限が増えたと判断したとする。その場合、サーバ側並列通信部301は、この新しいTCPコネクションの上限をconに指定したMTCP‐sessionヘッダを有するHTTP応答(100‐Continue)を生成する。サーバ側並列通信部301は、生成したHTTP応答(100‐Continue)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS401)。
【0093】
クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(100‐Continue)(ステップS401)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認する。すなわちクライアント側並列通信部201は、サーバ装置300が対応可能なTCPコネクションの上限を確認し、新たなTCPコネクション(本例ではセカンダリコネクション#4)を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、新たに確立したセカンダリコネクション#4を用いてサーバ側並列通信部301へ並列に送信させる(ステップS402)。
【0094】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#4を通じてサーバ側通信部304を介して受信する。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#4を用いてクライアント装置200に並列に送信させる(ステップS403)。そして、サーバ側並列通信部301は、新たに確立されたセカンダリコネクション#4をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0095】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#4をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。
【0096】
クライアント側通信分散部203は、クライアント側並列通信部201からセカンダリコネクション#4の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3、#4)を用いてクライアント装置200へ並列に送信させ、最後にクライアント側通信部204に、プライマリコネクション#0を用いてzeroチャンクをサーバ装置300へ送信させる(ステップS404〜S409)。
【0097】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200より送信されたzeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部301に通知する。サーバ側並列通信部301は、データ受信完了の通知を受けると、HTTP応答(200 OK)を生成し、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS410)。
【0098】
[5.データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法]
図7は、データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。
ここでは、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法について説明する。
【0099】
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS101〜S110)。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200へ並列に送信させる(ステップS111〜S114)。
【0100】
ここで、サーバ側並列通信部301が、サーバ装置300側でクライアント装置200向けに処理可能なTCPコネクションの本数を減らすよう判断したとする。ここで、TCPコネクションの本数を減らすためには、減らす対象のTCPコネクションで通信されているデータを止めてからでないと、データの欠損が起きてしまう。それを防ぐため、以下の方法でTCPコネクションの本数を減らす。
【0101】
サーバ側並列通信部301は、サーバ側通信分散部303に、TCPコネクションの本数を減少するよう通知する。サーバ側通信分散部303は、通知を受けると、サーバ側通信部304により、減らす対象のセカンダリコネクションを用いて、クライアント装置200に、zeroチャンクを送信する。ここで、zeroチャンクの書式は、例えば、"0; con=n;cseq=cmd-seq"である。
【0102】
本例では、現在4本のTCPコネクション(プライマリコネクションを含む)を用いていて、そのうち2本セカンダリコネクションを切断して2本のTCPコネクションにする場合を示す。サーバ側通信分散部303は、切断対象の2本のセカンダリコネクション(例えばセカンダリコネクション#2、#3)を任意に選択する。サーバ側通信分散部303は、サーバ側通信部304により、選択したセカンダリコネクション#2、#3を用いて、con=2を指定した上記zeroチャンクをクライアント装置200へ送信する(ステップS501、S502)。
【0103】
なお、通常チャンクはプライマリコネクションでダウンロード/アップロードが行われた後に通信される。しかし、上記zeroチャンクは、ダウンロード/アップロードが完了した後でも、任意のタイミングでサーバ装置300からクライアント装置200に対して送信してよい。
【0104】
サーバ側通信分散部303は、サーバ側通信部304によりzeroチャンクをクライアント装置200へ送信すると、切断対象のセカンダリコネクション#2、#3を用いた新たなチャンクの送信を停止する。そして、サーバ側通信分散部303は、クライアント装置200によりセカンダリコネクション#2、#3が切断されるのを待つ。しかしながら、PUT用のチャンクがクライアント側通信分散部203からサーバ側通信集積部302に届く可能性があるので、サーバ側通信集積部302は、セカンダリコネクション#2、#3が切断されるまではチャンク受信に備えておく。これは、サーバ側通信分散部303が上記zeroチャンクを送信するのとほぼ同じタイミングでクライアント装置200がアップロード処理を開始した場合を考慮したものである。すなわちこのような場合、zeroチャンクがクライアント装置200に届く前に、クライアント側通信分散部203がクライアント側通信部204にアップロード用のチャンクをセカンダリコネクション#2、#3を用いて送信させる可能性があるからである。
【0105】
その後、サーバ側通信分散部303は、複数のチャンクを、サーバ側通信部304に、切断したセカンダリコネクション#2、#3を除く任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1)を用いてクライアント装置200へ並列に送信させる(ステップS503、S504)。続いて、サーバ側通信分散部303は、サーバ側通信部304に、プライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS505)。
【0106】
以上、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法について説明したが、データ通信(アップロード)の最中であれば、以下のように処理を行えばよい。すなわち、クライアント側通信分散部203は、上記zeroチャンクを受けて、もしアップロード用のチャンクの送信中であれば、新たなチャンクの送信を停止する。そして、クライアント側通信分散部203は、送信済みのチャンクがサーバ装置300に到着したのを確認してから切断対象のコネクションを切断する。なお、クライアント側通信分散部203は、送信済みのチャンクがサーバ装置300に到着したのを確認する技術については、TCP等、信頼性のあるトランスポートが前提であれば可能である。
【0107】
本実施形態によれば、セカンダリコネクションの本数を動的に増減することでスループットを調節することができる。動的なセカンダリコネクションの本数の制御は、例えば、以下のような場合に有用である。
【0108】
経路のリンク速度をL、1本あたりのTCPコネクションのスループットをTとするとき、nT<Lである最大の自然数n本のコネクションを確立すれば、最大のスループットを得ることができる。なお、nをそれ以上大きくしてもリンク速度Lの制約のためエラーが起こってしまい、スループットを得ることはできない。
【0109】
また、たとえばストリーミングのように必要なスループット(Qとする、また、Q<Lとする)が決まっている場合には、それに必要なスループット以上の本数を確立しても意味がない。この場合、mT>Qとなる最小のm本のTCPコネクションを確立すればよい。
【0110】
また、1つのサーバ装置300と複数のクライアント装置200とが同時期に通信を行うケースでは、サーバ装置300の処理能力の制限のため、クライアント装置200一つあたりに提供できるスループットが制限される。クライアント装置200の数が増えてきたときには既接続クライアント装置200へのスループットを下げることにより、新規クライアント装置200へのスループットと同等にすることができる。これにより、複数のクライアント装置200間で公平にサービスを行うことができる。
【0111】
[6.クライアント装置がサーバ装置にGET要求を送信し、サーバ装置300からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)]
まず、従来のHTTPのパイプラインについて説明しておくこととする。HTTPのパイプラインとは、クライアントがあるHTTPリクエストを送信し、それに対応するレスポンスが到着する前に、さらに次以降のHTTPリクエストを送信するものである。サーバがパイプラインに対応していれば、次以降のHTTPリクエストはサーバ側でキューイングされ、順番に処理されてHTTPレスポンスが返る。
【0112】
このように、レスポンスを待たずに次のリクエストを送ることができるのがHTTPのパイプラインであるが、レスポンスの順番はリクエストの順番通りであった。これは、一本のTCP上で異なるリクエストのための情報を同時に扱うことができないためである。このため、たとえばひとつのリクエストの処理に時間がかかると、他の本来処理時間が短くて済むはずのリクエストも応答に時間がかかってしまうという問題があった。
【0113】
図8は、クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
本図において実線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信(ダウンロード)を示す。一点鎖線の矢印は、クライアント側通信集積部202とサーバ側通信分散部303との、クライアント側通信部204及びサーバ側通信部304を介しての通信(ダウンロード)を示す。点線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信(アップロード)を示す。破線の矢印は、クライアント側通信分散部203とサーバ側通信集積部302との、クライアント側通信部204及びサーバ側通信部304を介しての通信(アップロード)を示す。
【0114】
まず、クライアント側並列通信部201は、HTTP GET要求をクライアント側通信部204によりサーバ装置300へ送信させる(ステップS601)。クライアント側並列通信部201は、HTTP GET要求に対する応答をサーバ装置300から取得する前に、HTTP PUT要求をクライアント側通信部204によりサーバ装置300へ送信させたとする(ステップS602)。
【0115】
本例のステップS603では、HTTP応答(200 OK)に"tid=5"が設定された例を示している。すなわち、このトランザクションは5つ目のトランザクションである("tid=5")、ということが示されている。また、ステップS607、S608、S617〜S622では、ダウンロードされるデータの各チャンクに"tid=5"が設定されている。
【0116】
一方、本例のステップS612では、HTTP応答(100‐Continue)に"tid=6"が設定された例を示している。すなわち、このトランザクションは6つ目のトランザクションである("tid=6")、ということが示されている。また、ステップS613〜S615では、アップロードされるデータの各チャンクに"tid=6"が設定されている。
【0117】
ここで、通信されるチャンクに着目すると、まず、ステップS607、S608で、ダウンロード対象のデータのうち一部のチャンク(tid=5)がダウンロードされる。次に、ステップS613〜S616で、アップロード対象のデータのうち全てのチャンク(tid=6)がアップロードされる。最後に、ステップS617〜S623で、ダウンロード対象のデータのうち残りのチャンク(tid=5)がダウンロードされる。本実施形態では、ダウンロード対象のデータに属するチャンクを全てダウンロードし、その後アップロード対象のデータに属するチャンクを全てアップロードする、という順序でデータの通信を必ずしも行う必要がない。
【0118】
本実施形態では各チャンクそれぞれにトランザクションID(tid)を付与している。これにより、受信側(アップロードの場合サーバ装置300、ダウンロードの場合クライアント装置200)がトランザクションIDを参照すれば、データ通信の順番に関わらず、同一のトランザクションID(tid)を有するチャンク毎にデータを復元することができる。例えば、クライアント装置200は、複数のデータをダウンロードする際、一方のデータから分割されたデータであるチャンク及び他方のデータから分割されたデータであるチャンクを、これらが混在するような順番で受信する可能性がある。このような場合であっても、クライアント装置200は、それぞれのデータを特定するtidを参照することで、同一のtidを有するチャンク毎に複数のデータをそれぞれ復元することができる。
【0119】
本実施形態によれば、HTTP要求がパイプラインされたあと、コネクションがどのトランザクション(どの要求)のために使用されているかをトランザクションID(tid)で示している。これにより、従来のHTTPレスポンスのヘッダに関してはリクエストの順序通りに返されなければならなかったが、本実施形態では必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送受信したりできる。
【0120】
[7.クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)]
図9は、クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
本図において実線の矢印は、クライアント装置200とサーバ装置300とのデータ通信(あるデータをダウンロード)を示す。二点鎖線の矢印は、クライアント装置200とサーバ装置300とのデータ通信(別のデータをダウンロード)を示す。一点鎖線の矢印は、セカンダリコネクション確立処理を示す。
【0121】
まず、クライアント側並列通信部201は、1つ目のHTTP GET要求(HTTP GET要求1とする。)をクライアント側通信部204によりサーバ装置300へ送信させる(ステップS701)。クライアント側並列通信部201は、HTTP GET要求1に対する応答を取得する前に、2つ目のHTTP GET要求(HTTP GET要求2とする。)をクライアント側通信部204によりサーバ装置300へ送信させたとする(ステップS702)。
【0122】
本例のステップS703では、HTTP応答(200 OK)に"tid=1"が設定された例を示している。すなわち、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。また、ステップS716〜S720では、ダウンロードされるデータの各チャンクに"tid=1"が設定されている。
【0123】
一方、本例のステップS710では、HTTP応答(200 OK)に"tid=2"が設定された例を示している。すなわち、このトランザクションは2つ目のトランザクションである("tid=2")、ということが示されている。また、ステップS711〜S714では、ダウンロードされるデータの各チャンクに"tid=2"が設定されている。
【0124】
これらHTTP応答(200 OK)は、HTTP GET要求の順序通りに返される。したがって、クライアント側並列通信部201は、自分の発行したHTTP GET要求にどのようなトランザクションIDが付与されたかを、HTTP応答(200 OK)のヘッダを参照することで知ることができる。
【0125】
ここで、通信されるチャンクに着目すると、まず、ステップS711〜S715で、HTTP GET要求2で指定されたダウンロード対象のデータのチャンク(tid=2)がダウンロードされる。次に、ステップS716〜S720で、HTTP GET要求1で指定されたダウンロード対象のデータのチャンク(tid=1)がダウンロードされる。本実施形態では、HTTP GET要求1で指定されたダウンロード対象のデータに属するチャンクをダウンロードし、その後HTTP GET要求2で指定されたダウンロード対象のデータに属するチャンクをダウンロードする、という順序でデータの通信を必ずしも行う必要がない。本実施形態では各チャンクそれぞれにトランザクションID(tid)を付与しているので、受信側であるクライアント装置200がトランザクションID(tid)を参照すれば、データ通信の順番に関わらず、同一のトランザクションIDを有するチャンク毎にデータを復元することができる。
【0126】
より具体的に、セカンダリコネクション#1を用いた通信に注目して説明する。まず、クライアント側通信集積部202は、クライアント側通信部204を介してseq:1a26 start:1a25 tid:2 のチャンクを受信する(ステップS712)。クライアント側通信集積部202は、このチャンクがHTTP GET要求2の、2つ目のチャンクであると判断する。続いて、クライアント側通信集積部202は、クライアント側通信部204を介してseq:1a22 start:1a21 tid:1 を受信する(ステップS717)。クライアント側通信集積部202は、この一つ前まででセカンダリコネクション#1上ではHTTP GET要求2に関するデータ(チャンク)の受信は完了し、今届いたチャンクはHTTP GET要求1の2番目のチャンクであると判断する。
【0127】
本実施形態では、送られるデータがどのリクエストに対応するものかを示すため、あるコネクション上で送られるデータがどのトランザクションのためのものかを示すtidを、チャンクに付記している。これにより、HTTPリクエストがパイプラインされたあと、コネクションがどのトランザクション(どのリクエスト)のために使用されているかをトランザクションID(tid)で示すことによって、受信側装置は、データ通信の順番に関わらずデータを復元することができる。これにより、送信側装置は、必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送ったりできるようにしている。
【0128】
[8.意図しないTCPコネクション切断からのデータ復帰方法(ダウンロード時)]
次に、通信障害等や、通信相手機器の事情により、複数のセカンダリコネクションのうち一部が意図せずに切断されてしまった場合について説明する。このような場合、以下のようにデータの完全性を保つことができる。
【0129】
まず、サーバ装置300の処理について説明する。1以上のセカンダリコネクションが切断されたとき、サーバ側通信分散部303は、サーバ側通信部304により、切断されたセカンダリコネクションで送信中であったチャンクを、改めて他のコネクションに振り分けてクライアント装置200へ送信させる。一方、クライアント側通信集積部202は、クライアント側通信部204を介して受信したチャンクの"chunk-seq"を参照する。サーバ側通信分散部303がチャンクの送信が失敗したと判断して同一のチャンクを再送信した場合、実は両方の送信が成功しており、クライアント側通信集積部202が同一のチャンクを重複して取得してしまうような場合がある。しかしながら、クライアント側通信集積部202は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。
【0130】
次に、クライアント装置200の処理について説明する。1以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部201は、その時点で確立してもよい上限を超えない限り、HTTP CONNECTを用いて最初に張ったときと同じSession idを指定してセカンダリコネクションを再確立する。切断されたコネクションを用いて送信中であったチャンクがあった場合は、サーバ装置300により新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いて再転送されることが期待される。上述のように、クライアント側通信集積部202は、チャンクの"chunk-seq"を参照することにより重複したチャンクを検出できる。転送されない場合は、HTTP GET要求を改めてRangeヘッダでその欠損チャンクの位置のみを指定して行うことで解決することができる。なお、上記説明したパイプラインの処理により、クライアント側並列通信部201は、元のHTTP GET要求が終了する前にでも、クライアント側通信部204により穴埋めのためのHTTP GET要求を並列に送信させることができる。
【0131】
[9.意図しないTCPコネクション切断からのデータ復帰方法(アップロード時)]
まず、クライアント装置200の処理について説明する。1以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部201は、その時点で確立してもよい上限を超えない限り、HTTP CONNECTを用いて最初に張ったときと同じSession idを指定してセカンダリコネクションを再確立する。切断コネクションを用いて送信中であったチャンクがあった場合は、クライアント側通信分散部203は、クライアント側通信部204により、新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いてそのチャンクを再送信させる。サーバ側通信集積部302は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。
【0132】
次に、サーバ装置300の処理について説明する。サーバ側通信集積部302は、1以上のセカンダリコネクションが切断されたときでも、残ったコネクションを用いてサーバ側通信部304を介してそのままデータ受信を続ける。切断されたコネクションで送信中であったチャンクがあった場合は、クライアント装置200により残ったコネクションを用いて再転送されることが期待される。サーバ側通信集積部302は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。サーバ側通信集積部302は、zeroチャンクを受信した時点でデータ(チャンク)に欠損があった場合には、HTTPのエラーをサーバ側通信部304によりクライアント装置200へ送信させる。
【0133】
[クライアント装置のハードウェア構成]
次に、クライアント装置200及びサーバ装置300のハードウェア構成について説明する。
【0134】
図10は、クライアント装置のハードウェア構成を示すブロック図である。
クライアント装置200において、CPU(Central Processing Unit)612には、システムバス613を介して、入力操作部601と、クライアント側通信部204と、記憶部604と、デコード部605と、表示部606と、メディアインターフェース部608と、ROM(Read Only Memory)610と、RAM(Random Access Memory)611とが接続されている。
【0135】
入力操作部601は、各種のキーなどを備える。利用者は、入力操作部601を用いて各種の命令やデータの入力を処理する。利用者により入力操作部601より入力された各種の命令は、システムバス613を通じてCPU612に供給される。
【0136】
クライアント側通信部204は、グローバルなネットワーク101との接続を処理する。
【0137】
記憶部604は、HDD、SSD等よりなる。記憶部604には、クライアント側通信部204によりネットワーク101を通じてダウンロードされたコンテンツデータ等が記録される。
【0138】
デコード部605は、記憶部604から読み出されたコンテンツのデータをデコードして、デジタルビデオデータ及びデジタルオーディオデータを復元する。復元されたデジタルビデオデータはシステムバス613を通じて表示部606に供給され、デジタルオーディオデータはシステムバス613を通じてスピーカ部607に供給される。
【0139】
表示部606は、例えば、LCD(Liquid Crystal Display)などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部606は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。
【0140】
メディアインターフェース部608には、光ディスクなどのリムーバブルメディア614の装着が可能とされ、このリムーバブルメディア614にコンテンツデータなどを記録することが可能である。リムーバブルメディア614としては、例えば、追記型、書換型のDVD、ブルーレイディスクなどがある。
【0141】
ROM610には、クライアント装置200が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部604に格納されていてもよい。
【0142】
RAM611は、CPU612によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。
【0143】
CPU612は、クライアント装置200の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU612は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU612は、クライアント装置200が実行すべきソフトウェア処理を実行するために、必要なプログラムをROM610からRAM611へロードし、解釈して実行する。
【0144】
このように、クライアント装置200は、典型的なコンピュータ・ハードウェアを用いて構成される。そして、ROM610に記憶されたプログラムは、クライアント装置200のコンピュータ・ハードウェアを、図2に示す各モジュールとして機能させる。
【0145】
[サーバ装置のハードウェア構成]
図11は、サーバ装置のハードウェア構成を示すブロック図である。
サーバ装置300において、CPU(Central Processing Unit)512には、システムバス513を介して、入力操作部501と、サーバ側通信部304と、記憶部504と、表示部506と、ROM(Read Only Memory)510と、RAM(Random Access Memory)511とが接続されている。
【0146】
入力操作部501は、各種のキーなどを備える。サーバ管理者は、入力操作部501を用いて各種の命令やデータの入力を処理する。サーバ管理者により入力操作部501より入力された各種の命令は、システムバス513を通じてCPU512に供給される。
【0147】
サーバ側通信部304(ネットワーク接続部)は、グローバルなネットワーク101との接続を処理する。
【0148】
記憶部504は、HDD、SSD等よりなる。記憶部504には、サーバ側通信部304によりネットワーク101を通じてアップロードされたコンテンツデータ等が記録される。
【0149】
表示部506は、例えば、LCD(Liquid Crystal Display)などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部506は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。
【0150】
メディアインターフェース部508には、光ディスクなどのリムーバブルメディア614の装着が可能とされる。リムーバブルメディア614としては、例えば、追記型、書換型のDVD、ブルーレイディスクなどがある。
【0151】
ROM510には、サーバ装置300が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部504に格納されていてもよい。
【0152】
RAM511は、CPU512によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。
【0153】
CPU512は、サーバ装置300の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU512は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU512は、サーバ装置300が実行すべきソフトウェア処理を実行するために、必要なプログラムをROM510からRAM511へロードし、解釈して実行する。
【0154】
ROM510に記憶されたプログラムは、サーバ装置300のコンピュータ・ハードウェアを、図2に示す各モジュールとして機能させる。
【符号の説明】
【0155】
101…ネットワーク
200…クライアント装置
201…クライアント側並列通信部
202…クライアント側通信集積部
203…クライアント側通信分散部
204…クライアント側通信部
300…サーバ装置
301…サーバ側並列通信部
302…サーバ側通信集積部
303…サーバ側通信分散部
304…サーバ側通信部
【技術分野】
【0001】
本発明は、サーバ装置とクライアント装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを複数のTCPコネクションを用いて通信するデータ通信方法及び情報処理装置に関する。
【背景技術】
【0002】
従来より、HTTP(HyperText Transfer Protocol)によりインターネット上のサービスからウェブページやコンテンツなどを通信することが広く行われている。たとえば、HTTPによりデータのダウンロード(GET)やアップロード(PUT)を行うことができる。
【0003】
一般に、HTTPは一本のTCP上で行われる。TCPは非同期に双方向通信が可能なトランスポートである。HTTPでは、クライアントとしての情報処理装置とサーバとしての情報処理装置との間で、データのダウンロード(GET)やアップロード(PUT)の要求や、この要求に対する返事のやり取りが一本のTCPコネクション上で行われる。具体的には、クライアントは、アップロード要求(PUT要求)を送信すると、PUT要求に続いてアップロードするデータを送信する。一方、クライアントがダウンロード要求(GET要求)を送信すると、サーバは、GET要求に対する返事を送信し、この返事に続いてダウンロードされるデータを送信する。
【0004】
ここで、十分に広帯域であり、遅延の大きい環境でのTCPの一本あたりのスループットは、TCPのフロー制御の仕組みによって決定される。ここで、最大スループットは、ソケットあたりの受信バッファサイズ/RTT(Round Trip Time、パケット往復にかかる時間)により求められる。TCPの最大スループットが上記によって制限される場合、十分に広帯域であり、遅延の大きい環境では、リンクの本来の能力が十分に活かされないおそれがある。
【0005】
そこで、インターネットコンテンツの通信プロトコルとして、HTTPを代替する規格であるSPDYが提案されている(例えば、非特許文献1参照。)。SPDYにおいては、HTTPのレイヤが変更され、一本のTCPでも効率的にさまざまなインターネットコンテンツを送信できるように改良されている。SPDYは、HTTP由来の問題(例えば、要求された順番でデータの通信を完了する必要がある等)の解決や、ブラウザによる効率的な先読みを可能にするヒントを提供している。
【0006】
また、複数のTCPコネクションを用いてHTTPによりデータの並列転送を行う方式も提案されている(例えば、特許文献1参照。)。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2005−57482号公報
【非特許文献】
【0008】
【非特許文献1】"SPDY"、[online]、[平成22年10月18日検索]、インターネット〈URL:http://www.chromium.org/spdy〉
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、先読みとは、先読みが可能であるコンテキストでのみ有効であり、先読みが不可能なシチュエーションも多い。非特許文献1に記載の技術では、TCPのスループットの上限を超えたデータ送信はできない。
【0010】
また、特許文献1では、同時に送るデータストリームは一つであることが想定されており、複数の要求を同時に処理したり、順序を入れ替えたりすることはできない。また、TCPコネクションの接続本数が固定であるため、動的にリソースの制限や、環境の変化に対応できない。また、特許文献1では、TCPが切断された場合のデータの復帰が考慮されていない。
【0011】
以上のような事情に鑑み、本発明の目的は、HTTPによるデータ通信を高速化することが可能なデータ通信方法及び情報処理装置を提供することにある。
【課題を解決するための手段】
【0012】
上記目的を達成するため、本発明の一形態に係るデータ通信方法は、第1の情報処理装置と第2の情報処理装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のTCPコネクションを用いて通信するデータ通信方法である。
上記第1の情報処理装置は、上記第2の情報処理装置との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を上記第2の情報処理装置に通知し、上記通知するコネクション上限情報を変更して、上記第2の情報処理装置との間でのTCPコネクションの数を動的に変更する。
【0013】
本発明によれば、TCPコネクションの本数を動的に増減することでスループットを調節することができる。TCPコネクションの本数の動的な制御は、例えば、以下のような場合に有用である。1つの第1の情報処理装置(サーバ装置)と複数の第2の情報処理装置(クライアント装置)とが同時期に通信を行うケースでは、第1の情報処理装置の処理能力の制限のため、第2の情報処理装置一つあたりに提供できるスループットが制限される。第2の情報処理装置の数が増えてきたときには既接続の第2の情報処理装置へのスループットを下げることにより、新規の第2の情報処理装置へのスループットと同等にすることができる。これにより、複数の第2の情報処理装置間で公平にサービスを行うことができる。
【0014】
上記第1の情報処理装置は、上記コネクション上限情報の変更に伴いコマンドシーケンス情報を順次更新して上記第2の情報処理装置に送信する。
上記第2の情報処理装置は、受信した上記コマンドシーケンス情報をもとに、上記第1の情報処理装置からの最新のコネクション上限情報を認識する。
【0015】
第1の情報処理装置が送信した異なる複数のコネクション上限情報が、異なるTCPコネクションを経由して第2の情報処理装置に届いたとき、複数のコネクション上限情報の到達順序が送信順序と異なる可能性がある。この場合、第2の情報処理装置は、後で送信された最新のコネクション上限情報が先に送信されたコネクション上限情報より先に到達した場合であっても、コマンドシーケンス情報をもとに最新のコネクション上限情報の通知を認識できる。
【0016】
上記第1の情報処理装置は、上記コネクション上限情報及び上記コマンドシーケンス情報を、分割された各データのヘッダに付加して上記第2の情報処理装置に送信する。
【0017】
コネクション上限情報及びコマンドシーケンス情報をヘッダに付加すれば、第1の情報処理装置は、第2の情報処理装置にコネクション上限情報を通知するための要求を、分割されたデータとは別個に送信する必要がなくなる。また、第2の情報処理装置は、随時受信する分割されたデータのヘッダを参照すれば、コネクション情報の更新を直ちに認識することができる。
【0018】
上記第2の情報処理装置は、データを特定するデータ特定情報を含む送信要求を上記第1の情報処理装置に送信する。
上記第1の情報処理装置は、受信した上記送信要求に含まれる上記データ特定情報により特定される上記データを所定の単位毎に分割し、上記分割された各データのヘッダにそれぞれ上記データ特定情報を付加して上記第2の情報処理装置に送信する。
【0019】
第2の情報処理装置は、分割されたデータのヘッダに付加されたデータ特定情報を参照することで、分割されたデータを受信する順番に関わらず、同一のデータ特定情報を有する分割されたデータ毎にデータを復元することができる。例えば、第2の情報処理装置は、複数のデータをダウンロードする際、一方のデータから分割されたデータ及び他方のデータから分割されたデータを、これらが混在するような順番で受信する可能性がある。このような場合であっても、第2の情報処理装置は、それぞれのデータを特定するデータ特定情報を参照することで、同一のデータ特定情報を有する分割されたデータ毎に複数のデータをそれぞれ復元することができる。
【0020】
上記第1の情報処理装置は、上記分割されたデータのヘッダにそれぞれ、分割前の上記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する。
【0021】
これにより、分割されたデータを受信する順番に関わらず、第2の情報処理装置は、前後関係識別情報を参照して正しい順序でデータを復元することができる。
【0022】
本発明の一形態に係るデータ通信方法は、ネットワークに接続可能なネットワーク接続部と、変更手段とを有する。
上記変更手段は、上記ネットワーク接続部を通じて他の情報処理との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを上記確立された複数のTCPコネクションを用いて通信するとき、上記他の情報処理との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を上記他の情報処理に通知し、この通知するコネクション上限情報を変更して、上記他の情報処理との間でのTCPコネクションの数を動的に変更する。
【発明の効果】
【0023】
本発明によれば、HTTPによるデータ通信を高速化することができる。
【図面の簡単な説明】
【0024】
【図1】本発明の一実施形態に係るデータ通信システムの構成を示す図である。
【図2】クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。
【図3】クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。
【図4】クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。
【図5】データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
【図6】データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
【図7】データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。
【図8】クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
【図9】クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
【図10】クライアント装置のハードウェア構成を示すブロック図である。
【図11】サーバ装置のハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【0025】
以下、図面を参照しながら、本発明の実施形態を説明する。
【0026】
[データ通信システムの構成]
図1は、本発明の一実施形態に係るデータ通信システムの構成を示す図である。
情報処理システム100は、1以上のクライアント装置200と、サーバ装置300とを有する。クライアント装置200とサーバ装置300とは、グローバルなネットワーク101を介して相互に通信可能なように接続されている。なお、以下、複数のクライアント装置200のうち1つのクライアント装置200についてのみ説明することとする。
【0027】
クライアント装置200及びサーバ装置300はそれぞれ、例えばPC(Personal Computer)等の情報処理装置によって構成され、TCPコネクションを用いてHTTPによりデータを通信することが可能である。
【0028】
例えば、クライアント装置200は、HTTPによりデータのアップロード要求(以下「HTTP PUT要求」又は単に「PUT要求」と呼ぶ。)をサーバ装置300に送信し、続いて、アップロードするデータをサーバ装置300に送信する。また、クライアント装置200は、HTTPによりデータのダウンロード要求(以下「HTTP GET要求」又は単に「GET要求」と呼ぶ。)をサーバ装置300に送信する。サーバ装置300は、GET要求を受信すると、ダウンロードされるデータをクライアント装置200に送信する。このようにして、クライアント装置200はサーバ装置300にデータをアップロードするともに、サーバ装置300からデータをダウンロードすることが可能となる(所謂クラウドコンピューティング)。
【0029】
[クライアント装置及びサーバ装置の機能的な構成]
図2は、クライアント装置及びサーバ装置の機能的な構成を示すブロック図である。
クライアント装置200は、クライアント側並列通信部201と、クライアント側通信集積部202と、クライアント側通信分散部203と、クライアント側通信部204と、ブラウザ205と、UI(User Interface)206とを有する。
【0030】
UI206は、クライアント装置200とユーザの間での情報をやりとりするためのインタフェースである。
【0031】
ブラウザ205は、UI206を通して入力されるユーザからの要求を受け入れてHTTP処理し、コンテンツを解釈する等の処理を行う。
【0032】
クライアント側並列通信部201は、複数のTCPコネクションを確立して並列通信をイニシエートする等の処理を行う。
【0033】
クライアント側通信分散部203は、クライアント側通信部204により、HTTPトランザクションを複数のTCPコネクションを用いて分散して送信させる等の処理を行う。
【0034】
クライアント側通信集積部202は、クライアント側通信部204を介して複数のTCPコネクションを通して受信したコンテンツ(チャンク)を集積して元の姿に戻す等の処理を行う。
【0035】
サーバ装置300は、サーバ側並列通信部301と、サーバ側通信集積部302と、サーバ側通信分散部303と、サーバ側通信部304と、ウェブサーバ306と、バックエンドサービス305とを有する。
【0036】
ウェブサーバ306は、HTTPに則り、クライアント装置200のブラウザ205に対して、データの表示を提供する等の処理を行う。
【0037】
バックエンドサービス305は、ユーザがブラウザ205を通して要求した命令を処理する等の処理を行う。
【0038】
サーバ側並列通信部301(変更手段)は、クライアント側並列通信部201からの並列通信の要求を受けてデータを送受信するのに適切なTCPコネクションの上限数を指定する等の処理を行う。
【0039】
サーバ側通信分散部303は、サーバ側通信部304により、HTTPトランザクションを複数のTCPコネクションを用いて分散して送信させる等の処理を行う。
【0040】
サーバ側通信集積部302は、サーバ側通信部304を介して複数のTCPコネクションを通して受信したコンテンツ(チャンク)を集積して元の姿に戻す等の処理を行う。
【0041】
[データ通信方法]
次に、本実施形態に係るデータ通信方法について説明する。説明は、以下の順に行うものとする。
1.クライアント装置200がサーバ装置300からデータをダウンロードする場合のデータ通信方法
2.クライアント装置200がサーバ装置300にデータをアップロードする場合のデータ通信方法
3.データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法
4.データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法
5.データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法
6.クライアント装置200がサーバ装置300にGET要求を送信し、サーバ装置300からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)
7.クライアント装置200がサーバ装置300にGET要求を送信し、サーバ装置300からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)
8.意図しないTCPコネクション切断からのデータ復帰方法(ダウンロード時)
9.意図しないTCPコネクション切断からのデータ復帰方法(アップロード時)
【0042】
[1.クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法]
クライアント側並列通信部201は、ブラウザ205からHTTP要求(コンテンツ受信要求)を受けると、HTTP GET要求送信(ステップS101)、HTTP応答ヘッダ部受信(ステップS102)、2つ目以降のTCPコネクション確立(ステップS105〜S107)、確立したTCPコネクションをクライアント側通信集積部202及びクライアント側通信分散部203に通知、の手順で並列通信を開始する。
【0043】
なお、以下に説明するTCPコネクションの確立のイニシエートは、常にクライアント装置200からサーバ装置300に対して行う。これは、クライアント装置200からサーバ装置300へのコネクションの確立可能性を高めるためである。一般にコネクションを待ち受けるための環境条件より、コネクションを確立しに行くことを可能にする環境条件の方が緩い。たとえば、機器とネットワーク101の間に、外から内への通信を制御するゲートウェイがある環境を想定する。ゲートウェイは不適切な通信を遮断することで内側の環境を健全に保つ。コネクションを待ち受けることを可能にするためには、ゲートウェイは常に固定のポートへの通信を許可しなければならず、そのポート宛ての意図しない通信を遮断するために別の対策を講じる必要がある。一方、確立しに行くことを可能にするためには、内側から外側へ通信があったタイミングでのみ、その返事用の、外から内への通信を許可するだけでよい。その返事としてふさわしくない発信者からの通信を遮断するのは容易である。このように、構築しやすい環境をクライアント側の条件にすることで、一般ユーザーがアクセスするサービスといったモデルに適用しやすくしている。
【0044】
図3は、クライアント装置がサーバ装置からデータをダウンロードする場合のデータ通信方法を示すシーケンス図である。
なお、本図において実線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信を示す。一点鎖線の矢印は、クライアント側通信集積部202とサーバ側通信分散部303との、クライアント側通信部204及びサーバ側通信部304を介しての通信を示す。
【0045】
クライアント側並列通信部201は、ブラウザ205からコンテンツ受信要求を受けると、一つ目のTCPコネクション#0(以下「プライマリコネクション#0」と呼ぶ。)を確立する。クライアント側並列通信部201は、Transfer−Encodingヘッダ(以下単に「TEヘッダ」と呼ぶ。)に値"mtcp"を指定したHTTP GET要求を生成する。クライアント側並列通信部201は、生成したHTTP GET要求を、クライアント側通信部204によりプライマリコネクション#0を用いてサーバ装置300へ送信させる(ステップS101)。
【0046】
サーバ側並列通信部301は、サーバ側通信部304を介してクライアント側並列通信部201からHTTP GET要求を受信すると、バックエンドサービス305にデータの送信要求を行う。ターゲットデータの場所はリクエストのURLで特定される。バックエンドサービス305は、クライアント装置200に要求されたデータをサーバ側通信分散部303の送信バッファ(図示せず。)に格納する。
【0047】
そして、サーバ側並列通信部301は、そのサーバ装置300でユニークであるsession‐idを発行する。また、サーバ側並列通信部301は、HTTP GET要求によってダウンロードが要求されたデータを送信するのに適切なTCPコネクションの上限数を定める(たとえば8Mbpsストリーミングコンテンツで、TCP1本あたり3Mbpsの環境であれば3本)。サーバ側並列通信部301は、HTTP GET要求に対する応答として、session‐id及びTCPコネクションの上限の値を示したHTTP応答(200 OK)を生成する。このHTTP応答(200 OK)のTEヘッダには、値"mtcp"が指定される。サーバ側並列通信部301は、生成したHTTP応答(200 OK)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS102)。そして、サーバ側並列通信部301は、受信したHTTP GET要求によってダウンロードが要求されたデータをサーバ側通信分散部303に通知する。
【0048】
ここで、HTTP応答(200 OK)は、MTCP−sessionヘッダを含む。MTCP−sessionヘッダのシンタックスは、"MTCP-Session" ":" session-id "," tid["," con]である。ここで、"session−id"は、同一のセッションに属するコネクションを特定する整数である。"tid"(トランザクションID、データ特定情報)は、送信すべきデータを識別するための整数すなわちトランザクションを特定する整数であり、一つのセッションの存続期間中固有の値が用いられる。"con"(コネクション上限情報)は、サーバ装置300が当該クライアント装置200に対して対応可能なTCPコネクションの上限(最大本数)を示す整数である。なお、"con"は、特定のセッション中初回のトランザクションの場合には必ず必要であるが、以前の値と等しい値を用いる場合には省略してもよい。また、サーバ装置300が適切なコネクションの本数(コネクションの上限)を決定するものとする。これは、複数のクライアント装置200に対する多数の接続を処理しなければならないサーバ装置300の方が、クライアント装置200に比べて処理能力の制限の影響が出やすいためである。
【0049】
本図のステップS102では、"tid=1"及び"con=4"が設定された例を示している。すなわち、このトランザクションは1つ目のトランザクションであり("tid=1")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は4本である("con=4")、ということが示されている。
【0050】
サーバ側通信分散部303は、バックエンドサービス305により送信バッファに格納されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304によりプライマリコネクション#0を用いて装置200へ送信させる(ステップS103、S104)。なお、サーバ側通信分散部303は、クライアント側並列通信部201により2つ目以降(本例では最大4本)のTCPコネクションが確立されるまでの間、各チャンクをサーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる。
【0051】
ここで、各チャンクにはチャンクヘッダが記載されている。チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。ここで、"chunk‐size"は、当該チャンクの長さを示す。"chunk‐seq"(前後関係識別情報)は、分割元のデータにおける位置関係を識別するための、チャンクのシーケンス番号(通し番号)を示す。なお、最初のチャンクの"chunk‐seq"はランダム値であり、それ以降のチャンクはどのTCPコネクションを通ったとしても(ここではプライマリコネクション#0)、データ分割前の順番でインクリメントされた値が記載される。start directiveとして記載される値である"start‐seq"は、そのトランザクションで最初のチャンクのchunk‐seqを示す。"tid"は、HTTP応答(200 OK)に含まれるtidの値を示す。なお、"n"、"cmd‐seq"に関してはのちに説明する。
【0052】
本図のステップS103では、"chunk‐seq:1a21"、"start‐seq:1a21"及び"tid=1"が設定された例を示している。すなわち、このチャンクのシーケンス番号は1a21であり("chunk‐seq:1a21")、このトランザクションで最初のチャンクのシーケンス番号は1a21であり("start‐seq:1a21")、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。そして、本図のステップS104では、シーケンス番号1a21のチャンクに続いて、シーケンス番号1a22のチャンク("chunk‐seq:1a22")が送信される。なお、本図では、ステップS104で送信するチャンクのチャンクヘッダの記載を一部省略している。
【0053】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300よりプライマリコネクション#0を用いて送信された各チャンクを受信する。クライアント側通信集積部202は受信バッファ(図示せず。)を有し、受信したチャンクを一旦受信バッファに保存する。
【0054】
一方、クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(200 OK)(ステップS102)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認する。すなわちクライアント側並列通信部201は、サーバ装置300がクライアント装置200に対してに対して対応可能なTCPコネクションの上限を確認する。クライアント側並列通信部201は、"con"が2以上と判定すると、2本目以降のTCPコネクション(以下「セカンダリコネクション」と呼ぶ。)を確立する。本例では、"con=4"であるので、クライアント側並列通信部201は、プライマリコネクション#0を含めて計4本のTCPコネクションを確立する。すなわちクライアント側並列通信部201は、3本のセカンダリコネクション#1、#2、#3を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、確立したセカンダリコネクション#1、#2、#3それぞれを用いてサーバ側並列通信部301へ並列に送信させる(ステップS105〜S107)。
【0055】
なお、通常、クライアント側並列通信部201は、MTCP−sessionヘッダに含まれる"con"の値によって指定された上限になるようにセカンダリコネクションを確立する。しかしながら、たとえば別処理のため十分な処理能力がない場合など、指定された本数のセカンダリコネクションを確立することができない場合には、クライアント側並列通信部201は、この上限の範囲で可能な本数のセカンダリコネクションを確立すればよい。
【0056】
ここで、クライアント側並列通信部201は、HTTP CONNECT要求のMTCP−sessionヘッダの値には、ステップS102で受信したsession‐idを指定し、TEヘッダに"mtcp"を指定する。
【0057】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#1、#2、#3それぞれを通じてサーバ側通信部304を介して受信する。サーバ側並列通信部301は、受信したHTTP CONNECT要求に示されるsession‐idを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。本例では、サーバ側並列通信部301は、セカンダリコネクション#1、#2、#3それぞれを通じて受信したHTTP CONNECT要求に示されるsession‐idを参照し、これらのセカンダリコネクション#1、#2、#3がプライマリコネクション#0に属すると判断する。なお、該当するsession‐idが存在しない場合や、セカンダリコネクションの本数が上限を超えている場合には、サーバ側並列通信部301は、サーバ側通信部304により、エラーをクライアント装置200に送信させる。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#1、#2、#3それぞれを用いてクライアント装置200に並列に送信させる(ステップS108〜S110)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#1、#2、#3をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0058】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#1、#2、#3をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。以上で、並列通信の開始処理が完了する。
【0059】
サーバ側通信分散部303は、サーバ側並列通信部301からセカンダリコネクション#1、#2、#3の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200に並列に送信させる(ステップS111〜S120)。
【0060】
なお、サーバ側通信分散部303は、各TCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)毎の送信ソケットバッファを監視し、何れかのTCPコネクションの送信ソケットバッファに空きができたら、サーバ側通信分散部303が持つ送信バッファの未送信データをさらにチャンクに分割して、その空きができた送信ソケットバッファに移動してもよい。
【0061】
本図では、サーバ側通信分散部303は、ステップS103、S104で既に"chunk‐seq:1a21"、"chunk‐seq:1a22"により示される各チャンクをサーバ側通信部304に送信させている。したがって、サーバ側通信分散部303が続いてサーバ側通信部304に送信させるチャンクの"chunk‐seq"(シーケンス番号)は、順に、1a23、1a24、1a25…1a2a、1a2b、1a2cのようになる。例えば、ステップS112で送信するチャンクのチャンクヘッダとして、"chunk‐seq:1a24"、"start‐seq:1a21"、"tid=1"が設定されている。すなわち、このチャンクのシーケンス番号は1a24であり("chunk‐seq:1a24")、このトランザクションで最初のチャンクのシーケンス番号は1a21であり("start‐seq:1a21")、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。なお、本図では、ステップS111〜S120で送信するチャンクのチャンクヘッダの記載を一部省略している。また、以下の図においてもチャンクヘッダの記載を一部省略している箇所がある。
【0062】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300よりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いて送信された各チャンクを受信する。クライアント側通信集積部202は、何れのTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。クライアント側通信集積部202は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをブラウザ205に受信データとして供給する。クライアント側通信集積部202は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、クライアント側通信集積部202は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがサーバ装置300より届くのを待つ。
【0063】
サーバ側通信分散部303は、サーバ側通信部304に、1つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをクライアント装置200へ送信させる(ステップS120)。続いて、サーバ側通信分散部303は、サーバ側通信部304に、プライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS121)。
【0064】
ここで、zeroチャンクとは、チャンクヘッダのみでデータをもたないチャンクである。zeroチャンクの書式は、例えば、0; [con=n;cseq=cmd-seq];last=last-seqである。"last‐seq"は、1つのデータより分割された複数のチャンクの末尾のシーケンス番号、すなわち1つのトランザクションで最後のチャンクのシーケンス番号を示す。なお、"n"、"cmd‐seq"は後述する。
【0065】
クライアント側通信集積部202は、クライアント側通信部204を介して、サーバ装置300より送信されたzeroチャンクを受信する。クライアント側通信集積部202は、zeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をブラウザ205に通知する。これにより、1つのトランザクションが終了する。
【0066】
続いて、さらに別のトランザクションが行われる(ステップS122〜S127)。以下の説明において、既に説明したデータ通信方法と同様の工程等については説明を省略又は簡略化し、異なる点を中心に説明する。
【0067】
本図のステップS123では、HTTP応答(200 OK)に"tid=2"及び"con=4"が設定された例を示している。すなわち、このトランザクションは2つ目のトランザクションであり("tid=2")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は従来と同じ4本である("con=4")、ということが示されている。したがって、クライアント装置200は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ4本のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を引き続き用いればよい。
【0068】
[2.クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法]
図4は、クライアント装置がサーバ装置にデータをアップロードする場合のデータ通信方法を示すシーケンス図である。
ブラウザ205は、UI206を通して入力されるユーザからのコンテンツ送信要求を受け、クライアント側並列通信部201にコンテンツ送信要求を通知すると共に、クライアント側通信分散部203の送信バッファ(図示せず。)に送信すべきデータを配置する。クライアント側並列通信部201は、ブラウザ205からコンテンツ送信要求を受けると、一つ目のTCPコネクション#0(プライマリコネクション#0)を確立する。クライアント側並列通信部201は、TEヘッダに値"mtcp"を指定したHTTP PUT要求を生成する。クライアント側並列通信部201は、生成したHTTP PUT要求を、クライアント側通信部204によりプライマリコネクション#0を用いてサーバ装置300へ送信させる(ステップS201)。
【0069】
ここで、プライマリコネクション#0確立後最初のHTTP PUT要求は、Expectヘッダを含む。このExpectヘッダの値は、"100‐Continue"である。
【0070】
サーバ側並列通信部301は、サーバ側通信部304を介してクライアント側並列通信部201からHTTP PUT要求を受信すると、そのサーバ装置300でユニークであるsession‐idを発行する。また、サーバ側並列通信部301は、HTTP PUT要求によってアップロードが要求されたデータを送信するのに適切なTCPコネクションの上限を定める。サーバ側並列通信部301は、HTTP PUT要求に対する応答として、上記session‐id、tid、con(TCPコネクションの本数の上限)を示したHTTP応答(100‐Continue)を生成する。このHTTP応答(100‐Continue)のTEヘッダには、値"mtcp"が指定される。サーバ側並列通信部301は、生成したHTTP応答(100‐Continue)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS202)。
【0071】
ここで、HTTP応答(100‐Continue)は、同一のセッションに属するコネクションを特定する"session−id"、トランザクションを特定する"tid"、TCPコネクションの上限を示す"con"等を含む。
【0072】
本図のステップS202では、"tid=3"及び"con=4"が設定された例を示している。すなわち、このトランザクションは3つ目のトランザクションであり("tid=3")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は4本である("con=4")、ということが示されている。
【0073】
クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(100‐Continue)(ステップS202)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認し、2本目以降のTCPコネクションを確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、確立したセカンダリコネクション#1、#2、#3それぞれを用いてサーバ側並列通信部301へ並列に送信させる(ステップS203〜S205)。
【0074】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#1、#2、#3それぞれを通じてサーバ側通信部304を介して受信する。サーバ側並列通信部301は、受信したHTTP CONNECT要求に示されるsession‐idを参照し、何れのプライマリコネクションに属するセカンダリコネクションなのかを判断する。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#1、#2、#3それぞれを用いてクライアント装置200に並列に送信させる(ステップS206〜S208)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#1、#2、#3をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0075】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#1、#2、#3をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。以上で、並列通信の開始処理が完了する。
【0076】
クライアント側通信分散部203は、通知を受けると、ブラウザ205によって送信バッファに配置されたデータをチャンクに分割し、各チャンクにそれぞれシーケンス番号を付与する。そして、クライアント側通信分散部203は、シーケンス番号を付した複数のチャンクを、クライアント側通信部204によりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いてサーバ装置300へ送信させる(ステップS209〜S218)。
【0077】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200よりプライマリ及びセカンダリコネクション#0、#1、#2、#3を用いて送信された各チャンクを受信する。サーバ側通信集積部302は、何れのTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)が用いられたかに拘わらず、受信したチャンクを一旦受信バッファに保存する。サーバ側通信集積部302は、チャンクをある程度集積したところで、シーケンス番号に抜けがない一連のチャンクをウェブサーバ306に受信データとして供給する。サーバ側通信集積部302は、この処理を繰り返す。なお、コネクションが切断されたわけではないのにシーケンス番号に抜けがある部分は、サーバ側通信集積部302は、抜け以降のチャンクを受信バッファに保存しながら、その抜けているチャンクがクライアント装置200より届くのを待つ。
【0078】
クライアント側通信分散部203は、クライアント側通信部204に、1つのデータより分割された複数のチャンクのうち最後のシーケンス番号が付されたチャンクをサーバ装置300へ送信させる(ステップS218)。続いて、クライアント側通信分散部203は、クライアント側通信部204に、プライマリコネクション#0を用いてzeroチャンクをサーバ装置300へ送信させる(ステップS219)。
【0079】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200より送信されたzeroチャンクを受信する。サーバ側通信集積部302は、zeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部301に通知する。
【0080】
サーバ側並列通信部301は、データ受信完了の通知を受けると、HTTP応答(200 OK)を生成し、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS220)。
【0081】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、データのアップロードの完了を判断する。これにより、1つのトランザクションが終了する。
【0082】
続いて、さらに別のトランザクションが行われる(ステップS221〜S227)。本図のステップS222では、HTTP応答(100−Continue)に"tid=4"及び"con=4"が設定された例を示している。すなわち、このトランザクションは4つ目のトランザクションであり("tid=4")、サーバ装置300がクライアント装置200に対して対応可能なTCPコネクションの上限は従来と同じ4本である("con=4")、ということが示されている。したがって、クライアント装置200は、新たにセカンダリコネクションを確立する必要はなく、従来と同じ4本のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を引き続き用いればよい。
【0083】
[3.データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法]
図5は、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS101〜S110)。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200へ並列に送信させる(ステップS111〜S114)。
【0084】
ここで、バックエンドサービス306が、クライアント装置200向けに処理可能なTCPコネクションの上限が増えたと判断したとする。その場合、バックエンドサービス306は、サーバ側並列通信部301にTCPコネクションの上限の増加を通知し、サーバ側並列通信部301は、サーバ側通信分散部303にTCPコネクションの上限の増加を通知する。サーバ側通信分散部303は、通知を受けると、次回クライアント装置200へ送信すべきチャンクに付随するチャンクヘッダを次のように書き換える。上述のように、チャンクヘッダのシンタックスは、chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]である。サーバ側通信分散部303は、"con=n"に、サーバ側並列通信部301からの通知に含まれるTCPコネクションの上限(例えば"con=5")を指定する。さらに、サーバ側通信分散部303は、"cmd‐seq"に、前回のcmd‐seqの値をインクリメントした値を指定する。なお、最初はランダム値とする。サーバ側通信分散部303は、このように書き換えたチャンクヘッダを付したチャンクを、任意のTCPコネクション(例えば、プライマリコネクション#0)を用いてクライアント装置200に送信させる(ステップS301)。
【0085】
ここで、"cmd‐seq"とは、コネクション上限情報の変更に伴い順次更新される、コネクション本数の変更の要求の順番を示す整数である。本実施形態のような並列通信では、サーバ側通信分散部303がサーバ側通信部304に送信させたデータ(複数のチャンク)が、異なるTCPコネクションを経由してクライアント側通信集積部202に届いたとき、データの到達順序が変わってしまう可能性がある。たとえばサーバ側通信分散部303は、"con=1"及び"cmd‐seq=1"を指定したチャンクヘッダを含むチャンクA、"con=4"及び"cmd‐seq=2"を指定したチャンクヘッダを含むチャンクB、"con=2"及び"cmd‐seq=3"を指定したチャンクヘッダを含むチャンクCをこの順にサーバ側通信部304に送信させるとする。しかし、クライアント側通信集積部202は、チャンクA("con=1"、"cmd‐seq=1")、チャンクC("con=2"、"cmd‐seq=3")、チャンクB("con=4"、"cmd‐seq=2")の順で、クライアント側通信部204を介してこれらのチャンクを受信したとする。クライアント側通信集積部202は、受信した複数のチャンクに含まれるcmd‐seqの値を比較し、もっとも大きい値が設定されたcmd‐seqを判定する。そして、クライアント側通信集積部202は、もっとも大きい値が設定されたcmd‐seqを含むチャンクヘッダが、最新のconを示すものと判断する。このように、cmd‐seqを設定することで、データの到達順序が変わっても、クライアント側通信集積部202は、最新のTCPコネクションの上限を判断することができる。
【0086】
クライアント側通信集積部202は、クライアント側通信部204を介してサーバ側通信分散部303よりチャンクを受信すると、チャンクヘッダのcmd‐seqの値を確認する。クライアント側通信集積部202は、cmd‐seqに従来の値と異なる値が設定されていると判定すると、そのチャンクヘッダのconの値すなわちTCPコネクションの上限をクライアント側並列通信部201に通知する。
【0087】
クライアント側並列通信部201は、クライアント側通信集積部202からTCPコネクションの上限を取得すると、新たなTCPコネクション(セカンダリコネクション#4)を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、新たに確立したセカンダリコネクション#4を用いてサーバ側並列通信部301へ並列に送信させる(ステップS302)。
【0088】
サーバ側並列通信部301は、HTTP CONNECT要求をセカンダリコネクション#4を通じてサーバ側通信部304を介して受信すると、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#4を用いてクライアント装置200に送信させる(ステップS303)。そして、サーバ側並列通信部301は、確立されたセカンダリコネクション#4をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0089】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#4をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。
【0090】
サーバ側通信分散部303は、サーバ側並列通信部301からセカンダリコネクション#4の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3、#4)を用いてクライアント装置200へ並列に送信させ、最後にプライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS304〜S309)。
【0091】
[4.データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法]
図6は、データ通信(アップロード)の最中にTCPコネクションの接続本数を増加する場合のデータ通信方法を示すシーケンス図である。
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS201〜S208)。そして、クライアント側通信分散部203は、シーケンス番号を付した複数のチャンクを、クライアント側通信部204に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてサーバ装置300へ並列に送信させる(ステップS209〜S212)。
【0092】
ここで、サーバ側並列通信部301が、サーバ装置300側でクライアント装置200向けに処理可能なTCPコネクションの上限が増えたと判断したとする。その場合、サーバ側並列通信部301は、この新しいTCPコネクションの上限をconに指定したMTCP‐sessionヘッダを有するHTTP応答(100‐Continue)を生成する。サーバ側並列通信部301は、生成したHTTP応答(100‐Continue)を、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS401)。
【0093】
クライアント側並列通信部201は、クライアント側通信部204を介してサーバ側並列通信部301からHTTP応答(100‐Continue)(ステップS401)を受信すると、MTCP−sessionヘッダに含まれる"con"の値を確認する。すなわちクライアント側並列通信部201は、サーバ装置300が対応可能なTCPコネクションの上限を確認し、新たなTCPコネクション(本例ではセカンダリコネクション#4)を確立する。クライアント側並列通信部201は、HTTP CONNECT要求を、クライアント側通信部204により、新たに確立したセカンダリコネクション#4を用いてサーバ側並列通信部301へ並列に送信させる(ステップS402)。
【0094】
サーバ側並列通信部301は、HTTP CONNECT要求を、セカンダリコネクション#4を通じてサーバ側通信部304を介して受信する。続いて、サーバ側並列通信部301は、HTTP応答(200 OK)を、サーバ側通信部304により、セカンダリコネクション#4を用いてクライアント装置200に並列に送信させる(ステップS403)。そして、サーバ側並列通信部301は、新たに確立されたセカンダリコネクション#4をサーバ側通信集積部302及びサーバ側通信分散部303に通知する。
【0095】
クライアント側並列通信部201は、クライアント側通信部204を介してHTTP応答(200 OK)をそれぞれ受信すると、確立したセカンダリコネクション#4をクライアント側通信集積部202及びクライアント側通信分散部203に通知する。
【0096】
クライアント側通信分散部203は、クライアント側並列通信部201からセカンダリコネクション#4の確立の通知を受けると、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3、#4)を用いてクライアント装置200へ並列に送信させ、最後にクライアント側通信部204に、プライマリコネクション#0を用いてzeroチャンクをサーバ装置300へ送信させる(ステップS404〜S409)。
【0097】
サーバ側通信集積部302は、サーバ側通信部304を介して、クライアント装置200より送信されたzeroチャンクを受信すると、全てのチャンクを受信したものと判断し、データ受信完了をサーバ側並列通信部301に通知する。サーバ側並列通信部301は、データ受信完了の通知を受けると、HTTP応答(200 OK)を生成し、サーバ側通信部304によりプライマリコネクション#0を用いてクライアント装置200へ送信させる(ステップS410)。
【0098】
[5.データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法]
図7は、データ通信の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法を示すシーケンス図である。
ここでは、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法について説明する。
【0099】
まず、クライアント装置200及びサーバ装置300は、並列通信の開始処理を行う(ステップS101〜S110)。そして、サーバ側通信分散部303は、シーケンス番号を付した複数のチャンクを、サーバ側通信部304に、任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1、#2、#3)を用いてクライアント装置200へ並列に送信させる(ステップS111〜S114)。
【0100】
ここで、サーバ側並列通信部301が、サーバ装置300側でクライアント装置200向けに処理可能なTCPコネクションの本数を減らすよう判断したとする。ここで、TCPコネクションの本数を減らすためには、減らす対象のTCPコネクションで通信されているデータを止めてからでないと、データの欠損が起きてしまう。それを防ぐため、以下の方法でTCPコネクションの本数を減らす。
【0101】
サーバ側並列通信部301は、サーバ側通信分散部303に、TCPコネクションの本数を減少するよう通知する。サーバ側通信分散部303は、通知を受けると、サーバ側通信部304により、減らす対象のセカンダリコネクションを用いて、クライアント装置200に、zeroチャンクを送信する。ここで、zeroチャンクの書式は、例えば、"0; con=n;cseq=cmd-seq"である。
【0102】
本例では、現在4本のTCPコネクション(プライマリコネクションを含む)を用いていて、そのうち2本セカンダリコネクションを切断して2本のTCPコネクションにする場合を示す。サーバ側通信分散部303は、切断対象の2本のセカンダリコネクション(例えばセカンダリコネクション#2、#3)を任意に選択する。サーバ側通信分散部303は、サーバ側通信部304により、選択したセカンダリコネクション#2、#3を用いて、con=2を指定した上記zeroチャンクをクライアント装置200へ送信する(ステップS501、S502)。
【0103】
なお、通常チャンクはプライマリコネクションでダウンロード/アップロードが行われた後に通信される。しかし、上記zeroチャンクは、ダウンロード/アップロードが完了した後でも、任意のタイミングでサーバ装置300からクライアント装置200に対して送信してよい。
【0104】
サーバ側通信分散部303は、サーバ側通信部304によりzeroチャンクをクライアント装置200へ送信すると、切断対象のセカンダリコネクション#2、#3を用いた新たなチャンクの送信を停止する。そして、サーバ側通信分散部303は、クライアント装置200によりセカンダリコネクション#2、#3が切断されるのを待つ。しかしながら、PUT用のチャンクがクライアント側通信分散部203からサーバ側通信集積部302に届く可能性があるので、サーバ側通信集積部302は、セカンダリコネクション#2、#3が切断されるまではチャンク受信に備えておく。これは、サーバ側通信分散部303が上記zeroチャンクを送信するのとほぼ同じタイミングでクライアント装置200がアップロード処理を開始した場合を考慮したものである。すなわちこのような場合、zeroチャンクがクライアント装置200に届く前に、クライアント側通信分散部203がクライアント側通信部204にアップロード用のチャンクをセカンダリコネクション#2、#3を用いて送信させる可能性があるからである。
【0105】
その後、サーバ側通信分散部303は、複数のチャンクを、サーバ側通信部304に、切断したセカンダリコネクション#2、#3を除く任意のTCPコネクション(プライマリ及びセカンダリコネクション#0、#1)を用いてクライアント装置200へ並列に送信させる(ステップS503、S504)。続いて、サーバ側通信分散部303は、サーバ側通信部304に、プライマリコネクション#0を用いてzeroチャンクをクライアント装置200へ送信させる(ステップS505)。
【0106】
以上、データ通信(ダウンロード)の最中にTCPコネクションの接続本数を減少する場合のデータ通信方法について説明したが、データ通信(アップロード)の最中であれば、以下のように処理を行えばよい。すなわち、クライアント側通信分散部203は、上記zeroチャンクを受けて、もしアップロード用のチャンクの送信中であれば、新たなチャンクの送信を停止する。そして、クライアント側通信分散部203は、送信済みのチャンクがサーバ装置300に到着したのを確認してから切断対象のコネクションを切断する。なお、クライアント側通信分散部203は、送信済みのチャンクがサーバ装置300に到着したのを確認する技術については、TCP等、信頼性のあるトランスポートが前提であれば可能である。
【0107】
本実施形態によれば、セカンダリコネクションの本数を動的に増減することでスループットを調節することができる。動的なセカンダリコネクションの本数の制御は、例えば、以下のような場合に有用である。
【0108】
経路のリンク速度をL、1本あたりのTCPコネクションのスループットをTとするとき、nT<Lである最大の自然数n本のコネクションを確立すれば、最大のスループットを得ることができる。なお、nをそれ以上大きくしてもリンク速度Lの制約のためエラーが起こってしまい、スループットを得ることはできない。
【0109】
また、たとえばストリーミングのように必要なスループット(Qとする、また、Q<Lとする)が決まっている場合には、それに必要なスループット以上の本数を確立しても意味がない。この場合、mT>Qとなる最小のm本のTCPコネクションを確立すればよい。
【0110】
また、1つのサーバ装置300と複数のクライアント装置200とが同時期に通信を行うケースでは、サーバ装置300の処理能力の制限のため、クライアント装置200一つあたりに提供できるスループットが制限される。クライアント装置200の数が増えてきたときには既接続クライアント装置200へのスループットを下げることにより、新規クライアント装置200へのスループットと同等にすることができる。これにより、複数のクライアント装置200間で公平にサービスを行うことができる。
【0111】
[6.クライアント装置がサーバ装置にGET要求を送信し、サーバ装置300からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)]
まず、従来のHTTPのパイプラインについて説明しておくこととする。HTTPのパイプラインとは、クライアントがあるHTTPリクエストを送信し、それに対応するレスポンスが到着する前に、さらに次以降のHTTPリクエストを送信するものである。サーバがパイプラインに対応していれば、次以降のHTTPリクエストはサーバ側でキューイングされ、順番に処理されてHTTPレスポンスが返る。
【0112】
このように、レスポンスを待たずに次のリクエストを送ることができるのがHTTPのパイプラインであるが、レスポンスの順番はリクエストの順番通りであった。これは、一本のTCP上で異なるリクエストのための情報を同時に扱うことができないためである。このため、たとえばひとつのリクエストの処理に時間がかかると、他の本来処理時間が短くて済むはずのリクエストも応答に時間がかかってしまうという問題があった。
【0113】
図8は、クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、PUT要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
本図において実線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信(ダウンロード)を示す。一点鎖線の矢印は、クライアント側通信集積部202とサーバ側通信分散部303との、クライアント側通信部204及びサーバ側通信部304を介しての通信(ダウンロード)を示す。点線の矢印は、クライアント側並列通信部201とサーバ側並列通信部301との、クライアント側通信部204及びサーバ側通信部304を介しての通信(アップロード)を示す。破線の矢印は、クライアント側通信分散部203とサーバ側通信集積部302との、クライアント側通信部204及びサーバ側通信部304を介しての通信(アップロード)を示す。
【0114】
まず、クライアント側並列通信部201は、HTTP GET要求をクライアント側通信部204によりサーバ装置300へ送信させる(ステップS601)。クライアント側並列通信部201は、HTTP GET要求に対する応答をサーバ装置300から取得する前に、HTTP PUT要求をクライアント側通信部204によりサーバ装置300へ送信させたとする(ステップS602)。
【0115】
本例のステップS603では、HTTP応答(200 OK)に"tid=5"が設定された例を示している。すなわち、このトランザクションは5つ目のトランザクションである("tid=5")、ということが示されている。また、ステップS607、S608、S617〜S622では、ダウンロードされるデータの各チャンクに"tid=5"が設定されている。
【0116】
一方、本例のステップS612では、HTTP応答(100‐Continue)に"tid=6"が設定された例を示している。すなわち、このトランザクションは6つ目のトランザクションである("tid=6")、ということが示されている。また、ステップS613〜S615では、アップロードされるデータの各チャンクに"tid=6"が設定されている。
【0117】
ここで、通信されるチャンクに着目すると、まず、ステップS607、S608で、ダウンロード対象のデータのうち一部のチャンク(tid=5)がダウンロードされる。次に、ステップS613〜S616で、アップロード対象のデータのうち全てのチャンク(tid=6)がアップロードされる。最後に、ステップS617〜S623で、ダウンロード対象のデータのうち残りのチャンク(tid=5)がダウンロードされる。本実施形態では、ダウンロード対象のデータに属するチャンクを全てダウンロードし、その後アップロード対象のデータに属するチャンクを全てアップロードする、という順序でデータの通信を必ずしも行う必要がない。
【0118】
本実施形態では各チャンクそれぞれにトランザクションID(tid)を付与している。これにより、受信側(アップロードの場合サーバ装置300、ダウンロードの場合クライアント装置200)がトランザクションIDを参照すれば、データ通信の順番に関わらず、同一のトランザクションID(tid)を有するチャンク毎にデータを復元することができる。例えば、クライアント装置200は、複数のデータをダウンロードする際、一方のデータから分割されたデータであるチャンク及び他方のデータから分割されたデータであるチャンクを、これらが混在するような順番で受信する可能性がある。このような場合であっても、クライアント装置200は、それぞれのデータを特定するtidを参照することで、同一のtidを有するチャンク毎に複数のデータをそれぞれ復元することができる。
【0119】
本実施形態によれば、HTTP要求がパイプラインされたあと、コネクションがどのトランザクション(どの要求)のために使用されているかをトランザクションID(tid)で示している。これにより、従来のHTTPレスポンスのヘッダに関してはリクエストの順序通りに返されなければならなかったが、本実施形態では必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送受信したりできる。
【0120】
[7.クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)]
図9は、クライアント装置がサーバ装置にGET要求を送信し、サーバ装置からの応答を取得する前に、別のGET要求をさらに送信する場合のデータ通信方法(パイプライン)を示すシーケンス図である。
本図において実線の矢印は、クライアント装置200とサーバ装置300とのデータ通信(あるデータをダウンロード)を示す。二点鎖線の矢印は、クライアント装置200とサーバ装置300とのデータ通信(別のデータをダウンロード)を示す。一点鎖線の矢印は、セカンダリコネクション確立処理を示す。
【0121】
まず、クライアント側並列通信部201は、1つ目のHTTP GET要求(HTTP GET要求1とする。)をクライアント側通信部204によりサーバ装置300へ送信させる(ステップS701)。クライアント側並列通信部201は、HTTP GET要求1に対する応答を取得する前に、2つ目のHTTP GET要求(HTTP GET要求2とする。)をクライアント側通信部204によりサーバ装置300へ送信させたとする(ステップS702)。
【0122】
本例のステップS703では、HTTP応答(200 OK)に"tid=1"が設定された例を示している。すなわち、このトランザクションは1つ目のトランザクションである("tid=1")、ということが示されている。また、ステップS716〜S720では、ダウンロードされるデータの各チャンクに"tid=1"が設定されている。
【0123】
一方、本例のステップS710では、HTTP応答(200 OK)に"tid=2"が設定された例を示している。すなわち、このトランザクションは2つ目のトランザクションである("tid=2")、ということが示されている。また、ステップS711〜S714では、ダウンロードされるデータの各チャンクに"tid=2"が設定されている。
【0124】
これらHTTP応答(200 OK)は、HTTP GET要求の順序通りに返される。したがって、クライアント側並列通信部201は、自分の発行したHTTP GET要求にどのようなトランザクションIDが付与されたかを、HTTP応答(200 OK)のヘッダを参照することで知ることができる。
【0125】
ここで、通信されるチャンクに着目すると、まず、ステップS711〜S715で、HTTP GET要求2で指定されたダウンロード対象のデータのチャンク(tid=2)がダウンロードされる。次に、ステップS716〜S720で、HTTP GET要求1で指定されたダウンロード対象のデータのチャンク(tid=1)がダウンロードされる。本実施形態では、HTTP GET要求1で指定されたダウンロード対象のデータに属するチャンクをダウンロードし、その後HTTP GET要求2で指定されたダウンロード対象のデータに属するチャンクをダウンロードする、という順序でデータの通信を必ずしも行う必要がない。本実施形態では各チャンクそれぞれにトランザクションID(tid)を付与しているので、受信側であるクライアント装置200がトランザクションID(tid)を参照すれば、データ通信の順番に関わらず、同一のトランザクションIDを有するチャンク毎にデータを復元することができる。
【0126】
より具体的に、セカンダリコネクション#1を用いた通信に注目して説明する。まず、クライアント側通信集積部202は、クライアント側通信部204を介してseq:1a26 start:1a25 tid:2 のチャンクを受信する(ステップS712)。クライアント側通信集積部202は、このチャンクがHTTP GET要求2の、2つ目のチャンクであると判断する。続いて、クライアント側通信集積部202は、クライアント側通信部204を介してseq:1a22 start:1a21 tid:1 を受信する(ステップS717)。クライアント側通信集積部202は、この一つ前まででセカンダリコネクション#1上ではHTTP GET要求2に関するデータ(チャンク)の受信は完了し、今届いたチャンクはHTTP GET要求1の2番目のチャンクであると判断する。
【0127】
本実施形態では、送られるデータがどのリクエストに対応するものかを示すため、あるコネクション上で送られるデータがどのトランザクションのためのものかを示すtidを、チャンクに付記している。これにより、HTTPリクエストがパイプラインされたあと、コネクションがどのトランザクション(どのリクエスト)のために使用されているかをトランザクションID(tid)で示すことによって、受信側装置は、データ通信の順番に関わらずデータを復元することができる。これにより、送信側装置は、必要に応じてデータの送信順序を変えたり、複数のコンテンツを並行に送ったりできるようにしている。
【0128】
[8.意図しないTCPコネクション切断からのデータ復帰方法(ダウンロード時)]
次に、通信障害等や、通信相手機器の事情により、複数のセカンダリコネクションのうち一部が意図せずに切断されてしまった場合について説明する。このような場合、以下のようにデータの完全性を保つことができる。
【0129】
まず、サーバ装置300の処理について説明する。1以上のセカンダリコネクションが切断されたとき、サーバ側通信分散部303は、サーバ側通信部304により、切断されたセカンダリコネクションで送信中であったチャンクを、改めて他のコネクションに振り分けてクライアント装置200へ送信させる。一方、クライアント側通信集積部202は、クライアント側通信部204を介して受信したチャンクの"chunk-seq"を参照する。サーバ側通信分散部303がチャンクの送信が失敗したと判断して同一のチャンクを再送信した場合、実は両方の送信が成功しており、クライアント側通信集積部202が同一のチャンクを重複して取得してしまうような場合がある。しかしながら、クライアント側通信集積部202は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。
【0130】
次に、クライアント装置200の処理について説明する。1以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部201は、その時点で確立してもよい上限を超えない限り、HTTP CONNECTを用いて最初に張ったときと同じSession idを指定してセカンダリコネクションを再確立する。切断されたコネクションを用いて送信中であったチャンクがあった場合は、サーバ装置300により新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いて再転送されることが期待される。上述のように、クライアント側通信集積部202は、チャンクの"chunk-seq"を参照することにより重複したチャンクを検出できる。転送されない場合は、HTTP GET要求を改めてRangeヘッダでその欠損チャンクの位置のみを指定して行うことで解決することができる。なお、上記説明したパイプラインの処理により、クライアント側並列通信部201は、元のHTTP GET要求が終了する前にでも、クライアント側通信部204により穴埋めのためのHTTP GET要求を並列に送信させることができる。
【0131】
[9.意図しないTCPコネクション切断からのデータ復帰方法(アップロード時)]
まず、クライアント装置200の処理について説明する。1以上のセカンダリコネクションが切断されたとき、クライアント側並列通信部201は、その時点で確立してもよい上限を超えない限り、HTTP CONNECTを用いて最初に張ったときと同じSession idを指定してセカンダリコネクションを再確立する。切断コネクションを用いて送信中であったチャンクがあった場合は、クライアント側通信分散部203は、クライアント側通信部204により、新たに確立されたセカンダリコネクションを含むいずれかのコネクションを用いてそのチャンクを再送信させる。サーバ側通信集積部302は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。
【0132】
次に、サーバ装置300の処理について説明する。サーバ側通信集積部302は、1以上のセカンダリコネクションが切断されたときでも、残ったコネクションを用いてサーバ側通信部304を介してそのままデータ受信を続ける。切断されたコネクションで送信中であったチャンクがあった場合は、クライアント装置200により残ったコネクションを用いて再転送されることが期待される。サーバ側通信集積部302は、取得したチャンクの"chunk-seq"を参照することにより重複したチャンクを識別することができ、重複して取得したチャンクの一方を無視することができる。サーバ側通信集積部302は、zeroチャンクを受信した時点でデータ(チャンク)に欠損があった場合には、HTTPのエラーをサーバ側通信部304によりクライアント装置200へ送信させる。
【0133】
[クライアント装置のハードウェア構成]
次に、クライアント装置200及びサーバ装置300のハードウェア構成について説明する。
【0134】
図10は、クライアント装置のハードウェア構成を示すブロック図である。
クライアント装置200において、CPU(Central Processing Unit)612には、システムバス613を介して、入力操作部601と、クライアント側通信部204と、記憶部604と、デコード部605と、表示部606と、メディアインターフェース部608と、ROM(Read Only Memory)610と、RAM(Random Access Memory)611とが接続されている。
【0135】
入力操作部601は、各種のキーなどを備える。利用者は、入力操作部601を用いて各種の命令やデータの入力を処理する。利用者により入力操作部601より入力された各種の命令は、システムバス613を通じてCPU612に供給される。
【0136】
クライアント側通信部204は、グローバルなネットワーク101との接続を処理する。
【0137】
記憶部604は、HDD、SSD等よりなる。記憶部604には、クライアント側通信部204によりネットワーク101を通じてダウンロードされたコンテンツデータ等が記録される。
【0138】
デコード部605は、記憶部604から読み出されたコンテンツのデータをデコードして、デジタルビデオデータ及びデジタルオーディオデータを復元する。復元されたデジタルビデオデータはシステムバス613を通じて表示部606に供給され、デジタルオーディオデータはシステムバス613を通じてスピーカ部607に供給される。
【0139】
表示部606は、例えば、LCD(Liquid Crystal Display)などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部606は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。
【0140】
メディアインターフェース部608には、光ディスクなどのリムーバブルメディア614の装着が可能とされ、このリムーバブルメディア614にコンテンツデータなどを記録することが可能である。リムーバブルメディア614としては、例えば、追記型、書換型のDVD、ブルーレイディスクなどがある。
【0141】
ROM610には、クライアント装置200が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部604に格納されていてもよい。
【0142】
RAM611は、CPU612によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。
【0143】
CPU612は、クライアント装置200の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU612は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU612は、クライアント装置200が実行すべきソフトウェア処理を実行するために、必要なプログラムをROM610からRAM611へロードし、解釈して実行する。
【0144】
このように、クライアント装置200は、典型的なコンピュータ・ハードウェアを用いて構成される。そして、ROM610に記憶されたプログラムは、クライアント装置200のコンピュータ・ハードウェアを、図2に示す各モジュールとして機能させる。
【0145】
[サーバ装置のハードウェア構成]
図11は、サーバ装置のハードウェア構成を示すブロック図である。
サーバ装置300において、CPU(Central Processing Unit)512には、システムバス513を介して、入力操作部501と、サーバ側通信部304と、記憶部504と、表示部506と、ROM(Read Only Memory)510と、RAM(Random Access Memory)511とが接続されている。
【0146】
入力操作部501は、各種のキーなどを備える。サーバ管理者は、入力操作部501を用いて各種の命令やデータの入力を処理する。サーバ管理者により入力操作部501より入力された各種の命令は、システムバス513を通じてCPU512に供給される。
【0147】
サーバ側通信部304(ネットワーク接続部)は、グローバルなネットワーク101との接続を処理する。
【0148】
記憶部504は、HDD、SSD等よりなる。記憶部504には、サーバ側通信部304によりネットワーク101を通じてアップロードされたコンテンツデータ等が記録される。
【0149】
表示部506は、例えば、LCD(Liquid Crystal Display)などの表示画面を備える表示器と、表示器を駆動する表示制御回路等よりなる。表示部506は、利用者から入力された指令やデータの確認、各種のステータス等を表示したりする。
【0150】
メディアインターフェース部508には、光ディスクなどのリムーバブルメディア614の装着が可能とされる。リムーバブルメディア614としては、例えば、追記型、書換型のDVD、ブルーレイディスクなどがある。
【0151】
ROM510には、サーバ装置300が実行すべきソフトウェア処理のためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部504に格納されていてもよい。
【0152】
RAM511は、CPU512によって実行されるプログラム・コードをロードしたり、プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。
【0153】
CPU512は、サーバ装置300の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU512は、上記の各部の制御を総括的に行うとともに各部の間でのデータのやりとりを制御する。CPU512は、サーバ装置300が実行すべきソフトウェア処理を実行するために、必要なプログラムをROM510からRAM511へロードし、解釈して実行する。
【0154】
ROM510に記憶されたプログラムは、サーバ装置300のコンピュータ・ハードウェアを、図2に示す各モジュールとして機能させる。
【符号の説明】
【0155】
101…ネットワーク
200…クライアント装置
201…クライアント側並列通信部
202…クライアント側通信集積部
203…クライアント側通信分散部
204…クライアント側通信部
300…サーバ装置
301…サーバ側並列通信部
302…サーバ側通信集積部
303…サーバ側通信分散部
304…サーバ側通信部
【特許請求の範囲】
【請求項1】
第1の情報処理装置と第2の情報処理装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のTCPコネクションを用いて通信するデータ通信方法であって、
前記第1の情報処理装置は、前記第2の情報処理装置との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を前記第2の情報処理装置に通知し、前記通知するコネクション上限情報を変更して、前記第2の情報処理装置との間でのTCPコネクションの数を動的に変更する
データ通信方法。
【請求項2】
請求項1に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記コネクション上限情報の変更に伴いコマンドシーケンス情報を順次更新して前記第2の情報処理装置に送信し、
前記第2の情報処理装置は、受信した前記コマンドシーケンス情報をもとに、前記第1の情報処理装置からの最新のコネクション上限情報を認識する
データ通信方法。
【請求項3】
請求項2に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記コネクション上限情報及び前記コマンドシーケンス情報を、分割された各データのヘッダに付加して前記第2の情報処理装置に送信する
データ通信方法。
【請求項4】
請求項3に記載のデータ通信方法であって、
前記第2の情報処理装置は、データを特定するデータ特定情報を含む送信要求を前記第1の情報処理装置に送信し、
前記第1の情報処理装置は、受信した前記送信要求に含まれる前記データ特定情報により特定される前記データを所定の単位毎に分割し、前記分割された各データのヘッダにそれぞれ前記データ特定情報を付加して前記第2の情報処理装置に送信する
データ通信方法。
【請求項5】
請求項4に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記分割されたデータのヘッダにそれぞれ、分割前の前記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する
データ通信方法。
【請求項6】
ネットワークに接続可能なネットワーク接続部と、
前記ネットワーク接続部を通じて他の情報処理との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のTCPコネクションを用いて通信するとき、前記他の情報処理との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を前記他の情報処理に通知し、この通知するコネクション上限情報を変更して、前記他の情報処理との間でのTCPコネクションの数を動的に変更するための変更手段と
を具備する情報処理装置。
【請求項1】
第1の情報処理装置と第2の情報処理装置との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のTCPコネクションを用いて通信するデータ通信方法であって、
前記第1の情報処理装置は、前記第2の情報処理装置との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を前記第2の情報処理装置に通知し、前記通知するコネクション上限情報を変更して、前記第2の情報処理装置との間でのTCPコネクションの数を動的に変更する
データ通信方法。
【請求項2】
請求項1に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記コネクション上限情報の変更に伴いコマンドシーケンス情報を順次更新して前記第2の情報処理装置に送信し、
前記第2の情報処理装置は、受信した前記コマンドシーケンス情報をもとに、前記第1の情報処理装置からの最新のコネクション上限情報を認識する
データ通信方法。
【請求項3】
請求項2に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記コネクション上限情報及び前記コマンドシーケンス情報を、分割された各データのヘッダに付加して前記第2の情報処理装置に送信する
データ通信方法。
【請求項4】
請求項3に記載のデータ通信方法であって、
前記第2の情報処理装置は、データを特定するデータ特定情報を含む送信要求を前記第1の情報処理装置に送信し、
前記第1の情報処理装置は、受信した前記送信要求に含まれる前記データ特定情報により特定される前記データを所定の単位毎に分割し、前記分割された各データのヘッダにそれぞれ前記データ特定情報を付加して前記第2の情報処理装置に送信する
データ通信方法。
【請求項5】
請求項4に記載のデータ通信方法であって、
前記第1の情報処理装置は、前記分割されたデータのヘッダにそれぞれ、分割前の前記データにおける前後の関係を識別するための前後関係識別情報をさらに付加する
データ通信方法。
【請求項6】
ネットワークに接続可能なネットワーク接続部と、
前記ネットワーク接続部を通じて他の情報処理との間で複数のTCP(Transmission Control Protocol)コネクションを確立し、所定の単位毎に分割された各データを前記確立された複数のTCPコネクションを用いて通信するとき、前記他の情報処理との間で確立すべきTCPコネクションの数の上限を示すコネクション上限情報を前記他の情報処理に通知し、この通知するコネクション上限情報を変更して、前記他の情報処理との間でのTCPコネクションの数を動的に変更するための変更手段と
を具備する情報処理装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公開番号】特開2012−95098(P2012−95098A)
【公開日】平成24年5月17日(2012.5.17)
【国際特許分類】
【出願番号】特願2010−240691(P2010−240691)
【出願日】平成22年10月27日(2010.10.27)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成24年5月17日(2012.5.17)
【国際特許分類】
【出願日】平成22年10月27日(2010.10.27)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]