• 沒有找到結果。

題目:整合快取與鏡射檔案傳輸服務之系統架構

N/A
N/A
Protected

Academic year: 2022

Share "題目:整合快取與鏡射檔案傳輸服務之系統架構 "

Copied!
84
0
0

加載中.... (立即查看全文)

全文

(1)

中 華 大 學 碩 士 論 文

題目:整合快取與鏡射檔案傳輸服務之系統架構

A Framework for Integrating Caching and Mirroring FTP Servers

系 所 別:資訊工程學系碩士班 學號姓名:8802507 黃 重 儒 指導教授:王 素 華 博 士

中華民國 九十年 七月

(2)

摘要

檔案傳輸協定是網際網路上所提供的眾多服務資源項目中,最常 用的項目之一。而目前因網際網路的使用量大增,使得網路頻寬不敷 使用,其中受到許多不必要浪費的影響,如重複頻寬的佔用。

而就檔案傳輸伺服器的服務來說,目前主要是利用鏡射的方法,

定期的將資料備份傳輸到自己的檔案傳輸伺服器上以供使用,解決一 般使用者遠端抓取檔案時,頻寬重複使用之問題。但是仍存在部分問 題,如許多檔案的使用率不高,不論是空間或每次鏡射備份時低使用 率檔案頻寬重複佔用等,都造成電腦與網路資源的浪費。

因此,可以利用目前網際網路代理伺服器的快取技術,來快取網 際網路資料,應用於檔案傳輸服務的領域。如果可以利用快取的觀 念,架構在檔案傳輸服務上,應可以改善傳統檔案傳輸伺服器空間的 浪費及鏡射時所不斷耗用的頻寬等現象。

快取檔案傳輸伺服器主要是透過虛擬目錄的運作,架設虛擬的檔 案架構,只存放較常被使用者存取的檔案,如此,能有效節省空間、

減緩重複頻寬的佔用等問題。本論文主要除了要探討提供整合快取與 鏡射技術的檔案傳輸服務之系統架構外,並將說明應用快取技術時所 需的路徑選擇器機制,討論相關資料蒐集機制,以及未來其他可行的 研究等。

關鍵字:網際網路、檔案傳輸技術、鏡射技術、快取技術、代理伺服器。

(3)

Abstract

FTP (File Transfer Protocol) is one of the most used protocols on the network. As the population of network users grows, the bandwidth is not sufficient to the increasing demand for data transfer and inefficient use of network resources.

To save the international bandwidth, most current FTP servers use the mirroring technique to backup files on a regular time schedule. This can solve the problem of international bandwidth reduplicated. However, other problems still exist, such as the low request frequency of some files. It takes a lot of time and bandwidth to do the regular backup and wastes the resource of the network.

Caching is one of the most popular technique for improving the network performance by keeping local copies of remote resources. Caching technique can be used in the FTP service. If we can use the caching concept in the FTP framework, it can improve the mirroring FTP service by saving time, bandwidth and hard disk spaces.

The caching FTP server incorporates the virtual directory framework in the system. By keeping the most used files in cache, the system can save the server’s hard disk space and reduce the bandwidth’s reduplicate occupation problems. In this research, we will discuss the integration of the mirroring and caching FTP services, and the related issues, such as resource selector, information gathering, future workable research, etc.

Keyword: Internet, FTP, Mirroring, Caching, Proxy.

(4)

目錄

第壹章 緒論……… 1

1.1 研究動機……… 1

1.2 研究目的……… 2

1.3 研究範圍與限制……… 3

1.4 論文架構……… 4

第貳章 相關文獻探討……… 5

2.1 檔案傳輸伺服器(WuFTP)……… 6

2.2 鏡射技術(Mirroring)……… 7

2.3 代理伺服器(Proxy Server)……… 9

2.4 快取技術……… 10

2.4.1 快取技術的運用……… 10

2.4.2 快取技術中的一致性問題……… 12

2.4.3 快取機制的改良法……… 13

2.5 網路預取技術……… 16

2.6 Caching FTP Server……… 18

第參章 整合快取與鏡射之系統架構………21

3.1 系統架構……… 21

3.2 架構元件……… 23

3.2.1 快取檔案伺服器管理員(CFTP Manager)…… 23

3.2.2 虛擬目錄(Virtual Directory)……… 24

(5)

3.2.3 快取代理伺服器 (Proxy Cache)……… 25

3.2.4 更新引擎(Update Engine)……… 26

3.2.5 路徑選擇器(Resource Selector)……… 29

3.3 資料蒐集機制( Information Gathering)……… 33

3.4 檔案傳輸伺服器之比較……… 35

第肆章 系統設計與實作……… 37

4.1 系統架構平台……… 37

4.1.1 作業系統 FreeBSD……… 38

4.1.2 檔案傳輸伺服器……… 38

4.1.3 資料庫 MySQL……… 39

4.1.4 程式語言 JAVA……… 40

4.2 資料定義……… 41

4.3 實作模擬平台……… 44

4.3.1 軟硬體平台……… 44

4.3.2 模擬測試之考量……… 45

4.3.3 系統分析設計……… 46

4.4 系統實作……… 49

4.4.1 實作畫面與說明……… 50

4.4.2 資料蒐集與分析……… 52

第伍章 效能評估……… 54

5.1 資料來源……… 54

5.2 系統執行方式……… 55

(6)

5.3 模擬結果……… 56

5.3.1 一般檔案傳輸伺服器之模擬結果……… 56

5.3.2 本系統之模擬結果……… 57

5.4 結果分析……… 58

5.4.1 與一般 FTP 比較……… 59

5.4.1.1 系統時間效率比較……… 60

5.4.1.2 空間與傳輸效能比較……… 63

5.4.2 結果評估……… 65

第陸章 結論……… 69

6.1 未來研究與展望……… 69

6.2 結論……… 73

參考文獻……… 72

(7)

圖目錄

圖 2.1 HEANSA CFTP 的 Web 介面……… 18

圖 3.1 快取檔案伺服器系統架構圖……… 22

圖 3.2 快取檔案伺服器管理員控制流程圖……… 24

圖 3.3 更新引擎控制流程圖……… 28

圖 3.4 更新機制流程圖……… 28

圖 3.5 路徑選擇器示意圖……… 29

圖 3.6 路徑選擇器控制流程圖……… 30

圖 4.1 整合快取與鏡射檔案傳輸服務之系統平台……… 37

圖 4.2 模擬測試之系統平台……… 45

圖 4.3 第一層 DFD Main Process……… 47

圖 4.4 第二層 DFD Resource Selector……… 49

圖 4.5 系統模擬運作畫面……… 51

圖 4.6 傳統傳輸伺服器模擬運作畫面……… 52

圖 5.1 系統運作時間效能比較圖……… 62

圖 5.2 系統時間效能差距圖……… 62

圖 5.3 系統運作時間效能差距百分比圖……… 63

圖 5.4 系統空間效能比較圖……… 64

(8)

表目錄

表 2.1 Distribution of requests by sites……… 19

表 3.1

HENSA CFTP Server、MOD System 與本系統架構的差異

… 36 表 4.1 accesslog……… 42

表 4.2 updatelog……… 42

表 4.3 cachelog……… 42

表 4.4 dataprofile……… 43

表 4.5 datainfo……… 43

表 4.6 rec_selector……… 43

表 4.7 user_pro……… 43

表 5.1 檔案傳輸伺服器使用者要求次數統計……… 54

表 5.2 資料來源紀錄檔部分範例……… 55

表 5.3 一般檔案傳輸伺服器之模擬結果……… 56

表 5.4 本系統之模擬結果……… 57

表 5.5 本系統架構模擬統計數據……… 58

表 5.6 運作時間效能比較……… 61

表 5.7 檔案空間比較……… 63

(9)

第壹章 緒論

網際網路近幾年來蓬勃發展,網路頻寬一直趕不上使用者迅速增 加的需求,因此有許多致力於改善網路頻寬問題的方法。而本論文即 針對其中檔案傳輸協定的部分做相關研究,以下將逐一說明相關部 分。

1.1 研究動機

目前網際網路最常用的通訊協定之一是檔案傳輸協定(FTP – File Transfer Protocol),隨著網際網路使用率大增,網際網路的資源 也就備受限制,資源、頻寬的不足也就逐漸產生。例如:檔案傳輸服 務常被用到,每位使用者若都到原始站台抓取相同資料時,可能造成 原始站台的負擔與網路佔用頻寬,因此有鏡射站台(Mirror Site)的 產生,以供使用者抓取檔案時選擇較近或較快的檔案傳輸伺服器。

