以即時流量控制之代理伺服器提供彈性的網路服務

以即時流量控制之代理伺服器提供彈性的網路服務

游象甫, 曾黎明

國立中央大學資訊工程研究所, 國立中央大學電子計算機中心

[email protected] [email protected]

摘要

根據教育部電算中心的統計 HTTP 佔 TANet 流量第一位, 且持續成長. 為使網路頻 寬使用更有效率, TANet 全面推行使用網路代 理伺服器, 藉由網頁資源的共用, 降低頻寬需 求. 網路代理伺服器的確有效增加頻寬的利 用率, 若代理伺服器能對不同的需求提供不 同的服務, 則應能進一步提昇網路服務品質. 同時國內多所大學發生使用者以下載程式大 量且連續下載電子期刊以致影響其他正常使 用者權益的事件, 亦突顯網路代理伺服器需 要即時有效的使用管理功能, 以維護正常使 用者的權益. 目前多數代理伺服器只提供簡 單的使用者及 Web 伺服器存取管制, 無法對 異常使用作出反應, 雖然 TANet 有些學校管 制網路代理伺服器使用量, 但只針對使用者 的總下載量, 並沒有對個別使用者或網站下 載量進行控管, 另外其監控的時間間隔長達 一日, 異常的使用行為需 24 小時後才能被 發現阻止, 缺乏時效. 在此論文中我們提出一 個網路代理伺服器使用量控制系統, 可根據 不同的需求, 提供彈性的管制機制, 同時可保 障網路資源的公平使用, 維護網路智慧財產 權. 關鍵字: 網路代理伺器, 流量管制, 網際網路, WWW, Web

1 簡介

由於 WWW 其支援多媒體及安裝使用 簡易的特性, 是 Internet 成長最快速也是最 重要的服務, 幾乎各行各業都有網站供查詢. 根 據 教 育 部 電 算 中 心 統 計 TANet 上 HTTP[12, 19] 封包佔所有流量的 85%[9]. 為 使網路頻寬使用更有效率, TANet 推行使用 WWW 網路代理伺服器, (本論文中除特別說 明, 否則網路代理伺服器或代理伺服器都是 指 WWW 網路代理伺服器), 藉由共用網頁 降低頻寬需求. 網路代理伺服器有多項好處. 首先, 可以降低回應時間讓使用者更快速的 瀏覽網頁; 其次, 被快取(cache)的物件可被多 人使用, 讓網路使用更加有效; 最後, 代理伺 服器可以分擔熱門網站的負載. 雖然上述優點已經由實際測試而被驗證 [18], 但我們認為代理伺服器還有針對不同的 需求提供彈性服務的潛力. 有非常多的研究[] 在討論如何對不同的使用者給不同的網路資 源, 其大部分是從網路層的觀點來提出可能 的方法. 若從應用層來考慮, 則代理伺服器不 失為一種可能的策略, 所以若代理伺服器能 控制使用量, 則提供網路上優先權服務就不 再是不可能的事了. 另一方面, 代理伺服器可藉由控制使用 量維護所有網路服務提供者及使用者的權益. 當使用者藉代理伺服器連上網站時, 網站可 以看到代理伺服器而無法知道真正連線的使 用者. 此特性使得網站被網頁下載軟體(如 WGET[2])大量存取時, 不易偵測, 因為網路 代理伺服器會產生非常多的存取, 以中央大 學的代理伺服器為例, 一天有上百萬次存取, 對某些網站可能就有數萬次, 所以網站很難 識別那些存取是正常或是惡意的. 這種網路 濫用行為會損及他人的權益, 對網站而言, 網 路頻寬被佔用, 伺服器負載增加, 智慧財產權 受侵犯; 對使用者而言, 網路頻寬與代理伺服 器被佔用, 等待時間加長, 更糟的是如果受攻 擊的網站對代理伺服器採取暫停使用的策略, 則所有正常的使用者都會受到影響.

