連續媒體代理伺服器而設計之調變式後置視窗快取演算法

爲連續媒體代理伺服器而設計之調變式後置視窗快取演算法

童曉儒 Sheau-Ru Tong ,江家宏 Chia-Hung Chiang

國立屏東科技大學資訊管理系

[email protected],[email protected]

摘要

代理伺服器通常用來協助用戶端透過網路接 收遠端的資訊。本篇論文探討如何設計代理伺服器 的快取策略，以利使用者來擷取遠端的連續媒體， 如影音串流。我們將快取的資料分為兩種不同的影 片區段：(1)prefix：開頭影片和(2)suffix-window： 則是開頭影片之後，最近正在從遠端 Video Server 下載的後續影片。由於 Video Server 可能提供數部 影片，而影片的點播頻率可能不同且隨時間而變 動。基本上我們希望能讓受歡迎程度越高的影片越 能佔用代理伺服器的暫存空間，反之受歡迎程度越 低的影片越難有機會使用。為了達到上述目的，我 們提出『可調變式後置視窗機制』，針對影片的受 歡迎程度自動的調整分配代理伺服器的暫存空間 來儲存 suffix-window，以獲取系統的最佳利益。 經由模擬實驗結果得知，我們的快取機制可迅速的 適應影片點播頻率的變動，並改善系統的效能，尤 其是當使用者的緩衝區越小，這樣的效果就越明 顯。 關鍵詞：代理伺服器、連續媒體、影片串流、調變 式後置視窗機制。

Abstract

A proxy server is usually deployed for serving a set of clients to access remote information from Internet. This thesis focuses on designing such a proxy server for accessing continuous media, like video streams. In principle, two kinds of segments are stored in the proxy: (1) prefix: the beginning segment of a video and (2) suffix-window: the video segment just transmitted. Different videos usually show different popularity and the popularity may be changed with time. Ideally, the system should allow more popular videos to gain more proxy storage than the less popular ones. For this purpose, we propose an adaptive suffix-window scheme, which is able to self-tune the storage allocation for suffix window in response to the video popularity change to gain the optimal performance. The simulation results reveal that our scheme can quickly adapt to video popularity and improve the system performance with great significance particularly when the client buffer is very limited.

Keywords: Proxy Server、continuous media、video

streams、adaptive suffix-window scheme.

1.前言

隨著網際網路蓬勃發展，利用網路傳輸連續 媒體(如：視訊與音訊)已十分普遍，然而由於網路 頻寬有限，且交通壅塞，將造成延遲冗長，例如接 收一部 110 分鐘的 MPEG-1 影片，資料量可高達 1.1GB，影片傳輸時需要 1.5 Mbit/sec 的頻寬。一 旦網路壅塞便會造成使用者等待時間過長與影片 播放不順暢的問題產生。常用來解決上述問題的方 式為在靠近使用者端也就是區域網路(LAN)上設 置代理伺服器(Proxy Server)[3]，Proxy Server 存放 最近被存取到之連續性物件，讓使用者直接由 Proxy Server 存取資料，而不用透過建立連線向 Video Server 提出要求，如此可以節省下許多等待 的時間。當使用者透過網際網路點選相同的視訊或 是音訊的次數越是頻繁，代理伺服器 cache 的特性 更形重要，使用者透過 Cache 來取得資料，不僅可 以減少網路上的重複傳輸，減少頻寬的浪費，也讓 使用者就近取得資料減少等待傳輸的時間，但是代 理伺服器的 Cache 記憶體空間是有限的，所以必須 在適當的時機置換出不常用的物件或不再有使用 者會存取的物件，讓伺服器快取記憶體中的空間利 用率達到最佳效能。 在以往網路中提出的快取置換策略，皆為探 討如何減少網路壅塞並降低使用者在存取資料時 的錯誤率[4][7][8][9]。當有新的物件置入 cache 時，若 cache 空間不足，則需要丟棄一個或是多個 cache 中的物件，以求得足夠空間來容納這個新進 物件，此種選擇物件來丟棄的方式稱為置換策略 (Replacement Policy)，這種置換策略有以物件最近 被存取的時間、記錄快取記憶體中物件被重複存取 的次數，或最近存取頻率最高的物件先置換掉 [2]，其置換策略會優先選取挑選中的物件作為替 換掉的物件，但這些置換策略並不適用於目前的影 音串流系統，因為影片的資料量過大，把一部影片 視為單一物件來 Cache，將會很容易就消耗掉 Proxy 的容量，這種作法是很不切實際的。所以一 種折衷的作法是，Proxy 僅需要 Cache 部分的影 片，期望能夠達到快取記憶體最佳化的效果。 在[10]中提出代理伺服器中使用預先 Cache 影 片的初始部分(Prefix)，能夠有效地降低使用者起始 等待時間。因為 Prefix 事先儲存於 Proxy 中，是考 慮到區域網路回應的速度，遠快於在廣域網路環境 中，所以當使用者點播時，Proxy 會先將 Prefix 傳 給使用者，其餘的影片部分(Suffix)，再從 Server

