通过 Viavi MTS-5800TrueSpeed 进行的 RFC 6349 测试— 像客户一样体验您的网络

RFC 6349 是 Viavi 与来自 Bell Canada 和 Deutsche Telecom 的代表合作开发的一种新的传输控制 协议 (TCP) 吞吐量测试方法。RFC 6349 最近由互联网工程任务 组 (IETF) 组织发布，提供了一种可 重复的 TCP 吞吐量分析测试方法，以及用于优化网络和服务器性能的系统化流程、指标和准则。

本应用指南对“TCP 吞吐量测试框架”即 RFC 6349 进行了简要说明，并且 重点描述了 TrueSpeed 这一自动化并且完全符合标准的 Viavi RFC 6349 的实现——TrueSpeed 现在可在 Viavi MTS-6000A 多服务应用程序模块 (MSAM) 和 MTS-5800 手持式网络测试仪上提供。 本应用指南还讨论了 TrueSpeed RFC 6349 与 ITU Y.1564 以太网服务激活 标准的集成。这一功能强大的测试组合提供了一种全面的方法来确保在多 服务（例如三网融合）环境中实现最佳最终客户体验。

RFC 6349 TCP 测试方法 

RFC 6349 指定了一种用于在托管 IP 网络中测量端对端 TCP 吞吐量的实 用方法，其目标是为了更好地展现用户体验情况。在 RFC 6349 框架中， 还指定了 TCP 和 IP 参数来优化 TCP 吞吐量。

RFC 6349 建议在 TCP 测试之前始终执行第 2/3 层开通测试。验证位于第 2/3 层的网络之后，RFC 6349 指定执行以下三个测试步骤。

● 路径 MTU 检测（依照 RFC 4821），用于验证网络最大传输单元 (MTU)， 并进行活动 TCP 段大小测试来确保 TCP 净荷保持完整。

● 基准往返延迟和带宽测试，预测最佳 TCP 窗口大小，用于自动计算 TCP BDP 。

● 单一和多个 TCP 连接吞吐量测试，用于验证实现自动“满管”TCP 测试的 TCP 窗口大小预测 以下各个小节提供了每个 RFC 6349 测试步骤的详细信息。

路径 MTU 发现（依照 RFC 4821） 

TCP 实现应使用依赖于互联网控制消息协议 (ICMP)“需要分片”消息的 路径 MTU 发现技术 (PMTUD) 来了解路径 MTU。如果设备要发送的数 据包在 IP 头中设置了不分片 (DF) 位，并且该数据包比下一个中继段的 MTU 大，则会丢弃该数据包，且该设备会将一条 ICMP 需要分片消息发 回到最初发出该数据包的主机。ICMP 需要分片消息包括下一个中继段的 MTU，PMTUD 使用该 MTU 来对自身进行调整。遗憾的是，由于许多网 络管理员完全禁用了 ICMP，因此这一技术可能多少有些不可靠。

因此，RFC 6349 建议执行依照 RFC 4821 的分组层路径 MTU 发现 (PLPMTUD) 来验证网络路径 MTU，因为它可在有或者没有 ICMP 的情 况下使用。PLPMTUD 指定使用实时 TCP 流量轮询网络来确定 MTU。 采用了与设置 IP 数据包 DF 位相同的技术，但由于它使用实时 TCP 会话，因此不依赖于 ICMP。该算法使用 TCP 重发条件来搜索 MTU， 用于避免在所有后续步骤中分片。

基准往返延迟和带宽 

务必要确定基准往返时间 (RTT) 或非堵塞固有延迟以及端到端网络的瓶 颈带宽 (BB)，然后才能开始 TCP 测试。这些基准测量用于计算 BDP 和 估算 TCP 接收窗口 (RWND) 大小，并发送将在后续测试步骤中使用的套 接字缓冲区。

在广域网 (WAN) 链路上，必须对 TCP 进行适当的配置，来调整发送方在 接收来自接收方的确认 (ACK) 之前可传输的字节数。这一“in-flight”字 节数通常称为 TCP 窗口；尽管事实上存在若干个工作中的 TCP 窗口机制。

图 1 描绘了往返延迟 (RTD) 为 25 毫秒的 45 Mbps WAN 链路上的 TCP 传 输中数据字节数这一概念。

在图 1 中，TCP 窗口的调优不适当，在请求 ACK 之前只从发送方传输了 64 kB。

如 RFC 6349 所述，BDP 为最佳 TCP 窗口，计算方式为

在此示例中，BDP 将为 140 kB，是发送方 64 kB 窗口大小的两倍多，并且 发送方将只获得大约 20 Mbps 的吞吐量。

RFC 6349 定义了以下机制用于测量 RTT：

● 第 2/3 层的活动流量生成，以及从一端到另一端的环回

● 数据包捕获

● 网络设备中的扩展管理信息库 (MIB) (RFC 4898)

● ICMP ping

BDP 同时依赖于 RTT 和 BB，因此它还需要测量 BB。为运营网络采用 的第 2/3 层测试（例如 RFC 2544）被指定为用于测量 BB 的一种方法。 知道了 RTT 和 BB 之后，RFC 6349 将能够计算后续 TCP 吞吐量测试的 预期 TCP 性能。

单一和多个 TCP 连接吞吐量测试

决定是要采用单一还是多个 TCP 连接测试取决于与最终用户环境中配置的 TCP RWND 相关的 BDP 大小。例如，长肥网络 (LFN) 的 BDP 为 2 MB， 则使用多个连接测试此网络路径可能更加现实。假定是 64 kB 的典型主机 TCP RWND 大小（例如，Windows XP），则使用 32 个 TCP 连接将模拟 出小型办公室场景。

尽管 RFC 6349 不要求测试多个连接，但作为最现实的方法，强烈建议进 行此测试来准确地验证 TCP 吞吐量。RFC 6349 还定义了在 TCP 吞吐量测 试过程中要测量的特定指标，接下来将加以讨论。

RFC 6349 指标

下面介绍了 RFC 6349 TCP 指标，以及使用这些指标来诊断 TCP 性能不理 想原因的示例。

TCP 传输时间 

第一个 RFC 6349 TCP 指标是 TCP 传输时间，该指标仅测量跨同步 TCP 连接传输数据块所花费的时间。理想的 TCP 传输时间来源于网络路径 BB 以及与网络路径关联的各种第 1/2/3 层开销，例如，通过 500 Mbps 以太 网服务在五个同步 TCP 连接上进行的 100 MB 批量传输，每个连接上传 100 MB。每个连接在测试期间可能会获得不同的吞吐量，因此确定总体 吞吐率并不总是很容易，特别是在连接数增加的情况下尤为如此。

更多信息，网盘下载文档：

链接：https://pan.baidu.com/s/1CU6In3-auO5B9icyRDHX1g 

提取码：5ojx