1998 年 8 月時中央大學圖書館收到美 國物理學會的電子郵件通知校內有不明人士 於一 個 晚上 經 網路 代 理伺 服器 下 載約 900 MB 的論文, 希望能查明原因. 對此事件本校 迅速查出係一研究生因不想慢慢瀏覽於是利 用 Teleport[6] 下載美國物理學會期刊網站中 的論文, 其非惡意, 也不是企圖違反智慧財產 權. 但這並非單一偶發事件, 隨後在 1999 年 台灣其他國立大學也發生類似事件, 甚至造 成全校被電子期刊停權. TANet 上很多大專院校皆有網路流量管 制, 但通常屬公共服務的伺服器, 如電子郵件 伺服器或代理伺服器不在管制範圍內, 所以 使用者可以利用代理伺服器躲避流量管制, 縱然 TANet 有些學校[3, 4, 5] 管制網路代理 伺服器使用量, 通常只針對使用者的總下載 量, 並沒有對個別使用者或網站下載量進行 控管, 另外其監控的間隔長達一日, 異常的使 用行為需 24 小時後才能被發現阻止, 缺乏 時效. 為滿足上述需求及解決已發生的問題, 本論文提出一個可控制網路代理伺服器使用 量的系統, 讓代理伺服器能針對不同的需求 提供富彈性的服務, 同時保護所有網路使用 者的權益, 本系統具備下列功能:  可自動產生網路代理伺服器存取控 制設定, 包含網站及使用者;  可即時對異常使用採取反應並公告, 包含網站每單位時間被下載量管制 及使用者每單位時間使用量管制;  可將使用者或網站分成不同的群組 設定不同的管制策略. 本論文其他章節安排如後, 下一節討論 控制代理伺服器使用量的問題及可能的解決 方法; 第三節說明本系統的實作; 第四節介紹 相關研究; 最後是結論及未來改善方向.

2 問題研究及可行方法

本節會討論如何利用代理伺服器提供彈 性的服務以滿足不同的需求或維護使用者權 益. 另外, 我們也會說明如何設計具流量管制 功能的代理伺服器. 2.1 如何提供彈性的服務 提供彈性服務的策略有很多種, 例如在 WWW 伺服器上建置 prioritized 機制[10, 14, 15], 在此我們僅討論如何在 Internet 讓具控 制流量功能的代理伺服器能產生效用. 可以 從兩個方面來思考, 第一是代理伺服器的使 用是非通透; 第二是代理伺服器的使用是通 透. 第一種方式使用者必須在瀏覽器上設定 使用代理伺服器, 所以會遭遇使用者不知道 或不願意設定使用代理伺服器的問題, 讓代 理伺服器無法發揮控制流量的功能. 使用者 不知道需要設定或如何設定代理伺服器的問 題可以藉由宣導伺服器的好處或教授瀏覽器 設定來改善, 這點在 TANet 上已經証明可以 克服不再是問題. 但對於不願意使用代理伺 器的使用者則必須搭配其他誘因使其樂於使 用代理伺服器, 比如代理伺服器有專屬高速 頻寬, 如圖一, 過去 TANet 就是利用類似的 方 式 , 讓 各 區 網 中 心 的 代 理 伺 服 器 以 163.28.X.X 的 IP 使用保留頻寬出國, 以高 速吸引使用者使用代理伺服器, 現在的作法 則改以讓代理伺服器以 ADSL[32] 專線接民 營 ISP 出國, 如交大, 中正理工學院等.這種 利透策略也証明相當有效, TANet 上大部分使 用者均有使用代理伺服器. 不過因為非通透 方式是建立在使用者的配合上, 所以網站也 普通通道 使用者 代理伺服器 高速通道 LAN WAN 圖一 以具高速專屬通道的代理伺服器提供彈性網路

