欧美在线观看视频网站,亚洲熟妇色自偷自拍另类,啪啪伊人网,中文字幕第13亚洲另类,中文成人久久久久影院免费观看 ,精品人妻人人做人人爽,亚洲a视频

一種網頁內容預加載方法、裝置及系統的制作方法

文檔序號:6442597閱讀:361來源:國知局
專利名稱:一種網頁內容預加載方法、裝置及系統的制作方法
技術領域
本發(fā)明涉及互聯網領域,尤其涉及一種網頁內容預加載方法、裝置及系統。
背景技術
現在大部分關鍵應用,如電信管理系統、IT服務管理系統、企業(yè)網應用系統為了提供可用性、節(jié)省部署成本,都采用B/S的架構,即瀏覽器和服務器架構。在這種結構下,用戶工作界面(UI,User Interface)是通過Wffff瀏覽器來呈現,而主要事務邏輯在服務器端 (Server)實現,這樣就大大簡化了客戶端負荷,減輕了系統維護與升級的成本和工作量,降低了用戶的總體成本,其中,用戶工作界面又稱為前端,服務器端又稱為后臺。但在當前的網絡管理系統及企業(yè)管理等應用系統中,由于在某些環(huán)節(jié),例如告警數據、采集任務網元數據、采集任務日志等,經常需要進行大量的數據更新,而更新的數據量越大,前端用于從后臺獲取和加載數據的響應時間就越長,從而導致在前端進行操作時,用戶等待的時間較長,用戶體驗差。在現有的基于B/S的架構的應用系統中,一般通過在Web服務器中部署頁面片段緩存(Edge Side Includes,ESI)或者在客戶端部署前端頁面緩存的方式,預先加載大量的網頁數據到緩存中,使瀏覽器不必從Web服務器頻繁讀取數據,從而減少瀏覽器從Web服務器加載數據的時間。采用現有技術方案由于無法確定用戶最可能訪問的數據,因此需要部署大量的緩存空間,從而系統的復雜度和成本大幅提高,難以在實際中大規(guī)模商用,無法有效地解決基于B/S架構的應用系統中部分操作耗時太長的問題。

發(fā)明內容
本發(fā)明實施例提供一種網頁內容預加載方法,基于用戶行為分析實現網頁內容的預加載,減少用戶在基于B/S架構的應用系統中,進行前端操作時的等待時間,提高用戶體驗。本發(fā)明實施例提供一種網頁內容預加載方法,包括響應用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁;分析所述網頁,采集所述網頁的特征元數據;查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;將所述預加載網頁緩存在緩存中;接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是所述用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;如果是,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。
本發(fā)明實施例提供一種網頁內容預加載裝置,包括第一響應單元,用于響應用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁;特征采集單元,用于分析所述網頁,采集所述網頁的特征元數據;策略單元,用于查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;緩存單元,用于將所述預加載網頁緩存在緩存中;第二響應單元,用于接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是所述用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;加載單元,用于當所述緩存中有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。本發(fā)明實施例提供一種建立預加載策略表的方法,包括獲得用戶訪問的多個網頁對應的多個特征元數據;分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄;對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。本發(fā)明一種基于瀏覽器/服務器架構的通信系統,包括瀏覽器和服務器,所述瀏覽器用于,接收包含有網址信息的服務請求,從所述服務器加載與所述服務請求對應的網頁;所述服務器,用于將所述服務請求對應的網頁數據發(fā)送給所述瀏覽器;所述瀏覽器還用于,分析所述網頁,采集所述網頁的特征元數據;查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;將所述預加載網頁緩存在緩存中;接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;如果是,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。本發(fā)明實施例通過以上技術方案,通過采集網頁的特征元數據和查詢預加載策略表來確定用戶下一次最可能訪問的頁面,并在保證用戶正常瀏覽業(yè)務的情況下,提前緩存用戶可能訪問的一下個頁面數據,使得用戶請求下一個頁面時,直接從緩存中讀取數據,克服了用戶在前端進行操作后,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗。


