JP7344315B2 - ネットワークベースのサービスのためのｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔオフロードメカニズム - Google Patents

Description

関連出願

本出願は、２０１９年５月１７日に出願された米国特許出願第１６／４１６１０８号の利益を主張するものであり、その内容は参照により本明細書に組み込まれる。

本発明の実施形態は、概してクライアント－サーバアーキテクチャに関し、より具体的には、ネットワークベースのサービスのためのｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔオフロードメカニズムに関する。

多くのクライアントアプリケーションが、バージョン１．０または１．１（「１．ｘ」）のＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（「ＨＴＴＰ」） ｏｖｅｒ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（「ＴＣＰ」）を使用して、ネットワークベースのサービスにアクセスする。その際、クライアントアプリケーションが、クライアントアプリケーションとネットワークベースのサービスとの間のＴＣＰ接続を介して送信されるＨＴＴＰトランザクションによってネットワークベースのサービスと対話する。典型的なクライアントアプリケーションは、比較的少ない対話型ＨＴＴＰトランザクションおよび比較的多い情報提供型ＨＴＴＰトランザクションを開始する。対話型ＨＴＴＰトランザクションでは、クライアントアプリケーションは、ホームページ用の表示情報など、クライアントアプリケーションと対話しているユーザに提供する必要があるデータをダウンロードする。情報提供型ＨＴＴＰトランザクションでは、クライアントアプリケーションは、ネットワークベースのサービスが情報提供の目的で使用するデータを１つ以上のサーバマシンにアップロードする。例えば、クライアントアプリケーションは、イベントログ、クライアントアプリケーションのパフォーマンスを示すメトリックログ、および／またはクライアントアプリケーションが適切に実行されていることを示す「ハートビート」をアップロードすることができる。

ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを使用することの１つの欠点は、大量の情報提供型ＨＴＴＰトランザクションが、所与のクライアントアプリケーションに関連する対話型ＨＴＴＰトランザクションの送信および処理を大幅に遅延させる可能性がある点にある。ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰでは、各ＨＴＴＰトランザクションは、専用のＴＣＰ接続を要する。さらに、クライアントアプリケーションが実行されるクライアントプラットフォームでは、ＴＣＰ接続の同時処理数が２～６接続に制限されることがしばしばある。また、よく理解されているように、アップロード速度は通常、ダウンロード速度よりも遅い。その結果、様々な時点で、利用可能なＴＣＰ接続の全てが情報提供型ＨＴＴＰトランザクションのみに割り当てられる場合がある。保留中の対話型ＨＴＴＰトランザクションは、ＨＴＴＰトランザクションの相対的に遅いアップロード部分を含む情報提供型ＨＴＴＰトランザクションの１つが完了するまで待機しなければならない。保留中の対話型ＨＴＴＰトランザクションに関連するデータのダウンロードの結果的な遅延により、全般的なユーザエクスペリエンスの低下を招く場合がある。

上記の問題に対処する取り組みでは、幾つかのクライアントアプリケーションが、利用可能なＴＣＰ接続の少なくとも１つを情報提供型ＨＴＴＰトランザクションに割り当て、他のＴＣＰ接続を対話型ＨＴＴＰトランザクションに割り当てている。しかし、このアプローチでは、情報提供型ＨＴＴＰトランザクションの実際の量に関わらず、対話型ＨＴＴＰトランザクションに利用可能なＴＣＰ接続の数が自動的に低減される。情報提供型ＨＴＴＰトランザクションの量が比較的少ない場合には、このような低減は望ましくない。さらに、情報提供型ＨＴＴＰトランザクションに割り当てられたＴＣＰ接続の容量を超えれば、クライアントアプリケーションが、情報提供型ＨＴＴＰトランザクションによってネットワークベースのサービスに送信される情報を欠落させてしまう場合がある。

上記の問題に対処する別のアプローチとして、一部のクライアントアプリケーションは、複数のＨＴＴＰトランザクションを各ＴＣＰ接続上で多重化できるＨＴＴＰ／２を実装する。クライアントアプリケーションは、ＨＴＴＰ／２を実装する場合、各ＴＣＰ接続上で任意の数の情報提供型ＨＴＴＰトランザクションと同時に任意の数の対話型ＨＴＴＰトランザクションを開始することができるため、１つ以上の対話型ＨＴＴＰトランザクションによってユーザに提供されるべきデータのダウンロードの遅延を低減することができる。しかし、一部のクライアントプラットフォームはＨＴＴＰ／２に対応しておらず、この解決手段の有効性は低下する。

上述したように、当該技術分野では、ネットワークベースのサービスに関連する要求を処理するためのより効果的な技術が必要とされている。

本発明の一実施形態は、ネットワークベースのサービスに関連する要求を処理するためのコンピュータ実装方法を規定する。方法は、クライアントアプリケーションから受信された第１の要求が、第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定するステップと、第１の要求をサーバマシンに送信する前に、サーバマシンが第１の要求の処理に成功したことを示す、第１の要求に対する第１の応答を、クライアントアプリケーションに送信するステップとを含み、第１の応答を受信したことに応じて、クライアントアプリケーションが第２の要求を開始することが可能となる。

先行技術に比べた開示の技術の少なくとも１つの技術的利点は、開示の技術により、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを実装するクライアントアプリケーションのための情報提供型ＨＴＴＰトランザクションによって対話型ＨＴＴＰトランザクションが遅延する可能性が低くなる点にある。特に、クライアントアプリケーションから送信された情報提供型ＨＴＴＰトランザクションにプロキシサーバが応答するとすぐに、クライアントアプリケーションは、バックエンドサーバからの応答を待つ必要なしに、関連するＴＣＰ接続を閉じるかまたは再使用することができる。したがって、クライアントアプリケーションが、利用可能なＴＣＰ接続を全て情報提供型ＨＴＴＰトランザクションに使用してしまい、対話型ＨＴＴＰトランザクションの送信および処理を遅延させる可能性が低くなる。これらの技術的利点は、先行技術のアプローチに対する１つ以上の技術的進歩を表すものである。

様々な実施形態の上述した特徴を詳細に理解できるように、上で簡潔に要約された発明概念のより具体的な説明を、添付の図面に一部が示されている様々な実施形態を参照することによって行うことができる。しかし、添付の図面は、発明概念の典型的な実施形態のみを示しており、したがって、いかなる方法でも範囲を限定するものとはみなされず、他にも同等に効果的な実施形態があることに留意されたい。
本発明の１つ以上の態様を実施するように構成されたシステムの概念図である。 本発明の様々な実施形態による、動作中の図１の高速化システムの１つのより詳細な図である。 本発明の様々な実施形態による、図２のプロキシアプリケーションのより詳細な図である。 本発明の様々な実施形態による、ネットワークベースのサービスに関連する要求を処理するための方法ステップのフロー図である。

以下の説明では、様々な実施形態のより完全な理解をもたらすために、多数の具体的な詳細が規定される。しかし、これらの具体的な詳細の１つ以上がなくても発明概念を実践しうることが当業者にとって明らかであろう。

ユーザは典型的に、インターネットに接続されたクライアントデバイス上で実行されるクライアントアプリケーションを介して、メディアストリーミングサービスと対話する。例えば、スマートテレビ上で実行されるクライアントアプリケーションは、メディアストリーミングサービスによって提供されるメディアコンテンツを閲覧、検索、選択、ダウンロード、およびストリーミングすることをユーザに可能にさせることができる。多くのクライアントアプリケーションは、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを使用してメディアストリーミングサービスにアクセスする。その際、クライアントアプリケーションは、ＨＴＴＰトランザクションによってメディアストリーミングサービスと対話する。典型的なクライアントアプリケーションは、比較的少ない対話型ＨＴＴＰトランザクションおよび比較的多い情報提供型ＨＴＴＰトランザクションを開始する。対話型ＨＴＴＰトランザクションでは、クライアントアプリケーションは、ホームページ用の表示情報など、クライアントアプリケーションと対話しているユーザに提供する必要があるデータをダウンロードする。情報提供型ＨＴＴＰトランザクションでは、クライアントアプリケーションは、メディアストリーミングサービスが情報提供の目的で使用するデータを１つ以上のサーバマシンにアップロードする。例えば、クライアントアプリケーションは、イベントログ、クライアントアプリケーションのパフォーマンスを示すメトリックログ、および／またはストリーミングセッションがアクティブであることを示す「ハートビート」をアップロードすることができる。

ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを使用することの１つの欠点は、大量の情報提供型ＨＴＴＰトランザクションが、所与のクライアントアプリケーションに関連する対話型ＨＴＴＰトランザクションの送信および処理を大幅に遅延させる可能性がある点にある。ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰでは、各ＨＴＴＰトランザクションは、専用のＴＣＰ接続を要する。さらに、クライアントアプリケーションが実行されるクライアントプラットフォームでは、ＴＣＰ接続の同時処理数が２～６接続に制限されることがよくある。また、よく理解されているように、アップロード速度は通常、ダウンロード速度よりも遅い。例えば、インターネットサービスプロバイダ（「ＩＳＰ」）は、アップロード速度が最大で５メガビット／秒（「Ｍｂｐｓ」）であるのに対し、ダウンロード速度が最大で２５０Ｍｂｐｓのサービス階層を提供することができる。その結果、様々な時点で、利用可能なＴＣＰ接続が全て、情報提供型ＨＴＴＰトランザクションのみに割り当てられる場合がある。保留中の対話型ＨＴＴＰトランザクションは、ＨＴＴＰトランザクションの相対的に遅いアップロード部分を含む情報提供型ＨＴＴＰトランザクションの１つが完了するまで待機しなければならない。保留中の対話型ＨＴＴＰトランザクションに関連するデータのダウンロードの結果的な遅延により、全般的なユーザエクスペリエンスの低下を招く場合がある。例えば、選択された映像に関連する情報を見るために５０ミリ秒待つ代わりに、ユーザは１秒待つことになる。

しかし、開示の技術により、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを実装するクライアントアプリケーションのための情報提供型ＨＴＴＰトランザクションによって対話型ＨＴＴＰトランザクションが遅延する可能性が低くなる。一実施形態では、プロキシアプリケーションが、１つ以上のクライアントアプリケーションと、メディアストリーミングサービスを提供するバックエンドサーバとの間の仲介役として機能するプロキシサーバ上で実行される。プロキシサーバとバックエンドサーバとは、ＨＴＴＰ／２ ｏｖｅｒ ＴＣＰを介して通信し、複数のＨＴＴＰトランザクションを各ＴＣＰ接続上で多重化することができる。

幾つかの実施形態では、クライアントアプリケーションは、情報提供型ＨＴＴＰトランザクションを開始する各要求に「ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔ」ヘッダを追加する。要求を受信すると、プロキシアプリケーションは、要求がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいるかどうかに基づいて、要求についてオフロードをアクティブにするかどうかを判定する。プロキシアプリケーションが要求についてオフロードをアクティブにすれば、プロキシアプリケーションは、バックエンドサーバに要求を送信する前に、有効な包括的応答をクライアントアプリケーションに送信する。有効な包括的応答は、バックエンドサーバが要求の処理に成功したと意図的に誤って示す。要求についてオフロードがアクティブであるかどうかに関わらず、プロキシアプリケーションはバックエンドサーバに要求を送信する。オフロードがアクティブであれば、プロキシアプリケーションは、バックエンドサーバから受信された応答を破棄する。そうでない場合、プロキシアプリケーションは、バックエンドサーバから受信された応答をクライアントアプリケーションに送信する。

先行技術に比べた開示の技術の少なくとも１つの技術的利点は、開示の技術により、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを実装するクライアントアプリケーションのための情報提供型ＨＴＴＰトランザクションによって対話型ＨＴＴＰトランザクションが遅延する可能性が低くなる点にある。特に、プロキシサーバがクライアントアプリケーションから送信された情報提供型ＨＴＴＰトランザクションに応答するとすぐに、クライアントアプリケーションは、バックエンドサーバからの応答を待つ必要なしに、関連するＴＣＰ接続を閉じるかまたは再使用することができる。したがって、クライアントアプリケーションが、利用可能なＴＣＰ接続を全て情報提供型ＨＴＴＰトランザクションに使用し、対話型ＨＴＴＰトランザクションの送信および処理を遅延させる可能性が低くなる。その結果、クライアントアプリケーションを介してメディアストリーミングサービスによって提供される典型的なユーザエクスペリエンスが向上する。これらの技術的利点は、先行技術のアプローチに対する１つ以上の技術的進歩を表すものである。

システムの概要
図１は、本発明の１つ以上の態様を実施するように構成されたシステム１００の概念図である。図示されているように、システム１００は、限定されないが、ネットワークベースのサービスシステム１０２、任意の数のクライアントデバイス１０４、および任意の数の高速化システム１０６を含む。説明を目的として、同様のオブジェクトの複数のインスタンスが、オブジェクトを識別する参照番号と、必要な場合にはインスタンスを識別する括弧内の番号とで示される。

ネットワークベースのサービスシステム１０２と、クライアントデバイス１０４と、高速化システム１０６とは、通信ネットワーク（図示せず）を介して通信する。通信ネットワークは、データ通信を促進するように構成された、ルータやスイッチなどの複数のネットワーク通信システムを含む。当業者であれば、周知のインターネット通信ネットワークを展開する際に実践される技術など、通信ネットワークを構築するための技術的に実現可能な多くの技術が存在することを認識するであろう。

