以應用層為基礎之網路品質量測

(1)

以應用層為基礎之網路品質量測

賴守全

銘傳大學

電腦與通訊工程學系

郭文曲

國立清華大學

資訊工程學系

摘要

隨著電腦網路科技的快速發展，網際網路也逐漸成為生日常活中的一部份。然而有著越來越多的網路應用，需要穩定而快速的網路，才能實現網路生活帶給我們的便利。當使用者發現網路狀況不理想時，通常能做的，就是跟網路管理者抱怨，然而不少時候，網路管理人員從網路管理系統上所得到的數據，卻顯示網路並沒有明顯的障礙，也因此常常產生使用者和管理者認知上的差異。在本論文中，我們提出一個更能貼近使用者使用狀況的網路狀態量測系統-「以應用層為基礎的網路品質量測系統」，來對網路狀況進行量測，期能更精準的反應使用者的感受，同時也能讓網路管理者在處理使用者的抱怨時能夠有更實質的依據。關鍵詞關鍵詞關鍵詞關鍵詞：網路管理、網路量測、網路品質

1. 前言

前言

隨著電腦網路科技的快速發展，各種網路應用如雨後春筍般蓬勃發展，網際網路也逐漸成為生日常活中的一部份。透過網際網路，可以查詢各種生活資訊，如新聞和氣象，也可以拍賣或購物，還可以透過網路線上申請各種服務。然而有著越來越多的網路應用，需要穩定而快速的網路，才能實現網路生活帶給我們的便利，例如：今年的大學推薦甄選的志願填表，媒體新聞報導，有的學生需要 2 個小時以上的等候才能完成志願選填。此外，不少大學生熟悉的網路選課，也深受網路品質的影響，網路順暢的就能幸運的搶到想要的科目，網路狀況不佳的，就可能因此喪失了先機。當使用者發現網路狀況不理想時，通常能做的，就是跟網路管理者抱怨，然而不少時候，網路管理人員從網路管理系統上所得到的數據，卻顯示網路並沒有明顯的障礙，也因此常常產生使用者和管理者認知上的差異。現今有許多網路管理者都採用 MRTG 來監控網路的狀況。在許多情形下，MRTG 的統計圖並沒有呈現很高的網路流量，也就是俗稱的網路塞車的情況，但網路使用起來並沒有非常順暢的情況，因此我們認為 MRTG 的網路流量統計圖並不足以反應網路使用情形的全貌，應該存在其他更能反映使用者使用狀況或感受的量測系統，方能更準確的反映網路的使用情況，為使用者和網路管理者的認知差異建立更好的溝通橋樑。當使用者實際在使用網路時，都是以電腦上的應用軟體來進行資訊的傳輸，例如利用網頁瀏覽器來瀏覽網站，或用電子郵件軟體來收發 email，或者使用 FTP 軟體來進行檔案的傳輸。然而以一般網路品質量測，或是直接讀取網路設備上的封包流動數量，或封包流量大小，來呈現網路的使用狀態；或者是使用"ping"（送出 ICMP 封包並等候回應），來量測網路的傳輸情況。就量測封包傳輸總量來說，當傳輸總量並沒有造成網路頻寬壅塞時，並不能反映個別的使用情況。就 ping 的使用來說，其發送的 ICMP 封包是一種網路層的傳輸行為，並非完全等同於實際應用軟體於應用層的傳輸情況，加上效能量測或資通安全的理由，ICMP 封包在不少網路設備常被加速處理或攔截阻絕，因此 ping 也常無法獲得所需的資訊。因此採用應用層的協定，針對提供服務的系統加以量測，一來無被阻絕的顧慮，二來在應用層上進行，將能更準確的反映使用者使用上情況。在本論文中，我們將提出一個更能貼近使用者使用狀況的網路狀態量測系統-「以應用層為基礎的網路品質量測系統」，來對網路狀況進行量測，期能更精準的反應使用者的感受，同時也能讓網路管理者在處理使用者的抱怨時能夠有更實質的依據。我們將建置一個網路量測系統，並以程式語言開發能模擬網路應用的簡易連線軟體來進行量測，並將量測後的結果以圖形化的方式加以呈現，配合定期監控的自動機制，期能有效反映常見網路應用的使用情況，以做為使用者或管理者掌握網路品質的有力工具。在下一節，我們將介紹目前量測網路狀態的常見方法及其運作原理。在第三節中，我們將介紹如何設計與實作一個以應用層為基礎之網路品質量測系統，以補強現有量測方式之不足。這個新系統的實際運作成效將在第四節中加以討論。最後一節為本論文的結論。

