專利名稱：長延時鏈路上提高h(yuǎn)ttp性能的方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計(jì)算機(jī)網(wǎng)絡(luò)性能的改進(jìn)方法。更具體的，本發(fā)明涉及在長延時 (latency)鏈路上經(jīng)由聚合和流量控制的信道通過并發(fā)預(yù)取對象來提高HTTP的性能。
背景技術(shù)：
因特網(wǎng)網(wǎng)頁嵌入多種類型URL和對象。因特網(wǎng)網(wǎng)頁的標(biāo)準(zhǔn)瀏覽器可以從他們的 網(wǎng)頁服務(wù)器數(shù)據(jù)庫(r印ository)中并行取出一部分這些對象。利用瀏覽器性能并行取 出對象的方案減少了由瀏覽器顯示具有多個嵌入式對象的網(wǎng)頁的時間。然而，當(dāng)下載諸 如JavaScript和StyleSheet的特定類型對象時，由于向后兼容、TCP(傳輸控制協(xié)議)的 有效性以及瀏覽器實(shí)施的簡化使得并行度受限。現(xiàn)今所熟知的網(wǎng)頁瀏覽器通常順序下載 JavaScript以及在分階段下載StyleSheet。 對象的順序提取導(dǎo)致終端用戶經(jīng)歷這種URL(統(tǒng)一資源定位器)處于高延時以及 低帶寬網(wǎng)絡(luò)，諸如無線接入網(wǎng)下。簡而言之，服務(wù)器已經(jīng)準(zhǔn)備接收新的請求，但客戶端直到 相應(yīng)的響應(yīng)到達(dá)才發(fā)出這些請求。這將引起鏈路處于低利用狀態(tài)。 瀏覽器上的通用緩存用于改進(jìn)再次訪問相同網(wǎng)頁所花費(fèi)的時間。然而，通用緩存 無助于無線鏈路上第一次訪問網(wǎng)頁。同時，如果瀏覽器具有緩存清除部分用來容納從其它 網(wǎng)址依次取出的對象，則對后續(xù)的再次訪問沒有益處。因此，通用緩存的使用未提供一致并 可預(yù)測的改進(jìn)性能。 當(dāng)兩個終端都支持HTTP 1. 1請求流水線(Request Pipelining)標(biāo)準(zhǔn)(RFC2616) 時如果該標(biāo)準(zhǔn)正確使用將使得并發(fā)度提高。然而，現(xiàn)今瀏覽器由于諸如向后兼容、簡化執(zhí)行 以及流量控制的有效性等多種原因而未在最佳方式下使用。因此，該標(biāo)準(zhǔn)未改變?yōu)g覽器的 特性，從而不能總是優(yōu)化鏈路使用。 在低帶寬和高延時網(wǎng)絡(luò)而不改變?yōu)g覽器特性情況下，提供一種減輕順序訪問所帶 來的負(fù)面影響的方法和裝置是有利的。

發(fā)明內(nèi)容
本發(fā)明在低帶寬高延時網(wǎng)絡(luò)而在不改變?yōu)g覽器特性的情況下減輕了順序接入所 帶來的負(fù)面影響。這通過使用不同的下載策略，即，從代理到服務(wù)器網(wǎng)關(guān)預(yù)取，在長延時鏈 路上提高并行度來實(shí)現(xiàn)。低并行度問題局限在瀏覽器和代理之間，其中對于HTTP處理基本 上無延時以及帶寬限制。從而，該問題得到了緩解。 在一個實(shí)施方式中，本發(fā)明包含一套軟件(客戶端)，其與相應(yīng)的服務(wù)器軟件通 信，該服務(wù)器軟件準(zhǔn)備必要的對象從而在寄主瀏覽器的平臺上能夠獲得。當(dāng)瀏覽器從源 Web(環(huán)球網(wǎng))服務(wù)器順序下載對象時或在并發(fā)度小于最佳情況下，長延時鏈路利用率低。 這造成終端用戶經(jīng)歷的主要延時。通過使用本發(fā)明的預(yù)取裝置大大地減小了該延時。從而 本發(fā)明經(jīng)由聚合和流量控制信道通過并發(fā)預(yù)取對象提高長延時鏈路上HTTP的性能。代理 和網(wǎng)關(guān)共同協(xié)助Web瀏覽器通過長延時數(shù)據(jù)鏈路快速從因特網(wǎng)Web網(wǎng)址預(yù)取HTTP內(nèi)容。通
5過在駐留瀏覽器需要之前準(zhǔn)備好對象并在主機(jī)平臺上可以得到該對象的方式，該網(wǎng)關(guān)和代 理協(xié)作取出選擇的嵌入式對象。對于瀏覽器似乎瞬時得到對象使得完成對象處理不需要等 待就可以請求下一個對象。在不能瞬時獲得嵌入式對象情形下，瀏覽器需要等待請求以及 相應(yīng)的響應(yīng)來遍歷長延時鏈路。本發(fā)明不限于在瀏覽器上緩存歷史記錄。在瀏覽器請求特 定對象之前，瀏覽器在高并發(fā)方式下主動從網(wǎng)關(guān)服務(wù)器執(zhí)行有選擇性的預(yù)取。不需要Web 瀏覽器以及終端源服務(wù)器的任何支持。在高并行度情況下，沒有引入任何流量控制問題。從 而本發(fā)明改進(jìn)客戶端-服務(wù)器實(shí)施中HTTP性能，尤其是對于使用多個JavaScript和Style Sheet的Web網(wǎng)址。


圖1示出了根據(jù)本發(fā)明的在長延時鏈路上實(shí)施提高HTTP性能的方法和裝置的系 統(tǒng)結(jié)構(gòu)的方框圖； 圖2示出了根據(jù)本發(fā)明的模塊間交互概述的方框圖；
圖3示出了根據(jù)本發(fā)明的經(jīng)由本地緩存的連接流的流程圖；
圖4示出了根據(jù)本發(fā)明的來自本地緩存的連接流的流程圖；以及
圖5示出了根據(jù)本發(fā)明的預(yù)取后置HTML處理連接的方框圖。
具體實(shí)施方式

