RFC2544測試指標

參考：https://wenku.baidu.com/view/3abbb5bf960590c69ec3769d.html  RFC2544性能測試介紹

參考：https://wenku.baidu.com/view/6556b31382c4bb4cf7ec4afe04a1b0717ed5b348.html   RFC2544以太網性能測試規程

參考：https://wenku.baidu.com/view/7ccbcb4b2b160b4e767fcf9e.html   關於防火牆性能測試(RFC2544)

 

網絡數據包中，小包、中包、大包、分別指 64字節是小包，64~1518字節的是中包，大於1518的是大包。
網絡中 Maximum Transmission Unit(最大傳輸單元)一般是1500

 

原文：https://blog.csdn.net/jane_rabbit/article/details/10140199 

 

RFC2544提供了一個對網絡設備測試的基准，它規定了一系列的測試過程和方法，使得服務提供商和用戶間可以在同一個基准下，對測試的實施和結果達成共識。

RFC2544標准要求的幀長：64byte、128byte、256byte、512byte、768byte、1024byte、1280byte、1518byte

一、吞吐量（Throughput）

         設備能夠無丟失地傳送接收到的幀信號的最大速率，簡單的說就是從源發送方，到目的接收方，無丟包的情況下，單位時間內可傳輸的最大數據量。對於一個以太網系統，絕對的量大吞吐率應該等同於其接口的速率。實際上，由於不同的幀長度具有不同的傳輸速率，這些絕對的吞吐率是無法達到的，越小的幀由於前導碼的幀間隔的原因，其傳輸效率就越低。

           64byte的幀，其最大數據吞吐率（Data Throughput）是76.19MBit/s，每秒可傳輸148809幀。對於1518byte幀，則分別為98.69MBit/s和8127幀/s。

          測試要求：一般把測試持續時間設定為20s，為了克服隨機性的影響，每一個測試案例的測試次數設定為20次；測試粒度設定為不過理論速率的1%。

二、時延（Latency）

         是指一個幀從源點到目的點的總傳輸時間，這個時間包括網絡節點的處理時間和在傳輸介質上的傳播時間。一般的測試方法是發送一個帶有時間戳的幀，通過網絡后，在接收方將當時的時間和幀所攜帶的時間戳比較，從而得出延時值。考慮到時間同步的問題，一般采用將發出的幀環回到發送方進行比較，因此也稱為雙程時延。

         有兩種定義方法：存儲轉發時延（store and forward latency,S&F）和直通交換時延（cut through latency,CT）。存儲轉發時延是指數據幀最后一個比特到達設備輸入端口的時間與該數據幀第一個比特出現在設備輸出端口的時間間隔，按后進先出的方法計算；直通時延是指數據幀第一個比特到達設備輸入端口的時間與該數據幀第一個比特出現在設備輸出端口的時間間隔，按先進先出的方法計算。

         RFC2544要求對時延測試至少要重復20次，至少持續120s，結果取所有測試結果的平均值。

三、丟包率（Frame Loss Rate）

就是發送方發出但沒有到達接收方的幀的數目。一般表示為幀丟失率。即相對於總發送幀數目的一個百分比。

計算公式：丟包率 = 接收方沒有收到的包的個數/發包方的發包總數 * 100%

四、背靠背（Back to back）

         屬於邊界值測試范疇，是向被測試設備連續發送具有最小幀間隔的N個幀（以太網標准規定最小幀間隔為0.96微秒），在不發生丟包的情況下，統計被測設備送出的幀的個數。如果和發送的個數相等，則增加N值，重復上述測試過程。直到被測設備送同的幀個數小於測試發送幀個數。反之則減少發送幀數，並減少發包時間，直至沒有幀丟失發生。主要用於衡量具有存儲轉發能力的被測試設備的最大貯轉發能力。

          它主要和以下一些因素有關：網絡設備內部緩沖的大小；網絡設備入、出口之間的速率差；網絡設備轉發能力的大小；網絡設備交換網絡的調度算法等。

          標准中要求發送時間不能小於2s，建議至少重復20次，結果取其平均值。

五 、系統恢復（System recovery）

         用於測試設備在超負載情況下的系統恢復能力。測試過程為先按被測設備最大吞吐率的1.1倍發送至少60s的數據，然后將速率下除50%，統計速率下降到無幀丟失之間的時間，即為系統恢復時間。

六、復位測試（Reset）

         用於測試系統從復位到恢復正常工作之間的時間。測試過程為先按最大吞吐率發送最小長度的幀，然后復位被測設備，統計復位前發出的最后一幀的時間戳和復位后收到的第一幀的時間戳的差值，即為復位測試時間。

 

Note: All performance values are “up to” and vary depending on system confguration. Antivirus performance is measured
using 44 Kbyte HTTP files. IPS performance is measured using 1 Mbyte HTTP files. IPsec VPN performance is based on
512 byte UDP packets using AES-256+SHA1. Firewall Throughput performance is measured using UDP 1518 Bytes
based on RFC 2544. Antivirus Throughput is measured in proxy mode.

 