2. 網路狀態

網路狀態

網路狀態量測

網路狀態

量測

為了解網路運作的概況，網路管理者除運用一些網路診斷工具來了解當時的網路情況外，也常使用一些工具程式來量測網路的常態運作概況。目前最常見的網路量測工具包含 MRTG (SNMP)、ping、

(2)

及 HTTP ping 等，以下就這些常見工具的運作方式與特性加以討論。

2.1 MRTG (SNMP)

MRTG (Multi Router Traffic Grapher) [4]是目前相當常見的網路監控工具，它可經由內附的 SNMP (Simple Network Management Protocol) [6]模組詢問網路設備的流量或其他相關數據，進而繪製成為易於觀察的圖形。圖 1就是一個典型的 MRTG 圖形，圖形的橫軸為時間，縱軸為頻寬的使用量，而藍線和綠線是由每 5 分鐘的輸入和輸出頻寬使用量的量測值所構成的曲線。MRTG 可攜性是非常高的，可以執行在大多數 Unix 和 Windows NT 系統之上。現在網管人員普遍使用 MRTG 來將各種量測數據以生動的視覺效果呈現。圖圖圖 圖 1 MRTG 圖呈現網路頻寬使用狀況圖呈現網路頻寬使用狀況圖呈現網路頻寬使用狀況圖呈現網路頻寬使用狀況 MRTG除了能夠提供詳細的每日數據記錄，同時也能夠以相同的視覺呈現方式產生過去七天，過去一個月，以及過去一年的數據記錄。MRTG 會把從網路設備取得的數據記錄下來，並將這些記錄自動合併計算，其儲存空間不會隨著時間的成長而成長，但仍保留足夠提供過去一年年數據趨勢的資訊。在實務應用上，MRTG 常透過 SNMP 來取得支援 SNMP 的網路設備的各種資訊(仍有些低階設備並不支援 SNMP)，如：封包傳輸量，封包傳遞數，封包錯誤數量等。但 MRTG 的使用並不侷限於網路設備內建 SNMP 數據的取得，MRTG 也可以配合外部程式來收集想要用 MRTG 進行監控的數據，例如我們可用 Perl 設計量測程式，並以該程式量測特定的標的並傳回量測值，之後將量測的數據交由 MRTG加以處理並繪製成圖形，以方便網路管理人員觀察量測的結果。從實務經驗上不難發現，頻寬的使用量在非達到飽和的情況下，僅能顯示頻寬上有餘裕，但這並不表示網路應用的運作必定非常順暢，舉例來說，某個網路通訊埠可能因故被封鎖，而導致某種網路應用無法正常使用，或者會增加該應用使用上的延遲，然而這種現象在頻寬使用圖上是顯示不出來的。因此，網管人員僅觀察頻寬使用狀況來解釋網路的狀態是有所不足的。

2.2 ping

若要了解網路的連通狀況，ping 是個相當好用的工具。透過 ping，除了可以顯示出從發起地到目的地的網路連通狀態，亦可得知 ICMP (Internet Control Message Protocol) [5]封包來回所需要的時間。如果定時以 ping 去檢測一些標的網路設備或網站，並將結果傳回 MRTG 加以處理，就可以得到一個定期 ping 量測結果的 MRTG 圖。透過 ping 的量測，是可以得知網路的連通性，但隨著網路安全日益受到重視，不少網路管理者會關閉網路設備或網路伺服器對 ICMP 的回應，有的管理者甚至會把送進其所管理網域的 ICMP 封包加以過濾阻絕，造成 ICMP 量測實務上的困難。在這種情況之下，網路管理者將無從得知其所管理網路連通到其他網路的連線狀況，因此，有必要發展一個新的連通量測程式，來補強 ping 所遭遇的阻絕問題。

2.3 HTTP ping

