[要約] 要約：RFC 3511は、ファイアウォールのパフォーマンスを評価するためのベンチマーク手法を提供しています。 目的：このRFCの目的は、ファイアウォールの性能評価を標準化し、比較可能な結果を得ることです。
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.
Copyright（c）The Internet Society（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.
* この単語、または「必要な」という言葉と「必要」と「「必要」と「」とは、項目が仕様の絶対的な要件であることを意味します。
* "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.
* この単語または形容詞「オプション」を「5月」と意味します。このアイテムが本当にオプションであることを意味します。1人のベンダーは、特定の市場に必要なものを必要とするため、またはたとえば製品を強化するため、アイテムを含めることを選択できます。別のベンダーは同じアイテムを省略する場合があります。
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".
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]、通常はパブリックネットワーク（インターネット）に接続されています。他のインターフェイスは、保護されたネットワーク[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.
Tri-Homed [1]構成は、非武装ゾーン（DMZ）と呼ばれる3番目のセグメントを採用しています。トライホーム構成により、パブリックネットワークにアクセスできるサーバーがDMZに接続されています。Tri-Homed構成は、パブリックネットワークにアクセスできるサーバーを内部ホストから分離することにより、追加のセキュリティを提供します。
+----------+ +----------+
| | | +----------+ | | |
| 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/SUTSが含まれる可能性があるため、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...
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 Disabledを使用してテストを実行し、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.
一部のテスト機器は、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を通過するネットワーク層データのスループットを決定するため。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.
スループット：1秒あたりのビットまたは1秒あたりのパケットで表される最大提供負荷。パケット損失は検出されません。カウントされるビットは、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.
転送レート：1秒あたりのビットまたは1秒あたりのパケットで表される転送率は、指定された提供された負荷に応じて正しい宛先インターフェイスに正常に転送することが観察されます。カウントされるビットは、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接続要求が試行される1秒あたりの接続で表される集約レート。レートは、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ヘッダーに関連付けられたバイトを除くバイト数を定義し、HTTP 1.1以下のGETリクエストに応じて転送されます。
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/SUTSをテストする場合、仮想クライアントはHTTP 1.1以下のGETリクエストを使用して2つのオブジェクトを要求する必要があります。最初のGETリクエストは、付録Bで指定されている接続時間の確立[1]測定に必要です。2番目の要求は、前述のように検証に使用されます。プロキシと非プロキシベースのDUT/SUTSを比較する場合、テストは同じ方法で実行する必要があります。
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を発行することをお勧めします。テスト機器は、次の反復に続く前に老化時間を待ちます。
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.
最小接続確立時間：付録Bで定義されている最低TCP接続確立時間測定時間測定時間
Maximum connection establishment time: Highest TCP connection establishment time measured, as defined in appendix B.
最大接続確立時間：付録Bで定義されている最高のTCP接続確立時間測定時間測定時間
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フィンまたは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ヘッダーに関連付けられたバイトを除くバイト数を定義し、HTTP 1.1以下のGETリクエストに応じて転送されます。
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を発行することをお勧めします。テスト機器は、次の反復に続く前に老化時間を待ちます。
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.
最高の接続レート：最高のレート、1秒あたりの接続で、すべての接続が検索アルゴリズムで正常に開かれました。
Minimum connection establishment time: Lowest TCP connection establishment time measured, as defined in appendix B.
最小接続確立時間：付録Bで定義されている最低TCP接続確立時間測定時間測定時間
Maximum connection establishment time: Highest TCP connection establishment time measured, as defined in appendix B.
最大接続確立時間：付録Bで定義されている最高のTCP接続確立時間測定時間測定時間
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接続を除去する最大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フィンまたは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.
閉じる方法：TCP接続を閉じるための方法を定義します。テストは、3方向または四方の握手で実行する必要があります。4方向の握手では、それぞれの側が個別のFINとACKメッセージを送信します。3方向の握手では、片側は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/SUTSの場合、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 Rを発行することをお勧めします。成功。テストは、次の反復に続く前に老化時間を待ちます。
Highest connection tear down rate: Highest rate, in connections per second, for which all TCP connections were successfully torn down in the search algorithm.
最高の接続の解体速度：最高のレート、1秒あたりの接続で、すべての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洪水攻撃は、攻撃ソースホストに被害者ホストに向けてランダムなソースアドレスを備えた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パケットで標的にされている1秒あたりのパケットで表されます。
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.
ベースラインTCP接続の確立率に対するテストまたはHTTP転送速度テストに対するテストに敬意を表して、セクション5.3.3または5.6.3で定義されているのと同じ手順を使用します。さらに、テスト機器は、Syn攻撃レートで定義されたレートでサーバー（S）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.
ベースラインTCP接続確立率テストに対するテストまたはHTTP転送速度に対するテストに応じて、セクション5.3.4または5.6.4で定義されているのと同じ測定値を実行します。
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.
テストでは、ベースラインTCP接続確立率テストまたはHTTP転送速度に対するテストが敬意を表してテストするかどうかに応じて、セクション5.3.5または5.6.5で説明したのと同じレポート形式を使用する必要があります。
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.
閉じる方法：TCP接続を閉じる方法を定義します。テストは、3方向または四方の握手で実行する必要があります。4方向の握手では、それぞれの側が個別のFINとACKメッセージを送信します。3方向の握手では、片側は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以下の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ヘッダーに関連付けられたバイトを除くバイト数を定義し、HTTP 1.1以下のGETリクエストに応じて転送されます。
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を使用して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.
仮想クライアントが接続ごとに複数の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の平均転送率を測定する必要があり、要求されたオブジェクトを参照する必要があります。測定は、最初に要求されたオブジェクトの最初のビットの送信から始まり、最後の要求されたオブジェクトの最後のビットの送信で終了します。1秒あたりビットでの平均転送率は、次の式を使用して計算されます。
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.
再送信バイト - 再送信されたバイトの総数。
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 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.
レポートには、接続の確立の障害と接続の崩壊障害の両方の分布をプロットするグラフを含めることをお勧めします。X座標はエルプステスト時間である必要があり、Y座標は特定のサンプリング期間の障害の数でなければなりません。グラフには2つの行があります。1つは接続障害用、もう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.
閉じる方法：TCP接続を閉じるための方法を定義します。テストは、3方向または四方の握手で実行する必要があります。4方向の握手では、それぞれの側が個別のFINとACKメッセージを送信します。3方向の握手では、片側は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ヘッダーに関連付けられたバイトを除くバイト数を定義し、HTTP 1.1以下のGETリクエストに応じて転送されます。
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リクエストごとに同じオブジェクトサイズを要求する必要があります。異なるオブジェクトサイズで複数のテストを実行できます。
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.
テストレポートは、閉鎖方法、密接な方向、確立された接続の数、および取り壊された接続の数に注意する必要があります。
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の行動を特徴付ける。違法なトラフィックは攻撃を指すのではなく、ルールによって明示的に定義されているトラフィックを指すことに注意してください。
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: Illegal traffic percentage: Percentage of HTTP 1.1 or higher connections which have been explicitly defined in a rule(s) to drop.
セットアップパラメーターは、HTTP転送速度テストで指定されたのと同じパラメーターを使用します（セクション5.6.2）。さらに、次のセットアップパラメーターを定義する必要があります。違法なトラフィック率：ルールで明示的に定義されている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 Requestを使用して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 Requestを使用してHTTP 1.1以下のサーバーから1つ以上のオブジェクトを要求します。接続の数で定義された試行された接続の総数は、参加するすべての仮想クライアント間で均等に分割する必要があります。仮想クライアントが接続ごとに複数の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.
BaseLine測定は、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ヘッダーに関連付けられたバイトを除くバイト数を定義し、HTTP 1.1以下のGETリクエストに応じて転送されます。メディアでサポートされている最小オブジェクトサイズを使用する必要がありますが、他のオブジェクトサイズも使用できます。
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 Requestsを使用して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.
テストレポートは、パケットサイズ、提供された負荷と使用されるテスト期間に注意する必要があります。さらに、テストレポートは、セクション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] ニューマン、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 2544、1999年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。、「LANスイッチングデバイスのベンチマーク用語」、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、「LANスイッチングデバイスのベンチマーク方法論」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners -Lee、「HyperText Transfer Protocol -HTTP/1.1」、RFC 2616、6月1999年。
[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] Postel、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接続が開かれます。いくつかの実装は、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/SUTSは、TCP接続を監視し、タイムアウト後、アクティビティが検出されない場合は接続を閉じます。このタイムアウトの期間は、HTTP/1.1仕様では定義されておらず、DUT/SUTSによって異なります。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/SUTSの場合、DUT/SUTは接続を終了し、サーバーへの個別の接続を設定します。そのような場合、テスト機器は接続の両側を所有していないため、測定は2つの異なる方法で行われます。以下は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/SUTSをテストする場合、確立時間は直接測定され、最初のsynパケットの最初のビットがクライアントによって送信されるまでと見なされます。ターゲットサーバーが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フィンパケットの最初のビットの送信と、該当するいずれかの間隔と見なされます。同じ仮想クライアント/サーバーインターフェイスで。
Authors' Addresses
著者のアドレス
Brooks Hickman Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Brooks Hickman Spirent Communications 26750 Agoura Road Calabasas、CA 91302 USA
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 Network Test Inc. 31324 Colinas、Suite 113 Westlake Village、CA 91362-6761 USA
Phone: + 1 818 889-0011
EMail: dnewman@networktest.com
Saldju Tadjudin Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Saldju Tadjudin Spirent Communications 26750 Agoura Road Calabasas、CA 91302 USA
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 SW Warm Springs Road Tualatinまたは。97062 USA
Phone: + 1 503 612 4422
EMail: tmartin@gvnw.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。