交大網路測試中心

真實流量測試

  客戶端問題

CFD & CFD對廠商的負面影響

CFD,顧客端發現問題,即為Customer Found Defect,簡稱CFD。廠商面對多樣化及複雜的真實網路世界,產品在顧客端的問題層出不窮,實驗室內部測試時很難模擬,往往造成低階產品容易被退貨或 高階產品打不進市場。CFD對廠商造成的影響將會是因退貨與客訴等造成的龐大成本,以及為解決、釐清問題的煩瑣冗長過程、內部人員必須針對各種可能的排列 組合進行測試與問題重製、On-Site除錯不易等的負面連鎖效應。

降低CFD之道

既然CFD讓公司所付出的代價這麼 大,那麼該如何減少CFD呢 ? NBL從測試的角度出發,思考如何提供一個容易Identify、Reproduce及Debug的真實測試環境,從真實網路流量測試的環境、技術與應用 三方層面來提出解決之道。第一個層面(環境)是最根本的問題,所謂解鈴還需繫鈴人,我們該如何找到一群使用者來使用產品,就像顧客一樣地在日常生活中來使 用產品,對於這樣的一群使用者我們稱之為「Beta Site」,在Beta Site上我們可以將未上市的設備擺上去進行測試,目前NBL與交大計中在交大宿舍網路上建置的Beta Site共有約一千三百位同學的參加,也就是說有一千三百位用戶在測試放在Beta Site上的網路產品,此Beta Site的架構如右圖所示,共有六個測試區(Zone),此環境可以測試的產品包括: End-user software, Ethernet L2/L3 Switch, Wireless AP, Core Router, UTM, IPS, Anti-Virus, QoS Firewall, Network Forensic, Anti-Malware/Botnet, SOHO Router, Home Gateway, Broadband Gateway, DSL Router, IAD Gateway。第二個層面(技術)是在發展錄製與重播真實網路流量的技術,為了要解決有些產品因為某些因素而不適合直接放在Beta Site上面進行測試,這些因素包括流量速度與環境符合度..等等,在錄製流量的技術方面,必須要考慮如何在高速的環境下錄製流量可以沒有遺漏封 包,NBL使用一套專門的硬體與軟體來達到此目的,在重播流量的技術方面NBL使用Open Source工具如: tcpreplay和tomahawk,也使用商業測試工具如: Spirent Avalanche和Karalon Traffic IQ Pro,除此之外也自行開發重播工具如: natreplay和socketreplay。第三個層面(應用)是基於流量錄製與重播的技術,開發相關的應用,目前已開發出兩大應用系統: PCAP Library以及In-Lab Live Test (ILLT)。PCAP Library這套系統即是流量資料庫,可應用來找出可能造成網路安全產品漏判(False Negative)與誤判(False Positive)的網路流量,In-Lab Live Test (ILLT)這套系統可應用於家用閘道器的穩定性測試,檢驗是否有穩定性問題如: 當機、重開機、程式當掉、變慢、容易斷線。

比較Lab Test、Field Test及Replay Test

若將 測試分成實驗室測試(Lab Test)、實地測試(Field Test)以及重播測試(Replay Test)三類的話,我們可以歸納出這三類測試方法的一些特性,其中在設備投資與人力投資的這兩部份的資料是以NBL本身為例來做說明,提供作為公司安排 測試資源時的參考,唯有真正地投入真實網路流量測試,才能降低CFD的發生機率。

  實驗室測試
(Lab Test)

 

實地測試
(Field Test)

 

重播測試
(Replay Test)

 

流量
真實性
低  高 
主要
測試類型
功能、效能、符合、
互通
穩定、相容、準確、
效能 
穩定、準確、效能 
CFD降低之貢獻  低 高 
主要
參與者
 測試人員 研發人員  測試或研發人員,依應用類型而定
設備
投資比例
 100 10  1
人力
投資比例
 50% 25%  25%


  真實流量測試環境

Why do we need Beta Site

