Web緩存技術(shù)概述

1、Webg存技術(shù)概述日期：2006-05-31來(lái)源： 作者：字體：大 中 小王世克吳集金士堯摘要WWW是互聯(lián)網(wǎng)上最受歡迎的應(yīng)用之一，其快速增長(zhǎng)導(dǎo)致網(wǎng)絡(luò)擁塞和服務(wù)器超載，緩存技術(shù)被認(rèn)為是減輕服務(wù)器負(fù)載、降低網(wǎng)絡(luò)擁塞，減少客戶(hù)訪問(wèn)延遲的有效途徑之一。本文首先描述了Web緩存系統(tǒng)的基本要素及理想屬性，然后介紹目前圍繞Web緩存技術(shù)已經(jīng)開(kāi)展的研究，最后討論Web緩存技術(shù)需要進(jìn)一步研究的問(wèn)題。關(guān)鍵字WWW緩存技術(shù)代理1引言WWW是互聯(lián)網(wǎng)上最受歡迎的應(yīng)用之一，其快速增長(zhǎng)造成網(wǎng)絡(luò)擁塞和服務(wù)器超載，導(dǎo)致客戶(hù)訪問(wèn)延遲增大，WWW服務(wù)質(zhì)量問(wèn)題日益顯現(xiàn)出來(lái)。緩存技術(shù)被認(rèn)為是減輕服務(wù)器負(fù)載、降低網(wǎng)絡(luò)擁塞、增強(qiáng)WWW可擴(kuò)

2、展性的有效途徑之一，其基本思想是利用客戶(hù)訪問(wèn)的時(shí)間局部性(Temporal Locality )原理，將客戶(hù)訪問(wèn)過(guò)的內(nèi)容在Cache中存放一個(gè)副本，當(dāng)該內(nèi)容下次被訪問(wèn)時(shí)，不必連接到駐留網(wǎng)站，而是由Cache中保留的副本提供。Web內(nèi)容可以緩存在客戶(hù)端、代理服務(wù)器以及服務(wù)器端。研究表明，緩存技術(shù)可以顯著地提高WWW性能，它可以帶來(lái)以下好處：(1)減少網(wǎng)絡(luò)流量，從而減輕網(wǎng)絡(luò)擁塞；(2)降低客戶(hù)訪問(wèn)延遲，其主要原因有：緩存在代理服務(wù)器中的內(nèi)容，客戶(hù)可以直接從代理獲取而不是從遠(yuǎn)程服務(wù)器獲取，從而減小了傳輸延遲； 沒(méi)有被緩存的內(nèi)容由于網(wǎng)絡(luò)擁塞及服務(wù)器負(fù)載的減輕而可以較快地被客戶(hù)獲取；(3)由于客戶(hù)的部分

3、請(qǐng)求內(nèi)容可以從代理處獲取，從而減輕了遠(yuǎn)程服務(wù)器負(fù)載；(4)如果由于遠(yuǎn)程服務(wù)器故障或網(wǎng)絡(luò)故障造成遠(yuǎn)程服務(wù)器無(wú)法響應(yīng)客戶(hù)請(qǐng)求，客戶(hù)可以從代理中獲取緩存的內(nèi)容副本，使得WWW服務(wù)的魯棒性(Robustness )得到了加強(qiáng)。Web緩存系統(tǒng)也會(huì)帶來(lái)以下問(wèn)題：(1)客戶(hù)通過(guò)代理獲取的可能是過(guò)時(shí)的內(nèi)容；(2)如果發(fā)生緩存失效，客戶(hù)的訪問(wèn)延遲由于額外的代理處理開(kāi)銷(xiāo)而增加。因此在設(shè)計(jì)Web緩存系統(tǒng)時(shí)，應(yīng)力求做到Cache命中率最大化和失效代價(jià)最小化；(3)代理可能成為瓶頸。因此應(yīng)為一個(gè)代理設(shè)定一個(gè)服務(wù)客戶(hù)數(shù)量上限及一個(gè)服務(wù)效率下限，使得一個(gè)代理系統(tǒng)的效率至少同客戶(hù)直接和遠(yuǎn)程服務(wù)器相連的效率一樣。目前，圍繞We

