引言
WWW是互聯(lián)網(wǎng)上最受歡迎的應用之一，其快速增長(cháng)造成網(wǎng)絡(luò )擁塞和服務(wù)器超載，導致客戶(hù)訪(fǎng)問(wèn)延遲增大，WWW服務(wù)質(zhì)量問(wèn)題日益顯現出來(lái)。緩存技術(shù) 被認為是減輕服務(wù)器負載、降低網(wǎng)絡(luò )擁塞、增強WWW可擴展性的有效途徑之一，其基本思想是利用客戶(hù)訪(fǎng)問(wèn)的時(shí)間局部性（Temporal Locality）原理，將客戶(hù)訪(fǎng)問(wèn)過(guò)的內容在Cache中存放一個(gè)副本，當該內容下次被訪(fǎng)問(wèn)時(shí)，不必連接到駐留網(wǎng)站，而是由Cache中保留的副本提 供。
Web內容可以緩存在客戶(hù)端、代理服務(wù)器以及服務(wù)器端。研究表明，緩存技術(shù)可以顯著(zhù)地提高WWW性能[1][2]，它可 以帶來(lái)以下好處：
（1）減少網(wǎng)絡(luò )流量，從而減輕網(wǎng)絡(luò )擁塞；
（2）降低客戶(hù)訪(fǎng)問(wèn)延遲，其主要原因有：①緩存在代理服務(wù)器中的內容，客戶(hù)可以直接從代理獲取而不是從遠程服務(wù)器獲取，從而減小了傳輸延遲；② 沒(méi)有被緩存的內容由于網(wǎng)絡(luò )擁塞及服務(wù)器負載的減輕而可以較快地被客戶(hù)獲??；
（3）由于客戶(hù)的部分請求內容可以從代理處獲取，從而減輕了遠程服務(wù)器負載；
（4）如果由于遠程服務(wù)器故障或網(wǎng)絡(luò )故障造成遠程服務(wù)器無(wú)法響應客戶(hù)請求，客戶(hù)可以從代理中獲取緩存的內容副本，使得WWW服務(wù)的魯棒性 （Robustness）得到了加強。
Web緩存系統也會(huì )帶來(lái)以下問(wèn)題：
（1）客戶(hù)通過(guò)代理獲取的可能是過(guò)時(shí)的內容；
（2）如果發(fā)生緩存失效，客戶(hù)的訪(fǎng)問(wèn)延遲由于額外的代理處理開(kāi)銷(xiāo)而增加。因此在設計Web緩存系統時(shí)，應力求做到Cache命中率最大化和失效 代價(jià)最小化；
（3）代理可能成為瓶頸。因此應為一個(gè)代理設定一個(gè)服務(wù)客戶(hù)數量上限及一個(gè)服務(wù)效率下限，使得一個(gè)代理系統的效率至少同客戶(hù)直接和遠程服務(wù)器相 連的效率一樣。
目前，圍繞Web緩存系統及其最優(yōu)化問(wèn)題已經(jīng)開(kāi)展了廣泛而深入的研究，這些研究工作主要是圍繞代理的作用展開(kāi)的。
2 Web緩存系統的理想特性
一個(gè)理想的Web緩存系統應具有以下特性：
（1）快捷性：緩存系統應該能夠有效地降低客戶(hù)的訪(fǎng)問(wèn)延遲；
（2）魯棒性：魯棒性意味著(zhù)可用性，客戶(hù)希望Web服務(wù)隨時(shí)可用；
（3）透明性：緩存系統對客戶(hù)應是透明的，客戶(hù)得到的結果僅僅是快速的響應和良好的可用性；
（4）可擴展性：Web緩存系統應能夠隨著(zhù)網(wǎng)絡(luò )規模和密度的不斷增長(cháng)而很好地進(jìn)行擴展；
（5）高效性：Web緩存系統給網(wǎng)絡(luò )帶來(lái)的開(kāi)銷(xiāo)越小越好；
（6）適應性：緩存系統能夠適應客戶(hù)請求和網(wǎng)絡(luò )環(huán)境的動(dòng)態(tài)變化，這涉及到緩存管理、緩存路由、代理配置等，對于獲得理想的緩存性能至關(guān)重要；
（7）穩定性：Web緩存系統采用的方案不應給網(wǎng)絡(luò )帶來(lái)不穩定；
（8）負載均衡：一個(gè)理想的緩存方案應能夠將負載均勻地分發(fā)到整個(gè)網(wǎng)絡(luò )，以避免某一個(gè)代理或服務(wù)器成為瓶頸或Hot spot點(diǎn)，而造成系統一部分甚至整個(gè)系統性能下降；
（9）異構處理能力：隨著(zhù)網(wǎng)絡(luò )規模和覆蓋域的不斷增大，網(wǎng)絡(luò )將跨越一系列不同的硬件和軟件體系結構。Web緩存系統應能夠適應不同的網(wǎng)絡(luò )體系結 構；
（10）簡(jiǎn)單性：簡(jiǎn)單的方案容易實(shí)現且易被普遍接受，一個(gè)理想的Web緩存方案配置起來(lái)應簡(jiǎn)單易行。
圍繞上述特性，一個(gè)Web緩存系統必須解決好以下問(wèn)題：
（1）緩存體系結構：緩存代理在網(wǎng)絡(luò )中如何組織和配置；
（2）代理合作：代理間如何合作，相互合作的代理可以提高命中率而改善緩存系統的性能；
（3）緩存路由：當一處緩存代理失效時(shí)，如何將請求向其它緩存代理轉發(fā)；
（4）緩存替換算法：當緩存空間不夠時(shí)，緩存內容如何替換；
（5）緩存一致性：即緩存內容的時(shí)效性問(wèn)題，如何防止緩存的內容過(guò)時(shí)；
（6）內容預?。捍砣绾螞Q定從服務(wù)器或其它代理處進(jìn)行內容預取以減少客戶(hù)的訪(fǎng)問(wèn)延遲；
（7）負載平衡：如何解決網(wǎng)絡(luò )中的“Hot spot”現象；
（8）緩存內容：什么樣的內容可以被緩存。
在設計Web緩存系統時(shí)，必須涉及上述問(wèn)題。
3 Web緩存方案概述
3.1 Web緩存體系結構
一個(gè)Web緩存系統的性能取決于其客戶(hù)群的大小，客戶(hù)群越大，緩存的內容被再次請求的可能性就越高。相互合作的Cache組可能會(huì )提高命中率而 提高緩存系統的性能，因此緩存系統的體系結構應確保代理間能夠有效地進(jìn)行合作。典型的緩存體系結構有以下幾種：層次式、分布式和混合式。
圖1 Web緩存系統體系結構圖
3.1.1 層次式緩存體系結構
Harvest項目[3]首先提出了層次式Web緩存體系結構。在層次式緩存體系結構中，Cache在網(wǎng)絡(luò )呈多級配置， 如圖1（a）所示。為簡(jiǎn)單起見(jiàn)，假定有四級：底層Cache、局域層Cache、區域層Cache、廣域層Cache。底層是客戶(hù)/瀏覽器Cache，當 客戶(hù)端Cache不能滿(mǎn)足客戶(hù)的請求時(shí)，該請求被轉發(fā)到局域層Cache，如果仍然得不到滿(mǎn)足，則該請求被轉發(fā)到區域層Cache直至廣域層Cache。 如果該請求在各級Cache中都得不到滿(mǎn)足，則請求最終被轉發(fā)到服務(wù)器。然后服務(wù)器對該請求的響應自頂向下地發(fā)送給客戶(hù)，在沿途的每一個(gè)中間層Cache 中留下一個(gè)副本。請求相同內容的其它請求則自下而上地進(jìn)行轉發(fā)，直到在某一級Cache中得到滿(mǎn)足。
層次式緩存體系結構帶寬效率高，點(diǎn)擊率較高的Web內容可以快速高效地分布到網(wǎng)絡(luò )中。但該體系結構也存在一些不足[4]：
（1）建立層次式緩存體系結構，緩存服務(wù)器必須配置在網(wǎng)絡(luò )中關(guān)鍵的訪(fǎng)問(wèn)點(diǎn)上，緩存服務(wù)器間需相互合作；
（2）每一級Cache都會(huì )帶來(lái)額外的延遲；
（3）高層Cache可能會(huì )成為瓶頸并帶來(lái)較長(cháng)的排隊延遲；
（4）同一個(gè)內容的多個(gè)副本被保存在不同的Cache中，整個(gè)系統Cache空間利用率不高。
3.1.2 分布式緩存體系結構
針對層次式緩存結構的上述缺陷，一些研究者提出了分布式緩存體系結構，在這種結構中，只有低層Cache,如圖1（b）所示。文獻[5]中 的分布式Web緩存結構中，沒(méi)有超出局域層的中間Cache層，Cache之間相互協(xié)作以處理失效。為了確定將客戶(hù)請求轉發(fā)給哪一個(gè)局域層Cache來(lái)獲 取失效的內容，每一個(gè)局域層Cache保留一份其它局域層Cache中緩存內容的目錄信息，以便發(fā)生失效時(shí)將客戶(hù)請求準確地轉發(fā)到相應的局域層 Cache。緩存陣列路由協(xié)議CARP [6]（Cache Array Routing PRotocol）是一種分布式緩存方案，它將URL空間分割成不同的部分，將每一部分指定給一組松散耦合的Cache組，每個(gè)Cache只能緩存具有指 定給它的URL的Web內容，從而可以根據客戶(hù)請求內容的URL來(lái)確定將請求轉發(fā)給哪一個(gè)Cache。
在分布式緩存結構中，大多數的網(wǎng)絡(luò )流量都發(fā)生在網(wǎng)絡(luò )底層，不容易產(chǎn)生網(wǎng)絡(luò )擁塞，Cache空間利用率高，且可以更好地實(shí)現負載共享，容錯性更 好。然而，一個(gè)大規模的分布式緩存系統的配置可能會(huì )遇到幾個(gè)問(wèn)題：連接次數較多、帶寬要求高、管理困難[4]。
3.1.3 混合式緩存體系結構
混合式體系結構如圖1（c）所示，同級Cache采用分布式緩存結構，相互合作。Harvest集團設計的互聯(lián)網(wǎng)緩存協(xié)議ICP（the Internet Cache Protocol）支持從RTT最小的父Cache或鄰居Cache中獲取相應的內容。
3.1.4 緩存體系結構的優(yōu)化
研究表明[4]層次式緩存體系結構和分布式緩存結構相比，層次式緩存體系結構具有較短的連接時(shí)間，因此將較小的文檔緩存 在中間層Cache中可以減少訪(fǎng)問(wèn)延遲；分布緩存結構具有較短的傳輸時(shí)間和較高的帶寬利用率。理想的方案就是將二者結合起來(lái)，充分發(fā)揮各自的長(cháng)處，同時(shí)減 少連接時(shí)間和傳輸時(shí)間。
3.2 緩存路由
出于對Web緩存系統擴展性的考慮，大多數緩存系統將大量的Cache分散在互聯(lián)網(wǎng)上，這樣帶來(lái)的最大問(wèn)題是如何快速地定位緩存有所需內容的 Cache，這就是緩存路由問(wèn)題。該問(wèn)題有點(diǎn)類(lèi)似于網(wǎng)絡(luò )路由，但卻不能用同樣的方式解決。傳統的網(wǎng)絡(luò )路由可依地址聚類(lèi)（層次式的地址表示使得地址聚類(lèi)成為 可能）而進(jìn)行，但是在WWW中，具有相同URL前綴或服務(wù)器地址前綴的文檔未必發(fā)送給相同的客戶(hù)，難以對路由地址進(jìn)行聚類(lèi)，這樣緩存路由表將大得難以管 理。此外，緩存內容不斷更新，過(guò)時(shí)的緩存路由信息將導致緩存失效。為降低Cache失效的代價(jià)，理想的緩存路由算法應該將客戶(hù)的請求路由到下一個(gè)代理，該 代理具有較高的命中可能性且位于或接近于客戶(hù)到服務(wù)器的網(wǎng)絡(luò )路徑上。
3.2.1 緩存路由表法
Malpani等人[7]將一組Cache組合起來(lái)，當客戶(hù)的請求被轉發(fā)到指定的Cache時(shí)，如果該Cache緩存有 請求的內容，則將其發(fā)送給客戶(hù)，否則通過(guò)ip組播將請求轉發(fā)給同組的其它Cache，由緩存有相應內容的Cache對客戶(hù)的請求進(jìn)行響應，如果所有 Cache中都沒(méi)有緩存請求的內容，則該請求被轉發(fā)到源服務(wù)器。Harvest[3]緩存系統將Cache組織成層次式結構并使用 Cache解析協(xié)議ICP（Internet Cache Protocol），當發(fā)生Cache失效時(shí)，低層Cache在將客戶(hù)請求轉發(fā)到上一層Cache前，首先查詢(xún)兄弟節點(diǎn)Cache是否緩存有相應的內容， 以避免頂層Cache超載。自適應Web緩存系統[8]為每一個(gè)服務(wù)器建立Cache樹(shù)，樹(shù)中的Cache被組織成相互重疊的多點(diǎn) 傳送組，一個(gè)請求通過(guò)這些傳送組來(lái)獲取相應的緩存內容。該方法對每一個(gè)服務(wù)器構造不同的Cache樹(shù)，因此沒(méi)有根結點(diǎn)的超載問(wèn)題，自配置性和魯棒性都比較 好。但是對點(diǎn)擊率較低的內容請求可能會(huì )經(jīng)過(guò)較多的Cache，產(chǎn)生較大的Cache通信開(kāi)銷(xiāo)，作者建議通過(guò)限制請求經(jīng)過(guò)的Cache數來(lái)解決該問(wèn)題。
3.2.2 哈希函數法
Cache陣列路由協(xié)議CARP[6]使用一個(gè)基于陣列成員列表和URL的哈希函數來(lái)確定一個(gè)Web對象確切的緩存地址 或一個(gè)Web對象應緩存在什么地方。在Summary Cache[9]中，每個(gè)代理保存一個(gè)同組中其它代理所緩存內容的URL摘 要信息，該代理在轉發(fā)客戶(hù)請求時(shí)檢查這些摘要信息以確定將請求轉發(fā)給哪一個(gè)代理。為減小開(kāi)銷(xiāo)，這些摘要信息定期進(jìn)行更新。試驗表明該系統可以顯著(zhù)地減少 Cache間的信息數量、帶寬消耗以及協(xié)議帶來(lái)的CPU開(kāi)銷(xiāo)，而保持和ICP幾乎一樣的緩存命中率。
3.3 Cache替換算法
Cache替換算法是影響代理緩存系統性能的一個(gè)重要因素，一個(gè)好的Cache替換算法可以產(chǎn)生較高的命中率。目前已經(jīng)提出的算法可以劃分為以 下三類(lèi)：
（1）傳統替換算法及其直接演化，其代表算法有：①LRU（Least Recently Used）算法：將最近最少使用的內容替換出Cache；②LFU（Lease Frequently Used）算法：將訪(fǎng)問(wèn)次數最少的內容替換出Cache；③Pitkow/Recker[10]提出了一種替換算法：如果 Cache中所有內容都是同一天被緩存的，則將最大的文檔替換出Cache，否則按LRU算法進(jìn)行替換。
（2）基于緩存內容關(guān)鍵特征的替換算法，其代表算法有：①Size[10]替換算法：將最大的內容替換出 Cache；②LRU—MIN[11]替換算法：該算法力圖使被替換的文檔個(gè)數最少。設待緩存文檔的大小為S，對Cache中緩存 的大小至少是S的文檔，根據LRU算法進(jìn)行替換；如果沒(méi)有大小至少為S的對象，則從大小至少為S/2的文檔中按照LRU算法進(jìn)行替換；③LRU— Threshold[11] 替換算法：和LRU算法一致，只是大小超過(guò)一定閾值的文檔不能被緩存；④Lowest Lacency First[12]替換算法：將訪(fǎng)問(wèn)延遲最小的文檔替換出Cache。
（3）基于代價(jià)的替換算法，該類(lèi)算法使用一個(gè)代價(jià)函數對Cache中的對象進(jìn)行評估，最后根據代價(jià)值的大小決定替換對象。其代表算法 有：①Hybrid[12] 算法：算法對Cache中的每一個(gè)對象賦予一個(gè)效用函數，將效用最小的對象替換出Cache；②Lowest Relative Value[13] 算法：將效用值最低的對象替換出Cache；③Least Normalized Cost Replacement（LCNR）[14]算 法：該算法使用一個(gè)關(guān)于文檔訪(fǎng)問(wèn)頻次、傳輸時(shí)間和大小的推理函數來(lái)確定替換文檔；④Bolot等人 [15]提出了一種基于文檔傳 輸時(shí)間代價(jià)、大小、和上次訪(fǎng)問(wèn)時(shí)間的權重推理函數來(lái)確定文檔替換；⑤Size—Adjust LRU（SLRU）[16] 算法：對緩存的對象按代價(jià)與大小的比率進(jìn)行排序，并選取比率最小的對象進(jìn)行替換。
總之，為了使Cache命中率最大化，圍繞Cache替換算法已經(jīng)開(kāi)展了大量的工作，但是替換算法的性能很大程度上取決于WWW訪(fǎng)問(wèn)的特性，還 沒(méi)有哪一種替換算法能夠對所有Web訪(fǎng)問(wèn)模式都優(yōu)于其它算法。
3.4 緩存一致性
Web緩存系統可以減小訪(fǎng)問(wèn)延遲，但帶來(lái)了一個(gè)副作用：緩存的副本提供給客戶(hù)的可能是過(guò)時(shí)的內容，因此必須有一套緩存一致性機制來(lái)確保緩存的內 容能夠及時(shí)進(jìn)行更新及有效性確認，以便為客戶(hù)提供最新的內容。
目前主要有兩種緩存一致性類(lèi)型：強緩存一致性和弱緩存一致性。
3.4.1 強緩存一致性
（1）客戶(hù)端確認：對于每一次訪(fǎng)問(wèn)，代理都認為緩存的內容已經(jīng)過(guò)時(shí)并隨請求發(fā)送一個(gè)“IF—Modified —Since—date”報頭到服務(wù)器。如果在指定的時(shí)間后該內容發(fā)生了變化，則服務(wù)器將更新后的內容發(fā)送給代理并最終發(fā)送給客戶(hù)；如果請求內容未修改， 則發(fā)回 “304”響應，表示文檔未修改，緩存內容繼續有效。
（2）服務(wù)器確認：當服務(wù)器檢測到一個(gè)內容發(fā)生變化時(shí)，服務(wù)器向所有最近請求過(guò)該內容并有可能緩存該內容的客戶(hù)發(fā)送作廢信息[17]。 該方法要求服務(wù)器必須保存一個(gè)訪(fǎng)問(wèn)該內容的客戶(hù)鏈表以便發(fā)送作廢信息，當客戶(hù)數量很大時(shí)，該方法將變得不適用，同時(shí)，該鏈表本身也可能過(guò)時(shí)，造成服務(wù)器向 許多已經(jīng)不再緩存該內容的客戶(hù)發(fā)送作廢信息。
3.4.2 弱緩存一致性
（1）自適應TTL[18] （Time To Live）機制：通過(guò)觀(guān)察一個(gè)文檔的生存期來(lái)調整其生存時(shí)間，從而解決緩存一致性問(wèn)題。如果一個(gè)文檔在一個(gè)相當長(cháng)的時(shí)間內都未修改過(guò)，它往往不會(huì )再發(fā)生變 化。這樣，一個(gè)文檔的生存期屬性被賦予一個(gè)該文檔目前“年齡”（等于目前時(shí)間減去上一次修改的時(shí)間）的百分比。自適應TTL法可以將一個(gè)文檔過(guò)時(shí)的可能性 控制在＜5%的范圍內。大多數的代理服務(wù)器都使用該機制，但是這種基于文檔生存期的緩存一致性機制并不能確保緩存內容的有效性。
（2）捎帶作廢機制
Krishnamurthy等人提出使用捎帶作廢機制來(lái)提高緩存一致性的效率。他們提出了三種機制：①捎帶確認PCV[19]（Piggyback Cache Validation）機制：利用代理發(fā)送給服務(wù)器的請求來(lái)提高緩存一致性。例如，當一個(gè)代理向服務(wù)器發(fā)出請求時(shí)，它捎帶一系列緩存的但可能過(guò)時(shí)的來(lái)自該 服務(wù)器的內容進(jìn)行有效性確認；②捎帶作廢PSI[20]（Piggyback Service Invalidation）機制：其基本思想是當服務(wù)器對代理進(jìn)行響應時(shí)，把一系列上次代理訪(fǎng)問(wèn)后變化的內容告訴代理服務(wù)器并由代理將這些內容作廢，從而 延長(cháng)其它緩存內容在Cache中的緩存時(shí)間；③PSI和PCV混合機制[21]：該機制根據代理上次請求作廢的時(shí)間距當前時(shí)間間隔 的大小來(lái)確定采用何種機制，以實(shí)現最佳的總體性能。如果這個(gè)時(shí)間間隔較小，則使用PSI機制，否則使用PCV機制來(lái)對緩存內容進(jìn)行確認。其基本原理是時(shí)間 間隔越小，與PSI一起發(fā)送的作廢數量就小，但隨著(zhù)時(shí)間的增長(cháng)，發(fā)送作廢的開(kāi)銷(xiāo)將大于請求確認的開(kāi)銷(xiāo)。
3.5 內容預取
Web緩存技術(shù)可以提高Web性能，但研究表明[22]，不管采用何種緩存方案，最大緩存命中率通常不大于 40～50%。為進(jìn)一步提高緩存命中率，引入了預取技術(shù)。預取技術(shù)本質(zhì)上是一種主動(dòng)緩存技術(shù)，其基本思想是在處理客戶(hù)的當前請求時(shí)，利用客戶(hù)訪(fǎng)問(wèn)內容或模 式的先驗知識，對客戶(hù)接下來(lái)的請求內容進(jìn)行預測，并利用客戶(hù)請求的間隙將預測內容緩存在Cache中，從而更好地隱藏延遲，提高服務(wù)質(zhì)量。
早期研究集中在瀏覽器/客戶(hù)與Web服務(wù)器之間進(jìn)行內容預取，當代理被引入后，人們的研究興趣轉到了代理與服務(wù)器之間的預取技術(shù)研究。研究表明 預取技術(shù)可以有效地降低客戶(hù)訪(fǎng)問(wèn)延遲，但預取技術(shù)仍飽受爭議，原因有二：
（1）內容預取是一種實(shí)時(shí)性要求較高的任務(wù)，它主要利用客戶(hù)請求的間隔進(jìn)行，而這個(gè)間隔一般情況下小于一分鐘[23]， 如果在這段時(shí)間內不能完成預取任務(wù)，預取將變得毫無(wú)意義。因此對預取算法的效率有較高的要求。
（2）內容預取是通過(guò)加重服務(wù)器負載及增加網(wǎng)絡(luò )流量為代價(jià)來(lái)降低客戶(hù)端響應時(shí)間的，因此對預取的準確度有較高的要求。同時(shí)，一個(gè)預取模型在確定 預取文檔的數量時(shí)，必須考慮客戶(hù)的訪(fǎng)問(wèn)特性、服務(wù)器負載及網(wǎng)絡(luò )流量狀況，如果拋開(kāi)這些因素來(lái)進(jìn)行預取可能會(huì )造成事與愿違的效果。
總之，一個(gè)良好的預取模型，效率、準確度要高，付出代價(jià)小。圍繞預取的高效性和準確性還需做進(jìn)一步的研究。
3.5 負載平衡
當眾多客戶(hù)同時(shí)從一臺服務(wù)器獲取數據或服務(wù)時(shí)就會(huì )發(fā)生Hot Spot現象，導致服務(wù)器性能下降甚至失效。目前處理該問(wèn)題的方法大多數是使用某些復制策略將被請求的內容分貯在互聯(lián)網(wǎng)上，從而將負載分散到多個(gè)服務(wù)器 （代理）上[24]，避免單個(gè)服務(wù)器成為為瓶頸。
3.6 緩存內容
一個(gè)代理可能發(fā)揮多種作用，除進(jìn)行數據緩存外還可以進(jìn)行連接緩存和計算緩存。連接緩存指在客戶(hù)與代理、代理與服務(wù)器間使用持久連接，來(lái)減少建立 TCP連接開(kāi)銷(xiāo)及服務(wù)器發(fā)送時(shí)的慢起動(dòng)開(kāi)銷(xiāo)，從而減小客戶(hù)訪(fǎng)問(wèn)延遲時(shí)間[25]。計算緩存可以看作是Web服務(wù)器可以將它們的部分 服務(wù)遷移到代理，以減輕服務(wù)器瓶頸，其應用之一就是動(dòng)態(tài)數據緩存，通過(guò)代理來(lái)緩存動(dòng)態(tài)數據并將一部分計算遷移到代理，由代理來(lái)產(chǎn)生和維護緩存的動(dòng)態(tài)數據， 從而提高客戶(hù)獲取動(dòng)態(tài)數據的性能。
4 需要進(jìn)一步研究的問(wèn)題
圍繞Web緩存技術(shù)已經(jīng)開(kāi)展了大量的研究并取得了豐碩成果，但仍有一些問(wèn)題需做進(jìn)一步的研究。這些問(wèn)題包括：
（1）客戶(hù)訪(fǎng)問(wèn)模式研究：通過(guò)研究客戶(hù)的訪(fǎng)問(wèn)模式，從而更好地進(jìn)行緩存管理和內容預取，提高緩存命中率；
（2）動(dòng)態(tài)數據緩存：目前Web緩存命中率不高的一個(gè)重要原因是相當一部分內容（私有數據、授權數據、動(dòng)態(tài)數據等）不能被緩存。如何使得更多的 數據可以緩存以及如何減小客戶(hù)訪(fǎng)問(wèn)非緩存頁(yè)面的訪(fǎng)問(wèn)延遲已經(jīng)成為提高Web性能的關(guān)鍵問(wèn)題；
（3）Web流量特征：緩存系統的效率在于Web訪(fǎng)問(wèn)流的時(shí)間局部性以及良好的Cache管理策略，理解Web客戶(hù)產(chǎn)生的負載特性對于更好地設 計和提供Web服務(wù)具有重要意義；
（4）代理配置：要獲得良好的Web性能，代理的配置至關(guān)重要，代理配置策略的理想標準是：自組織、高效路由、負載均衡、行為穩定等，圍繞此問(wèn) 題還需做進(jìn)一步的研究。
總之，提高Web性能的前沿研究在于開(kāi)發(fā)擴展性、魯棒性、適應性、穩定性好、高效且能夠較好地配置在當前及今后網(wǎng)絡(luò )中的緩存方案。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