隨著 WWW 應用的普及，WWW 在網際網路應用中所扮演的角色也日益重要，WWW 的穩定運作也漸漸成為網際網路穩定運作的重要因子。透過 WWW流量的觀測以及 ping 的詢問，或許可以顯示 WWW的資料傳輸情況及網路層(Network Layer)反應速率。然而，異常的 WWW 運作，也可能會產生傳輸量，在應用層(Application Layer)異常的情形下，其網路層也可能維持正常的運作，因此流量觀測和 ping 反應都仍有其不足之處，也因此 HTTP ping [2]被提出作為觀測 Web 伺服器的一個新方法。 HTTP ping運作於應用層，在 Web 伺服器異常的情況下，能反應出其 HTTP 運作狀態的異常，然而，HTTP ping 在獲得正確 200 狀態碼的回應後，即結束其檢測。這樣的檢測方式，對首頁結構相當單純的 Web 網站來說，或許是足夠的，但是對網站首頁內容中，包含有其他元件仍須從其他網站取得的情況下，距離使用者實際用瀏覽器瀏覽網站首頁的情況，仍有些差距，應有改進的空間。從以上討論中我們可以發現，這些目前常用的網路狀態量測工具，並不能有效的反應使用者在網路應用上可能面臨的真實使用情況，也因此，當網路管理者觀測認知網路狀況良好的情況下，使用者卻可能有完全不同的感受。因此，我們提出網路狀態的量測，除網路設備本體，及網路層運作狀態外，應加上應用層的量測，方能有效反應出使用者可能遭遇的使用狀況，如此網路管理者將能更有效的排除可能的問題，為使用者提供更好的網路環境。

(3)

3. 應用層

應用層

應用層網路

應用層

網路

網路量測

網路

量測

量測系統之設計與實作

系統之設計與實作

網際網路上有著各式各樣的網路應用，如： WWW、電子郵件(email)、檔案傳輸(FTP)、網路電話(VoIP)，視訊會議(video conference)等，這些應用都有著各自不同的應用層通訊協定，要充分了解各式應用在網路使用上的概況，必須發展足以模擬各式應用的網路品質量測系統。然而本論文之目的並非發展完整的應用層網路品質量測系統，而是提出以應用層為基礎之網路品質量測，相較於傳統量測方法，更能反應出使用者使用網際網路的概況。因此，我們將挑選常用的網際網路應用，並藉由量測該應用的使用狀況，來和其他量測方法進行比較。