需要有自己的管制機制, 才能避免被大量下 載. 在使用通透代理伺服器[16, 17, 35] 的情 況下, 瀏覽器不必設定代理伺服器即會自動 使用代理伺服器. 建構通透代理伺服器的策 略可分為兩種:  封 包 轉 向 . 使 用 layer 4 switch 或 policy-based router 將瀏覽器的封包轉 向至代理伺服器. 通常代理伺服器會直 接與 switch 相連, 而 switch 會將所有 往 port 80 的封包導向代理伺服器. 當 switch 收到往 port 80 的 TCP SYN 封 包時會將封包轉向到代理伺服器, 而不 必更改 IP 或 TCP 的 header 資訊. 此 時 通 常 代 理 伺 服 器 會 被 設 定 為 promiscuous 模式接受任何連線請求而 不管其連線目的地為何, 同時也會將送 回封包的 source IP address 改為原來使 用者要去的網站位址. 最後當連線建立 完成, 代理伺服器收 到瀏 覽器送來 的 URL ( 不 含 網 站 位 址 ), 再利 用 原 來 從 TCP SYN 得到的目的網站位址組合成 一個含網站位址的 URL, 接著如正常 的代理伺服器一樣開始存取網頁. 使用 router 的 方 式 和 switch 相 似 , 除 了 router 只會將往 port 80 的封包轉向至 代 理 伺 服 器 , 其 餘 封 包 則 繞 路 至 Internet. 利用類似原理發展的通透代理 伺服器有[26, 35].  封包攔截. 將代理伺服器配置於 router 同段的網路上, 利用網路監控軟體攔截 HTTP 封包, 將其 轉向 至 代理 伺服 器, 藉此提供具通透性的服務. 當網路監控 軟體攔截到連線的第一個 TCP SYN 封 包時會將封包轉向到代理伺服器, 此時 將使用者及其目的網站的 IP 位址及 port 儲存下來, 並將被攔截封包的目的 位址改為代理伺服器的位址, 接著將修 改的封包送回網路, 於是接來所有來自 於同一個使用者同一個 port 的封包就 會被送至代理伺服器. 相反地, 若代理 伺服器要送封包給使用者時會將封包的 source IP 及 port 改為原來目的網站的 IP 及 port. 藉此代理伺服器可以在使 用 者 不 知 情 的 情 況 下 幫 使 用 者 完 成 HTTP 請求. 利用類似原理發展的通透 代理伺服器有[16, 23, 25]. 2.2 如何設計可控制流量的代理伺服器 2.2.1 建立新系統 vs 修改現存系統 可用兩種策略來發展符合需求的代理伺 服器: 建立新代理伺服器及修改現存代理伺 服器. 兩個方式各有優劣, 前者的優點有: 沒 有相容於舊系統的包袱、可以完全根據需求發 展、沒有智慧財產權問題和擁有完整發展文件 及技術, 日後修改比較容易. 但缺點為: 系統 開發難度高、需要很多費用及時間. 相反的, 修改現存系統的好處為: 利用現存技術比較 容易、節省費用及時間. 其壞處是: 必須牽就 修改的系統、可能破壞原設計架構、缺乏完整 系統發展文件、有智慧財產權的問題, 同時在 某些情況下有時不可能修改原系統. 2.2.2 修改程式碼 vs 外加功能模組 若採用 2.1修改現存系統的策略, 有兩 個方式可以進行: 修改程式碼或外加功能模 組. 修改程式碼是取得系統原始碼後直接修 改或新增, 依這種方式發展系統執行較快, 同 時對修改的功能沒有限制, 但沒有原始程式 碼時, 則無法進行修改; 另一方面, 程式設計 師必須必須閱讀大量原始程式碼, 且必須考 量版本的問題, 當原系統更換新版本時, 修改 的程式碼可能不適用必須修改. 最後, 因為是 修改原始碼, 智慧財產權問題可能難以避免. 外加功能模組是不變動程式碼但新增模 組以加強原有系統的功能. 利用此種方法不 需有原始程式即可加強原系統功能, 可用來 填補商業系統不足之處; 程式設計師不需閱

