JP2017038297A - 通信装置、通信方法、及び通信システム - Google Patents

Abstract

【課題】ＨＴＴＰ／２のコネクション及びストリームによって通信が行なわれる場合において、帯域を効率的に利用した通信を行えるようにする。
【解決手段】通信路としてのコネクションを生成して対向装置と接続する接続部と、コネクションに少なくとも１つの論理的なストリームを確立するストリーム処理部と、対向装置との通信情報に基づいて、コネクション用のウインドウサイズ及びストリーム用のウインドウサイズを決定する決定部と、決定されたウインドウサイズを含むコネクション用のウインドウ更新フレーム及びストリーム用のウインドウ更新フレームを対向装置に送信する更新送信部とを有し、対向装置との通信に応じてウインドウサイズを適切に更新できるようにする。
【選択図】図４

Description

本発明は、通信路を介して通信を行う通信装置、通信方法、及び通信システムに関する。

クライアント機器（以下、「クライアント」と称す）がネットワークを介して遠隔のサーバに接続し、画像をアップロードするといったことが一般化している。このとき、クライアントのアプリケーションは、ＨＴＴＰ（HyperText Transfer Protocol）を用いて遠隔のサーバに接続している。遠隔のサーバに接続する際に、バッファサイズを適切に設定しないと通信帯域を有効活用できないという課題があった。この課題を解決するために、往復遅延時間（ＲＴＴ：Round Trip Time）の測定とパケットロスの原因から輻輳ウインドウサイズを調節する方法が提案されている（例えば特許文献１）。

特開２０１４−９０３６７号公報

ＩＥＴＦ（Internet Engineering Task Force）では、ＨＴＴＰ／１．１の次期の規格であるＨＴＴＰ／２が提案されている。ＨＴＴＰ／２では、コネクションとストリームの双方に、送受信を行うためのバッファに相当するウインドウサイズが設定される。初期ウインドウサイズでは、帯域遅延積に相当するバッファサイズを満たさないため、通信帯域を有効活用することができないという課題がある。

例えば特許文献１に記載の技術をＨＴＴＰ／２の課題に適用した場合、ＴＣＰ（Transmission Control Protocol）の輻輳ウインドウサイズを調節することはできる。しかし、ＨＴＴＰ／２のコネクションとストリームのウインドウサイズを設定しないため、結果として帯域を有効活用した通信ができない。これにより、クライアントからサーバへの画像のアップロードや、サーバからクライアントへの画像のダウンロードが遅くなるという課題があった。

例えば、１６ＫＢｙｔｅのウインドウサイズで３０ｍｓの遅延（ＲＴＴ）のある環境では、１６Ｍｂｐｓが最大帯域幅となる。そのため、一般的なＩＥＥＥ８０２．１１ｎ規格やＩＥＥＥ８０２．１１ａｃ規格といった無線回線、ケーブルテレビ回線、光回線等の高速回線下では帯域幅の利用効率が低くなる。

本発明は、このような事情に鑑みてなされたものであり、コネクション及びストリームによって通信が行われる場合において、帯域を効率的に利用した通信を行えるようにすることを目的とする。

本発明に係る通信装置は、通信路としてのコネクションを生成して他の通信装置と接続する接続手段と、前記コネクションに少なくとも１つの論理的なストリームを確立するストリーム処理手段と、前記他の通信装置との通信情報に基づいて、前記コネクションのための第１のウインドウサイズ及び前記ストリームのための第２のウインドウサイズを決定する決定手段と、前記第１のウインドウサイズを含むウインドウ更新フレーム及び前記第２のウインドウサイズを含むウインドウ更新フレームを前記他の通信装置に送信する更新送信手段とを有することを特徴とする。

本発明によれば、コネクション及びストリームによって通信が行なわれる場合において、帯域を効率的に利用した通信が可能となる。

本発明の一実施形態における通信システムの構成例を示す図である。 本実施形態における通信装置の機能構成例を示す図である。 本実施形態における通信装置のハードウェア構成例を示す図である。 本実施形態における通信装置の動作例を示すフローチャートである。 コネクション及びストリームのウインドウサイズの例を示す図である。 本実施形態における通信装置の動作例を示すフローチャートである。 本実施形態における通信装置の動作例を示すフローチャートである。 本実施形態において通信装置と対向装置との間で行う通信動作の例を示す図である。 本実施形態において通信装置と対向装置との間で行う通信動作の例を示す図である。 本実施形態において通信装置と対向装置との間で行う通信動作の例を示す図である。

以下、本発明の実施形態を図面に基づいて説明する。

図１は、本発明の一実施形態における通信システムの構成例を示す図である。本実施形態では、通信装置１０１及び対向装置１０２がネットワーク１００に接続し、通信装置１０１は、ネットワーク１００を通じて対向装置１０２とＨＴＴＰ（HyperText Transfer Protocol）／２によって通信を行う。ネットワーク１００は、例えばインターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、及びそれらを複合したネットワークである。なお、通信装置１０１は、プロキシサーバを介して対向装置１０２と通信するようにしてもよい。

図２は、本実施形態における通信装置１０１の機能構成例を示す図である。通信装置１０１は、通信部２０１、表示部２０２、接続部２０３、ストリーム処理部２０４、判断部２０５、遅延取得部２０６、帯域幅取得部２０７、決定部２０８、更新送信部２０９、及びＨＴＴＰ処理部２１０を有する。これらの機能部２０１、２０２、２０３、２０４、２０５、２０６、２０７、２０８、２０９、２１０は、バス２００を介して互いに通信可能に接続されている。