WWW (World Wide Web)是當前網際網路最普遍且不可或缺的應用。在瀏覽或使用網站資源的過程中，如何能順利連接上網站，並傳回首頁(Home Page)的畫面，以利後續瀏覽或操作的進行，是整體網站應用過程中相當重要的第一步。從長年的網路管理經驗中可以發現，對不少使用者來說，連接到網站的反應時間及傳輸速率，是他主觀判斷網路品質良莠與否的重要依據。對一般使用者來說，如果能快速的連接上網站，並傳回畫面，會直覺認為所在區域的網路品質相當不錯；但是，相反的，如果打開瀏覽器後，首頁畫面遲遲無法出現，會直覺認為該區域的網路品質不佳。因此，在本論文中，我們將發展一個自動化量測系統，量測使用者從連線到目的網站至首頁完全呈現所需的時間，作為評估網路品質的基準。這個以 WWW 應用為基礎的網路品質自動化量測系統，量測使用者從連接網站至首頁完全呈現所需的時間，係依照下列步驟進行： (1) 連線到目標網站並將網站的首頁取回 (2) 分析首頁並找出呈現首頁所需的其他元件 (3) 連線到其他元件所在的位置並取回 (4) 計算全程所需時間及其他資訊在連線到目標網站取回首頁的過程，有些網站並不是直接送出首頁網頁的內容，即傳回如 index.html般的檔案內容，而是傳回轉向(Redirection) 狀態碼，如：302 Found，此時量測系統必須重新發出連線請求到新的 URL(Uniform Resource Locator)，方能找到目標網站的首頁內容。因此，網頁量測系統必須能正確解讀 HTTP 的狀態碼，並加以因應處理。在分析網站首頁方面，要得知首頁的完成呈現總共包含哪些元件，則需要具備分析 HTML 的能力。就單純的 HTML 網頁來說，配合 HTML TAG 的意涵，可以很快的找出其他組成元件，如：<IMG SRC=URL>，並到所指定的 URL，去將元件資料取回。但隨著網頁生動活潑的趨勢，有不少的首頁設計，加入了描述語言(script)，如：Java Script，來產生更好的互動效果。因此，分析程式必須能解析這些 script 並加以判斷哪些是第一次首頁呈現時必須擷取的內容。此外，還有些網頁會嵌入其他多媒體的呈現，如：背景音樂、Flash 等，而這些多媒體資料的傳遞方式，也會影響首頁呈現的感受。當量測程式連線到其他元件所在位置，取回這些元件時，這些元件所在的位置可能不同於原來的網站，可能可以順利取回，也可能遭遇不確定因素的延遲，或者元件不存在。因此，量測系統必須加入適當的時限處理，以避免量測系統產生不必要的等候。在取回所有組成元件或達到傳輸時限後，即可計算整體連線所花費的時間。因電腦網路的速度相當快，因此，量測系統至少需要能做到千分之一秒 (ms)的精確度，方能反應出與其他量測方法的顯著差異。除此之外，連線的進行方式，如：循序連線，或同步連線，也會影響整體的連線時間。例如：在取回首頁的內容後，透過網頁分析，可以得知尚有哪些元件必須取回，此時，如採取同時發動連線到全部元件所在位置，取回全部的元件，所需的時間會最短，但同時間會產生的連線數也會達到最高。但這樣的作法，可能會被資訊安全防護設備誤判為一種阻斷服務攻擊(Denial of Service Attack)。在 RFC2616 [1]中就建議同時間連線到一個網站或代理伺服器(proxy)的連線數不宜超過兩個，此外，在使用者常用瀏覽器上，如：Microsoft Internet Explore [3]，也有加入這樣的限制。因此，量測系統在設計時，應審慎考慮同時連線的數目，以期更能切合實際的連線感受。

為方便快速完成自動化量測系統的建置，我們選擇了常用的 CentOS Linux v4.3 作業平台，以 perl v5.8.5 為發展語言，利用 libwww-perl v5.79 及 Time-HiRes v1.55模組，發展了一個符合要求的自動化量測系統-簡易網站品質量測系統(Simple Web Traffic Meter, SWTM)。這個量測系統，會連線到所指定的網站，判讀 HTTP 的狀態碼，並取回首頁(例如：index.html)，並自動分析網頁的內容，計算出尚須取回的元件數，之後，逐一循序將所需元件取回，並記載整個過程所需的時間，連線次數，各元件的大小及整體的傳輸量，以作為評估使用者連線到該網站時，可能感受到網路品質的概況，其系統流程架構如圖 2所示。圖圖圖 圖 2 SWTM 系統流程圖系統流程圖系統流程圖系統流程圖

(4)

4. 量測

量測

量測結果與討論

量測

結果與討論

為充分比較並呈現不同的量測方法其所能獲取資訊的差異性，我們依照網站屬性及網站所在位置的不同，隨機挑選幾個網站，做為觀察量測的標的網站。在量測方法上，我們比較了網路管理者最常用的頻寬使用率，封包傳輸速率，ping，HTTP ping，及我們所發展的應用層量測 (Simple Web Traffic Meter)。進行量測時，除頻寬使用率及封包傳輸速率是從連線設備取得相關資訊外，每個方法都是以 10 分鐘間隔，對量測標的網站進行量測，並將量測結果加以記錄。最後，為方便比較觀察量測的結果，我們將各種量測方法的量測結果統一以 MRTG圖形來加以呈現。此外，為便於觀察具體而為的變化，我們將以一天的量測結果做為討論的依據。

4.1 量測方法

量測方法

量測方法的差異性

的差異性

