Proxy Server 之應用

逢 甲 大 學

資 訊 工 程 學 系 專 題 報 告

Proxy Server 之應用

方建佳 (四甲)

學

生： 陳昱祥 (四甲)

黃仲寧 (四甲)

指

導

教

授 ： 李維聰 老師

中華民國九十一年十二月

目 錄

第一章 前言--Proxy Server 運作原理..……….…..1 1.1 Proxy 的觀念與功能介紹………..……….…....1 1.2 Proxy 運作方式………..……….…....2 第二章 Squid 的安裝與設定……….……3 2.1 主要架構介紹…………..……….…...3 2.2 Squid 的安裝…………..……….…....3 2.3 Squid 的組織結構介紹………….……….….5 2.4 squid.conf 的設定…………..………...7

第三章 Apache 與 Proxy Server 的網頁整合………8

3.1 主要架構介紹…………..………8 3.2 Apache 的介紹與安裝目的……..………8 3.3 Apache 的安裝與設定………...………...9 3.4 網頁展示…..……….….12 第四章 Squid.conf 檔的介面管理………....13 4.1 主要架構介紹………..………..13 4.2 製作目的與功能…..………..13 4.3 介面管理…..………..14 4.4 介面操作與展示…..………..21 第五章 Proxy 的替換機制………23 5.1 主要架構………..……….…..23 5.2 快取的替換策略與修改………..………….……..25 5.3 排它性實驗………..……….……..32 5.4

實驗總結、分析與討論………..53

專題心得……….55

附錄 A……...………60 B………61

第一章 前言

Proxy Server 運作原理

1.1 Proxy 的觀念與功能介紹

代理伺服器（proxy server）設置的兩個主要目的：加強網路安 全及提升網路使用效率。 在加強網路安全方面，早期代理伺服器是作為內部網路與外部網 路之間的一個通道，所有要連到外面的網路流量皆要經過代理伺 服器，因而可以利用此特性，在代理伺服器加上管制的機制，控 制可連出去的點及所使用的通訊協定及管制由外部來的連線，進 而加強內部網路安全，也因而有時代理伺服器也可稱為防火牆 (firewall)。

近來，由於 Internet 的快速發展，全球資訊網(World Wide Web) 風靡整個 Internet，其通訊協定(http)所造成之網路流量達 80% 以上的使用頻寬，這對於原本對外網路頻寬不是很大的單位來說 是非常大的使用量，而這些 80%以上的網路流量當中，又有許多 是重複的資料，比如說，有三個人由台大利用 www 瀏覽器同時連 到蕃薯藤網站，如此就有三份同樣資料經由網路傳入台大區網， 等於網路頻寬使用浪費在資料重複傳輸上，這種情形在網路頻寬 大的地方是沒有感覺，但是對於頻寬小的連線來說，則是相當大 的浪費，尤其國際線路的租用上，更需要減少這一類的浪費，也 因此就有人利用代理(proxy)的觀念，來發展出一套提升網路使 用效率的運作機制，其主要的構想就是將前一個人所抓取的資 料，儲存在自己的區域網路伺服器上，當下一位使用者要抓相同 的資料時，就由這一個區域網路伺服器提供資料，達到此次對外 頻寬之節省﹔而這一個區域網路伺服器所扮演的腳色類似所謂 的快取伺服器(Cache Server)，它將所有經過的資料都儲存一份 備份，當有使用者提出需求時，它會先檢查自己的備份當中是否 有該資料，如有，則直接傳給使用者，如沒有，它將向外查詢， 取到資料後，存一份備份並傳給使用者。此外，代理伺服器除了 可以有備份資料外，它還有一項附加功能，就是資料過濾的能 力，它可以經由管理者的設定，來決定有哪些資訊必須被排除過 濾，或是可以重新導向使用者的需求到內部網路已有的資訊站， 進而節省對外頻寬。

1.2 Proxy 運作方式

Proxy 的基本運作情形如上所述，使用者端發出一個 http 的網頁 請求給代理伺服器，代理伺服器收到請求後，先檢查自己的快取 區是否有使用者所要的資料，如果有找到，則直接將資料傳給使 用者，結束此次的請求，如果查沒有使用者要的資訊時，則由代 理伺服器發出 http 的網頁請求給原來的網頁伺服器，待要到資 料後，代理伺服器先存一份資料在自己的快取區，再送這份資料 給使用者，然後就結束此次的請求。如下圖所示。

第二章 Squid 的安裝與設定

2.1 主要架構介紹

internet internet

2.2 Squid 的安裝

Squid 是一套相當知名的 Proxy Caching Server(快取代理者伺服 器)，專門用來加快讀取 http、ftp、gopher 等協定所傳出的資料。 當安裝 Redhat+Cle 的 Server 套件後，系統並不包含 Squid Proxy Server，除非使用 Custom 套件事先安裝或是事後自行安裝。安裝 Squid 程序相當簡單，程序如下:

1.#mount/mnt/cdrom。

2.#cd/mnt/cdrom/Redhet/RPMS/。 3.#rpm-Uvh squid-*。

在此所安裝的是 Squid-2.3.STABLE*版本，安裝好 Squid 後，Squid 尚未啟動，即使從新開機也不會啟動，需要使用 linuxconf 設定 Linux 一開機後就自動啟動 Squid，由以下步驟設定: 1. #setup。(啟動 setup) 2. 按一下「System services」項目。 3. 設定「squid」項目為 Enable。 4. 按一下「OK」、「Quit」。 P.S. 可到以下網站下載最新的 RPM 版本 Client Proxy server Web Server

http://www.acore.com.tw/~gau/works/rpms

若 Squid 想採用傳統的安裝方式，到 squid 官方網站

http://squid.nlanr.net 下載最新版的 Squid proxy。 接著設定如下: 1. #adduser-M squid :建立一新無個人空間的帳號 squid，並且隸屬於 squid 群組。 2. su squid :從 root 身分 su 成 squid。 3. % tar xzf squid-2.3.RELEASE-src.tar.gz 4. % cd squid-2.3.RELEASE 5. % ./configure :內定安裝 squid 的目錄為/usr/local/squid。 6. % make 7. % make install 8. % cd/usr/local/squid/bin 9. /usr/local/squid/bin/squid-z :製作快取目錄。 10. ./RunCache :執行 squid daemon 注意一: 若不清楚 configure 參數，可以執行% ./configure--help， 已獲悉完整的 configure 參數。

注意二：Squid Proxy 內設傳輸資料的 Port 是 3128，當您在瀏覽器 （如 IE、Netscape）裡使用 Proxy 選項時，請記得將 Proxy Server 的 Port 設定為：3128

2.3 Squid 的組織結構介紹

在真正規劃 Squid cache 與設定 Squid 組態檔之前，簡單的介紹 rpm 型態的 Squid 內定的目錄與檔案組織結構，以利於設定 Squid 組態檔 (/etc/squid.conf)。 squid 的檔案大致分為三類:組態檔、應用程式檔及各項紀錄檔(logs files)。對其他伺服器而言，或許紀錄檔不是挺重要的一部分，但是 對於 Squid 而言，紀錄檔族是相當的重要喔!

【Squid 的組態檔及結構】

rpm 格式的 squid，內定放置相關組態檔案的目錄是/etc/squid，其 完整結構如下所示: /etc/squid

|

--errorÆ /usr/lib/squid/errors/English ;錯誤時所用的語系

|

--mib.txt ;SQUID-MIB 定義檔

|

--mime.conf ;定義 Squid 所任式的 mine type

|

--mime.conf.default ;Squid 內定 mine type 檔

|

--squid.conf ;目前使用的 squid 組態檔

|

--squid.conf.default ;Squid 內定組態檔

【Squid 傳統安裝的組織結構】

本系統使用傳統 Compiler 方式安裝 squid，其內定的目錄安裝在 /usr/local/squid 目錄下,因此所有與 Squid 相關的檔案都在此目錄 下，其結構如下: /usr/local/squid

|

-- bin ;放置 squid 相關執行檔

|

|

--RunAccel

|

|

--RunCache ;執行 squid 的 Script

|

|

--cachemgr.cgi ;查看 squid 即時運作的程式

|

|

--client ;統計並顯示 digest table 的內容

|

|

--dnsserver ;輔助 squid 處理領域名稱解析

|

|

--squid ; squid daemon，主程式

|

、--unlinkd

|

-- etc ;放置 squid 相關組態檔

|

|

--errors

|

|

--icons

|

|

--mib.txt ;SQUID-MIB 定義檔

|

|

--mime.conf ;定義 squid 所任式的 mine type

|

|

--mime.conf.default ; squid 內定的 mine type 檔

|

|

--squid.conf ;目前使用的 squid 組態檔

|

、--squid.conf.default ; squid 內定組態檔 、--logs ;放置 logs 目錄

|

--access.log ;client 端使用 Proxy 的紀錄檔

|

--store.log ;儲存快取物件的狀態紀錄檔

、--cache.log ;cache 的啟動及各類狀態紀錄檔 此類架構由於將所有與 squid 相關的檔案，程式放置在

2.4 squid.conf 的設定