ネットワークベースのサービスシステム１０２は、限定されないが、世界中に分散され、ネットワークベースのサービス（例えば、ストリーミングメディアサービス）に関連するデータを受信、送信、処理、および／または記憶する、相互接続されたノードのネットワークを含む。相互接続されたノードは、これらの望ましい機能を行うソフトウェア、ファームウェア、およびハードウェアの任意の適切な組み合わせを含むことができる。特に、ネットワークベースのサービスシステム１０２は、同じ場所に配置されていてよく、物理的に互いに分散されていてもよい、複数のコンピューティングデバイスを含む。例えば、これらのコンピューティングデバイスは、１つ以上の汎用ＰＣ、Ｍａｃｉｎｔｏｓｈ、ワークステーション、Ｌｉｎｕｘ(登録商標)系のコンピュータ、サーバコンピュータ、１つ以上のサーバプール、または他の任意の適切なデバイスを含むことができる。コンピューティングデバイスは、対応するアプリケーションプログラミングインタフェース（「ＡＰＩ」）を介するなど、技術的に実現可能な任意の手法でリモートアクセス可能な１つ以上のプログラムを記憶して実行する。様々な実施形態では、任意の数のコンピューティングデバイスを、１つ以上のクラウドコンピューティング環境（すなわち、カプセル化された共有リソース、ソフトウェア、データなど）で実施してもよい。

各クライアントデバイス１０４は、ソフトウェアアプリケーションを実行し、通信ネットワークを介して他のデバイスと通信することができる、任意の種類のデバイスであってよい。例えば、クライアントデバイス１０４（１）は、タブレット、セットトップボックス、スマートテレビ、ゲーム機、ストリーミングメディアプレーヤ、スマートフォンなどのモバイルデバイスなどであってよい。クライアントデバイス１０４は、任意の数の物理的な場所に分散されていてよい。クライアントデバイス１０４はそれぞれ、データを受信、処理、記憶、および通信するための任意の適当な入力デバイス（キーパッド、タッチスクリーン、マウス、または情報を受容することができる他のデバイスなど）、出力デバイス、大容量記憶媒体、または他の適切な構成要素を含むことができる。入力デバイスと出力デバイスとの両方は、磁気コンピュータディスク、ＣＤ－ＲＯＭなどの固定式のまたはリムーバブルな記憶媒体を含むことができる。各クライアントデバイス１０４は、限定されないが、任意の数のプロセッサと任意の数のメモリとを任意の組み合わせで含むことができる。任意の数のクライアントデバイス１０４は、技術的に実現可能な任意の手法でマルチプロセッシング環境を提供することができる。

各クライアントデバイス１０４は、特定の動作のためにネットワークベースのサービスシステム１０２に依存する、コンピュータハードウェアおよび／またはコンピュータソフトウェアを含む。特に、各クライアントデバイス１０４は、それぞれ任意の数のソフトウェアアプリケーションを実行する任意の数のクライアントプラットフォームを含むことができる。クライアントプラットフォームの例としては、限定されないが、ウェブブラウザ、スマートテレビのオペレーティングシステム（ＯＳ）、携帯電話のＯＳ、ビデオゲーム機のＯＳなどが挙げられる。通信ネットワークを介してネットワークベースのサービスシステム１０２と通信し、様々な動作を行うソフトウェアアプリケーションを、本明細書では「クライアントアプリケーション」と称する。

幾つかの実施形態では、クライアントアプリケーションは、ネットワークベースのサービスシステム１０２に要求を発行することによって動作する。クライアントデバイス１０４は、ネットワークベースのサービスシステム１０２とのネットワーク接続を確立すると、ネットワーク接続を介してネットワークベースのサービスシステム１０２に要求を送信する。要求の受信に応じて、ネットワークベースのサービスシステム１０２は、要求を処理し、ネットワーク接続を介してクライアントアプリケーションに返送される応答を生成する。要求を発行し、対応する応答を受信するプロセスを、本明細書では「トランザクション」と称する。クライアント１０４上で実行されるクライアントアプリケーションと、ネットワークベースのサービスシステム１０２の要求処理部との間のラウンドトリップを、本明細書ではトランザクションラウンドトリップと称する。一般に、ネットワークベースのサービスシステム１０２の要求処理部からクライアント１０４が離れるほど、トランザクションラウンドトリップの待ち時間が長くなる。さらに、ネットワーク接続の輻輳が大きいほど、トランザクションラウンドトリップの待ち時間が長くなる。

高速化システム１０６は、ネットワークベースのサービスシステム１０２とクライアントデバイス１０４との間の仲介役として動作して、トランザクションラウンドトリップの待ち時間を低減する。高速化システム１０６は、世界中に分散されており、それぞれがクライアントデバイス１０４とネットワークベースのサービスシステム１０２との間の仲介役として動作する、相互接続されたシステムのネットワークを含む。所与の高速化システム１０６が、所与のクライアントデバイス１０４とのネットワーク接続を確立し、接続を介して要求を受信する。高速化システム１０６は、ネットワークベースのサービスシステム１０２とのネットワーク接続を介して、要求の処理を促進する。

様々な実施形態では、任意の数の高速化システム１０６を、インターネットサービスプロバイダ（「ＩＳＰ」）に関連するネットワーク内に組み込むことができる。幾つかのそのような実施形態では、高速化システム１０６（ｘ）がＩＳＰに関連するネットワーク内に組み込まれていれば、高速化システム１０６（ｘ）は、ＩＳＰに関連しているかつ／またはＩＳＰに加入しているクライアントデバイス１０４によってのみアクセス可能となる。同じまたは他の実施形態では、任意の数の高速化システム１０６が、インターネットエクスチェンジ内で、またはインターネットエクスチェンジに関連して、ＩＳＰから独立して動作してもよい。インターネットエクスチェンジは、ＩＳＰとコンテンツ配信ネットワーク（「ＣＤＮ」）がインターネットトラフィックを交換するための物理的なインフラストラクチャである。

高速化システム１０６が、ネットワークベースのサービスシステム１０２とクライアントデバイス１０４との間の仲介役として動作する場合、少なくとも２つの理由により、トランザクションの実行に要する時間が低減される。第１に、幾つかの実施形態では、高速化システム１０６は一般に、ネットワークベースのサービスシステム１０２に比べて、クライアントデバイス１０４に物理的に近い。よって、クライアントデバイス１０４と高速化システム１０６との間でネットワーク接続を確立するために必要とされるラウンドトリップ時間が、クライアントデバイス１０４とネットワークベースのサービスシステム１０２との間でネットワーク接続を確立する必要がある場合に比べて短くなる。第２に、幾つかの実施形態では、高速化システム１０６が複数のクライアントデバイス１０４からの大量の要求を有することに起因して、高速化システム１０６は、ネットワークベースのサービスシステム１０２との予め確立され予め認証された安定したネットワーク接続を有する。よって、ネットワークベースのサービスシステム１０２とのネットワーク接続を要求ごとに確立し認証する必要がない。

本明細書に示すシステム１００が例示的なものであって変形および変更が可能であることが理解されるであろう。例えば、システム１００の様々な構成要素間の接続トポロジは、所望に応じて変更可能である。なお、本明細書に記載している技術は、限定的でなく例示的なものであり、本発明のより広義の趣旨および範囲から逸脱することなく改変可能である。様々な実施形態では、本明細書に開示している任意の数の技術が実施可能である一方、他の技術を技術的に実現可能な任意の手法で省略することもできる。

説明のみを目的として、図２～図４は、ＴＣＰ接続および特定バージョンのＨＴＴＰプロトコルの文脈でシステム１００の機能を説明する。しかし、本明細書に記載される技術は、限定的でなく例示的なものであり、本発明のより広義の趣旨および範囲から逸脱することなく改変可能である。記載している実施形態および技術の範囲および趣旨から逸脱しない多くの変更および変形が当業者にとって明らかであろう。

図２は、本発明の様々な実施形態による、動作中の図１の高速化システム１０６の１つのより詳細な図である。より正確に、図２は、任意の数のクライアントデバイス１０４（１）～１０４（Ｎ）上で実行される任意の数のクライアントアプリケーション２２０（１）～２２０（Ｍ）と、高速化システム１０６（１）に含まれるプロキシサーバ２４０と、ネットワークベースのサービスシステム１０２に含まれるバックエンドサーバ２７０との間の対話を示す。

バックエンドサーバ２７０は、限定されないが、ネットワークベースのサービスシステム１０２に含まれる任意の数のコンピューティングデバイスを含む。コンピューティングデバイスはそれぞれ、ネットワークベースのサービスシステム１０２に対するＨＴＴＰ要求を処理し、これに応答する任意の数および種類のソフトウェアアプリケーションを実行することができる。

プロキシサーバ２４０は、高速化システム１０６（１）に含まれるコンピューティングデバイスである。代替的な実施形態では、プロキシサーバ２４０は、高速化システム１０６（１）に含まれる任意の数のコンピューティングデバイスを含むことができる。図示されているように、クライアントデバイス１０４とプロキシサーバ２４０とは、クライアント／プロキシＴＣＰ接続２３０を介してＨＴＴＰ／１．１を使用して通信する。プロキシサーバ２４０とバックエンドサーバ２７０とは、プロキシ／バックエンドＴＣＰ接続２６０を介してＨＴＴＰ／２を使用して通信する。動作中、プロキシサーバ２４０は、クライアントデバイス１０４（１）～１０４（Ｎ）とバックエンドサーバ２７０との間の仲介役として機能して、ＨＴＴＰトランザクションの実行に要する時間を低減する。プロキシサーバ２４０は、往々にして「リバースプロキシサーバ」と称される。

プロキシサーバ２４０は、少なくとも３つの理由により、ＨＴＴＰトランザクションの実行に要する時間を短縮する。第１に、プロキシサーバ２４０は一般的に、バックエンドサーバ２７０に比べて、クライアントデバイス１０４（１）～１０４（Ｎ）に物理的に近い。特に、幾つかの実施形態では、プロキシサーバ２４０は、クライアントデバイス１０４（１）～１０４（Ｎ）にも関連するＩＳＰに関連するネットワーク内に組み込まれる。よって、クライアントデバイス１０４とプロキシサーバ２４０との間でネットワーク接続を確立するために必要とされるラウンドトリップ時間が、クライアントデバイス１０４とバックエンドサーバ２７０との間でネットワーク接続を確立する必要がある場合に比べて短くなる。第２に、幾つかの実施形態では、プロキシサーバ２４０が複数のクライアントデバイス１０４からの大量の要求を有することに起因して、プロキシサーバ２４０は、バックエンドサーバ２７０との安定した予め確立され予め認証された任意の数のプロキシ／バックエンドＴＣＰ接続２６０を有する。よって、バックエンドサーバ２７０とのＴＣＰ接続を、ＨＴＴＰ要求ごとに確立し認証する必要がない。

第３に、プロキシサーバ２４０とバックエンドサーバ２７０とは、ＨＴＴＰ／２を使用して通信する。周知のように、ＨＴＴＰ／２は、ＨＴＴＰ／１．ｘに比べて多種多様なパフォーマンス向上策を実装する。特に、ＨＴＴＰ／２では、複数のＨＴＴＰトランザクションが、各接続（例えば、プロキシ／バックエンドＴＣＰ接続２６０（１））上で多重化される。したがって、ＨＴＴＰ対話の同時処理数が必ずしも制限されない。幾つかの実施形態では、プロキシサーバ２４０は、通常の動作中に到達する可能性が低い同時処理リミットを設定する。例えば、幾つかの実施形態では、プロキシサーバ２４０は、２つのプロキシ／バックエンドＴＣＰ接続２６０（１）および２６０（２）を介してバックエンドサーバ２７０に接続し、ＴＣＰ接続ごとに５０の同時処理のＨＴＴＰトランザクションからなる同時処理リミットを設定する。したがって、プロキシサーバ２４０とバックエンドサーバ２７０との間では、最大で１００のＨＴＴＰトランザクションを同時に実行することができる。

図示されているように、プロキシサーバ２４０は、限定されないが、プロセッサ２１２およびメモリ２１６を含む。プロセッサ２１２は、命令を実行することができる任意の命令実行システム、装置、またはデバイスであってよい。例えば、プロセッサ２１２は、中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、コントローラ、マイクロコントローラ、ステートマシン、またはこれらの任意の組み合わせで構成することができる。メモリ２１６は、演算インスタンス１１０のプロセッサ２１２が使用するための、ソフトウェアアプリケーションおよびデータなどのコンテンツを記憶する。

