什么是非侵入式监控非侵入式监控是一种不会中断信源与接收器之间现有会话的监控方式。换言之监控探针不会与信源建立单独的会话也不会像中继/代理解决方案那样创建中间会话。优势探针监控的会话正是待观测的目标会话。探针不创建第二个会话因此不会造成流量或信源的负载加倍。不使用中继/代理因此不会引入额外的延迟也不会提高故障概率。劣势不仅需要配置探针还需要配置交换设备要求具备网络工程专业能力。接收器的测量结果可能与探针的测量结果存在差异。但在服务质量 (QoS) 层面这种方式比创建单独的监控会话更准确。启动监控任务的操作相对复杂下文详述。监控加密流可能存在困难甚至无法实现。尽管存在上述不足但其优势更为突出且符合客户预期。什么是探针Boro 探针是一款软件应用程序运行于 Windows 或 Linux 环境下的 x86 兼容硬件上。它通常部署在专用服务器上以系统服务形式安装。服务器配备足够数量、足够带宽的网络适配器用于接收所监控的流。该应用程序也可直接安装在编码器、发送器、接收器及其他设备上前提是这些设备运行在 Windows 或 Linux 环境下的 x86 兼容硬件上。Boro 探针接收流并收集详细的 QoS、体验质量 (QoE) 指标。统计数据非流本身会发送至 Boro 服务器通常部署在单独的机器上。服务器提供探针管理、图形和表格的可视化展示以及触发和警报配置功能。非侵入式监控中的流量捕获方式从技术角度看非侵入式监控可以通过多种方式实现。如前所述这些方法既不得创建单独的会话也不得中断已建立的会话。网络 TAP网络 TAP测试接入点是串接在网络链路上的硬件设备。它会被动复制两个方向的所有流量用于监控、安全或分析目的而不会干扰实时数据流。与可能会丢弃数据包的 SPAN 端口不同它可提供完整的流量副本。TAP 的种类繁多包括简单串接在线缆中的无源设备以及能够汇聚多个端口并提供附加功能的更复杂的设备。无论是何种情况这种方法都需要安装额外的硬件并将其物理串接至链路中因此会引入潜在的故障点。端口镜像端口镜像又称交换端口分析器 (SPAN)是一种网络流量监控功能可将一个或多个信源端口的数据包复制到一个目标端口。连接到该目标端口的监控设备随后可以在不影响网络运行的情况下分析流量。这种方法的优点是无需额外的硬件因为几乎所有现代交换机都支持此功能且通常已部署在网络中。缺点包括镜像目标端口可能发生丢包主要原因有以下两点镜像目标端口的优先级可能低于其他端口在高负载情况下首先会丢弃数据包镜像转发的流量可能会超出目标端口的带宽承载能力。直接在信源或接收器上安装探针软件如果信源或接收器是在 x86 兼容 PC 上运行的软件Windows/Linux 环境则该计算机的网络协议栈可发挥类似于网络 TAP 的作用使探针能够直接访问入站流量。在何处捕获 SRT 信号前两种方法在中间节点实现监控而最后一种方法则将监控置于端点。在组播场景中探针通常连接到离潜在组播接收器位置最近的交换机上这是测量传输质量 (QoS) 的合理位置。但在监控 SRT 这类支持重传的协议时探针也可部署在信源侧或中间节点因为探针能够捕获包含重传请求的数据包。在这种情况下需要记录两组数据测量点的当前状态以及将接收器发出重传请求考虑在内的状态。无论使用哪种方法来分流流量以进行监控Boro 探针应用程序均可正常工作。下文以流量镜像为例进行说明。探针如何处理通过 SPAN 捕获的流量下图中监控在靠近接收器的中间节点执行。运行探针的服务器与 SRT 接收器连接至同一交换机。通过 SPAN 监控 SRT 会话的示意图交换设备必须支持端口镜像 (SPAN) 功能。该功能会复制所有到达接收器端口的流量并将副本转发至连接探针的端口。由于 SRT 协议是双向的配置镜像时必须同时镜像入站和出站流量。如本例所示当探针运行在单独的服务器上时无法通过标准方式接收镜像流量。镜像数据包的目标地址是其他主机无法通过标准套接字网络通信的常规 API接收。通常这类数据包会被网卡过滤器或操作系统的网络协议栈丢弃。因此在捕获流量时探针必须将网络适配器切换至混杂模式。在该模式下适配器会接收到达该端口的所有流量而不仅是目标为本机的流量。此外探针使用 PCAP数据包捕获 API库可在流量经过操作系统的网络过滤器之前将其捕获。PCAP 提供丰富的过滤能力可精准隔离目标 SRT 会话并将其转发以供进一步分析。在探针上启动监控任务由于通过数据包捕获进行监控并非一个简单的过程任务启动系统被设计为灵活可配置。用户可指定所有参数 —— srcIP:port dstIP:port四元组或部分参数 —— srcIP:port 或 dstIP:port。端口为必填项。此外还需指定被捕获流的协议类型在本文场景中即为 SRT。当前实现已在“呼叫-监听”(Caller–Listener) 模式的连接下完成测试这意味着至少有一个 IP 地址始终是已知的。单个 SRT 会话始终对应一个连接即一个固定的四元组。所有数据 —— 握手、命令交换、数据包重传请求以及有效载荷传输 —— 均在同一连接内完成。示例 1探针位于以 Caller 模式运行的接收器附近并且对等端之间的会话已经建立。在这种情况下信源 IP 地址、信源端口和接收器的 IP 地址是已知的但接收器的端口未知。通过指定已知参数用户可以启动一个可靠隔离所需会话的任务即使该接收器上还运行着另一个 Caller 模式的会话。示例 2探针位于以 Listener 模式运行的接收器附近。暂无 Caller 接入因此仅知道接收器的 IP 和端口。启动任务时仅指定 dstIP:port 对。探针会创建一个主任务监控指定 IP 和端口上的所有流量。当第一个 Caller 接入时主任务就会捕获数据包。如果协议被识别为 SRT它会自动创建一个子任务进行分析并将首批捕获的数据包传递给子任务。这样可以保留握手控制包。对于后续接入的每个 Caller都会创建一个新的子任务。SRT 监控SRT 协议非常适合在 Boro 中进行嗅探原因如下命令数量少且定义清晰仅对数据包进行加密会话密钥交换不使用完全前向保密算法通信仅使用单个端口数据以 MPEG-TS 格式传输。一旦被捕获只有属于目标会话的数据包才会被传递给监控任务并根据 SRT 规范进行解析。与 SRT 接收器类似探针会维护一个缓冲区来累积接收到的数据包。如果分析器检测到重传的数据包就会记录此事件。如果对应的缓冲槽尚未被清理重传的数据包会被插入到缓冲区中。这个过程会生成一个重建的数据流。重建的传输流随后会进入与常规组播流相同的处理流程测量包间到达时间 (IAT)、验证流完整性、分析 TR 101 290 参数等直至完成 QoE 检测。探针还会记录一组与标准 SRT 监控相同的指标包括预估带宽和往返时间 (RTT) 测量基于捕获的 ACK 数据包。如何判定过滤出的流是 SRT即使 SRT 流已加密SRT 数据包头部仍保持不加密状态。探针会查找一个推测的 SRT 数据包头部然后检查套接字 ID 字段该字段在所有数据包中应保持不变。随后探针会检查预期会递增的计数器字段。综合这些判定条件探针能够以高置信度识别 SRT 数据包。加密的 SRT要解密一个流探针需要满足以下条件。首先必须在分析任务中指定正确的加密口令。其次分析任务必须在对等端建立会话之前启动。在 Caller-Listener 模式下Caller 通过发送握手控制包来发起会话以交换配置参数。如果启用了加密握手控制包会包含用于交换加密和解密所需信息的密钥材料消息。通过拦截握手数据包探针可以获得解密流所需的信息密钥、向量和密码。对等端会定期轮换加密密钥探针也会捕获并在适当时机应用这些密钥。如果捕获任务是在会话已建立后启动的探针将无法获取密钥。在这种情况下监控任务中将仅显示入站码率而无其他详细信息。这种状态将持续到下一次密钥材料更新而此类更新发生的频率通常很低。加密是非侵入式监控的主要限制之一但如上所述只要遵循正确的流程启动顺序就可以解决这个问题。多路复用流的问题SRT 协议支持多路复用流。多个 SRT 套接字可共享同一个 UDP 套接字因此接收到该 UDP 套接字的数据包将被正确地分发至当前对应的目标 SRT 套接字。在握手阶段通信双方会交换各自的 SRT 套接字 ID。这些 ID 随后会被用于每个控制和数据包的“目标 SRT 套接字 ID”字段中。例如一个会话承载了两路流的复用。探针将捕获带有四个标识符的数据包两个数据标识符两个控制标识符。如果未捕获握手控制包就无法确定哪个标识符属于哪一路流。这个问题同样会影响 RTT 和预估带宽的测量因为探针跟踪的测量数据包也包含套接字 ID。与加密流一样监控多路复用流要求在 SRT 会话建立之前启动监控任务。缓冲区大小通过嗅探分析 SRT 时缓冲区大小是一个关键参数。探针的缓冲区大小必须与信源和接收器之间协商确定的缓冲区大小一致。只有这样监控任务中的数据包恢复行为才会与接收器的行为一致。在对等端协商阶段双方会确定最大的缓冲区大小并通过握手控制包进行传输。探针会使用所确定的缓冲区大小。但是如果探针未能捕获握手控制包则用户必须在任务创建表单中手动输入缓冲区大小然后才能启动任务。监控参数以下是通过非侵入式监控收集的 SRT 特定指标列表。由分析器计算得出数据包的最大 IATSRT 丢包数SRT 丢弃包数在监控任务侧测量可能与接收器统计数据不同SRT 收包数SRT 重传包数SRT 重传率SRT 码率SRT 接收缓冲区大小SRT 延迟从捕获的 ACK 数据包中提取SRT 带宽SRT 平滑往返时间 (SRTT)从捕获的 NAK 数据包中提取补充探针侧计算SRT 丢包数代码库与其他监控方法相比非侵入式监控具有显著优势但也需要大量的开发工作。我们无法直接使用现有的 libsrt 库并进行修改因为该库基于的标准假定在握手阶段以及从信源向接收器传输数据阶段均存在顺序数据交换。基于套接字的操作是内建在该库架构中的。相比之下嗅探模式下的探针不发送任何数据。它不会干扰数据包交换仅执行流量过滤以提取属于特定会话的数据。然后探针根据 SRT 标准将数据包解析为命令和数据并以与接收器相同的方式重建接收到的流。因此接收库几乎全部由 Elecard 团队编写仅复用了 libsrt 库中一小部分工具函数约占代码库的 7%–10%。我们没有偏离、扩展或修改 SRT 标准因为探针不会向被监控的会话发送任何一个数据包且使用的是未经修改的 libsrt 库。性能在撰写本文时尚未进行大规模的性能测试。但数据包捕获子系统已经在生产环境中运行了足够长的时间暴露出一些与性能相关的问题。PCAP 进程在单个 CPU 核心上运行最多能处理约 2 Gbit/s 的入站流量。在最新的探针版本中增加了一个智能算法可以创建多个进程避免捕获环节成为性能瓶颈。PCAP 进程仅负责选择属于特定会话的数据包然后将数据传递给其他进程。在此阶段基于嗅探的分析性能可认为与传统 SRT 分析不相上下。资源消耗最大的组件始终是视频解码和高级 QoE 分析它们的计算开销比数据接收高出几个数量级。所有监控方式的视频解码逻辑完全一致。结论SRT 协议的非侵入式监控是一种高效的解决方案满足了行业长期存在的需求。尽管与标准方法相比存在某些局限性且配置更为复杂但其优势大于劣势。研究表明这种方法可以收集到传统 SRT 监控能提供的所有信号指标。还有一个重要因素需要强调非侵入式监控的成本与传统方法基本持平因为它不需要更高的探针硬件性能。由于所需的交换设备几乎在所有生产环境中都已具备因此不会增加部署成本。作者Anton Proshutya — Elecard Boro 产品经理。自 2007 年以来他一直从事视频质量控制领域的工作。Elecard Boro — 用于 UDP、RTP、HTTP、HLS、DASH、SRT 和 RTMP 流质量控制的软件解决方案可测量分布式网络各环节的 QoS 和 QoE 参数。支持直播流监控。