台灣學術網路出國線路壅塞狀況之分析研究




劉大川 、 張傑生、楊子翔

國立交通大學計算機中心
新竹市大學路 1001 號
TEL:(03) 5712121 EXT.31905
EMAIL: ltc@news.cc.nctu.edu.tw, {jason,robe}@proxy.nctu.edu.tw






摘要

自從 1996 年五月,台灣學術網路出國專線擴充為兩條 T1 迄今,根據 TWNIC 與資策會的統計資料,台灣地區網路人口由一百萬人成長至兩百一十七萬人,成長數量超過一倍,而網路主機則由 48013 台成長為 63340 台,亦成長了百分之二十。在教育部的大力推廣之下,各級高中小學連上學術網路的數目亦大幅成長。然而,連續兩年沒有增加的出國線路,要應付如此龐大的使用人數,相形之下,顯得力不從心。

事實上,台灣學術網路出國線路壅塞的問題由來已久,在僧多粥少的情況下,無法人人滿足是必然的結果。問題是,當最基本的電子郵件通信都失效的情況發生時,是該重新檢視頻寬使用狀況,進而針對不適當的頻寬使用加以改善。

本篇文章觀察 1998 年六月第一個星期的台灣學術網路出國線路流量資料,並且嘗試從中找尋問題,並提出改善建議。

 

 

一、序論

近年來,隨著網際網路的風行,網路人口日益增多,網路頻寬使用量亦相對地提升,再加上大量使用 WWW 圖形化介面,以及各種影音聲光多媒體,這些龐大資料量的應用,造成早已拮据的網路頻寬雪上加霜。

增加硬體線路是解決頻寬問題最直接的方法,然而,現實的經濟問題卻不允許這種解決方式。既然開源不可得,則節流是唯一解決之道。透過流量內容的統計分析,檢查是否有不當之應用存在,或是缺乏效率的頻寬濫用,再藉由進一步的管制措施,限制某些應用的 傳輸,以確保其他應用的正常傳遞,是目前網際網路上對於頻寬問題的常見作法。

本篇文章將以台灣學術網路之出國頻寬使用作為研究對象,並根據量測得到的頻寬使用資料加以分析,探討台灣學術網路出國部分的使用型態,進而討論目前的頻寬問題以及提出合理的解決之道。


 

二、台灣學術網路出國狀況描述

 

 

2.1 環境

 

目前台灣學術網路對國外部分有兩條 T1(1.544Mbps)線路,由教育部電算中心向外連結,大部分的區網中心則透過 T3(45Mbps) 線路與教育部電算中心相連結。在此種頻寬比例懸殊的狀況下,再加上許多熱門資訊的來源都位於國外,例如搜尋引擎與軟體公司的網站等,造成大部分的使用者習慣向國外網站讀取資料,國際線路壅塞,乃意料中事。

圖一、台灣學術網路出國線路示意圖

 


2.2 狀況

由台灣學術網路對國外網站以 ping (icmp) 測試,封包遺失率高達 30-50%,在這種情況下,幾乎所有交談式(interactive)的應用都無法正常運作,最明顯的例子就是 telnet。至於 WWW 瀏覽亦是斷斷續續走走停停,出現 request timeout 的錯誤訊息更是家常便飯,根本也可以算是幾近停擺。然而,一直到連基本需求 -- 電子郵件的收送都無法正常運作時,使用者的不滿情緒已經提昇到最高點。


2.3 網路流量

如此網路品質,絕對無法令人接受。然而,根據路由器上取得的 SNMP 流量資訊,顯示由國外傳入部份全日幾近 97% 滿載[圖二、圖三]。而傳輸錯誤率極低(Input/Output error 與 CRC error),完全可以忽略不計,這些數據充份顯示實體線路品質良好,資料傳輸正常。

現在的問題在於,到底這些寶貴的頻寬被如何使用,尤其是當大多數人都無法享用的情況下。

 