メモリ２１６は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、フロッピーディスク、ハードディスク、またはローカルもしくはリモートの他の任意の形態のデジタルストレージなどの、容易に入手可能なメモリの１つ以上であってよい。幾つかの実施形態では、ストレージ（図示せず）が、メモリ２１６を補完または置換してもよい。ストレージは、プロセッサ２１２にとってアクセス可能な任意の数および種類の外部メモリを含むことができる。例えば、限定されないが、ストレージは、ＳＤカード（Secure Digital Card）、外部フラッシュメモリ、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、光学記憶装置、磁気記憶装置、またはこれらの任意の適切な組み合わせを含むことができる。代替的な実施形態では、プロキシサーバ２４０は、限定されないが、任意の数のプロセッサ２１２と任意の数のメモリ２１６とを任意の組み合わせで含むことができる。同じまたは他の実施形態では、プロキシサーバ２４０に含まれる任意の数のコンピューティングデバイスが、技術的に実現可能な任意の手法でマルチプロセッシング環境を提供することができる。

プロキシサーバ２４０は、クライアントアプリケーション２２０がバックエンドサーバ２７０を介してネットワークベースのサービスにアクセスすることを可能にする１つ以上のアプリケーションを実装するように構成される。各アプリケーションは、プロキシサーバ２４０の単一のメモリ２１６に常駐し、プロキシサーバ２４０の単一のプロセッサ２１２上で実行されるものとして説明される。しかし、当業者が認識するように、各アプリケーションの機能は、任意の数の演算装置のメモリ２１６に常駐し、任意の数の演算装置のプロセッサ２１２上で実行される、任意の数の他のアプリケーションに分散されてもよい。さらに、任意の数のアプリケーションの機能を、単一のアプリケーションまたはサブシステムに統合してもよい。

クライアントアプリケーション２２０はそれぞれ、ＨＴＴＰ１．ｘ ｏｖｅｒ ＴＣＰを使用してネットワークベースのサービスシステム１０２にアクセスする。その際、クライアントアプリケーション２２０はそれぞれ、１つ以上のクライアント／プロキシＴＣＰ接続２３０を介してプロキシサーバ２４０と対話する。各クライアント／プロキシＴＣＰ接続２３０は、クライアントデバイス１０４の１つで実行されるクライアントアプリケーション２２０の１つをプロキシサーバ２４０に接続する。クライアントアプリケーション２２０（１）について示すように、クライアントアプリケーション２２０はそれぞれ、最大ＴＣＰ接続数２０４に関連付けられる。最大ＴＣＰ接続数２０４（１）は、クライアントアプリケーション２２０（１）が各ネットワークベースのサービスシステム１０２に対して有することができるＴＣＰ接続の最大数を指定する。典型的に、最大ＴＣＰ接続数２０４は、クライアントアプリケーション２２０を実行するクライアントプラットフォーム（例えば、ウェブブラウザ、スマートテレビ操作システムなど）によって設定されて実施される。説明のみを目的として、クライアントアプリケーション２２０（１）の最大ＴＣＰ接続数２０４は３つである。したがって、クライアントアプリケーション２２０（１）は、最大で３つのクライアント／プロキシＴＣＰ接続２３０を確立することができる。

ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰでは、各ＨＴＴＰトランザクションは、専用のＴＣＰ接続を要する。典型的なクライアントアプリケーション２２０は、比較的少ない対話型ＨＴＴＰトランザクションおよび比較的多い情報提供型ＨＴＴＰトランザクションを開始する。対話型ＨＴＴＰトランザクションでは、クライアントアプリケーション２２０は、ホームページ用の表示情報など、クライアントアプリケーション２２０と対話しているユーザに提供する必要があるデータをダウンロードする。情報提供型ＨＴＴＰトランザクションでは、クライアントアプリケーション２２０は、ネットワークベースのサービスシステム１０２が情報提供の目的で使用するデータをバックエンドサーバ２７０にアップロードする。例えば、クライアントアプリケーション２２０は、イベントログ、クライアントアプリケーション２２０のパフォーマンスを示すメトリックログ、および／またはクライアントアプリケーション２２０が適切に実行されていることを示す「ハートビート」をアップロードすることができる。

ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを使用することの１つの欠点は、大量の情報提供型ＨＴＴＰトランザクションが、所与の従来のクライアントアプリケーションに関連する対話型ＨＴＴＰトランザクションの送信および処理を大幅に遅延させる可能性がある点にある。従来のクライアントアプリケーションは、ＴＣＰ接続の最大数に制限されるだけでなく、アップロード速度は、通常、ダウンロード速度よりも遅い。その結果、様々な時点で、利用可能なＴＣＰ接続が全て情報提供型ＨＴＴＰトランザクションのみに割り当てられる場合がある。保留中の対話型ＨＴＴＰトランザクションは、ＨＴＴＰトランザクションの相対的に遅いアップロード部分を含む情報提供型ＨＴＴＰトランザクションの１つが完了するまで待機しなければならない。保留中の対話型ＨＴＴＰトランザクションに関連するデータのダウンロードの結果的な遅延により、全般的なユーザエクスペリエンスの低下を招く場合がある。

本明細書で前述したように、上記の問題に対処する取り組みでは、対話型ＨＴＴＰトランザクションに利用可能なＴＣＰ接続の数が自動的に低減されてしまい、情報提供型ＨＴＴＰトランザクションによってネットワークベースのサービスに送信される情報が欠落するリスクが増大し、かつ／または適用範囲が制限される。

バックエンドサーバのオフロード
上記の問題により効果的に対処するために、プロキシサーバ２４０は、限定されないが、プロキシアプリケーション２５０を含む。図示されているように、プロキシアプリケーション２５０は、メモリ２１６に常駐し、プロキシサーバ２４０のプロセッサ２１２上で実行される。プロキシアプリケーション２５０は、クライアントアプリケーション２２０とバックエンドサーバ２７０との間の仲介役として機能する一方で、情報提供用アップロードのための任意の数のＨＴＴＰ要求への応答を、バックエンドサーバ２７０から選択的にオフロードする。情報提供用アップロードのためのＨＴＴＰ要求および対応するＨＴＴＰ応答を、本明細書では情報提供型ＨＴＴＰトランザクションと称する。

ＨＴＴＰ／１．ｘ要求２３２（ｘ）を生成するときに、対応するＨＴＴＰ／１．ｘ応答２３４（ｘ）がクライアントアプリケーション２２０にとって重要でなければ、クライアントアプリケーション２２０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に「ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔ」ヘッダを追加することができる。当業者が認識しているように、対応するＨＴＴＰ／１．ｘ応答２３４（ｘ）がクライアントアプリケーション２２０にとって重要でないＨＴＴＰ／１．ｘ要求２３２（ｘ）は典型的に、データをアップロードするために使用される、「ＰＯＳＴ」や「ＰＵＴ」などのＨＴＴＰメソッドを指定する。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）への応答をバックエンドサーバ２７０からプロキシアプリケーション２５０にオフロードできることをプロキシアプリケーション２５０に示す。なお、関連するクライアントアプリケーション２２０に対して情報提供型ＨＴＴＰ対話が典型的に有する唯一の影響は、潜在的に他のＨＴＴＰ対話を遅延させ、このためにクライアントアプリケーション２２０のパフォーマンスを低下させる点である。このため、幾つかの実施形態では、クライアントアプリケーション２２０は、情報提供型ＨＴＴＰ対話を開始する各ＨＴＴＰ／１．ｘ要求２３２にｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを追加する。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、限定されないが、名称「Ｆｉｒｅ－ａｎｄ－Ｆｏｒｇｅｔ」および成功コードリスト（成功コードパラメータの１つ以上の値）を含む。名称「Ｆｉｒｅ－ａｎｄ－Ｆｏｒｇｅｔ」は、対応するＨＴＴＰ／１．ｘ応答２３４（ｘ）が重要でないことを示す。成功コードリストは、ＨＴＴＰ／１．ｘ応答２３４（ｘ）の成功をそれぞれ示す１つ以上のステータスコードを指定する。例えば、ＨＴＴＰ／１．ｘ要求２３２（ｘ）のｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダのための成功コードリストは、「２００，２０４」を指定することができ、ＨＴＴＰ／１．ｘ要求２３２（ｙ）のｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダの成功コードリストは、「２００」を指定することができる。

ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいれば、ＨＴＴＰ／１．ｘ要求２３２（ｘ）は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関連する重要度に相関するパーシステンスレベルに関連付けられる。ＨＴＴＰ１．ｘ要求２３２（ｘ）のパーシステンスレベルは、ＨＴＴＰ１．ｘ要求２３２（ｘ）に含まれる「ｐｅｒｓｉｓｔｅｎｃｅ」ヘッダによって指定することができる。ＨＴＴＰ１．ｘ要求２３２（ｘ）がパーシステンスヘッダを含んでいなければ、ＨＴＴＰ１．ｘ要求２３２（ｘ）は、デフォルトのパーシステンスレベルに関連付けられる。

パーシステンスヘッダは、限定されないが、名称「Ｐｅｒｓｉｓｔｅｎｃｅ」およびパーシステンスレベル（パーシステンスパラメータの値）を含む。許容される各パーシステンスレベルは、あるバージョンの関連するＨＴＴＰ要求２３２をバックエンドサーバ２７０が処理に成功しない場合にプロキシアプリケーション２５０が行うことになる、異なるエラー処理プロセスに関連付けられる。より正確には、ＨＴＴＰ要求２３２（ｘ）のパーシステンスレベルは、バックエンドサーバがＨＴＴＰ／２要求２６２（ｘ）の処理に成功できない場合にプロキシアプリケーション２５０が行うことになる、エラー処理プロセスを指定する。ＨＴＴＰ／２要求２６２（ｘ）は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）のＨＴＴＰ／２バージョンである。

クライアントアプリケーション２２０の１つからＨＴＴＰ／１．ｘ要求２３２（ｘ）を受信すると、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにするかどうかを判定する。幾つかの実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含む場合に、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにする。他の実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダおよび任意の数の追加の基準を含むかどうかに基づいて、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにするかどうかを判定してもよい。

例えば、様々な実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダおよび最大オフロード同時処理数（図１には示さず）を含むかどうかに基づいて、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにするかどうかを判定する。最大オフロード同時処理数は、任意の所与の時間にオフロードをアクティブにすることができるＨＴＴＰ／１．ｘ要求２３２の最大数を指定する。ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含み、オフロードがアクティブであるＨＴＴＰ１．ｘ要求２３２の総数が最大オフロード同時処理数よりも少なければ、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにする。そうでない場合、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにしない。プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で追跡してオフロードをアクティブにすることができる。

例えば、幾つかの実施形態では、図３と併せてより詳細に説明するように、プロキシアプリケーション２５０は、Ｇｏ言語で書かれており、各ＨＴＴＰ／１．ｘ要求２３２は、異なる実行スレッドによって処理される。オフロード機能は、オフロード機能を実行するスレッドの数を最大オフロード同時処理数に制限するＨＴＴＰ．ｈａｎｄｌｅｒに含まれる。

ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードがアクティブであれば、プロキシアプリケーション２５０は、ＨＴＴＰ／要求２３２（ｘ）が受信されたクライアント／プロキシＴＣＰ接続２３０を使用して、「有効な」包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）をクライアントアプリケーション２２０に送信する。この場合、クライアントアプリケーション２２０は、クライアント／プロキシＴＣＰ接続２３０を再使用してもよく、閉じてもよい。有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）は、バックエンドサーバ２７０がＨＴＴＰ／１．ｘ要求２３２（ｘ）の処理に成功したことを意図的に誤って示す。プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成することができる。

例えば、幾つかの実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）のｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダの成功コードリストに指定されたステータスコードの１つを含む有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成する。例えば、成功コードリストが２００のステータスコードを含んでいれば、プロキシアプリケーション２５０は、ＨＴＴＰステータスライン「２００ ＯＫ」および空のボディを有する、有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成することができる。当業者が認識するように、「ＨＴＴＰステータスライン」は、関連する理由フレーズ（例えば、「ＯＫ」）を伴うステータスコード（例えば、２００）である。２００のステータスコードは、バックエンドサーバ２７０がＨＴＴＰ／１．ｘ要求２３２（ｘ）の処理に成功したことを示している。別の例では、成功コードリストが２０４のステータスコードを含んでいれば、プロキシアプリケーション２５０は、ＨＴＴＰステータスライン「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」を有する有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成することができる。２０４のステータスコードは、バックエンドサーバ２７０がＨＴＴＰ／１．ｘ要求２３２（ｘ）の処理に成功しており、コンテンツも返さないことを示している。