4、b緩存系統(tǒng)及其最優(yōu)化問(wèn)題已經(jīng)開(kāi)展了廣泛而深入的研究，這些研究工作主 要是圍繞代理的作用展開(kāi)的。2Web緩存系統(tǒng)的理想特性一個(gè)理想的Web緩存系統(tǒng)應(yīng)具有以下特性：(1)快捷性：緩存系統(tǒng)應(yīng)該能夠有效地降低客戶(hù)的訪問(wèn)延遲；(2)魯棒性：魯棒性意味著可用性，客戶(hù)希望Web服務(wù)隨時(shí)可用；(3)透明性：緩存系統(tǒng)對(duì)客戶(hù)應(yīng)是透明的，客戶(hù)得到的結(jié)果僅僅是快速的響應(yīng)和良好的可 用性；(4)可擴(kuò)展性：Web緩存系統(tǒng)應(yīng)能夠隨著網(wǎng)絡(luò)規(guī)模和密度的不斷增長(zhǎng)而很好地進(jìn)行擴(kuò)展；(5)高效性：Web緩存系統(tǒng)給網(wǎng)絡(luò)帶來(lái)的開(kāi)銷(xiāo)越小越好；(6)適應(yīng)性：緩存系統(tǒng)能夠適應(yīng)客戶(hù)請(qǐng)求和網(wǎng)絡(luò)環(huán)境的動(dòng)態(tài)變化，這涉及到緩存管理、緩存路由、代理配置等

5、，對(duì)于獲得理想的緩存性能至關(guān)重要；(7)穩(wěn)定性：Web緩存系統(tǒng)采用的方案不應(yīng)給網(wǎng)絡(luò)帶來(lái)不穩(wěn)定；(8)負(fù)載均衡：一個(gè)理想的緩存方案應(yīng)能夠?qū)⒇?fù)載均勻地分發(fā)到整個(gè)網(wǎng)絡(luò)，以避免某一個(gè)代理或服務(wù)器成為瓶頸或Hot spot點(diǎn)，而造成系統(tǒng)一部分甚至整個(gè)系統(tǒng)性能下降；(9)異構(gòu)處理能力：隨著網(wǎng)絡(luò)規(guī)模和覆蓋域的不斷增大，網(wǎng)絡(luò)將跨越一系列不同的硬件和軟件體系結(jié)構(gòu)。Web緩存系統(tǒng)應(yīng)能夠適應(yīng)不同的網(wǎng)絡(luò)體系結(jié)構(gòu)；(10 )簡(jiǎn)單性：簡(jiǎn)單的方案容易實(shí)現(xiàn)且易被普遍接受，一個(gè)理想的Web緩存方案配置起來(lái)應(yīng)簡(jiǎn)單易行。圍繞上述特性，一個(gè)Web緩存系統(tǒng)必須解決好以下問(wèn)題：(1)緩存體系結(jié)構(gòu)：緩存代理在網(wǎng)絡(luò)中如何組織和配置；(2)代

6、理合作：代理間如何合作，相互合作的代理可以提高命中率而改善緩存系統(tǒng)的性能；(3)緩存路由：當(dāng)一處緩存代理失效時(shí)，如何將請(qǐng)求向其它緩存代理轉(zhuǎn)發(fā)；(4)緩存替換算法：當(dāng)緩存空間不夠時(shí)，緩存內(nèi)容如何替換；(5)緩存一致性：即緩存內(nèi)容的時(shí)效性問(wèn)題，如何防止緩存的內(nèi)容過(guò)時(shí)；(6)內(nèi)容預(yù)?。捍砣绾螞Q定從服務(wù)器或其它代理處進(jìn)行內(nèi)容預(yù)取以減少客戶(hù)的訪問(wèn)延遲；(7)負(fù)載平衡：如何解決網(wǎng)絡(luò)中的Hotspot現(xiàn)象；(8)緩存內(nèi)容：什么樣的內(nèi)容可以被緩存。在設(shè)計(jì)Web緩存系統(tǒng)時(shí)，必須涉及上述問(wèn)題。3Web緩存方案概述3.1 Web緩存體系結(jié)構(gòu)一個(gè)Web緩存系統(tǒng)的性能取決于其客戶(hù)群的大小，客戶(hù)群越大，緩存的內(nèi)容被再次

7、請(qǐng)求的可能性就越高。相互合作的Cache組可能會(huì)提高命中率而提高緩存系統(tǒng)的性能，因此緩存系統(tǒng)的體系結(jié)構(gòu)應(yīng)確保代理間能夠有效地進(jìn)行合作。典型的緩存體系結(jié)構(gòu)有以下幾種：層次式、分布式和混合式。圖1 Web緩存系統(tǒng)體系結(jié)構(gòu)圖3.1.1層次式緩存體系結(jié)構(gòu)Harvest項(xiàng)目3首先提出了層次式Web緩存體系結(jié)構(gòu)。在層次式緩存體系結(jié)構(gòu)中，Cache在網(wǎng)絡(luò)呈多級(jí)配置，如圖1 (a)所示。為簡(jiǎn)單起見(jiàn)，假定有四級(jí)：底層Cache、局域?qū)覥ache、區(qū)域?qū)覥ache、廣域?qū)覥ache。底層是客戶(hù)/瀏覽器Cache，當(dāng)客戶(hù)端Cache不能 滿(mǎn)足客戶(hù)的請(qǐng)求時(shí)，該請(qǐng)求被轉(zhuǎn)發(fā)到局域?qū)覥ache ,如果仍然得不到滿(mǎn)足，則該請(qǐng)