直接下載，以接續即將播放完畢的 Prefix，如此一 來將可使廣域網路中所消耗的起始延遲縮短。[6] 則提出了當 Video Server 提供了數部不同的影片且 影片的點播頻率隨著時間的變化有所不同情況 下，代理伺服器以影片的點播頻率來分配 Proxy 的 快取記憶體來 Cache 影片的 Prefix，希望點播率高 之影片能更有效率的使用 Proxy 提供的快取記憶 體。 但是 Prefix 的限制為使用者必須有足夠的緩 衝區大小，否則便可能因為沒有足夠的 Buffer 來暫 存影片而無法被 Proxy 服務，在現今網路上存在各 式各樣不同種類的設備，例如：筆記型電腦、手機 與 PDA 等，使用手持設備的缺點在於緩衝區空間 (Buffer)有限，無法暫存過大的資料，所以當使用 者拿手持式設備下載影片觀賞時，Prefix 顯然無法 降低網路傳輸量，因此[1]提出了 Suffix-Window Caching 來儲存 Suffix 的代理伺服器快取機制以解 決使用者緩衝區不足的情況。 有鑑於以往的 Proxy Cache 機制著重探討暫存 影片的初始部分(稱之為 Prefix)，已不適用於目前 的手持式設備使用者，所以本論文提出一『調變式 後置視窗』(Adaptive Suffix Window / ASW)與延伸

調變式後置視窗(Adaptive Suffix Window+

/ ASW+)

兩種機制於此，在第二節中將介紹 ASW 和 ASW+

透過設計一有彈性的 Proxy 資源管理機制來 Cache 影片。其原則為賦予高點播頻率的影片擁有較高之 權重來使用 Proxy 的資源，Cache 更多的影片至 Proxy 內，以降低 WAN 的 traffic。越低頻率的影片 則越不能使用 Proxy 資源，以期能更有效率的使用 Proxy Buffer，讓整體的系統效能提升。

在第三節中我們將透過模擬實驗，與先前僅 具 Prefix Caching 的策略比較，我們發現在相同的 Proxy Cache 容量下，藉由增加些許 LAN 的頻寬消 耗，的確能降低 WAN 之頻寬消耗與使用者拒絕 率，特別是當使用者緩衝區的條件愈嚴苛時，效率 改善也就越顯著。最後我們將對本研究做結論。

2.

調變式後置視窗快取機制

以前 Proxy Cache Scheme 為在 Proxy 內存放影 片的連續起始部分，因為通常使用者觀看影片的行 為幾乎是觀看影片的初始片段，所以影片只需有 Prefix 就能滿足使用者觀看影片的要求，而以 Prefix 為 基 礎 的 演 算 法 有 MPach 和 Segment-Based。為輔助說明我們的方法，在此對 MPatch 方法[5]和 Segment-Based 做一概略性之描 述。 2.1 MPatch 我們首先對 MPatch 代理伺服器提出一個簡單 的圖型表示，在圖形中設定代理伺服器永遠提供一 段 Prefix(vi)串流給予任何時間點進入代理伺服器 要求的 User client，當影片被第一個點選者選取之 後 ， 代 理 伺 服 器 會 啟 動 一 個 Master multicast stream，我們稱這個使用者為 Master client。這個 Multicast Stream 會在 Prefix 耗盡前自 Video Server 下載 Suffix stream 到 Proxy 中，以便接續 stream。