通信部２０１は、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）の制御を行う。表示部２０２は、コンテンツの表示やエラーの表示を行う。接続部２０３は、通信路としてのＨＴＴＰ／２のコネクションを生成し対向装置１０２と接続する。ストリーム処理部２０４は、ＨＴＴＰ／２のコネクション上で論理的なストリームを確立しストリームを利用して通信を行うための処理部である。判断部２０５は、コネクションのウインドウアップデート及びストリームのウインドウアップデートを対向装置１０２に送信するか否かを判断する。ウインドウアップデートは、ウインドウサイズを更新するウインドウ更新フレームである。

遅延取得部２０６は、通信装置１０１と対向装置１０２との間の遅延を測定する。帯域幅取得部２０７は、通信装置１０１と対向装置１０２との間の通信帯域幅を取得する。決定部２０８は、遅延取得部２０６により測定された遅延及び帯域幅取得部２０７により取得された帯域幅を用いて、コネクション及びストリームのウインドウサイズを決定する。なお、決定部２０８は、遅延及び帯域幅といった通信情報以外にも、例えば動画アプリケーションの通信に必要帯域などを含めてウインドウサイズを決定してもよい。

更新送信部２０９は、コネクション及びストリームのウインドウアップデートを送信する。ＨＴＴＰ処理部２１０は、ＨＴＴＰ／２に係る処理を行う。ＨＴＴＰ処理部２１０は、例えばＨＴＴＰ／２で定義されるフレームの処理や、ヘッダ及びボディの処理、ＨＴＴＰ ＧＥＴやＨＴＴＰ ＰＵＴといったメソッドの処理等を行う。

図３は、本実施形態における通信装置１０１のハードウェア構成例を示す図である。通信装置１０１は、ＣＰＵ（プロセッサ）３０１と、ＲＯＭ３０２と、ＲＡＭ３０３とを有する。また、操作部（ＣＯＮＳ）３０９のコントローラ（ＣＯＮＳＣ）３０５と、表示部としてのディスプレイ（ＤＩＳＰ）３１０のディスプレイコントローラ（ＤＩＳＰＣ）３０６とを有する。

さらに、通信装置１０１は、ハードディスク（ＨＤ）３１１及びフレキシブルディスク等の記憶デバイス（ＳＴＤ）３１２のコントローラ（ＤＣＯＮＴ）３０７と、ネットワークインタフェースカード（ＮＩＣ）３０８とを有する。それら機能部３０１、３０２、３０３、３０５、３０６、３０７、３０８は、システムバス３０４を介して互いに通信可能に接続されている。

ＣＰＵ３０１は、ＲＯＭ３０２又はＨＤ３１１に記憶されたソフトウェア、又はＳＴＤ３１２より供給されるソフトウェアを実行することで、システムバス３０４に接続された各構成部を総括的に制御する。すなわち、ＣＰＵ３０１は、ＲＯＭ３０２、ＨＤ３１１、又はＳＴＤ３１２から処理プログラムを読み出して実行することで、本実施形態での動作を実現するための制御を行う。ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ又はワークエリア等として機能する。

ＣＯＮＳＣ３０５は、ＣＯＮＳ３０９からの指示入力を制御する。ＤＩＳＰＣ３０６は、ＤＩＳＰ３１０の表示を制御する。ＤＣＯＮＴ３０７は、ブートプログラム、種々のアプリケーション、ユーザファイル、ネットワーク管理プログラム、及び本実施形態における動作を実現するための処理プログラム等を記憶するＨＤ３１１及びＳＴＤ３１２とのアクセスを制御する。ＮＩＣ３０８はネットワーク１００上の他の装置（例えば対向装置１０２）と双方向にデータをやりとりする。

図４は、本実施形態における通信装置１０１の動作例を示すフローチャートである。図４には、通信装置１０１がＨＴＴＰ／２通信を開始した時の処理例を示している。通信装置１０１と対向装置１０２との間でＨＴＴＰ接続がされ、ＡＬＰＮ（Application Layer Protocol Negotiation）によるプロトコルアップグレードが完了している状態であるとする。また、通信装置１０１が、対向装置１０２にＨＴＴＰ ＧＥＴを送信し、画像コンテンツの取得を要求したとする。

ステップＳ４０１では、通信装置１０１の遅延取得部２０６が、通信装置１０１と対向装置１０２との間の遅延を取得する。遅延取得部２０６は、通信装置１０１と対向装置１０２との間で遅延を測定するためのパケットを送信して遅延を測定してもよいし、ＴＣＰの３ウェイハンドシェイクやＨＴＴＰ／２の送受信パケットから遅延を測定してもよい。また、遅延取得部２０６は、通信装置１０１及び対向装置１０２のＩＰアドレス又は逆引きしたＦＱＤＮ（Fully Qualified Domain Name）から各装置が存在する地域を特定して遅延を決定してもよい。

これに限らず、通信装置１０１と対向装置１０２とが移動しない装置同士であった場合、予め設定した遅延値を利用するようにしてもよい。また例えば、日本用の仕向けなどの場合、日本から日本の固定サーバにアクセスすることが予想されるため、遅延を固定値に設定してもよい。この場合、遅延は固定値となるが、後述する帯域幅が変動値となる。なお、遅延取得部２０６は、処理負荷軽減のために遅延の測定を毎回実行せずに一定期間の間は同じ遅延値を利用するようにしてもよい。

ステップＳ４０２では、通信装置１０１の帯域幅取得部２０７が、通信装置１０１と対向装置１０２との間の帯域幅を取得する。例えば、帯域幅取得部２０７は、有線帯域幅、無線帯域幅、動的な測定による帯域幅、予め設定された設定値としての帯域幅、ネットワーク１００上にある中継装置に問い合わせを行って得られた帯域幅を利用する。