Input: Internet -> TANet , Output: TANet -> Internet

Input Max 1511.8 kb/s 97.9% Avr 1499.2 kb/s 97.1%
Output Max 1422.5 kb/s 92.1% Avr 907.2 kb/s 58.8%

圖二、1998 6/5-6/6 兩日的SNMP ifInOctects 與 ifOutOctects 流量圖

Input: Internet -> TANet , Output: TANet -> Internet

Input Max 1510.0 kb/s 97.8% Avr 1499.3 kb/s 97.1%
Output Max 1431.6 kb/s 92.7% Avr 955.3 kb/s 61.9%

圖三、 1998 5/25-6/7 兩週的SNMP ifInOctects 與 ifOutOctects 流量圖

 

2.4 應變措施

為了電子郵件這種基本應用的暢通,教育部電算中心於每天清晨 0400-0600 這段時間,
禁止 WWW 應用的流通,希望降低整體頻寬使用量,以換取其它應用的通行。成效顯然不差,
至少使用者抱怨電子郵件不通的情況大為降低。

 

三、流量量測分析架構

3.1 傳統的流量量測方式 -- surveillance based

在以往的網路環境下,流量的量測分析都是透過乙太網路的監聽程式(sniffer, nnstat, tcpdump),利用乙太網路廣播(broadcast)的特性,於相同的子網路上架設工作站,即可監聽每一個傳遞的封包,隨後做進一步的處理分析[圖四]。

圖四、傳統的 Ethernet 流量統計

 

然而, 在現今網路架構下, 這種網路監測方式, 受到許多侷限。
  • 計算能力與資料處理.
    在以前 ethernet 10Mbps 的環境下, 超過 40% 滿載的網路流量,就已經超過一般電腦所能夠負荷的計算量[1993]. 雖然現在處理器的效能 號稱每十八個月倍增一次,但是 ethernet 相對地進步到 100Mbps 的 fast ethernet 甚至 1Gbps 的Gigabit ethernet. 到底現在電腦的計算能力是否得以勝任高速網路巨額資料?
  • 網路卡接收能力
    要監測網路流量,網路卡必須啟動 promiscuous 模式,然而一旦無限制接收封包,首先面臨的就是卡上面的 buffer 與系統 bus 是否可以順利接受大量湧入的封包資料. 根據一般的使用經驗, 以 tcpdump 為例, 在網路負載超過 40% 的情況下, 開始有 1% 的 packet loss 情況[1993].
  • 無法運作於 Switching Device 的環境下
    現在的網路架構,傾向設置 switching device,以有效舒緩 collision 的困擾。然而,在此一環境一下,sniffer 也將失去作用,因為無法完全接收所有網路上的流量封包。雖然某些 switching device 有提供所謂的 monitor port,不過畢竟是少數特例。
  • 只適合運作於區域網路的環境
    由於監測系統乃是利用完全監聽的概念,所以在 ethernet broadcast based 的環境之下,如魚得水。但是以廣域網路的專線模式,通常都是採用 ATM、HDLC、PPP 等 protocol,一般說來,sniffer 無從下手。(以 ATM 來說,的確是可以利用 fiber splitter 的方式,duplicate 所有流量資訊,方便 sniffer 作流量分析,但是設備不易取得,價格昂貴)

 

3.2 傳統的流量量測方式 -- SNMP/MIB based

這是最被廣為採用的網路管理標準,而且幾乎所有重要的網路設備都支援此一標準,並且直接於硬體提供 MIB 資料庫,提供 client 端以 SNMP 的方式取用。其運作方式類似於圖四之架構,由網路管理工作站,定時向網路上的其它設備(router, switch)取得 MIB 資訊,並作進一步的分析統計。