假設這個 Multicast stream 啟動時間為 t=0，之 後如果還有使用者要求同一部影片，我們稱之為 Slave client，若 ta代表 Slave client 發出對影片需求

的時間如果使用者發出需求的時間介於 0≦ta≦vi

(如圖 1 所示)，此時該 Slave Client 可直接加入正在 進行傳送 Prefix 的 multicast channel 外；對於錯過

的片段部分[0, ti]，則同時另外開啟一個 unicast

channel 自 proxy 接收。若 Slave Client 於 vi < ti ≤ Gi

時發出的點播需求(如圖 2 所示)，此時他除了直接 加入正在進行傳送 prefix 的 multicast channel 外；

而對於錯過的片段部分[0, ti]，分成兩段下載，首

先[0, vi]為 prefix，透過開啟一道連至 proxy 的

unicast channel 下載；同時[vi, ti]稱之為 patch，則透

過開啟一道連至 server 的 unicast channel 下載；若

是 ti≧Gi(圖 3 所示)，則不能加入目前正在 multicast

channel，該 User 成為一新的 Master Client，啟動

一新的 Multicast session。此外 User 必須備有 ti大

小的緩衝區(Client buffer Length)用來暫存即將要 播放的影片，否則將變成新的 Master Client（此時 ti重設成 0）。若是 Client 的 Buffer 有限，則上述的 狀況將會頻繁發生，網路的傳輸品質將無法獲得改 善。 a t a t Time Prefix i v from proxy,unicast a t 0 from proxy,multicast a i t L − i L

Client buffer Length

Gi 圖 1：0≦ta≦vi i v prefix 0 i v a t from proxy,unicast a i t L − i L from proxy,multicast i v t2− from server,unicast Time

Client buffer Length

Gi

Time i G Threshold i v Prefix i v 0 i t i L from proxy,multicast i i v L−

New multicast session from server

Client buffer Length

圖 3：ti≧Gi 2.2 Segment-Based Caching 當 Video Server 提供數部相異的影片情況 下，且每部影片的點播頻率不盡相同，此時 Proxy 可以依影片的頻率來分配快取記憶體來 Cache 影 片的 Prefix。Cache 的大小以 Segments 不同來儲 存，Segment 的大小為 Segment Size 以 2 的冪次方 成長(如圖 4 所示)。Segment 0 和 Segment 1 只擁 有一個 Block，Segment 2 包含 2 Blocks，…Segment i 包含有 2i-1 Blocks。 0 1 2 3 4 5 6 7 Seg 0 Seg 1 Seg 2 Seg 3 8 9 10 11 12 13 14 15 Seg 4 ▉ ▉ ▉ 圖 4：Segment-Based Size 影片的點播頻率隨著時間而改變時，舊有 Cache 再 Proxy 快取記憶體內的 Segments 將被選取 替換掉，以釋放出 Proxy Buffer 提供給之後盛行起 的影片使用。Segment-Based 提出一影片置換快取 的策略稱為 Admission Policy。替換時機取決於 Segment 的 Cache Value。假設 Object P 想要儲存 Segment i，但 Proxy Buffer 已經沒有足夠的 Buffer Size 來放置 Segment i，Replacement 將找出一目前 以沒人使用的 Object Q，Object Q 存放於 Buffer 內 最大的 Segment j，比較 P 欲存放 Segment i 的 Caching Value 和 Q 欲被替換 Segment j 的 Caching Value ， Caching Value = reference frequency / segment distance，當 Segment i 的 Caching Value 大 於或等於 Segment j 則 Replacement Segment j。

Segment-Based 雖然可依影片的 Frequency 來 決定影片存放到 Proxy 內的 Prefix 長度，但隨著時 間的變化，高點播頻率影片可能會衰減為低點播頻 率，Segment-Based Cache 的 Prefix 只要有 User 點 播就無法釋放出快取記憶體，所以當頻率瞬間下降 時，無法及時性的反映頻率衰減分配記憶體的大 小。 2.3 可調適性後置視窗快取機制 以下我們介紹可調適視窗快取機制(ASW)的 運作原理，我們假設代理伺服器提供一段 Buffer 來暫存兩種不同的影片區段：(1)prefix vi：開頭影 片和(2)suffix-window wi：則是開頭影片之後，最 近正在從遠端 Video Server 下載的後續影片，假設 當 master Client 在時間 t=0 要求了一部影片，隨後 有一個 Slave Client 於 ta加入要求相同的影片，此 時有四種以下的情況，如圖 5 所示，此圖代表影片 位置對於系統時間的關係圖(Location-to-Time)，橫 軸 Time 代表系統的時間，t0為系統的起始時間。 縱軸為影片的播放位置，灰階區域代表是某個時間 點，目前存放在 Proxy 內的是哪一段資料。