讀程式碼, 可以最適合的程式語言開發, 得以 加快發展時程, 降低成本; 若原系統出新版本, 外加功能模組較不需隨之更新; 最後, 因為沒 有引用原始碼, 所以可能不會遇到智慧財產 權問題. 不過由於不修改原始程式碼, 可增加 的功能受限, 有時可能無法滿足需求; 另外, 因為功能模組並沒有完全整合進原系統, 所 以效率較低. 2.2.3 有關外加功能模組的方式 若利用 2.2外加功能模組的方式使代理 伺服器具流量管理的功能, 則有三種方式可 將網路代理伺服器與流量管理模組連結起來:  URL 轉向: 將流量管理模組置於網路 代理伺服器之前, 即以輸入的 URL 作 為模組的輸入, 而模組再利用代理伺服 器取得網頁內容, 最後由流量管理模組 輸出給使用者, 在整個過程中流量管理 模組可以分析輸入的 URL 決定是否呼 叫代理伺服器取得網頁, 亦可分析得到 的網頁內容統計下載量, 進行流量管制, 如圖二. 若以 SQUID 為例, 流量管理 模組可從 port 3128 取得 HTTP 請求, 接著呼叫 SQUID 的 Client 程式[7] 使 SQUID 由網站取得網頁內容, 再導回 流量管模組分析, 決定是否輸出取得的 網頁. 另外 SQUID 也提供 URL 轉向 的存取介面, 也可以 外掛 程式對處 理 URL.  網頁轉向: 有些代理伺服器有提供網頁 轉向的功能[17], 可將取得的網頁轉向 至一個外掛程式處理後, 再輸出到瀏覽 器, 所以我們可以將代理伺服器的輸出 轉至管理模組再將結果轉回代理伺服器 傳給使用者, 如圖三.  分析 Log: 最後一種是分析代理伺服器 產生的 log 以此調整伺服器的運作進 行流量控制, 如圖四. 2.2.4 其他設計考量 本節討論其他發展網路代理伺服器流量 管制時應注意的需求. 2.4.1 即時管制 就像前面曾提到的, 雖然 TANet 上有 些學校進行網路代理伺服器使用量管制, 但 管制時間間隔達一日, 缺乏時效. 所以我們認 為管制最好能即時, 才能在第一時間內對異 常情況作出反應. 不過在設計上需考慮網路 代理伺服器一般而言非常忙碌, 隨時均有大 量網頁存取, 分析計算各種使用量會耗用相 當多的系統資源, 降低伺服器效能. 不同的實 作技術會有不一樣的方式以避免這種情形,, 若以 2.3 節分析 log 的方法為例, 考慮網路 伺服器的輸出量, 顯然持續不斷的分析 log 不是最佳的策略, 比較有效率的方式是依管 理者要求代理伺服器管制下載量的精確度來 計算出最合適的監控週期, 假設代理伺服器 的使用者平均每秒可下載 50 Kbyte, 若管理 者希望使用量誤差不超過 1 MB, 則每 10 秒 (1000/50/2, 多除 2 是為避免最壞的情形: 使 用者在前一次統計時非常接近管制量但沒超 過比如 0.99 Mbyte, 在第二次時又用了 0.99 回饋 代理伺 服器 流量管理模組 輸入的 URL 輸出 Log 圖四 以分析 log 方式新增流量管理功能 圖三 以網頁轉向方式新增流量管理功能 代理伺服器 流量管理模組 輸入的 URL 輸出 代理伺服器 流量管理模組 輸入的 URL 輸出 圖二 以 URL 轉向方式新增流量管理功能

Mbyte, 總共 1.98 Mbyte 才被管制) 統計下 載量一次就可達到即時管制的目的了. 2.4.2 自我調適 因為網路環境變化非常快, 常常在不同 的時間有不同情況, 例如, TANet 流量一般是 從晚上開始上昇, 至午夜到達高峰, 然後下降, 至早上 5 點左右最低. 在設計流量控制系統 時, 必須儘量使其可根據環境的改變自動調 整, 以減輕流量控制對系統造成的額外負載, 舉例來說, 管制機制可自動於晚上 8 點網路 擁擠, 傳輸速度較低時, 將監控的時間間隔調 大, 使代理伺服器效能較不受影響; 同時又自 動於早上 5 點傳輸速度較快時, 將監控的時 間間隔調小, 避免有漏網之魚. 2.4.3 友善使用者介面 雖然系統的目標是使代理伺服器可對使 用量進行控制, 然而對管理者或使用者而言, 一個具親和力的使用者介面仍然是必要的. Web 介面無疑是非常好的選擇, 對 Internet 的使用者而言, 瀏覽器易於安裝及使用, 而且 跨平台, 幾乎所有提供視窗環境的作業系統 都有支援, 因此一個好的流量管制系統基本 上應該提供以 HTTP 存取的使用者介面.

3 系統實作