設定檔位置：/usr/local/squid/etc/squid.conf 修改下列各項設 定。 修改參數 注意事項 http_port 3128 將 # 註解拿掉 icp_port 3130 將 # 註解拿掉 cache_mem 8MB 將 # 註解拿掉 cache_peer 210.240.125.5 parent 3128 3130 設定上層為縣網的 proxy cache_dir ufs /usr/local/squid/cache 100 16 256 將 # 註解拿掉 cache_access_log /usr/local/squiid/logs/access.log 將 # 註解拿掉 cache_store_log /usr/local/squid/logs/store.log 將 # 註解拿掉 http_access deny all 預設為 deny

把她改為 allow http_access allow all

cache_effective_user nobody 將 # 註解拿掉 cache_effective_group nogroup cache_effective_group nobody 改為 nobody 並且 # 註解拿掉 logfile rotate 7

logfile rotate 1 替換 log 檔

第三章 Apache 與 Proxy Server 的網頁整合

3.1 主要架構介紹

internet Internet

3.2 Apache 的介紹與安裝目的

【

Apache 介紹

】

: 建立一個網站呢? 除了主機，作業系統與使用者所製作的網頁外，我 們還需要安裝一套能將網頁放到網路上讓其它人來存取的軟體，也就 是所謂的 Web Server。

Web Server 比較有名的有免費的 Apache,、Microsoft 的 Internet Information Server、 Netscape 的 Enterprise Server 等等。 而免費的 Apache Web server 具有比商業 Web server 不惶多讓的功 能與速度， 同時安裝與設定也十分地容易，由於這些特性使得 Apache 成為佔有率最高的 Web Server 軟體。此外 Apache 適用於各式的平 台上。它可以搭配安裝 Perl 達到執行 CGI 的功能。

【

安裝目的

】

: 為了能用cgi等www網頁控制proxyserver，所以必須要先架起apache 這個webserver， Client Proxy Server Apache Server Web Server

3.3 Apache 的安裝與設定

3.3.1 Apache 的安裝 先到以下網站抓 Apache 的壓縮檔 ftp://linux.sinica.edu.tw 接著執行以下指令 tar zxvf apache_1.3.26.tar.gz $ ./configure --prefix=/path/to/apache $ make $ make install (轉換 CGI 的執行權限) $ ./configure --prefix=/path/to/apache \ --enable-suexec \ --suexec-caller=www \ --suexec-usrdir=.www \ --suexec-docroot=/path/to/root/dir \ --suexec-logfile=/path/to/logdir/suexec_log \ --suexec-uidmin=1000 \ --suexec-gidmin=1000 \ --suexec-safepath=”/bin:/usr /bin” //此段下指令時是要寫成一行，此處使用 \ 分行符號將它寫成好幾 行 $ make $ make install 3.3.2 httpd.conf、srm.conf 與 access.conf 檔的設定 httpd.conf 檔修改的部分如下 #

# ServerRoot: The top of the directory tree under which the server's

# configuration, error, and log files are kept. #

# NOTE! If you intend to place this on an NFS (or otherwise network)

# mounted filesystem then please read the LockFile documentation

# (available at

<URL:http://www.apache.org/docs/mod/core.html#lockfile>); # you will save yourself a lot of trouble.

#

ServerRoot "/usr/local/apache" #

# ServerAdmin: Your address, where problems with the server should be

# e-mailed. This address appears on some server-generated pages, such # as error documents. # ServerAdmin sam@FcuProxy #ServerName FcuProxy #

# "/usr/local/apache/cgi-bin" should be changed to whatever your ScriptAliased

# CGI directory exists, if you have that configured. #

<Directory "/usr/local/apache/cgi-bin"> AllowOverride None

Options None Order allow,deny Allow from all </Directory>

接下來是 Access.conf 檔，原本裡面是空的，需要加上以下指令。 此檔最主要是設定哪些目錄市開放共享的目錄，如此就可以將網頁放 置這些區域

##

## access.conf -- Apache HTTP server configuration file ##

#

# This is the default file for the AccessConfig directive in httpd.conf.

# It is processed after httpd.conf and srm.conf. #

# To avoid confusion, it is recommended that you put all of your # Apache server directives into the httpd.conf file and leave this

# one essentially empty. #

<Directory /home/*/www>

Options Indexes Includes FollowSymLinks AllowOverride None

order allow,deny allow from all </DirectorY> <Directory /home/*/cgi-bin> Options ExecCGI AllowOverride None </DirectorY> 最後是 srm.conf 檔，原本裡面是空的，需要加上以下指令。 此檔案中有些重要的命令與 Web Server 有很大的關係。 ##

## srm.conf -- Apache HTTP server configuration file ##

#

# This is the default file for the ResourceConfig directive in httpd.conf.

# It is processed after httpd.conf but before access.conf. #

# To avoid confusion, it is recommended that you put all of your # Apache server directives into the httpd.conf file and leave this

# one essentially empty. #

DocumentRoot /usr/httpd/html UserDir www

DirectoryIndex index.html index.htm index.shtml index.cgi sam.htm sam.html

3.4 網頁展示

第四章 Squid.conf 檔的介面管理

4.1 主要架構介紹:

透過 cgi 可輕易的修改 squid.conf 檔的設定

internet

4.2 製作目的與功能:

目的: 因為在實驗過程中，更改 Max_Object_Size 須先登入主機，找出 Squid 的設定檔 squid.conf 修改後，再重新載入 squid.conf， 過程十分繁瑣，故目的在於簡化過程。 功能: 將需更改的部分藉由網頁來做修改，透過 CGI 程式將修改的資料 傳回主機同步修改 squid.conf，節省時間 Client Proxy Server Apache Server CGI 管理介面

4.3 介面管理

使用語言: Perl 語言。 4.2.1 程式製作流程: Identify.cgi 的流程： 1.使用者名稱與密碼檢查，若符合則登入成功。 2.若登入的使用者為系統管理員帳號，則進入修改畫面，若為一般使 用者，則進入一般畫面。如下圖所示: 系統管理員 一般使用者 Else Check.cgi 的流程： 1. 讀取表單上的資料。 2. 經由常規式後將各個資料分開。 3. 一行一行讀取 squid.conf 檔，存入一 TEMP 的陣列中，比較若每 行 squid.conf 中的設定與要修改的部分吻合的話，則修改後再存入 TEMP 陣列中。 4. 完成後重新將 TEMP 陣列的資料存入 squid.conf 中，並藉由系統 呼叫重新載入 squid.conf。 5.將修改過的 squid.conf show 至銀幕上，以檢查是否有修改。 如下圖所示: LOGIN CGI 管理介面 一般畫面 If = id && psword Access deny

System call Reload

4.2.2 Source Code

identify.cgi：驗證使用者的登入 #!/usr/bin/perl -w

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); @pairs = split(/&/, $buffer);

foreach $pair (@pairs) {

($name, $value) = split(/=/, $pair); $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $value =~ s/<!--(.|\n)*-->//g; $FORM{$name} = $value; } open (PEOPLE,"people.lst"); @lines = <PEOPLE>; close (PEOPLE);

foreach $line (@lines) {

($realname, $realpassword) = split(/ /,$line);

Data 讀取 && 常規式 Temp Squid.conf Show squid.conf 比較與 修改

chomp($realpassword); $realname =~ tr/A-Z/a-z/; $pwordlist{$realname}=$realpassword; } if (!$pwordlist{$FORM{'username'}}) {

print "Content-type: text/html\n\n"; print <<"ERROR01";

<?xml version = "1.0"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml"> <head> <title>禁止進入</title> </head> <body> <h1>禁止進入</h1> <p>錯誤的使用者名稱</p>

<p><a href = "//140.134.25.20/login.html">請重新嘗試 </a></p>

</html> ERROR01 }

elsif ($FORM{'password'} ne $pwordlist{$FORM{'username'}}) {

print "Content-type: text/html\n\n"; print <<"ERROR02";

<?xml version = "1.0"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml">

<head>

</head> <body>

<h1>禁止進入</h1> <p>密碼錯誤</p>

<p><a href = "//140.134.25.20/login.html">請重新嘗試 </a></p>

</html> ERROR02 }

elsif ($FORM{'username'} ne "admin") {

print "Content-type: text/html\n\n"; print <<"NORMAL";

<?xml version = "1.0"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml"> <head> <title>一般登入</title> </head> <body> <h1>squid.conf 檔的全部內容</h1> <hr /> <p>哈哈哈</p> <center> <p>若要修改請用管理者身份<a href = "//140.134.25.20/login.html">登入</a></p> </center> </html> NORMAL } else {

print "Content-type: text/html\n\n"; print <<"MAIN";

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml"> <head> <title>Main Page</title> </head> <frameset cols = "200,*">

<frame name = "leftframe" src = "//140.134.25.20/list.html" />

<frame name = "main" src = "//140.134.25.20/main.html" /> </frameset> </html> MAIN } check.cgi：將傳回的資料處理後，存入 squid.conf，再重新載入 #!/usr/bin/perl -w

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); @pairs = split(/&/, $buffer);

