(57)【要約】【課題】  本発明は、集合し、かつ、フロー制御されたチャネルを介して、同時にオブジェクトをプリフェッチすることによって、長い待ち時間リンクのHTTPのパフォーマンスを増加させる。【解決手段】  エージェントおよびゲートウェイは、共に、長い待ち時間データリンクのインターネットウェブサイトからより速くHTTPコンテンツをフェッチする際のウェブブラウザをアシストする。ゲートウェイおよびエージェントは、常駐ブラウザが要求する前にオブジェクトがホストプラットホームで動作可能および利用可能であるように、この種の手段で選択的な埋め込みオブジェクトのフェッチングを調整する。表面上はブラウザに対するオブジェクトを瞬間的に利用可能で、次のオブジェクトを要求するための長い待ち時間なくオブジェクト処理を完了することができる。埋め込みオブジェクトのこの瞬間アベイラビリティがなければ、ブラウザは、要求および対応する応答に長い遅延リンクが通り抜けるのを待つ。【選択図】  図1
2008541239.tif 000002
【特許請求の範囲】
【請求項１】
ブラウザによって、複数のウェブページオブジェクトを備えるウェブページを表示する装置であって、当該ウェブページオブジェクトが、長い待ち時間リンクにより個々にフェッチされなければならず、
集合されかつフロー制御されたチャネルを介して同時にオブジェクトを選択的にプリフェッチするための手段と、
当該ブラウザのすぐ近くの当該プリフェッチされたオブジェクトをキャッシュするための手段とを有し、
当該ウェブページオブジェクトへのシーケンシャルなアクセスが、ブラウザの動作を変更すること無く、低いバンド幅および高い遅延ネットワークで提供される、装置。
【請求項２】
選択的にプリフェッチするための当該手段が、エージェントからゲートウェイサーバまで当該プリフェッチを実行し、かつ、並列性の低い程度が、当該ブラウザと当該エージェントとの間でローカライズされる、請求項１の装置。
【請求項３】
選択的にプリフェッチするための当該手段が、対応するサーバモジュールと通信するためのモジュールから成り、かつ、必要なウェブページオブジェクトに当該ブラウザのホストをつとめているプラットホームで利用可能に準備をさせる、請求項１の装置。
【請求項４】
当該エージェントおよび当該ゲートウェイが、共同して、選択的に埋め込まれたウェブページオブジェクトのフェッチを調整することによって、ウェブページオブジェクトをフェッチする際の当該ウェブブラウザをアシストし、
選択された埋め込まれたウェブページオブジェクトが、当該ブラウザに対しローカルに利用可能であり、かつ、
当該ブラウザが、オブジェクトが利用可能となる前に、要求および対応する応答が長遅延リンクを通り抜けるのを待つ必要がない、請求項２の装置。
【請求項５】
ブラウザおよびホストプラットホームに関連づけられたエージェントと、
ソースウェブサーバと通信するゲートウェイと、
当該エージェントと当該ゲートウェイとの間の長い待ち時間リンクと、
当該低い待ち時間リンクを介して当該ソースウェブサーバから当該ブラウザまで並列にウェブページオブジェクトをダウンロードするための独立フロー制御機構（VTP）と、
当該エージェントが、当該ブラウザおよび当該ソースウェブサーバの実施とは独立してそれらを認識すると即座に、ウェブページオブジェクトが並列に選択的にダウンロードされる当該ホストプラットホームと関連しているキャッシュとを、
備える装置であって、
選択された埋め込まれたウェブページオブジェクトが、当該エージェントによって当該キャッシュで当該ブラウザに対しローカルに利用可能にされ、かつ、
当該ブラウザが、ウェブオブジェクトが利用可能となる前に、要求および対応する応答が当該長い待ち時間リンクを通り抜けるのを待つ必要がない、装置。
【請求項６】
ホストプラットホーム内のブラウザと、
プリフェッチ機能およびウェブオブジェクトキャッシュを有するエージェントを備える当該プラットホームと関連しているクライアントであって、当該エージェントが、選択され、シーケンシャルにロードされたウェブページオブジェクトを明確にプリフェッチし、かつ当該ウェブオブジェクトキャッシュに当該プリフェッチされたオブジェクトを記憶しているクライアントと、
フロー制御されたチャネルを有する長い待ち時間リンクを介して経た当該クライアントと通信するサーバと、
当該サーバと通信するオリジナルウェブサーバとを、
備える、長い待ち時間リンクのHTTPのパフォーマンスを増加させる装置であって、
当該ブラウザを介してその要求に従って当該オリジナルウェブサーバから要求された、シーケンシャルにロードされたウェブページオブジェクトが、当該エージェントを介して当該ウェブオブジェクトキャッシュにロードされ、
当該シーケンシャルにロードしたウェブページオブジェクトは、利用可能であり、かつ、当該要求に応じて当該ウェブオブジェクトキャッシュからロードされ、かつ、
当該要求およびそれに対しての応答が、当該長い待ち時間リンクを通り抜けない、装置。
【請求項７】
当該シーケンシャルにロードされたオブジェクトが、JavaScriptおよびStyle Sheetsの何かを備える、請求項６の装置。
【請求項８】
クライアントに関連したブラウザが、当該長い待ち時間リンクの第１端部からウェブページを要求するステップと、
ゲートウェイが、当該長い待ち時間リンクの第２端部で当該要求を受信するステップであって、当該ゲートウェイが、オリジナルウェブサーバからウェブページ記述をretrieveし、かつ当該長い待ち時間リンクを介して当該ウェブページ記述を当該クライアントに送信するステップと、
当該ブラウザが、当該ウェブページ記述を受信し、かつ、解析するステップと、
当該ウェブページ記述が、当該ウェブページをロードするために当該ブラウザによって作動される間、通常はシーケンシャルにフェッチされる選択されたウェブページオブジェクトタイプのオブジェクトを特定する当該ブラウザと無関係にかつ同時に当該ページ記述を解析するステップと、
当該ブラウザが当該ウェブページをさらにロードしている間、当該オブジェクトをフェッチして、当該オリジナルウェブサーバにアクセスするために当該ブラウザと同時にプリフェッチ機構を使用するステップと、
当該プリフェッチ機構により当該オブジェクトをフェッチした後に、ローカルキャッシュに当該オブジェクトを記憶するステップと、
当該オブジェクトが当該ウェブページのロードを完了するために、当該ブラウザが、当該ローカルキャッシュにアクセスするステップとを、
備える、長い待ち時間リンクのウェブページのロードの実行を増やす方法であって、
当該ブラウザが、当該長い待ち時間リンクを介して当該オブジェクトを要求せずに、当該オブジェクトが、ロードされる、方法。
【請求項９】
解析する当該ステップが、当該ウェブページにJavaScriptやStyle Sheetsがあるか否かを決定し、かつ、当該プリフェッチ機構が、当該ブラウザによる当該ウェブページのロードと同時に、当該オブジェクトをフェッチする、請求項８の方法。
【請求項１０】
当該プリフェッチ機構が、如何なる特定オブジェクトの選択的プリフェッチも実行するステップであって、プリフェッチング動作が前記ブラウザにすでに要求されたオブジェクトの前記フェッチを遅延させた前記影響を減らすために、何れのオブジェクトが、選択的にプリフェッチされるべきかを決定するために、当該プリフェッチ機構が、発見的手法、規則および適応的行動の何れを適用するステップを備える、請求項８の方法。
【請求項１１】
当該ウェブページが、集中化された時点で如何なる発見的手法の適用によっても当該ゲートウェイによって提供されるメタタグを備え、
何れのオブジェクトが、選択的にプリフェッチされるべきかを決定するために当該プリフェッチ機構により当該メタタグを解釈するステップを備える、請求項８の方法。
【請求項１２】
複数のウェブページオブジェクトを備えるウェブページをブラウザによって表示する方法であって、当該ウェブページオブジェクトが、長い待ち時間リンクにより個々にフェッチしなければならず、当該方法が、
集合化されかつフロー制御されたチャネルを介して、同時に、オブジェクトを選択的プリフェッチするステップと、
当該ブラウザのすぐ近くの当該プリフェッチされたオブジェクトをキャッシングするステップとを、
備え、
当該ウェブページオブジェクトに対するシーケンシャルアクセスが、ブラウザ動作を変更せずに、低バンド幅および高遅延ネットワークで提供される、方法。
【請求項１３】
選択的にプリフェッチする前記ステップが、エージェントからゲートウェイサーバまで当該プリフェッチを実行するステップを更に含み、かつ、並列性の低い程度が、当該ブラウザと当該エージェントとの間でローカライズされる、請求項12の方法。
【請求項１４】
選択的にプリフェッチする当該ステップが、対応するサーバモジュールと通信するステップと、当該ブラウザでホスティングするプラットホームで必要なウェブページオブジェクトが利用可能となるように準備するステップとを更に含む、請求項12の方法。
【請求項１５】
当該エージェントおよび当該ゲートウェイが、共に、協調することによって、当該ウェブブラウザをアシストして、選択的に埋め込まれたウェブページオブジェクトのフェッチングを調整することにより、ウェブページオブジェクトをフェッチングし、選択された埋め込まれたウェブページオブジェクトが、ローカルに当該ブラウザに対し利用可能であり、かつ、当該ブラウザが、オブジェクトが利用可能となる前に、要求および対応する応答が長遅延リンクを通り抜けるのを待つ必要がない、請求項13の方法。
【請求項１６】
ホストプラットホーム内でブラウザを使用するステップと、
プリフェッチ機能およびウェブオブジェクトキャッシュを有するエージェントを備える当該プラットホームと関連しているクライアントを提供するステップであって、当該エージェントが、選択され、シーケンシャルにロードされたウェブページオブジェクトを明確にプリフェッチし、かつ当該ウェブオブジェクトキャッシュ内に当該プリフェッチされたオブジェクトを記憶するステップと、
フロー制御されたチャネルを有する長い待ち時間リンクを介して当該クライアントと通信するサーバを提供するステップと、
当該サーバと通信するオリジナルウェブサーバにアクセスするステップと、
を備える、長い待ち時間リンクによるHTTPのパフォーマンスを増加させる方法であって、
当該ブラウザを介してその要求に従って当該オリジナルウェブサーバから要求されるシーケンシャルにロードしたウェブページオブジェクトが、当該エージェントを介して当該ウェブオブジェクトキャッシュにロードされ、当該シーケンシャルにロードしたウェブページオブジェクトが、当該ウェブオブジェクトキャッシュで利用可能で、かつ、当該要求に応じて当該ウェブオブジェクトキャッシュからロードされ、かつ、当該要求およびそれに対しての応答が、当該長い待ち時間リンクを通り抜けない、方法
【請求項１７】
当該シーケンシャルにロードされたオブジェクトが、JavaScriptおよびStyle Sheetsのいずれかを含む、請求項16の方法。
【請求項１８】
当該長い待ち時間リンクの第１端部からウェブページを要求するクライアントと関連したブラウザであって、ウェブページ記述を受信し、かつ、解析している当該ブラウザと、
当該長い待ち時間リンクの第２端部で当該要求を受信するゲートウェイであって、オリジナルウェブサーバおよび当該長い待ち時間リンクを経た当該ウェブページ記述をクライアントに送信する当該ゲートウェイと、
無関係に当該ページ記述を解析するためのパーサと同時に、当該ウェブページ記述が当該ウェブページをロードするために当該ブラウザによって機能される間、通常はシーケンシャルにフェッチされる選択されたウェブページオブジェクトタイプのオブジェクトを特定する当該ブラウザと、
当該ブラウザが当該ウェブページをさらにロードする間、当該オブジェクトをフェッチするために当該ブラウザと同時に使用する当該オリジナルウェブサーバにアクセスするプリフェッチ機構と、
当該プリフェッチ機構を有する当該オブジェクトのフェッチの後の当該オブジェクトの記憶のためのローカルキャッシュとを、
備える、長い待ち時間リンクをロードしているウェブページのパフォーマンスを増加させる装置であって、
当該ブラウザが、当該ウェブページのロードを完了するために、当該オブジェクトのための当該ローカルキャッシュにアクセスし、かつ
当該オブジェクトが、当該長い待ち時間リンクを介して、当該オブジェクトを要求する当該ブラウザなしでロードされる、装置。
【請求項１９】
当該パーサが、JavaScriptかStyle Sheetsが当該ウェブページにあるか否かを決定し、かつ、当該プリフェッチ機構が、当該ウェブページの当該ブラウザのロードと同時に、当該オブジェクトをフェッチする、請求項18の装置。
【請求項２０】
如何なる特定のオブジェクトの選択的プリフェッチも実行する当該プリフェッチ機構と関連する手段を備え、当該プリフェッチ機構が、発見的手法、規則および適応的行動のいずれを適用するか決定し、オブジェクトが、選択的にプリフェッチされる、請求項18の装置。
【請求項２１】
当該ウェブページが、さまざまなフローについて集中された情報を適用する当該ゲートウェイによってエージェントに供給されるメタタグを備える装置であって、
当該装置が、どのオブジェクトが選択的プリフェッチされるかを決定するために当該メタタグを解釈する当該プリフェッチ機構と関連する手段を備える、請求項18の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューターネットワークのパフォーマンスの向上に関する。さらに詳しくは、本発明は、集合しかつフロー制御されたチャネルを介して、同時にオブジェクトをプリフェッチングすることによって長い待ち時間リンクのHTTPパフォーマンスを増加させることに関する。
【背景技術】
【０００２】
インターネットのウェブページには、多くの種類のURLとオブジェクトが埋め込まれている。インターネットのウェブページを表示する標準ブラウザは、それらのウェブサーバリポジトリから並列にオブジェクトを取り込むことができる。ブラウザの機能を利用して、並列にオブジェクトを取り込む方式は、多くのオブジェクトが埋め込まれたページを表示するのに要するブラウザの時間を低減する。しかしながら、特定のオブジェクトタイプ（例えば、Java（登録商標）ScriptおよびStyleSheets）をダウンロードするときに、並列性の程度は、下位互換性、TCPフロー制御の有効性、およびブラウザ実装のシンプルさにより制限される。現在よく知られたウェブブラウザは、常にJava（登録商標）ScriptをシーケンシャルにかつStyleSheetsを個別のフェーズでダウンロードする。
【０００３】
オブジェクトをシーケンシャルにフェッチすることは、エンドユーザーが、低バンド幅ネットワークにおけるURLと、ラジオアクセス網のような長い待ち時間と、体験することを低下させる。つまり、サーバは新しい要求が届くのを待っているが、クライアントは以前の対応するレスポンスが受け取られるまで、それらを送出させない。これが、使用中となっているリンクの原因となる。
【０００４】
ブラウザ上の汎用キャッシュは、同じウェブページを再訪するのにかかる時間を改善するために用いられる。しかしながら、この汎用キャッシュは、無線リンク上のウェブページへの最初の訪問には役立たない。また、このブラウザが、他のウェブサイトからの次の取り込みからのオブジェクトに対応するためにそのキャッシュの部分をクリアしていた場合、次の再訪は利益とならないかもしれない。このように、汎用キャッシュの使用は、パフォーマンスにおける一貫しかつ予測可能な改善を提供しない。
【０００５】
HTTP 1.1 Request Pipelining standard (RFC 2616)は、両端がそれをサポートしているときにそれが適切に使用される場合、並列化の程度を増加させることを許可する。しかしながら、最新のブラウザは、（例えば、上位互換、実現のシンプルさおよびフロー制御の有効性）などの多くの理由から、最適様式でそれを使用することは無い。このように、このスタンダードは、ブラウザ動作を変えないので、リンクを常時使用するように最適化することは出来ない。
【０００６】
バンド幅が低くかつ遅延が著しいネットワークにおいて、ブラウザ動作を変更させずに、シーケンシャルなアクセスのマイナスの影響を解決する方法と装置を提供することは、有利であろう。
【０００７】
【特許文献１】米国特許第6,529,516号
【特許文献２】米国特許第6,115,384号
【発明の開示】
【課題を解決するための手段】
【０００８】
本発明は、ブラウザ動作を変更させることなく、低帯域幅および大遅延ネットワークにおけるシーケンシャルなアクセスのマイナスの影響を解決する。これは、エージェントからゲートウェイサーバまで異なるダウンロード方式、すなわち、プリフェッチを課すことによって長遅延リンクの並列性の程度を増加させることにより達成される。並列性の程度が低いと言う問題は、ブラウザとエージェントとの間で局所化され、この場合HTTPトランザクションに対し、実質上、遅延および帯域幅の制限がない。従って、この問題は解決する。
【０００９】
一実施例の場合、本発明は、ブラウザのホストをつとめているプラットホームで利用できる必要なオブジェクトを準備する、対応するサーバソフトウェアと通信するソフトウェア（クライアント）を備える。長い待ち時間リンクの低利用率は、ブラウザが、ソースウェブサーバからオブジェクトを、シーケンシャルにまたは少なくとも最適ではない程度の並列化で、ダウンロードしようとする際に、発生する。これは、エンドユーザーが感じる主な遅延原因をもたらす。この待ち時間は、本発明のプリフェッチング機構を使用することにより、格段に減らすことができる。このように、本発明は、集合されかつフロー制御されたチャネルを介して、オブジェクトを並列にプリフェッチすることによって長い待ち時間リンクのHTTPのパフォーマンスを向上させる。エージェントおよびゲートウェイは、協働して、長遅延データリンクによりインターネットウェブサイトからより高速にHTTPコンテンツをフェッチするよう、ウェブブラウザをアシストする。ゲートウェイおよびエージェントは、常駐ブラウザがオブジェクトを必要とする前に、そのオブジェクトが、ホストプラットホームで利用可能かつ実行可能となるように、選択的な埋め込みオブジェクトの取り込みを調整する。
【００１０】
オブジェクトがブラウザに見かけ上瞬間的に利用可能となることは、長く待つことなく次のオブジェクトを要請する、オブジェクトの完全処理を可能にする。埋め込みオブジェクトがこのように瞬間的に得られない場合には、ブラウザは、長遅延リンクを横断するために、その要求および対応する応答を待つ。本発明は、ブラウザにヒストリーをキャッシュすることには限定されない。本発明は、ブラウザが特定のオブジェクトを要求する前に、高度な並列方法でゲートウェイサーバから選択的フェッチを積極的に実行する。本発明は、ウェブブラウザおよびエンドソースサーバーからはいかなるサポートも必要としない。また、これは、高度な並列性の基では、いかなるフロー制御の問題も生じない。このように、本発明は、特に、多くのJava（登録商標）ScriptおよびStyle Sheetsを使用するウェブサイトとの、クライアントサーバ実装のHTTPパフォーマンスを向上させる。
【発明を実施するための最良の形態】
【００１１】
定義
HTTP：Hyper Text Transfer Protocol - インターネット上でウェブページ、文書などを転送するTCP/IPベースのプロトコル。
【００１２】
HTML：Hyper Text Markup Language。
【００１３】
API：Application Programming Interface。
【００１４】
VTP：A Transport Protocol。
【００１５】
XML：Extension Hyper Text Markup Language。
【００１６】
現在、TCPコネクションの数が増大するにつれて、減少するフロー制御効果によって、一般に利用されているHTTPブラウザは、ウェブサーバに限定された数の並列TCPコネクションを開く。これは、ページオブジェクトのダウンロードに対し並列化の程度を限定することになる。上記HTTP1.1 Pipelining standardは、それらの応答が受け取られる前に、同じTCPコネクションによる複数の要求からの送信を許容することによって、この課題を解決しようとする。しかしながら、下位互換性およびブラウザおよびサーバの限界のため、並列化の程度はしばしば低い。
【００１７】
加えて、いくつかの種類のオブジェクト（例えば、Java（登録商標）ScriptおよびCascading Style Sheets）は、実装の単純さにより、しばしば、ブラウザによってシーケンシャルにダウンロードされる。これは、さらに並列化の程度を、従って、応答を待つことに費やされる時間により、長い待ち時間リンクの使用を、減少させる。
【００１８】
本発明の好ましい実施例は、エージェントおよびゲートウェイシステムを備える。このシステムは、独立したフロー制御機構（VTP）を使用することにより、ブラウザホストプラットホームおよびソースウェブ（またはプロキシ）サーバとの間に仮想的に開かれるTCPコネクションの数にかかわらない。この結果、このシステムは、並列にオブジェクトをダウンロードするのに有用である。クライアント側のキャッシュを使用することにより、ウェブオブジェクトは、エンドブラウザおよびソースウェブサーバの実施から独立して、エージェントがそれらを認識するとすぐに、並列にダウンロードさせることができる。
【００１９】
図1は、本発明による長い待ち時間リンクのHTTPのパフォーマンスを増加させるための方法と装置を実施するシステムアーキテクチャのブロック略線図である。
【００２０】
好ましいシステムの場合、主に4つのエンティティ：典型的にはホストプラットホーム10の内部にあるブラウザ11；プリフェッチ機能17およびウェブオブジェクトキャッシュ13を有するエージェントを備えるクライアント12；フロー制御されたチャネル19を有する長い待ち時間リンクを介して当該クライアント12と通信するサーバ14；そして、当該サーバ14と通信するオリジナルウェブサーバ16、がある。従来技術においては、ブラウザ要求は、シグナルメッセージに変換され、トランスポートプロトコル（VTP）でフロー制御され、そしてサーバに送られる。サーバは、元の通常HTTPへの要求をオリジナルウェブサーバへの要求に変換し、かつ、その応答がサーバに戻される。次いで、それには、公知技術である損失性か非損失性技術の何れかを使用して圧縮され、そしてクライアントへ再びVTPによって転送される、処理が行われる。このクライアントは、ブラウザへ圧縮メッセージを提供する。好ましい実施例は、後述する、UDPベースの、VTPフロー制御およびトランスポートプロトコルを使用する（USPN 6,529,516およびUSPN 6,115,384も参照。これらの文献は、参照文献として全部が本願明細書に取り込まれているものとする）。
【００２１】
並列性の程度が低く、かつ、要求数が少ない場合、多くのブラウザは、Java（登録商標）（登録商標）ScriptおよびStyle Sheetsを、並列よりもシーケンシャルに分岐させるという事実を、本発明は、認識する。従って、本発明は、全体のパフォーマンスを劇的に向上させて、明確にこの種のオブジェクトをプリフェッチした。
【００２２】
例えば、ウェブページは、いくつかのJava（登録商標）（登録商標）ScriptとStyle Sheetsおよび多くのGIFを有する場合がる。これらは、ウェブページの構成要素の一部であり、かつウェブページを描画するために用いられる。ウェブページは、付加的に、HTML、JPEGおよびFLASH、な否から構成される場合もある。
【００２３】
本発明者らは、システムを減速させる大きな要因として2つのオブジェクト（すなわちJava（登録商標）ScriptおよびStyle Sheets）を特定した。但し、本発明は、これらのオブジェクトのみのプリフェッチングに限定されない。ブラウザは、すぐにいくつかの並列フェッチングを実行する場合があるが、Java（登録商標）ScriptおよびStyle Sheetsは、通常はフェッチされず、フェッチされているオブジェクトタイプを識別するいかなる試みもなされていない。これらの特定のオブジェクト（例えば、この種のオブジェクト）を選択的プリフェッチすることによって、システムのパフォーマンスは、劇的に高められる。このように、好ましい実施例は、好ましい本実施例では、Java（登録商標）ScriptおよびStyle Sheetのプリフェッチングを備える、クライアント側での選択的プリフェッチングを実施する。
【００２４】
本発明は、好ましくはプリフェッチ17およびキャッシュ18のコンポーネントを備え、後者はシステムのクライアント部分に導入される。プリフェッチするために、システムは、プリフェッチされたオブジェクト（詳細は、後述する）状態を保つために、パーサ、プリフェッチハンドラおよび記憶装置も含む。
【００２５】
動作に際して、ブラウザは、オブジェクトを要求する。オブジェクトは、サーバによりクライアントへ送り返される。オブジェクトが、ウェブページの記述（例えば、HTML）である場合、クライアントは、エージェントに対しオブジェクトを解析し、かつ、ウェブページがオブジェクトの特定のコンポーネントを有することを決定する。好ましい実施例の場合、パーサは、Java（登録商標）ScriptかStyle Sheetsが、例えば、ウェブページの中に、存在すか否かを判定する。もし、存在する場合には、それらのオブジェクトがユーザのブラウザによって要求されるのを待たずに、それらのオブジェクトは、エージェントによってウェブサーバから取得される。従って、ウェブページがユーザに戻るときに、ウェブページはブラウザに戻り、かつ同時にJava（登録商標）Scriptがフェッチされる間、ページは停止しない。
【００２６】
ウェブページは、記述オブジェクトである。それは、コンポーネントオブジェクトを特定する。メインページは、常に、最初に戻るオブジェクトで、かつそれは、ページを描画するのに必要とされるものを記述する。ほとんどの場合、ブラウザは、Java（登録商標）ScriptおよびStyle Sheetのオブジェクトを一つずつフェッチする。この種のオブジェクトがフェッチされるたびに、ユーザは時間遅延を待たなければならない。本発明者等は、ブラウザが、他のタイプのオブジェクト（例えば、GIF、JPEGまたはFLASH）に対して同じことをしないことに気がついた。典型的ブラウザは、少なくともある程度、並列に、他のタイプのオブジェクトをフェッチし、かつともかく一つずつ特定のタイプのオブジェクトをフェッチするだけである。
【００２７】
ブラウザは、ページ記述を解析し、かつページ記述がブラウザによって作用される間、分析要素は、Java（登録商標）ScriptおよびStyle Sheetsを特定するためにページ記述も解析する。これらの特定のオブジェクトは、通常、シーケンシャルにフェッチされるタイプである。プリフェッチ機構は、ブラウザと同時に使用され、ブラウザがページをロードする間に、これらのオブジェクトをフェッチするためにオリジナルウェブサーバへ行く。システムは、これらのオブジェクトをフェッチし、かつそれらをキャッシュに引き込むので、これらのオブジェクトは今やキャッシュに存在している。この結果、その付随する待ち時間を有するシステム全体に行く必要は無く、これらのオブジェクトを得てシーケンシャルにウェブページのビルディングを完了するためには、局所的にクライアントに必要なアクセスをするだけで、ウェブページのロードが完了する。これは、著しくシステムをスピードアップする。従って、本発明は、並列性および選択的プリフェッチングを使用することにより、ラウンドトリップが減少したインプレッションを与える。
【００２８】
機能仕様
問題定義
現在のクライアントアーキテクチャの場合、ブラウザによって要求されると、HTMLページが、フェッチされる。ある状況では、ブラウザは、シーケンシャルにページ（例えば、Java（登録商標）Script）を要求する。シーケンシャル要求は、並列性がないと、VTPを最大化できない。VTPを最大にするためには、クライアントでのプリフェッチが、必要となる。
【００２９】
仮定
本発明の実施態様では、ブラウザが、あるファイル（例えば、Java（登録商標）Script）に対し、HTML要求をシーケンシャルに実行すると仮定する。
【００３０】
要件
本発明は、以下の要件を備えたクライアントプリフェッチ機能を実施する：
・XMLによる構成可能な特性：
・ブラウザ要求に基づくHTMLページの優先順位
・異なるランニングセッションにわたる非持続性
・HTMLファイルプリフェッチを実行する
機能性
以下の機能コンポーネントが、必要とされる：ポストHTML処理、クライアント側プリフェッチ制御およびファイルキャッシュ。
【００３１】
それらのファイル拡張子に関係なく、ポストHTML処理モジュールは、プリフェッチにURLのリストを検索するためにHTMLページを解析する。このURLのリストは、クライアントプリフェッチ制御モジュールに供給される。
【００３２】
クライアント側プリフェッチ制御モジュールは、特定されたオブジェクトのためのHTTP要求を実行する。
【００３３】
ファイルキャッシュは、ローカルに永続性記憶装置のプリフェッチファイルをキャッシュシング処理する。
【００３４】
使用性
本発明は、エンドユーザーが、ファイルフェッチを使用可能または使用不可にすることができる条件で実施されることが好ましい。この特徴のために、GUIは、この特徴を使用可能にするかまたは使用不可にするためのオプションを提示する。使用不可にすると、ローカルにキャッシュされたファイルと内部プリフェッチ記録は、消去される。
【００３５】
設計仕様
この考察は、ポストHTML処理、クライアントプリフェッチ制御およびファイルキャッシュモジュールに対する設計の詳細を提供する。
【００３６】
概観
図2は、モジュールインタラクションの概観を示すブロック略線図である。図2において、ブラウザ11は、OSソケット層20を介してプロトコルモジュール25”と相互作用する。OSソケット層は、アプリケーション層21と相互作用し、次に、コンプレッサ層23およびトランスポート機構22と相互作用する。HTTP処理モジュール24は、本発明の動作のキーであり、かつアプリケーション層およびコンプレッサ層に加えて、ポストHTML処理モジュール27およびクライアントプリフェッチ制御モジュール26（それ自体はファイルキャッシュ制御18と相互作用する。）と相互作用する。
【００３７】
モジュール設計
以下の考察は、サブシステム（すなわち、ポストHTML処理、クライアントプリフェッチ制御およびファイルキャッシュ）の各々に対するモジュール設計について記載する。以下に記載した図3-5の各々において、動作フローは数字およびアスタリスク（例えば、”1*.”）によって示される。
【００３８】
図3は、ローカルキャッシュを介した接続フローを示す流れ図である。ユーザがウェブページ1*を見るためにブラウザにアクセスするとき、OSソケット層/VLSPは、次にアプリケーション層2*と通信する。ポストHTML処理モジュールは、アクセス3*され、そして、アプリケーション層4*に出力を戻す。アプリケーションは、次いで、トランスポートモジュール5*にアクセスし、ウェブページおよびファイルキャッシュモジュール6*をフェッチし、OSソケット層/VLSP 7*にウェブページを戻す。
【００３９】
図4は、ローカルキャッシュから接続フローを示す流れ図である。プロトコルモジュールは、作動中のとき、OSソケット層/VLSP 1*にアクセスする。これは、次にアプリケーション層2*にアクセスする。アプリケーション層は、ポストHTML処理モジュール3*、4*と相互に作用し、そして、アプリケーション層は、トランスポートモジュール5*を使用し、その後、OSソケット層/VLSP 6*にキャッシュ内容を送る。
【００４０】
図5は、プリフェッチポストHTML処理接続を示すブロック略線図である。ここで、サーバは、OSソケット層、VLSP 1*にアクセスする。これは、次に、アプリケーション層2*と、次いで、HTTP処理モジュール3*と通信する。フローは、ポストHTML処理モジュール4*へ進み、クライアントプリフェッチ制御モジュール5*と相互作用する。クライアントプリフェッチ制御モジュールは、次に、プロトコルモジュール7*と通信するトランスポートモジュール6*と相互作用する。プロトコルモジュールは、OSソケット層/VLSP 8*に、要求された結果を返送する。
【００４１】
ポストHTML処理モジュール設計
ポストHTML処理モジュールは、プリフェッチにURLのリストを作成する。各URLは、クライアントプリフェッチ制御モジュールに供給される。
【００４２】
クライアントプリフェッチ制御モジュール設計
クライアントプリフェッチ制御モジュールは、ページをフェッチするか否かを決定する判定ロジックを含む。プリフェッチURLは、インデックスにリンクされたリスト構造に格納される。一旦、URLがプリフェッチされることが決定されると、ローカルキャッシュモジュールへのバイパスコネクションが確立する。キャッシュアドレスおよびポート番号は、ローカルキャッシュモジュールを問い合わせることによって決定される。コネクションが確立され、かつ、それがローカルキャッシュからデータを受信すると、コネクションは直ちに閉ざされる。従って、接続が閉ざされるときでも、ローカルキャッシュは、ダウンロードを続けるように構成されなければならない。
【００４３】
VTP（UDP）トランスポート設計
動作の概観
以下の考察は、本発明の好ましい実施例の実行と関連して使用することができるタイプのUDPベースのVTPプロトコルの設計を記載する。
【００４４】
このプロトコルは、TCPと同様に信頼性が高いデータの配信をシーケンシャルに提供する。しかしながら、それは、高いバンド幅のバリエーションとパケット損失レートを有する環境に適するいろいろなレート制御機構を使用する。加えて、このプロトコルは、さらに、2つのホスト間に単一のフロー制御されたチャネルにより、いくつかのトランスポートフローを同時伝送することもサポートする。このプロトコルの主要な目的の1つは、TCPが取り扱えないそれらの領域において、より良く実行することである：高いバンド幅、高遅延および／または激しいパケットドロップ。無線TCPのいくつかの欠点は、その小さい最初の送信ウィンドウ、大きい最大送信ウィンドサイズおよび非常にアグレッシブな輻輳制御機構を含む。
【００４５】
このプロトコルは、TCPによって提供されるような信頼性が高いデータの配信を提供する。しかしながら、これは、高いバンド幅のバリエーションとパケット損失レートを有する環境に、より適した様々なレート制御機構を使用する。加えて、このプロトコルは、さらに2つのホスト間に単一チャネルにより複数のアプリケーションデータフローを同時に伝送することもサポートする。それらの間に極めて多くのTCPコネクションを使用するときに経験されるフロー制御効率が減少するという副作用無しに、これは、2つのホスト間のアプリケーション通話数が非常に増加することを可能にする。
【００４６】
コネンションの確立
UDPは、コネクションレス型（データグラム指向のプロトコル）である。VTPにおいては、論理コネクションは、以下の一つ以上の理由から、クライアントとサーバとの間に確立されなければならない：
・順序付けられた配信を保証するシーケンス番号を交換する;
・サーバー側でクライアント接続を認証する;
・各エン否からスタートアップパラメータを得る。
【００４７】
フローが如何なるアプリケーション層にセットアップされる前に、2つのホスト間のVTPコネクションはセットアップされる。一旦VTPコネクションが確立されると、2つのVTP接続されたホスト間の個々のアプリケーション通話は、スリーウェイハンドシェイクを必要としない。機構を切り換えているVTP端点によって、TCPフローが長いセットアップ遅延なしでVTPトンネルに切り換えられること可能となる。
【００４８】
VTPコネクションのセットアップは、個々のアプリケーションフロー（TCPフロー）から制御パケットおよびデータパケットの配信を保証するために、認証およびシーケンス番号交換を含む。
【００４９】
過去にサーバとコネクションが無かった場合、新しいコネクションが開かれる。コネクションのオープン要求は、REQ_CONN（要求コネクション）パケットをサーバに送信することによって、クライアントから開始される。コネクション要求識別子は、REQ_CONNおよびREQ_ACKパケットに適合させるために、すべてのREQ_CONNパケットに送信される。このパケットを送信した後、クライアントはタイマーを起動する。REQ_CONNタイマーが起動すると、異なるコネクション要求識別子を有する他のREQ_CONNパケットを送信する。いくつかのREQ_CONNパケット数n（変更可能なパラメータ）を送信した後、他の側から何の応答も受信されない場合、クライアントは断念し、かつ呼び出し側に「コネクションを確立することはできない」と報告する。クライアントがREQ_CONNパケットを送信した後、それは、そのコネクションの状態を閉じる（VTP_CLOSED）から「進行中のコネクション」（VTP_REQ_CONN）状態に変える。
【００５０】
サーバは、ソケットを開き、かつクライアント接続要求を聞くために、いくつかの良く知られているポートに結合される。サーバがREQ_CONNパケットを受けとるときはいつでも、これは、新しいリアルコネクションノードを割り当て、かつREQ_CONN+ACKパケットを送信することによって、REQ_CONNパケットに応答する。この時点で、サーバは、このコネクションを「確立されたコネクション」（VTP_EST）状態に、移行する。一旦クライアントがREQ_CONN+ACKパケットを受け取ると、それは「確立させたコネクション」状態にそのリアルコネクションノードを移行することができる。
【００５１】
クライアントは、ACKパケットを有するサーバのREQ_CONN+ACKパケットに応答する。クライアントは、REQ_CONNおよびREQ_CONN+ACKパケットからサーバに対してそのラウンドトリップ時間を演繹することができ、そして、サーバは、クライアントからREQ_CONN+ACKおよびACKパケットからそれ自体およびこのクライアントとの間にラウンドトリップ時間を演繹することができることに注意を要する。各エンドは、ネットワークを識別する必要性があるたびに、RTT推定値を受けとる。
【００５２】
リアルコネクションが正常に開かれる場合、データは、ta_send()を呼び出すことによって、バーチャルコネクション上に送信させることができる。
【００５３】
データフローおよび明確なレートフロー制御
如何なるトランスポート層の目的のうちの1つは、能率的にデータを送信し、およびネットワークから可能な限りの最大スループットを受けとることである。一旦コネクションが確立されると、センダとレシーバ間の中間ルータのいずれか作動しなくなるかもしれず、または、経路で一つ以上のリンクを使用すると、もう少し新しいコネクションが確立されるかもしれない。センダは、ネットワークの輻輳の要因となるいかなるデータも決して送信しない。センダがレシーバからのフィードバックを受けとらずに送信することができるデータ量は、「ウインドウを送信する」と呼ばれ、そして、次のように算出される：
Send_Window =（const1 *バンド幅*遅延時間）+（const2 * N）
ここで：
バンド幅は、ボトルネックリンクバンド幅（以下説明される）である
遅延は、センダおよびレシーバ間のラウンドトリップ時間である
const1は、正確なバンド幅と遅延評価の整定数である
const2は、廃棄されたACKパケットの割合を占める整定数である
Nは、ACKを送信する前に受信される最大バイトである。
【００５４】
コネクションのスループットは、ネットワークが運ぶことができるデータ量およびバッファスペースの量によって限定され、かつレシーバは、データがアプリケーション層を通過する前に、それを格納しなければならない。本発明において、レシーバのバッファは、制約条件と考えられていない。何故ならば、ネットワークがボトルネックとなっているので、中間ルータと送信ホストのバッファを考慮して、センダはネットワークが受け入れることができる以上のデータを決して送信しない。例えば、1Mbpsのリンクを有するセンダおよびレシーバは、128kbpsのリンクによって相互接続される。スループットは、その時は128kbps（16KBytes/s）のリンクに制約される。例えば、センダが、送信するデータを2Mにした場合、それらは中間ルータで消滅する可能性があるので、それは、これらのデータの全てをすぐにバーストするべきではない。厳密に言えば、センダは、1秒間に16KBを超えるものを送信すべきではない。これによって、センダが、それ自身からレシーバまでの経路におけるボトルネックリンクのバンド幅について情報を有する場合、その間のパケットが消滅しないように送信レートを調整することができることは、明らかである。
【００５５】
上記段落の実例を続けるには、送信ウィンドウを30KBとしよう。すべてのデータが送信されるべきであるので、バイトの値が完全な送信ウィンドウは一度に送信させることができる。これは、次のルータでバーストパケットを生成し、かつこれらのパケットを保持するためのバッファスペースがない場合、結局それらは、ただ消滅することになる。これを回避するために、センダがバンド幅を知っているので、制御された方法でそのバイトを送信することができる。これは、トランスポートのフロー制御面である。このコネクションが利用できるバンド幅が同じ状態を維持する間は、パケットが消滅する可能性は少ない。送信ウィンドウはネットワークの輻輳を回避する必要があり、かつ、フロー制御はバーストを回避する必要がある。
【００５６】
一旦センダがウィンドウのバイト値を送信すると、それはそのウィンドウを閉じ、かつ、レシーバからのフィードバックを待つべきである。理想的には、センダが送信するデータを有する場合、すべてのデータが他端に到達するまで、決して送信を止めるべきではない。すなわち、センダは、その送信ウィンドウを決して閉じるべきではない。センダが送信したデータの、いくらかまたは全て受けとったレシーバ報告からフィードバックを受けとるとき、センダは再びその送信ウィンドウを開くべきである。センダは、レシーバが受け取ったことを明確に応答するまで、その送信ウィンドウのデータを解放すべきではないことに注意すべきである。常に送信ウィンドウをオープンな状態に保ち、かつより多くのデータのための空間を有するために、レシーバは、必要に応じて、頻繁にフィードバックを送信するべきである。
【００５７】
バンド幅の情報およびトランスポートが効率的に機能するためのトリップタイムは、明確である。以下のセクションでは、VTPがボトルネックバンド幅およびトリップタイムを受けとる方法を記載する。
【００５８】
ラウンドトリップ時間
ラウンドトリップ時間（RTT）は、パケットが他端に着いて、かつ戻って来るまでの時間である。この時間は、センダでの待ち行列および伝送遅延、中間ルータでの待ち行列および処理遅延、そして、最終ホストでの処理遅延を含む。トリップタイム（TT）は、パケットがセンダからレシーバまでかかる時間である。VTPは、RTTを演繹するために、以下の方程式を使用する：
RTT =（最後のパケットの送信からACKを受信するまでの時間）―（レシーバでの  
遅延）―（sizeof（pkt.）/バンド幅）
センダがSACKに応答して一つ以上のパケットを解放する（すなわち、明らかにACKされる）場合のみ、RTTは測定される。方程式の第2項がデータパケットを必要とするので、SACKがレシーバが何も受信しなかったとの報告を受けたときは、それは測定されない。
【００５９】
以下の例は、RTT計算を示す：
レシーバ                      センダ
1 2を送信する< ― 時間t1
3 4を送信する< ― 時間t2
5 6を送信する< ― 時間t3
t4→  1
t5→  3
t6→  6
t7−> SACKは、1,3,6を受けたことをレシーバに報告する。
SACK到着<--時間t8
RTT@sender =（t8 − t3）−（t7 − t6）−（sizeof（pkt. 6）/バンド幅）。
【００６０】
RTTは、送信ウィンドウを計算する際に使用され、さらに、再送信のタイムアウト（後で説明される）を判断する際にも使用される。コネクション（リアル）を開始したクライアントトランスポートは、REQ_CONNおよびREQ_CONN+ACKパケットを有するコネクションセットアップで、RTTを受けとることができる。サーバはクライアントのACKパケットを受けとると、クライアントのRTTを演繹することができる。クライアントのACKパケットが消滅すると、サーバはレシーバからの最初のSACKから上記の方程式を使用してRTTを導出しなければならない。これは、センダが、送信された各パケットにタイムスタンプを付すことを必要とする。SACKパケットは、その最後のデータパケットからこのSACKまでの時間差を伝えるべきである。
【００６１】
タイムアウトによる送信ウィンドウの終了（WTO）
上述したように、アプリケーション層から受けとった最後のデータパケットを送信した後、または、それが十分なウインドウのバイト値を送信した後に、センダは、停止すべきである。アプリケーション層によって送信されるどのバイトも、シーケンシャルにかついかなるエラーもなく、レシーバに配信されることを保証することは、センダ次第である。レシーバは、受信したパケットおよび受信していないパケットに関するフィードバックを送信する。受信するパケットに関するフィードバックが消滅した場合、センダはレシーバで受信されたパケットについて知るいくつかの手段を有すべきである。送信中のパケットをレシーバが受けとっていることを保障するために、最後のパケットを送信した後に、それは、ある時間で切れるタイマーをスタートさせるべきである。このタイムアウトは、ラストパケットACKタイムアウト（LTO）と呼ばれている。センダがLTOタイム内で何のフィードバックも受けとらない場合、レシーバにフィードバックを送信させるために、（いつフィードバックを送信すべきかが、SACKにおいて明らかにされている場合）「リクエスティングサック」パケットを送信する。LTOタイマーは、あまり早く、または、あまり遅く期限切れにならないようにセットされるべきである。LTOタイマーは、2つの理由からあまり早く期限切れにならない：フィードバックが、センダへ向かっている途中であることもありえる;あまりに早いタイムアウトは、あまりにも多くの再送信の原因となる。もはやパイプはコネクションから何のパケットも伝えていないことから、あまり遅く期限切れになるべきではない。LTO方程式は、以下で与えられる：
LTO = K5 *（RTT + bytes_sent/バンド幅）
ここで：
K5−遅延を調整する整数定数
RTT−センダのRTT
bytes_sent−送信される合計バイト数
バンド幅−レート伝送。
【００６２】
センダが十分な送信ウィンドウのバイト値を送信する場合、それは、如何なる新しいパケットの送信も停止しなければならない。トランスポート層は、それが仮想接続キュー内に送信するより多くのデータを有するとき、このことが決して発生しないことを確認すべきである。送信ウィンドウが閉じられ、かつセンダがパケットを送信していないという事実は、センダがパイプを最大限使用していないことを意味している。受け取られたパケットに応答するSACKが、センダがその送信ウィンドウからACKされたバイトを開放することを可能にする。これにより、送信される新しいバイトに対し空間が提供される。
【００６３】
完全送信ウィンドウを送信した後にそれが停止しなければならないときはいつでも、センダは、「送信ウィンドウ終了タイマー」を開始する。送信ウィンドウ終了タイマー（WTO）は、以下のように与えられる：
WTO = 2^M * Const * RTT
ここで：
M−リトライの最大数
Const−整数定数
RTT−クライアントに対するセンダRTT。
【００６４】
WTOが期限切れになると、センダは、レシーバにSACKの送信を要求するSEND_SACKと呼ばれる新しいパケットを送信するべきである。センダは、設定された相当回数（M）、SEND_SACKパケットを送信しようと試みる。最後のSEND_SACKパケットの後、何のフィードバックも得られない場合、センダは、そのリアルコネクション上のすべての仮想接続を閉じ、バウンドキューからリアルコネクションのあらゆるパケットを処分し、そして、リアルコネクションを解放すべきである。
【００６５】
ネットワークが何のパケットも消滅させなければ、WTOタイマー上にタイムアウトは全く存在しないかもしれない。
【００６６】
バンド幅
経路のバンド幅は、センダからレシーバまで相当なバイト数を伝送するのにかかる時間である。この時間は、リンク（s）の間のデバイス伝搬時間に伝送時間を加えたものを含む。リンクは、2つのホストの間の、媒体、導線または無線である。VTPは、次々と、センダで時間差なしで、2つのパケットを送信することによって経路のバンド幅を測定する。それが通り抜けるリンクのバンド幅に応じて、両方とも、レシーバに多少の時間差で到着する。到達時刻は、レシーバが、recvfrom() system callを介してUDPソケットバッファからパケット（s）を得る時間である。なお、高速度リンク（例えば、4Mbps）であれば、二個以上のパケットが、時間差ゼロで到着する可能性がある。以下は、4KB/sのリンク上でそれぞれ1KBのサイズの二個のパケットを送信することによって、どれほどのバンド幅を得ることができるかについて示す。
【００６７】
c11はコネクション1からのパケット1であり、c12はコネクション1からのパケット2であり、そして、c21はコネクション2からのパケットである。
【００６８】
バンド幅=（c12 到達時刻 ― c11到達時刻）/c12パケット長
伝搬遅延を無視すると、1KBのパケットが4KB/sのリンクを通り抜けるのに、0.25秒かかる。
【００６９】
CASE1：
------------------
センダ  | c12 | c11 |  レシーバ  bw = (0.5 - 0.25)/1KB = 4 
------------------
CASE2：
------------------
センダ  | c21 | c12 | c11 |  レシーバ  bw = (0.5 - 0.25)/1KB = 4 
------------------
CASE3：
------------------
センダ  | c12 | c21 | c11 |  レシーバ  bw = (0.75 - 0.25)/1KB = 2 
------------------
CASE4：
-----------------------
センダ  | c12 | c22 | c21 | c11 |  レシーバ  bw = (1 - 0.25)/1KB = 1.33 
-----------------------
CASE1の場合、コネクション1は、リンクを使用する唯一のコネクションであるので、それは完全なバンド幅を得、そして、それはトランスポートが確かめるものである。CASES 2、3および4の場合、新しいコネクションc2は、同じリンクも使用している。このときに、理想的には、コネクション1の受信側トランスポートは、2KB/sのバンド幅を検出すべきである。しかし、上述したように、これはコネクション1でのパケットがどのような間隔を置いて配置されるかにによって、1.33KB/s〜4KB/sのどこにでも変動することができる。VTPは、絶えずバンド幅を平均することによって、2KB/s近くに到達する。受信側トランスポートは、SACKを介して現在の受信レートを通告すべきである。
【００７０】
シーケンシャルの2つのパケット間の時間差がゼロである場合、VTPは、デフォルト最大バンド幅としてそれを測定する。
【００７１】
選択的確認応答（SACK）
SACKは、レシーバからのフィードバックである。レシーバは、いくつかの理由からできるだけ頻繁に受信したデータについて、フィードバックを送信すべきである：
・送信ウィンドウをセンダ側で開いた状態に保つ
・失われ、かつ、受信されるパケットについてセンダに報告する
・レシーバの現在の受信レートをセンダに報告する。
【００７２】
SACKは、必要に応じて送信されるべきである。
【００７３】
処理確認応答
レシーバは、以下の場合に確認応答を送信する：
1. RTOが期限切れになるとき
2. シーケンスに16KBまたは32個パケットを受信するとき
3.いかなる保留ACKも、データパケットによってピギーバック方式で送信することが  出来る
4. 最初のシーケンス誤りパケット
5. バンド幅の実質的な変更。
【００７４】
最初の3つのACKは、失われた／受信されたデータパケットに関する情報を含む；例え、新しいデータパケットがレシーバによって受信されない場合であっても、最後の二個は送信させることができるであろう。情報を失った／受信したACKを受信すると、センダは、即座に、ACKされたVBufsを直ちに解放すべきである。着信ACKが明らかにout_queueのすべての到着を通知する場合（すなわち、sent-but-unacked），センダが送信する何かを持っているなら，パイプが明らかに空であるので，それは、「次の送信タイマー」をクリアし、かつ新しいデータを送るべきである。
【００７５】
（再）伝送ポリシー
それが現在の送信ウィンドウに適合すると、センダは、新しいパケットを送信することができる。そうでなければ、送信ウィンドウが次のSACKによって開かれるときに、センダは、パケットを仮想接続のアウトバウンドのキューに残し、かつそれらを送信すべきである。センダが新しいパケットを伝送するときはいつでも、LTO時間で期限切れになる新しいタイマーをスタートさせるべきである。LTO時間は、トリップ時間に加えて送信時間を含む。このタイマーが期限切れになるときに、センダはREQUEST_SACKパケットを送信して、タイマーを再開する。センダがN（可変な）数のREQUEST_SACKを送信後に，レシーバから何の応答も得ない場合、センダはレシーバとの接続を閉じなければならない。センダは、送信したパケットが現在のバンド幅および待ち時間に基づいてネットワークから抜け出したとみなすまで決して再送信すべきではない。再送信する要求が所要時間内に受信されると、センダは再送信要求を無視する。
【００７６】
センダは、バイトの値が完全送信ウィンドウを決して一度に送信すべきでない。十分なバッファが無い場合、これは、次のまたは中間ルータでのバーストパケットもたらすかもしれず、かつパケット落ちの原因となる可能性がある。これを回避するために、センダは、経路のバンド幅および遅延に従ってそれらを間隔を置いて配置して、パケットのフローを常に時間によって制御しなければならない。
【００７７】
コネクションの終結
アプリケーション層は、いつでも仮想接続を終了することができる。トランスポート層は、終了の種類（すなわち、異常終了または正常終了）を有するコネクション終了パケットを送信すべきである。アプリケーションがそのコネクションをアボートしている場合、トランスポート層は、仮想接続から他端に向かうあらゆるパケットを破棄し、かつTP_ABORT種類の新しいパケット（ほぼヘッダが十分な）を送信すべきである。そうでない場合には、すべてのパケットを送信し、そして次に、VCを閉じるべきである。後者の場合、VCを閉じたことを伝えるために、TP_CLOSEビットをVCの最後の発信パケットにセットする。一旦仮想接続が閉じられると、何のデータもそのコネクションに送信されないかまたは受信されない。受信側トランスポート層は、アプリケーション層に相手がコネクション閉鎖の要求があることを知らせる。リアルコネクションは決して閉じられないことに注意を要する。リアルコネクションは、コネクションの一端がなくなるときにだけ閉じられる。
【００７８】
チェックサム計算
トランスポートは、データが何のエラーもなく他端にも配信されることを保証すべきである。伝送のビット誤りを検出するために、チェックサムは、データグラムをレシーバに配信する前に、全パケットにわたって計算される。レシーバは、到着するパケットのチェックサムを再計算し、パケットのチェックサムを比較すすべきである。チェックサムが異なる場合、それを破損したパケットとみなして廃棄する。ヘッダのチェックサムフィールドは、チェックサムを計算する前にゼロとしなければならない。チェックサムを計算するために、すべてのデータを16ビット量に分割し、かつそれらの1の補数合計の1の補数を計算する。これは、インターネットのチェックサム計算と類似している。
【００７９】
認証
クライアントおよび／またはサーバの認証は、一旦リアルコネクションがトランスポート層で確立されるならば、しかし、いかなるデータも各エンド間で伝送される前に、認証モジュールによって確認することができる。ここで留意すべき点は、リアルコネクションが認証パラメータに応じて確立されていないかもしれないことである。例えば、サーバーがクライアントを認証することを欲求するが、クライアントが認証の使用禁止を有するか、またはクライアントが認証をサポートすることができない場合、リアルコネクションはトランスポートレベルで拒絶される。
【００８０】
安全性
安全性は、システムによって送信されるパケットに似ているパケットを送信しているいかなる悪意あるハッカーも回避するためにトランスポートに提供される。リアルコネクションを崩壊させることになる一つの方法は、順番に、クライアント／サーバによって送信される真正なパケットとシーケンシャルである、偽のパケットを送信することである。VTPの安全性の目的は、この種の仲間者攻撃に対して何の穴も残さないことである。これを回避するために、各エンドは、関係する同位エンティティだけによってデコードできる擬似乱数（PRSN）を送信する。
【００８１】
クライアントは、UIからトランスポートレベルで安全性を可能にすることができる。トランスポートが安全に構成されていない場合、データ伝送およびACKプロセスのシリアルシーケンス番号を使用する。
【００８２】
本発明が好ましい実施例に関して本願明細書において記載されているにもかかわらず、当業者は、ほかの応用が本発明の趣旨および範囲から逸脱することなく、本願明細書において記載されるそれらと置換することが出来ることを、容易に理解するであろう。例えば、プリフェッチ機構は、（現にシーケンシャルにロードされるものでない）いかなる選択されたオブジェクトの選択的プリフェッチも実行することができるであろう。どのオブジェクトが選択的プリフェッチされることになっているかについて決定するために、プリフェッチ機構には、さまざまな発見的手法、規則または適応的行動を応用することができるであろう。更に、ウェブページは、プリフェッチ機構によって解釈され、そして、どのオブジェクトが選択的にプリフェッチされることになっているかについて決定するメタタグを含むことができるであろう。
【００８３】
よって、本発明は、単に特許請求の範囲によって制限されなければならない。
【図面の簡単な説明】
【００８４】
【図１】本発明による長い待ち時間リンクのHTTPのパフォーマンスを増加させるための方法と装置を実施しているシステムアーキテクチャのブロック略線図である。
【図２】本発明によるモジュール相互の作用の概観を示すブロック略線図である。
【図３】本発明によるローカルキャッシュを介して接続フローを示すフローチャートである。
【図４】本発明によるローカルキャッシュから接続フローを示すフローチャートである。
【図５】本発明によるプリフェッチポストHTML接続処理を示すブロック略線図である。
【符号の説明】
【００８５】
10  ホストプラットホーム
11  ブラウザ
12  エージェントを備えるクライアント
13  ウェブオブジェクトキャッシュ
14  サーバ
16  オリジナルウェブサーバ
17  プリフェッチ機能
18  ファイルキャッシュ
19  フロー制御されたチャネルを有する長い待ち時間リンク
20  ＯＳソケット層
21  アプリケーション層
22  トランスポート機構
23  コンプレッサ層
24  ＨＴＴＰ処理モジュール
25  プロトコルモジュール
26  クライアントプリフェッチ制御モジュール
27  ポストHTML処理モジュール
【図１】
2008541239.tif 000003
【図２】
2008541239.tif 000004
【図３】
2008541239.tif 000005
【図４】
2008541239.tif 000006
【図５】
2008541239.tif 000007
【国際調査報告】
2008541239.tif 000008
2008541239.tif 000009