產品研發越趨完整時,越需要的測試項目也越趨真實,從最初可能只有幾個功能 可以直接利用Hallway Test、Alpha Test,到最終已經成為一個趨近完整的商品時所需的Beta Test,但是隨著網際網路流量越趨複雜,現有的In-Lab測試已無法完全滿足網路產品測試的需求,往往產品賣到客戶端才發現產品的問題,造成消費者對 產品,甚至是品牌的不信任,最好的方法就是實際上拿到真正的網路環境上做Beta Site Test,讓消費者進行試用,透過真實網路使用行為,觀察產品的問題,一般的Beta Site往往是靠著廠商與各大小單位主管的關係,將產品放置到對應的環境進行測試,測試的內容是不公開的環境,使用者也不見得了解自己處於Beta Site之中,但是別忘了,既然是進行測試,就不保證待測的產品是處於穩定的狀態下,在這樣的Beta Site中,使用者不見得能忍耐不穩定的網路品質,所以產品無法進行長期測試,而且測試的內容單調,規模小也較不具有彈性;因此我們利用交大宿舍網路,精 心設計了一個真實網路流量測試環境供國內外廠商進行各種不同的測試,交大Beta Site(以下簡稱Beta Site)是一個公開的測試環境,可以進行長期、整合型、大規模並且具有彈性的測試,期望能協助廠商解決CFD(Customer Found Defect),提升顧客端對產品以及品牌的認同,同時這樣的環境也能提供學校進行學術研究。

Users

Beta Site的參與者目前為使用宿舍網路的同學,每位宿舍網路的使用者在學期初進行申請時,即可自由地依自己的意願來申請為一般平台或是測試平台(Beta Site),由Beta Site提供多項福利作為吸引同學申請測式平台,Beta Site的同學可以享用較新的網路技術:Gigabit Ethernet(包含Switch及贈送同學Gigabit網路卡),802.11n(包含802.11n AP及贈送同學802.11n網路卡),免費提供下載使用Anti Malware軟體供同學使用,讓電腦在網路上使用更為安全;而Beta Site也組織一支服務團隊,專門用來處理同學無法正常使用網路,或是對各項服務有問題時,可以迅速到各位同學的寢室進行相關的服務;而因應各項廠商所欲 測試的服務,Beta Site也推出使用測試的服務時贈送各位同學200元便利商店禮券,吸引同學加入測試平台。

依據以往經驗(2007-2009),每學年參與Beta Site的同學約為一千三百位。

Environment Overview

 

Degrees of Traffic Volume(流量分級)

廠 商在測試時可能遇到產品雖然放在合適的測試環境了,可是卻發現該區域流量太大,待測產品無法負荷,為此Beta Site針對Zone 4, Zone5及Zone 6都有相對應的流量調整機制,如圖1所示,Zone4是整個Beta Site的出入口,流量是較大的位置,為了分散流量,Beta Site配置有兩個不同型號的Core Router進行流量分散,在此簡稱Router1及Router2,以Router1為主要的交換核心,將部份宿舍的流量導入到Router2上,也就 是說,有部份的宿舍流量是經過Router1直接出去Internet,一部份的宿舍網量是經由Router2 -> Router1出去Internet,如此便可以在Router1及Router2中間建立一個新的In-Line區進行對應的測試,如圖2; Zone5可以採用高效能的過濾器進行流量過濾,流量從Core Router的mirror port出來之後需經過一台Regeneration Tap將所有的流量重新複製到所有的連接埠上,Tap上可以對各個連接埠的流量進行過濾,只將待測物所欲需的流量灌入到待測物中即可,Zon6則是使用軟 體進行Pcap Library播放,所以可以透過軟體的方式,調節ILLT進行播放網路流量的速度,達成對待測物減低流量的任務。

  

  

  

  

  

  

  

  

Traffic Profiling

廠 商在進來測試之前最關心的就是流量有多大?有哪些通訊協定?設備要送測所需開?的通訊協定(或功能)?目前Beta Site流量統計是利用MRTG及Netflow進行設備及各IP流量統計,Beta Site網路中使用者所使用的通訊協定分佈狀況透過Beta Site放置在出入口處的Analyzer進行分析,如圖3所示;至於送測的產品需要哪些功能:1. Zone2內需要使用Port Based VLAN,原因是宿舍網路有分成一般平台和測試平台,目前Beta Site是依賴Port Based VLAN讓申請Beta Site的使用者不必再經過實體線路切換才能使用Beta Site,透過VLAN切換將Beta Site的路由切開,讓同學可以不必有線路調整的空窗期,2. Zone3需要BGP路由協定與上層路由器進行路由交換。