http://sd.wareonearth.com/~phil/jumbo.html

Whether or not Gigabit Ethernet (and beyond) should support frame sizes (i.e. packets) larger than 1500 bytes has been a topic of great debate. With the explosive growth of Gigabit ethernet, the impact of this decision is critically important and will affect Internet performance for years to come.

Most of the debate about jumbo frames has focused on local area network performance and the impact that frame size has on host processing requirements, interface cards, memory, etc. But what is less well known, and of critical concern for high performance computing, is the impact that frame size has on wide area network performance. This document discusses why you should care, and about the largely ignored but important impact that frame size has on the wide area performance of TCP.
How jumbo is a jumbo frame anyway?
Ethernet has used 1500 byte frame sizes since it was created (around 1980). To maintain backward compatibility, 100 Mbps ethernet used the same size, and today "standard" gigabit ethernet is also using 1500 byte frames. This is so a packet to/from any combination of 10/100/1000 Mbps ethernet devices can be handled without any layer two fragmentation or reassembly.

"Jumbo frames" extends ethernet to 9000 bytes. Why 9000? First because ethernet uses a 32 bit CRC that loses its effectiveness above about 12000 bytes. And secondly, 9000 was large enough to carry an 8 KB application datagram (e.g. NFS) plus packet header overhead. Is 9000 bytes enough? It's a lot better than 1500, but for pure performance reasons there is little reason to stop there. At 64 KB we reach the limit of an IPv4 datagram, while IPv6 allows for packets up to 4 GB in size. For ethernet however, the 32 bit CRC limit is hard to change, so don't expect to see ethernet frame sizes above 9000 bytes anytime soon.

 

RFC2544測試

來源 https://blog.51cto.com/lyloveyou/1638483

吞吐量

吞吐量是衡量一款設備轉發數據包能力的測試。這個數據是衡量一款防火牆或者路由交換設備的最重要的指標。

 

測試吞吐量首先根據標稱性能確定被測試設備的可能吞吐量大小，這樣來決定我們測試一款設備所需要的測試儀端口數量。如果一塊設備標稱性能達到8Gbps，那么通常我們需要8個1000Mbps的測試儀端口來測試。

 

吞吐量的測試通常會選用測試儀所對應的RFC測試套件進行測試。測試的數據包長包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包長或者混合包長（IMIX）進行測試。IMIX流量通常是指用幾種數據包混合流量來測試防火牆的吞吐量。我們測試用的比例為64Bytes*58%+570Bytes*34%+1518Bytes*8%，也就是7:4:1。如果需要測試***的吞吐量，不能使用1518Bytes，因為會分片，一般改用1400字節測試。

 

吞吐量一般采用UDP數據包進行測試。測試通常采用雙向各一條流或者多條流的方式測試。測試流量通常是A<->B，C<->D雙向對打的流量。使用單向流量測試的情況比較少見。

 

測試儀通常都會采用二分迭代法進行測試。比如測試儀會首先使用100%的流量發包（1st trial），如果發現丟包，則會采用50%((100%+0)/2)的流量進行測試（2nd trial），如果發現沒有丟包，會采用75%((50%+100%)/2)的流量進行測試（3rd trial）。通過這種二分迭代的測試最終測試出設備的最大吞吐量數據。我們內部測試的時候每一個trial的時間設置為30秒，每個包長通常會進行8個trial的測試（取決於測試儀設置的精確度）。由於測試儀會嚴格判斷是否有丟包，即使有一個包沒有收到，都會用二分法往下降。但是這個丟包可能不是設備（網線質量，中間的交換機或者其他原因）造成。因此對於這種情況，測試儀都會有一個loss tolerance的設定，通過設定一個恰當的數值來避免其它原因造成丟包對測試結果的影響。

 

        在進行對一款設備的吞吐性能測試時，通常會紀錄一組從64Bytes到1518Bytes的測試數據，每一個測試結果均有相對應的pps數。64Bytes的pps數最大，基本上可以反映出設備處理數據包的最大能力。僅僅從64Bytes的這個數我們基本上可以推算出系統最大能處理的吞吐量是多少。因為通常衡量一款網絡設備的CPU/NP/ASIC的最大處理能力的極限就是64Bytes的pps數。很多路由設備的性能指標有一點就是宣稱xxMpps，所指的就是設備處理64Bytes的pps數。比如64Bytes的pps為100000pps，吞吐量為100000*(64+20)*8/1000000= 67.2Mbps，拿這個結果計算1518Bytes的數據為100000*(1518+20)*8/100000=1230.4Mbps。其中的20Bytes是指12Bytes的幀間距（IPG）以及8Bytes的前導碼（7Bytes同步+1Bytes起始），測試每一個字節的吞吐量都需要將這20字節計算在內。通過前面的算式可以看出，我們即使不測試1518Bytes的吞吐量也能夠大致推算出設備最大的吞吐量是多少。而最終的結果只能<=這個結果。根據以往的測試經驗，64字節測試結果的pps數與1518字節的pps數，相差在20%以內。

        

        測試注意項：1、防火牆接口的不同工作模式對性能的影響：路由、橋(ACCESS/TRUNK)、子接口、聚合接口等工作模式會對設備轉發的性能有一定程度的影響，但是基本上不會偏差太大，當然個別的實例除外。2、網卡的型號會對轉發的性能有一定程度的影響：a、部分網卡會網卡性能問題，例如測試過程當中遇到的82574L型號的網卡，千兆64字節的性能下載比數據只能測試到64.4%左右。網卡的驅動與防火牆的轉發實現存在問題，例如中高端牆上的網卡的驅動e1000e只有一個隊列，但是防火牆的轉發進程存在多個，這樣會導致網卡上的數據被轉發進程獲取的時候總有幾個轉發的隊列是空閑的，導致最終的測試數據無法真實的反饋出我們設備的性能。

 

 

