跳到主要内容

4. 协议概述 (Protocol Overview)

本文档定义的所有消息都应 (SHALL) 使用 UDP 传输 [RFC0768].

本节其余部分对两个测试端点之间的通信协议给出资料性概述, 不表达要求, 也不详细说明认证方面的内容.

一个端点承担服务器角色, 在标准 UDP Speed Test Protocol 端口号上监听来自另一个端点 (客户端) 的连接请求.

为了开始与服务器的建立和配置交换, 客户端需要配置测试方向参数 (上行或下行测试, 其中客户端分别承担发送方或接收方角色), 以及服务器的主机名或 IP 地址. 默认情况下, 客户端对每个连接使用单一标准 UDPSTP 端口号 (见第 6 节). 如果不使用默认端口号, 客户端可能需要配置每个服务器使用的控制端口号. 当多个服务器实例 (进程) 在一台或多台机器上运行时, 就会出现这种情况.

此外, 该协议支持多连接 (多流) 测试. 每个连接都是独立的, 并尝试最大化其自身的单独流量速率. 对于多连接测试, 单个客户端进程会向一个或多个服务器实例多次复制连接建立和测试过程 (每个流一次). 服务器实例会独立处理每个连接, 就像这些连接来自不同客户端一样. 客户端进程负责管理这些相互关联的连接, 例如处理各个连接建立的成功和失败, 在测试期间清理连接 (如果某些连接失败), 以及将各个测试结果聚合为整体性能统计. Setup Request 中的字段 (即 mcIndex, mcCount 和 mcIdent; 见第 6.1 节) 用于区分并关联构成单个测试的多个连接.

该协议使用 UDP 传输, 并包含两个连接阶段: Control 和 Data. 如下所示, 交换 1 和 2 构成 Control 阶段, 交换 3 和 4 构成 Data 阶段. 在本文档中, 术语 "message" 与术语 "Protocol Data Unit" 或 "PDU" [RFC5044] 可互换使用.

  1. Test Setup Request and Response: 如果服务器实例由一个主机名标识, 且该主机名解析为 IPv4/IPv6 两类地址, 推荐使用名称解析响应返回的第一个地址, 无论它是 IPv4 还是 IPv6. 因此, 首选 IP 地址族的决策交给名称解析器的默认行为. 对单独 IPv4 和 IPv6 测量, 或 IPv4 与 IPv6 多连接建立的支持留待未来改进. 然后, 客户端通过传达其 UDPSTP 协议版本, 预期安全模式和数据报大小支持来请求开始测试. 服务器要么确认匹配某个配置, 要么拒绝连接请求. 如果请求被接受, 服务器会为每个测试连接提供唯一的临时端口号, 以允许后续通信. 在多连接建立中, 每个来自服务器实例的 Setup Response 都可能分配不同的 UDP 端口号. 如果在这种情况下所有 Setup Response 消息都源自同一服务器, 则会分配不同的 UDP 端口号.

  2. Test Activation Request and Response: 在收到服务器对配置的确认后, 客户端会构造一个请求, 传达测试方向, 测试间隔和测试子间隔的持续时间, 以及各种阈值等参数 (详细讨论见 [RFC9097] 和 [TR-471]). 然后, 服务器选择接受, 忽略或修改任意测试参数, 并传达将要使用的参数集合, 除非客户端拒绝这些修改. 注意, 客户端假定 Test Activation 交换已经为该测试连接 (响应临时端口号上的 Request 数据包) 以及随后的流量打开任何共址防火墙和网络地址/端口转换器. 关于防火墙和 NAT 相关特性的更详细讨论见 [RFC9097]. 如果 Test Activation Request 被拒绝或失败, 客户端假定防火墙会在其配置的空闲流量超时后关闭地址/端口号针孔条目.

  3. Test Stream Transmission and Measurement Feedback Messages: 测试过程中, 一个端点发送 Load PDU, 另一个端点接收 Load PDU 并频繁发送状态消息, 以传达状态和接收条件. 反馈消息中的数据, 无论是从客户端接收, 还是发送给客户端, 都会作为服务器上负载速率调整算法的输入, 该算法控制任一端未来的发送速率. 无论传输方向如何都将负载速率调整算法放在服务器上, 意味着该算法可以在网络内主机上更容易更新, 并且需要更新的主机数量少于客户端数量. 注意, 状态消息也有助于让路径上的有状态设备保持针孔 (或相应映射) 活跃. 如果瓶颈发生拥塞, UDPSTP 至少部分符合 [RFC8085] 第 3.1 节. 但通过将拥塞持续时间限制为确定瓶颈容量所需的最短时间, 可以避免即将发生的拥塞.

  4. Stopping the Test: 当达到指定测试持续时间时, 服务器通过在其发出的 Load PDU 或 Status Feedback 消息中设置 STOP 指示来发起停止测试的交换. 客户端收到后, 也通过在其发出的 Load PDU 或 Status Feedback 消息中设置 STOP 指示来确认. 然后, 每端都会进行优雅连接终止. 由于使用的是 Load PDU 和 Status Feedback 消息, 该交换被视为上述第 3 项的子交换. 如果测试流量停止或通信路径失败, 客户端假定防火墙会在其配置的空闲流量超时后关闭该地址/端口号组合.

  5. 客户端和服务器都会分别对 Control 阶段或 Data 阶段中的意外中断作出反应. Watchdog 定时器限制服务器或客户端在停止所有流量并终止测试之前等待的时间.

