專利名稱：一種更新Web頁面的方法和Web代理設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及Web技術(shù)，尤指一種更新Web頁面的方法和Web代理設(shè)備。
背景技術(shù)：
在現(xiàn)有技術(shù)中，客戶端主要通過如下兩個階段實現(xiàn)對Web頁面的訪問。 第一個階段是客戶端根據(jù)所請求Web頁面的統(tǒng)一資源定位符(URL, Uniform Resource Location)地址，向Web服務(wù)器發(fā)送Http請求報文請求該 Web頁面的主文件，即超文本標(biāo)記語言(HTML, Hypertext Markup Language ) 文件；Web服務(wù)器向客戶端返回Web頁面的主文件。第二個階段是客戶 端接收HTML文件，得到顯示W(wǎng)eb頁面所需內(nèi)嵌附屬文件的URL,根據(jù)附 屬文件的URL向?qū)?yīng)的服務(wù)器發(fā)送超文本傳輸協(xié)議(Http, Hypertext Transfer Protocol)請求報文請求所需的附屬文件；Web服務(wù)器返回附屬文件?？蛻?端才艮據(jù)收到的主文件以及附屬文件顯示W(wǎng)eb頁面。這里，才艮據(jù)Web頁面的 不同形式，附屬文件可以包括圖片、腳本、樣式表等類型。
當(dāng)客戶端無法直接與Web服務(wù)器進(jìn)行通信，客戶端通常通過Web代理 設(shè)備實現(xiàn)與Web服務(wù)器之間交互，訪問Web頁面。例如，在公網(wǎng)的客戶端 無法訪問內(nèi)網(wǎng)中的Web服務(wù)器時，客戶端通過http反向代理設(shè)備(HRP, Http Reverse Proxy)訪問Web服務(wù)器，具體如圖1所示。在這種情況下， 客戶端通過廣域網(wǎng)訪問擁有公網(wǎng)IP地址的HRP,對HRP發(fā)出Http請求報 文。HRP解析Http請求報文，根據(jù)請求的URL找到對應(yīng)的內(nèi)網(wǎng)真實URL 地址，將其轉(zhuǎn)發(fā)給相應(yīng)的Web服務(wù)器進(jìn)行處理。內(nèi)網(wǎng)Web服務(wù)器處理完請 求后，將應(yīng)答報文轉(zhuǎn)發(fā)給HRP，由HRP再將應(yīng)答報文返回給遠(yuǎn)程主機。
在Web代理設(shè)備代理客戶端訪問Web服務(wù)器時，還會緩存Web服務(wù)器返回的應(yīng)答報文，保存其中攜帶的文件以及文件的校驗參數(shù)，用來減少重復(fù)
數(shù)據(jù)的傳送。當(dāng)Web代理設(shè)備收到客戶端發(fā)送的Http請求報文時，首先檢 查所需的文件是否在本地緩存，如果是，根據(jù)檢驗參數(shù)對其進(jìn)行校驗，在不 過期的情況下，直接向客戶端返回所需的文件；如果沒有在本地緩存或者所 需的文件過期，則向Web服務(wù)器發(fā)送Http請求報文請求更新緩存文件，在 收到返回的應(yīng)答報文時，向客戶端返回收到的應(yīng)答報文，并根據(jù)該應(yīng)答報文 更新自身緩存。
通過上面的介紹不難發(fā)現(xiàn)，Web代理設(shè)備只會在收到客戶端發(fā)來請求附 屬文件的Http請求報文后，才檢查緩存的文件是否需要更新。如果需要更 新，再從Web服務(wù)器獲取更新文件。這樣，Web代理設(shè)備在每處理一個Web 頁面請求時，客戶端都會等待一個較長的時間。為了提高Web代理設(shè)備的 響應(yīng)速度，現(xiàn)有技術(shù)在Web代理設(shè)備收到Web服務(wù)器返回的主頁面時，解 析主頁面得到附屬文件的URL，根據(jù)得到的URL主動向Web服務(wù)器更新附 屬文件，然后將更新后的附屬文件發(fā)送給客戶端，供客戶端顯示。由于減少 了客戶端向Web代理設(shè)備請求附屬文件的過程，有效的提高了 Web代理設(shè) 備的響應(yīng)速度。
然而，隨著Web網(wǎng)頁功能的不斷增加，Web頁面內(nèi)嵌附屬文件的URL 并不是都由Web網(wǎng)頁的主文件來攜帶，而是客戶端在收到主文件后根據(jù)自 身的運行環(huán)境以及主文件中攜帶的內(nèi)容計算得到。在這種情況下，Web代理 設(shè)備難以通過解析主文件來得到其內(nèi)嵌附屬文件的URL,因此還是會出現(xiàn) Web代理設(shè)備響應(yīng)速度慢的問題。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明提供了一種更新Web頁面的方法和Web代理設(shè)備， 應(yīng)用本發(fā)明所提供的方法及Web代理設(shè)備能夠獲得Web頁面內(nèi)嵌附屬文件 的URL地址，加快Web頁面的響應(yīng)速度。
為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的一種更新Web頁面的方法，該方法包括 記錄Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系； 收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報文后，根據(jù) 所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件的URL地址，確定需要更新 所述附屬文件時，根據(jù)所獲得的URL地址訪問Web服務(wù)器更新所述附屬文 件；向所述客戶端提供所述Web頁面更新后的附屬文件。 一種Web代理設(shè)備，該Web代理設(shè)備包括控制單元和緩存單元； 所述控制單元，用于記錄并將Web頁面與其內(nèi)嵌附屬文件URL地址的 關(guān)聯(lián)關(guān)系保存至所述緩存單元；收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁 面的Http請求報文后，根據(jù)所述緩存單元記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁 面附屬文件的URL地址，確定需要更新所述附屬文件時，根據(jù)所獲得的URL 地址訪問Web服務(wù)器更新所述附屬文件；向客戶端提供更新后的附屬文件； 所述緩存單元，用于保存Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián) 關(guān)系。本發(fā)明所提供的 一種更新Web頁面的方法和Web ^理i殳備，記錄Web 頁面與其內(nèi)嵌附屬文件URL的關(guān)聯(lián)關(guān)系，在收到客戶端訪問已記錄關(guān)聯(lián)關(guān) 系的Web頁面的Http請求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁 面附屬文件的URL地址，主動更新附屬文件，使客戶端能夠直接從Web代 理設(shè)備中獲得附屬文件的更新文件，加快了 Web頁面的響應(yīng)速度。本發(fā)明 的技術(shù)方案，由于不需要依靠解析應(yīng)答報文來獲得Web頁面內(nèi)嵌附屬文件 的URL地址，因此解決了現(xiàn)有技術(shù)無法通過解析應(yīng)答報文得到附屬文件 URL地址的技術(shù)問題。