また、帯域幅取得部２０７は、通信装置１０１と対向装置１０２との間で実行されるサービスが必要とする帯域幅を取得してもよい。例えば、帯域幅取得部２０７は、動画ストリーミングや音声通話の必要帯域幅、コンテンツサイズとコンテンツ送受信の終了までの時間から算出された帯域幅、予めサービスに必要と定義された帯域幅を利用してもよい。

また、帯域幅取得部２０７は、通信装置１０１と対向装置１０２との間にプロキシなどが存在しておりエンドツーエンドでの帯域幅を取得できない場合、通信経路の一部の帯域幅を通信装置１０１と対向装置１０２との間の帯域幅として利用してもよい。また、同一アプリケーションでも動画ストリーミングモードの時と画像サムネイルモードの時では必要帯域幅が異なるため、それぞれに適したウインドウサイズの設定を行う。

ステップＳ４０３では、通信装置１０１の決定部２０８が、ステップＳ４０１において取得された遅延とステップＳ４０２において取得された帯域幅から、（式１）を利用して帯域遅延積を計算する。
帯域幅（ｂｐｓ）×１／８（バイト変換）×遅延（ｍｓ） …（式１）
なお、（式１）として示した計算式は一例であって、帯域遅延積の計算には遅延の揺らぎや帯域幅の変化といったパラメータを含めてもよい。なお、通信装置１０１は、例えば遅延と帯域幅と帯域遅延積の関連付けたテーブルを参照することで帯域遅延積を決定しても良い。

本実施形態では、遅延と帯域幅とを用いる場合で説明するが、これに限らず、アプリケーションやミドルウェアの要求を用いて計算してもよく、アプリケーションやミドルウェアが必要なウインドウサイズを要求してもよい。更に、決定部２０８は、ボトルネックの原因が遅延や帯域幅など以外（アプリケーションの表示速度、バス速度、メモリサイズ、ＣＰＵパワーなど）にある場合、それらを変更できない場合には制約条件として計算に含めてもよい。なお、変更可能な場合には変更要求を送信して変更させるようにしてもよい。

ステップＳ４０４では、決定部２０８が、コネクション用のウインドウサイズを決定する。また、ステップＳ４０５では、決定部２０８が、ストリーム用のウインドウサイズを決定する。このステップＳ４０４及びＳ４０５において帯域遅延積を満たすウインドウサイズを決定するとき、決定部２０８は、揺らぎやアプリケーションがレンダリングするまでの時間などを考慮してもよい。更に、決定部２０８は、現在のウインドウサイズと決定した最適なウインドウサイズとの差分を計算し、ウインドウアップデート送信のためのウインドウサイズを決定する（図５参照）。

図５は、コネクション及びストリームのウインドウサイズの例を示す図である。図５に示す例では、１つのコネクションの中に３つのストリームが含まれる。説明のため、帯域遅延積を満たすウインドウサイズ、すなわち（帯域遅延積）≦（ウインドウサイズ）となるウインドウサイズを必要ウインドウサイズと名付ける。ストリームＩＤがｉｄ＝０はコネクションを示し、ｉｄ＝１、３、５はストリームを示す。帯域幅が１００Ｍｂｐｓ、遅延が４０ｍｓである場合のウインドウサイズの設定例を示している。

コネクション（ｉｄ＝０）は、５００ＫＢｙｔｅの必要ウインドウサイズを（式１）の計算式を用いて算出できる。ストリーム（ｉｄ＝１、３、５）は、アプリケーションが定めた優先度があり、各ストリームに対して帯域幅を５ＫＢｙｔｅ、９５ＫＢｙｔｅ、４００ＫＢｙｔｅと割り振っている。なお、各ストリームに対する割り振りは、優先度を用いて行ってもよいし、アプリケーションが必要な帯域を予め設定又は対向装置１０２から取得して行ってもよい。現在のウインドウサイズは、コネクション（ｉｄ＝０）とストリーム（ｉｄ＝１、３、５）がそれぞれ６４ＫＢｙｔｅである。本実施形態では６４ＫＢｙｔｅとしたが、ＨＴＴＰ／２のＳＥＴＴＩＮＧＳフレームを設定することでデフォルト値を変更することができる。

必要ウインドウサイズから現在のウインドウサイズを引いた分が、必要ウインドウサイズに足りないウインドウサイズとなる。コネクション（ｉｄ＝０）、及びストリーム（ｉｄ＝３、５）のようにウインドウサイズが足りていない場合、ウインドウアップデートによるウインドウサイズの更新を行う。この例では、コネクション（ｉｄ＝０）は４３６ＫＢｙｔｅ、ストリーム（ｉｄ＝３）は３１ＫＢｙｔｅ、ストリーム（ｉｄ＝５）は３３６ＫＢｙｔｅとなる。一方、ストリーム（ｉｄ＝１）のようにウインドウサイズが足りている場合、ウインドウアップデートによるウインドウサイズの更新を行わない。更新送信部２０９によってウインドウアップデート（ウインドウ更新フレーム）が送信された後、現在のウインドウサイズを更新送信部２０９によって送信したウインドウサイズに変更する。

以上のように、必要ウインドウサイズを満たすようにウインドウアップデートによって更新するウインドウサイズを決定することができる。本実施形態では説明の簡単化のために、遅延と帯域幅のみのパラメータを用いた例で説明したが、前述の通り揺らぎを用いた計算を行っても良い。

