科技行者2018-10-31 11:09:39翻到一篇以前寫的舊文，可以回答這個問題。
在當前的下一代防火牆產品測試過程中，網路應用效能測試已經得到了充分的重視。然而在產品適用性分析上還有很大的不足。使用者不清楚如何對產品各種應用效能指標進行理性的辨別，只能以性高則優的方式去進行選擇。廠商也因此，不得不陷入產品效能價格比拼殘酷競爭之中。如何擺脫價效比之爭，令產品選擇迴歸理性？這就需要一個由應用到適用的轉變。
什麼是適用評估
在以往的網路產品測試中，我們僅關注網路產品的處理效能，而缺乏對使用者網路應用需求的分析。因此在實際應用過程中，常會出現採用高效能產品成本增加，低價格產品適用能力不足的情況；高效能低價格的產品也有，可往往又會有產品質量隱患出現的問題出現。因此，使用者採購網路產品時，往往需要大費心力。要想緩解此類情況，理想的辦法，就是讓廠商主動將其網路產品的適用性做一下評估。
什麼是網路產品適用性評估？簡單說，就是找到使用者網路產品處理效能可忍受的底線，並以此為基準，對網路產品處理效能進行分析。舉個較常見的例子：當對一條接入寬頻的服務質量做適用性評估時，首先我們需要對介面頻寬的資料包轉發效能評估，看其是否可以在滿足正常資料轉發時，對頻寬流量不產生影響。其次，對連線處理能力進行分析，瞭解其可以滿足多少使用者同時使用，連線處理不產生瓶頸。這只是對網路產品，對網路安全產品，適用性評估需要考慮的問題會更多。
適用評估要如何進行
也許有人會存有疑問，這些種分析看起來並不複雜，以前沒有人在做嗎？在這裡十分遺憾的告訴大家，至少是沒有很好的去做。為什麼？因為目前為止，還沒有一個較通用的網路適用性評估標準。目前為止，我也只是在個別大廠商的產品評測中，試著去進行一下產品適用性的評估分析，但這還遠未達到生成一套普遍認可的網路適用標準的地步。而且使用者網路應用的需求又是因人而異，並隨應用變化面變化。因此網路適用性標準的建立舉步維艱！
那麼我們就不去做適用性評估了嗎？不，飯要一口口的吃，事要一件件的去做。想當年網路應用效能測試的各項指標，也是從無到有，從一份報告一個廠商開始，逐漸在廠商和使用者中普及並得到認可。現在網路適用性評估，只要我們堅持不懈，相信也會有普及的一天。我現階段的工作計劃如下：
由於下一代防火牆的各項功能指標在網路層及應用層中均有覆蓋，非常具有代表性。因此計劃透過下一代防火牆測試方法的研討，並與相關測試儀表廠商和產品廠商進行溝通，對下一代防火牆的適用性評估技術指標專案進行制定，並明確每個指標的具體測試方法。再透過廣泛接觸廠商及終端使用者的方式，對適用性評估的媒體評估標準進行確定。期望透過若干次的試定修改，相信會有一個比較成熟的網路適用性評估方案可以出臺。
適用評估方法
現在，就根據以往的測試經驗，將需要評估的技術指標進行一下羅列：
具備下一代防火牆產品的廠商眾多，各個廠商的下一代防火牆功能也不盡相同。為了方便統一、規範化的進行分析，現在計劃透過網路層適用評估、傳輸層適用評估、應用層管理控制適用評估、應用層深度內容分析適用評估這四個方向，對下一代防火牆的適用性進行分析。
網路層適用評估
基於網路層資料包的轉發管理控制測試，可以說是最基礎的網路測試專案。RFC 2544的相關測試項至今依然適用，只不過測試專案已精減到了目前的吞吐量和時延這兩項而已。
網路層適用評估適用於下一代防火牆產品中的傳統防火牆功能、路由轉發功能、NAT以及透明模式下網路介面資料包轉發效能評估。評估指標專案前暫定為吞吐量和時延。
吞吐量
有關吞吐量的適用評估，我在思科的ASA 5500X防火牆測試中進行了一次分析，這裡就不再贅述了，有興趣請參閱評測文章“演進中的下一代”中“穩健可靠的網路傳輸”http：//test。cnw。com。cn/test-report/htm2013/20131112_286063_2。shtml中的相關描述。
在那裡，我依據思科反饋的在不同應用場景下資料包平均大小統計，將吞吐量指標的合格線定在了512Byte時吞吐量達到或接近100%即可滿足使用者應用需求。下一步將依據此項評估指標再與其它下一代防火牆廠商和使用者進行溝通，收集更多應用需求後再次進行確定。
時延
從我個人應用體驗來看，資料鏈接建立的最大時延只要不超過1000毫秒（1秒），基本上可以忍受，但在資料傳輸時的平均時延就不同了，最好在1毫秒以下否則資料傳輸速率會受到較大影響。現在進行測試時，時延所採用的數值通常時整個資料傳輸過程中所有資料包傳輸的一個平均值，這裡時延指標的高下就有一些參差不齊了。個人感覺，平均時延如果能在50毫秒以下，應用時應該不會有太多傳輸問題出現。當然，時延的指標還是越小越好，具體指標同樣還需要繼續與廠商進行溝通。
傳輸層適用評估
在實際網路應用中，一個傳輸層連線內有多個應用連線，或一個應用會發起多個傳輸層連線的情況均十分常見，因此以往的應用效能測試中，傳輸層應用效能測試專案常常被忽略，或與應用層處理效能相混淆。而隨著下一代防火牆連線管理控制功能逐步受到重視，以及未來SDN交換裝置的大規模應用，此項測試的重要性也將得以突顯。
以往對傳輸層效能測試的方法也與應用層測試差別不大，都是採用應用層的網路測試儀表，透過建立TCP協議傳輸通道的方式來考查被測裝置的傳輸層連線建立能力和連線保持能力（TCP新建連線和TCP併發連線）。這裡就會出現一個問題，當前網路及網路安全產品傳輸層的處理能力在顯著提升，而測試儀表的測試效能開始出現瓶頸。前些時間接到一個測試，一個1U網路產品，傳輸層的處理效能（數百萬的新建效能！）預計需要4-5臺高效能應用層測試儀表才可能滿足測試需求。這種情況的出現，不但為測試機構，同樣也為廠商對產品的效能驗證提出了更大的挑戰。可以預計，當未來SDN交換機產大規模出現後，如果傳輸層測試方法沒有很好改善，將會有更多的相關測試問題出現。
為改善這種被動情況，必需對測試方法進行改進。在這裡我準備與測試儀表廠商（思博倫和IXIA）進行進一步溝通，試著採用網路層測試儀表在資料包中加入UDP頭資訊的方式對傳輸層處理效能進行驗證。然而這裡會牽扯到連線協議建立是否完整的問題，還需要再進一步與廠商就測試方法進行溝通驗證。
下面就傳輸層適用評估指標進行一下分析：
TCP（或UDP）新建連線
有關傳輸層適用性的評估指標，根據我個人總結的情況來看，在傳輸層連線建立能力（TCP或UDP新建連線）指標評估時，單使用者（每IP）最低可忍受1Mbps頻寬、每秒鐘建立10個傳輸層連線的新建連線處理效能。因此，就暫將單使用者（每IP）1Mpbs頻寬、每秒10TCP（或UDP）新建連線做為傳輸層新建連線的適用層評估指標
TCP（或UDP）併發連線
同樣還是當前我個總結情況，每個使用者（每IP）最少保持100個TCP（或UDP）連線既可保單個使用者的最小網路應用需求。
在今後參與廠商具體產品測試過程中，我還將根據具體情況對此指標進行進一步修訂，並以此為基準對廠商產品傳輸層處理能力進行評估分析。
應用層適用評估
下一代防火牆最重要的轉變就是具備了網路應用行為分析能力，在未來勢必因此而引發網路安全防護的重大變革。相關分析可參考我的另一篇下一代防火牆分析及測試方法探討文章“網路安全能否做到夜不閉戶”。（http：//test。cnw。com。cn/test-news/htm2014/20140826_311052。shtml）而應用效能自然也成為使用者選擇下一代防火牆產品的關注重點。
根據目前所掌握情況來看，下一代防火牆產品的應用層效能測試，還沒有類似傳輸層測試儀表效能瓶頸的情況出現。但並不是說現在的應用效能測試專案就可以滿足下一代防火牆功能測試需求。理由有以下兩點：
一、單一應用協議對應用處理效能無法全面評估
目前傳統應用層效能測試僅透過HTTP一種應用協議進行應用處理效能測試。無法全向對應用識別、行為分析管理等下一代防火牆功能進行有效評估。尤其是在某些廠商“研發”出一些針對此類協議“最佳化”的技術後，在測試中無法有效進行判別。
二、混合應用流量協議不規範
十年前開始進行網路應用效能測試時，應用協議模擬數量少，而且其它協議（FTP、SMTP等）所佔應用比例也小，因此HTTP協議的應用效能測試就逐漸成為了主流。而現在隨著應用效能測試方法的增加，對應用協議也已經可以有較全面的模擬，目前已有測試儀表廠商甚至在提儀修改RFC3511的應用效能測試標準，增加混合應用流量測試的新方法。對於這點我肯定是會舉雙手贊成的。但在這個標準出臺之前，還是再和測試儀表廠商協商一下相關測試方法的事情吧。不過舊指標不是一下就可以輕易拋棄的，透過HTTP協議來測試產品的應用處理能力在現階段還是可以有效反映產品應用處理效能的。
下面就應用層適用評估指標進行一下分析：
HTTP新建連線
由於傳輸層協議已經把管道的數量進行了限制，在這個管道里再跑什麼應用也就是下一代防火牆再做一下深入分析的事情了。因此HTTP新建連線的適用性評估指標目前也定在了單使用者（每IP）1Mpbs頻寬、每秒10 HTTP新建連線。
併發連線數
同上，目前也是定在每個使用者（每IP）最少保持100個HTTP連線。
應用流量
從當前下一代防火牆產品功能性分析上來看，只有在下一代防火牆進行深度內容識別（例如開啟IPS、檔案內容檢測或防病毒功能）時，才會對應用檔案內容去進行分析。這時，應用流量的效能評估才會有意義，否則透過網路層資料包轉發效能對流量轉發效能進行測試就足以了。
而對傳統的應用流量轉發效能測試時，測試方法單一、死板。同樣也是僅採用HTTP這單一協議，在一定HTTP新建連線速率下，載入一個固定大小檔案來生成一個較大測試流量。從上次下一代防火牆測試中可以瞭解，這種測試方法已經無法滿足當前產品在進行深度內容識別時，流量處理能力的測試需求。
現在測試儀表廠商有兩種不同的新應用流量測試方案。一種是採用抓包回放的方式模擬真實網路流量，一種是用測試儀表直接生成多種應用協議測試流量。這兩種方法各有利弊，抓包回放資料流與真實應用情況相近，但生成大流量比較困難；測試儀表生成多種應用協議測試流量可以滿足，但應用檔案內容定製不便。看來此項測試還需要再和測試儀表廠商多多進行溝通才可以有一個比較明確的測試方法出臺。
明確應用需求 保住適用底線
以上適用評估測試方法，很多是很早以前就有的，在這裡反覆炒冷飯的原因就是，透過適用性的基礎指標乘上使用人數，使用者可以輕易瞭解，自身對網路裝置的實際應用需求。從而可以更加明確的去選擇產品。
對於產品廠商也同樣是如此，廠商提供裝置的網路應用處理能力在這條低線之上，即可保障使用者最起碼的網路正常應用。當然使用者經濟能力以及廠商技術能力允許，也可以選用效能更高、處理能力更強的產品來對網路業務應用處理能力再進行提升。
我也會在以後的產品測試報告中，同樣引入適用性的指標對廠商產品效能進行評估。從而選出更加適合使用者選用的優質產品出來以供大家選擇。
本文來自科技行者團隊老董