8、求被轉(zhuǎn)發(fā)到區(qū)域?qū)覥ache直至廣域?qū)覥ache。如果該請(qǐng)求在各級(jí)Cache中都得不到滿(mǎn)足， 則請(qǐng)求 最終被轉(zhuǎn)發(fā)到服務(wù)器。然后服務(wù)器對(duì)該請(qǐng)求的響應(yīng)自頂向下地發(fā)送給客戶(hù)，在沿途的每一個(gè)中間層Cache中留下一個(gè)副本。 請(qǐng)求相同內(nèi)容的其它請(qǐng)求則自下而上地進(jìn)行轉(zhuǎn)發(fā)， 直到在 某一級(jí)Cache中得到滿(mǎn)足。層次式緩存體系結(jié)構(gòu)帶寬效率高，點(diǎn)擊率較高的Web內(nèi)容可以快速高效地分布到網(wǎng)絡(luò)中。但該體系結(jié)構(gòu)也存在一些不足4:(1)建立層次式緩存體系結(jié)構(gòu)，緩存服務(wù)器必須配置在網(wǎng)絡(luò)中關(guān)鍵的訪問(wèn)點(diǎn)上，緩存服務(wù)器間需相互合作；(2)每一級(jí)Cache都會(huì)帶來(lái)額外的延退；(3)高層Cache可能會(huì)成為瓶頸并帶來(lái)較長(zhǎng)的排隊(duì)延退；

9、(4)同一個(gè)內(nèi)容的多個(gè)副本被保存在不同的Cache中，整個(gè)系統(tǒng)Cache空間利用率不高。3.1.2分布式緩存體系結(jié)構(gòu)針對(duì)層次式緩存結(jié)構(gòu)的上述缺陷，一些研究者提出了分布式緩存體系結(jié)構(gòu)，在這種結(jié)構(gòu)中，只有低層Cache,如圖1 (b)所示。文獻(xiàn)5中的分布式Web緩存結(jié)構(gòu)中，沒(méi)有超出局域?qū)有怕×嵛腍TTP: WW/V XLLW CN山眼傘她牽的中間Cache層，Cache之間相互協(xié)作以處理失效。為了確定將客戶(hù)請(qǐng)求轉(zhuǎn)發(fā)給哪一個(gè)局域?qū)覥ache來(lái)獲取失效的內(nèi)容，每一個(gè)局域?qū)覥ache保留一份其它局域?qū)覥ache中緩存內(nèi)容的目錄信息，以便發(fā)生失效時(shí)將客戶(hù)請(qǐng)求準(zhǔn)確地轉(zhuǎn)發(fā)到相應(yīng)的局域?qū)覥ache。緩存陣列路由

10、協(xié)議CARP6(Cache Array Routing protocol )是一種分布式緩存方案，它將UR L空間分割成不同的部分，將每一部分指定給一組松散耦合的Cache組，每個(gè)Cache只能緩存具有指定給它的URL的Web內(nèi)容，從而可以根據(jù)客戶(hù)請(qǐng)求內(nèi)容的URL來(lái)確定將請(qǐng)求轉(zhuǎn)發(fā)給哪一個(gè)Cache。在分布式緩存結(jié)構(gòu)中，大多數(shù)的網(wǎng)絡(luò)流量都發(fā)生在網(wǎng)絡(luò)底層，不容易產(chǎn)生網(wǎng)絡(luò)擁塞，Cache空間利用率高，且可以更好地實(shí)現(xiàn)負(fù)載共享，容錯(cuò)性更好。然而，一個(gè)大規(guī)模的分布式緩 存系統(tǒng)的配置可能會(huì)遇到幾個(gè)問(wèn)題：連接次數(shù)較多、帶寬要求高、管理困難4。3.1.3混合式緩存體系結(jié)構(gòu)混合式體系結(jié)構(gòu)如圖1 (c)所示，同級(jí)