その後、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードがアクティブであるかどうかにかかわらず、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）をＨＴＴＰ／２要求２６２（ｘ）に変換する。ＨＴＴＰ／２要求２６２（ｘ）は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）のＨＴＴＰ／２バージョンである。プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、ＨＴＴＰ／１．ｘ要求２３２（ｘ）をＨＴＴＰ／２要求２６２（ｘ）に変換することができる。次いで、プロキシアプリケーション２５０は、プロキシ／バックエンドＴＣＰ接続２６０の１つを介して、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（ｘ）の送信を試行する。ＨＴＴＰ／１．ｘトランザクションとは対照的に、任意の数のＨＴＴＰ／２要求２６２および任意の数のＨＴＴＰ／２応答２６４が、プロキシ／バックエンドＴＣＰ接続２６０のそれぞれを共有することができるため、任意の数のＨＴＴＰ／２トランザクションを同時に実行することができる。

ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブでなく、プロキシアプリケーション２５０がバックエンドサーバ２７０からＨＴＴＰ／２応答２６４（ｘ）の受信に成功すれば、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（ｘ）をＨＴＴＰ１．ｘ応答２３４（ｘ）に変換する。ＨＴＴＰ／１．ｘ応答２３４（ｘ）は、ＨＴＴＰ／２応答２６４（ｘ）のＨＴＴＰ／１．ｘバージョンである。プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、ＨＴＴＰ／２応答２６４（ｘ）をＨＴＴＰ１．ｘ応答２３４（ｘ）に変換することができる。次いで、プロキシアプリケーション２５０は、ＨＴＴＰ／要求２３２（ｘ）が受信されたクライアント／プロキシＴＣＰ接続２３０を使用して、ＨＴＴＰ／１．ｘ応答２３４（ｘ）をクライアントアプリケーション２２０に送信する。この場合、クライアントアプリケーション２２０は、クライアント／プロキシＴＣＰ接続２３０を再使用してもよく、閉じてもよい。

ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブでなく、プロキシアプリケーション２５０がバックエンドサーバ２７０からＨＴＴＰ／２応答２６４（ｘ）を受信しなければ、プロキシアプリケーション２５０は「ｓｅｒｖｅｒ ｅｒｒｏｒ」のＨＴＴＰ／２応答２６４（ｘ）を生成する。プロキシアプリケーション２５０は、様々な理由により、バックエンドサーバ２７０からＨＴＴＰ／２応答２６４（ｘ）を受信しない場合がある。例えば、バックエンドサーバ２７０は過負荷となる可能性がある。サーバエラーのＨＴＴＰ応答２６４（ｘ）は、サーバエラーのためＨＴＴＰ／１．ｘ要求２３２（ｘ）が成功しなかったことを示す。例えば、幾つかの実施形態では、サーバエラーのＨＴＴＰ応答２６４（ｘ）は、ＨＴＴＰステータスライン「５０２ Ｂａｄ Ｇａｔｅｗａｙ」を有する。５０２のステータスコードは、プロキシサーバ２４０がバックエンドサーバ２７０から無効な応答を受信したことを示す。

ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであり、プロキシアプリケーション２５０がバックエンドサーバ２７０から成功を示すＨＴＴＰ／２応答２６４（ｘ）を受信すれば、プロキシアプリケーション２５０はＨＴＴＰ／２応答２６４（ｘ）を破棄する。プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、ＨＴＴＰ／２応答２６４（ｘ）が成功を示しているかどうかを判定することができる。例えば、幾つかの実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰ／１要求２３２（ｘ）に関連する成功コードリストに基づいて、ＨＴＴＰ／２応答２６４（ｘ）が成功を示しているかどうかを判定する。ＨＴＴＰ／２応答２６４（ｘ）に含まれるステータスコードが、成功コードリストに含まれるステータスコードの１つに一致すれば、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（ｘ）が成功を示していることを判定する。一致しない場合、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（ｘ）が成功を示していないことを判定する。

ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであり、プロキシアプリケーション２５０がバックエンドサーバ２７０からＨＴＴＰ／２応答を受信しなければ、プロキシアプリケーション２５０は、パーシステンスレベルに従ってエラー処理プロセスを実行する。同様に、ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであり、プロキシアプリケーション２５０がバックエンドサーバ２７０から成功を示していないＨＴＴＰ／２応答２６４（ｘ）を受信すれば、プロキシアプリケーション２５０は、パーシステンスレベルに従ってエラー処理プロセスを実行する。

プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、任意の数および種類の許容可能なパーシステンスレベルに基づく、任意の数および種類のエラー処理プロセスを実施することができる。例えば、幾つかの実施形態では、許容可能なパーシステンスレベルは、「低」、「中」、「高」（デフォルトのパーシステンスレベル）、および「耐久性」である。ＨＴＴＰ／１．ｘ要求２３２（ｘ）のパーシステンスレベルが低であれば、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関して更なる操作を行わない。パーシステンスレベルが中であれば、プロキシアプリケーション２５０は、比較的短い間隔で最大で３回の再送信の試行を行う。再送信の試行は、ＨＴＴＰ／２要求２６２（ｘ）をバックエンドサーバ２７０に再送信する試行である。

パーシステンスレベルが高であれば、プロキシアプリケーション２５０は、成功を示すＨＴＴＰ／２応答２６４（ｘ）をバックエンドサーバ２７０から受信するまで、再送信の試行を行う。なお、最大オフロード同時処理数に到達すれば、プロキシアプリケーション２５０は、もはやオフロードをアクティブにせず、代わりに同期プロキシ操作を行う。その結果、パーシステンスレベルが高であるので、プロキシアプリケーション２５０にバックログは生じない。

パーシステンスレベルが耐久性であれば、プロキシアプリケーション２５０は、再起動を越えて存続するためにＨＴＴＰ／２要求２６２（ｘ）を持続的なストレージ（例えば、ディスク）に書き込み、成功を示すＨＴＴＰ／２応答２６４（ｘ）をプロキシアプリケーション２５０がバックエンドサーバ２７０から受信するまで、再送信の試行を行う。エラー処理プロセス中の任意の時点で、成功を示すＨＴＴＰ／２応答２６４（ｘ）をプロキシアプリケーション２５０がバックエンドサーバ２７０から受信すると、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（ｘ）を破棄し、エラー処理プロセスを終了する。

各クライアントアプリケーション２２０は、技術的に実現可能な任意の手法で、各ＨＴＴＰ／１．ｘ要求２３２のパーシステンスレベルを判定することができる。例えば、幾つかの実施形態では、ハートビートが比較的頻繁に発生するので、クライアントアプリケーション２２０は、ハートビートのアップロードを伴う各ＨＴＴＰ／１．ｘ要求２３２に、低のパーシステンスレベルを指定するパーシステンスヘッダを含める。イベントログおよびメトリックログは典型的には頻繁に生成されないため、クライアントアプリケーション２２０は、イベントログまたはメトリックログのアップロードを伴うＨＴＴＰ／１．ｘ要求２３２にパーシステンスヘッダを含めず、これによって関連するパーシステンスレベルを高にデフォルト設定する。

説明のみを目的として、図２は、クライアントアプリケーション２２０（１）、プロキシアプリケーション２５０、およびバックエンドサーバ２７０の間の一連の対話を、一連の丸囲み番号として示す。クライアントアプリケーション２２０（１）は、クライアントデバイス１０４（１）上で実行され、最大で３つの接続２０４（１）を有する。

ネットワークベースのサービスシステム１０２と対話するために、クライアントアプリケーション２２０（１）は、４つのＨＴＴＰ／１．ｘ要求２３２（１）～２３２（４）を生成する。ＨＴＴＰ／１．ｘ要求２３２（１）～２３２（４）はそれぞれ、ネットワークベースのサービスシステム１０２をホストとして指定する。ＨＴＴＰ／１．ｘ要求２３２（１），２３２（２），２３２（４）はそれぞれダウンロードの要求であり、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含まない。対照的に、ＨＴＴＰ／１．ｘ要求２３２（３）は、イベントログのアップロードの要求であり、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含む。この場合、クライアントアプリケーション２２０（１）は、プロキシアプリケーション２５０へのＨＴＴＰ／１．ｘ要求２３２（１）～２３２（４）の送信を試行する。

クライアントアプリケーション２２０（１）が最大で３つのＴＣＰ接続に制限されるため、クライアントデバイス１０４は、ＨＴＴＰ／１．ｘ要求２３２（１）～２３２（３）のための３つのクライアント／プロキシＴＣＰ接続２３０（１）～（３）をそれぞれ生成する。ＨＴＴＰ／１．ｘ要求２３２がそれぞれ専用のクライアント／プロキシＴＣＰ接続２３０を要し、利用可能なクライアント／プロキシＴＣＰ接続２３０が全て使用中であるため、ＨＴＴＰ／１．ｘ要求２３２（４）の送信は遅延してしまう。

ＨＴＴＰ／１．Ｘ要求２３２（ｘ）のためのクライアント／プロキシＴＣＰ接続２３０（ｘ）を生成するために、クライアントデバイス１０４（１）およびプロキシサーバ２４０は、ＴＣＰハンドシェイクに続いてトランスポート層セキュリティ（「ＴＬＳ」）ハンドシェイクを行う。ＴＣＰハンドシェイクは、クライアントデバイス１０４とプロキシサーバ２４０とが、互いに通信するためのＴＣＰ通信セッションをネゴシエートして開始するためのメカニズムである。ＴＬＳハンドシェイクは、クライアントデバイス１０４（１）とプロキシサーバ２４０とが、安全な通信セッションを確立するために必要なセキュリティキーを交換するメカニズムである。

丸囲みの１～３番で示されているように、プロキシアプリケーション２５０は、それぞれクライアント／プロキシＴＣＰ接続２３０（１）～２３０（３）を介してＨＴＴＰ／１．ｘ要求２３２（１）～２３２（３）を受信する。プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（３）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含み、現在のオフロード同時処理総数が最大オフロード同時処理数よりも少ないことを判定する。したがって、丸囲みの４番で示されているように、プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（３）についてオフロードをアクティブにし、ＨＴＴＰステータスライン「２００ ＯＫ」を含むＨＴＴＰ／１．ｘ応答２３４（３）を、クライアント／プロキシＴＣＰ接続２３０（３）を介してクライアントアプリケーション２２０（１）に送信する。

プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（１）～２３２（３）をそれぞれＨＴＴＰ／２要求２６２（１）～２６２（３）に変換し、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（１）～２６２（３）の送信を試行する。有利には、プロキシサーバ２４０とバックエンドサーバ２７０とは、ＴＣＰハンドシェイクおよびＴＬＳハンドシェイクを従前に行って、予め確立され予め認証された任意の数のプロキシ／バックエンドＴＣＰ接続２６０を生成している。さらに、プロキシサーバ２４０とバックエンドサーバ２７０との間のトラフィック量が比較的多いことに起因して、プロキシ／バックエンドＴＣＰ接続２６０は持続的である。その結果、プロキシサーバ２４０は、追加のハンドシェイクを行うことなく、プロキシ／バックエンドＴＣＰ接続２６０（１）を介してバックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（１）～２６２（３）の送信を開始する。より正確には、プロキシサーバ２４０は、ＨＴＴＰ／２要求２６２（１）～２６２（３）と、任意の数の他のＨＴＴＰ／２要求２６２および／またはＨＴＴＰ／２応答２６４とを、プロキシ／バックエンドＴＣＰ接続２６０（１）上で多重化する。

クライアントアプリケーション２２０（１）がＨＴＴＰ／１．ｘ応答２３４（３）を受信すると、クライアントデバイス１０４（１）は、遅延したＨＴＴＰ／１．ｘ要求２３２（４）のためにクライアント／プロキシＴＣＰ接続２３０（３）を再生成する（例えば、閉じて再確立し再認証する）。代替的な実施形態では、クライアントデバイス１０４（１）は、クライアント／プロキシＴＣＰ接続２３０（３）を閉じて再確立し再認証することなく、遅延したＨＴＴＰ／１．ｘ要求２３２（４）のためにクライアント／プロキシＴＣＰ接続２３０（３）を再使用してもよい。次いで、クライアントデバイス１０４（１）は、クライアント／プロキシＴＣＰ接続２３０（３）を介してプロキシサーバ２４０へのＨＴＴＰ／１．ｘ要求２３２（４）の送信を開始する。

有利には、プロキシサーバ２４０は、バックエンドサーバ２７０に比べて、クライアントデバイス１０４（１）に物理的に近い。そのため、丸囲みの５番で示されているように、プロキシアプリケーション２５０は、ＨＴＴＰ／２要求２６２（１）～２６２（３）がバックエンドサーバ２７０に到達する前に、ＨＴＴＰ／１．ｘ要求２３２（４）を受信する。プロキシアプリケーション２５０は、ＨＴＴＰ／１．ｘ要求２３２（４）をＨＴＴＰ／２要求２６２（４）に変換し、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（４）の送信を試行する。プロキシサーバ２４０は、ＨＴＴＰ／２要求２６２（４）と、ＨＴＴＰ／２要求２６２（１）～２６２（３）および任意の数の他のＨＴＴＰ／２要求２６２および／またはＨＴＴＰ／２応答２６４とを、プロキシ／バックエンドＴＣＰ接続２６０（１）上で多重化する。

その後、丸囲みの６～８番で示されているように、バックエンドサーバ２７０は、プロキシ／バックエンドＴＣＰ接続２６０（１）を介して、ＨＴＴＰ／２要求２６２（１），２６２（２）および２６２（４）を受信する。ＨＴＴＰ／２要求２６２（３）は、アップロードを伴うため、バックエンドサーバ２７０への到達までにより長い時間を要する。バックエンドサーバ２７０は、ＨＴＴＰ／２要求２６２（１），２６２（２）および２６２（４）を処理し、ＨＴＴＰ／２応答２６４（１），２６４（２）および２６４（４）をそれぞれ生成する。バックエンドサーバ２７０は、プロキシ／バックエンドＴＣＰ接続２６０（１）を介してプロキシアプリケーション２５０へのＨＴＴＰ／２応答２６４（１），２６４（２）および２６４（４）の送信を開始する。