首先我們觀察網站所在位置對量測所產生的影響。圖圖圖圖 3是量測進行時間，量測系統所在位置的 網路頻寬使用率。圖圖圖 4、圖圖圖圖圖 5、圖圖圖圖 6分別是我們從 國立清華大學分別以 ping、HTTP ping，以及我們發展的 SWTM 對國立中山大學的網站 (www.nsysu.edu.tw)進行量測結果。從圖圖圖圖 3的結果中 可以發現，量測所在的網路分別在前一天的 18 時到當天的凌晨 1 時及當天 14-15 時有較大的流量，但從圖圖圖 4可以發現，以 ping 對遠端網站進行量測並圖沒有相同的波動曲線，顯示頻寬的使用率未達頻寬飽和狀態時，並不能有效反應封包送至遠端的反應速率。接下來比較 ping 與 HTTP ping 的量測結果，我們發現兩者的量測有著比較接近的結果，這是因為當網站正常運作時，ping 是 ICMP 的來回時間，而 HTTP ping則是一個 TCP session 的來回時間，兩者在網路上的傳輸時間會是構成量測數據的主要因子。對於某些關閉 ICMP 回應的網站來說，例如：國立中興大學網站(www.nchu.edu.tw)，ping 無法獲得有效數據，此時 HTTP ping 將是一個相當有效的遠端網站連線量測方法。最後我們以所發展的 SWTM 來模擬使用這在這段時間，連線到國立中山大學網站，可能得到的反應速率。從圖圖圖 6我們可以發現，首頁的取回反應圖速率在 9 到 17 時有明顯變慢的情況，原本使用者可以在 1 秒內看到首頁的全貌，在那段時間，使用者必須等待約 4 秒鐘，才能看到首頁的全貌，以進行接下來的操作。會造成這樣的差異可能在於國立中山大學的首頁約有 10 個以上物件所組成，而這些物件必須全部取得後方能構成完整的首頁全貌，在全部物件取得的過程中，若部分物件取得反應較慢，則整體網頁取得的時間也會因而延遲，而這也是造成 HTTP ping 和 SWTM 量測結果差異的最大因素。從這些結果中，我們不然發現，當首頁的構成物件數較多或較複雜時，HTTP ping 僅能反應網站回應單一 HTML 檔的時間，但卻不能有效反應出，使用者在連線該網站時，可能的反應情況，而這也是我們發展 SWTM 的主要動機和考量—如何建構一個能更忠實反應使用狀況的網路品質量測系統。圖圖圖 圖 3 網路頻寬使用率網路頻寬使用率網路頻寬使用率(bandwidth) 網路頻寬使用率圖圖圖 圖 4 NSYSU ping 反應時間反應時間反應時間 (ms) 反應時間圖圖圖 圖 5 NSYSU HTTP ping 反應時間反應時間反應時間 (ms) 反應時間圖圖圖 圖 6 NSYSU SWTM 反應時間反應時間反應時間反應時間 (ms)

4.2 網站屬性的差異性

網站屬性的差異性

網站首頁的特性，例如：含有較多的圖形物件，也會對量測結果產生不同的影響。圖圖圖 7、圖圖圖圖圖 8、 圖圖圖 圖 9是同一量測時段對 Yahoo! TW(tw.yahoo.com) 進行 ping、HTTP ping 和 SWTM 的量測結果。如同先前的觀測結果，Yahoo!在 ping 和 HTTP ping 上反應時間接近，狀態也接近。但在 SWTM 的量測上，其反應時間卻和 HTTP ping 的結果有著極大的差距。以圖圖圖圖 8來說，單一一個 HTTP session 約莫 300ms 就可獲致回應，但在 SWTM 中，卻需要約 5000ms 方能取回所有構成首頁的物件。這是因為 Yahoo! 的首頁有 10 個以上的物件構成，且其實際物件的傳輸速率約莫 30KB/s，但需要傳送約 169KB 的首頁資料量，因此產生近 5 秒的量測結果。從這個結果可以得知，以網頁的實際構成來說，HTTP ping 所取得的，應為構成首頁主架構的 HTML檔，例如：index.html，其檔案實際大小往往並不大，但是當首頁中存在其他圖形時，要完整呈現首頁的內容，則需把這些置放在首頁中的圖形取

(5)

回，這些圖形大小往往比 HTML 檔更大，且一旦數量較多時，所需花費的時間也將更多，此時，HTTP ping 所得到的結果將和 SWTM 所量測的結果有著更大的差異。因此，相對於 ping 或 HTTP ping 來說， SWTM 是一個更能反應實際使用狀況的一個網路品質量測系統。圖圖圖 圖 7 Yahoo! ping 反應時間反應時間反應時間反應時間 (ms) 圖圖圖 圖 8 Yahoo! HTTP ping 反應時間反應時間反應時間反應時間 (ms) 圖圖圖 圖 9 Yahoo! SWTM 反應反應反應反應時間時間時間時間 (ms)