然而檔案傳輸伺服器「鏡射」(Mirroring)的機制,定期抓取資 料,有許多檔案並沒有需要更新,卻還是重新抓取,使得頻寬重複佔 用,加重網路的負擔,常造成網路頻寬不足、網路塞車。另外,在傳 統檔案傳輸伺服器在資料傳送服務時,許多檔案存在伺服端並沒有真 正常被利用到,或是使用率不高,造成了資源的浪費,佔用空間的問 題。

(10)

而就現有的網路硬體限制,無法因應網際網路使用人口的快速膨 脹,因而有多改善網際網路使用頻寬與使用量問題的技術。而就網路 頻寬的使用率而言,雖然以全球資訊網(World Wide Web)為主,但 是在檔案傳輸服務的部分,其使用量是相當驚人的。因而本論文希望 藉由結合快取與鏡射技術以應用於檔案傳輸服務之上,以因應目前網 路頻寬不足之現象,以及改善檔案傳輸服務之效能。

1.2 研究目的

快取技術(Caching)近幾年也因為全球資訊網的流行而廣泛被 利用,為了要平衡傳輸時造成的負擔,我們利用快取技術來架設在檔 案傳輸伺服器上。當然,功能能否發揮要視各主機的快取容量,保留 時間與使用者取用各資源之頻率而定。而透過快取觀念、技術架設檔 案傳輸伺服器的快取檔案傳輸伺服器(CFTP,Caching FTP Server)

其目的就是改善傳統檔案傳輸伺服器的幾項嚴重缺點,可以有效的改 善網路傳輸問題。

快取檔案傳輸伺服器的主要精神,應該首推虛擬目錄(Virtual Directory)。因為傳統檔案傳輸伺服器的檔案使用率並不高,造成許 多經濟效益問題,因此我們利用虛擬目錄來改善,將檔案傳輸伺服器 架設虛擬的檔案架構,照常提供使用者檔案傳輸的服務,但是實體存 放的卻是最常被存取的檔案,而對於不常被存取的檔案,再由檔案傳 輸伺服器立即選擇最迅速的其他鏡射或原始站台來抓取檔案以提供

(11)

服務給使用者。如此可以有效的改善空間、時間的經濟效益,並且節 省檔案傳輸伺服器在做鏡射時所造成的網路頻寬浪費及不必要的成 本。

本論文主要以改善整體網路與伺服器效能為主,並考慮所影響使 用者是否在可容忍之範圍。本研究藉由整合快取與鏡射服務之檔案傳 輸架構,以期進而改善網路頻寬使用不足問題及其伺服器效能。

1.3 研究範圍與限制

本研究範圍以檔案傳輸伺服器為主,並將探討與整合相關技術,

如:整合快取技術以及鏡射技術之架構,且透過本論文所設計之路徑 選擇器機制,進而達到結合快取技術時所需即時抓取檔案之功能。而 在檔案更新機制部分,分為線上及批次作業。而在未來可再加入研究 的檔案傳輸服務之預取功能,則暫不在本研究範圍。

因為考量到線上測試所可能面臨的諸多問題。使用者要求之資料 來源不足以及其正確性:使用者不常使用該檔案傳輸服務,導致資料 量不足,或是資料偏頗。及需與其他站台合作等議題。而本研究架構 亦不適用於特殊情形,例如會受使用者行為影響,使用者需求之檔案 分佈過廣,導致系統必須不斷重新導向,便無法有效克服頻寬重複使 用問題等。因此,將透過模擬測試的方式,於後章節說明。

(12)

1.4 論文架構

本篇論文將針對所提出的整合快取與鏡射檔案傳輸服務之系統 架構與流程作說明,內容還包含資料蒐集機制以及系統建置平台,以 及未來相關的研究工作。

本論文架構如下:

首先在下一章節會針對相關技術如:檔案傳輸伺服器、鏡射技 術、代理伺服器、快取技術等文獻做一探討。在第三章將會說明本論 文所提出的整合與快取鏡射之檔案傳輸系統架構,針對系統架構的各 個組件說明,如:快取檔案伺服器管理員、虛擬目錄、快取代理伺服 器、更新引擎、路徑選擇器等。以及可能遭遇之問題及所採用之解決 方法。

接著會在第四章對所設計之架構作系統設計與以及模擬實作描 述。包含有作業系統、檔案傳輸伺服器、資料庫、程式語言與系統平 台之轉移。並會對資料作定義,模擬實作的平台、測試之考量等。以 及系統分析設計、實作方法畫面。

在第五章,則對於實際模擬之架構作效能評估。系統執行的方 式、模擬結果,以及本系統架構之模擬測試與一般傳統架構測試相互 比較與評估。最後在第六章會提出未來還可以加強、發展的空間,研 究展望以及結論。

在下一章中,首先將對目前檔案傳輸與鏡射、快取技術等相關文 獻作討論。

(13)

第貳章 相關文獻探討

在這一章節中,將討論與網際網路中與系統相關的技術作一討 論,使設計能更符合現行需求。將針對目前網際網路技術中的檔案傳 輸協定(File Transfer Protocol, FTP)的鏡射(Mirroring)與快取

(Caching)之結合及相關技術做一探討。

檔案傳輸協定是在網路傳輸控制上使用的一種檔案通訊協定,定 義如何將一個電腦系統,連接現有的網路,以便存取網路上的系統資 源。其主要工作是提供檔案目錄清單,負責檔案傳輸與轉換工作。在 企業內部網路(Intranet),檔案傳輸協定可以提供一個快速存取檔案 的服務,特別適合用於檔案太大,不適合利用電子郵件(E-mail)傳遞 的檔案。

鏡射技術近來被廣泛應用於檔案傳輸技術,遠端伺服器透過檔案 更新機制定期備份的方式,以方便使用者需要抓取檔案時,無須再到 檔案的原始站台抓取,只需到較近的鏡射站台抓取資料,因此,使用 者可以節省檔案的抓取時間。不過通常在鏡射站台做備份時,是相當 耗時與佔用頻寬的。

快取技術更是熱門,快取具有重複使用的特性,相當符合網際網 路迅速發展所需。一方面,不同使用者具有相同需求時,可以節省時 間、空間,並且也能有效解決重複使用頻寬的問題。

以下,將會對各個相關技術逐一做探討。

(14)

2.1 檔案傳輸伺服器(WuFTP)

一般在網際網路上的伺服器的服務方式有兩種:一種是利用 inetd daemon 呼叫伺服器的服務行程,首先 itend 需先啟動並閒置(或稱 Sleeping)在記憶體裡,當客戶端對伺服器端提出要求時,此時,系 統會藉由 inetd 這個超級的 daemon 執行伺服器的相關服務行程,當 伺服器服務完畢後,伺服器行程會停止,而 itend 又回復到閒置狀態。

在此種情況下,您可將 inetd daemon 想成是總指揮,當不須伺服器服 務時,那麼相關程式也不會被 inetd daemon 執行。

另一種是在系統啟動後,伺服器立即獨立啟動並常駐於記憶體 裡,這種伺服器的啟動方式稱為 standalone,由於它是常駐的

daemon,所以一直被系統執行著,一旦客戶端向提出伺服器端提出 服務後,此 standalone 的伺服器 daemon 會馬上處理需求;如沒有任 何客戶端需要服務的時,這個常駐的 daemon 程式,也會靜靜的等待 提供服務。

目前所討論的 wu-ftpd 提供有上述兩種不同的 Server 版本,一般 較常使用的是由 inetd daemon 來呼叫執行的版本,當有人使用客戶端 FTP 程式連上檔案傳輸伺服器主機時,inetd daemon 就會去執行 wu-ftpd 的程式,當使用完畢離開後, wu-ftpd 行程就結束。如果都沒 人使用檔案傳輸服務連上檔案傳輸伺服器主機,wu-ftpd 程式就不會 平白無故被執行,這一類型的服務會一直被 inetd daemon 所監控著。

(15)

一般來說,使用 inetd daemon 監控 wu-ftpd 而不用 standalone 型 的 wu-ftpd。因為對於檔案傳輸伺服器的服務而言,其使用量較少也 不需立即對客戶端做出回應,不若全球資訊網服務是隨時需提供服務 且須立即做出回應。使用 inetd daemon 監控 wu-ftpd 雖然在即時回應 及處理的效能上較 standalone 型的 wu-ftpd 為差,但是卻可較節省實 體記憶體的用量(因用到才執行程式),整體說來,若是檔案傳輸伺 服器所服務用量不大的話,通常一部檔案傳輸伺服器主機還可以兼併 執行其他伺服器服務。[WinFTP, WuFTPab, WU-FTPD, Town95]

2.2 鏡射技術(Mirroring)