通信装置１０１のメモリの制約上、必要ウインドウサイズ分のメモリを確保できない場合、確保できるまでのウインドウサイズをコネクション（ｉｄ＝０）に設定し、各ストリーム（ｉｄ＝１、３、５）にストリームで増やした分のウインドウサイズを割り振る。コネクションによってＨＴＴＰ／２通信で送受信されるデータ量が決定されるため、必ずしもコネクションのウインドウサイズとストリームのウインドウサイズとを一致させる必要はない。ストリームのウインドウサイズの総量をコネクションのウインドウサイズより大きくすることで、送信可能なストリームからコネクションのウインドウサイズを有効利用して送信することが可能となる。また、新しいストリームが作成されることが分かっている場合、予め大きめのコネクションのウインドウサイズを割り当ててもよい。これによって、新しいストリーム生成時のウインドウアップデートの送信を低減できる。

ステップＳ４０６では、通信装置１０１の判断部２０５が、コネクション用のウインドウアップデートを送信するか否かを判断する。判断部２０５は、図５においてストリームＩＤがｉｄ＝０である行の情報を確認し、ウインドウアップデートのサイズ（４３６ＫＢｙｔｅ）があるため、コネクション用のウインドウアップデートを送信すると判断し、ステップＳ４０７に進む。ステップＳ４０７では、通信装置１０１の更新送信部２０９が、コネクション用のウインドウアップデートを対向装置１０２に送信する。なお、ステップＳ４０６において、判断部２０５がコネクション用のウインドウアップデートを送信しないと判断した場合、ステップＳ４０８に進む。

また、ステップＳ４０６において判断部２０５は、コネクション用のウインドウアップデートのサイズがあるか以外にもメモリなどのリソースが確保できるかの判断を行う。例えば、判断部２０５が十分なメモリなどのリソースが確保できないと判断した場合、ウインドウアップデートで示すウインドウサイズをメモリなどのリソースが確保できる範囲で設定してもよい。本実施形態では、以後説明の簡単化のために、判断部２０５がウインドウアップデート時には十分なメモリなどのリソースがあると判断した前提で説明する。

ステップＳ４０８では、判断部２０５が、ストリーム用のウインドウアップデートを送信するか否かを判断する。判断部２０５は、図５においてストリームＩＤがｉｄ＝１、３、５である行の情報を確認する。判断部２０５は、ウインドウアップデートのサイズがプラス値であるｉｄ＝３とｉｄ＝５のウインドウアップデートを送信すると判断し、ステップＳ４０９に進む。また、判断部２０５は、ウインドウアップデートのサイズがない（プラス値ではない）ｉｄ＝１のウインドウアップデートを送信しないと判断する。なお、本実施形態では３つのストリームがあるが、ｉｄ＝１のストリームのみであった場合、判断部２０５はストリーム用のウインドウアップデートを送信しないと判断し、処理を終了する。

ステップＳ４０９では、更新送信部２０９が、判断部２０５によってウインドウアップデートを送信すると判断されたストリームＩＤに関連付けられた、ストリーム用のウインドウアップデートを対向装置１０２に送信する。その後、処理を終了する。

図６は、本実施形態における通信装置１０１の動作例を示すフローチャートである。図６には、対向装置１０２が過去に接続したことのある通信相手であって、通信装置１０１でのウインドウサイズ決定の処理を低減する場合の処理例を示している。

ステップＳ６０１では、通信装置１０１のＨＴＴＰ処理部２１０が、対向装置１０２が過去にＨＴＴＰ／２接続したことのある対向装置であるか否かを判断する。ＨＴＴＰ処理部２１０がＨＴＴＰ／２接続したことのある装置であると判断すると、ステップＳ６０２に進む。一方、ＨＴＴＰ処理部２１０がＨＴＴＰ／２接続したことのない対向装置であると判断すると、ステップＳ６０３に進む。

ステップＳ６０２では、決定部２０８が、過去に対向装置１０２と接続したときに取得し保存していた帯域遅延積を利用して、コネクション用及びストリーム用のウインドウサイズをそれぞれ決定する。その後、更新送信部２０９が、必要に応じてコネクション用及びストリーム用のウインドウアップデートを対向装置１０２に送信する。

ステップＳ６０３では、通信装置１０１は図４に示した処理を実行して、ステップＳ６０４に進む。ステップＳ６０４では、ステップＳ６０３での処理において計算した帯域遅延積を保存し、処理を終了する。

本実施形態では、帯域遅延積を保存するようにしているが、これに限らず、遅延と帯域幅を保存して再利用してもよいし、必要ウインドウサイズを保存して再利用してもよい。また、これらパラメータの一部を再利用するようにしてもよい。このように過去の接続によって得られたパラメータを再利用することで、必要ウインドウサイズの取得のための処理や決定のための処理を低減することができる。

図７は、本実施形態における通信装置１０１の動作例を示すフローチャートである。図７には、ウインドウサイズを再計算するか否かを判断するための処理例を示している。

ステップＳ７０１では、遅延取得部２０６が、通信装置１０１と対向装置１０２との間の遅延が変化したか否かの確認を行う。遅延が変化したと遅延取得部２０６が判断すると、ステップＳ７０３に進む。一方、遅延が変化していないと遅延取得部２０６が判断すると、ステップＳ７０２に進む。

ステップＳ７０２では、帯域幅取得部２０７が、通信装置１０１と対向装置１０２との間の帯域幅が変化したか否かの確認を行う。帯域幅が変化したと帯域幅取得部２０７が判断すると、ステップＳ７０３に進む。一方、帯域幅が変化していないと帯域幅取得部２０７が判断すると、ステップＳ７０４に進む。

ステップＳ７０１及びＳ７０２での遅延取得部２０６及び帯域幅取得部２０７の判断は、値の比較によって一定以上の差があった場合に変化したと判断してもよい。また、必要ウインドウサイズが大きくなる場合のみ（遅延及び帯域幅が大きくなった場合のみ）変化したと判断してもよい。