丸囲みの９～１１番で示されているように、プロキシアプリケーション２５０は、プロキシ／バックエンドＴＣＰ接続２６０（１）を介して、ＨＴＴＰ／２応答２６４（１），２６４（２）および２６４（４）を有効に受信する。ＨＴＴＰ／１．ｘ要求２３２（１），２３２（２）および２３２（４）についてオフロードがアクティブでないため、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（１），２６４（２）および２６４（４）をそれぞれＨＴＴＰ／１．ｘ応答２３４（１），２３４（２）および２３４（４）に変換する。次いで、プロキシアプリケーション２５０は、クライアント／プロキシＴＣＰ接続２３０（１）を介したＨＴＴＰ１．ｘ応答２３４（１）の送信、クライアント／プロキシＴＣＰ接続２３０（２）を介したＨＴＴＰ１．ｘ応答２３４（２）の送信、およびクライアント／プロキシＴＣＰ接続２３０（３）を介したＨＴＴＰ１．ｘ応答２３４（４）の送信を開始する。

ＨＴＴＰ／１．ｘ応答２３４（１），２３４（２）および２３４（４）がクライアントアプリケーション２２０（１）に伝わっている間、バックエンドサーバ２７０は、ＨＴＴＰ／２要求２６２（３）を受信する（丸囲みの１２番で示している）。バックエンドサーバ２７０は、ＨＴＴＰ／２要求２６２（３）を処理し、ＨＴＴＰ／２応答２６４（３）を生成し、プロキシ／バックエンドＴＣＰ接続２６０（１）を介してプロキシアプリケーション２５０へのＨＴＴＰ／２応答２６４（３）の送信を開始する。

丸囲みの１３～１５番で示されているように、ＨＴＴＰ／２応答２６４（３）がプロキシアプリケーション２５０に伝わっている間に、クライアントアプリケーション２２０（１）は、ＨＴＴＰ／１．ｘ応答２３４（１），２３４（２）および２３４（４）を受信する。その後、丸囲みの１６番で示されているように、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（３）を受信する。ＨＴＴＰ／１．ｘ要求２３２（３）についてオフロードがアクティブであり、バックエンドサーバ２７０がＨＴＴＰ／１．ｘ要求２３２（３）の処理に成功したことをＨＴＴＰ／２応答２６４（３）が示すため、プロキシアプリケーション２５０は、ＨＴＴＰ／２応答２６４（３）を破棄する。

説明のみを目的として、図２～図３は、ＴＣＰ接続および特定バージョンのＨＴＴＰプロトコルの文脈でシステム１００の機能を説明する。しかし、本明細書に記載される技術は、限定的でなく例示的なものであり、本発明のより広義の趣旨および範囲から逸脱することなく改変可能である。記載している実施形態および技術の範囲および趣旨から逸脱しない多くの変更および変形が当業者にとって明らかであろう。

一般的な事項として、本明細書に概説される技術は、ネットワークベースのサービスに要求を送信する前に、ネットワークベースのサービスのための選択された要求に応じて、有効な包括的応答を返すことに適用可能である。代替的な実施形態では、要求および応答は、任意の数および種類の伝送プロトコルに準拠し、任意の数および種類の接続を介して送信されてもよい。一般に、クライアントアプリケーション２２０から受信されたＨＴＴＰ要求に応答するとき、プロキシアプリケーション２５０は、ＨＴＴＰフォーマットのＨＴＴＰ要求でクライアントアプリケーション２２０へのＨＴＴＰ応答を生成または中継する。ＨＴＴＰ要求をバックエンドサーバ２７０に中継するとき、プロキシアプリケーションは、バックエンドサーバ２７０へのあるバージョンのＨＴＴＰ要求の最も効率的な送信を確実にするために、ＨＴＴＰ要求に任意の数の変換操作を行うことができる。

例えば、幾つかの代替的な実施形態では、任意の数のクライアントアプリケーション２２０がＨＴＴＰ／２を実装する。ＨＴＴＰ／２要求２６２（ｘ）を生成するとき、クライアントアプリケーションは、対応するＨＴＴＰ／２応答２６４（ｘ）が重要でないことを示すために、ＨＴＴＰ／２要求２６２（ｘ）にｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを追加することができる。プロキシアプリケーション２５０は、ＨＴＴＰ／２要求２６２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを有するかどうか、および最大オフロード同時処理数に基づいて、ＨＴＴＰ／２要求２６２（ｘ）についてオフロードをアクティブにするかどうかを判定する。ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであれば、プロキシアプリケーション２５０は、有効な包括的ＨＴＴＰ／２応答２６４をクライアントアプリケーション２２０に送信する。ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであるかどうかにかかわらず、プロキシアプリケーション２５０は、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（ｘ）の送信を試行する。ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブであれば、プロキシアプリケーション２５０は、バックエンドサーバ２７０から受信したＨＴＴＰ／２応答２６４（ｘ）を破棄する。ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブでなく、プロキシアプリケーション２５０がＨＴＴＰ／２要求２６２（ｘ）をバックエンドサーバ２７０に送信できなければ、プロキシアプリケーション２５０は、サーバエラーのＨＴＴＰ／２応答をクライアントアプリケーション２２０に送信する。そうでなく、ＨＴＴＰ／２要求２６２（ｘ）についてオフロードがアクティブでなければ、プロキシアプリケーション２５０は、バックエンドサーバ２７０から受信したＨＴＴＰ／２応答２６４（ｘ）をクライアントアプリケーション２２０に送信する。

代替的な実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダおよびパーシステンスヘッダは、技術的に実現可能な任意の手法で指定され、任意の量および種類の関連情報を含むことができる。例えば、幾つかの実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、成功コードリストを指定しない。そのような実施形態では、プロキシアプリケーション２５０は、技術的に実現可能な任意の手法で、各ＨＴＴＰ／２応答２６４が成功を示しているかどうかを判定することができる。例えば、プロキシアプリケーション２５０は、所定の成功コードリストを実装することができる。同じまたは他の実施形態では、パーシステンスヘッダが実装されず、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、任意でパーシステンスレベルを指定する。

図３は、本発明の様々な実施形態による、図２のプロキシアプリケーション２５０のより詳細な図である。説明のみを目的として、図３は、Ｇｏプログラミング言語で書かれたプロキシアプリケーション２５０の例を説明する。しかし、本明細書に記載される技術は、限定的でなく例示的なものであり、本発明のより広義の趣旨および範囲から逸脱することなく改変可能である。特に、プロキシアプリケーション２５０は、任意の数および種類のアルゴリズムを実行することができ、技術的に実現可能な任意の数（１つを含む）のプログラミング言語および／またはスクリプト言語で記述することができる。

図示されているように、プロキシアプリケーション２５０は、限定されないが、ＨＴＴＰライブラリ層３１０、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔプロキシハンドラ３２０、任意の数のハンドラ３３０、およびプロキシハンドラ３４０を含む。ＨＴＴＰライブラリ層３１０は、プロキシサーバ２４０への各ＨＴＴＰ／１．ｘ要求２３２を異なる実行スレッドとして受信するように構成される。ＨＴＴＰ／１．ｘ要求２３２（ｘ）を受信すると、ＨＴＴＰライブラリ層３１０は、関連する実行スレッドの制御を、ネストされたＨＴＴＰハンドラの双方向パイプラインに転送する。

双方向パイプラインは、順方向で順に、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔプロキシハンドラ３２０、任意の数のハンドラ３３０、およびプロキシハンドラ３４０を含む。代替的な実施形態では、任意の数のハンドラ３３０がパイプライン内でｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔプロキシハンドラ３２０に先行してもよいし、任意の数のハンドラ３３０がパイプライン内でプロキシハンドラ３４０に後続してもよい。

ＨＴＴＰハンドラはそれぞれ、２つの引数、ｈｔｔｐ．ＲｅｓｐｏｎｓｅＷｒｉｔｅｒとｈｔｔｐ．Ｒｅｑｕｅｓｔへのポインタを有するｈｔｔｐ．ＨａｎｄｌｅｒＦｕｎｃ型である。ｈｔｔｐ．Ｒｅｑｕｅｓｔは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）を表すデータ構造である。ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に対するＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成して送信する。ＨＴＴＰハンドラがｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒにデータを書き込めば、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）が受信されたクライアント／プロキシＴＣＰ接続２３０を介して、対応するＨＴＴＰ／１．ｘ応答２３４（ｘ）を送信する。加えて、パイプライン内の様々なＨＴＴＰハンドラが、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に対するＨＴＴＰ応答を表すｈｔｔｐ．Ｒｅｓｐｏｎｓｅデータ構造にアクセスする。

ＨＴＴＰハンドラはそれぞれ、ＨＴＴＰ／１．ｘ要求２３２（ｘ）および／またはＨＴＴＰ／２要求２６２（ｘ）に関連する任意の数および種類の操作をｈｔｔｐ．Ｒｅｑｕｅｓｔによって行うことができる。同様に、ＨＴＴＰハンドラはそれぞれ、ＨＴＴＰ／１．ｘ応答２３４（ｘ）および／またはＨＴＴＰ／２応答２６４（ｘ）に関連する任意の数および種類の操作をｈｔｔｐ．Ｒｅｓｐｏｎｓｅによって行うことができる。また、ＨＴＴＰハンドラはそれぞれ、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒへの書き込み、いずれかの方向でのパイプライン内の次のＨＴＴＰハンドラへの制御の転送、パイプラインを通じた制御の伝播の停止などを行うことができる。

ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関連する実行スレッドがＨＴＴＰライブラリ層３１０に入ると、ＨＴＴＰライブラリ層３１０は、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒと、ＨＴＴＰ／１．ｘ要求２３２（ｘ）を表すｈｔｔｐ．Ｒｅｑｕｅｓｔとを生成する。次いで、ＨＴＴＰライブラリ層３１０は、パイプライン内の最初のＨＴＴＰハンドラに制御を転送して、順方向の伝播を開始する。図３に示す実施形態では、パイプライン内の最初のＨＴＴＰハンドラは、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０である。

図示されているように、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、限定されないが、ＨＴＴＰヘッダトリガ３２４、最大オフロード同時処理数３２２、およびオフロード操作３２６を含む。ＨＴＴＰヘッダトリガ３２４は、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを区別する名称「Ｆｉｒｅ－ａｎｄ－Ｆｏｒｇｅｔ」を指定する。最大オフロード同時処理数３２２は、任意の所与の時間でオフロードをアクティブにすることができるＨＴＴＰ／１．ｘ要求２３２（すなわち、スレッド）の最大数を指定する。オフロード操作３２６は、実行スレッドのオフロードがアクティブであるときに実行されるｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０における操作である。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が実行スレッドの制御を受け取ると、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰヘッダトリガ３２４に基づいて、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいるかどうかを判定する。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいないことを判定すれば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、順方向のパススルーとして機能する。より正確には、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６を実行することなく、順方向でパイプライン内の次のハンドラ３３０（１）に制御を転送する。

しかし、ＨＴＴＰ／１．ｘ要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいることをｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が判定した場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、最大オフロード同時処理数３２２に基づき、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにするかどうかを判定する。一般に、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロードがアクティブであるＨＴＴＰ／１．ｘ要求２３２の総数を、最大オフロード同時処理数３２２に制限する。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、技術的に実現可能な任意の手法で、オフロードがアクティブであるＨＴＴＰ／１．ｘ要求２３２の総数を追跡し制限することができる。例えば、幾つかの実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＧＯ言語の同時処理機能（例えば、チャネル）を使用して、任意の所与の時間にオフロードがアクティブであるスレッドの総数を制限することができる。他の実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロードがアクティブである実行スレッドのカウントを維持し、そのカウントを最大オフロード同時処理数３２２と比較することもできる。カウントが最大オフロード同時処理数３２２と等しければ、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードをアクティブにせず、順方向のパススルーとして機能する。より正確には、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６を実行することなく、順方向でパイプライン内の次のハンドラ３３０（１）に制御を転送する。

代替的な実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、技術的に実現可能な任意の手法で、ＨＴＴＰ／要求２３２（ｘ）についてオフロードをアクティブにすることができる。例えば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／要求２３２（ｘ）に関連するオフロードフラグを偽に初期化することができる。ＨＴＴＰ／要求２３２（ｘ）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含み、オフロードがアクティブであるＨＴＴＰ要求の総数が最大オフロード同時処理数３２２よりも少なければ、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０はオフロードフラグを真に設定する。オフロードフラグが偽であれば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０はオフロード操作３２６を実行しない。偽でなければ、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０はオフロード操作３２６を実行する。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が実行スレッドの制御を保持していれば、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードがアクティブであり、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６の実行を開始する。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成する。次いで、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）をｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒに書き込む。これに応じて、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）が受信されたクライアント／プロキシＴＣＰ接続２３０を介して、有効な包括的ＨＴＴＰ／１．ｘ応答２３４（ｘ）を送信する。なお、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒへの書き込みは、実行スレッドに関して非停止操作である。ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒへの書き込み後、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、実行スレッドの制御を順方向でパイプライン内の次のハンドラ３３０（１）に転送する。

