JP2004530231A - ユーザアプリケーションとサーバ間における改良型相互動作方法 - Google Patents

Abstract

メッセージを伴った通信プロトコルに従って、ユーザ装置（ＵＥ）とサーバ（Ｓ）間における改良されたデータ通信の方法において、前記ユーザ装置（ＵＥ）は前記プロトコルの第１のバージョンに適合し、前記サーバ（Ｓ）は前記プロトコルの第２のバージョンに適合する。データ通信のための接続はプロキシサーバ（ＰＳ）上で実行され、そのプロキシサーバ（ＰＳ）は、前記ユーザ装置（ＵＥ）と前記サーバ（Ｓ）の間で送信される第１のメッセージのプロトコルバージョンを分析して、対応する接続の識別情報を格納する。また、プロキシサーバ（ＰＳ）は、前記識別された接続に対応する応答メッセージを待ち受け、その応答メッセージのプロトコルバージョンを分析する。その接続に対応する応答メッセージ又は更なる別のメッセージは、分析に従って処理される。また、本発明を具体化する装置及びプログラムも開示されている。

Description

【技術分野】
【０００１】
本発明は、請求項１の前提部分（プリアンブル）、即ちユーザ装置とサーバ間における改良型データ伝送方法に関する。そして、本発明を具体化する装置及びソフトウエアプログラムも開示される。
【背景技術】
【０００２】
ワールドワイドウェブを見るために用いられるプロトコルは、ＨＴＴＰであり、主にインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）のリクエスト・フォー・コメント（ＲＦＣ）１９４５で述べられたＨＴＴＰ／１．０やＲＦＣ２６１６で述べられたＨＴＴＰ／１．１である。ＨＴＴＰは、単純な要求と応答のスキームに基づくものである。
【０００３】
閲覧（ブラウジング）は、ワールドワイドウェブ（ＷＷＷ）を見るエンドユーザのユーザ装置、例えば無線端末装置で実行されるプログラムであるところのユーザエージェントによって実行される。ユーザエージェントは、本目的のため、ウェブサーバにコンタクトするが、このウェブサーバは、これに関連して応答を送信することによってリクエストを接続するコンピュータ或いはコンピュータグループ上で実行されるアプリケーションである。ＨＴＴＰプロトコルによるリクエストや応答は、スタートライン、ゼロ個若しくは１以上のヘッダフィールド、ヘッダの末尾や任意のボディを示す空（エンプティ）ラインからなっている。
【０００４】
リクエストに関しては、スタートラインは方式トークン（method token）で始まり、それにＵＲＩ（Uniform Resouce Identifier）やＨＴＴＰバージョンが続いている。方式トークンの例は、ＧＥＴコマンド、即ちこのＵＲＩよって識別されるリソースを取得するユーザエージェントによるリクエストである。基本的にこれは、単純なファイル転送を開始する。リクエスト中のヘッダは、例えばユーザの好みに関する情報（例えば、イメージパラメータや文字セットを定義する希望言語（Accept-Language）、リクエストに関する条件（例えば、If-Modified-Since：HTTP要求ヘッダのフィールドの１つ）や承諾を含むものである。
【０００５】
応答に関して、スタートラインはプロトコルバージョンからなり、それに数値ステータスコード（numeric status code）やnumeric codeを説明する可読なテキストフレーズが続いている。このステータスコード（Status code）は、リクエストが成功であったか否か、または更にどんなステップ（工程）が実行される必要があるか、を記述するものである。応答中のヘッダはまた、コンテンツタイプや主要部（body）のコンテンツ符号化（方法）に関する情報であって、サーバが所定のパラメータ、例えばリソース部を定義する範囲、を受ける情報を提供したり、ウェブサーバ又は次のプロキシが接続を閉じようとしていることを記述することが可能である。
【０００６】
通常ユーザエージェントは、転送チャンネル、例えばＴＣＰ／ＩＰ接続上でＵＲＩによって定義されるリソースに対する主要部無しにリクエストを送信し、ウェブサーバ又は次のプロキシによる応答を待つ。ＲＦＣ１９４５で定義されるプロキシは、他のクライアントのためにリクエストを作成する目的で、サーバ及びクライアントの両方として動作する中間プログラムである。リクエストは、内部的又はそれらを送信して異なるプロトコル間で可能な解釈をすることにより、他のサーバに送信される。プロキシは、リクエストメッセージを送信する前に、それを解釈し、そして必要ならそれを書き換えなければならない。プロキシは、ネットワークファイヤウォールを介したクライアント側ポータルとして、そしてユーザエージェントによって実行されないプロトコルを介したリクエストを処理する補助アプリケーションとして、しばしば用いられる。
【０００７】
ＨＴＴＰ／１．０において、接続は、送信が終われば閉じる。このパターンは、全てのリソース、即ちＵＲＩで識別される全てのオブジェクト又はサービス、に対して繰り返される。今日のウェブページは、多くのリソースからなるので、このことはウェブページのダウンロードの間、かなりの回数起こっていることである。接続を閉じることは、大きな欠点である。なぜなら、新しい接続を確立するために（通信）容量を演算して信号を送信するのに時間がかかるからである。
【０００８】
ＨＴＴＰ／１．１において、ＲＦＣ２６１６によれば、（複数の）接続を、１つの接続は幾つかのリソースを転送するのに用いられうることを常に意味するように維持することが可能であるということが、重要で新しい特徴である。他の新しい特徴として、ユーザエージェントが続けて幾つかのリクエストを、最初のリソースが完全に転送されるのを待つ必要が無く、送信することを可能とするパイプラインである。ユーザエージェントがウェブサーバをパイプラインを行う場合、次のプロキシは、リソースがユーザエージェントによって要求された順番で正確にリソースを送信しなければならない。
【０００９】
ワールドワイドウェブの歴史的進化による問題は、新しいバージョンのプロトコル、例えばＨＴＴＰに適合しない多くのウェブサーバやプロキシが存在することである。基本的機能は一般的に互換性を有するが、即ち、旧バージョンによるコマンドのみを含む場合には新バージョンによるリクエストが旧バージョンに適合するサーバによって処理されうるが、新バージョンで導入される付加的特徴についてはサーバは解釈できず、条件を満たすことができない。このように、新プロトコルバージョンに適合するクライアントは、前バージョンに適合するウェブサーバやプロキシを通信する場合には、上記新しい特徴（feature）からは利益を享受しない。このことは、クライアントとサーバとの間の接続が遅かったり、モデム、ＩＳＤＮ、ＧＳＭ（Grobal System for Mobile Communication）やＧＰＲＳ（General Packet Radio Service）のリンクのように高ラウンドトリップ時間（High Round Trip Time）を有する場合には、特に不都合となる。
【００１０】
別の問題として、ＨＴＴＰ／１．１準拠のウェブサーバやプロキシは、しばしば、ＨＴＴＰ／１．１の永続的接続や他の特徴（feature）を充分に活用していないということがある。例えば、Ｓｑｕｉｄというサーバソフトは、広く普及したキャッシュプロキシであり、即ちリクエストに対する応答を格納し、格納したバージョンによる同じコンテンツのリクエストを提供するプロキシであるが、これは、キャッシュされたバージョンに比べて変化しないリソースに対する条件付リクエストを実行する場合に接続を終わらせてしまう。従って、限られた範囲のプロトコルの特徴（feature）のみが、例えば、サーバにおける又はプログラムエラーによる処理負荷を低減するため、接続で用いられる。これは、たとえユーザエージェントやサーバが同じプロトコルバージョンで適応され、このバージョンが付加的な特徴（feature）を許容するものであっても用いられるものである。
【００１１】
ＧＳＭにおける低バンド幅での無線送信の改良のため、フィルタプロキシが、例えば１９９９年８月に発行された”c't magagin fur computer technik（Verlag Heinz Heise著, ドイツ・ハノーバー市に記述されたものとして提案されてた。フィルタプロキシは、ユーザ装置とサーバ間におけるエアーインタフェースにおけるウェブページからのコンテンツを圧縮し、選択的に削減する。そして、このコンテンツは、ユーザ装置において伸張される。しかしながら、上述のプロキシは、上記問題点を解決するものではないし、プロトコルの改良によって提供される利点を活用するものでもない。
【非特許文献１】
c't magagin fur computer technik（Verlag Heinz Heise著, １９９９年８月）
【発明の開示】
【発明が解決しようとする課題】
【００１２】
発 明 の 目 的
本発明は、上述の不都合を回避し、ユーザ装置とサーバ間の通信における改良されたプロトコルの改良された活用方法を可能にするものである。
【００１３】
発 明 の 概 要
本発明によれば、請求項１に記載された方法が実行される。
【００１４】
さらに、本発明は、請求項１２や１５にそれぞれ述べられているように、装置やソフトウェアプログラムにおいて具体化される。利点のある実施形態は、さらに別の請求項に述べられている。
【００１５】
発 明 の 概 要
提案された方法では、メッセージが送信プロトコルに従って、ユーザ装置とサーバ間で、即ちユーザ装置へ若しくはユーザ装置から、送信される。ユーザ装置、即ちユーザ装置で実行されるユーザエージェントは、前記プロトコルの第１のバージョンに適合され、サーバは前記プロトコルの第２のバージョンに適合している。両バージョンは同一でも異なっていても良い。両者が異なっている場合には、両バージョンは互換性を有する、即ち高位バージョンでも低位バージョンでも両者は処理することができ、どちらも適合するバージョンでメッセージを送信する。しかしながら、高位バージョン部分のみである機能は低位バージョンによる装置では実行されない。
【００１６】
本発明によるデータ通信は、プロキシサーバ上で行われる、つまり、プロキシサーバはメッセージを分析して送信するのである。プロキシサーバは、送信中や送信後にユーザ装置とサーバ間で送信される第１のメッセージのプロトコルバージョンを分析する。それに対応する接続の識別情報（ＩＤ）は、分析結果と共にメモリに格納される。その分析結果には、好ましくは、プロトコルバージョンの識別だけでなく、本バージョンの使用された特徴（feature）も含まれる。
【００１７】
プロキシサーバは、その識別された接続に対応する応答メッセージを待つことになる。そして、プロキシサーバは、その応答メッセージのプロトコルバージョンを分析し、第１のメッセージのバージョンと応答メッセージのバージョンを比較する。この比較は、例えば、そのメッセージヘッダで示されるプロトコルバージョンに基づいて実行される。より効果的なのは、どの機能がその応答やリクエストで許容され又は用いられるか、例えば、ヘッダフィールド中のオプションによって示されているか、をチェックすることである。これにより、示されたバージョンが誤りだったり、装置（entity）がプロトコルバージョンの部分的機能しか使用を許容しない場合には、誤った結果の発生が防止され。そして、プロキシサーバは応答の前に第１のメッセージ源から追加のリクエストを受信することが可能である。この場合、それら（リクエスト）はまた、転送される。
【００１８】
上記分析により、プロキシサーバは、応答メッセージを処理し、或いは、更に接続に対応するメッセージを処理する。特に、許容された機能は比較され、そしてヘッダフィールドは、メッセージ転送前に機能を適合させるために、変更されうる。さらに、プロキシサーバは、メッセージを再送する必要があるか否かをチェックする。これは、目標とする装置（entity）が処理に適合しない、例えば、パイプライン処理に適合しないからである。また、他の分析によれば接続が継続しているが、ある分析では接続の切断が検出された場合には、再接続が実行され、最小限度の遅延で更なるメッセージの送信を実行することができる。
【００１９】
提案された方法によれば、ユーザエージェントは、改良されたプロトコルバージョン、例えば、ＨＴＴＰの高位バージョンの特徴（feature）を活用することができる。これによって、送信データ量の削減による負荷時間の減少や、或いは、豊富なビルサービス（volume-billing services）に対するコスト削減が可能となる。接続確立のための信号送信容量および処理容量もまた減少させることができる。提案された方法の応用も、ユーザエージェントやサーバが同一のプロトコルバージョンに適合されるが、そのバージョンの特徴（feature）を部分的にのみ用いる場合に、利点となるものである。
【００２０】
好適な実施形態では、プロキシサーバは、上記分析に従って接続に対応する、応答メッセージのプロトコルバージョン或いは更なるメッセージのプロトコルバージョンを変換する。例えば、応答メッセージのプロトコルバージョンが低位である場合には、プロキシサーバは、応答メッセージのプロトコルバージョンを、応答メッセージ転送前に、上記第１のメッセージのプロトコルバージョンに変換することができる。応答メッセージのプロトコルバージョンが高位である場合には、第１のメッセージ源（source）からの、即ち接続に対応する、どんな更なるメッセージのプロトコルバージョンでも高位のプロトコルバージョンに変換されうるのである。バージョンの変換は、例えば、ヘッダの書き換え、より具体的には、ＨＴＴＰ／１．０と比較してＨＴＴＰ／１．１において新規なヘッダフィールドの削除や変更から構成される。それらのヘッダフィールドは、それぞれプロトコルバージョン間（ＨＴＴＰ／１．０とＨＴＴＰ／１．１間）でダウングレードしたり、アップグレードしたりして、削除、変更されるものである。それにより、バージョンによって与えられる特徴（feature）を最適に活用することが可能となる。
【００２１】
更なる好適な実施形態では、プロキシサーバは、第１のメッセージのプロトコルバージョンを、プロキシサーバに用いられる最高位のバージョンにアップグレードする。このように、プロキシサーバは、サーバがプロキシサーバの最大範囲の機能に適合するか否かチェックすることができる。
【００２２】
有効なプロキシサーバは、メッセージを格納する少なくとも１つのバッファを有する。これにより、転送エラーであったり、受信側のプロトコルバージョンが処理に適合しないという理由で、適切な結果が受信されないメッセージに対して迅速な再送信が可能となる。
【００２３】
好ましくは、プロキシサーバは、接続が切断されているかの情報のためのメッセージヘッダを分析して、特にチェック結果が接続に対応するバッファが未送信のメッセージを格納していることを示している場合には、再度接続を確立する。このように、格納されたメッセージは、最小限の遅延で送信することが可能である。好ましくは、上記情報は、同接続がまた切断されることを避けるために、更なる装置（entity）に転送されない。これにより、送信における遅延と（無駄な）信号送信を削減する。
【００２４】
方法についての有効な実施形態では、応答メッセージが、第１のメッセージでリクエストされていない情報についてチェックされ、その情報は応答メッセージから削除される。例えば、ユーザはウェブページから限定された範囲をリクエストする一方、サーバはその範囲に関するリクエスト（range request）を考慮することはない。この場合、リクエストされない情報は、メッセージサイズを減少させるために、メッセージボディ部（message body）から削除することができる。
【００２５】
好ましくは、メッセージ内容は、上記分析に従って、プロキシサーバにおいて圧縮又は伸張される。このように、プロキシサーバへの送信が圧縮されずに実行されても、リンク上の不足した送信容量は確保（save）することができる。圧縮は特に、無線リンクには有効であるが、また、圧縮はコアネットワークを介した送信に対しても実行することができる。また、圧縮タイプを変更したり、別のタイプのリンクに適合させたりすることも可能である。
【００２６】
好ましくは、冗長情報を、メッセージ、例えばリクエストや応答から削除し、送信メッセージサイズを減少する。例えば、メッセージヘッダは、よく、冗長情報を含むものである。
【００２７】
提案された方法によるサーバについては、必ずしもコンテンツプロバイダではなく、データ通信における別のプロキシ（further proxy）とすることも可能であり、ここでこのデータ通信は、プロキシがさらに別のサーバ、即ち更に別のサーバやコンテンツサーバ、からデータを転送するものである。この場合、コンテンツサーバもユーザ装置も、高位プロトコルに適合され、一方で、データ通信における少なくとも１つの別のプロキシは、低位バージョンに適合されるのみである。提案された方法によれば、その別のプロキシによる送信パラメータの劣化（degradation）が避けられる。
【００２８】
提案された方法は、送信プロトコルがＨＴＴＰプロトコルである場合に特に有効であるが、このプロトコルに限定されない。
【００２９】
提案された方法は、少なくとも１つの接続がハイ・ラウンド・トリップ・タイム（high round trip time）又はロー・データ・レート（low data rate）で、若しくは双方で、リンク上において実行される場合は、特に利点を有する。これらの条件の少なくとも１つは、例えば、無線接続、例えば、ＧＳＭやＧＰＲＳシステムの場合に実現される。その方法はまた、ＵＭＴＳ（Universal Mobile Telecommunication System）無線アクセスシステムにとっても有効である。その方法は、ユーザ装置に隣接した接続、例えばユーザエージェントが実行される移動体端末への無線リンクが、ハイ・ラウンド・トリップ・タイム（high round trip time）を有する場合に、特に提案される。
【００３０】
本発明によるプロキシサーバによれば、メッセージ付送信プロトコルに従って、ユーザ装置とサーバ間における改良されたデータ通信を可能にするものである。プロキシサーバは、プロトコルに従ってメッセージを分析するように適合された処理システムとデータ通信に対する接続が実行されるインタフェースを備えている。その処理システムは、ユーザ装置とサーバ間で送信される第１のメッセージのプロトコルバージョンを分析し、対応する接続の識別情報（ＩＤ）と分析結果をメモリに格納する。その処理システムは、応答メッセージの識別情報（ＩＤ）が格納された識別情報に対応するものであるかについて応答メッセージを分析する。その処理システムは、さらに、その格納された識別情報に対応する応答メッセージのプロトコルバージョンを分析する。処理システムは、分析に従って、接続に対応する応答メッセージ又はさらに別のメッセージを処理する。それ（処理システム）は、応答メッセージのプロトコルバージョンを、例えば、比較分析に従って、接続に対応する第１のメッセージのプロトコル又はさらに別のメッセージプロトコルに変換する。プロキシサーバは、好ましくは、上述のいずれかの方法を実行するように適合される。
【００３１】
好ましくは、プロキシサーバは、無線送信システムのアクセスネットワーク中に配置、例えば、無線基地局、基地局コントローラ、或いは無線ネットワークコントローラで実施され、或いはそれらのいずれかに接続される。
【００３２】
本発明によるプログラムユニットは、例えば、一連の信号列として、データキャリア上に保存されたり、プロキシサーバに取り込まれうるものである。そのプログラムユニットは、上述の方法の実施形態のいずれかを実行するものである。
【００３３】
本発明の前術した、そして他の目的、特徴や利点は、添付図面に示される好適な実施の形態に関する次の詳細な記載において明らかになるものである。
【発明を実施するための最良の形態】
【００３４】
図１は、ユーザ装置ＵＥとサーバＳ間のデータ通信の具体例を示している。ここで、ユーザ装置ＵＥは、例えば、ユーザエージェントが実行される処理システムを用いた移動体端末である。そのデータ通信は、特定のプロトコル、例えばＨＴＴＰに従って実行される。データ通信のルートは、ユーザ装置ＵＥとアクセスネットワークＡＮの無線基地局との間の無線リンクＷＬを含む幾つかの接続を備えるものである。そのデータ通信における別の接続は、通信システム、例えばＧＳＭやＵＭＴＳシステムのコアネットワークＣＮや具体例中のサーバＳが接続されるインターネットＩＮを介して確立される。前述の接続は、パケット交換（packet switched）や回路交換（circuit switched）とすることができる。
【００３５】
データ通信が確立される、示されたネットワークＡＮ、ＣＮ、ＩＮ或いは他のネットワークにおいて、複数の別のサーバ（further servers）は、ユーザ装置ＵＥとサーバＳとの間で送信されるデータの転送を実行する。また、プロキシサーバ（複数）が、例えば、ネットワークの境界やネットワーク内に存在するようにしても良い。多数及び異なるオペレータによって、通信プロトコルの改良バージョンが使えると、接続を処理する全サーバがアップグレードされることは、一般的に可能ではないし、現実的でもない。従って、接続は、異なる能力を有する別のサーバ（further servers）を介してしばしば確立される。また、サーバＳとユーザ装置ＵＥによって用いられるプロトコルバージョンは異なり、両者（entities）のうち１つは、例えば、高負荷の場合に処理容量を節約するため、あるプトコルバージョンの全ての特徴（feature）は用いなくてもよい。これは、ユーザ装置ＵＥが無線リンクＷＬ上で効率的なデータ通信を可能とする新しいプロトコルバージョンに適合する場合に特に不利益となる。無線リソース、例えばバンド幅は、充分でなく、高価だからである。
【００３６】
この問題の解決策として、ＨＴＴＰプロトコルに特に有益な上記提案された方法がある。その解決策の中心的な考えは、ユーザエージェントとウェブサーバとの間にプロトコルブーストプロキシサーバＰＳ（protocol boosting proxy server）を導入することである。好ましくは、プロキシサーバＰＳは、ユーザエージェントの近くに、例えば、アクセスネットワーク中、より詳しくは、無線基地局やユーザ装置に無線リンクを供給する無線ネットワークコントローラに配置される。ほとんど全ての通例のユーザエージェントは、リクエストに応じてウェブサーバからリソースを検索するプロキシをサポートするものである。提案されたプロトコルブーストプロキシサーバＰＳは、最新のプロトコルバージョンに従って、全範囲のプロトコルフィーチャをサポートする。このように、完全に特徴（feature）づけられたユーザエージェントは、ターゲットとなるウェブサーバ或いは次のプロキシがどんな特徴（feature）を可能とするかに関係なく、その全ての特徴（feature）を用いることができる。
【００３７】
さらに、プロトコルブーストプロキシは、できるだけ効率的であるために、ウェブサーバ又は他のプロキシと通信するときにできるだけ多くの特徴（features）を用いるようにする。
【００３８】
提案されたプロトコルブーストプロキシサーバＰＳは、好ましくは、リクエストアナライザと応答アナライザである２つの主要部を備えている。提案された方法によるデータ通信の処理についての具体例が、図２のフローチャートに関して説明されている。
【００３９】
第１のステップ１０では、リクエストアナライザは、ユーザエージェントが、例えば、ＴＣＰ／ＩＰ接続上でつながるのを待っている。接続されると、リクエストアナライザは、ステップ１２においてこの接続のためのＦＩＦＯ（first in, first out）バッファを割り当てる。そして、ステップ１２では、バッファはユーザエージェントからのリクエストを格納する。ステップ１４においてリクエスト（requests）が受信されると、リクエストはプロトコルブーストプロキシに有用な最高位プロトコルバージョンにアップグレードされ、アップグレードされたバージョンは、次のプロキシ又はターゲットウェブサーバ（ステップ１６）に転送される。そのリクエストは、好ましくは、後の使用のために保存される。これにより、次のプロキシ又はターゲットウェブサーバがパイプライン処理をサポートしないが、ユーザエージェントがパイプライン処理を実行したい場合に、リクエストを再送信することが可能となる。
【００４０】
リクエストに対応する応答は、待機動作のステップ１８の後に到着する。次の分析及び変換ステップ（工程）２０において、複数のステップが次に述べられるように実行されうる。これらのステップのうち１、又は幾つかが実行可能である。特に、応答アナライザは、ステップ（工程）２０における応答や応答ヘッダをユーザエージェントが適合される最高位ＨＴＴＰバージョンに変換、例えば、ダウングレード（downgrade）する。
【００４１】
チェックステップ２２が図２においてステップ２０とは別に示されているが、ステップ（工程）２０の一部とすることも可能である。応答アナライザは、次のプロキシ又はターゲットウェブサーバが接続を切断するであろう場合には、応答ヘッダを検査する。この場合、プロトコルブーストプロキシは、分析中のこのヘッダフィールド及び変換ステップ（工程）２０を削除し、ユーザエージェントがその接続を永続的なものであるとみなすことを保証する。さらに、第２のチェックステップ２４では、ＦＩＦＯバッファにリクエスト（どんなリクエストでも）が残っているかチェックされる。ウェブサーバ又は次のプロキシは、接続を切断した後ではこれらのリクエストを実現することはない。従って、ステップ２６において、プロトコルブーストプロキシは次のプロキシ又はウェブサーバに再接続して、ＦＩＦＯバッファから第１のリクエストを再送する。ステップ２６では、第１のリクエストのみが再送される。なぜなら、以前の接続が切断されたので、プロトコルブーストプロキシはウェブサーバ又は次のプロキシがパイプライン処理をサポートしないと認識するからである。そして、対応する応答は、存続する接続上でユーザエージェントに返信される。ＦＩＦＯバッファにおける別のどんなリクエストに対しても、プロトコルブーストプロキシは、サーバに対する新しい接続を作り、リクエストを再送し、応答を処理し、それをユーザエージェントに転送することによって、同様な方法で処理を進行させる。
【００４２】
ステップ２８でその応答がユーザエージェントに送信される前に、プロトコルブーストプロキシは、ステップ２０において、ウェブサーバ又は次のプロキシの応答の主要部（body）が圧縮されたものであるか否かを選択的にチェックする。圧縮されておらず、ユーザエージェントからのリクエストヘッダが、プロトコルブーストプロキシもサポートする圧縮をサポートしていると示している場合、そのプロキシは適切な圧縮をその主要部に適用する。このように、削減された量のデータ（即ちバイト数分）が、ユーザエージェントに送信される。プロトコルブーストプロキシが、既にリンク特性を、例えばデータレート又はラウンドトリップタイムの測定によって、或いはその実行によって、認識している場合には、この判断（圧縮bodyか否かの判断）はリンク特性のチェックステップにおいてキャンセルされるようにしても良い。この実施形態の利点は、リンクが高速の場合には、圧縮によって発生する待ち時間が圧縮された主要部を送信することにより節約される時間より長くてもよいということである。
【００４３】
さらなるオプションとして、プロトコルブーストプロキシは、ステップ２０において、ユーザエージェントは、範囲が定められたリクエスト（range request）を送信し、ウェブサーバ又は次のプロキシがそれを実行、即ち全オブジェクトではなくリクエストされた範囲のオブジェクトのみを送信するか否かをチェックする。全オブジェクトがプロトコルブーストプロキシに送られた場合、そのプロキシは、好ましくは、ステップ２０におけるこの応答を、所定部分、即ちユーザエージェントからリクエストされていない主要部のバイト分を取り除くことにより、部分的応答に変換する。このようにデータ量は、待ち時間を発生させることなく、削減することができる。
【００４４】
さらに、プロトコルブーストプロキシがステップ２０において、幾つかのサーバによって送信される冗長ヘッダフィールド、例えば”コンテンツ符号化（Content-Encoding）：識別情報（ＩＤ）”を削除する場合、即ち符号化が用いられない場合、送信データ量は、削減されうる。
【００４５】
この処理が終了し、適合したリクエストが転送されると、格納されたリクエストはもう必要が無く、ステップ３０においてＦＩＦＯバッファから削除される。さらに、チェックステップ３２、３４は、バッファが空か否か、接続が切断されているかについて実行され、そして処理がリクエスト又は応答の待機ステップ１４、１８に移行すべきか、或いは処理を終了すべきかを判断する。リクエスト又は応答は、ステップ１４と１８を指す矢印３６、３８で示される処理が行われている間はいつでも、プロトコルブーストプロキシによって受信されるようにしても良い。幾つかのメッセージがパラレルに処理されうる、例えば、応答がステップ２０で処理されている間にリクエストがステップ２６で再送信されるようにしても良い。最後に、当業者であれば、ユーザエージェントが同一の或いは異なるサーバと同時に幾つかの接続を有しているということは認識することである。
【００４６】
図３は、ユーザ装置ＵＥとサーバＳとの間のデータ通信を示しており、そこでは接続は、本発明によるプロキシサーバＰＳと別のプロキシサーバＰ２、例えばインターネットにおけるキャッシュサーバに対して確立されている。データ通信におけるＰ２以外の他の全ての装置（entities）は新しいプロトコルバージョンＨＴＴＰ／１．１に適合する一方、別のプロキシサーバＰ２は旧バージョンＨＴＴＰ／１．０にのみ適合する。ユーザ装置ＵＥにおけるユーザエージェントとサーバＳは、両者とも、無線リンクＷＬ上の無線リソースを効率的に活用することを可能にするプロトコルバージョンに適合するが、このバージョンは最新技術では用いることはできない。なぜならば、その別のサーバ（Ｐ２）はＨＴＴＰ／１．０によるメッセージのみを送信するからである。本発明のプロキシサーバＰＳは、別のプロキシサーバＰ２によって送信されるメッセージを、無線リンクＷＬの改良利用を可能にするプロトコルバージョンＨＴＴＰ／１．１にアップグレードしなおす。
【００４７】
上述の処理を実行するため、プロキシサーバには、処理システムＰＲが備えられる。この処理システムＰＲは、ユーザ装置と別のプロキシサーバＰ２のそれぞに対するインタフェースＩ１、Ｉ２上で送受信されるメッセージを分析し、変換するようになされている。メモリＭＥＭにより、適切な応答が受信されない場合にメッセージを格納し、例えば、それらを再送することが可能になる。図面上明示されてはいないが、当業者なら、データ通信中の他の装置（entities）もまた処理システムやインタフェースを備えているものと認識するものである。
【００４８】
図４において、本発明による方法におけるメッセージシーケンスが示されている。この具体例において、ユーザ装置ＵＥは、メッセージプロトコルのバージョンｘに適合し、一方で、プロキシサーバＰＳはバージョンｚ、サーバＳは旧バージョンｙに適合するものとする。バージョンｘとｚはメッセージのパイプライン処理を可能とするが、バージョンｙはそれに対応していない。例えば、バージョンｘとｚは、ＨＴＴＰ／１．１で、一方、バージョンｙはＨＴＴＰ／１．０とすることができる。
【００４９】
ユーザ装置上のユーザエージェントは、接続ｃ上のプロトコルｘに従って、リソースに対する２つのリクエスト４１，４２を送信する。プロキシサーバは、メッセージ４１を分析し、ユーザ装置ＵＥ上のユーザエージェントへの接続ｃで用いられるプロトコルバージョンｘを格納する。プロキシサーバは両メッセージを、サーバが適合される最高位のバージョンであるバージョンｚに変換し、それらを格納し、サーバＳにリクエスト４１’、４２’として送信する。サーバＳは、リクエスト４１’があり次第、バージョンｙによる応答４３を送信し、一方リクエスト４２’は処理されない。バージョンｙはパイプライン処理に対応していないからである。プロキシサーバは応答４３を受信し、接続がバージョンｙに対応するものであるか分析し、この情報（分析結果）を格納する。ユーザ装置ＵＥへの接続ｃに対する情報に従って、プロキシサーバＰＳは、メッセージ４３を、メッセージ４３’としてユーザ装置ＵＥに送信する前に、バージョンｘに変換する。
【００５０】
また、プロキシサーバＰＳは、応答４３の分析から、プロトコルバージョンｙがパイプラインに対応しないため、リクエスト４１が処理されなかったということを認識している。
【００５１】
従って、リクエストが、リクエスト４２”としてバージョンｙに従って再送信される。このリクエストに対する応答４４、４４’は、他のメッセージ４５、４５’、４６、４６’と同様に、同じ接続上で、ユーザ装置ＵＥとプロキシサーバＰＳの間はプロトコルｘに従って、プロキシサーバＰＳとサーバＳの間はプロトコルｙに従って、プロキシサーバＰＳが変換処理をしながら、送信される。しかしながら、パラレルな接続ｃ’がユーザエージェントからサーバＳに設定されると、この接続は一般的に新たな接続として扱われ、従ってリクエスト４７が、対応するレスポンスが接続ｃ’上で受信されるまで、プロトコルｚに従ってリクエスト４７’として、再度送信される。
【００５２】
上記実施形態によって、本発明の目的が的確に達成される。
【００５３】
しかしながら、添付特許請求の範囲によって明らかにされる本発明の技術的範囲を逸脱しない限りにおいて、変形、変更が当業者によってなしうるものであることは明らかである。
【図面の簡単な説明】
【００５４】
【図１】図１は、ユーザ装置とサーバ間におけるデータ通信を表す図である。
【図２】図２は、本発明による方法の動作を示すフローチャートである。
【図３】図３は、幾つかのプロキシを含む接続を示す図である。
【図４】図４は、本発明による方法におけるメッセージシーケンスを示す図である。