ステップＳ７０３では、決定部２０８が、遅延取得部２０６及び帯域幅取得部２０７から現在の遅延及び帯域幅を取得して、帯域遅延積の再計算を行う。なお、帯域遅延積の計算は、図４に示したステップＳ４０３と同様に、例えば（式１）を利用して計算すればよい。

ステップＳ７０４では、ＨＴＴＰ処理部２１０が一定時間待機する。ここでの待機時間は、予め定められた時間でもよいし、遅延や帯域幅の変化の頻度によって間隔を変えてもよい。次のステップＳ７０５では、ＨＴＴＰ処理部２１０が、対向装置１０２とのコネクションが切断されたか否かを判断する。ＨＴＴＰ接続が切断されたとＨＴＴＰ処理部２１０が判断すると、処理を終了する。一方、まだＨＴＴＰ接続中であるとＨＴＴＰ処理部２１０が判断すると、ステップＳ７０１に進む。

このようにすることで、動作中の通信装置１０１でウインドウサイズを再計算し、変動するパラメータに適したウインドウアップデートを送信することが可能となる。通信装置１０１は、不必要にリソースを確保することなく帯域遅延積を満たすウインドウサイズを確保した通信を行うことが可能となる。本実施形態では、説明の簡単化のために遅延と帯域について確認する例を示しているが、これに限らず、揺らぎ、アプリケーションの要求の変更、メモリといったウインドウサイズが変更される要因が変更された時にも同様に適用できる。

以下、本実施形態において通信装置１０１と対向装置１０２との間で行う通信動作の例について説明する。

＜ＨＴＴＰ ＧＥＴメソッドでコンテンツ取得を行う場合＞
図８は、本実施形態において通信装置１０１と対向装置１０２との間でＨＴＴＰ ＧＥＴメソッドでコンテンツ取得を行う場合のシーケンスの例を示す図である。以下では、簡単化のためにｉｄ＝５のストリームのみについて記す。ｉｄ＝１及びｉｄ＝３のストリームがある場合、各ストリームＩＤに対応したストリーム用のウインドウアップデートが送信される点で異なる。コネクション用のウインドウサイズについては、一定期間毎に送信してもよいし、各ストリーム用のウインドウアップデートの合計値毎や、各ストリーム用のウインドウアップデートの送信時に送信してもよい。

通信装置１０１は、対向装置１０２に対してＴＬＳ（Transport Layer Security）で接続し、ＨＴＴＰ／１．１からＨＴＴＰ／２へプロトコルアップグレードする（Ｍ８０１）。その後、通信装置１０１は、対向装置１０２にＨＥＡＤＥＲＳフレームでＨＴＴＰのＧＥＴメッセージを送信する（Ｍ８０２）。対向装置１０２は、通信装置１０１にＨＥＡＤＥＲＳフレームでＨＴＴＰのＧＥＴメッセージへの返答である２００ ＯＫを送信する（Ｍ８０３）。

次に、通信装置１０１は、対向装置１０２との間の遅延を取得し（Ｍ８０４）、対向装置１０２との間の帯域幅を取得する（Ｍ８０５）。そして、通信装置１０１は、取得した遅延及び帯域幅を用いて対向装置１０２との間における帯域遅延積を計算する（Ｍ８０６）。

次に、通信装置１０１は、対向装置１０２との間で接続されているＨＴＴＰ／２のコネクション用のウインドウサイズを決定する（Ｍ８０７）。また、通信装置１０１は、対向装置１０２との間で接続されているＨＴＴＰ／２のコネクション上で通信するストリーム用のウインドウサイズを決定する（Ｍ８０８）。

次に、通信装置１０１は、対向装置１０２にコネクション用のウインドウアップデートを送信するか否かを判断し（Ｍ８０９）、送信すると判断した場合には、対向装置１０２にコネクション用のウインドウアップデートを送信する（Ｍ８１０）。また、通信装置１０１は、対向装置１０２にストリーム用のウインドウアップデートを送信するか否かを判断し（Ｍ８１１）、送信すると判断した場合には、対向装置１０２にストリーム用のウインドウアップデートを送信する（Ｍ８１２）。

その後、通信装置１０１は、対向装置１０２からＨＴＴＰのＧＥＴメッセージの返答であるＨＴＴＰのボディ部を受信する（Ｍ８１３）。例えば、通信装置１０１は、対向装置１０２から画像コンテンツを受信する。

通信装置１０１が対向装置１０２からＨＴＴＰのボディ部を受信すると、ウインドウサイズが小さくなる（図５に示す現在のウインドウサイズがデータサイズ分減る）。通信装置１０１は、コネクション用のウインドウサイズを再決定し、コネクション用のウインドウアップデートを送信するか否かを判断する（Ｍ８１４）。送信すると判断した場合には、通信装置１０１は、対向装置１０２にコネクション用のウインドウアップデートを送信する（Ｍ８１５）。

また、通信装置１０１は、ストリーム用のウインドウアップデートを再決定し、ストリーム用のウインドウアップデートを送信するか否かを判断する（Ｍ８１６）。送信すると判断した場合には、通信装置１０１は、対向装置１０２にストリーム用のウインドウアップデートを送信する（Ｍ８１７）。

ここでは、図６に示した処理に従って保存済みの帯域遅延積を用いて再決定を行うものとするが、これに限らず、図７に示した処理のように遅延や帯域幅の再取得を行っても良い。図６に示した処理及び図７に示した処理は毎回変更の確認を行う必要はなく、時間毎や回数毎に切り替えてもよい。

次に、通信装置１０１は、対向装置１０２から続きのＨＴＴＰのボディ部を受信する（Ｍ８１８）。通信装置１０１は、対向装置１０２から更に続きのＨＴＴＰのボディ部を受信する（Ｍ８１９）。