Case 1 (ta ∈(0, vi+ wi] and bc≥(ta-wi))：當 Slave

Client 發出影片需求的起始點落在(vi+ wi)內，這

時 Slave Client 除了可以加入由 Video Server 產 生的 Master Multicast Stream，或加入由 Proxy Server 為 Slave Client 產生的 Slave stream，從 Proxy 中下載正在進行的影片外，錯過的部分則 用 Unicast 自 Proxy 下載到本身 Buffer。Slave Client 必須具備有容納長度片段(ta-wi)的 Buffer。

Case 2 (ta ∈(0, vi+ wi] and bc< (ta-wi))：當 Slave

Client 發出影片需求的起始點落在(0, vi+ wi]

內，但是 Slave Client 的 Buffer Size 並不夠來接

收(ta-wi)缺失的部分，此時 Proxy 決定是否該

Expanding Suffix Window。(ta-wi)為 Proxy 需付

出之 Buffer，當 Proxy 為此使用者儲存 wi Size(wi

=t)後，Slave Client 可以透過代理伺服器啟動一 群播群組，稱作 salve Stream，而不需要直接向 video Server 要求一新 Master stream，這樣可以 降 低 WAN 上 的傳 輸頻寬 ，同 時此新 Slave Multicast Stream 可以讓後續使用者加入其群

組。相對的 Proxy 消耗了(ta-wi)的容量，假如

Proxy Buffer 小於(ta-wi)的容量，此時這 Slave

Client 只能透過 WAN 直接要求 Video Server 產 生一新完整的 Multicast stream(Master stream)。 Case 3(ta ∈(vi+wi, S] and bc≥(ta-wi))：當 Slave

Client 發出影片需求的起始點落在(vi+wi, S]內，

Client Buffer Size 足夠容納(ta-wi)的話，Slave

Client 可以選擇加入 Last stream 群播群組，並且 透過 WAN 向 Video Server 使用 Unicast 下載 path[vi, t-wi]缺失部份影片。

Case 4(ta ∈(vi+wi, S] and bc< (ta-wi))：當 Slave

Client 發出影片需求的起始點落在(vi+wi, S]外，

已經無法分享 Master or Slave stream，故只好扮 演 Master Client 的角色，重新開啟一個 Multicast session，從 Server 中下載整部影片。

Lo ca ti on Time vi

Case 2 Case 2 Case 3

wi1 wi2 t1 _t2 _t3 =wi3 t0 wi0=0

Patch from sever

t4 Case 4 wi4=0 t3_-w i2 Case 1 圖 5：ASW 系統時間關係圖

在上述 Case4 的討論中，我們提到 Slave Client 進入時間點落在 ta ∈(vi+wi, S]時，Client 必須具備

有可容納(ta-wi)影片長度的 Buffer，方可加入 Last

stream 且下載 path 成為 Slave Client。若是沒有足 夠的空間，則 Client 必須再重新啟動一個新的 Master stream，為了解決這個問題，本論文加入延 伸調變示後置視窗快取機制(ASW+ )機制來解決， 以下是其說明： Case 4(ta ∈(vi+wi, S] and bc< (ta-wi))：如圖 6 所 示。使用者要求時間為 t4落在(vi+w12, S]，Client 緩衝區小於(t4-w12)，系統判斷獲利益值大於門檻值 R，系統允許此部影片繼續 Expanding (t4-w12)大小

的 Suffix Window Size，此時 Suffix Window Size =

w13，代理伺服器為此使用者產生一 Slave stream 群

播群組，避免使用者直接向 Video Server 透過 WAN 要求傳輸資料。 L oc a ti on Time vi

