網際網路服務品質查詢系統之設計與實作

網際網路服務品質查詢系統之設計與實作

吳潮銘、蔡建良、黃金維、蔡志宏

國立台灣大學電信工程研究所

[email protected]

[email protected]

摘要

鑑於目前網路交通量測工具程式 為了量測網路交通情況，往往傳送多數 的量測樣本封包，以達到統計上的精確 度，但同時可能造成將來網路上交通量 測封包充斥，佔據頻寬。為避免這種情 況 ， 這 裡 提 出 結 合 SNMP （ Simple Network Management Protocol）的方式 來查詢網路交通情況，目標是想以最少 數 的 封 包 來 完 成 查 詢 網 路 交 通 的 資 訊。代理伺服器的概念在本文所提的系 統中採用，其能自動尋取服務品資資訊 之功能，並以多個分散式代理伺服器完 成系統架構，以期獲取網路交通資訊過 程中，傳送最少的封包，並對網路交通 狀態有最少的影響。

一. 緒論

檢視目前的網路交通量測偵錯程 式，許多是以 Ping[1]及 Traceroute[2]為 基礎來量測網路交通狀況之應用工具 程式，這些程式是以簡單快速的方法來 量得網路的交通情形。由於程式講求簡 便，在量測估算網路交通狀況參數時， 如封包遺失率，其量測封包樣本代表性 不足，使量測結果的信心區間過大。若 欲縮小信心區間，提升量測封包的樣本 數，這樣會使網路多了額外的負載，網 路的壅塞情形只會更糟。為避免這種情 況 ， 這 裡 提 出 結 合 SNMP （ Simple Network Management Protocol）的方式 來查詢網路交通情況，目標是想以最少 數的封包來完成查詢網路交通的資訊。 一般在上傳與下載頻寬對稱的網 路上，其點至點連結路徑的封包遺失 率，最簡單的獲得方法是傳送 ICMP （Internet Control Message Protocol）回 應請求（Echo Request）封包，並等待 接收 ICMP 回應答覆（Echo Reply）封 包。然後將未收到的封包數除以總傳送 封包數代表封包遺失率，其精準度端視 傳送量測的 ICMP 回應請求的總封包 數。愈多的量測封包得到愈高的精確 度，同時也佔據了某些頻寬；反之若欲 儘量不佔頻寬而只傳送少數的 ICMP 回 應請求封包，量測所得的封包遺失率值 愈不精確。為改善上述方式，我們認為 適當利用 SNMP 網管系統的查詢方式 可以改善上述的情況。然而，由於多數 ISP 網路管理人員均傾向不開放其自己 的 SNMP 資訊給非該領域之網管人員 或一般使用者，我們認為直接以量測工 具取得 SNMP 資訊並不容易。 此外，利用 ICMP 封包量測封包遺

失率時，無法判定封包是在上傳或是下 載的路徑中遺失。這裡所提出的分散式 伺服器架構，可以改善此項一般量測工 具功能之不足，經由伺服器間彼此合 作，分別找出上傳與下載路徑中的封包 遺失率。相同地，為了達成以少量的封 包 完 成 獲 取 網 路 交 通 狀 況 資 訊 的 目 標，代理伺服器的概念亦在此採用。

二. 系統架構設計

代理伺服器（Proxy Server）的架構 廣泛使用在全球資訊網，其擷取網站資 料的工作交由代理伺服器執行，使用者 的電腦再向代理伺服器取回目標網站 的資料。代理伺服器會將最近所擷取的 網站資料，以快取的方式保留一份，當 任何使用者請求代理伺服器擷取網站 資料時，若代理伺服器的快取記憶內容 有相同資料，即立刻傳回給使用者，可 免除從原始網站再下載一份相同的資 料。其優點是節省資料在網路上傳送， 亦可縮短使用者取回資料的時間，符合 所提出減少封包傳送的目標。在此，系 統架構亦採用代理伺服器的方式，稱為 服務品質查詢代理伺服器（QoS Query Proxy），其功能包含量測封包來回傳輸

時間（Round Trip Time）、查詢路由器或