Auto Failure Detection and Notification

網 管在維護Beta Site時最怕影響到同學使用網路的權益,的確在Beta Site內無法保證所有的待測產品都處於非常穩定的情況,因此如何在第一時間就知道產品出現問題並立即通知管理人員便顯得非常重要,Beta Site對於這個問題有兩套機制並行使用,一個是利用Zone4的bypass switch,bypass switch會於固定時間內發送heartbeat封包,對待測產品發出類似ICMP封包,如果待測產品有回應,則表示它處於正常運作的狀態,若否則表示 處於不正常的狀態,需要進行啟動bypass模式(i.e. Auto Recovery);另一種是使用user-behavior probing,Beta Site根據NBL App-Test系統開發了Beta Site Monitor System(簡稱BSMS),BSMS會定期發出ICMP、ARP及Application封包,對真實網路使用情況進行驗證,其中ICMP及ARP是 針對各宿舍機房的Switch進行測試,Application則包含HTTP, FTP及多媒體串流(Youtube, Wretch.cc),各個裝有BSMS的PC會散佈到各個宿舍機房內,並定期進行各項測試,測試完畢再向監控中心回報相關的測試情況,如此一來網管便可 得知在Beta Site內的使用者使用網路的品質,一有回題會由Beta Site Server進行e-mail及簡訊回報,網管便可迅速進行反應及修正。

Auto Recovery

上 面談到對於網路情況的監控,若遇到問題時該如何自動進行修復?bypass switch本身就具有Auto Recovery的功能,如圖4所示,在Normal Mode下流量是由External Network <-> DUT <-> Internal Network,而Bypass Mode則是直接由External Network <-> Internal Network,i.e. 就是流量沒有經過待測產品,一旦bypass siwtch偵測到待測物處於不正常運作情況下,就會自動進行切換模式可迅速進行反應及修正。

綜合以上為Beta Site的架構內容,整體摘要整理如表:

Concern

Solution(s)

DUT Coverage Zone 1 ~ Zone 6>
Remote Control Remote Console, Remote Power
Degrees of Traffic Volume Use a switch to regular traffic volume, High Performance Filtering, ILLT
Traffic Profiling MRTG, NetFlow, Analyzer
Volunteers Students’ free will, Incentive, NDA,Use VLAN Separate from Dormnet
Auto Failure D&N User-behavior probing, Bypass switch
Auto Recovery Bypass switch

SOP

談到這裡,或許已經開始對於Beta Site的測試感到有興趣,想將您的DUT送進來測試,產品送Beta Site測試有一定的SOP,如圖:

產 品要進行測試前,需填妥BS-001表格,內容是關於DUT的資訊以及與合作廠商及NBL負責人員的相關聯絡資料,待確定此資料之後會將產品安裝上適合的 環境,同時視流量的需要進行調整,當進行到Testing階段時,廠商工程師開始進行對DUT的監控,NBL工程師進行網路情況的監控,一旦偵測到發生問 題時,會進行發生情況收集,並將DUT上的log進行備份,NBL這邊會將所有的資訊記錄到BS-003中,讓廠商工程師能迅速了解並還原發生問題時的情 況,同時進行Fail Recovery,若問題屬於相當嚴重,就會暫時將產品離線,這時RD開始進行debug的動作,待問題解決之後再重新上線進行測試,並且將問題發生的原 因及解決的方式記錄到BS-002中作為記錄。

Case Study

底下將舉三個不同的產品,其中所發生的情況為例子,作為供大家經驗上的交流以及參考。

Case 1: Botnet/Malware

Case1 是一個關於Botnet/Malware系統的測試,待測產品包括在Zone1的Agent軟體,Zone5的Traffic Analyzer及Chief Server,在Beta Site內的使用者,透過Beta Site網路將本系統中的Agent程式下載並安裝到自己的電腦上,而所有經過Beta Site的流量都會送到Traffic Analyzer進行分析是否有惡意程式被下載或進行攻擊,當Traffic Analyzer發現有問題的PC時,會透過Chief Server通知有問題的PC,進行Delete Process or Software Program等動作,同時會將整個發生問題的原因以及有問題的PC IP通知管理者,達成對使用者資料保護。