Case 2 Case 2 Case 4

wi1 wi2 t1 _t2 _t3 wi3 t0 wi0=0

Patch from server

t4 Case 2 t3_-w i2 wi4 圖 6：ASW+_{系統時間關係圖} 此外因為 ASW 由於可能會有一部以上的影片 在同時搶 Proxy 資源，所以我們希望被點播頻率越 高的影片越有機會搶到資源，點播頻率越低的越沒 有機會，為了達到這個效果我們提出 R function，R function 的 Admission Control 為 Breq=Bactual*(1-log

f)，此處 Breq為該影片提出的 Buffer 需求，Bactual

為實際的 Buffer 需求，f 為影片的點播率。對於 f

高的影片， Breq會儘可能接近 Bactual ，反之對於 f

低的影片，Breq會遠大於 Bactual 。譬如有部影片實

際要求 2MB buffer size，影片之頻率為 0.02，帶入 R function 後變成要求 Buffer size 為 5.2MB，此時 Proxy 若有大於 5.2MB 的 Buffer Size 則實際分配 2MB 給予該影片，若無足夠 Buffer Size 則拒絕該 要求。

3.

效能評估

在 本 節 的 模 擬 實 驗 中 我 們 模 擬 比 較 儲 存 Prefix 或是 Suffix 何者能夠有效的解決網路壅塞， 包容使用者本身緩衝區的限制網路異質性的問 題。我們比較三種 Scheme，MPatch、Segment-Based 和 Suffix。對於 MPatch 來說，我們假設所有的 Proxy Buffer 以 完 全 平 均 分 配 給 所 有 的 影 片 ， Segment-Based 的 Prefix 成長是根據影片的頻率使 用 2 的次方方式來 Cache，而 Suffix 則是根據我們

所提的 ASW 和 ASW+_{的方式來運作。}

每個使用者端的緩衝區(Client Buffer)並不相 同，Client buffe r 的大小是由 Gamma distribution Γ(α)所給定，其中α值設定為 3，系統探討異質 性終端者緩衝區大小對於 Patch 和 Dynamic Suffix Window 及 Dynamic Suffix Window Plus 之影響。

使用者對 Proxy 發出影片的需求是以 Poisson Process 方式所產生的，使用者與使用者間的時間 間隔為 Exponential Distribution，模擬假設影片的 總長度(Li)為 500 個單位時間，執行時間為 10000 個單位時間，單位時間內發出影片需求的使用者為 0.2 人，亦即平均速率為 0.2 人/單位時間，我們討 論不同的 Arrive Rate 對效能的影響。 3.1 效能指標之定義 在 此 模 擬 實 驗 中 我 們 想 探 討 MPatch 、 Segment-Based、ASW 和 ASWf三種機制的網路傳

輸資料量比例(Bandwidth Gain)，和 Proxy Buffer 的分配(Buffer allocation)。

Average Buffer Usage：當 Proxy Buffer 增加的時 候， MPatch 平均分配 Proxy 的資源來預先儲存

每部影片的 Prefix，而 ASW 和 ASW+_則是依照

影片的 Frequency 來搶奪 Proxy 資源，頻率高的 影片相較於頻率低影片更能夠使用到 Proxy 的 資源，來儲存影片的 Suffix 至 Proxy 內，我們將 探討哪種機制較能有效率的使用資源。 網路傳輸獲利值(Bandwidth Gain)：在 LAN 中傳

輸資料量代表使用者透過 LAN 環境由 Proxy 下 載影片，在 WAN 中傳輸資料量則是透過 WAN 環境由 Video Server 下載。我們探討 WAN 中的 資 料 傳 輸 總 量 ， 分 別 以 Segment-Based Bandwidth Gain 、 ASW Bandwidth Gain 和

ASW+ Bandwidth Gain 來表示。

Segment-Based Bandwidth Gain = (MPatch Bandwidth Cost –Segment-Based ASW Bandwidth Cost ) / MPatch Bandwidth Cost ASW Bandwidth Gain = (MPatch Bandwidth Cost – ASW Bandwidth Cost ) / MPatch Bandwidth Cost

ASW+ Bandwidth Gain = (MPatch Bandwidth Cost – ASW+ Bandwidth Cost ) / MPatch Bandwidth Cost