Claims (15)

1. メッセージを伴った通信プロトコルに従って、ユーザ装置（ＵＥ）とサーバ（Ｓ）間における改良されたデータ通信の方法であり、前記ユーザ装置（ＵＥ）は前記プロトコルの第１のバージョンに適合し、前記サーバ（Ｓ）は前記プロトコルの第２のバージョンに適合し、前記データ通信のための接続はプロキシサーバ（ＰＳ）上で実行される通信方法であって、
   前記プロキシサーバ（ＰＳ）は、
   前記ユーザ装置（ＵＥ）と前記サーバ（Ｓ）の間で送信される第１のメッセージのプロトコルバージョンを分析して、対応する接続の識別情報を格納し、
   前記識別された接続に対応する応答メッセージを待ち受け、
   前記応答メッセージのプロトコルバージョンを分析し、
   前記分析に従って、前記接続に対応する前記応答メッセージ又は更なる別のメッセージを処理する、
   ことを特徴とする改良データ通信方法。
2. 前記プロキシサーバ（ＰＳ）は、前記分析に従って、前記接続に対応する前記応答メッセージのプロトコルバージョン又は前記更なる別のメッセージのプロトコルバージョンを変換することを特徴とする請求項１に記載の改良データ通信方法。
3. 前記プロキサーバ（ＰＳ）は、前記第１のメッセージのプロトコルバージョンを、前記プロキシサーバに有効な最高位のバージョンにアップグレードすることを特徴とする請求項１又は２に記載の改良通信方法。
4. 前記プロキシサーバ（ＰＳ）は、メッセージを格納する、少なくとも１つのバッファを有することを特徴とする請求項１乃至３のいずれか１項に記載の改良通信方法。
5. 前記プロキシサーバ（ＰＳ）は、接続が切断されているかの情報のためのメッセージヘッダを分析し、前記接続を再度確立することを特徴とする請求項１乃至４のいずれか１項に記載の改良通信方法。
6. 前記応答メッセージは、前記第１のメッセージで要求されていない情報についてチェックされ、前記情報は前記応答メッセージから削除されることを特徴とする請求項１乃至５のいずれか１項に記載の改良通信方法。
7. 前記メッセージの少なくとも１つのコンテンツは、前記分析の比較に従って、圧縮され、又は伸張されることを特徴とする請求項１乃至６のいずれか１項に記載の改良通信方法。
8. 冗長情報は、前記メッセージの少なくとも１つから削除されることを特徴とする請求項１乃至７のいずれか１項に記載の改良通信方法。
9. 前記サーバ（Ｓ）は、更なる別のサーバからのデータを転送するプロキシであることを特徴とする請求項１乃至８のいずれか１項に記載の改良通信方法。
10. 前記通信プロトコルは、ＨＴＴＰプロトコルであることを特徴とする請求項１乃至９のいずれか１項に記載の改良通信方法。
11. 少なくとも１つの接続が、ハイ・ラウンド・トリップタイム（high round trip time）又はロー・データ・レート（low data rate）で動作するリンク上で実行されることを特徴とする請求項１乃至１０のいずれか１項に記載の改良通信方法。
12. メッセージを伴った通信プロトコルに従って、ユーザ装置（ＵＥ）と更なる別のサーバ（Ｓ）間における改良されたデータ通信のためのプロキシサーバであり、前記プロキサーバ（ＰＳ）は、前記プロトコルに従ってメッセージを分析するようにする処理システムと、前記データ通信のための接続が実行されるインタフェースとを備えるプロキシサーバであって、
    前記処理システムは、
    前記ユーザ装置（ＵＥ）と前記更なる別のサーバ（Ｓ）の間で送信される第１のメッセージのプロトコルバージョンを分析して、対応する接続の識別情報をメモリに格納し、
    前記識別された接続に対応する応答メッセージを待ち受け、
    応答メッセージの識別情報が格納された識別情報に対応するか否か、応答メッセージを分析し、
    前記格納された識別情報に対応する応答メッセージのプロトコルバージョンを分析し、
    前記分析に従って、前記接続に対応する前記応答メッセージ又は更なる別のメッセージを処理する、
    ことを特徴とするプロキシサーバ。
13. 前記プロキシサーバ（ＰＳ）は、無線通信システムのアクセスネットワーク（ＡＮ）に配置されていることを特徴とする請求項１２に記載のプロキシサーバ。
14. 前記プロキシサーバ（ＰＳ）は、請求項１乃至１１のいずれかの通信方法を実行するようすることを特徴とする請求項１２又は１３に記載のプロキシサーバ。
15. 請求項１乃至１１のいずれかの通信方法の工程を実行するためのコードを有するプログラムユニット。

Images