第三層交換機（以下僅用路由器來代表 兩者）的 MIB 資料庫、與它台服務品質 代理伺服器合作、網路服務品質評估與 計算等。由於一般網路管理者不開放其 SNMP 網管資訊，通常以 Community 或 其 它 用 戶 識 別 方 式 區 隔 資 訊 取 得 權 限，所以本架構所提出的伺服器個別僅 負 責 對 其 所 屬 區 域 的 路 由 器 查 詢 （Query）MIB 資料庫，無權亦不易查 詢其它區域路由器的 MIB 資料庫，因此 伺服器將設計成一分散式的架構。伺服 器除了自己負責的路由器外，對其它路 由器的 QoS MIB 內容及其該區域所對 應的 QoS 查詢代理伺服器負責查詢其 MIB 資料庫則完全不知情，因此需要一 個類似分散式資料庫系統的功能來輔 助尋找負責查詢各路由器 MIB 資料庫 的服務品質查詢代理伺服器，這裡是藉 由 「 服 務 品 質 管 理 域 名 系 統 」（ QoS Domain Name System，簡寫為 Q-DNS） 來完成。

2.1 設計目標

對於一個網路交通資訊量測或查 詢系統，參考[7]的設計目標，提出我們 這裡的設計目標：  減少傳送封包：服務品質查詢系 統必須將量測與查詢過程所需 傳送封包儘可能的減少，並且時 常更新量測與查詢結果以反應 當時的網路服務品質。  分散式的系統：將量測或查詢系 統分置於不同區域，構成一個分 散式的系統，可避免為了量測或 獲得網路交通資訊所傳送的封 包集中於固定區域，造成網路壅 塞源。  公正地量測及查詢：目前部分網 際網路量測的困難在於其組成 是許多不同的區域網路，每個 區域網路的管理者有他們自己 的量測策略，所以提出的量測 及查詢內容需是基本的，且能

在不同的產品（Vendor）環境下 公正地量測及查詢。  容易擴大規模：現今的網際網路 規模相當龐大，量測或查詢系 統平台要能容易地增加，以因 應大規模互連 ISP 的網路交通 資訊取得，不可只適用於區域 網路上。  分區全權控制平台：量測或查詢 代理伺服器要單一化的管理， 完全由區域網路的網路管理者 控制管理，他可決定是否加入 網路服務品質查詢系統或其量 測查詢子系統。  量測功能模組化：對於每種網路 特性，分別設計一個量測模組 來實現，並於整合介面上設計 個別啟動方式，以期各平台可 選擇部份或全部的量測或查詢 功能。  最少的管理，具自行設定組態能 力：手動方式設定的平台，在 小規模的情況下尚無問題，當 量測或查詢規模迅速擴增時， 設定或更動平台恐會變得很麻 煩。因此對平台的增減，量測 或查詢系統最好能自動規劃調 整，或是平台的設定管理的複 雜度不隨平台數量增減而改 變。

2.2 代理伺服器式之服務品質

查詢系統架構

根據設計目標，在此提出圖一的網 際網路服務品質查詢系統的整體架構 圖。其中服務品質查詢代理伺服器設計 成分散式的系統，它們使用 SNMP 通訊 協定，各自負責查詢一個區域（如校園 網路、企業網路或網路服務提供業者） 或數個區域內之路由器的 MIB 資料，如 實體層頻寬、緩衝區大小、封包遺失數 量、封包轉送數量及其它與網路服務品 質相關資料等，皆可透過 SNMP 取回。 對於別的區域之網路服務品質相關資 訊，分散的服務品質查詢代理伺服器則 使 用 服 務 品 質 資 訊 交 換 協 定 （ QoS Information Exchange Protocol）來互相 傳送。然而在分散式的服務品質查詢代 理伺服器之間，彼此不知道其它代理伺 服 器 的 位 置 與 其 所 負 責 查 詢 的 路 由 器，因此在分散式系統的搜尋上，這裡 採 用 服 務 品 質 管 理 域 名 系 統 （ QoS DNS）的架構，稱為 Q-DNS，並經由 Q-DNS Protocol 來完成分散式系統的階 層架構。 QoS Application or QoS Surfing Tool

Internet QoS Profile (MIB) :

Delay/Jitter Bound ． BW ． Buffer Limit ．

Packet Loss Control ． QoS Information Exchange Protocol QoS Query Proxy QoS Query Proxy QoS Query Proxy ．．．．． Network State Probe (SNMP Agent) Router Router Layer 3 Switch QoS Profile Query ( SNMP )

