(57)【要約】      （修正有）【課題】クライアントとサーバとの間のＴＣＰプロキシセッションのためのバッファ使用量を低減する方法を提供する。【解決手段】サービスゲートウェイによってクライアントとサーバとの間のＴＣＰプロキシセッションのためのバッファ使用量を低減することは、サーバ側ＴＣＰセッションのための第１のラウンドトリップ時間（ＲＴＴ）を決定し、クライアント側ＴＣＰセッションのための第２のＲＴＴを決定する工程と、第１のＲＴＴを第２のＲＴＴと比較する工程と、第２のＲＴＴがしきい値を超えて第２のＲＴＴを上回るか否かを判定する工程と、第２のＲＴＴがしきい値を超えて第２のＲＴＴを上回るのであれば、第２のＲＴＴに基づいて所望のＲＴＴを計算する工程と、計算された所望のＲＴＴに従ってタイマを設定する工程であって、タイマが終了するまで、サーバ側ＴＣＰセッションのためのＴＣＰ確認応答が遅延される、設定する工程とを含む。【選択図】図１
2014143686.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとサーバとの間の伝送制御プロトコル（ＴＣＰ）プロキシセッションのためのバッファ使用量を低減する方法であって、
（ａ）サービスゲートウェイと前記サーバとの間の前記ＴＣＰプロキシセッションのサーバ側ＴＣＰセッションのための第１のラウンドトリップ時間（ＲＴＴ）を決定し、前記サービスゲートウェイと前記クライアントとの間の前記ＴＣＰプロキシセションのクライアント側ＴＣＰセッションのための第２のＲＴＴを決定する工程と、
（ｂ）前記サービスゲートウェイによって前記第１のＲＴＴを前記第２のＲＴＴと比較する工程と、
（ｃ）前記第２のＲＴＴが前記第１のＲＴＴを超えるか否かを判定する工程と、
（ｄ）前記第２のＲＴＴが前記第１のＲＴＴを超えるという判定に応答して、前記サービスゲートウェイによって、前記第２のＲＴＴに基づいて所望のＲＴＴを計算する工程と、
（ｅ）前記サービスゲートウェイによって、前記計算された所望のＲＴＴに従ってタイマを設定する工程であって、前記タイマが終了するまで、前記サーバ側ＴＣＰセッションのためのＴＣＰ確認応答が遅延される、設定する工程と
を含む方法。
【請求項２】
請求項１に記載の方法であって、
前記判定する工程（ｃ）および前記計算する工程（ｄ）が、
（ｃ１）前記第２のＲＴＴが所定のしきい値を超えて前記第１のＲＴＴを上回るか否かを判定する工程と、
（ｄ１）前記第２のＲＴＴが前記所定のしきい値を超えて前記第１のＲＴＴを上回るという判定に応答して、前記サービスゲートウェイによって、前記第２のＲＴＴに基づいて前記所望のＲＴＴを計算する工程と
を含む、方法。
【請求項３】
請求項１に記載の方法であって、
前記計算する工程（ｄ）が、
（ｄ１）前記サービスゲートウェイによって、前記所望のＲＴＴを、前記第２のＲＴＴのパーセンテージとして計算する工程
を含む、方法。
【請求項４】
請求項１に記載の方法であって、
前記計算する工程（ｄ）が、
（ｄ１）前記サービスゲートウェイによって、前記所望のＲＴＴを、前記第２のＲＴＴマイナス所定の値として計算する工程
を含む、方法。
【請求項５】
請求項１に記載の方法であって、
前記設定する工程（ｅ）が、
（ｅ１）前記サービスゲートウェイによって、前記サーバ側ＴＣＰセッションを介して前記サーバからデータパケットを受信する工程と、
（ｅ２）前記サービスゲートウェイによって、前記サーバに前記ＴＣＰ確認応答を送信する必要性を判定する工程と、
（ｅ３）前記サービスゲートウェイによって、前記所望のＲＴＴにタイマを設定する工程と、
（ｅ４）前記タイマの終了に応答して、前記サービスゲートウェイによって前記サーバに前記ＴＣＰ確認応答を送信する工程と
を含む、方法。
【請求項６】
クライアントとサーバとの間の伝送制御プロトコル（ＴＣＰ）プロキシセッションのためのバッファ使用量を低減するコンピュータ可読プログラムコードが具体化される非一時的コンピュータ可読媒体であって、前記コンピュータ可読プログラムコードが、
（ａ）サービスゲートウェイと前記サーバとの間の前記ＴＣＰプロキシセッションのサーバ側ＴＣＰセッションのための第１のラウンドトリップ時間（ＲＴＴ）を決定し、前記サービスゲートウェイと前記クライアントとの間の前記ＴＣＰプロキシセションのクライアント側ＴＣＰセッションのための第２のＲＴＴを決定することと、
（ｂ）前記第１のＲＴＴを前記第２のＲＴＴと比較することと、
（ｃ）前記第２のＲＴＴが前記第１のＲＴＴを超えるか否かを判定することと、
（ｄ）前記第２のＲＴＴが前記第１のＲＴＴを超えるという判定に応答して、前記第２のＲＴＴに基づいて所望のＲＴＴを計算することと、
（ｅ）前記計算された所望のＲＴＴに従ってタイマを設定することであって、前記タイマが終了するまで、前記サーバ側ＴＣＰセッションのためのＴＣＰ確認応答が遅延される、設定することと
を行うように構成されている、媒体。
【請求項７】
請求項６に記載の媒体であって、
前記決定すること（ｃ）および前記計算すること（ｄ）を行うように構成された前記コンピュータ可読プログラムコードが、さらに、
（ｃ１）前記第２のＲＴＴが所定のしきい値を超えて前記第１のＲＴＴを上回るか否かを判定することと、
（ｄ１）前記第２のＲＴＴが前記所定のしきい値を超えて前記第１のＲＴＴを上回るという判定に応答して、前記サービスゲートウェイによって、前記第２のＲＴＴに基づいて前記所望のＲＴＴを計算することと
を行うように構成されている、媒体。
【請求項８】
請求項６に記載の媒体であって、
前記計算すること（ｄ）を行うように構成された前記コンピュータ可読プログラムコードが、さらに、
（ｄ１）前記所望のＲＴＴを、前記第２のＲＴＴのパーセンテージとして計算すること
を行うように構成されている、媒体。
【請求項９】
請求項６に記載の媒体であって、
前記計算すること（ｄ）を行うように構成された前記コンピュータ可読プログラムコードが、さらに、
（ｄ１）前記所望のＲＴＴを、前記第２のＲＴＴマイナス所定の値として計算すること
を行うように構成されている、媒体。
【請求項１０】
請求項６に記載の媒体であって、
前記設定すること（ｅ）を行うように構成された前記コンピュータ可読プログラムコードが、さらに、
（ｅ１）前記サーバ側ＴＣＰセッションを介して前記サーバからデータパケットを受信ことと、
（ｅ２）前記サーバに前記ＴＣＰ確認応答を送信する必要性を判定ことと、
（ｅ３）前記所望のＲＴＴにタイマを設定ことと、
（ｅ４）前記タイマの終了に応答して、前記サーバに前記ＴＣＰ確認応答を送信することと
を行うように構成されている、媒体。
【請求項１１】
クライアントとサーバとの間の伝送制御プロトコル（ＴＣＰ）プロキシセッションのためのバッファ使用量を低減するシステムであって、
セキュリティゲートウェイを備え、前記ＴＣＰプロキシセッションのサーバ側ＴＣＰセッションが、前記セキュリティゲートウェイと前記サーバとの間に確立され、前記ＴＣＰプロキシセッションのクライアント側ＴＣＰセッションが、前記セキュリティゲートウェイと前記クライアントとの間に確立され、前記セキュリティゲートウェイが、
（ａ）サービスゲートウェイと前記サーバとの間の前記ＴＣＰプロキシセッションのサーバ側ＴＣＰセッションのための第１のラウンドトリップ時間（ＲＴＴ）を決定し、前記サービスゲートウェイと前記クライアントとの間の前記ＴＣＰプロキシセションのクライアント側ＴＣＰセッションのための第２のＲＴＴを決定することと、
（ｂ）前記第１のＲＴＴを前記第２のＲＴＴと比較することと、
（ｃ）前記第２のＲＴＴが前記第１のＲＴＴを超えるか否かを判定することと、
（ｄ）前記第２のＲＴＴが前記第１のＲＴＴを超えるという判定に応答して、前記第２のＲＴＴに基づいて所望のＲＴＴを計算することと、
（ｅ）前記計算された所望のＲＴＴに従ってタイマを設定することであって、前記タイマが終了するまで、前記サーバ側ＴＣＰセッションのためのＴＣＰ確認応答が遅延される、設定することと
を行う、システム。
【請求項１２】
請求項１１に記載のシステムであって、
前記決定すること（ｃ）および前記計算すること（ｄ）が、
（ｃ１）前記第２のＲＴＴが所定のしきい値を超えて前記第１のＲＴＴを上回るか否かを判定することと、
（ｄ１）前記第２のＲＴＴが前記所定のしきい値を超えて前記第１のＲＴＴを上回るという判定に応答して、前記第２のＲＴＴに基づいて前記所望のＲＴＴを計算することと
を含む、システム。
【請求項１３】
請求項１１に記載のシステムであって、
前記計算すること（ｄ）が、
（ｄ１）前記所望のＲＴＴを、前記第２のＲＴＴのパーセンテージとして計算すること
を含む、システム。
【請求項１４】
請求項１１に記載のシステムであって、
前記計算すること（ｄ）が、
（ｄ１）前記所望のＲＴＴを、前記第２のＲＴＴマイナス所定の値として計算すること
を含む、システム。
【請求項１５】
請求項１１に記載のシステムであって、
前記設定すること（ｅ）が、
（ｅ１）前記サーバ側ＴＣＰセッションを介して前記サーバからデータパケットを受信することと、
（ｅ２）前記サーバに前記ＴＣＰ確認応答を送信する必要性を判定することと、
（ｅ３）前記所望のＲＴＴにタイマを設定することと、
（ｅ４）前記タイマの終了に応答して、前記サーバに前記ＴＣＰ確認応答を送信することと
を含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本発明は、一般に、データ通信に関し、より詳細には、サービスゲートウェイに関する。
【背景技術】
【０００２】
[0002]ファイアウォールおよびサーバ負荷分散装置などの数多くのサービスゲートウェイは、以前から伝送制御プロトコル（ＴＣＰ）プロキシ機能を提供している。ＴＣＰプロキシの通常のサービスアプリケーションは、ネットワーク分析、セキュリティ、ならびに非対称のクライアントとサーバの状態によるトラフィック適合を含む。ＴＣＰプロキシサーバは、通常、クライアントデバイスとサーバとの間のＴＣＰセッションのデータパケットバッファリングを処理するために、ある量のメモリバッファを割り当てる。メモリバッファは、クライアント側セッションおよびサーバ側セッションのためのデータパケットバッファを処理するために使用される。クライアント側セッションの送信バッファおよび受信バッファと、サーバ側セッションの送信バッファおよび受信バッファとの間のメモリ空間の割当ては、しばしば、性能を考慮しない。ＴＣＰプロキシサーバは、サーバ側セッションからデータパケットを受信し、必要なサービスアプリケーションに従ってデータパケットを処理し、結果として生じるデータパケットをクライアント側セッションに送信する。理想的なシナリオでは、これらのステップは、サーバ側セッションからの次のデータパケットがＴＣＰプロキシサーバに送達される前に完了される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、多くの展開された状況では、クライアントデバイスは、モバイルブロードバンドアクセスまたは残余のインターネットアクセスを介してサーバにアクセスし、この場合、このようなアクセスでは、長い距離の広域ネットワークに起因して伝送時間がより長く、加入者アクセスサービスに基づいて伝送帯域幅がより遅い。それにもかかわらず、ＴＣＰプロキシサーバおよび複数のサーバは、同じデータセンタ内に常駐し、短い伝送時間および大容量の帯域幅を享受する。このような展開シナリオでは、ＴＣＰプロキシサーバが、サーバ側セッションからデータパケットを受信すると、受信されたデータパケットは、サーバ側セッションの受信サーバ内に配置され、サービスアプリケーションによって処理されるその順番を待ち、次に、以前に処理された保留のデータパケットで満たされたクライアント側セッションの送信バッファを、クライアント側セッションが解放するのを待ち、次に、前に送信されたデータパケットの伝送が遅いため、それらの伝送の順番を待っている。
【０００４】
[0003]通常の状況では、ＴＣＰプロキシサーバは、サーバからの適切な量のＴＣＰデータを首尾よく受信すると、ＴＣＰプロトコルに従って、ＴＣＰ確認応答を送信する。サーバが、前に送信されたＴＣＰデータのＴＣＰ確認応答を受信すると、サーバは、追加のＴＣＰデータパケットをＴＣＰプロキシサーバに送信することになる。ＴＣＰプロキシサーバは、さらに、前のＴＣＰデータが処理され、クライアントに送信されるのを待ちながら、追加のＴＣＰデータパケットを格納するために、サーバ側セッションの受信バッファのためのメモリ空間を増加させることになる。カスケーディング効果は、ＴＣＰプロキシサーバが、サーバ側セッションの受信されたＴＣＰデータパケットを保持するのに必要なサーバ側セッションの受信バッファのための大量のメモリ空間を消費させる。ＴＣＰプロキシサーバが、追加の負荷を処理するために、他の豊富なリソースを有することができるのにもかかわらず、より多くのバッファ空間が使用され、追加のＴＣＰプロキシセッションを処理するためにＴＣＰプロキシサーバに利用可能なメモリリソースは、より少なくなる。
【課題を解決するための手段】
【０００５】
[0004]本発明の一実施形態によれば、クライアントとサーバとの間の伝送制御プロトコル（ＴＣＰ）プロキシセッションのためのバッファ使用量を低減する方法は、（ａ）サービスゲートウェイとサーバとの間のＴＣＰプロキシセッションのサーバ側ＴＣＰセッションのための第１のラウンドトリップ時間（ＲＴＴ）を決定し、サービスゲートウェイとクライアントとの間のＴＣＰプロキシセションのクライアント側ＴＣＰセッションのための第２のＲＴＴを決定する工程と、（ｂ）サービスゲートウェイによって第１のＲＴＴを第２のＲＴＴと比較する工程と、（ｃ）第２のＲＴＴが第１のＲＴＴを超えるか否かを判定する工程と、（ｄ）第２のＲＴＴが第１のＲＴＴを超えるという判定に応答して、サービスゲートウェイによって、第２のＲＴＴに基づいて所望のＲＴＴを計算する工程と、（ｅ）サービスゲートウェイによって、計算された所望のＲＴＴに従ってタイマを設定する工程であって、タイマが終了するまで、サーバ側ＴＣＰセッションのためのＴＣＰ確認応答が遅延される、設定する工程を含む。
【０００６】
[0005]本発明の一態様では、判定する工程（ｃ）および計算する工程（ｄ）は、（ｃ１）第２のＲＴＴが所定のしきい値を超えて第１のＲＴＴを上回るか否かを判定する工程と、（ｄ１）第２のＲＴＴが所定のしきい値を超えて第１のＲＴＴ上回るという判定に応答して、サービスゲートウェイによって、第２のＲＴＴに基づいて所望のＲＴＴを計算する工程とを含む。
【０００７】
[0006]本発明の一態様では、計算する工程（ｄ）は、（ｄ１）サービスゲートウェイによって、所望のＲＴＴを、第２のＲＴＴのパーセンテージとして計算する工程を含む。
【０００８】
[0007]本発明の一態様では、計算する工程（ｄ）は、（ｄ１）サービスゲートウェイによって、所望のＲＴＴを、第２のＲＴＴマイナス所定の値として計算する工程を含む。
【０００９】
[0008]本発明の一態様では、設定する工程（ｅ）は、（ｅ１）サービスゲートウェイによって、サーバ側ＴＣＰセッションを介してサーバからデータパケットを受信する工程と、（ｅ２）サービスゲートウェイによって、サーバにＴＣＰ確認応答を送信する必要性を判定する工程と、（ｅ３）サービスゲートウェイによって、所望のＲＴＴにタイマを設定する工程と、（ｅ４）タイマの終了に応答して、サービスゲートウェイによってサーバにＴＣＰ確認応答を送信する工程とを含む。
【００１０】
[0009]上記の要約された方法に対応するシステムおよびコンピュータ可読媒体も、本明細書で説明され、特許請求される。
【図面の簡単な説明】
【００１１】
【図１】[0010]本発明の実施形態によるクライアントデバイスとサーバとの間のＴＣＰプロキシセクションをサービスするサービスゲートウェイを示す図である。
【図１ａ】[0011]本発明の実施形態によるサービスゲートウェイの構成要素を示す図である。
【図２】[0012]本発明の実施形態によるＴＣＰ  ＡＣＫパケットの送信を遅延させるための方法を示す図である。
【発明を実施するための形態】
【００１２】
[0013]本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアの要素およびソフトウェアの要素の両方を含む実施形態の形態をとることができる。好適実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されないソフトウェアで実現される。
【００１３】
[0014]さらに、本発明は、コンピュータもしくは任意の命令実行システムによって、またはこれらに関連して使用するためのプログラムコードを提供するコンピュータ使用可能もしくはコンピュータ可読媒体からアクセス可能な、コンピュータプログラム製品の形態をとることができる。この説明の目的のため、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、もしくはデバイスによって、あるいはこれらに関連して使用するためのプログラムを含む、格納する、通信する、伝播する、または伝送することができる任意の装置であってもよい。
【００１４】
[0015]媒体は、電子、磁気、光、電磁気、赤外線、もしくは半導体システム（または装置もしくはデバイス）、あるいは伝搬媒体であってもよい。コンピュータ可読媒体の例は、半導体もしくは固体メモリ、磁気テープ、取外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクを含む。光ディスクの現在の例は、コンパクトディスク−読取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。
【００１５】
[0016]プログラムコードを格納および／または実行するのに適したデータ処理システムは、システムバスを介してメモリに直接または間接的に結合された少なくとも１つのプロセッサを含むであろう。メモリ素子は、プログラムコードの実際の実行中に用いられるローカルメモリ、大容量記憶装置、およびキャッシュメモリを含むことができ、キャッシュメモリは、実行中にコードを大容量記憶装置から取り出さなければならない回数を減らすために、少なくともいくつかのプログラムコードの一時的な記憶領域を提供する。
【００１６】
[0017]入力／出力またはＩ／Ｏデバイス（キーボード、ディスプレイ、ポイントデバイスなどを含むが、これらに限定されない）が、システムに直接、または介在するＩ／Ｏコントローラを介して結合されてもよい。
【００１７】
[0018]データ処理システムが、介在するプライベートまたはパブリックネットワークを介して、他のデータ処理システムまたはリモートプリンタに結合されることを可能にするために、ネットワークアダプタも、システムに結合されてもよい。モデム、ケーブルモデム、およびイーサネット（登録商標）カードは、ネットワークアダプタの現在利用可能な形式の中のほんのいくつかにすぎない。
【００１８】
[0019]図中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示す。この点について、フローチャートまたはブロック図中の各ブロックは、指定されたローカル機能を実現するための１つまたは複数の実行可能な命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。いくつかの代わりの実施では、ブロック内で特に言及された機能は、図中に特に言及された順序以外で生じうることにも留意すべきである。例えば、連続して示された２つのブロックは、実際には、実質的に同時に実行されてもよく、またはブロックは、時には、関係する機能に応じて、逆順に実行されてもよい。ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図中のブロックの組み合わせは、指定された機能もしくは作用を実行する専用ハードウェアベースのシステム、または専用ハードウェアおよびコンピュータ命令の組み合わせによって実施されてもよいことも注意すべきである。
【００１９】
[0020]本明細書で使用される用語は、特定の実施形態のみを説明する目的のためのものであり、発明を限定することは意図されない。本明細書で使用される場合、単数形の「ａ」、「ａｎ」および「ｔｈｅ」は、文脈が別途明確に示さない限り、複数形も含むことが意図される。「備える」および／または「備えている」という用語は、本明細書で使用される場合、述べられた特徴、整数、ステップ、動作、要素、および／または構成要素の存在を特定するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、および／またはそれらのグループの存在を排除しないことは、さらに理解されるであろう。
【００２０】
[0021]本発明の実施形態は、後述するように、バッファ使用量を低減するために、サービス側セッションの伝送時間を調節し、バッファ使用量の低減は、ＴＣＰプロキシサーバのＴＣＰプロキシセッションの容量を増加させる。本発明の実施形態によれば、ＴＣＰプロキシサーバは、サーバが追加のＴＣＰデータを送信するのを遅延させ、遅延は、ＴＣＰプロキシサーバが、処理されてクライアントに送信されるべきサーバ側セッションの受信バッファ内の現在のＴＣＰデータを処理し、送信することを可能にする。遅延後、サーバが追加のデータを送信するとき、ＴＣＰプロキシサーバは、追加のＴＣＰデータを受信するために、サーバ側セッションの受信バッファ内に十分な空間を有することになる。このような遅延は、サーバとＴＣＰプロキシサーバとの間のサーバ側セッションのための伝送時間を長くする。
【００２１】
[0022]図１は、本発明の実施形態による、データネットワーク１５３を介してクライアントデバイス１００とサーバデバイス２００との間のＴＣＰプロキシセッション４００をサービスするサービスゲートウェイ３００を示す。
【００２２】
[0023]一実施形態では、データネットワーク１５３は、インターネットプロトコル（ＩＰ）ネットワーク、企業データネットワーク、地域の企業データネットワーク、インターネットサービスプロバイダネットワーク、住宅用データネットワーク、イーサネットなどの有線ネットワーク、Ｗｉ−Ｆｉ（登録商標）ネットワークなどの無線ネットワーク、またはセルラネットワークを含む。一実施形態では、データネットワーク１５３は、データセンタ内に常駐し、またはネットワークもしくはアプリケーションネットワーククラウドに接続する。
【００２３】
[0024]クライアントデバイス１００は、典型的には、ネットワークアクセス機能を有するコンピューティングデバイスである。一実施形態では、クライアントデバイス１００は、ワークステーション、デスクトップパーソナルコンピュータもしくはラップトップパーソナルコンピュータ、パーソナルデータアシスタント（ＰＤＡ）、タブレットコンピューティングデバイス、スマートフォン、もしくは携帯電話、セットトップボックス、インターネットメディアビューワ、インターネットメディアプレーヤ、スマートセンサ、スマート医療デバイス、ネットトップボックス、ネットワーク接続されたテレビジョンセット、ネットワーク接続されたＤＶＲ、ネットワーク接続されたＢｌｕ−ｒａｙ（登録商標）プレーヤ、ネットワーク接続された携帯ゲームデバイス、またはメディアセンタである。
【００２４】
[0025]一実施形態では、クライアントデバイス１００は、住宅用ブロードバンドゲートウェイ、ビジネスインターネットゲートウェイ、ビジネスウェブプロキシサーバ、ネットワーク宅内デバイス（ＣＰＥ）、またはインターネットアクセスゲートウェイである。
【００２５】
[0026]一実施形態では、クライアントデバイス１００は、ブロードバンドリモートアクセスサーバ（ＢＲＡＳ）、デジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）、ケーブルモデム終端システム（ＣＭＴＳ）、またはサービスプロバイダアクセスゲートウェイを含む。
【００２６】
[0027]一実施形態では、クライアントデバイス１００は、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）などのモバイルブロードバンドアクセスゲートウェイ、ホームエージェント（ＨＡ）、またはＰＤＮゲートウェイ（ＰＧＷ）を含む。
【００２７】
[0028]一実施形態では、クライアントデバイス１００は、サーバ負荷分散装置、アプリケーション配信コントローラ、トラフィックマネージャ、ファイアウォール、ＶＰＮサーバ、リモートアクセスサーバ、または企業もしくはデータセンタアクセスゲートウェイを含む。
【００２８】
[0029]一実施形態では、クライアントデバイス１００は、サービスゲートウェイ３００と同様のデバイスである。
【００２９】
[0030]クライアントデバイス１００は、サービスゲートウェイ３００を介して、サーバ２００に向けてＴＣＰセッション４００を開始する。
【００３０】
[0031]サーバ２００は、典型的には、プロセッサ、およびコンピュータ可読プログラムコードを格納するコンピュータ可読媒体に結合されたコンピューティングデバイスである。サーバ２００は、プロセッサおよびコンピュータ可読プログラムコードと共に、ＴＣＰセッション４００を使用してクライアントデバイス１００にＴＣＰベースのサービスまたはアプリケーションサービスを提供する、ウェブサーバ、ファイルサーバ、ビデオサーバ、データベースサーバ、アプリケーションサーバ、音声システム、会議サーバ、メディアゲートウェイ、メディアセンタ、アプリサーバ、またはネットワークサーバの機能を実現する。
【００３１】
[0032]一実施形態では、サーバ２００は、サービスゲートウェイ３００と同様のデバイスである。
【００３２】
[0033]一実施形態では、ＴＣＰセッション４００は、ＨＴＴＰセッション、ＦＴＰファイル転送セッション、ＴＣＰベースのビデオストリーミングセッション、ＴＣＰベースの音楽ストリーミングセッション、ファイルダウンロードセッション、グループ会議セッション、データベースアクセスセッション、リモート端末アクセスセッション、テルネットセッション、電子商取引、リモートプロシージャコール、またはＴＣＰベースのネットワーク通信セッションを含む。
【００３３】
[0034]図１ａに示されるサービスゲートウェイ３００は、プロセッサ３１０、メモリモジュール３２０、ネットワークインタフェースモジュール３３０、およびコンピュータ可読媒体３４０に任意に結合される。コンピュータ可読媒体３４０は、コンピュータ可読プログラムコードを格納し、コンピュータ可読プログラムコードは、メモリモジュール３２０を使用してプロセッサ３１０によって実行されると、本明細書に記載されるような本発明の様々な実施形態を実現する。いくつかの実施形態では、サービスゲートウェイ３００は、サーバ負荷分散装置、アプリケーション配信コントローラ、サービス配信プラットフォーム、トラフィックマネージャ、セキュリティゲートウェイ、ファイアウォールシステムの構成要素、仮想プライベートネットワーク（ＶＰＮ）の構成要素、ビデオサーバ用負荷分散装置、負荷を１つまたは複数のサーバに分散させるゲートウェイ、ウェブまたはＨＴＴＰサーバ、ネットワークアドレス変換（ＮＡＴ）ゲートウェイ、あるいはＴＣＰプロキシサーバとして実装される。
【００３４】
[0035]一実施形態では、コンピュータ可読媒体３４０は、サービスアプリケーション３５０のための命令を含み、プロセッサ３１０は、サービスアプリケーション３５０を実行する。
【００３５】
[0036]一実施形態では、サービスアプリケーション３５０は、ＶＰＮファイアウォール、ゲートウェイセキュリティアプリケーション、ＨＴＴＰプロキシ、ＴＣＰベースのオーディオもしくはビデオストリーミングセッションプロキシ、ウェブセッションプロキシ、コンテンツフィルタリング、サーバ負荷分散、ファイアウォール、またはネットワークアプリケーションセッションプロキシを実装する。
【００３６】
[0037]図１に戻り、クライアントデバイス１００とサーバ２００との間のＴＣＰプロキシセッション４００をサービスする一実施形態では、サービスゲートウェイ３００は、クライアントデバイス１００とのクライアント側ＴＣＰセッション４２０、およびサーバ２００とのサーバ側ＴＣＰセッション４７０を確立する。
【００３７】
[0038]一実施形態では、サービスゲートウェイ３００は、サーバ側ＴＣＰセッション４７０のための受信バッファ４７４を割り当てる。一実施形態では、受信バッファ４７４は、メモリモジュール３２０内に常駐する。
【００３８】
[0039]一実施形態では、サービスゲートウェイ３００は、ＴＣＰセッション４７０のラウンドトリップ時間（ＲＴＴ）４９７を使用して、ＴＣＰセッション４７０の性能を監視する。サービスゲートウェイ３００は、ＴＣＰセッション４７０に関するＲＴＴ４９７を測定または推定する。１つの例示的な実施形態では、サービスゲートウェイ３００は、サービスゲートウェイ３００が、ＴＣＰセッション４７０のデータパケットをサーバ２００に送信する時間と、サービスゲートウェイ３００が、送信されたデータパケットに関する確認応答を受信する時間との間の時間間隔に基づいて、ＲＴＴ４９７を測定する。一実施形態では、サービスゲートウェイ３００は、ＴＣＰセッション４７０の間、ＲＴＴ４９７を定期的にまたは随時に測定する。一実施形態では、サービスゲートウェイ３００は、サーバ２００との１つまたは複数の以前のサーバ側ＴＣＰセッションに基づいて、ＲＴＴ４９７を測定する。一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９７を、１０ミリ秒、１００ミリ秒、３ミリ秒、２２ミリ秒、または３秒であると推定する。
【００３９】
[0040]一実施形態では、サービスゲートウェイ３００は、受信バッファ４７４からデータを取り出し、データを、一実施形態では、サービスアプリケーション３５０によって処理し、処理されたデータを、ＴＣＰセッション４２０を介してクライアントデバイス１００に送信する。一実施形態では、サービスゲートウェイ３００は、ＴＣＰセッション４２０が送信の準備ができているときはいつでも、受信バッファ４７４からのデータを処理する。ＴＣＰセッション４２０の遅い伝送は、サービスゲートウェイ３００が受信バッファ４７４からのデータを処理するのを遅延させる。一実施形態では、サービスゲートウェイ３００は、ＴＣＰセッション４２０のラウンドトリップ時間（ＲＴＴ）４９２を使用して、ＴＣＰセッション４２０の性能を監視する。サービスゲートウェイ３００は、ＴＣＰセッション４２０に関するＲＴＴ４９２を測定または監視する。１つの例示的な実施形態では、サービスゲートウェイ３００は、サービスゲートウェイ３００が、ＴＣＰセッション４２０のデータパケットをクライアントデバイス１００に送信する時間と、サービスゲートウェイ３００が、送信されたデータパケットに関する確認応答を受信する時間との間の時間間隔に基づいて、ＲＴＴ４９２を測定する。一実施形態では、サービスゲートウェイ３００は、ＴＣＰセッション４２０の間、ＲＴＴ４９２を定期的にまたは随時に測定する。一実施形態では、サービスゲートウェイ３００は、クライアントデバイス１００との１つまたは複数の以前のクライアント側ＴＣＰセッションに基づいて、ＲＴＴ４９２を測定する。一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９２を、１０ミリ秒、１００ミリ秒、３ミリ秒、２２ミリ秒、または３秒であると推定する。
【００４０】
[0041]一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９７をＲＴＴ４９２と比較する。一実施形態では、サービスゲートウェイ３００が、ＲＴＴ４９２が特定のしきい値を超えてＲＴＴ４９７を上回ると判定すると、サービスゲートウェイ３００は、ＲＴＴ４９２およびＲＴＴ４９７間のギャップを狭くするようにＲＴＴ４９７を調節するために、以下でさらに説明される処理を適用する。一実施形態では、ＲＴＴ４９２が、少なくとも、ＲＴＴ４９７の２倍高い、５倍高い、もしくは１０倍高い場合、またはＲＴＴ４９２が、少なくとも、２０ミリ秒、５０ミリ秒、もしくは２００ミリ秒などの所定の量だけＲＴＴ４９７より大きい場合、ＲＴＴ４９２は、しきい値を超えてＲＴＴ４９７を上回ると判定される。
【００４１】
[0042]一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９２がしきい値を超えてＲＴＴ４９７を上回らないと判定し、サービスゲートウェイ３００は、ＲＴＴ４９７を調節しない。
【００４２】
[0043]一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９２およびＲＴＴ４９７を、定期的にまたは随時に測定し、ＲＴＴ４９２をＲＴＴ４９７と比較する。
【００４３】
[0044]図２は、本発明の実施形態による、サーバ側ＴＣＰセッション４７０に関するＲＴＴ４９７を調節する方法を示す。一実施形態では、サービスゲートウェイ３００は、サーバ２００からＴＣＰセッション４７０を介してデータパケット４８０を受信する。サービスゲートウェイ３００は、データパケット４８０を受信バッファ４７４に格納する。一実施形態では、サービスゲートウェイ３００は、受信バッファ４７４から、ＴＣＰプロトコル毎にＴＣＰ確認応答を送信する必要性を判定する。ＴＣＰ  ＡＣＫデータパケット４７９をすぐに送信する代わりに、サービスゲートウェイ３００は、タイマ４８７を使用して、ＴＣＰ  ＡＣＫデータパケット４７９をより後の時間に送信するように予定する。サービスゲートウェイ３００は、タイマ４８７を、所望のＲＴＴ４９８に設定する。タイマ４８７が終了すると、サービスゲートウェイ３００は、ＴＣＰ  ＡＣＫデータパケット４７９を送信する。一実施形態では、サービスゲートウェイ３００は、サービスゲートウェイ３００が、タイマ４８７が終了した場合を判定することを可能にするクロック（図示せず）を含む。
【００４４】
[0045]一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９２に基づいて所望のＲＴＴ４９８を計算する。一実施形態では、所望のＲＴＴ４９８は、ＲＴＴ４９２の実質的な範囲内に計算される。例えば、所望のＲＴＴ４９８は、ＲＴＴ４９２の３０％、４０％、６０％、または７５％など、ＲＴＴ４９２の所定のパーセンテージとして計算される。一実施形態では、所望のＲＴＴ４９８は、ＲＴＴ４９２マイナス１０ミリ秒、５ミリ秒、または２５ミリ秒などの所定の値に計算される。所望のＲＴＴ４９８は、ＴＣＰセッション４７０に関するＴＣＰ確認応答の時限遅延を提供し、したがって、ＴＣＰ４７０のラウンドトリップ時間を増加させる。サービスゲートウェイ３００が、ＴＣＰ  ＡＣＫデータパケット４７９を送信した後、図１に示すようなＲＴＴ４９７を測定すると、ＲＴＴ４９７は、所望のＲＴＴ４９８と同様の値を有すると予想される。
【００４５】
[0046]一実施形態では、サービスゲートウェイ３００は、ＲＴＴ４９７、ＲＴＴ４９２を測定し、ＲＴＴ４９２をＲＴＴ４９７と比較し、サービスゲートウェイ３００が、ＲＴＴ４９２がＲＴＴ４９７より実質的に大きいと判定すると、受信バッファ４７４のメモリ容量を低減するために、図２のステップを処理する方法を実行し、受信バッファ４７４のメモリ容量の低減は、サービスゲートウェイ３００が追加のＴＣＰプロキシセッションを処理するための容量を増加させる。
【００４６】
[0047]一実施形態では、ＲＴＴ４９２の所定のパーセンテージまたは所定の値は、異なるクライアントおよびサーバに関する異なるＴＣＰプロキシセッションに関する様々なパーセンテージおよび値を使用する実験を通じて、ユーザによって決定される。典型的には、ＲＴＴ４９２とＲＴＴ４９７との間の差がより小さくなると、より小さいメモリ容量の受信バッファ４７４が必要になる。一実施形態では、ユーザは、ＲＴＴ４９７とＲＴＴ４９２と間の差を低減するように、所望のＲＴＴ４９８を設定する。一実施形態では、所定のパーセンテージは、３０％から５０％の間であり、ユーザによってサービスゲートウェイ３００に設定される。ユーザは、所定のパーセンテージのためのより高い値、またはより小さい受信バッファ４７４の容量のための所望のＲＴＴ４９８を設定することができ、所定のパーセンテージのためのより小さい値、またはより大きい受信バッファ４７４の容量のための所望のＲＴＴ４９８を設定することができる。ユーザは、受信バッファ４７４の容量と所望のＲＴＴ４９８との間をバランスさせるために、所定のパーセンテージおよび所定の値を考慮することができる。
【００４７】
[0048]本発明は、図示された実施形態に従って説明されてきたが、当業者は、実施形態に対する変形形態が存在してもよく、これらの変形形態は、本発明の要素および範囲内になることを容易に認めるであろう。したがって、多くの変更が、当業者によって、添付の特許請求の範囲の要旨および範囲から逸脱することなく、行われてもよい。
【符号の説明】
【００４８】
１００  クライアントデバイス
１５３  データネットワーク
２００  サーバデバイス
３００  サービスゲートウェイ
３１０  プロセッサ
３２０  メモリモジュール
３３０  ネットワークインタフェースモジュール
３４０  コンピュータ可読媒体
３５０  サービスアプリケーション
４００  ＴＣＰプロキシセッション
４２０  クライアント側ＴＣＰセッション
４７０  サーバ側ＴＣＰセッション
４７４  受信バッファ
４７９  ＴＣＰ  Ａｃｋデータパケット
４８０  データパケット
４８７  タイマ
４９２  ＲＴＴ
４９７  ＲＴＴ
４９８  所望のＲＴＴ
【図１】
2014143686.tif 000003
【図１ａ】
2014143686.tif 000004
【図２】
2014143686.tif 000005
【外国語明細書】
2014143686000001.pdf