然而,雖然普遍支援,廣為採用,對於網路管理來說,依舊有許多不便之處。

  • 只提供既有定義的數值資料
    MIB 資料庫中的資訊,並沒有完全符合我們需要的詳細資料,一般說來,定義的資訊包括:In/Out octect rate, packet rate, error rate。當我們需要更為細部的流量資訊,例如, protocol based, application based,則愛莫能助。
  • 提供的資訊乃是以網路介面為基礎
    對於 router/switch 而言,他們所提供的 In/Out octect rate 等資訊,都是以其 interface 為基礎,也就是接在某一個介面之下的總流量。如果我們想要對各個子網路,或者是某些特定機器作統計,除非個別分配獨立的網路介面,否則無法量測。

3.3 目前所使用的流量量測方式

然而為了因應遠距教學實驗計畫,自 1997 年起,台灣學術網路的骨幹部分,已改走 ATM 協定,由於 layer 2 協定改變,傳統的監聽量測方式,無法繼續使用。

新一代的網路廠商,包括 Cisco 與 Baynetworks,都在他們的高階產品上支援 proprietary 的網路流量監測系統。以 Cisco 為例,在他們發展的 Netflow 系統中,除了增進系統效能的 caching 與 switching 等功能,另外包含了將網路流量資訊,輸出到網管工作站,由特定的程式做後續的分析統計工作[圖五]。

圖五、目前所使用的流量統計方式

 

這種作法的明顯缺點,就是毫無標準可言,各家產品林立,互不相容,後續網管所需的軟體,必須向原廠購買,無法得到 3rd party 的支援。

然而,以 Cisco 的 Netflow 而言,由於其輸出的 data format 有公開,使得自行發展分析軟體成為可行之路。再者,由 Netflow 所送出的資訊,乃是經過整理的“再造資訊”,並非完整的封包內容,所以資料量比起原先的 raw data,少了許多。根據測試,至少是在網路卡與處理器所可以接受的範圍。

優點:

  • Data Integrity (useful information preserved)
  • Data Compaction (total size reduced dramatically)

如此一來,需要的資訊完整留下,並且經過壓縮整理,資料減量,則不必要的 CPU 計算浪費與傳輸頻寬浪費都可避免。

本研究將針對 Cisco 的 Netflow 機制,實作一套完整的網路監測系統,資訊的詳細度將以傳統的 surveillance based 系統為準,並且加入各項所需的量測 metrics. [7]

 

3.4 Cisco Netflow

現今網際網路聯結錯綜複雜,routing 資訊更動頻繁,router 花費在接收新的routing 資訊,更新 routing table 的處理時間可觀,routing table 的內容龐大複雜。根據分析,router 在處理 packet routing 的時候,負擔最重的工作,便是 routing table 的查詢比對。許多研究朝向改善 table 查詢的演算法,希望能夠降低查表時間。

Cisco 這家公司 router 的 Netflow 功能[6],則是利用鄰近封包大多前往相同的目的地之 locality 特性,再加上 cache 的概念,定義了 flow 的觀念。

flow: 相同來源 IP/port 到相同目的 IP/port 的單向封包序列(unidirectional packet sequence)

可細分為以下三種 flows:

當一串 TCP 封包序列出現 FIN(finish) 或者是 RST (reset)之時,便自動結束此 flow

由上述定義可知,flow 的觀念已經超越 layer 3(IP layer)而直達 layer 4(transport layer)。雖然 router 處理到越高層次的封包內容,所需的時間更長,然而,為了可以做更進一步的 access control 以及統計分析,再加上近年來硬體計算能力大幅提升,這種作法反而較容易受到大家的接受。

而 flow 對於 router 效能最大的影響,則是同一 flow 中的所有封包,只有第一個才需要做複雜的 routing table lookup,其他的則直接享受 cache 的便利,對於 access control 亦然,一旦 access-list table lookup 做完一次,其他的封包一樣比照辦理。如此一來,最為耗費處理能力的 table lookup 工作量大為減輕,整體效能自然提升。最後,所有統計資訊也是等到 flow 結束才一次 update,相異於以往的 per packet update,連統計工作都簡單不少。

 

