中 華 大 學 碩 士 論 文
題目：動態網頁快取系統之設計與實作
Design and Implementation of Caching Dynamic Web Pages
系 所 別：資訊工程學系碩士班 學號姓名：M09002042 蔣坤霖 指導教授：張 燕 光 博 士 王 素 華 博 士
中華民國 九十二 年 七 月
摘要
在World Wide Web 熱潮之推波助瀾下，動態網頁技術於近幾年內快速的發 展與成熟，使得動態網頁具備有多方面之優勢，而能逐漸取代傳統之靜態網頁，
成為現今網路服務之主流方式，不過正因動態網頁之盛行，許多棘手的問題也隨 之衍生，如客戶端之等待時間大幅增加、伺服器之處理能力被迫下降、網路之傳 輸更加壅塞等，而在過去，當這些問題出現於靜態網頁上之時，尚能以網頁快取 之方式解決，但由於現今之網頁快取機制仍未能有效的快取動態網頁，使得這些 問題日趨惡化，嚴重影響今日網路服務之品質。
本研究即以快取動態網頁為主要目標，先後研發出 Application-Level 與 Server-Level 二套架構於網頁伺服器端之動態網頁快取系統，此二套系統不僅能 有效的儲存動態網頁成為靜態的快取文件，網頁伺服器因此能夠像是取用靜態網 頁一般，快速的提供客戶端動態資訊，同時快取文件管理機制也能妥善管理快取 文件，持續維持快取文件之內容一致性，更能以半自動化之方式，分離動態網頁 中之動、靜態內容，使本研究能藉以解決動態網頁所衍生之問題，成就最終之研 究目的 – 增進網路服務品質，而這也在本研究所進行之各項實驗中，得到具體 數據之證實。
關鍵字： 動態網頁、快取、一致性
Abstract
Propelled by the increasing demands of World Wide Web, the technology of dynamic web pages was rapidly developed and matured in recent years. Therefore, the dynamic web pages can replace the traditional static web pages and become the major way of providing internet service. Nevertheless, just because of the popularity of dynamic web pages, many thorny problems need to be solved, e.g., the user-perceived delays, the loads of web server and the network bandwidth usage. In the past, caching techniques are used to solve these problems. But the technology of caching web pages does not work well for the dynamic web pages today. Therefore, these problems have deteriorated sharply recently and seriously damage the quality of internet service.
The goal of this thesis is to cache the dynamic web pages. We have developed an application-level and a server-level caching systems for dynamic web pages as well as a cache management mechanism. These systems cache dynamic web pages in the form of static files and thus can provide the dynamic information to the clients. In addition, the cache management mechanism can efficiently manage those cached objects and keep them consistent. Our systems can also semi-automatically separate dynamic and static contents in dynamic web pages. Based on our design and implementation, we conduct experiments and show that the user-perceived delays,
web server loads, and the network bandwidth usage are indeed reduced. Therefore, we can achieve the final goal of this research – Improving the quality of internet service.
Keywords： dynamic web pages, caching, consistency
目錄
摘要...i
Abstract...ii
目錄...iv
圖目錄...viii
表目錄... x
第一章 緒論... 1
1.1 研究動機 ... 1
1.2 研究目的 ... 3
1.3 論文架構 ... 5
第二章 文獻探討 ... 7
2.1 HTTP 快取控制表頭（HTTP Cache-Control Headers） ... 7
2.2 網頁內容一致性之維持機制 ... 10
2.2.1 弱的一致性（Weak Consistency） ...10
2.2.1.1 存活時間（TTL） ...11
2.2.1.2 適性化存活時間（Adaptive TTL）...11
2.2.2 強的一致性（Strong Consistency） ...12
2.2.2.1 每次皆檢查之一致性驗證（Polling-every-time） ...12
2.2.2.2 使其無效之一致性驗證（Invalidation） ...12
2.3 現行網頁快取系統之分類 ...13
2.3.1 瀏覽器快取（Browser Cache） ...13
2.3.2 快取代理伺服器（Proxy Cache） ...13
2.3.2.1 正向快取代理伺服器（Forward Proxy） ...14
2.3.2.2 反向快取代理伺服器（Reverse Proxy） ...14
2.3.2.3 通透快取代理伺服器（Transparent Proxy） ...16
2.3.3 網頁伺服器端快取（Server-Side Cache）...16
2.4 動態網頁快取機制之研究 ... 17
2.4.1 以網頁伺服器為基礎之動態網頁快取（Server-based Cache）....17
2.4.2 以代理伺服器為基礎之動態網頁快取（Proxy-based Cache）...18
2.4.3 以程式語言為基礎之動態網頁快取（Language-based Cache） ..19
2.4.4 以應用程式為基礎之動態網頁快取（Application-based Cache）20
2.5 動態網頁於快取上之問題定義 ... 21
2.5.1 動態網頁之產生過程...21
2.5.2 問題定義...22
2.5.2.1 客戶端傳遞參數值之方式...22
2.5.2.2 動態網頁應用程式之執行延遲...23
2.5.2.3 動態網頁欠缺 HTTP Cache-Control Header...24
2.5.2.4 動態網頁之網路傳輸重複浪費...25
第三章 系統設計與實作 ... 27
3.1 系統設計概念 ... 27
3.2 Application-Level 動態網頁快取系統之設計與實作 ... 30
3.2.1 系統整體架構與運作流程...30
3.2.2 系統元件設計...34
3.2.2.1 Type B URL...34
3.2.2.2 Web Switch ...36
3.2.2.3 Web Application Designed for Caching（WADC）...38
3.2.2.4 Cache Manager ...43
3.2.3 系統實作...53
3.3 Server-Level 動態網頁快取系統之設計...62
3.3.1 系統整體架構與運作流程...62
3.3.2 系統元件設計...66
3.3.2.1 <CACHE> ...66
3.3.2.2 Request Handler...74
3.3.2.3 Response Handler ...76
3.3.2.4 Response Output Filter ...80
第四章 系統效能評估 ... 83
4.1 測試平台 ... 84
4.2 客戶端等待時間、伺服器處理能力 ... 85
4.2.1 實驗目的...85
4.2.2 實驗設計...85
4.2.3 實驗結果與分析...87
4.3 網路傳輸量 ... 89
4.3.1 實驗目的...89
4.3.2 實驗設計...89
4.3.3 實驗結果與分析...90
4.4 網頁內容一致性 ... 92
4.4.1 實驗目的...92
4.4.2 實驗設計...92
4.4.3 實驗結果與分析...94
4.5 與其它動態網頁快取系統之比較 ... 101
4.5.1 實驗目的...101
4.5.2 實驗設計...101
4.5.3 實驗結果與分析...102
第五章 結論與未來展望 ...105
5.1 結論 ...105
5.2 未來展望 ...106
參考文獻...108
圖目錄
圖2.1、靜態網頁之 HTTP Header 傳遞過程示意圖 ...8
圖2.2、各 Proxy Cache 之比對示意圖...15
圖2.3、動態網頁產生過程示意圖...22
圖2.4、Type A URL 語法 ...23
圖2.5、Squid-Cache Server 之預設設定 ...23
圖2.6.、動態網頁之 HTTP Header 傳遞過程示意圖 ...26
圖3.1、系統設計概念圖...29
圖3.2、Application-Level 動態網頁系統之整體架構與流程示意圖 ...31
圖3.3、Type A、B URL 之語法對照圖 ...34
圖3.4、客戶端以 Type B URL 提出請求之 JavaScript 範例 ...35
圖3.5、Apache 內執行 PHP 動態網頁應用程式之設定...37
圖3.6、網頁伺服器內之原先 Web Switch 作業概念示意圖 ...37
圖3.7、Web Switch 與 URL Pre-processing 之處理流程圖...39
圖3.8、WADC 之處理流程圖...44
圖3.9、使用 Cache Manager 之叢集式動態網頁快取系統之設計示意圖 ...45
圖3.10、Method for Irregularly Changed Objects without Notification 之 Pseudo Code ...52
圖3.11、URL Rewrite Rule...54
圖3.12、urlparsr.pl 程式碼 ...54
圖3.13、access.log ...56
圖3.14、rewrite.log ...56
圖3.15、WADC 之設計範本...57
圖3.16、Cache Manager 與其它系統元件之實作關係圖 ...60
圖3.17、Server-Level 動態網頁系統之整體架構與流程示意圖...63
圖3.18、動態網頁中之動、靜態內容示意圖...67
圖3.19、動、靜態內容合成之概念圖...68
圖3.20、<CACHE>應用範例一之網頁伺服器處理流程示意圖 ...71
圖3.21、<CACHE>應用範例一之 HTTP Header 傳遞過程示意圖 ...72
圖3.22、<CACHE>應用範例二之網頁伺服器處理流程示意圖 ...73
圖3.23、<CACHE>應用範例二之 HTTP Header 傳遞過程示意圖 ...74
圖3.24、Request Handler 判別流程圖...76
圖3.25、Response Handler 處理流程 ...79
圖3.26、Response Output Filter 處理流程 ...82
圖4.1、CPU-Bound PHP Web Application 之 Pseudo Code...85
圖4.2、Exp. CPU-Bound 伺服器處理能力之比較圖 ...88
圖4.3、Exp. CPU-Bound 客戶端等待時間之比較圖 ...88
圖4.4、二大網站之動態網頁內動、靜態內容示意圖...91
圖4.5、網路傳輸量之比較圖...91
圖4.6、MT1 實驗之整體配置流程圖...96
圖4.7、MT2 實驗之整體配置流程圖...96
圖4.8、客戶端等待時間之比較圖...97
圖4.9、伺服器 CPU 使用率之比較圖...97
圖4.10、MT3 之搜尋快取文件內容變動時間軌跡圖...99
圖4.11、各系統使用者等待時間之比較圖...103
圖4.12、各系統快取文件搜尋與傳輸時間之比較圖...104
圖4.13、各系統程序使用時間之比較圖...104
表目錄
表4.1、實驗所用之軟硬體設備列表...84 表4.2、MT1 之 Fresh Hit Ratio 列表...100 表4.3、MT2 之 Fresh Hit Ratio 列表...100
第一章 緒論
動態網頁已成現今網路服務之主流方式，不過其所衍生之問題卻已逐漸掩蓋 其應有之效益，在此次研究之中，即希望能藉由快取動態網頁之方式，以解決動 態網頁之相關問題，以下，將詳細說明此次研究之動機與最終之研究目的。
1.1 研究動機
WWW（World Wide Web）優越與即時之資訊分享能力，使其一躍而成現今
網路服務之主流，且近幾年，其於全球網路傳輸量之佔有率，更是一舉攀升至 60%以上 [34,35,37]，不過，如此驚人的成長速度，卻是造成長久以來，網路壅 塞、回應遲緩等等問題的主因之一，雖今日網路之基礎建設已有長足進步，個人 與企業所能擁有之網路頻寬已較往日有著大幅增加，但這僅能暫時舒緩問題之急 迫性，並未能真正有效解決問題。
而由過往經驗之累積，可以了解到「網頁快取（Web Caching）」，乃是此一 問題之最佳解決方案 [48]，因網頁快取是將客戶端所曾瀏覽過的網頁，存留一 副本於網頁快取系統之中，此一副本稱為快取文件（Cache Object），當客戶端欲 再次瀏覽該網頁時，網頁快取系統便可立即取出快取文件給予客戶端，無須客戶 端再次遠至伺服器端取得該網頁，故可有效縮短客戶端等待之時間，也同時減輕 了伺服器之工作量，另外，客戶端與伺服器端之間的網路傳輸量因此而減少，故
也紓解了該段網路之壅塞情況，因此，網頁快取對伴隨 WWW 熱潮而來之種種 問題解決而言，確實有著莫大的助益，不過，當網頁快取遇上動態網頁時，所有 快取之優點則已不再復見，這全因現今之網頁快取系統僅能快取靜態網頁。
動態網頁是由位在伺服器後端之動態網頁應用程式，依客戶端或其他之輸入 值執行後而動態產生（on the fly），相較於事先備妥固定檔案內容之靜態網頁，
動態網頁擁有可達成互動性、可滿足個人化、可執行分散式運算等多樣之優勢，
這也是現今動態網頁之所以備受歡迎與廣為使用的主要原因，但這並非無須付出 任何代價即能達成，由於動態網頁應用程式在執行時，須佔用伺服器之運算資 源，因而加重了伺服器之負擔，迫使伺服器對客戶端請求（Request）之處理能 力下降，客戶端之等待時間也因此而被迫延長，此外，由於動態網頁乃是動態產 生，其內容與大小並非固定不會變動，故現今之網頁快取系統皆不快取之，以免 引發更多棘手之問題，如在快取動態網頁後，該如何確保快取文件之內容一致性
（Consistency）等等，於是這又造成了客戶端與伺服器端之間的網路傳輸量大幅
增加，是故，原先由網頁快取所解決之種種問題，又再度回到尋求解決之道的起 點。
因此，在此次研究當中，便針對現今網頁快取系統無法快取動態網頁之難 題，期盼能提出一完善的解決方案，使網頁快取能重新拾回其應有之功效，協助 解決現今因動態網頁所引起之眾多問題。
1.2 研究目的
現今網路世界有著如此蓬勃之發展，動態網頁乃是其後不可或缺的推手之 一，舉凡資料搜尋、網頁郵件、網路報稅等等，皆為常見之動態網頁應用實例，
而動態網頁更是現今電子商務之基礎，故動態網頁之重要性已不在話下，但伴隨 動態網頁而來的種種棘手問題，如遲緩等等窘況，使得動態網頁之應有效益大打 折扣，已成今日不得不正視之問題。
此次研究之主要研究目標，即在於藉由網頁快取之概念，達成有效、正確的 快取與管理動態網頁，來解決動態網頁之回應遲緩問題，而若能達成此一研究目 標，將可成就本研究之最終研究目的 – 增進網路服務品質，並實現以下三項主 要研究目的：
縮短客戶端之等待時間
”eight-second rule”是廣為網站建構者所遵從的一項設計規範，其內容是指 若讓客戶端下載網頁時所等候之時間超過八秒鐘，則客戶端將會放棄下載網頁 而逕行離去，並不再回到該網站來，因而導致網站之營收明顯減少。是故，若 能快取動態網頁，將可省去因執行動態網頁程式所需花費的時間，使客戶端之 等待時間明顯縮短。
提升伺服器之處理能力
動態網頁之生成，須耗用伺服器之運算資源，如 CPU、記憶體與磁碟等
等，而當執行越多或越複雜之網頁應用程式時，資源耗用之程度則越是嚴重，
使得伺服器無法有充裕的資源來全力應對客戶端之請求，造成伺服器之整體處 理能力下降，因此，若能快取動態網頁，將可減去動態網頁應用程式重複執行 相同運算之次數，因而降低伺服器之資源耗用程度，使得在相同的情況下，伺 服器處理客戶端請求之能力可較先前大幅提升。
減輕網路之壅塞情況
當眾多動態網頁於網路上傳輸時，便會造成網路壅塞之情況，而若能快取 動態網頁，必可使整體網路之傳輸量減少，不過事實上，網路之傳輸量尚有更 進一步減少之空間，那便是應用動態網頁之動、靜態內容分離的概念 [22]，
在一般情況下，單一動態網頁之組成可區分為動態內容與靜態內容，動態內容 指的是動態網頁中會發生變動之內容，如股票網頁中股價資訊，而靜態內容便 是指其餘不會變動之內容，因此，若能僅更替動態內容，而重複使用靜態內容，
網路之傳輸量將能更加減少，網路之壅塞情況必能更加減輕。
若要能達成快取動態網頁之目標，則必須先從問題之起源，即由網頁伺服器 產生與輸出動態網頁之過程，開始著手改善，因此，本研究將首先改良網頁伺服 器之輸入、處理與輸出流程，讓動態網頁可在初產生之際，即能快取於伺服器端 內，而伺服器端也能猶如取用靜態網頁般，可直接取用快取文件，並同時訂定一 套管理與維護之機制，用以妥善管理動態網頁之快取文件，以及適時維護快取文 件之內容一致性，此外也分離動態網頁中之動、靜態內容，使靜態內容可存留於
客戶端上重複使用，並能適時更新動態內容，令二者可共同組合而成一完整網 頁，以供客戶端瀏覽，而前述之種種改良與設計，最終將可協助實現此次研究之 研究目的。
1.3 論文架構
首先於第二章中，先行探討與本研究相關之現行靜態網頁快取技術，如 HTTTP Cache-Control Header 與網頁內容一致性之維持機制，以對這些靜態網頁 快取技術有一基礎之了解，再來則針對各主要動、靜態網頁網頁快取系統與快取 技術作深入淺出之研究與分析，以作為本研究學習與參考之依據，最後則再回頭 仔細檢視動態網頁之整體產生過程，從中尋找所有問題之起因，並同時探求問題 之解決方案。
在第三章中，則正式詳述本研究所研發之動態網頁快取系統，首先闡述系統 之主要設計概念，以能定調於往後系統之基本設計方向，接下來，則介紹本研究 於研究期間內，由此主要系統設計概念所先後研發出之二套動態網頁快取系統 – Application-Level 動態網頁快取系統以及 Server-Level 動態網頁快取系統，完整 說明此二套快取系統之整體架構與運作流程，以及其內個別系統元件之功用與設 計，並且也於此章中，以部分實際程式碼為範例，詳細說明Application-Level 動 態網頁快取系統之實作方式。
第四章則為系統效能評估，當中將進行一連串不同目的與情境之實驗，以測
知Application-Level 動態網頁快取系統之實際效率表現，另外，也針對此次研究 所提出之快取文件內容一致性維護機制進行實驗，以了解該維護機制之可行性，
最後，則再與其它相同性質之動態網頁快取系統一同比較，以了解此系統相較於 其它快取系統，在程序效率上之表現程度。
最終之第五章為結論與未來展望，其中說明了此次研究之成果，並對未來研 究之發展，提出部分可行之方向與建議。
第二章 文獻探討
網頁快取系統之基本設計方向，在於儲存使用者所曾瀏覽過的網頁，以加快 使用者再次瀏覽該網頁時之取得速度，而為了實現這樣的設計方向，許多相關的 運作機制便順應而生，在此一章節中，將陸續探討一些與本研究相關之網頁快取 技術與機制。
2.1 HTTP 快取控制表頭（HTTP Cache-Control Headers）
HTTP 通訊協定（Hypertext Transfer Protocol）為網頁文件於網路上傳輸時之 共通規範，定義客戶端與伺服器端相互溝通時所使用之語言與行為，如客戶端該 如何向伺服器端索取網頁，伺服器端又該如何回覆客戶端之請求等等，不過對於 網頁快取之規範，在HTTP 1.0 中仍尚未齊備，使得早期的網頁快取機制並不完 整，故在後續之HTTP 1.1 中，便新增了許多對網頁快取之行為與規範，健全了 網頁快取時之處理機制 [6,46]。
客戶端與伺服器端相互溝通的方法，是利用彼此交換HTTP Header（表頭）
的方式來達成，而這些HTTP Header 也正是 HTTP 通訊協定實作之方式，每當客 戶端向伺服器端索取網頁時，以及伺服器端開始傳輸網頁至客戶端之前，都會先 利用HTTP Header 相互溝通，其中也包含了在 HTTP 傳輸協定所規範的網頁快取 機制實作的HTTP Cache-Control Header（快取控制表頭），圖 2.1 為客戶端向伺 服器端索取網頁時，雙方溝通所使用之HTTP Header 訊息內容實例，客戶端在一
圖2.1、靜態網頁之 HTTP Header 傳遞過程示意圖
開始利用 Request Headers 向 clotho.mi.chu.edu.tw 伺服器端說明，現欲索取 /index.html 網頁，索取的方式是利用在 HTTP 1.1 中所規範之 GET Request Method
（請求模式），而當伺服器端處理完客戶端的請求，在傳輸 /index.html 網頁至客 戶端之前，會先傳輸Response Headers，告知客戶端對於其請求之處理狀態碼為 200 OK，表示所有的處理過程已全部成功完成，而伺服器端收到客戶端請求的
時間為 Date 網頁表頭中顯示之時間，網頁伺服器軟體為 Apache，其中有著 mod_perl 與 PHP 二個網頁伺服器擴充模組，回傳文件為 index.html，該文件可儲
存於快取之中，此外，自Date 顯示時間起算，在 Cache-Control 所顯示之秒數內，
該文件之內容”應該”是不會改變的，”應該”是 Fresh（新鮮的）而非 Stale（逾期
Client Server
Request Headers :
GET /index.html HTTP/1.1 Host: clotho.mi.chu.edu.tw Accept: */*
Accept-Language: en User-Agent: Lynx/2.8.5dev.7 Connection: close
Response Headers : HTTP/1.1 200 OK
Date: Mon, 19 May 2003 18:32:35 GMT
Server: Apache/2.0.45 (Unix) mod_perl/1.99_09 PHP/4.3.1 Content-Location: index.html
Cache-Control: max-age=172800
Expires: Wed, 21 May 2003 18:32:35 GMT Last-Modified: Fri, 04 May 2001 00:01:18 GMT ETag: "64121-945-c21ff9c0"
Accept-Ranges: bytes Content-Length: 1456 Connection: close
Content-Type: text/html; charset=ISO-8859-1
的），故在Expires 所顯示日期之前，皆可使用儲存於快取之內的該文件，無須再 向伺服器端索取該網頁文件，Last-Modified 顯示該文件的內容最後一次被更動之 時間，另外在ETag 所顯示的字串，為可供用來辨別該文件內容是否有更動的另 一項有利工具，至於該文件之內容大小，正為Content-Length 內所顯示之大小。
在上述的HTTP Header 之中，Date、Cache-Control、Expires、Last-Modified、
ETag 與 Content-Length 等等 HTTP Header，皆為決定該份網頁文件能否快取之相 關Header，而其中 Cache-Control 與 Expires，更是直接控制快取文件可直接使用 無須再次重回伺服器端驗證之關鍵，至於Last-Modified 與 ETag 則可作為當快取 文件逾期時，客戶端重回伺服器端比對快取文件與原始文件之內容有無相異的有 利工具。故現若快取文件已儲存超過Cache-Control 與 Expires 所標示之期限後，
客戶端若要再次使用該文件，必須先至伺服器端驗證該文件之內容有無更動，此 時在客戶端所送出的 Request Header 內，便會附有 If-Modified-Since（IMS）的 HTTP Header，若快取文件含有 ETag，則 ETag 也將在此時一併送出，伺服器端 會在收到Request Header 時，首先取用這二個 Header 與原始文件比對，若相符，
則會在Response Header 中使用 304 Not Modified 的狀態碼，表示客戶端內之快 取文件與伺服器端內之原始文件內容相同，客戶端可使用該快取文件，但若是比 對結果不相符，則伺服器會送出 200 OK 的狀態碼與其它 HTTP Header 於 Response Header 中，並隨後傳送新的原始文件予客戶端，此時客戶端內之快取 文件便立刻失效，客戶端必須使用該份新的原始文件，並用之替換快取文件。
至此可知，若要網頁文件可被快取並能被正確的使用，相關的Cache-Control Header 之有無與準確，確實是相當重要。
2.2 網頁內容一致性之維持機制
內容一致性（Consistency）向來是在所有的網頁快取研究中，相當重要的一 項研究議題，尤其是在網頁已快取一段時日之後，一定會面臨到快取文件與原始 網頁之內容產生互異的情況發生，因此，該如何判斷快取文件之內容何時為Fresh 而可重複使用之，又何時該快取文件為 Stale 進而刪除之或是再向伺服器端索取 最新之內容，以能有效減少客戶端與伺服器端間不必要之通訊次數，即為維持網 頁內容一致性機制之研發重點，而現有之一致性機制之研究可分為二個主要方 向：
2.2.1 弱的一致性（Weak Consistency）
其為現今多數快取系統所用，此機制不能完全保證快取文件與原始文件內容 之一致，但是可以有效的降低快取文件之內容為 Stale 之機率，其同時也是在理 論上耗用客戶端與伺服器端雙方資源之程度上，如網路使用量、運算使用量等 等，最為節省的一致性確保機制，而目前Weak Consistency 常見之實作方式下列 有二種。
2.2.1.1 存活時間（TTL）
先前曾提及Cache-Control Header 內所設定之秒數，是為快取文件之內容在 這段時間內”應該”是不會改變的，故可視為 Fresh 而使用之，這段時間便稱為快
取文件之TTL（Time-To-Live），過了這段時間快取文件之內容便視為 Stale 而須 更新之，這也是現今最為常用、設定最為簡易之方式，而特別提及”應該”這二字 之原因，在於這樣的方式對伺服器內之原始網頁並未有任何強制性的制約，來約 束原始網頁之內容不可有任何改變，故在這段時間之內，任何一方都無法真正確 保快取文件與原始網頁能有著相同內容，故 TTL 時間長度之決定，對快取文件 內容為Stale 之比率有著極大的影響。
2.2.1.2 適性化存活時間（Adaptive TTL）
為了改善TTL 之缺點，Adaptive TTL 便順應而生，其方式仍然根基於使用 不具任何約束性的 TTL 時間長度，不過卻多了周期性的檢查機制，所有的快取 文件皆被設定一檢查時間門檻值，此時間門檻值為一由快取系統管理者所掌控的 百分比值，用來設定快取系統檢查快取文件與原始網頁間之一致性的週期間隔時 間，如一快取文件之TTL 為 3 天，該檢查時間門檻值為 10%，則網頁快取系統 應自該快取文件首次被快取之時間起算，每隔432 分鐘，就應向伺服器端確認原 始網頁之內容是否有所更動，以決定該快取文件是否可再繼續使用或是需作更 新，故Adaptive TTL 有效的解決了 TTL 的缺點，同時又不至於增加過多對客戶
端與伺服器端之負擔。
2.2.2 強的一致性（Strong Consistency）
相反於Weak Consistency，Strong Consistency 即可完全保證快取文件與原始 文件內容之一致，使客戶端永遠使用與原始網頁完全相同內容之快取文件，不過 這樣的機制在理論上，多是必須以犧牲大量的資源作為代價的，目前 Strong Consistency 常見之實作方式有二種：
2.2.2.1 每次皆檢查之一致性驗證（Polling-every-time）
每當客戶端要使用快取文件時，必須先至伺服器端確認原始網頁之內容與快 取文件是否相同，若相同，則客戶端可使用該快取文件，若相異，則取回原始網 頁使用之，並用之替代該快取文件，如此一來，將可確保客戶端所使用的快取文 件永遠為最新之內容，故此機制相當簡單並有效，但必須大幅增加與伺服器端通 訊之次數，使網路使用量增加，同時也增加了網頁伺服器的負擔。
2.2.2.2 使其無效之一致性驗證（Invalidation）
前三種實作方式皆是由客戶端主動負擔起查驗的機制（Client-polling），但 在 Invalidation 中，則是由伺服器端擔負起維持一致性之工作，伺服器需紀錄下 各個客戶端曾索取過什麼網頁，並隨時監控該網頁之內容有無更動，一旦某一網 頁有了更動，便必須立即通知所有曾索取過該網頁之客戶端，告知該網頁之內容
已有更動，須更新其快取系統內之快取文件的內容，以免快取文件與原始網頁之 內容有所差異，此方式完全確保了內容一致性，不過卻較polling-every-time 更加 的耗損資源。
2.3 現行網頁快取系統之分類
網頁快取系統經過長期之研究與發展，在本質上並未有太多的改變，但因在 發展背景與使用目的上有所不同，使得各個快取系統之間有了不同的定位，現若 以快取系統所使用的網路區域上來分別，則可將現有的快取系統分為三大類：
2.3.1 瀏覽器快取（Browser Cache）
現今客戶端上之使用者，大多使用Browser（瀏覽器）來瀏覽網頁，而多數 現代的Browser 本身即含有一小型的網頁快取系統，此 Browser Cache 最主要的 作用在於提供使用者”回上一頁（go Back）”的功能，使得使用者能快速的回到 先前所曾瀏覽過的網頁，而無須再向伺服器端索取相同網頁，大幅縮短了客戶端 之等待時間，另一功能則為可快取較為機密或是牽涉個人隱私的網頁，畢竟這樣 的網頁並不適於公開為所有的客戶端使用，不過正由於如此的設計定位，使得 Browser Cache 通常只有最基本的快取功能。
2.3.2 快取代理伺服器（Proxy Cache）
Proxy Cache 也通稱為 Proxy Server（代理伺服器），其設計定位於可供多數
客戶端使用，當有一客戶端透過Proxy Server 來索取網頁，則該網頁不僅會儲存 在客戶端之Browser Cache 中，也同時也會儲存於 Proxy Server 之中，如此一來，
其餘之客戶端便無須至伺服器端索取同一網頁，可直接使用Proxy Server 內之快 取文件，縮短了多數用戶端等待網頁傳輸之時間，同時在Proxy Server 之間，也 可彼此相互分享快取文件，故其快取功能較Browser Cache 要來的多，而現若再 以Proxy Server 的主要使用目的來區分，則 Proxy Server 尚可作以下區分：
2.3.2.1 正向快取代理伺服器（Forward Proxy）
最為常見之Proxy Server 使用型態便是 Forward Proxy，其主要服務之對象為 多數使用者所在之客戶端，Forward Proxy 通常位於中小型區域網路之最外圍，
較伺服器端鄰近於客戶端，代理區域內之客戶端要求，向不同的伺服器端索取網 頁，而所儲存之快取文件也可為所有的客戶端共同使用，Forward Proxy 如圖 2.2(a)。
2.3.2.2 反向快取代理伺服器（Reverse Proxy）
其多被建置在 Server Farm（伺服器叢集）之前端，外界視其為進入 Server Farm 之單一入口，除了基本網頁快取功能外，也負責將客戶端之請求，視其所
請求之文件的不同，重導客戶端之請求至適當的伺服器來處理，而由於 Reverse Proxy 具有此種分配客戶端請求之能力，故也可作為 Server Farm 之 Load Balancer
（負載平衡器），平均分攤各個伺服器的工作量，使得整體Server Farm 可不因單
一伺服器過多之工作量造成處理不及，因而拖累其餘的伺服器，導致整體Server Farm 之效能下降，Reverse Proxy 如圖 2.2(b)。
圖2.2、各 Proxy Cache 之比對示意圖
Clients
Forward Proxy
Servers
Relative Distances
(a). Forward Proxy
Server Farm
Reverse Proxy Clients
Relative Distances
(b). Reverse Proxy
Clients
Transparent Proxy
Servers
Relative Distances
(c). Transparent Proxy
2.3.2.3 通透快取代理伺服器（Transparent Proxy）
該功能與作用與Forward Proxy 皆相同，唯一的相異點在於 Transparent Proxy 並沒有Forward Proxy 先天上之缺陷，一般而言，當客戶端上之使用者若欲使用 Forward Proxy 時，必須先更動其 Browser 之設定，使 Browser 能將網頁請求首先 送至Forward Proxy，否則即無法享有 Forward Proxy 所能帶來的各種便利性，不 過 Transparent Proxy 則無須使用者作任何設定，使用者無法得知也不必得知 Transparent Proxy 之存在，便可以享有其所帶來的益處，而這通常是由該區域網
路管理員來設定的，管理員會將該區域網路內所有的網頁請求重導至Transparent Proxy，使得所有客戶端之請求皆會透過 Transparent Proxy，其內之快取文件也可 供所有的客戶端共同分享使用，Transparent Proxy 如圖 2.2(c)。
2.3.3 網頁伺服器端快取（Server-Side Cache）
為一建置在網頁伺服器後端的快取系統，並與網頁伺服器保持著密切合作的 關係，其內儲存較常為客戶端所請求的網頁文件，但客戶端並無法直接接觸到 Server-Side Cache，所有來自於用戶端之請求仍是由網頁伺服器負責處理，網頁 伺服器會先至Server-Side Cache 內尋找客戶端所要求的網頁文件，並回傳給使用 者端，此種做法的優點在於可大幅減少網頁伺服器尋找並處理網頁文件之時間，
也就是等於減少了客戶端等待之時間，並由於與網頁伺服器的合作關係，使得在 處理客戶端請求的各方面，如快取控制、內容監控與特殊請求等，皆可輕易達成，
而這是前述種種快取系統所不能實現的。
2.4 動態網頁快取機制之研究
上述所提及的網頁快取技術，其多屬傳統靜態網頁快取之研究範疇，但近幾 年，動態網頁技術之快速成熟與廣泛應用，使得動態網頁之快取也成為熱門的研 究重點之一，而現有之動態網頁快取研究可依其快取機制之主要執行所在位置與 所使用之技術與方法，約略分為 Server-based、Proxy-based、Language-based 與 Application-based 動態網頁快取機制，解說如下：
2.4.1 以網頁伺服器為基礎之動態網頁快取（Server-based Cache）
Server-based 快取機制之研究主要目的，在於避免伺服器端計算資源的重複 性浪費，藉以減少客戶端等待伺服器端計算之時間花費，其做法大多以儲存動態 網頁成靜態網頁，並放置於伺服器後端的快取系統中為主，如在 [5] 中，提供 了一套應用程式界面（API），可供動態網頁應用程式設計師使用於動態網頁應 用程式中，藉由使用這套API，程式設計師將可以令動態網頁之內容存放於快取 系統中，並能直接新增、刪除與取用在伺服器後端的快取系統內之快取文件，而 在 [29] 中，則發展了 DUP（Data Update Propagation），也同樣的提供了一套相 似功能的API，並更多了 ODG（Object Dependence Graph）來輔助快取文件間彼 此資料內容之相依性的管理，另外在 [23] 中，則依據 URL、cookie 與 URL 參 數值等等，來管理動態網頁與快取文件，其快取系統 – Cachuma，更提供了可對
快取文件作Invalidation 與 Precomputing 等一系列管理機制。
總合分析，Server-based 快取機制多建置在伺服器端，並與網頁伺服器保持 密切的合作，其快取機制會將每次伺服器之運算結果，也就是動態網頁，保存在 本身的快取系統之中，待下次客戶端要求相同之動態網頁時，便可直接從快取系 統中取出使用，不需伺服器再次作相同的運算，得出相同的結果，而使得網頁伺 服器能有更多的時間與資源做其它新的運算，以滿足其他客戶端之需求，也因為 省去重複運算之時間，使得客戶端能較快速的獲得網頁，縮短了整體客戶端等待 之時間。
2.4.2 以代理伺服器為基礎之動態網頁快取（Proxy-based Cache）
Proxy-based 之主要運作機制在於可使用 Proxy Cache 內已有之快取文件，並
在 Proxy 內直接組合而成一完整網頁供用戶端使用，相較於 Server-based，
Proxy-based 快取機制則多了一項預期效益 — 減少整體網路使用量，如在 Active Cache [45] 中，Proxy Sever 內被植入了一個 Java Applet，此 Java Applet 負責攔 截客戶端傳至Proxy Server 之請求，並視請求之內容，以決定屆時在應傳回客戶 端之完整網頁中，哪些內容可取自Proxy Cache 中之快取文件，又哪些內容應令 網頁伺服器端重新產生以使用，待所有的內容皆已備妥後，便組合所有部分成一 完整網頁，並送回客戶端以供使用者使用。
整體分析 Proxy-based 快取機制，由於使用 Proxy Cache 既有之資源，相同
內容之網頁部分可直接使用儲存於Proxy Cache 內之快取文件，使得伺服器端無 須再次傳輸，故減少了總體網路使用量，同時網頁伺服器也因此可以處理更多的 請求，也同時縮短了客戶端等待之時間。
2.4.3 以程式語言為基礎之動態網頁快取（Language-based Cache）
Language-based 快取機制與前兩者迥然不同，其使用自定之快取語言或標
籤，使動態網頁中之動、靜態內容分離，因而增進客戶端與伺服器端二者間
（end-to-end）之動態網頁處理與遞送之效能，如在 [17] 中，一套不同於動態網 頁程式語言（Programming Language）之語言標籤（Language Tag）稱為 HPP（Html Pre-Processing），用來協助動態網頁應用程式設計師，設計出可達成網頁中動態
內容與靜態內容之個別處理，靜態部分之網頁將會成為一可儲存在 Browser Cache 內之網頁範本（Template），並傳回至客戶端，屆時客戶端再依照 Template 內 HPP 之指示，向伺服器端索取網頁中動態之內容，最後這些動、靜態之內容 由事先放置在客戶端瀏覽器內之Java Applet 或是外掛程式（plug-ins），組合而成 完整之網頁畫面呈現在使用者面前，而在 [12] 中，則更進一步發展成一套稱為
<bigwig>之完整動態網頁程式語言，程式設計師須依其語法設計出動態網頁應用 程式，並經<bigwig>所附之專屬編譯器（compiler）編譯過後，即可達成網頁中 之動、靜態內容分離，並能在客戶端上利用Java Script 組合而成一完整網頁畫面。
檢視Language-based 快取機制，由於使用了動、靜態內容分離並在客戶端組
合而成一完整網頁的方式，的確可讓整體網路之傳輸量有著部份的減少，也可使 網頁伺服器之運算資源耗用的程度減輕，但位居二者之間的Proxy Cache 卻未在 其主要設計考量範圍之內，使得居中的Proxy Cache 不能發揮應有之功效，因此，
在這樣僅適合於客戶端與伺服器端的快取機制之下，對於伺服器之整體負擔，並 未真能有效的減輕。
2.4.4 以應用程式為基礎之動態網頁快取（Application-based Cache）
Application-based 快取機制則直接使用動態網頁程式語言來設計動態網頁快 取系統，其做法主要是由負責產生動態網頁之動態網頁應用程式，在產生動態網 頁之同時，也順道快取本身所產生的動態網頁成靜態快取文件，待下次客戶端再 有相同請求時，動態網頁應用程式即可直接取用先前所快取之靜態快取文件，故 其可省去再次執行完整動態網頁應用程式所須耗費之伺服器運算資源與時間，如 在 [55] 中，即為直接使用 PHP 動態網頁程式語言來設計動態網頁快取系統，稱 為phpCache，此系統將原先負責產生動態網頁之 PHP 動態網頁應用程式包覆入 本身的快取程式中，因此當客戶端之請求將由網頁伺服器準備轉交動態網頁應用 程式執行時，則將會首先經過phpCache，此時 phpCache 會視有無先前已快取之 靜態快取文件，進而決定直接取用快取文件以快速回覆客戶端，或是執行動態網 頁應用程式以產生動態網頁，並快取之。
整體分析Application-based 快取機制，其功用與先前 Server-based 快取機制
相當近似，同樣可省去因執行動態網頁應用程式所需之運算資源與時間之耗費，
故可有效減少客戶端之等待時間，但由於Application-based 快取機制在運作時，
對於每個客戶端請求皆須執行由動態網頁應用程式所組成之動態網頁快取系統 來判讀，故對伺服器運算資源耗用程度而言，仍是無法有效降低。
2.5 動態網頁於快取上之問題定義
動態網頁與傳統靜態網頁在產生的過程中有許多相異之處，使得傳統快取機 制無法快取動態網頁，雖然在如前述的眾多研究中，皆提出了對動態網頁快取的 解決方案，但這些解決方案與其說是”動態網頁之快取機制”，不如說是”動態網 頁之產生加速機制”要來的實際、貼切，因為其並未真正符合快取的本質，也未 完全考慮到與現今已廣泛使用之傳統靜態網頁快取機制的相容性，是故，以下將 重新檢視動態網頁之產生過程，並尋找、定義出動態網頁無法快取之根本因素，
作為本研究之研究基礎與主要解決目標。
2.5.1 動態網頁之產生過程
動態網頁乃是由動態網頁應用程式所產生，就如同一般的程式，需要給定參 數值後，程式才能根據所收到的參數值來產生最終之結果，於是一開始客戶端將 參數值附加於請求當中，待網頁伺服器收到請求後便轉交予動態網頁應用程式，
動態網頁應用程式便依據請求中所附加之參數值，來計算並產生動態網頁，此動 態網頁並不形成一實際檔案存在於伺服器內，而是直接由網頁伺服器收取動態網
頁之全部內容並傳送給客戶端（on the fly），至此，所有工作至此已全部完成，
全部過程如圖2.3 所示。
圖2.3、動態網頁產生過程示意圖
2.5.2 問題定義
以上是一般的動態網頁過程，在此過程中，屏除網路頻寬之影響，可發現有 多處不利於快取與處理延遲之所在，整理陳述如下。
2.5.2.1 客戶端傳遞參數值之方式
客戶端送出參數值至網頁應用程式之方式，在先前曾提及是將參數值附加於 請求當中，在實作上，則是附加在URL（Uniform Resource Locators）之後，如 圖2.4 內之 URL 語法所示，在本研究中稱此種樣式之 URL 為 Type A URL，其表 示客戶端向host 伺服器下的 abs_path 相對路徑內之 webapp 動態網頁程式送出名 為k1 值為 v1 的參數值，以及名為 k2 值為 v2 的參數值，參數之間以” & ”符號
Web Server
Web App if ( Key ==...) {………..}
else if ( … ) {…..}
HTML Page
<HTML>
………..
………..
</HTML>
Request Response http://site/webapp?Key=xxx
Output Client
相連，全部參數則是以” ? ”附加於動態網頁程式名稱之後，於是動態網頁程式便 可依據這些參數值作運算處理，最後產生動態網頁回傳予客戶端。
圖2.4、Type A URL 語法
Type A URL 參數值傳遞方式現今應用於絕大多數的動態網頁產生過程中，
而此語法正是造成動態網頁無法快取的因素之一，今日之網頁快取系統一旦遇上 動態網頁，便放棄快取其內容而直接傳回給客戶端，而快取系統判別是否為動態 網頁的方式之一，便是判別客戶端所送出的URL 中是否含有” ? ”字元，如在最 為常見的Squid 快取伺服器中 [61]，便有如圖 2.5 的預設設定，因此，為了相容 於現今多數的網頁快取系統，Type A URL 語法是本研究首先須改進的目標。
圖2.5、Squid-Cache Server 之預設設定
2.5.2.2 動態網頁應用程式之執行延遲
動態網頁應用程式也正如同一般的程式，在執行時皆須佔用伺服器的處理資 http://host/abs_path/webapp?k1=v1&k2=v2 （Type A URL）
# TAG: no_cache
# A list of ACL elements which, if matched, cause the request to
# not be satisfied from the cache and the reply to not be cached.
# In other words, use this to force certain objects to never be cached.
#
#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
源，尤其是在一個擁有眾多客戶端的網頁伺服器，其須同時處理每個來自於客戶 端之請求，此時單一伺服器的資源便極有可能不敷所需，而出現動態網頁程式執 行延遲的情況，導致客戶端之等待時間加長，而現今多數的企業組織在面對此一 情況時，通常都以再購置更多的硬體設備來解決，不過這樣的解決方案通常所費 不貲，在過去尚可利用快取機制，無須造成更多的花費，即能解決此種伺服器面 對大量處理請求時之窘況發生，但面對動態網頁，傳統的快取機制便無法發揮應 有之作用。
不過倘若仔細觀察動態網頁應用程式之處理過程，可以發現動態網頁應用程 式之執行結果，即動態網頁，並非每次皆會不同，如同一般的程式，給定相同的 參數值，其各次之執行結果必然也會相同，因此，快取動態網頁之構想是絕對可 行的，只要確定參數值相同，便無須再次耗用伺服器處理資源來執行動態網頁程 式以產生相同之動態網頁，只要取出在快取之中的前次執行結果即可，但是，也 如同傳統靜態網頁一般，快取內之動態網頁快取文件也會面臨內容一致性的問 題，而此問題可能較靜態網頁來的更加嚴重、困難，是故，動態網頁之快取、管 理與一致性之問題，將為本研究之重點所在。
2.5.2.3 動態網頁欠缺 HTTP Cache-Control Header
先前曾提及，網頁能否快取，其關鍵因素之一，便是該網頁是否含有相關的 HTTP Cache-Control Header，如 Cache-Control 以及 Expires 等 Header，不然至少
需要 Last-Modified 與 Content-Length 此二個 Header，快取系統才得以快取該網 頁，並做到基本的快取管理，前二種 Header 尚需經過額外設定方能包含於網頁 之前，但後二種 Header 無須經特別設定，網頁伺服器就可自動產生，因凡存在 於伺服器檔案系統中的各種檔案，如靜態網頁，必含有該檔案最後被修改之時間 以及檔案之大小，網頁伺服器可取出這二個資訊並轉化為 Header 包含於網頁之 中，故一般的靜態網頁皆是可快取的。
但動態網頁則全然缺少這些HTTP Cache-Control Header，如圖 2.6，其為客 戶端向伺服器要求 /index.php 動態網頁之雙方 Header 交換訊息紀錄，可以發現 的是當中並無任何HTTP Cache-Control Header，原因可能是如前述所提過，動態 網頁乃是動態產生，其並不形成實際檔案存在於伺服器內，網頁伺服器因而缺乏 相關資訊可主動添加相關 Header 於動態網頁中，故使得網頁快取系統無法快取 該動態網頁，因此，本研究將設法添加HTTP Cache-Control Header 於動態網頁 之前，使網頁快取系統得以有足夠之資訊而能快取動態網頁，並得以利用這些資 訊來管理該動態網頁。
2.5.2.4 動態網頁之網路傳輸重複浪費
長久以來，許多研究的目標都在鑽研如何在有限的網路頻寬內擠出更多的效 能，而現今的快取系統其功用即在避免相同的網頁文件於網路上再次傳輸，以減 輕整體網路的使用量，不過現今有個明顯的事實擺在眾人面前，即許多使用者並
圖2.6.、動態網頁之 HTTP Header 傳遞過程示意圖
未設定使用Proxy Cache，頂多就只有使用 Browser Cache 而已，對減輕網路的整 體使用量並未有太多助益，更何況面對的是無法快取的動態網頁，這將會使得早 已壅塞的網路更加的不堪負荷。
因此，不僅僅是要快取動態網頁，同時必須再更進一步的減少網路使用量，
以能造福於只有使用Browser Cache 的客戶端，其解決方法若以成本與務實的角 度來思考，答案便顯的容易許多，就是避免傳輸的重複與浪費，在一份動態網頁 之中，必定有某些內容並不會隨著不同的參數值而有所變動，這些固定不變的內 容便是可再次使用之部分，是故，如何有效利用動態網頁中不變之部分，而僅只 更替那些會變動的部分，使網路整體傳輸量更加的減少，也將為本研究之重點研 究項目。
Client Server
Request Headers :
GET /index.php HTTP/1.1 Host: clotho.mi.chu.edu.tw Accept: */*
Accept-Language: en User-Agent: Lynx/2.8.5dev.7 Connection: close
Response Headers : HTTP/1.1 200 OK
Date: Mon, 02 Jun 2003 07:16:22 GMT
Server: Apache/2.0.45 (Unix) mod_perl/1.99_09 PHP/4.3.1 Accept-Ranges: bytes
X-Powered-By: PHP/4.3.1 Connection: close
Content-Type: text/html; charset=ISO-8859-1
第三章 系統設計與實作
綜合第二章之分析，可知若要成功構築一動態網頁快取系統，不僅系統本身 須能有效快取動態網頁，並維持準確的維持快取文件之內容一致性，同時也須能 善用現行之靜態網頁快取機制、網路上既有之網頁快取系統與客戶端已有之技 術，形成在網路上之一整體快取系統，方可發揮系統之最大功效，達成研究之最 終目的，而在本章節中，將先行闡釋本研究之設計概念，而後開始正式介紹本研 究於研究之過程中，先後研發出之二套動態網頁快取系統，一為主要由動態網頁 應用程式負責快取作業之Application-Level 動態網頁快取系統，二為主要由網頁 伺服器負責快取作業之Server-Level 動態網頁快取系統，說明這二套快取系統之 整體架構與運作流程，並逐一詳述各系統之元件與機制之功用與運作方式，此外 須另加說明的是，此二套系統皆需位於網頁伺服器背景端之Cache Manager 的協 助，以能管理已暫存之快取文件，並能維持這些快取文件之內容一致性。
3.1 系統設計概念
由上一章可以得知，Proxy Cache 與 Browser Cache 在快取網頁與管理快取文 件時，相當的倚重HTTP Cache-Control Header，而這必須由網頁伺服器端在傳遞 網頁時即附加上去，至於客戶端等待時間之增長與網頁伺服器處理能力之下降，
乃是肇因於網頁伺服器產生動態網頁時，需要冗長之動態網頁應用程式運算時間 與龐大之伺服器運算資源所致，此外，由於動態網頁是在網頁伺服器端所產生，
故若要取得動態網頁之內容以快取之，在網頁伺服器端必然不會是件難事，同時 當動態網頁之內容有所變動時，也必然能在網頁伺服器端首先察覺，因此，若要 能有效的快取動態網頁，並避免內容一致性之問題發生，以解決動態網頁所衍生 之相關問題，網頁伺服器端將會是最合適的解決方式之研發起點。
不過，由於網頁伺服器之設計主旨並非在於快取網頁，故對於在快取網頁時 所需具備之處理流程與伺服器元件全然缺乏，而部分網頁伺服器雖有快取網頁之 能力，如Apache 網頁伺服器，其雖有著 mod_proxy 與 mod_cache 二個快取模組，
但其可快取之網頁種類，也僅限於靜態網頁而非動態網頁，同時，本研究認為，
對網頁伺服器而言，最自然且效率應為最佳之處理方式，即為直接取用靜態網 頁，過多或過於複雜的伺服器處理與快取之流程與元件，在未能真正達成最佳設 計規劃之下，將只會更進一步拖慢網頁伺服器之處理速度而已，因此，本研究將 以網頁伺服器取用靜態網頁之處理流程，作為研發動態網頁快取系統時之設計藍 本，並在更動原有網頁伺服器處理流程需為最小之前提下，增添快取動態網頁時 所需之伺服器元件，使網頁伺服器不僅能快取動態網頁，且能如同取用靜態網頁 一般，直接取用在快取動態網頁後所成之快取文件，以回覆客戶端之請求。
而在經由上述種種設計之考量下，本研究之動態網頁快取系統之初始設計概 念與運作流程即如圖3.1 所示，其中的 Cache Directory 為存放所有快取文件之所 在，而本研究僅在網頁伺服器處理客戶端請求之流程前加上一個判別樞紐，作為
圖3.1、系統設計概念圖
判別在 Cache Directory 中，有無存在客戶端所要求的動態網頁之快取版本，若 有，則開始進行伺服器處理靜態網頁之程序，自Cache Directory 取出快取文件，
以此回覆予客戶端，而若樞紐之判別結果為無，則開始進行伺服器處理動態網頁 之程序，首先執行動態網頁應用程式，以產生動態網頁之內容，並在該內容之前 端加上所需之HTTP Cache-Control Header，以此先回覆予客戶端，隨後將該內容 存成快取文件，放置於Cache Directory 中，使得若再有相同的客戶端請求，網頁 伺服器即可自動進行靜態網頁之處理程序，以能快速的回覆客戶端。
是故，此種設計不僅簡單，同時也極有效率，將能大幅的縮短客戶端之等待 時間，並將可降低伺服器之資源耗用程度，而能較先前未使用此系統設計時，大
Web Server If have cached
dynamic web
page Web App
Cache Directory HTML Page
Request
Response No
Yes Output
Save
With HTTP Cache-Control Header
幅提升網頁伺服器之處理能力，而為了實現此設計概念，本研究先後進行了二種 不同實作層次之動態網頁快取系統設計 -- Application-Level 與 Server-Level，而 此二套快取系統將在本章之後續章節分別詳細介紹。
3.2 Application-Level 動態網頁快取系統之設計與實作
若要網頁伺服器之處理流程徹底的單純化，以達成最佳之處理效率，則不應 使網頁伺服器擔負過多的工作，因此，動態網頁之快取工作即須由動態網頁應用 程式來負責，故此種動態網頁快取系統之設計層次即為Application-Level，而此 快取系統即稱為Application-Level 動態網頁快取系統。
3.2.1 系統整體架構與運作流程
圖3.2 即為 Application-Level 動態網頁快取系統之整體架構，此架構乃是依 先前所述之系統設計概念而成，並同時結合Server-based 與 Application-based 動 態網頁快取機制之優點於其中。
本研究於此系統中，創新研發了多個系統元件，首先即為圖3.3 中之 Type B URL，此種 URL 乃是仿製一般用來請求靜態網頁之 URL 而成，並如同 Type A URL 可攜帶客戶端之參數值，其目的是為使 Proxy Cache 與 Browser Cache，視 此種URL 所請求之網頁將為可快取的網頁，因而能突破客戶端網頁快取系統之 查驗網頁可否快取的第一檢查機制，讓此快取系統所對外輸出之動態網頁內容，
圖3.2、Application-Level 動態網頁系統之整體架構與流程示意圖
可初步取得這些網頁快取系統之快取認可。
再來則是位於伺服器處理客戶端請求之流程前的判別樞紐，在此系統中稱為 Web Switch，由於 Web Switch 之設計必須特別簡化，以免加重網頁伺服器之負 擔，導致伺服器之處理能力降低，因此，在藉由伺服器之原有機制之協助下，本 研究僅在Web Switch 中作二點判別，一為所請求之網頁是否存在，二為請求中 之URL 是否為 Type B，之後便根據最後之判別結果，來決定是否須將此 Type B URL 轉譯為 Type A URL，以驅使網頁伺服器開始進行靜態網頁之處理流程，自 Cache Directory 中，直接取出快取文件，或是驅使網頁伺服器自伺服器之其它儲 存位置中，直接取出 靜態網頁之內容，再 由伺服器自行加上相 關之 HTTP
Static Web Server
Cache Directory
Web Apps
（WADC）
Web Switch
Dynamic Client
Save Type B
Cache Manager
Type A
Save as cmr file
Compare Update
Notify
Response Response
Header，最後傳送回客戶端使用，或是驅使網頁伺服器開始進行動態網頁之處理 流程。
一旦網頁伺服器開始動態網頁之處理流程，則必然會執行動態網頁應用程 式，以產生動態網頁，由於Application-Level 動態網頁快取系統之主要動態網頁 快取工作，乃是由動態網頁應用程式所負責，因此，動態網頁應用程式即須具備 快取之功能，故本研究稱之為WADC（Web Application Designed for Caching），
WADC 須自行快取其程式執行所產生之結果，而此結果在交由網頁伺服器傳送
回客戶端使用之前，須再自行加上適當之HTTP Cache-Control Header，使此結果 不僅可突破客戶端網頁快取系統之查驗網頁可否快取的第二檢查機制 – 有無 HTTP Cache-Control Header，而可快取於客戶端之網頁快取系統內，也可指示客
戶端之網頁快取系統，須在 Header 內所標明之快取文件逾期時間，向網頁伺服 器端索取最新之內容，以避免內容一致性之問題發生，此外，WADC 也須將這 些結果存成快取文件，放置於Cache Directory 中，以供下次再有相同之客戶端請 求時，網頁伺服器可進行靜態網頁之處理流程，直接取用這些快取文件，以快速 的回覆客戶端之請求，而在最後，WADC 尚須進行另一項工作 – 知會 Cache Manager，以利 Cache Manager 爾後對快取文件之管理工作。
最後的系統元件即為Cache Manager，其位於網頁伺服器之後端，接收來自 於 WADC 之知會，以了解該如何維護快取文件，但其並不實際參與任何前述之
處理流程，是為一獨立運行於伺服器系統之常駐程式，其負責管理所有存放於 Cache Directory 中之快取文件，Cache Manager 紀錄這些快取文件之各種屬性 值，並負責維護快取文件之內容一致性，其能在快取文件逾期之當時，旋即向網 頁伺服器發出Type A URL 之請求，以驅策網頁應用程式產生最新的快取文件之 內容，並比對新、舊快取文件內容之異同，以決定是否更新快取文件之內容，而 另一項Cache Manager 之工作項目，則為在 Cache Directory 之磁碟儲存空間即將 滿溢時，進行快取空間置換之工作。
綜合上述之各系統元件與流程，可以得知在Application-Level 動態網頁快取 系統中，共有三個處理流程，分別為靜態網頁之處理流程、動態網頁之處理流程、
Cache Manager 之處理流程，這些流程彼此獨立運行，而不相互衝突、干擾，故 能使此快取系統之效率大幅提升，並能在充分運用網頁伺服器之既有運行架構，
但卻又不會增加過多負擔網頁伺服器之情況下，達成了本研究快取動態網頁之設 計目標，因而可完全達成縮短使用者之等待時間，以及提升網頁伺服器之處理能 力二大研究目的，不過由於Application-Level 動態網頁快取系統之設計初衷是為 追求最大之系統效率，故因在不增加網頁伺服器負擔之設計考量下，使得網頁伺 服器無法擁有更多之功能，因此，對於使用動態網頁中之動、靜態內容分離之概 念，以減少網路壅塞情形之研究目的，則需程式設計師在設計動態網頁應用程式 時，自行分離出動、靜態內容之程式碼，成為二個分別處理、輸出動、靜態內容 之動態網頁應用程式，方能達成。
3.2.2 系統元件設計
3.2.2.1 Type B URL
由 2.5.2.1 章節之研討中，可以得知現今快取系統判別是否為動態網頁之最 常見做法，便是辨識出客戶端所送出之URL 中，是否含有” ? ”字元，若含有，
則直接放棄快取，若未含有，則再視有無相關之HTTP Cache-Control Header 來 決定是否快取，故本研究即首先針對現今最為常見之客戶端使用URL 傳遞參數 值方式（Type A URL），提出改進之道。
若要解決因URL 中之” ? ”字元所引發的快取問題，最為顯而易見的解決方 案，便是將” ? ”字元自 URL 中除去並以其他特殊字元取代，本研究則以” ! ”特殊 字元取代” ? ”，而參數與參數值之相連仍使用” = ”，同時所有參數值間之串聯也 仍使用” & ”，最後則以”.html”副檔名作為結尾，而為了縮短 Response Handler 處理與在Cache Directory 內搜尋快取文件之時間，同時扁平化網頁之架構階層，
以便於管理，本研究將相對路徑中（abs_path）常用之” / ”路徑區隔字元，改以”,”
字元替換，此URL 語法在本研究中稱其為 Type B URL，如圖 3.3 所示。
圖3.3、Type A、B URL 之語法對照圖
Type B URL 僅較 Type A URL 作了極小部分的改變，但卻可在多數現有之快 http://host/abs_path/page?k1=v1&k2=v2 ( Type A URL )
http://host/abs_path,page!k1=v1&k2=v2.html ( Type B URL )
取系統網頁的快取與否之判別機制上獲得初步認同，而無須對快取系統進行任何 變更，完全遵從本研究之設計準則，此外，若需再轉譯回Type A URL，僅須替 換部分特殊字元即可，故Type B URL 也可說是具有高度之相容性。
不過如何使客戶端送出Type B URL 則又是另一項難題，此點尚須網頁應用 程式設計師之配合，首先是在網頁中既有之Type A URL 網址方面，本研究稱之 為固定式網頁超鏈結（Fixed Hyper Link），程式設計師須自行轉換或使用另外撰 寫之自動轉換程式以將其轉換成Type B URL，而另一種則是用<Form>方式，由 客戶端所動態產生之 Type A URL 請求，本研究稱之為非固定式網頁超鏈結
（Non-Fixed Hyper Link），為了符合本研究之設計準則 – 使用客戶端已有之技 術，本研究採用了現今客戶端所用之多數瀏覽器皆可執行之語言 – JavaScript，
提供一段如圖3.4 之 JavaScript 供程式設計師放入動態網頁中使用，此 Script 可 取出網頁表單中之參數值，並組合成一完整 Type B URL，最後則再以 GET Request Method 向伺服器端送出。
圖3.4、客戶端以 Type B URL 提出請求之 JavaScript 範例
<Script Language=JavaScript> function Location() { var UrlStr;
UrlStr = "http://host/abs_path,page! k1=" + document.LocationBody.k1.value +
"&k2=" + document.LocationBody.k2.value + ".html";
window.location.href = UrlStr; } </Script>
<Form Name=LocationBody>
Key 1: <Input Type=Text Name=k1><BR>
Key 2: <Input Type=Text Name=k2><BR>
<Input Type=Button Value=Submit onClick="Location();"> </Form>
3.2.2.2 Web Switch
在網頁伺服器之內部，有著許多既定之處理流程，其中最為主要的，即為靜 態網頁處理流程與動態網頁處理流程，而這些處理流程之選定，則是由網頁伺服 器內之一特定樞紐元件來負責，本研究稱此樞紐元件為Web Switch，至於不稱為 URL Switch 之原因，乃在於此樞紐元件經本研究之改良後，已具有判別檔案是 否存之能力，而非單純僅對URL 進行判別。
原先Web Switch 之作業內容，與在客戶端請求中之 URL 息息相關，因其在 判定應使用何種處理流程以處理客戶端請求之時，會先剖析在該URL 中，所請 求網頁之副檔名為何，若該副檔名為事先已定義之動態網頁副檔名，則開始進行 動態網頁之處理程序，執行動態網頁應用程式以產生動態網頁，並直接將動態網 頁之內容傳送回客戶端，不然，則開始進行靜態網頁之處理程序，至伺服器之檔 案系統中，取出所請求的網頁或檔案之內容，再搭配上相關的HTTP Header，最 後一併傳回客戶端。現以一實例說明，在 Apache 網頁伺服器中，有著如圖 3.5 之設定，該設定是指示Apache 網頁伺服器，若遇上以.php 為副檔名之網頁請求，
則應執行以該檔名為名之PHP 動態網頁應用程式，如現若客戶端請求 index.php 網頁時，則Apache 會執行 index.php 動態網頁應用程式，以產生 index.php 動態 網頁，而若是客戶端請求 index.html 網頁時，則 Apache 會取出 index.html 靜態 網頁之內容，傳送回客戶端，因此，網頁伺服器內之原先Web Switch 的作業概 念即可如圖3.6 之示意圖所示。
圖3.5、Apache 內執行 PHP 動態網頁應用程式之設定
圖3.6、網頁伺服器內之原先 Web Switch 作業概念示意圖
在Application-Level 動態網頁快取系統之設計構想中，快取文件應能如同靜 態網頁一般，透過網頁伺服器之靜態網頁處理流程，直接取出、傳送該快取文件 之內容，以供客戶端使用，如此快取系統方能提供真正的高效率服務，而 Web Switch 正好掌控了靜態網頁處理流程之選用，現 Type B URL 之語法與一般請求 靜態網頁所用之 URL 語法幾近相同，Web Switch 將會視其為對靜態網頁之請 求，而選用靜態網頁之處理流程，直接取出快取文件之內容，傳送回客戶端，但 若當快取文件尚未存在，則需執行動態網頁應用程式以產生，不過，這並非Web Switch 既有之功能，尚待本研究賦予之。
#
# AddType allows you to add to or override the MIME configuration
# file mime.types for specific file types.
#
AddType application/x-httpd-php .php
Request
If the request is for dynamic page
Executing the normal process for
dynamic page
Executing the normal process for static
page
Web Switch
Yes No
因此，本研究即在原先Web Switch 進行剖析、判斷 URL 之作業前，先行一 步處理 URL，在此稱為 URL Pre-processing，其所進行之工作為先判斷該 URL 所請求之檔案有無存在，因該URL 可能為請求動態網頁，或是請求快取文件，
也可能為只為一般靜態網頁之請求，因此若所請求之檔案存在，則直接交由Web Switch 作後續之處理，但若為對快取文件之請求，則該請求所使用之 URL 必為 Type B，同時現又存在於伺服器之檔案系統中，即為存在於 Cache Directory 之 中，因此，Web Switch 將會進行靜態網頁之處理程序，快速的取出快取文件之內 容，傳送回客戶端；而若是所請求之檔案並不存在，則可能代表該URL 所請求 之動態網頁尚未存在，故需剖析（parse）URL，確定其是否使用 Type B URL 之
語法，以得知該URL 是否真為對快取文件之請求，而若該 URL 真為使用 Type B URL，則須再進行轉譯 Type B URL 為 Type A 之作業，使 Web Switch 能判斷出 該URL 所請求之動態網頁程式之名稱與所攜帶之參數值，以能進行動態網頁之 處理程序，執行該動態網頁程式，產生動態網頁，並將網頁之內容存成快取文件，
以供下次再有相同之請求時，可直接進行靜態網頁處理程序，省去執行動態網頁 程式之所需時間與運算資源，讓客戶端可快速的得到所欲瀏覽之動態網頁內容。
Web Switch 與 URL Pre-processing 之處理流程如圖 3.7 所示。
3.2.2.3 Web Application Designed for Caching（WADC）
動態網頁之本質，乃是由網頁伺服器執行動態網頁應用程式後，所臨時產生 的暫時性結果資料，一旦動態網頁程式執行完畢，動態網頁也交由網頁伺服器傳
圖3.7、Web Switch 與 URL Pre-processing 之處理流程圖
回客戶端後，動態網頁即立刻被網頁伺服器丟棄，而先前傳回客戶端之動態網 頁，也因未具有HTTP Cache-Control Header，使得客戶端之網頁快取系統無法快 取之，故若當客戶端欲再次瀏覽該動態網頁時，網頁伺服器端必須再次重複上述 之動態網頁產生過程，因而造成先前提及的動態網頁所衍生之種種問題，因此，
在 Application-Level 動態網頁快取系統中，為了真正使快取系統之服務效率提 高，同時不讓網頁伺服器之負擔加重，本研究即令動態網頁應用程式自行快取其 程式所產生之動態網頁，而雖然此種動態網頁程式與一般動態網頁程式並無過多 之差異，但主要因其擁有快取之能力，故本研究稱其為WADC（Web Application
Request
If the request is for dynamic page
If URL is Type B
Executing the normal process for
dynamic page
Executing the normal process for static
page
Convert Type B URL into Type A
No No
Yes
Yes
URL Pre-processing Web Switch
Yes No If the requested
page exists
