RFC 2544阅读笔记

网络互连设备的基准测试方法

摘要

本文档讨论并定义了许多可用于描述网络互连设备的性能特性的测试。除了定义测试外,本文档还描述了用于报告测试结果的具体格式。

附录A列出了我们认为应包括的特定情况下的测试和条件,并提供了有关测试实践的额外信息。

附录B是用于各种媒介上特定帧大小的最大帧速率的参考列表。

附录C给出了测试中使用的帧格式的一些示例。

1、引言

供应商经常从事“眼镜精神”,试图让他们的产品在市场上占有更好的地位。这通常涉及“烟雾和镜子”,以迷惑产品的潜在用户。本文档定义了一组特定的测试,供应商可以使用这些测试来测量和报告网络设备的性能特性。这些测试的结果将为用户提供来自不同供应商的可比数据,用于评估这些设备。先前的文档“网络互连设备的基准术语”(RFC 1242)定义了本文档中使用的许多术语。在使用本文件之前,应查阅术语文件。

2、现实状况

在编写本文件时,作者试图牢记所述试验设备都必须实际构建的要求。我们不知道是否有“现成”设备可用于执行所有测试,但我们认为可以建造此类设备。

3、待运行的测试

本文档中描述了许多测试,并非所有的测试都适用于所有类型的被测设备(DUT),供应商应执行特定类型产品支持的所有测试。作者明白在所有推荐条件下进行所有推荐试验需要相当长的时间,但我们认为这些结果值得付出这些努力。附录A列出了我们认为应包括在特定情况下的一些测试和条件。

4、评估结果

执行所有推荐的测试将会产生大量的数据,这些数据中的大部分不适用于各种情况下的设备评估。例如,路由器转发IPX帧的速率对于为不支持该协议的环境选择路由器几乎没有什么用处。即使评估与特定网络安装相关的数据,也需要可能不容易获得的经验。此外,必须选择要运行的测试和评估测试数据,同时了解关于少量试验的重复性、方差和统计意义的公认测试实践。

5、要求

在本文件中,用于定义每个特定要求的重要性的词语大写。这些词语包括:

  • MUST、REQUIRED、SHALL表示该项目是本规范的绝对要求。
  • SHOULDRECOMMENDED表示在特定情况下,可能有正当理由忽略这一项,但在选择不同的课程之前,应理解其全部含义,并仔细权衡情况。
  • MAY、OPTIONAL的意思是这个项目是真正可选的。例如,一个供应商可能会选择包含该项目,因为特定的市场需要它,或者因为它增强了产品;另一个供应商可能会忽略相同的项目。

如果实现不能满足其实现协议的一个或多个必需(MUST)要求,则该实现不兼容。

满足其协议的所有必须(MUST)和应该(SHOULD)要求的实现称为“无条件遵从”。

一个满足所有必须(MUST)要求但不是所有应该(SHOULD)要求的协议被称为“有条件地符合”。

6、测试设置

实现这一系列测试的理想方法是使用带有发送和接收端口的测试仪,从测试仪的发送端口连接到DUT的接收端口,又从DUT的发送端口连接回测试仪,如图1所示。由于测试仪发送测试流量并将其接收回来,因此在流量被转发到DUT之后,测试仪可以很容易地确定是否接收到了所有发送的数据包,并验证是否接收到了正确的数据包。类似的测试可以通过如图2所示的拓扑结构,将发送和接收设备分离出来对接到测试仪两端,但是除非它们由某些计算机以模拟单台测试仪的方式远程控制,否则精确执行某些测试(特别是吞吐量测试)所需的劳动可能会令人望而却步。

6.1、多种媒介类型的测试设置

可以使用两种不同的设置来测试DUT,DUT用于实际网络中,以连接不同媒介类型的网络,例如本地以太网到主干FDDI环。测试仪可以支持两种介质类型,在这种情况下,将使用图1所示的设置。

另一种测试设置中使用两个相同的DUT,如图3,在许多情况下,这种设置可以更准确地模拟实际场景。例如,用广域网链路或高速主干网连接两个局域网。这种设置在模拟以太局域网上的客户机与FDDI主干上的服务器进行交互的系统方面并不太好。

7、DUT设置

在开始执行测试之前,必须按照提供给用户的说明配置待测试的DUT,具体来说,就是所有支持的协议都将在设置DUT期间配置和使能(见附录A)。预期情况是所有测试将在不改变DUT配置或设置的情况下运行,而不是以执行特定测试所需的方式。例如,在帧处理速率的测试之间更改帧处理缓冲区的大小或在测试该协议的吞吐量时禁用除一个传输协议以外的所有传输协议是不可接受的。在启动测试以确定过滤器对吞吐量的影响时,有必要修改配置,但唯一的更改必须是启用特定的过滤器。DUT的设置应包括通常建议的路由更新间隔和保活频率。测试期间使用的软件的特定版本和精确DUT配置(包括禁用的功能)必须作为结果报告的一部分。