在Case1內透過使用者的回報以及管理者監控,找到下列的defects:

  • False-Negative/False-Positive:
    1. Users can’t use Alcohol 120% successfully after install Agent
    2. Users can’t use Raidenftpd successfully after install Agent
    3. Users can’t use TrendMicro Internet Security 2009 successfully after install Agent
    4. Agent can’t recognize many antivirus software successfully
  • Service Compatibility:
    1. Users can’t watch Network TV by using Vigor and TVant after install Agent
    2. Users can’t use Hinet Digital Home service after install Agent
  • 廠商的解決方式:
    1. FN/FP: Software Exception List, Upgrade recognize policy
    2. Service Compatibility: Upgrade Agent

Case 2: Security Appliance

Case2 是放置於Zone4 (One-In, One-Out)的設備,主要的功能具有防火牆及IPS, IDP等功能,而在這個case中發生了使用者在client往像是yahoo或是無名小站等極受歡迎的網站時,卻無法正常建立連線,發生問題的原因是 DUT本身收到來自使用者端發出的不完整封包,造成DUT產生invalid memory access,而廠商的解決方式是透過增加額外的判斷式,去確認當收到這類型的封包時,避免發生執行部份function時產生invalid memory access的情況。

Case 3: Gigabit Switch

Case 3則是當Beta Site佈置Gigabit Switch時發現的問題,Gigabit Ethernet是Beta Site給同學的福利之一,但是由於同學使用各種不同的系統、網路卡以及各種不同的使用習慣,如圖7,而發生Zone1與Zone2產品之間互通性的問 題,這部份的問題通常發生在產品之間要進行Auto Negotiation時,常常使用者使用的網路卡與Switch之間有相容性問題時,會發生系統發出線路已拔除的訊息,甚至要取消Auto Negotiation,將速度設定為100Mbps或10Mbps時才可以正常使用,目前已知有兩種型號的網路卡有這樣的問題,廠商的處理方式是需要加 強對於電氣訊號的收送,以及對Auto Negotiation程序有更大的容錯空間。

Statistics of Product Defect

根據Beta Site對廠商收集各種defects,將各個defects分類為以下四種:

  • Stability: Hanging, Reboot
  • Performance: Slow Down, Connection Loss
  • Functionality:False-Negative/False-Positive,Software/Service Compatibility, Hardware Interoperability
  • Other: DUT can’t boot successfully after power loss

 

而所收集的defect數量如表所示(註: 此為2008年的資料):

Types of Defects Stability Performance Functionality Other
# of Defects 26/129 20/129 81/129 2/129
# of Products 25/42 8/42 23/42 3/42

Beta Site所送測的產品都是已經通過實驗室內部測試過,而且大部份廠商已了解的bug都已經解決了才送過來,也就是說產品都是已經接近要賣到市面上的產品 了,可是從表中可以了解,幾乎各項產品都還存在有數量不一的bug,從找到的defect來看,functionality還佔了大多數的情況,從產品的 角度來看,幾乎都還有一半以上的產品具有穩定性以及功能性的問題,顯示在Beta Site中的測試是具有其相當不錯的功效,能確實的找到實驗室內無法找到的defect。

各種新的產品以及應用仍將持續的被研發出 來,Beta Site也將在未來進行提供更多元化、更大規模的測試環境讓國內外的廠商進行測試,並極力致力於協助廠商改進相關的產品,未來Beta Site將會吸引更多的使用者,導入更大的流量供高端產品進行更大的產品壓力測試,也將納入更大的範圍(i.e. 不只有宿舍區的流量)進入Beta Site中進行測試,能提供更多種不同的通訊協定以及使用者習慣供測試時使用,未來也將提供10G網路、VOIP及IPv6等對應環境。


  流量重播

Why do we need replay

Replay Test的技術核心是希望結合Lab Test與Field Test的兩項優點,創造更好的測試範圍與更精確的尋找發生事件的原因。