11、Cache采用分布式緩存結(jié)構(gòu)，相互合作。Harvest集團(tuán)設(shè)計(jì)的互聯(lián)網(wǎng)緩存協(xié)議ICP (the Internet Cache Protocol )支持從RTT最小的父Cache或鄰居Cache中獲取相應(yīng)的內(nèi)容。3.1.4緩存體系結(jié)構(gòu)的優(yōu)化研究表明4層次式緩存體系結(jié)構(gòu)和分布式緩存結(jié)構(gòu)相比，層次式緩存體系結(jié)構(gòu)具有較短的連接時(shí)間，因此將較小的文檔緩存在中間層Cache中可以減少訪問(wèn)延遲；分布緩存結(jié)構(gòu)具有較短的傳輸時(shí)間和較高的帶寬利用率。理想的方案就是將二者結(jié)合起來(lái)，充分發(fā)揮各自的長(zhǎng)處，同時(shí)減少連接時(shí)間和傳輸時(shí)間。3.2緩存路由出于對(duì)Web緩存系統(tǒng)擴(kuò)展性的考慮，大多數(shù)緩存系統(tǒng)將大量的Cache分散在互

12、聯(lián)網(wǎng)上，這樣帶來(lái)的最大問(wèn)題是如何快速地定位緩存有所需內(nèi)容的Cache ,這就是緩存路由問(wèn)題。該問(wèn)題有點(diǎn)類(lèi)似于網(wǎng)絡(luò)路由，但卻不能用同樣的方式解決。傳統(tǒng)的網(wǎng)絡(luò)路由可依地址聚類(lèi)(層 次式的地址表示使得地址聚類(lèi)成為可能)而進(jìn)行，但是在WWW中，具有相同URL前綴或 服務(wù)器地址前綴的文檔未必發(fā)送給相同的客戶(hù)，難以對(duì)路由地址進(jìn)行聚類(lèi)，這樣緩存路由表將大得難以管理。此外， 緩存內(nèi)容不斷更新，過(guò)時(shí)的緩存路由信息將導(dǎo)致緩存失效。為降低Cache失效的代價(jià)，理想的緩存路由算法應(yīng)該將客戶(hù)的請(qǐng)求路由到下一個(gè)代理，該代理具 有較高的命中可能性且位于或接近于客戶(hù)到服務(wù)器的網(wǎng)絡(luò)路徑上。3.2.1緩存路由表法Malpani等

13、人7將一組Cache組合起來(lái)，當(dāng)客戶(hù)的請(qǐng)求被轉(zhuǎn)發(fā)到指定的Cache時(shí)，如果該Cache緩存有請(qǐng)求的內(nèi)容，則將其發(fā)送給客戶(hù)，否則通過(guò)IP組播將請(qǐng)求轉(zhuǎn)發(fā)給同組的其它Cache，由緩存有相應(yīng)內(nèi)容的Cache對(duì)客戶(hù)的請(qǐng)求進(jìn)行響應(yīng)，如果所有Cache中都沒(méi)有緩 存請(qǐng)求的內(nèi)容，則該請(qǐng)求被轉(zhuǎn)發(fā)到源服務(wù)器。Harvest3緩存系統(tǒng)將Cache組織成層次式結(jié) 構(gòu)并使用 Cache 解析協(xié)議 ICP (Internet Cache Protocol )，當(dāng)發(fā)生 Cache 失效時(shí)，低層Cache在將客戶(hù)請(qǐng)求轉(zhuǎn)發(fā)到上一層Cache前，首先查詢(xún)兄弟節(jié)點(diǎn)Cache是否緩存有相應(yīng)的內(nèi)容，以避免頂層Cache超載。自適應(yīng)W

14、eb緩存系統(tǒng)8為每一個(gè)服務(wù)器建立Cache樹(shù)，樹(shù)中的Cache被組織成相互重疊的多點(diǎn)傳送組，一個(gè)請(qǐng)求通過(guò)這些傳送組來(lái)獲取相應(yīng)的緩 存內(nèi)容。該方法對(duì)每一個(gè)服務(wù)器構(gòu)造不同的Cache樹(shù)，因此沒(méi)有根結(jié)點(diǎn)的超載問(wèn)題，自配置性和魯棒性都比較好。但是對(duì)點(diǎn)擊率較低的內(nèi)容請(qǐng)求可能會(huì)經(jīng)過(guò)較多的Cache ,產(chǎn)生較大的Cache通信開(kāi)銷(xiāo)，作者建議通過(guò)限制請(qǐng)求經(jīng)過(guò)的Cache數(shù)來(lái)解決該問(wèn)題。3.2.2哈希函數(shù)法Cache陣列路由協(xié)議CARP6使用一個(gè)基于陣列成員列表和URL的哈希函數(shù)來(lái)確定一個(gè)Web對(duì)象確切的緩存地址或一個(gè)Web對(duì)象應(yīng)緩存在什么地方。在Summary Cache9中，每個(gè)代理保存一個(gè)同組中其它代理所