8、帧格式

用于以太网TCP/IP的测试帧格式见附录C:测试帧格式。这些精确的帧格式应该用于本文档中描述的此协议/媒介组合的测试,并且这些帧将用作测试其他协议/媒介组合的模板。用于定义特定测试系列的测试帧的特定格式必须包含在结果报告中。

9、帧大小

所有描述的测试应在多种帧尺寸下进行。具体而言,大小应包括被测介质上被测协议的最大和最小合法大小,以及能够获得DUT性能完整特性的足够大小。除非另有说明,否则对每个试验应进行至少五种帧大小的试验。

理论上,最小长度的UDP应答请求帧由一个IP头(最小长度20字节)、一个UDP头(8字节)和所使用的媒介所需的任何MAC头组成。理论上的最大帧长由IP报头中长度字段(Length/Type)的大小决定。在几乎所有情况下,实际的最大和最小尺寸都是由介质的限制决定的。

理论上,以一种均匀分布理论帧速率的方式来分配帧大小是理想的。这些建议结合了这一理论,但规定了易于理解和记忆的帧大小。此外,在每种介质类型上都指定了许多相同的帧大小,以便进行性能比较。

注:在某些媒体类型上包含不现实的短帧(即,很少或没有数据空间)有助于表征DUT的每帧处理开销。

9.1、以太网上使用的帧大小

64, 128, 256, 512, 1024, 1280, 1518

这些大小包括以太网标准允许的最大和最小帧长,以及在这些极限之间的尺寸选择,对于较小的帧尺寸和较高的帧速率具有更细的粒度。

9.2、用于4Mb和16Mb令牌环的帧大小

54, 64, 128, 256, 1024, 1518, 2048, 4472

令牌环的帧大小建议假定路由协议的帧中没有RIF字段,RIF字段将出现在任何直接源路由桥性能测试中。令牌环上UDP的最小帧大小为54字节。由于许多令牌环接口的大小限制,建议16Mb令牌环的最大长度为4472字节,而不是理论上的17.9Kb。其余尺寸的选择允许与其他类型的介质进行直接比较。如果需要更高的数据速率,则可以另外使用IP(即,非UDP)帧,在这种情况下,最小帧大小是46字节。

9.3、FDDI上使用的帧大小

54, 64, 128, 256, 1024, 1518, 2048, 4472

FDDI上UDP的最小帧长为53字节,建议的最小帧长为54字节,以允许直接比较令牌环性能。最大帧长建议使用4472字节,而不是理论上的4500字节,以允许进行相同类型的比较。如果需要更高的数据速率,则可以另外使用IP(即,非UDP)帧,在这种情况下,最小帧长是45字节。

9.4、存在不同MTU时的帧大小

当互连DUT支持与具有不同MTU的链路连接时,应使用具有“更大”MTU的链路的帧大小,最大可到所测试协议的限制大小。如果互连DUT在MTU不匹配的情况下不支持帧分片,则该帧大小的转发速率应报告为零。

例如,使用连接FDDI和以太网的网桥或路由器进行IP转发的测试,应该在从FDDI进入到以太网链路时使用FDDI的帧大小。如果网桥不支持IP分片,那么对于以太网来说太大的帧的转发速率应该报告为零。

10、验证接收到的帧

测试设备应该丢弃在测试运行期间接收到的不是实际转发的测试帧的任何帧,例如,“保活”和“路由更新”帧不应包含在接收帧的计数中。在任何情况下,测试设备都应验证接收帧的长度,并检查它们是否与预期长度匹配。

更可取的是,测试设备应包括发送帧中的序列号,并在接收帧上检查该序列号。如果这样做了,报告的结果除了应包括丢弃的帧数外,还应包括接收到的无序帧数、接收到的重复帧数以及接收到的帧编号序列中的间隔数。所描述的某些测试需要此功能。

11、调节器

了解DUT在多种条件下的性能可能很有用,其中一些条件如下所述。报告的结果应包括测试设备能够产生的所有这些条件。测试组应该首先在没有任何修改条件的情况下运行,然后在每个条件下分别重复。为了保持比较这些测试结果的能力,生成修改条件(例如,管理查询)所需的任何帧将被包括在与正常测试帧相同的数据流中以代替其中一个测试帧,并且不在单独的网络端口上被提供给DUT。

11.1、广播帧