Field Test是將測試產品放到真實環境上直接為交大參加實驗網路的學生服務,如果產品發生問題無法繼續服務時,則可以利用先前介紹的機制通知網路管理員使得產 品開發者能進行觀察待測物。而Lab Test則是在實驗室的環境下產生流量看網路產品是否有按照規格上的設定跑,或進行壓力測試觀察待測物的極限值,如果在測試過程中發現有異狀,可以把同樣 的設定再重播一遍流量就可以重置問題的發生,以方便產品的開發者釐清問題。但Lab Test中測試範圍則無法像Field Test中以大量真實使用者、多元網路程式、複雜的網路行為測試產品,也無法產生比Field Test更接近使用者的行為,而Field Test則是無法像Lab Test可以很快速的從已知的設定中重置網路流量以便更仔細觀察待測物的狀態與反應。

Replay Test的作法則是用Field Test中所經過的流量經由Switch Mirror一份錄製下來(如圖一)再用Lab Test的環境再造真實網路流量,讓測試的網路流量不但可以包羅萬象、更接近使用者的行為、也可以加速釐清問題的產生讓網路產品能更快的提升品質。

Replay Test的第一步是要將流量分邊,這是為了模擬真實流量中一進一出的網路行為,但最重要的是第二步,重播的流量讓待測物看起來就像在Field Test環境所產生一樣真實,若只是將錄製的流量原封不動的播出去有可能會不符合網路規約而待測物則不會建立session table去處理該流量,失去測試的意義。因此在重播的過程中,除了將流量推出網路之外,也必須去聽取另外一端經過待測物後的流量,觀察此流量有沒有經過 什麼改變,以便重播下一個符合網路規約的封包。

Key to replay

因此重播流量的技術分為兩大項來評估,第一個 是順序的正確性,另一個是資料的準確性。順序的正確性代表著流量必須等到另外一端收到後才將下一個封包推出,而不是單純的依照當初錄製的時間為準,這是因 為每個待測物處理封包的時間可能都不同。而正確性則是強調若封包經過待測物修改、或重播時因為特別需求我們將重播的流量修改時,是否仍然符合網路規約,讓 待測物看起來這不是造假的流量而像是真的使用者再使用待測物的服務。

重播真實流量中資料的準確性,關鍵在於傳輸層(ex: TCP、UDP)與應用層(ex: FTP、HTTP)是否能符合規約所規定。以傳輸層的TCP為例,當遇到NAT修改了IP、Proxy改變了sequence number、IPS(Intrusion Prevention System)可能阻擋了部分封包時,必須在重播有相對應的處理才能確保接下來的重播對待測物來說是有效的。以應用層的FTP為例,Control connection會在payload中會告訴另外一端使用者下一條data connection要建立TCP連線必須連到哪一個IP address和port,因此在重播時若我們使用的IP address跟錄製時不同,就必須修改control connection的IP address,以讓data connection重播時能符合FTP 規約的規定。

Replay tools

為了解 決NAT(Network Address Translation)修改封包IP address的問題,NBL以TCPreplay為基礎開發了一項重播工具NatReplay,利用監聽被重播的流量,動態修改重播流量中改變的IP address和port,改進了TCPreplay只是將錄製的流量按照時間播出來的缺點,使得重播的流量確實能穿越NAT以達到測試的效果。

NameComplete ConnectionStatefulSelected Replay
TCPreplayNo requiredNoNo
TomahawkRequiredYesNo
MokeyNot requiredYesNo
AvalancheRequiredYesNo
SocketReplayNot requiredYesYes

在 現有研究技術和工具中,重播真實錄製的準確性仍有些實際的問題沒被完整的解決,如表一所述,第一個問題是錄製流量時連線在錄製時間點就開始建立,因此無法 錄置完整的連線,或在真實環境下的流量太大導致錄製不完全,第二則是前段所說明的問題,第三個是重播後如何在龐大流量中尋找產生事件(如待測物 crash或待測物產生的error、bug)的流量。而NBL開發的SocketReplay則提供同時解決這三項問題,使產品開發者不但可以測試到真 實流量的網路行為,也可以節省分析流量的時間與加速重置事件的過程,讓產品開發者能更能有效的除錯,最後讓產品更穩定。


  真實流量測試應用

PCAP Library