ハンドラ３３０はそれぞれ、実行スレッドの制御をパイプライン内の次のＨＴＴＰハンドラに転送する前に、任意の数および種類の操作を行うことができる。実行スレッドの制御がプロキシハンドラ３４０に転送されると、プロキシハンドラ３４０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）をＨＴＴＰ／２要求２６２（ｘ）に変換する。次いで、プロキシハンドラ３４０は、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（ｘ）の送信を試行する。バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（ｘ）の送信により、プロキシハンドラ３４０がＨＴＴＰ／２応答２６４（ｘ）を受信するか、またはバックエンドサーバ２７０が対応するＨＴＴＰ／２応答を送信できないとプロキシハンドラ３４０が判定するまで、実行スレッドが停止される。バックエンドサーバ２７０が対応するＨＴＴＰ／２応答を送信できないとプロキシハンドラ３４０が判定すれば、プロキシハンドラ３４０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関連する成功コードリストに含まれていないステータスコードを有するサーバエラーのＨＴＴＰ／２応答２６４（ｘ）を生成する。その後、プロキシハンドラ３４０は、実行スレッドの制御を、プロキシハンドラ３４０が制御を受け取ったＨＴＴＰハンドラに戻し、これにより逆方向でパイプラインの伝播を開始する。

実行スレッドの制御がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０に戻されると、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６の外または内のいずれかで実行を再開する。ＨＴＴＰ／要求２３２（ｘ）についてオフロードがアクティブでなければ、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６の外で実行を再開する。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／２応答２６４（ｘ）をＨＴＴＰ／１．ｘ応答２３４（ｘ）に変換する。次いで、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／１．ｘ応答２３４（ｘ）をｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒに書き込む。これに応じて、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒは、ＨＴＴＰ／１．ｘ要求２３２（ｘ）が受信されたクライアント／プロキシＴＣＰ接続２３０を介して、ＨＴＴＰ／１．ｘ応答２３４（ｘ）を送信する。

しかし、ＨＴＴＰ／１．ｘ要求２３２（ｘ）についてオフロードがアクティブである場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０はオフロード操作３２６内で実行を再開する。ＨＴＴＰ／２応答２６４（ｘ）のステータスコードが成功を示していれば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、実行スレッドを終了する。成功を示していない場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関連するパーシステンスレベルに対応するエラー処理手順を実行する。

本明細書で前述したように、ＨＴＴＰ／２応答２６４（ｘ）のステータスコードが、ＨＴＴＰ／１．ｘ要求２３２（ｘ）に関連する成功コードリストに含まれるステータスコードの１つに一致すれば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／２応答２６４（ｘ）が成功を示していることを判定する。一致しない場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／２応答２６４（ｘ）が成功を示していないことを判定する。一般に、バックエンドサーバ２７０は、ＨＴＴＰ／２応答２６４（ｘ）に任意のステータスコードを含めることができる。このため、ＨＴＴＰ／２応答２６４（ｘ）がバックエンドサーバ２７０によって生成されれば、ＨＴＴＰ／２応答２６４（ｘ）は、成功コードリストに従って成功を示してもよいし、示さなくてもよい。対照的に、バックエンドサーバ２７０がＨＴＴＰ／２要求２６２（ｘ）に応答できなかったことを示すＨＴＴＰ／２応答２６４（ｘ）がプロキシハンドラ３４０によって生成されれば、ＨＴＴＰ／２応答２６４（ｘ）は成功コードリストに従って成功を示さない。

エラー処理手順の実行の一部として、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０とプロキシハンドラ３４０との間で実行スレッドを繰り返し往復伝播させてもよい。エラー処理手順は、実行スレッドをイベントによって（eventfully）終了する。

本明細書に記載されるプロキシアプリケーション２５０が例示的なものであり、変形および変更が可能であることが理解されるであろう。例えば、代替的な実施形態では、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、技術的に実現可能な任意の手法で、ＨＴＴＰ／要求２３２（ｘ）についてオフロードがアクティブであるかどうかをプロキシハンドラ３４０に示すことができる。ＨＴＴＰ／要求２３２（ｘ）についてオフロードがアクティブでなければ、プロキシハンドラ３４０は、ＨＴＴＰ／１．ｘ応答２３４（ｘ）を生成し、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒに書き込む。次いで、プロキシハンドラ３４０は実行スレッドを終了する。

説明のみを目的として、図３は、クライアントアプリケーション２２０（１）から受信される、図２のＨＴＴＰ／１．ｘ要求２３２（３）に関連する実行スレッドの制御を、一連の丸囲み番号として示す。ＨＴＴＰ／１．ｘ要求２３２（３）は、限定されないが、要求ライン、ＨＯＳＴヘッダ、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダ、およびボディを含む。要求ラインは、ＰＯＳＴメソッド、要求ターゲット「／ｕｐｌｏａｄ」、プロトコルバージョンＨＴＴＰ／１．１を指定する。ＰＯＳＴメソッドは、要求ターゲット「／ｕｐｌｏａｄ」を作成または修正するために、ＨＴＴＰ／１．ｘ要求２３２（３）のボディ（図示せず）をバックエンドサーバ２７０に送る。ＨＯＳＴヘッダは、バックエンドサーバ２７０のドメイン名「ｗｗｗ．ＸＹＺ．ｃｏｍ」を指定する。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、名称「Ｆｉｒｅ－ａｎｄ－Ｆｏｒｇｅｔ」、および２００のステータスコードを含む成功コードリストを指定する。ＨＴＴＰ／１．ｘ要求２３２（３）は、パーシステンスヘッダを含まないため、ＨＴＴＰ／１．ｘ要求２３２（３）は、デフォルトの高のパーシステンスレベルに関連付けられる。

丸囲みの１番で示されているように、ＨＴＴＰ／１．ｘ要求２３２（３）に関連する実行スレッドは、ＨＴＴＰライブラリ層３１０に入る。ＨＴＴＰライブラリ層３１０は、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒと、ＨＴＴＰ／１．ｘ要求２３２（３）を表すｈｔｔｐ．Ｒｅｑｕｅｓｔとを生成して、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０に制御を転送する。ＨＴＴＰ／１．ｘ要求２３２（３）がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含むため、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、最大オフロード同時処理数３２２に基づいて、ＨＴＴＰ／１．ｘ要求２３２（３）についてオフロードをアクティブにするかどうかを判定する。説明のみを目的として、オフロードがアクティブであるＨＴＴＰ／１．ｘ要求２３２の総数は、最大オフロード同時処理数３２２よりも少ない。したがって、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／１．ｘ要求２３２（３）についてオフロードをアクティブにし、オフロード操作３２６の実行を開始する。

丸囲みの２番が示されているように、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ｈｔｔｐ．ｒｅｓｐｏｎｓｅＷｒｉｔｅｒを構成して、有効な包括的ＨＴＴＰ応答２３４（ｘ）を非停止態様でクライアントアプリケーション２２０（１）に送信する。この場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、実行スレッドを、プロキシハンドラ３４０が実行スレッドの制御を受け取るまで、パイプラインを通して順方向に伝播させる。プロキシハンドラ３４０は、ＨＴＴＰ／１．ｘ要求２３２（３）をＨＴＴＰ／２要求２６２（３）に変換する。

丸囲みの３番で示されているように、プロキシハンドラ３４０は、ＨＴＴＰ／２要求２６２（３）をバックエンドサーバ２７０に送信する。この場合、実行スレッドが、丸囲みの４番で示すＨＴＴＰステータスライン「５０４ Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔ」を指定するＨＴＴＰ／２応答２６４（３）を受信する。その後、プロキシハンドラ３４０は、実行スレッドを、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０に到達するまで、パイプラインを通して逆方向に伝播させる。

ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、オフロード操作３２６内で実行を再開する。ＨＴＴＰ／２応答２６４（３）が成功のステータスコードを指定していないため、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、高のパーシステンスレベルに対応するエラー処理プロセスを実行する。より具体的には、丸囲みの５番で示されているように、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、再送信の試行３２８を行う。再送信の試行３２８を実行するために、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、実行スレッドの制御をプロキシハンドラ３２０（１）に転送し、実行スレッドは、プロキシハンドラ３４０に到達するまで、パイプラインを通って順方向に再伝播する。

丸囲みの６番で示されているように、プロキシハンドラ３４０は、バックエンドサーバ２７０へのＨＴＴＰ／２要求２６２（３）の再送信を試行する。その後、丸囲みの７番で示されているように、プロキシハンドラ３４０は、ＨＴＴＰステータスライン「２００ ＯＫ」を指定するＨＴＴＰ／２応答２６４（３’）を受信する。プロキシハンドラ３４０は、実行スレッドを、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０に到達するまで、パイプラインを通して逆方向に再伝播させる。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、エラー処理プロセス内で実行を再開する。ＨＴＴＰ／２応答２６４（３’）のステータスコードが成功を示しているため、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は実行スレッドを終了する。

なお、本明細書に記載している技術は、限定的でなく例示的なものであり、本発明のより広義の趣旨および範囲から逸脱することなく改変可能であり、記載している実施形態および技術の範囲および趣旨から逸脱しない多くの変更および変形が当業者にとって明らかであろう。特に、プロキシアプリケーション２５０の機能は、技術的に実現可能な任意の手法で実施することができる。例えば、代替的な実施形態では、プロキシアプリケーション２５０は、ＨＴＴＰハンドラ機能のパイプラインの代わりに、任意の数（１つを含む）および種類の機能を含むことができる。

図４は、本発明の様々な実施形態による、ネットワークベースのサービスに関連する要求を処理するための方法ステップのフロー図である。図１～図３のシステムを参照して方法ステップを説明するが、当業者であれば、方法ステップを任意の順序で実施するように構成された任意のシステムが本発明の範囲に入ることを理解するであろう。

図示されているように、方法４００は、プロキシアプリケーション２５０がクライアントアプリケーション２２０の１つからＨＴＴＰ要求を受信する、ステップ４０２で始まる。ＨＴＴＰ要求は、ＨＴＴＰ／１．ｘフォーマット（すなわち、ＨＴＴＰ／１．ｘ要求２３２（ｘ））であってもよいし、ＨＴＴＰ／２フォーマット（すなわち、ＨＴＴＰ／２要求２６２（ｘ））であってもよい。ステップ４０４で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ要求がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを含んでいるかどうかに基づいて、任意で、最大オフロード同時処理数３２２にも基づいて、ＨＴＴＰ要求についてオフロードをアクティブにするかどうかを判定する。ステップ４０６で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ要求についてオフロードがアクティブであるかどうかを判定する。ステップ４０６で、ＨＴＴＰ要求についてオフロードがアクティブであることをｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が判定した場合、方法４００はステップ４０８に進む。

ステップ４０８で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ要求に関連するバージョンのＨＴＴＰで、有効な包括的ＨＴＴＰ応答をクライアントアプリケーション２２０に送信する。ステップ４１０で、プロキシハンドラ３４０は、バックエンドサーバ２７０への、ＨＴＴＰ要求に対応するＨＴＴＰ／２要求２６２の送信を試行する。ＨＴＴＰ要求に対応するＨＴＴＰ／２要求２６２は、ＨＴＴＰ要求であってよい。ステップ４１２で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、成功を示すＨＴＴＰ／２応答２６４をプロキシハンドラ３４０が受信したかどうかを判定する。ステップ４１２で、成功を示すＨＴＴＰ／２応答２６４をプロキシハンドラ３４０が受信したとｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が判定した場合、方法４００は終了する。

しかし、ステップ４１２で、成功を示すＨＴＴＰ／２応答２６４をプロキシハンドラ３４０が受信しなかったとｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が判定した場合、方法４００はステップ４１４に進む。ステップ４１４で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、パーシステンスレベルに基づいてエラー処理プロセスを実行する。パーシステンスレベルは、ＨＴＴＰ要求のパーシステンスヘッダで指定されるか、デフォルトのパーシステンスレベルに等しいかのいずれかである。エラー処理プロセスは、任意の数（ゼロを含む）の再送信の試行３２８を含んでもよい。次いで、方法４００は終了する。

ここでステップ４０６に戻ると、ＨＴＴＰ要求についてオフロードがアクティブでないとｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０が判定すれば、方法４００はステップ４１６に直接に進む。ステップ４１６で、プロキシハンドラ３４０は、バックエンドサーバ２７０への、ＨＴＴＰ要求に対応するＨＴＴＰ／２要求２６２の送信を試行する。ＨＴＴＰ要求に対応するＨＴＴＰ／２要求２６２はＨＴＴＰ要求であってよい。

ステップ４１８で、プロキシハンドラ３４０は、対応するＨＴＴＰ／２応答２６４がバックエンドサーバ２７０から受信されたかどうかを判定する。ステップ４１８で、対応するＨＴＴＰ／２応答２６４がバックエンドサーバ２７０から受信されたとプロキシハンドラ３４０が判定した場合、方法４００はステップ４２２に直接に進む。ステップ４１８で、対応するＨＴＴＰ／２応答２６４がバックエンドサーバ２７０から受信されなかったとプロキシハンドラ３４０が判定した場合、方法４００はステップ４２０に進む。ステップ４２０で、プロキシハンドラ３４０は、サーバエラーのＨＴＴＰ／２応答２６４を生成し、方法４００はステップ４２２に進む。