foreach $pair (@pairs) {

($name, $value) = split(/=/, $pair); $value =~ tr/+/ /; $FORM{$name} = $value; } open (RCONF,"/etc/squid/squid.conf"); $check = <RCONF>; $count = 0; while ($check) { $temp[$count] = $check;

if ($result = $check =~ /\bhttp_port/) {

}

elsif ($result = $check =~ /\bicp_port/) {

$temp[$count] = "icp_port $FORM{'icpport'}\n"; }

elsif ($result = $check =~ /\bcache_mem/) {

$temp[$count] = "cache_mem $FORM{'cachemem'} MB\n"; }

elsif ($result = $check =~ /maximum_object_size\b/) {

$temp[$count] = "maximum_object_size $FORM{'maximum'} KB\n"; } $check = <RCONF>; $count++; } close (RCONF); open (WCONF,">/etc/squid/squid.conf"); for ($i = 0; $i < $count ; $i++)

{

print WCONF ($temp[$i]); }

close (WCONF);

system ("/usr/sbin/squid -k reconfigure"); open (SHOW,"/etc/squid/squid.conf");

@show = <SHOW>; close (SHOW);

print "Content-type: text/html\n\n"; print <<"TEST";

<?xml version = "1.0"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml">

<head> <title>修改完成</title> </head> <body> <h1>修改結果</h1> <hr> <p>@show</p>

<a href = "//140.134.25.20/login.html" target = "_top">按此回到首頁</a>

</html> TEST

4.4 介面操作與展示

<Figure 4.1 CGI 登錄畫面>

當輸入適當的帳號與密碼後，按下 Submit 鍵，

就可進入 Squid.conf 的管理介面。

進入到以下圖 4.2 的畫面後,可依照個人喜好來設定 squid

的 configuration 檔。

第五章 Proxy 的替換機制

5.1 主要架構:

HTTP Request if cache miss

intenet

internet

5.1.1 目的:

根據許多的研究數據均顯示出網際網路之使用已是一股銳不可檔的 新潮流，且將影響人類生活型態甚鉅，而各國也都積極地規劃因應之 道。而在上網時候，經常去的網頁希望能讀的愈快愈好，在網路上除 了檔案有大有小之外，還有距離長短、速度快慢、連線品質等問題， 這些都是不容易變動的，想一些能加速上網的策略是必要的。 有鑑於快取空間的排擠效應以及各網頁物件組群的再用程度不一等 因素下，我們使用了「快取排它策略」應用於網頁代理快取伺服器 (WebPCS)，藉以提升快取系統效能。 5.1.2 何謂快取排它策略: 排他性策略是達到加速上網效率的策略之一。在上網時對路過 proxy 檔案做限制，就像是檔案大小、距離長短、速度快慢、連線品質、主 機位置、上線時間等，像是檔案大的就不放在 proxy 的快取裡，或是 連線速度很快的、主機位置很近的、區網內的不放在 proxy 的快取 Client Proxy Server Apache Server CGI 管理介面 Web Server Replacement cache

裡，這些都可以設定，只需更動 config 檔而不需更動軟體基礎架構 即可增加效能，但有些網路品質不佳，proxy 都不建議設，也是策略 的一種。也就是說，傳統式的 WebPCS 對於網頁物件是否給予快取， 原則上並未設定任何的限制條件。意即任何大小的檔案皆可給予快 取。而在 WebPCS 中設置一「快取排它門檻」條件，用以篩選具備高 再用性的網頁物件作為快取對象，此一機制稱之為「快取排它策略」。 5.1.3 主要實作方法: 以網頁物件之「資料量」大小劃分群組,再以組群物件平估因子做快取 分析,以期研判出影響快取效能的相關因素,藉以歸納出各不同群組所 呈現的再用性，以及判斷何種替代機制效能較好。而由於 WebPCS 所快 取的物件類型種類繁多，用戶端群所瀏覽的網頁意向也不相同，故不 易去評估一個網頁繼續保留於快去中的使用價值。故本實驗以組員自 己設計的網頁為主要實驗網頁。 本章專題製作步驟如下: 1. squid 中去尋找其替換機制位置，試圖加入排他性功能。 2. 製作欲實驗的網頁。 3. 以組群物件方式來分析 WebPCS 之快取效能，實作一效能模擬系 統，一組為對照組，一組為實驗組，用以驗證與探討此快取排它策 略的實質效應。

5.2 快取的替換策略與修改

5.2.1 Squid 替換策略的介紹:

根據指導教授的建議，為了完成排他性實驗，在 squid 中去尋找其替 換機制位置，試圖加入排他性功能。

這個強大的網路伺服器 proxy server 軟體 squid，是用 c 語言去寫的， 1mb 的檔案裡面有著完美的變數宣告與註解，花了一段時間之後，找 到了替換機制，發現在當初設計的時候就有加入 3 種替換機制。 1.LRU(Least Recently Used)：使用最近使用策略,以最久未使用的

物件作為替換。

2.GDSF(Greedy-Dual Size Frequency)：依照使用頻率大小貪婪抓取 策略。

3.LFUDA( Least Frequently Used with Dynamic Aging)：使用最常 使用策略，以物件的命中次數為取代的根據。

以下對 GDSF 策略與 LFUDA 策略有更進一步的說明:

當磁碟空間的需求不夠時，替代機制的參數決定物件將被替換。Squid 通常只有一個替代機制,LRU。但，當建了 DHEAP_REPLACEMENT， 可以選擇兩種新的替代機制,以提高策略的運用;

GDSF: Greedy-Dual Size Frequency

LFUDA: Least Frequently Used with Dynamic Aging

這兩種機制都是以”frequency”基礎的，其效能比以”recency”為 基礎的 LRU 還好。 GDSF 策略是由保留 cache 裡小檔且常用的物件，使物件的命中率達 到最佳化，所以這策略有比較好的命中率。雖然即使這替換機制排除 了較大的物件(也許常用)，但它對於較小位元的物件命中率卻優於 LFUDA。 LFUDA 策略是將常用的物件皆保留在 cache 中,而不管物件的大小。 較大，較常用的物件將會被保留在 cache 中，如此一來，cache 空間 不會被較小且較不常用的物件給佔用

5.2.2 Squid 替換機制的尋找

所以，squid 內建三種替換機制(replacement policy)，方便使用者 選擇，你可以在安裝好 squid 的機器中的

/etc/squid/squid.conf.default，去找到這標記： #TAG: replacement_policy

#The cache replacement policy parameter determines which objects are evicted #(replaced) when disk space is needed. #Squid used to have only a single replacement policy, LRU. ………… replacement_policy LFUDA 由此得知預設替換機制是 LFUDA。 在安裝前，替換機制是放在 store_heap_replacement.c 中等待安裝 連結，在 squid 裡面檔案是由指標(point)加累堆(heap)的倍精準函 數構成。 store_heap_replacement.c 如下： static heap_key

HeapKeyGen_StoreEntry_LFUDA(void *entry, double age) {

StoreEntry *e = entry; double tie;

if (e->lastref <= 0) tie = 0.0;

else if (squid_curtime <= e->lastref) tie = 0.0;

else

tie = 1.0 - exp((double) (e->lastref - squid_curtime) / 86400.0);

return age + (double) e->refcount - tie; }

static heap_key

HeapKeyGen_StoreEntry_GDSF(void *entry, double age) {

double size = e->swap_file_sz ? (double) e->swap_file_sz : 1.0;

double tie = (e->lastref > 1) ? (1.0 / e->lastref) : 1.0; return age + ((double) e->refcount / size) - tie;

}

static heap_key

HeapKeyGen_StoreEntry_LRU(void *entry, double age) {

StoreEntry *e = entry;

return (heap_key) e->lastref; }

另外，在 store.c 亦可找到下列這一段 void storeInit(void)函式， 該段有給使用替換機制做控制，void storeInit(void)如下： void storeInit(void) { storeKeyInit(); storeInitHashValues(); store_table = hash_create(storeKeyHashCmp, store_hash_buckets, storeKeyHashHash); storeDigestInit(); storeLogOpen(); #if HEAP_REPLACEMENT

inmem_heap = new_heap(1000, HeapKeyGen_StoreEntry_GDSF); if (Config.replPolicy) {

if (tolower(Config.replPolicy[0]) == 'g') {

debug(20, 1) ("Using GDSF disk replacement policy\n"); store_heap = new_heap(10000,

HeapKeyGen_StoreEntry_GDSF);

} else if (tolower(Config.replPolicy[0]) == 'l') { if (tolower(Config.replPolicy[1]) == 'f') {

debug(20, 1) ("Using LFUDA disk replacement policy\n"); store_heap = new_heap(10000,

HeapKeyGen_StoreEntry_LFUDA);

debug(20, 1) ("Using LRU heap disk replacement policy\n"); store_heap = new_heap(10000, HeapKeyGen_StoreEntry_LRU); } } else {

debug(20, 1) ("Unrecognized replacement_policy; using GDSF\n");

store_heap = new_heap(10000, HeapKeyGen_StoreEntry_GDSF);

}

} else {

debug(20, 1) ("Using default disk replacement policy (GDSF)\n");

store_heap = new_heap(10000, HeapKeyGen_StoreEntry_GDSF); }

#else

store_list.head = store_list.tail = NULL; inmem_list.head = inmem_list.tail = NULL; #endif

stackInit(&LateReleaseStack);

eventAdd("storeLateRelease", storeLateRelease, NULL, 1.0, 1);

storeDirInit();

storeRebuildStart();

cachemgrRegister("storedir", "Store Directory Stats", storeDirStats, 0, 1); cachemgrRegister("store_check_cachable_stats", "storeCheckCachable() Stats", storeCheckCachableStats, 0, 1); } 知道了替換機制的位置，那是哪裡在使用這個替換機制？ 原先研究方向是設法在 squid 原始碼裡面，替換機制的位置中加入一 行類似 if 的內容，讓 squid 得到排他性的功能，為了更了解程式， 於是追朔程式宣告源頭，找呼叫替換機制的位置，一方面 email 致函