四、分析與討論

我們對於 1998 5/31-6/6 這一週量測統計所產生的結果,置於第七章附錄。(其中表一到表四並非完整列表,只有列出統計資料中的前幾名)

4.1 以流量組成內容為觀點

4.1.1 分析

根據表一、表二,TCP 佔了絕大多數的 byte 流量(85%),其組成內容大部分為 WWW、NNTP、FTP、SMTP,與一般常理所推斷符合,表示出國頻寬大部分還是被利用於預期的應用之上。

而在 packet 部分,TCP 佔了六成多,而 UDP 佔了三成多。根據之前所提到 router 處理是以封包為單位,雖然 UDP 的 byte 流量才一成多,但是 router 花費在處理封包查表、傳遞的時間, UDP 卻竄升至三成多。

再看到 flow 數目,則 TCP 與 UDP 已經相差無多,這個可以參照表中 packets/flow 的欄位。TCP 流量大部分都是所謂的 long term flows,每一 flow 通常會由較多的封包數量組成。而 UDP 則為 short term flows,明顯的應用則是 DNS lookup、NTP(網路對時)等等,一般來說,一兩個封包即可完成查詢。

更詳細的流量資料可以參閱表三、表四,這兩張表列出幾個主要應用的傳輸統計,我們可以很容易地看出,WWW 號稱 Internet Killer 當之無愧,超過五成的頻寬使用都用於 WWW 傳輸之上(57%-62%),而民生必需的 Email 與 DNS 各佔總量的 8%-9%。

相同地,分析 packet 比例,雖然 WWW 還是一枝獨秀(41%),然而 DNS 卻急起直追,16%-17% 的比例,並不容忽視。而 flow 的部分,DNS 更是佔了 25%,總量的四分之一。由於每一 flow 所佔有的 packet 數與 byte 數較高,WWW 僅佔總 flow 數的 38%。

4.1.2 討論

如何才能夠將既有的稀少資源做合理分配,這是我們目前最為關心的問題,台灣學術網路的出國頻寬即為此例。

根據統計資料,在 flow、packet、byte 這三種主要量測項目中,以 WWW、DNS、SMTP、FTP、NNTP 為主要構成單元。討論這幾種應用,除了 Email 必需是一對一傳遞,幾乎是無法節省頻寬之外,其他的應用,都已經存在節省頻寬的有效方法。NNTP(Usenet)大概是最為成功的例子,人們早已習慣就近使用 local 的 news server 讀取網路新聞,除了反應迅速之外,大家也都明白,同樣一篇討論文章,並不會因為傳遞過程遙遠而扭曲內容,以目前的 Usenet 傳遞狀況,由國外傳入的網路新聞,都是統一由教育部 news server 接收,之後轉送全國各地,如此一來,對於出國頻寬的使用,顯得極為節省有效率。行之有年的 FTP 亦然,網路上流行的 mirror site,便是將國外著名的 ftp site 完全相同地儲存一份在 local 硬碟,以方便國內使用者抓取資料。

相同於 FTP、NNTP 的資料內容不變性、一致性,DNS 與 WWW 也有相同特性,一份 IP <-> FQDN 的資訊或是一頁 homepage(CGI 部分除外),無論傳遞路徑多遙遠、複雜,也不會更動其內容。然而,根據我們所做的統計顯示,大部分的 WWW、DNS request,還是由一般使用者所發出。許多國內 DNS server,一天對國外傳輸 DNS 資訊達數十 MB,根據交通大學陳昌盛先生的研究[8]指出,大部分的情況,都是設定錯誤,其中又以 Windows NT 的 server 為最,這些機器會向國外 DNS root servers 做 zone transfer 的動作,上百 MB 的 DNS 資訊取回後,又沒有人可以再利用這些 DNS 資訊,這是完全無意義且無必要的浪費。其他的問題則包括,許多 DNS server 並沒有設定上層 forwarder,也就是每一筆查詢都會直接向國外要求,這樣便無法利用到國內既存的 cache 資料。