我們已完成一個網路代理伺服器即時流 量控制系統, 稱為 ProxyBreaker, 本節將介紹 其架構與實作. 3.1 ProxyBreaker 的設計 根據前面的討論, 考量發展的成本, 因 此 ProxyBreaker 是採用修改已存在網路代理 伺服器的策略, 我們選擇修改 Internet 上常 見 的 代 理 伺 服 器 SQUID[7, 31, 34]. 因 為 SQUID 常常更新版本, 若修改原始碼必須花 時間產生不同的 patch file, 以維持與 SQUID 版本一致, 所以我們不考慮修改原始碼而以 外掛流量控制模組的方式, 讓 SQUID 能進 行使用量控管. 最後為使我們的控制模組容 易相容於其他網路代理伺服器, ProxyBreaker 以 2.3 節中分析 log 方式與網路代理伺服器 連結, 進行流量管制, 如圖五. 3.2 ProxyBreaker 的架構 ProxyBreaker 分 成 三 部 分 : Extractor, Controller 及 Viewer. Extractor 負 責 從 log 萃 取 必 須 的 資 料 , 同 時 將 資 料 存 入 中 間 檔 (middle file). 接著 Controller 分析中間檔後, 依據管理者的設定自動產生 SQUID 的設定 檔 (squid.conf), 藉以進行使用量管制. Viewer 則提供 Web 介面供使用者查詢有關的管制 資訊. 3.2.1 Extractor SQUID 的 log[7] 是一 個 循序 文 字檔, 每一次存取都會留下一筆記錄. 因為原始 log 包含非常多資料, 但不都是流量管制所需要, 為減少處理資料量, Extractor 將原始 log 轉 成中間檔供 Controller 分析. Extrator 每隔一 段時間就讀取 log, 只保留其中有關 HTTP 存取的部分, 取出 time, client address, bytes, peerstatus/peerhost 等四個欄位資料後, 將相 同的使用者及網站下載量加總後, 逐筆儲入 中間檔. 中間檔有兩種, 一種是以使用者對網 站的下載量, 另一種為網站對使用者的被下 載 量 ( 中 間 檔 的 格 式 如 圖 六 ). 為 加 速 Controller 處理的速度, 每次讀取 log 時就會 建立新的中間檔, 換句話說, Extractor 會產生 多個中間檔, 每個中間檔只代表某一段時間 回饋 網路代理伺服 器 輸入 URL Log 圖五 ProxyBreaker 與網路代理伺服器的連結 Extractor Controller 輸出 ProxyBreaker Viewer 中間 檔

的資料, 而且其檔名會包含資料的起始時間 以加速搜尋檔案速度.

WWW server Client Status Byte Frequency 網站被下載量記錄

Client WWW server

Status Byte Frequency

使用者下載量記錄 WWW server: 網站位址 Client: 使用者位址 Status: 網路代理伺服器快取存取狀態碼 Byte: 被下載量或下載量 Frequency: 存取次數 圖六 ProxyBreaker 中間檔格式 由於 Extractor 每隔一段時間才會讀取 log, 因此時間間距會影響 ProxyBreaker 的最 大可能誤差, 最大可能誤差是使用者最大下 載速度 X 時間間距 X 2, 即若使用者最大下 載速度為 20 Kbyte/sec, 時間間距為 50 秒, 則 ProxyBreaker 管制的最大可能誤差為 2 MB, 使用者可能超用 2 MB 才被發現. 在實 務上, 時間間隔會依據使用者平均下載速度 來設定, 像 2.4.1 所提及, 若網路不擁塞, 使 用者下載速度快, 則時間間隔須設定較小, 反 之, 若網路擁塞, 下載速度慢, 則時間間隔可 為較大值. 值得注意的事是若時間間隔設定 較小會讓 SQUID 重新設定的次數增加, 影 響其服務效能. 此外, Extractor 會檢查網路代理伺器的 磁碟空間是否足夠, 自動清除 log 及過期的 中間檔. 雖然 log 已被化簡產生新的資料, 可大幅縮短分析的時間, 但尚未解決 log 檔 佔用大量磁碟空間的問題. 因此 Extractor 會 壓縮過期的 log 約成為原大小的十分之一, 同時清除過期中間檔. 除此之外在磁碟空間 低 於 臨 界 點 時 , 會 自 動 清 除 log. 最 後 , Extractor 會檢查網路代理伺服器快取磁碟空 間是否不足, 如果低於臨界值則會以電子郵 件告知系統管理者, 若沒有得到有效處理, 會 自動呼叫網路代理伺器清除快取中的檔案. 3.2.2 Controller Controller 的功能在於根據管理者預先 設定的流量進行即時管制. 首先利用不同的 中間檔建立兩種雜湊表, 一個是以使用者-網 站為鍵, 值為使用量的雜湊表; 另一個為以網 站-使用者為鍵, 值為下載量的雜湊表. 接著 根 據 管 制 條 件 找 出 違 規 的 使 用 者 , 最 後 Controller 會自動產生對應網路代理伺服器 (即 SQUID)的 ACL (Access Control List), 並 且更新其設定檔, 同時讓新的設定生效. 3.2.3 Viewer