图 1 给出了下行和上行 UDP Speed Test 的控制与测量 PDU 交换示例 (始终由客户端发起):

             =========== Downstream Test ===========
+---------+                                           +---------+
| Client  |          Test Setup Request ----->        |  Server |
+---------+                                           +---------+
            <----- Test Setup Response (Accept)
            <----- Null Request PDU

                   Test Activation Request ----->

            <----- Test Activation Response (Accept)

            <----- Load PDUs

                      Status Feedback PDUs ----->

          After expiry of server's test duration timer...

            <----- Load PDU (TEST_ACT_STOP)

           Status Feedback PDU (TEST_ACT_STOP) ----->


             ============ Upstream Test ============
+---------+                                           +---------+
| Client  |          Test Setup Request ----->        |  Server |
+---------+                                           +---------+
            <----- Test Setup Response (Accept)
            <----- Null Request PDU

                   Test Activation Request ----->

            <----- Test Activation Response (Accept)

                      Load PDUs ----->

            <----- Status Feedback PDUs

          After expiry of server's test duration timer...

            <----- Status Feedback PDU (TEST_ACT_STOP)

                    Load PDU (TEST_ACT_STOP) ----->

            Figure 1: Successful UDPSTP Message Exchanges

4.1. 固定速率测试 (Fixed-Rate Testing)​

如果网络运营商确定需要验证的 IP-Layer Capacity, 可以执行固定速率 IP-Layer Capacity 测试, 并避免激活测量负载速率调整算法 (见 [RFC9097] 第 8.1 节). 固定速率测试应当 (SHOULD) 只由运营商在其本地网络域内出于运行和维护目的激活.

如果订户向网络运营商请求诊断测试, 这强烈暗示瓶颈容量并不确定, 因此推荐 (RECOMMENDED) 发起基于负载调整算法的 UDP Speed Test. 为防止误用, 客户端 (通常也包括消费者) 禁止 (MUST NOT) 发起固定速率测试. 网络运营商可以出于调试目的, 在负载速率调整算法确定的最大值附近或等于该最大值处执行固定速率测试, 以获得稳定测量. 这对于安装后或修复后的验证可能很有价值.

4.2. 自诱导拥塞的处理和所需保护措施 (Handling of and Safeguards Required by Self-Induced Congestion)​

主动容量测量需要有意诱导拥塞. 在容量瓶颈不与其他流共享的路径上, 这种自拥塞会表现为丢包和/或延迟. 但是, 当路径由其他流共享时, 测量流量可能会使路径上的瓶颈拥塞, 从而降低其他流的性能. 不受限制地使用 UDPSTP 可能导致流量饥饿和严重问题.

在共享路径 (包括 Wi-Fi 和 Internet 路径) 上生成流量的测量需要考虑对其他流量的影响. 固定速率测试在没有拥塞控制的情况下运行, 因此不得在其他运营商的网段上执行. 因此, 固定速率测试仅限于完全由执行测量的网络运营商按段和端到端管理及运营的域内路径. 在考虑对其他流造成中断的风险后, 测试可以扩展到同样存在测试协议的相邻运营域.

使共同瓶颈拥塞的并发测试会损害测量并导致额外拥塞. 在单一路径上并发测量最大容量会适得其反. 无论流数量多少, 对一条路径的并发独立测试数量都应 (SHALL) 限制为一个.

需要使用负载速率调整算法 (见第 5.1 节) 来缓解这种拥塞的影响, 并在检测到突然损伤或连接丢失时终止测试, 从而限制任何拥塞的持续时间.

最后于 更新