網際網路是一個相當成功的資訊系統,使用率的成長,逐漸地使 得網路出現塞車的現象。除了直到近年來超文件傳輸通訊協定(Hyper Text Transfer Protocol, HTTP)的興起,其實檔案傳輸協定(File Transfer Protocol, FTP)[Post85, RFC 959, Kant86]一直是網際網路最常用的一 個通訊協定。檔案傳輸協定負責傳遞不同系統之間的檔案。而資料傳 輸量大的關係造成網路速度慢,因此鏡射技術(Mirroring) [McLo] 以 及快取技術(Caching) [Abra95, Bern95] 是目前改善網路效能的兩 個最熱門技術。

(16)

關於鏡射技術方面,一向被廣泛使用於網路檔案傳輸伺服器上,

藉由網路檔案傳輸伺服器管理員的人工設定,定期前往指定目的網路 檔案傳輸伺服器複製指定目錄下的網路檔案為自己本身檔案系統上 的檔案。其優點是藉由人工設定收集熱門檔案於本地端的網路檔案傳 輸伺服器上,服務本地端的網路使用者,讓使用者能直接透過本地端 網路下載傳輸,以期減少網路頻寬的使用量。鏡射的缺點則是因為由 管理員人工所做的設定不見得能跟上快速變遷的網際網路世界,因此 所鏡射的檔案往往跟近期使用者所熱門的檔案間具有一定程度的差 距存在。

Mirror 是以 Perl [Perl]所寫的,它使用檔案傳輸協定,在它所執 行的主機與一部遠端主機之間複製一個目錄的階層組織。藉著在傳輸 檔案之前比較檔案時間與檔案大小,它可以避免拷貝不必要的檔案。

在其他的方面,它可以選擇重新命名、壓縮、 gzip 壓縮與分割檔案。

[McLo]

關於檔案傳輸伺服器方面採用 Wu-ftpd [WuFTPab, WU-FTPD],

之所以被廣泛用於 UNIX 平台,除卻支援平台廣之外,也有許多好 處,包含限制同時連線,以維持連線最佳品質、記錄檔案傳輸的時間 與相關訊息,以供日後分析、傳輸時可顯示傳輸狀態、可對不同網域 的機器或是使用者進行存取限制、下載檔案同時可以自動協助壓縮與 解壓縮[WinFTP,WuFTPab, WU-FTPD, Town95]

(17)

2.3 代理伺服器(Proxy Server)

由於鏡射技術,雖然解決遠端存取的使用效率,但是對於定期備 份的方式,網路傳輸流量仍然有負擔。網路基礎頻寬建設,跟不上日 進千里的網路運用,而代理伺服器,運用快取的概念與技術,能夠改 善頻寬重複佔用,因此在目前有限的頻寬與高負載的網路中,代理伺 服器成為熱門的服務之一。

在代理伺服器(Squid)方面可以解決頻寬重複佔用的問題,讓 頻寬資源能更有效的運用。他提供代理抓取使用者想抓取的資料,例 如,使用者想抓取某網頁,使用者可以對 Squid 發出要求,而 Squid 便會代為抓取,存放於伺服端,而別的使用者有相同需求時,便可直 接由此伺服端直接抓取,不必再透過遠端抓取,減少時間與頻寬的成 本。

大部分的檔案傳輸伺服器都是利用定期鏡射原始網站的方式來 更新資料,而都是利用人工方式來設定該更新機制。至於快取技術大 多用於網頁代理伺服器,並且都是儲存較新的資料在快取記憶體中。

在[Lin96]中所提的快取傳輸協定的更新方法裡,根據 Squid(proxy servers)[Squid]利用歷史紀錄來推估最常被使用的資料,進而在資料 過期前能夠更新並提供給使用者。其他相關的論文、研究也有提出檔 案傳輸服務客戶端相關技術[Telport, WuFTPab, WU-FTPD, WinFTP, Town95]。

(18)

2.4 快取技術

代理伺服器運用的就是快取。快取是一種技術,它把網路上使用 者經常瀏覽的網頁內容,如:圖片,文字,保留一份在較靠近(邏輯 上或實際上)使用者的地方,下一次,該使用者或者其他人也在網路 上搜尋,瀏覽相同的網頁,它會代替遠處的伺服器把資訊快速的送給 使用者,因為這個技術,可使得在網路上下載資訊速度變快,網路頻 寬也因為它,而大幅地節省下來。

快取具有重複使用的特性,能有效因應網際網路迅速發展所需,

尤其被廣泛的運用在全球資訊網。不同使用者具有相同需求時,可以 節省時間、空間,並且也能有效解決重複使用頻寬的問題。因此,在 檔案傳輸服務中,也運用了快取的概念。

以下小節將針對快取的相關技術與機制做一探討。

2.4.1 快取技術的運用

在快取技術方面,我們就快取的位置可分客戶端快取、伺服器端 快取,及代理伺服器端快取三種形式。在此是關於檔案傳輸協定的代 理伺服器端快取,取決於代理伺服端器快取的概念應用。

(19)

一般而言,快取技術被廣泛使用的原因主要有三:

1.具有節省網路頻寬的功能

使用者在使用網際網路,例如:全球資訊網或網路檔案傳輸 伺服器時,皆具有時間及空間區域的特性,由於這些特性,網際 網路代理伺服器利用配合快取的機制來存儲被使用者重複存取 的網路資料、檔案,如此可節省網路的流量負擔。

2.具有阻隔網路的功能

在某些狀況下,內部網路不宜直接連接在網際網路下,例 如:公司、政府單位之較具需安全性保護之內部網路,可透過搭 配使用網際網路代理伺服器的方式,即可避免內部網路直接和外 界網路相連接,且又可維持對外存取全球資訊網及網路檔案傳輸 等行為的正常運作。

3.具有階層式架構的功能

網路管理員可以依其不同目的、不同之網路環境將數個網際 網路代理伺服器組成其所需的階層式架構,這一群代理伺服器間 彼此可透過網際網路快取協定(Internet Cache Protocol, ICP)

[Wess97]來互相溝通訊息,彼此交換所需要的網路檔案資料,使 得整體應用上較具有彈性。[WinFTP, Zeng99, Luot94]

(20)

2.4.2 快取技術中的一致性問題:

當一個檔案被代理伺服器所快取時,此時就產生了快取一致性的 問題。當伺服器上的資料已經被更新,但代理伺服器上的所快取資料 並沒有同步被更新,如果使用者 Client 端在此時發出請求,就有可能 會拿到舊的檔案。因此產生了快取與實際不一致性的問題,而其中維 持快取一致性方法一般有下列三種:[WinFTP, Zeng99, Luot94]

1. Validation checks or Client Polling:

當 Proxy 第一次取回檔案的同時,紀錄檔案的更新時間。

若之後有使用者再對該檔案發出要求,Proxy 則先和來源伺服 器比對更新時間,不同的話即重新跟來源伺服器抓取檔案,否 則直接回應給使用者 Client 端。

2. Invalidation callbacks:

伺服器紀錄有哪一些 Proxy 從本處抓資料,當檔案更新 時,由伺服器主動通知 Proxy 重新擷取檔案,目前這個方法尚 未被廣泛使用,因為牽涉到重新設計 Web Server 與 Proxy 的內 部架構,而且也會增加伺服器的負擔。

3. Time-to-live fields:

最常使用的便是 TTL(Time-To-Live),透過 Proxy 設定 TTL 時間值,用來作為檔案是否過期的判斷。被要求的檔案若

(21)

大於 TTL 設定值則視為過期,Proxy 則必須從來源伺服器重新 抓取檔案。這個方法的問題是:如何設定適當的 TTL 值?太 短的 TTL 值會使得有效的檔案太少,造成快取的命中率偏低。

而太長的 TTL 值會造成使用者取得過時的檔案之機會大增。

目前亦有改良式的 TTL 值設定理論,較能有效的平衡 TTL 的 問題。

由來源伺服器主動通知代理伺服器資料過期是不可行 的,一份資料可能被千萬個代理伺服器所快取,這樣的做法會 造成伺服器的負載過重。利用設定 TTL 的方式,如何決定一 個適當 TTL 的值是很難決定的。客戶端主動跟伺服端作有效 確認是比較可行的方法。[WinFTP, Zeng99, Luot94]

2.4.3 快取機制的改良法

現今改良方式的 Squid Proxy Server 的快取機制和其他網際網路 代理伺服器最大的不同點在於,Squid Proxy Server 1.1 版後不再使用 依靠設定 Time-To-Live (TTL)值的清除機制模式(expiration model),取 而代之的方法是使用 Refresh-Rate model。

對於因使用者要求(request)而進入快取系統的網路檔案計算出新 穎度(freshness)的因子(factor)。當被快取下來的網路檔案又再度被後 續的使用者要求讀取時,Squid Proxy Server 依照新方法來做出判斷,

(22)