而 WWW 的資料再利用,則是透過 proxy cache server,觀念亦同於 DNS cache serrver,凡是查詢過的資料,必會在 local 硬碟留存一份,以供後來的使用者查詢。由於 WWW 的風行是這幾年的事情,使用 proxy cache server 的觀念並未深入一般使用者的腦海,再加上,proxy cache server 的建置數量不足與設定錯誤,造成使用者不願使用。種種前因,使得目前出國線路被 WWW 所佔滿,其他應用動彈不得。

由於線路費率是依照頻寬大小收費,如何能夠降低不必要的頻寬浪費,將寶貴的頻寬資源有效利用,這才是公平且合理的作法。

在頻寬問題錙銖必較的同時,不可忽略統計數字中關於 flow 與 packet 的部分,router 處理封包的 routing table 查詢與轉送(包括 output buffer queue),都是以 packet 為處理單位,大量的小封包對於 router 來說,比少量的大封包更為負擔沈重,是故,減少封包數目,可以有效提升 router 處理效率與反應時間,對於許多忙碌的 backbone routers 這絕對有正面的影響。

目前 TANet 骨幹 router 都是使用 Cisco 7 系列,這些 router 在處理封包時,為了 routing table cache 考量與資料統計方便,是以 flow 為單位,觀察 TANet 出國 router,flow 數目幾乎隨時滿載,也就是 flow expiration 的動作隨時在進行,這樣子的結果,就跟 OS 的 thrashing 相同,當 memory 不足,開始大量 swap 的時候,系統的整體效能將會降至最低,甚至 crash。

所以,減少網路上不必要的傳輸,同時設法降低 flow、packet 數,才是恢復網路品質的解決之道。

4.1.3 建議

如同之前所討論,WWW、DNS、FTP、NNTP 等應用,都可以提出有效的頻寬節省方法,目前 NNTP 的 news server 與 FTP 的 mirror 都已存在,並且發揮顯著的效用,勢必繼續維持。

DNS 部分,則應該建立 cache hierarchy 的階層觀念,各區域學校將 forwarder 設定於該區網中心,而各區網中心則將 cache miss 部分送往教育部主機,教育部 cache miss 的部分則出國查詢。如此一來,除了大量減少出國流量的 packet 與 flow 數目,降低 router 負擔,end user 更可以直接享受 cache 所帶來的好處,更有效率的查詢,更快速的回應。

WWW 部分與 DNS 幾乎完全相同,階層式的 cache hierarchy 必需建立,目前機器硬體價格下滑,記憶體、硬碟等設備,比起頻寬費用,簡直九牛一毛。根據交通大學計算機中心的實驗,兩部 32GB 硬碟的 server,每天下傳約 25 GB 的資料,cache hit 達 50% 以上,頻寬節省一半。建置費用四十萬元的機器,比起數千萬的出國頻寬,絕對值得各大區網中心做此投資。

最重要的是,頻寬統計資料必需持續追蹤觀察,一旦發現頻寬濫用、誤用的情況,才能即時處理。

 

4.2 以流量時間分佈為觀點

4.2.1 現象

觀察圖二、圖三的 SNMP ifInOctects 與 ifOutOctects 的資料,顯示在 layer 2(data link layer)的傳輸上,進入 TANet 的部分全天候滿載,而奇怪的是,TANet 出國的部分,卻是每天清晨都有一個 pulse。而這個 pulse 的大小,卻幾乎可以衝到 98% 的頻寬使用。

再觀察 layer 3 的傳輸總量,由圖六與圖七,我們會發現每天清晨 0400-0800 為大量資料進出 TANet 的尖峰,奇怪的是,除了下午兩點前後有一小小 pulse 之外,全日的傳輸量竟然不及凌晨的那段。