在大多数路由器设计中,当接收到寻址到硬件广播地址的帧时,需要特殊处理。在网桥(或在网桥模式的路由器)中,这些广播帧必须被灌到多个端口。测试帧的流应增加1%的帧寻址到硬件广播地址。发送到广播地址的帧应该是路由器不需要处理的类型。本测试的目的是确定是否对流中其他数据的转发速率有任何影响。应使用的特定帧包含在测试帧格式文档中。广播帧应均匀地分布在整个数据流中,例如,每100个帧。

同样的测试应该在桥式DUT上进行,但在这种情况下,广播报文将被处理,并灌到所有出端口。

据了解,1%的广播帧级别比许多网络经验要高得多,但是,就像在药物毒性评估中,要求更高的级别能够测量影响,否则通常会落在系统性能的正常可变性范围内。由于设计因素,一些测试设备将无法生成如此低级别的交替帧。在这些情况下,百分比应达到设备所能提供的最低要求,并在测试结果报告中描述实际水平。

11.2、管理帧

现在,大多数数据网络都使用SNMP等管理协议。在许多环境中,可以有多个管理站同时向同一DUT发送查询。测试帧流应该增加一个管理查询,作为在测试期间每秒发送的第一帧,查询结果必须对应一个响应帧,响应帧应由试验设备进行验证。应使用的特定查询帧的一个示例如附录C所示。

11.3、路由更新帧

动态路由协议更新的处理会对路由器转发数据帧的能力产生重大影响。测试帧流应该增加一个路由更新帧,作为在试验期间传输的第一帧。路由更新帧应以附录C中针对测试中使用的特定路由协议指定的速率发送。附录C中为以太网上TCP/IP定义了两个路由更新帧。路由帧用于将路由更改为不涉及测试数据转发的多个网络。第一帧将路由表状态设置为“A”,第二帧将状态更改为“B”。在试验期间,必须交替使用帧。测试应验证路由更新是否由DUT处理。

11.4、过滤器

过滤器被添加到路由器和网桥,以选择性地抑制帧的转发。这样做通常是为了对一个区域和另一个区域之间接受的数据实施安全控制。不同的产品具有实现过滤器的不同功能。

DUT应首先配置为添加一个过滤条件和执行的测试,此过滤器应允许转发测试数据流。在路由器中的过滤器的形式应为:转发input_protocol_address 到output_protocol_address。在网桥中的过滤器的形式应为:转发destination_hardware_address。

然后应重新配置DUT,以实现总共25个过滤器。前24个过滤器的形式应为:过滤input_protocol_address到output_protocol_address之间的地址。

24个输入和输出协议地址不应是测试数据流中表示的任何地址,最后一个过滤器应允许转发测试数据流。“first”和“last”的意思是确保在第二种情况下,在数据帧与允许帧转发的条件匹配之前,必须检查25个条件。当然,如果DUT对过滤器进行重新排序或不使用过滤器规则的线性扫描,则过滤器输入顺序的效果将正确丢失。

结果报告中应包括使用的确切过滤器配置命令行。

11.4.1、过滤器地址

需要两组过滤器地址,一个用于单个过滤器的场景,一个用于25个过滤器的场景。

单个过滤器应允许从IP地址198.18.1.2到IP地址198.19.65.2的流量,并拒绝所有其他流量。

25个过滤器场景应遵循以下顺序:

在输入此序列之前,所有以前的过滤条件都应从路由器中清除。选择该序列是为了测试路由器是否对过滤条件进行排序,或者是否按照输入的顺序接受过滤条件。这两个过程对性能的影响都比某种形式的散列编码更大。

12、协议地址