ステップ４２２で、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、あるバージョンのＨＴＴＰ／２応答２６４をクライアントアプリケーション２２０に送る。クライアントアプリケーション２２０から受信されたＨＴＴＰ要求がＨＴＴＰ／２フォーマットであれば、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／２応答２６４をクライアントアプリケーション２２０に送信する。ＨＴＴＰ／２フォーマットでない場合、ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔハンドラ３２０は、ＨＴＴＰ／２応答２６４をＨＴＴＰ／１．ｘ応答２３４に変換し、ＨＴＴＰ／１．ｘ応答２３４をクライアントアプリケーション２２０に送信する。次いで、方法４００は終了する。

まとめると、開示の技術を使用して、プロキシアプリケーションにより、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを実装するクライアントアプリケーションが、ネットワークベースのサービスにアクセスするためにバックエンドサーバと効率的に対話することを可能にすることができる。クライアントアプリケーションは、対応するＨＴＴＰ応答が重要でないことを示すために、情報提供用アップロードのためのＨＴＴＰ要求に「ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔ」ヘッダを追加することができる。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、成功とみなされるステータスコードの成功コードリストを指定する。ｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダは、デフォルトのパーシステンスレベルに関連付けられ、クライアントアプリケーションは、パーシステンスレベルを明示的に指定する「パーシステンス」ヘッダをＨＴＴＰ要求に追加することもできる。パーシステンスレベルは、ＨＴＴＰ要求を受信するバックエンドサーバにとっての重要度に相関する。

プロキシアプリケーションは、クライアントアプリケーションとバックエンドサーバとの間の仲介役として機能するプロキシサーバ上で実行される。クライアントアプリケーションからＨＴＴＰ要求を受信すると、プロキシアプリケーションは、ＨＴＴＰ要求についてオフロードをアクティブにするかどうかを判定する。ＨＴＴＰ要求がｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔヘッダを有し、最大オフロード同時処理数に到達していなければ、プロキシアプリケーションは、ＨＴＴＰ要求についてオフロードをアクティブにする。そうでない場合には、プロキシアプリケーションは、ＨＴＴＰ要求のｆｉｒｅ－ａｎｄ－ｆｏｒｇｅｔをアクティブにしない。

ＨＴＴＰ要求についてオフロードがアクティブであれば、プロキシアプリケーションは有効な包括的ＨＴＴＰ応答をクライアントに送信する。有効な包括的ＨＴＴＰ応答は、成功コードリストに含まれるステータスコードの１つを指定し、これにより、バックエンドサーバがＨＴＴＰ要求を有効に受信して処理したと意図的に誤って示す。この場合、プロキシアプリケーションは、バックエンドサーバへのＨＴＴＰ／２バージョンのＨＴＴＰ要求の送信を試行する。成功コードリストに従って成功を示すＨＴＴＰ／２応答をプロキシアプリケーションが受信すれば、プロキシアプリケーションは、ＨＴＴＰ／２応答を破棄する。受信しない場合、プロキシアプリケーションは、パーシステンスレベルに基づいてエラー処理プロセスを実行する。エラー処理プロセスは、任意の数の再送信の試行を含むことができる。

ＨＴＴＰ要求についてオフロードがアクティブでなければ、プロキシアプリケーションは、バックエンドサーバへのＨＴＴＰ／２バージョンのＨＴＴＰ／１．ｘ要求の送信を試行する。プロキシアプリケーションがバックエンドサーバからＨＴＴＰ／２応答を受信しなければ、プロキシアプリケーションは、サーバエラーのＨＴＴＰ／１．ｘ応答をクライアントアプリケーションに送信する。そうでない場合、プロキシアプリケーションは、バックエンドサーバから受信したＨＴＴＰ／１．ｘバージョンのＨＴＴＰ／２応答をクライアントアプリケーションに送信する。

先行技術に比べた開示の技術の少なくとも１つの技術的利点は、開示の技術により、ＨＴＴＰ／１．ｘ ｏｖｅｒ ＴＣＰを実装するクライアントアプリケーションのための情報提供型ＨＴＴＰトランザクションによって対話型ＨＴＴＰトランザクションが遅延する可能性が低くなる点にある。特に、クライアントアプリケーションから送信された情報提供型ＨＴＴＰトランザクションにプロキシサーバが応答するとすぐに、クライアントアプリケーションは、バックエンドサーバからの応答を待つ必要なしに、関連するＴＣＰ接続を閉じるかまたは再使用することができる。したがって、クライアントアプリケーションが利用可能なＴＣＰ接続を全て情報提供型ＨＴＴＰトランザクションに使用し、対話型ＨＴＴＰトランザクションの送信および処理を遅延させる可能性が低くなる。さらに、その後にバックエンドサーバへの情報提供型ＨＴＴＰトランザクションに関連する情報のアップロードをプロキシサーバが試行するため、情報が欠落してしまう可能性が増大しない。また、プロキシサーバが、予め確立され予め認証されたＴＣＰ接続を使用してＨＴＴＰ／２を介してバックエンドサーバと通信するので、クライアントアプリケーションとバックエンドサーバとの間の通信時間が短縮される。これらの技術的利点は、先行技術のアプローチに対する１つ以上の技術的進歩を表すものである。

１． 幾つかの実施形態では、方法は、クライアントアプリケーションから受信された第１の要求が、第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定するステップと、第１の要求をサーバマシンに送信する前に、サーバマシンが第１の要求の処理に成功したことを示す、第１の要求に対する第１の応答を、クライアントアプリケーションに送信するステップとを含み、第１の応答を受信したことに応じて、クライアントアプリケーションが第２の要求を開始することが可能となる。

２． 第１の要求は、サーバマシンが第１の要求の処理に成功したことを示すステータスコードを含む、条項１記載の方法。

３． 第１の要求は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）／１．ｘに関連しており、第１の要求をサーバマシンに送信するステップが、第１の要求に基づいて、ＨＴＴＰ／２に関連する第２の要求を生成するステップと、第２の要求とＨＴＴＰ／２に関連する少なくとも第３の要求とを、サーバマシンへの第１のＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続上で多重化するステップとを含む、条項１または２記載の方法。

４． 方法は、サーバマシンが第１の要求の処理に成功していないことを判定するステップと、第１の要求が第１のパーシステンスレベルを示していることを判定するステップと、第１のパーシステンスレベルに基づいて１つ以上のエラー処理操作を行うステップであって、１つ以上のエラー処理操作によりサーバマシンに第１の要求を有効に処理させるステップとをさらに含む、条項１から３までのいずれか１項記載の方法。

５． 第１の要求が第１のパーシステンスレベルを示していることを判定するステップは、第１の要求が、第１のパーシステンスレベルに相当するパーシステンスパラメータの値を指定するヘッダ部分を含んでいることを判定することを含む、条項１から４までのいずれか１項記載の方法。

６． 第１の要求は、サーバマシンにアップロードされる情報提供データを含む、条項１から５までのいずれか１項記載の方法。

７． 第１の要求に対する第２の応答をサーバマシンから受信するステップと、第２の応答をクライアントアプリケーションに送信する代わりに、第２の応答を破棄するステップとをさらに含む、条項１から６までのいずれか１項記載の方法。

８． クライアントアプリケーションが、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続を介して第１の応答を受信し、ＴＣＰ接続を再使用または再生成して第２の要求を開始する、条項１から７までのいずれか１項記載の方法。

９． 方法は、クライアントアプリケーションから受信された第２の要求が、第２の要求に対する応答をサーバマシンからオフロードできることを示していないことを判定するステップと、第２の要求をサーバマシンに直接に送信するステップと、第２の要求に対する第２の応答をサーバマシンから受信したことに応じて、第２の応答をクライアントアプリケーションに送信するステップとをさらに含む、条項１から８までのいずれか１項記載の方法。

１０． 第１の要求に対する応答をオフロードできることを第１の要求が示していることを判定するステップは、第１の要求に対する応答が重要でないことを示すヘッダ部分を第１の要求が含んでいると識別することを含む、条項１から９までのいずれか１項記載の方法。

１１． 幾つかの実施形態では、１つ以上の非一時的なコンピュータ可読媒体が、プロセッサによって実行される際に、プロセッサに、クライアントアプリケーションから受信された第１の要求をサーバマシンからオフロードできることを判定するステップと、第１の要求をサーバマシンに送信する前に、サーバマシンが第１の要求の処理に成功したことを示す、第１の要求に対する第１の応答を、クライアントアプリケーションに送信するステップとを行わせるための命令を含み、第１の応答を受信したことに応じて、クライアントアプリケーションが第２の要求を開始することが可能となる。

１２． 第１の要求は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）／１．ｘに関連しており、第１の要求をサーバマシンに送信するステップが、第１の要求に基づいて、ＨＴＴＰ／２に関連する第２の要求を生成するステップと、第２の要求とＨＴＴＰ／２に関連する少なくとも第３の要求とを、サーバマシンへの第１のＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続上で多重化するステップとを含む、条項１１記載の１つ以上の非一時的なコンピュータ可読媒体。

１３． サーバマシンが第１の要求の処理に成功していないことを判定するステップと、第１の要求が第１のパーシステンスレベルを示していることを判定するステップと、第１のパーシステンスレベルに基づいて１つ以上のエラー処理操作を行うステップであって、１つ以上のエラー処理操作によりサーバマシンに第１の要求を有効に処理させるステップとをさらに含む、条項１１または１２記載の１つ以上の非一時的なコンピュータ可読媒体。

１４． １つ以上のエラー処理操作は、第１の要求を持続的なストレージに記憶する１つ以上の書き込み操作を含む、条項１１から１３までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

１５． 第１の要求は、イベントログ、クライアントアプリケーションが適切に実行されていることを示すハートビート、およびメトリックログのうちの少なくとも１つを含む、条項１１から１４までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

１６． 第１の要求に対する第２の応答をサーバマシンから受信するステップと、第２の応答をクライアントアプリケーションに送信する代わりに、第２の応答を破棄するステップとをさらに含む、条項１１から１５までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

１７． クライアントアプリケーションが、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続を介して第１の応答を受信し、ＴＣＰ接続を再使用または再生成して第２の要求を開始する、条項１１から１６までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

１８． クライアントアプリケーションから受信された第２の要求をサーバマシンからオフロードできることを判定するステップと、現在のオフロード同時処理数が最大オフロード同時処理数に等しいことを判定するステップと、第２の要求をサーバマシンに直接に送信するステップと、第２の要求に対する第２の応答をサーバマシンから受信したことに応じて、第２の応答をクライアントアプリケーションに送信するステップとをさらに含む、条項１１から１７までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

１９． 第１の要求をオフロードできることを判定するステップが、第１の要求に対する応答が重要でないことを示すヘッダ部分を第１の要求が含んでいることを識別することを含む、条項１１から１８までのいずれか１項記載の１つ以上の非一時的なコンピュータ可読媒体。

２０． 幾つかの実施形態では、システムが、命令を記憶する１つ以上のメモリと、１つ以上のメモリに結合された１つ以上のプロセッサとを備え、１つ以上のプロセッサが、命令を実行する際に、クライアントアプリケーションから第１の接続を介して受信された第１の要求が、第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定し、第１の要求をサーバマシンに送信する前に、サーバマシンが第１の要求の処理に成功したことを示す、第１の要求に対する第１の応答を、クライアントアプリケーションに送信するように構成されており、第１の応答を受信したことに応じて、クライアントアプリケーションが第１の接続を再使用または再生成して第２の要求を開始することが可能となる。

いずれかの請求項に記載される請求項の要素および／または本出願に記載しているいずれかの要素のあらゆる任意のまた全ての組み合わせが、本発明および保護の企図された範囲内に入る。

様々な実施形態の説明は、例示を目的として提示しているものであり、網羅的な提示または開示している実施形態への限定を意図するものでない。記載している実施形態の範囲および趣旨から逸脱しない多くの変更および変形が当業者にとって明らかであろう。

本実施形態の態様は、システム、方法、またはコンピュータプログラム製品として具現化することができる。したがって、本開示の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形態をとることができ、本明細書では、これらは全て「モジュール」、「システム」、または「コンピュータ」と総称する場合がある。加えて、本開示に記載される任意のハードウェアおよび／またはソフトウェア技術、プロセス、機能、構成要素、エンジン、モジュール、またはシステムは、回路または回路のセットとして実装することができる。さらに、本開示の態様は、コンピュータ可読プログラムコードが具現化された１つ以上のコンピュータ可読媒体に具現化されたコンピュータプログラム製品の形態をとることができる。

１つ以上のコンピュータ可読媒体の任意の組み合わせを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であってよい。コンピュータ可読記憶媒体は、例えば、限定されないが、電子的な、磁気的な、光学的な、電磁的な、赤外線的な、もしくは半導体のシステム、装置、もしくはデバイス、またはこれらの任意の適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な例（非排他的なリスト）としては、１本以上の電線を有する電気接続部、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能なプログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、光学記憶装置、磁気記憶装置、またはこれらの任意の適切な組み合わせを挙げることができよう。本文書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置もしくはデバイスによってまたはこれらに関連して使用されるプログラムを含むこと、または記憶することができる任意の有形の媒体であってよい。