假如回傳「新穎」(Fresh)則將此快取網路檔案物件直接傳送給使用 者,假如回傳「過時」(Stale)則不將此快取網路檔案物件傳給使用者,

取而代之的是為該使用者產生包含「If-Modified-Since」的 HTTP 要 求給原始目的網路站台,等待原始站台對「If-Modified-Since」要求 的回應而決定重新自原始伺服器傳輸一次或是傳輸快取網路檔案資 料給使用者。[WinFTP, Zeng99, Luot94]

而 Squid Proxy Server 對快取網路檔案物件採用的清除機制是使 用 Least-Recently-Used(LRU)替換法則演算法,當快取資料總量超過 代理伺服器管理員設定的高水位(high-water mark)限制時即從 LRU age 較大的快取物件開始進行清除的動作。由於其所採用的這快取清 除機制有考慮到該網路檔案的原始日期、最後修改日期、進入快取日 期、HTTP/1.1 的 Cache-Control 欄位資料、全球資訊網伺服器端回傳 的設定清除日期等...較多的因子,因此其快取物件的壽命相較於一般 使用人工設定 Time-To-Live 值方式的網路代理伺服器合理,具有較 強的檔案一致性(consistency policy),較為適用目前資料多變化的網際 網路。[WinFTP, Zeng99, Luot94]

使用者對於網路檔案的讀取是具有時間區域特性(Temporal

Locailty),為了達到讓使用者能讀取到最新的網路資料,而不需要使 用者費時手動更新的目的,因此有 Update Engine。

為了達到自動調適更新(auto-update)的效果,必須預估出何時該 去對一個網路檔案進行預取更新的動作,對每個網路檔案訂出一個自

(23)

動調適預取更新時間週期(Time-To-Update)。Time-To-Update 數值的 計算以該網路檔案的壽命(即其平均更新時間週期)為基準值,加乘上 其網路地理位址及其對應網路主幹目前負載狀況,針對當某網路檔案 的對應網路主幹線路較為忙碌的時候,藉由 TTU 值的放大而減少預 取更新動作的發生,而當在其對應網路主幹負載較輕時進行較多的預 取更新動作。

公式 2 - 1 TTU 計算公式[WinFTP]

而針對此法,可以加入多種考量,以改良之。

1. 目前的時間距離該網路檔案上次更新時間已大於該網路檔案之 Time-To-Update 值。

2. 在上一次對該檔案做預取更新後,是否後續有使用來讀取預取更 新過後的新資料。

當條件 1 及條件 2 同時成立時,代表該網路檔案在原始站台很可 能已經更新過了,而且該網路檔案近期具有一定程度的熱門性(上次 更新過後陸續有使用者讀取該網路檔案),因此我們即對該網路檔案 進行預取更新的動作。若當條件 1 成立但是條件 2 未成立時,也就代

TTU= {ac × [1 + ( mL -aL) / aL]}

ac:該網路檔案平均更新時間週期 mL:對應網路主幹目前負荷值 aL:對應網路主幹平均負荷值

(24)

表了上次預取更新後並未有後續使用者來讀取,我們知道該網路檔案 的熱門性可能正在衰退中。此時為了避免系統對這個過時網路檔案依 據以前的 TTU 值來持續做預取更新的行為而產生浪費網路頻寬的情 形,必須降低這個網路檔案預取更新行為的發生的頻次。[WinFTP, Zeng99, Luot94]

公式 2 - 2 網路檔案更新時間週期調整公式[WinFTP]

2.5 網路預取技術

網路預取(Prefetch),所謂的預取技術主要依靠使用者過去的使用 記錄或是根據網路檔案資料內相關超連結(Hyper Link)來建立網路檔 案存取模組,而由使用者端或是中繼體(如網際網路代理伺服器、防 火牆、路由器)於當使用者正讀取某網路資料時,將其後續可能被使 用者讀取的網路檔案做預先傳輸載入的動作,以降低使用者等待傳輸

Modified TTU = oac × ( 1 +arc / aarc )

oac = 原更新時間週期 arc = 平均讀取時間週期

aarc =全部網路檔案平均讀取時間週期

(25)

後續網路檔案所需的時間,讓使用者整體存取網路檔案的行為能有較 短反應延遲(response latency)。由於是在使用者尚未發出驅動需求 (Demand Request)即進行了檔案傳送的行為,必然會需要消耗較多的 網路頻寬,再加上對使用者後續存取行為的猜測(Predictive)亦不可能 百分之百正確,而增加了預取錯誤所付出的代價(penalty)。[Chan99]

預取系統適用的基本條件為:

1. 其網路頻寬為非共享式的網路(如 modem 撥接使用者)。

2. 具高頻寬高延遲時間(high latency)的網路(如衛星線路)。

3. 固接專線網路的非尖峰時段(none-busy time)。

而推送技術和預取技術最大的不同點在於推送技術主要是倚靠伺 服器端發動檔案傳輸或是告知使用者有新的網路資料,形成預先存放 或是類似廣播頻道的功能。由於負責推送的伺服器端較不容易掌控使 用者端的網路狀況及個人需求行為模式(User Demand),比起預取行為 更容易造成網路頻寬的浪費,推送的另外一個問題是容易發生伺服器 端推送使用者並不感興趣的資料而讓人抱怨(如商業廣告等..),因此推 送技術並未如預期般的廣泛被使用。[PCInc, MCDF, NCCN, Chan99]

而在網路預取的部分,其優點可以方便使用者,而網路預取技術 中,相對的會對網路頻寬有所影響,不過實際的影響量,可能還需要 更詳細的評估,因此規劃為未來可以加入的方向。在本研究中,僅止 於簡單的探討,並尚未實際運用該技術。

(26)

2.6 Caching FTP Server

HENSA Caching FTP Server[Russ98]是英國有名的一個 FTP

Server,除了利用人工管理檔案之外,並提供了一個網頁介面的 CFTP Server 供使用者讀取檔案。而網頁介面則是該 CFTP Server 所實際提 供的 Client 端,使用者在點選檔案,發出要求,則該 CFTP Server 會 檢視是否有該檔案,如果有的話則直接給予使用者,如果沒有則會從 原始站台下載檔案給欲使用者,並儲存一份在 CFTP Server 上,以提 供給下一個使用者。

圖 2.1 HEANSA CFTP 的 Web 介面[CFTP]

(27)

根據 Russell 以及 Hopkins 統計的數據[Russ98],其實非常少的檔 案,真正的在檔案傳輸伺服器中被使用者要求。就重複使用率的統計 而言,大約百分之四十到五十的檔案是較具重複使用的代表性。因此 不斷的追蹤所有檔案將會造成浪費頻寬,而快取則能夠改善此問題。

為了讓檔案傳輸伺服器達到更佳的效能,[Russ98]提出快取的觀念,

運用虛擬結構樹的想法,而為了達到較佳效果,使用者可選用專門的 客戶端軟體,或透過設定來使用虛擬結構樹的檔案傳輸伺服器。

表 2.1 Distribution of requests by sites [Russ98]

#Sites %Sites %Request %Data 4

7 16 31 60 148 294 1464 2926

0.1 0.2 0.5 1.0 2.0 5.0 10.0 50.0 100.0

40.0 46.2 54.4 61.8 70.0 80.0 86.9 97.9 100.0

41.8 50.5 56.5 62.6 69.0 78.7 85.6 98.2 100.0

而另一個 CFTP 的系統,由曾黎明與呂信益設計的以需求為導向 之資料複製再用型檔案傳輸伺服器中[Zeng99],提出以使用者驅動複 製檔案,同時利用檔案上傳和檔案預約的方式運作,並讓使用者在複 製過程中提供資訊協助檔案自動分類及產生說明檔。

(28)

而我們所設計的快取檔案傳輸伺服器亦是利用快取的觀念來架 設檔案傳輸伺服器。我們設計以虛擬目錄為結構,改進鏡射的方法,

只鏡射原始站台的目錄結構,整合了快取與鏡射的檔案傳輸服務。除 此之外,我們加入最佳路徑選擇功能,提供較佳的即時檔案連結路徑 判斷。使用者不必額外要使用或設定軟體,只需依照一般檔案傳輸方 式,整個系統架構,使用者是感覺不出與一般有差別。另外還有所設 計採用的更新機制及資料蒐集分析等,將會於後章節一併討論。而相 關的檔案傳輸伺服器比較,將於後之章節說明。

(29)

第參章 整合快取與鏡射之系統架構

本論文最主要是在於改善檔案傳輸伺服器在做資料處理與傳送 的效能。主要的工作核心是著重於虛擬目錄架構的快取檔案傳輸伺服 器。以下小節將分別詳細說明規劃設計之系統架構。

3.1 系統架構