15、緩存內(nèi)容的URL摘要信息，該代理在轉(zhuǎn)發(fā)客戶(hù)請(qǐng)求時(shí)檢查這些摘要信息以確定將請(qǐng)求轉(zhuǎn)發(fā)給哪一個(gè)代理。為減小開(kāi)銷(xiāo)，這些摘要信息定期進(jìn)行更新。試驗(yàn)表明該系統(tǒng)可以顯著地減少Cache間的信息數(shù)量、帶寬消耗以及協(xié)議帶來(lái)的CPU開(kāi)銷(xiāo)，而保持和ICP幾乎一樣的緩存命中率。3.3 Cache替換算法Cache替換算法是影響代理緩存系統(tǒng)性能的一個(gè)重要因素，一個(gè)好的Cache替換算法可以產(chǎn)生較高的命中率。目前已經(jīng)提出的算法可以劃分為以下三類(lèi)：(1)傳統(tǒng)替換算法及其直接演化，其代表算法有：LRU ( Least Recently Used)算法：將最近最少使用的內(nèi)容替換出Cache ;LFU ( Lease Frequ

16、ently Used )算法：將訪問(wèn)次 數(shù)最少的內(nèi)容替換出Cache ;Pitkow/Recker10提出了一種替換算法： 如果Cache中所有 內(nèi)容都是同一天被緩存的，則將最大的文檔替換出Cache，否則按LRU算法進(jìn)行替換。(2)基于緩存內(nèi)容關(guān)鍵特征的替換算法，其代表算法有：Size10替換算法：將最大的內(nèi)容替換出Cache ;LRU MIN11替換算法：該算法力圖使被替換的文檔個(gè)數(shù)最少。設(shè)待 緩存文檔的大小為S,對(duì)Cache中緩存的大小至少是S的文檔，根據(jù)LRU算法進(jìn)行替換； 如果沒(méi)有大小至少為S的對(duì)象，則從大小至少為S/2的文檔中按照LRU算法進(jìn)行替換；LRU Threshold11替

17、換算法： 和LRU算法一致， 只是大小超過(guò)一定閾值的文檔不能被緩 存； LowestLacency First12替換算法：將訪問(wèn)延遲最小的文檔替換出Cache。(3)基于代價(jià)的替換算法， 該類(lèi)算法使用一個(gè)代價(jià)函數(shù)對(duì)Cache中的對(duì)象進(jìn)行評(píng)估， 最后 根據(jù)代價(jià)值的大小決定替換對(duì)象。其代表算法有：Hybrid12算法：算法對(duì)Cache中的每 一個(gè)對(duì)象賦予一個(gè)效用函數(shù)， 將效用最小的對(duì)象替換出Cache :Lowest Relative Value1 3算法：將效用值最低的對(duì)象替換出Cache ;Least Normalized Cost Replacement (L CNR )14算法：該算法使

18、用一個(gè)關(guān)于文檔訪問(wèn)頻次、傳輸時(shí)間和大小的推理函數(shù)來(lái)確定替換文檔；Bolot等人15提出了一種基于文檔傳輸時(shí)間代價(jià)、大小、和上次訪問(wèn)時(shí)間的權(quán)重推理函數(shù)來(lái)確定文檔替換；Size Adjust LRU (SLRU )16算法：對(duì)緩存的對(duì)象按代價(jià) 與大小的比率進(jìn)行排序，并選取比率最小的對(duì)象進(jìn)行替換。總之，為了使Cache命中率最大化，圍繞Cache替換算法已經(jīng)開(kāi)展了大量的工作，但是替 換算法的性能很大程度上取決于WWW訪問(wèn)的特性，還沒(méi)有哪一種替換算法能夠?qū)λ蠾eb訪問(wèn)模式都優(yōu)于其它算法。3.4緩存一致性Web緩存系統(tǒng)可以減小訪問(wèn)延遲，但帶來(lái)了一個(gè)副作用：緩存的副本提供給客戶(hù)的可能是 過(guò)時(shí)的內(nèi)容，因此

19、必須有一套緩存一致性機(jī)制來(lái)確保緩存的內(nèi)容能夠及時(shí)進(jìn)行更新及有效性 確認(rèn)，以便為客戶(hù)提供最新的內(nèi)容。目前主要有兩種緩存一致性類(lèi)型：強(qiáng)緩存一致性和弱緩存一致性。3.4.1強(qiáng)緩存一致性(1)客戶(hù)端確認(rèn)：對(duì)于每一次訪問(wèn)，代理都認(rèn)為緩存的內(nèi)容已經(jīng)過(guò)時(shí)并隨請(qǐng)求發(fā)送一個(gè)“F Modified Since date服頭到服務(wù)器。如果在指定的時(shí)間后該內(nèi)容發(fā)生了變化，貝U服務(wù)器將更新后的內(nèi)容發(fā)送給代理并最終發(fā)送給客戶(hù)；如果請(qǐng)求內(nèi)容未修改，則發(fā)回“304”響應(yīng)，表示文檔未修改，緩存內(nèi)容繼續(xù)有效。(2)服務(wù)器確認(rèn)：當(dāng)服務(wù)器檢測(cè)到一個(gè)內(nèi)容發(fā)生變化時(shí)，服務(wù)器向所有最近請(qǐng)求過(guò)該內(nèi)容并有可能緩存該內(nèi)容的客戶(hù)發(fā)送作廢信息17。

