服務項目

• 服務說明
• 認證與驗證
• 　　真實網路流量穩定性測試認證
• 　　產品規格驗證
• 真實流量測試
• 　　客戶端問題
• 　　真實流量測試環境
• 　　流量重播
• 　　真實流量測試應用
• 　　認證準則及問與答
• 自行開發工具與測試設備
• 委託測試
• 　　標準化測試
• 　　客製化測試
• 公開測試
• 研討會
• 會員

快速索引：

Why do we need replay

Key to replay

Replay tools

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去處理該流量，失去測試的意義。因此在重播的過程中，除了將流量推出網路之外，也必須去聽取另外一端經過待測物後的流量，觀察此流量有沒有經過什麼改變，以便重播下一個符合網路規約的封包。



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

重播真實流量中資料的準確性，關鍵在於傳輸層(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 規約的規定。



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

Name	Complete Connection	Stateful	Selected Replay
TCPreplay	No required	No	No
Tomahawk	Required	Yes	No
Mokey	Not required	Yes	No
Avalanche	Required	Yes	No
SocketReplay	Not required	Yes	Yes

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