JP6483636B2 - Ｗｅｂコンテンツ配信方法 - Google Patents

Description

本発明は、クライアントがサーバからWebコンテンツを高速に受信するためのWebコンテンツ配信方法に係り、特に、疑似的に初期の輻輳ウィンドウサイズを拡張することで高速なWebコンテンツ配信を可能にするWebコンテンツ配信方法に関する。

現在のインターネットにおいて、Webコンテンツの配信プロトコルとして普及しているHTTPのバージョン1.1は、主にkeep-alive（キープアライブ）機能により、多数の画像コンテンツを含むWebページの表示などが高速化される。HTTP/1.1では、その初めは同時接続できるコネクション数が少なかったため、これを補う技術としてマルチドメイン構成のWebページが開発された。しかしながら、keep-alive機能では、リクエストの送信後、そのレスポンスを受信するまで、次のリクエストを送信することができないので十分な高速化を実現できない。

このような技術課題を解決するために、HTTPの次世代のバージョンとしてHTTP/2.0が研究されている。このHTTP/2.0では、複数のHTTPセッションを単一のTCPコネクション上で並列に確立することで上記の技術課題を解決している。

非特許文献１には、単一TCPコネクション上のHTTPセッションの多重化、HTTPリクエストの優先度付け、冗長なヘッダの省略、通信データの圧縮の必須化、サーバからのPush配信を行うことで、既存のHTTPにおけるWebコンテンツ配信速度の向上を行う技術が開示されている。この技術はセッション層に実装され、これにより、既存のTCP、SSL、HTTPに手を加えることなく前述の機能を実現する。

非特許文献２には、HTTPを用いてStreaming配信を行うMPEG-DASH(Dynamic adaptive streaming over HTTP)をSPDYの配信に適用させる技術が開示されている。MPEG-DASHでは、コンテンツを配信するネットワーク帯域に応じた複数の符号化レートで（サーバに）保持する。また、コンテンツを10秒単位のセグメントに分割する。コンテンツのStreaming配信・再生に必要な情報（コンテンツの取得先、コンテンツの種類、解像度、最大ビットレート、DRM情報）はMPD(The Media Presentation Description)ファイルに記述される。

クライアントはMPDファイルを解析してサーバに該当コンテンツのセグメントのリクエストをHTTP GET REQUESTとして送信し、サーバからコンテンツのセグメントを(HTTP GET RESPONSEとして)受信する。クライアントの使用可能な帯域幅が狭い場合は、クライアントは低レートのセグメントをリクエスト送信時に選択し、要求することで符号化レートの変更を可能としている。

非特許文献2ではさらに、HTTP2.0(SPDY)を適用することで、初期輻輳ウィンドウサイズの拡大やリクエスト(HTTP GET Request)の多重化、冗長となるHTTPヘッダの圧縮を用いてHTTP Streamingの高速化を実現している。

IETF httpbis Internet-Draft, Hypertext Transfer Protocol version 2 (14) The 2013 IEEE International Conference on Multimedia and Expo (ICME)2013, p1-p6、DYNAMIC ADAPTIVE STREAMING OVER HTTP/2.0

非特許文献1では、初期輻輳ウィンドウサイズをTCPコネクションの仕様における最大値の64Kbyteまで拡張して用いている。しかしながら、単一のTCPコネクション上でHTTPセッションの多重化を実現するため、複数のTCPコネクションを用いる既存のHTTP/1.1のように、疑似的に初期輻輳ウィンドウサイズを拡張する手法と比べるとウィンドウサイズが十分とは言えず、Webコンテンツ配信の高速化の制限となるという問題が生じる。

サーバの輻輳ウィンドウサイズを変更する場合は、サーバの設定を変更するか、SPDY（登録商標）のWINDOW_UPDATEフレームを送信する必要がある。前者の場合は、サーバに一台ずつ設定を行う必要があるため現実的ではない。後者の場合は、クライアント・サーバ間で複数回のやり取りが必要となり、そこまで大きな初期輻輳ウィンドウサイズが利用できないという問題がある。

非特許文献2は、MPEG-DASHにSPDY（登録商標）を単純に適用したのみである。そのため、非特許文献1と同様の技術課題を含んでいる。