3.2 儲存 Prefix 和 Suffix 的效能獲利

圖 7 為 Segment-Based 相對 MPatch 的效能獲 利，橫軸為 Proxy Buffer 變化，Buffer Size 由 0 Li

到 4 Li，縱軸為 Segment-Based 對於 MPatch 的

Bandwidth Gain。我們可以看到 Segment-Based 因 為在 Proxy Buffer 中完整的儲存了影片頻率高的影 片，如影片 17、13、6、14 幾乎在 Proxy 內 Cache 完整的影片。因此使用者點選該影片後可以直接從 Proxy 下載影片，而不需在透過 WAN 去向 Video Server 要求 Suffix 的資料，可以大幅減少 WAN 的 網路傳輸量。 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Proxy Buffer B and w idt h G ai n Segment

圖 7：Segment-Based Bandwidth Gain 由圖 7 知道 Segment-Based Cache 確實能夠有 效的解決網路壅塞，但在使用者緩衝區不足的情況

時，由圖 8 可看出 ASW 和 ASW+_{以 Cache Suffix}

的方式比 Segment-Based 的 Cache Prefix 來得佳， 因為在 Segment-Based 中，使用者緩衝區小不足以 加入目前正在播放當中的 Video Stream，所以在 Segment-Based 中該使用者只能視為一新的 Master Client，產生一獨立的 Video Stream。但在 ASW 和

ASW+中緩衝區小的使用者可以透過 Proxy Buffer

內暫存的 Suffix 產生一 Slave Stream，而 Slave Stream 不需要透過 WAN 從 Video Server 下載，所

以 ASW 和 ASW+_{的 Bandwidth Gain 會 比}

Segment-Based 都來的好。 -0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ProxyBuffer B andw idt h G ai n SegMent(0.01) DSW(0.01) DSW+(0.01) Segment(0.05) DSW(0.05) DSW+(0.05) 圖 8：ASW 和 ASW+ Bandwidth Gain 3.3 Proxy buffer distribution

在 ASW 和 ASW+_{因為有一部以上的影片同時}

使用 Proxy Resource，當影片 Frequency 越高時， 系 統 給 予 該 影 片 有 較 高 的 優 先 權 使 用 Proxy Buffer，反之頻率低之影片使用 Buffer 優先權較 低，藉此達到有效的分配 Proxy 資源，以降低 WAN 的資料傳輸量。由圖 9 所示，左邊的縱軸代表影片 的頻率(Video Frequency)，右邊的縱軸代表影片的 Buffer utility。橫軸的座標則是表示影片的編號， 系統總共有編號 0 到 19 部影片。(Buffer utility = Suffix Window Size wi * Suffix window’s Keep Time )

0 0.05 0.1 0.15 0.2 0.25 Vide o 17 Vide o 6 Vide o 18 Vide o 7 Vide o 8 Video 0 Vide o 16 Vide o 15 Vide o 11 Vide o 3 Video Number F re que nc y 0 50 100 150 200 250 300 350 400 450 500 Bu ff er U sa g e Frequency S = 20 S = 15 S = 10 圖 9：ASW 和 ASW+

Average Buffer Use 3.4 Client Buffer 大小對網路傳輸量的影響

圖 10 所示為 Mean Client Buffer 改變時 ASW

和 ASW+_{的變化。我們看到 Mean Client Buffer =}

0.1，ASW 只能節省下不到 2 成的 WAN 傳輸量， 因為使用者的緩衝區變大，使用者可以直接加入目 前正在播放中的 Master Stream，且同時使用緩衝區 接收來自 Video Server 的缺失部份，這部分和

MPatch 相同，因此 ASW+的資料傳輸量並不會顯

著優於 MPatch。當 Client Buffer Size = 0.01 Li，由

於使用者緩衝區太小不足以接收來自 Video Server 補齊缺失部份影片，在 MPatch，使用者只能透過 WAN 直接向 Video Server 要求重傳一完整新影

片。但在 ASW 和 ASW+_{中，因為 Proxy 儲存了部}

來說，不需透過 WAN 向 Video Server 下載，只需 透過 LAN 經由 Proxy 直接下載影片，減少來自