使用者透過正常使用的方式使用檔案傳輸伺服器,當快取檔案傳 輸伺服器收到使用者的要求,會比對是否在快取裡有此檔案或是第一 次收到要求。如果是既存檔案,則是會透過更新引擎(Update Engine)

去確認是否需要更新。如果需要的檔案既存並需要更新,或是檔案並 不存在快取之中,則系統透過路徑選擇器(Resource Selector),經由 資料蒐集分析機制,到原始站台或是其他鏡射站台抓取使用者要求之 檔案,並回傳、記錄到快取之中,再發送給使用者。而使用者將感覺 不出有虛擬目錄架構之快取檔案服務。如圖 3.1 顯示。

其中關於更新引擎的部分,可分為兩部分,一為線上即時性

(On-line)的判斷檔案是否需要更新。另一部份則是批次作業(Batch Time),透過批次作業方式來判斷一些逐漸較不常被使用者要求之檔 案,是否需要被預存於快取之中。

(30)

在路徑選擇器的部分,當檔案透過線上即時性更新引擎判斷之 後,若檔案屬已經過時,需要被更新,則透過路徑選擇器的機制,自 動選擇欲抓取該檔案之最佳路徑,有可能是原始站台或是其他鏡射站 台。而路徑選擇器將透過資料蒐集機制與分析之輔助,來進行最佳路 徑之選擇。

另外,未來還可以擴展的系統中,在檔案傳輸服務(FTP Service) 裡,可再加入預取(Prefetch)功能。透過預取可以提供使用者更快 速便利的存取檔案。而目前在本研究的系統架構中,尚屬規劃加入階 段,在此尚未實際加入預取系統之運作。

圖 3.1 快取檔案伺服器系統架構圖

CFTP Manager

Virtual Directory

Proxy Cache

Resource Selector

Evaluation Module

Update Engine

Update Log

Prefetch Analyzer

Request History Prefetch

Engine

Original Site

Mirror Site

• User

User

User

(31)

3.2 架構元件

快取檔案傳輸伺服器系統架構,如圖 3.1 顯示,其組成的原件,

將在以下小節分別介紹。而除了系統架構的介紹之外,我們還會對於 系統所需的依據所應有的資料蒐集機制做介紹。

3.2.1 快取檔案伺服器管理員( CFTP Manager)

快取檔案伺服器管理員是系統的主要部分,主要系統架構是以虛 擬目錄的方式提供檔案傳輸服務。使用者將依一般使用檔案傳輸服務 之方式或軟體正常使用,將感覺不出本系統與一般檔案傳輸服務有何 差別。

當快取檔案伺服器管理員收到使用者發出的資料傳送的要求 時,會決定接下來所要採取的步驟,如果所需求的檔案已經存在於快 取,將會直接傳給使用者,反之則會透過路徑選擇器(Resource Selector)選擇所要抓取的檔案來源最佳路徑,可能是某鏡射站台或 是原始站台,以節省重新傳輸的時間。

而在未來可以加入的部分是預取的功能,經由歷史紀錄來分析使 用者行為,並預取使用者可能常抓取的檔案。整個快取檔案伺服器管 理員運作的流程如圖 3.2 所示。

(32)

圖 3.2 快取檔案伺服器管理員控制流程圖

3.2.2 虛擬目錄( Virtual Directory)

本研究主要利用虛擬目錄的方式來達到改善檔案傳輸服務的效 能,此為本研究的重要觀念。我們不難從一些經驗、歷史資料中發現,

有許多的檔案在伺服器(如檔案傳輸伺服器)中是不常被使用的,雖 然現今硬體空間的價格比已經相當便宜,不過,在檔案傳輸伺服器的 更新機制,卻常常會去檢查原始站台,以對應一致性,因此相當的浪

No Yes Yes

No Locate the requested file

Send file to user Found ?

Pass Request Information to Prefetch Analyzer

Pass request to Resource Selector

Activate Prefetch Engine Check refresh rate model

Should refresh

Get from mirror or original site

Update to proxy cache

Modified update model

(33)

在鏡射站台的部分,我們針對原本鏡射的缺點,設計了虛擬目錄 的結構。而為了改進一部份被鏡射回來的檔案被使用率過低或者根本 不曾被使用過,我們改進的方法是建立一個與原始站台上一模一樣的 目錄結構,包含了目錄名稱及目錄下包含的檔案名稱、大小以及日 期,一切就如同將這些檔案複製了一份在鏡射站台。但事實上,這些 都是虛擬的,即我們所謂的虛擬目錄的結構。我們只需設立一個虛擬 目錄,對應原始站台的目錄,但實際檔案並不存在,只需存放較熱門 的檔案,以供存取。不但可以有效的減低網路頻寬的消耗,亦可以減 少空間的浪費、系統的負擔以及檔案的再利用性。至於相關的機制和 理論架構,均述如下。

3.2.3 快取代理伺服器 (Proxy Cache)

在系統架構裡,運用快取的觀念來架設檔案傳輸服務,以增進檔 案傳輸的效能以及改善缺點。而目前快取代理伺服器被廣泛使用的主 要原因有:具有節省網路頻寬的功能、具有阻隔網路的功能、具有階 層式架構(Hierarchical Architecture)的功能。

早期代理伺服器上快取的運作機制採用人工設定定期更新

(Time-To- Live ,TTL)的方式,一個網路檔案首次被讀取後系統存

(34)

放在快取中,後續使用者對同一網路檔案的讀取行為即會命中快取 (hit cache),直到到期而遭到清除。Squid 代理伺服器的快取機制和其 他網際網路代理伺服器最大的不同點在於,Squid 代理伺服器 1.1 版 後不再使用依靠設定定期更新值的清除機制模式(expiration model),

取而代之的方法是使用更新率模式(Refresh-Rate model)。

而 Squid 代理伺服器對快取網路檔案物件採用的清除機制是使 用 Least-Recently-Used(LRU)替換法則演算法,當快取資料總量超過 代理伺服器管理員設定的高水位(high-water mark)限制時即從 LRU age 較大的快取物件開始進行清除的動作。由於其所採用的這快取清 除機制有考慮到該網路檔案的原始日期、最後修改日期、進入快取日 期、HTTP/1.1 的 Cache-Control 欄位資料、全球資訊網伺服器端回傳 的設定清除日期等...較多的因子,因此其快取物件的壽命相較於一般 使用人工設定 Time-To-Live 值方式的網路代理伺服器合理,具有較 強的檔案一致性,較為適用目前資料多變化的網際網路。

3.2.4 更新引擎( Update Engine)

在更新引擎的運作模式,使用者對於檔案的讀取是具有時間區域 特性,為了達到讓使用者能讀取到最新的網路資料,而不需要使用者 費時手動更新的目的,因此有更新引擎。更新引擎可分為兩的部分,

一部份是線上即時型(One-line)與批次作業(Batch Time)。

(35)

線上即時型的運作,在於當使用者所要求的檔案,經由快取檔案 伺服器管理員判斷該檔案已存在於快取之中,必須衡量該檔案是否已 經有可能過期,也就是與原始站台的檔案發生不一致性問題,因此我 們必須透過更新機制的運算來決定檔案是否已經過期。如果檔案尚未 過期,即可直接從快取中回傳給使用者;若該檔案已過期,則必須經 由路徑選擇器立刻重新抓取最新的檔案。如圖 3.3。

批次作業的部分,即於一般非即時作業時間,對快取部分中的檔 案進行檔案更新與否之機制運算與判斷。為了達到自動更新的效果,

我們必須預估出何時該去對一個檔案進行預取更新的動作,我們對每 個網路檔案訂出一個自動調適預取更新時間週期(Time-To-Update)。

我們所要考慮到的有,檔案的熱門程度以及該檔案的更新率高低 與否。熱門程度高,應考慮到檔案更新頻率與次數可能較高,反之若 是檔案熱門程度衰退,此時為了避免系統對這個過時網路檔案調整更 新週期以避免不斷更新的行為而產生浪費網路頻寬的情形,我們必須 調整這個網路檔案更新行為的發生的頻率、次數。如圖 3.4。

(36)

圖 3.3 更新引擎控制流程圖

圖 3.4 更新機制流程圖

Compare current time with the last checked time

Time to check Do nothing

Check consistency

Modified last checked time

Adjust frequency if necessary

Pass request to resource selector

Yes

No

Time to update

Update the file

Modified last update time

Yes

No

Time gap > TTU No update

Refresh

Enlarge update period

Yes

No

Reuse after last update?

Yes

No

Check refresh

(37)

3.2.5 路徑選擇器(Resource Selector)