その後、通信装置１０１は、コネクション用のウインドウサイズを再決定して、コネクション用のウインドウアップデートを送信するか否かを判断し、ここでは対向装置１０２にコネクション用のウインドウアップデートを送信しないと判断する（Ｍ８２０）。また、通信装置１０１は、対向装置１０２にストリーム用のウインドウアップデートを送信しないと判断する（Ｍ４２１）。例えば、判断部２０５が帯域遅延積を満たすウインドウサイズがまだ割り当てられていると判断した場合、ウインドウアップデートを送信しないと判断できる。また、ＨＴＴＰヘッダに含まれるＣｏｎｔｅｎｔＬｅｎｇｔｈからコンテンツ長が分かっており、既に必要十分なウインドウサイズが割り当てられている場合、ウインドウアップデートを送信しないと判断できる。

この例では、Ｍ８１８及びＭ８１９の２つのメッセージを受信したが、これに限らず、１つのメッセージを受信した段階（Ｍ８１８のみ）でＭ８２０及びＭ８２１の処理に進んでもよい。また、判断部２０５がウインドウサイズに余裕があると判断した場合や決定部２０８が予め余裕を持たせて決定していた場合、２つのメッセージだけでなく３つ以上のメッセージを受信してからＭ８２０及びＭ８２１の処理に進んでもよい。

その後、通信装置１０１は、対向装置１０２からＨＴＴＰのボディ部の残りとストリーム終了（ＥＮＤ＿ＳＴＲＥＡＭ）を受信する（Ｍ８２２）。通信装置１０１は、例えば表示部２０２を用いて、取得した画像コンテンツの表示を行う。表示部２０２には、画像コンテンツに限らず、ＨＴＴＰヘッダなどを表示してもよい。また、表示部２０２には送受信中に発生したコネクションエラーなどを表示してもよい。

通信装置１０１は、対向装置１０２とのコネクションが切断される場合、ウインドウアップデートを送信しないが、コネクションが切断されない場合、Ｍ８２２の後に対向装置１０２にコネクション用のウインドウアップデートを送信してもよい（Ｍ８２３）。これにより、新しくストリームを生成した時のウインドウアップデートを先に送信することで、速度向上につながる。このコネクション用のウインドウアップデートは単独で送ってもいいし、他のストリームが処理されている時に発生するコネクション用のウインドウアップデートの更新時にまとめて処理してもよい。

＜ＨＴＴＰ ＰＵＴメソッドでコンテンツをアップロードする場合＞
図９は、本実施形態において対向装置１０２が通信装置１０１にＨＴＴＰ ＰＵＴメソッドでコンテンツをアップロードする場合のシーケンスの例を示す図である。

通信装置１０１は、対向装置１０２に対してＴＬＳで接続し、ＨＴＴＰ／１．１からＨＴＴＰ／２へプロトコルアップグレードする（Ｍ９０１）。その後、対向装置１０２は、通信装置１０１にＨＥＡＤＥＲＳフレームでＥｘｐｅｃｔヘッダに１００−ｃｏｎｔｉｎｕｅを付けたＨＴＴＰのＰＵＴメッセージを送信する（Ｍ９０２）。通信装置１０１は、対向装置１０２にＨＥＡＤＥＲＳフレームでＨＴＴＰのＰＵＴメッセージへの暫定応答である１００ ＣＯＮＴＩＮＵＥを送信する（Ｍ９０３）。

これにより、通信装置１０１は、対向装置１０２からのコンテンツ送信を受け付けることを通知する。なお、通信装置１０１が対向装置１０２からのＨＴＴＰ ＰＵＴメソッドによるコンテンツのアップロードを受け付けられない場合、エラーを返し処理を終了する。Ｍ９０４〜Ｍ９１２の処理は、図８に示したＭ８０４〜Ｍ８１２の処理と同様であるため説明を省略する。

通信装置１０１は、対向装置１０２からＨＴＴＰのＰＵＴメッセージのボディ部を受信する（Ｍ９１３）。通信装置１０１は、対向装置１０２から続きのＨＴＴＰのボディ部を受信する（Ｍ９１４）。例えば、ＨＴＴＰのＰＵＴメッセージのボディ部には画像コンテンツが含まれる。Ｍ９１５〜Ｍ９１８の処理は、図８に示したＭ８１４〜Ｍ８１７の処理と同様であるため説明を省略する。

次に、通信装置１０１は、対向装置１０２から続きのＨＴＴＰのボディ部を受信する（Ｍ９１９）。通信装置１０１は、対向装置１０２から更に続きのＨＴＴＰのボディ部を受信する（Ｍ９２０）。Ｍ９２１及びＭ９２２の処理は、図８に示したＭ８２０及びＭ８２１の処理と同様であるため説明を省略する。

その後、通信装置１０１は、対向装置１０２からＨＴＴＰのボディ部の残りを受信する（Ｍ９２３）。通信装置１０１は、対向装置１０２にＨＴＴＰ ２００ ＯＫとストリーム終了（ＥＮＤ＿ＳＴＲＥＡＭ）を送信する（Ｍ９２４）。通信装置１０１は、例えば対向装置１０２からアップロードされたコンテンツを表示部２０２を用いて表示してもよい。表示部２０２には、画像コンテンツに限らず、ＨＴＴＰヘッダなどを表示してもよい。また、表示部２０２には送受信中に発生したコネクションエラーなどを表示してもよい。

このようにして、本実施形態によれば、通信装置１０１と対向装置１０２との間で帯域幅やリソースを有効に利用した通信を行うことができる。通信装置１０１がウインドウアップデートをＨＴＴＰのボディ部の受信前に送信することで、ＨＴＴＰのボディ部の受信前にウインドウサイズを増加させることができるようになりスループットが向上する。

