Web緩衝技術概述【zz】

 

摘  要  WWW是互連網上最受歡迎的應用之一，其快速增長導致網路擁塞和伺服器超載，緩衝技術被認為是減輕伺服器負載、降低網路擁塞，減少客戶訪問延遲的有效途徑之一。本文首先描述了Web緩衝系統的基本要素及理想屬性，然後介紹目前圍繞Web緩衝技術已經開展的研究，最後討論Web緩衝技術需要進一步研究的問題。關鍵字  WWW  緩衝技術  代理1  引言WWW是互連網上最受歡迎的應用之一，其快速增長造成網路擁塞和伺服器超載，導致客戶訪問延遲增大，WWW服務品質問題日益顯現出來。緩衝技術被認為是減輕伺服器負載、降低網路擁塞、增強WWW可擴充性的有效途徑之一，其基本思想是利用客戶訪問的時間局部性（Temporal Locality）原理，將客戶訪問過的內容在Cache中存放一個副本，當該內容下次被訪問時，不必串連到駐留網站，而是由Cache中保留的副本提供。Web內容可以緩衝在用戶端、Proxy 伺服器以及伺服器端。研究表明，緩衝技術可以顯著地提高WWW效能[1][2]，它可以帶來以下好處：（1）減少網路流量，從而減輕網路擁塞；（2）降低客戶訪問延遲，其主要原因有：①緩衝在Proxy 伺服器中的內容，客戶可以直接從代理擷取而不是從遠程伺服器擷取，從而減小了傳輸延遲；②沒有被緩衝的內容由於網路擁塞及伺服器負載的減輕而可以較快地被客戶擷取；（3）由於客戶的部分請求內容可以從代理處擷取，從而減輕了遠程伺服器負載；（4）如果由於遠程伺服器故障或網路故障造成遠程伺服器無法響應客戶請求，客戶可以從代理中擷取緩衝的內容副本，使得WWW服務的魯棒性（Robustness）得到了加強。Web緩衝系統也會帶來以下問題：（1）客戶通過代理擷取的可能是過時的內容；（2）如果發生緩衝失效，客戶的訪問延遲由於額外的代理處理開銷而增加。因此在設計Web緩衝系統時，應力求做到Cache命中率最大化和失效代價最小化；（3）代理可能成為瓶頸。因此應為一個代理設定一個服務客戶數量上限及一個服務效率下限，使得一個代理系統的效率至少同客戶直接和遠程伺服器相連的效率一樣。目前，圍繞Web緩衝系統及其最佳化問題已經開展了廣泛而深入的研究，這些研究工作主要是圍繞代理的作用展開的。2  Web緩衝系統的理想特性一個理想的Web緩衝系統應具有以下特性：（1）快捷性：緩衝系統應該能夠有效地降低客戶的訪問延遲；（2）魯棒性：魯棒性意味著可用性，客戶希望Web服務隨時可用；（3）透明性：緩衝系統對客戶應是透明的，客戶得到的結果僅僅是快速的響應和良好的可用性；（4）可擴充性：Web緩衝系統應能夠隨著網路規模和密度的不斷增長而很好地進行擴充；（5）高效性：Web緩衝系統給網路帶來的開銷越小越好；（6）適應性：緩衝系統能夠適應客戶請求和網路環境的動態變化，這涉及到緩衝管理、緩衝路由、代理配置等，對於獲得理想的緩衝效能至關重要；（7）穩定性：Web緩衝系統採用的方案不應給網路帶來不穩定；（8）負載平衡：一個理想的緩衝方案應能夠將負載均勻地分發到整個網路，以避免某一個代理或伺服器成為瓶頸或Hot spot點，而造成系統一部分甚至整個系統效能下降；（9）異構處理能力：隨著網路規模和覆蓋域的不斷增大，網路將跨越一系列不同的硬體和軟體體繫結構。Web緩衝系統應能夠適應不同的網路體繫結構；（10）簡單性：簡單的方案容易實現且易被普遍接受，一個理想的Web緩衝方案配置起來應簡單易行。圍繞上述特性，一個Web緩衝系統必須解決好以下問題：（1）緩衝體繫結構：緩衝代理在網路中如何組織和配置； （2）代理合作：代理間如何合作，相互合作的代理可以提高命中率而改善緩衝系統的效能；（3）緩衝路由：當一處緩衝代理失效時，如何將請求向其它緩衝代理轉寄；（4）緩衝替換演算法：當緩衝空間不夠時，緩衝內容如何替換；（5）緩衝一致性：即緩衝內容的時效性問題，如何防止緩衝的內容過時；（6）內容預取：代理如何決定從伺服器或其它代理處進行內容預取以減少客戶的訪問延遲；（7）Server Load Balancer：如何解決網路中的“Hot spot”現象；（8）緩衝內容：什麼樣的內容可以被緩衝。在設計Web緩衝系統時，必須涉及上述問題。3  Web緩衝方案概述3.1  Web緩衝體繫結構一個Web緩衝系統的效能取決於其客戶群的大小，客戶群越大，緩衝的內容被再次請求的可能性就越高。相互合作的Cache組可能會提高命中率而提高緩衝系統的效能，因此緩衝系統的體繫結構應確保代理間能夠有效地進行合作。典型的緩衝體繫結構有以下幾種：層次式、分布式和混合式。圖1 Web緩衝系統體繫結構圖3.1.1 層次式緩衝體繫結構Harvest項目[3]首先提出了層次式Web緩衝體繫結構。在層次式緩衝體繫結構中，Cache在網路呈多級配置，1（a）所示。為簡單起見，假定有四級：底層Cache、局域層Cache、地區層Cache、廣域層Cache。底層是客戶/瀏覽器Cache，當用戶端Cache不能滿足客戶的請求時，該請求被轉寄到局域層Cache，如果仍然得不到滿足，則該請求被轉寄到地區層Cache直至廣域層Cache。如果該請求在各級Cache中都得不到滿足，則請求最終被轉寄到伺服器。然後伺服器對該請求的響應自頂向下地發送給客戶，在沿途的每一個中介層Cache中留下一個副本。請求相同內容的其它請求則自下而上地進行轉寄，直到在某一級Cache中得到滿足。層次式緩衝體繫結構頻寬效率高，點擊率較高的Web內容可以快速高效地分布到網路中。但該體繫結構也存在一些不足[4]：（1）建立層次式緩衝體繫結構，快取服務器必須配置在網路中關鍵的訪問點上，快取服務器間需相互合作；（2）每一級Cache都會帶來額外的延遲；（3）高層Cache可能會成為瓶頸並帶來較長的排隊延遲；（4）同一個內容的多個副本被儲存在不同的Cache中，整個系統Cache空間利用率不高。3.1.2 分布式緩衝體繫結構針對層次式緩衝結構的上述缺陷，一些研究者提出了分布式緩衝體繫結構，在這種結構中，只有低層Cache,1（b）所示。文獻[5]中的分布式Web緩衝結構中，沒有超出局域層的中間Cache層，Cache之間相互協作以處理失效。為了確定將客戶請求轉寄給哪一個局域層Cache來擷取失效的內容，每一個局域層Cache保留一份其它局域層Cache中緩衝內容的目錄資訊，以便發生失效時將客戶請求準確地轉寄到相應的局域層Cache。緩衝陣列路由協議CARP [6]（Cache Array Routing protocol）是一種分布式緩衝方案，它將URL空間分割成不同的部分，將每一部分指定給一組鬆散耦合的Cache組，每個Cache只能緩衝具有指定給它的URL的Web內容，從而可以根據客戶請求內容的URL來確定將請求轉寄給哪一個Cache。在分布式緩衝結構中，大多數的網路流量都發生在網路底層，不容易產生網路擁塞，Cache空間利用率高，且可以更好地實現負載共用，容錯性更好。然而，一個大規模的分布式緩衝系統的配置可能會遇到幾個問題：串連次數較多、頻寬要求高、管理困難[4]。3.1.3 混合式緩衝體繫結構混合式體繫結構1（c）所示，同級Cache採用分布式緩衝結構，相互合作。Harvest集團設計的互連網緩衝協議ICP（the Internet Cache Protocol）支援從RTT最小的父Cache或鄰居Cache中擷取相應的內容。3.1.4 緩衝體繫結構的最佳化研究表明[4]層次式緩衝體繫結構和分布式緩衝結構相比，層次式緩衝體繫結構具有較短的連線時間，因此將較小的文檔緩衝在中介層Cache中可以減少訪問延遲；分布緩衝結構具有較短的傳輸時間和較高的頻寬利用率。理想的方案就是將二者結合起來，充分發揮各自的長處，同時減少連線時間和傳輸時間。3.2  緩衝路由出於對Web緩衝系統擴充性的考慮，大多數緩衝系統將大量的Cache分散在互連網上，這樣帶來的最大問題是如何快速地定位緩衝有所需內容的Cache，這就是緩衝路由問題。該問題有點類似於網路路由，但卻不能用同樣的方式解決。傳統的網路路由可依地址聚類（層次式的地址表示使得地址聚類成為可能）而進行，但是在WWW中，具有相同URL首碼或伺服器位址首碼的文檔未必發送給相同的客戶，難以對路由地址進行聚類，這樣緩衝路由表將大得難以管理。此外，緩衝內容不斷更新，過時的緩衝路由資訊將導致緩衝失效。為降低Cache失效的代價，理想的緩衝路由演算法應該將客戶的請求路由到下一個代理，該代理具有較高的命中可能性且位於或接近於客戶到伺服器的網路路徑上。3.2.1 緩衝路由表法Malpani等人[7]將一組Cache組合起來，當客戶的請求被轉寄到指定的Cache時，如果該Cache緩衝有請求的內容，則將其發送給客戶，否則通過IP組播將請求轉寄給同組的其它Cache，由緩衝有相應內容的Cache對客戶的請求進行響應，如果所有Cache中都沒有緩衝請求的內容，則該請求被轉寄到原始伺服器。Harvest[3]緩衝系統將Cache組織成層次式結構並使用Cache解析協議ICP（Internet Cache Protocol），當發生Cache失效時，低層Cache在將客戶請求轉寄到上一層Cache前，首先查詢兄弟節點Cache是否緩衝有相應的內容，以避免頂層Cache超載。自適應Web緩衝系統[8]為每一個伺服器建立Cache樹，樹中的Cache被組織成相互重疊的多點傳送組，一個請求通過這些傳送組來擷取相應的緩衝內容。該方法對每一個伺服器構造不同的Cache樹，因此沒有根結點的超載問題，自配置性和魯棒性都比較好。但是對點擊率較低的內容請求可能會經過較多的Cache，產生較大的Cache通訊開銷，作者建議通過限制請求經過的Cache數來解決該問題。3.2.2 雜湊函數法Cache陣列路由協議CARP[6]使用一個基於陣列成員列表和URL的雜湊函數來確定一個Web對象確切的緩衝地址或一個Web對象應緩衝在什麼地方。在Summary Cache[9]中，每個代理儲存一個同組中其它代理所緩衝內容的URL摘要資訊，該代理在轉寄客戶請求時檢查這些摘要資訊以確定將請求轉寄給哪一個代理。為減小開銷，這些摘要資訊定期進行更新。實驗表明該系統可以顯著地減少Cache間的資訊數量、頻寬消耗以及協議帶來的CPU開銷，而保持和ICP幾乎一樣的快取命中率。3.3  Cache替換演算法Cache替換演算法是影響代理緩衝系統效能的一個重要因素，一個好的Cache替換演算法可以產生較高的命中率。目前已經提出的演算法可以劃分為以下三類： （1）傳統替換演算法及其直接演化，其代表演算法有：①LRU（Least Recently Used）演算法：將最近最少使用的內容替換出Cache；②LFU（Lease Frequently Used）演算法：將訪問次數最少的內容替換出Cache；③Pitkow/Recker[10]提出了一種替換演算法：如果Cache中所有內容都是同一天被緩衝的，則將最大的文檔替換出Cache，否則按LRU演算法進行替換。（2）基於緩衝內容關鍵特徵的替換演算法，其代表演算法有：①Size[10]替換演算法：將最大的內容替換出Cache；②LRU—MIN[11]替換演算法：該演算法力圖使被替換的文檔個數最少。設待緩衝文檔的大小為S，對Cache中緩衝的大小至少是S的文檔，根據LRU演算法進行替換；如果沒有大小至少為S的對象，則從大小至少為S/2的文檔中按照LRU演算法進行替換；③LRU—Threshold[11] 替換演算法：和LRU演算法一致，只是大小超過一定閾值的文檔不能被緩衝；④Lowest Lacency First[12]替換演算法：將訪問延遲最小的文檔替換出Cache。（3）基於代價的替換演算法，該類演算法使用一個代價函數對Cache中的對象進行評估，最後根據代價值的大小決定替換對象。其代表演算法有：①Hybrid[12] 演算法：演算法對Cache中的每一個對象賦予一個效用函數，將效用最小的對象替換出Cache；②Lowest Relative Value[13] 演算法：將效用值最低的對象替換出Cache；③Least Normalized Cost Replacement（LCNR）[14]演算法：該演算法使用一個關於文檔訪問頻次、傳輸時間和大小的推理函數來確定替換文檔；④Bolot等人 [15]提出了一種基於文檔傳輸時間代價、大小、和上次訪問時間的權重推理函數來確定文檔替換；⑤Size—Adjust LRU（SLRU）[16] 演算法：對緩衝的對象按代價與大小的比率進行排序，並選取比率最小的對象進行替換。總之，為了使Cache命中率最大化，圍繞Cache替換演算法已經開展了大量的工作，但是替換演算法的效能很大程度上取決於WWW訪問的特性，還沒有哪一種替換演算法能夠對所有Web訪問模式都優於其它演算法。3.4 緩衝一致性Web緩衝系統可以減小訪問延遲，但帶來了一個副作用：緩衝的副本提供給客戶的可能是過時的內容，因此必須有一套緩衝一致性機制來確保緩衝的內容能夠及時進行更新及有效性確認，以便為客戶提供最新的內容。目前主要有兩種緩衝一致性類型：強緩衝一致性和弱緩衝一致性。3.4.1 強緩衝一致性（1）用戶端確認：對於每一次訪問，代理都認為緩衝的內容已經過時並隨請求發送一個“IF—Modified —Since—date”前序到伺服器。如果在指定的時間後該內容發生了變化，則伺服器將更新後的內容發送給代理並最終發送給客戶；如果請求內容未修改，則發回 “304”響應，表示文檔未修改，緩衝內容繼續有效。（2）伺服器確認：當伺服器檢測到一個內容發生變化時，伺服器向所有最近請求過該內容並有可能緩衝該內容的客戶發送作廢資訊[17]。該方法要求伺服器必須儲存一個訪問該內容的客戶鏈表以便發送作廢資訊，當客戶數量很大時，該方法將變得不適用，同時，該鏈表本身也可能過時，造成伺服器向許多已經不再緩衝該內容的客戶發送作廢資訊。3.4.2 弱緩衝一致性（1）自適應TTL[18] （Time To Live）機制：通過觀察一個文檔的生存期來調整其存留時間，從而解決緩衝一致性問題。如果一個文檔在一個相當長的時間內都未修改過，它往往不會再發生變化。這樣，一個文檔的生存期屬性被賦予一個該文檔目前“年齡”（等於目前時間減去上一次修改的時間）的百分比。自適應TTL法可以將一個文檔過時的可能性控制在＜5%的範圍內。大多數的Proxy 伺服器都使用該機制，但是這種基於文檔生存期的緩衝一致性機制並不能確保緩衝內容的有效性。（2）捎帶作廢機制Krishnamurthy等人提出使用捎帶作廢機制來提高緩衝一致性的效率。他們提出了三種機制：①捎帶確認PCV[19]（Piggyback Cache Validation）機制：利用代理髮送給伺服器的請求來提高緩衝一致性。例如，當一個代理向伺服器發出請求時，它捎帶一系列緩衝的但可能過時的來自該伺服器的內容進行有效性確認；②捎帶作廢PSI[20]（Piggyback Service Invalidation）機制：其基本思想是當伺服器對代理進行響應時，把一系列上次代理訪問後變化的內容告訴Proxy 伺服器並由代理將這些內容作廢，從而延長其它緩衝內容在Cache中的緩衝時間；③PSI和PCV混合機制[21]：該機制根據代理上次請求作廢的時間距目前時間間隔的大小來確定採用何種機制，以實現最佳的總體效能。如果這個時間間隔較小，則使用PSI機制，否則使用PCV機制來對緩衝內容進行確認。其基本原理是時間間隔越小，與PSI一起發送的作廢數量就小，但隨著時間的增長，發送作廢的開銷將大於請求確認的開銷。3.5 內容預取Web緩衝技術可以提高Web效能，但研究表明[22]，不管採用何種緩衝方案，最大快取命中率通常不大於40～50%。為進一步提高快取命中率，引入了預取技術。預取技術本質上是一種主動式快取技術，其基本思想是在處理客戶的當前請求時，利用客戶訪問內容或模式的先驗知識，對客戶接下來的請求內容進行預測，並利用客戶請求的間隙將預測內容緩衝在Cache中，從而更好地隱藏延遲，提高服務品質。早期研究集中在瀏覽器/客戶與Web伺服器之間進行內容預取，當代理被引入後，人們的研究興趣轉到了代理與伺服器之間的預取技術研究。研究表明預取技術可以有效地降低客戶訪問延遲，但預取技術仍飽受爭議，原因有二：（1）內容預取是一種即時性要求較高的任務，它主要利用客戶請求的間隔進行，而這個間隔一般情況下小於一分鐘[23]，如果在這段時間內不能完成預取任務，預取將變得毫無意義。因此對預取演算法的效率有較高的要求。（2）內容預取是通過加重伺服器負載及增加網路流量為代價來降低用戶端回應時間的，因此對預取的準確度有較高的要求。同時，一個預模數型在確定預取文檔的數量時，必須考慮客戶的訪問特性、伺服器負載及網路流量狀況，如果拋開這些因素來進行預取可能會造成事與願違的效果。總之，一個良好的預模數型，效率、準確度要高，付出代價小。圍繞預取的高效性和準確性還需做進一步的研究。3.5 Server Load Balancer當眾多客戶同時從一台伺服器擷取資料或服務時就會發生Hot Spot現象，導致伺服器效能下降甚至失效。目前處理該問題的方法大多數是使用某些複製策略將被請求的內容分貯在互連網上，從而將負載分散到多個伺服器（代理）上[24]，避免單個伺服器成為為瓶頸。3.6  緩衝內容一個代理可能發揮多種作用，除進行資料緩衝外還可以進行串連緩衝和計算緩衝。串連緩衝指在客戶與代理、代理與伺服器間使用持久串連，來減少建立TCP串連開銷及伺服器發送時的慢起動開銷，從而減小客戶訪問延遲時間[25]。計算緩衝可以看作是Web伺服器可以將它們的部分服務遷移到代理，以減輕伺服器瓶頸，其應用之一就是動態資料緩衝，通過代理來緩衝動態資料並將一部分計算遷移到代理，由代理來產生和維護緩衝的動態資料，從而提高客戶擷取動態資料的效能。4  需要進一步研究的問題圍繞Web緩衝技術已經開展了大量的研究並取得了豐碩成果，但仍有一些問題需做進一步的研究。這些問題包括：（1）客戶訪問模式研究：通過研究客戶的訪問模式，從而更好地進行緩衝管理和內容預取，提高快取命中率；（2）動態資料緩衝：目前Web快取命中率不高的一個重要原因是相當一部分內容（私人資料、授權資料、動態資料等）不能被緩衝。如何使得更多的資料可以緩衝以及如何減小客戶訪問非快取頁面面的訪問延遲已經成為提高Web效能的關鍵問題；（3）Web流量特徵：緩衝系統的效率在於Web訪問流的時間局部性以及良好的Cache管理原則，理解Web客戶產生的負載特性對於更好地設計和提供Web服務具有重要意義；（4）代理配置：要獲得良好的Web效能，代理的配置至關重要，代理配置策略的理想標準是：自組織、高效路由、負載平衡、行為穩定等，圍繞此問題還需做進一步的研究。總之，提高Web效能的前沿研究在於開發擴充性、魯棒性、適應性、穩定性好、高效且能夠較好地配置在當前及今後網路中的緩衝方案。參考文獻[1]          R. Caceres, F. Douglis, A. Feldmann, G. Glass, and M. Rabinovich, Web proxy caching: the devil is in the details, ACM Performance Evaluation Review, 26(3): pp. 11-15, December 1998.[2]          B. M. Duska, D. Marwood, and M. J. Feelay, The measured access characteristics of World Wide Web client proxy caches, Proceedings of USENIX Symposium on Internet Technologies and Systems  (http://cs.ubc.ca/spider/feeley/wwwap/wwwap.html).[3]          A. Chankhunthod, P. B. Danzig, C. Neerdaels, M. F. Schwartz, and K. J. Worrel, A hierarchical Internet object cache, Usenix’96, January 1996.[4]          P. Rodriguez, C. Spanner, and E. W. Biersack, Web caching architectures: hierarchical and distributed caching, Proceedings of WCW’99.[5]          R. Tewari, M. Dahlin, H. Vin, and J. Kay, Beyond hierarchies: design considerations for distributed caching on the Internet, Technical Report TR98-04, Department of Computer Science, University of Texas at Austin, February 1998.[6]          V. Valloppillil and K. W. Ross, Cache array routing protocol v1.0, Internet Draft _ draft- vinod-carp-v1-03.txt[7]          R. Malpani, J. Lorch, and D. Berger, Making World Wide Web caching servers cooperate, Proceedings of the 4th International WWW Conference, Boston, MA, Dec. 1995[8]          E. Cohen, B. Krishnamurthy, and J. Rexford, Evaluating server-assisted cache replacement in the Web, Proceedings of the European Symposium on Algorithms-98, 1998.[9]          L. Fan, P. Cao, J. Almeida, and A. Z. Broder, Summary cache: a scalable wide-area Web cache sharing protocol, Proceedings of Sigcomm’98.[10]       S. Williams, M. Abrams, C. R. Standridge, G. Abdulla, and E. A. Fox, Removal policies in network caches for World-Wide Web documents, Proceedings of Sigcomm’96.[11]       M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox, Caching proxies: limitations and potentials, Proceedings of the 4th International WWW Conference, Boston, MA, Dec. 1995.[12]       R. P. Wooster and M. Abrams, Proxy caching that estimates page load delays, Proceedings of the 6th International WWW Conference, April 1997 (http://www.cs.vt.edu/ chitra/docs/www6r/).[13]       P. Lorenzetti, L. Rizzo, and L. Vicisano, Replacement policies for a proxy cache .[14]       P. Scheuermann, J. Shim, and R. Vingralek, A case for delay-conscious caching of Web documents, Proceedings of the 6th International WWW Conference, Santa Clara, Apr. 1997.[15]       J. C. Bolot and P. Hoschka, Performance engineering of the World-Wide Web: Application to dimensioning and cache design, Proceedings of the 5th International WWW Conference, Paris, France, May 1996.[16]       C. 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/February 1999.[17]       P. Cao and C. Liu, Maintaining strong cache consistency in theWorld WideWeb, Proceedings of the 17th IEEE International Conference on Distributed Computing Systems, May 1997.[18]       V. Cate, Alex - a global file system, Proceedings of the 1992 USENIX File System Workshop, pp. 1-12, May 1992.[19]       B. Krishnamurthy and C. E.Wills, Study of piggyback cache validation for proxy caches in the World Wide Web, Proceedings of the 1997 USENIX Symposium on Internet Technology and Systems, pp. 1-12, December 1997.[20]       B. Krishnamurthy and C. E. Wills, Piggyback server invalidation for proxy cache coherency, Proceedings of the WWW-7 Conference, pp. 185-194, 1998.[21]       B. Krishnamurthy and C. E. Wills, Proxy cache coherency and replacement - towards a more complete picture, ICDC99, June 1999.[22]       F. Douglis, A. Feldmann, B. Krishnamurthy, and J. Mogul, Rate of change and other metrics: a live study of the World-Wide Web, Proceedings of the 1997 Usenix Symposium on Internet Technologies and Systems (USITS-97), Dec. 1997.[23]       B. Krishnamurthy and J. Rexford. Web Protocols and Practice : HTTP 1.1, Networking Protocols, Caching, and Tra_c Measurement. Addison-Wesley, 2001.[24]       P. Barford, A. Bestavros, A. Bradley, and M. E. Crovella, Changes in Web client access patterns: characteristics and caching implications, World Wide Web (special issue on Characterization and Performance Evaluation), 1999.[25]       A. Feldmann, R. Caceres, F. Douglis, G. Glass, and M. Rabinovich, Performance of Web proxy caching in heterogeneous bandwidth environments, Proceedings of Infocom’99