對於使用者實際發出要求,如本論文所提的確認檔案機制,若是 在本地端無法提供,或是檔案已經過期而必須即時更新、重新抓取檔 案,必須前往原始站台或是較近的幾個鏡射站台去讀取。而透過此路 徑選擇器,可以自動選擇較佳路徑,有時候可能會限於網路實體狀 況,例如較近的對應網站不見得較快,透過此機制讓系統自動選擇,

並且讓使用者感覺不出來,即達到所謂自動選擇的功能。而此機制所 要考慮的,當然最重要的一點就是網路傳輸效率及伺服器的效能。我 們可以透過歷史資料統計圖表(history good performance path)等,來做 為參考依據。另一考量,就是即時狀況,原始或鏡射站台的效能,而 系統所需的資訊以及產生的資料,將於下節利用資料蒐集的機制作討 論。示意如圖 3.5。

圖 3.5 路徑選擇器示意圖

•••••

Resource Selector

Mirror Site Mirror Site Mirror Site

•••••

•••••

Original Site Original Site Original Site

Mirroring by the Internet

(38)

圖 3.6 路徑選擇器控制流程圖

在路徑選擇器的作法,如圖 3.6,本研究所採用的解決方式、模 式,是透過查驗原始站台線上即時的狀況,以及經由資料蒐集機制所 提供歷史資料之評估分析,來決定選擇出目前較佳的路徑。

當有系統有需求給予路徑選擇器,路徑選擇器將優先判斷鄰近節 點(Sibling)的站台是否有該檔案,由於本系統架構是透過虛擬目錄 方式運作,因此為將所有檔案鏡射於站台之中,而鄰近節點則是一般 的檔案傳輸伺服器,因此當有檔案不存在於本系統之快取之中時,可 直接透過鄰近節點站台尋求該檔案,如果鄰近節點站台有該檔案,我 們可以較快速的抓取,以迅速回傳給使用者。

Check sibling has the file

Found ? Get from sibling

Get history of good performance path from all mirror sites and original site

Compare all sites’ network performance

Evaluation model

Get the file

Modified the history of good performance path

Yes

No

(39)

若鄰近節點站台沒有該檔案,我們將透過路徑選擇器機制中,資 料蒐集機制所節取、評估分析之歷史資料做為參考,並對各對應之鏡 射站台與原始站台作即時性的效能評析。

網路流量與狀況,我們可以透過幾個簡單的方式去做檢查,如:

1. 利用 ping 的方式,關於 ping,它是使用 ICMP(Internet Control Message Protocol)協定的 ECHO﹒REQUEST 封包,以強迫特定主 機回應。執行 ping 之後,可以得到封包從本地到目的地來回的總 時間。用 UDP 去測試,可看出網路反應狀況,不過,基本上這也 是會花費頻寬的。這是簡單但是相當實用的方式可以測知站台的 線上即時狀況。

2. 統計 SNMP(single network management protocol),透過程式去擷 取、測試資料。此法亦可行,可用圖表方式表現出網路狀況。不 過硬體的設備必須支援支援 SNMP。

3. 利用 traceroute IP/Domain,可以 trace 網路的路徑、經由的節點與 狀況。

4. 一些應用軟體,有相當多的商業軟體或是 shareware 逐漸普及,皆 可提供相關資訊。

(40)

由於線上即時測量的站台狀況,不見得完全準確,例如 ping 值 低,代表站台網路路徑反應快,但是卻有可能常常發生封包遺漏,導 致資料不完整、不正確,而需要重新擷取而花費時間與頻寬。因此我 們亦將考慮歷史紀錄。

系統將即時性所測得之反應值如 ping 值,將之切割成等分,每 一百為一等分,例如 ping 值若測得 0∼99,得到判斷值 0 分,100∼

199 為判斷值 1 分,200∼299 得判斷值 2 分,以此類推。因此得到之 判斷值越低代表該站台網路傳輸路徑反應越快。將判斷值設權重為百 分之五十。而每次決定之路徑站台的傳輸狀況將透過資料蒐集機制記 錄下來,因此系統將另外百分之五十之權重設定為歷史紀錄中,亦透 過 ping 值同樣方法之判斷值方式獲得。

藉由線上即時測得各站台所獲得之權重與歷史紀錄之站台狀況 兩者加以評析,取出所獲得之權重值評量最低之站台,這表示所獲選 之該站台計有即時兩好狀況與歷史紀錄良好之評估基礎。

本研究所採用的解決方法、模式,乃評估鑑於網路實體有許多不 可抗力之因素,而所採行的一套評估最佳路徑之解決模式。透過此模 式來獲取決定最佳路徑之選擇。而經由最佳路徑之選擇,擷取檔案,

存放於快取之中,更新檔案的新穎度之更新判斷值,以及記錄於歷史 資料當中,作為資料蒐集機制之參考。並將該檔案回傳給使用者。

(41)

3.3 資料蒐集機制(Information Gathering)

大部分的檔案傳輸伺服器的相關資訊是由伺服器所紀錄提供但 是無法完全完整呈現使用者存取時的所需要的資訊,因此,為了要能 獲得更完整的資訊,我們透過資料蒐集機制來獲取,藉以能夠透過這 些較完整的資訊來整合及測試,使系統運作。

首先在確認檔案存在快取與否的程序裡,必須要檢查檔案是否存 在於快取之中,可由代理伺服器中擷取相關資訊,並改寫存取於資料 庫之中,藉以日後判定檔案存在與否。

在路徑選擇器機制裡,檔案傳輸是先透過代理伺服器的運作來抓 取資料,若是快取中無此資料,則需立即到鏡射站台或原始站台抓 取,而最佳路徑的選擇,則使用路徑選擇器。必須要有資料作為路徑 選擇器的依據,這些依據必須靠本系統去產生。透過即時測試網路狀 況,所獲取之資訊,將之記錄於資料庫中,記錄網站網路連線狀況,

並記錄該網站選取連結的次數,成為歷史資料,日後並將歷史資料提 供作為路徑選擇時之判斷參考。

在系統建置前,需要大量的資料來源作為系統架構可行性分析的 依據,以及實際測試、開發時所需要有的參考,因此必須藉由許多資 料、內容的蒐集與方法來幫助系統開發與分析,藉由本地端及鄰近端 網際網路代理伺服器的記錄檔、本地端檔案傳輸伺服器的記錄檔、全 球資訊網伺服器的記錄檔… … 等方式獲得所需的資訊。

(42)

依照所得到的資料記錄各網路檔案被使用者讀取的次數 (reference count)、網際網路代理伺服器快取擊中的次數(cache hit count)、最後被讀取的時間(last reference date)、最後被使用者手動更 新的時間(last modify date)… … 等,進而統計後,可以計算出該網路檔 案平均被使用者讀取的時間週期(average reference cycle time)及平均 被使用者更新的時間週期(average modify cycle time)。記錄於資料庫 之中,可作為系統分析與實作時,更新機制所需的資料來源。

系統模擬實作時,使用者要求的檔案記錄,利用現行網路實體運 作之檔案傳輸伺服器之記錄檔,解讀記錄檔,以模擬使用者實際於本 系統所提之需求,作為使用者需求之資料來源。

除了一般所提供的功能之外,還可以從中獲取額外資訊,以利統 計分析出附加價值。如:可獲取其他鏡射站台或原始站台的名稱及連 線狀況,藉以未來路徑選擇時之依據。檔案種類、大小、使用度等,

可藉此對檔案物件作分析管理,而在連線的時間狀態,可萃取網路連 線的時間性,如此可供管理者要對快取做批次確認更新機制時的時間 管理。而在快取中的檔案物件,可以分析其檔案之使用度、重要性,

藉以釐清其檔案存取優先權。

透過此資料蒐集,藉此整合資料來源,以供整體系統運作時,各 部分所需之資料來源與存取。相關內容會於後實作章節加以說明。

(43)

3.4 檔案傳輸伺服器之比較

關於各快取檔案傳輸伺服器,針對 HENSA CFTP Server 及 MOD System 與本論文所提的系統架構,其中各系統皆有相同之功能即為 提供檔案傳輸服務,與結合鏡射與快取功能。

而其他則各有不同的功能,如:同時間下載所選定之多重檔案、

優先確認鄰近點鏡射站台、列出其他檔案傳輸伺服器所提供之檔案目 錄、檔案更新機制分列即時線上更新以及批次作業、路徑選擇器機 制、搜尋引擎、允許檔案上傳、允許使用者對所需檔案先行預約,以 利下次上線下載等。

而表 3.1 是 HENSA CFTP Server 及 MOD System 與本論文所提的 系統架構( Modified Virtual Directory System)的差異。對於其中各項 分列如下,而各項差異見表 3.1。

(44)

表 3.1 HENSA CFTP Server、MOD System 與本系統架構的差異 HENSA

CFTP

MOD System