時延

時延所測試的是系統處理數據包所需要的時間。防火牆的時延測試的是其存儲轉發（Store and Forward）的性能（另一種是Cut and Through）。

 

時延的測試通常會選用測試儀所對應的RFC測試套件進行測試。測試的數據包長包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包長或者混合包長進行測試。采用UDP數據包進行測試。測試通常采用雙向多條流的方式測試。

 

時延的測試通常是建立在測試完吞吐量的基礎上進行的測試。測試時延之前需要先測出每個包長得吞吐量大小，使用每個包長的吞吐量結果的 100%-90%作為時延測試的流量大小。一般時延的測試要求不能夠有任何的丟包。因為如果丟包，會造成時延非常大，結果不准確。我們測試一般使用最大吞吐量的95%或者90%進行測試。測試結果包括最大時延，最小時延，平均時延，一般記錄平均時延。

 

如果測試得比較精細，也可以測試在不同負載下的時延。比如可以測試在10%，20%...直到最大負載的結果下的時延。

 

測試時長通常是設置30秒的流量，然后測試幾次取平均值最為最終結果。

 

 

丟包率

丟包率是測試系統在一定負載的情況下丟包數量多少的測試。這個測試實際上和吞吐量測試類似。測試的意義在於通過過載的流量來考查對設備正常轉發性能的影響。

 

丟包率的測試通常會選用測試儀所對應的RFC測試套件進行測試。測試的數據包長包括64Bytes，128Bytes，256Bytes，512Bytes，1024Bytes，1240Bytes，1518Bytes。或者使用特定包長或者混合包長進行測試。采用UDP數據包進行測試。測試通常采用雙向各一條流的方式測試。

 

測試方法通常是采用10%--100%的流量分別測試被測系統的丟包情況。當測試100%負載的情況事，對於NP/ASIC架構的防火牆來說，丟包率=1-吞吐量(%)。因為NP和ASIC轉發更依靠硬件的性能，而硬件的性能通常比較穩定。而對於多核和x86架構的防火牆來說，轉發依靠CPU的計算，性能相對硬件轉發來說相對較弱，所以100%負載的丟包率>1-吞吐量(%)。比如我們測試出NP牆的吞吐量是80%，那么100%的丟包率基本上可以推算出等於20%，而多核和x86架構的防火牆的丟包率大多數情況>20%。所以，丟包率的測試對於我們產品的測試不是很有利。不過丟包率的測試在一般的對外測試中並不常見。

 

 

 

背靠背緩沖測試

背靠背緩沖測試主要測試被測設備緩沖處理burst數據的能力。考驗的是被測設備處理突發數據流緩存數據並快速處理的能力。這個測試在一般的測試中並不常見。

 

測試方法和結果和吞吐量有很多相似的地方。測試儀向背測試設備發送一定流量大小的數據包，發送時間通常為1-2秒，然后看接收端能夠收到多少的數據包。通常線速轉發的設備的背靠緩沖能力和吞吐量的pps相一致。比如，一台設備能夠線速轉發雙向2Gbps的流量，那么背靠背緩沖性能（發送時間為2秒）基本上可以確定是148萬*2*2 pps。

 

網絡層吞吐性能測試方法簡介

    在之前已經寫一篇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的轉發速率，對比多款機型、平台看看是否存在一定的關系。

 

另外請注意測試出來的數據一定要反思，為什么會是如此個數據，是如何來的，這樣才能提高。

 

對內測試列了很多需要測試的數據，就是為了更完整的反應產品的性能，但是這么多的性能數據，這么多的工作量在緊張的測試資源條件下，該如何進行呢，請大家來思考。

 

================ End