本実施形態では、ＨＴＴＰ／２のウインドウサイズを変更したが、更に、帯域遅延積をＴＣＰ等の他レイヤのプロトコルのバッファサイズと合わせてもよい。これにより、ＨＴＴＰ／２を利用して通信を行う通信装置は他レイヤでのバッファサイズが足りないことによる速度低下を低減できる。また、メモリなどのリソースが足りない場合は、ＨＴＴＰ／２のウインドウサイズだけに割り振るのではなく他レイヤのプロトコルと均等にリソースを割り当てることで性能を向上させることができる。

ここではＨＴＴＰのＧＥＴメッセージ及びＰＵＴメッセージの例を示したが、これに限らず、他のＨＴＴＰメソッドでボディ部を含むもの（ＰＯＳＴメソッドなど）であった場合にも適用できる。また、ＨＴＴＰによる処理を例に説明したが、これに限らず、リクエストレスポンス型の通信で送信制御を行うプロトコルに適用できる。

本実施形態によれば、例えば、動画ストリーミングの要求帯域幅（２４Ｍｂｐｓ）が設定された場合、通信装置１０１は適したウインドウサイズで高速にコンテンツデータを受信することができる。これにより、立ち上がりの動画ストリーミングのバッファリング時間を低減させることができる。また、ウインドウアップデートが送信されるまでの間、動画ストリーミングの開始時に要求帯域幅に満たないことによる性能低下（ノイズ、開始が遅い、コマ落ちなど）を低減できる。さらに、必要以上にウインドウサイズを大きくしないため、通信制御以外のアプリケーション（例えば、画像処理やユーザーインターフェース）のメモリを圧迫することなく、製品としての性能劣化を低減できる。

次に、通信装置１０１と対向装置１０２との間で１つのコネクション上で複数のストリームを処理する場合の例について説明する。図１０は、本実施形態において通信装置１０１が対向装置１０２から複数のＨＴＴＰのＧＥＴメッセージでコンテンツ取得を行う場合のシーケンスの例を示す図である。

通信装置１０１は、対向装置１０２に対してＴＬＳで接続し、ＨＴＴＰ／１．１からＨＴＴＰ／２へプロトコルアップグレードする（Ｍ１００１）。その後、通信装置１０１は、対向装置１０２との間のコネクション上で３つのストリーム（ｉｄ＝１、３、５）を開始する。

通信装置１０１は、ストリーム１（ｉｄ＝１のときのストリームを以後、ストリーム１と呼ぶ）を用いて対向装置１０２にＨＴＴＰのＧＥＴメッセージで画像コンテンツの取得を行う（Ｍ１００２）。通信装置１０１は、対向装置１０２から２００ ＯＫのレスポンスを受信する（Ｍ１００３）。また、通信装置１０１はストリーム３（ｉｄ＝３のときのストリームを以後、ストリーム３と呼ぶ）を用いて対向装置１０２にＨＴＴＰのＧＥＴメッセージで画像コンテンツの取得を行う（Ｍ１００４）。通信装置１０１は、対向装置１０２から２００ ＯＫのレスポンスを受信する（Ｍ１００５）。また、通信装置１０１は、ストリーム５（ｉｄ＝５のときのストリームを以後、ストリーム１と呼ぶ）を用いて対向装置１０２にＨＴＴＰのＧＥＴメッセージで画像コンテンツの取得を行う（Ｍ１００６）。通信装置１０１は、対向装置１０２から２００ ＯＫのレスポンスを受信する（Ｍ１００７）。

その後、通信装置１０１は、コネクション及びストリームのウインドウサイズを決定する（Ｍ１００８）。この例では、コネクション及び複数のストリームのウインドウサイズの決定を一括して行うことで、帯域遅延積の計算など共通的な処理量を低減させている。なお、コネクション及び複数のストリームのウインドウサイズの決定の一部の処理のみをまとめて実行してもよい。例えば、ストリーム１、ストリーム３、ストリーム５の処理のみ一括して実行するようにしてもよい。

通信装置１０１は、コネクション用のウインドウアップデートを送信する（Ｍ１００９）。また、通信装置１０１は、ストリーム１、ストリーム３、ストリーム５用のウインドウアップデートをそれぞれ送信する（Ｍ１０１０〜Ｍ１０１２）。この例では、通信装置１０１は、コネクション用のウインドウアップデートの次にストリーム用のウインドウアップデートを送信しているが、これに限らず、ストリーム用のウインドウアップデートから送信してもよい。また、場合によっては、ウインドウアップデートを送信しないと判断することもある。

通信装置１０１は、対向装置１０２からストリーム１、ストリーム３、ストリーム５のＨＴＴＰのボディ部を受信する（Ｍ１０１３〜Ｍ１０１５）。その後、通信装置１０１は、コネクション及びストリームのウインドウサイズを決定する（Ｍ１０１６）。ここでは、通信装置１０１は、コネクション、ストリーム１、ストリーム３、ストリーム５用のウインドウアップデートを送信しないと判断する。

例えば、ストリーム１はＨＴＭＬのインデックスであり、ストリーム３とストリーム５で２つの画像をダウンロードしているとする（この例の場合、ストリーム１のボディ部は、ストリーム３とストリーム５の開始よりも先に取得しているものとする）。ＨＴＭＬインデックスには他の画像やリソースへの取得はないため、通信装置１０１と対向装置１０２とのコネクションが終了する。ストリーム５の後に新たなストリームが作成されることはないため、ウインドウアップデートを送信しなくてよいと判断できる。このように、アプリケーションからウインドウアップデートを送信するか否かの判断を行うことができる。