Network Service Plane Network Management Plane

QoS Profile (MIB) : Delay/Jitter Bound ． BW ． Buffer Limit ．

Packet Loss Control ． 圖一：服務品質查詢系統架構圖 Network State Probe (SNMP Agent) Router Layer 3 Switch QoS Information Exchange Protocol QoS Information Exchange Protocol Q-DNS Root Server Q-DNS Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol Current Implementation 查詢所得結果，亦可經由服務品質 資訊交換協定，將其與網路管理系統整 合。使用者則使用網路服務品質瀏覽工 具或其它直接利用服務品質之應用程 式，由資訊交換協定來取得並利用網路 服務品質。故用戶端之程式可以是一個 視窗應用程式，亦可整合在全球資訊網

瀏覽器的界面，或是與現有區域網路軟 體整合。

2.3 服務品質查詢代理伺服器

網際網路服務品質查詢系統主要 是由服務品質查詢代理伺服器構成，此 伺服器亦為本文所致力設計與完成的 部份。服務品質查詢代理伺服器會定時 地向所管轄的路由器取回其 MIB 內的 網路服務品質相關之資訊，並暫時記錄 下來，等待其它服務品質查詢代理伺服 器的詢問。當使用者想知道他到某一目 標主機間的網路交通狀況時，便詢問服 務品質查詢代理伺服器，查詢代理伺服 器接到使用者的詢問時，先找出到達使 用者目標主機會經過的路由器，再由 Q-DNS 系統來尋找管轄各路由器的服 務品質查詢代理伺服器，然後向各路由 器的管轄者詢問服務品質相關資訊，最 後將各查詢代理伺服器所傳回的網路 服務品質相關資訊回報給使用者。計對 以上所述之功能，參考[3]量測代理伺服 器的模組設計，這裡分別設計服務品質

資訊查詢模組（QoS Query Module）、尋

徑模組（Trace Module）、服務品質域名

系統模組（Q-DNS Module）、資訊交換 模組（Information Exchange Module）、 效 能 評 估 及 解 譯 模 組 （ Performance Prediction and Interpretation Module）等 五 個 模 組 來 完 成 ， 如 圖 二 所 示 。 圖二：服務品質查詢代理伺服器內部模組 Other QoS Query Proxy QoS Information Exchange QoS Query Module Q-DNS Module ( BIND ) Q-DNS Protocol End User QoS Application QoS Information Exchange Information Exchange Module Performance Prediction and Interpretation Module Router Layer 3 Switch SNMP SNMP Trace Module

QoS Query Proxy Server

Q-DNS Root Server Q-DNS Protocol

三. 服務品質分析與應用

3.1 服務品質資訊

3.1.1 封包傳送延遲時間

以統計學的觀點，精確的量測需有 足夠的樣本數，但對於時變的受測母 體，無法在時間軸的同一點上採集所需 的樣本數，亦無法獲得當時的精確量測 結果。因此這裡封包傳送延遲時間是將 連續的 ICMP 回應答覆封包的來回傳送 一趟所耗時間予以平均，再取其一半值 即為封包傳送延遲時間。由於不能個別 區分封包在上傳及下載的延遲狀況，在 此所得的封包傳送延遲時間值是一個 近似值。

3.1.2 封包遺失率

本文的訴求是以網路管理 MIB 資 料庫的資訊來取代量測方式所獲得的 網路服務品質資訊，其最顯著的項目就 是封包遺失率。對於端點至端點連線中 的路由器節點，封包遺失率由 IP 轉送封 包數、IP 輸出要求封包數、IP 輸出遺失 封包數、IP 轉送遺失封包數等四個 MIB 資料來獲得。由於此四個資料形態是三 十二位元的整數計數器，且在路由器運