請教排他性實驗的先人，得知〝無須更動該 proxy 之 rep. policy.〞，

5.2.3 Squid 替換機制的修改 到 squid.conf 找出下列兩有用的標記：Cache_Mem 與 Maximum_Object_Size。 Cache_Mem 是用來指定快取使用的記憶體容量上限； Maximum_Object_Size 是指定快取網頁物件容量上限，超過此限物件 不予快取。 你可以在安裝好 squid 的機器中的 /etc/squid/squid.conf.default，去找到這標記： #cache_mem 8 MB #maximum_object_size 4096 KB 由此得知預設網頁物件容量上限是 4MB(4096 KB)，只要將 maximum_object_size 此項數值降低，在快取抓網頁物件時，就會過 濾調較大的檔案，即可完成排他性實驗。

在安裝前，maximum_object_size 是放在 store.c 中，在 store.c 可 找到下列這一段 int storeCheckCachable(StoreEntry * e)函式， 該段有使用 maximum_object_size 對快取空間做控制，仔細看 Config.Store.maxObjectSize 這個變數，就是由該變數過濾網頁物 件，也就是說 store.c 的 Config.Store.maxObjectSize 就是

squid.conf 裡的 maximum_object_size 標記。 int storeCheckCachable(StoreEntry * e)如下： int