4.3 其他量測問題

其他量測問題

隨著網路安全問題日益受到重視，在我們實際量測的過程中，也明顯感受到網路安全防護設備對網路品質量測的影響。在我們隨機選擇的網站中，有幾個網站是不回應 ICMP echo request 的，也因此當我們使用 ping 來量測這些網站時，是無法得到有效數據的。圖圖圖 10是量測期間，以 ping 對國立中興圖大學(www.nchu.edu.tw)的量測結果，結果顯示，該校的網站對 ICMP 是不做回應的。圖圖圖圖 11是同時間對 該校網站以 SWTM 進行量測所得到的結果，該結果顯示，在大部分情況下，獲取該校首頁所需的時間平均約 0.3 秒，對大多數使用者來說，應是可接受的。圖圖圖 圖 10 NCHU ping 反應時間反應時間反應時間反應時間圖圖圖 圖 11 NCHU SWTM 反應時間反應時間反應時間反應時間 (ms) 此外，為強化網站對阻絕式攻擊的防護能力，更有些網站(如：Google)，加裝了應用層的網路安全防護設備，當量測系統定期發送量測連線到這些網站時，這些防護系統可能會將量測系統所發送的連線視為不友善的連線，進而將量測系統所在的伺服器列入黑名單，拒絕所有來自量測系統的連線，如此一來，量測系統將無法有效取得數據。因此，如何適當的設定量測頻率，以避免被網路安全防護系統視為不當連線，是系統實際運作時必須審慎考量的問題。

5. 結論

結論

在這篇論文中，我們提出了一個以應用層為基礎的網路品質量測觀念，並實作了一個以 HTTP 量測網站首頁的網路品質量測系統(SWTM)。透過這個應用層網路品質系統，對照傳統的網路品質量測機制，如線路的頻寬使用率，線路的封包速率，ICMP 的量測，以及陸續被採用的 HTTP ping，我們發現，透過應用層的量測，實際模擬使用者的使用狀況，可讓網路管理者更能有效的掌握使用者的感受，並針對網路的即時狀況發佈訊息或採取應變措施，將網路維運工作，從單純的區域設備維護機能，進而提升到整體網路服務提供的地位。隨著網路安全日益受到重視，近來網路層的網路量測，如 ping 和 traceroute 等，逐漸受網路安全防護設備的阻絕，而無法穿透或送達遠端的量測點，如此一來，既有的自動化網路量測系統，將無法獲得有效的數據，網路管理者將很難了解整體的網路連線概況。此時，以應用層為基礎的量測系統，因其所使用的量測基準，正是遠端伺服器所提供的公開性服務，因此在網路安全設備的防護下，仍能為網路管理者帶來有效的網路量測資訊。未來，更多的網際網路應用將扮演更重要的角色，如網路電話，隨選視訊，遠距學習，視訊會議等，單純的網路設備或線路量測，或者是網路層的量測，可能無法滿足使用者對網路品質的期待。如何能發展更多更準確的網路應用層網路品質量測系統，以充分反應網路的使用狀況，將是網路管理者必須正視與面對的重要課題。

(6)

參考文獻

[1] R. Fielding, etc., "Hypertext Transfer Protocol -

HTTP/1.1," RFC 2616

(http://www.faqs.org/rfcs/rfc2616.html), 1999. [2] Jef Poskanzer, "http_ping - measure HTTP

latency,"

http://www.acme.com/software/http_ping/. [3] Microsoft, "WinInet limits connections per server,"

http://support.microsoft.com/kb/183110, 2006. [4] Tobi Oetiker, "The Multi Router Traffic Grapher,"

http://oss.oetiker.ch/mrtg/.

[5] J. Postel, "Internet Control Message Protocol," RFC 792, http://www.faqs.org/rfcs/rfc792.html, 1981.

[6] R. Presuhn, "Management Information Base (MIB) for the Simple Network Management Protocol

(SNMP)," RFC 3418,

以應用層為基礎之網路品質量測