ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度
パラレルなハイパーテキスト転送プロトコル（ＨＴＴＰ）接続とパイプライン化の組み合わせは、未処理のリクエストの数を最小化し、リンクを依然としてフルに利用するように、パラレルな接続の数とパイプライン化されたリクエストの数をリアルタイムに変化させることにより、増加するラウンドトリップタイム（ＲＴＴ）の影響を克服する。ＨＴＴＰスタックにおけるリクエストおよび接続の最適な構築およびスケジューリングは、ページロード時間を改善し、オブジェクト優先順位における変更に対するより高い応答性を提供する。ＨＴＴＰに対するアプリケーションレイヤにおけるマルチホーミングおよび移動性に対処する。組み合わせて、これらは、よりスムーズな移動性を提供する。サーバまたはネットワークのサポートなしに、このように移動性を提供することができる。
【発明の詳細な説明】
【合衆国法典第３５部第１１９条の下での優先権の主張】
【０００１】
本特許出願は、“ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度”と題され、２００９年１２月１８日に出願され、この出願の譲受人に譲渡され、ここでの参照によりここに明確に組み込まれている仮出願番号第６１／２８８，１１９号に対して優先権を主張する。
【同時係属中の特許出願に対する参照】
【０００２】
本特許出願は、これとともに同時に出願され、この出願の譲受人に譲渡され、ここでの参照により明確に組み込まれている、Ｒａｍｉｎ Ｒｅｚａｉｉｆａｒ氏らによる、代理人ドケット番号第１００５２８Ｕ２号を有する、以下の同時係属中の米国特許出願“アプリケーションレイヤにおける、複数のインターフェースの結合／集約”に関連する。
【分野】
【０００３】
本開示は、一般的に通信に関し、さらに詳細には、ワイヤレス通信ネットワーク中で、ハイパーテキストパケットデータコンテンツを取り出すための技術に関する。
【背景】
【０００４】
ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ウェブブラウザおよびウェブアプリケーションにより使用されている主要な通信プロトコルである。コンテンツ配信ネットワークの形で、ＨＴＴＰプロトコルの効率的な動作をサポートするために、インターネット内で大型インフラストラクチャが成長してきた。結果として、増加する数のアプリケーションが、ＨＴＴＰプロトコルに移行している。この移行に対する他の理由（例えば、ネットワークアドレス変換（ＮＡＴ）およびファイアウォールトラバーサル）がある一方で、主な動因は、ウェブインフラストラクチャの大規模なスケーラビリティを活用する能力である。
【０００５】
今日、ウェブサイトは、極めて複雑であり、ＨＴＴＰを使用してそれぞれが別々にリクエストされなければならない、数十または数百のオブジェクトを含んでいることが多い。サーバからクライアントにオブジェクトを伝送できるスピードを改善するために、さまざまな最適化がＨＴＴＰ内で定義されている。ワイヤードネットワーク内でこれらの最適化を適用するときに、かなりの量の作業が行われてきた。しかしながら、高ラウンドトリップタイム（ＲＴＴ）と非常に可変の帯域幅とを持つ、より挑戦的な移動体環境で、これらの特徴がどのように振る舞い、組み合わせられるのかを理解することは、依然として未解決の問題のままである。特に、移動体ネットワークの特性が、その当時、今日とは大きく異なっていた数年前に、多くのＨＴＴＰ作業が実行されたことに留意すべきである。
【概要】
【０００６】
以下のものは、開示されている態様のうちのいくつかの態様の基本的な理解を提供するために、簡略化した概要を提示する。この概要は、広範囲にわたる概略ではなく、キーエレメントまたは重要なエレメントを識別することや、このような態様の範囲を線引きすることのどちらも意図していない。この目的は、後に提示するさらに詳細な説明に対する前置きとして、説明されている特徴のうちのいくつかの概念を、簡略化した形で提示することである。
【０００７】
１つの態様では、パケットデータ通信のための多数のパラレルな接続を確立することと、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信することと、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させることとによる、パケットデータ通信のための方法が提供されている。
【０００８】
別の態様では、パケットデータ通信のための少なくとも１つのプロセッサが提供されている。第１のモジュールは、パケットデータ通信のための多数のパラレルな接続を確立する。第２のモジュールは、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。第３のモジュールは、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【０００９】
追加の態様では、パケットデータ通信のためのコンピュータプログラムプロダクトが提供されている。一時的でないコンピュータ読取可能媒体は、コードの組を記憶する。第１の組のコードは、コンピュータに、パケットデータ通信のための多数のパラレルな接続を確立させる。第２の組のコードは、コンピュータに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信させる。第３の組のコードは、コンピュータに、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００１０】
さらなる態様では、パケットデータ通信のための装置が提供されている。装置は、パケットデータ通信のための多数のパラレルな接続を確立する手段を具備する。装置は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する手段を具備する。装置は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる手段を具備する。
【００１１】
さらに別の態様では、パケットデータ通信のための装置が提供されている。トランシーバは、パケットデータ通信のための多数のパラレルな接続を確立する。トランシーバは、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。コンピューティングプラットフォームは、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００１２】
先の目的および関連する目的を達成するために、１つ以上の態様は、後に完全に説明する特徴、および、特許請求の範囲中で特に指摘する特徴を含んでいる。以下の説明および添付した図面により、ある例示的な態様を詳細に述べ、態様の原理を用いることができるさまざまな方法のうちのいくつかだけを示す。図面とともに考えるときに、他の利点および新規の特徴が、以下の詳細な説明から明らかになるだろう。開示されている態様は、このようなすべての態様とそれらの均等物とを含むことを意図している。
【図面の簡単な説明】
【００１３】
同一の参照文字が全体を通して対応したものを識別している図面とともに考慮されたときに、以下で示される詳細な説明から、本開示の特徴、特質、および利点がより明白となろう。
【図１】図１は、ＨＴＴＰ最適化のための通信システムの概略図を示している。
【図２Ａ】図２Ａは、ＨＴＴＰ最適化のための方法に対するフローダイヤグラムを示している。
【図２Ｂ】図２Ｂは、ＨＴＴＰ最適化のための方法に対するフローダイヤグラムを示している。
【図３】図３は、ラウンドトリップタイム（ＲＴＴ）の関数として、ページロード時間のグラフィカルプロットを示している。
【図４】図４は、単一の継続的接続に対するリンク使用パターンのダイヤグラムを示している。
【図５】図５は、第１および第２のアップリンクリクエストならびにダウンリンクレスポンスに対するリンク使用パターンのダイヤグラムを示している。
【図６】図６は、固定帯域幅での異なるＲＴＴに対して達成される最良のページダウンロード時間に対するグラフィカルプロットを示している。
【図７】図７は、ＨＴＴＰ最適化に対する複数のアルゴリズムの例示的な関係に対するダイヤグラムを示している。
【図８】図８は、ＨＴＴＰ最適化を実行する移動端末に対するブロックダイヤグラムを示している。
【図９】図９は、ＨＴＴＰ最適化をサポートするノードに対するブロックダイヤグラムを示している。
【図１０】図１０は、ＨＴＴＰ最適化に対する電気コンポーネントの論理グルーピングを有する、移動デバイス中に少なくとも部分的に存在するシステムに対するブロックダイヤグラムを示している。
【図１１】図１１は、ＨＴＴＰ最適化をサポートする電気コンポーネントの論理グルーピングを有する、ネットワーク中に存在するシステムに対するブロックダイヤグラムを示している。
【詳細な説明】
【００１４】
増加するラウンドトリップタイム（ＲＴＴ）の影響を克服するために、パラレルなＨＴＴＰ接続とパイプライン化を組み合わせることに利益が存在する。一般的に知られているブラウザは、固定数のパラレルな接続と、固定数の未処理のリクエストを用いるが、接触しなければならない異なるサーバの組により、パラレルな接続の数は影響を受ける。
【００１５】
本イノベーションの１つの態様は、未処理のリクエストの数が最小になり、リンクが依然としてフルに利用されるように、パラレルな接続の数と、パイプライン化されたリクエストの数とを、リアルタイムに変化させるためのものである。
【００１６】
例えば、リクエストされるデータの量に基づいて、リンクが依然として確実にフルに利用されるように、これらの数を変化させることができる。しかしながら、まだ受信されていないデータの量が、帯域幅とＲＴＴの積を超えてはならない。これらの量の双方とも、絶えず変化している。加えて、オブジェクトのヘッダが届くまで、オブジェクトサイズはわからないので、未処理のデータの量は、正確にはわからない。
【００１７】
１つの可能性は、これらのすべての変数に対する確率モデルを構築し、リンクがアイドルになる確率全体を、何らかのしきい値を下回るように維持しようと試みることである。例えば、オブジェクトサイズに対する確率モデルは、オブジェクトタイプ（イメージ、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ等）を、オブジェクトサイズに関する分布にマッピングするヒストリカルデータを使用してもよい。特に、オブジェクトの以前のキャッシュされたバージョンがある場合には、返されるだろうデータは、オブジェクトは変更されていないので、ゼロ（または、むしろ、ＨＴＴＰヘッダだけ）であるか、あるいは、古いものと類似するサイズを有する可能性がある新しいバージョンであるかのいずれかである。
【００１８】
したがって、最近測定された帯域幅およびラウンドトリップタイムに基づいて、リクエストされたが受信されていないデータが、帯域幅とＲＴＴの積を超える確率まで、より多くのオブジェクトのパイプライン化を継続できる。より多くのデータが届くか、あるいは、帯域幅またはラウンドトリップタイムにおける変更が観測されたときにはいつでも、この計算を繰り返すことができる。それにより、ＨＴＴＰ接続上のパイプライン化されたリクエストのターゲット数は、以下でさらに詳細に説明するように、接続の持続時間の間に変化することがある。
【００１９】
図面を参照して、ここでさまざまな態様を説明する。以下の説明では、説明の目的上、１つ以上の態様の完全な理解を提供するために、多数の特定の詳細を述べる。しかしながら、これらの特定の詳細なしにさまざまな態様を実施できることが、明らかであることがある。他の例では、これらの態様の説明を促進するために、よく知られている構造およびデバイスは、ブロックダイヤグラムの形で示されている。
【００２０】
図１では、通信システム１００において、移動デバイス、アクセス端末、または、ユーザ機器（ＵＥ）１０２が、複数のサーバ１１２〜１１４上に記憶されているオブジェクト１０６、１０８、１１０を含むハイパーテキストコンテンツ１０４に対するパイプライン化リクエスト１０３を行う。例示的な態様では、移動デバイス１０２は、オブジェクト１０６〜１１０を受信するのに、したがって、ハイパーテキストコンテンツ１０４をレンダリングするのに必要とされるラウンドトリップタイム（ＲＴＴ）を悪化させるエアリンク１１６を通して、アクセスを得る。１つの態様では、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）１２０の一部として役割を果たすノード（例えば、マクロセル、フェムトセル、リレー）１１９と通信する無線トランシーバ１１８を、移動デバイス１０２は有しており、このノード１１９は、コアネットワーク（ＣＮ）（例えば、インターネット）１２４においてホスト管理されているサーバ１１２〜１１４へのインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）１２２に向かうものである。
【００２１】
代替的に、または、加えて、移動デバイス１０２は、ノード１２８と通信するトランシーバ１２６を有しており、ノード１２８は、ＣＮ１２４を介してサーバ１１２〜１１４にアクセスするためのワイヤレスローカルアクセスネットワーク（ＷＬＡＮ）１３０を担当する。
【００２２】
代替的に、または、加えて、移動デバイス１０２は、ノード１３４と通信するトランシーバ１３２を有しており、ノード１３４は、パーソナルアクセスネットワーク（ＰＡＮ）１３６を担当し、ＣＮ１２４を介してサーバ１１２〜１１４に到達するために、１３８において示されているようなＷＷＡＮ１２０か、または、１４０において示されているようなＷＬＡＮ１３０のいずれかに結合されている。
【００２３】
１つの態様では、トランシーバ１１８、１２６、１３２は、パケットデータ通信のための多数のパラレルな接続を確立する。トランシーバ１１８、１２６、１３２は、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。
【００２４】
移動デバイス１０２のコンピューティングシステム１２４は、ＨＴＴＰ最適化コンポーネント１４４を有しており、ＨＴＴＰ最適化コンポーネント１４４は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００２５】
図２（図２Ａおよび図２Ｂ）では、例示的な方法２００または動作のシーケンスが、ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度に対して示されている。ブロック２０４は、パケットデータ通信のための多数のパラレルな接続を確立することを示している。特定の態様では、多数のパラレルな接続を確立することは、複数のサーバのうちのそれぞれに対する接続の数を最小化すること（ブロック２０６）により達成される。リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、多数のパラレルな接続が使用される（ブロック２０８）。
【００２６】
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストが送信される（ブロック２１０）。
【００２７】
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続を介して追加のパイプライン化リクエストを送信するために、パラレルな接続の数を動的に変化させる（ブロック２１２）。例えば、フルなリンク利用は、グリーディ（greedy）リソース利用を、または、ジャストインタイム（ＪｉＴ）リソース利用を必要とすることがある。
【００２８】
例示的な態様では、帯域幅とラウンドトリップタイムを推定すること（ブロック２１４）により、この動的な変化が達成される。リクエストされたが受信されていないパケットデータが、推定された帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、パイプライン化リクエストの送信を継続する（ブロック２１６）。
【００２９】
例示的な態様では、特に、ＨＴＴＰ取り出しを促進するネットワークによりサポートされている場合に、１つ以上のさらなる最適化が含まれる。
【００３０】
例えば、パケットデータ部分をレンダリングするためのプログレッシブな順序付けが決定され、複数のパイプライン化リクエストの順序は、プログレッシブな順序付けに関連して、優先順位が付けられる（ブロック２１８）。取り出しの間に変更が生じた場合には（ブロック２２０）、プログレッシブな順序付けの優先順位が付け直され、プロセスが更新される（ブロック２２２）。
【００３１】
別の例に対して、複数のパイプライン化リクエストは、ヘッダ圧縮によりリクエストされる（ブロック２２４）。
【００３２】
追加の例に対して、ネットワークは、移動デバイスによりどのような追加リソースが要求されることがあるかを識別（予想）できる。このようなケースでは、リクエストしなかった、サーバにより識別されたリソースを受信することがある（ブロック２２６）。必要でない場合には、サーバ識別リソースをキャンセルすることによるレスポンスによって、無線リソースの不必要な消費を避けることができる（ブロック２２８）。
【００３３】
さらなる例に対して、ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストとして、複数のパイプライン化されたリクエストを送信することができる（ブロック２３０）。
【００３４】
さらに別の例に対して、接続ラウンドロビンにより、マルチホームのホストに対してリンクを集約すること（ブロック２３２）によって、複数のパイプライン化リクエストを送信することができる。インターフェースが利用可能でなくなったこと、または、利用可能になったことを検出し（ブロック２３４）、インターフェースを使用しているオープンな接続を識別し（ブロック２３６）、オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築することにより（ブロック２３８）、ならびに、識別したオープンな接続と、インターフェースと、未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを、動的に変化させることにより（ブロック２４０）、このマルチホーミング能力の観点での移動性に対処することができる。
【００３５】
例示的な態様において、移動デバイスは、各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持することができ、ネットワークプロキシと、静的に定義されたルートと、オペレーティングシステムおよびウェブブラウザのサポートがない場合には、プロキシ自動設定（ＰＡＣ）スクリプトとを使用することができる。
【００３６】
図３は、グラフィカルプロット３００において、ｎｙｔｉｍｅｓ．ｃｏｍに対してパラレルな接続およびパイプライン化が使用可能であるＦｉｒｅｆｏｘ（登録商標）ウェブブラウザを使用して、より長いＲＴＴがページロード時間（秒単位）に与える影響を示している。テストしたページは、合計で約１．３ＭＢのデータである、おおよそ１００個のオブジェクトからなる。テストは、１．５Ｍビット／秒の固定帯域幅のリンクを通して実行され、より高いＲＴＴリンクをシミュレートするために、異なる量の追加遅延で繰り返された。フルなリンク利用では、ページをダウンロードするのにおよそ７秒かかるはずであり、実際のところ、これは、ワイヤードネットワーク上で観測されることがあるような、非常に低いラウンドトリップタイムにより達成されるものである。しかしながら、明らかに、リンク利用は、ＲＴＴが増加するにつれて、ＲＴＴに反比例して急激に落ち込む。
【００３７】
この実験が明示しているのは、ＲＴＴが、ワイヤードネットワーク上で典型的に見られるよりも大きい場合には、最先端のウェブブラウザでさえ、適度の帯域幅のリンクをフルに利用することができないということである。さらに、（７秒から２１秒への、ページロード時間における２００％の増加が非常に顕著であるのに対し、１００ｍｓから３００ｍｓへの２００％の増加は、そうでないことがあるという点で、）結果として生じる増加したページロード時間は、十分に、ユーザ経験が影響を受ける範囲内にある。
【００３８】
ここで使用されるようなリンク利用は、ネットワークが与えるように準備しているすべてのリソースを利用する、クライアントの能力のことを指す。ＥＶ−ＤＯまたはＨＳＰＡのシナリオでは、１人のユーザがこの意味でリンクを“十分に利用していない”ときに、使用されていない容量は、他のユーザに与えられるので、全体として無線リソースを十分に利用していないことはない。しかしながら、この意味での乏しいリンク利用は、より長いページロード時間において観測されるような、乏しいユーザ経験を、結果として生じさせる。
【００３９】
具体的な例として、１０人のユーザが、それぞれ、１ＭＢファイルをリクエストし（必ずしもすべてが同時でなくてもよい）、ネットワークが、８Ｍビット／秒の共有容量を有している場合に、データをユーザのすべてに配信するのに１０秒かかるだろう。平均待ち時間の観点から、データを“シーケンシャルに”供し、各ユーザに対して１秒かけるほうが、各ユーザに対してパラレルに１０秒もかけてすべてのユーザに配信するよりも、より望ましい。
【００４０】
オブジェクト配信を最適化するために、ＨＴＴＰにおいて利用可能なさまざまな技術を使用することができる。
【００４１】
継続的接続：ＨＴＴＰ１．０規格は、各ＨＴＴＰリクエストに対して、新しい伝送制御プロトコル（ＴＣＰ）接続が確立されることを要求した。各ＴＣＰ接続の確立は、ＳＹＮ／ＡＣＫ（同期化／肯定応答）交換と、ＴＣＰ輻輳制御のスロースタートフェーズに起因するスロー送信の期間とを暗示するので、この要件は、オブジェクト配信時間の観点から高い代償を必要とした。
【００４２】
ＨＴＴＰ１．１は、複数のリクエストが同じサーバに発行されるケースをより良くサポートするために、継続的接続を導入した。このケースでは、以前のレスポンスの受信が完了した後に、同じ接続上で新しいＨＴＴＰリクエストを送ることにより、ＴＣＰ接続を再使用する。このアプローチでは、リクエストの送信と、レスポンスの最初のパケットの受信との間の時間（１つのラウンドトリップタイム）の間、ダウンリンクはアイドルである。
【００４３】
単一の継続的接続に対するリンク使用パターン４００を、図４から理解することができる。図４では、アップリンクリクエスト４０２とダウンリンクレスポンス４０４との間のギャップが、リンクが十分に利用されていないことを（ギャップの形で）示しており、ＲＴＴがより高い場合に、この十分に利用されていないことが、いっそう悪いという事実を示している。
【００４４】
ＲＴＴに対処しない、リンク帯域幅の単なる増加は、それ自体では、リンク利用の観点から性能を改善しないことを、本開示の利益により正しく認識すべきである。さらに図４を参照すると、帯域幅の増加は、時間の関数として、各アップリンクブロックおよびダウンリンクブロックをより狭くさせる（すなわち、より少ない時間で同じデータが転送される）だろうが、ギャップのサイズを減少させないだろう。実際、ギャップは、総ダウンロード時間のより大きな部分を表し、したがって、このケースでは、帯域幅の増加は、リンク利用を減少させる。
【００４５】
パラレルな接続：現代のブラウザは、同じサーバまたは異なるサーバ（またはその双方）のいずれに対しても、パラレルな複数のＴＣＰ接続を開いている。この技術の効果は、２つある：第１に、複数のアクティブに送信しているＴＣＰ接続を集約するという輻輳制御の振る舞いは、スロースタートの間の輻輳ウィンドウのより速い開きと、各パケットドロップに対するより減少した輻輳レスポンス以外では、単一のＴＣＰ接続と同等のものとして見なされることがある。第２に、（継続的接続に対して先に示したように）１つの接続上の送信が断続的であるケースでは、送信の間のアイドル期間が、他の接続によって使用されてもよく、これによりリンク利用を改善する。
【００４６】
パイプライン化：実際、ＨＴＴＰ１．１は、第１のリクエストに対するレスポンスの完了を待つことなく、複数のリクエストを送ることを可能にする。これは、レスポンスの間にリンクがアイドルになることなく、サーバが続けざまにレスポンスを送ることを可能にする。ＨＴＴＰは、リクエストとレスポンスを整合させるための他のメカニズムを何ら提供しないので、レスポンスは、リクエストを受信したのと同じ順序で送らなければならない。
【００４７】
図５では、第１および第２のアップリンクリクエスト５０２、５０３と、ダウンリンクレスポンス５０４とによる、継続的接続のためのリンク使用パターン５００に対して、パイプライン化の効果が示されている。
【００４８】
現代のウェブブラウザはすべて、先の最初の２つの技術を実質的に利用している。しかしながら、ＨＴＴＰ１．１規格中で定義されているが、パイプライン化のサポートは、かなりの間、サーバおよびプロキシにおいて普遍的でなかったし、特に、透過型プロキシのケースでは、固有の失敗モードの何らかの証拠がある。結果として、例えば、失敗モードを検出して、非パイプライン化動作にグレースフルにフォールバックするように注意したり、この技術が成功しているサーバのホワイトリストを維持する等、パイプライン化の実現において何らかの注意が必要である。Ｏｐｅｒａ（登録商標）ブラウザは、デフォルトによりパイプライン化をイネーブルさせる（そして、明らかに、このような技術を実現する）。Ｆｉｒｅｆｏｘでは、パイプライン化はサポートされているが、デフォルトによりディセーブルされている。Ｓａｆａｒｉ（登録商標）およびＣｈｒｏｍｅ（登録商標）は、（現在）パイプライン化をサポートしていない。
【００４９】
ブラウザにおいてパイプライン化に対する幅広いサポートがない理由は、図３と、先に参照した問題とから明らかである：継続的でパラレルな接続のみを使用する低ＲＴＴ接続上では、リンクのブラウザ利用は非常に高い。コンテンツ配信ネットワークは、近年、典型的なウェブＲＴＴを積極的に押し下げ、改善されたブラウジング性能を結果として生じさせ（これは、ＣＤＮの主要な価値命題である）、結果として、ワイヤードおよびワイヤレスのローカルアクセスネットワーク（ＷＬＡＮ）ウェブブラウジングの大多数に対して、認識されている問題はほとんどない。
【００５０】
パイプライン化がサポートされている場合に、レスポンス間にギャップがないはずなので、リンク利用は、単一の接続では１００％であるはずだと、ある人は期待するかもしれない。しかしながら、いくつかのケースでは、パイプライン化された形でのリクエストをサーバが受け入れることがある一方で、以前のリクエストが完了するまでサーバが各リクエストを処理しないことがある。これは、サーバ処理のためにかかる時間に等しい、レスポンス間のギャップにつながる。サーバの負荷が非常に大きい場合に、レスポンスを発生させるために、サーバが、スクリプト実行のような、複雑な機能を実行しなければならない場合に、および／または、サーバが、外部サーバ（例えば、データベース）を参照しなければならない場合に、この時間はかなりのものであるかもしれない。
【００５１】
到来側では、パイプライン化されたリクエストを受け入れるが、送出側では、シリアルなリクエストを発行する中間プロキシがある場合に、同じ効果が観測されることがある。パイプライン化されたリクエストをサーバがパラレルに処理する場合でさえ、所定のレスポンスを送る時間が来たときに、この処理の結果が利用可能でないことがある。
【００５２】
最初の実験：先のデータは、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のような、高ＲＴＴリンク上で、ウェブブラウジング性能において改善の余地があると、我々に信じさせる。さらなる証拠は、クライアントと中間プロキシとの間にパイプライン化を適用することと、さらに、順序通りでなく（すなわち、クライアントおよびプロキシによりサポートされている新しいＨＴＴＰ拡張機能を通して）レスポンスを返す可能性を導入することとによってもたらされる。このアプローチにおいて、リンク利用が改善される。その理由は、クライアントとプロキシとの間の低ＲＴＴにより、単一のＴＣＰ接続が、ＷＷＡＮリンクをフルに利用することが可能になり、プロキシは、送出側でパラレルなリクエストを発行するように設計されているからである。要求されるリソースの早期の識別もまた、組み込むことができる。
【００５３】
ターゲットＨＴＴＰサーバにより直接サポートされている（そして、これらのサーバがリクエストをパラレルに処理すると仮定する）場合に、順序通りでないレスポンスに対するＨＴＴＰ拡張機能が、利益を提供することがあることに留意すべきである。Ｇｏｏｇｌｅ（登録商標）ＳＰＤＹに対して以下で説明する範囲を除いて、実験はこのアプローチを追求していないと信じられている。
【００５４】
本イノベーションを推進するために行われた実験は、プロキシの配備が要求されないケース（すなわち、クライアント側のみの技術）に対処する。明確さのために、ネットワーキングを除くすべてのボトルネックが取り除かれている“理想的なブラウザ”に、最初の焦点を当てる。特に、“理想的なブラウザ”は、ページをレンダリングするのに要求されるリクエストの完全な組のアプリオリな知識を有し、受信するとすぐにコンテンツをレンダリングする。
【００５５】
それゆえ、ページロード時間に対する唯一の寄与は、ＨＴＴＰプロトコルを使用して、ネットワークを通してデータを転送するのに要求される時間である。“理想的なブラウザ”は、パイソンスクリプトとして実現され、パイソンスクリプトには、（実際のウェブページのダウンロードのトレースから取られた）オブジェクトのリストが事前に供給され、パイソンスクリプトは、ＨＴＴＰ継続的接続と、パラレルな接続と、パイプライン化とを使用して、オブジェクトをダウンロードするアルゴリズムを実現する。すべてのオブジェクトをダウンロードするのにかかる時間を測定する。
【００５６】
パラレルな接続と、パイプライン化と、ネットワーク帯域幅およびＲＴＴとの間の相互作用をより良く理解するために、１〜１０個の間のパラレルな接続と、そのそれぞれにおける１〜１０個の間の未処理のリクエストとにより、実験を行った。（１個の未処理のリクエストは、標準的な非パイプライン化アプローチに対応し、‘ｎ’個の未処理のリクエストは、最初に‘ｎ’個のリクエストが送られ、その後、レスポンスが完全に受信されるたびに、新しいリクエストが送られることを意味する。）
異なるネットワーク帯域幅およびＲＴＴに対する結果が、表１〜６において示されている。特に、実際のウェブサーバトレースにおける複数の接続およびパイプライン化の異なるコンフィギュレーションの性能が、理想化されている。ウェブリクエストトレースは、Ｗｉｒｅｓｈａｒｋ（登録商標）を使用して、人気のあるウェブサイトから収集される。その後、リクエストトレースファイルを発生させるために、ダンプファイルが処理される。最初の実験に対して、すべてのリクエストが予め知られており、順序通りに実行されると仮定する。オブジェクトは、プライマリサーバからのみ、すなわち、ウェブサイトを構成するオブジェクトの不均衡な配分が問題になっているサーバからのみ、リクエストされる。プライマリサーバ現象は、人気のあるウェブサイトに対しても特徴付けられる。
【００５７】
以下の表１は、複数の接続およびパイプライン化の各コンフィギュレーションに対して観測された平均ダウンロード時間を示している。
【表１】
【００５８】
以下の表２〜７は、複数の接続およびパイプライン化の各コンフィギュレーションに対して観測された平均ダウンロード時間を示している。
【表２】
【表３】
【表４】
【表５】
【表６】
【００５９】
これらの実験では、実験を行っている間に、バックグランドで何かがダウンロードされる。
【表７】
【００６０】
要約すると、図６は、１．５Ｍビット／秒の固定帯域幅での異なるＲＴＴに対して、また、（双方とも１．５Ｍビット／秒よりも高い帯域幅を持った）３Ｇ接続およびバックグランドトラフィックを持つ３Ｇ接続を通しての異なるＲＴＴに対して、達成された、最良のページダウンロード時間を提示している。各ケースに対する注釈は、最良の結果が達成された、パラレルな接続の数およびパイプライン化の量を示す。
【００６１】
明確さのために、これらの実験は、単一のサーバ上に存在するページオブジェクトのうちの９０％に制限されていたが、本イノベーションの態様は、複数のサーバの結果に拡張できることに留意されたい。
【００６２】
原則として、ダウンロード時間は、図３におけるのと同じくらいＲＴＴに敏感である必要はまったくないことを、図６からの本開示の利益により正しく認識すべきである。
【００６３】
ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度
本イノベーションは、例えば、部分的にダウンロードされたイメージがもはや目に見えないように、ウェブページがスクロールされたときに、ＨＴＴＰスタックにおけるリクエストおよび接続の最適な構築ならびにスケジューリングの問題に対処し、ページロード時間を改善させ、オブジェクトの優先度における変更に対してより良い応答性も提供する。
【００６４】
本イノベーションは、ＨＴＴＰに対する、アプリケーションレイヤにおけるマルチホーミングおよび移動性に対するソリューションも考える。マルチホーミングは、特に、インターフェースの利用可能な帯域幅が、同程度の大きさである（これは、ＷＬＡＮがバックホール制限されているために、そうであることが多い）ケースにおいて、ダウンロード時間を改善する、例えば、ＷＷＡＮおよびＷＬＡＮのインターフェースのような、複数のインターフェースの同時使用を提供する。移動性は、デバイスが動くにつれて、接続の切り替えを提供する。組み合わせて、これらは、よりスムーズな移動性を提供する。サーバまたはネットワークのサポートをそれぞれ要求する、マルチパス伝送制御プロトコル（ＭＰＴＣＰ）またはモバイルＩＰのような、トランスポートレイヤあるいはネットワークレイヤのソリューションとは対照的に、サーバまたはネットワークのサポートなしに、このように移動性を提供することができる。
【００６５】
優先度における変更に対する応答性を改善するためと、マルチホーミングおよび移動性のサポートを改善するために、複数の部分的なリクエストの使用とともに、マルチホーミングおよび移動性のサポートに対してここで説明する技術は、新規であると信じられている。各インターフェースに対して別々のドメインネームサービス（ＤＮＳ）キャッシュを維持する技術もまた、新規であると信じられている。
【００６６】
最後に、オペレーティングシステムおよびウェブブラウザのサポートはないが、ネットワークプロキシと、静的に定義されたルートと、プロキシ自動設定（ＰＡＣ）スクリプトとを使用する、ここで説明した技術のうちのいくつかを実現するための新規の技術も、我々は説明する。
【００６７】
一般的な問題を、次のように説明することができる。
【００６８】
１組の統一資源ロケータ（ＵＲＬ）の形での１組の要求されるリソースによって、アプリケーション（例えば、ウェブブラウザ）により、ＨＴＴＰスタックが提供される。これらは、１度に提供されてもよく、または、時間の期間にわたって提供されてもよい。ＨＴＴＰスタックは、これらのリソースに対するリクエストをいつどのように発行するかという観点からなされるいくつかの決定を有している。特に、次のようなものがある。
【００６９】
複数のリソースが同じサーバにおいて利用可能である場合に、これらのリクエストを単一のＴＣＰ接続上でパイプライン化してもよい。
【００７０】
これが行われる場合には、リクエストの順序が決定される必要がある。
【００７１】
パイプライン化に対するサポートは、普遍的でも一貫したものでもないので、未処理のリクエストの数を制限するか、あるいは、パイプライン化に対するサーバサポートをどうにかして検出することが望ましいことがある。
【００７２】
サーバは、リクエストの順序付けおよび未処理のリクエストの数に対して異なる基準があるケースでは、順序通りでないレスポンスに対するＱＣ ＨＴＴＰ拡張機能をサポートしてもよい。
【００７３】
どの時点においても開かれているべきであるパラレルなＴＣＰ接続の数に限度があることがあり、これは、異なるサーバへの接続の確立に対する順序を選ぶ必要性を結果として生じさせる。
【００７４】
それゆえ、基本的な問題は、リンク利用が最大化されるこのような方法で、ＴＣＰ接続とこれらの接続上でのＨＴＴＰリクエストの双方をスケジュールすることである。これを問題１と呼ぶ。
【００７５】
ここでは、あるサーバにおいて利用可能なリソースの観点から、問題を説明することに留意されたい。これらのサーバは、コンテンツをホスト管理するオリジナルのウェブサーバ（オリジンサーバ）、または、クライアントとオリジナルサーバとの間のパス上の（透過型でない）プロキシサーバであってもよい。プロキシサーバは、（ＣＤＮプロキシのケースでは）特定のリソースに特有であってもよく、または、（構成または学習されているローカルプロキシのケースでは）任意のリソースに対して適用可能であってもよい。ここで説明する問題およびアルゴリズムは、リソースを取り出すためにクライアントがアクセスする“サーバ”の種類に関係ない：我々は、何らかのオプション的なサーバ能力が、何らかの種類のサーバ上に存在することがあると仮定する。
【００７６】
この問題に対する多数の拡張を、次のように実現することができる。
【００７７】
要求されるリソースに関して何らかの種類の優先度順序付けがあることは、一般的である。例えば、ウェブサーバに対して、画像、広告、および、ビデオの前に、かつ、トラッカーまたは他の補助的な機能を呼び出す前に、レイアウト、スタイル、スクリプト、および、テキストのリソースを受信することが一般的に望ましい。これにより、すべてのリソースをダウンロードする前に、ページのレンダリングを開始することが可能になる。そのため、拡張される問題は、問題１に、リソースに関する優先度順序付けという追加の情報と、その順序でのまたはその順序に近いリソース配信という追加の目標とをプラスしたものである。これを問題２と呼ぶ。
【００７８】
別の可能性は、すべてのリソースが完全に受信される前に、リソースの優先度順序付けが変更されるかもしれないということである（ダウンロードプロセスの間に、要求されているリストに新しいリソースを追加できる可能性を、問題１が含んでいたことも思い出してほしい）。例えば、ウェブページが完全にダウンロードされる前にユーザがウェブページをスクロールした場合に、これが生じ、そのため、リソースの順序付けは、目に見えるリソースを優先させるように変更する。このケースでは、追加の目標は、この変更または優先度を尊重し、利用可能なリソースが、確実に、変更後の最高の優先度のリソースに依然として専用であることである。これを問題３と呼ぶ。
【００７９】
別のケースは、クライアントが、複数のインターフェースに対するアクセスを有し、それゆえ、リソースをホスト管理するサーバへの複数のパスを有するというものである。ここでは、ＣＤＮの一般的な動作−既存のシステムではサポートされていないと信じられている何かに起因して、ドメインネームのＤＮＳ解決がインターフェースごとに変化すると考えることが重要であるべきである。このケースでは、複数のインターフェースのすべてにおいて利用可能な帯域幅を利用するという追加の目的により、問題が拡張される。これを問題４と呼ぶ。
【００８０】
最後に、１組の利用可能なインターフェースが変更する可能性もある。このケースでは、利用可能な帯域幅は、最高の優先度のリソースに専用であるべきであるという原則を維持して、最小のデータ損失により、変更を効率的に取り扱う必要がある。これを問題５と呼ぶ。
【００８１】
要約すると、問題１は、１組のＵＲＬに対するパイプライン化およびリクエストのスケジューリングの最適な使用に関係する。目的は、帯域幅使用を最適化し、それにより、ページダウンロード時間を減少させることである。
【００８２】
問題２は、ＵＲＬに対する優先度順序付けと、その優先度を尊重するという目標とを追加する。目的は、ウェブページのプログレッシブなレンダリングを可能にし、それにより、知覚されているページのダウンロードスピードを改善することである。
【００８３】
問題３は、優先度の変更を可能にする。目的は、高い優先度のオブジェクトに、帯域幅を確実にすばやく再割り当てし、それにより、ユーザの注目の変更（リンクのクリック、タブの変更、スクロール等）に対する応答性を改善することである。
【００８４】
問題４は、複数のインターフェースの効率的な使用を考慮に入れ、それにより、マルチホームのホストに対するリンクアグリゲーションを通して、ページダウンロード時間を改善することを目的としている。
【００８５】
問題５は、利用可能なインターフェースにおける変更を考慮に入れ、それにより、移動性をサポートすることを目的としている。
【００８６】
ＨＴＴＰプロトコルに基づくこれらの問題に対するソリューションは、ここでは、トランスポートレイヤの代わりに、ＨＴＴＰアプリケーションレイヤに焦点を当てている。
【００８７】
既存のソリューション：既存のウェブブラウザは、問題１と、ある程度は、問題２とを解決しようと試みている。しかしながら、現在の構成は、いくつかの欠陥を有している。第１に、要求されるリソース（ＵＲＬ）は、ページがダウンロードされるにつれて、プログレッシブに識別され、これは、クライアントにより既に知られている将来要求されるリソースについての情報を考慮することなく、接続の開閉について決定がなされることを意味する。
【００８８】
第２に、既存のブラウザは、一般的に、パラレルな接続の数において任意の制限を有している。大多数のパラレルな接続が利点を提供することは期待されない。一般的な経験則は、６個のパラレルな接続を上回る収穫逓減があるように思われる。しかしながら、ＷＷＡＮネットワークは、大きなネットワーク側ダウンリンクバッファにより構成されていることが多いことに留意すべきである。これは、リンクがフルに利用されているときに、高いＲＴＴに寄与することがある。それゆえ、パラレルな接続に対するＴＣＰ Ｓｌｏｗ Ｓｔａｒｔは、別の接続が既にリンクを利用している場合には、極めてスローであるかもしれない。
【００８９】
第３に、既存のブラウザは、パイプライン化を常に善用しているわけではない。これは、パイプライン化が、ＨＴＴＰプロキシにおいて一貫してサポートされていないためである。また、プロキシによるパイプライン化の使用は、送られることになる次のオブジェクトが、プロキシにおいてまだ利用可能でないために、ＴＣＰ接続がアイドルになる“ブロッキング”問題を引き起こすことがある。同じ接続上でリクエストされている別のオブジェクトが、プロキシにおいて利用可能である場合には、その代わりに、“順序通りでないレスポンス”としてそれを送ることが望ましいだろう。
【００９０】
Ｇｏｏｇｌｅにおいて最近発表されたＳＰＤＹプロジェクト（http://dev.chromium.org/spdy）は、ＴＣＰとＨＴＴＰの間に薄い多重化レイヤを挿入することにより、問題１および問題２を解決することを目的としている。これにより、単一のＴＣＰ接続を通して、割り当てられた優先度で、複数のＨＴＴＰトランザクションをパラレルに行うことが可能になる。作成者は、問題３を将来的な作業として識別している。ＳＰＤＹプロジェクトは、ＨＴＴＰヘッダ圧縮も、重要なコンポーネントとして識別している。ＷＷＡＮを特に述べていないが、ＨＴＴＰリクエストの圧縮は、特に、ＷＷＡＮネットワークに対して価値があることがある。
【００９１】
本開示は、標準的なＨＴＴＰ１．１に基づく問題１〜５にプログレッシブに対処する例示的なアプローチを解析する。加えて、性能をさらに改善することができる、何らかの、最小の、最適なサーバ拡張を説明する。
【００９２】
問題１：基本接続およびリクエストのスケジューリング：本セクションの基本的な考えは、リソースの識別と、ＴＣＰ接続の確立と、実際のリクエストのスケジューリングとを別々に扱うことである。第１に、要求されるリソースは識別されており、したがって、接触が必要なサーバの完全な組は知られているという仮定がなされる。第２に、ＴＣＰ接続がこれらのサーバに対して確立されるが、一度にすべてである必要はなく、サーバ当たり１つの接続である必要もない。第３に、リクエストは、確立されている接続にマッピングされる。
【００９３】
接続を開くことを決定すべき２つの原則がある。
【００９４】
第１に、各サーバに対する接続の数を最小化し、その結果、パイプライン化を利用する。これは、新しい接続が確立される（ＳＹＮ／ＡＣＫおよびスロースタート）たびに、高い代償が払われるためである。他のアクティブな接続が、大幅なキューイング遅延と、したがって、大きなＲＴＴとがあることを意味する場合に、これは、特に当てはまる。
【００９５】
第２に、パケットが損失したまたは遅れたときに、全体的な輻輳レスポンスを減少させるために、複数のパラレルな接続を利用する。‘ｎ’個のＴＣＰ接続がある場合に、単一の損失に対するレスポンスは、組み合わされた輻輳ウィンドウを１／２ｎだけ減少させるためのものである。
【００９６】
これらの２つの目的が明らかに対立していると、このトレードオフを制御するパラメータが導入される：Ｐmaxを、パラレルなＴＣＰ接続の最大数とし、Ｐminを、パラレルなＴＣＰ接続の最小数におけるターゲットとする。目的は、Ｐminを前提として、サーバ当たり１個の接続を確立することである。
【００９７】
ｎ個のＵＲＬの組Ｕが与えられると、Ｕ＝｛Ｕ0，．．．，Ｕn-1｝であり、ｍ個の一意的なサーバの組Ｓ（Ｓ＝｛Ｓ0，．．．，Ｓm-1｝）をそこから識別でき、ここで、ｍ≦ｎである。既存のウェブサーバに対する即座に有用な拡張は、ページに対して可能な限り多くの要求されるＵＲＬを、可能な限りすばやく識別するためのものであることに留意されたい。現在、このプロセスは、関係し合う必要がないダウンロードおよびレンダリングプロセスと関係し合っている。
【００９８】
複数の完全修飾ドメインネーム（ＦＱＤＮ）は、同じＩＰアドレスにマッピングしてもよいので、サーバＳjは、ＦＱＤＮではなく、ＩＰアドレスによって識別される。（単一のＦＱＤＮが複数のアドレスにマッピングする可能性を、以下でさらに説明する。）ｓ（ｉ）を、ＵＲＬ Ｕiに対して要求されるサーバのインデックスとし（すなわち、Ｕiは、Ｓs(i)から取得することができる）、Ｕ（ｊ）を、サーバＳjから取得することができるＵＲＬの組とする。
【００９９】
接続を確立し、リクエストを接続に割り振るためのプロセスが提供されている。このプロセスでは、リクエスト機会は、新しいリクエストを発行するための機会である。これがどのように定義されるかは、リクエスト／接続の整合に事前に取り組むことと、接続がアイドルになるのを可能にすることとの間のトレードオフである。その理由は、すべてのリクエストは、新しいリクエストが発行される前に完了するからである。いくつかの例を以下に示す。
【０１００】
アルゴリズム１：
【数１】
【０１０１】
このプロセスの動作は、リクエスト機会がどのように定義されるかに依存する。２つの両極端は、次のように定義される。
【０１０２】
グリーディリクエスト機会：サーバに対する接続がオープンであるときにはいつでも、これが起こる。
【０１０３】
レイジー（ｌａｚｙ）リクエスト機会：レスポンスが接続上で完全に受信されたときにはいつでも、これが起こる。
【０１０４】
グリーディリクエスト機会のケースでは、接続の最大数Ｐmaxを前提として、すべてのリクエストが即座に発行される。Ｐminを尊重するために、リクエストは、同じサーバへの複数の接続にわたって分配されることもある。しかしながら、いったん、すべてのリクエストが発行されると、変更を行う機会はない。１つの接続上でのリクエストは、別の接続上でのリクエストよりも、完了するのにより長い時間がかかるので、Ｐminの接続よりも少ないということが起こるかもしれない。
【０１０５】
レイジーリクエスト機会のケースでは、プロセス全体を通してＰminが尊重される。しかしながら、１つのレスポンスの終了と、次のレスポンスの開始との間の時間の間、各接続はアイドルのままであり、この時間は、１つのラウンドトリップタイムにサーバレスポンス時間をプラスしたものを測定する。これは、パイプライン化をサポートしないＨＴＴＰ１．１クライアントに対する標準的な振る舞いである。
【０１０６】
理想的には、リクエスト機会に対する定義は、２つの両極端の間のどこかにあるだろう。例えば、レスポンスを受信するための残り時間が、１つのラウンドトリップタイムにサーバ処理時間をプラスしたものであると推定されたときに、リクエスト機会が、起こることがある。しかしながら、サーバ処理時間が知られておらず、ＲＴＴのみが推定されていると、いずれにしても、この時間は、以前のレスポンスに対する総受信時間よりも長いことがある。以下の説明では、“ジャストインタイム”（Ｊｉｔ）リクエスト機会は、リンクがアイドルになるのを避けるのに十分な時間において、しかし、そうでなければ、可能な限り遅く、リクエストが発行される、最適化されたバージョンを意味する。
【０１０７】
パイプライン化のサーバサポート：プロキシサーバは、パイプライン化に対する一貫したサポートを提供しないと噂されている。（プロキシを含む）ＨＴＴＰ１．１サーバは、パイプライン化リクエストを処理するか、または、無視するかのいずれかである（すなわち、失敗しない）ように要求される。したがって、１つより多いリクエストが発行された場合に、最初のレスポンスを完全に受信した後に、（第２のレスポンスが後に続くか否かによって）サーバは、パイプライン化をサポートするか否かを決定することが可能であるはずである。サーバがパイプライン化をサポートしないケースでは、そのサーバからリクエストされたＵＲＬは、最初のものを除いて、そのサーバに対するｕi組に返されるべきであり、言及したパイプライン化サポートはない。そのサーバへの後続する接続は、最大で１つのリクエストを受信すべきである。
【０１０８】
順序通りでないレスポンス：標準的なサーバは、リクエストを受信した順序で、パイプライン化されたリクエストに対するレスポンスを返す。サーバが異なる順序でリクエストを返すことを可能にするＨＴＴＰ拡張機能が、定義されている。特に、プロキシサーバのケースでは、オブジェクトをリクエストしたのとは異なる順序で、サーバにおいてオブジェクトが利用可能になることがあるので、これは価値がある。それゆえ、順序通りのオブジェクト配信は、ヘッドオブラインブロッキング問題を引き起こすかもしれない。しかし、この特徴を利用するためには、複数のリクエストが接続上でパイプライン化される必要がある：より多くのリクエストがキューに入れられている場合に、ヘッドオブラインブロッキングの可能性は減少するが、より多くの取り組みが行われている：結果として、この特徴が存在するときに、この特徴が存在しないときよりも、接続上でより多くのリクエストを発行することが望ましいことがある。
【０１０９】
順序通りでない拡張は、リクエストに追加された“トランザクションＩＤ”ヘッダフィールドからなる。順序通りでないレスポンスは、対応するリクエストのトランザクションＩＤ値をエコーとして返す。レスポンスにおけるトランザクションＩＤフィールドの不在は、サーバが、順序通りでないレスポンスをサポートしないことを示す。
【０１１０】
ＨＴＴＰヘッダ圧縮：ＨＴＴＰは、エンティティボディのｇｚｉｐ圧縮をサポートするが、リクエストのｇｚｉｐ圧縮はサポートしない。Ｇｏｏｇｌｅ ＳＰＤＹプロジェクトは、かなりの利点を提供するとして、ＨＴＴＰヘッダ圧縮を識別しており、ＷＷＡＮネットワークに対しては、リクエスト圧縮が特に有用であることが期待されてもよい。
【０１１１】
ヘッダ圧縮は、下位互換性のあるＨＴＴＰ拡張機能として次のように容易に定義できる。
【０１１２】
ヘッダ圧縮をサポートしているクライアントは、既存のＣｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇヘッダ（例えば、Ｈｅａｄｅｒ−Ｅｎｃｏｄｉｎｇ：ｇｚｉｐ）に類似する、最初のリクエスト中の新しいオプション的なヘッダにより、これを示す。
【０１１３】
ヘッダ圧縮をサポートしているサーバは、新しいヘッダを認識し、圧縮されたヘッダを持つレスポンスを返す。
【０１１４】
ヘッダ圧縮の始まりは、新しいリクエストまたはレスポンスが期待されるストリーム中に現れる標準的なｇｚｉｐヘッダにより、示すことができる。
【０１１５】
接続上でのリクエストまたはレスポンスのシーケンスは、１つの連続的なストリームとして圧縮すべきである。（それぞれの終端の復帰改行を含む）リクエストまたはレスポンスの連結から、圧縮されていないストリームが形成される。各リクエストまたはレスポンスの終わりに、フラッシュポイント（flush point）があるにちがいないので、後続の情報を受信することなく、これをフルにデコードすることができる。
【０１１６】
圧縮が始まる前に送られた、圧縮されていないリクエストまたはレスポンスは、圧縮のための静的なディクショナリとして使用すべきである。
【０１１７】
サーバ識別リソース：Ｇｏｏｇｌｅ ＳＰＤＹは、これらの例において、クライアントがリクエストしていない、このリソースが要求されるだろうとサーバが気付いているリソースを、サーバがクライアントに返す可能性を識別する。クライアントがリクエストすることを望むことがあるリソースの提案を、サーバが提供する可能性もある。
【０１１８】
前者のオプションは、クライアントがリクエストをキャンセルする能力を要求するのに対し、後者は、その能力に対する必要性なく、同じ目的のほとんどを達成する。
【０１１９】
順序通りでないレスポンスがサポートされている場合に、提案したアプローチのシンプルな構成は、特別なトランザクションＩＤとリクエストＵＲＬを持つ、サーバ識別リソースに対するレスポンスヘッダを、サーバが送ることである。これは、クライアントが、そのキャッシュを調べて、オブジェクトをリクエストするか否かを決定することができるように、キャッシュ関連情報（データ、Ｅタグ、キャッシュ制御ディレクティブ）を含めることを可能にする。
【０１２０】
リクエストのキャンセル：先に説明した順序通りでない拡張がサポートされている場合には、トランザクションＩＤを持つリクエストを参照することにより、リクエストをキャンセルするための新しい方法を、自明に追加することができる。これは、より多くのリクエストをパイプライン中でキューアップすることを可能にする（そして、ヘッドオブラインブロッキングの可能性を減少させる）のに、有用であってもよい一方で、必要な場合に、この取り組みを逆にすることもできる。
【０１２１】
問題２：リクエストの優先順位付け：問題２は、ＵＲＬの組、Ｕが、優先度順序を有する追加の可能性を導入する。一般性を損なうことなく、リストＵ0，．．．，Ｕn-1は、最高の優先度が１番目である優先度順序であると仮定する。また、追加されるのは、より高い優先度のオブジェクトが、より低い優先度のオブジェクトの前に配信されるという目的である。
【０１２２】
この新しい目的は、利用可能な帯域幅使用を最大化するという本来の目的に次ぐものであることに留意されたい：すなわち、帯域幅使用を最大化するためにこれが必要である場合には、優先度順序通りでなくオブジェクトを配信することを許容できる（そうでなければ、厳密な優先度順序でリクエストを発行し、各リクエストの後で、別のリクエストが発行される前にそれが完了するのを待つことにより、要件が満たされるだろう）。
【０１２３】
優先順位付けをサポートするために、アルゴリズム１を次のように修正する：
アルゴリズム２
１）Ｕにおける順序付けは、そのサーバ上で利用可能な最高優先度のリソースの順序にサーバを置くことにより、Ｓにおける順序付けを誘発する。その後、各組ｕiも、明白な方法で順序付けされる
２）ステップ２（ａ）、２（ｂ）、および、４（ｃ）（ｉ）において、選ばれたｉの値が、このような最小値であること以外は、アルゴリズム１にしたがう。
【０１２４】
問題３：優先度における変更：Ｇｏｏｇｌｅ ＳＰＤＹプロトコルは、ＴＣＰとＨＴＴＰとの間に薄い多重化レイヤを提供し、これを使用して、複数のリクエスト／レスポンストランザクションを同じ接続上で多重化することにより、この要件に対処することを目的としている。既存の技術との相違は、次のように理解することができる。
【０１２５】
パイプライン化は、複数のリクエスト／レスポンストランザクションが、ＴＣＰ接続を共有することを可能にするが、レスポンスが、シーケンシャルにおよび順序通りに返されることを要求する。
【０１２６】
順序通りでないレスポンスによるパイプライン化（ワンショットウェブ）は、レスポンスが、異なる順序で返されることを可能にするが、レスポンスは、依然としてシーケンシャルである（各レスポンスは、次が開始する前に完了しなければならない）。
【０１２７】
パラレルなＴＣＰ接続は、レスポンスが、パラレルに送られる（ＩＰレイヤにおいて多重化される）ことを可能にするが、トランザクションは、独立して進む：１つのものの、他のものに対する優先順位付けを調整することはできない。
【０１２８】
このため、ＳＰＤＹプロトコルは、レスポンスのシーケンシャルな完了に対する要件なしに、パイプライン化の利益を得ることを目的している。
【０１２９】
第１に、アルゴリズム２において、レイジーリクエスト機会またはジャストインタイムリクエスト機会が使用される場合に、各ｕi組内のリクエストされていないリソースの優先度を再順序付けすることが、いかなるときにおいても常に可能であることに留意すべきである。このシンプルなアプローチは、実質的な利益を提供することができる（これをアルゴリズム２ａと呼ぶ）。
【０１３０】
ＨＴＴＰの部分的なリクエスト（すなわち、Ｒａｎｇｅヘッダを持つＨＴＴＰリクエスト）の使用に基づいて、より細かい粒度で優先度の変更を取り扱うための、代替的なスキームをここで説明する。
【０１３１】
第１に、Ｒを、バイトでの、最大リクエストサイズとする。サイズＲまたはより小さいサイズの要求されるリソースの断片に対して、リクエストが発行される。アルゴリズム２では、各ＵＲＬ、ｕiは、対（ＵＲＬ、Ｂｙｔｅ Ｒａｎｇｅ）により置換される。アプリケーションにより提供されるＵＲＬおよびＢｙｔｅ Ｒａｎｇｅ［０，Ｒ−１］により、これらの対が初期化される。
【０１３２】
その後、アルゴリズム３を形成するために、以下の手順が追加される。
【０１３３】
ＵＲＬに対する第１のレスポンスヘッダを受信次第、オブジェクトサイズＦを取得する。その後、Ｆ＞Ｒである場合に、同じＵＲＬとＢｙｔｅ Ｒａｎｇｅ［Ｒ，２Ｒ−１］，［２Ｒ，３Ｒ−１］，．．．，［ｒＲ，Ｆ−１］とを持つ、ｕi中のｒ：＝ｃｅｉｌ（Ｆ／Ｒ）−１の追加エントリを構築する。ｕiにおけるエントリの順序は、先のように、ＵＲＬの優先度順序付けに基づくべきであることに留意されたい。
【０１３４】
このスキームでは、優先度の変更が起こったときに、リクエストされたが、接続上で受信されていない未処理のデータの量は、最大Ｒであり、それゆえ、リソースが、より低い優先度のリソースに専用である期間が減少される。
【０１３５】
ジャストインタイム（ＪｉＴ）リクエスト機会を効率的にサポートするために、Ｒは、１つのラウンドトリップタイム中で送信することができるデータの量よりも大きいはずであるものと考えられる。測定されたラウンドトリップタイムおよびデータレートにしたがって、Ｒが変化すべきであってもよい。
【０１３６】
問題４：マルチホーミングに対するサポート：マルチホームのホストは、複数の接続されたインターフェースを有し、それゆえ、インターネットへの複数のルートを有するものである。マルチホームのホストのケースにおける目的は、ダウンロードスピードを改善するために、複数のインターフェースを同時に利用することである。
【０１３７】
第１に、ＨＴＴＰスタックが、利用可能なインターフェースの知識と、特定のインターフェースを使用するようにＴＣＰ接続に命令するための能力とを有していると仮定する。既存のホストオペレーティングシステム（ＯＳ）構成ではそうではないので、これを達成するために何らかの作業が要求される。このようなＯＳの改善に先立って、可能性ある代替実施形態は、別々のインターフェースを通して到達可能なＨＴＴＰプロキシサーバを提供するためと、異なるインターフェースを通して各サーバにパケットを向ける、これらのサーバに対する明示的なルートを、クライアントルーティングテーブル内で定義するためのものである。このように、プロキシサーバの選択は、使用されるだろうインターフェースを決定し、そのインターフェースに関係付けられているプロキシに接続を向けることにより、インターフェースに接続を向けることができる。
【０１３８】
所定のＵＲＬに対して使用されることになるプロキシを決定するＪａｖａＳｃｒｉｐｔ機能を、ユーザが特定することを可能にする、プロキシ自動設定スクリプトの使用により、多くの既存のウェブブラウザ構成において、プロキシサーバの選択を制御することができる。このアプローチにより、インターフェースにわたってリクエストを静的に分配することが可能になり、例えば、ある割合のリクエストは、１つのインターフェースに対するものであり、残りのものは、別のインターフェースに対するものである。
【０１３９】
リクエストのうちの１／Ｎをｐｒｏｘｙ＿ａに向け、残りのものをｐｒｏｘｙ＿ｂに向ける適切なスクリプトが、以下に示されている：
【数２】
【０１４０】
このスクリプトでは、ＵＲＬの長さがハッシュ関数として使用される。代替的なハッシュ関数を使用することもできる。
【０１４１】
特定のインターフェースにＴＣＰ接続を向けるＯＳベースの能力が与えられるとすると、ここではアルゴリズム４と呼ばれるシンプルなマルチホーミングアプローチは、アルゴリズム２にしたがうためのものであり、ラウンドロビン方法で、利用可能なインターフェースにわたってＴＣＰ接続を分配するためのものである。
【０１４２】
アルゴリズム５を得るために、アルゴリズム３に対して同じ拡張を行うことができる。アルゴリズム４と比較すると、利点は、大きなオブジェクトを複数のインターフェースにわたって分けてもよいことである。その理由は、オブジェクトに対する部分的なリクエストが、接続にわたって分配されるだろうからである。
【０１４３】
これらのケースでは、Ｐminを、少なくともインターフェースの数に設定することが望ましい。
【０１４４】
マルチホーミングおよびＤＮＳ：ＣＤＮの通常の動作に起因して、ＤＮＳ解決の結果は、ホストのインターネットへの接続のポイントに依存して、および、リクエストが最初に送られるＤＮＳサーバに依存して、異なってもよい。我々の知る限り、既存のホストＯＳは、これに対処していない。
【０１４５】
ＨＴＴＰおよびＣＤＮの特定のケースでは、異なる解決の結果の理由は、ＣＤＮが、接続のポイントに“近い”適切なプロキシを識別するためである。各インターフェースに対して正しいプロキシを使用することが極めて望ましい。
【０１４６】
問題５：移動性：問題４に対するソリューション（マルチホーミング）が与えられると、移動性に対するサポートは、転送の間にインターフェースがシャットダウンするケースと、新しいインターフェースが利用可能になるケースとを取り扱うという問題に減少する。
【０１４７】
移動性をサポートするアルゴリズム６を得るために、アルゴリズム４が次のように拡張される。
【０１４８】
インターフェースが停止したときに、そのインターフェースを使用しているオープンな接続を識別し、これらの接続上で発行されている未完了のリクエストのリストを構築する。これらのリソースを適切なｕi組に追加して戻し、プロセスを継続する。
【０１４９】
インターフェースが立ち上がったときに、次回接続を確立しなければならないときに、このインターフェースを選択に対して利用可能にする。
【０１５０】
双方のケースにおいて、インターフェースの数に基づいてＰminが設定されている場合に、Ｐminを修正することを考える。
【０１５１】
アルゴリズム７を得るために、アルゴリズム５に対して、類似する拡張を次のように行うことができる。
【０１５２】
インターフェースが停止したときに、そのインターフェースを使用しているオープンな接続を識別し、これらの接続上で発行されている未完了のリクエストのリストを構築する。これらのリクエストを適切なｕi組に追加して戻し、プロセスを継続する。Ｂｙｔｅ Ｒａｎｇｅ［ａ，ｂ］に対する進行中の何らかのリクエストに対して、受信した最後のバイトｃを識別し、Ｂｙｔｅ Ｒａｎｇｅ［ｃ＋１，ｂ］に対するリクエストを、適切なｕi組に追加する。
【０１５３】
インターフェースが立ち上がったときに、次回接続を確立しなければならないときに、このインターフェースを選択に対して利用可能にする。
【０１５４】
双方のケースにおいて、インターフェースの数に基づいてＰminが設定されている場合に、Ｐminを修正することを考える。
【０１５５】
図７、ダイヤグラム７００は、前述した７個のアルゴリズムの例示的な関係を示している。本開示の利益により、リソース識別７０２と、接続確立７０４と、リクエストスケジューリング７０６との分離の基本概念が、アルゴリズム１ ７０８において初めから適用され、アルゴリズム１ ７０８は、グリーディまたはＪＩＴのリクエスト動作７１０を用いることができることを正しく認識すべきである。アルゴリズム１ ７０８は、利用可能なオプション的なサーバ能力は何でも（例えば、パイプライン化７１２、順序通りでないレスポンス７１４、ヘッダ圧縮７１６、サーバ識別リソース７１８、および、ＨＴＴＰキャンセル能力７２０）最大限利用することができるが、これらがすべて利用可能でない場合にもなお改善を提供する。
【０１５６】
アルゴリズム２ ７２２は、グリーディまたはＪｉＴのリクエスト動作７２６に加えて、シンプルなリクエスト優先順位付け７２４を追加する。アルゴリズム２ ７２２に基づくアルゴリズム２ａ ７２８では、ジャストインタイムリクエスト機会７３２とともに使用するために、優先順位の付け直し７３０が提供されている。アルゴリズム２Ａ ７２８に基づくことができるアルゴリズム４ ７３４は、ラウンドロビンベースで、接続をインターフェースに割り振ることにより、マルチホーミング７３６を提供する。アルゴリズム４ ７３４に基づくアルゴリズム６ ７３８は、ラウンドロビンベースで、接続をインターフェースに割り振ることにより、このシンプルなモデルによってさえサポートすることができる移動性７４０を提供する。
【０１５７】
アルゴリズム３ ７４２は、リクエストの優先順位付けの付け直し７４６およびＪｉＴリクエスト動作７４８とともに、部分的なリクエスト７４４の使用によって、より細かい粒度での優先順位の付け直しを提供する。アルゴリズム５ ７５０においてマルチホーミング７５２に拡張されるときにも、および、アルゴリズム７ ７５４において移動性７５６に拡張されるときにも、このアプローチは利益を提供する。
【０１５８】
図８は、ここで説明する機能性のさまざまな態様を実現するために利用することができる別のシステム８００のブロックダイヤグラムである。１つの例では、システム８００は、移動端末８０２を含む。示されているように、移動端末８０２は、１つ以上のアンテナ８０８を介して、信号を、１つ以上の基地局８０４から受信することができ、１つ以上の基地局８０４に送信することができる。さらに、移動端末８０２は、アンテナ８０８から情報を受け取る受信機８１０を備えることができる。１つの例では、受信機８１０は、受け取った情報を復調する復調器８１２に動作可能に関係付けることができる。復調されたシンボルは、その後、プロセッサ８１４により解析することができる。プロセッサ８１４はメモリ８１６に結合することができ、メモリ８１６は、移動端末８０２に関連するデータおよび／またはプログラムコードを記憶することができる。さらに、移動端末８０２は、ここで説明する方法を実行するために、プロセッサ８１４を用いることができる。移動端末８０２は、アンテナ８０８を通して送信機８２０により送信するための信号を多重化することができる変調器８１８も備えることができる。
【０１５９】
移動端末８０２は、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを基地局８０４に送信する。メモリ８１６において、および、プロセッサ８１４により実行されると、ＨＴＴＰ最適化コンポーネント８２２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる。
【０１６０】
図９は、ここで説明する機能性のさまざまな態様を実現するために利用することができるシステム９００のブロックダイヤグラムである。１つの例では、システム９００は、基地局またはノードＢ９０２を含む。示されているように、ノードＢ９０２は、信号を、１つ以上の受信（Ｒｘ）アンテナ９０６を介して、１つ以上のＵＥ９０４から受信し、１つ以上の送信（Ｔｘ）アンテナ９０８を介して、１つ以上のＵＥ９０４に送信することができる。さらに、ノードＢ９０２は、受信アンテナ９０６から情報を受け取る受信機９１０を備えることができる。１つの例では、受信機９１０は、受け取った情報を復調する復調器９１２に動作可能に関係付けることができる。復調されたシンボルは、その後、プロセッサ９１４により解析することができる。プロセッサ９１４はメモリ９１６に結合することができ、メモリ９１６は、コードクラスタ、アクセス端末割り当て、メモリ９１６に関連するルックアップテーブル、一意的なスクランブルシーケンスに関連する情報、および／または、他の適切なタイプの情報を記憶することができる。１つの例では、ノードＢ９０２は、送信アンテナ９０８を通して送信機９２０により送信するための信号を多重化することができる変調器９１８も備えることができる。
【０１６１】
メモリ９１６において、および、プロセッサ９１４により実行されると、ＨＴＴＰ最適化サポートコンポーネント９２２は、ＨＴＴＰ通信を最適化するために、ＵＥ９０４によってリクエストされることがある能力（例えば、パイプライン化、順序通りでないレスポンス、ヘッダ圧縮、サーバ識別リソース、および、ＨＴＴＰキャンセル能力）を提供する。
【０１６２】
図１０を参照すると、示されているのは、パケットデータ通信のためのシステム１０００である。例えば、システム１０００は、ユーザ機器（ＵＥ）内に少なくとも部分的に存在することができる。機能ブロックを含むものとして、システム１０００が表され、機能ブロックは、コンピューティングプラットフォーム、プロセッサ、ソフトウェア、または、それらの組み合わせ（例えば、ファームウェア）により実現される機能を表す機能ブロックとすることができることを正しく認識すべきである。システム１０００は、共に動作することができる電気コンポーネントの論理グルーピング１００２を含む。例えば、論理グルーピング１００２は、パケットデータ通信のための多数のパラレルな接続を確立する電気コンポーネント１００４を含むことができる。さらに、論理グルーピング１００２は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化リクエストを送信する電気コンポーネント１００６を含むことができる。加えて、論理グルーピング１００２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる電気コンポーネント１００８を含むことができる。さらに、システム１０００は、電気コンポーネント１００４〜１００８に関係付けられている機能を実行するための命令を保持するメモリ１０２０を含むことができる。メモリ１０２０の外部にあるとして示されているが、電気コンポーネント１００４〜１００８のうちの１つ以上は、メモリ１０２０内に存在することができることを理解すべきである。
【０１６３】
図１１において、パケットデータ通信のための装置１１０２が示されている。装置１１０２は、パケットデータ通信のための多数のパラレルな接続を確立する手段１１０４を備える。装置１１０２は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化リクエストを送信する手段１１０６を備える。装置１１０２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる手段１１０８を備える。
【０１６４】
ここで開示した態様に関連して説明した、さまざまな例示的な論理ブロック、モジュール、回路およびアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェア、または、双方を組み合わせたものとして実現してもよいことを、当業者はさらに正しく認識するであろう。ハードウェアおよびソフトウェアのこの交換可能性を明確に示すために、さまざまな例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、一般的にこれらの機能性に関して上述した。このような機能性がハードウェアまたはソフトウェアとして実現されるか否かは、特定の応用、および、システム全体に課せられた設計の制約に依存する。当業者は、それぞれの特定の応用に対して方法を変化させて、説明した機能性を実現してもよいが、このようなインプリメンテーション決定は、本開示の範囲からの逸脱を生じさせるものとして解釈すべきではない。
【０１６５】
本明細書で使用するような、用語“コンポーネント”、“モジュール”、“システム”、および、これらに類するものは、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または、実行中のソフトウェアのいずれかである、コンピュータ関連エンティティのことを指すことを意図している。例えば、コンポーネントは、これらに限定されないが、プロセッサ上で動作しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／または、コンピュータであってもよい。例として、サーバ上で動作しているアプリケーションとサーバの双方をコンポーネントとすることができる。１つ以上のコンポーネントが、プロセスおよび／または実行のスレッド内に存在することがあり、コンポーネントは、１つのコンピュータ上に局所化されていてもよく、および／または、２つ以上のコンピュータ間に分散されていてもよい。
【０１６６】
ここでは、例として、事例として、あるいは例示として機能することを意味するように、“例示的な”という単語を使用する。“例示的な”ものとして、ここで説明したいずれの態様または設計は、他の態様または設計と比較して、必ずしも好ましいものとして、または、利益のあるものとして、解釈すべきではない。
【０１６７】
多数のコンポーネント、モジュール、および、これらに類するものを含んでもよいシステムの観点から、さまざまな態様が提示されるだろう。さまざまなシステムが、追加のコンポーネント、モジュール等を含んでもよいこと、および／または、図面に関連して論じたコンポーネント、モジュール等のすべてを含まなくてもよいことを理解し、正しく認識すべきである。これらのアプローチの組み合わせもまた使用してもよい。ここで開示したさまざまな態様は、タッチスクリーンディスプレイ技術を、ならびに／あるいは、マウスおよびキーボードタイプのインターフェースを、利用するデバイスを含む電気デバイス上で実行することができる。このようなデバイスの例は、コンピュータ（デスクトップおよびモバイル）、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ならびに、ワイヤードおよびワイヤレス双方の他の電子デバイスを含む。
【０１６８】
加えて、ここで開示した態様に関連して説明した、さまざまな例示的な論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここで説明した機能を実行するように設計されているこれらの任意の組み合わせで、実現または実行されてもよい。汎用プロセッサは、マイクロプロセッサであってもよいが、代替的に、プロセッサは、何らかの従来のプロセッサ、制御装置、マイクロ制御装置、または、状態機械であってもよい。プロセッサはまた、コンピューティングデバイスの組み合わせとして、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアを伴った１つ以上のマイクロプロセッサ、あるいは、このようなコンフィギュレーションの他の何らかのものとして実現されてもよい。
【０１６９】
さらに、開示した態様を実現するようにコンピュータを制御するために、標準のプログラミングおよび／またはエンジニアリング技法を使用して、ソフトウェア、ファームウェア、ハードウェア、または、これらの何らかの組み合わせを生成させることにより、方法、装置、または、製造物として、１つ以上のバージョンを実現してもよい。ここで使用するような用語“製造物”（または、代替的に、“コンピュータプログラムプロダクト”）は、何らかのコンピュータ読取可能デバイス、キャリア、または、媒体から、アクセス可能なコンピュータプログラムを含むことを意図している。例えば、コンピュータ読取可能媒体は、これらに限定されないが、磁気記憶デバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）や、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）．．．）や、スマートカードや、フラッシュメモリデバイス（例えば、カード、スティック）を含むことがある。さらに、電子メールを送受信する際に、あるいは、インターネットまたはローカルエリアネットワーク（ＬＡＮ）のようなネットワークにアクセスする際に使用するもののような、コンピュータ読取可能な電子データを伝えるために、搬送波を用いることができることを正しく認識すべきである。当然、当業者は、開示した態様の範囲から逸脱することなく、このコンフィギュレーションに対して多くの改良がなされてもよいことを認識するだろう。
【０１７０】
ここで開示した態様に関連して説明した方法またはアルゴリズムのステップは、直接、ハードウェアで、プロセッサにより実行されるソフトウェアモジュールで、あるいは、２つの組み合わせで、具現化してもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーブバルディスク、ＣＤ−ＲＯＭ、あるいは、技術的に知られている他の何らかの形態の記憶媒体に存在していてもよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替実施形態では、記憶媒体は、プロセッサと一体化されてもよい。プロセッサおよび記憶媒体は、ＡＳＩＣに存在してもよい。ＡＳＩＣは、ユーザ端末に存在してもよい。代替実施形態では、プロセッサおよび記憶媒体は、ユーザ端末中のディスクリートコンポーネントとして存在してもよい。
【０１７１】
開示した態様の先の説明は、当業者が本開示を作り、または、使用できるように提供されている。これらの態様に対するさまざまな改良は、当業者に容易に明らかになるであろう。そして、ここで定義されている一般的な原理は、本開示の精神または範囲を逸脱することなく、他の実施形態に適用されてもよい。したがって、本開示は、ここに示した実施形態に限定されることを意図しているものではないが、ここに開示した原理および新規の特徴と矛盾しない最も広い範囲に一致させるべきである。
【０１７２】
先に説明した例示的なシステムを考慮して、開示した主題事項にしたがって実現されてもよい方法を、いくつかのフローダイヤグラムを参照して説明してきた。説明を簡略化する目的のために、一連のブロックとして、方法を示し、説明してきたが、いくつかのブロックは、ここで示し、説明したものとは異なる順序で、および／または、他のブロックと同時に、起こることがあるので、請求されている主題事項は、ブロックの順序によって限定されないことを理解し、正しく認識すべきである。さらに、ここで説明した方法を実現するのに、示されているブロックがすべて要求されるわけではない。さらに、ここで開示した方法は、このような方法をコンピュータに伝送および転送するのを促進するために、製造物上に記憶することができることをさらに正しく認識すべきである。ここで使用するような製造物という用語は、何らかのコンピュータ読取可能デバイス、キャリア、または、媒体からアクセス可能なコンピュータプログラムを含むように意図されている。
【０１７３】
ここでの参照により組み込まれていると言われた、何らかの特許、公報、または、他の開示資料は、組み込まれている資料が、本開示で述べた、既存の定義、ステートメント、または、他の開示資料と対立しない限りのみ、全体または一部として、ここに組み込まれることを正しく認識すべきである。そのようなものとして、および、必要である限り、ここで明示的に述べたような開示は、参照によりここに組み込まれている、対立するあらゆる資料に取って代わる。参照によりここに組み込まれていると言われた、何らかの資料あるいはその一部は、既存の定義、ステートメント、または、ここで述べた他の開示資料と対立するもの以外は、その組み込まれている資料と既存の開示資料との間で何ら対立が生じない限りのみ、組み込まれるだろう。
【合衆国法典第３５部第１１９条の下での優先権の主張】
【０００１】
本特許出願は、“ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度”と題され、２００９年１２月１８日に出願され、この出願の譲受人に譲渡され、ここでの参照によりここに明確に組み込まれている仮出願番号第６１／２８８，１１９号に対して優先権を主張する。
【同時係属中の特許出願に対する参照】
【０００２】
本特許出願は、これとともに同時に出願され、この出願の譲受人に譲渡され、ここでの参照により明確に組み込まれている、Ｒａｍｉｎ Ｒｅｚａｉｉｆａｒ氏らによる、代理人ドケット番号第１００５２８Ｕ２号を有する、以下の同時係属中の米国特許出願“アプリケーションレイヤにおける、複数のインターフェースの結合／集約”に関連する。
【分野】
【０００３】
本開示は、一般的に通信に関し、さらに詳細には、ワイヤレス通信ネットワーク中で、ハイパーテキストパケットデータコンテンツを取り出すための技術に関する。
【背景】
【０００４】
ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ウェブブラウザおよびウェブアプリケーションにより使用されている主要な通信プロトコルである。コンテンツ配信ネットワークの形で、ＨＴＴＰプロトコルの効率的な動作をサポートするために、インターネット内で大型インフラストラクチャが成長してきた。結果として、増加する数のアプリケーションが、ＨＴＴＰプロトコルに移行している。この移行に対する他の理由（例えば、ネットワークアドレス変換（ＮＡＴ）およびファイアウォールトラバーサル）がある一方で、主な動因は、ウェブインフラストラクチャの大規模なスケーラビリティを活用する能力である。
【０００５】
今日、ウェブサイトは、極めて複雑であり、ＨＴＴＰを使用してそれぞれが別々にリクエストされなければならない、数十または数百のオブジェクトを含んでいることが多い。サーバからクライアントにオブジェクトを伝送できるスピードを改善するために、さまざまな最適化がＨＴＴＰ内で定義されている。ワイヤードネットワーク内でこれらの最適化を適用するときに、かなりの量の作業が行われてきた。しかしながら、高ラウンドトリップタイム（ＲＴＴ）と非常に可変の帯域幅とを持つ、より挑戦的な移動体環境で、これらの特徴がどのように振る舞い、組み合わせられるのかを理解することは、依然として未解決の問題のままである。特に、移動体ネットワークの特性が、その当時、今日とは大きく異なっていた数年前に、多くのＨＴＴＰ作業が実行されたことに留意すべきである。
【概要】
【０００６】
以下のものは、開示されている態様のうちのいくつかの態様の基本的な理解を提供するために、簡略化した概要を提示する。この概要は、広範囲にわたる概略ではなく、キーエレメントまたは重要なエレメントを識別することや、このような態様の範囲を線引きすることのどちらも意図していない。この目的は、後に提示するさらに詳細な説明に対する前置きとして、説明されている特徴のうちのいくつかの概念を、簡略化した形で提示することである。
【０００７】
１つの態様では、パケットデータ通信のための多数のパラレルな接続を確立することと、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信することと、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させることとによる、パケットデータ通信のための方法が提供されている。
【０００８】
別の態様では、パケットデータ通信のための少なくとも１つのプロセッサが提供されている。第１のモジュールは、パケットデータ通信のための多数のパラレルな接続を確立する。第２のモジュールは、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。第３のモジュールは、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【０００９】
追加の態様では、パケットデータ通信のためのコンピュータプログラムプロダクトが提供されている。一時的でないコンピュータ読取可能媒体は、コードの組を記憶する。第１の組のコードは、コンピュータに、パケットデータ通信のための多数のパラレルな接続を確立させる。第２の組のコードは、コンピュータに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信させる。第３の組のコードは、コンピュータに、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００１０】
さらなる態様では、パケットデータ通信のための装置が提供されている。装置は、パケットデータ通信のための多数のパラレルな接続を確立する手段を具備する。装置は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する手段を具備する。装置は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる手段を具備する。
【００１１】
さらに別の態様では、パケットデータ通信のための装置が提供されている。トランシーバは、パケットデータ通信のための多数のパラレルな接続を確立する。トランシーバは、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。コンピューティングプラットフォームは、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００１２】
先の目的および関連する目的を達成するために、１つ以上の態様は、後に完全に説明する特徴、および、特許請求の範囲中で特に指摘する特徴を含んでいる。以下の説明および添付した図面により、ある例示的な態様を詳細に述べ、態様の原理を用いることができるさまざまな方法のうちのいくつかだけを示す。図面とともに考えるときに、他の利点および新規の特徴が、以下の詳細な説明から明らかになるだろう。開示されている態様は、このようなすべての態様とそれらの均等物とを含むことを意図している。
【図面の簡単な説明】
【００１３】
同一の参照文字が全体を通して対応したものを識別している図面とともに考慮されたときに、以下で示される詳細な説明から、本開示の特徴、特質、および利点がより明白となろう。
【図１】図１は、ＨＴＴＰ最適化のための通信システムの概略図を示している。
【図２Ａ】図２Ａは、ＨＴＴＰ最適化のための方法に対するフローダイヤグラムを示している。
【図２Ｂ】図２Ｂは、ＨＴＴＰ最適化のための方法に対するフローダイヤグラムを示している。
【図３】図３は、ラウンドトリップタイム（ＲＴＴ）の関数として、ページロード時間のグラフィカルプロットを示している。
【図４】図４は、単一の継続的接続に対するリンク使用パターンのダイヤグラムを示している。
【図５】図５は、第１および第２のアップリンクリクエストならびにダウンリンクレスポンスに対するリンク使用パターンのダイヤグラムを示している。
【図６】図６は、固定帯域幅での異なるＲＴＴに対して達成される最良のページダウンロード時間に対するグラフィカルプロットを示している。
【図７】図７は、ＨＴＴＰ最適化に対する複数のアルゴリズムの例示的な関係に対するダイヤグラムを示している。
【図８】図８は、ＨＴＴＰ最適化を実行する移動端末に対するブロックダイヤグラムを示している。
【図９】図９は、ＨＴＴＰ最適化をサポートするノードに対するブロックダイヤグラムを示している。
【図１０】図１０は、ＨＴＴＰ最適化に対する電気コンポーネントの論理グルーピングを有する、移動デバイス中に少なくとも部分的に存在するシステムに対するブロックダイヤグラムを示している。
【図１１】図１１は、ＨＴＴＰ最適化をサポートする電気コンポーネントの論理グルーピングを有する、ネットワーク中に存在するシステムに対するブロックダイヤグラムを示している。
【詳細な説明】
【００１４】
増加するラウンドトリップタイム（ＲＴＴ）の影響を克服するために、パラレルなＨＴＴＰ接続とパイプライン化を組み合わせることに利益が存在する。一般的に知られているブラウザは、固定数のパラレルな接続と、固定数の未処理のリクエストを用いるが、接触しなければならない異なるサーバの組により、パラレルな接続の数は影響を受ける。
【００１５】
本イノベーションの１つの態様は、未処理のリクエストの数が最小になり、リンクが依然としてフルに利用されるように、パラレルな接続の数と、パイプライン化されたリクエストの数とを、リアルタイムに変化させるためのものである。
【００１６】
例えば、リクエストされるデータの量に基づいて、リンクが依然として確実にフルに利用されるように、これらの数を変化させることができる。しかしながら、まだ受信されていないデータの量が、帯域幅とＲＴＴの積を超えてはならない。これらの量の双方とも、絶えず変化している。加えて、オブジェクトのヘッダが届くまで、オブジェクトサイズはわからないので、未処理のデータの量は、正確にはわからない。
【００１７】
１つの可能性は、これらのすべての変数に対する確率モデルを構築し、リンクがアイドルになる確率全体を、何らかのしきい値を下回るように維持しようと試みることである。例えば、オブジェクトサイズに対する確率モデルは、オブジェクトタイプ（イメージ、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ等）を、オブジェクトサイズに関する分布にマッピングするヒストリカルデータを使用してもよい。特に、オブジェクトの以前のキャッシュされたバージョンがある場合には、返されるだろうデータは、オブジェクトは変更されていないので、ゼロ（または、むしろ、ＨＴＴＰヘッダだけ）であるか、あるいは、古いものと類似するサイズを有する可能性がある新しいバージョンであるかのいずれかである。
【００１８】
したがって、最近測定された帯域幅およびラウンドトリップタイムに基づいて、リクエストされたが受信されていないデータが、帯域幅とＲＴＴの積を超える確率まで、より多くのオブジェクトのパイプライン化を継続できる。より多くのデータが届くか、あるいは、帯域幅またはラウンドトリップタイムにおける変更が観測されたときにはいつでも、この計算を繰り返すことができる。それにより、ＨＴＴＰ接続上のパイプライン化されたリクエストのターゲット数は、以下でさらに詳細に説明するように、接続の持続時間の間に変化することがある。
【００１９】
図面を参照して、ここでさまざまな態様を説明する。以下の説明では、説明の目的上、１つ以上の態様の完全な理解を提供するために、多数の特定の詳細を述べる。しかしながら、これらの特定の詳細なしにさまざまな態様を実施できることが、明らかであることがある。他の例では、これらの態様の説明を促進するために、よく知られている構造およびデバイスは、ブロックダイヤグラムの形で示されている。
【００２０】
図１では、通信システム１００において、移動デバイス、アクセス端末、または、ユーザ機器（ＵＥ）１０２が、複数のサーバ１１２〜１１４上に記憶されているオブジェクト１０６、１０８、１１０を含むハイパーテキストコンテンツ１０４に対するパイプライン化リクエスト１０３を行う。例示的な態様では、移動デバイス１０２は、オブジェクト１０６〜１１０を受信するのに、したがって、ハイパーテキストコンテンツ１０４をレンダリングするのに必要とされるラウンドトリップタイム（ＲＴＴ）を悪化させるエアリンク１１６を通して、アクセスを得る。１つの態様では、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）１２０の一部として役割を果たすノード（例えば、マクロセル、フェムトセル、リレー）１１９と通信する無線トランシーバ１１８を、移動デバイス１０２は有しており、このノード１１９は、コアネットワーク（ＣＮ）（例えば、インターネット）１２４においてホスト管理されているサーバ１１２〜１１４へのインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）１２２に向かうものである。
【００２１】
代替的に、または、加えて、移動デバイス１０２は、ノード１２８と通信するトランシーバ１２６を有しており、ノード１２８は、ＣＮ１２４を介してサーバ１１２〜１１４にアクセスするためのワイヤレスローカルアクセスネットワーク（ＷＬＡＮ）１３０を担当する。
【００２２】
代替的に、または、加えて、移動デバイス１０２は、ノード１３４と通信するトランシーバ１３２を有しており、ノード１３４は、パーソナルアクセスネットワーク（ＰＡＮ）１３６を担当し、ＣＮ１２４を介してサーバ１１２〜１１４に到達するために、１３８において示されているようなＷＷＡＮ１２０か、または、１４０において示されているようなＷＬＡＮ１３０のいずれかに結合されている。
【００２３】
１つの態様では、トランシーバ１１８、１２６、１３２は、パケットデータ通信のための多数のパラレルな接続を確立する。トランシーバ１１８、１２６、１３２は、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する。
【００２４】
移動デバイス１０２のコンピューティングシステム１２４は、ＨＴＴＰ最適化コンポーネント１４４を有しており、ＨＴＴＰ最適化コンポーネント１４４は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる。
【００２５】
図２（図２Ａおよび図２Ｂ）では、例示的な方法２００または動作のシーケンスが、ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度に対して示されている。ブロック２０４は、パケットデータ通信のための多数のパラレルな接続を確立することを示している。特定の態様では、多数のパラレルな接続を確立することは、複数のサーバのうちのそれぞれに対する接続の数を最小化すること（ブロック２０６）により達成される。リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、多数のパラレルな接続が使用される（ブロック２０８）。
【００２６】
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストが送信される（ブロック２１０）。
【００２７】
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続を介して追加のパイプライン化リクエストを送信するために、パラレルな接続の数を動的に変化させる（ブロック２１２）。例えば、フルなリンク利用は、グリーディ（greedy）リソース利用を、または、ジャストインタイム（ＪｉＴ）リソース利用を必要とすることがある。
【００２８】
例示的な態様では、帯域幅とラウンドトリップタイムを推定すること（ブロック２１４）により、この動的な変化が達成される。リクエストされたが受信されていないパケットデータが、推定された帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、パイプライン化リクエストの送信を継続する（ブロック２１６）。
【００２９】
例示的な態様では、特に、ＨＴＴＰ取り出しを促進するネットワークによりサポートされている場合に、１つ以上のさらなる最適化が含まれる。
【００３０】
例えば、パケットデータ部分をレンダリングするためのプログレッシブな順序付けが決定され、複数のパイプライン化リクエストの順序は、プログレッシブな順序付けに関連して、優先順位が付けられる（ブロック２１８）。取り出しの間に変更が生じた場合には（ブロック２２０）、プログレッシブな順序付けの優先順位が付け直され、プロセスが更新される（ブロック２２２）。
【００３１】
別の例に対して、複数のパイプライン化リクエストは、ヘッダ圧縮によりリクエストされる（ブロック２２４）。
【００３２】
追加の例に対して、ネットワークは、移動デバイスによりどのような追加リソースが要求されることがあるかを識別（予想）できる。このようなケースでは、リクエストしなかった、サーバにより識別されたリソースを受信することがある（ブロック２２６）。必要でない場合には、サーバ識別リソースをキャンセルすることによるレスポンスによって、無線リソースの不必要な消費を避けることができる（ブロック２２８）。
【００３３】
さらなる例に対して、ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストとして、複数のパイプライン化されたリクエストを送信することができる（ブロック２３０）。
【００３４】
さらに別の例に対して、接続ラウンドロビンにより、マルチホームのホストに対してリンクを集約すること（ブロック２３２）によって、複数のパイプライン化リクエストを送信することができる。インターフェースが利用可能でなくなったこと、または、利用可能になったことを検出し（ブロック２３４）、インターフェースを使用しているオープンな接続を識別し（ブロック２３６）、オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築することにより（ブロック２３８）、ならびに、識別したオープンな接続と、インターフェースと、未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを、動的に変化させることにより（ブロック２４０）、このマルチホーミング能力の観点での移動性に対処することができる。
【００３５】
例示的な態様において、移動デバイスは、各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持することができ、ネットワークプロキシと、静的に定義されたルートと、オペレーティングシステムおよびウェブブラウザのサポートがない場合には、プロキシ自動設定（ＰＡＣ）スクリプトとを使用することができる。
【００３６】
図３は、グラフィカルプロット３００において、ｎｙｔｉｍｅｓ．ｃｏｍに対してパラレルな接続およびパイプライン化が使用可能であるＦｉｒｅｆｏｘ（登録商標）ウェブブラウザを使用して、より長いＲＴＴがページロード時間（秒単位）に与える影響を示している。テストしたページは、合計で約１．３ＭＢのデータである、おおよそ１００個のオブジェクトからなる。テストは、１．５Ｍビット／秒の固定帯域幅のリンクを通して実行され、より高いＲＴＴリンクをシミュレートするために、異なる量の追加遅延で繰り返された。フルなリンク利用では、ページをダウンロードするのにおよそ７秒かかるはずであり、実際のところ、これは、ワイヤードネットワーク上で観測されることがあるような、非常に低いラウンドトリップタイムにより達成されるものである。しかしながら、明らかに、リンク利用は、ＲＴＴが増加するにつれて、ＲＴＴに反比例して急激に落ち込む。
【００３７】
この実験が明示しているのは、ＲＴＴが、ワイヤードネットワーク上で典型的に見られるよりも大きい場合には、最先端のウェブブラウザでさえ、適度の帯域幅のリンクをフルに利用することができないということである。さらに、（７秒から２１秒への、ページロード時間における２００％の増加が非常に顕著であるのに対し、１００ｍｓから３００ｍｓへの２００％の増加は、そうでないことがあるという点で、）結果として生じる増加したページロード時間は、十分に、ユーザ経験が影響を受ける範囲内にある。
【００３８】
ここで使用されるようなリンク利用は、ネットワークが与えるように準備しているすべてのリソースを利用する、クライアントの能力のことを指す。ＥＶ−ＤＯまたはＨＳＰＡのシナリオでは、１人のユーザがこの意味でリンクを“十分に利用していない”ときに、使用されていない容量は、他のユーザに与えられるので、全体として無線リソースを十分に利用していないことはない。しかしながら、この意味での乏しいリンク利用は、より長いページロード時間において観測されるような、乏しいユーザ経験を、結果として生じさせる。
【００３９】
具体的な例として、１０人のユーザが、それぞれ、１ＭＢファイルをリクエストし（必ずしもすべてが同時でなくてもよい）、ネットワークが、８Ｍビット／秒の共有容量を有している場合に、データをユーザのすべてに配信するのに１０秒かかるだろう。平均待ち時間の観点から、データを“シーケンシャルに”供し、各ユーザに対して１秒かけるほうが、各ユーザに対してパラレルに１０秒もかけてすべてのユーザに配信するよりも、より望ましい。
【００４０】
オブジェクト配信を最適化するために、ＨＴＴＰにおいて利用可能なさまざまな技術を使用することができる。
【００４１】
継続的接続：ＨＴＴＰ１．０規格は、各ＨＴＴＰリクエストに対して、新しい伝送制御プロトコル（ＴＣＰ）接続が確立されることを要求した。各ＴＣＰ接続の確立は、ＳＹＮ／ＡＣＫ（同期化／肯定応答）交換と、ＴＣＰ輻輳制御のスロースタートフェーズに起因するスロー送信の期間とを暗示するので、この要件は、オブジェクト配信時間の観点から高い代償を必要とした。
【００４２】
ＨＴＴＰ１．１は、複数のリクエストが同じサーバに発行されるケースをより良くサポートするために、継続的接続を導入した。このケースでは、以前のレスポンスの受信が完了した後に、同じ接続上で新しいＨＴＴＰリクエストを送ることにより、ＴＣＰ接続を再使用する。このアプローチでは、リクエストの送信と、レスポンスの最初のパケットの受信との間の時間（１つのラウンドトリップタイム）の間、ダウンリンクはアイドルである。
【００４３】
単一の継続的接続に対するリンク使用パターン４００を、図４から理解することができる。図４では、アップリンクリクエスト４０２とダウンリンクレスポンス４０４との間のギャップが、リンクが十分に利用されていないことを（ギャップの形で）示しており、ＲＴＴがより高い場合に、この十分に利用されていないことが、いっそう悪いという事実を示している。
【００４４】
ＲＴＴに対処しない、リンク帯域幅の単なる増加は、それ自体では、リンク利用の観点から性能を改善しないことを、本開示の利益により正しく認識すべきである。さらに図４を参照すると、帯域幅の増加は、時間の関数として、各アップリンクブロックおよびダウンリンクブロックをより狭くさせる（すなわち、より少ない時間で同じデータが転送される）だろうが、ギャップのサイズを減少させないだろう。実際、ギャップは、総ダウンロード時間のより大きな部分を表し、したがって、このケースでは、帯域幅の増加は、リンク利用を減少させる。
【００４５】
パラレルな接続：現代のブラウザは、同じサーバまたは異なるサーバ（またはその双方）のいずれに対しても、パラレルな複数のＴＣＰ接続を開いている。この技術の効果は、２つある：第１に、複数のアクティブに送信しているＴＣＰ接続を集約するという輻輳制御の振る舞いは、スロースタートの間の輻輳ウィンドウのより速い開きと、各パケットドロップに対するより減少した輻輳レスポンス以外では、単一のＴＣＰ接続と同等のものとして見なされることがある。第２に、（継続的接続に対して先に示したように）１つの接続上の送信が断続的であるケースでは、送信の間のアイドル期間が、他の接続によって使用されてもよく、これによりリンク利用を改善する。
【００４６】
パイプライン化：実際、ＨＴＴＰ１．１は、第１のリクエストに対するレスポンスの完了を待つことなく、複数のリクエストを送ることを可能にする。これは、レスポンスの間にリンクがアイドルになることなく、サーバが続けざまにレスポンスを送ることを可能にする。ＨＴＴＰは、リクエストとレスポンスを整合させるための他のメカニズムを何ら提供しないので、レスポンスは、リクエストを受信したのと同じ順序で送らなければならない。
【００４７】
図５では、第１および第２のアップリンクリクエスト５０２、５０３と、ダウンリンクレスポンス５０４とによる、継続的接続のためのリンク使用パターン５００に対して、パイプライン化の効果が示されている。
【００４８】
現代のウェブブラウザはすべて、先の最初の２つの技術を実質的に利用している。しかしながら、ＨＴＴＰ１．１規格中で定義されているが、パイプライン化のサポートは、かなりの間、サーバおよびプロキシにおいて普遍的でなかったし、特に、透過型プロキシのケースでは、固有の失敗モードの何らかの証拠がある。結果として、例えば、失敗モードを検出して、非パイプライン化動作にグレースフルにフォールバックするように注意したり、この技術が成功しているサーバのホワイトリストを維持する等、パイプライン化の実現において何らかの注意が必要である。Ｏｐｅｒａ（登録商標）ブラウザは、デフォルトによりパイプライン化をイネーブルさせる（そして、明らかに、このような技術を実現する）。Ｆｉｒｅｆｏｘでは、パイプライン化はサポートされているが、デフォルトによりディセーブルされている。Ｓａｆａｒｉ（登録商標）およびＣｈｒｏｍｅ（登録商標）は、（現在）パイプライン化をサポートしていない。
【００４９】
ブラウザにおいてパイプライン化に対する幅広いサポートがない理由は、図３と、先に参照した問題とから明らかである：継続的でパラレルな接続のみを使用する低ＲＴＴ接続上では、リンクのブラウザ利用は非常に高い。コンテンツ配信ネットワークは、近年、典型的なウェブＲＴＴを積極的に押し下げ、改善されたブラウジング性能を結果として生じさせ（これは、ＣＤＮの主要な価値命題である）、結果として、ワイヤードおよびワイヤレスのローカルアクセスネットワーク（ＷＬＡＮ）ウェブブラウジングの大多数に対して、認識されている問題はほとんどない。
【００５０】
パイプライン化がサポートされている場合に、レスポンス間にギャップがないはずなので、リンク利用は、単一の接続では１００％であるはずだと、ある人は期待するかもしれない。しかしながら、いくつかのケースでは、パイプライン化された形でのリクエストをサーバが受け入れることがある一方で、以前のリクエストが完了するまでサーバが各リクエストを処理しないことがある。これは、サーバ処理のためにかかる時間に等しい、レスポンス間のギャップにつながる。サーバの負荷が非常に大きい場合に、レスポンスを発生させるために、サーバが、スクリプト実行のような、複雑な機能を実行しなければならない場合に、および／または、サーバが、外部サーバ（例えば、データベース）を参照しなければならない場合に、この時間はかなりのものであるかもしれない。
【００５１】
到来側では、パイプライン化されたリクエストを受け入れるが、送出側では、シリアルなリクエストを発行する中間プロキシがある場合に、同じ効果が観測されることがある。パイプライン化されたリクエストをサーバがパラレルに処理する場合でさえ、所定のレスポンスを送る時間が来たときに、この処理の結果が利用可能でないことがある。
【００５２】
最初の実験：先のデータは、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のような、高ＲＴＴリンク上で、ウェブブラウジング性能において改善の余地があると、我々に信じさせる。さらなる証拠は、クライアントと中間プロキシとの間にパイプライン化を適用することと、さらに、順序通りでなく（すなわち、クライアントおよびプロキシによりサポートされている新しいＨＴＴＰ拡張機能を通して）レスポンスを返す可能性を導入することとによってもたらされる。このアプローチにおいて、リンク利用が改善される。その理由は、クライアントとプロキシとの間の低ＲＴＴにより、単一のＴＣＰ接続が、ＷＷＡＮリンクをフルに利用することが可能になり、プロキシは、送出側でパラレルなリクエストを発行するように設計されているからである。要求されるリソースの早期の識別もまた、組み込むことができる。
【００５３】
ターゲットＨＴＴＰサーバにより直接サポートされている（そして、これらのサーバがリクエストをパラレルに処理すると仮定する）場合に、順序通りでないレスポンスに対するＨＴＴＰ拡張機能が、利益を提供することがあることに留意すべきである。Ｇｏｏｇｌｅ（登録商標）ＳＰＤＹに対して以下で説明する範囲を除いて、実験はこのアプローチを追求していないと信じられている。
【００５４】
本イノベーションを推進するために行われた実験は、プロキシの配備が要求されないケース（すなわち、クライアント側のみの技術）に対処する。明確さのために、ネットワーキングを除くすべてのボトルネックが取り除かれている“理想的なブラウザ”に、最初の焦点を当てる。特に、“理想的なブラウザ”は、ページをレンダリングするのに要求されるリクエストの完全な組のアプリオリな知識を有し、受信するとすぐにコンテンツをレンダリングする。
【００５５】
それゆえ、ページロード時間に対する唯一の寄与は、ＨＴＴＰプロトコルを使用して、ネットワークを通してデータを転送するのに要求される時間である。“理想的なブラウザ”は、パイソンスクリプトとして実現され、パイソンスクリプトには、（実際のウェブページのダウンロードのトレースから取られた）オブジェクトのリストが事前に供給され、パイソンスクリプトは、ＨＴＴＰ継続的接続と、パラレルな接続と、パイプライン化とを使用して、オブジェクトをダウンロードするアルゴリズムを実現する。すべてのオブジェクトをダウンロードするのにかかる時間を測定する。
【００５６】
パラレルな接続と、パイプライン化と、ネットワーク帯域幅およびＲＴＴとの間の相互作用をより良く理解するために、１〜１０個の間のパラレルな接続と、そのそれぞれにおける１〜１０個の間の未処理のリクエストとにより、実験を行った。（１個の未処理のリクエストは、標準的な非パイプライン化アプローチに対応し、‘ｎ’個の未処理のリクエストは、最初に‘ｎ’個のリクエストが送られ、その後、レスポンスが完全に受信されるたびに、新しいリクエストが送られることを意味する。）
異なるネットワーク帯域幅およびＲＴＴに対する結果が、表１〜６において示されている。特に、実際のウェブサーバトレースにおける複数の接続およびパイプライン化の異なるコンフィギュレーションの性能が、理想化されている。ウェブリクエストトレースは、Ｗｉｒｅｓｈａｒｋ（登録商標）を使用して、人気のあるウェブサイトから収集される。その後、リクエストトレースファイルを発生させるために、ダンプファイルが処理される。最初の実験に対して、すべてのリクエストが予め知られており、順序通りに実行されると仮定する。オブジェクトは、プライマリサーバからのみ、すなわち、ウェブサイトを構成するオブジェクトの不均衡な配分が問題になっているサーバからのみ、リクエストされる。プライマリサーバ現象は、人気のあるウェブサイトに対しても特徴付けられる。
【００５７】
以下の表１は、複数の接続およびパイプライン化の各コンフィギュレーションに対して観測された平均ダウンロード時間を示している。
【表１】
【００５８】
以下の表２〜７は、複数の接続およびパイプライン化の各コンフィギュレーションに対して観測された平均ダウンロード時間を示している。
【表２】
【表３】
【表４】
【表５】
【表６】
【００５９】
これらの実験では、実験を行っている間に、バックグランドで何かがダウンロードされる。
【表７】
【００６０】
要約すると、図６は、１．５Ｍビット／秒の固定帯域幅での異なるＲＴＴに対して、また、（双方とも１．５Ｍビット／秒よりも高い帯域幅を持った）３Ｇ接続およびバックグランドトラフィックを持つ３Ｇ接続を通しての異なるＲＴＴに対して、達成された、最良のページダウンロード時間を提示している。各ケースに対する注釈は、最良の結果が達成された、パラレルな接続の数およびパイプライン化の量を示す。
【００６１】
明確さのために、これらの実験は、単一のサーバ上に存在するページオブジェクトのうちの９０％に制限されていたが、本イノベーションの態様は、複数のサーバの結果に拡張できることに留意されたい。
【００６２】
原則として、ダウンロード時間は、図３におけるのと同じくらいＲＴＴに敏感である必要はまったくないことを、図６からの本開示の利益により正しく認識すべきである。
【００６３】
ＨＴＴＰ最適化、マルチホーミング、移動性、および、優先度
本イノベーションは、例えば、部分的にダウンロードされたイメージがもはや目に見えないように、ウェブページがスクロールされたときに、ＨＴＴＰスタックにおけるリクエストおよび接続の最適な構築ならびにスケジューリングの問題に対処し、ページロード時間を改善させ、オブジェクトの優先度における変更に対してより良い応答性も提供する。
【００６４】
本イノベーションは、ＨＴＴＰに対する、アプリケーションレイヤにおけるマルチホーミングおよび移動性に対するソリューションも考える。マルチホーミングは、特に、インターフェースの利用可能な帯域幅が、同程度の大きさである（これは、ＷＬＡＮがバックホール制限されているために、そうであることが多い）ケースにおいて、ダウンロード時間を改善する、例えば、ＷＷＡＮおよびＷＬＡＮのインターフェースのような、複数のインターフェースの同時使用を提供する。移動性は、デバイスが動くにつれて、接続の切り替えを提供する。組み合わせて、これらは、よりスムーズな移動性を提供する。サーバまたはネットワークのサポートをそれぞれ要求する、マルチパス伝送制御プロトコル（ＭＰＴＣＰ）またはモバイルＩＰのような、トランスポートレイヤあるいはネットワークレイヤのソリューションとは対照的に、サーバまたはネットワークのサポートなしに、このように移動性を提供することができる。
【００６５】
優先度における変更に対する応答性を改善するためと、マルチホーミングおよび移動性のサポートを改善するために、複数の部分的なリクエストの使用とともに、マルチホーミングおよび移動性のサポートに対してここで説明する技術は、新規であると信じられている。各インターフェースに対して別々のドメインネームサービス（ＤＮＳ）キャッシュを維持する技術もまた、新規であると信じられている。
【００６６】
最後に、オペレーティングシステムおよびウェブブラウザのサポートはないが、ネットワークプロキシと、静的に定義されたルートと、プロキシ自動設定（ＰＡＣ）スクリプトとを使用する、ここで説明した技術のうちのいくつかを実現するための新規の技術も、我々は説明する。
【００６７】
一般的な問題を、次のように説明することができる。
【００６８】
１組の統一資源ロケータ（ＵＲＬ）の形での１組の要求されるリソースによって、アプリケーション（例えば、ウェブブラウザ）により、ＨＴＴＰスタックが提供される。これらは、１度に提供されてもよく、または、時間の期間にわたって提供されてもよい。ＨＴＴＰスタックは、これらのリソースに対するリクエストをいつどのように発行するかという観点からなされるいくつかの決定を有している。特に、次のようなものがある。
【００６９】
複数のリソースが同じサーバにおいて利用可能である場合に、これらのリクエストを単一のＴＣＰ接続上でパイプライン化してもよい。
【００７０】
これが行われる場合には、リクエストの順序が決定される必要がある。
【００７１】
パイプライン化に対するサポートは、普遍的でも一貫したものでもないので、未処理のリクエストの数を制限するか、あるいは、パイプライン化に対するサーバサポートをどうにかして検出することが望ましいことがある。
【００７２】
サーバは、リクエストの順序付けおよび未処理のリクエストの数に対して異なる基準があるケースでは、順序通りでないレスポンスに対するＱＣ ＨＴＴＰ拡張機能をサポートしてもよい。
【００７３】
どの時点においても開かれているべきであるパラレルなＴＣＰ接続の数に限度があることがあり、これは、異なるサーバへの接続の確立に対する順序を選ぶ必要性を結果として生じさせる。
【００７４】
それゆえ、基本的な問題は、リンク利用が最大化されるこのような方法で、ＴＣＰ接続とこれらの接続上でのＨＴＴＰリクエストの双方をスケジュールすることである。これを問題１と呼ぶ。
【００７５】
ここでは、あるサーバにおいて利用可能なリソースの観点から、問題を説明することに留意されたい。これらのサーバは、コンテンツをホスト管理するオリジナルのウェブサーバ（オリジンサーバ）、または、クライアントとオリジナルサーバとの間のパス上の（透過型でない）プロキシサーバであってもよい。プロキシサーバは、（ＣＤＮプロキシのケースでは）特定のリソースに特有であってもよく、または、（構成または学習されているローカルプロキシのケースでは）任意のリソースに対して適用可能であってもよい。ここで説明する問題およびアルゴリズムは、リソースを取り出すためにクライアントがアクセスする“サーバ”の種類に関係ない：我々は、何らかのオプション的なサーバ能力が、何らかの種類のサーバ上に存在することがあると仮定する。
【００７６】
この問題に対する多数の拡張を、次のように実現することができる。
【００７７】
要求されるリソースに関して何らかの種類の優先度順序付けがあることは、一般的である。例えば、ウェブサーバに対して、画像、広告、および、ビデオの前に、かつ、トラッカーまたは他の補助的な機能を呼び出す前に、レイアウト、スタイル、スクリプト、および、テキストのリソースを受信することが一般的に望ましい。これにより、すべてのリソースをダウンロードする前に、ページのレンダリングを開始することが可能になる。そのため、拡張される問題は、問題１に、リソースに関する優先度順序付けという追加の情報と、その順序でのまたはその順序に近いリソース配信という追加の目標とをプラスしたものである。これを問題２と呼ぶ。
【００７８】
別の可能性は、すべてのリソースが完全に受信される前に、リソースの優先度順序付けが変更されるかもしれないということである（ダウンロードプロセスの間に、要求されているリストに新しいリソースを追加できる可能性を、問題１が含んでいたことも思い出してほしい）。例えば、ウェブページが完全にダウンロードされる前にユーザがウェブページをスクロールした場合に、これが生じ、そのため、リソースの順序付けは、目に見えるリソースを優先させるように変更する。このケースでは、追加の目標は、この変更または優先度を尊重し、利用可能なリソースが、確実に、変更後の最高の優先度のリソースに依然として専用であることである。これを問題３と呼ぶ。
【００７９】
別のケースは、クライアントが、複数のインターフェースに対するアクセスを有し、それゆえ、リソースをホスト管理するサーバへの複数のパスを有するというものである。ここでは、ＣＤＮの一般的な動作−既存のシステムではサポートされていないと信じられている何かに起因して、ドメインネームのＤＮＳ解決がインターフェースごとに変化すると考えることが重要であるべきである。このケースでは、複数のインターフェースのすべてにおいて利用可能な帯域幅を利用するという追加の目的により、問題が拡張される。これを問題４と呼ぶ。
【００８０】
最後に、１組の利用可能なインターフェースが変更する可能性もある。このケースでは、利用可能な帯域幅は、最高の優先度のリソースに専用であるべきであるという原則を維持して、最小のデータ損失により、変更を効率的に取り扱う必要がある。これを問題５と呼ぶ。
【００８１】
要約すると、問題１は、１組のＵＲＬに対するパイプライン化およびリクエストのスケジューリングの最適な使用に関係する。目的は、帯域幅使用を最適化し、それにより、ページダウンロード時間を減少させることである。
【００８２】
問題２は、ＵＲＬに対する優先度順序付けと、その優先度を尊重するという目標とを追加する。目的は、ウェブページのプログレッシブなレンダリングを可能にし、それにより、知覚されているページのダウンロードスピードを改善することである。
【００８３】
問題３は、優先度の変更を可能にする。目的は、高い優先度のオブジェクトに、帯域幅を確実にすばやく再割り当てし、それにより、ユーザの注目の変更（リンクのクリック、タブの変更、スクロール等）に対する応答性を改善することである。
【００８４】
問題４は、複数のインターフェースの効率的な使用を考慮に入れ、それにより、マルチホームのホストに対するリンクアグリゲーションを通して、ページダウンロード時間を改善することを目的としている。
【００８５】
問題５は、利用可能なインターフェースにおける変更を考慮に入れ、それにより、移動性をサポートすることを目的としている。
【００８６】
ＨＴＴＰプロトコルに基づくこれらの問題に対するソリューションは、ここでは、トランスポートレイヤの代わりに、ＨＴＴＰアプリケーションレイヤに焦点を当てている。
【００８７】
既存のソリューション：既存のウェブブラウザは、問題１と、ある程度は、問題２とを解決しようと試みている。しかしながら、現在の構成は、いくつかの欠陥を有している。第１に、要求されるリソース（ＵＲＬ）は、ページがダウンロードされるにつれて、プログレッシブに識別され、これは、クライアントにより既に知られている将来要求されるリソースについての情報を考慮することなく、接続の開閉について決定がなされることを意味する。
【００８８】
第２に、既存のブラウザは、一般的に、パラレルな接続の数において任意の制限を有している。大多数のパラレルな接続が利点を提供することは期待されない。一般的な経験則は、６個のパラレルな接続を上回る収穫逓減があるように思われる。しかしながら、ＷＷＡＮネットワークは、大きなネットワーク側ダウンリンクバッファにより構成されていることが多いことに留意すべきである。これは、リンクがフルに利用されているときに、高いＲＴＴに寄与することがある。それゆえ、パラレルな接続に対するＴＣＰ Ｓｌｏｗ Ｓｔａｒｔは、別の接続が既にリンクを利用している場合には、極めてスローであるかもしれない。
【００８９】
第３に、既存のブラウザは、パイプライン化を常に善用しているわけではない。これは、パイプライン化が、ＨＴＴＰプロキシにおいて一貫してサポートされていないためである。また、プロキシによるパイプライン化の使用は、送られることになる次のオブジェクトが、プロキシにおいてまだ利用可能でないために、ＴＣＰ接続がアイドルになる“ブロッキング”問題を引き起こすことがある。同じ接続上でリクエストされている別のオブジェクトが、プロキシにおいて利用可能である場合には、その代わりに、“順序通りでないレスポンス”としてそれを送ることが望ましいだろう。
【００９０】
Ｇｏｏｇｌｅにおいて最近発表されたＳＰＤＹプロジェクト（http://dev.chromium.org/spdy）は、ＴＣＰとＨＴＴＰの間に薄い多重化レイヤを挿入することにより、問題１および問題２を解決することを目的としている。これにより、単一のＴＣＰ接続を通して、割り当てられた優先度で、複数のＨＴＴＰトランザクションをパラレルに行うことが可能になる。作成者は、問題３を将来的な作業として識別している。ＳＰＤＹプロジェクトは、ＨＴＴＰヘッダ圧縮も、重要なコンポーネントとして識別している。ＷＷＡＮを特に述べていないが、ＨＴＴＰリクエストの圧縮は、特に、ＷＷＡＮネットワークに対して価値があることがある。
【００９１】
本開示は、標準的なＨＴＴＰ１．１に基づく問題１〜５にプログレッシブに対処する例示的なアプローチを解析する。加えて、性能をさらに改善することができる、何らかの、最小の、最適なサーバ拡張を説明する。
【００９２】
問題１：基本接続およびリクエストのスケジューリング：本セクションの基本的な考えは、リソースの識別と、ＴＣＰ接続の確立と、実際のリクエストのスケジューリングとを別々に扱うことである。第１に、要求されるリソースは識別されており、したがって、接触が必要なサーバの完全な組は知られているという仮定がなされる。第２に、ＴＣＰ接続がこれらのサーバに対して確立されるが、一度にすべてである必要はなく、サーバ当たり１つの接続である必要もない。第３に、リクエストは、確立されている接続にマッピングされる。
【００９３】
接続を開くことを決定すべき２つの原則がある。
【００９４】
第１に、各サーバに対する接続の数を最小化し、その結果、パイプライン化を利用する。これは、新しい接続が確立される（ＳＹＮ／ＡＣＫおよびスロースタート）たびに、高い代償が払われるためである。他のアクティブな接続が、大幅なキューイング遅延と、したがって、大きなＲＴＴとがあることを意味する場合に、これは、特に当てはまる。
【００９５】
第２に、パケットが損失したまたは遅れたときに、全体的な輻輳レスポンスを減少させるために、複数のパラレルな接続を利用する。‘ｎ’個のＴＣＰ接続がある場合に、単一の損失に対するレスポンスは、組み合わされた輻輳ウィンドウを１／２ｎだけ減少させるためのものである。
【００９６】
これらの２つの目的が明らかに対立していると、このトレードオフを制御するパラメータが導入される：Ｐmaxを、パラレルなＴＣＰ接続の最大数とし、Ｐminを、パラレルなＴＣＰ接続の最小数におけるターゲットとする。目的は、Ｐminを前提として、サーバ当たり１個の接続を確立することである。
【００９７】
ｎ個のＵＲＬの組Ｕが与えられると、Ｕ＝｛Ｕ0，．．．，Ｕn-1｝であり、ｍ個の一意的なサーバの組Ｓ（Ｓ＝｛Ｓ0，．．．，Ｓm-1｝）をそこから識別でき、ここで、ｍ≦ｎである。既存のウェブサーバに対する即座に有用な拡張は、ページに対して可能な限り多くの要求されるＵＲＬを、可能な限りすばやく識別するためのものであることに留意されたい。現在、このプロセスは、関係し合う必要がないダウンロードおよびレンダリングプロセスと関係し合っている。
【００９８】
複数の完全修飾ドメインネーム（ＦＱＤＮ）は、同じＩＰアドレスにマッピングしてもよいので、サーバＳjは、ＦＱＤＮではなく、ＩＰアドレスによって識別される。（単一のＦＱＤＮが複数のアドレスにマッピングする可能性を、以下でさらに説明する。）ｓ（ｉ）を、ＵＲＬ Ｕiに対して要求されるサーバのインデックスとし（すなわち、Ｕiは、Ｓs(i)から取得することができる）、Ｕ（ｊ）を、サーバＳjから取得することができるＵＲＬの組とする。
【００９９】
接続を確立し、リクエストを接続に割り振るためのプロセスが提供されている。このプロセスでは、リクエスト機会は、新しいリクエストを発行するための機会である。これがどのように定義されるかは、リクエスト／接続の整合に事前に取り組むことと、接続がアイドルになるのを可能にすることとの間のトレードオフである。その理由は、すべてのリクエストは、新しいリクエストが発行される前に完了するからである。いくつかの例を以下に示す。
【０１００】
アルゴリズム１：
【数１】
【０１０１】
このプロセスの動作は、リクエスト機会がどのように定義されるかに依存する。２つの両極端は、次のように定義される。
【０１０２】
グリーディリクエスト機会：サーバに対する接続がオープンであるときにはいつでも、これが起こる。
【０１０３】
レイジー（ｌａｚｙ）リクエスト機会：レスポンスが接続上で完全に受信されたときにはいつでも、これが起こる。
【０１０４】
グリーディリクエスト機会のケースでは、接続の最大数Ｐmaxを前提として、すべてのリクエストが即座に発行される。Ｐminを尊重するために、リクエストは、同じサーバへの複数の接続にわたって分配されることもある。しかしながら、いったん、すべてのリクエストが発行されると、変更を行う機会はない。１つの接続上でのリクエストは、別の接続上でのリクエストよりも、完了するのにより長い時間がかかるので、Ｐminの接続よりも少ないということが起こるかもしれない。
【０１０５】
レイジーリクエスト機会のケースでは、プロセス全体を通してＰminが尊重される。しかしながら、１つのレスポンスの終了と、次のレスポンスの開始との間の時間の間、各接続はアイドルのままであり、この時間は、１つのラウンドトリップタイムにサーバレスポンス時間をプラスしたものを測定する。これは、パイプライン化をサポートしないＨＴＴＰ１．１クライアントに対する標準的な振る舞いである。
【０１０６】
理想的には、リクエスト機会に対する定義は、２つの両極端の間のどこかにあるだろう。例えば、レスポンスを受信するための残り時間が、１つのラウンドトリップタイムにサーバ処理時間をプラスしたものであると推定されたときに、リクエスト機会が、起こることがある。しかしながら、サーバ処理時間が知られておらず、ＲＴＴのみが推定されていると、いずれにしても、この時間は、以前のレスポンスに対する総受信時間よりも長いことがある。以下の説明では、“ジャストインタイム”（Ｊｉｔ）リクエスト機会は、リンクがアイドルになるのを避けるのに十分な時間において、しかし、そうでなければ、可能な限り遅く、リクエストが発行される、最適化されたバージョンを意味する。
【０１０７】
パイプライン化のサーバサポート：プロキシサーバは、パイプライン化に対する一貫したサポートを提供しないと噂されている。（プロキシを含む）ＨＴＴＰ１．１サーバは、パイプライン化リクエストを処理するか、または、無視するかのいずれかである（すなわち、失敗しない）ように要求される。したがって、１つより多いリクエストが発行された場合に、最初のレスポンスを完全に受信した後に、（第２のレスポンスが後に続くか否かによって）サーバは、パイプライン化をサポートするか否かを決定することが可能であるはずである。サーバがパイプライン化をサポートしないケースでは、そのサーバからリクエストされたＵＲＬは、最初のものを除いて、そのサーバに対するｕi組に返されるべきであり、言及したパイプライン化サポートはない。そのサーバへの後続する接続は、最大で１つのリクエストを受信すべきである。
【０１０８】
順序通りでないレスポンス：標準的なサーバは、リクエストを受信した順序で、パイプライン化されたリクエストに対するレスポンスを返す。サーバが異なる順序でリクエストを返すことを可能にするＨＴＴＰ拡張機能が、定義されている。特に、プロキシサーバのケースでは、オブジェクトをリクエストしたのとは異なる順序で、サーバにおいてオブジェクトが利用可能になることがあるので、これは価値がある。それゆえ、順序通りのオブジェクト配信は、ヘッドオブラインブロッキング問題を引き起こすかもしれない。しかし、この特徴を利用するためには、複数のリクエストが接続上でパイプライン化される必要がある：より多くのリクエストがキューに入れられている場合に、ヘッドオブラインブロッキングの可能性は減少するが、より多くの取り組みが行われている：結果として、この特徴が存在するときに、この特徴が存在しないときよりも、接続上でより多くのリクエストを発行することが望ましいことがある。
【０１０９】
順序通りでない拡張は、リクエストに追加された“トランザクションＩＤ”ヘッダフィールドからなる。順序通りでないレスポンスは、対応するリクエストのトランザクションＩＤ値をエコーとして返す。レスポンスにおけるトランザクションＩＤフィールドの不在は、サーバが、順序通りでないレスポンスをサポートしないことを示す。
【０１１０】
ＨＴＴＰヘッダ圧縮：ＨＴＴＰは、エンティティボディのｇｚｉｐ圧縮をサポートするが、リクエストのｇｚｉｐ圧縮はサポートしない。Ｇｏｏｇｌｅ ＳＰＤＹプロジェクトは、かなりの利点を提供するとして、ＨＴＴＰヘッダ圧縮を識別しており、ＷＷＡＮネットワークに対しては、リクエスト圧縮が特に有用であることが期待されてもよい。
【０１１１】
ヘッダ圧縮は、下位互換性のあるＨＴＴＰ拡張機能として次のように容易に定義できる。
【０１１２】
ヘッダ圧縮をサポートしているクライアントは、既存のＣｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇヘッダ（例えば、Ｈｅａｄｅｒ−Ｅｎｃｏｄｉｎｇ：ｇｚｉｐ）に類似する、最初のリクエスト中の新しいオプション的なヘッダにより、これを示す。
【０１１３】
ヘッダ圧縮をサポートしているサーバは、新しいヘッダを認識し、圧縮されたヘッダを持つレスポンスを返す。
【０１１４】
ヘッダ圧縮の始まりは、新しいリクエストまたはレスポンスが期待されるストリーム中に現れる標準的なｇｚｉｐヘッダにより、示すことができる。
【０１１５】
接続上でのリクエストまたはレスポンスのシーケンスは、１つの連続的なストリームとして圧縮すべきである。（それぞれの終端の復帰改行を含む）リクエストまたはレスポンスの連結から、圧縮されていないストリームが形成される。各リクエストまたはレスポンスの終わりに、フラッシュポイント（flush point）があるにちがいないので、後続の情報を受信することなく、これをフルにデコードすることができる。
【０１１６】
圧縮が始まる前に送られた、圧縮されていないリクエストまたはレスポンスは、圧縮のための静的なディクショナリとして使用すべきである。
【０１１７】
サーバ識別リソース：Ｇｏｏｇｌｅ ＳＰＤＹは、これらの例において、クライアントがリクエストしていない、このリソースが要求されるだろうとサーバが気付いているリソースを、サーバがクライアントに返す可能性を識別する。クライアントがリクエストすることを望むことがあるリソースの提案を、サーバが提供する可能性もある。
【０１１８】
前者のオプションは、クライアントがリクエストをキャンセルする能力を要求するのに対し、後者は、その能力に対する必要性なく、同じ目的のほとんどを達成する。
【０１１９】
順序通りでないレスポンスがサポートされている場合に、提案したアプローチのシンプルな構成は、特別なトランザクションＩＤとリクエストＵＲＬを持つ、サーバ識別リソースに対するレスポンスヘッダを、サーバが送ることである。これは、クライアントが、そのキャッシュを調べて、オブジェクトをリクエストするか否かを決定することができるように、キャッシュ関連情報（データ、Ｅタグ、キャッシュ制御ディレクティブ）を含めることを可能にする。
【０１２０】
リクエストのキャンセル：先に説明した順序通りでない拡張がサポートされている場合には、トランザクションＩＤを持つリクエストを参照することにより、リクエストをキャンセルするための新しい方法を、自明に追加することができる。これは、より多くのリクエストをパイプライン中でキューアップすることを可能にする（そして、ヘッドオブラインブロッキングの可能性を減少させる）のに、有用であってもよい一方で、必要な場合に、この取り組みを逆にすることもできる。
【０１２１】
問題２：リクエストの優先順位付け：問題２は、ＵＲＬの組、Ｕが、優先度順序を有する追加の可能性を導入する。一般性を損なうことなく、リストＵ0，．．．，Ｕn-1は、最高の優先度が１番目である優先度順序であると仮定する。また、追加されるのは、より高い優先度のオブジェクトが、より低い優先度のオブジェクトの前に配信されるという目的である。
【０１２２】
この新しい目的は、利用可能な帯域幅使用を最大化するという本来の目的に次ぐものであることに留意されたい：すなわち、帯域幅使用を最大化するためにこれが必要である場合には、優先度順序通りでなくオブジェクトを配信することを許容できる（そうでなければ、厳密な優先度順序でリクエストを発行し、各リクエストの後で、別のリクエストが発行される前にそれが完了するのを待つことにより、要件が満たされるだろう）。
【０１２３】
優先順位付けをサポートするために、アルゴリズム１を次のように修正する：
アルゴリズム２
１）Ｕにおける順序付けは、そのサーバ上で利用可能な最高優先度のリソースの順序にサーバを置くことにより、Ｓにおける順序付けを誘発する。その後、各組ｕiも、明白な方法で順序付けされる
２）ステップ２（ａ）、２（ｂ）、および、４（ｃ）（ｉ）において、選ばれたｉの値が、このような最小値であること以外は、アルゴリズム１にしたがう。
【０１２４】
問題３：優先度における変更：Ｇｏｏｇｌｅ ＳＰＤＹプロトコルは、ＴＣＰとＨＴＴＰとの間に薄い多重化レイヤを提供し、これを使用して、複数のリクエスト／レスポンストランザクションを同じ接続上で多重化することにより、この要件に対処することを目的としている。既存の技術との相違は、次のように理解することができる。
【０１２５】
パイプライン化は、複数のリクエスト／レスポンストランザクションが、ＴＣＰ接続を共有することを可能にするが、レスポンスが、シーケンシャルにおよび順序通りに返されることを要求する。
【０１２６】
順序通りでないレスポンスによるパイプライン化（ワンショットウェブ）は、レスポンスが、異なる順序で返されることを可能にするが、レスポンスは、依然としてシーケンシャルである（各レスポンスは、次が開始する前に完了しなければならない）。
【０１２７】
パラレルなＴＣＰ接続は、レスポンスが、パラレルに送られる（ＩＰレイヤにおいて多重化される）ことを可能にするが、トランザクションは、独立して進む：１つのものの、他のものに対する優先順位付けを調整することはできない。
【０１２８】
このため、ＳＰＤＹプロトコルは、レスポンスのシーケンシャルな完了に対する要件なしに、パイプライン化の利益を得ることを目的している。
【０１２９】
第１に、アルゴリズム２において、レイジーリクエスト機会またはジャストインタイムリクエスト機会が使用される場合に、各ｕi組内のリクエストされていないリソースの優先度を再順序付けすることが、いかなるときにおいても常に可能であることに留意すべきである。このシンプルなアプローチは、実質的な利益を提供することができる（これをアルゴリズム２ａと呼ぶ）。
【０１３０】
ＨＴＴＰの部分的なリクエスト（すなわち、Ｒａｎｇｅヘッダを持つＨＴＴＰリクエスト）の使用に基づいて、より細かい粒度で優先度の変更を取り扱うための、代替的なスキームをここで説明する。
【０１３１】
第１に、Ｒを、バイトでの、最大リクエストサイズとする。サイズＲまたはより小さいサイズの要求されるリソースの断片に対して、リクエストが発行される。アルゴリズム２では、各ＵＲＬ、ｕiは、対（ＵＲＬ、Ｂｙｔｅ Ｒａｎｇｅ）により置換される。アプリケーションにより提供されるＵＲＬおよびＢｙｔｅ Ｒａｎｇｅ［０，Ｒ−１］により、これらの対が初期化される。
【０１３２】
その後、アルゴリズム３を形成するために、以下の手順が追加される。
【０１３３】
ＵＲＬに対する第１のレスポンスヘッダを受信次第、オブジェクトサイズＦを取得する。その後、Ｆ＞Ｒである場合に、同じＵＲＬとＢｙｔｅ Ｒａｎｇｅ［Ｒ，２Ｒ−１］，［２Ｒ，３Ｒ−１］，．．．，［ｒＲ，Ｆ−１］とを持つ、ｕi中のｒ：＝ｃｅｉｌ（Ｆ／Ｒ）−１の追加エントリを構築する。ｕiにおけるエントリの順序は、先のように、ＵＲＬの優先度順序付けに基づくべきであることに留意されたい。
【０１３４】
このスキームでは、優先度の変更が起こったときに、リクエストされたが、接続上で受信されていない未処理のデータの量は、最大Ｒであり、それゆえ、リソースが、より低い優先度のリソースに専用である期間が減少される。
【０１３５】
ジャストインタイム（ＪｉＴ）リクエスト機会を効率的にサポートするために、Ｒは、１つのラウンドトリップタイム中で送信することができるデータの量よりも大きいはずであるものと考えられる。測定されたラウンドトリップタイムおよびデータレートにしたがって、Ｒが変化すべきであってもよい。
【０１３６】
問題４：マルチホーミングに対するサポート：マルチホームのホストは、複数の接続されたインターフェースを有し、それゆえ、インターネットへの複数のルートを有するものである。マルチホームのホストのケースにおける目的は、ダウンロードスピードを改善するために、複数のインターフェースを同時に利用することである。
【０１３７】
第１に、ＨＴＴＰスタックが、利用可能なインターフェースの知識と、特定のインターフェースを使用するようにＴＣＰ接続に命令するための能力とを有していると仮定する。既存のホストオペレーティングシステム（ＯＳ）構成ではそうではないので、これを達成するために何らかの作業が要求される。このようなＯＳの改善に先立って、可能性ある代替実施形態は、別々のインターフェースを通して到達可能なＨＴＴＰプロキシサーバを提供するためと、異なるインターフェースを通して各サーバにパケットを向ける、これらのサーバに対する明示的なルートを、クライアントルーティングテーブル内で定義するためのものである。このように、プロキシサーバの選択は、使用されるだろうインターフェースを決定し、そのインターフェースに関係付けられているプロキシに接続を向けることにより、インターフェースに接続を向けることができる。
【０１３８】
所定のＵＲＬに対して使用されることになるプロキシを決定するＪａｖａＳｃｒｉｐｔ機能を、ユーザが特定することを可能にする、プロキシ自動設定スクリプトの使用により、多くの既存のウェブブラウザ構成において、プロキシサーバの選択を制御することができる。このアプローチにより、インターフェースにわたってリクエストを静的に分配することが可能になり、例えば、ある割合のリクエストは、１つのインターフェースに対するものであり、残りのものは、別のインターフェースに対するものである。
【０１３９】
リクエストのうちの１／Ｎをｐｒｏｘｙ＿ａに向け、残りのものをｐｒｏｘｙ＿ｂに向ける適切なスクリプトが、以下に示されている：
【数２】
【０１４０】
このスクリプトでは、ＵＲＬの長さがハッシュ関数として使用される。代替的なハッシュ関数を使用することもできる。
【０１４１】
特定のインターフェースにＴＣＰ接続を向けるＯＳベースの能力が与えられるとすると、ここではアルゴリズム４と呼ばれるシンプルなマルチホーミングアプローチは、アルゴリズム２にしたがうためのものであり、ラウンドロビン方法で、利用可能なインターフェースにわたってＴＣＰ接続を分配するためのものである。
【０１４２】
アルゴリズム５を得るために、アルゴリズム３に対して同じ拡張を行うことができる。アルゴリズム４と比較すると、利点は、大きなオブジェクトを複数のインターフェースにわたって分けてもよいことである。その理由は、オブジェクトに対する部分的なリクエストが、接続にわたって分配されるだろうからである。
【０１４３】
これらのケースでは、Ｐminを、少なくともインターフェースの数に設定することが望ましい。
【０１４４】
マルチホーミングおよびＤＮＳ：ＣＤＮの通常の動作に起因して、ＤＮＳ解決の結果は、ホストのインターネットへの接続のポイントに依存して、および、リクエストが最初に送られるＤＮＳサーバに依存して、異なってもよい。我々の知る限り、既存のホストＯＳは、これに対処していない。
【０１４５】
ＨＴＴＰおよびＣＤＮの特定のケースでは、異なる解決の結果の理由は、ＣＤＮが、接続のポイントに“近い”適切なプロキシを識別するためである。各インターフェースに対して正しいプロキシを使用することが極めて望ましい。
【０１４６】
問題５：移動性：問題４に対するソリューション（マルチホーミング）が与えられると、移動性に対するサポートは、転送の間にインターフェースがシャットダウンするケースと、新しいインターフェースが利用可能になるケースとを取り扱うという問題に減少する。
【０１４７】
移動性をサポートするアルゴリズム６を得るために、アルゴリズム４が次のように拡張される。
【０１４８】
インターフェースが停止したときに、そのインターフェースを使用しているオープンな接続を識別し、これらの接続上で発行されている未完了のリクエストのリストを構築する。これらのリソースを適切なｕi組に追加して戻し、プロセスを継続する。
【０１４９】
インターフェースが立ち上がったときに、次回接続を確立しなければならないときに、このインターフェースを選択に対して利用可能にする。
【０１５０】
双方のケースにおいて、インターフェースの数に基づいてＰminが設定されている場合に、Ｐminを修正することを考える。
【０１５１】
アルゴリズム７を得るために、アルゴリズム５に対して、類似する拡張を次のように行うことができる。
【０１５２】
インターフェースが停止したときに、そのインターフェースを使用しているオープンな接続を識別し、これらの接続上で発行されている未完了のリクエストのリストを構築する。これらのリクエストを適切なｕi組に追加して戻し、プロセスを継続する。Ｂｙｔｅ Ｒａｎｇｅ［ａ，ｂ］に対する進行中の何らかのリクエストに対して、受信した最後のバイトｃを識別し、Ｂｙｔｅ Ｒａｎｇｅ［ｃ＋１，ｂ］に対するリクエストを、適切なｕi組に追加する。
【０１５３】
インターフェースが立ち上がったときに、次回接続を確立しなければならないときに、このインターフェースを選択に対して利用可能にする。
【０１５４】
双方のケースにおいて、インターフェースの数に基づいてＰminが設定されている場合に、Ｐminを修正することを考える。
【０１５５】
図７、ダイヤグラム７００は、前述した７個のアルゴリズムの例示的な関係を示している。本開示の利益により、リソース識別７０２と、接続確立７０４と、リクエストスケジューリング７０６との分離の基本概念が、アルゴリズム１ ７０８において初めから適用され、アルゴリズム１ ７０８は、グリーディまたはＪＩＴのリクエスト動作７１０を用いることができることを正しく認識すべきである。アルゴリズム１ ７０８は、利用可能なオプション的なサーバ能力は何でも（例えば、パイプライン化７１２、順序通りでないレスポンス７１４、ヘッダ圧縮７１６、サーバ識別リソース７１８、および、ＨＴＴＰキャンセル能力７２０）最大限利用することができるが、これらがすべて利用可能でない場合にもなお改善を提供する。
【０１５６】
アルゴリズム２ ７２２は、グリーディまたはＪｉＴのリクエスト動作７２６に加えて、シンプルなリクエスト優先順位付け７２４を追加する。アルゴリズム２ ７２２に基づくアルゴリズム２ａ ７２８では、ジャストインタイムリクエスト機会７３２とともに使用するために、優先順位の付け直し７３０が提供されている。アルゴリズム２Ａ ７２８に基づくことができるアルゴリズム４ ７３４は、ラウンドロビンベースで、接続をインターフェースに割り振ることにより、マルチホーミング７３６を提供する。アルゴリズム４ ７３４に基づくアルゴリズム６ ７３８は、ラウンドロビンベースで、接続をインターフェースに割り振ることにより、このシンプルなモデルによってさえサポートすることができる移動性７４０を提供する。
【０１５７】
アルゴリズム３ ７４２は、リクエストの優先順位付けの付け直し７４６およびＪｉＴリクエスト動作７４８とともに、部分的なリクエスト７４４の使用によって、より細かい粒度での優先順位の付け直しを提供する。アルゴリズム５ ７５０においてマルチホーミング７５２に拡張されるときにも、および、アルゴリズム７ ７５４において移動性７５６に拡張されるときにも、このアプローチは利益を提供する。
【０１５８】
図８は、ここで説明する機能性のさまざまな態様を実現するために利用することができる別のシステム８００のブロックダイヤグラムである。１つの例では、システム８００は、移動端末８０２を含む。示されているように、移動端末８０２は、１つ以上のアンテナ８０８を介して、信号を、１つ以上の基地局８０４から受信することができ、１つ以上の基地局８０４に送信することができる。さらに、移動端末８０２は、アンテナ８０８から情報を受け取る受信機８１０を備えることができる。１つの例では、受信機８１０は、受け取った情報を復調する復調器８１２に動作可能に関係付けることができる。復調されたシンボルは、その後、プロセッサ８１４により解析することができる。プロセッサ８１４はメモリ８１６に結合することができ、メモリ８１６は、移動端末８０２に関連するデータおよび／またはプログラムコードを記憶することができる。さらに、移動端末８０２は、ここで説明する方法を実行するために、プロセッサ８１４を用いることができる。移動端末８０２は、アンテナ８０８を通して送信機８２０により送信するための信号を多重化することができる変調器８１８も備えることができる。
【０１５９】
移動端末８０２は、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを基地局８０４に送信する。メモリ８１６において、および、プロセッサ８１４により実行されると、ＨＴＴＰ最適化コンポーネント８２２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる。
【０１６０】
図９は、ここで説明する機能性のさまざまな態様を実現するために利用することができるシステム９００のブロックダイヤグラムである。１つの例では、システム９００は、基地局またはノードＢ９０２を含む。示されているように、ノードＢ９０２は、信号を、１つ以上の受信（Ｒｘ）アンテナ９０６を介して、１つ以上のＵＥ９０４から受信し、１つ以上の送信（Ｔｘ）アンテナ９０８を介して、１つ以上のＵＥ９０４に送信することができる。さらに、ノードＢ９０２は、受信アンテナ９０６から情報を受け取る受信機９１０を備えることができる。１つの例では、受信機９１０は、受け取った情報を復調する復調器９１２に動作可能に関係付けることができる。復調されたシンボルは、その後、プロセッサ９１４により解析することができる。プロセッサ９１４はメモリ９１６に結合することができ、メモリ９１６は、コードクラスタ、アクセス端末割り当て、メモリ９１６に関連するルックアップテーブル、一意的なスクランブルシーケンスに関連する情報、および／または、他の適切なタイプの情報を記憶することができる。１つの例では、ノードＢ９０２は、送信アンテナ９０８を通して送信機９２０により送信するための信号を多重化することができる変調器９１８も備えることができる。
【０１６１】
メモリ９１６において、および、プロセッサ９１４により実行されると、ＨＴＴＰ最適化サポートコンポーネント９２２は、ＨＴＴＰ通信を最適化するために、ＵＥ９０４によってリクエストされることがある能力（例えば、パイプライン化、順序通りでないレスポンス、ヘッダ圧縮、サーバ識別リソース、および、ＨＴＴＰキャンセル能力）を提供する。
【０１６２】
図１０を参照すると、示されているのは、パケットデータ通信のためのシステム１０００である。例えば、システム１０００は、ユーザ機器（ＵＥ）内に少なくとも部分的に存在することができる。機能ブロックを含むものとして、システム１０００が表され、機能ブロックは、コンピューティングプラットフォーム、プロセッサ、ソフトウェア、または、それらの組み合わせ（例えば、ファームウェア）により実現される機能を表す機能ブロックとすることができることを正しく認識すべきである。システム１０００は、共に動作することができる電気コンポーネントの論理グルーピング１００２を含む。例えば、論理グルーピング１００２は、パケットデータ通信のための多数のパラレルな接続を確立する電気コンポーネント１００４を含むことができる。さらに、論理グルーピング１００２は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化リクエストを送信する電気コンポーネント１００６を含むことができる。加えて、論理グルーピング１００２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる電気コンポーネント１００８を含むことができる。さらに、システム１０００は、電気コンポーネント１００４〜１００８に関係付けられている機能を実行するための命令を保持するメモリ１０２０を含むことができる。メモリ１０２０の外部にあるとして示されているが、電気コンポーネント１００４〜１００８のうちの１つ以上は、メモリ１０２０内に存在することができることを理解すべきである。
【０１６３】
図１１において、パケットデータ通信のための装置１１０２が示されている。装置１１０２は、パケットデータ通信のための多数のパラレルな接続を確立する手段１１０４を備える。装置１１０２は、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、多数のパラレルな接続を介して、複数のパイプライン化リクエストを送信する手段１１０６を備える。装置１１０２は、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、パラレルな接続を介するパイプライン化リクエストの数とを動的に変化させる手段１１０８を備える。
【０１６４】
ここで開示した態様に関連して説明した、さまざまな例示的な論理ブロック、モジュール、回路およびアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェア、または、双方を組み合わせたものとして実現してもよいことを、当業者はさらに正しく認識するであろう。ハードウェアおよびソフトウェアのこの交換可能性を明確に示すために、さまざまな例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、一般的にこれらの機能性に関して上述した。このような機能性がハードウェアまたはソフトウェアとして実現されるか否かは、特定の応用、および、システム全体に課せられた設計の制約に依存する。当業者は、それぞれの特定の応用に対して方法を変化させて、説明した機能性を実現してもよいが、このようなインプリメンテーション決定は、本開示の範囲からの逸脱を生じさせるものとして解釈すべきではない。
【０１６５】
本明細書で使用するような、用語“コンポーネント”、“モジュール”、“システム”、および、これらに類するものは、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または、実行中のソフトウェアのいずれかである、コンピュータ関連エンティティのことを指すことを意図している。例えば、コンポーネントは、これらに限定されないが、プロセッサ上で動作しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／または、コンピュータであってもよい。例として、サーバ上で動作しているアプリケーションとサーバの双方をコンポーネントとすることができる。１つ以上のコンポーネントが、プロセスおよび／または実行のスレッド内に存在することがあり、コンポーネントは、１つのコンピュータ上に局所化されていてもよく、および／または、２つ以上のコンピュータ間に分散されていてもよい。
【０１６６】
ここでは、例として、事例として、あるいは例示として機能することを意味するように、“例示的な”という単語を使用する。“例示的な”ものとして、ここで説明したいずれの態様または設計は、他の態様または設計と比較して、必ずしも好ましいものとして、または、利益のあるものとして、解釈すべきではない。
【０１６７】
多数のコンポーネント、モジュール、および、これらに類するものを含んでもよいシステムの観点から、さまざまな態様が提示されるだろう。さまざまなシステムが、追加のコンポーネント、モジュール等を含んでもよいこと、および／または、図面に関連して論じたコンポーネント、モジュール等のすべてを含まなくてもよいことを理解し、正しく認識すべきである。これらのアプローチの組み合わせもまた使用してもよい。ここで開示したさまざまな態様は、タッチスクリーンディスプレイ技術を、ならびに／あるいは、マウスおよびキーボードタイプのインターフェースを、利用するデバイスを含む電気デバイス上で実行することができる。このようなデバイスの例は、コンピュータ（デスクトップおよびモバイル）、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ならびに、ワイヤードおよびワイヤレス双方の他の電子デバイスを含む。
【０１６８】
加えて、ここで開示した態様に関連して説明した、さまざまな例示的な論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここで説明した機能を実行するように設計されているこれらの任意の組み合わせで、実現または実行されてもよい。汎用プロセッサは、マイクロプロセッサであってもよいが、代替的に、プロセッサは、何らかの従来のプロセッサ、制御装置、マイクロ制御装置、または、状態機械であってもよい。プロセッサはまた、コンピューティングデバイスの組み合わせとして、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアを伴った１つ以上のマイクロプロセッサ、あるいは、このようなコンフィギュレーションの他の何らかのものとして実現されてもよい。
【０１６９】
さらに、開示した態様を実現するようにコンピュータを制御するために、標準のプログラミングおよび／またはエンジニアリング技法を使用して、ソフトウェア、ファームウェア、ハードウェア、または、これらの何らかの組み合わせを生成させることにより、方法、装置、または、製造物として、１つ以上のバージョンを実現してもよい。ここで使用するような用語“製造物”（または、代替的に、“コンピュータプログラムプロダクト”）は、何らかのコンピュータ読取可能デバイス、キャリア、または、媒体から、アクセス可能なコンピュータプログラムを含むことを意図している。例えば、コンピュータ読取可能媒体は、これらに限定されないが、磁気記憶デバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）や、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）．．．）や、スマートカードや、フラッシュメモリデバイス（例えば、カード、スティック）を含むことがある。さらに、電子メールを送受信する際に、あるいは、インターネットまたはローカルエリアネットワーク（ＬＡＮ）のようなネットワークにアクセスする際に使用するもののような、コンピュータ読取可能な電子データを伝えるために、搬送波を用いることができることを正しく認識すべきである。当然、当業者は、開示した態様の範囲から逸脱することなく、このコンフィギュレーションに対して多くの改良がなされてもよいことを認識するだろう。
【０１７０】
ここで開示した態様に関連して説明した方法またはアルゴリズムのステップは、直接、ハードウェアで、プロセッサにより実行されるソフトウェアモジュールで、あるいは、２つの組み合わせで、具現化してもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーブバルディスク、ＣＤ−ＲＯＭ、あるいは、技術的に知られている他の何らかの形態の記憶媒体に存在していてもよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替実施形態では、記憶媒体は、プロセッサと一体化されてもよい。プロセッサおよび記憶媒体は、ＡＳＩＣに存在してもよい。ＡＳＩＣは、ユーザ端末に存在してもよい。代替実施形態では、プロセッサおよび記憶媒体は、ユーザ端末中のディスクリートコンポーネントとして存在してもよい。
【０１７１】
開示した態様の先の説明は、当業者が本開示を作り、または、使用できるように提供されている。これらの態様に対するさまざまな改良は、当業者に容易に明らかになるであろう。そして、ここで定義されている一般的な原理は、本開示の精神または範囲を逸脱することなく、他の実施形態に適用されてもよい。したがって、本開示は、ここに示した実施形態に限定されることを意図しているものではないが、ここに開示した原理および新規の特徴と矛盾しない最も広い範囲に一致させるべきである。
【０１７２】
先に説明した例示的なシステムを考慮して、開示した主題事項にしたがって実現されてもよい方法を、いくつかのフローダイヤグラムを参照して説明してきた。説明を簡略化する目的のために、一連のブロックとして、方法を示し、説明してきたが、いくつかのブロックは、ここで示し、説明したものとは異なる順序で、および／または、他のブロックと同時に、起こることがあるので、請求されている主題事項は、ブロックの順序によって限定されないことを理解し、正しく認識すべきである。さらに、ここで説明した方法を実現するのに、示されているブロックがすべて要求されるわけではない。さらに、ここで開示した方法は、このような方法をコンピュータに伝送および転送するのを促進するために、製造物上に記憶することができることをさらに正しく認識すべきである。ここで使用するような製造物という用語は、何らかのコンピュータ読取可能デバイス、キャリア、または、媒体からアクセス可能なコンピュータプログラムを含むように意図されている。
【０１７３】
ここでの参照により組み込まれていると言われた、何らかの特許、公報、または、他の開示資料は、組み込まれている資料が、本開示で述べた、既存の定義、ステートメント、または、他の開示資料と対立しない限りのみ、全体または一部として、ここに組み込まれることを正しく認識すべきである。そのようなものとして、および、必要である限り、ここで明示的に述べたような開示は、参照によりここに組み込まれている、対立するあらゆる資料に取って代わる。参照によりここに組み込まれていると言われた、何らかの資料あるいはその一部は、既存の定義、ステートメント、または、ここで述べた他の開示資料と対立するもの以外は、その組み込まれている資料と既存の開示資料との間で何ら対立が生じない限りのみ、組み込まれるだろう。
【特許請求の範囲】
【請求項１】
パケットデータ通信のための方法において、
前記方法は、
パケットデータ通信のための多数のパラレルな接続を確立することと、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信することと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させることとを含む方法。
【請求項２】
前記複数のパイプライン化されたリクエストを送信することは、ワイヤレスワイドエリアネットワークのノードにアクセスすることをさらに含む請求項１記載の方法。
【請求項３】
前記パラレルな接続の数と、前記パイプライン化されたリクエストの数とを動的に変化させることは、
帯域幅とラウンドトリップタイムとを推定することと、
リクエストされたが受信されていないパケットデータが、推定した帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、前記パイプライン化されたリクエストの送信を継続することとをさらに含む請求項１記載の方法。
【請求項４】
前記パケットデータ通信のための多数のパラレルな接続を確立することは、
前記複数のサーバのうちのそれぞれに対する接続の数を最小化することと、
リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、前記多数のパラレルな接続を使用することと、
前記接続の数を最小化するという目的と、前記全体的な輻輳を減少させるために、前記多数のパラレルな接続を使用するという目的との対立を最適化するために、前記パラレルな接続の数と前記パイプライン化されたリクエストの数とを動的に変化させることとをさらに含む請求項１記載の方法。
【請求項５】
前記パケットデータ部分をレンダリングするためのプログレッシブな順序付けを決定することと、
前記プログレッシブな順序付けに関連して、前記複数のパイプライン化されたリクエストの順序に優先順位を付けることとをさらに含む請求項１記載の方法。
【請求項６】
フルなリンク利用を維持することは、グリーディリクエスト機会を利用することをさらに含む請求項１記載の方法。
【請求項７】
フルなリンク利用を維持することは、ジャストインタイムリクエスト機会を利用することをさらに含む請求項１記載の方法。
【請求項８】
前記複数のパイプライン化されたリクエストを送信することは、ヘッダ圧縮をリクエストすることを含む請求項１記載の方法。
【請求項９】
リクエストされなかった、サーバにより識別されたリソースを受信することをさらに含む請求項１記載の方法。
【請求項１０】
前記サーバ識別リソースが必要でないことを決定することと、
前記サーバ識別リソースをキャンセルすることとをさらに含む請求項９記載の方法。
【請求項１１】
ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストを送信することをさらに含む、前記複数のパイプライン化されたリクエストを送信することをさらに含む請求項１記載の方法。
【請求項１２】
前記複数のパイプライン化されたリクエストを送信することは、
インターフェースが利用可能でなくなったことを、または、利用可能になったことを検出することと、
前記インターフェースを使用しているオープンな接続を識別することと、
前記オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築することと、
前記識別したオープンな接続と、前記インターフェースと、前記未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、前記パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを、動的に変化させることとをさらに含む請求項１記載の方法。
【請求項１３】
各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持することをさらに含む請求項１記載の方法。
【請求項１４】
パケットデータ通信のための少なくとも１つのプロセッサにおいて、
前記少なくとも１つのプロセッサは、
パケットデータ通信のための多数のパラレルな接続を確立する第１のモジュールと、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する第２のモジュールと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる第３のモジュールとを具備する少なくとも１つのプロセッサ。
【請求項１５】
パケットデータ通信のためのコンピュータプログラムプロダクトにおいて、
前記コンピュータプログラムプロダクトは、コードの組を記憶する一時的でないコンピュータ読取可能媒体を具備し、
前記コードの組は、
コンピュータに、パケットデータ通信のための多数のパラレルな接続を確立させるための第１の組のコードと、
前記コンピュータに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信させるための第２の組のコードと、
前記コンピュータに、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させるための第３の組のコードとを含むコンピュータプログラムプロダクト。
【請求項１６】
パケットデータ通信のための装置において、
前記装置は、
パケットデータ通信のための多数のパラレルな接続を確立する手段と、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する手段と、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる手段とを具備する装置。
【請求項１７】
パケットデータ通信のための装置において、
前記装置は、
パケットデータ通信のための多数のパラレルな接続を確立するトランシーバであって、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信するためのトランシーバと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させるコンピューティングプラットフォームとを具備する装置。
【請求項１８】
前記トランシーバは、さらに、ワイヤレスワイドエリアネットワークのノードにアクセスすることにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項１９】
前記コンピューティングプラットフォームは、さらに、
帯域幅とラウンドトリップタイムとを推定することと、
リクエストされたが受信されていないパケットデータが、推定した帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、前記パイプライン化されたリクエストの送信を継続することとにより、
前記パラレルな接続の数と、前記パイプライン化されたリクエストの数とを動的に変化させるためのものである請求項１７記載の装置。
【請求項２０】
前記トランシーバを介する前記コンピューティングプラットフォームは、さらに、
前記複数のサーバのうちのそれぞれに対する接続の数を最小化することと、
リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、前記多数のパラレルな接続を使用することと、
前記接続の数を最小化するという目的と、前記全体的な輻輳を減少させるために、前記多数のパラレルな接続を使用するという目的との対立を最適化するために、前記パラレルな接続の数と前記パイプライン化されたリクエストの数とを動的に変化させることとにより、
前記パケットデータ通信のための多数のパラレルな接続を確立するためのものである請求項１７記載の装置。
【請求項２１】
前記コンピューティングプラットフォームは、さらに、前記パケットデータ部分をレンダリングするためのプログレッシブな順序付けを決定するためと、
前記プログレッシブな順序付けに関連して、前記複数のパイプライン化されたリクエストの順序に優先順位を付けるためのものである請求項１７記載の装置。
【請求項２２】
前記コンピューティングプラットフォームは、さらに、グリーディリクエスト機会を利用することにより、フルなリンク利用を維持するためのものである請求項１７記載の装置。
【請求項２３】
前記コンピューティングプラットフォームは、さらに、ジャストインタイムリクエスト機会を利用することにより、フルなリンク利用を維持するためのものである請求項１７記載の装置。
【請求項２４】
前記トランシーバは、さらに、ヘッダ圧縮をリクエストすることにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項２５】
前記トランシーバは、さらに、リクエストされなかった、サーバにより識別されたリソースを受信するためのものである請求項１７記載の装置。
【請求項２６】
前記コンピューティングプラットフォームは、さらに、
前記サーバ識別リソースが必要でないことを決定するためと、
前記サーバ識別リソースをキャンセルするためのものである請求項２５記載の装置。
【請求項２７】
前記トランシーバは、さらに、ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストを送信することにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項２８】
前記コンピューティングプラットフォームは、さらに、
インターフェースが利用可能でなくなったことを、または、利用可能になったことを検出するためと、
前記インターフェースを使用しているオープンな接続を識別するためと、
前記オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築するためと、
前記識別したオープンな接続と、前記インターフェースと、前記未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、前記パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを、動的に変化させるためのものである請求項１７記載の装置。
【請求項２９】
前記コンピューティングプラットフォームは、さらに、各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持するためのものである請求項１７記載の装置。
【請求項１】
パケットデータ通信のための方法において、
前記方法は、
パケットデータ通信のための多数のパラレルな接続を確立することと、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信することと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させることとを含む方法。
【請求項２】
前記複数のパイプライン化されたリクエストを送信することは、ワイヤレスワイドエリアネットワークのノードにアクセスすることをさらに含む請求項１記載の方法。
【請求項３】
前記パラレルな接続の数と、前記パイプライン化されたリクエストの数とを動的に変化させることは、
帯域幅とラウンドトリップタイムとを推定することと、
リクエストされたが受信されていないパケットデータが、推定した帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、前記パイプライン化されたリクエストの送信を継続することとをさらに含む請求項１記載の方法。
【請求項４】
前記パケットデータ通信のための多数のパラレルな接続を確立することは、
前記複数のサーバのうちのそれぞれに対する接続の数を最小化することと、
リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、前記多数のパラレルな接続を使用することと、
前記接続の数を最小化するという目的と、前記全体的な輻輳を減少させるために、前記多数のパラレルな接続を使用するという目的との対立を最適化するために、前記パラレルな接続の数と前記パイプライン化されたリクエストの数とを動的に変化させることとをさらに含む請求項１記載の方法。
【請求項５】
前記パケットデータ部分をレンダリングするためのプログレッシブな順序付けを決定することと、
前記プログレッシブな順序付けに関連して、前記複数のパイプライン化されたリクエストの順序に優先順位を付けることとをさらに含む請求項１記載の方法。
【請求項６】
フルなリンク利用を維持することは、グリーディリクエスト機会を利用することをさらに含む請求項１記載の方法。
【請求項７】
フルなリンク利用を維持することは、ジャストインタイムリクエスト機会を利用することをさらに含む請求項１記載の方法。
【請求項８】
前記複数のパイプライン化されたリクエストを送信することは、ヘッダ圧縮をリクエストすることを含む請求項１記載の方法。
【請求項９】
リクエストされなかった、サーバにより識別されたリソースを受信することをさらに含む請求項１記載の方法。
【請求項１０】
前記サーバ識別リソースが必要でないことを決定することと、
前記サーバ識別リソースをキャンセルすることとをさらに含む請求項９記載の方法。
【請求項１１】
ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストを送信することをさらに含む、前記複数のパイプライン化されたリクエストを送信することをさらに含む請求項１記載の方法。
【請求項１２】
前記複数のパイプライン化されたリクエストを送信することは、
インターフェースが利用可能でなくなったことを、または、利用可能になったことを検出することと、
前記インターフェースを使用しているオープンな接続を識別することと、
前記オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築することと、
前記識別したオープンな接続と、前記インターフェースと、前記未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、前記パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを、動的に変化させることとをさらに含む請求項１記載の方法。
【請求項１３】
各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持することをさらに含む請求項１記載の方法。
【請求項１４】
パケットデータ通信のための少なくとも１つのプロセッサにおいて、
前記少なくとも１つのプロセッサは、
パケットデータ通信のための多数のパラレルな接続を確立する第１のモジュールと、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する第２のモジュールと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる第３のモジュールとを具備する少なくとも１つのプロセッサ。
【請求項１５】
パケットデータ通信のためのコンピュータプログラムプロダクトにおいて、
前記コンピュータプログラムプロダクトは、コードの組を記憶する一時的でないコンピュータ読取可能媒体を具備し、
前記コードの組は、
コンピュータに、パケットデータ通信のための多数のパラレルな接続を確立させるための第１の組のコードと、
前記コンピュータに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信させるための第２の組のコードと、
前記コンピュータに、フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させるための第３の組のコードとを含むコンピュータプログラムプロダクト。
【請求項１６】
パケットデータ通信のための装置において、
前記装置は、
パケットデータ通信のための多数のパラレルな接続を確立する手段と、
複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信する手段と、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させる手段とを具備する装置。
【請求項１７】
パケットデータ通信のための装置において、
前記装置は、
パケットデータ通信のための多数のパラレルな接続を確立するトランシーバであって、さらに、複数のサーバ上にそれぞれ記憶されているパケットデータ部分から構成されるハイパーテキストオブジェクトを取り出すために、前記多数のパラレルな接続を介して、複数のパイプライン化されたリクエストを送信するためのトランシーバと、
フルなリンク利用を維持しながら、未処理のリクエストを減少させるために、パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを動的に変化させるコンピューティングプラットフォームとを具備する装置。
【請求項１８】
前記トランシーバは、さらに、ワイヤレスワイドエリアネットワークのノードにアクセスすることにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項１９】
前記コンピューティングプラットフォームは、さらに、
帯域幅とラウンドトリップタイムとを推定することと、
リクエストされたが受信されていないパケットデータが、推定した帯域幅およびラウンドトリップタイムの積を超える可能性があるまで、前記パイプライン化されたリクエストの送信を継続することとにより、
前記パラレルな接続の数と、前記パイプライン化されたリクエストの数とを動的に変化させるためのものである請求項１７記載の装置。
【請求項２０】
前記トランシーバを介する前記コンピューティングプラットフォームは、さらに、
前記複数のサーバのうちのそれぞれに対する接続の数を最小化することと、
リクエストされたパケットデータを遅らせるまたは損失させる全体的な輻輳レスポンスを減少させるために、前記多数のパラレルな接続を使用することと、
前記接続の数を最小化するという目的と、前記全体的な輻輳を減少させるために、前記多数のパラレルな接続を使用するという目的との対立を最適化するために、前記パラレルな接続の数と前記パイプライン化されたリクエストの数とを動的に変化させることとにより、
前記パケットデータ通信のための多数のパラレルな接続を確立するためのものである請求項１７記載の装置。
【請求項２１】
前記コンピューティングプラットフォームは、さらに、前記パケットデータ部分をレンダリングするためのプログレッシブな順序付けを決定するためと、
前記プログレッシブな順序付けに関連して、前記複数のパイプライン化されたリクエストの順序に優先順位を付けるためのものである請求項１７記載の装置。
【請求項２２】
前記コンピューティングプラットフォームは、さらに、グリーディリクエスト機会を利用することにより、フルなリンク利用を維持するためのものである請求項１７記載の装置。
【請求項２３】
前記コンピューティングプラットフォームは、さらに、ジャストインタイムリクエスト機会を利用することにより、フルなリンク利用を維持するためのものである請求項１７記載の装置。
【請求項２４】
前記トランシーバは、さらに、ヘッダ圧縮をリクエストすることにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項２５】
前記トランシーバは、さらに、リクエストされなかった、サーバにより識別されたリソースを受信するためのものである請求項１７記載の装置。
【請求項２６】
前記コンピューティングプラットフォームは、さらに、
前記サーバ識別リソースが必要でないことを決定するためと、
前記サーバ識別リソースをキャンセルするためのものである請求項２５記載の装置。
【請求項２７】
前記トランシーバは、さらに、ヘッダ範囲機能を使用して、複数の部分的なパイプライン化リクエストを送信することにより、前記複数のパイプライン化されたリクエストを送信するためのものである請求項１７記載の装置。
【請求項２８】
前記コンピューティングプラットフォームは、さらに、
インターフェースが利用可能でなくなったことを、または、利用可能になったことを検出するためと、
前記インターフェースを使用しているオープンな接続を識別するためと、
前記オープンな接続上で発行されている未完了のパイプライン化リクエストのリストを構築するためと、
前記識別したオープンな接続と、前記インターフェースと、前記未完了のパイプライン化リクエストのリストとに部分的に基づいて、接続ラウンドロビンにより、前記パラレルな接続の数と、前記パラレルな接続を介するパイプライン化されたリクエストの数とを、動的に変化させるためのものである請求項１７記載の装置。
【請求項２９】
前記コンピューティングプラットフォームは、さらに、各インターフェースに対する別々のドメインネームサーバ（ＤＮＳ）キャッシュを維持するためのものである請求項１７記載の装置。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１３−５１５３９９（Ｐ２０１３−５１５３９９Ａ）
【公表日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願番号】特願２０１２−５４４９４６（Ｐ２０１２−５４４９４６）
【出願日】平成２２年１２月２０日（２０１０．１２．２０）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６１３６０
【国際公開番号】ＷＯ２０１１／０７５７３８
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願日】平成２２年１２月２０日（２０１０．１２．２０）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６１３６０
【国際公開番号】ＷＯ２０１１／０７５７３８
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]