storeCheckCachable(StoreEntry * e) {

#if CACHE_ALL_METHODS

if (e->mem_obj->method != METHOD_GET) {

debug(20, 2) ("storeCheckCachable: NO: non-GET method\n"); store_check_cachable_hist.no.non_get++;

} else #endif

if (!EBIT_TEST(e->flags, ENTRY_CACHABLE)) {

debug(20, 2) ("storeCheckCachable: NO: not cachable\n"); store_check_cachable_hist.no.not_entry_cachable++;

} else if (EBIT_TEST(e->flags, RELEASE_REQUEST)) { debug(20, 2) ("storeCheckCachable: NO: release requested\n");

} else if (e->store_status == STORE_OK && EBIT_TEST(e->flags, ENTRY_BAD_LENGTH)) {

debug(20, 2) ("storeCheckCachable: NO: wrong content-length\n");

store_check_cachable_hist.no.wrong_content_length++; } else if (EBIT_TEST(e->flags, ENTRY_NEGCACHED)) {

debug(20, 3) ("storeCheckCachable: NO: negative cached\n");

store_check_cachable_hist.no.negative_cached++; return 0; /* avoid release call below */ } else if (e->mem_obj->inmem_hi >

Config.Store.maxObjectSize) {

debug(20, 2) ("storeCheckCachable: NO: too big\n"); store_check_cachable_hist.no.too_big++;

} else if (e->mem_obj->reply->content_length > (int) Config.Store.maxObjectSize) {

debug(20, 2) ("storeCheckCachable: NO: too big\n"); store_check_cachable_hist.no.too_big++;

} else if (storeCheckTooSmall(e)) {

debug(20, 2) ("storeCheckCachable: NO: too small\n"); store_check_cachable_hist.no.too_small++;

} else if (EBIT_TEST(e->flags, KEY_PRIVATE)) {

debug(20, 3) ("storeCheckCachable: NO: private key\n"); store_check_cachable_hist.no.private_key++;

} else if (e->swap_status != SWAPOUT_NONE) { /*

* here we checked the swap_status because the remaining * cases are only relevant only if we haven't started swapping

* out the object yet.

*/

return 1;

} else if (storeTooManyDiskFilesOpen()) {

debug(20, 2) ("storeCheckCachable: NO: too many disk files open\n");

store_check_cachable_hist.no.too_many_open_files++; } else if (fdNFree() < RESERVED_FD) {

open\n");

store_check_cachable_hist.no.too_many_open_fds++; #if HEAP_REPLACEMENT

/*

* With the HEAP-based replacement policies a low reference * age should not prevent cacheability of an object. We * do not use LRU age at all.

*/

#else

} else if (storeExpiredReferenceAge() < 300) {

debug(20, 2) ("storeCheckCachable: NO: LRU Age = %d\n", storeExpiredReferenceAge()); store_check_cachable_hist.no.lru_age_too_low++; #endif } else { store_check_cachable_hist.yes.Default++; return 1; } storeReleaseRequest(e); EBIT_CLR(e->flags, ENTRY_CACHABLE); return 0; } squid 內建強大功能，使用者可以利用 config 的標記加以控制，連 網頁物件容量上限亦可數值修正，過濾檔案，〝無須更動該 proxy 之 rep. policy.〞

5.3 排它性實驗

5.3.1 作業程序介紹 本排他性(evictor)實驗是參考「物件導向技術及應用研討會」內容 中的篇論文，關於這方面有 email 致函請教，獲益匪淺，受益良多。 這一次的排他實驗中讓我有許些體認到排他性的確有增加瀏覽網路 的效能。在檔案的部分，設小型檔為 16kb 以下，中型檔居 16 至 256kb 之間，大型檔在 256kb 以上，根據指導教授的建議，我將網頁結構分 成 5 種類型： 1.小型檔居多的網頁：最常見於網際網路的網頁，一個網頁裡面，放 了大量的文字或小圖形，所有的物件加起來不超過 1mb 的網頁，(簡 稱：小)，如下圖所示:

2.小檔多包含中型檔的網頁：一個網頁裡面，除了文字與小圖形，也 有包含 16kb 以上的物件圖，所有的物件加起來不超過 1mb 的網頁(簡 稱：小中)，如下圖所示: 3.小中大檔皆有的網頁：第二常見於網際網路的網頁，圖文並茂的網 頁內放了圖片文字與音樂，小中大物件都有。(簡稱：小中大)， 如下圖所示:

4.中型檔多包含少量大檔的網頁：放了中型檔圖形，所有的物件加起 來超過 1mb 的網頁，(簡稱：中大)，如下圖所示:

5.大型檔的網頁：寬評專用的網頁，線上音樂或多媒體引片一個網頁 裡面，放了大量的文字或小圖形，所有的物件加起來不超過 1mb 的 網頁，(簡稱：大)，如下圖所示:

根據指導教授的建議，在相同得網路速度之下，也對一些不同大小順 序的存取做試驗，試圖整理思考出其置換定理與排他性的效用，以下 大小順序用上面的編號，1 為小，2 為小中，以此類推。 以下為樣本類型: # 類型 總容量 檔案數量 特性 網頁代號 1. 小 338kb 52 檔,51 小檔,1 中檔 - nt07 2. 小中 750kb 47 檔,43 小檔,4 中檔 - nt05 3. 小中大 3.39mb 29 檔,20 小檔,6 中檔,3 大檔 2mb 的 mp3 nt04 4. 中大 2.00mb 12 檔,10 中檔,2 大檔 1mb 的 bmp nt08 5. 大 4.41mb 6 檔,2 中檔,4 大檔 3mb 的 mp3 nt09 【實驗方法】：碼表。 以人工方式判斷瀏覽器下載完檔案，決定全程時間大小。

【設定方式】：更動 config 檔，使用專為 proxy server 設計的 cgi

檔來更改 proxy-server.conf 檔之 Cache_Mem 值與 Maximum_Object_Size 值，Cache_Mem 是用來指定快取使用的記憶體容量上限； Maximum_Object_Size 是指定快取網頁物件容量上限，超過此限物件 不予快取。 【清空 cache】:為了確保實驗的準確性，必須在每次不同的實驗下 執 行清空 chche 這個動作。 cd /var/spool/squid//etc/rc.d/init.d/squid stop rm -rf 00 ~ 03 /usr/sbin/./squid -z cd /var/spool/squid//etc/rc.d/init.d/squid start

5.3.2 實驗一 Cache_Mem=6MB 無排他性 Maximum_Object_Size=4096KB 順序瀏覽時間統計(單位:min’sec) 註:若無特別標明,其測試環境皆在 T1 環境下測試 順序 #1 #2 #3 #4 #5 #6 6.47 6.57 6.59 6.63 6.76 1,1,1,1,1,1 (512/512 kb/s) 7.82 平均:6.604 10.89 10.79 10.52 12.51 12.03 2,2,2,2,2,2 (512/512 kb/s) 12.01 平均:11.348 24.13 26.13 26.32 24.19 24.66 3,3,3,3,3,3 26.06 平均:25.086 29.56 30.93 28.50 29.77 28.49 4,4,4,4,4,4 (512/512 kb/s) 30.12 平均:29.45 33.21 33.65 34.17 31.57 33.57 5,5,5,5,5,5 34.59 平均:33.234 4.23 7.09 3.02 6.67 2.79 5.97 2.87 5.95 平均:4.845 平均:4.38 平均:4.41 12,121212 平均:5.66 總平均:4.545 4.49 35.59 3.09 35.91 2.77 33.92 3.3 32.38 平均:19.5 平 均:18.345 平均:17.84 15,151515 平均:20.195 總平均:18.562 34.14 24.1 2 3.6 2 33.2 3 23.8 3 3.5 9 31. 37 24. 29 2.64 31.6 0 23.7 9 3.52 平均:20.20 平均:19.43 平均:19.63 531,53153153 1 平均:20.627 總平均:19.753 25.09 16.9 2 33.1 9 26.38 16.0 3 31.9 9 23. 45 16. 78 33.0 1 24.5 9 16.3 9 32.8 4 平均:24.8 平 均:24.413 平 均:24.606 345,34534534 5 平均:25.067 總平均:24.624

有排他性 Maximum_Object_Size=512KB 順序瀏覽時間統計(單位:min’sec) 註:若無特別標明,其測試環境皆在 T1 環境下測試 順序 #1 #2 #3 #4 #5 #6 25.28 25.77 24.85 27.09 24.33 3,3,3,3,3,3 26.02 平均:25.464 15.73 15.58 15.56 15.69 15.45 4,4,4,4,4,4 (512/512 kb/s) 16.83 平均:15.602 32.67 31.84 32.83 31.98 32.11 5,5,5,5,5,5 37.13 平均:32.286 6.69 33.09 2.96 33.10 2.91 32.95 2.95 34.63 平均:18.03 平均:17.93 平均:18.79 15,151515 平均:19.89 總平均:18.25 34.56 23.1 5 3.1 5 34.1 3 26.1 3 3.2 9 34. 95 27. 50 2.72 35.7 8 26.2 3 3.05 平均:21.18 平均:21.72 平均:21.68 531,53153153 1 平均:20.29 總平均:21.52 25.47 16.3 5 33.0 0 24.83 16.0 2 32.1 5 24. 33 15. 73 32.9 7 24.2 9 15.3 7 32.7 平均:24.33 平 均:24.343 平均:24.12 345,34534534 5 平均:24.94 總平均:24.264 比較: 註:( )代表各類型 存取速度的比較大 小 第一次(無 cache) 無排他性 有排他性 333333 26.06 (3) 25.086 (1) 25.464 (2) 444444 30.12 29.45 15.602 555555 34.59 (3) 33.234 (1) 32.286 (2) 15151515 20.195 (3) 18.562 (2) 18.25 (1) 531531531531 20.627 (2) 19.753 (1) 21.52 (3)

問題討論: 由此實驗結果得知，第一次存取所花的時間比有排它性及無排它性的 存取時間來的多一些，而無排它的策略在一些實驗下發現比有排它性 所花的時間來的大,因為無排它性的策略有花時間在 swaping 置換檔 案，所以排他性可以減少這類的時間浪費。 但是，以時間上的差別來看，幾乎第一次存取、無排它性策略與排它 性策略的時間只相差 1~2 秒鐘，若再考慮誤差的因素來看，感覺上這 三種實驗情況所得到的數據並沒有太大的差別。 所以經過檢討與跟指導教授的討論後，發現到由於我們的測試網頁放 在 Knight 主機上，而 Proxy Server 與 Knight 主機十分近，且兩者 之間的速度為 100M，所以即使 Cache Miss 後，要到 Web Server 抓 資料，這段路徑所花的時間是非常之短，所以才會顯示這三組實驗的 平均數據不相上下。如下圖所示: If cache miss FCU 100M 100M internet T1 Knight Cache Home Pc

實驗二:

經由第一次的實驗後，這次的實驗我們將改變 Web Server 的位置， 以更換 Proxy Server 與測試網頁的 Router，目的是使 Proxy Server 與 Web Server 之間的網路速度變慢，而 Client 端到 Proxy Server 之間的網路速度是快速的，如此一來，才能突顯出有無 Cache 與有無 排它性策略的明顯差別。如下圖所示: if cache miss internet 慢 Internet T1 討論: 第二次實驗立即遇到的困難。 第二次實驗指導教授希望我們在學校網路實驗室裡面上網，藉由我們 的 proxy server 連到外面固定 ip 的網頁(203.217.100.147)測試， 實驗時的一點小失誤讓我們有所新發現，測試數據出來時，就發現了 一個大問題： 網頁只要連過一次，即使把我們的 proxy server 快取刪除，速度依 然等同快取時候的速度，這問題也在學校以外的 T1 網路證實過，快 取刪除後速度與快取到時候的速度差不了多少，感覺像是快取到了一 樣。 Web Server Cache Home Pc

以下是 T1 連 203.217.100.147 實驗網頁的部分數據 1.先測試組 有排他性 Maximum_Object_Size=512KB 順序瀏覽累計時間 (單位：min’sec) 2.後測試組 無排他性 Maximum_Object_Size=4096KB 順序瀏覽累計時間 (單位：min’sec) 測試 #1 #2 #3 #4 #5 #6 #1 #2 #3 … 1.小 28.5 9.29 9.49 9.31 9.46 9.61 9.76 9.61 9.50 … 4.中 大 1,56.27 41.33 41.63 41.11 40.76 41.11 41.86 41.10 41.70 … 5.大 >4 分鐘 52.11 52.13 51.63 52.68 53.69 54.63 53.80 54.10 … 以下是學校網路實驗室連 203.217.100.147 實驗網頁的部分數據 1.先測試組 無排他性 Maximum_Object_Size=4096KB 順序瀏覽累計時間 (單位：min’sec) 2.後測試組 有排他性 Maximum_Object_Size=25 6KB 順序瀏覽累計時間 (單位：min’sec) 測試 #1 #2 #3 #4 #5 #6 #1 #2 1.小 6.53 4.63 4.55 4.49 4.33 4.29 4.34 … 2.小中 37.21 5.47 5.15 5.40 5.43 5.37 5.41 … 3.小中大 50.13 5.62 5.55 5.76 5.85 5.45 5.63 … 4.中大 1’55. 36 12.30 13.15 12.30 13.22 12.19 12.32 … 5.大 2’10. 99 15.34 14.98 14.83 15.68 15.23 15.01 …

當在測量第五個實驗數據時，嚐試了將 proxy server 的 cache 刪除 後，再重新 load 一次，但發現測得的數據結果卻跟沒有將 cache 刪 除前的結果接近。 這樣的試驗感覺上是當連到外面的網域時會先路過某台機器，而此機 器會 cache 一份我們所需求的測試網頁。 經過我們的推測與跟老師的討論，得知我們的 proxy server 會先路 過〝逢甲大學 proxy server〞才會連到外面去，只要一連上網頁，〝逢

甲大學 proxy server〞就會先幫我們存起來，相當於〝逢甲大學 proxy server〞為 proxy 的 parent 而我們的 proxy 為 child。

如下圖所示: internet 第一次 cache miss Parent 期望的路徑 100M 第二次後的 cache miss 100M child 為了改善不利於我們測量準確性的環境，所以在 203.217.100.147 的 地方增設許多數量相同大小不同資料夾的測試網頁，供給我們多做幾 組數據，因為不同路徑無論是大小或是檔名相同的檔案，proxy server 都一定要〝快取〞到。但是，當測試排他性時，卻發現結果 依然錯誤。 因為〝逢甲大學 proxy server〞的機器並沒有排他性，也就是說， 即使我們的 proxy server 產生排他，但〝逢甲大學 proxy server〞 並沒有排他的機制，以致於在擷取所需的較大檔的網頁是直接向 parent 讀取，並不符合我們所要測試的環境要求。 Web Server Home Pc Proxy server Cach 學校的 server Cache

如下圖所示: internet 第一次 cache miss parent 排他後， 期望的路徑 排他後的 cache miss child 基於受到〝逢甲大學 proxy server〞的限制，小組討論後，決定找 另一個 ip 做實驗。 Web Server Home Pc Proxy server Cach 學校的 server Cache

實驗三：

由於前兩次實驗環境的因素導致數據的不正確，經過分析討論後，將 proxy server 與 web server 再做一次適當的環境調整(如下圖所 示)，測試的網頁資料也有做稍微的調整修改。以下為調整後所測得 的完整實驗資料與數據。 Proxy server: Web server: 140.134.4.20 10M internet T1 以下是修改後測試的網頁的格式，位置在 140.134.4.20 的學生網頁 上。 1.小 73 檔,73 小檔,小於 30kb 共 1.57mb nt11 2.小中 62 檔,50 小檔,12 中檔 共 1.91mb nt14 3.小中大 30 檔,20 小檔,9 中檔,2 大檔 共 2.73mb nt04a 4.中大 _{13 檔,272~724Kb 之間 共 5.85mb nt12} 5.大 4 大檔,741~2793Kb 共 7.37mb nt13 User Web Server Proxy Server

測試一: 無排他 Cache:100M Maximum_Object_Size=4096KB (單位:min’sec) 測量 #1 #2 #3 #4 #5 #6 1.09 1.40 1.76 1.75 2.06 1,1,1,1,1 9.29 平均:1.612 2.21 2.18 2.35 2.06 2.20 2,2,2,2,2 14.56 平均:2.2 2.77 2.70 2.74 2.78 2.97 3,3,3,3,3 17.91 平均:2.792 5.92 5.97 6.02 6.12 5.80 4,4,4,4,4 40.64 平均:5.822 15.99 14.83 15.02 15.10 15.45 5,5,5,5,5 51.97 平均:15.278 討論: 以上的測試，主要是為了確認有快取與沒有快取在存取資料所花費的 時間上有懸殊的差別。

測試二: 對照組:無排他 Cache:2MB Maximum_Object_Size=4096KB (單位:min’sec) #1 9.45 14.66 #2 9.28 14.68 #3 9.20 14.40 #4 9.16 14.33 #5 9.37 14.55 1,2 Total:24.11 (Total)平均:23.7425 #1 14.53 18.00 41.42 #2 14.82 17.66 40.61 #3 13.84 18.08 41.20 #4 15.08 18.24 41.70 #5 15.13 17.59 41.03 2,3,4 Total:73.59 (Total)平均:73.73 #1 17.74 14.55 8.99 #2 17.41 13.75 9.28 #3 17.48 14.13 9.07 #4 17.87 14.45 9.76 #5 17.95 14.20 9.46 3,2,1 Total:41.28 (Total)平均:41.202 #1 9.29 41.44 50.58 #2 9.22 40.81 51.10 #3 9.06 40.27 50.87 #4 9.17 41.04 50.52 #5 9.39 41.17 50.95 1,4,5 Total:101.31 (Total)平均:100.768 實驗組:排他性 Cache:2MB Maximum_Object_Size=128KB (單位:min’sec) #1 9.31 14.55 #2 9.24 15.09 #3 9.15 14.46 #4 9.42 15.02 #5 9.18 14.99 1,2 Total:23.86 (Total)平均:24.138 #1 14.59 17.79 40.45 #2 9.92 14.84 40.10 #3 10.07 14.87 40.09 #4 9.58 15.07 40.22 #5 9.64 14.74 40.13 2,3,4 Total:72.83 (Total)平均:64.872 #1 17.90 15.37 9.15 #2 18.07 14.53 9.17 #3 17.79 14.08 9.30 #4 17.86 14.30 9.54 #5 18.01 14.59 9.39 3,2,1 Total:42.42 (Total)平均:41.658 #1 9.40 40.33 50.80 #2 1.66 40.13 50.72 #3 1.62 40.32 50.67 #4 1.81 40.75 50.57 #5 1.73 40.18 50.81 1,4,5 Total:100.53 (Total)平均:92.742

比較: (單位:min’sec) 測試 Cache=2MB 無排他性 排他性 (Max=128KB) 排他與無排他 比較 誤差:約 2(s) 1,2 23.7425 24.138 相等 3,2,1 41.202 41.658 相等 2,3,4 73.73 64.872 排他性快 (約 9 秒) 1,4,5 100.768 92.742 排他性快 (約 8 秒) 討論: 由以上兩組實驗與對照組的數據顯示，當 Cache 設定為 2MB， Max_Object size 設為 128KB 時，在測量組別 2,3,4 與 1,4,5 這三個 網頁時，排他性在速度上會稍快於無排他性，原因是由於在排他性實 驗中，網頁 1、2 有許多的小檔，且總大小不超過 2MB，所以都保留 在 Cache 中，而非排他性實驗中，在測量 1,4,5 的過程中，Cache 內 的檔案會全部都會被置換掉。而至於測量組別 1,2、3,2,1 時，其結 果卻跟無排他時幾乎一樣，是由於 Cache Memory 的大小太小，只有 2MB,以至於網頁 1、2、3 中小於 128KB 的小檔案總合大於 2MB，以至 於先前抓過的資料都會被置換掉，當要再 Reload 時，就必須再重新 抓取，當然結果就跟無排他性的測試無差別。 想法:

若 Cache Memory 大小不變，而將 Max_Object size 加大為 512KB 後 結果會是如何? 實驗組:排他性 Cache:2MB Maximum_Object_Size=128KB (單位:min’sec) 測試 #1 #2 #3 15.87 19.13 40.26 14.82 18.66 40.17 15.62 17.44 40.40 2,3,4 Total:75.26 (Total)平均:73.555 17.80 14.92 9.26 17.89 14.45 9.14 18.68 14.51 9.16 3,2,1 Total:41.98 (Total)平均:41.765

討論:

所測得的結果為即使加大 Max_Object size 而 Cache 大小不變，將無 法使排他性發揮其效能，因為 Cache 不夠大，測試過程 Cache 內的資 料都被置換掉了。若 Cache Memory 加大,而 Max_Object_Size 也隨之 而變化，其結果會如何呢?(測試三) 測試三: 對照組:無排他 Cache:4MB Maximum_Object_Size=4096KB (單位:min’sec) 測試 #2 #1 9.39 14.63 17.56 40.27 9.16 14.56 17.58 40.34 #3 9.50 14.47 17.79 40.38 #4 9.45 14.65 17.68 40.56 #5 9.57 14.71 17.42 40.49 1,2,3,4 Total:81.85 (Total)平均:82.078 實驗組:排他 Cache:4MB Maximum_Object_Size=128KB (單位:min’sec) 測試 #2 #1 9.29 14.29 17.79 40.50 1.60 9.78 14.68 40.28 #3 1.63 9.90 14.43 40.72 #4 1.83 9.64 14.79 40.60 #5 1.68 9.69 14.31 40.48 1,2,3,4 Total:81.87 (Total)平均:66.51 Cache:4MB Maximum_Object_Size=256KB (單位:min’sec) 測試 #2 #1 9.51 14.62 17.88 40.24 9.66 14.80 17.90 40.39 #3 9.57 14.97 17.98 40.38 #4 9.44 14.84 18.11 40.72 #5 9.84 15.01 18.10 40.77 1,2,3,4 Total:82.25 (Total)平均:83.098

比較: (單位:min’sec) 測試 Cache=4MB 無排他性 排他性 (Max=128KB) 排他與無排他 比較 誤差:約 2(s) 1,2,3,4 82.078 66.51 排他性快 (約 16 秒) 排他性 (Max=256KB) 1,2,3,4 82.078 83.098 兩者約相等 討論: 小組討論後，認為若能將網頁 1、2、3 的小檔案留在 Cache 中，排他 性的效能應該會比實驗二的結果更為顯著。

於是在我們適當的將 Cache Memory 調大為 4MB，但 Max_Object 大小 不變，實驗結果的數據顯示排他性的效能上比無排他性的效能又更好 了一些，原因是網頁 1、2、3 的小檔案全部都如預期的留在 Cache 中， 且小檔案總合小於 4MB(在沒排他的前提下，不會被置換掉)，而無排 他性的測試在 Reload 網頁時，由於先前的檔案都被置換出去了，所 以全部 Cache Miss(與測試二結果相同)。接下來將排他大小調為 256KB 的限制後，發現與第一次 Cache Miss 的結果是一樣的，所以 我們斷定假使再調為 512KB 後的結果亦如此，理由是因為 Cache 內可 容納的檔案大小變大也變多，但 Cache Memory 的大小卻依然不變， 以至於全都被置換出去，跟無排他機制的結果是無差別的。

測試四: 對照組:無排他 Cache:6MB Maximum_Object_Size=4096KB (單位:min’sec) 測試 #2 #1 9.48 14.38 17.85 41.32 9.93 14.69 17.63 40.50 #3 9.39 14.69 17.79 40.37 #4 9.77 14.83 17.73 40.97 #5 9.51 14.55 17.90 40.79 1,2,3,4 Total:83.03 (Total)平均:82.61 實驗組:排他 Cache:6MB Maximum_Object_Size=128KB (單位:min’sec) 測試 #2 #1 9.36 14.73 17.87 40.42 1.73 10.30 14.94 40.17 #3 1.70 10.03 15.09 40.33 #4 1.86 9.96 14.95 40.12 #5 1.85 10.02 14.74 40.03 1,2,3,4 Total:82.38 (Total)平均:66.95 Cache:6MB Maximum_Object_Size=256KB (單位:min’sec) 測試 #2 #1 9.30 14.59 17.38 40.09 1.70 2.55 9.92 41.97 #3 1.60 2.57 10.16 41.07 #4 1.77 2.48 10.27 #4 #5 1.73 2.46 9.80 #5 1,2,3,4 Total:81.36 (Total)平均:55.32 Cache:6MB Maximum_Object_Size=512KB (單位:min’sec) 測試 #2 #1 9.43 14.13 17.70 40.74 9.41 14.46 18.03 40.53 #3 9.21 14.42 17.71 40.55 #4 9.58 14.67 17.69 #4 #5 9.40 14.68 17.59 #5 1,2,3,4 Total:82 (Total)平均:82.18

比較: (單位:min’sec) 測試 Cache=6MB 無排他性 排他性 (Max=128KB) 排他與無排他 比較 誤差:約 2(s) 1,2,3,4 82.61 66.95 排他性快 (約 16 秒) 排他性 (Max=256KB) 1,2,3,4 82.61 55.32 排他性快 (約 27 秒) 排他性 (Max=512KB) 1,2,3,4 82.61 82.18 兩者約相等 討論:

考慮將 Cache Memory 大小設為 6MB 與 Max_Object_Size 都一起調大 為 128KB、256KB、512KB 來觀察排他大小的限制相對於 Cache 的大小， 對系統的效能有怎樣的變化。 得到的結果為當 Cache 大小設定為 6MB，配合排他限制為 256KB 時所 得到的效能是最好的。由於網頁 1、2、3 內小於 256KB 的檔案都被存 放入 Cache 中，且總空間不超過 6MB，所以排他的效能較之前的測試 又更為優越。而非排他性的測試中，Cache 由於容量的限制，往往被 大的檔案置換掉，以至於每次都得到 Web Serve 重新抓取資料，效能 當然不如有排他性的機制。

測試五: 對照組:無排他 Cache:10MB Maximum_Object_Size=4096KB (單位:min’sec) 測試 #1 9.5 2 14.0 7 17.5 1 40.1 9 50.6 2 #2 9.5 4 14.16 17.51 41.07 50.6 9 #3 9.3 3 14.54 18.48 40.67 51.0 2 #4 9.5 9 14.35 17.90 40.76 50.7 3 #5 9.3 7 14.34 17.64 40.66 51.0 6 1,2,3,4 ,5 Total:131.91 (Total)平均:133.353 實驗組:排他 Cache:10MB Maximum_Object_Size=128KB (單位:min’sec) 測試 #1 9.8 9 14.4 8 17.4 7 40.4 5 50.5 2 #2 1.8 1 10.19 14.81 40.20 50.6 6 #3 1.7 6 10.12 15.19 40.47 50.1 0 #4 1.7 7 9.98 15.05 40.31 49.5 5 #5 1.8 8 10.75 15.61 40.84 50.6 8 1,2,3,4 ,5 Total:132.81 (Total)平均:117.933 Cache:10MB Maximum_Object_Size=512KB (單位:min’sec) 測試 #1 9.4 1 14.3 5 17.4 8 40.2 9 50.8 7 #2 1.6 1 2.44 8.21 23.07 51.0 0 #3 1.7 3 2.34 8.57 23.20 50.5 0 #4 1.7 8 2.51 8.45 23.29 50.9 8 #5 1.6 7 2.46 8.24 23.51 51.2 3 1,2,3,4 ,5 Total:132.4 (Total)平均:86.698

比較: (單位:min’sec) 測試 Cache=10MB 無排他性 排他性 (Max=128KB) 排他與無排他 比較 誤差:約 2(s) 1,2,3,4,5 133.353 117.933 排他性快 (約 15 秒) 排他性 (Max=512KB) 1,2,3,4,5 133.353 86.698 排他性快 (約 47 秒) 討論:

經由前幾次測試後得到的結果發現，若 Cache 與 Max_Object Size 都 能在某種範圍或者某種程度上的加大，其排他性的效能應該會更好。 所以，在這次的測試當中，我們將 Cache Memory 大小設定為 10MB， Max_Object Size 為 512KB，目的是為了讓網頁 1、2、3、4 中小於 512KB 的檔案幾乎都保留在 Cache 中，如此一來，能省下的時間應該 就會更多，而實驗測試的結果的確符合所推斷出來的想法，而當我們 設定排他限制的大小為 128KB 時，數據顯示與 Cache=6MB，排他為 128KB 時的情形一樣，而至於 Maximum_Object_Size= 256KB，我們認 為應該與測量快取大小為 6MB 時的狀況是一樣的，因為所有 256KB 以 內的檔案，總合小於 6MB，也就是說，即使快取調大為 10MB 時，結 果如同快取為 6MB。所以當 Cache 設定為 10MB 時，排他大小限制設 定為 512KB 時所得到的效能是最好的。

5.4 實驗總結、分析與討論:

在這次的實驗中，可以清楚的了解到，要利用排他性的替換機制來增 進瀏覽網頁(或在網路上做存取的動作)，其環境是其關鍵要素之一。 如下圖所示: 10MB Internet T1 由上圖可清楚的知道，當使用者與 Proxy server 之間的速度要快於 Proxy server 到外面的網域的速度時，其排他性的替換機制才可能 發揮他的作用。也就是說使用者必須與 Proxy server 處於近端。 倘若 Proxy server 與 Web server 的速度大於使用者與 Proxy server 之間的速度，Proxy server 到 Web server 抓取資料僅花不到幾秒鐘， 但，要回送給使用者時卻得花上一大段時間，其 Proxy server 幾乎 發揮不了作用，就如同實驗一時所做的數據一般。 在參考文件「網頁物件之排它策略應用於代理伺服器」報告書中，使 用排他機制可以使上網網頁的命中率大幅增加，排他門檻愈高 (Maximum_Object_Size 愈低)，命中率愈高，快取記憶體太大固定 100mb，下載速度上則是排他門檻愈高(Maximum_Object_Size 愈低)， 下載時間有減少，速度上有加快。 下表節錄自該文件： 策略 排他門檻 快取命中率(%) 加快比率(%) 2mb 1.7 3.44 1mb 2.3 4.65 LRU 500kb 2.9 5.79 2mb 2.0 4.07 1mb 2.0 4.16 LFU 500kb 2.1 4.39 2mb 1.7 3.35 1mb 2.3 4.56 LRU-MIN 500kb 2.9 5.67 User Web Server Proxy Server

上網速度方面，快取大小和排他性是否有關聯呢？這是他們沒有做到 的。而我們針對此方向開始實驗。 我們的實驗裡面，快取大小、排他性、網頁大小和讀取順序都有關聯， 快取大小和排他性似乎存在某種比率可以達到最佳化。 下表為我們實驗中測試網頁後效能的總整理與加快表格立體圖。 Max-obj Cache Mem 128KB 256KB 512KB 2MB 略好 （小檔與大檔配 合下，略能顯現出 排他性的效果） 差 （時間約相同） 差 （時間約相同） 4MB 中 （快約１６秒） 差 （時間約相同） 差 （時間約相同） 6MB 中 （快約 16 秒） 優 （快約 27 秒） 差 （時間約相同） 10MB 差 （快約 1５秒） 中 （快約２７秒） 優 （快約４７秒） 2 16 16 15 1 1 27 27 1 1 1 47 0 0 0 0

0

20

40

60

2MB 4MB 6MB 10MB 4096KB 512KB 256KB 128KB

4096KB

512KB

256KB

128KB

由圖表可以知道，可以想像的，瀏覽過愈大的網頁，排他就必須設大， 但，仍必須與快取的大小相互配合才能達到最佳的效果。 所以在快取空間在大小有限的的情況下，實驗排他性效能的結果符合 參考文件中所提到的結論。 圖表：加快表格立體圖 略估計增加秒數 排他門檻 快取空間大小

專題心得

學生:方建佳

呼，總算能在四上發表前將專題趕出來了，其實早在一兩個禮拜 前就應該可以完工，偏偏我們在實驗的過程上遭遇了不少的困難，最 初，我們將要測試的網頁與 Proxy Server 主機一同放置在學校而我 們從外面的網路來做測試時，一時沒有考慮距離太近的問題，導致有 用我們 Proxy Server 主機來做快取與沒有使用，在時間上差不了多 少，看不出我們所要做的排他機制的好壞，之後，我們將測試的網頁 移到外面，主機不動，而我們跑到學校實驗室裡面來做測試，照理論 來說，應該會有明顯的差別，但是想不到原來我們從學校要測試初始 數據而連到外面網頁的時候，學校的連外主機也會自動幫我們做一份 快取，這樣的話，即使將我們主機的快取清空要測試初始數據時，也 會因為學校連外主機的快取而導致無法連續測試的情況，再來，我們 就將主機和測試的網頁一同搬到外面去而我們在主機旁測數據，想說 應該萬無一失了，沒想到會因為放置測試網頁的地方頻寬不夠大，又 導致了傳回來的網頁有來不及完整開啟的情形，真是困難重重，不過 最後，我們將測試的網頁放到學校的主機而把 Proxy Server 主機一 樣放到外面，我們在主機旁來做測試，結果總算能夠順利的做實驗， 也總算可以順利驗證我們機制的好處，真是可喜可賀。 在團隊過程中，我覺得我們的分工合作做的還不錯，組員們各自 發揮了他們的專長，將自己的工作做好後，到最後我們再一同做實 驗、測試數據，沒有一個是在那邊乘涼的或是幫忙買便當的，所以我 們專題才能如期的做出來，這一點也是我們值得驕傲和欣慰的地方。 在我負責的部份，Squid 的網頁介面設計中，我也學到了不少，由最 早的 Squid 的架設與 Linux 的學習，到最後，利用 PERL 寫 CGI 程式 與 XHTML 來設計網頁，從原本不會，慢慢的到最後做出成果來，這段 過程讓我覺得很充實，也讓我覺得在程式設計的功力上又增進了不 少，或許我們的專題沒有很大，也沒有很了不起，但是我想我們的收 穫良多。 最後，還是要感謝一下指導我們專題的老師，畢竟沒有他的從旁協助 和一一點破我們專題所欠缺的不足部分，我們是不會順利的將專題完 成的。

學生:陳昱祥

本次專題我們經歷多災多難。

一開始，我們天王助教帶我們做 socket program 有關的 proxy 應用， 與無線網路卡結合，我們這部分難度並不高，socket program 到大 四才教選專題時候還沒有學所以要先學，但因為課業忙碌時間抽不出 來研究專題和學習陌生的網路語法，錯失了一次良機，天王助教去當 兵了，開始找專題新方向。 補習班把暑假的時間占走了，主機架設也有紛爭，專題拖到 9 月才開 始弄，我這時就開始反省自己…在一開始製作專題的時候，不明確的 製作方向、向心力不夠、補習、沒有花時間下工夫、技術不熟練等問 題，導致我們一再的浪費時間，因此專題起步比一般人晚。 但是隨著大四課業壓力減低，我開始鞭策自己致力於專題，開始常與 指導教授開會，李維聰老師循序漸進的帶領我門一步一步朝向目標前 進，啟發我們找問題解問題的耐心和專心。李維聰老師是我們的班 導，為人通情理懂非有原則，上課幽默有趣，再艱深的知識，都會教 的淺顯易懂，作業都使上課教的，考試也不會刁難學生，只要努力就 可輕易學到知識並拿到學分，即使他事業忙碌，他都會以善心和耐心 來指導我們，或許會有壓力，但是你不會感到太沉重，或許會遇到困 難，但是絕對有方法可以解決的，你或許無法從他身上學到解問題技 巧，但，你可以從他的身上學到如何解決問找問題的方法，目前為止 他是令我難忘的一個好老師。拜李維聰老師所賜，專題終於進入最後 偵測階段，時間也到了 11 月初，開始準備推薦甄試，在大家的同心 協力之下，專題終於有成果了。 專題製作方面，一開始的方向是找尋並修改 squid 找到快取替代策略 使實現排他機制，squid 是用 c 語言寫的，花不少時間研究 squid 原 始碼撰寫的結構，5mb 的原始碼內容調理分明但是錯綜複雜，一個好 的軟體就需要完整有規劃的軟體工程。其他組員的分工事 cgi 介面設 計與資料收集。李維聰老師給予的建議之下，我們架 proxy server 在逢甲內，用不同的客戶端測試放在學校的測試網頁。 為了求數值正確，於是到處奔波找可用 IP，畢竟，借時間是一件麻 煩的事，過程…高潮迭起，耐人尋味。找到一些可用的 IP，傳資料 不打緊，實驗必須多方協調同時有空(機器與 IP)才可完成，這麻煩 了，為了實驗你還得協助他完成他手邊的工作，否則只有浪費你的時 間，真是費時費力又傷神，於是對組員抱怨：「借東西最麻煩了，特 別是 IP！」瑣碎的設備問題折騰好久，數據出錯…毅然決定把機器 搬到另外的地方試驗…感覺時間好像浪費一樣。經過多次測試，各地 實驗的結果以 web server 位置方面還是覺得逢甲大學的 140.134.4.20 最穩，proxy server 位置方面連外的一個 IP 內的區

網為最佳，其他地方實驗的結果還是有用處的。 不經一事，不長一智，就我所學的經驗當中，有時候也不容易找出一 些或忽略一些細小的錯誤，若沒有基礎的知識與技能，問題就多了， 除了操作與修改不易，設定檔不熟悉改錯沒發覺，讓我們吃盡了苦 頭，即使是碰壁繞遠路，也學到了不少經驗，累積知識，一步一步去 思考問題，利用知識與經驗將問題明朗化。 製作本專題讓我學到不少，liunx 實作與架站技巧、cgi 結合應用、 網路程式設計等。遇到的問題範圍自平台、網路、軟硬體、程式語言、 機制等數種。當然，組員之間的分工合作和彼此建立的信念和共識也 是少不了的，專題到後面，我們享受到實驗的成果和團結合作努力奮 鬥的果實，感謝我的組員∼建佳和仲寧，沒有他們專題可能沒有辦法 完成，還有感謝李維聰老師的指導，以及建佳室友與家豪等人大力協 助，能夠趕在發表完成專題，我百感交集，感激不盡。

學生:黃仲寧

到目前為止我還是很難想像專題竟然可以如期的完成，專題過程中， 可以說是經歷了不少的風風雨雨，面對了許多從未碰到的困難與窘 境，卻也學習到了遭遇到困難時所應有的冷靜與積極的面對與有效解 決問題的態度。雖然不少狀況仍然是學生目前能力無法處理的，但， 藉由這次的專題經驗讓我有更明確的認知，除了獲益於做人處世的道 理外，進而向上求學問是我未來生涯規劃堅定且必然的道路。 專題的一開始由熱心的博士班學長與李維聰老師共同指導。起初的目 標與方向是實作 PDA 的省電模式。在開始這次的專題前，我們組員分 工閱讀完與本專題有關的知識，如 http protocol、socket programming 等後，開始進入專題的作業。就在一開始架設 proxy server 時就出現了第一個問題，這問題卻也是讓我們組陷入低潮的 開始。經過一連串許久的修改才找到問題的所在，終於使得 proxy server 可以正常運作。而伺服器架好才算是進入專題的開始，隨即 的碰到了我們目前無法處理的難處(包括組員們都要補習、學識上的 不足…等)，在這段時期，幾乎每個星期都得跟老師與學長開會，由 於個人實力不夠且外務繁多，無法達到當時的進度，每次都硬著頭皮 的去開會。可是，最後還是很遺憾的宣告這次的題目失敗與放棄。 經由之前一次失敗的教訓，我們便積極的找下一個題目的目標與方 向，然而卻沒有太大的收穫。我們帶著灰心與慚愧與指導老師開會， 老師給我們許多的鼓勵並建議學生一個參考的方向----proxy 的替換 機制，這時大家的心情有如大旱之逢甘霖般的喜悅，緊接著，我們便 馬上分配各自的工作。 在這替換機制專題過程中，一切似乎很順利。事前準備一切就緒後， 開始測量有排他與無排他機制的效能時，所測得的數據顯示我們這次 的實驗失敗。實驗數據告訴我們，若扣除誤差，其實有沒有 proxy server 都無所謂，完全看不出其功用。後來與指導老師的開會討論 之下才知道，原來問題出在測試環境上，決定將 web server 放到學 校外的網路，而我們到學校的實驗室中測數據，透過 proxy server 到外面較慢的網路，可以測量到準確的實驗數據。 就在正當在實驗室測數據時，又發現了一個難以補救的錯誤。感覺老 天似乎開了我們組一個大玩笑。也是環境作業上的錯誤，可是這次卻 是除了搬離主機外，沒有其他的方法。之後，我們四處的找尋拜訪有 固定 ip 的同學，盼望能借我們 ip 以完成這個實驗。幾經一番波折， 終於將此專題最後的實驗完成，也成功的得到排他性機制的效能優於 非排他機制理論的結果。 很開心我們的專題終於完成，雖然專題內容並不是多偉大，但，那種 興奮，那種成就感卻是難以形容的，因為我有太多的第一次都是在這

個專題上發生，如第一次的架站，第一次的了解如何使用 CGI 與網頁 整合，更是第一次感受到 Linux 功能的強大，雖然在 linux 上吃了許 多苦頭，卻也學到了不少，獲得許多新技巧與收穫。 最後我要感謝組員建佳、昱祥給我這機會與他們一同參與這次的專 題，讓我更明白了團隊合作的難得與可貴，也重新的感受與學習到小 組的分工與負責的應有態度。 更要感謝指導教授李維聰老師與細心不倦的指導，使學生在這次的專 題經驗中有所成長。老師常以鼓勵代替我們怠惰所應有的責罵，每次 一有小小的結果，老師總是以 ”很好”，”很不錯”來給我們信心 喊話，雖然被誇獎的感覺很不錯，不過卻讓我有更深刻的反省，因為 知道自己本身的努力不夠，所以即使專題結束了，今後仍要再繼續努 力充實自己才行。

附錄 A

本排他性(evictor)實驗參考於第「十三屆物件導向技術及應用研討 會」報告書中:

「網頁物件之排它策略應用於代理伺服器」

(Eviction Policy on Web Object for Proxy Cache Server) 作者:段裘慶 簡嘉言 黃承丞 楊鍵樵 在實做專題過程中，由於有部分之處的不了解，於是寄信請教原作者 之一。以下為原始文件: 主題:有事請教 日期: Mon, 14 Oct 2002 09:47:41 +0800 你們在第 13 屆物件導向研討會上， 〝網頁物件排他策略應用於代理伺服器〞這研究寫的不錯。 而剛好我也有想往這方面研究的興趣， 有一些問題想請教一下

1.做這項研究需要更動 squid 的原始碼 source code 嗎？ 我想修改原始碼 source code，在使用快取機制之前加一行徵測大小，可是我找不到 source code 內呼叫快取機制的那一行。 2.要怎樣換快取機制？ 我只知道 squid 內建這三種 LRU、LFU、GDSF 但是找不到哪裡可更換。 煩請盡速答覆...感激不盡 m(_ _)m 以下為回覆信件: 您好 1. 該研究係經由 simulator 完成

2. 本研究強調於任一 replacement policy 前若加入 evictor 可改 善效能

而非要更動該 proxy 之 rep. policy. Best regards,

C.-C. Tuan Oct. 14, 2002 ---Original Message---

From: samyup.tw [mailto:[email protected]] Sent: Sunday, October 13, 2002 5:11 PM

To: [email protected] Subject: 有事請教

附錄 B

參考書目: 1 書名: Linux 網路實作經典 作者:高建智 賴阿服 編著 出版社:知城數位科技股份有限公司 2.書名:Linux 應用管理手冊 作者:黃子益 編著 出版社:松崗電腦圖書資料股份有限公司 3.Perl 程式設計入門手冊 作者:Wyke Thomas 編著 吳東賢 譯 出版社:麥格羅˙希爾國際出版公司