Viewer 負責提供介面供使用者或管理 者 查 詢 管 制 情 況 . 為 容 易 使 用 及 跨 平 台 , Viewer 主要提供 Web 查詢介面, 利用 CGI 程式讀取 Extractor 產生的中間檔中各項使 用量資訊, 讓使用者可查詢其使用量況狀同 時可知道其是否已被暫時停止連線至某些網 站. 3.3 ProxyBreaker 的實作 本系統已實作完成, 在 Pentium II 400, 10/100 Mbps 網路卡的個人電腦上執行. 作業 系 統 是 FreeBSD[21], 網 路 代 理 伺 服 器 是 SQUID 2.3-STABLE, WWW 伺 服 器 是 Apache 1.36[11]. 使 用 perl 程 式 語 言 開 發 , 實作架構如圖七, 中央大學圖書館的網路代 理伺服器已利用 ProxyBreaker 進行流量管制, 目前提供下列功能:  自動產生網路代理伺服器存取控制設定, 包含網站及使用者管制;  自動對異常使用者進行即時管制並公告, 包含網站每單位時間被下載量及使用者 每單位時間使用量管制;  可將使用者或網站分成不同的群組設定 不同的管制策略; ProxyBreaker Proxy servers Utilities

Operation system

Operation system: FreeBSD

Proxy servers: SQUID

Utilities: mail, Apache WWW server

 自我偵測網路代理伺服器是否正常運作, 回報異常情形並自動進行校正.

4 相關研究

網路代理伺服器的管理軟體眾多, 在此 僅 介 紹 與 SQUID 相 關 的 軟 體 . MRTG (Multi-Router Traffic Grapher)[28] 是 Internet 普遍用來顯示網路流量的軟體, 用 C 及 Perl 語言所撰寫, 可在多種平台上執行, 其可根據 所提供的資料, 如 SNMP 的 MIB[29] 資訊, 自動產生 HTML 檔及相關的 GIF 檔, 讓網 路的狀況以圖形化的方式呈現. 另外 MRTG 也可顯示系統的資訊, 例如伺服器負載, hit ratio, request rate 等.

Calamaris[13] 是 分 析 SQUID 的 log 計算各項統計數據並以網頁顯示的軟體, 提 供的資訊可供管理者調整其網路代理伺器效 能 . 其 他 類 似 的 軟 體 有 Anemone[1], pwebstats[22], PY_Squid_Stats[30], WebLog[27] 及 Squeezer[24]. 最後介紹兩種 SQUID 的網 頁 過 濾 器 (filter): SquidGuard[8] 及 Squirm[20], 由於 Internet 上暴力及色情網頁 日益增加, 為保護青少年的身心, 所以在網路 代理伺服器上安裝過濾器以攔阻內容不宜的 網頁, 兩種軟體提供的功能類似, 可以限制使 用者存取網站或網頁、禁止下載含某些字串的 URL 及 將 使 用 者 分 群 管 制 的 功 能 . 根 據 Jann-Perng Tseng[33] 的研究 SquidGuard 遠 較 Squidrm 來得有效率. 表一是各軟體功能 的比較.

表一 有關 SQUID 網路管理軟體的比較

ProxyBreaker Calamaris SquidGuard

Access control V V

Flow control V

URL filter V

Proxy status report V V* V 模組外掛方式 分析 log 分析 log URL 轉向 * Calamaris 各項統計較深入.

5 結論

為使網路頻寬的使用更有效率, TANet 推行使用網路代理伺服器, 藉由網頁的共用 降低頻寬需求. 網路代理伺服器的確有效增 加頻寬的利用率, 若代理伺服器能對不同的 需求提供不同的服務, 則應能進一步提昇網 路服務品質. 同時國內有數所大學的圖書館 因使用者以網頁下載程式大量且連續下載電 子期刊而被警告甚至停權, 因此我們提出一 個 網 路 代 理 伺 服 器 使 用 量 控 制 系 統 , ProxyBreaker, 可根據不同的需求, 提供彈性 的管制機制, 同時可保障網路資源的公平使 用, 維護網路智慧財產權. 未來我們希望能繼 續 改 善 本 系 統 使 其 能 提 供 differentiated service.