而圖八、圖九則為 Email 的傳輸分佈圖,相似於每日傳輸總量,Email 的傳輸尖峰也在每日清晨 0400-0800,難怪大家常常抱怨,每天上班就有一堆 Email 要處理。事實上,FTP、NNTP 的每日傳輸狀況,與 Email 完全相同。

4.2.2 討論

事後發現,教育部為了解決 Email 收發的問題,每天凌晨 0400-0600 由 router 阻擋所有的 Internet -> TANet WWW 流量(單向管制,准出不准入)[圖十二][圖十三]。而根據進一步的觀察,每日清晨四點那一剎那,由於將所有的 WWW 封包完全自 router 清除,router 的 flow table entries 數目降至原來的 30%,表示原來 router 之內,大概有 70% 的 queue,都是屬於 WWW 應用。

再更進一步地檢視每天 0400-0600 與 1400-1600 這兩段期間的傳輸,我們發現:

1400-1600 的 flows 大多由許多 timeout 的 flow 的組成,都是少數封包,並且沒有 ACK 於其中,或者有些 flow ,根本只有一個 ACK 封包在裡面。

0400-0600 的 flows 明顯每一 flow 所擁有的封包數大量增加,並且幾乎所有 flow 都有 ACK。而整體的 flow duration 持續傳送時間,亦大幅增加。

由於 TCP 為 connection oriented 的傳輸,需要 ACK(acknowledge packet)的存在讓收送雙方溝通狀態,如果超過某一 timeout 未收到 ACK,則會有重新傳送的動作,更長的 timeout 就會直接視為 lost 並且斷線。TANet 平時的出國狀態,正是屬於過度壅塞的線路,其嚴重程度,連 ACK 封包都無法如期收送:

因此 sender 只好重複 retransmit 更多更大量的封包,然而這些封包繼續在線路上、在 router 中排隊等候傳遞,等到真正到達 receiver 的手上時,早已超過 timeout 時間,這些封包根本就被直接 drop。於是線路上、router 中就越來越多無用的垃圾,但是我們仍必需花費頻寬、router 處理時間,來傳送這些垃圾。

receiver 亦然,當送出 ACK 封包後,並沒有繼續收到 sender 傳來的資料,以為是 ACK lost,於是重複送出 ACK 封包,直到 timeout。

根據美國 MCI backbone 的量測,所有在 MCI 網路上傳送的封包中,大約 40% 為 40bytes 大小的封包,而這些所謂的 40-byte 封包大多都是 ACK [10][11]。再相對於 TANet 的例子,則可發現我們的 ACK 封包所佔的比率過低。

雖然國際線路由 SNMP 資訊看來,是單向滿載(Internet -> TANet)的情況,但是一旦 ACK 封包無法順利傳遞,則直接影響另一方向(TANet -> Internet)的傳輸。也就代表連國內對外的 TCP 傳輸,亦無法送出。觀察圖六、圖七,以及圖十二、圖十三送出國外的部分,一旦瓶頸解除,ACK 封包可以正常進出,則由 TANet 送到 Internet 的資料量亦是滿載(T1 頻寬),以往我們觀察 SNMP 資訊,總是認為我們 TANet 是典型的 "消費者",大部分的頻寬應用,都是向國外取資料,然而,現在根據 IP level (layer 3,4)的流量資訊,我們發現,TANet 送出國的流量,不只是 Email,WWW 佔了更大的部分,表示國內網站亦存有許多國外有興趣的資訊。我們推測,如果網路狀況稍加改善,至少 ACK 封包能夠正常傳遞,則 TANet <-> Internet 的流量比例,應該不是現在看到的 60% vs. 97% (SNMP layer2),或許可以拉近到 1:1 的程度。

 

4.3 討論 Email 收發不正常的問題