WAN 的 資 料 傳 輸 量 。 所 以 ASW 和 ASW+的

Bandwidth Gain 明顯的上昇，代表在 WAN 上的資 料傳輸量遠低於 MPatch 的消耗。 -0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 3.2 3.4 3.6 3.8 4 Proxy buffer size (Li)

B andw idt h G ai n (% )

ASW WAN(0.01) ASW+ WAN(0.01)

ASW WAN(0.05) ASW+ WAN(0.05)

ASW WAN(0.1) ASW+WAN(0.1)

圖 10：ASW 和 ASW+

Change Mean Client Buffer 3.5 影片 Distribution 的影響

影片被點選機率分別有 Uniform distribution 和以 Zipf distribution 為主，Uniform distribution 設 定影片被點選的機率為均等，而 Zipf distribution 每次都以亂數分配每部影片的熱門程度，我們調整 Zipf function 參數使影片的分布不會出現極端的情 形出現(只有某幾部影片有被點選中的機會)。圖 11 可以看到不論是 Uniform distribution 或是 Zipf

distribution，ASW 和 ASW+兩種機制對於 WAN 的

頻寬節省率都有顯著的節省，Uniform distribution 更有高達 80 %的獲利值。 -0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ProxyBuffer (Li) B an dw id th G ain

Zipf_DSW_WAN Zipf_DSW+ WAN

Uni DSW WAN Uni DSW+ WAN

圖 11：ASW 和 ASW+ _{Chang 影片 Distribution}

4 結論

由於網路上使用者的異質性設備差異大，代 理伺服器必須要能夠服務網路上不同使用者的要 求。且代理伺服器的資源有限，無法提供所有影片 暫存影片部分片段，考慮到頻率隨著時間而變動， 暫存於代理伺服器內的影片，需適時的替換出以提 供別人使用，且替換的時間能越快越能及時服務使 用者。因此在三層架構中的 proxy 要如何能夠同時 服務不同設備的使用者對影片的要求，且考慮代理 伺服器的效能最佳化便是本篇論文探討的重點。我 們所提的 ASW 和 ASW+_{機制，能夠有效的縮短起} 始等待，WAN 降低頻寬的消耗，更重要的是能包 容 buffer 不足的 client，即時的反應影片的頻率變 化，以便有效提升系統的使用率。

參考文獻

[1] 林青，“在異質環境下為傳輸連續媒體而設計 之代理伺服器快取策略 ”，屏東科技大學碩士 論文， 2003。 [2] 賈坤芳，“關聯法則應用於代理伺服器上之快 取置換機制 ”，中興大學資訊科學所碩士論 文， 2002。

[3] B.D. Davison, “A Survey of Proxy Cache

Evaluation Techniques, in Proceedings of the 4-th International WWW Caching Workshop, April 1999.

[4] B. M. Duska, D. Marwood, and M. J. Feeley,

“The Measured Access Characteristics of World-Wide-Web Client Proxy Caches,” in Proceedings of the USENIX Symposium on Internet Technologies and Systems (USITS), December 1997.

[5] B. Wang, S. Sen, M. Adler, and D. Towsley,

“Optimal Proxy Cache Allocation for Efficient Streaming Media Distribution, in Proc. IEEE INFOCOM, April 2001.

[6] K. L. Wu, P. S. Yu, and J. L. Wolf,

“Segment-Based Proxy Caching of Multimedia Streams,” ACM, May ,2001

[7] M. Arlitt, L. Cherkasova, J. Dilley, R. Friedrich,

and T. Jin, “Evaluating Content Management Techniques for Web Proxy Caches,” in Proceedings of the 4th International WWW Caching Workshop, April 1999.

[8] R. P. Wooster, “Optimizing Response Time,

Rather than Hit Rates, of WWW Proxy Cache,” Master’s thesis, Virginia Polytechnic Institute and State University, Blacksburg, Virginia, December 1996

[9] R. P. Wooster, and M. Abrams, “Proxy Caching

the Estimates Page Load Delay,” in Proceedings of the 6th International World Wide Web Conference, P.P 7–11, April 1997.

[10] S. Sen, J. Rexford, and D. Towsley, “Proxy

Prefix Caching for Multimedia Streams,” in Proc. IEEE INFOCOM, April 1999.