また、画像コンテンツの一覧を既に取得している状態で、アプリケーションが３つのコンテンツを取得するとする（ストリーム１、ストリーム３、ストリーム５）。この場合においても、新たなストリームが作成されることはないため、ウインドウアップデートを送信しなくてよいと判断できる。

通信装置１０１は、対向装置１０２からストリーム１、ストリーム３、ストリーム５の残りのＨＴＴＰのボディ部とストリーム終了（ＥＮＤ＿ＳＴＲＥＡＭ）を受信する（Ｍ１０１７〜Ｍ１０１９）。通信装置１０１は、対向装置１０２とのＨＴＴＰ／２のコネクションを切断し、更にＴＬＳ接続を切断する（Ｍ１０２０）。

以上のように、図１０に示した例によれば、複数のストリームを実行した場合にウインドウサイズの決定処理を低減することができる。また、アプリケーションの要求に応じてウインドウアップデートを送信するか否かを判断することで、ウインドウアップデートの送信処理のオーバーヘッドを低減することができる。図１０においては、図８に示した例を基に説明したが、図９に示した例においても同様に適用できる。

（本発明の他の実施形態）
本発明は、前述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

なお、前記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００：ネットワーク １０１：通信装置 １０２：対向装置 ２０１：通信部 ２０２：表示部 ２０３：接続部 ２０４：ストリーム処理部 ２０５：判断部 ２０６：遅延取得部 ２０７：帯域幅取得部 ２０８：決定部 ２０９：更新送信部 ２１０：ＨＴＴＰ処理部

Claims (11)

1. 通信路としてのコネクションを生成して他の通信装置と接続する接続手段と、
   前記コネクションに少なくとも１つの論理的なストリームを確立するストリーム処理手段と、
   前記他の通信装置との通信情報に基づいて、前記コネクションのための第１のウインドウサイズ及び前記ストリームのための第２のウインドウサイズを決定する決定手段と、
   前記第１のウインドウサイズを含むウインドウ更新フレーム及び前記第２のウインドウサイズを含むウインドウ更新フレームを前記他の通信装置に送信する更新送信手段とを有することを特徴とする通信装置。
2. 前記ウインドウ更新フレームを前記他の通信装置に送信するか否かを前記決定手段により決定された前記第１及び第２のウインドウサイズのうち少なくともいずれかに基づいて判断する判断手段を有することを特徴とする請求項１記載の通信装置。
3. 前記判断手段は、前記第１のウインドウサイズと前記コネクションのウインドウサイズとを比較し、前記第１のウインドウサイズが前記コネクションのウインドウサイズより大きい場合、前記ウインドウ更新フレームを前記他の通信装置に送信すると判断することを特徴とする請求項２記載の通信装置。
4. 前記判断手段は、前記第２のウインドウサイズと前記ストリームのウインドウサイズとを比較し、前記第２のウインドウサイズが前記ストリームのウインドウサイズより大きい場合、前記ウインドウ更新フレームを前記他の通信装置に送信すると判断することを特徴とする請求項２又は３記載の通信装置。
5. 前記通信情報には、前記他の通信装置との間の帯域幅及び遅延の少なくとも一方を含むことを特徴とする請求項１〜４の何れか１項に記載の通信装置。
6. 前記他の通信装置との間の帯域幅を取得する帯域幅取得手段を有することを特徴とする請求項５記載の通信装置。
7. 前記他の通信装置との間の遅延を取得する遅延取得手段を有することを特徴とする請求項５又は６記載の通信装置。
8. 前記通信情報には、前記他の通信装置との間の帯域幅及び遅延を含み、
   前記決定手段は、前記他の通信装置との間の帯域幅及び遅延を基に算出される帯域遅延積を用いて、前記第１のウインドウサイズ及び前記第２のウインドウサイズを決定することを特徴とする請求項１〜４の何れか１項に記載の通信装置。
9. 通信路としてのコネクションを生成して他の通信装置と接続する工程と、
   前記コネクションに少なくとも１つの論理的なストリームを確立する工程と、
   前記他の通信装置との通信情報に基づいて、前記コネクションのための第１のウインドウサイズ及び前記ストリームのための第２のウインドウサイズを決定する工程と、
   前記第１のウインドウサイズを含むウインドウ更新フレーム及び前記第２のウインドウサイズを含むウインドウ更新フレームを前記他の通信装置に送信する工程とを有することを特徴とする通信方法。
10. 第１の通信装置と第２の通信装置とがネットワークを介して接続された通信システムであって、
    前記第１の通信装置は、
    通信路としてのコネクションを生成して前記第２の通信装置と接続する接続手段と、
    前記コネクションに少なくとも１つの論理的なストリームを確立するストリーム処理手段と、
    前記第２の通信装置との通信情報に基づいて、前記コネクションのための第１のウインドウサイズ及び前記ストリームのための第２のウインドウサイズを決定する決定手段と、
    前記第１のウインドウサイズを含むウインドウ更新フレーム及び前記第２のウインドウサイズを含むウインドウ更新フレームを前記第２の通信装置に送信する更新送信手段とを有し、
    前記更新送信手段より送信されたウインドウ更新フレームに応じたウインドウサイズで前記第１の通信装置と前記第２の通信装置との間で通信を行うことを特徴とする通信システム。
11. 通信路としてのコネクションを生成して他の通信装置と接続するステップと、
    前記コネクションに少なくとも１つの論理的なストリームを確立するステップと、
    前記他の通信装置との通信情報に基づいて、前記コネクションのための第１のウインドウサイズ及び前記ストリームのための第２のウインドウサイズを決定するステップと、
    前記第１のウインドウサイズを含むウインドウ更新フレーム及び前記第２のウインドウサイズを含むウインドウ更新フレームを前記他の通信装置に送信するステップとをコンピュータに実行させるためのプログラム。

Images