在之前已經寫一篇RFC2544性能測試內容，此篇內容是接着RFC2544的性能測試項吞吐來繼續深入一些闡述網絡層吞吐性能應該來如何測試。
吞吐性能數據最終要反饋給的目標人羣有：自己、開發人員、產品人員、以及用戶。那首先就要考慮各類人羣如何從哪個角度來衡量產品的性能，這裏我們從對內，以及對外給出兩種測試方法。
以下是筆者在對外的測試項目遇到的用戶選擇的測試方法：其中必有不足，歡迎各位補充：
a、常規的RFC 2544測試，64、128、256、512、1024、1280、1518等七種字節包長的udp雙向對稱數據包測試
b、常規的RFC 2544測試，64、128、256、512、1024、1280、1518等七種字節包長的udp單向數據包測試
注：a、b的測試方法在一段時間內，很受歡迎、認可。如：資質測試、入圍測試、項目測試都用以上的標準做爲網絡層測試的標準，但是隨着時間的推移，測試的方法慢慢熟知、普及，人們想到了更多的測試方法如：
c、常規的RFC 2544測試，64、67、128、256、512、1024、1280、1517、1518等九種字節包長的udp雙向數據包測試
d、常規的RFC 2544測試，64、67、128、256、512、1024、1280、1517、1518等九種字節包長的udp單向數據包測試
e、64、512、1518一定比例混合測試
f、64、128、256、512、1024、1280、1518的ip報文測試
對於以上幾種的客戶測試方法，我們需要明確我們當前產品的支持情況。拿防火牆做個簡單的舉例，不同廠家對自己轉發實現的方式不一致。
1、傳統包過濾防火牆：所有數據包都需要進行沒有選擇的過濾，所以以上這幾種方法轉發都不存在問題，對性能的結果也基本影響不大。
2、無狀態連接防火牆：以上f這種測試方法可能會造成轉發與性能問題。此類防火牆要建立連接，連接建立的前提是五元組，但是此時測試的報文是ip報文，連接應該如何建立？轉發的過程當中是否還需要每次都進行route、nat、acl等邏輯，是否又會影響到性能？
3、有狀態連接防火牆：通過有狀態連接的防火牆，都會爲了性能的提升做出快速轉發模式與默認轉發模式。針對這兩種模式，大部分的廠家實現想要進入快速模式，都是需要連接上有雙向的數據包，所以當此兩種條件限制，測試方法b、d、f是否會表現出異常？額外再加點料：進入到快速轉發模式的連接上再來了分片包，轉發是否存在問題？
4、下一代防火牆：衆所周知，下一代防火牆前提要基於應用識別，而且要高性能、雲特徵分析等，那以上的測試方法又會帶來哪些問題呢？大家都來分析一下。
接下來爲對內測試：在以上a、b、c、d、f、g的測試方法前提下，通常都會增加不同的工作模式測試如：二層（vlan、bridge、bond、旁路等）、三層（路由、bond、子接口等）、在不同的工作模式下，分別驗證快速轉發模式、默認轉發模式的性能，以及性能的差別，並明確差別的合理性；基於以上的測試，再擴展功能如路由、nat、策略，測試各項功能對轉發的影響。此外在過往的經驗中對吞吐性能的影響還有一個比較大的影響參數：併發連接數。測試不同的併發連接數下吞吐的性能，很有可能會發現併發連接數導致的性能問題。對於以上的測試請記錄詳細的測試過程數據，方便查看以及日後追蹤、回憶。
測試點記錄如下：（只簡單的列了2大項）
二層：
vlan+快速轉發模式
1、測試結果：如：package轉發速率、延時
2、測試過程：如：cpu使用率、內存使用率、併發連接數、perf記錄等有利對性能分析的數據
vlan+快速轉發模式+功能（路由、nat、策略等）
vlan+默認轉發模式
vlan+默認轉發模式+功能（路由、nat、策略等）
三層：
路由+快速轉發模式
1、測試結果：如：package轉發速率、延時
2、測試過程：如：cpu使用率、內存使用率、併發連接數、perf記錄等有利對性能分析的數據
路由+快速轉發模式+功能（路由、nat、策略等）
路由+默認轉發模式
路由+默認轉發模式+功能（路由、nat、策略等）
結合上一篇查看快速轉發模式與默認轉發模式在不同字節package的轉發速率，對比多款機型、平臺看看是否存在一定的關係。
另外請注意測試出來的數據一定要反思，爲什麼會是如此個數據，是如何來的，這樣才能提高。
對內測試列了很多需要測試的數據，就是爲了更完整的反應產品的性能，但是這麼多的性能數據，這麼多的工作量在緊張的測試資源條件下，該如何進行呢，請大家來思考。