20、該方法要求服務(wù)器必須保存一個(gè)訪問(wèn)該內(nèi)容的客戶(hù)鏈表以便發(fā)送作廢信息，當(dāng)客戶(hù)數(shù)量很大時(shí)，該方法將變得不適用，同時(shí)，該鏈表本身也可能過(guò)時(shí)，造成服務(wù)器向許多已經(jīng)不再緩存該內(nèi)容的客戶(hù)發(fā)送作廢信息。3.4.2弱緩存一致性(1)自適應(yīng)TTL18(Time To Live)機(jī)制：通過(guò)觀察一個(gè)文檔的生存期來(lái)調(diào)整其生存時(shí)間，從而解決緩存一致性問(wèn)題。如果一個(gè)文檔在一個(gè)相當(dāng)長(zhǎng)的時(shí)間內(nèi)都未修改過(guò)，它往往不會(huì)再發(fā)生變化。這樣，一個(gè)文檔的生存期屬性被賦予一個(gè)該文檔目前年齡”(等于目前時(shí)間減去上一次修改的時(shí)間)的百分比。自適應(yīng)TTL法可以將一個(gè)文檔過(guò)時(shí)的可能性控制在 v5%的范圍內(nèi)。大多數(shù)的代理服務(wù)器都使用該機(jī)制，但是這種基

21、于文檔生存期的緩存一致性機(jī)制并不能確保緩存內(nèi)容的有效性。(2)捎帶作廢機(jī)制Krishnamurthy等人提出使用捎帶作廢機(jī)制來(lái)提高緩存一致性的效率。他們提出了三種機(jī) 制：捎帶確認(rèn)PCV19(Piggyback Cache Validation )機(jī)制：利用代理發(fā)送給服務(wù)器的 請(qǐng)求來(lái)提高緩存一致性。例如，當(dāng)一個(gè)代理向服務(wù)器發(fā)出請(qǐng)求時(shí)，它捎帶一系列緩存的但可能過(guò)時(shí)的來(lái)自該服務(wù)器的內(nèi)容進(jìn)行有效性確認(rèn)；捎帶作廢PSI20(Piggyback Service Invalidation )機(jī)制：其基本思想是當(dāng)服務(wù)器對(duì)代理進(jìn)行響應(yīng)時(shí)，把一系列上次代理訪問(wèn)后變 化的內(nèi)容告訴代理服務(wù)器并由代理將這些內(nèi)容作廢，從

22、而延長(zhǎng)其它緩存內(nèi)容在Cache中的緩存時(shí)間；PSI和PCV混合機(jī)制21:該機(jī)制根據(jù)代理上次請(qǐng)求作廢的時(shí)間距當(dāng)前時(shí)間間隔的大小來(lái)確定采用何種機(jī)制， 以實(shí)現(xiàn)最佳的總體性能。 如果這個(gè)時(shí)間間隔較小， 則使用P SI機(jī)制，否則使用PCV機(jī)制來(lái)對(duì)緩存內(nèi)容進(jìn)行確認(rèn)。其基本原理是時(shí)間間隔越小，與PSI一起發(fā)送的作廢數(shù)量就小，但隨著時(shí)間的增長(zhǎng)，發(fā)送作廢的開(kāi)銷(xiāo)將大于請(qǐng)求確認(rèn)的開(kāi)銷(xiāo)。3.5內(nèi)容預(yù)取Web緩存技術(shù)可以提高Web性能，但研究表明22,不管采用何種緩存方案，最大緩存命中率通常不大于4050%。為進(jìn)一步提高緩存命中率，引入了預(yù)取技術(shù)。預(yù)取技術(shù)本質(zhì)上是 一種主動(dòng)緩存技術(shù)，其基本思想是在處理客戶(hù)的當(dāng)前請(qǐng)求時(shí)，