本発明の目的は、従来技術の課題を全て解決し、クライアント・サーバ間に複数のSPDYセッションを確立することで、サーバに手を加えることなく、単一TCPコネクションの初期の輻輳ウィンドウサイズを疑似的に拡張できるWebコンテンツ配信の高速化を実現することにある。

上記の目的を達成するために、本発明は、サーバがクライアントへSPDYセッションでコンテンツを配信するWebコンテンツ配信方法において、クライアントがサーバとの間に先行SPDYセッションを確立してコンテンツの構成ファイルを要求する手順と、クライアントが、先行SPDYセッションの確立要求から構成ファイル受信までの待機遅延期間を利用して、サーバとの間に複数の後行SPDYセッションを確立する手順と、クライアアントが先行SPDYセッションで受信した構成ファイルにアドレス情報が記述されている各サブコンテンツを各SPDYセッションで並列的に受信する手順とを含むようにした。

本発明によれば、以下のような効果が達成される。
(1) 複数のSPDYセッションを用いて、疑似的に初期輻輳ウィンドウサイズを拡大できるので、Webコンテンツ配信の高速化が期待できるようになる。

(2) 先行SPDYセッションの確立を要求してから構成ファイルを受信するまでの応答遅延期間中に、サーバとの間に複数のSPDYセッションを確立する手順を実行することにより、複数のSPDYセッションを確立するための所要時間を、先行SPDYセッションの確立要求から構成ファイル受信までの応答遅延期間に重ねられるので、複数のSPDYセッションを追加的に確立するための所要時間がコンテンツ配信を遅延させてしまうことを防止できる。

(3) HTTP Streamingにおける各セグメントの配信方法が、セグメントの転送速度に応じて切り換えられるので、低速時でも途切れの無い再生を可能にでき、高速時にはシーケンスバーの先送りに対応できるなどの利便性の向上が可能になる。

(4) サーバ側を改修することなく、クライアント側の改修、実装のみで対応できるので、既存システムへの適用が容易となる。

本発明のコンテンツ配信方法の概要を説明するための図である。 本発明の一実施形態の動作を示したフローチャートである。 コンテンツがWebページである場合のクライアント／サーバ間でのシーケンスフローである。 コンテンツがHTTP Streamingである場合のクライアント／サーバ間でのシーケンスフローである。 HTTP Streamingにおけるセグメントの第１の配信方法を示した図である。 HTTP Streamingにおけるセグメントの第２の配信方法を示した図である。

以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明のWebコンテンツ配信方法の概要を説明するための図であり、クライアント１はサーバ２との間に複数のSPDYセッションを確立し、各SPDYセッションを利用してWebコンテンツを構成する複数のサブコンテンツを並列的に受信する。

本発明が配信対象とするWebコンテンツは、一つの構成ファイルと複数のサブコンテンツとから構成され、各サブコンテンツの取得先アドレス情報は構成ファイルに記述されている。

前記構成ファイルは、取得しようとするWebコンテンツがWebページであればHTMLファイルであり、HTTP StreamingであればMPD（Music Player Daemon）である。前記サブコンテンツは、取得しようとするコンテンツがWebページであれば当該ページに表示される各画像等のコンテンツデータあり、HTTP Streamingであればストリーミング映像を構成する各セグメントである。

クライアント１は初めに、サーバ２との間に先行して一つのSPDYセッション（先行SPDYセッション）を確立する。そして、当該先行SPDYセッションにおいてコンテンツの構成ファイルをサーバへ要求[同図(a)]する。

クライアント１はさらに、前記先行SPDYセッションの確立をサーバ２へ要求してから前記構成ファイルを受信するまでの応答遅延期間中に、サーバ２との間に複数のSPDYセッション（後行SPDYセッション）を追加的に確立する手順を実行する[同図(b)]。これにより、複数の後行SPDYセッションをサーバ２との間に確立するための所要時間を、先行SPDYセッションの確立要求から構成ファイル受信までの応答遅延期間に重ねられるので、複数のSPDYセッションを追加的に確立するための所要時間がコンテンツ配信を遅延させてしまうことを防止できる。

