免责声明：截至本文发布时，该解决方案仍处于持续开发与扩展测试阶段。部分技术细节可能会在后续版本中优化调整。
什么是非侵入式监控
非侵入式监控是一种不会中断信源与接收器之间现有会话的监控方式。
换言之，监控探针不会与信源建立单独的会话，也不会像中继/代理解决方案那样创建中间会话。
优势
- 探针监控的会话正是待观测的目标会话。
- 探针不创建第二个会话，因此不会造成流量或信源的负载加倍。
- 不使用中继/代理，因此不会引入额外的延迟，也不会提高故障概率。
劣势
- 不仅需要配置探针，还需要配置交换设备；要求具备网络工程专业能力。
- 接收器的测量结果可能与探针的测量结果存在差异。但在服务质量 (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 特定指标列表。
由分析器计算得出：
- 数据包的最大 IAT
- SRT 丢包数
- 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 参数。支持直播流监控。