TANet Email 無法送出國外的原因正如 4.2 節所提。由於 ACK 封包無法順利及時由國外傳入,導致 Email(TCP 應用)傳輸持續 timeout,封包無法繼續送出國外。

但是為何 WWW 在此種網路環境下卻能夠獨佔 60% 的頻寬呢?根據觀察,當 browser 瀏覽 homepage 時,對於 homepage 中的各個物件(聲音、圖片)是同時發出不同的 request,也就是說瀏覽一頁 homepage 時,可能是同時有四五個 flow 在 router 中排隊。如果 router 處理每一 packet、flow 的機率是相同的,那麼 WWW request 獲得傳送的機率顯然大得多。而且,由於將 homepage 物件分成不同的小量 request,每一個 flow 所需傳輸的資料量較少,也就是封包數量少,那麼因為 packet loss 或是等不到 ACK 封包而造成 flow timeout 的機率也明顯地變低,所以有效的傳輸量自然大為增加。

相對於 WWW,一般 NNTP、FTP 傳遞方式,都是 single long term flow,也就是每次只發出一個 connection request,當然這個唯一的 flow 封包數目與傳輸總量都會非常的大,然而,在此種過度壅塞的網路環境下,由於 packet loss 的機率非常高,ACK 封包無法如期取得的機率亦高,造成 NNTP、FTP flows 非常容易中斷,進而無法於這種網路下生存。

同樣的道理,亦可以解釋為何一般簡短的 Email 收送尚可接受,但是遇到有 attach file 的大型 Email ,卻常常遭受退信,無法傳遞。

 

五、結論

真實世界中,高速公路的塞車問題,隨處可見,單方向的嚴重堵塞,造成的交通中斷不過是單方向,另一方向依舊能夠順暢通行。然而,由於通訊協定(protocol)的特性,在網路的世界中,雙方向的交通流量,卻是彼此互相牽制,攸關相戚。根據本篇文章的觀察 結果,如何維持網路的品質,隨時保持最大的頻寬利用率,即是避免發生任一方向的堵塞。

此外,根據我們所做的流量分析,大部分的網路資源(包括頻寬與 router 處理能力)都是少部分的應用所獨佔,其中包括了 WWW、DNS、SMTP、FTP、NNTP,而這其中的大部分,都可利用 cache 的方式達成頻寬再利用。因此,促成各種 cache server 的建置,對於頻寬的再利用,提高頻寬有效使用率都有正面的幫助。

未來則可以考慮以頻寬分割的方式,將重要的 DNS、NNTP、FTP、WWW cache server 放置於預先保留的頻寬之上,再由這些 server 提供 TANet 使用者服務,以避免因為網路狀況不佳,造成重要服務中斷。

台灣學術網路目前雖然只有出國線路處於過度壅塞的狀況,然而國內骨幹白天亦開始有滿載的現象,頻寬問題之解決刻不容緩,與其等到網路品質惡劣到無法忍受的地步,不如未雨綢繆,及早規劃合理的頻寬使用規範。


六、參考文獻

[1] R.Caceres, P. Danzig, S. Jamin, D. Mitzel, Characteristics of Wide-area TCP/IP Conversations, In Proceedings of ACM SIGCOMM '91, 9 1991
[2] J.Mogul, Observing TCP Dynamics in Real Networks, In Proceedings of ACM SIGCOMM '91, 9 1991
[3] M. Acharya, B. Bhalla, A Flow Model for Computer Traffic Using Real-time Measurements, In Second International Conference on Telecommunications Systems, Modeling and Analysis, March 1994
[4] K. C. Claffy, H. W. Braun, G. C. Polyzos, A Parametrizable Methodology for Internet Traffic Flow Profiling, IEEE JSAC Special Issue on the Global Internet, 1995
[5] Kimberly C. Claffy, Internet Traffic Characterization, PhD thesis, University of Californa, San Diego, 1994

[6] http://www.cisco.com