その後、構成ファイルを受信したクライアント１は、複数の後行SPDYセッションがサーバ２との間に確立されると、前記構成ファイルを送受し終えた先行SPDYセッションおよび新たに確立された複数の後行SPDYセッションを利用して、構成ファイルに記述されている複数のサブコンテンツの要求およびその受信を並行して実行する[同図(c)]。これにより、疑似的に初期輻輳ウィンドウサイズを拡大できるので、コンテンツ配信の高速化が期待できるようになる。

図２は、本発明の一実施形態の動作を示したフローチャートであり、図３は、配信対象のWebコンテンツがWebページである場合のシーケンスフローであり、図４は、HTTP Streamingである場合のシーケンスフローである。

初めに図２，３を参照し、ステップS１において、クライアントに対するWebコンテンツの配信要求が検知されると、ステップS２では、当該Webコンテンツを蓄積するサーバに対してSPDYセッションの確立要求が送信され（時刻t0）、これにサーバ応答することにより、クライアントとサーバとの間に先行して一つのSPDYセッション（先行SPDYセッション）が確立され（時刻t1）、さらにクライアントからサーバへ、前記先行SPDYセッションにおいて、コンテンツの構成ファイルを受信するためのGETリクエストが送信される（時刻t2）。

前記ステップS２と並行して、ステップS３では、クライアントとサーバとの間に複数のSPDYセッション（後行SPDYセッション）を確立する手順が開始される（時刻t3〜t4）。ステップS４では、配信要求されたWebコンテンツが、WebページおよびHTTP Streamingのいずれであるかが判定される。

Webページの配信要求であればステップS５へ進み、前記要求した構成ファイル（ここでは、HTMLファイル）が前記先行SPDYセッションで受信される（時刻t5）のを待ってステップS６へ進む。ステップS６では、受信したHTMLファイルに記述されている各サブコンテンツのアドレスが識別されてGETリクエストのメッセージがそれぞれ生成される。

ステップS７では、前記ステップS３で確立手順が開始されてサーバとの間に確立された複数の後行SPDYセッション、および前記構成ファイルの送受が完了した先行SPDYセッションを利用して、前記各GETリクエストが並行してサーバへ送信され（時刻t6，t7，t8）、当該GETリクエストに応答してサーバが配信した各サブコンテンツが受信される（時刻t9〜t14）。

ステップS８では、全てのサブコンテンツの受信が完了したか否かが判定される。完了していなければステップS７へ戻り、送受信の完了した後行SPDYセッションを利用して未送信のGETリクエストを送信し、サーバが応答したサブコンテンツが受信される。

次いで、図２，４を参照し、前記ステップS４において、HTTP Streamingの配信要求と判定されればステップS９へ進み、前記要求した構成ファイル（ここでは、MPDファイル）が前記先行SPDYセッションで受信される（時刻t15）のを待ってステップS１０へ進む。

ステップS１０では、受信したMPDファイルに記述されている各セグメントの受信順序が、その再生順序に基づいて決定される。ステップS１１では、各セグメントのアドレスが識別されてGETリクエストのメッセージがそれぞれ生成される。

ステップS１２では、前記ステップS３で確立手順が開始されてサーバとの間に確立された複数の後行SPDYセッション、および構成ファイルの送受を完了した先行SPDYセッションを利用して、セグメントファイルのリクエストおよびその受信が並行して行われる。

本実施形態では、初めに再生順序が１番のセグメント#1に関するGETリクエストがサーバへ送信され（時刻t16）、当該リクエストに応答してサーバが配信したセグメント#1が受信される（時刻t17）。

次いで、前記セグメント#1の受信に要した時間に基づいて、後続する各セグメント#2，#3，#4の受信品質が決定される（時刻t18）。そして、確立されている複数のSPDYセッションを利用して、前記受信品質指定を含む各GETリクエストが並行してサーバへ送信され（時刻t19，t20，t21）、当該リクエストに応答してサーバが配信した各サブコンテンツ#2，#3，#4が前記指定品質で受信される（t22，t23，t24）。

ステップS１３では、全てのサブコンテンツの受信が完了したか否かが判定される。完了していなければステップS１２へ戻り、セグメント#2，#3，#4の受信に要した時間に基づいて、後続するセグメント#5，#6の受信品質が決定される（時刻t25）。

