第二章 文獻探討
2.4 動態網頁快取機制之研究
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