[7] http://netflow.nctu.edu.tw

[8] http://dnsrd.nctu.edu.tw

[9] http://news-peer.nctu.edu.tw/

[10] http://www.nlanr.net/NA/Learn/mice.html

[11] http://www.nlanr.net/NA/Learn/packetsizes.html

 

七、附錄

Protocol

Flows%

Pkts%

Bytes%

flows/s

pkts/s

kbytes/s

pkts/flow

kbytes/flow

kbytes/pkt

ICMP

5.72 5.28 1.57 4.50 17.34 1.57 3.85 0.35 0.09

TCP

48.93 62.01 85.00 38.49 203.72 84.83 5.29 2.20 0.42

UDP

45.35 32.72 13.43 35.67 107.49 13.41 3.01 0.38 0.12

表一、 1998 5/31-6/6 一週 Internet -> TANet 流量 Protocol 分析

Protocol

Flows%

Pkts%

Bytes%

flows/s

pkts/s

kbytes/s

Pkts/flow

kbytes/flow

kbytes/pkt

ICMP

5.79 5.01 1.42 4.25 17.04 1.47 4.01 0.35 0.09

TCP

49.48 64.58 85.88 36.36 219.77 88.65 6.04 2.44 0.40

UDP

44.73 30.41 12.70 32.87 103.51 13.11 3.15 0.40 0.13

表二、 1998 5/31-6/6 一週 TANet -> Internet 流量 Protocol 分析

Application

port

flows%

pkts%

bytes%

flows/s

pkts/s

kbytes/s

pkts/flow

kbytes/flow

kbytes/pkt

Ftp-data

20

0.34

2.90

6.36

0.27

9.52

6.35

35.49

23.67

0.67

ftp

21

1.21

1.22

0.29

0.95

3.99

0.29

4.19

0.31

0.07

Telnet

23

0.25

0.98

0.20

0.20

3.22

0.20

16.23

1.02

0.06

Smtp

25

5.06

8.71

9.12

3.98

28.61

9.10

7.19

2.29

0.32

Domain

53

25.92

17.85

9.67

20.39

58.65

9.65

2.88

0.47

0.16

Http

80

38.28

41.70

62.62

30.11

137.00

62.50

4.55

2.08

0.46

Nntp

119

0.24

1.85

2.88

0.19

6.07

2.88

31.69

15.03

0.47

表三、 1998 5/31-6/6 一週 Internet -> TANet 流量 Application 分析

Application

port

flows%

pkts%

bytes%

flows/s

pkts/s

kbytes/s

pkts/flow

kbytes/flow

kbytes/pkt

Ftp-data

20

0.41

4.60

10.53

0.30

15.64

10.87

51.78

35.98

0.69

ftp

21

1.24

1.29

0.30

0.91

4.39

0.31

4.81

0.34

0.07

telnet

23

0.25

1.15

0.21

0.18

3.90

0.21

21.53

1.18

0.06

smtp

25

4.64

7.69

8.17

3.41

26.16

8.43

7.68

2.48

0.32

Domain

53

24.65

16.29

8.88

18.11

55.43

9.16

3.06

0.51

0.17

http

80

38.64

41.72

57.39

28.39

141.97

59.25

5.00

2.09

0.42

nntp

119

0.28

2.12

3.22

0.20

7.21

3.32

35.34

16.28

0.46

表四、 1998 5/31-6/6 一週 TANet -> Internet 流量 Application 分析

圖六、 1998 6/3 一日總流量 圖七、 1998 5/31-6/6 一週總流量
圖八、 1998 6/3 一日 SMTP 流量 圖九、 1998 5/31-6/6 一週 SMTP 流量
圖十、 1998 6/3 一日 DNS 流量 圖十一、 1998 5/31-6/6 一週 DNS 流量
圖十二、 1998 6/3 一日 WWW 流量 圖十三、 1998 5/31-6/6 一週 WWW 流量