本開示の態様は、本開示の実施形態による方法、装置（システム）、およびコンピュータプログラム製品のフローチャート図および／またはブロック図を参照して上述されている。フローチャート図および／またはブロック図の各ブロック、ならびにフローチャート図および／またはブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実施できることが理解されるであろう。これらのコンピュータプログラム命令は、機械を製造するために、汎用コンピュータ、特殊目的用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供することができる。命令は、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサによって実行される際に、フローチャートおよび／またはブロック図の１つ以上のブロックに指定された機能／行為の実施を可能にする。このようなプロセッサは、限定されないが、汎用プロセッサ、特殊目的用プロセッサ、特定用途向けプロセッサ、またはフィールドプログラマブルゲートアレイであってよい。

図中のフローチャートおよびブロック図は、本開示の様々な実施形態によるシステム、方法、およびコンピュータプログラム製品の可能な実施のアーキテクチャ、機能、および動作を例示するものである。これに関連して、フローチャートまたはブロック図の各ブロックは、指定された論理的機能を実施するための１つ以上の実行可能な命令を含むコードのモジュール、セグメントまたは部分を表すことができる。なお、幾つかの代替的な実施形態では、ブロックに記載される機能が、図に記載される順序以外で行われる場合がある。例えば、連続して示される２つのブロックが、関係する機能に応じて、実際には実質的に同時に実行される場合があり、ブロックが逆の順序で実行される場合もある。なお、ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図のブロックの組み合わせは、指定された機能または行為を行う特殊目的用のハードウェア式システム、または特殊目的用のハードウェアとコンピュータ命令との組み合わせによって実施することができる。

前述した事項は、本開示の実施形態に向けられるが、本開示の基本的な範囲から逸脱することなく、本開示の他の実施形態および更なる実施形態を考案することができ、本開示の範囲は、以下の請求項によって決定される。

以下、本発明の好ましい実施形態を項分け記載する。

実施形態１
コンピュータ実装方法であって、前記方法が、
クライアントアプリケーションから受信された第１の要求が前記第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定するステップと、
前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信するステップと
を含み、
前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが第２の要求を開始することが可能となる、方法。

実施形態２
前記第１の要求は、前記サーバマシンが前記第１の要求の処理に成功したことを示すステータスコードを含む、実施形態１記載の方法。

実施形態３
前記第１の要求は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）／１．ｘに関連しており、前記第１の要求を前記サーバマシンに送信するステップが、
前記第１の要求に基づいて、ＨＴＴＰ／２に関連する第２の要求を生成するステップと、
前記第２の要求とＨＴＴＰ／２に関連する少なくとも第３の要求とを、前記サーバマシンへの第１のＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続上で多重化するステップと
を含む、実施形態１記載の方法。

実施形態４
前記方法は、
前記サーバマシンが前記第１の要求の処理に成功していないことを判定するステップと、
前記第１の要求が第１のパーシステンスレベルを示していることを判定するステップと、
前記第１のパーシステンスレベルに基づいて１つ以上のエラー処理操作を行うステップであって、前記１つ以上のエラー処理操作により前記サーバマシンに前記第１の要求を有効に処理させるステップと
をさらに含む、実施形態１記載の方法。

実施形態５
前記第１の要求が第１のパーシステンスレベルを示していることを判定するステップは、前記第１の要求が、前記第１のパーシステンスレベルに相当するパーシステンスパラメータの値を指定するヘッダ部分を含んでいることを判定するステップを含む、実施形態４記載の方法。

実施形態６
前記第１の要求は、前記サーバマシンにアップロードされる情報提供データを含む、実施形態１記載の方法。

実施形態７
前記方法は、
前記第１の要求に対する第２の応答を前記サーバマシンから受信するステップと、
前記第２の応答を前記クライアントアプリケーションに送信する代わりに、前記第２の応答を破棄するステップと、
をさらに含む、実施形態１記載の方法。

実施形態８
前記クライアントアプリケーションが、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続を介して前記第１の応答を受信し、前記ＴＣＰ接続を再使用または再生成して前記第２の要求を開始する、実施形態１記載の方法。

実施形態９
前記方法は、
前記クライアントアプリケーションから受信された前記第２の要求が、前記第２の要求に対する応答を前記サーバマシンからオフロードできることを示していないことを判定するステップと、
前記第２の要求を前記サーバマシンに直接に送信するステップと、
前記第２の要求に対する第２の応答を前記サーバマシンから受信したことに応じて、前記第２の応答を前記クライアントアプリケーションに送信するステップと、
をさらに含む、実施形態１記載の方法。

実施形態１０
前記第１の要求に対する応答をオフロードできることを前記第１の要求が示していることを判定するステップは、前記第１の要求に対する前記応答が重要でないことを示すヘッダ部分を前記第１の要求が含んでいることを識別するステップを含む、実施形態１記載の方法。

実施形態１１
１つ以上の非一時的なコンピュータ可読媒体であって、１つ以上のプロセッサによって実行される際に、前記１つ以上のプロセッサに、
クライアントアプリケーションから受信された第１の要求をサーバマシンからオフロードできることを判定するステップと、
前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信するステップと
を行わせるための命令を含み、
前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが第２の要求を開始することが可能となる、１つ以上の非一時的なコンピュータ可読媒体。

実施形態１２
前記第１の要求は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）／１．ｘに関連しており、前記第１の要求を前記サーバマシンに送信するステップが、
前記第１の要求に基づいて、ＨＴＴＰ／２に関連する第２の要求を生成するステップと、
前記第２の要求とＨＴＴＰ／２に関連する少なくとも第３の要求とを、前記サーバマシンへの第１のＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続上で多重化するステップと
を含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１３
前記サーバマシンが前記第１の要求の処理に成功していないことを判定するステップと、
前記第１の要求が第１のパーシステンスレベルを示していることを判定するステップと、
前記第１のパーシステンスレベルに基づいて１つ以上のエラー処理操作を行うステップであって、前記１つ以上のエラー処理操作により前記サーバマシンに前記第１の要求を有効に処理させるステップと
をさらに含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１４
前記１つ以上のエラー処理操作は、前記第１の要求を持続的なストレージに記憶する１つ以上の書き込み操作を含む、実施形態１３記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１５
前記第１の要求は、イベントログ、前記クライアントアプリケーションが適切に実行されていることを示すハートビート、およびメトリックログのうちの少なくとも１つを含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１６
前記第１の要求に対する第２の応答を前記サーバマシンから受信するステップと、
前記第２の応答を前記クライアントアプリケーションに送信する代わりに、前記第２の応答を破棄するステップと
をさらに含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１７
前記クライアントアプリケーションが、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続を介して前記第１の応答を受信し、前記ＴＣＰ接続を再使用または再生成して前記第２の要求を開始する、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１８
前記クライアントアプリケーションから受信された前記第２の要求を前記サーバマシンからオフロードできることを判定するステップと、
現在のオフロード同時処理数が最大オフロード同時処理数に等しいことを判定するステップと、
前記第２の要求を前記サーバマシンに直接に送信するステップと、
前記第２の要求に対する第２の応答を前記サーバマシンから受信したことに応じて、前記第２の応答を前記クライアントアプリケーションに送信するステップと、
をさらに含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態１９
前記第１の要求をオフロードできることを判定するステップは、前記第１の要求に対する前記応答が重要でないことを示すヘッダ部分を前記第１の要求が含んでいることを識別するステップを含む、実施形態１１記載の１つ以上の非一時的なコンピュータ可読媒体。

実施形態２０
システムであって、
命令を記憶する１つ以上のメモリと、
前記１つ以上のメモリに結合された１つ以上のプロセッサと
を備え、前記１つ以上のプロセッサが、前記命令を実行する際に、
クライアントアプリケーションから第１の接続を介して受信された第１の要求が、前記第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定し、
前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信する
ように構成されており、
前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが前記第１の接続を再使用または再生成して第２の要求を開始することが可能となる、システム。

Claims (12)

1. コンピュータ実装方法であって、前記方法が、
   クライアントアプリケーションから受信された第１の要求が前記第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定するステップと、
   前記クライアントアプリケーションから受信された前記第１の要求が前記第１の要求に対する応答をサーバマシンからオフロードできることを示しているならば、前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信するステップと、
   ＨＴＴＰ／２要求についてオフロードがアクティブであり、サーバマシンから成功を示していないＨＴＴＰ／２応答を受信すれば、パーシステンスレベルに従ってエラー処理プロセスを実行するステップと
   を含み、
   前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが第２の要求を開始することが可能となる、方法。
2. 前記第１の要求は、前記サーバマシンが前記第１の要求の処理に成功したことを示すステータスコードを含む、請求項１記載の方法。
3. 前記第１の要求は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）／１．ｘに関連しており、前記第１の要求を前記サーバマシンに送信するステップが、
   前記第１の要求に基づいて、ＨＴＴＰ／２に関連する第３の要求を生成するステップと、
   前記第２の要求とＨＴＴＰ／２に関連する少なくとも第４の要求とを、前記サーバマシンへの第１のＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続上で多重化するステップと
   を含む、請求項１記載の方法。
4. 前記方法は、
   前記サーバマシンが前記第１の要求の処理に成功していないことを判定するステップと、
   前記第１の要求が第１のパーシステンスレベルを示していることを判定するステップと、
   前記第１のパーシステンスレベルに基づいて１つ以上のエラー処理操作を行うステップであって、前記１つ以上のエラー処理操作により前記サーバマシンに前記第１の要求を有効に処理させるステップと
   をさらに含む、請求項１記載の方法。
5. 前記第１の要求が第１のパーシステンスレベルを示していることを判定するステップは、前記第１の要求が、前記第１のパーシステンスレベルに相当するパーシステンスパラメータの値を指定するヘッダ部分を含んでいることを判定するステップを含む、請求項４記載の方法。
6. 前記第１の要求は、前記サーバマシンにアップロードされる情報提供データを含む、請求項１記載の方法。
7. 前記方法は、
   前記第１の要求に対する第２の応答を前記サーバマシンから受信するステップと、
   前記第２の応答を前記クライアントアプリケーションに送信する代わりに、前記第２の応答を破棄するステップと、
   をさらに含む、請求項１記載の方法。
8. 前記クライアントアプリケーションが、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続を介して前記第１の応答を受信し、前記ＴＣＰ接続を再使用または再生成して前記第２の要求を開始する、請求項１記載の方法。
9. 前記方法は、
   前記クライアントアプリケーションから受信された前記第２の要求が、前記第２の要求に対する応答を前記サーバマシンからオフロードできることを示していないことを判定するステップと、
   前記クライアントアプリケーションから受信された前記第２の要求が前記第２の要求に対する応答を前記サーバマシンからオフロードできることを示していないならば、前記第２の要求を前記サーバマシンに直接に送信するステップと、
   前記第２の要求に対する第２の応答を前記サーバマシンから受信したことに応じて、前記第２の応答を前記クライアントアプリケーションに送信するステップと、
   をさらに含む、請求項１記載の方法。
10. 前記第１の要求に対する応答をオフロードできることを前記第１の要求が示していることを判定するステップは、前記第１の要求に対する前記応答が重要でないことを示すヘッダ部分を前記第１の要求が含んでいることを識別するステップを含む、請求項１記載の方法。
11. １つ以上の非一時的なコンピュータ可読媒体であって、１つ以上のプロセッサによって実行される際に、前記１つ以上のプロセッサに、
    クライアントアプリケーションから受信された第１の要求をサーバマシンからオフロードできることを判定するステップと、
    前記クライアントアプリケーションから受信された前記第１の要求をサーバマシンからオフロードできるならば、前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信するステップと、
    ＨＴＴＰ／２要求についてオフロードがアクティブであり、サーバマシンから成功を示していないＨＴＴＰ／２応答を受信すれば、パーシステンスレベルに従ってエラー処理プロセスを実行するステップと
    を行わせるための命令を含み、
    前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが第２の要求を開始することが可能となる、１つ以上の非一時的なコンピュータ可読媒体。
12. システムであって、
    命令を記憶する１つ以上のメモリと、
    前記１つ以上のメモリに結合された１つ以上のプロセッサと
    を備え、前記１つ以上のプロセッサが、前記命令を実行する際に、
    クライアントアプリケーションから第１の接続を介して受信された第１の要求が、前記第１の要求に対する応答をサーバマシンからオフロードできることを示していることを判定し、
    前記クライアントアプリケーションから受信された前記第１の要求が前記第１の要求に対する応答をサーバマシンからオフロードできることを示しているならば、前記第１の要求を前記サーバマシンに送信する前に、前記サーバマシンが前記第１の要求の処理に成功したことを示す、前記第１の要求に対する第１の応答を、前記クライアントアプリケーションに送信し、
    ＨＴＴＰ／２要求についてオフロードがアクティブであり、サーバマシンから成功を示していないＨＴＴＰ／２応答を受信すれば、パーシステンスレベルに従ってエラー処理プロセスを実行する
    ように構成されており、
    前記第１の応答を受信したことに応じて、前記クライアントアプリケーションが前記第１の接続を再使用または再生成して第２の要求を開始することが可能となる、システム。

Images