次いで、送受信の完了した複数のSPDYセッションを利用して、前記受信品質指定を含む未受信のセグメント#5，#6のGETリクエストを送信し（時刻t26，t27）、サーバが応答したセグメント#5，#6が受信される（時刻t28，t29）。

図５，６は、HTTP Streamingにおける各セグメントの配信方法を模式的に表現した図である。本実施形態では、セグメントの転送速度Viと再生時間tiとの関係に基づいて、セグメントの配信方法を切り替える基準速度Vrefが設定され、セグメントの転送速度Viが基準速度Vrefを上回るか否かに応じて転送方法が切り換えられる。

セグメントの転送速度Viが基準速度Vrefを下回る場合は、図５に示したように、ストリーミング再生に途切れが生じないことを最優先に、連続するn個のセグメントを、n本（ここでは、3本）の各SPDYセッションで１個ずつ並列的に受信し、これを一周期として繰り返す配信方法が採用される。

これに対して、セグメントの転送速度Viが十分に早く、基準速度Vrefを上回る場合は、図６に示したように、シーケンスバーの先送りに対応できるよう、連続するn×m個（ここでは、3×3）のセグメントを、n本の各SPDYセッションで連続するm個ずつ並列的に受信し、これを一周期として繰り返す配信方法が採用される。

本実施形態によれば、複数のSPDYセッションを用いて、疑似的に初期輻輳ウィンドウサイズを拡大できるので、Webコンテンツ配信の高速化が期待できるようになる。

また、本実施形態によれば、クライアントが先行SPDYセッションの確立を要求してから構成ファイルを受信するまでの応答遅延期間中に、サーバとの間に複数のSPDYセッションを確立する手順が実行される。その結果、複数のSPDYセッションをサーバとの間に確立するための所要時間を、先行SPDYセッションの確立要求から構成ファイル受信までの応答遅延期間に重ねられるので、複数のSPDYセッションを追加的に確立するための所要時間がコンテンツ配信を遅延させてしまうことを防止できる。

さらに、本実施形態によれば、HTTP Streamingにおける各セグメントの配信方法が、セグメントの転送速度Viに応じて切り換えられるので、低速時でも途切れの無い再生を可能にでき、高速時にはシーケンスバーの先送りに対応できるなどの利便性の向上が可能になる。

さらに、本実施形態によれば、サーバ側を改修することなく、クライアント側の改修、実装のみで対応できるので、既存システムへの適用が容易となる。

１…クライアント，２…サーバ

Claims (4)

1. サーバがクライアントへSPDYセッションでWebコンテンツを配信するWebコンテンツ配信方法において、
   クライアントがサーバとの間に先行SPDYセッションを確立してコンテンツの構成ファイルを要求する手順と、
   クライアントが、前記先行SPDYセッションの確立を要求してから構成ファイルを受信するまでの待機遅延期間を利用して、サーバとの間に複数の後行SPDYセッションを確立する手順と、
   クライアアントが前記先行SPDYセッションで受信した構成ファイルにアドレス情報が記述されている各サブコンテンツを前記各SPDYセッションで並列的に受信する手順とを含むことを特徴とするWebコンテンツ配信方法。
2. 前記コンテンツがWebページであり、前記構成ファイルがHTMLファイルであり、前記サブコンテンツが当該Webページに表示される各コンテンツデータであることを特徴とする請求項１に記載のWebコンテンツ配信方法。
3. 前記コンテンツがHTTP Streamingであり、前記構成ファイルがMPDファイルであり、前記サブコンテンツが時系列の各セグメントファイルであることを特徴とする請求項１に記載のWebコンテンツ配信方法。
4. 前記並列的に受信する手順は、
   連続するn個のセグメントを、n本の各SPDYセッションで１個ずつ並列的に受信し、これを一周期として繰り返す第１手順と、
   連続するn×m個のセグメントを、n本の各SPDYセッションで連続するm個ずつ並列的に受信し、これを一周期として繰り返す第２手順とを選択的に採用し、
   セグメントの転送速度がセグメントの再生時間に依存した所定の基準速度よりも遅ければ前記第１手順を採用し、早ければ第２手順を採用することを特徴とする請求項３に記載のWebコンテンツ配信方法。