23、利用客戶(hù)訪問(wèn)內(nèi)容或模式的先驗(yàn)知識(shí)，對(duì)客戶(hù)接下來(lái)的請(qǐng)求內(nèi)容進(jìn)行預(yù)測(cè)，并利用客戶(hù)請(qǐng)求的間隙將預(yù)測(cè)內(nèi)容緩存在Cache中，從而更好地隱藏延遲，提高服務(wù)質(zhì)量。早期研究集中在瀏覽器/客戶(hù)與Web服務(wù)器之間進(jìn)行內(nèi)容預(yù)取，當(dāng)代理被引入后，人們的研 究興趣轉(zhuǎn)到了代理與服務(wù)器之間的預(yù)取技術(shù)研究。研究表明預(yù)取技術(shù)可以有效地降低客戶(hù)訪問(wèn)延遲，但預(yù)取技術(shù)仍飽受爭(zhēng)議，原因有二：(1)內(nèi)容預(yù)取是一種實(shí)時(shí)性要求較高的任務(wù)，它主要利用客戶(hù)請(qǐng)求的間隔進(jìn)行，而這個(gè)間 隔一般情況下小于一分鐘23,如果在這段時(shí)間內(nèi)不能完成預(yù)取任務(wù)，預(yù)取將變得毫無(wú)意義。 因此對(duì)預(yù)取算法的效率有較高的要求。(2)內(nèi)容預(yù)取是通過(guò)加重服務(wù)器負(fù)載及增加網(wǎng)絡(luò)流

24、量為代價(jià)來(lái)降低客戶(hù)端響應(yīng)時(shí)間的，因此對(duì)預(yù)取的準(zhǔn)確度有較高的要求。同時(shí)，一個(gè)預(yù)取模型在確定預(yù)取文檔的數(shù)量時(shí)，必須考慮客戶(hù)的訪問(wèn)特性、服務(wù)器負(fù)載及網(wǎng)絡(luò)流量狀況，如果拋開(kāi)這些因素來(lái)進(jìn)行預(yù)取可能會(huì)造成事與愿違的效果。總之，一個(gè)良好的預(yù)取模型，效率、準(zhǔn)確度要高，付出代價(jià)小。圍繞預(yù)取的高效性和準(zhǔn)確性還需做進(jìn)一步的研究。3.5負(fù)載平衡當(dāng)眾多客戶(hù)同時(shí)從一臺(tái)服務(wù)器獲取數(shù)據(jù)或服務(wù)時(shí)就會(huì)發(fā)生Hot Spot現(xiàn)象，導(dǎo)致服務(wù)器性能下降甚至失效。目前處理該問(wèn)題的方法大多數(shù)是使用某些復(fù)制策略將被請(qǐng)求的內(nèi)容分貯在互 聯(lián)網(wǎng)上，從而將負(fù)載分散到多個(gè)服務(wù)器(代理)上24,避免單個(gè)服務(wù)器成為為瓶頸。3.6緩存內(nèi)容一個(gè)代理可能發(fā)揮多種

25、作用，除進(jìn)行數(shù)據(jù)緩存外還可以進(jìn)行連接緩存和計(jì)算緩存。連接緩存指在客戶(hù)與代理、代理與服務(wù)器間使用持久連接，來(lái)減少建立TCP連接開(kāi)銷(xiāo)及服務(wù)器發(fā)送時(shí)的慢起動(dòng)開(kāi)銷(xiāo)，從而減小客戶(hù)訪問(wèn)延遲時(shí)間25。計(jì)算緩存可以看作是Web服務(wù)器可以將它們的部分服務(wù)遷移到代理， 以減輕服務(wù)器瓶頸， 其應(yīng)用之一就是動(dòng)態(tài)數(shù)據(jù)緩存，通過(guò)代理來(lái)緩存動(dòng)態(tài)數(shù)據(jù)并將一部分計(jì)算遷移到代理，由代理來(lái)產(chǎn)生和維護(hù)緩存的動(dòng)態(tài)數(shù)據(jù)，從而提高客戶(hù)獲取動(dòng)態(tài)數(shù)據(jù)的性能。4需要進(jìn)一步研究的問(wèn)題圍繞Web緩存技術(shù)已經(jīng)開(kāi)展了大量的研究并取得了豐碩成果，但仍有一些問(wèn)題需做進(jìn)一步的研究。這些問(wèn)題包括：(1)客戶(hù)訪問(wèn)模式研究：通過(guò)研究客戶(hù)的訪問(wèn)模式， 從而更好地進(jìn)行