定義 HTTP :超文本傳輸協(xié)議_基于TCP/IP協(xié)議通過因特網(wǎng)傳輸網(wǎng)頁、文本等。 HTML:超文本標(biāo)記語言 API:應(yīng)用程序接口 VTP:傳輸協(xié)議 XML :可擴(kuò)展的超文本標(biāo)記語言 當(dāng)今，由于隨著TCP連接數(shù)量的增加減小了流量控制的影響，公開可獲得的HTTP
瀏覽器開放有限數(shù)量的并發(fā)TCP連接到Web服務(wù)器。這將限制用于頁面對象下載的并發(fā)度。
HTTP1. 1 Pipelining標(biāo)準(zhǔn)supra試圖通過相同的TCP連接在接收到響應(yīng)之前發(fā)送多個請求
解決此問題。然而，由于向后兼容以及瀏覽器和服務(wù)器限制，并發(fā)度通常較低。 另外，兒種類型對象，如JavaScript和Cascading Style Sheet (層疊樣式單)由
于簡化實(shí)施通常通過瀏覽器順序下載。因此進(jìn)一步地減小了并發(fā)度，并且其中由于在等待
響應(yīng)花費(fèi)的時間而使用長延時鏈路。 本發(fā)明的優(yōu)選實(shí)施方式包括代理和網(wǎng)關(guān)系統(tǒng)，由于使用獨(dú)立的流量控制機(jī)制 (VTP)，不考慮在瀏覽器主機(jī)平臺和源Web (或代理)服務(wù)器之間實(shí)質(zhì)上開放的TCP連接數(shù)， 從而對于并行下載對象來說是有用的。通過在客戶端使用緩存，可以在代理得知的時候并 行下載Web對象，獨(dú)立于終端瀏覽器和源Web服務(wù)器的操作。 圖1示出了根據(jù)本發(fā)明的在長延時鏈路上實(shí)施提高HTTP性能的方法和裝置的系 統(tǒng)結(jié)構(gòu)的方框圖。在優(yōu)選系統(tǒng)中有四個主要實(shí)體瀏覽器ll，通常位于主機(jī)平臺10內(nèi)；含 有具有預(yù)取功能代理17以及Web對象緩存13的客戶端12 ;服務(wù)器14，與所述客戶端經(jīng)由 具有流量可控信道19的長延時鏈路進(jìn)行通信；以及與所述服務(wù)器14通信的源Web服務(wù)器16。在現(xiàn)有技術(shù)中，瀏覽器請求在傳輸協(xié)議(VTP)下轉(zhuǎn)化為信號消息和流量控制，并路由到 服務(wù)器。服務(wù)器將請求轉(zhuǎn)化回原來的、規(guī)則的HTTP請求發(fā)送到源Web服務(wù)器，并向服務(wù)器 發(fā)回響應(yīng)。然后，使用本領(lǐng)域熟知的有損技術(shù)或無損技術(shù)對其進(jìn)行處理或壓縮。并再次通 過VTP傳送回客戶端?？蛻舳藢嚎s后的消息提供給瀏覽器。優(yōu)選實(shí)施方式使用基于UDP 的、VTP流量控制以及傳輸協(xié)議，將在下面進(jìn)行討論(也可參見USPN 6， 529， 516和USPN 6， 115， 384，在此引入全部內(nèi)容作為參考)。 在并行度較低并且請求數(shù)較低的情形下，本發(fā)明證實(shí)多個瀏覽器分支JavaScript 和Style Sheet是按順序的方式而不是并行的方式。從而，本發(fā)明顯示預(yù)取這種類型的對 象，具有顯著提高的整體性能。 例如，網(wǎng)頁可以具有幾個JavaScript和Style Sheet以及多個GIF。這些是網(wǎng)頁 的組成部分，并且他們用于描述網(wǎng)頁。網(wǎng)頁也包括其它的HTML、 JPEG以及FLASH等。
發(fā)明者已經(jīng)確定兩個對象，即，JavaScript和Style Sheet作為減緩系統(tǒng)的主要 因素，但本發(fā)明不限于只對這些對象的預(yù)取。瀏覽器可能已經(jīng)執(zhí)行某種并行取出，但通常沒 有取出JavaScript和Style Sheet,也未試圖區(qū)分要取出的對象的類型。通過有選擇地預(yù) 取某些對象，如這些類型的對象，系統(tǒng)的性能明顯提高。從而，優(yōu)選實(shí)施方式執(zhí)行客戶端選 擇性的預(yù)取，在現(xiàn)有的優(yōu)選實(shí)施方式，包括JavaScript和Style Sheet預(yù)取。
本發(fā)明優(yōu)選地包括預(yù)取17和緩存18組成部分，其中后者引入到系統(tǒng)的客戶端部 分。為了進(jìn)行預(yù)取，系統(tǒng)也包括解析器、預(yù)取處理器以及保持預(yù)取對象的存儲系統(tǒng)(將在下 面詳細(xì)討論)。 在運(yùn)行中，瀏覽器請求對象。該對象通過服務(wù)器發(fā)送回客戶端。如果對象是對網(wǎng) 頁的描述，例如HTML,客戶端為代理對其進(jìn)行解析并確定網(wǎng)頁所具有的某些組成部分。在優(yōu) 選實(shí)施方式中，解析器確定例如，在網(wǎng)頁中是否存在任何JavaScript或Style Sheet。如 果存在，通過代理在Web服務(wù)器中獲得這些對象，而不是等待用戶瀏覽器請求這些對象。從 而，當(dāng)網(wǎng)頁返回給用戶時，網(wǎng)頁返回到瀏覽器，在并發(fā)取出JavaScript時，頁面沒有暫停。
網(wǎng)頁是描述對象。它指定組件對象。主頁面總是返回的第一個對象，并且它描述 了描述頁面所需要的內(nèi)容。大多數(shù)情況下，瀏覽器一次取回JavaScript和Style Sheet對 象。每次取回所述對象，用戶必須等待時延。發(fā)明者已經(jīng)得出，瀏覽器不會對其它類型的對 象如GIF、 JPEG或FLASH做相同的事情。典型的瀏覽器并行取回其它類型的對象，至少在一 定程度上，并且有時每次只取回某些類型的對象。 瀏覽器解析頁面描述，并且同時瀏覽器對頁面描述操作，解析部件也解析此頁面 描述來確定JavaScript和Style Sheet。這些特定的對象通常為順序提取的類型。并發(fā)使 用預(yù)取裝置與瀏覽器轉(zhuǎn)到原始Web服務(wù)器，在瀏覽器仍然加載這些頁面的同時，取出這些 對象。系統(tǒng)取出這些對象并將他們交給緩存，從而這些對象駐留在緩存中。因此，不需要必 須通過具有伴隨延時的系統(tǒng)，來順序得到這些對象完成網(wǎng)頁的創(chuàng)建，只需要接入本地客戶 端完成網(wǎng)頁的加載。這使得系統(tǒng)速度相當(dāng)快。因此，本發(fā)明使用并行和選擇性的預(yù)取給出 減小的往返時間(round trip)。
功能規(guī)范
問題定義 在當(dāng)前客戶端結(jié)構(gòu)中，瀏覽器請求的時候取出HTML頁面。在某種情形下，瀏覽器順序請求頁面，如JavaScript。由于沒有并行，順序請求沒有最大化VTP。為了最大化VTP，
在客戶端需要預(yù)取。
假設(shè) 本發(fā)明的實(shí)施假定瀏覽器針對某些文件順序執(zhí)行HTML請求，諸如JavaScript。
需求 本發(fā)明按照以下需求執(zhí)行客戶預(yù)取特性 通過XML可配置的屬性 基于瀏覽器請求的HTML頁面優(yōu)先級 不同的運(yùn)行會話上的非持久性 執(zhí)行HTML文件預(yù)取 功能 需要以下功能部件后置HTML處理、客戶側(cè)預(yù)取控制以及文件緩存。 后置HTML處理模塊用于解析HTML頁面以檢索預(yù)取的URL表單，不考慮文件擴(kuò)展
名。將該URL表單加進(jìn)客戶預(yù)取控制模塊。 客戶端預(yù)取控制模塊執(zhí)行HTTP請求所識別的對象。 文件緩存處理本地持久存儲器上的緩存預(yù)取文件。 可用性 本發(fā)明優(yōu)選地實(shí)施為終端用戶提供能夠提取文件或不能提取文件。對于此特征， GUI呈現(xiàn)選項(xiàng)或者使此特征能用或不能用。在此特征失效的選項(xiàng)下，清除本地緩存的文件， 以及內(nèi)部預(yù)取記錄。
設(shè)計(jì)規(guī)范 本討論提供用于后置HTML處理、客戶預(yù)取控制以及文件緩存模塊的設(shè)計(jì)細(xì)節(jié)。
概述 圖2示出了模塊間交互概況的方框圖。在圖2中，瀏覽器11通過0S(操作系統(tǒng)) 套接字層20與文件緩存25交互，該OS套接字層與應(yīng)用層21交互，依次與壓縮層23和傳 輸裝置22交互。HTTP處理模塊24是本發(fā)明實(shí)施的關(guān)鍵，并且除了與應(yīng)用層和壓縮層交互 外，還與預(yù)取控制模塊27和客戶端預(yù)取控制模塊26交互，客戶端預(yù)取控制模塊26本身與 文件緩存控制模塊18交互。
模塊設(shè)計(jì) 以下討論描述用于每一個子系統(tǒng)的模塊設(shè)計(jì)，S卩，后置HTML處理、客戶端預(yù)取控
制以及文件緩存。以下對圖3-5的每個圖進(jìn)行討論，通過數(shù)字和星號，如"r"表示操作流程。 圖3示出了根據(jù)本發(fā)明的經(jīng)由本地緩存的連接流的流程圖；當(dāng)用戶接入瀏覽器瀏 覽網(wǎng)頁r時，OS套接字層/VLSP(虛擬局域網(wǎng)鏈路狀態(tài)協(xié)議)依次與應(yīng)用層2*通信。后置 HTML處理模塊接入3*并將輸出返回給應(yīng)用層4*。隨后應(yīng)用接入傳輸模塊5 提取網(wǎng)頁，以 及接入文件緩存模塊6*，將網(wǎng)頁返回到OS套接字層/VLSP 7*。 圖4示出了來自本地緩存的連接流的流程圖。當(dāng)激活協(xié)議模塊時，它接入OS套接 字層/VLSP 1*，順序接入應(yīng)用層2*。應(yīng)用層與后置HTML處理模塊交互3^4 然后應(yīng)用層使 用傳輸模塊5*，隨后將緩存內(nèi)容提供給0S套接字層/VLSP 6*。
圖5示出了根據(jù)本發(fā)明的預(yù)取后置HTML處理連接的方框圖。此時，服務(wù)器接入 OS套接字層T。 VLSP依次與應(yīng)用層通信2*，然后與HTTP處理模塊通信3*。當(dāng)流程進(jìn)行到 HTML處理模塊4*，該HTML處理模塊與客戶端塊通信3*。當(dāng)流程進(jìn)行到HTML處理模塊4*， 該HTML處理模塊與客戶端預(yù)取控制模塊交互5*?？蛻舳祟A(yù)取控制模塊與傳輸模塊交互6*， 該傳輸模塊順序與協(xié)議模塊通信7*。協(xié)議模塊將請求結(jié)果返回給OS套接字層/VLSP 8*。
后置HTML處理模塊設(shè)計(jì) 后置HTML處理模塊生成用于預(yù)取的URL表單。將每一個URL加到客戶端預(yù)取控 制模塊中。 客戶端預(yù)取控制模塊設(shè)計(jì) 客戶端預(yù)取控制模塊包括確定邏輯單元以確定是否以及何時取出網(wǎng)頁。預(yù)取URL 存儲在索引鏈接表單結(jié)構(gòu)中。 一旦確定應(yīng)該預(yù)取URL，建立到本地緩存模塊的旁路連接。緩 沖地址和端口數(shù)量通過查詢本地緩沖模塊而確定。當(dāng)連接建立起來，并且接收到來自本地 緩存的數(shù)據(jù)時，連接立即關(guān)閉。因此，必須配置本地緩存以在即使連接關(guān)閉的時候繼續(xù)下載。 VTP (UDP)傳輸設(shè)計(jì)
實(shí)施概述 以下討論將描述基于UDP (用戶數(shù)據(jù)報協(xié)議)的VTP協(xié)議類型的設(shè)計(jì)，該設(shè)計(jì)可在 本發(fā)明優(yōu)選實(shí)施方式實(shí)施中使用。 該防議提供如TCP具有的順序的、可靠的數(shù)據(jù)傳輸。然而，該協(xié)議使用不同的速率
控制機(jī)制能更好地適合于高寬帶變化以及高丟包率環(huán)境。另外，該協(xié)議也支持經(jīng)過兩個主
機(jī)之間的單個流量可控信道的多路傳輸流。該協(xié)議的主要目的之一在于在TCP沒有高寬
帶、高時延、和/或高丟包的區(qū)域，能夠更好的執(zhí)行。無線鏈路上的TCP的一些缺點(diǎn)包括較
小的初始發(fā)送窗口、較大的最大化發(fā)送窗口尺寸以及激進(jìn)的擁塞控制機(jī)制。 該協(xié)議與TCP —樣提供可靠的數(shù)據(jù)傳輸。然而，該協(xié)議使用不同的速率控制機(jī)制
能更好的適合高帶寬變化以及高丟包率環(huán)境。另外，該協(xié)議也支持經(jīng)過兩個主機(jī)之間的單
個流量可控信道的多路多應(yīng)用數(shù)據(jù)流。這在兩個主機(jī)之間使用大量TCP連接時使得大大增
加兩個主機(jī)之間應(yīng)用會話的數(shù)量，而不受減小的流量控制效率的負(fù)面影響。 連接建立 UDP是無連接的，面向數(shù)據(jù)報的協(xié)議。在VTP中，由于以下一個或多個原因必須在 客戶端和服務(wù)器之間建立邏輯連接。
改變確保順序傳送的序列號
鑒權(quán)在服務(wù)器端連接的客戶端
從每個終端得到所有的起始參數(shù) 在所有的應(yīng)用級流建立之前，建立兩個主機(jī)之間的VTP連接。 一旦VTP連接建立，
兩個已連接的VTP主機(jī)之間的單獨(dú)應(yīng)用會話不需要三相交握(threeiay hand-shaking)。
VTP終端重定向機(jī)制允許將TCP流不需要很長的建立時延而重定向到VTP信道。 VTP連接建立包括鑒權(quán)和順序號交換來保證來自單獨(dú)應(yīng)用流(TCP流)的控制包和
數(shù)據(jù)包的傳輸。 如果先前沒有與服務(wù)器的連接，則打開新的連接。通過向服務(wù)器發(fā)送RE(LC0NN(請求連接)包發(fā)起來自客戶端的連接打開請求。在每一個REQ_C0NN包中發(fā)送連接 請求標(biāo)識來匹配REQJX)NN和REQ—ACK包。在發(fā)送此數(shù)據(jù)包之后，客戶端應(yīng)該開始計(jì)時。如 果REQ_C0NN定時器超時，使發(fā)送具有不同的連接標(biāo)識的另一個REQ_C0NN包。在發(fā)送n個 (可配置的參數(shù))REQ_C0NN包后，如果沒有從其它端接收到響應(yīng)，則客戶端放棄并向呼叫方 報告"不能建立連接"。在客戶端發(fā)送REQJX)NN包后，將連接從關(guān)閉狀態(tài)(VTP_CL0SED)變 為"進(jìn)行連接"(VTP_REQ_C0NN)狀態(tài)。 服務(wù)器打開套接字并綁定到一些已知的用于監(jiān)聽客戶端連接請求的端口。無論什 么時候服務(wù)器得到REQ_C0NN，它應(yīng)該分配新的實(shí)際連接節(jié)點(diǎn)并通過發(fā)送REQ_C0NN+ACK包 來回復(fù)REQJX)NN包。在這種情況下，服務(wù)器將連接移到"連接已建立"(VTP—EST)狀態(tài)。一 旦客戶端收到REQ_C0NN+ACK包，將實(shí)際連接節(jié)點(diǎn)移到"連接已建立"狀態(tài)。
客戶確認(rèn)收到服務(wù)器的具有ACK包的REQ_C0NN+ACK包。注意到客戶端可以從REQ_ CONN和REQ_C0NN+ACK包推算到服務(wù)器的往返時間，同時服務(wù)器可以從來自客戶端的REQ_ CONN+ACK和ACK推算它本身和客戶端之間的往返時間。每一個終端應(yīng)該根據(jù)需要獲得RTT 估計(jì)來了解網(wǎng)絡(luò)。 如果實(shí)際連接成功地打開，則數(shù)據(jù)可以通過呼叫ta_Send()在虛擬連接上發(fā)送。
數(shù)據(jù)流和顯示速率流量控制 傳輸層的目的之一是有效地發(fā)送數(shù)據(jù)并從網(wǎng)絡(luò)得到最大可能的吞吐量。 一旦連接 建立，發(fā)送者和接收者之間的任何中間路由器可以傳送下去(go down)或者可以在路徑上 使用一個或多個鏈路建立更多的新連接。發(fā)送方應(yīng)該決不發(fā)送導(dǎo)致網(wǎng)絡(luò)擁塞的數(shù)據(jù)。發(fā)送 方發(fā)送的沒有得到接收方任何反饋的數(shù)據(jù)量稱作"發(fā)送窗口 "，計(jì)算為
Send_Window = (constl*帶寬*時延)+ (const2*N)
其中 帶寬是鏈路寬帶(將在下面解釋)的瓶頸(以下解釋) 時延為發(fā)送方和接收方的往返時間 constl為校正(correct)帶寬和時延估計(jì)的整數(shù)常數(shù) const2為計(jì)算丟棄的ACK包的整數(shù)常數(shù) N為在發(fā)送ACK之前接收到的最大字節(jié) 由于網(wǎng)絡(luò)能夠承載的數(shù)據(jù)量以及緩沖器的空間使得連接吞吐量受到限制，接收方 在將數(shù)據(jù)傳到應(yīng)用層之前必須存儲這些數(shù)據(jù)。在本發(fā)明中，不考慮接收緩沖器的約束。因 為現(xiàn)在網(wǎng)絡(luò)是瓶頸，考慮到中間路由器以及發(fā)送主機(jī)的緩沖器，發(fā)送方不應(yīng)發(fā)送超過網(wǎng)絡(luò) 所能接受的數(shù)據(jù)。例如，1Mbps鏈路的發(fā)送方和接收方由128kbps鏈路相互連接在一起。此 時的吞吐量受限于128kbps (16KBytes/s)鏈路。如果發(fā)送方有如2MB的數(shù)據(jù)要發(fā)送，不應(yīng) 將這些數(shù)據(jù)全部一齊發(fā)送，因?yàn)樗麄兛赡茉谥虚g路由器處會被丟棄。確切地說，發(fā)送方每秒 發(fā)送不應(yīng)該超過 16KB。這使得發(fā)送方能夠清楚了解到從其本身到發(fā)送方的路徑中的鏈路 瓶頸，能夠調(diào)節(jié)其發(fā)送速率，從而在二者之間不會有包丟棄。 繼續(xù)上面所述的例子，所述發(fā)送窗口為30KB。由于所有的數(shù)據(jù)在發(fā)送窗口發(fā)送，全 部發(fā)送窗口字節(jié)(complete send window worth of bytes)可以一次發(fā)送。這將在下一個 路由器處產(chǎn)生包突發(fā)，如果沒有緩沖空間來容納這些包，它們將被丟棄。為了避免這種情況 發(fā)生，由于發(fā)送方知道帶寬，它可以可控的方式來發(fā)送那些字節(jié)。這就是傳輸?shù)牧髁靠刂品揭驗(yàn)榈仁街械牡诙?xiàng)需要數(shù)據(jù)包c(diǎn)
案。只要該連接可獲得的帶寬保持不變，丟包機(jī)會就較小。發(fā)送窗口對于避免網(wǎng)絡(luò)擁塞是 必要的并且流量控制對于避免突發(fā)是必要的。 —旦發(fā)送方發(fā)送其窗口字節(jié)，窗口將關(guān)閉并等待接收方的反饋。理想情況下，如果 發(fā)送方有數(shù)據(jù)要發(fā)送，它將在所有的數(shù)據(jù)都到達(dá)另一端后才停止發(fā)送，即，發(fā)送方不應(yīng)該關(guān) 閉其發(fā)送窗口。當(dāng)發(fā)送方得到接收方表示從發(fā)送方所發(fā)送的數(shù)據(jù)已經(jīng)部分或全部接收到的 反饋時，則發(fā)送方應(yīng)該再打開其發(fā)送窗口 。注意到發(fā)送方直到收到來自接收方的正面確認(rèn)， 才釋放其發(fā)送窗口中的數(shù)據(jù)。為了保持發(fā)送方一直打開以及有容納更多數(shù)據(jù)的空間，接收 方應(yīng)該根據(jù)需要頻繁地發(fā)送反饋。 很明顯，了解傳輸?shù)膸捄托谐虝r間能夠有效進(jìn)行工作。以下部分描述VTP如何
獲得瓶頸帶寬以及行程時間。
往返時間 往返時間(RTT)為包到達(dá)另一終端并返回所用的時間。該時間包括發(fā)送方的排
隊(duì)、傳輸時延，中間路由器的排隊(duì)和處理時延以及在最終主機(jī)的處理時延。 行程時間(TT)為包從發(fā)送方到接收方的時間。VTP使用以下公式推算出RTT : RTT=(發(fā)送的最后一個包到接收到ACK的時間)-(接收方時延)-((pkt)尺寸/
帶寬) 只有當(dāng)發(fā)送方響應(yīng)SACK，S卩，正面ACK，釋放一個或多個包的時候才測量RTT。當(dāng) SACK表示接收方什么都沒有收到時，則不需要效
以下例子表示RTT的計(jì)算
接收方