使用单个逻辑数据流、一个源协议地址和一个目的协议地址来实现这些测试更容易,对于上述过滤器的某些条件,这是一个实际需求。现实世界中的网络并不局限于单一的数据流。测试组应该首先使用单一协议(或网桥测试的硬件)源地址和目的地址对来运行,然后应使用随机目的地址重复测试。在测试路由器时,地址应在256个网络范围内随机均匀分布,在网桥的整个MAC范围内随机均匀分布。IP使用的具体地址范围如附录C所示。

 

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:[email protected] 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1 RFC文档中文翻译计划组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:[email protected] 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1 RFC文档中文翻译计划组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:[email protected] 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:[email protected] 译者:王翌(mcsewang [email protected]) 译文发布时间:2001-6-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须 保留本文档的翻译及版权信息。 Network Working Group S. Crocker RFC-10 UCLA 21 July 1969 文档规范 (RFC10 ── DOCUMENTATION CONVENTIONS) 此规范是NWG/RFC # 3 的修订版。 网络工作组(Network Working Group)包括来自尤他洲的Steve Carr,SRI 的 Elmer Shapiro 和 Bill English,UCLA的Steve Crocker,RAND 的 John Haefner,林肯实验室的 Paul Rovner 和 Jim Curry,成员资格没有限制。 网络工作组(Network Working Group:NWG)关注主机软件、网络使用策略及网络应 用中的初始经验。 NWG工作文档通过类似于本文的笔记形式纪录。这种文档可以由任何站点的任何人发 布并包括在这个系列中。 内容 NWG文件记录的可以是任何想法、建议等与主机软件或网络的其他特征相关的内容。 文件不一定要文辞精美,但应尽量保证内容的时效性和及时性。以下几种内容的文档也可以, 如:纯粹的立场观点的表述,而没有举出实例和其他一些细节;提出特别的建议或执行技巧 而没有给出相关的背景解释;只是明白的提出一个问题而没有给出任何解答。一份文档要求 不少于一句话。 这些标准是基于下面两个原因制定的:第一,人们倾向于将文件记录当成事实上的权 威,我们希望推动交流和讨论而不是听信权威性的结论。第二,人们通常不愿发表一些未认 真雕琢过的文章,我们希望消除这种顾虑。 格式 每篇NWG 文档都应该包括下列信息: 1. “ Network Working Group ” “ Request for Comnments : X”( X下划线 ) 其中X是一个序号,它由UCLA的Steve Crocker 给出 2. 作者及合作人 3. 日期 4. 题目 标题不要求唯一 发布 笔记的一份拷贝由作者的站点发至下列成员: 1. Steve Crocker, UCLA 2. Ron Stoughton, UCSB 3. Elmer Shapiro, SRI 4. Steve Carr, Utah 5. John Haefner, RAND 6. Paul Rovner, LL 7. Bob Kahn, BB&N 8. Larry Roberts, ARPA 9. Jerry Cole, SDC 若有需要,副本可以在本地自行处理。 地址 以下是最新的地址,必要时请更正: Steve Crocker UCLA 3732 Boelter Hall (213) 825-4864 UCLA 825-2543 Sec'y Los Angeles, California 90024 Ron Stoughton UCSB Computer Research Lab. (805) 961-3221 UCSB Santa Barbara, California 93106 Elmer Shapiro SRI Stanford Research Institute (415)326-6200 333 Ravenswood Menlo Park, California 94025  Steve Carr Utah Computer Science Dept. (801) 322-8224 University of Utah Salt Lake City, Utah 84ll2 John Haefner RAND The Rand Corp. (213) 393-0411 1700 Main Street Santa Monica, California 90406 Paul D. Rovner LL Mass. Inst. of Tech. (617) 662-5500 Lincoln Laboratory B-115 X7211 P.O. Box 73 Lexington, Mass. 02173 Robert Kahn BBN Bolt, Beranek and Newman (617) 491-1850 50 Moulton St. 49l-1868 Cambridge, Mass. 02138 Larry Roberts ARPA ODS/ARPA (202) OX 7-8663 3D167 Pentagon OX 7-8654 Washington, D.C. 2030l Jerry Cole SDC 7842 Croyden 2500 Colorado L.A., California 90045 Santa Monica, California 90406 (213) 393-9411 X438 X6019 Sec'y RFC10 DOCUMENTATION CONVENTIONS 文档规范 1 RFC文档中文翻译计划 RFC文档中文翻译计划
IXnetwork RFC2544是一种网络性能测试方法,目的是通过模拟真实网络环境,检测和评估网络设备的性能表现。RFC2544是一项由IETF制定的标准,它提供了一种标准化的方法来测试网络设备的性能,包括吞吐量、延迟、丢包率等。 IXnetwork是一种专业的网络测试和性能评估工具,它可以使用RFC2544进行网络性能测试。通过使用IXnetwork,我们可以模拟各种网络流量和应用场景,以测试网络设备在不同负载条件下的性能。 使用IXnetwork RFC2544测试时,我们首先需要指定测试的目标,例如需要测试的网络设备、测试的参数和测试的条件等。然后,IXnetwork会发送具有不同负载的流量到被测设备,并收集响应数据进行性能分析。 在RFC2544测试过程中,我们可以获得以下信息: 1. 吞吐量:测试期间的实际转发速率。 2. 延迟:数据从发送到接收所需的时间。 3. 丢包率:在测试期间发生的数据包丢失的百分比。 4. 端到端的可靠性:根据不同条件下的测试结果,评估网络设备的性能。 通过使用IXnetwork RFC2544,我们可以实现以下目标: 1. 评估网络设备的性能:比较不同设备在相同条件下的性能表现,并选择最佳的设备。 2. 测试网络设备的极限:确定网络设备在最大负载下的性能极限。 3. 发现网络瓶颈:识别网络中的瓶颈,并优化网络结构。 总之,IXnetwork RFC2544是一项重要的网络性能测试方法,它可以帮助我们评估和优化网络设备的性能,提高网络的可靠性和效率。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值