PCAP是一種保存網路流量的檔案格式,我們將國立交通大學Beta Site上的各種網路流量儲存成PCAP,並分門別類的存入資料庫,當使用者想使用真實流量來進行測試時,可以指定特定條件來搜尋到想要的網路流量,這套系統我們稱之為PCAP Library。

整 套PCAP Library系統可以分為三大部份,首先,透過錄製設備將網路流量轉換為PCAP並從Capture Site傳回Replay Site,為了瞭解這個PCAP裡面包含了哪些流量,我們將這個PCAP還原為網路流量對不同的網路安全產品播放,在流量流經網路安全產品的同時,網路安 全產品會檢測出其中有害流量,同時將有害流量的資訊以syslog的方式傳回播放設備上,播放設備根據網路安全產品的偵測結果將PCAP切割成多個小 PCAP,每個小PCAP中只包含一條connection,最後將小PCAP連同網路安全產品的偵測結果一併上傳至資料庫中儲存,等待使用者指定條件來 進行搜尋。

PCAP Library搜尋頁面中可以透過編號、連線資訊、時間、偵測裝置四大類索引來進行搜尋,每一個被上傳到資料庫中的PCAP都會被賦予一個獨一無二的 PCAP ID,當使用者知道上次使用的PCAP ID為何時,可以直接的輸入PCAP ID進行搜尋快速的找到上次所使用的PCAP。若使用者為第一次使用PCAP Library可以透過指定IP或Port的方式來搜尋特定的主機或服務被攻擊的流量,也能指定攻擊時間來搜尋PCAP,或者選定特定的網路安全產品來瞭 解這些產品偵測到哪些攻擊流量,當然,這四大類的搜尋方式可以依據使用者需求同時使用。

搜 尋結果中會顯示出符合條件PCAP的連線資訊、時間、攻擊名稱並可以透過Get這個連結來下載PCAP,或使用Download All Pcap File來下載所有符合條件的PCAP。除了基本的搜尋功能外,PCAP Library也可以應用在測試誤判與漏判問題,同一份PCAP若A,B,C三台產品有偵測到,而D產品沒有偵測到,這份PCAP是D產品漏判的機會就相 當高,反之,若A,B,C三台產品沒有偵測到而D產品偵測到,則很有可能是D產品的誤判。

In-Lab Live Test

公 司內部在測試網路產品的所使用的流量通常是透過測試設備所產生出來的,相較與使用者進行網路連線行為所產生出來的流量,測試設備所產生出來的流量單純許 多,無法測試到真實世界可能發生的行為,導致一項新的或改版的網路設備有不穩定的現象發生,為了解決這個問題,公司在網路設備上市前常會透過關係尋找 Beta Site試用並回報問題以降低網路設備上市後的問題。Beta Site的測試方法固然可以減少產品上市後的問題,卻因為問題重製不易,導致開發團隊除錯困難,再者規模較小的公司也不容易找到適合的Beta Site。

為了讓網路產品都可以使用真實流量進行測試並簡單的重製問題,NBL建立了一套In Lab Live Test系統(圖4),PCAP Storage上儲存著交大Beta Site所錄到的PCAP,透過Replayer將這些PCAP轉換成網路流量對待測的網路產品播放,並以NBL自行開發的檢測程式瞭解待測產品的狀況, 若發生錯誤即時紀錄,將來要重製問題時,只需找出發生錯誤當時所播放的PCAP重新播放即可。

check device可以透過ARP、ICMP、TCP及HTTP四種通訊協定持續的對待測物進行檢查,圖五為Check device的主畫面,在啟動In Lab Live Test系統前,需填入待測物的IP,選擇要使用哪些通訊協定來檢查待測物並指定多久檢查一次,當測試完成後,也能透過FTP或SMTP將測試結果報告寄 送給相關人員,check device實際執行流程如圖六,在測試程序剛開始時,待測物處於pass的狀態,若指定檢查的其中一項功能沒有回覆,狀態便跳至functional, 當所有功能都沒有回覆時,狀態跳至suspend並暫時停止播放流量,若流量停止後,待測物又開始回覆檢查,則稱這台待測物有exhausted的問題, 並繼續測試,反之若流量已停止待測物仍無法回覆,這台待測物就有hanging的問題。

 


  認證準則與問與答