圖1為現(xiàn)有技術(shù)客戶端通過HRP訪問Web服務(wù)器的網(wǎng)絡(luò)結(jié)構(gòu)圖； 圖2為本發(fā)明實施例中記錄主文件和附屬文件的數(shù)據(jù)結(jié)構(gòu)示意圖；圖3為本發(fā)明實施例中記錄關(guān)聯(lián)關(guān)系的流程圖； 圖4為本發(fā)明實施例中更新附屬文件的流程圖； 圖5為本發(fā)明實施例中Web代理設(shè)備的結(jié)構(gòu)圖。
具體實施方式
根據(jù)背景技術(shù)中的介紹不難發(fā)現(xiàn)，由于Web服務(wù)器返回的主文件，即 HTML文件所攜帶的內(nèi)嵌附屬文件的URL鏈接難以解析，因此在本發(fā)明的 技術(shù)方案中，可以根據(jù)獲取附屬文件的Http請求報文中攜帶的信息來記錄 Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系。這樣，收到客戶端訪問 已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲 得所述Web頁面附屬文件的URL地址，確定需要更新所述附屬文件時，根 據(jù)所獲得的URL地址訪問Web服務(wù)器更新所述附屬文件；對后續(xù)收到的客 戶端獲取附屬文件的http請求，直接從緩存中提取更新后的附屬文件，返回 給客戶端，加快Web頁面的響應(yīng)速度。其中，根據(jù)Http請求報文中攜帶的附屬文件的URL地址記錄Web頁面 與其內(nèi)嵌附屬文件鏈接地址的關(guān)聯(lián)關(guān)系具體可以是確定收到獲取附屬文件 的Http請求報文，從該請求報文的請求頭中查找得到所述附屬文件所屬的 Web頁面，并獲得請求頭中附屬文件的URL地址；對應(yīng)查找到的Web頁面 記錄該附屬文件的URL地址。通常情況下，客戶端與Web代理設(shè)備之間會為每個Http請求建立一 個傳輸控制協(xié)議(TCP, Transmission Control Protocol)連接，包括請求主 文件的Http請求以及請求附屬文件的Http請求，用來傳輸-清求才艮文以及應(yīng) 答報文。在這種情況下，為了確定當(dāng)前收到的Http請求報文為針對附屬文 件發(fā)送的，Web代理設(shè)備在收到客戶端發(fā)送的Http請求報文之后，還需要 等待該請求報文的應(yīng)答報文，根據(jù)應(yīng)答報文應(yīng)答頭包含的文件類型 (Content-Type )字段來確定當(dāng)前收到的Http請求報文是針對主文件的、還 是針對附屬文件的。在應(yīng)答頭攜帶的文件類型字段指示不為主文件的情況下，確定當(dāng)前收到的Http請求報文為訪問附屬文件的Http請求報文。這里，為了提高傳輸效率Http也允許使用TCP常連接，即客戶端與服 務(wù)器之間建立持續(xù)使用的TCP連接，通過一條連接處理多條Http請求。同 時，為了在使用常連接時不混淆請求與應(yīng)答之間的對應(yīng)關(guān)系，Http協(xié)議要求 客戶端與服務(wù)器之間采用一問一答的形式，即在前一個請求的應(yīng)答沒有返回 之前，客戶端不能發(fā)送新的Http請求報文。當(dāng)客戶端通過常連接訪問Web 頁面時，TCP常連接中傳輸?shù)氖讉€Http請求報文必然是針對主文件的，而 后續(xù)傳輸非首個Http請求報文必然是針對附屬文件。當(dāng)確定當(dāng)前收到的Http請求報文為針對附屬文件的請求報文后，需要 查找得到所述附屬文件所屬的Web頁面時，可以根據(jù)Http請求報文請求頭 中的Referer字段確定附屬文件所屬的Web頁面。按照Http協(xié)議的定義， Referer字段用來說明當(dāng)前的請求源自哪個Web頁面。這里，對應(yīng)查找到的Web頁面記錄該附屬文件的URL地址可以是對應(yīng) Web頁面的URL地址記錄所述附屬文件的URL地址。這樣，在接收到客戶 端發(fā)送的Http請求報文時，可以獲得該Http請求報文的URL地址，在對應(yīng) 該URL地址記錄了附屬文件的URL地址時，就可以確定收到客戶端訪問已 記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報文。另外，在本發(fā)明的技術(shù)方案中所指的確定需要更新所述Web頁面內(nèi)嵌 附屬文件的方式可以是指，在Web代理設(shè)備的緩存中確定附屬文件已經(jīng)過 期時。具體的執(zhí)行方式是，在收到請求附屬文件的應(yīng)答報文時，可以根據(jù)請 求附屬文件的應(yīng)答報文，對應(yīng)所述附屬文件的URL地址記錄附屬文件以及 該附屬文件的校驗信息。這樣，收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁 面的Http請求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件 的URL地址，就獲得附屬文件以及附屬文件的檢驗信息，在所述校驗信息 確定當(dāng)前附屬文件過期時，就可以確定需要更新所述Web頁面內(nèi)嵌附屬文 件。在本發(fā)明的技術(shù)方案，Web代理設(shè)備向客戶端提供附屬文件的更新文件的方式可以是，收到客戶端發(fā)送的獲取附屬文件的Http請求報文，從緩存中提取更新后的附屬文件，返回給所述客戶端；當(dāng)然也可以是采用現(xiàn)有技術(shù)的方法，獲得更新文件后主動向客戶端返回獲得的更新文件。從上面的介紹不難看出，本發(fā)明技術(shù)方案主要關(guān)注對附屬文件Http請 求4艮文的處理，而對于請求主文件的Http請求報文的處理可以沿用現(xiàn)有技 術(shù)的相關(guān)技術(shù)手段。以下參照附圖并列舉實施例，對本發(fā)明的技術(shù)方案做進(jìn) 一 步的詳細(xì)說明。在本實施例的技術(shù)方案中，為了記錄Web頁面內(nèi)嵌附屬文件的URL地 址，可以采用如圖2所示的數(shù)據(jù)結(jié)構(gòu)。在圖2中包括主節(jié)點和從節(jié)點。主節(jié) 點用來記錄一個Web頁面的主文件，從節(jié)點用來記錄一個Web頁面內(nèi)嵌的 附屬文件。主節(jié)點中包括該Web頁面的URL地址、主文件緩存、指向主文 件緩存的指針和關(guān)聯(lián)關(guān)系鏈表指針。其中，關(guān)聯(lián)關(guān)系鏈表指針中記錄了指向 各從節(jié)點的指針。從節(jié)點中包括附屬文件緩存，以及指向附屬文件緩存的指 針，附屬文件緩存中記錄附屬文件以及對應(yīng)的校驗參數(shù)等。這里，需要指出頁面URL地址稱為主文件的URL地址。本發(fā)明的技術(shù)方案主要通過記錄Web頁面與其內(nèi)嵌附屬文件URL的關(guān) 聯(lián)關(guān)系，在收到對主文件的Http請求報文時，利用關(guān)聯(lián)關(guān)系主動更新主文 件包含的附屬文件，以提高Web頁面的響應(yīng)速度。因此，在本實施例的技 術(shù)方案中通過訪問Web頁面的流程，來介紹記錄關(guān)聯(lián)關(guān)系以及更新附屬文 件的操作。在本實施例中，假設(shè)客戶端A和客戶端B通過Web代理設(shè)備訪問一 Web頁面，客戶端A先訪問。該Web頁面由主文件和一附屬文件構(gòu)成，Web 服務(wù)器X提供主文件，Web服務(wù)器Y提供附屬文件。在Web代理設(shè)備上未 保存所要訪問的Web頁面。那么，客戶端A訪問Web頁面時，Web代理詔: 備將建立Web頁面與內(nèi)嵌附屬文件的關(guān)聯(lián)關(guān)系。當(dāng)客戶端B再次訪問該Web頁面時，Web代理設(shè)備則根據(jù)記錄的關(guān)聯(lián)關(guān)系提前更新附屬文件，使 客戶端B能夠更加快速地訪問Web頁面。參見圖3,圖3為客戶端A訪問Web頁面的流程圖，在此過程中Web 代理設(shè)備將記錄Web頁面內(nèi)嵌附屬文件的URL。在步驟301中，客戶端A需要訪問當(dāng)前Web頁面，向Web代理設(shè)備發(fā) 送請求主文件的Http請求l艮文。在步驟302中，Web代理設(shè)備根據(jù)收到的Http請求報文的URL,向 Web服務(wù)器X發(fā)送Http請求報文。由于Web代理設(shè)備本身并不知道當(dāng)前收到的Http請求報文是針對Web 頁面，還是針對Web頁面內(nèi)嵌附屬文件的。因此，為了建立該Web頁面的 關(guān)聯(lián)關(guān)系，Web代理設(shè)備向Web服務(wù)器X發(fā)送Http請求報文后，還需要監(jiān) 控從Web服務(wù)器X返回的應(yīng)答才艮文，用來確定當(dāng)前Http請求凈艮文對應(yīng)的文 件對象。在返回的應(yīng)答報文攜帶的文件類型為主文件類型時，則當(dāng)前Http 請求報文為請求主文件的報文；在返回的應(yīng)答報文攜帶的文件類型為附屬文 件類型時，則當(dāng)前Http請求報文為請求附屬文件的報文。另外，Web代理設(shè)備在收到客戶端發(fā)來的Http請求報文后，均會根據(jù) Http請求報文請求頭中的URL判斷自身是否緩存了所需的文件，如果緩存 了，直接向客戶端返回對應(yīng)的應(yīng)答報文；如果沒有緩存，則根據(jù)URL向?qū)?應(yīng)的Web服務(wù)器發(fā)送該Http請求報文。這里，由于Web代理設(shè)備中并沒有 緩存當(dāng)前請求Web頁面的相關(guān)信息，因此向提供該Web頁面的Web服務(wù)器 發(fā)送Http請求4艮文。在步驟303中，Web服務(wù)器向Web代理設(shè)備返回所請求主文件的應(yīng)答 報文。在步驟304中，Web代理設(shè)備接收步驟302發(fā)送Http請求報文的應(yīng)答 報文，在應(yīng)答報文應(yīng)答頭的Content-Type字段指示該應(yīng)答報文中攜帶的是 Web頁面的主文件時，確定步驟301中收到的Http請求l艮文為針對主文件， 記錄主文件。具體記錄主文件的方式可以是，為當(dāng)前主文件設(shè)置圖2所示主節(jié)點的數(shù)據(jù)結(jié)構(gòu)。在其中記錄主文件的URL,以及應(yīng)答報文中攜帶的主文件以及對 應(yīng)的校驗信息。當(dāng)Web頁面的主文件是由Web服務(wù)器根據(jù)請求參數(shù)動態(tài)生 成的時候，由于主文件在每次生成時均不相同，因此Web代理設(shè)備不需要 保存其中的主文件以及對應(yīng)的校驗信息。此時，Web代理設(shè)備可以根據(jù)http 響應(yīng)頭中的緩存控制字段確定收到的頁面是否可以緩存。在步驟304中，Web代理設(shè)備向客戶端A返回主文件應(yīng)答l艮文。在步驟305中，客戶端A接收返回的應(yīng)答報文，獲得其中攜帶的主文 件，解析主文件可以獲得當(dāng)前Web頁面中附屬文件的URL,向Web代理i殳 備Y發(fā)送請求附屬文件的Http請求報文。在步驟306中，Web代理設(shè)備接收客戶端A發(fā)送的Http請求報文，根 據(jù)收到的Http請求報文的URL,向Web服務(wù)器Y發(fā)送Http請求報文。與步驟302中的情況相同，Web代理設(shè)備本身并不知道當(dāng)前收到的Http 請求報文是針對主文件，還是針對Web頁面內(nèi)嵌附屬文件的。為了建立該 Web頁面的關(guān)聯(lián)關(guān)系，Web代理設(shè)備向Web服務(wù)器Y發(fā)送Http請求報文后， 還需要監(jiān)控從Web服務(wù)器Y返回的應(yīng)答報文，用來確定當(dāng)前Http請求報文 對應(yīng)的文件對象。相同的，Web代理設(shè)備在收到客戶端發(fā)來的Http請求報文后，均會根 據(jù)Http請求報文中的URL判斷自身是否緩存了所需的文件，如果緩存了 ， 直接向客戶端返回對應(yīng)的應(yīng)答報文；如果沒有緩存，則根據(jù)URL向?qū)?yīng)的 Web服務(wù)器發(fā)送該Http請求報文。這里，由于Web代理設(shè)備中并沒有緩存 當(dāng)前請求的Web頁面內(nèi)嵌附屬文件，因此需要向提供該附屬文件的Web服 務(wù)器發(fā)送Http請求報文。在步驟307中，Web服務(wù)器Y向Web代理設(shè)備返回請求附屬文件的應(yīng) 答報文。在步驟308中，Web代理設(shè)備接收步驟306發(fā)送Http請求報文的應(yīng)答 報文，在應(yīng)答報文應(yīng)答頭文件類型字段指示該應(yīng)答報文中攜帶的不是Web頁面的主文件時，確定步驟306中收到的Http請求報文為針對Web頁面內(nèi) 嵌附屬文件的，記錄附屬文件建立關(guān)聯(lián)關(guān)系。具體記錄附屬文件的方式可以是，從步驟306中收到的Http請求報文 請求頭中獲得的Referer字段，確定附屬文件源自的Web頁面，即Web頁 面的URL。為當(dāng)前附屬文件設(shè)置圖2所示從節(jié)點的數(shù)據(jù)結(jié)構(gòu)，在其中記錄 附屬文件的URL，以及附屬文件以及對應(yīng)的校驗信息；并根據(jù)Web頁面的 URL找到對應(yīng)的主節(jié)點，在主節(jié)點中記錄當(dāng)前從節(jié)點的指針，從而建立了 Web頁面與其附屬文件的關(guān)聯(lián)關(guān)系。在步驟308中，Web代理設(shè)備向客戶端A返回針對附屬文件的應(yīng)答報文。在步驟309中，客戶端A接收步驟308中Web代理設(shè)備返回的應(yīng)答報 文，沖艮據(jù)收到的主文件以及附屬文件顯示所請求的Web頁面。此時，客戶端A實現(xiàn)了對Web頁面的訪問，同時在Web代理設(shè)備也緩 存了顯示W(wǎng)eb頁面所需的主文件、附屬文件，并且還記錄了 Web頁面與內(nèi) 嵌附屬文件之間的關(guān)聯(lián)關(guān)系。在圖3所示的流程中，主要介紹的是依據(jù)應(yīng)答報文應(yīng)答頭包含的文件類 型字段來判斷對應(yīng)的Http請求報文所針對的文件類型。這種判斷方式既適 用于TCP常連接的情況，也適用于一個請求一個TCP連接的情況。但是， 在使用TCP常連接時，瀏覽器會首先建立一條TCP連接，發(fā)送對Web主頁 面的請求，在收到響應(yīng)后，并不斷開這條TCP連接。通過分析Web主頁面， 瀏覽器會從中提取出Web主頁面的附屬文件鏈接。此時，瀏覽器可以使用 剛才未斷開的TCP連接獲取后續(xù)的附屬文件。當(dāng)然，為了加快獲取附屬文 件的速度，瀏覽器還可以再建立多條新的TCP連接，使用多條并發(fā)的TCP 連接同時獲取多個附屬文件。在使用常連接的情況下，對每條新建TCP連接，在收到第 一個Http請 求報文時，使用步驟302中的方法就可以確定該報文是否為針對主文件的請 求。而TCP連接上后續(xù)收到的Http請求報文可以確定為是針對附屬文件的。對應(yīng)本實施例，在使用TCP常連接時，Web代理設(shè)備在收到該連接上的第 一個Http請求報文時，即步驟302中收到的報文，使用步驟302判斷獲得 的報文是對主文件的請求時，就可以設(shè)置主節(jié)點并在主節(jié)點中記錄該Http 請求報文的URL,返回的主文件和相關(guān)信息。同時，當(dāng)Web代理設(shè)備收到 該連接上的后續(xù)的Http請求報文時，即步驟306中收到的報文，就可以設(shè) 置從節(jié)點并在該從節(jié)點中記錄該Http請求報文的URL,查找到所屬的Web 網(wǎng)頁，在Web網(wǎng)頁的主節(jié)點中記錄從節(jié)點的指針，待收到附屬文件的應(yīng)答 報文時，再記錄附屬文件以及附屬文件的校驗信息。當(dāng)Web網(wǎng)頁內(nèi)嵌多個附屬文件，客戶端會依次對附屬文件發(fā)送Http請 求報文，具體的處理與上述介紹的對附屬文件相同，即設(shè)置從節(jié)點并在主節(jié) 點中記錄從節(jié)點的指針，具體處理在此不再贅述。另外，參見圖4，圖4為客戶端B訪問當(dāng)前Web頁面的流程。在該流 程中，Web代理設(shè)備將會根據(jù)附屬文件URL提前對附屬文件進(jìn)行更新，提 高Web頁面的響應(yīng)速度。在步驟401中，客戶端B在需要訪問當(dāng)前Web頁面，向Web代理設(shè)備 發(fā)送的請求主文件的Http請求報文。在步驟402中，Web代理設(shè)備接收Http請求報文，根據(jù)Http請求報文 中攜帶的URL,查找得到本地記錄了該Web頁面，才艮據(jù)該Web頁面對應(yīng)的 校驗信息，確定頁面過期時，向Web服務(wù)器X發(fā)送Http請求報文。此時，Web代理設(shè)備可以根據(jù)該Web頁面是否記錄了關(guān)聯(lián)的附屬文件 的指針，來確定當(dāng)前接收到的Http請求報文是否對針對主文件的。在查找 Web緩存，得到該Web頁面對應(yīng)節(jié)點中記錄了關(guān)聯(lián)附屬文件的指針時，確 定該Http請求才艮文請求的是主文件；在該Web頁面對應(yīng)節(jié)點中未記錄附屬 文件的指針時，確定該Http請求報文請求的是附屬文件。在確定頁面未過期，從緩存中取出所保存的主文件發(fā)送給客戶端。另外， 當(dāng)Web頁面是由Web服務(wù)器動態(tài)生成，Web代理設(shè)備未保存Web頁面的 主文件時，Web代理設(shè)備也需要向Web服務(wù)器X發(fā)送Http請求報文。在步驟403中，Web服務(wù)器向Web代理設(shè)備返回所請求主文件的應(yīng)答 報文。
在步驟404中，Web代理設(shè)備根據(jù)Web服務(wù)器返回的應(yīng)答報文更新主 文件緩存，并根據(jù)當(dāng)前Web頁面的URL查找得到主節(jié)點，根據(jù)其中記錄的 關(guān)聯(lián)關(guān)系得到主文件對應(yīng)的附屬文件，根據(jù)附屬文件的檢驗信息確定需要更 新附屬文件時，根據(jù)記錄的附屬文件的URL，向Web服務(wù)器Y發(fā)送請求附 屬文件的Http請求報文；并向客戶端返回主文件的應(yīng)答報文。
在步驟405中，Web服務(wù)器向Web代理設(shè)備返回請求附屬文件的應(yīng)答 報文。
在步驟406中，Web代理設(shè)備接收應(yīng)答報文，根據(jù)應(yīng)答報文更新附屬文 件的記錄。
具體包括如果返回的是狀態(tài)碼為304的應(yīng)答報文，則只需要更新一下 緩存的刷新時間；如果返回的是新頁面，則用該頁面替換緩存中的內(nèi)容；如 果返回的是404號報文，說明文件已不存在，則刪除緩存中保存的文件，并 更新頁面之間的關(guān)耳關(guān)關(guān)系。
在步驟407中，客戶端B接收返回的應(yīng)答報文，獲得其中攜帶的主文 件，解析主文件獲得Web頁面內(nèi)嵌附屬文件的URL。
在步驟407中，客戶端B根據(jù)獲得的附屬文件的URL，向Web代理設(shè) 備發(fā)送請求附屬文件的Http請求報文。
在步驟408中，Web代理設(shè)備向客戶端B返回自身記錄的Web頁面的 附屬文件。
這里，由于Web代理設(shè)備已經(jīng)提前更新了該Web頁面的附屬文件，因 此在收到Http請求報文，根據(jù)報文中的URL就能夠查找到更新后的附屬文 件，并將更新后的附屬文件返回給客戶端B。
在步驟409中，客戶端B根據(jù)收到的主文件以及附屬文件顯示所請求 的Web頁面。
在本實施例上述方法的介紹中，僅以一個附屬文件為例進(jìn)行了介紹。但是，在實際的過程中， 一個Web頁面中往往內(nèi)嵌了多個附屬文件。對于其 中任何一個附屬文件的處理均可以按照上述方案執(zhí)行。當(dāng)然，在Web代理 設(shè)備需要獲取多個附屬文件時，可以對應(yīng)每個附屬文件建立TCP連接，用 來提高獲取速度；也可以建立TCP常鏈接，在一條連接上傳送多個Http請 求來獲取附屬文件。
另外，在本實施例中，為了有效處理附屬文件的老化問題。在主節(jié)點中， 除了可以記錄各從節(jié)點的指針，還可以對應(yīng)各指針記錄該附屬文件的訪問時 間。在客戶端每訪問到該附屬文件，以及Web代理設(shè)備更新該附屬文件， 均對訪問時間進(jìn)行更新。當(dāng)節(jié)點未被訪問的時間超過一定翁:值時，刪除對應(yīng) 的從節(jié)點，同時刪除該從節(jié)點在主節(jié)點中記錄的指針。
另外，參見圖5，圖5為本發(fā)明實施例所提供的Web代理設(shè)備的結(jié)構(gòu)圖。 該Web代理設(shè)備包括控制單元和緩存單元。其中，所述控制單元，用于記 錄并將Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系保存至所述緩存單 元；收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報文后，根據(jù) 所述緩存單元記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件的URL地址，確 定需要更新所述附屬文件時，根據(jù)所獲得的URL地址訪問Web服務(wù)器更新 所述附屬文件；向客戶端提供更新后的附屬文件；所述緩存單元，用于保存 Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系。
具體地，所述控制單元包括記錄單元和執(zhí)行單元。其中，所述記錄單元， 用于確定收到獲取附屬文件的Http請求報文，從該請求報文的請求頭中查 找得到所述附屬文件所屬的Web頁面，并獲得請求頭中附屬文件的URL地 址，在所述緩存單元中對應(yīng)查找到的Web頁面記錄該附屬文件的URL地址； 所述執(zhí)行單元，用于收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請 求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件的URL地址， 確定需要更新所述附屬文件時，根據(jù)所獲得的URL地址訪問Web服務(wù)器更 新所述附屬文件；向客戶端提供所述Web頁面更新后的附屬文件。
所述記錄單元，用于在確定收到獲取附屬文件的Http請求報文時，接收客戶端發(fā)送的Http請求報文，在其應(yīng)答報文指示返回的文件類型不為主
頁面的情況下，確定所述Http請求報文為獲取附屬文件的Http請求報文； 或者，在使用TCP常連接的情況下，接收的Http請求報文不為所在TCP連 接的第一個Http請求報文時，確定所述Http請求報文為獲取附屬文件的Http 請求報文。
所述記錄單元，用于在查找得到所述附屬文件所屬的Web頁面時，根 據(jù)Http請求頭中的Referer字段查找得到附屬文件所屬的Web頁面。
所述記錄單元，用于對應(yīng)查找到的Web頁面記錄附屬文件的URL地址 時，對應(yīng)Web頁面的URL地址在所述緩存單元中記錄所述附屬文件的URL 地址；相應(yīng)的，所述執(zhí)行單元，用于接收客戶端發(fā)送的Http請求報文，獲 得該Http請求報文的目的URL地址，在所述緩存單元中對應(yīng)該URL地址 記錄了附屬文件的URL地址時，確定收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的 Web頁面的Http請求4艮文。
另外，所述記錄單元，進(jìn)一步用于根據(jù)請求附屬文件的應(yīng)答報文，在所 述緩存單元中對應(yīng)所述附屬文件URL地址記錄附屬文件以及該附屬文件的 校驗信息；所述執(zhí)行單元，用于根據(jù)所述附屬文件的URL地址，從所述緩 存單元中獲得所述附屬文件以及附屬文件的檢驗信息，根據(jù)所述校驗信息確 定當(dāng)前附屬文件過期時，確定需要更新所述Web頁面內(nèi)嵌附屬文件。
所述執(zhí)行單元，用于向客戶端提供所述更新后的附屬文件，接收客戶端 發(fā)送的獲取附屬文件的Http請求報文，根據(jù)收到的Http請求報文向所述客 戶端返回更新后的附屬文件。
本發(fā)明技術(shù)方案所提供的Web代理設(shè)備，即可以作為Web前向代理設(shè) 備，也可以作為Web反向代理設(shè)備。
在本發(fā)明的技術(shù)方案中，主要通過Http請求報文中攜帶的附屬文件的 URL地址，獲得Web頁面與其內(nèi)嵌附屬文件URL的關(guān)聯(lián)關(guān)系，而不是解析 應(yīng)答報文來獲得，因此解決了現(xiàn)有技術(shù)無法解析一些應(yīng)答報文的問題。同時， 由于本發(fā)明的技術(shù)方案利用關(guān)聯(lián)關(guān)系主動更新主文件對應(yīng)的附屬文件，使客戶端能夠直接獲得附屬文件的更新文件，因此有效的提高了 Web頁面的響 應(yīng)速度。
另外，由于客戶端的Web瀏覽器有自己的頁面緩存，在一般情況下并 不需要再次傳輸文件實體，只有在頁面過期需要更新時才會再次傳輸。因此， 本發(fā)明的技術(shù)方案在收到客戶端發(fā)送的附屬文件Http請求報文后，根據(jù)收 到的Http請求報文向所述客戶端返回所述附屬文件的更新文件，相對于現(xiàn) 有技術(shù)主動將更新文件發(fā)送至客戶端的技術(shù)手段來說，節(jié)約了 Web代理設(shè) 備的出口帶寬，減少了不必要的文件傳輸。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本 發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在 本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1、一種更新Web頁面的方法，其特征在于，該方法包括記錄Web頁面與其內(nèi)嵌附屬文件統(tǒng)一資源定位符URL地址的關(guān)聯(lián)關(guān)系；收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的超文本傳輸協(xié)議Http請求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件的URL地址，確定需要更新所述附屬文件時，根據(jù)所獲得的URL地址訪問Web服務(wù)器更新所述附屬文件；向所述客戶端提供所述Web頁面更新后的附屬文件。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述記錄Web頁面與其內(nèi) 嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系包括確定收到獲取附屬文件的Http請求報文，從該請求報文的請求頭中查找得 到所述附屬文件所屬的Web頁面，并獲得請求頭中附屬文件的URL地址；對 應(yīng)查找到的Web頁面記錄該附屬文件的URL地址。
3、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述確定收到獲取附屬文件 的Http請求報文包括接收客戶端發(fā)送的Http請求報文，在其應(yīng)答報文指示返回的文件類型不為 主頁面的情況下，確定所述Http請求報文為獲取附屬文件的Http請求報文；或 者，在使用TCP常連接的情況下，接收的Http請求報文不為所在TCP連接的 第一個Http請求報文時，確定所述Http請求報文為獲取附屬文件的Http請求 報文。
4、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述查找得到所述附屬文件 所屬的Web頁面包括根據(jù)Http請求頭中的Referer字段查找得到附屬文件所屬的Web頁面。
5、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述對應(yīng)查找到的Web頁面記錄附屬文件的URL地址包括對應(yīng)Web頁 面的URL地址記錄所述附屬文件的URL地址；所述收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報文包括接 收客戶端發(fā)送的Http請求報文，獲得該Http請求報文的目的URL地址，在對 應(yīng)該URL地址記錄了附屬文件的URL地址時，確定收到客戶端訪問已記錄關(guān) 聯(lián)關(guān)系的Web頁面的Http請求報文。
6、 根據(jù)權(quán)利要求1至5中任一權(quán)利要求所述的方法，其特征在于， 該方法進(jìn)一步包括根據(jù)請求附屬文件的應(yīng)答報文，對應(yīng)所述附屬文件的URL地址記錄附屬文件以及該附屬文件的校驗信息；所述確定需要更新所述附屬文件包括根據(jù)所述附屬文件的URL地址獲得 附屬文件以及附屬文件的檢驗信息，根據(jù)所述校驗信息確定當(dāng)前附屬文件過期 時，確定需要更新所述Web頁面內(nèi)嵌附屬文件。
7、 根據(jù)權(quán)利要求1至5中任一權(quán)利要求所述的方法，其特征在于，所述向 客戶端提供所述更新后的附屬文件包括接收客戶端發(fā)送的獲取附屬文件的Http請求報文，根據(jù)收到的Http請求報 文向所述客戶端返回更新后的附屬文件。
8、 一種Web代理設(shè)備，其特征在于，該Web代理設(shè)備包括控制單元和緩 存單元；所述控制單元，用于記錄并將Web頁面與其內(nèi)嵌附屬文件統(tǒng)一資源定位符 URL地址的關(guān)聯(lián)關(guān)系保存至所述緩存單元；收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的 Web頁面的超文本傳輸協(xié)議Http請求報文后，根據(jù)所述緩存單元記錄的關(guān)聯(lián)關(guān) 系獲得所述Web頁面附屬文件的URL地址，確定需要更新所述附屬文件時， 根據(jù)所獲得的URL地址訪問Web服務(wù)器更新所述附屬文件；向客戶端提供更 新后的附屬文件；所述緩存單元，用于保存Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系。
9、 根據(jù)權(quán)利要求8所述的Web代理設(shè)備，其特征在于，所述控制單元包 括記錄單元和執(zhí)行單元；所述記錄單元，用于確定收到獲取附屬文件的Http請求報文，從該請求報文的請求頭中查找得到所述附屬文件所屬的Web頁面，并獲得請求頭中附屬文 件的URL地址，在所述纟爰存單元中對應(yīng)查找到的Web頁面記錄該附屬文件的 URL地址；所述執(zhí)行單元，用于收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http 請求報文后，根據(jù)所記錄的關(guān)聯(lián)關(guān)系獲得所述Web頁面附屬文件的URL地址， 確定需要更新所述附屬文件時，根據(jù)所獲得的URL地址訪問Web服務(wù)器更新 所述附屬文件；向客戶端提供所述Web頁面更新后的附屬文件。
10、 根據(jù)權(quán)利要求9所述的Web代理設(shè)備，其特征在于， 所述記錄單元，用于在確定收到獲取附屬文件的Http請求報文時，接收客戶端發(fā)送的Http請求報文，在其應(yīng)答報文指示返回的文件類型不為主頁面的情 況下，確定所述Http請求報文為獲取附屬文件的Http請求報文；或者，在使用 TCP常連接的情況下，接收的Http請求報文不為所在TCP連接的第一個Http 請求報文時，確定所述Http請求報文為獲取附屬文件的Http請求報文。
11、 根據(jù)權(quán)利要求9所述的Web代理設(shè)備，其特征在于， 所述記錄單元，用于在查找得到所述附屬文件所屬的Web頁面時，根據(jù)Http請求頭中的Referer字段查找得到附屬文件所屬的Web頁面。
12、 根據(jù)權(quán)利要求9所述的Web代理設(shè)備，其特征在于， 所述記錄單元，用于對應(yīng)查找到的Web頁面記錄附屬文件的URL地址時，對應(yīng)Web頁面的URL地址在所述緩存單元中記錄所述附屬文件的URL地址；所述執(zhí)行單元，用于接收客戶端發(fā)送的Http請求報文，獲得該Http請求報 文的目的URL地址，在所述緩存單元中對應(yīng)該URL地址記錄了附屬文件的 URL地址時，確定收到客戶端訪問已記錄關(guān)聯(lián)關(guān)系的Web頁面的Http請求報 文。
13、 根據(jù)權(quán)利要求9至12中任一權(quán)利要求所述的Web代理設(shè)備，其特征 在于，所述記錄單元，進(jìn)一步用于根據(jù)請求附屬文件的應(yīng)答報文，在所述緩存單 元中對應(yīng)所述附屬文件URL地址記錄附屬文件以及該附屬文件的校驗信息；所述執(zhí)行單元，用于根據(jù)所述附屬文件的URL地址，從所迷緩存單元中獲 得所述附屬文件以及附屬文件的檢驗信息，根據(jù)所述校驗信息確定當(dāng)前附屬文件過期時，確定需要更新所述Web頁面內(nèi)嵌附屬文件。
14、根據(jù)權(quán)利要求8至12中任一權(quán)利要求所述的Web代理設(shè)備，其特征 在于，所述執(zhí)行單元，用于向客戶端提供所述更新后的附屬文件，接收客戶端發(fā) 送的獲取附屬文件的Http請求報文，根據(jù)收到的Http請求報文向所述客戶端返 回更新后的附屬文件。
全文摘要
本發(fā)明公開了一種更新Web頁面的方法和Web代理設(shè)備。本發(fā)明的技術(shù)方案主要根據(jù)Http請求報文中攜帶的附屬文件的URL地址，記錄Web頁面與其內(nèi)嵌附屬文件URL地址的關(guān)聯(lián)關(guān)系，在收到對Web頁面的Http請求報文時，利用關(guān)聯(lián)關(guān)系主動更新該Web頁面的附屬文件，使客戶端能夠直接獲取更新后的附屬文件，從而提高了整個系統(tǒng)返回Web頁面的響應(yīng)速度。在本發(fā)明的技術(shù)方案中，由于不需要解析應(yīng)答報文中的Web頁面來獲得其中內(nèi)嵌的附屬文件URL地址，因此解決了現(xiàn)有技術(shù)無法通過解析應(yīng)答報文得到附屬文件URL地址的技術(shù)問題。
文檔編號H04L12/56GK101287013SQ200810114078
公開日2008年10月15日 申請日期2008年5月30日 優(yōu)先權(quán)日2008年5月30日
發(fā)明者明 薛 申請人:杭州華三通信技術(shù)有限公司