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
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.
この文書では、ファイアウォールのパフォーマンスベンチマークのための方法論を提供します。転送、接続、レイテンシとフィルタリング：それは、次の4つの領域をカバーしています。テストの定義に加えて、この文書はまた、試験結果を報告するための特定のフォーマットを説明しています。
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.
*この単語、または単語「必須」とは、項目が仕様の絶対的な要件であることを意味し、「SHALL」、「しなければなりません」。
* "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.
*「SHOULD」この単語、あるいは形容詞「推奨」は、この項目を無視する特定の事情の正当な理由が存在することを意味するが、完全な意味が理解されるべきであるとする場合は慎重に別のコースを選択する前に秤量しました。
* "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".
それはMUST要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTとすべてのSHOULD要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUST要件を満たしていないが、すべてのSHOULD要件は、「条件付き準拠した」と言われている1。
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.
デュアルホーム構成を採用したファイアウォールは、2つのネットワークを接続します。ファイアウォールの一方のインターフェイスは保護されていないネットワーク[1]、典型的には公衆網（インターネット）に取り付けられています。他のインターフェースは、保護されたネットワーク[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)
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）と呼ばれる第3のセグメントを使用します。トライホーム構成で、パブリックネットワークにアクセス可能なサーバをDMZに添付されています。トライホームの構成は、内部ホストからパブリックネットワークにアクセス可能なサーバ（複数可）を分離することによって追加のセキュリティを提供します。
+----------+ +----------+
| | | +----------+ | | |
| 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.
ファイアウォールのテストは、複数のユーザーまたはホストをエミュレートするデータソースを伴うことがあるので、方法論は、仮想クライアント/サーバーの用語を使用しています。これらのファイアウォールのテストでは、仮想クライアント/サーバは、固有の物理インターフェイスに関連付けされないことがあり、アプリケーション層のエンティティを指定します。例えば、4つの仮想クライアントは、同じデータ・ソース[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:
デュアルホーム構成では、2つのユニークなトラフィックフローがあります。
Client Server
------ ------
Protected -> Unprotected
Unprotected -> Protected
For Tri-Homed configurations, there are three unique traffic flows:
トライホームの構成の場合、3つのユニークなトラフィックフローがあります。
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:
1つ以上のクライアントには、特定のアプリケーションの複数のサーバを標的にしてもよいです。各仮想クライアントは、ラウンドロビン方式で接続を開始しなければなりません。テストは3台のサーバーをターゲット6つの仮想クライアントから構成されている場合たとえば、次のように、パターンは次のようになります。
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 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 ...
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]、公共のインターネットアドレスにプライベートインターネットアドレスを変換する機能を実装します。これは、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] [1] DUT / SUTが転送されますと、それは拒否されますどのパケットを決定するアクセス制御ポリシーの集合です。これらのアクセス制御ポリシーが定義されるかもしれない基準が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.
いくつかのテスト機器は、それによって提供されるトラフィックフローに影響を与えるとパフォーマンス測定値に影響を与え、1つ以上の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.
RFC 1242で定義されるように、DUT / SUTを横断するネットワーク層データのスループットを決定するために、[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.
試験報告書は、パケットサイズ（S）、試験時間、スループット、および転送速度に注意しなければなりません。また、試験報告書は、セクション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を介して、またはでサポート同時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を介して、またはでサポートされる同時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リクエストを使用して2つのオブジェクトを要求しなければなりません。前述したように、第2の要求を検証するために使用されている付録Bに指定されたように、第1のGET要求は、接続時間の確立[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で設定した報告要件、テストのセットアップに従わなければなりません。
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クライアント（複数可）とサーバ（群）のバージョンに注意しなければなりません。
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によって定義されるように、DUT / SUTを介して、またはで最大TCPコネクション確立レートを決定するために、[1]。このテストでは、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で設定した報告要件、テストのセットアップに従わなければなりません。
The test report MUST note object size(s), number of completed requests and number of completed responses.
試験報告書は、オブジェクトサイズ（S）、完了した要求の数と完了した応答の数に注意しなければなりません。
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クライアント（複数可）とサーバ（群）のバージョンに注意しなければなりません。
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によって定義される最大TCP接続を決定するために[1]、DUT / SUTを介して、またはで速度を取り壊します。
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メソッド：TCP接続を閉じるための方法を定義します。試験は三元または4ウェイハンドシェイクのいずれかを用いて行われなければなりません。 4ウェイハンドシェイクでは、それぞれの側は、別々の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.
このテストでは、最大TCP接続のDUT / SUTでサポートされている割合を取り壊すを決定するために反復探索アルゴリズムを採用します。別の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自体がTCPコネクションのその側を閉じるためにFINパケットを発行することに応答してACKを受信することになります。検証目的のために、適用可能であるいずれかの仮想クライアント又はサーバは、DUT / SUTは、最終的なACKを再送信することによって、最終的な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.
各反復の間に、適用される方の仮想クライアント（複数可）またはサーバー（s）は、かどうかにかかわらず、接続の、解体しようとした各接続を参照して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コネクションを切断接続の数、エージング時間、closeメソッド、閉方向、最小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フラッド攻撃は、それによって、そのホストのリソースを消費し、攻撃の送信元ホストが被害者のホストへのランダムな送信元アドレスを持つTCP SYNパケットを生成することによってTCPの3ウェイハンドシェイクのメカニズムを利用します。
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アタックレート：レートは、サーバ（群）またはNATプロキシアドレスは、TCP SYNパケットをターゲットにされた秒あたりのパケットで表現しました。
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攻撃を発信する試験装置は、保護されていないネットワークに接続する必要があります。また、試験装置は、SYNパケットに応じて、ターゲット・サーバーまたはNATプロキシによって送信された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を維持することができますどれだけかを決定するために有効と無効で、テストでは、このような攻撃の下で、実行する必要があり、5.3節と節で決定したベースラインの接続確立率とHTTP転送速度それぞれ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).
また、試験装置は、保護またはDMZインタフェース（S）上のDUT / SUTを転送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.
DUT / SUTを横断HTTP要求されたオブジェクトの転送速度を決定するには。
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メソッドは：TCP接続を閉じるための方法を定義します。試験は三元または4ウェイハンドシェイクのいずれかを用いて行われなければなりません。 4ウェイハンドシェイクでは、それぞれの側は、別々の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.
接続あたりのリクエストをGET：HTTP 1.1または接続ごとに試みた高いGET要求の数を定義します。
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以降の仮想クライアントは、各接続を介して1つまたは複数のHTTP GETリクエストを使用してHTTP 1.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.
仮想クライアント（s）は、複数のHTTP接続あたりのリクエストをプレゼントした場合、それは各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 - Total number of objects successfully transferred across all connections.
OBJECTS - 成功したすべての接続を介して転送オブジェクトの合計数。
OBJECTSIZE - Object size in bytes
OBJECTSIZE - バイト単位のオブジェクトサイズ
DURATION - Aggregate transfer time based on aforementioned time references.
DURATION - 上記の時間基準に基づいて集計転送時間。
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].
グッドプット[1]：RFCのセクション3.17に定義された2647.測定としてグッドプットは、プロトコルヘッダのいずれかを除いた、プロトコル・ペイロードを参照しなければなりません。また、試験装置は、[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.
再送されたバイト - 再送されたバイトの合計数。
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).
試験報告書は、接続およびオブジェクトサイズ（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.
試験報告書は、接続の数、closeメソッド、閉方向と測定が行われたためにプロトコルを注意しなければなりません。
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 application layer reporting, provided the table clearly identifies the protocol for which the measurement was made.
結果は、試験したHTTPオブジェクトサイズのそれぞれについて、表形式で報告されるべきです。転送合計バイト数の行、合計タイムアウト、総再送バイトとし、得られたグッドプットが存在すべきです。総バイト数が転送総データグラムのペイロードバイトを指すことに留意されたいです。テーブルは、テーブルが明確に測定が行われたためのプロトコルを識別する設けられ、アプリケーション層の報告と組み合わせることができます。
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.
レポートが障害を取り壊す接続確立の失敗、接続の両方の分布をプロットするグラフを含むことが推奨されます。 y座標、経過試験時間であるべきであるX座標を所定のサンプリング期間の失敗の数でなければなりません。グラフ上に2本の線、接続障害用と涙ダウン障害の1があるはずです。グラフは、サンプリング期間に注意しなければなりません。
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メソッド：TCP接続を閉じるための方法を定義します。試験は三元または4ウェイハンドシェイクのいずれかを用いて行われなければなりません。 4ウェイハンドシェイクでは、それぞれの側は、別々の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.
テスト期間：時間、仮想クライアント（複数可）が試みたGETリクエストレートを維持しますそのため、秒単位で表されます。期間が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.
仮想クライアント（s）は、複数のHTTP接続あたりのリクエストをプレゼントした場合、それは各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.
探索アルゴリズムの中間結果は、各反復のために列を持つ表形式で報告することができます。完了した要求のGETリクエストの試み率、試みられた要求の数、数と割合の行があるはず、未遂応答の数は、応答の数と割合は、最小トランザクション時間、平均トランザクション時間と最大トランザクション時間を完了しました。
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.
試験報告書は、closeメソッド、閉方向、確立された接続の数と取り壊さ接続の数に注意しなければなりません。
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.
法的および違法両方の組み合わせを提示する場合、[1]のトラフィックをDUT / SUTの振る舞いを特徴づけるために。不正なトラフィックが攻撃を参照していないが、明示的ルール（S）で定義されているトラフィックがドロップすることに注意してください。
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以上のクライアントは、各接続を介して1つまたは複数のHTTP GETリクエストを使用してHTTP 1.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の転送速度に持っているか決定することに焦点を当てます。 RFC 1858は、ルータとホストで使用される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以上のクライアントは、各接続を介して1つまたは複数のHTTP GETリクエストを使用してHTTP 1.1以上のサーバから1つまたは複数のオブジェクトを要求します。接続の数によって定義された接続試行の総数は、均等に参加仮想クライアントの全ての間で分割しなければなりません。仮想クライアント（s）は、複数のHTTP接続あたりのリクエストをプレゼントした場合、それは各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.
ネットワークの保護されていない側に取り付けられた試験装置は、いずれかの保護またはDMZセグメントに取り付けられたサーバーをターゲットと、ユニキャスト断片化されたIP / UDPトラフィックの一方向の流れを提供します。試験装置は、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.
接続タイプ：試験装置はレイテンシ測定のための1つの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以降クライアントは、1つまたは複数のHTTP GETリクエストを使用してHTTP 1.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.
試験報告書は、使用されるパケットサイズ（S）、提供された負荷（S）とテスト時間を注意しなければなりません。また、試験報告書は、セクション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.
試験報告書は、オブジェクトサイズ（S）および完了した要求と応答の数に注意しなければなりません。該当する場合は、固定期間が使用された場合には、報告書は、試験時間を注意しなければなりません。また、試験報告書は、セクション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]ニューマン、D.、 "ファイアウォールデバイスのためのベンチマーキング用語"、RFC 2647、1999年8月。
[2] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[2]ブラドナー、S.とJ. McQuaid、 "ベンチマーキング方法論ネットワークのための相互接続デバイス"、RFC 2544、1999年3月。
[3] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[3]ブラドナーの、S.、 "ネットワーク相互接続デバイスのためのベンチマーキング用語"、RFC 1242、1991年7月。
[4] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[4]マンデビル、R.、RFC 2285、1998年2月 "LANスイッチングデバイスのためのベンチマーキング用語を"。
[5] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[5]、RFC 2889 "LANスイッチングデバイスのためのベンチマーキング方法論" マンデヴィル、R.とJ. Perser、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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
[7] Clark, D., "IP Datagram Reassembly Algorithm", RFC 815, July 1982.
[7]クラーク、D.、 "IPデータグラム再アセンブリアルゴリズム"、RFC 815、1982年7月。
[8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[8]ポステル、J.、 "伝送制御プロトコル"、STD 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は、デフォルトでは、永続的な接続をサポートしていません。別のTCP接続は、クライアントが開始することを望んでいる各GET要求のために開いて、要求されたオブジェクトの転送が完了した後に閉じられています。いくつかの実装は、HTTP / 1.0サポートがキープアライブを使用して永続性が、キープアライブがどのように動作するかのための正式な仕様はありません。また、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の最後のビット3ウェイハンドシェイクは、ターゲットサーバで受信されます。
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：クライアントが、最終的なACKを送信します。 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
ブルックスヒックマンのSpirentコミュニケーションズ26750アゴーラ道路カラバサス、CA 91302 USA
Phone: + 1 818 676 2412 EMail: brooks.hickman@spirentcom.com
電話：+ 1 818 676 2412 Eメール：brooks.hickman@spirentcom.com
David Newman Network Test Inc. 31324 Via Colinas, Suite 113 Westlake Village, CA 91362-6761 USA
デヴィッド・ニューマンネットワークテスト株式会社31324経由コリナス、スイート113ウェストレイク・ビレッジ、CA 91362から6761 USA
Phone: + 1 818 889-0011 EMail: dnewman@networktest.com
電話：+ 1 818 889-0011 Eメール：dnewman@networktest.com
Saldju Tadjudin Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Saldju TadjudinのSpirentコミュニケーションズ26750アゴーラ道路カラバサス、CA 91302 USA
Phone: + 1 818 676 2468 EMail: Saldju.Tadjudin@spirentcom.com
電話：+ 1 818 676 2468 Eメール：Saldju.Tadjudin@spirentcom.com
Terry Martin GVNW Consulting Inc. 8050 SW Warm Springs Road Tualatin Or. 97062 USA
テリー・マーティンGVNWコンサルティング株式会社8050 SWウォームスプリングスロードテュアラティンか。 97062 USA
Phone: + 1 503 612 4422 EMail: tmartin@gvnw.com
電話：+ 1 503 612 4422 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。