長延時鏈路上提高http性能的方法和裝置的製作方法

2023-05-15 15:32:01

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

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


圖1示出了根據本發明的在長延時鏈路上實施提高HTTP性能的方法和裝置的系 統結構的方框圖； 圖2示出了根據本發明的模塊間交互概述的方框圖；
圖3示出了根據本發明的經由本地緩存的連接流的流程圖；
圖4示出了根據本發明的來自本地緩存的連接流的流程圖；以及
圖5示出了根據本發明的預取後置HTML處理連接的方框圖。
具體實施方式

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



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