Network Working Group B. Hickman
Request for Comments: 3511 Spirent Communications
Category: Informational D. Newman
Network Test
S. Tadjudin
Spirent Communications
T. Martin
GVNW Consulting Inc
April 2003
Network Working Group B. Hickman
Request for Comments: 3511 Spirent Communications
Category: Informational D. Newman
Network Test
S. Tadjudin
Spirent Communications
T. Martin
GVNW Consulting Inc
April 2003
Benchmarking Methodology for Firewall Performance
防火墙性能的基准测试方法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.
本文档讨论并定义了一些可用于描述防火墙性能特征的测试。除了定义测试外，本文件还描述了报告测试结果的具体格式。
This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).
本文件是互联网工程任务组（IETF）基准方法工作组（BMWG）的产品。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Test Considerations. . . . . . . . . . . . . . . . . . . 4
4.2 Virtual Client/Servers . . . . . . . . . . . . . . . . . 4
4.3 Test Traffic Requirements. . . . . . . . . . . . . . . . 5
4.4 DUT/SUT Traffic Flows. . . . . . . . . . . . . . . . . . 5
4.5 Multiple Client/Server Testing . . . . . . . . . . . . . 5
4.6 Network Address Translation (NAT). . . . . . . . . . . . 6
4.7 Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . 6
4.8 Web Caching. . . . . . . . . . . . . . . . . . . . . . . 6
4.9 Authentication . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Test Considerations. . . . . . . . . . . . . . . . . . . 4
4.2 Virtual Client/Servers . . . . . . . . . . . . . . . . . 4
4.3 Test Traffic Requirements. . . . . . . . . . . . . . . . 5
4.4 DUT/SUT Traffic Flows. . . . . . . . . . . . . . . . . . 5
4.5 Multiple Client/Server Testing . . . . . . . . . . . . . 5
4.6 Network Address Translation (NAT). . . . . . . . . . . . 6
4.7 Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . 6
4.8 Web Caching. . . . . . . . . . . . . . . . . . . . . . . 6
4.9 Authentication . . . . . . . . . . . . . . . . . . . . . 7
4.10 TCP Stack Considerations. . . . . . . . . . . . . . . . 7
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 7
5.1 IP throughput. . . . . . . . . . . . . . . . . . . . . . 7
5.2 Concurrent TCP Connection Capacity . . . . . . . . . . . 9
5.3 Maximum TCP Connection Establishment Rate. . . . . . . . 12
5.4 Maximum TCP Connection Tear Down Rate. . . . . . . . . . 14
5.5 Denial Of Service Handling . . . . . . . . . . . . . . . 16
5.6 HTTP Transfer Rate . . . . . . . . . . . . . . . . . . . 18
5.7 Maximum HTTP Transaction Rate. . . . . . . . . . . . . . 21
5.8 Illegal Traffic Handling . . . . . . . . . . . . . . . . 23
5.9 IP Fragmentation Handling. . . . . . . . . . . . . . . . 24
5.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Normative References . . . . . . . . . . . . . . . . . . 29
6.2 Informative References . . . . . . . . . . . . . . . . . 30
7. Security Consideration . . . . . . . . . . . . . . . . . . . 30
Appendix A - HyperText Transfer Protocol (HTTP) . . . . . . . . 31
Appendix B - Connection Establishment Time Measurements . . . . 31
Appendix C - Connection Tear Down Time Measurements . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
4.10 TCP Stack Considerations. . . . . . . . . . . . . . . . 7
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 7
5.1 IP throughput. . . . . . . . . . . . . . . . . . . . . . 7
5.2 Concurrent TCP Connection Capacity . . . . . . . . . . . 9
5.3 Maximum TCP Connection Establishment Rate. . . . . . . . 12
5.4 Maximum TCP Connection Tear Down Rate. . . . . . . . . . 14
5.5 Denial Of Service Handling . . . . . . . . . . . . . . . 16
5.6 HTTP Transfer Rate . . . . . . . . . . . . . . . . . . . 18
5.7 Maximum HTTP Transaction Rate. . . . . . . . . . . . . . 21
5.8 Illegal Traffic Handling . . . . . . . . . . . . . . . . 23
5.9 IP Fragmentation Handling. . . . . . . . . . . . . . . . 24
5.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Normative References . . . . . . . . . . . . . . . . . . 29
6.2 Informative References . . . . . . . . . . . . . . . . . 30
7. Security Consideration . . . . . . . . . . . . . . . . . . . 30
Appendix A - HyperText Transfer Protocol (HTTP) . . . . . . . . 31
Appendix B - Connection Establishment Time Measurements . . . . 31
Appendix C - Connection Tear Down Time Measurements . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
This document provides methodologies for the performance benchmarking of firewalls. It covers four areas: forwarding, connection, latency and filtering. In addition to defining tests, this document also describes specific formats for reporting test results.
本文档提供了防火墙性能基准测试的方法。它包括四个方面：转发、连接、延迟和过滤。除了定义测试外，本文档还描述了报告测试结果的特定格式。
A previous document, "Benchmarking Terminology for Firewall Performance" [1], defines many of the terms that are used in this document. The terminology document SHOULD be consulted before attempting to make use of this document.
先前的文档“防火墙性能基准术语”[1]定义了本文档中使用的许多术语。在尝试使用本文件之前，应查阅术语文件。
In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are:
在本文件中，用于定义每个特定要求重要性的词语大写。这些词是：
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the item is an absolute requirement of the specification.
* “必须”一词，或“要求”和“应”一词表示该项目是本规范的绝对要求。
* "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
* “应该”这个词或形容词“建议”意味着在特定情况下可能存在忽略该项目的正当理由，但在选择不同的课程之前，应理解其全部含义并仔细权衡情况。
* "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
* “MAY”这个词或形容词“OPTIONAL”表示这个项目确实是可选的。一个供应商可能会选择包括该项目，因为特定的市场需要它，或者因为它增强了产品，例如；另一个供应商可以省略相同的项目。
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements. An implementation that satisfies all the MUST and all the SHOULD requirements is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements is said to be "conditionally compliant".
如果一个实现不能满足一个或多个必需的要求，那么它就是不兼容的。满足所有必须和应该要求的实现称为“无条件遵从”；满足所有“必须”要求但并非所有“应该”要求的人被称为“有条件地符合”。
Firewalls can control access between networks. Usually, a firewall protects a private network from public or shared network(s) to which it is connected. A firewall can be as simple as a single device that filters packets or as complex as a group of devices that combine packet filtering and application-level proxy and network translation services. This document focuses on benchmarking firewall performance, wherever possible, independent of implementation.
防火墙可以控制网络之间的访问。通常，防火墙保护私有网络不受其所连接的公共或共享网络的影响。防火墙可以像过滤数据包的单个设备一样简单，也可以像组合数据包过滤和应用程序级代理及网络翻译服务的一组设备一样复杂。本文档重点介绍防火墙性能基准测试，尽可能独立于实现。
Test configurations defined in this document will be confined to dual-homed and tri-homed as shown in figure 1 and figure 2 respectively.
本文件中定义的测试配置将分别限于图1和图2所示的双宿和三宿。
Firewalls employing dual-homed configurations connect two networks. One interface of the firewall is attached to the unprotected network [1], typically the public network (Internet). The other interface is connected to the protected network [1], typically the internal LAN.
采用双宿配置的防火墙连接两个网络。防火墙的一个接口连接到未受保护的网络[1]，通常是公共网络（Internet）。另一个接口连接到受保护的网络[1]，通常是内部LAN。
In the case of dual-homed configurations, servers which are made accessible to the public (Unprotected) network are attached to the private (Protected) network.
在双主配置的情况下，使公用（不受保护）网络可以访问的服务器连接到专用（受保护）网络。
+----------+ +----------+
| | | +----------+ | | |
| Servers/ |----| | | |------| Servers/ |
| Clients | | | | | | Clients |
| | |-------| DUT/SUT |--------| | |
+----------+ | | | | +----------+
Protected | +----------+ | Unprotected
Network | | Network
Figure 1 (Dual-Homed)
+----------+ +----------+
| | | +----------+ | | |
| Servers/ |----| | | |------| Servers/ |
| Clients | | | | | | Clients |
| | |-------| DUT/SUT |--------| | |
+----------+ | | | | +----------+
Protected | +----------+ | Unprotected
Network | | Network
Figure 1 (Dual-Homed)
Tri-homed [1] configurations employ a third segment called a Demilitarized Zone (DMZ). With tri-homed configurations, servers accessible to the public network are attached to the DMZ. Tri-Homed configurations offer additional security by separating server(s) accessible to the public network from internal hosts.
三基地[1]配置采用第三段，称为非军事区（DMZ）。通过三主机配置，公共网络可访问的服务器连接到DMZ。三主机配置通过将公共网络可访问的服务器与内部主机分离，提供了额外的安全性。
+----------+ +----------+
| | | +----------+ | | |
| Clients |----| | | |------| Servers/ |
| | | | | | | Clients |
+----------+ |-------| DUT/SUT |--------| | |
| | | | +----------+
| +----------+ |
Protected | | | Unprotected
Network | Network
|
-----------------
| DMZ
|
|
+-----------+
| |
| Servers |
| |
+-----------+
+----------+ +----------+
| | | +----------+ | | |
| Clients |----| | | |------| Servers/ |
| | | | | | | Clients |
+----------+ |-------| DUT/SUT |--------| | |
| | | | +----------+
| +----------+ |
Protected | | | Unprotected
Network | Network
|
-----------------
| DMZ
|
|
+-----------+
| |
| Servers |
| |
+-----------+
Figure 2 (Tri-Homed)
图2（三总部）
Since firewall testing may involve data sources which emulate multiple users or hosts, the methodology uses the terms virtual clients/servers. For these firewall tests, virtual clients/servers specify application layer entities which may not be associated with a unique physical interface. For example, four virtual clients may
由于防火墙测试可能涉及模拟多个用户或主机的数据源，因此该方法使用术语虚拟客户端/服务器。对于这些防火墙测试，虚拟客户端/服务器指定可能与唯一物理接口不关联的应用层实体。例如，可能有四个虚拟客户端
originate from the same data source [1]. The test report MUST indicate the number of virtual clients and virtual servers participating in the test.
来自同一数据源[1]。测试报告必须指明参与测试的虚拟客户端和虚拟服务器的数量。
While the function of a firewall is to enforce access control policies, the criteria by which those policies are defined vary depending on the implementation. Firewalls may use network layer, transport layer or, in many cases, application-layer criteria to make access-control decisions.
虽然防火墙的功能是强制执行访问控制策略，但定义这些策略的标准因实现而异。防火墙可以使用网络层、传输层，或者在许多情况下，使用应用层标准来做出访问控制决策。
For the purposes of benchmarking firewall performance, this document references HTTP 1.1 or higher as the application layer entity. The methodologies MAY be used as a template for benchmarking with other applications. Since testing may involve proxy based DUT/SUTs, HTTP version considerations are discussed in appendix A.
为了对防火墙性能进行基准测试，本文档引用HTTP 1.1或更高版本作为应用层实体。这些方法可以用作与其他应用程序进行基准测试的模板。由于测试可能涉及基于代理的DUT/SUT，HTTP版本注意事项在附录A中讨论。
Since the number of interfaces are not fixed, the traffic flows will be dependent upon the configuration used in benchmarking the DUT/SUT. Note that the term "traffic flows" is associated with client-to-server requests.
由于接口的数量不是固定的，因此流量将取决于DUT/SUT基准测试中使用的配置。请注意，术语“流量”与客户端到服务器的请求相关联。
For Dual-Homed configurations, there are two unique traffic flows:
对于双宿配置，有两种独特的流量：
Client Server
------ ------
Protected -> Unprotected
Unprotected -> Protected
Client Server
------ ------
Protected -> Unprotected
Unprotected -> Protected
For Tri-Homed configurations, there are three unique traffic flows:
对于三宿配置，有三种独特的流量：
Client Server
------ ------
Protected -> Unprotected
Protected -> DMZ
Unprotected -> DMZ
Client Server
------ ------
Protected -> Unprotected
Protected -> DMZ
Unprotected -> DMZ
One or more clients may target multiple servers for a given application. Each virtual client MUST initiate connections in a round-robin fashion. For example, if the test consisted of six virtual clients targeting three servers, the pattern would be as follows:
一个或多个客户端可以针对给定应用程序的多个服务器。每个虚拟客户端必须以循环方式启动连接。例如，如果测试由六个针对三台服务器的虚拟客户端组成，则模式如下：
Client Target Server (In order of request) #1 1 2 3 1... #2 2 3 1 2... #3 3 1 2 3... #4 1 2 3 1... #5 2 3 1 2... #6 3 1 2 3...
客户端目标服务器（按请求顺序）#1 3 1#2 2 3 1 2... #3 3 1 2 3... #4 1 2 3 1... #5 2 3 1 2... #6 3 1 2 3...
Many firewalls implement network address translation (NAT) [1], a function which translates private internet addresses to public internet addresses. This involves additional processing on the part of the DUT/SUT and may impact performance. Therefore, tests SHOULD be ran with NAT disabled and NAT enabled to determine the performance differential, if any. The test report MUST indicate whether NAT was enabled or disabled.
许多防火墙实现网络地址转换（NAT）[1]，这是一种将专用internet地址转换为公用internet地址的功能。这涉及DUT/SUT部分的额外处理，可能会影响性能。因此，应在禁用NAT和启用NAT的情况下运行测试，以确定性能差异（如果有）。测试报告必须指明NAT是启用还是禁用的。
Rule sets [1] are a collection of access control policies that determine which packets the DUT/SUT will forward and which it will reject [1]. Since criteria by which these access control policies may be defined will vary depending on the capabilities of the DUT/SUT, the following is limited to providing guidelines for configuring rule sets when benchmarking the performance of the DUT/SUT.
规则集[1]是访问控制策略的集合，用于确定DUT/SUT将转发哪些数据包以及拒绝哪些数据包[1]。由于可定义这些访问控制策略的标准将根据DUT/SUT的能力而有所不同，因此以下仅限于提供在对DUT/SUT的性能进行基准测试时配置规则集的指南。
It is RECOMMENDED that a rule be entered for each host (Virtual client). In addition, testing SHOULD be performed using different size rule sets to determine its impact on the performance of the DUT/SUT. Rule sets MUST be configured in a manner, such that, rules associated with actual test traffic are configured at the end of the rule set and not at the beginning.
建议为每个主机（虚拟客户端）输入一条规则。此外，应使用不同的大小规则集进行测试，以确定其对DUT/SUT性能的影响。必须以这样的方式配置规则集：与实际测试流量相关联的规则在规则集的末尾配置，而不是在开始配置。
The DUT/SUT SHOULD be configured to deny access to all traffic which was not previously defined in the rule set. The test report SHOULD include the DUT/SUT configured rule set(s).
DUT/SUT应配置为拒绝访问以前未在规则集中定义的所有流量。测试报告应包括DUT/SUT配置的规则集。
Some firewalls include caching agents to reduce network load. When making a request through a caching agent, the caching agent attempts to service the response from its internal memory. The cache itself saves responses it receives, such as responses for HTTP GET requests. Testing SHOULD be performed with any caching agents on the DUT/SUT disabled.
一些防火墙包括缓存代理以减少网络负载。当通过缓存代理发出请求时，缓存代理会尝试从其内部内存为响应提供服务。缓存本身保存它接收的响应，例如HTTP GET请求的响应。应在禁用DUT/SUT上的任何缓存代理的情况下执行测试。
Access control may involve authentication processes such as user, client or session authentication. Authentication is usually performed by devices external to the firewall itself, such as an authentication server(s) and may add to the latency of the system. Any authentication processes MUST be included as part of connection setup process.
访问控制可能涉及身份验证过程，例如用户、客户端或会话身份验证。身份验证通常由防火墙本身外部的设备执行，例如身份验证服务器，并且可能会增加系统的延迟。任何身份验证过程都必须包含在连接设置过程中。
Some test instruments allow configuration of one or more TCP stack parameters, thereby influencing the traffic flows which will be offered and impacting performance measurements. While this document does not attempt to specify which TCP parameters should be configurable, any such TCP parameter(s) MUST be noted in the test report. In addition, when comparing multiple DUT/SUTs, the same TCP parameters MUST be used.
一些测试仪器允许配置一个或多个TCP堆栈参数，从而影响将提供的流量并影响性能测量。虽然本文档未试图指定哪些TCP参数应可配置，但必须在测试报告中注明任何此类TCP参数。此外，在比较多个DUT/SUT时，必须使用相同的TCP参数。
To determine the throughput of network-layer data traversing the DUT/SUT, as defined in RFC 1242 [3]. Note that while RFC 1242 uses the term frames, which is associated with the link layer, the procedure uses the term packets, since it is referencing the network layer.
确定穿过DUT/SUT的网络层数据的吞吐量，如RFC 1242[3]中所定义。注意，尽管RFC 1242使用与链路层相关联的术语帧，但是该过程使用术语分组，因为它引用网络层。
The following parameters MUST be defined:
必须定义以下参数：
Packet size - Number of bytes in the IP packet, exclusive of any link layer header or checksums.
数据包大小—IP数据包中的字节数，不包括任何链路层头或校验和。
Test Duration - Duration of the test, expressed in seconds.
测试持续时间-测试持续时间，以秒为单位。
The test instrument MUST offer unicast IP packets to the DUT/SUT at a constant rate. The test MAY consist of either bi-directional or unidirectional traffic; for example, an emulated client may offer a unicast stream of packets to an emulated server, or the test instrument may simulate a client/server exchange by offering bidirectional traffic.
测试仪器必须以恒定速率向DUT/SUT提供单播IP数据包。测试可包括双向或单向交通；例如，模拟客户端可以向模拟服务器提供数据包的单播流，或者测试仪器可以通过提供双向通信来模拟客户端/服务器交换。
This test will employ an iterative search algorithm. Each iteration will involve the test instrument varying the intended load until the maximum rate, at which no packet loss occurs, is found. Since backpressure mechanisms may be employed, resulting in the intended load and offered load being different, the test SHOULD be performed in either a packet based or time based manner as described in RFC 2889 [5]. As with RFC 1242, the term packet is used in place of frame. The duration of the test portion of each trial MUST be at least 30 seconds.
该测试将采用迭代搜索算法。每次迭代将涉及测试仪器改变预期负载，直到找到最大速率，在该速率下不会发生数据包丢失。由于可能采用背压机制，导致预期负载和提供的负载不同，因此应按照RFC 2889[5]中所述的基于分组或基于时间的方式进行测试。与RFC 1242一样，使用术语分组代替帧。每次试验的试验部分的持续时间必须至少为30秒。
It is RECOMMENDED to perform the throughput measurements with different packet sizes. When testing with different packet sizes the DUT/SUT configuration MUST remain the same.
建议使用不同的数据包大小进行吞吐量测量。当使用不同的数据包大小进行测试时，DUT/SUT配置必须保持不变。
Throughput: Maximum offered load, expressed in either bits per second or packets per second, at which no packet loss is detected. The bits to be counted are in the IP packet (header plus payload); other fields, such as link-layer headers and trailers, MUST NOT be included in the measurement.
吞吐量：提供的最大负载，以比特/秒或数据包/秒表示，在该负载下未检测到数据包丢失。要计数的比特在IP分组中（报头加有效载荷）；其他字段，如链路层标头和拖车，不得包含在测量中。
Forwarding Rate: Forwarding rate, expressed in either bits per second or packets per second, the device is observed to successfully forward to the correct destination interface in response to a specified offered load. The bits to be counted are in the IP packet (header plus payload); other fields, such as link-layer headers and trailers, MUST NOT be included in the measurement.
转发速率：转发速率，以比特/秒或数据包/秒表示，观察到设备响应指定的提供负载成功转发到正确的目标接口。要计数的比特在IP分组中（报头加有效载荷）；其他字段，如链路层标头和拖车，不得包含在测量中。
The test report MUST note the packet size(s), test duration, throughput and forwarding rate. In addition, the test report MUST conform to the reporting requirements set in section 4, Test Setup. If the test involved offering packets which target more than one segment (Protected, Unprotected or DMZ), the report MUST identify the results as an aggregate throughput measurement.
测试报告必须注明数据包大小、测试持续时间、吞吐量和转发速率。此外，试验报告必须符合第4节“试验设置”中规定的报告要求。如果测试涉及提供针对多个段（受保护、未受保护或DMZ）的数据包，则报告必须将结果标识为聚合吞吐量度量。
The throughput results SHOULD be reported in the format of a table with a row for each of the tested packet sizes. There SHOULD be columns for the packet size, the intended load, the offered load, resultant throughput and forwarding rate for each test.
吞吐量结果应以表格的形式报告，每个测试数据包大小对应一行。对于每个测试，应该有数据包大小、预期负载、提供的负载、结果吞吐量和转发率列。
The intermediate results of the search algorithm MAY be saved in log file which includes the packet size, test duration and for each iteration:
搜索算法的中间结果可保存在日志文件中，其中包括数据包大小、测试持续时间和每次迭代的时间：
- Step Iteration - Pass/Fail Status - Total packets offered - Total packets forwarded - Intended load - Offered load (If applicable) - Forwarding rate
- 步骤迭代-通过/失败状态-提供的数据包总数-转发的数据包总数-预期负载-提供的负载（如果适用）-转发速率
To determine the maximum number of concurrent TCP connections supported through or with the DUT/SUT, as defined in RFC 2647 [1]. This test is intended to find the maximum number of entries the DUT/SUT can store in its connection table.
根据RFC 2647[1]中的定义，确定通过DUT/SUT或与DUT/SUT支持的最大并发TCP连接数。该测试旨在找出DUT/SUT可存储在其连接表中的最大条目数。
The following parameters MUST be defined for all tests:
必须为所有测试定义以下参数：
Connection Attempt Rate: The aggregate rate, expressed in connections per second, at which TCP connection requests are attempted. The rate SHOULD be set at or lower than the maximum rate at which the DUT/SUT can accept connection requests.
连接尝试速率：尝试TCP连接请求的聚合速率，以每秒连接数表示。速率应设置为或低于DUT/SUT可接受连接请求的最大速率。
Aging Time: The time, expressed in seconds, the DUT/SUT will keep a connection in its connection table after receiving a TCP FIN or RST packet.
老化时间：DUT/SUT在收到TCP FIN或RST数据包后在其连接表中保持连接的时间，以秒为单位。
Validation Method: HTTP 1.1 or higher MUST be used for this test for both clients and servers. The client and server MUST use the same HTTP version.
验证方法：对于客户端和服务器，此测试必须使用HTTP 1.1或更高版本。客户端和服务器必须使用相同的HTTP版本。
Object Size: Defines the number of bytes, excluding any bytes associated with the HTTP header, to be transferred in response to an HTTP 1.1 or higher GET request.
对象大小：定义响应HTTP 1.1或更高版本的GET请求而传输的字节数，不包括与HTTP头关联的任何字节。
This test will employ an iterative search algorithm to determine the maximum number of concurrent TCP connections supported through or with the DUT/SUT.
该测试将采用迭代搜索算法来确定通过DUT/SUT或与DUT/SUT一起支持的最大并发TCP连接数。
For each iteration, the aggregate number of concurrent TCP connections attempted by the virtual client(s) will be varied. The destination address will be that of the server or that of the NAT proxy. The aggregate rate will be defined by connection attempt rate, and will be attempted in a round-robin fashion (See 4.5).
对于每个迭代，虚拟客户端尝试的并发TCP连接的总数将有所不同。目标地址将是服务器的地址或NAT代理的地址。聚合速率将由连接尝试速率定义，并将以循环方式进行尝试（见4.5）。
To validate all connections, the virtual client(s) MUST request an object using an HTTP 1.1 or higher GET request. The requests MUST be initiated on each connection after all of the TCP connections have been established.
要验证所有连接，虚拟客户端必须使用HTTP 1.1或更高版本的GET请求请求对象。所有TCP连接建立后，必须在每个连接上启动请求。
When testing proxy-based DUT/SUTs, the virtual client(s) MUST request two objects using HTTP 1.1 or higher GET requests. The first GET request is required for connection time establishment [1] measurements as specified in appendix B. The second request is used for validation as previously mentioned. When comparing proxy and non-proxy based DUT/SUTs, the test MUST be performed in the same manner.
测试基于代理的DUT/SUT时，虚拟客户端必须使用HTTP 1.1或更高版本的GET请求请求两个对象。第一个GET请求用于附录B中规定的连接时间建立[1]测量。第二个请求用于验证，如前所述。当比较基于代理和非代理的DUT/SUT时，必须以相同的方式执行测试。
Between each iteration, it is RECOMMENDED that the test instrument issue a TCP RST referencing each connection attempted for the previous iteration, regardless of whether or not the connection attempt was successful. The test instrument will wait for aging time before continuing to the next iteration.
在每次迭代之间，建议测试仪器发出一个TCP RST，引用上一次迭代尝试的每个连接，无论连接尝试是否成功。测试仪器将等待老化时间，然后继续下一次迭代。
Number of objects requested
请求的对象数
Number of objects returned
返回的对象数
Maximum concurrent connections: Total number of TCP connections open for the last successful iteration performed in the search algorithm.
最大并发连接数：在搜索算法中执行的最后一次成功迭代中打开的TCP连接总数。
Minimum connection establishment time: Lowest TCP connection establishment time measured, as defined in appendix B.
最小连接建立时间：测量的最小TCP连接建立时间，如附录B中所定义。
Maximum connection establishment time: Highest TCP connection establishment time measured, as defined in appendix B.
最大连接建立时间：测量的最高TCP连接建立时间，如附录B中所定义。
Average connection establishment time: The mean of all measurements of connection establishment times.
平均连接建立时间：连接建立时间的所有测量值的平均值。
Aggregate connection establishment time: The total of all measurements of connection establishment times.
聚合连接建立时间：连接建立时间的所有度量的总和。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须符合第4节“测试设置”中规定的报告要求。
5.2.5.1 Application-Layer Reporting:
5.2.5.1 应用程序层报告：
The test report MUST note the object size, number of completed requests and number of completed responses.
测试报告必须注明对象大小、已完成请求的数量和已完成响应的数量。
The intermediate results of the search algorithm MAY be reported in a tabular format with a column for each iteration. There SHOULD be rows for the number of requests attempted, number and percentage requests completed, number of responses attempted, number and percentage of responses completed. The table MAY be combined with the transport-layer reporting, provided that the table identify this as an application layer measurement.
搜索算法的中间结果可以以表格格式报告，每次迭代都有一列。应该有行显示尝试的请求数、完成的请求数和百分比、尝试的响应数、完成的响应数和百分比。该表可与传输层报告相结合，前提是该表将其标识为应用层测量。
Version information: The test report MUST note the version of HTTP client(s) and server(s).
版本信息：测试报告必须注明HTTP客户端和服务器的版本。
5.2.5.2 Transport-Layer Reporting:
5.2.5.2 传输层报告：
The test report MUST note the connection attempt rate, aging time, minimum TCP connection establishment time, maximum TCP connection establishment time, average connection establishment time, aggregate connection establishment time and maximum concurrent connections measured.
测试报告必须记录连接尝试率、老化时间、最小TCP连接建立时间、最大TCP连接建立时间、平均连接建立时间、聚合连接建立时间和测量的最大并发连接。
The intermediate results of the search algorithm MAY be reported in the format of a table with a column for each iteration. There SHOULD be rows for the total number of TCP connections attempted, number and percentage of TCP connections completed, minimum TCP connection establishment time, maximum TCP connection establishment time, average connection establishment time and the aggregate connection establishment time.
搜索算法的中间结果可以以表格的形式报告，每个迭代都有一列。应包含尝试的TCP连接总数、完成的TCP连接数和百分比、最小TCP连接建立时间、最大TCP连接建立时间、平均连接建立时间和总连接建立时间的行。
To determine the maximum TCP connection establishment rate through or with the DUT/SUT, as defined by RFC 2647 [1]. This test is intended to find the maximum rate the DUT/SUT can update its connection table.
根据RFC 2647[1]的定义，确定通过DUT/SUT或与DUT/SUT建立TCP连接的最大速率。本测试旨在确定DUT/SUT更新其连接表的最大速率。
The following parameters MUST be defined for all tests:
必须为所有测试定义以下参数：
Number of Connections: Defines the aggregate number of TCP connections that must be established.
连接数：定义必须建立的TCP连接的总数。
Aging Time: The time, expressed in seconds, the DUT/SUT will keep a connection in it's state table after receiving a TCP FIN or RST packet.
老化时间：DUT/SUT在收到TCP FIN或RST数据包后将在其状态表中保持连接的时间，以秒为单位。
Validation Method: HTTP 1.1 or higher MUST be used for this test for both clients and servers. The client and server MUST use the same HTTP version.
验证方法：对于客户端和服务器，此测试必须使用HTTP 1.1或更高版本。客户端和服务器必须使用相同的HTTP版本。
Object Size: Defines the number of bytes, excluding any bytes associated with the HTTP header, to be transferred in response to an HTTP 1.1 or higher GET request.
对象大小：定义响应HTTP 1.1或更高版本的GET请求而传输的字节数，不包括与HTTP头关联的任何字节。
This test will employ an iterative search algorithm to determine the maximum rate at which the DUT/SUT can accept TCP connection requests.
该测试将采用迭代搜索算法来确定DUT/SUT可以接受TCP连接请求的最大速率。
For each iteration, the aggregate rate at which TCP connection requests are attempted by the virtual client(s) will be varied. The destination address will be that of the server or that of the NAT proxy. The aggregate number of connections, defined by number of connections, will be attempted in a round-robin fashion (See 4.5).
对于每个迭代，虚拟客户端尝试TCP连接请求的聚合速率将有所不同。目标地址将是服务器的地址或NAT代理的地址。将以循环方式尝试由连接数定义的连接总数（见4.5）。
The same application-layer object transfers required for validation and establishment time measurements as described in the concurrent TCP connection capacity test MUST be performed.
必须执行并发TCP连接容量测试中描述的验证和建立时间测量所需的相同应用层对象传输。
Between each iteration, it is RECOMMENDED that the test instrument issue a TCP RST referencing each connection attempted for the previous iteration, regardless of whether or not the connection attempt was successful. The test instrument will wait for aging time before continuing to the next iteration.
在每次迭代之间，建议测试仪器发出一个TCP RST，引用上一次迭代尝试的每个连接，无论连接尝试是否成功。测试仪器将等待老化时间，然后继续下一次迭代。
Number of objects requested
请求的对象数
Number of objects returned
返回的对象数
Highest connection rate: Highest rate, in connections per second, for which all connections successfully opened in the search algorithm.
最高连接速率：在搜索算法中成功打开所有连接的最高速率，以每秒连接数为单位。
Minimum connection establishment time: Lowest TCP connection establishment time measured, as defined in appendix B.
最小连接建立时间：测量的最小TCP连接建立时间，如附录B中所定义。
Maximum connection establishment time: Highest TCP connection establishment time measured, as defined in appendix B.
最大连接建立时间：测量的最高TCP连接建立时间，如附录B中所定义。
Average connection establishment time: The mean of all measurements of connection establishment times.
平均连接建立时间：连接建立时间的所有测量值的平均值。
Aggregate connection establishment time: The total of all measurements of connection establishment times.
聚合连接建立时间：连接建立时间的所有度量的总和。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须符合第4节“测试设置”中规定的报告要求。
5.3.5.1 Application-Layer Reporting:
5.3.5.1 应用程序层报告：
The test report MUST note object size(s), number of completed requests and number of completed responses.
测试报告必须注明对象大小、已完成请求数和已完成响应数。
The intermediate results of the search algorithm MAY be reported in a tabular format with a column for each iteration. There SHOULD be rows for the number of requests attempted, number and percentage requests completed, number of responses attempted, number and
搜索算法的中间结果可以以表格格式报告，每次迭代都有一列。应该有行显示尝试的请求数、完成的请求数和百分比、尝试的响应数、请求数和百分比
percentage of responses completed. The table MAY be combined with the transport-layer reporting, provided that the table identify this as an application layer measurement.
完成答复的百分比。该表可与传输层报告相结合，前提是该表将其标识为应用层测量。
Version information: The test report MUST note the version of HTTP client(s) and server(s).
版本信息：测试报告必须注明HTTP客户端和服务器的版本。
5.3.5.2 Transport-Layer Reporting:
5.3.5.2 传输层报告：
The test report MUST note the number of connections, aging time, minimum TCP connection establishment time, maximum TCP connection establishment time, average connection establishment time, aggregate connection establishment time and highest connection rate measured.
测试报告必须记录连接数、老化时间、最小TCP连接建立时间、最大TCP连接建立时间、平均连接建立时间、聚合连接建立时间和测量的最高连接率。
The intermediate results of the search algorithm MAY be reported in the format of a table with a column for each iteration. There SHOULD be rows for the connection attempt rate, total number of TCP connections attempted, total number of TCP connections completed, minimum TCP connection establishment time, maximum TCP connection establishment time, average connection establishment time and the aggregate connection establishment time.
搜索算法的中间结果可以以表格的形式报告，每个迭代都有一列。应该有连接尝试率、尝试的TCP连接总数、完成的TCP连接总数、最小TCP连接建立时间、最大TCP连接建立时间、平均连接建立时间和总连接建立时间的行。
To determine the maximum TCP connection tear down rate through or with the DUT/SUT, as defined by RFC 2647 [1].
根据RFC 2647[1]的定义，确定通过DUT/SUT或与DUT/SUT的最大TCP连接中断率。
Number of Connections: Defines the number of TCP connections that will be attempted to be torn down.
连接数：定义将尝试断开的TCP连接数。
Aging Time: The time, expressed in seconds, the DUT/SUT will keep a connection in it's state table after receiving a TCP FIN or RST packet.
老化时间：DUT/SUT在收到TCP FIN或RST数据包后将在其状态表中保持连接的时间，以秒为单位。
Close Method: Defines method for closing TCP connections. The test MUST be performed with either a three-way or four-way handshake. In a four-way handshake, each side sends separate FIN and ACK messages. In a three-way handshake, one side sends a combined FIN/ACK message upon receipt of a FIN.
Close Method：定义关闭TCP连接的方法。测试必须通过三向或四向握手进行。在四向握手中，每一方发送单独的FIN和ACK消息。在三向握手中，一方在收到FIN后发送组合FIN/ACK消息。
Close Direction: Defines whether closing of connections are to be initiated from the client or from the server.
关闭方向：定义是从客户端还是从服务器开始关闭连接。
This test will employ an iterative search algorithm to determine the maximum TCP connection tear down rate supported by the DUT/SUT. The test iterates through different TCP connection tear down rates with a fixed number of TCP connections.
该测试将采用迭代搜索算法来确定DUT/SUT支持的最大TCP连接中断率。该测试使用固定数量的TCP连接迭代不同的TCP连接断开率。
In the case of proxy based DUT/SUTs, the DUT/SUT will itself receive the ACK in response to issuing a FIN packet to close its side of the TCP connection. For validation purposes, the virtual client or server, whichever is applicable, MAY verify that the DUT/SUT received the final ACK by re-transmitting the final ACK. A TCP RST should be received in response to the retransmitted ACK.
在基于代理的DUT/SUT的情况下，DUT/SUT自身将接收ACK，以响应发出FIN数据包以关闭其TCP连接侧。出于验证目的，虚拟客户端或服务器（以适用者为准）可通过重新发送最终ACK来验证DUT/SUT是否接收到最终ACK。应接收TCP RST以响应重新传输的ACK。
Between each iteration, it is RECOMMENDED that the virtual client(s) or server(s), whichever is applicable, issue a TCP RST referencing each connection which was attempted to be torn down, regardless of whether or not the connection tear down attempt was successful. The test will wait for aging time before continuing to the next iteration.
在每次迭代之间，建议虚拟客户机或服务器（以适用的为准）发出一个TCP RST，引用尝试断开的每个连接，无论连接断开尝试是否成功。测试将等待老化时间，然后继续下一次迭代。
Highest connection tear down rate: Highest rate, in connections per second, for which all TCP connections were successfully torn down in the search algorithm.
最高连接断开率：在搜索算法中成功断开所有TCP连接的最高速率，以每秒连接数为单位。
The following tear down time [1] measurements MUST only include connections for which both sides of the connection were successfully torn down. For example, tear down times for connections which are left in a FINWAIT-2 [8] state should not be included:
以下拆卸时间[1]测量必须仅包括已成功拆卸连接两侧的连接。例如，不应包括处于FINWAIT-2[8]状态的连接的断开时间：
Minimum connection tear down time: Lowest TCP connection tear down time measured as defined in appendix C.
最小连接中断时间：按照附录C中的定义测量的最小TCP连接中断时间。
Maximum connection tear down time: Highest TCP connection tear down time measured as defined in appendix C.
最大连接中断时间：按照附录C中的定义测量的最高TCP连接中断时间。
Average connection tear down time: The mean of all measurements of connection tear down times.
平均连接中断时间：所有连接中断时间测量值的平均值。
Aggregate connection tear down time: The total of all measurements of connection tear down times.
聚合连接断开时间：连接断开时间的所有测量值的总和。
The test report MUST note the number of connections, aging time, close method, close direction, minimum TCP connection tear down time, maximum TCP connection tear down time, average TCP connection tear down time and the aggregate TCP connection tear down time and highest connection tear down rate measured. In addition, the test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须记录连接数、老化时间、关闭方法、关闭方向、最小TCP连接中断时间、最大TCP连接中断时间、平均TCP连接中断时间以及测量的聚合TCP连接中断时间和最高连接中断率。此外，试验报告必须符合第4节“试验设置”中规定的报告要求。
The intermediate results of the search algorithm MAY be reported in the format of a table with a column for each iteration. There SHOULD be rows for the number of TCP tear downs attempted, number and percentage of TCP connection tear downs completed, minimum TCP connection tear down time, maximum TCP connection tear down time, average TCP connection tear down time, aggregate TCP connection tear down time and validation failures, if required.
搜索算法的中间结果可以以表格的形式报告，每个迭代都有一列。如果需要，应该有行记录尝试的TCP断开次数、完成的TCP连接断开次数和百分比、最小TCP连接断开时间、最大TCP连接断开时间、平均TCP连接断开时间、聚合TCP连接断开时间和验证失败。
To determine the effect of a denial of service attack on a DUT/SUT TCP connection establishment and/or HTTP transfer rates. The denial of service handling test MUST be run after obtaining baseline measurements from sections 5.3 and/or 5.6.
确定拒绝服务攻击对DUT/SUT TCP连接建立和/或HTTP传输速率的影响。拒绝服务处理测试必须在从第5.3节和/或第5.6节获得基线测量值后运行。
The TCP SYN flood attack exploits TCP's three-way handshake mechanism by having an attacking source host generate TCP SYN packets with random source addresses towards a victim host, thereby consuming that host's resources.
TCP SYN flood攻击利用TCP的三方握手机制，让攻击源主机向受害主机生成具有随机源地址的TCP SYN数据包，从而消耗该主机的资源。
Use the same setup parameters as defined in section 5.3.2 or 5.6.2, depending on whether testing against the baseline TCP connection establishment rate test or HTTP transfer rate test, respectfully.
使用第5.3.2节或第5.6.2节中定义的相同设置参数，具体取决于是根据基线TCP连接建立速率测试还是HTTP传输速率测试进行测试。
In addition, the following setup parameters MUST be defined:
此外，必须定义以下设置参数：
SYN attack rate: Rate, expressed in packets per second, at which the server(s) or NAT proxy address is targeted with TCP SYN packets.
SYN攻击速率：TCP SYN数据包以服务器或NAT代理地址为目标的速率，以每秒数据包数表示。
Use the same procedure as defined in section 5.3.3 or 5.6.3, depending on whether testing against the baseline TCP connection establishment rate or HTTP transfer rate test, respectfully. In addition, the test instrument will generate TCP SYN packets targeting the server(s) IP address or NAT proxy address at a rate defined by SYN attack rate.
使用第5.3.3节或第5.6.3节中定义的相同程序，具体取决于是根据基线TCP连接建立率测试还是HTTP传输率测试进行测试。此外，测试仪器将以SYN攻击率定义的速率生成以服务器IP地址或NAT代理地址为目标的TCP SYN数据包。
The test instrument originating the TCP SYN attack MUST be attached to the unprotected network. In addition, the test instrument MUST not respond to the SYN/ACK packets sent by target server or NAT proxy in response to the SYN packet.
发起TCP SYN攻击的测试仪器必须连接到未受保护的网络。此外，测试仪器不得响应目标服务器或NAT代理为响应SYN数据包而发送的SYN/ACK数据包。
Some firewalls employ mechanisms to guard against SYN attacks. If such mechanisms exist on the DUT/SUT, tests SHOULD be run with these mechanisms enabled and disabled to determine how well the DUT/SUT can maintain, under such attacks, the baseline connection establishment rates and HTTP transfer rates determined in section 5.3 and section 5.6, respectively.
有些防火墙采用机制来防范SYN攻击。如果DUT/SUT上存在此类机制，则应在启用和禁用这些机制的情况下运行测试，以确定DUT/SUT在此类攻击下能够维持的基线连接建立速率和HTTP传输速率分别在第5.3节和第5.6节中确定。
Perform the same measurements as defined in section 5.3.4 or 5.6.4, depending on whether testing against the baseline TCP connection establishment rate test or HTTP transfer rate, respectfully.
执行第5.3.4节或第5.6.4节中定义的相同测量，具体取决于是根据基线TCP连接建立速率测试还是HTTP传输速率进行测试。
In addition, the test instrument SHOULD track TCP SYN packets associated with the SYN attack which the DUT/SUT forwards on the protected or DMZ interface(s).
此外，测试仪器应跟踪与DUT/SUT在受保护或DMZ接口上转发的SYN攻击相关的TCP SYN数据包。
The test SHOULD use the same reporting format as described in section 5.3.5 or 5.6.5, depending on whether testing against the baseline TCP connection establishment rate test or HTTP transfer rate, respectfully.
测试应使用第5.3.5节或第5.6.5节所述的相同报告格式，具体取决于测试是针对基线TCP连接建立速率测试还是HTTP传输速率。
In addition, the report MUST indicate a denial of service handling test, SYN attack rate, number of TCP SYN attack packets transmitted and the number of TCP SYN attack packets forwarded by the DUT/SUT. The report MUST indicate whether or not the DUT has any SYN attack mechanisms enabled.
此外，报告必须说明拒绝服务处理测试、SYN攻击率、传输的TCP SYN攻击数据包数量以及DUT/SUT转发的TCP SYN攻击数据包数量。报告必须指出DUT是否启用了任何SYN攻击机制。
To determine the transfer rate of HTTP requested object traversing the DUT/SUT.
确定HTTP请求对象穿越DUT/SUT的传输速率。
The following parameters MUST be defined for all tests:
必须为所有测试定义以下参数：
Number of connections: Defines the aggregate number of connections attempted. The number SHOULD be a multiple of the number of virtual clients participating in the test.
连接数：定义尝试的连接总数。该数字应该是参与测试的虚拟客户端数量的倍数。
Close Method: Defines the method for closing TCP connections. The test MUST be performed with either a three-way or four-way handshake. In a four-way handshake, each side sends separate FIN and ACK messages. In a three-way handshake, one side sends a combined FIN/ACK message upon receipt of a FIN.
Close Method：定义关闭TCP连接的方法。测试必须通过三向或四向握手进行。在四向握手中，每一方发送单独的FIN和ACK消息。在三向握手中，一方在收到FIN后发送组合FIN/ACK消息。
Close Direction: Defines whether closing of connections are to be initiated from the client or from the server.
关闭方向：定义是从客户端还是从服务器开始关闭连接。
Session Type: The virtual clients/servers MUST use HTTP 1.1 or higher. The client and server MUST use the same HTTP version.
会话类型：虚拟客户端/服务器必须使用HTTP 1.1或更高版本。客户端和服务器必须使用相同的HTTP版本。
GET requests per connection: Defines the number of HTTP 1.1 or higher GET requests attempted per connection.
每个连接获取请求：定义每个连接尝试的HTTP 1.1或更高版本的获取请求数。
Object Size: Defines the number of bytes, excluding any bytes associated with the HTTP header, to be transferred in response to an HTTP 1.1 or higher GET request.
对象大小：定义响应HTTP 1.1或更高版本的GET请求而传输的字节数，不包括与HTTP头关联的任何字节。
Each HTTP 1.1 or higher virtual client will request one or more objects from an HTTP 1.1 or higher server using one or more HTTP GET requests over each connection. The aggregate number of connections attempted, defined by number of connections, MUST be evenly divided among all of the participating virtual clients.
每个HTTP 1.1或更高版本的虚拟客户端将通过每个连接使用一个或多个HTTP GET请求从HTTP 1.1或更高版本的服务器请求一个或多个对象。尝试的连接总数（由连接数定义）必须平均分配给所有参与的虚拟客户端。
If the virtual client(s) make multiple HTTP GET requests per connection, it MUST request the same object size for each GET request. Multiple iterations of this test may be run with objects of different sizes.
如果虚拟客户端对每个连接发出多个HTTP GET请求，则它必须为每个GET请求请求相同的对象大小。可以使用不同大小的对象运行此测试的多次迭代。
Average Transfer Rate : The average transfer rate of the DUT/SUT MUST be measured and shall be referenced to the requested object(s). The measurement will start on transmission of the first bit of the first requested object and end on transmission of the last bit of the last requested object. The average transfer rate, in bits per second, will be calculated using the following formula:
平均传输速率：必须测量DUT/SUT的平均传输速率，并应参考请求的对象。测量将在传输第一个请求对象的第一位时开始，并在传输最后一个请求对象的最后一位时结束。平均传输速率（以比特/秒为单位）将使用以下公式计算：
OBJECTS * OBJECTSIZE * 8
TRANSFER RATE (bit/s) = --------------------------
DURATION
OBJECTS * OBJECTSIZE * 8
TRANSFER RATE (bit/s) = --------------------------
DURATION
OBJECTS - Total number of objects successfully transferred across all connections.
对象-在所有连接中成功传输的对象总数。
OBJECTSIZE - Object size in bytes
OBJECTSIZE—对象大小（字节）
DURATION - Aggregate transfer time based on aforementioned time references.
持续时间-基于上述时间参考的总传输时间。
The following measurements SHOULD be performed for each connection-oriented protocol:
应对每个面向连接的协议执行以下测量：
Goodput [1]: Goodput as defined in section 3.17 of RFC 2647. Measurements MUST only reference the protocol payload, excluding any of the protocol header. In addition, the test instrument MUST exclude any bits associated with the connection establishment, connection tear down, security associations [1] or connection maintenance [1].
Goodput[1]：RFC 2647第3.17节中定义的Goodput。测量必须仅参考协议有效负载，不包括任何协议头。此外，测试仪器必须排除与连接建立、连接中断、安全关联[1]或连接维护[1]相关的任何位。
Since connection-oriented protocols require that data be acknowledged, the offered load [4] will be varying. Therefore, the test instrument should measure the average forwarding rate over the duration of the test. Measurement should start on transmission of the first bit of the payload of the first datagram and end on transmission of the last bit of the payload of the last datagram.
由于面向连接的协议要求确认数据，因此提供的负载[4]会有所不同。因此，测试仪器应测量测试期间的平均转发速率。测量应在传输第一个数据报的有效载荷的第一位时开始，并在传输最后一个数据报的有效载荷的最后一位时结束。
Number of bytes transferred - Total payload bytes transferred.
传输的字节数-传输的总有效负载字节数。
Number of Timeouts - Total number of timeout events.
超时次数-超时事件的总数。
Retransmitted bytes - Total number of retransmitted bytes.
Retransmitted bytes—重新传输的字节总数。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须符合第4节“测试设置”中规定的报告要求。
The test report MUST note number of GET requests per connection and object size(s).
测试报告必须记录每个连接的GET请求数和对象大小。
The transfer rate results SHOULD be reported in tabular form with a column for each of the object sizes tested. There SHOULD be a row for the number and percentage of completed requests, number and percentage of completed responses, and the resultant transfer rate for each iteration of the test.
传输速率结果应以表格形式报告，并为每个测试对象尺寸列一列。应该有一行记录完成请求的数量和百分比、完成响应的数量和百分比，以及测试每次迭代的结果传输速率。
Failure analysis: The test report SHOULD indicate the number and percentage of HTTP GET request and responses that failed to complete.
失败分析：测试报告应该指出未能完成的HTTP GET请求和响应的数量和百分比。
Version information: The test report MUST note the version of HTTP client(s) and server(s).
版本信息：测试报告必须注明HTTP客户端和服务器的版本。
The test report MUST note the number of connections, close method, close direction and the protocol for which the measurement was made.
测试报告必须注明连接数量、闭合方法、闭合方向和测量协议。
The results SHOULD be reported in tabular form for each of the HTTP object sizes tested. There SHOULD be a row for the total bytes transferred, total timeouts, total retransmitted bytes and and resultant goodput. Note that total bytes refers to total datagram payload bytes transferred. The table MAY be combined with the
对于测试的每个HTTP对象大小，应以表格形式报告结果。应该有一行记录传输的总字节数、总超时数、总重传字节数和结果goodput。请注意，total bytes指传输的数据报有效负载字节总数。该表可与
application layer reporting, provided the table clearly identifies the protocol for which the measurement was made.
应用层报告，前提是该表清楚地标识了进行测量的协议。
Failure analysis: The test report SHOULD indicate the number and percentage of connection establishment failures as well as number and percentage of TCP tear down failures.
故障分析：测试报告应说明连接建立故障的数量和百分比，以及TCP中断故障的数量和百分比。
It is RECOMMENDED that the report include a graph to plot the distribution of both connection establishment failures and connection tear down failures. The x coordinate SHOULD be the elapsed test time, the y coordinate SHOULD be the number of failures for a given sampling period. There SHOULD be two lines on the graph, one for connection failures and one for tear down failures. The graph MUST note the sampling period.
建议报告中包含一个图表，以绘制连接建立故障和连接断开故障的分布。x坐标应为经过的测试时间，y坐标应为给定采样周期内的故障数。图表上应该有两条线，一条用于连接故障，另一条用于拆卸故障。图表必须注明采样周期。
Determine the maximum transaction rate the DUT/SUT can sustain. This test is intended to find the maximum rate at which users can access objects.
确定DUT/SUT可维持的最大事务速率。此测试旨在找到用户可以访问对象的最大速率。
Close Method: Defines method for closing TCP connections. The test MUST be performed with either a three-way or four-way handshake. In a four-way handshake, each side sends separate FIN and ACK messages. In a three-way handshake, one side sends a combined FIN/ACK message upon receipt of a FIN.
Close Method：定义关闭TCP连接的方法。测试必须通过三向或四向握手进行。在四向握手中，每一方发送单独的FIN和ACK消息。在三向握手中，一方在收到FIN后发送组合FIN/ACK消息。
Close Direction: Defines whether closing of connections are to be initiated from the client or from the server.
关闭方向：定义是从客户端还是从服务器开始关闭连接。
Session Type: HTTP 1.1 or higher MUST be used for this test. The client and server MUST use the same HTTP version.
会话类型：此测试必须使用HTTP 1.1或更高版本。客户端和服务器必须使用相同的HTTP版本。
Test Duration: Time, expressed in seconds, for which the virtual client(s) will sustain the attempted GET request rate. It is RECOMMENDED that the duration be at least 30 seconds.
测试持续时间：虚拟客户端将维持尝试获取请求速率的时间，以秒为单位。建议持续时间至少为30秒。
Requests per connection: Number of object requests per connection.
每个连接的请求数：每个连接的对象请求数。
Object Size: Defines the number of bytes, excluding any bytes associated with the HTTP header, to be transferred in response to an HTTP 1.1 or higher GET request.
对象大小：定义响应HTTP 1.1或更高版本的GET请求而传输的字节数，不包括与HTTP头关联的任何字节。
This test will employ an iterative search algorithm to determine the maximum transaction rate that the DUT/SUT can sustain.
该测试将采用迭代搜索算法来确定DUT/SUT能够维持的最大事务速率。
For each iteration, HTTP 1.1 or higher virtual client(s) will vary the aggregate GET request rate offered to HTTP 1.1 or higher server(s). The virtual client(s) will maintain the offered request rate for the defined test duration.
对于每个迭代，HTTP 1.1或更高版本的虚拟客户端将改变提供给HTTP 1.1或更高版本服务器的聚合GET请求速率。虚拟客户端将在定义的测试持续时间内保持提供的请求速率。
If the virtual client(s) make multiple HTTP GET requests per connection, it MUST request the same object size for each GET request. Multiple tests MAY be performed with different object sizes.
如果虚拟客户端对每个连接发出多个HTTP GET请求，则它必须为每个GET请求请求相同的对象大小。可以使用不同的对象大小执行多个测试。
Maximum Transaction Rate: The maximum rate at which all transactions, that is all requests/responses cycles, are completed.
最大事务速率：完成所有事务（即所有请求/响应周期）的最大速率。
Transaction Time: The test instrument SHOULD measure minimum, maximum and average transaction times. The transaction time will start when the virtual client issues the GET request and end when the requesting virtual client receives the last bit of the requested object.
事务时间：测试仪器应测量最小、最大和平均事务时间。事务时间将在虚拟客户端发出GET请求时开始，并在请求的虚拟客户端接收到请求对象的最后一位时结束。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须符合第4节“测试设置”中规定的报告要求。
The test report MUST note the test duration, object size, requests per connection, minimum transaction time, maximum transaction time, average transaction time and maximum transaction rate measured
测试报告必须记录测试持续时间、对象大小、每个连接的请求、最小事务时间、最大事务时间、平均事务时间和测量的最大事务速率
The intermediate results of the search algorithm MAY be reported in a table format with a column for each iteration. There SHOULD be rows for the GET request attempt rate, number of requests attempted, number and percentage of requests completed, number of responses attempted, number and percentage of responses completed, minimum transaction time, average transaction time and maximum transaction time.
搜索算法的中间结果可以以表格形式报告，每次迭代都有一列。应该有用于获取请求尝试率、尝试请求数、完成请求数和百分比、尝试响应数、完成响应数和百分比、最小事务时间、平均事务时间和最大事务时间的行。
Version information: The test report MUST note the version of HTTP client(s) and server(s).
版本信息：测试报告必须注明HTTP客户端和服务器的版本。
The test report MUST note the close method, close direction, number of connections established and number of connections torn down.
试验报告必须注明关闭方法、关闭方向、建立的连接数量和拆除的连接数量。
The intermediate results of the search algorithm MAY be reported in a table format with a column for each iteration. There SHOULD be rows for the number of connections attempted, number and percentage of connections completed, number and percentage of connection tear downs completed. The table MAY be combined with the application layer reporting, provided the table identify this as transport layer measurement.
搜索算法的中间结果可以以表格形式报告，每次迭代都有一列。应该有行记录尝试的连接数、完成的连接数和百分比、完成的连接断开数和百分比。该表可与应用层报告结合使用，前提是该表将其标识为传输层测量。
To characterize the behavior of the DUT/SUT when presented with a combination of both legal and Illegal [1] traffic. Note that Illegal traffic does not refer to an attack, but traffic which has been explicitly defined by a rule(s) to drop.
描述DUT/SUT在出现合法和非法[1]流量组合时的行为。请注意，非法流量不是指攻击，而是指由要丢弃的规则明确定义的流量。
Setup parameters will use the same parameters as specified in the HTTP transfer rate test (Section 5.6.2). In addition, the following setup parameters MUST be defined:
设置参数将使用HTTP传输速率测试（第5.6.2节）中指定的相同参数。此外，必须定义以下设置参数：
Illegal traffic percentage: Percentage of HTTP 1.1 or higher connections which have been explicitly defined in a rule(s) to drop.
非法流量百分比：在规则中明确定义要删除的HTTP 1.1或更高版本连接的百分比。
Each HTTP 1.1 or higher client will request one or more objects from an HTTP 1.1 or higher server using one or more HTTP GET requests over each connection. The aggregate number of connections attempted, defined by number of connections, MUST be evenly divided among all of the participating virtual clients.
每个HTTP 1.1或更高版本的客户端将通过每个连接使用一个或多个HTTP GET请求从HTTP 1.1或更高版本的服务器请求一个或多个对象。尝试的连接总数（由连接数定义）必须平均分配给所有参与的虚拟客户端。
The virtual client(s) MUST offer the connection requests, both legal and illegal, in an evenly distributed manner. Many firewalls have the capability to filter on different traffic criteria (IP addresses, Port numbers, etc.). Multiple iterations of this test MAY be run with the DUT/SUT configured to filter on different traffic criteria.
虚拟客户端必须以均匀分布的方式提供合法和非法的连接请求。许多防火墙能够根据不同的流量标准（IP地址、端口号等）进行过滤。该测试的多次迭代可在DUT/SUT配置为根据不同的流量标准进行过滤的情况下运行。
The same measurements as defined in HTTP transfer rate test (Section 5.6.4) SHOULD be performed. Any forwarding rate measurements MUST only include bits which are associated with legal traffic.
应执行HTTP传输速率测试（第5.6.4节）中定义的相同测量。任何转发速率测量必须仅包括与合法流量相关的位。
Test reporting format SHOULD be the same as specified in the HTTP transfer rate test (Section 5.6.5).
测试报告格式应与HTTP传输速率测试（第5.6.5节）中规定的格式相同。
In addition, the report MUST note the percentage of illegal HTTP connections.
此外，报告必须注意非法HTTP连接的百分比。
Failure analysis: Test report MUST note the number and percentage of illegal connections that were allowed by the DUT/SUT.
故障分析：测试报告必须注明DUT/SUT允许的非法连接的数量和百分比。
To determine the performance impact when the DUT/SUT is presented with IP fragmented traffic. IP packets which have been fragmented, due to crossing a network that supports a smaller MTU (Maximum Transmission Unit) than the actual IP packet, may require the firewall to perform re-assembly prior to the rule set being applied.
确定DUT/SUT呈现IP碎片流量时的性能影响。由于穿越支持比实际IP数据包更小MTU（最大传输单元）的网络而被分割的IP数据包可能要求防火墙在应用规则集之前执行重新组装。
While IP fragmentation is a common form of attack, either on the firewall itself or on internal hosts, this test will focus on determining how the additional processing associated with the re-assembly of the packets have on the forwarding rate of the DUT/SUT. RFC 1858 addresses some fragmentation attacks that get around IP filtering processes used in routers and hosts.
虽然IP碎片是防火墙本身或内部主机上常见的攻击形式，但本测试将重点确定与数据包重新组装相关的附加处理对DUT/SUT转发速率的影响。RFC1858解决了一些绕过路由器和主机中使用的IP过滤过程的碎片攻击。
The following parameters MUST be defined.
必须定义以下参数。
Setup parameters will be the same as defined in the HTTP transfer rate test (Sections 5.6.2.1 and 5.6.2.2).
设置参数与HTTP传输速率测试（第5.6.2.1节和第5.6.2.2节）中定义的参数相同。
Packet size: Number of bytes in the IP/UDP packet, exclusive of link-layer headers and checksums, prior to fragmentation.
数据包大小：在分段之前，IP/UDP数据包中的字节数，不包括链路层头和校验和。
MTU: Maximum transmission unit, expressed in bytes. For testing purposes, this MAY be configured to values smaller than the MTU supported by the link layer.
MTU：最大传输单位，以字节表示。出于测试目的，可将其配置为小于链路层支持的MTU的值。
Intended Load: Intended load, expressed as percentage of media utilization.
预期负载：预期负载，表示为介质利用率的百分比。
Each HTTP 1.1 or higher client will request one or more objects from an HTTP 1.1 or higher server using one or more HTTP GET requests over each connection. The aggregate number of connections attempted, defined by number of connections, MUST be evenly divided among all of the participating virtual clients. If the virtual client(s) make multiple HTTP GET requests per connection, it MUST request the same object size for each GET request.
每个HTTP 1.1或更高版本的客户端将通过每个连接使用一个或多个HTTP GET请求从HTTP 1.1或更高版本的服务器请求一个或多个对象。尝试的连接总数（由连接数定义）必须平均分配给所有参与的虚拟客户端。如果虚拟客户端对每个连接发出多个HTTP GET请求，则它必须为每个GET请求请求相同的对象大小。
A test instrument attached to the unprotected side of the network, will offer a unidirectional stream of unicast fragmented IP/UDP traffic, targeting a server attached to either the protected or DMZ segment. The test instrument MUST offer the unidirectional stream over the duration of the test, that is, duration over which the HTTP traffic is being offered.
连接到网络未受保护端的测试仪器将提供单播分段IP/UDP通信的单向流，目标是连接到受保护或DMZ段的服务器。测试仪器必须在测试期间提供单向流，也就是说，在HTTP流量提供期间。
Baseline measurements SHOULD be performed with IP filtering deny rule(s) to filter fragmented traffic. If the DUT/SUT has logging capability, the log SHOULD be checked to determine if it contains the correct information regarding the fragmented traffic.
应使用IP过滤拒绝规则执行基线测量，以过滤碎片流量。如果DUT/SUT具有日志记录功能，则应检查日志，以确定其是否包含有关分段流量的正确信息。
The test SHOULD be repeated with the DUT/SUT rule set changed to allow the fragmented traffic through. When running multiple iterations of the test, it is RECOMMENDED to vary the MTU while keeping all other parameters constant.
应在DUT/SUT规则集更改后重复测试，以允许分段通信通过。当运行测试的多次迭代时，建议在保持所有其他参数不变的情况下改变MTU。
Then setup the DUT/SUT to the policy or rule set the manufacturer required to be defined to protect against fragmentation attacks and repeat the measurements outlined in the baseline procedures.
然后将DUT/SUT设置为制造商需要定义的策略或规则集，以防止碎片攻击，并重复基线程序中概述的测量。
Test instrument SHOULD perform the same measurements as defined in HTTP test (Section 5.6.4).
测试仪器应执行HTTP测试（第5.6.4节）中定义的相同测量。
Transmitted UDP/IP Packets: Number of UDP packets transmitted by client.
传输的UDP/IP数据包：客户端传输的UDP数据包数。
Received UDP/IP Packets: Number of UDP/IP Packets received by server.
接收的UDP/IP数据包：服务器接收的UDP/IP数据包数。
The test report SHOULD be the same as described in section 5.6.5. Note that any forwarding rate measurements for the HTTP traffic excludes any bits associated with the fragmented traffic which may be forward by the DUT/SUT.
试验报告应与第5.6.5节所述相同。注意，HTTP流量的任何转发速率测量都不包括与可能由DUT/SUT转发的分段流量相关联的任何比特。
The test report MUST note the packet size, MTU size, intended load, number of UDP/IP packets transmitted and number of UDP/IP packets forwarded. The test report SHOULD also note whether or not the DUT/SUT forwarded the offered UDP/IP traffic fragmented.
测试报告必须注明数据包大小、MTU大小、预期负载、传输的UDP/IP数据包数量和转发的UDP/IP数据包数量。测试报告还应注意DUT/SUT是否转发了提供的UDP/IP流量。
To determine the latency of network-layer or application-layer data traversing the DUT/SUT. RFC 1242 [3] defines latency.
确定网络层或应用层数据穿越DUT/SUT的延迟。RFC 1242[3]定义了延迟。
The following parameters MUST be defined:
必须定义以下参数：
Packet size, expressed as the number of bytes in the IP packet, exclusive of link-layer headers and checksums.
数据包大小，表示为IP数据包中的字节数，不包括链路层头和校验和。
Intended load, expressed as percentage of media utilization.
预期负载，表示为介质利用率的百分比。
Test duration, expressed in seconds.
测试持续时间，以秒表示。
The test instruments MUST generate packets with unique timestamp signatures.
测试仪器必须生成具有唯一时间戳签名的数据包。
Object Size: Defines the number of bytes, excluding any bytes associated with the HTTP header, to be transferred in response to an HTTP 1.1 or higher GET request. The minimum object size supported by the media SHOULD be used, but other object sizes MAY be used as well.
对象大小：定义响应HTTP 1.1或更高版本的GET请求而传输的字节数，不包括与HTTP头关联的任何字节。应使用介质支持的最小对象大小，但也可以使用其他对象大小。
Connection type: The test instrument MUST use one HTTP 1.1 or higher connection for latency measurements.
连接类型：测试仪器必须使用一个HTTP 1.1或更高版本的连接进行延迟测量。
Number of objects requested.
请求的对象数。
Number of objects transferred.
传输的对象数。
Test duration, expressed in seconds.
测试持续时间，以秒表示。
Test instruments MUST generate packets with unique timestamp signatures.
测试仪器必须生成具有唯一时间戳签名的数据包。
A client will offer a unidirectional stream of unicast packets to a server. The packets MUST use a connectionless protocol like IP or UDP/IP.
客户端将向服务器提供单向的单播数据包流。数据包必须使用无连接协议，如IP或UDP/IP。
The test instrument MUST offer packets in a steady state. As noted in the latency discussion in RFC 2544 [2], latency measurements MUST be taken at the throughput level, that is, at the highest offered load with zero packet loss. Measurements taken at the throughput level are the only ones that can legitimately be termed latency.
测试仪器必须提供稳定状态的数据包。如RFC 2544[2]中的延迟讨论所述，必须在吞吐量级别进行延迟测量，也就是说，在提供的负载最高且数据包丢失为零的情况下进行测量。在吞吐量级别进行的测量是唯一可以合法地称为延迟的测量。
It is RECOMMENDED that implementers use offered loads not only at the throughput level, but also at load levels that are less than or greater than the throughput level. To avoid confusion with existing terminology, measurements from such tests MUST be labeled as delay rather than latency.
建议实施者不仅在吞吐量级别上使用提供的负载，而且在小于或大于吞吐量级别的负载级别上也使用提供的负载。为避免与现有术语混淆，此类测试的测量值必须标记为延迟，而不是延迟。
It is RECOMMENDED to perform the latency measurements with different packet sizes. When testing with different packet sizes the DUT/SUT configuration MUST remain the same.
建议使用不同的数据包大小执行延迟测量。当使用不同的数据包大小进行测试时，DUT/SUT配置必须保持不变。
If desired, a step test MAY be used in which offered loads increment or decrement through a range of load levels.
如果需要，可以使用阶跃测试，在该测试中，提供的负载在负载水平范围内递增或递减。
The duration of the test portion of each trial MUST be at least 30 seconds.
每次试验的试验部分的持续时间必须至少为30秒。
An HTTP 1.1 or higher client will request one or more objects from an HTTP 1.1 or higher server using one or more HTTP GET requests. If the test instrument makes multiple HTTP GET requests, it MUST request the same-sized object each time. Multiple iterations of this test may be performed with objects of different sizes.
HTTP 1.1或更高版本的客户端将使用一个或多个HTTP GET请求从HTTP 1.1或更高版本的服务器请求一个或多个对象。如果测试工具发出多个HTTP GET请求，则每次必须请求相同大小的对象。可以使用不同大小的对象执行此测试的多次迭代。
Implementers MAY configure the test instrument to run for a fixed duration. In this case, the test instrument MUST report the number of objects requested and returned for the duration of the test. For fixed-duration tests it is RECOMMENDED that the duration be at least 30 seconds.
实施者可以将测试工具配置为在固定时间内运行。在这种情况下，测试仪器必须报告测试期间请求和返回的对象数量。对于固定持续时间测试，建议持续时间至少为30秒。
Minimum delay: The smallest delay incurred by data traversing the DUT/SUT at the network layer or application layer, as appropriate.
最小延迟：数据在网络层或应用层（视情况而定）通过DUT/SUT产生的最小延迟。
Maximum delay: The largest delay incurred by data traversing the DUT/SUT at the network layer or application layer, as appropriate.
最大延迟：数据在网络层或应用层（视情况而定）通过DUT/SUT产生的最大延迟。
Average delay: The mean of all measurements of delay incurred by data traversing the DUT/SUT at the network layer or application layer, as appropriate.
平均延迟：数据在网络层或应用层（视情况而定）通过DUT/SUT产生的所有延迟测量值的平均值。
Delay distribution: A set of histograms of all delay measurements observed for data traversing the DUT/SUT at the network layer or application layer, as appropriate.
延迟分布：在网络层或应用层（视情况而定）观察到的数据通过DUT/SUT的所有延迟测量的直方图。
The test report MUST note the packet size(s), offered load(s) and test duration used. In addition, the test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须注明数据包大小、提供的负载和使用的测试持续时间。此外，试验报告必须符合第4节“试验设置”中规定的报告要求。
The latency results SHOULD be reported in the format of a table with a row for each of the tested packet sizes. There SHOULD be columns for the packet size, the intended rate, the offered rate, and the resultant latency or delay values for each test.
延迟结果应以表格的形式报告，表格中的每一个测试数据包大小对应一行。对于每个测试，应该有数据包大小、预期速率、提供速率以及结果延迟或延迟值列。
The test report MUST note the object size(s) and number of requests and responses completed. If applicable, the report MUST note the test duration if a fixed duration was used. In addition, the test report MUST conform to the reporting requirements set in section 4, Test Setup.
测试报告必须注明对象大小以及完成的请求和响应数量。如果适用，报告必须注明试验持续时间（如果使用固定持续时间）。此外，试验报告必须符合第4节“试验设置”中规定的报告要求。
The latency results SHOULD be reported in the format of a table with a row for each of the object sizes. There SHOULD be columns for the object size, the number of completed requests, the number of completed responses, and the resultant latency or delay values for each test.
延迟结果应以表格的形式报告，每个对象大小对应一行。每个测试的对象大小、已完成请求的数量、已完成响应的数量以及产生的延迟或延迟值都应该有列。
Failure analysis: The test report SHOULD indicate the number and percentage of HTTP GET request or responses that failed to complete within the test duration.
失败分析：测试报告应该指出在测试持续时间内未能完成的HTTP GET请求或响应的数量和百分比。
Version information: The test report MUST note the version of HTTP client and server.
版本信息：测试报告必须注明HTTP客户端和服务器的版本。
[1] Newman, D., "Benchmarking Terminology for Firewall Devices", RFC 2647, August 1999.
[1] Newman，D.，“防火墙设备的基准术语”，RFC 2647，1999年8月。
[2] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[2] Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 25441999年3月。
[3] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[3] Bradner，S.，“网络互连设备的基准术语”，RFC 1242，1991年7月。
[4] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[4] Mandeville，R.，“局域网交换设备的基准术语”，RFC 2285，1998年2月。
[5] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[5] Mandeville，R.和J.Perser，“局域网交换设备的基准测试方法”，RFC 2889，2000年8月。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[6] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯泰克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议-HTTP/1.1”，RFC2616，1999年6月。
[7] Clark, D., "IP Datagram Reassembly Algorithm", RFC 815, July 1982.
[7] Clark，D.，“IP数据报重组算法”，RFC 815，1982年7月。
[8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[8] 《传输控制协议》，标准7，RFC 793，1981年9月。
The primary goal of this document is to provide methodologies in benchmarking firewall performance. While there is some overlap between performance and security issues, assessment of firewall security is outside the scope of this document.
本文档的主要目标是提供防火墙性能基准测试方法。虽然性能和安全问题之间存在一些重叠，但防火墙安全评估不在本文档的范围之内。
APPENDIX A: HTTP (HyperText Transfer Protocol)
附录A:HTTP（超文本传输协议）
The most common versions of HTTP in use today are HTTP/1.0 and HTTP/1.1 with the main difference being in regard to persistent connections. HTTP 1.0, by default, does not support persistent connections. A separate TCP connection is opened up for each GET request the client wants to initiate and closed after the requested object transfer is completed. While some implementations HTTP/1.0 supports persistence through the use of a keep-alive, there is no official specification for how the keep-alive operates. In addition, HTTP 1.0 proxies do support persistent connection as they do not recognize the connection header.
目前使用的最常见的HTTP版本是HTTP/1.0和HTTP/1.1，主要区别在于持久连接。默认情况下，HTTP 1.0不支持持久连接。对于客户端想要启动的每个GET请求，会打开一个单独的TCP连接，并在请求的对象传输完成后关闭。虽然HTTP/1.0的一些实现通过使用keep-alive支持持久性，但没有关于keep-alive如何操作的正式规范。此外，HTTP 1.0代理不支持持久连接，因为它们无法识别连接头。
HTTP/1.1, by default, does support persistent connection and is therefore the version that is referenced in this methodology. Proxy based DUT/SUTs may monitor the TCP connection and after a timeout, close the connection if no activity is detected. The duration of this timeout is not defined in the HTTP/1.1 specification and will vary between DUT/SUTs. If the DUT/SUT closes inactive connections, the aging timer on the DUT SHOULD be configured for a duration that exceeds the test time.
默认情况下，HTTP/1.1支持持久连接，因此是此方法中引用的版本。基于代理的DUT/SUT可以监视TCP连接，超时后，如果未检测到任何活动，则关闭连接。HTTP/1.1规范中未定义此超时的持续时间，并且在DUT/SUT之间会有所不同。如果DUT/SUT关闭非活动连接，则DUT上的老化计时器的配置持续时间应超过测试时间。
While this document cannot foresee future changes to HTTP and it impact on the methodologies defined herein, such changes should be accommodated for so that newer versions of HTTP may be used in benchmarking firewall performance.
虽然本文档无法预见HTTP的未来变化及其对本文定义的方法的影响，但应适应此类变化，以便在防火墙性能基准测试中使用HTTP的较新版本。
APPENDIX B: Connection Establishment Time Measurements
附录B：连接建立时间测量
Some connection oriented protocols, such as TCP, involve an odd number of messages when establishing a connection. In the case of proxy based DUT/SUTs, the DUT/SUT will terminate the connection, setting up a separate connection to the server. Since, in such cases, the test instrument does not own both sides of the connection, measurements will be made two different ways. While the following describes the measurements with reference to TCP, the methodology may be used with other connection oriented protocols which involve an odd number of messages.
一些面向连接的协议，如TCP，在建立连接时涉及奇数条消息。在基于代理的DUT/SUT的情况下，DUT/SUT将终止连接，建立到服务器的单独连接。由于在这种情况下，测试仪器并不拥有连接的两侧，因此将采用两种不同的方式进行测量。虽然以下描述了关于TCP的测量，但该方法可用于涉及奇数条消息的其他面向连接的协议。
When testing non-proxy based DUT/SUTs , the establishment time shall be directly measured and is considered to be from the time the first bit of the first SYN packet is transmitted by the client to the time the last bit of the final ACK in the three-way handshake is received by the target server.
当测试非基于代理的DUT/SUT时，应直接测量建立时间，并将其视为从客户端传输第一个SYN数据包的第一位到目标服务器接收到三向握手中最终ACK的最后一位的时间。
If the DUT/SUT is proxy based, the connection establishment time is considered to be from the time the first bit of the first SYN packet is transmitted by the client to the time the client transmits the first bit of the first acknowledged TCP datagram (t4-t0 in the following timeline).
如果DUT/SUT是基于代理的，则连接建立时间被认为是从客户端发送第一SYN包的第一位到客户端发送第一个确认的TCP数据报的第一位的时间（以下时间线中的t4-t0）。
t0: Client sends a SYN. t1: Proxy sends a SYN/ACK. t2: Client sends the final ACK. t3: Proxy establishes separate connection with server. t4: Client sends TCP datagram to server. *t5: Proxy sends ACK of the datagram to client.
t0：客户端发送一个SYN。t1：代理发送SYN/ACK。t2：客户端发送最终确认。t3：代理与服务器建立单独的连接。t4：客户端向服务器发送TCP数据报*t5：代理向客户端发送数据报的ACK。
* While t5 is not considered part of the TCP connection establishment, acknowledgement of t4 must be received for the connection to be considered successful.
* 虽然t5不被视为TCP连接建立的一部分，但必须收到t4的确认，才能认为连接成功。
APPENDIX C: Connection Tear Down Time Measurements
附录C：连接拆卸时间测量
While TCP connections are full duplex, tearing down of such connections are performed in a simplex fashion, that is, FIN segments are sent by each host/device terminating each side of the TCP connection.
虽然TCP连接是全双工的，但这种连接的拆卸是以单工方式执行的，即，FIN段由终止TCP连接每侧的每个主机/设备发送。
When making connection tear down times measurements, such measurements will be made from the perspective of the entity, that is, virtual client/server initiating the connection tear down request. In addition, the measurement will be performed in the same manner, independent of whether or not the DUT/SUT is proxy-based. The connection tear down will be considered the interval between the transmission of the first bit of the first TCP FIN packet transmitted by the virtual client or server, whichever is applicable, requesting a connection tear down to receipt of the last bit of the corresponding ACK packet on the same virtual client/server interface.
在进行连接断开时间测量时，将从实体的角度进行此类测量，即，启动连接断开请求的虚拟客户机/服务器。此外，测量将以相同的方式进行，与DUT/SUT是否基于代理无关。连接中断将被视为虚拟客户机或服务器发送的第一个TCP FIN数据包的第一位的传输之间的间隔，以适用的为准，请求断开连接到在同一虚拟客户机/服务器接口上接收对应ACK数据包的最后一位。
Authors' Addresses
作者地址
Brooks Hickman Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Brooks Hickman Spirent Communications美国加利福尼亚州卡拉巴斯市Agoura路26750号，邮编：91302
Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
David Newman Network Test Inc. 31324 Via Colinas, Suite 113 Westlake Village, CA 91362-6761 USA
David Newman网络测试公司31324 Via Colinas，美国加利福尼亚州西湖村113室，邮编：91362-6761
Phone: + 1 818 889-0011
EMail: dnewman@networktest.com
Phone: + 1 818 889-0011
EMail: dnewman@networktest.com
Saldju Tadjudin Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Saldju Tadjudin Spirent Communications美国加利福尼亚州卡拉巴斯市Agoura路26750号，邮编：91302
Phone: + 1 818 676 2468
EMail: Saldju.Tadjudin@spirentcom.com
Phone: + 1 818 676 2468
EMail: Saldju.Tadjudin@spirentcom.com
Terry Martin GVNW Consulting Inc. 8050 SW Warm Springs Road Tualatin Or. 97062 USA
Terry Martin GVNW Consulting Inc.温斯普林斯路西南8050号。97062美国
Phone: + 1 503 612 4422
EMail: tmartin@gvnw.com
Phone: + 1 503 612 4422
EMail: tmartin@gvnw.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。