轉後即持續地累積計數，代表的訊息是 一個長時間未加權的統計量，並不適合 代表網路的即時服務品質，加上三十二 位元的計數器會有溢位的情況發生，因 此路由器節點的封包遺失率在此必需 以增量估算值計算獲得，如(1)式所示。 在本系統的服務品質查詢代理伺 服器每五分鐘會自動地查詢其所管轄 路由器的 QoS MIB 資料，並算出五分鐘 內計數器的增量，以(1)式計算來代表路 由器 IP 位址的封包遺失率。至於增量的 間隔時間長短沒有特別的要求，這裡定 每五分鐘對路由器查詢一次 MIB 資料 的考量因素為兩個，第一：太短的間隔 時間會使路由器的負擔增加，尤其是路 由器負載很大時，第二：太長的間隔時 間，所得的 MIB 資料對網路目前的狀況 較無代表性。 ) 1 ( 　　 ＝ grams ipForwData sts ipOutReque iscards ipRoutingD rds ipOutDisca p      

有了中間節點的封包遺失率，端點至 端點的封包遺失率可以用簡單的方式 來表達，以圖三為例，下載路徑的封包 遺失率為：



1



1



1



(2) 1 1 2 3 　　　 ＝　 p p p  P     Server Client Packet Loss Rate 1 p Packet Loss Rate 2 p Packet Loss Rate 3 p 圖三：連結路徑之封包遺失率 Data Flow Request

3.1.3 網路實體頻寬

從目標網站至使用者端所經各段 路由器的下載 IP 位址之實體網路頻 寬，這裡由各路由器的 MIB 資料取得。 MIB 資料庫的 ifSpeed 記錄該 IP 位址實 體層的頻寬。一般在網路的終端地區， 大量使用橋接器（Bridge）、乙太網路交 換器（Ether Switch）等網路通訊協定第 二層的網路設備，對於這些網路設備無 法以第三層的 IP、ICMP 通訊協定來尋 找。因此若資料傳輸經過第二層網路設 備時，我們仍然不能得到所有下載路徑 所經網路設備各段的實體頻寬。除非在 第二層的網路設備支援網路管理 SNMP 通訊協定，並由網路管理系統提供網路 拓撲（Topology）資訊，即可得知下載 路徑各段網路設備的實際頻寬。

3.1.4 路徑最大封包傳送單位（Path

MTU）

封包傳送的大小攸關傳送效率。在 網路架構各層的通訊協定標頭（Header） 皆有固定的位元組數，每個封包將通訊 協定的標頭位元組數扣除才是真正傳 送的資料量。因此傳送的封包愈大，傳 送效率愈好，但封包傳送延遲時間增 加，且封包傳送中發生位元錯誤的機會 也愈大；而太小的傳送封包則傳送效率 不佳。對於實際可傳送封包的最大值 （MTU）會因實體網路之差異而不相 同，其定義在網路第二層的通訊協定 中， 在高速的實際網路環境內會有較 大的傳送單位值。對於下載路徑的最大 封包傳送單位，這裡是將各路由器 MIB 資料的 ifMtu 值取回，當中的最小值即 為路徑最大封包傳送單位。同 3.1.3 節 所述情況，對於網路通訊協定第二層未 支援 SNMP 的網路設備，在此亦不能獲 得其最大封包傳送單位值。 目前我們 採用以下方式估算 PathMTU：



1, 2, ,



　　(3) ＝MinMTU MTU MTUn

PathMTU 

3.2 服務品質查詢系統之應用

3.2.1 應用於分級服務網路

為了加強在網際網路上的服務，所 以有許多研究及設計被提出來。目前的 發展是在網路上將提供有服務品質保 證 的 分 級 服 務 （ Differentiated Services），其在 IP 欄位的定義[14]及架 構[15]已見諸於各 RFC。根據目前已有 RFC 之規劃，分級服務的提供是以各個 網域為範圍，當端點至端點的連線同時 跨過分級服務及未支援分級服務的網 域時，連線的服務品質就不能獲得保 證。且各個分級服務的網域有個別的服 務品質策略及安排方式，其網路的服務 品質會嚴格控管，不會讓外界直接存 取。而介於分級服務的網域之間，在建 立服務品質保證連線前，其服務品質資 訊 取 得 需 遵 循 每 站 行 為 （ Per-hop Behavior：PHB）之規定，所以分級服 務網域的服務品質資訊交換只限在相 鄰的分級服務網域之間，不能跨過網域 傳遞，這對建立服務品質保證的連線要 求沒有問題，可是對端點至端點連線所 能提供的服務品質資訊卻無法取得。本 文所發展的網際網路服務品質查詢系 統與分級服務系統架構在所管轄網域 的服務品質蒐集功能方面非常類似，服 務品質查詢代理伺服器亦可以應用於 分級服務的網域內，因此這裡提出圖四 的跨網域整合架構圖，以獲得端點至端 點連線的服務品質資訊。 圖四的整合架構圖除了在使用網 路服務跨過分級服務網域外，其餘皆與 圖一相同。在分級服務網域內的服務品 質控制與頻寬分配是由「頻寬代理商」 BB（Bandwidth Broker）負責。對於一 個可信賴的分級服務網域內，只能有一 個 BB 代表其網域來與相鄰分級服務網 域的 BB 代表溝通，其要能掌握網路的 即時狀況及網域內各節點的服務品質 資訊，再根據它的策略資料庫來規劃設 定路由器，以提供相鄰分級服務網域的 特別網路服務要求。不論分級服務網域 內所有的服務品質資訊是由 BB 負責取 得或是由網路管理系統負責取得再傳 給 BB，BB 一定有該網域內所有的服務 品質資訊。因此部署在分級服務網域內 的服務品質查詢代理伺服器應將其內 的服務品質查詢模組的功能關閉，不用 直接向路由器查詢 MIB 資料，改由 BB 處取得服務品質資訊，而其中的通訊協 定則需視 BB 系統的實作方式及其願意 提供的服務品質項目而定之。 Q-DNS BB QoS Query Server DiffServ Domain BB QoS Query Server DiffServ Domain Q-DNS Root Server QoS Query Server QoS Query Server Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol Q-DNS Protocol QoS Information Exchange Protocol QoS Information Exchange Protocol QoS Information Exchange Protocol QoS Information Exchange Protocol Q-DNS Protocol End User (Client) SNMP Query SNMP Query Destination Host (Server) QoS Information Exchange Protocol Router Layer 3 Switch Router RouterLayer 3 Switch RouterRouter 圖四：服務品質尋取系統與分級服務系統之整合架構圖

3.2.2 自動詢價的應用

未來在分級服務網域的收費方式 亦有可能會採分級的方式，其各等級的 收費可能是固定的或隨時段、網路狀 況、使用量的多寡、服務品質而動態地 調整。在圖四內的服務品質資訊交換通 訊協定內可以增加價格的資訊，讓使用

者查詢完服務品質資訊後即可了解當 時 在 各 分 級 服 務 網 域 的 等 級 收 費 資 訊。待將來最大努力傳送機制的網路升 級至分級服務網路後，服務品質查詢系 統 在 收 費 資 訊 上 的 應 用 可 以 隱 藏 （Embedded）在應用程式內，讓使用者 不必刻意去查詢即可隨時了解當時上 網的費用及截至當時已累積的使用費 用。 因此將來網路電話盛行時，各網路 服務提供業者可以利用服務品質查詢 系統內的收費資訊進行他們的網路電 話使用即時報價資訊，以公平競爭的方 式提供網路電話服務。而顧客拿起網路 電話機的話筒時，服務品質查詢系統立 刻查詢所有可以使用的網路電話提供 者之品質及使用價格資訊，在網路服務 品質符合網路電話使用的諸網路提供 者之間，自動尋找最便宜的網路服務組 合讓顧客使用。

3.2.3 域名代理伺服器（DNS Proxy）

動態指定網址之應用

在網路上的每台主機至少要指定 一部域名系統伺服器，才能進行主機域 名與網路位置（FQDN  IP）的對映轉 換。結合服務品質查詢系統，我們可以 設計一部依據服務品質來動態指定網 址的域名代理伺服器（QoS-Based DNS Proxy），如圖五所示。使用者將其指定 的域名伺服器（DNS Server）改指定 QoS-Based DNS Proxy 為其域名伺服 器。當使用者要連接網站時，會傳給 QoS-Based DNS Proxy 一個目標網站的 名稱，這時 QoS-Based DNS Proxy 會向 域名伺服器查詢使用者目標網站的 IP 位址，若目標網站有多個映射站（Mirror Sites）時，名稱伺服器會把所有映射站 的 IP 位址回給 QoS-Based DNS Proxy， QoS-Based DNS Proxy 便逐一向服務品 質查詢代理伺服器來查詢各個映射站 的網路服務品質，然後找一個網路服務 品質最好的 IP 位址傳回給使用者，使用 者便可每次都動態地連接服務品質最 佳的目標網站。 DNS Server QoS-Based DNS Proxy End User QoS Query Proxy 圖五：動態指定網址的系統架構圖

四. 實作結果

本文所設計之網際網路服務品質 查詢系統主要是由服務品質查詢代理 伺服器構成，此伺服器亦是這裡實作完 成的部份。組成查詢代理伺服器的五個 模組中，服務品質資訊查詢模組是修改 麻省理工學院在 public-domain 上公開 的 SNMP 程式碼[11]；尋徑模組即是 Traceroute 程式，本實驗室參考[1]已有 實作這部份的程式碼，直接取用之；服 務 品 質 域 名 系 統 模 組 則 使 用 BIND （Berkeley Internet Name Domain）的名 稱伺服器的功能，但在搜尋服務品質查 詢代理伺服器的過程中，為了避免與

DNS 的搜尋樹發生混淆，不可使用各作 業系統平台解析（resolver）程式中的預 設名稱伺服器，所以在 Q-DNS 的部份 發展了一份 Q-resolver 解析程式；資訊 交換模組與效能評估及解譯模組則完 全在本文中發展。五個模組已陸續完 成，並在 LINUX Redhat 5.2 作業系統 （kernel 2.0.36）平台上成功地整合成服 務品質查詢代理伺服器。

服務品質查詢代理伺服器對所管 轄路由器查詢 MIB 資料時，必須有一個 稱 community 的密碼，路由器才會答詢 其 MIB 資料。由於安全的因素及管理上 的 考 量 ， 要 取 得 大 量 路 由 器 的 community 來完成大規模實際跨多網域 的測試比較困難。在可取得資源的條件 下，在此提出圖六的測試架構圖。 140.112.175.0 140.112.19.0 router19.ee 140.112.19.254 r7513-EE 140.112.254.8 dorm1-cisco4 140.112.1.240 140.112.175.254 ntu-router 140.112.1.254 r7513-NTU 140.112.254.6 golden.m14 140.112.175.146 tiger.ee 140.112.19.83 Q-DNS Root Server (manager2.ee) 140.112.19.150 End User QoS Profile Query Server QoS Profile Query Server 圖六：服務品質尋取系統測試架構 測試架構圖所示的測試網域是從 台大電機二館的 140.112.19.0 子網域至 台大男 14 舍 140.112.175.0 子網域，這 兩個子網域中間經過三部台大計算機 中心所管轄的路由器，在計算機中心的 協 助 之 下 ， 給 我 們 這 三 部 路 由 器 的 community。設在電機二館內的 tiger.ee 服 務 品 質 查 詢 代 理 伺 服 器 負 責 管 轄 140.112.19.0、140.112.254.0 兩個子網域 內的路由器 IP 位址：140.112.19.254、 140.112.254.8、140.112.254.6；設在男 14 舍的 golden.m14 服務品質查詢代理 伺 服 器 負 責 管 轄 140.112.1.0 、 140.112.175.0 兩個子網域內的路由器 IP 位址：140.112.1.254、140.112.1.240、 140.112.175.254。Q-DNS 根伺服器則由 電機二館內的 manager2.ee 工作站來執 行。 圖七與圖八為簡單的網路服務品 質 瀏 覽 器 ， 其 中 圖 七 是 查 詢 從 140.112.175.147 主 機 傳 送 資 料 至 140.112.19.0 子網域所經路由器的服務 品質資訊，從結果可知封包的 Round Trip Time 為 2ms、各路由器下載網路卡 在五分鐘內的平均封包遺失率、各路由 器的實體頻寬及 MTU 等資訊。依實體 頻寬為 100Mbps 及 MTU 為 1500 位元 組之資訊可以判斷 140.112.19.254 為 Fast Ether net，而 MTU 為 4470 位元組 可猜得 140.112.254.6 及 140.112.1.240 為 FDDI 網路。圖八則是 140.112.19.87 主機傳送資料至 140.112.175.0 子網域 所經路由器的服務品質資訊。將圖七與 圖八查詢的結果統合即為 140.112.19.0 與 140.112.175.0 兩個子網域間之網路 上傳及下載路徑的服務品質資訊。 圖七：140.112.175.0 子網域至

140.112.19.0 子網域下載路徑之網路服 務品質 圖八：140.112.19.0 子網域至 140.112.175.0 子網域下載路徑之網路服 務品質 由以上各部份的結果討論顯示，服 務品質查詢代理伺服器如先前所設計 般地完成的所有的功能。

五. 結論

本文所設計之網際網路服務品質 查詢系統的創新之處在於代理式查詢 方式，自動尋取服務品資資訊的功能， 並 以 多 個 分 散 式 代 理 伺 服 器 架 構 完 成，以傳送最少封包的目標來獲取網路 的服務品質，並對網路交通狀態有最少 的影響。從第四章的實作結果顯示，構 成系統架構的服務品質查詢代理伺服 器符合我們的目標。 由於多數 ISP 網路管理人員均傾向 不開放其自己的 SNMP 網管資訊給非 該領域之網管人員或一般使用者，我們 認為直接以量測工具取得 SNMP 網管 資訊並不容易。因此本文的第一個貢獻 是可以跨網域來獲得各個不同管理網 域的 SNMP 網管資料；而第二個貢獻是 在分散式的系統架構中，可以透過伺服 器間的合作，在目標網域內執行尋徑模 組，可找出所有上傳所經路由器的 IP 位址，再對各個 IP 位址查詢 MIB 資料， 即可以得知上傳及下載路徑（即 TCP 封包傳送的全路徑）的網路服務品質資 訊，這對網路壅塞點的位置尋找非常重 要，尤其是在非對稱頻寬的網路環境 中。 在 現 行 最 大 努 力 傳 送 機 制 的 TCP/IP 網路，由於路由器皆公平地對待 網路上傳送的封包，所以當網路壅塞 時，任何網路應用程式執行速度皆受影 響，這時不論是何種網路量測程式或是 本文的服務品質查詢系統，常因封包的 嚴重延遲或大量遺失，對網路服務品質 資訊常無法獲得，這會讓使用者對這類 軟體逐漸不感興趣。3.2 節中所述的分 級服務網域可以改善上述的問題，因分 級服務網路內可以設定封包傳送的優 先權，只要將服務品質量測程式或查詢 系 統 的 封 包 傳 送 優 先 權 設 為 第 二 優 先，僅次於網路控制及管理封包的最高 優先權。如此將可在網路壅塞的環境 中，仍能快速地得知網路的服務品質， 保證使用者或其應用能真正在連網前 即得知當時的網路交通狀況及服務品 質。如此，本文所提出的各項應用，如 分網服務網路品質之查詢、自動詢價、 動態指定網址等，均將實現之可能。

六. 參考文獻

[1] W. R. Stevens, UNIX Network Programming, Prenticd-Hall, 1990.

[2] V. Jacobson, et al. traceroute, 1988. [3] 蔡建良，“網際網路服務品質量測 系統之設計與實作”，台灣大學電機工 程研究所碩士論文，中華民國八十七年 六 月 。 ( 可 下 載 程 式 之 網 址 為 http://eagle.ee.ntu.edu.tw)

[4] W. R. Stevens, TCP/IP Illustrated Volume 1: The Protocols, Addison Wesley, 1994.

[5] W. R. Stevens, TCP/IP Illustrated Volume 2: The Implementation, Addison Wesley, 1995.

[6] W. R. Stevens, TCP/IP Illustrated Volume 3: The Application, Addison Wesley, 1997.

[7] V. Paxson, J. Mahdavi, A. Adams,

M. Mathis, “An Architecture for

Large-Scale Internet Measurement,”

IEEE Communications Magazine, pp. 48-54, August 1998.

[8] K. McCloghrie, M. Rose,

“Management Information Base for network management of TCP/IP-based internets: MIB-I,” RFC 1156, May 1990. [9] M. Rose, K. McCloghrie, “Concise

MIB Definitions,” RFC 1212, March 1991.

[10] K. McCloghrie, M. Rose,

“Management Information Base for Network Management of TCP/IP-based internets: MIB-II,” RFC 1213, Mar. 1991. [11] J. Davin, “mit-snmp”,

Massachusetts Institute of Technology, 1989.

[12] P. Albits, C. Liu, DNS and BIND, O’Reilly & Associates, 1992.

[13] K. Nichols, V. Jacobson, L. Zhang, “A Two-bit Differentiated Services

Architecture for the Internet,”

ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.

[14] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” RFC 2474, December 1998.

[15] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Services,” RFC 2475, December 1998.