Our MVD System 1.Proxy/FTP Service ○ ○ ○ 2.Combine mirroring and caching ○ ○ ○ 3.Download multiple files

simultaneously

4.Sibling site checking ○ 5.Other FTP site directory listing ○

6.Online/Batch refresh checking ○ 7.Resource Selecting Checking ○ 8.Search Engine ○ ○

9.File Upload ○

10.File Ordering ○

(45)

第肆章 系統設計與實作

本章據所提的架構,對所規劃之系統架構加以說明,並以模擬方 式進行開發測試,依據所得之數據資料再對系統架構能多做評估與調 整。在本章中將要介紹系統開發的平台、資料定義,與模擬實做研究。

4.1 系統架構平台

關於系統的架構平台,本研究規劃架構作業系統是以 UNIX 系統 為主的 FreeBSD 4.2 Release 版[FreeBSD]。檔案傳輸伺服器是廣泛被 使用、跨平台的 WuFTP[WuFTPab]。而網路代理伺服器則是相容多功 能包含檔案傳輸伺服器的 Squid。而在記錄系統資料庫則是採用強 健、快速的資料庫系統 MySQL。透過跨平台 JAVA 程式開發。

本論文之系統規劃設計的實作平台如圖 4.1 所示。以下小節將針 對平台各部分做一說明。

圖 4.1 整合快取與鏡射檔案傳輸服務之系統平台

Requests Files

FreeBSD Files

Modified WuFTP Server Caching FTP

File System

JAVA

Database (MySQL)

User

(46)

4.1.1 作業系統 FreeBSD

在設計上,本研究所採取的是平台是以 UNIX 系統為主,而所採 用的 UNIX 軟體版本為 FreeBSD 4.2 Release 版,由於 FreeBSD 是個 完整,具專業水準的 UNIX 作業系統。近年來更在網際網路上成為 非常熱門的話題,具有穩定的作業系統,其作業系統的更新速度亦是 相當快,廣泛的被運用在學術界以及一般大眾,凡舉網路、資料庫、

文書處理、電腦輔助設計、X 視窗、影像處理、中文、程式發展、模 擬器、遊戲等等都有極佳的評績。功能不比商業版的 UNIX 遜色,有 些地方還猶有過及。短短的幾年間就擁有眾多的使用人口,尤其是伺 服器以及程式開發者。

4.1.2 檔案傳輸伺服器

檔案傳輸伺服器,採用廣泛被使用的 WuFTP 軟體,目前最常使 用免費的檔案傳輸伺服器大致是 Wu-ftpd 與 Proftpd,兩者在檔案傳輸 協定的服務上看起來是一樣的,但是在組態上卻是迥然不同的。

Wu-ftpd 較早發行,伺服器的組織較為零散,安全性較 Proftpd 差,但 穩定性較好,尤其同時連線人數一多,很明顯的,Wu-ftpd 要比 Proftpd 來的好,不過整體而言,Wu-ftpd 伺服器發展較久、系統較穩定,在 最新版裡( 2.6.x)已經對最為人病垢的系統安全性問題做一完善的修 正,因此還是檔案傳輸伺服器中的主流。

(47)

下列是 Wu-Ftpd 的一些功能:

1. 可記錄檔案傳輸伺服器使用情形。

2. 可對不同網域做不同存取權限和可存取時段。

3. 提供 user 在下載檔案的時,可自動壓縮或解壓。

4.可限定最多連線人數,以符合整體運作效能。

5.顯示相關訊息,讓使用者瞭解接收狀態。

6.當系統需要維護時,可將檔案傳輸伺服器暫停,便於系統維護。

7.支援虛擬檔案傳輸伺服器主機(Virtual FTP Servers)。

而在研究的設計系統裡,規劃設計以改寫 WuFTP 的方式,使可 以虛擬目錄的方式來運作,而透過連結資料庫的方式來支援改寫式的 檔案傳輸伺服器( Modified FTP Server),並結合快取功能,以及鏡射 機制。

本研究系統會用到前述快取代理伺服器、以及修正鏡射架構的虛 擬目錄之處理與相關功能,加到現有的檔案傳輸服務中,而透過資料 庫記錄系統所因應與產生的資料,以利統計分析以及程式運作。

4.1.3 資料庫 MySQL

而資料庫方面,採用 MySQL,它是由瑞典斯德歌爾摩一家叫作

(48)