RealFlow Certification

利用真實網路流量測試環境、技術與應用所進行的相關測試,統稱為 「RealFlow Test」,而「RealFlow Certification」則是對於在RealFlow Test過程中表現優異的產品所頒予的認證,來鼓勵那些一直在RealFlow Test過程中努力不懈,最後將其穩定性提升至符合認證標準的優質產品。NBL目前提供RealFlow Certification服務的產品類型包含SOHO Router及Security Appliance兩類,未來還會繼續擴充至其它產品類型。

取得RealFlow Certification的產品,代表其在真實網路流量的環境中有很好的穩定性,也就是說當該產品銷售到顧客端時可以更穩定地運作。

Criteria

RealFlow Certification認證程序分為兩個階段進行,第一階段測試包含效能面與功能面的測試項目,在第一階段的測試項目中,若廠商銷售時有透過任何形式 公佈或公開與測試項目相關數據,則 NBL要求測試結果至少需達到廠商所宣稱的數據,反之,若廠商不公開或公佈任何與測試項目相關數據,則NBL不對第一階段的任何測試項目設限,並將結果公 開提供使用者瀏覽參考。第二階段NBL將欲取得認證的設備進行穩定性測試,並於測試同時依據DUT規格調整測試內容,驗證設備是否穩定性問題。

FAQ

  • Q1.
    • RealFlow Certification的測試過程會開啟DUT的哪些功能 ?
  • A1.
    • 多 數網通產品的功能愈漸複雜,但問題通常都是在整合的時候容易有問題。因此雖然在流量變複雜的時候容易有問題,但產品本身也很可能會有問題。所以在做認證測 試的時候,NBL會將常用的功能都打開來測,在各種不同功能組合下進行測試,DUT有開啟哪些功能會公布在測試報告中。
  • Q2.
    • RealFlow Test穩定性測試的變因眾多(例如流量有高峰有低峰等),NBL如何保持其客觀性?
  • A2.
    • 因 使用者無法受我們的控制且有其特定行為模式,所以流量大小或種類的因素不會是測試過程中的「操縱變因」或「控制變因」,而是測試過程的環境 Profile,我們會將流量大小及種類記錄下來作為解析測試結果時的參考。RealFlow Test著重的是流量內容與行為的真實性,認證的「時間」為其中一個重要因素,一個產品的測試通常都是一開始會有很多問題,逐漸修復各項問題之後產品會漸 趨穩定,才會發給認證。
  • Q3.
    • 測試過程所使用的網路流量,NBL如何以合法方式且不違反隱私的情況下提供廠商進行測試使用?
  • A3.
    • NBL 是採取召募的方式來號召同學加入Beta Site,同學要不要加入Beta Site是他們自由意志下的決定而非強制被迫加入,而在加入Beta Site的程序中會讓同學充份了解到加入Beta Site的權利與義務,因此只要廠商與NBL的合作中可以遵守我們對於同學隱私的保障規範(簽署NDA是必要的程序)、承擔必要之責任風險,則廠商便可取 得真實網路流量進行測試。
  • Q4.
    • NBL如何改善使其更貼近企業級產品適用的流量?
  • A4.
    1. 交大Beta Site的流量也只是一種類型,擴展網路流量的類型與範圍是未來重點工作項目之一。
    2. 相 較於企業流量,校園流量更具挑戰性,原因在於學生的網路使用行為遠比員工的網路使用行為更具多樣性,同時企業對於員工網路的使用行為規範也比學校來得更加 限制。許多廠商都有把產品放上自己公司網路測試、把自己公司當作Beta Site的經驗,但都發現能找到的問題遠不及校園網路的環境。
  • Q5.
    • 交大Beta Site與其他Beta Site的比較差異?
  • A5.
    1. 傳統Beta Site都是靠Power User,但只適用較小型的產品。若是較大型的產品,遇到問題時就有無法重製當時的流量的問題。可有較大變異性、較多人數的流量,傳統合作的Beta Site通常較為保守,不太可能做一些新技術的嚐試。
    2. 傳統Beta Site: 靠關係、短期、單調、小規模、無彈性。交大Beta Site: 開放服務、長期、多樣化、大規模、彈性。