為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領域普通技術人員來講,在不付出創(chuàng)造性勞動性的前提下,還可以根據這些附圖獲得其他的附圖。圖1為本發(fā)明實施例提供的一種網管架構圖;圖2為本發(fā)明實施例提供的基于瀏覽器/服務器架構的通信方法流程圖;圖3為本發(fā)明實施例提供的一種預加載策略表的示意圖;圖4為本發(fā)明實施例提供的網頁內容預加載方法流程圖;圖5為本發(fā)明實施例提供的預加載策略表更新方法流程圖;圖6為本發(fā)明實施例提供的一種網頁內容預加載裝置示意圖;圖7為本發(fā)明實施例提供的基于瀏覽器/服務器架構的通信系統示意圖;圖8為本發(fā)明實施例提供的一種建立預加載策略表的方法流程圖。
具體實施例方式下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例?;诒景l(fā)明中的實施例,本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。為使本領域一般技術人員更好的了解本發(fā)明實施例提供的技術方案,對網頁瀏覽的HTTP (Hyper Text Transfer Protocol,超文本傳輸協議)通信機制做一個簡單的介紹HTTP互聯網上應用最為廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。HTTP協議定義了 Web客戶端如何從Web服務器請求Web頁面,以及服務器如何把Web 頁面?zhèn)魉徒o客戶端,HTTP協議采用了請求/響應模型。在一次完整的網頁瀏覽過程中,Web 瀏覽器與Web服務器之間將遵循HTTP協議完成下列4個步驟(1)建立 TCP 連接;在進行網頁瀏覽之前,Web瀏覽器首先要通過網絡與Web服務器建立連接,該連接是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此 Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議,根據規(guī)則,只有低層協議建立之后才能,才能進行更層協議的連接,因此,首先要建立TCP連接,一般TCP連接的端口號是80;(2) Web瀏覽器向Web服務器發(fā)送網頁請求消息;一旦建立了 TCP連接,Web瀏覽器就會向Web服務器發(fā)送網頁請求消息,網頁請求消息包含請求的方法、URL、協議版本、請求頭部和請求數據。其中,請求方法有GET、 POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT,而網頁瀏覽時一般只用 GET 方法; URL (Uniform Resource Locator,統一資源定位符)也被稱為網頁地址,是因特網上標準的資源的地址;請求頭部由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號“”分隔。 請求頭部通知服務器有關于客戶端請求的信息,典型的請求頭有
User-Agent 產生請求的瀏覽器類型;Accept 客戶端可識別的內容類型列表;Host 請求的主機名,允許多個域名同處一個IP地址,即虛擬主機。請求數據不在GET方法中使用,而是在POST方法中使用。(3) Web服務器接收請求并返回頁面數據;Web服務器解析網頁請求消息,定位請求資源,并將頁面數據寫到TCP套接字,由客戶端讀取。Web服務器返回的頁面數據由狀態(tài)行、響應頭部、空行和響應數據4部分組成。(4)Web瀏覽器根據收到的頁面數據,加載和顯示頁面。實施例一,本發(fā)明實施例一提供一種基于瀏覽器/服務器架構的通信方法,該方法應用于網絡管理系統或企業(yè)網管理系統中,需要說明的是,網絡管理系統,以下簡稱網管,是一個以軟件為主的分布式網絡應用系統,其目的是管理網絡,使網絡高效正常運行; 網管的功能一般分為性能管理,配置管理,安全管理,計費管理和故障管理等五大管理功能;網管管理的對象一般包括路由器,交換機,HUB等;網管的操作主體為網絡管理員。與網管類似,企業(yè)網管理系統也是一個以軟件為主的分布式網絡應用系統,企業(yè)網管理系統與網管的主要區(qū)別就在于,企業(yè)網管理系統的管理對象一般是服務。圖1所示為本發(fā)明實施例提供的一種網管架構圖,根據圖1,客戶端用于響應用戶的操作,客戶端通過網絡與服務器通信耦合,該網絡可以為局域網或互聯網或兩者的組合; 客戶端可以是通用個人計算機,其包括處理器、暫時和永久性存儲設備、輸入/輸出子系統,以及可構成通用個人計算機組件間通信通道的總線,例如以太網接口 ;客戶端還可以為手持設備、機頂終端、手機、PDA等,且多個客戶端可與網絡通信耦合。當位于客戶端的用戶要從服務器獲取數據時,該用戶可以利用瀏覽器,瀏覽器可以安裝在本地客戶端或其遠端。 瀏覽器通過網絡向服務器發(fā)送請求,要求從服務器的數據存儲裝置獲取指定內容,服務器響應瀏覽器的請求,并通過網絡向瀏覽器發(fā)送該指定內容。圖2為本發(fā)明實施例一提供的基于瀏覽器/服務器架構的通信方法的流程圖。參考圖2,本發(fā)明實施例提供的網頁內容加載方法具體包括如下步驟步驟201,瀏覽器接收包含有網址信息的服務請求,并向服務器發(fā)送包含有該網址信息和用戶參數的HTTP請求報文;所述服務請求,可以是用戶直接通過在瀏覽器客戶端輸入網址而發(fā)起的請求,也可以是用戶通過網頁觸發(fā)或設置業(yè)務后,由“應用側”發(fā)起的請求。步驟202,服務器接收瀏覽器發(fā)送的HTTP請求報文,并根據該HTTP請求報文向瀏覽器返回對應的頁面數據;根據之前介紹的網頁瀏覽的HTTP通信機制,服務器在接收到瀏覽器發(fā)送的HTTP 請求報文后,解析該HTTP請求報文,定位請求資源,并將對應的頁面數據寫到TCP套接字, 由瀏覽器讀取。步驟203,瀏覽器接收服務器返回的頁面數據,解析所述頁面數據,并顯示頁面;服務器返回的頁面數據由狀態(tài)行、響應頭部、空行和響應數據4部分組成。具體地,在一個實施例中,瀏覽器接收到服務器返回的頁面數據后,首先解析狀態(tài)行,查看表明請求是否成功的狀態(tài)代碼;然后解析每一個響應頭,響應頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集;最后瀏覽器讀取響應數據HTML,根據HTML的語法對其進行格式化,并在瀏覽器窗口中顯示。步驟204,瀏覽器分析顯示的網頁,采集所述網頁的特征元數據;針對網管的特性,在一個實施例中,用戶特征元數據包括用戶名、網元、功能分類和URL,其中,用戶名具體指當前在網管前端進行操作的管理員的用戶名;網元代表網管前端當前正在對網絡中的哪一種網元進行操作,比如路由器,交換機或者HUB等;功能分類表示當前網管頁面的功能,比如性能管理、配置管理、安全管理、計費管理或故障管理等; URL(Uniform Resource Locator,統一資源定位符)也被稱為網頁地址,是指當前用戶訪問的頁面在服務器中的資源地址。針對企業(yè)網管理系統的特性,在另一個實施例中,用戶特征元數據包括用戶名、 服務、功能分類和URL。用戶名具體指當前在企業(yè)網管理系統前端進行操作的管理員的用戶名;服務具體指企業(yè)網管理系統前端當前正在對哪一種服務進行操作,比如,視頻會議服務、云計算服務等;功能分類表示對當前服務進行何種操作,比如配置、測試等;URL是指當前用戶訪問的頁面在服務器中的資源地址。具體地,這些用戶特征元數據中的一部分,比如用戶名、功能分類包含在頁面數據的響應頭部中,還有一部分數據,比如URL包含在HTTP請求報文中,通過對HTTP報文中的 URL以及HTTP報文對應的響應數據頭部進行解析,可以得到所述用戶特征元數據。步驟205,瀏覽器根據采集的特征元數據,查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上, 后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;需要說明的是,預加載策略表是根據網管中大部分用戶的操作習慣而預先制定的一個URL關聯表,它存儲了用戶當前訪問網頁網頁的特征元數據和所述預加載網頁的對應關系,所述預加載網頁為用戶在訪問完當前網頁后,接下來最有可能訪問或后續(xù)訪問的概率最大的一個或多個網頁。具體地,在一個實施例中,服務器基于概率統計的方法,對多個用戶在前端的多次操作的URL進行統計,對于用戶訪問的每個網頁,統計用戶在訪問該網頁后,接下來最常訪問,即訪問次數最多的一個網頁的URL,該URL即為預加載網頁的URL,將該URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表。當然可以理解的是,在另一個實施例中,預加載網頁可以有多個,具體地,對于用戶訪問的每個網頁,可以統計用戶在訪問該網頁后, 接下來最常訪問,即訪問次數最多的多個網頁的URL,比如3個,將所述多個URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表中。圖3所示為本發(fā)明實施例提供的一種預加載策略表的示意圖。根據圖3,預加載策略表包括兩部分當前訪問的URL和預加載網頁的 URL。在一個實施例中,在進行查詢時,可以將采集的特征元數據中的URL作為鍵(key) 值,采用hash(哈希)索引的方法從預加載策略表查找出與該URL對應的預加載網頁的 URL,然后根據查找出的預加載網頁的URL,從服務器獲取預加載數據。需要說明的是,Hash 索引的方法作為一個具體的查找方式具有迅速查找的優(yōu)勢,能提高匹配速度??梢岳斫獾氖莌ash索引的方法并不是匹配的唯一實現方式,故hash索引的方式作為一個舉例不應理解為對本發(fā)明實施例的限定。
步驟206,瀏覽器將獲取的預加載網頁緩存在緩存中;具體地,這里的緩存,可以是瀏覽器本地的緩存,也可以是與瀏覽器物理或邏輯連接的其他緩存。進一步地,本發(fā)明實施例提供的通信方法還包括步驟207,瀏覽器接收下一個服務請求,判斷所請求頁面數據是否已經預加載到緩存中,如果是,則從緩存中加載所述頁面數據,并顯示頁面。進一步地,為了根據用戶的偏好對預加載策略表進行實時更新,達到最佳的用戶體驗,本發(fā)明實施例提供的通信方法還包括步驟20 ,瀏覽器將采集的用戶特征元數據上傳到服務器,以使服務器根據上傳的用戶特征元數據,更新預加載策略表。本發(fā)明實施例一通過以上技術方案,在網管及企業(yè)網管理系統中,通過采集用戶的特征元數據和查詢預加載策略表來確定用戶下一次最可能訪問的頁面,并在保證用戶正常瀏覽業(yè)務的情況下,提前緩存用戶可能訪問的一下個頁面數據,使得用戶請求下一個頁面時,直接從緩存中讀取數據,克服了網管系統中用戶在前端進行操作后,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗;進一步地,通過對采集的特征元數據進行分析,并基于分析的結果,更新預加載策略表,可以針對用戶的偏好對預加載策略表進行實時更新,達到最佳的用戶體驗?;诒景l(fā)明實施例一的描述,本領域技術人員應當理解,在本發(fā)明實施例一中,主要由瀏覽器來完成了網頁內容的預加載,在實際應用中,這些步驟并不限于用瀏覽器來完成,還可以由瀏覽器之外的另一個實體,例如瀏覽器控件或者模塊來實現,同時,可以理解的是,本發(fā)明實施例提供的技術方案的應用場景并不限于網管或企業(yè)網管理系統,可以擴展到所有采用B/S架構的應用系統,比如因特網網頁的瀏覽中。基于這一思想,本發(fā)明實施例二提供一種網頁內容預加載方法,如圖4所示,本發(fā)明實施例二提供的網頁內容預加載方法包括步驟401,響應用戶的網頁訪問請求,從服務器加載用戶請求訪問的網頁;具體地,根據之前介紹的網頁瀏覽的HTTP通信機制,從服務器加載所述用戶請求訪問的網頁數據的過程為瀏覽器接收到用戶的網頁訪問請求后,向服務器發(fā)送包含有該網址信息的HTTP請求報文,服務器在接收到瀏覽器發(fā)送的HTTP請求報文后,解析該HTTP 請求報文,定位請求資源,并將對應的頁面數據寫到TCP套接字,由瀏覽器讀取。所述網頁訪問請求,可以是用戶直接通過在瀏覽器客戶端輸入網址而發(fā)起的請求,也可以是用戶通過網頁觸發(fā)或設置業(yè)務后,由“應用側”發(fā)起的請求;在一個實施例中, 所述網頁訪問請求還可以包含用戶參數,該用戶參數具體可以包括客戶端設備的屏幕大小、設備支持的顯示格式及設備的計算能力等信息。步驟402,分析用戶請求訪問的網頁,采集該網頁的特征元數據;需要說明的是,服務器返回的網頁數據由狀態(tài)行、響應頭部、空行和響應數據4部分組成。在一個實施例中,網頁的特征元數據可以包括所述網頁的功能和所述網頁的 URL ;其中,網頁的功能可以通過對網頁的URL解析得到,例如,網頁的URL為/news/lady/ default, jsp ? user = abc&refer = http: //www. 163. com/lady,根據斜杠的數量來判斷網頁層次(從URL開頭到問號結束,沒有問號則到空格結束),此處共有3個斜杠,則說明此網頁為第三層網頁;解析斜杠之間的內容,可以獲得關鍵字,比如news、lady,則說明此網頁的類型或功能為女性、新聞。在一個實施例中,針對網管的特性,網頁的特征元數據可以包括用戶名、網元、功能分類和URL,其中,用戶名具體指當前在網管前端進行操作的管理員的用戶名;網元代表網管前端當前正在對網絡中的哪一種網元進行操作,比如路由器,交換機或者HUB等;功能分類表示當前網管頁面的功能,比如性能管理、配置管理、安全管理、計費管理或故障管理等;URL(Uniform Resource Locator,統一資源定位符)也被稱為網頁地址,是指當前用戶訪問的頁面在服務器中的資源地址。針對企業(yè)網管理系統的特性,在另一個實施例中,網頁的特征元數據包括用戶名、服務、功能分類和URL。用戶名具體指當前在企業(yè)網管理系統前端進行操作的管理員的用戶名;服務具體指企業(yè)網管理系統前端當前正在對哪一種服務進行操作,比如,視頻會議服務、云計算服務等;功能分類表示對當前服務進行何種操作,比如配置、測試等;URL是指當前用戶訪問的頁面在服務器中的資源地址。具體地,這些網頁的特征元數據比如用戶名、功能分類包含在頁面數據的響應頭部中,還有一部分數據,比如URL包含在HTTP請求報文中,通過對HTTP報文中的URL以及 HTTP報文對應的響應數據頭部進行解析,可以得到所述網頁的特征元數據。步驟403,查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁; 所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;需要說明的是,所述預加載策略表存儲了所述網頁的特征元數據和所述預加載網頁的對應關系;在一個實施例中,預加載策略表是基于用戶的操作習慣而預先制定的一個 URL關聯表,它存儲了每一個用戶當前訪問網頁的URL和預加載網頁的URL的對應關系,所述預加載網頁為所述用戶在訪問當前網頁的基礎上,后續(xù)訪問的概率最大或者最有可能訪問的一個或多個網頁。具體地,在一個實施例中,可以基于概率統計的方法,對多個用戶在前端的多次操作的URL進行統計,對于每個用戶訪問的每個網頁,統計該用戶在訪問該網頁后,接下來最常訪問,即訪問次數最多的一個網頁的URL,該URL即為預加載網頁的URL,將該URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表。當然可以理解的是,在另一個實施例中,預加載網頁可以有多個,具體地,對于用戶訪問的每個網頁,可以統計用戶在訪問該網頁后,接下來最常訪問,即訪問次數最多的多個網頁的URL,比如3個,將所述多個URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表中。圖3所示為本發(fā)明實施例提供的一種預加載策略表的示意圖。根據圖3,預加載策略表包括兩部分當前訪問的URL和預加載網頁的URL。在一個實施例中,在進行查詢時,可以將采集的特征元數據中的URL作為鍵(key) 值,采用hash(哈希)索引的方法從預加載策略表查找出與該URL對應的預加載網頁的 URL,然后根據查找出的預加載網頁的URL,從服務器獲取預加載數據。需要說明的是,Hash 索引的方法作為一個具體的查找方式具有迅速查找的優(yōu)勢,能提高匹配速度??梢岳斫獾氖莌ash索引的方法并不是匹配的唯一實現方式,故hash索引的方式作為一個舉例不應理解為對本發(fā)明實施例的限定。步驟404,將獲取的預加載網頁緩存在緩存中;具體地,這里的緩存,可以是瀏覽器本地的緩存,也可以是與瀏覽器物理或邏輯連接的其他緩存。步驟405,接收所述用戶的后續(xù)訪問請求,查詢緩存中是否緩存有該訪問請求請求訪問的網頁;所述后續(xù)訪問請求是用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;步驟406,如果是,從緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。進一步地,本發(fā)明實施例提供的通信方法還包括步驟407,如果否,從所述服務器加載用戶請求訪問的網頁。進一步地,為了根據用戶的偏好對預加載策略表進行實時更新,達到最佳的用戶體驗,本發(fā)明實施例提供的通信方法還包括步驟408,根據用戶后續(xù)訪問的網頁的多個特征元數據,更新預加載策略表。在一個實施例中,如圖5所示,根據用戶后續(xù)訪問的網頁的多個特征元數據,更新預加載策略表,具體包括步驟501,獲得所述用戶后續(xù)訪問的網頁的多個特征元數據;步驟502,分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄;步驟503,對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;步驟504,基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;步驟505,建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。在另一個實施例中,根據用戶后續(xù)訪問的網頁的多個特征元數據,更新預加載策略表,也可以通過以下方式服務器每次獲得用戶訪問的網頁的特征元數據之后,根據該特征元數據得到以下邏輯意義網管“用戶”在“網元”的”功能分類”上操作了”URL”企業(yè)網管理系統“用戶”在“服務”的”功能分類”上操作了”URL” ;因此,用戶的每一次操作都可以抽象成以上邏輯意義,根據該邏輯意義,可以將用戶的操作變成以時間為排序的一組操作記錄,在形成預加載策略時,對每個用戶的操作記錄進行排序,將用戶出現最多的幾個操作及出現下一個操作關聯,從而更新預加載策略表。本發(fā)明實施例二通過以上技術方案,通過采集網頁的特征元數據和查詢預加載策略表來確定用戶下一次最可能訪問的頁面,并在保證用戶正常瀏覽業(yè)務的情況下,提前緩存用戶可能訪問的一下個頁面數據,使得用戶請求下一個頁面時,直接從緩存中讀取數據, 克服了用戶在前端進行操作時,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗;進一步地,通過對采集的特征元數據進行分析,并基于分析的結果,更新預加載策略表,可以針對用戶的偏好對預加載策略表進行實時更新,達到最佳的用戶體驗。實施例三,如圖6所示,本發(fā)明實施例三提供一種網頁內容預加載裝置,包括第一響應單元610,用于響應用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁;特征采集單元620,用于分析所述網頁,采集所述網頁的特征元數據;策略單元630,用于獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;緩存單元640,用于將所述預加載網頁緩存在緩存中;第二響應單元650,用于接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;加載單元660,用于當所述緩存中有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。進一步地,在一個實施例中,加載單元660還用于,當所述緩存中沒有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述服務器加載所述后續(xù)網頁訪問請求請求訪問的網頁。需要說明的是,第一響應單元610的具體工作步驟可以參照步驟401,特征采集單元620的具體工作可以參照步驟402,策略單元630的具體工作步驟可以參照步驟403,緩存單元640的具體工作步驟可以參照步驟404,第二響應單元650的具體工作步驟可以參照步驟405,加載單元660的具體工作步驟可以參照步驟406。本發(fā)明實施例三通過以上技術方案,通過采集網頁的特征元數據和查詢預加載策略表來確定用戶下一次最可能訪問的頁面,在保證用戶正常瀏覽業(yè)務的情況下,提前緩存用戶可能訪問的一下個頁面數據,使得用戶請求下一個頁面時,直接從緩存中讀取數據,克服了用戶在前端進行操作時,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗。實施例四,如圖7所示,本發(fā)明實施例四提供一種基于瀏覽器/服務器架構的通信系統,包括瀏覽器、服務器,其中瀏覽器,用于接收用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁, 同時通過分析該頁面信息,采集網頁的特征元數據,基于采集的特征元數據,查詢預加載策略表,獲取與該網頁的特征元數據對應的預加載網頁,并將獲取的預加載網頁緩存到緩存中;進一步地,瀏覽器還用于,接收用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有該后續(xù)網頁訪問請求請求訪問的網頁;如果是,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。所述后續(xù)訪問請求是用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;所述網頁訪問請求,可以是用戶直接通過在瀏覽器客戶端輸入網址而發(fā)起的請求,也可以是用戶通過網頁觸發(fā)或設置業(yè)務后,由“應用側”發(fā)起的請求。服務器,用于將瀏覽器接收的網頁訪問請求對應的網頁數據發(fā)送給瀏覽器。參考圖7,本發(fā)明實施例的通信系統中,瀏覽器主要包括第一接收模塊710、預加載模塊720、第二接收模塊730和加載模塊740。其中,第一接收模塊710,用于接收用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁。需要說明的是,第一接收模塊710根據之前介紹的網頁瀏覽的HTTP通信機制從服務器獲得用戶請求訪問的網頁數據。
預加載模塊720,用于分析第一接收模塊710加載的頁面,采集網頁的特征元數據,并根據采集的特征元數據,通過查詢預加載策略表,獲取用戶下一批可能訪問的頁面數據,最后將獲取的頁面數據緩存。進一步的,所述預加載模塊720具體包括采集單元7201,用于分析第一接收模塊710加載的頁面,采集所述網頁的特征元數據;根據之前介紹的網頁瀏覽的HTTP通信機制,服務器返回的頁面數據由狀態(tài)行、響應頭部、空行和響應數據4部分組成。具體地,在一個實施例中,網頁的特征元數據可以包括所述網頁的功能和所述網頁的URL ;其中,網頁的功能可以通過對網頁的URL解析得到, 例如,網頁的 URL 為 /news/lady/default, jsp ? user = abc&refer = http//www. 163. com/lady,根據斜杠的數量來判斷網頁層次(從URL開頭到問號結束,沒有問號則到空格結束),此處共有3個斜杠,則說明此網頁為第三層網頁;解析斜杠之間的內容,可以獲得關鍵字,比如news、lady,則說明此網頁的類型或功能為女性、新聞。在一個實施例中,針對網管的特性,網頁的特征元數據可以包括用戶名、網元、功能分類和URL,其中,用戶名具體指當前在網管前端進行操作的管理員的用戶名;網元代表網管前端當前正在對網絡中的哪一種網元進行操作,比如路由器,交換機或者HUB等;功能分類表示當前網管頁面的功能,比如性能管理、配置管理、安全管理、計費管理或故障管理等;URL(Uniform Resource Locator,統一資源定位符)也被稱為網頁地址,是指當前用戶訪問的頁面在服務器中的資源地址。針對企業(yè)網管理系統的特性,在另一個實施例中,網頁的特征元數據包括用戶名、服務、功能分類和URL。用戶名具體指當前在企業(yè)網管理系統前端進行操作的管理員的用戶名;服務具體指企業(yè)網管理系統前端當前正在對哪一種服務進行操作,比如,視頻會議服務、云計算服務等;功能分類表示對當前服務進行何種操作,比如配置、測試等;URL是指當前用戶訪問的頁面在服務器中的資源地址。具體地,這些網頁的特征元數據比如用戶名、功能分類包含在頁面數據的響應頭部中,還有一部分數據,比如URL包含在HTTP請求報文中,采集單元7201通過對HTTP報文中的URL以及HTTP報文對應的響應數據頭部進行解析,可以得到所述網頁的特征元數據。查詢單元7202,用于根據采集的特征元數據,查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系;需要說明的是,預加載策略表是根據網管中每個用戶的操作習慣而預先制定的一個URL關聯表,它存儲了用戶當前訪問網頁的URL和預加載網頁的URL的對應關系,所述預加載網頁為用戶在訪問完當前網頁后,接下來最有可能訪問的一個或多個網頁。具體地,在一個實施例中,基于概率統計的方法,對每個用戶在前端的多次操作的 URL進行統計,對于用戶訪問的每個網頁,統計用戶在訪問該網頁后,接下來最常訪問,即訪問次數最多的一個網頁的URL,該URL即為預加載網頁的URL,將該URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表。當然可以理解的是,在另一個實施例中,預加載網頁可以有多個,具體地,對于用戶訪問的每個網頁,可以統計用戶在訪問該網頁后,接下來最常訪問,即訪問次數最多的多個網頁的URL,比如3個,將所述多個URL和用戶當前訪問網頁的URL關聯,并添加到預加載策略表中。圖3所示為本發(fā)明實施例提供的一種預加載策略表的示意圖。根據圖3,預加載策略表包括兩部分當前訪問的URL和預加載網頁的URL。在一個實施例中,在進行查詢時,可以將采集的特征元數據中的URL作為鍵(key) 值,采用hash(哈希)索引的方法從預加載策略表查找出與該URL對應的預加載網頁的 URL,然后根據查找出的預加載網頁的URL,從服務器獲取預加載數據。需要說明的是,Hash 索引的方法作為一個具體的查找方式具有迅速查找的優(yōu)勢,能提高匹配速度。可以理解的是hash索引的方法并不是查找的唯一實現方式,故hash索引的方式作為一個舉例不應理解為對本發(fā)明實施例的限定。存儲單元7203,用于緩存查詢單元7202獲取的預加載網頁;具體地,存儲單元7203可以是瀏覽器本地的緩存,也可以是與瀏覽器物理或邏輯連接的其他緩存。進一步地,為了根據用戶的偏好對預加載策略表進行實時更新,預加載模塊720 還包括上傳單元7204,用于將采集單元7201采集的網頁特征元數據上傳到服務器,以使服務器根據所述網頁的特征元數據,更新所述預加載策略表。相應地,為了對預加載策略表進行定期更新,服務器還用于,根據上傳單元7204 上傳的網頁的特征元數據,更新預加載策略表。具體地,服務器通過以下步驟實現預加載策略表的更新(1)獲得所述用戶后續(xù)訪問的網頁的多個特征元數據;(2)分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄;(3)對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;(4)基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;(5)建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。第二接收模塊730,用于接收用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有該后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的。加載模塊740,用于當所述緩存中有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。進一步地,加載模塊740還用于,當所述緩存中沒有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述服務器加載所述后續(xù)網頁訪問請求請求訪問的網頁。本發(fā)明實施例四提供的基于瀏覽器/服務器架構的通信系統,基于網頁的特征元數據的采集,通過預加載模塊,在保證用戶正常瀏覽業(yè)務的情況下,提前緩存用戶可能訪問的一下個頁面數據,從而使得用戶請求下一個頁面時,直接從緩存中讀取數據,克服了用戶在前端進行操作后,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗;進一步地,通過對采集的特征元數據進行分析,并基于分析的結果, 更新預加載策略表,可以針對用戶的偏好對預加載策略表進行實時更新,達到最佳的用戶體驗。
實施例五,如圖8所示,本發(fā)明實施例五提供一種建立預加載策略表的方法,包括步驟801,獲得用戶訪問的多個網頁對應的多個特征元數據;步驟802,分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄;步驟803,對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;步驟804,基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;步驟805,建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。本發(fā)明實施例五通過以上技術方案,通過統計和分析用戶訪問的網頁的特征元數據,并基于分析的結果,針對用戶的偏好建立預加載策略表,方便后續(xù)訪問該網頁時直接從預加載策略表中獲取預加載網頁。本領域普通技術人員可以理解實現上述實施例方法中的全部或部分流程,是可以通過計算機程序來指令相關的硬件來完成,所述的程序可存儲于一計算機可讀取存儲介質中,該程序在執(zhí)行時,可包括如上述各方法的實施例的流程。其中,所述的存儲介質可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory, ROM)或隨機存儲記憶體(Random Access Memory, RAM)等。最后應說明的是以上實施例僅用以說明本發(fā)明的技術方案,而非對其限制;盡管參照前述實施例對本發(fā)明進行了詳細的說明,本領域的普通技術人員應當理解其依然可以對前述各實施例所記載的技術方案進行修改,或者對其中部分技術特征進行等同替換;而這些修改或者替換,并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的范圍。
權利要求
1.一種網頁內容預加載方法,其特征在于,包括響應用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁; 分析所述網頁,采集所述網頁的特征元數據;查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系; 將所述預加載網頁緩存在緩存中;接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)網頁訪問請求是所述用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;如果是,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。
2.如權利要求1所述的方法,其特征在于,還包括如果否,從所述服務器加載所述后續(xù)網頁訪問請求請求訪問的網頁。
3.如權利要求1或2所述的方法,其特征在于,還包括 獲得所述用戶后續(xù)訪問的網頁的多個特征元數據;分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄; 對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。
4.如權利要求1-3任一項所述的方法,其特征在于,所述緩存,為瀏覽器本地的緩存, 或者與瀏覽器物理或邏輯連接的其他緩存。
5.一種網頁內容預加載裝置,其特征在于,包括第一響應單元,用于響應用戶的網頁訪問請求,從服務器加載所述用戶請求訪問的網頁;特征采集單元,用于分析所述網頁,采集所述網頁的特征元數據; 策略單元,用于查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁; 所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系; 緩存單元,用于將所述預加載網頁緩存在緩存中;第二響應單元,用于接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是所述用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;加載單元,用于當所述緩存中有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。
6.如權利要求5所述的裝置,其特征在于,所述加載單元還用于,當所述緩存中沒有所述后續(xù)網頁訪問請求請求訪問的網頁時,從所述服務器加載所述后續(xù)網頁訪問請求請求訪問的網頁。
7.一種建立預加載策略表的方法,其特征在于,包括 獲得用戶訪問的多個網頁對應的多個特征元數據;分析所述多個特征元數據,得到所述用戶的多次網頁訪問記錄; 對所述用戶的多次網頁訪問記錄按照訪問的時間先后順序排序,得到所述用戶訪問的多個網頁在訪問時間上的關聯關系;基于所述關聯關系,統計得到所述用戶在訪問所述多個網頁中的任一個網頁的基礎上,后續(xù)訪問的概率最大的網頁;建立所述多個網頁中的任一個網頁的統一資源定位符URL和所述后續(xù)訪問的概率最大的網頁的URL之間的關聯關系。
8.如權利要求7所述的方法,其特征在于,所述網頁的特征元數據包括所述網頁的功能和所述網頁的URL。
9.一種基于瀏覽器/服務器架構的通信系統,包括瀏覽器和服務器,其特征在于,所述瀏覽器用于,接收包含有網址信息的服務請求,從所述服務器加載與所述服務請求對應的網頁;所述服務器,用于將所述服務請求對應的網頁數據發(fā)送給所述瀏覽器; 所述瀏覽器還用于,分析所述網頁,采集所述網頁的特征元數據; 查詢預加載策略表,獲取與所述網頁的特征元數據對應的預加載網頁;所述預加載網頁為在所述用戶請求訪問的網頁的基礎上,后續(xù)請求訪問的概率最大的網頁;所述預加載策略表包含有所述網頁的特征元數據和所述預加載網頁的對應關系; 將所述預加載網頁緩存在緩存中;接收所述用戶的后續(xù)網頁訪問請求,查詢緩存中是否緩存有所述后續(xù)網頁訪問請求請求訪問的網頁;所述后續(xù)訪問請求是所述用戶在所述用戶請求訪問的網頁的基礎上發(fā)出的;如果是,從所述緩存中加載所述后續(xù)網頁訪問請求請求訪問的網頁。
10.如權利要求9所述的系統,其特征在于,所述瀏覽器還用于,將采集的網頁的特征元數據上傳到服務器,以使服務器統計網頁的特征元數據,更新所述預加載策略表。
全文摘要
本發(fā)明實施例公開一種網頁內容預加載方法,包括根據用戶當前訪問的網頁信息,采集網頁的特征元數據;根據采集的特征元數據,查詢預加載策略表,獲取預加載數據;將獲取的預加載數據加載到緩存中;相應地,本發(fā)明實施例還公開了一種網頁內容預加載裝置、預加載策略表建立方法及通信系統。通過以上技術方案,在保證用戶正常瀏覽業(yè)務的情況下,緩存模塊提前緩存用戶可能訪問的一下個頁面數據,使得用戶請求下一個頁面時,直接從緩存中讀取數據,克服了網管系統中用戶在前端進行操作后,由于瀏覽器需要從服務器讀取大量數據而造成用戶等待時間過長的問題,提高了用戶的體驗。
文檔編號G06F17/30GK102446222SQ20111043458
公開日2012年5月9日 申請日期2011年12月22日 優(yōu)先權日2011年12月22日
發(fā)明者林文旭 申請人:華為技術有限公司
網友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1
宜宾市| 钦州市| 黎川县| 称多县| 繁昌县| 宿州市| 海门市| 新余市| 富蕴县| 二连浩特市| 哈尔滨市| 阳曲县| 保定市| 襄垣县| 铅山县| 顺义区| 长乐市| 泽州县| 巩义市| 克东县| 喀什市| 博白县| 陕西省| 新晃| 滕州市| 成都市| 大竹县| 黎城县| 梧州市| 来安县| 务川| 德兴市| 昌平区| 南部县| 庆安县| 定远县| 乌拉特后旗| 黔江区| 客服| 桃园县| 黄山市|