T.c.X. DataKonsultAB(http://www.tcx.se) 的公司所開發,是一個真正 多使用者 (Multi-User)、多執行程序 (Multi-Thread) 的 SQL Server,

採用最普遍的 SQL(Structured Query Language) 語法,擁有多種作業 環境下 (Win32、Unix),的伺服器端程式與多種客戶端支援。依照 T.c.X 的說法是,當初 MySQL 為了自我本身需求,需要一套又快速、

又能夠管理大型資料的伺服器,進而所發展出來的,主要的目標就是

「快速、穩健、使用簡單」。而該資料庫不僅為免費軟體可供學術研 究之外,亦足以應付一般之需求。

4.1.4 程式語言 JAVA

Java 本身具備幾個特性,諸如:簡單、分散式、物件導向程式設 計、安全性、強韌性、架構中立性、跨平台、可移植性、可解譯、多 重線串、動態等特性。整體串連系統用的程式語言所採用的是跨平台 的 Java。透過 Java 改寫檔案傳輸伺服器,予以應用虛擬目錄之架構,

並整合資料庫用以存取整體系統之運作,串連鏡射及快取之檔案傳輸 服務,並提供資料蒐集、整合分析之用。而 Java 本身因具備跨平台 轉移之特性,因此在未來作系統轉移時,將可正常運作。

(49)

4.2 資料定義

為記錄並維護檔案傳輸服務中所需之相關資料,我們利用在 UNIX 作業平台上使用的關聯式資料庫 MySQL 作資料的存取,資料 庫中的資料項目包含一般客戶端的需求記錄以及與檔案傳輸伺服器 相關的資料,這些資料用於紀錄與維護檔案傳輸服務所需的功能、機 制與運作,以及歷史紀錄供作分析,主要資料項目如下:

檔案存取記錄:修改、存取伺服器原有的一般記錄,存放來自使 用者檔案需求之歷史紀錄。

檔案更新紀錄:存取檔案的更新時間、上次更新時間、最近更新 時間、檔案更新頻率次數等。

快取相關資料:存取紀錄快取大小、內容、檔案配置與紀錄。

檔案基本資料:存取檔案所存在的目錄、檔名、檔案容量、虛擬 檔案連結路徑、流量統計等資料。

相關維護記錄:彙整記錄系統所需的資料,包含檔案被要求次 數、快取命中次數、最後參照日期、最後更動日期,以及檔案傳輸 站台資訊(網址、站台狀況、系統資訊)等。

其資料定義如表 4.1∼4.7,而其中增加的表 4.6 與表 4.7 為 模擬測試時,為紀錄模擬使用者接收到檔案以及路徑選擇器被驅 動之紀錄。

(50)

表 4.1 accesslog

欄位名稱 資料型態 長度 備註

acc_id integer

time datetime 啟使時間

remotehost char t 15 IP

user char 40

code_status char 5 狀態碼

bytes bigint 傳輸大小

method char

url char 10 FTP 網址

filename char 50

date datetime 50

expire_time datetime

表 4.2 updatelog

欄位名稱 資料型態 長度 備註

upd_id integer fileno integer

cost_time time 更新檔案所花費時間

lastmod datetime 上次更新時間

modcount integer 更新頻率

lastref datetime

表 4.3 cachelog

欄位名稱 資料型態 長度 備註

cac_id integer fileno integer cachesize bigint

urlpath char 255 此物件的 URL

timestamp datetime 此物件最近被確認的時間

expire datetime lastmod datetime

filename char 255

(51)

表 4.4 dataprofile

欄位名稱 資料型態 長度 備註

dat_id integer

directory char 255 實體路徑

filename char 255

size bigint

linkpath char 255 連結路徑

hitcount integer fileno integer

表 4.5 datainfo

欄位名稱 資料型態 長度 備註

inf_id integer

filehitcount integer 檔案重複命中次數

cachehitcount integer 快取重複命中次數

lastref char 255

lastmod datetime

refurl char 255

refsitestatus char 255 網站狀態

refinfo char 255 網站相關資訊備註

表 4.6 rec_selector

欄位名稱 資料型態 長度 備註

rec_id integer

rec_count integer 模擬確認次數

rec_from char 255

表 4.7 user_pro

欄位名稱 資料型態 長度 備註

user_id integer

user_get char 20

(52)

4.3 實作模擬平台

在系統規劃設計架構方面,是屬於線上運作的模式,而本研究所 採行的模式是利用模擬測試的方法。為了要能測試達成原有功能,透 過跨平台的特性與整合,仍以相同、跨平台之架構作為模擬測試。若 改以上線的的方式,可能面臨的問題有幾點,例如:實際上使用者連 線到自行架設的網站使用機率不高,可能會對於使用者要求的次數不 夠與種類較為偏頗,反而會造成數據的不準確性,此外需要較長時間 性的擷取數據等困難點。而本論文利用模擬的方式,以實際在網際網 路上大量被使用的 Hinet 網站之使用者紀錄作為使用者要求之模擬,

能有效提供數據的準確性。

4.3.1 軟硬體平台

所採用的模擬測試平台,在硬體方面,所採用的是 Pentium III 700 CPU,256MB SDRAM,12GB 硬碟。在軟體方面,作業系統為 Windows 2000 Server 版(Service Pack 1),而資料庫採用 Win32 核心的

MySQL,具備快平台轉移的特性。而程式語言方面,所採用的是 Java JDK 1.3。因此,不論是在程式或資料庫方面,皆具備跨平台轉移之 特性,藉此可以透過模擬測試之方式,以驗證原系統規劃之架構。如 圖 4.2 所示。

(53)

圖 4.2 模擬測試之系統平台

根據本系統架構,將以模擬測試方式進行,因此所採用的系統軟 體平台等,皆具有跨平台的特性。因此,在測試本模擬系統之可行性 之後,可以利用跨平台轉移的特性,將系統轉移到原設計之平台。如 資料庫 MySQL,原始平台其實是在 UNIX 上,其後為方便使用者,

因此推出 Win32 版本的平台。因此在資料庫轉移上是相容的。而在 程式的部分,由於 Java 本身就具備跨平台特性,因此在程式部分較 沒有問題。透過系統平台的轉移,即可正常的運作。而在此將對所設 計的平台作一模擬測試。

4.3.2 模擬測試之考量

由於線上測試的方式,有許多問題與困難點,採用模擬測試的原 因如:

Simulation results

LogFiles Requests

Windows 2000 Server Files

Simulation FTP Server Caching FTP

Win32 File System

JAVA

Database (MySQL)

User

(54)

與官方網站的檔案傳輸伺服器合作上會有一定的困難點,如溝 通、配合、軟硬體技術、人力維護等等,都可能是無法直接上線原因 之一。

而本檔案傳輸服務網站必須要有足夠的使用者真正到本網站使 用,必須有足夠的使用量,要長時間的累計資料量。如果沒有太多的 使用者存取,反而這些使用者要求不具有代表性。

因此,採用模擬方式也有模擬的好處,如:所採用的模擬數據是 由 Hinet 所提供的紀錄檔,其中的使用者存取記錄,流動性高、資料 量大,取其記錄作為模擬測試讓數據與結果較具有真實性與代表性。

雖然本實驗是透過模擬方式,但是仍採用真正的網路使用數據,且 Hinet 的資料樣本也夠大,因此在模擬之可信度上亦能較為準確。

此外,透過模擬測試,我們可以從中規劃、獲取所需要的資料,

即資料蒐集機制,而且可以另外設計規劃額外所能擷取之資訊,藉以 提供更多的數據統計分析。

4.3.3 系統分析設計

本研究採用的模擬方式,依據原架構流程,由線上方式改由封閉 式模擬,利用程式的來模擬流程。從使用者的要求,透過檔案傳輸伺 服器的紀錄檔,從中取出使用者要求記錄,作為系統的模擬使用者要

(55)

求,其記錄檔的資料來源是由 Hinet 提供,屬於實際在網際網路上運 作之檔案傳輸服務記錄。

模擬之系統分析設計如圖 4.3 及圖 4.4。

圖 4.3 第一層 DFD Main Process

在主要處理程序的資料流程圖裡面,其各個程序與資料儲存 (Data Store)相關的資料流動狀況。而相關的資料儲存於資料定義(資 料庫)中有描述。

1.0

Check File

2.0

Resource Selector

3.0

Update

5.0

Refresh

4.0

Send File Cache_logs

Data Profile

Update_logs Data_Info Access_logs Client

Remote

site

(56)

1. 確認檔案程序:

a. 當使用者要求檔案時,其要求之記錄會被儲存於「檔案存取紀 錄」(不論使否抓取檔案,皆會被紀錄)。

b. 當列出目錄結構給使用者時,會從「檔案基本資料」讀取,顯 示目錄、檔名、大小… … 等相關訊息。

c. 檢查檔案是否儲存於快取之中,由「快取相關資料」中讀取。

2. 路徑選擇器程序:

a. 當系統透過路徑選擇器抓取資料,會到「相關維護紀錄」讀取 該檔案相關訊息,如檔案連結的路徑,連結網站的歷史狀態記 錄… … 等。

b. 當路徑選擇器所需要的檔案資料,透過「檔案基本資料」讀取。

c. 路徑選擇器程序所做的資料流動狀況於儲存「檔案存取紀錄」

中。

d. 將所抓取之檔案訊息記錄於「檔案更新紀錄」。

3. 更新程序:當系統運作更新引擎時,會透過路徑選擇器決定路徑,

並將抓取之檔案置放於快取之中。其中會存取「檔案更新紀錄」。

4. 寄送檔案程序:檔案欲回傳給使用者,會更新「檔案更新紀錄」

及「檔案存取紀錄」。

5. 檔案批次更新程序:當欲定期判斷檔案新穎度以變更其更新率,

需與「檔案更新紀錄」及「相關維護紀錄」有關。

(57)

圖 4.4 第二層 DFD Resource Selector

4.4 系統實作

系統實作時,分別對本系統與一般傳統傳輸伺服器作模擬測試,

而從中,透過資料蒐集機制,可額外擷取出之資訊與分析,其相關說 明如下。

Access_logs

Remote site

2.1

Select(path)

2.2

Get File

Data_Info Cache_logs

2.3

Send File

Data_Profile

File name

Path, File

(58)

4.4.1 實作畫面與說明

系統在實作方面,以模擬方法,利用程式語言 Java,透過 JDBC 連結 ODBC 的方式,存取 MySQL 資料庫。使用 JDK 1.3 版 compiler。

利用程式模擬資料流動的狀況,以 Hinet 所提供之 Log 檔,總共約有 十三萬筆資料,將 Log 模擬使用者實際發出要求的方式,進行系統之 運作。

系統運作方式如下:

如圖 4.5 畫面所示,系統會先讀取 Log 檔,當系統讀入 Log 檔之 後會對 Log 檔裡面的使用者要求,分別做字串的欄位切割判斷,根據 使用者要求檔案之不同,進行系統運作程序。例如:根據使用者要求 之檔案,先進入判斷檔案存在快取與否的程序,檔案存在則進行檔案 新穎度判斷,若不需更新,則將檔案傳給使用者,若需更新,則同檔 案未於存快取之步驟,進行檔案抓取之路徑選擇器程序。經由路徑選 擇器之程序,將檔案抓取存放於快取之中,並回傳給使用者。

(59)

圖 4.5 系統模擬運作畫面

而在模擬實驗中,另一對照組為一般傳統檔案傳輸伺服器的模擬 運作,透過相同的資料來源作為使用者行為之模擬,以作為與本研究 相互比較對照。其中,一般傳統檔案傳輸伺服器是不具備有快取功 能,純粹為提供檔案鏡射服務之功能。畫面如圖 4.6。

參考文獻

相關文件

(B)使用 Windows XP 內建的 Windows Media Player 來播放影片檔案時,請問下列

在數位系統中,若有一個以上通道的數位信號需要輸往單一的接收端,數位系統通常會使用到一種可提供選擇資料的裝置,透過選擇線上的編碼可以決定輸入端

有關 PHP 的敘述何者有誤?①可在 Apache、MS IIS 等 Web 伺服 器執行的 Script②只能在 Linux 或 Unix 作業系統上執行,無法於 Windows 或 Mac

最後特別提出說明,本研究用戶端作業系統為 Win 2000 Professional,伺服 器端作業系統為 Windows 2000 Server 並啟動 Active Directory

上傳後的資料。倘若 於上傳初選檔案截止 日(2/24)前,仍有必 要更換評選檔案,請

日本電信電話公社宣布,於 9 月 30 日起正式終止呼叫器(BB Call)的服務。日本 呼叫器服務從 1968 年起由電信電話公社開始提供,與當年台灣的

例如 : http ( 網頁伺服器所用的協定 ) 定義了 client 如何向 server request 網頁及 server 如何 將網頁及其中的各種內容回傳給 client 。. 提供服務給 application layer

 培養具有檔案學基礎知識與文化知識,掌握現代資訊技術的基 本技能,能在檔案館、國家機關和企事業單位的檔案機構、資