t4—_> 1
t5—_> 3
t6—_> 6 t7—-〉SACK表示接收方得到1、3、6 SACK到達(dá)〈一時間t8 RTT@sender = (t8-t3) - (t7-t6) - ((pkt 6)的尺寸/帶寬) RTT用于計(jì)算發(fā)送窗口也可用于估算重傳時延(后面解釋)。發(fā)起連接(實(shí)際) 的客戶端傳輸能夠在與REQ_C0NN和REQ_C0NN+ACK的連接建立時得到RTT。如果服務(wù)器得 到客戶端的ACK包，則能夠推算出其到客戶端的RTT。如果客戶端的ACK包丟失，則服務(wù)器 必須使用以上的公式從來自接收方的第一個SACK得出RTT。這需要發(fā)送方為每一個發(fā)送的 包打上時間戳。SACK包應(yīng)該攜帶最后數(shù)據(jù)包到該SACK之間的時間間隔。
發(fā)送窗口關(guān)閉超時(WTO) 如前面所提到的，當(dāng)從應(yīng)用層得到最后的數(shù)據(jù)包發(fā)送之后或發(fā)送整個窗口的字節(jié) 后，發(fā)送方應(yīng)該停止發(fā)送。這取決于發(fā)送方要確保每次以及每一個由應(yīng)用層發(fā)送的字節(jié)都 能順序地且無任何差錯地發(fā)送到接收方。接收方發(fā)送關(guān)于接收到的包以及沒有接收到的包 的反饋。如果反饋是關(guān)于接收的包丟失，則發(fā)送方應(yīng)該以某種方式得知在接收方接收到的包。為了確保接收方得到正在發(fā)送的包，當(dāng)發(fā)送完最后的包之后，應(yīng)該開啟在一定時間就超 時的定時器。該超時稱為最后包ACK超時(LT0)。如果發(fā)送方在LTO時間內(nèi)沒有得到任何 反饋，則將發(fā)送"請求sack"包使得接收方發(fā)送反饋(何時發(fā)送反饋在SACK中說明)。LT0 定時器不能設(shè)置太早或太晚超時。不應(yīng)設(shè)為太早超時有兩個原因反饋可能已經(jīng)在到發(fā)送 方的途中；太早超時引起多次重傳。也不應(yīng)設(shè)置為太晚超時原因在于管道不再承載來自本 連接的任何包。以下給出LT0公式
LT0 = K5* (RTT+bytes_sent/帶寬)
其中 K5-調(diào)整時延的整數(shù)常量
RTT-發(fā)送方的RTT
bytes—sent-發(fā)送的總字節(jié)數(shù)
帶寬-傳輸速率 當(dāng)發(fā)送方已經(jīng)發(fā)送全部發(fā)送窗口的字節(jié)，必須停止發(fā)送任何新包。當(dāng)虛擬連接隊(duì)
列中有更多的數(shù)據(jù)要發(fā)送時傳輸層應(yīng)該確保不會發(fā)生這種情況。發(fā)送窗口關(guān)閉，并且發(fā)送
方不發(fā)送任何包的事實(shí)表明發(fā)送方?jīng)]有最大程度使用管道(pipe)。 SACK確認(rèn)接收到的包
能夠使發(fā)送方從其發(fā)送窗口釋放ACK字節(jié)，從而為要發(fā)送的新字節(jié)提供空間。 發(fā)送方開啟"發(fā)送窗口關(guān)閉定時器"，只要整個發(fā)送窗口發(fā)送后應(yīng)該停止計(jì)時。如
下給出發(fā)送窗口關(guān)閉定時器(WT0):WTO = 2~M*Const*RTT 其中 M-重試的最大數(shù) Const-整數(shù)常量 RTT-發(fā)送方到客戶端的RTT 當(dāng)WTO超時時，發(fā)送方發(fā)送稱為SEND_SACK的新包來請求接收方發(fā)送它的SACK。 發(fā)送方盡可能在配置好的特定次數(shù)(M)之前發(fā)送這些SEND—SACK包。如果在最后的SEND_ SACK包發(fā)送后沒有收到任何反饋，則發(fā)送方將關(guān)閉實(shí)際連接上的所有虛連接，丟棄實(shí)際連 接中隊(duì)列之外的所有包，并釋放該實(shí)際連接。 如果網(wǎng)絡(luò)沒有丟棄任何包，則在WTO定時器上可能從來不會有超時發(fā)生。
帶寬 路徑的帶寬為從發(fā)送方向接收方傳輸一定量字節(jié)所需的時間。該時間包括設(shè)備傳 輸時間加上發(fā)送方和接收方之間鏈路傳播時間。鏈路是媒介，有線或無線，位于兩個主機(jī)之 間。VTP通過在發(fā)送方?jīng)]有時間間隔情形下發(fā)送兩個包，一個接一個，來測量路徑帶寬。根 據(jù)遍歷的路徑的帶寬，它們在一定時間間隔下到達(dá)接收方。到達(dá)時間為經(jīng)由recvfrom()系 統(tǒng)呼叫，接收方獲得UDP套接字緩沖區(qū)中的包的時間。注意到在高速鏈路下，如4Mbps，兩 個或多個包可以在零時間間隔到達(dá)。以下示出如何在4KB/s的鏈路上，通過發(fā)送大小都為 1KB的兩個包來得到帶寬。 cll為來自連接1的包1， c12為來自連接1的包2 ;以及
c21為來自連接2的包。 帶寬=(cl2到達(dá)時間-cll到達(dá)時間)/cl2包大小
忽略傳播時延，1KB的包在0. 25秒遍歷4KB/s鏈路。 例1 : ------------------ 發(fā)送方|cl2|cll| 接收方 bw = (0. 5-0. 25)/1KB = 4 ------------------ 例2 : ------------------ 發(fā)送方|c21 |cl2|cll I接收方 bw = (0. 5-0. 25)/lKB = 4 ------------------ 例3 : ------------------ 發(fā)送方|cl2|c21 |cll I接收方 bw = (0. 75-0. 25)/lKB = 2 ------------------ 例4: ----------------------- 發(fā)送方|cl2|c22|c21 |cll I接收方 bw = (1-0. 25)/1KB = 1. 33
----------------------- 在例1中，連接1為使用鏈路的唯一連接，因此可以得到全部帶寬，即傳輸可以看 到的。在例2、3和4中，新連接c2也使用相同的鏈路。此時，理想情況下，用于連接l的接 收傳輸應(yīng)該檢測2KB/s帶寬。但是如上面所示，這將在1. 33KB/s到4KB/s之間任何位置波 動，取決于連接1的包如何得到空間。通過不斷地平均帶寬，VTP接近2KB/s。接收傳輸應(yīng) 該通過SACK接近其當(dāng)前接收速率。 如果順序中兩個包的時間間隔為零，VTP測量作為缺省的最大的帶寬。
選擇性的確認(rèn)(SACK) SACK為來自接收方的反饋。接收方應(yīng)該與接收同樣頻繁的周期發(fā)送數(shù)據(jù)相關(guān)的反 饋，原因如下 以在發(fā)送端保持發(fā)送窗口打開
以讓發(fā)送方得知丟棄的和接收到的包
以讓發(fā)送方得知接收方當(dāng)前接收速率
SACK應(yīng)該只在需要的時候發(fā)送。
處理確認(rèn) 在以下情況下，接收方發(fā)送確認(rèn)
1、當(dāng)RT0超時的時候 2、當(dāng)接收序列中的16KB或32KB包的時候
3、任何未決的ACK可以附帶在數(shù)據(jù)包中
4、先出的序列包
5、帶寬的根本性變化 前三個ACK包括與丟棄/接收到的數(shù)據(jù)包相關(guān)的信息；即使接收方?jīng)]有接收到新 的數(shù)據(jù)包，可以發(fā)送最后兩個。 一旦收到具有丟失/已接收信息的ACK，發(fā)送方應(yīng)該馬上釋 放已經(jīng)確認(rèn)的VBuf 。如果引入的ACK正面確認(rèn)out_queue中的所有，即，發(fā)送但末確認(rèn)的，以及如果發(fā)送方有要發(fā)送的，則將清除'下一個發(fā)送定時器'并發(fā)送新的數(shù)據(jù)，因?yàn)楣艿酪?br> 經(jīng)清空。
(Re)傳輸策略 如果發(fā)送方符合當(dāng)前發(fā)送窗口 ，則可以發(fā)送新包。否則，發(fā)送方應(yīng)該將數(shù)據(jù)包留在 虛擬連接界外隊(duì)列(out bound queue)并在發(fā)送窗口由下一個SACK打開時，將它們發(fā)送。 無論什么時候發(fā)送發(fā)傳輸新的包時，應(yīng)該開始新的能夠在LTO時間中超時的定時器。LTO時 間包括傳輸時間加上行程時間。當(dāng)該定時器超時時，發(fā)送方發(fā)送REQUES乙SACK包并重新開 始定時。如果發(fā)送方在發(fā)送N個(可配置的)REQUES乙SACK包后，沒有從接收方得到任何 回復(fù)，則發(fā)送方必須關(guān)閉與接收方的連接。發(fā)送方認(rèn)為發(fā)送的包已經(jīng)超出基于當(dāng)前帶寬和 延時的網(wǎng)絡(luò)時才應(yīng)當(dāng)進(jìn)行重傳。如果在該時間(flight time)中接收到重傳請求，則發(fā)送 方忽略該重傳請求。 發(fā)送方一次不應(yīng)該發(fā)送整個窗口字節(jié)(window worth of bytes)。這將導(dǎo)致在下 一個或中間的路由器處包突發(fā)以及在沒有足夠的緩沖區(qū)情況下將引起丟包。為了避免這樣 情況發(fā)生，該發(fā)送方必須根據(jù)時間一直控制包流，根據(jù)帶寬和路徑時延將它們間隔開。
連接終止 應(yīng)用層應(yīng)該終止在各個時間的虛擬連接。傳輸層應(yīng)該發(fā)送關(guān)閉類型的連接關(guān)閉 包，如中止或友好的關(guān)閉。如果應(yīng)用層中止它的連接傳輸層應(yīng)該丟棄任何來自該虛擬連接 的朝向其他終端的包并發(fā)送新的TP—ABORT類型包。否則，應(yīng)該發(fā)送所有的包并隨后關(guān)閉 VC。在后面的例子中，在最后出來的VC包中設(shè)置TP—CLOSE位來轉(zhuǎn)達(dá)VC包已經(jīng)關(guān)閉了。 一 旦關(guān)閉虛擬連接，在該連接上將沒有數(shù)據(jù)發(fā)送和接收。接收傳輸層通知應(yīng)用層其他端已經(jīng) 請求連接關(guān)閉。注意到，實(shí)際連接從來沒有關(guān)閉。實(shí)際連接只在一個連接端停止時才關(guān)閉。
校驗(yàn)和計(jì)算 傳輸應(yīng)該保證數(shù)據(jù)在無任何差錯地傳送到另一端。為了檢測傳輸中的位錯誤，在 向接收方發(fā)送數(shù)據(jù)包之前對整個包計(jì)算校驗(yàn)和。接收方應(yīng)該重新計(jì)算到達(dá)的包的校驗(yàn)和， 并比較包中的校驗(yàn)和。如果校驗(yàn)和不同，則考慮為已破壞的包并丟棄它。在包頭中校驗(yàn)和 字段在計(jì)算校驗(yàn)和之前必須為零。為了計(jì)算校驗(yàn)和，所有的數(shù)據(jù)分為16位數(shù)，并計(jì)算他們 的余數(shù)和的一個余數(shù)。這類似于因特網(wǎng)中的校驗(yàn)和計(jì)算。
鑒權(quán) —旦在傳輸層建立實(shí)際網(wǎng)絡(luò)連接，但在數(shù)據(jù)在每個終端之間傳輸之前，客戶端和/ 或服務(wù)器端的鑒權(quán)可以通過鑒權(quán)模塊來驗(yàn)證。注意到根據(jù)鑒權(quán)參數(shù)可以不建立實(shí)際連接。 例如，如果服務(wù)器需要鑒別一個客戶端，而該客戶端鑒權(quán)失效或客戶端不支持鑒權(quán)，則在傳 輸層拒絕實(shí)際連接。
安全 在傳輸中提供安全來避免惡意黑客發(fā)送看上去類似于系統(tǒng)發(fā)送的包。 一種方法是 通過在客戶端/服務(wù)器發(fā)送的鑒權(quán)包的序列中發(fā)送假包來中斷實(shí)際連接。在VTP中，安全 的目的在于在中途攻擊中不為這樣的人留下任何漏洞。為了避免這種情況，每一個終端發(fā) 送僅能被相關(guān)的對點(diǎn)實(shí)體解碼的偽隨機(jī)序列號(PRSN)。 客戶端能夠在來自用戶界面(UI)的傳輸層處啟用安全。如果傳輸沒有設(shè)定為安 全的，則將使用連續(xù)序列號進(jìn)行數(shù)據(jù)傳輸和ACK處理。
雖然在此已描述了本發(fā)明的優(yōu)選實(shí)施方式，但應(yīng)當(dāng)理解對于本領(lǐng)域的技術(shù)人員可 以設(shè)計(jì)將落入所公開的本發(fā)明的精神和范圍內(nèi)的其它替代的應(yīng)用。例如，預(yù)取裝置可以執(zhí) 行任何所選對象的選擇性預(yù)取，不公僅是順序加載。預(yù)取裝置可用各種啟發(fā)式、規(guī)則或適應(yīng) 性的特性來確定有選擇地預(yù)取哪些對象。此外，Web頁面可以包括預(yù)取裝置所說明的元標(biāo) 記，并確定有選擇地預(yù)取哪些對象。 因此，本發(fā)明應(yīng)該僅限于以下權(quán)利要求所作的限制。
權(quán)利要求
一種利用瀏覽器顯示由多個網(wǎng)頁對象組成的網(wǎng)頁的顯示裝置，其中必須在長延時鏈路上分別取出所述網(wǎng)頁對象，該裝置包括用于通過聚合和流量可控信道，選擇性地并發(fā)預(yù)取對象的裝置；用于緩存接近所述瀏覽器的所述預(yù)取對象的裝置；其中，不改變?yōu)g覽器特性的情況下順序接入在低帶寬和高時延網(wǎng)絡(luò)中提供的所述網(wǎng)頁對象。
2. 根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述用于選擇性預(yù)取的裝置從代理到網(wǎng) 關(guān)服務(wù)器執(zhí)行所述預(yù)??；其中低并行度局限在所述瀏覽器和所述代理之間。
3. 根據(jù)權(quán)利要求1所述的裝置，其特征在于，用于選擇性預(yù)取的裝置包含用于與相應(yīng) 服務(wù)器模塊通信的模塊，并且準(zhǔn)備必要的網(wǎng)頁對象從而可以在寄主所述瀏覽器上的平臺上 得到。
4. 根據(jù)權(quán)利要求2所述的裝置，其特征在于，在提取Web網(wǎng)頁對象時，所述代理和所述 網(wǎng)關(guān)一起輔助所述Web瀏覽器，協(xié)作取出選擇的嵌入式網(wǎng)頁對象；其中選擇的嵌入式網(wǎng)頁 對象對于所述瀏覽器在本地是可以得到的；并且其中在對象得到之前，所述瀏覽器不需要 等待請求以及相應(yīng)的響應(yīng)來遍歷長時延鏈路。
5. —種裝置，包含 與瀏覽器以及主機(jī)平臺相關(guān)的代理； 與源Web服務(wù)器通信的網(wǎng)關(guān)； 在所述代理和所述網(wǎng)關(guān)之間的長延時鏈路；用于從所述源Web服務(wù)器到所述瀏覽器經(jīng)由所述低延時鏈路并行下載網(wǎng)頁對象的獨(dú) 立的流量控制裝置；以及與所述主機(jī)平臺相關(guān)的緩存，其中在所述代理得知網(wǎng)頁對象后，立即有選擇地并行下 載Web頁面對象，獨(dú)立執(zhí)行所述瀏覽器和所述源Web服務(wù)器；其中所述瀏覽器可以在本地通 過所述代理在所述緩存處得到已選擇嵌入式網(wǎng)頁對象；以及其中所述瀏覽器在獲得Web對象之前，不需要等待請求以及相應(yīng)的相應(yīng)遍歷所述長延 時鏈路。
6. 用于在長延時鏈路提高HTTP性能的裝置，包括 在主機(jī)平臺中的瀏覽器；與所述平臺相關(guān)的客戶端，所述平臺含有具有預(yù)取功能的代理以及Web對象緩存，所 述代理顯式預(yù)取所選擇的，順序加載的網(wǎng)頁對象，并在所述Web對象緩存中存儲預(yù)選對象； 與所述客戶端通過具有流量可控信道的長延時鏈路通信的服務(wù)器；以及 與所述服務(wù)器通信的源Web服務(wù)器；其中通過所述瀏覽器依照請求順序加載的所述源Web服務(wù)器請求的網(wǎng)頁對象通過所 述代理加載到所述Web對象緩存；其中所述順序加載的網(wǎng)頁對象是可以在所述請求時的所 述網(wǎng)頁緩存得到，并從在所述請求時的所述Web對象緩存加載；其中所述請求和響應(yīng)沒有 遍歷所述長延時鏈路。
7. 根據(jù)權(quán)利要求6所述的裝置，其特征在于，所述順序加載的對象包含任何 JavaScript禾口 Style Sheet。
8. —種用于提高通過長延時鏈路加載的網(wǎng)頁性能的方法，包括以下步驟與客戶相關(guān)的瀏覽器，請求來自所述長延時鏈路的一端的網(wǎng)頁；在所述長延時鏈路的另一端處接收所述請求的網(wǎng)關(guān)，所述網(wǎng)關(guān)從源Web服務(wù)器中找到 網(wǎng)頁描述并經(jīng)由所述長延時鏈路將所述網(wǎng)頁描述發(fā)送到所述客戶端。 所述瀏覽器接收并解析所述網(wǎng)頁描述；當(dāng)所述網(wǎng)頁描述運(yùn)行時，通過所述瀏覽器加載所述網(wǎng)頁，獨(dú)立解析所述頁面描述，以及同時，所述瀏覽器識別通常順序提取的已選的網(wǎng)頁對象類型；與所述瀏覽器并發(fā)地利用預(yù)取裝置接入所述源Web服務(wù)器取出所述對象，同時所述瀏覽器仍然加載所述網(wǎng)頁；在取出具有預(yù)取裝置地所述對象后，將所述對象存儲在本地緩存中；以及 所述瀏覽器接入用于所示對象地所述本地緩存來完成所述網(wǎng)頁地加載； 其中在所述瀏覽器沒有請求所述對象下經(jīng)由所述長延時鏈路加載所述對象。
9. 根據(jù)權(quán)利要求8所述的方法，其特征在于，所述解析步驟確定是否在所述Web網(wǎng)頁中 存在任何JavaScript或Style Sheet ;并且其中所述預(yù)取裝置與加載所述網(wǎng)頁的所述瀏覽 器并發(fā)預(yù)取所述對象。
10. 根據(jù)權(quán)利要求8所述的方法，還包含步驟所述預(yù)取裝置執(zhí)行任何指定的對象的有選擇性的預(yù)?。黄渲兴鲱A(yù)取裝置應(yīng)用任何啟 發(fā)式、規(guī)則以及適應(yīng)的特性來確定應(yīng)該有選擇地預(yù)取哪些對象來減小預(yù)取操作在由瀏覽器 請求的對象預(yù)取的時延上的影響。
11. 根據(jù)權(quán)利要求8所述的方法，其特征在于，所述網(wǎng)頁包含由所述網(wǎng)關(guān)通過任何啟發(fā) 式應(yīng)用在中心點(diǎn)提供的元標(biāo)記；所述方法還包含步驟通過所述預(yù)取裝置解釋所述元標(biāo)記來確定有選擇地預(yù)取哪些對象。
12. —種利用瀏覽器顯示由多個網(wǎng)頁對象組成的網(wǎng)頁的顯示方法，其中所述Web網(wǎng)頁 對象必須通過長延時鏈路分別取出，所述方法包含的步驟通過聚合和流量可控信道并發(fā)地有選擇地預(yù)取對象；以及 緩存接近所述瀏覽器的所述預(yù)取對象；其中在低帶寬和高時延網(wǎng)絡(luò)中在沒有改變?yōu)g覽器特性的情況下順序接入所述Web網(wǎng) 頁對象。
13. 根據(jù)權(quán)利要求12所述的方法，其特征在于，所述有選擇地預(yù)取步驟還包含從代理 到網(wǎng)關(guān)服務(wù)器執(zhí)行所述預(yù)取步驟，其中低并行度局限在所述瀏覽器和所述代理之間。
14. 根據(jù)權(quán)利要求12所述的方法，其特征在于，所述有選擇地預(yù)取還包含與相應(yīng)的服 務(wù)器模塊通信的步驟，以及準(zhǔn)備必要的網(wǎng)頁對象，從而在寄主所述瀏覽器的平臺上可以得 到。
15. 根據(jù)權(quán)利要求13所述的方法，其特征在于，所述代理和所述網(wǎng)關(guān)共同協(xié)助所述瀏 覽器通過協(xié)作預(yù)取選擇的嵌入式頁面對象來預(yù)取網(wǎng)頁對象；其中已選的網(wǎng)頁對象可以在本 地被所述瀏覽器得到；以及其中所述瀏覽器在得到對象之前不需要等待請求以及相應(yīng)的響 應(yīng)來遍歷長時延鏈路。
16. 用于在長延時鏈路上改進(jìn)HTTP性能的方法，包含以下步驟 在主機(jī)平臺中使用瀏覽器；提供與含有具有預(yù)取功能的代理和Web對象緩存的所述平臺相關(guān)的客戶端，所述代理顯式預(yù)取所選擇的、順序加載的網(wǎng)頁對象并在所述Web對象緩存中存儲所述預(yù)取對象； 提供通過具有流量可控信道的長延時鏈路與所述客戶端通信的服務(wù)器；以及 接入與所述服務(wù)器通信的源網(wǎng)頁對象；其中通過所述瀏覽器依照請求順序加載的所述源Web服務(wù)器請求的網(wǎng)頁對象通過所 述代理加載到所述Web對象緩存；其中所述按序加載的網(wǎng)頁對象是可以得到的，以及從所 述請求時的所述對象緩存加載；并且其中所述請求和響應(yīng)沒有遍歷所述長延時鏈路。
17. 根據(jù)權(quán)利要求16所述的方法，其特征在于，所述順序加載的對象包含任何 JavaScript禾口 Style Sheet。
18. —種用于改進(jìn)網(wǎng)頁通過長延時鏈路加載的性能的裝置；包含與客戶端相關(guān)的瀏覽器，用于請求來自所述長延時鏈路的一端的網(wǎng)頁；所述瀏覽器接 收并解析網(wǎng)頁描述；在所述長延時鏈路的另一端處接收所述請求的網(wǎng)關(guān)，所述網(wǎng)關(guān)從源Web服務(wù)器中找到 網(wǎng)頁描述并經(jīng)由所述長延時鏈路將所述頁面描述發(fā)送到所述客戶端；用于獨(dú)立解析所述網(wǎng)頁描述的解析器，以及并發(fā)地，在所述網(wǎng)頁描述通過所述瀏覽器 加載所述網(wǎng)頁的同時，所述瀏覽器識別通常為順序提取的已選的網(wǎng)頁對象類型；與所述瀏覽器并發(fā)使用的預(yù)取裝置，以接入所述源Web服務(wù)器取出所述對象，同時所 述瀏覽器仍然加載所述網(wǎng)頁；以及在使用預(yù)取裝置取出所述對象后，用于存儲所述對象的本地緩存； 其中所述瀏覽器接入所述對象的本地緩存完成所述網(wǎng)頁加載；以及 其中在所述瀏覽器未請求所述對象情況下通過所述長延時鏈路加載所述對象。
19. 根據(jù)權(quán)利要求18所述的裝置，其特征在于，所述解析器確定在所述網(wǎng)頁中是否存 在JavaScript或Style Sheet ;以及其中所述預(yù)取裝置與所述瀏覽器并發(fā)取出加載到所述 網(wǎng)頁的所述對象。
20. 根據(jù)權(quán)利要求18所述的裝置，其特征在于，還包含用于執(zhí)行任何指定對象的有選擇預(yù)取的與所述預(yù)取裝置相關(guān)的裝置，其中所述預(yù)取裝 置使用任何啟發(fā)式、規(guī)則以及適應(yīng)的特性來確定有選擇地預(yù)取哪些對象。
21. 根據(jù)權(quán)利要求18所述的裝置，其特征在于，所述網(wǎng)頁含有通過所述網(wǎng)關(guān)提供給代 理的元標(biāo)記，所述網(wǎng)關(guān)使用與多種流相關(guān)的集中的情報，所述裝置還包含與所述預(yù)取裝置相關(guān)的裝置，用于解釋所述元標(biāo)記來確定有選擇地預(yù)取哪些對象。
全文摘要
本發(fā)明涉及在長延時鏈路上經(jīng)由聚合和流量可控信道通過并發(fā)預(yù)取對象提高HTTP的性能。代理和網(wǎng)關(guān)共同輔助Web瀏覽器通過長延時數(shù)據(jù)鏈路快速從因特網(wǎng)Web網(wǎng)址取出HTTP內(nèi)容。通過將對象準(zhǔn)備就緒并且在駐留瀏覽器需要的時候可以在主機(jī)平臺得到的方式，網(wǎng)關(guān)和代理協(xié)作取出選擇的嵌入式對象。這對于瀏覽器似乎可以瞬時得到對象并完成對象處理，不需要太多等待下請求下一個對象。不需要瀏覽器等待其請求以及相應(yīng)的響應(yīng)來遍歷長時延鏈路，可以瞬時得到嵌入式對象。
文檔編號H04N7/10GK101796491SQ200680019323
公開日2010年8月4日 申請日期2006年5月4日 優(yōu)先權(quán)日2005年5月4日
發(fā)明者克爾恩·常, 奎師那·拉馬達(dá)斯, 洛克·N·霍 申請人:文丘里無線有限公司