26、緩存管理和內(nèi)容預(yù)取，提高緩存命中率；(2)動(dòng)態(tài)數(shù)據(jù)緩存：目前Web緩存命中率不高的一個(gè)重要原因是相當(dāng)一部分內(nèi)容(私有數(shù)據(jù)、授權(quán)數(shù)據(jù)、動(dòng)態(tài)數(shù)據(jù)等)不能被緩存。如何使得更多的數(shù)據(jù)可以緩存以及如何減小客 戶(hù)訪問(wèn)非緩存頁(yè)面的訪問(wèn)延遲已經(jīng)成為提高Web性能的關(guān)鍵問(wèn)題；(3)Web流量特征：緩存系統(tǒng)的效率在于Web訪問(wèn)流的時(shí)間局部性以及良好的Cache管理策略，理解Web客戶(hù)產(chǎn)生的負(fù)載特性對(duì)于更好地設(shè)計(jì)和提供Web服務(wù)具有重要意義；(4)代理配置：要獲得良好的Web性能，代理的配置至關(guān)重要，代理配置策略的理想標(biāo) 準(zhǔn)是：自組織、高效路由、負(fù)載均衡、行為穩(wěn)定等，圍繞此問(wèn)題還需做進(jìn)一步的研究?？傊?，提高Web性

27、能的前沿研究在于開(kāi)發(fā)擴(kuò)展性、魯棒性、適應(yīng)性、穩(wěn)定性好、高效且能 夠較好地配置在當(dāng)前及今后網(wǎng)絡(luò)中的緩存方案。參考文獻(xiàn)1R. Caceres, F. Douglis, A. Feldmann, G. Glass, and M. Rabinovich, Web proxy caching: thedevil is in the details, ACM Performance Evaluation Review, 26(3): pp. 11-15, December 1998.2B. M. Duska, D. Marwood, and M. J. Feelay, The measured acces

28、s chara cteristics of WorldWide Web client proxy caches, Proceedings of USENIX Symposi um on Internet Technologies andSystems (http:/cs.ubc.ca/spider/feeley/wwwap/ww wap.html).3A. Chankhunthod, P. B. Danzig, C. Neerdaels, M. F. Schwartz, and K. J. Worrel, Ahierarchical Internet object cache, Usenix

29、96,January 1996.4P. Rodriguez, C. Spanner, and E. W. Biersack, Web caching architectures:hierarchical and distributed caching, Proceedings of WCW99.5R. Tewari, M. Dahlin, H. Vin, and J. Kay, Beyond hierarchies: design con siderations fordistributed caching on the Internet, Technical Report TR98-04,

30、Depar tment of Computer Science,University of Texas at Austin, February 1998.6V. Valloppillil and K. W. Ross, Cache array routing protocol v1.0, Internet Draft _ draft-vinod-carp-v1-03.txt7R. Malpani, J. Lorch, and D. Berger, Making World Wide Web caching se rvers cooperate,Proceedings of the 4th In

31、ternational WWW Conference, Boston, M A, Dec. 19958E. Cohen, B. Krishnamurthy, and J. Rexford, Evaluating server-assisted ca che replacement inthe Web, Proceedings of the European Symposium on Algorith ms-98, 1998.9L. Fan, P. Cao, J. Almeida, and A. Z. Broder, Summary cache: a scalabl e wide- area W

32、ebcache sharing protocol, Proceedings of Sigcomm 98.10S. Williams, M. Abrams, C. R. Standridge, G. Abdulla, and E. A. Fox, Re moval policies innetwork caches for World-Wide Web documents, Proceedings of Sigcomm 96.11M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox, Cac hing proxie

33、s:limitations and potentials, Proceedings of the 4th International WWW Conference, Boston, MA, Dec.1995.12R. P. Wooster and M. Abrams, Proxy caching that estimates page load de lays, Proceedings ofthe 6th International WWW Conference, April 1997 (/ chitra/docs/www6r/).13P. Lorenze

34、tti, L. Rizzo, and L. Vicisano, Replacement policies for a proxy cache .14P. Scheuermann, J. Shim, and R. Vingralek, A case for delay-conscious c aching of Webdocuments, Proceedings of the 6th International WWW Conference, Santa Clara, Apr. 1997.15J. C. Bolot and P. Hoschka, Performance engineering

35、of the World-Wide Web: Application todimensioning and cache design, Proceedings of the 5th Interna tional WWW Conference, Paris, France,May 1996.16C. Aggarwal, J. L. Wolf, and P. S. Yu, Caching on theWorld Wide Web, IEEE Transactions on Knowledge and data Engineering, Vol. 11, No. 1, January/Fe brua

36、ry 1999.17P. Cao and C. Liu, Maintaining strong cache consistency in theWorld Wide Web, Proceedingsof the 17th IEEE International Conference on Distributed Comput ing Systems, May 1997.18V. Cate, Alex - a global file system, Proceedings of the 1992 USENIX File System Workshop,pp. 1-12, May 1992.19B. Krishnamurthy and C. E.Wills, St