RFC3511 日本語訳
3511 Benchmarking Methodology for Firewall Performance. B. Hickman, D.Newman, S. Tadjudin, T. Martin. April 2003. (Format: TXT=67916 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.ヒックマン要求をネットワークでつないでください: 3511年のSpirentコミュニケーションカテゴリ: Inc2003年4月に相談する情報のD.のS.Tadjudin SpirentコミュニケーションT.マーチンニューマンネットワークテストGVNW
Benchmarking Methodology for Firewall Performance
ファイアウォールパフォーマンスのためのベンチマーキング方法論
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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)のBenchmarking Methodology作業部会(BMWG)の製品です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Test Considerations. . . . . . . . . . . . . . . . . . . 4
4.2 Virtual Client/Servers . . . . . . . . . . . . . . . . . 4
4.3 Test Traffic Requirements. . . . . . . . . . . . . . . . 5
4.4 DUT/SUT Traffic Flows. . . . . . . . . . . . . . . . . . 5
4.5 Multiple Client/Server Testing . . . . . . . . . . . . . 5
4.6 Network Address Translation (NAT). . . . . . . . . . . . 6
4.7 Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . 6
4.8 Web Caching. . . . . . . . . . . . . . . . . . . . . . . 6
4.9 Authentication . . . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件. . . . . . . . . . . . . . . . . . . . . . . . 2 3。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 テストセットアップ. . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1Test Considerations。 . . . . . . . . . . . . . . . . . . 4 4.2 仮想のクライアント/サーバ.44.3はトラフィック要件をテストします。 . . . . . . . . . . . . . . . 5 4.4 DUT/SUTトラフィックは流れます。 . . . . . . . . . . . . . . . . . 5 4.5 複数のクライアント/サーバテスト. . . . . . . . . . . . . 5 4.6はアドレス変換(NAT)をネットワークでつなぎます。 . . . . . . . . . . . 6 4.7定規はセットします。 . . . . . . . . . . . . . . . . . . . . . . . 6 4.8 ウェブキャッシュ。 . . . . . . . . . . . . . . . . . . . . . . 6 4.9 認証. . . . . . . . . . . . . . . . . . . . . 7
Hickman, et al. Informational [Page 1] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[1ページ]のRFC3511方法論
4.10 TCP Stack Considerations. . . . . . . . . . . . . . . . 7
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 7
5.1 IP throughput. . . . . . . . . . . . . . . . . . . . . . 7
5.2 Concurrent TCP Connection Capacity . . . . . . . . . . . 9
5.3 Maximum TCP Connection Establishment Rate. . . . . . . . 12
5.4 Maximum TCP Connection Tear Down Rate. . . . . . . . . . 14
5.5 Denial Of Service Handling . . . . . . . . . . . . . . . 16
5.6 HTTP Transfer Rate . . . . . . . . . . . . . . . . . . . 18
5.7 Maximum HTTP Transaction Rate. . . . . . . . . . . . . . 21
5.8 Illegal Traffic Handling . . . . . . . . . . . . . . . . 23
5.9 IP Fragmentation Handling. . . . . . . . . . . . . . . . 24
5.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Normative References . . . . . . . . . . . . . . . . . . 29
6.2 Informative References . . . . . . . . . . . . . . . . . 30
7. Security Consideration . . . . . . . . . . . . . . . . . . . 30
Appendix A - HyperText Transfer Protocol (HTTP) . . . . . . . . 31
Appendix B - Connection Establishment Time Measurements . . . . 31
Appendix C - Connection Tear Down Time Measurements . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
4.10 TCPは問題を積み重ねます。 . . . . . . . . . . . . . . . 7 5. ベンチマーキングTests. . . . . . . . . . . . . . . . . . . . . 7 5.1IPスループット。 . . . . . . . . . . . . . . . . . . . . . 7 5.2 同時発生のTCP接続容量. . . . . . . . . . . 9 5.3の最大のTCPコネクション確立は評価します。 . . . . . . . 12 レートの下側への5.4の最大のTCP接続裂け目。 . . . . . . . . . 14 5.5 サービス取り扱. . . . . . . . . . . . . . . 16 5.6いHTTP転送レート. . . . . . . . . . . . . . . . . . . 18 5.7の最大のHTTPトランザクションレートの否定。 . . . . . . . . . . . . . 21 5.8 不法なトラフィック取り扱. . . . . . . . . . . . . . . . 23 5.9いIP断片化取り扱い。 . . . . . . . . . . . . . . . 24 5.10 潜在. . . . . . . . . . . . . . . . . . . . . . . . 26 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1の引用規格. . . . . . . . . . . . . . . . . . 29 6.2の有益な参照.307 警備上の配慮. . . . . . . . . . . . . . . . . . . 30付録A--ハイパーテキスト転送プロトコル(HTTP). . . . . . . . 31付録B--コネクション確立時間測定値. . . . 31付録C--接続裂け目の休止時間測定値. . . . . . 32作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 33は著作権宣言文. . . . . . . . . . . . . . . . . . . 34を洗い張りします。
1. Introduction
1. 序論
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])は本書では使用される用語の多くを定義します。 用語はSHOULDを記録します。このドキュメントを利用するのを試みる前に、相談されてください。
2. Requirements
2. 要件
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.
* "MUST" This単語、または単語が「必要であり」、“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"This単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
Hickman, et al. Informational [Page 2] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[2ページ]のRFC3511方法論
* "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月」This単語か「任意である」という形容詞が、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、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つか以上を満たさないなら実装が対応でない、要件はそうしなければなりません。 そして、すべてを満たす実装、すべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、すべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
3. Scope
3. 範囲
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.
ファイアウォールはネットワークの間のアクセスを制御できます。 通常、ファイアウォールはそれが関連している公共の、または、共有されたネットワークから私設のネットワークを保護します。 ファイアウォールは、パケットをフィルターにかける単一のデバイスと同じくらい簡単であるか、パケットフィルタリングを結合するデバイス、アプリケーションレベルプロキシ、およびネットワーク翻訳、通訳のサービスのグループとまたは同じくらい複雑であることができます。 このドキュメントはどこでも、実装の如何にかかわらず可能であるところでベンチマーキングファイアウォール性能に焦点を合わせます。
4. Test Setup
4. テストセットアップ
Test configurations defined in this document will be confined to dual-homed and tri-homed as shown in figure 1 and figure 2 respectively.
そして、テスト構成がこのドキュメントが限定されるコネを定義した、二元的である、-、家へ帰り、3、家へ帰り、示されるように、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.
ケース、二元的である、-、家へ帰り、構成、公立(保護のない)のネットワークにアクセスしやすくされるサーバは私設(保護される)のネットワークに取り付けられます。
Hickman, et al. Informational [Page 3] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[3ページ]のRFC3511方法論
+----------+ +----------+
| | | +----------+ | | |
| Servers/ |----| | | |------| Servers/ |
| Clients | | | | | | Clients |
| | |-------| DUT/SUT |--------| | |
+----------+ | | | | +----------+
Protected | +----------+ | Unprotected
Network | | Network
Figure 1 (Dual-Homed)
+----------+ +----------+ | | | +----------+ | | | | サーバ/|----| | | |------| サーバ/| | クライアント| | | | | | クライアント| | | |-------| DUT/SUT|--------| | | +----------+ | | | | +----------保護された+| +----------+ | 保護のないネットワーク| | ネットワーク図1(二元的である、-、家へ帰り、)
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.
3、家へ帰り、[1] 3分の1が区分する構成雇用は、非武装地帯を(DMZ)と呼びました。 3、家へ帰り、構成であり、公衆通信回線にアクセスしやすいサーバはDMZに取り付けられます。 3Homed構成は、内部のホストと公衆通信回線にアクセスしやすいサーバを切り離すことによって、追加担保を提供します。
+----------+ +----------+
| | | +----------+ | | |
| Clients |----| | | |------| Servers/ |
| | | | | | | Clients |
+----------+ |-------| DUT/SUT |--------| | |
| | | | +----------+
| +----------+ |
Protected | | | Unprotected
Network | Network
|
-----------------
| DMZ
|
|
+-----------+
| |
| Servers |
| |
+-----------+
+----------+ +----------+ | | | +----------+ | | | | クライアント|----| | | |------| サーバ/| | | | | | | | クライアント| +----------+ |-------| DUT/SUT|--------| | | | | | | +----------+ | +----------+ | 保護されます。| | | 保護のないネットワーク| ネットワーク| ----------------- | 非武装地帯| | +-----------+ | | | サーバ| | | +-----------+
Figure 2 (Tri-Homed)
図2(3、家へ帰り、)
4.1 Test Considerations
4.1 テスト問題
4.2 Virtual Clients/Servers
4.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
ファイアウォールテストが複数のユーザかホストをエミュレートするデータ送信端末にかかわるかもしれないので、方法論は用語を使用します。仮想のクライアント/サーバ。 これらのファイアウォールテストとして、仮想のクライアント/サーバはユニークな物理インターフェースに関連しないかもしれない応用層実体を指定します。 例えば、4人の仮想のクライアントはそうするかもしれません。
Hickman, et al. Informational [Page 4] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[4ページ]のRFC3511方法論
originate from the same data source [1]. The test report MUST indicate the number of virtual clients and virtual servers participating in the test.
同じデータ送信端末[1]から、発してください。 試験報告書はテストに参加する仮想のクライアントと仮想サーバの数を示さなければなりません。
4.3 Test Traffic Requirements
4.3 テストトラフィック要件
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にかかわるかもしれないので、付録AでHTTPバージョン問題について議論します。
4.4 DUT/SUT Traffic Flows
4.4 DUT/SUT交通の流れ
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:
Dual家へ帰る、構成であり、2回のユニークな交通の流れがあります:
Client Server
------ ------
Protected -> Unprotected
Unprotected -> Protected
クライアントサーバ------ ------ 保護された->保護のない保護のない->は保護されました。
For Tri-Homed configurations, there are three unique traffic flows:
Tri家へ帰る、構成であり、3回のユニークな交通の流れがあります:
Client Server
------ ------
Protected -> Unprotected
Protected -> DMZ
Unprotected -> DMZ
クライアントサーバ------ ------ 保護された->保護のない保護された->非武装地帯保護のない->非武装地帯
4.5 Multiple Client/Server Testing
4.5 複数のクライアント/サーバテスト
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人の仮想のクライアントから成るなら、パターンは以下の通りでしょうに:
Hickman, et al. Informational [Page 5] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[5ページ]のRFC3511方法論
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...
クライアントTarget Server(要求の順に)#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...
4.6 Network Address Translation (NAT)
4.6 ネットワークアドレス変換(NAT)
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側の追加処理にかかわって、性能に影響を与えるかもしれません。 したがって、テストSHOULD、NAT身体障害者とNATが性能デフ装置を決定していて、可能にされるもしあれば走りました。 試験報告書は、NATが可能にされたか、または無効にされたかを示さなければなりません。
4.7 Rule Sets
4.7 規則セット
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.
規則が各ホスト(仮想のクライアント)のために入れられるのは、RECOMMENDEDです。 SHOULDをテストして、さらに、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 SHOULD、構成されて、以前に規則に基づき定義されたというわけではないすべてのトラフィックへのアクセスがセットしたことを否定してください。 SHOULDがDUT/SUTを含んでいるという試験報告書は規則セットを構成しました。
4.8 Web Caching
4.8 ウェブキャッシュ
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要求のための応答などのように受ける応答を保存します。 SHOULDをテストして、DUT/SUTの上のエージェントが無効にしたあらゆるキャッシュで実行されてください。
Hickman, et al. Informational [Page 6] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[6ページ]のRFC3511方法論
4.9 Authentication
4.9 認証
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.
アクセスコントロールはユーザ、クライアントまたはセッション認証などの認証過程にかかわるかもしれません。 認証は、通常、認証サーバなどのファイアウォール自体への外部のデバイスによって実行されて、システムの潜在に加えるかもしれません。 接続設定プロセスの一部としてどんな認証過程も含まなければなりません。
4.10 TCP Stack Considerations
4.10 TCPスタック問題
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/SUTsを比較するとき、さらに、同じTCPパラメタを使用しなければなりません。
5. Benchmarking Tests
5. ベンチマーキングテスト
5.1 IP Throughput
5.1 IPスループット
5.1.1 Objective
5.1.1 目的
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.
RFC1242[3]で定義されるようにDUT/SUTを横断するネットワーク層データに関するスループットを測定するために。 RFC1242がフレームという用語を使用しますが、手順がパケットという用語を使用することに注意してください、ネットワーク層に参照をつけているので。用語はリンクレイヤに関連しています。
5.1.2 Setup Parameters
5.1.2 セットアップパラメタ
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.
Durationをテストしてください--秒に言い表されたテストの持続時間。
5.1.3 Procedure
5.1.3 手順
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.
試験計器は一定の割合でユニキャストIPパケットをDUT/SUTに提供しなければなりません。 テストは双方向か単方向のトラフィックから成るかもしれません。 例えば、見習われたクライアントがパケットのユニキャストの流れを見習われたサーバに提供するかもしれませんか、または試験計器は、双方向のトラフィックを提供することによって、クライアント/サーバ交換をシミュレートするかもしれません。
Hickman, et al. Informational [Page 7] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[7ページ]のRFC3511方法論
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.
このテストは繰り返しの検索アルゴリズムを使うでしょう。 各繰り返しは最高率(パケット損失は全く起こらない)が見つけられるまで意図している負荷を変える試験計器にかかわるでしょう。 背圧メカニズム以来、使われて、異なった意図している負荷と提供された負荷をもたらすテストSHOULDがパケットが基礎づけたどちらかかRFC2889[5]で説明される時間に基づいている方法で実行されますように。 RFC1242のように、用語パケットはフレームに代わって使用されます。 それぞれのトライアルの試料の持続時間は少なくとも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.
それは異なったパケットサイズでスループット測定を実行するRECOMMENDEDです。 異なったパケットサイズでテストするとき、DUT/SUT構成は同じままで残らなければなりません。
5.1.4 Measurement
5.1.4 測定
5.1.4.1 Network Layer
5.1.4.1 ネットワーク層
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秒あたりのbpsかパケットのどちらかで言い表されたパケット損失が全く検出されない負荷を提供しました。 数えられるべきビットが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秒あたりのbpsかパケットに、デバイスが首尾よく指定された提供された負荷に対応して正しい目的地のインタフェースに送るために観測される。 数えられるべきビットがIPパケット(ヘッダープラスペイロード)にあります。 測定でリンクレイヤヘッダーやトレーラなどの他の分野を含んではいけません。
5.1.5 Reporting Format
5.1.5 書式を報告すること。
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.
試験報告書はパケットサイズ、テスト持続時間、スループット、および伝送速度に注意しなければなりません。 Test Setup、さらに、試験報告書は要件がセクション4に設定する報告に従わなければなりません。 テストが、パケットを提供することを伴ったなら、どれが1つ以上のセグメントを狙うか。(保護された、Unprotectedか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.
スループット結果SHOULD、テーブルの形式では、行で、それぞれのテストされたパケットサイズのために報告されてください。 SHOULDはパケットサイズのためのコラム、そこでは、意図でした。負荷、提供された負荷、結果のスループット、および推進は各テストのために評価します。
Hickman, et al. Informational [Page 8] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[8ページ]のRFC3511方法論
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
- ステップIteration--総パケットが進めたStatus(提供された総パケット)--意図している負荷--提供された負荷に通るか、または失敗してください(適切であるなら)--Forwardingは評価します。
5.2 Concurrent TCP Connection Capacity
5.2 同時発生のTCP接続容量
5.2.1 Objective
5.2.1 目的
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.
DUT/SUTかDUT/SUTと共にRFC2647[1]で定義されるようにサポートされた同時発生のTCP接続の最大数を測定するために。 このテストがDUT/SUTが接続テーブルに保存できるエントリーの最大数を見つけることを意図します。
5.2.2 Setup Parameters
5.2.2 セットアップパラメタ
The following parameters MUST be defined for all tests:
すべてのテストのために以下のパラメタを定義しなければなりません:
5.2.2.1 Transport-Layer Setup Parameters
5.2.2.1 トランスポート層セットアップパラメタ
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.
接続試み率: 1秒あたりの接続で表されたTCP接続要求が試みられる集合レート。 レートSHOULDは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.
古い時間: 秒に言い表された時間、TCP FINかRSTパケットを受けた後に、DUT/SUTは接続テーブルに接続を保つでしょう。
5.2.2.2 Application-Layer Setup Parameters
5.2.2.2 応用層セットアップパラメタ
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.
オブジェクトサイズ: GETが要求するHTTPより多くの1.1に対応して移すためにHTTPヘッダに関連しているどんなバイトも除いて、バイト数を定義します。
Hickman, et al. Informational [Page 9] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[9ページ]のRFC3511方法論
5.2.3 Procedure
5.2.3 手順
This test will employ an iterative search algorithm to determine the maximum number of concurrent TCP connections supported through or with the DUT/SUT.
このテストは、DUT/SUTかDUT/SUTと共にサポートされた同時発生のTCP接続の最大数を測定するのに繰り返しの検索アルゴリズムを使うでしょう。
For each iteration, the aggregate number of concurrent TCP connections attempted by the virtual client(s) will be varied. The destination address will be that of the server or that of the NAT proxy. The aggregate rate will be defined by connection attempt rate, and will be attempted in a round-robin fashion (See 4.5).
各繰り返しにおいて、仮想のクライアントによって試みられた同時発生のTCP接続の集合数は変えられるでしょう。 送付先アドレスは、サーバのものかNATプロキシのものになるでしょう。 集合レートは、接続試み率によって定義されて、連続ファッションで試みられるでしょう(4.5を見てください)。
To validate all connections, the virtual client(s) MUST request an object using an HTTP 1.1 or higher GET request. The requests MUST be initiated on each connection after all of the TCP connections have been established.
すべての接続を有効にするために、GETが要求するHTTPより多くの1.1を使用して、仮想のクライアントはオブジェクトを要求しなければなりません。 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をテストするとき、HTTP1.1か、より高いGET要求を使用して、仮想のクライアントは2個のオブジェクトを要求しなければなりません。 GETが要求する1番目が付録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 RSTを発行するのは、RECOMMENDEDです、接続試みがうまくいったかどうかにかかわらず。 試験計器は次の繰り返しに続く前に、古い時間待っています。
5.2.4 Measurements
5.2.4 測定値
5.2.4.1 Application-Layer measurements
5.2.4.1 アプリケーション層の測定値
Number of objects requested
要求されたオブジェクトの数
Number of objects returned
オブジェクトの数は戻りました。
5.2.4.2 Transport-Layer measurements
5.2.4.2 輸送層の測定値
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コネクション確立時間。
Hickman, et al. Informational [Page 10] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[10ページ]のRFC3511方法論
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.
コネクション確立時間を集めてください: コネクション確立時間のすべての測定値の合計。
5.2.5 Reporting Format
5.2.5 書式を報告すること。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
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.
検索アルゴリズムの中間結果は表の様式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、船をこぐ、終了する要求、試みられた応答の数、数、および応答の割合が完成した試みられた要求の数、数、および割合。 テーブルはテーブルであればこれが応用層測定であると認識するように報告するトランスポート層に結合されるかもしれません。
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.
検索アルゴリズムの中間結果はテーブルの形式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、合計のための行が接続が試みたTCPの数であったなら、終了するTCP接続の数と割合(最小のTCPコネクション確立時間、最大のTCPコネクション確立時間)はコネクション確立時間と集合コネクション確立時間を平均します。
Hickman, et al. Informational [Page 11] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[11ページ]のRFC3511方法論
5.3 Maximum TCP Connection Establishment Rate
5.3 最大のTCPコネクション確立は評価します。
5.3.1 Objective
5.3.1 目的
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.
最大のTCPコネクション確立を決定するには、DUT/SUTかDUT/SUTと共にRFC2647[1]によって定義されるように評価してください。 このテストがDUT/SUTがアップデートできる最高率に接続テーブルを見つけることを意図します。
5.3.2 Setup Parameters
5.3.2 セットアップパラメタ
The following parameters MUST be defined for all tests:
すべてのテストのために以下のパラメタを定義しなければなりません:
5.3.2.1 Transport-Layer Setup Parameters
5.3.2.1 トランスポート層セットアップパラメタ
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パケットを受けた後のステートテーブルです。
5.3.2.2 Application-Layer Setup Parameters
5.3.2.2 応用層セットアップパラメタ
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.
オブジェクトサイズ: GETが要求するHTTPより多くの1.1に対応して移すためにHTTPヘッダに関連しているどんなバイトも除いて、バイト数を定義します。
5.3.3 Procedure
5.3.3 手順
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接続容量テストで説明されるように必要とした同じ応用層オブジェクトを実行しなければなりません。
Hickman, et al. Informational [Page 12] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[12ページ]のRFC3511方法論
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を発行するのは、RECOMMENDEDです、接続試みがうまくいったかどうかにかかわらず。 試験計器は次の繰り返しに続く前に、古い時間待っています。
5.3.4 Measurements
5.3.4 測定値
5.3.4.1 Application-Layer measurements
5.3.4.1 アプリケーション層の測定値
Number of objects requested
要求されたオブジェクトの数
Number of objects returned
オブジェクトの数は戻りました。
5.3.4.2 Transport-Layer measurements
5.3.4.2 輸送層の測定値
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.
コネクション確立時間を集めてください: コネクション確立時間のすべての測定値の合計。
5.3.5 Reporting Format
5.3.5 書式を報告すること。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
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
検索アルゴリズムの中間結果は表の様式で各繰り返しのためのコラムで報告されるかもしれません。 そしてそこ、SHOULD、船をこぐ、要求が完成した試みられた要求の数、数、および割合(試みられた応答の数)が付番する。
Hickman, et al. Informational [Page 13] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[13ページ]のRFC3511方法論
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.
検索アルゴリズムの中間結果はテーブルの形式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、接続試み率、接続が試みたTCPの総数、接続が完成したTCPの総数、最小のTCPコネクション確立時間、最大のTCPコネクション確立時間、平均したコネクション確立時間、および集合コネクション確立時間の行になってください。
5.4 Maximum TCP Connection Tear Down Rate
5.4 レートの下側への最大のTCP接続裂け目
5.4.1 Objective
5.4.1 目的
To determine the maximum TCP connection tear down rate through or with the DUT/SUT, as defined by RFC 2647 [1].
最大のTCP接続を決定するには、DUT/SUTかDUT/SUTと共にRFC2647[1]によって定義されるようにレートを取りこわしてください。
5.4.2 Setup Parameters
5.4.2 セットアップパラメタ
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.
クローズ方法: TCP接続を終えるためのメソッドを定義します。 3者間の、または、4方法の握手でテストを実行しなければなりません。 4方法の握手では、それぞれの側は別々のFINとACKにメッセージを送ります。 3方向ハンドシェイクでは、FINを受け取り次第半面は結合したFIN/ACKメッセージを送ります。
Hickman, et al. Informational [Page 14] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[14ページ]のRFC3511方法論
Close Direction:
Defines whether closing of connections are to be initiated from
the client or from the server.
方向を閉じてください: 接続に閉じるのがクライアントかサーバから開始されることになっているかどうかを定義します。
5.4.3 Procedure
5.4.3 手順
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/SUTsの場合では、DUT/SUT自身はTCP接続の側面を閉じるためにFINパケットを発行することに対応してACKを受けるために望んでいます。 合法化目的のために、仮想のクライアントかサーバ(適切である)が、DUT/SUTが最終的なACKを再送することによって最終的なACKを受けたことを確かめるかもしれません。 再送されたACKに対応してTCP RSTを受け取るべきです。
Between each iteration, it is RECOMMENDED that the virtual client(s) or server(s), whichever is applicable, issue a TCP RST referencing each connection which was attempted to be torn down, regardless of whether or not the connection tear down attempt was successful. The test will wait for aging time before continuing to the next iteration.
各繰り返しの間では、仮想のクライアントかサーバ(適切である)が取りこわすために試みられた各接続に参照をつけるTCP RSTを発行するのは、RECOMMENDEDです、試みの下側への接続裂け目がうまくいったかどうかにかかわらず。 テストは次の繰り返しに続く前に、古い時間待っています。
5.4.4 Measurements
5.4.4 測定値
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.
最小の接続裂け目の休止時間: 最も低いTCP接続裂け目の休止時間は付録Cで定義されるように測定しました。
Maximum connection tear down time:
Highest TCP connection tear down time measured as defined in
appendix C.
最大の接続裂け目の休止時間: 最も高いTCP接続裂け目の休止時間は付録Cで定義されるように測定しました。
Average connection tear down time:
The mean of all measurements of connection tear down times.
接続裂け目の休止時間を平均してください: 接続の測定値が回の下側まで引き裂くすべての平均。
Hickman, et al. Informational [Page 15] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[15ページ]のRFC3511方法論
Aggregate connection tear down time:
The total of all measurements of connection tear down times.
接続裂け目の休止時間に集めてください: 接続の測定値が回の下側まで引き裂くすべての合計。
5.4.5 Reporting Format
5.4.5 書式を報告すること。
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接続裂け目の休止時間、およびレートの下側への最も高い接続裂け目が測定したことに注意しなければなりません。 Test Setup、さらに、試験報告書は要件がセクション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.
検索アルゴリズムの中間結果はテーブルの形式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、必要なら下であるのが完成したTCP接続裂け目の下であるのが試みたTCP裂け目の数、数、および割合のための行と、最小のTCP接続裂け目の休止時間と、最大のTCP接続裂け目の休止時間と、平均したTCP接続裂け目の休止時間と、集合TCP接続裂け目の休止時間と合法化失敗になってください。
5.5 Denial Of Service Handling
5.5 サービス取り扱いの否定
5.5.1 Objective
5.5.1 目的
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方向ハンドシェイクメカニズムを利用します、その結果、そのホストのリソースを消費します。
5.5.2 Setup Parameters
5.5.2 セットアップパラメタ
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で定義されて、基線に対してテストして、TCP接続設立がテストかHTTPを評定するかどうかに関して.2、依存が速度テストを移すような同じセットアップパラメタを使用してください。
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はレートを攻撃します: 1秒あたりのパケットに表されたサーバ(s)かNATプロキシアドレスがTCP SYNパケットで狙うレート。
Hickman, et al. Informational [Page 16] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[16ページ]のRFC3511方法論
5.5.3 Procedure
5.5.3 手順
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で速度テストを移すような同じ手順を用いてください。 さらに、試験計器がサーバIPアドレスを狙うパケットをTCP SYNに生成するだろうか、またはSYN攻撃で定義されたレートにおけるNATプロキシアドレスは評価します。
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がどれくらいよくそうすることができるかを決定するために無効にされたSHOULDが、基線コネクション確立がそのような攻撃で評定すると主張するテストとHTTPはそれぞれセクション5.3とセクション5.6で決定しているレートを移します。
5.5.4 Measurements
5.5.4 測定値
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で定義されて、基線に対してテストして、TCP接続設立がテストかHTTPを評定するかどうかに関して.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が保護で進めるSYN攻撃に関連している試験計器SHOULD道のTCP SYNパケットかDMZが(s)を連結します。
5.5.5 Reporting Format
5.5.5 書式を報告すること。
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.
テストSHOULDは謹んでセクション5.3.5か5.6で説明されて、基線に対してテストして、TCP接続設立が評価するかどうかに関して.5、依存がテストされながら書式を報告する同じくらいか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攻撃メカニズムを可能にさせるかどうかを示さなければなりません。
Hickman, et al. Informational [Page 17] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[17ページ]のRFC3511方法論
5.6 HTTP Transfer Rate
5.6 HTTP転送レート
5.6.1 Objective
5.6.1 目的
To determine the transfer rate of HTTP requested object traversing the DUT/SUT.
HTTPの転送レートを決定するのはDUT/SUTを横断するオブジェクトを要求しました。
5.6.2 Setup Parameters
5.6.2 セットアップパラメタ
The following parameters MUST be defined for all tests:
すべてのテストのために以下のパラメタを定義しなければなりません:
5.6.2.1 Transport-Layer Setup Parameters
5.6.2.1 トランスポート層セットアップパラメタ
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.
ポートの数: 試みられた集合ポートの数を定義します。 仮想のクライアントの数が中で参加する倍数がテストであったならSHOULDに付番してください。
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方法の握手でテストを実行しなければなりません。 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.
方向を閉じてください: 接続に閉じるのがクライアントかサーバから開始されることになっているかどうかを定義します。
5.6.2.2 Application-Layer Setup Parameters
5.6.2.2 応用層セットアップパラメタ
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.
1接続あたりのGET要求: 接続単位で試みられたHTTP1.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.
オブジェクトサイズ: GETが要求するHTTPより多くの1.1に対応して移すためにHTTPヘッダに関連しているどんなバイトも除いて、バイト数を定義します。
Hickman, et al. Informational [Page 18] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[18ページ]のRFC3511方法論
5.6.3 Procedure
5.6.3 手順
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.
それぞれのHTTP1.1か、より高い仮想のクライアントが、HTTP1.1か、より高いサーバから各接続の上の1つ以上のHTTP GET要求を使用することで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.
仮想のクライアントが複数の1接続あたりのHTTP GET要求をするなら、それはそれぞれのGET要求のために同じオブジェクトサイズを要求しなければなりません。 このテストの複数の繰り返しが異なったサイズのオブジェクトで実行されるかもしれません。
5.6.4 Measurements
5.6.4 測定値
5.6.4.1 Application-Layer measurements
5.6.4.1 アプリケーション層の測定値
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 MUSTの平均した転送レートは、測定されて、要求されたオブジェクトに参照をつけられるものとします。 測定は最後に要求されたオブジェクトの最後のビットのトランスミッションの最初の要求されたオブジェクトと終わりの最初のビットのトランスミッションを始めるでしょう。 bpsでは、平均した転送レートは以下の公式を使用することで計算されるでしょう:
OBJECTS * OBJECTSIZE * 8
TRANSFER RATE (bit/s) = --------------------------
DURATION
オブジェクト*OBJECTSIZE*8転送レート(ビット/s)=-------------------------- 持続時間
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--集合転送時間は前述の時に参照を基礎づけました。
5.6.4.2 Measurements at or below the Transport-Layer
5.6.4.2 トランスポート層における、または、トランスポート層の下における測定値
The following measurements SHOULD be performed for each connection- oriented protocol:
以下の測定値SHOULD、それぞれの接続指向のプロトコルには、実行されてください:
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]: RFC2647のセクション3.17で定義されるGoodput。 プロトコルヘッダーのどれかを除いて、測定値はプロトコルペイロードに参照をつけるだけでよいです。 さらに、試験計器がコネクション確立に関連しているどんなビットも除かなければならなくて、接続裂け目は、下に、セキュリティ協会[1]または接続メインテナンス[1]です。
Hickman, et al. Informational [Page 19] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[19ページ]のRFC3511方法論
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.
Timeoutsの数--総数のタイムアウトイベント。
Retransmitted bytes - Total number of retransmitted bytes.
再送されたバイト--総数の再送されたバイト。
5.6.5 Reporting Format
5.6.5 書式を報告すること。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
Test Setup、試験報告書は要件がセクション4に設定する報告に従わなければなりません。
5.6.5.1 Application-Layer reporting
5.6.5.1 アプリケーション層の報告
The test report MUST note number of GET requests per connection and object size(s).
試験報告書は1接続あたりの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.
テストされて、転送は、報告されたコネがそれぞれのオブジェクトサイズのためのコラムがある表フォームであったなら結果がSHOULDであると評定します。 そこ、SHOULD、aが船をこぐ、完成した要求の数と割合、完成した応答の数と割合、および結果の転送はテストの各繰り返しのために評価します。
Failure analysis:
The test report SHOULD indicate the number and percentage of HTTP
GET request and responses that failed to complete.
故障解析: 試験報告書SHOULDは完全な状態でHTTP GET要求とそうしなかった応答の数と割合を示します。
Version information:
The test report MUST note the version of HTTP client(s) and
server(s).
バージョン情報: 試験報告書はHTTPクライアントとサーバのバージョンに注意しなければなりません。
5.6.5.2 Transport-Layer and below reporting
5.6.5.2 輸送層と以下の報告
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
結果SHOULD、表にしてそれぞれのHTTPオブジェクトサイズには、テストされていた状態で、報告されてください。 そして、そこ、SHOULD、総バイトわたっていて、総タイムアウトのための行、総再送されたバイトになってください、そして、結果のgoodput。 総バイトが総データグラムペイロードバイトについて言及するというメモは移されました。 テーブルは結合されるかもしれません。
Hickman, et al. Informational [Page 20] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[20ページ]のRFC3511方法論
application layer reporting, provided the table clearly identifies the protocol for which the measurement was made.
テーブルが明確に、測定がされたプロトコルを特定するなら報告する応用層。
Failure analysis:
The test report SHOULD indicate the number and percentage of
connection establishment failures as well as number and percentage
of TCP tear down failures.
故障解析: 試験報告書SHOULDは、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.
レポートがコネクション確立失敗と接続裂け目の両方の分配を失敗の下側に企むためにグラフを含んでいるのは、RECOMMENDEDです。 xは経過したテストが時間であったならSHOULDを調整して、yは与えられた標本抽出のための失敗の数が期間であったならSHOULDを調整します。 そこ、SHOULD、グラフに関する2つの系列、接続失敗のためのもの、および失敗の下側への裂け目への1つはそうです。 グラフはサンプリング周期に注意しなければなりません。
5.7 Maximum HTTP Transaction Rate
5.7 最大のHTTPトランザクションレート
5.7.1 Objective
5.7.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が支えることができる最大のトランザクションレートを測定してください。 このテストがユーザがオブジェクトにアクセスできる最高率を見つけることを意図します。
5.7.2 Setup Parameters
5.7.2 セットアップパラメタ
5.7.2.1 Transport-Layer Setup Parameters
5.7.2.1 トランスポート層セットアップパラメタ
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方法の握手でテストを実行しなければなりません。 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.
方向を閉じてください: 接続に閉じるのがクライアントかサーバから開始されることになっているかどうかを定義します。
5.7.2.2 Application-Layer Setup Parameters
5.7.2.2 応用層セットアップパラメタ
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バージョンを使用しなければなりません。
Hickman, et al. Informational [Page 21] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[21ページ]のRFC3511方法論
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秒であることはRECOMMENDEDです。
Requests per connection:
Number of object requests per connection.
1接続あたりの要求: 1接続あたりのオブジェクト要求の数。
Object Size:
Defines the number of bytes, excluding any bytes associated with
the HTTP header, to be transferred in response to an HTTP 1.1 or
higher GET request.
オブジェクトサイズ: GETが要求するHTTPより多くの1.1に対応して移すためにHTTPヘッダに関連しているどんなバイトも除いて、バイト数を定義します。
5.7.3 Procedure
5.7.3 手順
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.
各繰り返し単位で、HTTP1.1か、より高い仮想のクライアントがHTTP1.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.
仮想のクライアントが複数の1接続あたりのHTTP GET要求をするなら、それはそれぞれのGET要求のために同じオブジェクトサイズを要求しなければなりません。 複数のテストが異なったオブジェクトサイズで実行されるかもしれません。
5.7.4 Measurements
5.7.4 測定値
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.
トランザクション時間: 試験計器SHOULDは最小の、そして、最大の、そして、平均したトランザクション回を測定します。 仮想のクライアントが要求仮想のクライアントが要求されたオブジェクトの最後のビットを受け取るGET要求と終わりを出すとき、トランザクション時間は始まるでしょう。
5.7.5 Reporting Format
5.7.5 書式を報告すること。
The test report MUST conform to the reporting requirements set in section 4, Test Setup.
Test Setup、試験報告書は要件がセクション4に設定する報告に従わなければなりません。
Hickman, et al. Informational [Page 22] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[22ページ]のRFC3511方法論
5.7.5.1 Application-Layer reporting
5.7.5.1 アプリケーション層の報告
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
試験報告書はテスト持続時間に注意しなければなりません、オブジェクトサイズ、1接続あたりの要求、最小のトランザクション時間、最大のトランザクション時間、時間と最大のトランザクションレートが測定した平均したトランザクション
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.
検索アルゴリズムの中間結果はテーブル形式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、GETのための行が要求試み率であったなら、終了する要求の試みられた要求の数、数、および割合(終了する応答、最小のトランザクション時間の試みられた応答の数、数、および割合)は、トランザクション時間と最大のトランザクション時間を平均します。
Version information:
The test report MUST note the version of HTTP client(s) and
server(s).
バージョン情報: 試験報告書はHTTPクライアントとサーバのバージョンに注意しなければなりません。
5.7.5.2 Transport-Layer
5.7.5.2 トランスポート層
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.
検索アルゴリズムの中間結果はテーブル形式で各繰り返しのためのコラムで報告されるかもしれません。 そこ、SHOULD、試みられた接続、数の数、終了する接続、数の割合、および下であるのが完成した接続裂け目の割合のための行になってください。 テーブルはテーブルであるならこれがトランスポート層測定であると認識するように報告する応用層に結合されるかもしれません。
5.8 Illegal Traffic Handling
5.8 不法なトラフィック取り扱い
5.8.1 Objective
5.8.1 目的
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.
ともに法的、そして、Illegal[1]トラフィックの組み合わせを与えるとき、DUT/SUTの動きを特徴付けるために。 Illegalトラフィックが攻撃ではなく、低下するために規則で明らかに定義されたトラフィックについて言及することに注意してください。
5.8.2 Setup Parameters
5.8.2 セットアップパラメタ
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)における指定されるのと同じパラメタを使用するでしょう。 さらに、以下のセットアップパラメタを定義しなければなりません:
Hickman, et al. Informational [Page 23] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[23ページ]のRFC3511方法論
Illegal traffic percentage:
Percentage of HTTP 1.1 or higher connections which have been
explicitly defined in a rule(s) to drop.
不法なトラフィック割合: 低下するために規則に基づき明らかに定義されたHTTP1.1か、より高い接続の割合。
5.8.3 Procedure
5.8.3 手順
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.
それぞれのHTTP1.1か、より高いクライアントが、HTTP1.1か、より高いサーバから各接続の上の1つ以上のHTTP GET要求を使用することで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アドレス、Port番号など)をフィルターにかける能力があります。 DUT/SUTが異なったトラフィックで評価基準をフィルターにかけるために構成にされているので、このテストの複数の繰り返しが実行されるかもしれません。
5.8.4 Measurements
5.8.4 測定値
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)SHOULDを移します。実行されます。 どんな伝送速度測定値も法的なトラフィックに関連しているビットを含むだけでよいです。
5.8.5 Reporting Format
5.8.5 書式を報告すること。
Test reporting format SHOULD be the same as specified in the HTTP transfer rate test (Section 5.6.5).
HTTP転送速度テスト(セクション5.6.5)で指定されるように形式SHOULDが同じであると報告して、テストしてください。
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によって許された不法な接続の数と割合に注意しなければなりません。
5.9 IP Fragmentation Handling
5.9 IP断片化取り扱い
5.9.1 Objective
5.9.1 目的
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.
IPをDUT/SUTに与えるとき、性能影響を決定するのはトラフィックを断片化しました。 実際のIPパケットより小さいMTU(最大のTransmission Unit)をサポートするネットワークに交差するため断片化されたIPパケットは、適用されるように設定された規則の前に再アセンブリを実行するためにファイアウォールを必要とするかもしれません。
Hickman, et al. Informational [Page 24] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[24ページ]のRFC3511方法論
While IP fragmentation is a common form of attack, either on the firewall itself or on internal hosts, this test will focus on determining how the additional processing associated with the re- assembly of the packets have on the forwarding rate of the DUT/SUT. RFC 1858 addresses some fragmentation attacks that get around IP filtering processes used in routers and hosts.
IP断片化は追加処理がどのように再アセンブリと交際したかを決定するのにこのテストがファイアウォール自体の上、または、内部のホストの上で集中する一般的な形式の攻撃ですが、パケットはDUT/SUTの伝送速度でそうしました。 RFC1858は、何らかの断片化がルータとホストで使用されるIPろ過過程を逃れる攻撃であると扱います。
5.9.2 Setup Parameters
5.9.2 セットアップパラメタ
The following parameters MUST be defined.
以下のパラメタを定義しなければなりません。
5.9.2.1 Non-Fragmented Traffic Parameters
5.9.2.1 非断片化しているトラフィックパラメタ
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)。
5.9.2.2 Fragmented Traffic Parameters
5.9.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.
意図している負荷: メディア利用の割合として言い表された意図している負荷。
5.9.3 Procedure
5.9.3 手順
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.
それぞれのHTTP1.1か、より高いクライアントが、HTTP1.1か、より高いサーバから各接続の上の1つ以上のHTTP GET要求を使用することで1個以上のオブジェクトを要求するでしょう。 参加している仮想のクライアントのすべて中で均等にポートの数によって定義されて、試みられた集合ポートの数を分割しなければなりません。 仮想のクライアントが複数の1接続あたりのHTTP GET要求をするなら、それはそれぞれのGET要求のために同じオブジェクトサイズを要求しなければなりません。
A test instrument attached to the unprotected side of the network, will offer a unidirectional stream of unicast fragmented IP/UDP traffic, targeting a server attached to either the protected or DMZ segment. The test instrument MUST offer the unidirectional stream over the duration of the test, that is, duration over which the HTTP traffic is being offered.
ネットワークの保護のない側面に取り付けられた試験計器、ユニキャスト断片化しているIP/UDPトラフィックの単方向のストリームを提供するでしょう、保護かDMZセグメントのどちらかに取り付けられたサーバを狙って。 試験計器はテスト(すなわち、HTTPトラフィックが提供されている持続時間)の持続時間の上に単方向のストリームを提供しなければなりません。
Hickman, et al. Informational [Page 25] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[25ページ]のRFC3511方法論
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.
基線測定値SHOULD、フィルタリングが断片化しているトラフィックをフィルターにかけることを規則を否定するIPと共に実行されてください。 DUT/SUTであるなら、伐採能力、ログSHOULDは、それが断片化しているトラフィックに関する正確な情報を含むかどうか決定するためにチェックされましたか?
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規則セットに従って断片化しているトラフィックの通ることを許すために変えて、繰り返されて、SHOULDをテストしてください。 テストの複数の繰り返しを実行するとき、それは他のすべてのパラメタを一定に保っている間にMTUを変えるRECOMMENDEDです。
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にセットアップしてください。
5.9.4 Measurements
5.9.4 測定値
Test instrument SHOULD perform the same measurements as defined in HTTP test (Section 5.6.4).
試験計器SHOULDは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 Packetsの数。
5.9.5 Reporting Format
5.9.5 書式を報告すること。
5.9.5.1 Non-Fragmented Traffic
5.9.5.1 非断片化しているトラフィック
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で説明されるようにSHOULDが同じであると報告します。 HTTPトラフィックのためのレート測定値を転送するといくらか、前方にDUT/SUTであるかもしれない断片化しているトラフィックに関連しているどんなビットも除かれることに注意してください。
5.9.5.2 Fragmented Traffic
5.9.5.2 断片化しているトラフィック
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の数。 また、試験報告書SHOULDは、DUT/SUTが提供されたUDP/IPトラフィックを進めたかどうかが断片化したことに注意します。
5.10 Latency
5.10 潜在
5.10.1 Objective
5.10.1 目的
To determine the latency of network-layer or application-layer data traversing the DUT/SUT. RFC 1242 [3] defines latency.
DUT/SUTを横断するネットワーク層か応用層データの潜在を決定するために。 RFC1242[3]は潜在を定義します。
Hickman, et al. Informational [Page 26] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[26ページ]のRFC3511方法論
5.10.2 Setup Parameters
5.10.2 セットアップパラメタ
The following parameters MUST be defined:
以下のパラメタを定義しなければなりません:
5.10.2.1 Network-layer Measurements
5.10.2.1 ネットワーク層測定値
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.
試験計器はユニークなタイムスタンプ署名でパケットを生成しなければなりません。
5.10.2.2 Application-layer Measurements
5.10.2.2 応用層測定値
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.
オブジェクトサイズ: GETが要求するHTTPより多くの1.1に対応して移すためにHTTPヘッダに関連しているどんなバイトも除いて、バイト数を定義します。 また、サイズがメディアでSHOULDをサポートした最小のオブジェクトが使用されて、他のオブジェクトサイズだけを使用してもよいです。
Connection type:
The test instrument MUST use one HTTP 1.1 or higher connection for
latency measurements.
結合方式: 試験計器は潜在測定値に1つのHTTP1.1か、より高い接続を使用しなければなりません。
Number of objects requested.
要求されたオブジェクトの数。
Number of objects transferred.
オブジェクトの数は移されました。
Test duration, expressed in seconds.
秒に言い表された持続時間をテストしてください。
Test instruments MUST generate packets with unique timestamp signatures.
試験計器はユニークなタイムスタンプ署名でパケットを生成しなければなりません。
5.10.3 Network-layer procedure
5.10.3 ネットワーク層手順
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]、潜在測定値を取らなければならないことに注意するように、すなわち、スループットレベル、ものでは、提供される中で最も高いパケット損失に全く積まないでください。 スループットレベルで取られた測定値は合法的に潜在と呼ぶことができる唯一のものです。
Hickman, et al. Informational [Page 27] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[27ページ]のRFC3511方法論
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.
implementers使用がスループットレベルで提供しただけではなく、スループットレベルよりさらに少ないか、または大きい負荷レベルでも負荷を提供したのが、RECOMMENDEDです。 既存の用語への混乱を避けるために、潜在よりむしろ遅れとしてそのようなテストからの測定値をラベルしなければなりません。
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.
それは異なったパケットサイズで潜在測定を実行するRECOMMENDEDです。 異なったパケットサイズでテストするとき、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秒でなければなりません。
5.10.4 Application layer procedure
5.10.4 応用層手順
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.
HTTP1.1か、より高いクライアントが、HTTP1.1か、より高いサーバから1つ以上のHTTP GET要求を使用することで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.
Implementersは、固定持続時間に立候補するために試験計器を構成するかもしれません。 この場合、試験計器はテストの持続時間のために要求されていて、返されたオブジェクトの数を報告しなければなりません。 固定耐久テストのために、持続時間が少なくとも30秒であることはRECOMMENDEDです。
5.10.5 Measurements
5.10.5 測定値
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を横断するデータによって被られた遅れのすべての測定値の平均。
Hickman, et al. Informational [Page 28] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[28ページ]のRFC3511方法論
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を横断するデータに関して見ました、適宜。
5.10.6 Network-layer reporting format
5.10.6 ネットワーク層報告形式
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.
試験報告書はパケットサイズ、提供された負荷、および持続時間が使用したテストに注意しなければなりません。 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.
潜在結果SHOULD、テーブルの形式では、行で、それぞれのテストされたパケットサイズのために報告されてください。 そこに、SHOULDはパケットサイズ、意図しているレート、オファードレート、および結果の潜在のためのコラムであるか各テストのために値を遅らせます。
5.10.7 Application-layer reporting format
5.10.7 書式を報告する応用層
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.
試験報告書は要求と応答のサイズと数が完成したオブジェクトに注意しなければなりません。 適切であるなら、固定持続時間が使用されたなら、レポートはテスト持続時間に注意しなければなりません。 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.
潜在結果SHOULD、テーブルの形式では、行で、それぞれのオブジェクトサイズのために報告されてください。 そこに、SHOULDはオブジェクトサイズ、完成した要求の数、完成した応答の数、および結果の潜在のためのコラムであるか各テストのために値を遅らせます。
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.
故障解析: 試験報告書SHOULDはテスト持続時間の中で完全な状態でHTTP GET要求かそうしなかった応答の数と割合を示します。
Version information:
The test report MUST note the version of HTTP client and server.
バージョン情報: 試験報告書はHTTPクライアントとサーバのバージョンに注意しなければなりません。
6. References
6. 参照
6.1 Normative References
6.1 標準の参照
[1] Newman, D., "Benchmarking Terminology for Firewall Devices", RFC
2647, August 1999.
[1] ニューマン、D.、「ファイアウォールデバイスのためのベンチマーキング用語」、RFC2647、1999年8月。
[2] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[2] ブラドナーとS.とJ.McQuaid、「ネットワーク内部連絡デバイスのためのベンチマーキング方法論」、RFC2544、1999年3月。
Hickman, et al. Informational [Page 29] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[29ページ]のRFC3511方法論
[3] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[3] ブラドナー、S.、「ネットワーク相互接続デバイスのためのベンチマーキング用語」、RFC1242、1991年7月。
[4] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998.
[4] マンデヴィル、R.、「LAN切換装置のためのベンチマーキング用語」、RFC2285、1998年2月。
[5] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN
Switching Devices", RFC 2889, August 2000.
[5] マンデヴィルとR.とJ.Perser、「LAN切換装置のためのベンチマーキング方法論」、RFC2889、2000年8月。
6.2 Informative References
6.2 有益な参照
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[7] Clark, D., "IP Datagram Reassembly Algorithm", RFC 815, July
1982.
[7] クラーク、D.、「IPデータグラムReassemblyアルゴリズム」、RFC815、1982年7月。
[8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[8] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
7. Security Considerations
7. セキュリティ問題
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.
このドキュメントのプライマリ目標はベンチマーキングファイアウォール性能に方法論を提供することです。 性能と安全保障問題の間には、何らかのオーバラップがありますが、このドキュメントの範囲の外にファイアウォールセキュリティの査定があります。
Hickman, et al. Informational [Page 30] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[30ページ]のRFC3511方法論
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です。 HTTP1.0はデフォルトでパーシステントコネクションをサポートしません。 要求されたオブジェクト転送が終了した後に、別々のTCP接続は、クライアントが開始したがっているそれぞれのGET要求のために開けられて、閉店します。 HTTP/1.0が生きている生活費の使用で固執をサポートするいくつかの実装をゆったり過ごしてください、そして、生きている生活費がどう作動するか公式の仕様書が全くありません。 さらに、彼らが接続ヘッダーを認めないとき、プロキシがするHTTP1.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 SHOULDでは、テスト時間を超えている持続時間のために、構成されます。
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方向ハンドシェイクにおける、最終的なACKの最後のビットが目標サーバによって受け取られる時まであると考えられます。
Hickman, et al. Informational [Page 31] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[31ページ]のRFC3511方法論
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との別々の接続を確立します: クライアントはサーバ*t5にTCPデータグラムを送ります: プロキシはデータグラムの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.
* TCPコネクション確立の一部であるとt5を考えていない間、接続がうまくいくと考えられるために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接続がそうである、シンプレクスファッションで全二重、そのような接続の疾走を実行します、すなわち、TCP接続の各側面を終える各ホスト/デバイスはFINセグメントを送ります。
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パケットの最後のビットの領収書まで要求して。
Hickman, et al. Informational [Page 32] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[32ページ]のRFC3511方法論
Authors' Addresses
作者のアドレス
Brooks Hickman Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
ブルックスヒックマンSpirent Communications26750Agoura Roadカリフォルニア91302カラバサス(米国)
Phone: + 1 818 676 2412 EMail: brooks.hickman@spirentcom.com
以下に電話をしてください。 2412がメールする+1 818 676: brooks.hickman@spirentcom.com
David Newman Network Test Inc. 31324 Via Colinas, Suite 113 Westlake Village, CA 91362-6761 USA
Colinasを通したデヴィッドニューマンネットワークテスト株式会社31324、スイート113ウェストレーク村、カリフォルニア91362-6761米国
Phone: + 1 818 889-0011 EMail: dnewman@networktest.com
以下に電話をしてください。 + 1 818 889-0011メール: dnewman@networktest.com
Saldju Tadjudin Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
Saldju Tadjudin Spirentコミュニケーション26750Agoura Roadカリフォルニア91302カラバサス(米国)
Phone: + 1 818 676 2468 EMail: Saldju.Tadjudin@spirentcom.com
以下に電話をしてください。 2468がメールする+1 818 676: Saldju.Tadjudin@spirentcom.com
Terry Martin GVNW Consulting Inc. 8050 SW Warm Springs Road Tualatin Or. 97062 USA
またはタオルマーチンGVNWコンサルティングInc.8050SWウォームスプリングズ道路Tualatin。 97062 米国
Phone: + 1 503 612 4422 EMail: tmartin@gvnw.com
以下に電話をしてください。 4422がメールする+1 503 612: tmartin@gvnw.com
Hickman, et al. Informational [Page 33] RFC 3511 Methodology for Firewall Performance April 2003
ヒックマン、他 ファイアウォールパフォーマンス2003年4月のための情報[33ページ]のRFC3511方法論
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Hickman, et al. Informational [Page 34]
ヒックマン、他 情報[34ページ]
一覧
スポンサーリンク