參考文獻

[1] http://anemone.electricc.com/ [2] http://gnu.sinica.edu.tw/manual/wget/html_ mono/wget.html [3] http://proxy.nctu.edu.tw [4] http://proxy.nsysu.edu.tw [5] http://proxy.ntu.edu.tw [6] http://www.btsoftware.com/index.html [7] http://www.squid-cache.org/Doc/FAQ/ [8] http://www.squidguard.org/

[9] “The TANet Traffic”, The Ministry of Education Computer Center Newsletter, No. 8807, pp. 83-114, July 1999.

[10] Abdelzaher, T.F. and Bhatti, N., “Web server QoS management by adaptive content delivery”, IWQoS '99: 1999 Seventh International Workshop on Quality of Service, pp.216 –225, 1999.

[11] Apache development group, Apache web server 1.31, http://www.apache.org. [12] T. Berners-Lee, R. Fielding, H. Frystyk,

HyperText Transfer Protocol HTTP/1.0, RFC 1945, IETF HTTP WG, May 1996. [13] Cord Beermann,

http://cord.de/tools/squid/calamaris/

“Differentiated multimedia Web services using quality aware transcoding”, INFOCOM 2000, Vol. 2, pp. 961 –969, 2000.

[15] Xingping Chen and Prasant Mohapatra, “Providing Differentiated Service from an Internet Server”, Proceedings of Eight International Conference on Computer Communications and Networks, pp. 214 –217, 1999.

[16] Ariel Cohen, Sampath Rangarajan and Navjot Singh, “Supporting Transparent Caching with Standard Proxy Caches”, The 4th International Web Caching Workshop, 1999.

[17] Peter Danzig, “NetCache architecture and deployment”, Computer Networks, Vol. 30, Issue 22-23, pp. 2081-2091, 1998.

[18] Peter Danzig, Mike Schwartz, and Richard Hall, “A Case for caching file objects inside Internetworks”, 1993 ACM SIGCOMM, 1993.

[19] R. Fielding, J. Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2068, January 1997.

[20] Chris Foote, “Squirm – A Redirector for Squid”, http://www.wenet.com.au/squirm/. [21] FreeBSD, http://www.freebsd.org

[22] Martin Gleeson,

http://martin.gleeson.com/pwebstats/

[23] A. Heddaya, “DynaCache: weaving caching into the Internet”, The 3rd International Web Caching Workshop, Manchester, England, June 1998.

[24] Maciej Kozinski,

http://www.geocities.com/maciej_kozinski/ w3cache/squeezer.html

[25] P. Krishnan, Danny Raz and Yuval Shavitt, “Transparent En-Route Caching in WANs”, The 4th International Web Caching Workshop, 1999.

[26] Ulana Legedza, John Guttag, “Using network-level support to improve cache routing”, Computer Networks, Vol. 30, Issue 22-23, pp. 2193-2201, 1998.

[27] Mark Nottingham,

http://www.mnot.net/scripting/python/Web Log/

[28] T. Oetiker, D. Rand, MRTG: Multi Router Traffic Grapher,

http://ee-staff.ethz.ch/~oetiker/webtools/mr tg/mrtg.html.

[29] D. Perkins, E. McGinnis, Understanding SNMP MIBs, Prentice-Hall, Englewood Cliffs, NJ, 1997.

[30] David Ramahefason,

http://casimir.easynet.fr/

[31] Squid Internet Object Cache,

http://squid.mlanr.net/Squid

[32] Andrew S. Tanenbaum, Computer Networks, 3rd edition, Prentice Hall , Inc., USA, 1996.

[33] Jann-Perng Tseng and Huei-Huang Chen, “The Implementation and Evaluation of the Proxy Server’s Access Control System”, The Proceedings of TANet’99 Conference, 1999.

[34] D. Wessels and K. Claffy, “ICP and the Squid Web Cache”, IEEE Journal on Selected Areas in Communications, Vol. 16, No. 3, pp. 345-357, 1998.

[35] B. Williams, “Transparent web caching solutions”, The 3rd International Web Caching Workshop, Manchester, England, June 1998.