Aviso legal: En el momento de la publicación, la solución aún se encuentra en fase de desarrollo activo y pruebas exhaustivas. Algunos detalles técnicos podrían perfeccionarse en versiones posteriores.
Qué es la monitorización no intrusiva
La monitorización no intrusiva es un método de monitorización en el que se observa una sesión existente entre una fuente de señal y un receptor sin interrumpir dicha sesión.
En otras palabras, la sonda de monitorización no establece una sesión independiente con la fuente ni crea sesiones intermedias, como ocurre en las soluciones de tipo relay/proxy.
Ventajas
- La sonda monitoriza exactamente la misma sesión que se desea observar.
- La sonda no crea una segunda sesión y, por lo tanto, no duplica el tráfico ni la carga sobre la fuente.
- No se emplea ningún relay/proxy, lo que significa que no se introduce latencia adicional ni se incrementa la probabilidad de fallo.
Desventajas
- Es necesario configurar no solo la sonda, sino también los equipos de conmutación; se requieren conocimientos de ingeniería de redes.
- Las mediciones en el receptor pueden diferir de las obtenidas por la sonda. No obstante, este enfoque es más preciso que crear una sesión de monitorización independiente en lo que respecta a la QoS.
- La puesta en marcha de las tareas de monitorización no es directa (se abordará más adelante).
- La monitorización de flujos cifrados puede resultar problemática o incluso imposible.
A pesar de todo, las ventajas superan a las desventajas, y este enfoque se ajusta a las expectativas de los clientes.
Qué es una sonda
Boro Probe es una aplicación de software que se ejecuta en hardware compatible con x86 bajo Windows o Linux. Normalmente se despliega en un servidor dedicado. La sonda se instala como servicio del sistema. El servidor se equipa con el número necesario de interfaces de red, cada uno con el ancho de banda suficiente para recibir los flujos monitorizados.
La aplicación también puede instalarse directamente en codificadores, transmisores, receptores y otros equipos, siempre que estos funcionen sobre hardware compatible con x86 con sistema operativo Windows o Linux.
Boro Probe recibe los flujos y recopila métricas detalladas de QoS y QoE. Las estadísticas (no los flujos en sí) se envían a Boro Server, que generalmente se despliega en una máquina independiente. El servidor proporciona la gestión de las sondas, la visualización de gráficos y tablas, así como la configuración de disparadores y alertas.
Métodos de captura de tráfico en la monitorización no intrusiva
Técnicamente, la monitorización no intrusiva puede implementarse de varias formas. Como se mencionó anteriormente, estos métodos no deben crear una sesión independiente ni interrumpir una ya establecida.
TAP de red
Un TAP de red (Test Access Point, o punto de acceso de prueba) es un dispositivo de hardware que se instala en línea en un enlace de red. Copia de forma pasiva todo el tráfico en ambas direcciones con fines de monitorización, seguridad o análisis, sin interrumpir el flujo de datos en producción. Proporciona una copia fiel del tráfico, a diferencia de los puertos SPAN, que pueden descartar paquetes. Los TAP van desde dispositivos pasivos sencillos que se insertan en línea con el cable hasta unidades más complejas capaces de agregar múltiples puertos y ofrecer funcionalidades adicionales. En todos los casos, este enfoque requiere la instalación de hardware adicional que se inserta físicamente en el enlace, lo que introduce un posible punto de fallo.
Duplicación de puertos
La duplicación de puertos, o SPAN (Switched Port Analyzer), es una función de monitorización del tráfico de red que copia los paquetes de uno o varios puertos de origen hacia un puerto de destino. Un dispositivo de monitorización conectado a dicho puerto puede entonces analizar el tráfico sin afectar a la red. La ventaja de este método es que no se requiere hardware adicional, ya que prácticamente todos los switches modernos soportan esta función y, por lo general, ya están presentes en la red. Entre las desventajas se encuentra la posible pérdida de paquetes en el puerto de destino del espejo, que puede producirse por dos razones:
- El puerto de destino del espejo puede tener menor prioridad que otros puertos y será el primero en descartar paquetes bajo carga elevada.
- La duplicación puede dirigir un volumen de tráfico que supere el ancho de banda del puerto de destino.
Instalación del software de sonda directamente en la fuente o el receptor de la señal
Si la fuente o el receptor es un software que se ejecuta en un PC compatible con x86 bajo Windows/Linux, la pila de red del ordenador cumple una función similar a la de un TAP de red, proporcionando a la sonda acceso directo al tráfico entrante.
Dónde capturar la señal SRT
Los dos primeros métodos organizan la monitorización en puntos intermedios, mientras que el último la sitúa en los puntos finales.
En escenarios de multicast, la sonda suele conectarse al switch más cercano en la ubicación del posible receptor multicast, donde resulta lógico medir la calidad de entrega (QoS). Sin embargo, cuando se monitoriza un protocolo con capacidad de retransmisión como SRT, la sonda también puede desplegarse en el lado de la fuente o en un punto intermedio, ya que puede capturar paquetes que contienen solicitudes de retransmisión.
En este caso, es necesario registrar dos conjuntos de datos: el estado actual en el punto de medición y el estado teniendo en cuenta las solicitudes de retransmisión del receptor.
La aplicación Boro Probe funciona independientemente del método utilizado para desviar el tráfico hacia la monitorización. A continuación, se utiliza la duplicación de tráfico como ejemplo.
Cómo funciona la sonda con tráfico capturado mediante SPAN
En el diagrama siguiente, la monitorización se realiza en un punto intermedio cercano al receptor. Un servidor que ejecuta la sonda está conectado al mismo switch que el receptor SRT.
Diagrama de monitorización de sesión SRT mediante SPAN
El equipo de conmutación debe ser compatible con la duplicación de puertos (SPAN). Esta función duplica todo el tráfico que llega al puerto del receptor y envía una copia al puerto conectado a la sonda. Al configurar la duplicación, se debe espejar tanto el tráfico entrante como el saliente, ya que el protocolo SRT es bidireccional.
Cuando la sonda se ejecuta en un servidor independiente —como en este ejemplo—, no puede recibir el tráfico duplicado de la forma convencional. Los paquetes duplicados están dirigidos a otros hosts y no pueden recibirse a través de sockets estándar (la API convencional para la comunicación de red). Normalmente, estos paquetes son descartados por los filtros de la tarjeta de red o por la pila de red del sistema operativo.
Por lo tanto, al capturar el tráfico, la sonda debe conmutar el adaptador de red al modo promiscuo. En este modo, el adaptador recibe todo el tráfico que llega al puerto, no solo el destinado a esa máquina. Además, la sonda utiliza la biblioteca PCAP (Packet Capture API), que permite capturar el tráfico antes de que pase por los filtros de red del sistema operativo. PCAP ofrece una amplia gama de capacidades de filtrado que permiten aislar la sesión SRT deseada y reenviarla para su posterior análisis.
Lanzamiento de tareas de monitorización en la sonda
El sistema de lanzamiento de tareas está diseñado para ser flexible, ya que la monitorización mediante captura de paquetes es un proceso no trivial.
El usuario puede especificar todos los parámetros —srcIP:port + dstIP:port (una 4-tupla)— o solo parámetros parciales —srcIP:port o dstIP:port—. El puerto es obligatorio. Además, se especifica el tipo de protocolo del flujo capturado, que en este caso es SRT.
La implementación actual ha sido probada con conexiones en modo Caller–Listener, lo que significa que siempre se conoce al menos una dirección IP. Una sesión SRT única siempre corresponde a una única conexión, es decir, a una 4-tupla fija. Todos los datos —handshake, intercambio de comandos, solicitudes de retransmisión de paquetes y entrega de carga útil— se producen dentro de la misma conexión.
Dos ejemplos ayudan a clarificar el proceso.
Ejemplo 1
La sonda se encuentra cerca de un receptor que funciona en modo Caller, y la sesión entre los pares ya está establecida. En este caso, se conocen la dirección IP de la fuente, el puerto de la fuente y la dirección IP del receptor, pero no el puerto del receptor. Al especificar los parámetros conocidos, el usuario puede iniciar una tarea que aísle de forma fiable la sesión requerida, incluso si en el receptor se está ejecutando otra sesión en modo Caller.
Ejemplo 2
La sonda se encuentra cerca de un receptor que funciona en modo Listener. Aún no se ha conectado ningún Caller, por lo que solo se conocen la IP y el puerto del receptor. Al iniciar la tarea, solo se especifica el par dstIP:port. La sonda crea una tarea maestra que monitoriza todo el tráfico en la IP y el puerto indicados. En cuanto se conecta el primer Caller, la tarea maestra captura los paquetes. Si el protocolo se identifica como SRT, crea automáticamente una subtarea de análisis, pasándole los primeros paquetes capturados. Esto permite conservar los paquetes de control del Handshake. Se crea una nueva subtarea para cada Caller posterior.
Monitorización SRT
El protocolo SRT resulta especialmente adecuado para el análisis por captura (sniffing) en Boro por varias razones:
- Tiene un número reducido de comandos bien definidos.
- El cifrado se aplica únicamente a los paquetes de datos.
- No se utilizan algoritmos de secreto perfecto hacia adelante (perfect forward secrecy) para el intercambio de claves de sesión.
- La comunicación se realiza a través de un único puerto.
- Los datos se transmiten en formato MPEG-TS.
Una vez capturados, solo los paquetes pertenecientes a la sesión objetivo se envían a la tarea de monitorización, donde se analizan conforme a la especificación SRT.
Al igual que un receptor SRT, la sonda mantiene un búfer que acumula los paquetes recibidos. Si el analizador detecta un paquete retransmitido, este evento se registra. Los paquetes retransmitidos se insertan en el búfer si la posición correspondiente aún no ha sido descartada. Este proceso produce un flujo de datos reconstruido.
El flujo de transporte reconstruido se envía entonces al mismo pipeline utilizado para los flujos multicast convencionales: se mide el IAT, se verifica la integridad del flujo, se analizan los parámetros TR 101 290, y así sucesivamente, hasta llegar a las comprobaciones de QoE.
La sonda también registra un conjunto de métricas idéntico al de la monitorización SRT estándar, incluyendo el ancho de banda estimado (Estimated Bandwidth) y las mediciones de RTT (basadas en los paquetes ACK capturados).
En las siguientes secciones se abordan con mayor detalle los aspectos más significativos del proceso de monitorización.
Cómo determinar si un flujo filtrado es SRT
Incluso si el flujo SRT está cifrado, las cabeceras de los paquetes SRT permanecen sin cifrar. La sonda busca una cabecera SRT presunta y, a continuación, verifica el campo Socket ID, que debe mantenerse constante entre paquetes. Después, la sonda examina los campos de contador, cuyo valor debería ir en aumento. En conjunto, estos criterios permiten a la sonda identificar paquetes SRT con un alto grado de fiabilidad.
SRT cifrado
Para descifrar un flujo, la sonda necesita que se cumplan ciertos requisitos. En primer lugar, se debe especificar la frase de cifrado (passphrase) correcta en la tarea de análisis. En segundo lugar, la tarea de análisis debe iniciarse antes de que los pares establezcan la sesión.
En el modo Caller–Listener, el Caller inicia la sesión enviando paquetes de control de handshake para intercambiar parámetros de configuración. Si el cifrado está habilitado, los paquetes de control de handshake contienen mensajes de material de claves (Key Material Messages) utilizados para intercambiar la información necesaria para el cifrado y descifrado. Al interceptar los paquetes de handshake, la sonda obtiene la información necesaria para descifrar el flujo: claves, vectores y contraseña.
Los pares rotan periódicamente las claves de cifrado, que la sonda también captura y aplica en el momento adecuado.
Si se inicia una tarea de captura para una sesión ya establecida, la sonda no tiene forma de obtener las claves. En este caso, la tarea de monitorización solo mostrará la tasa de bits entrante, sin mayor detalle. Esta situación persistirá hasta la siguiente actualización de material de claves (Key Material), que normalmente ocurre con poca frecuencia.
El cifrado es una de las principales limitaciones de la monitorización no intrusiva, pero como se ha mostrado anteriormente, es posible gestionarlo. Es imprescindible respetar la secuencia correcta de inicio de los procesos.
El problema de los flujos multiplexados
El protocolo SRT admite flujos multiplexados. Varios sockets SRT pueden compartir el mismo socket UDP, de modo que los paquetes recibidos en dicho socket UDP se distribuyan correctamente a los sockets SRT a los que están destinados en cada momento. Durante el handshake, las partes intercambian sus identificadores de socket SRT (SRT Socket ID). Estos identificadores se utilizan posteriormente en el campo Destination SRT Socket ID de cada paquete de control y de datos.
Por ejemplo, una sesión transporta un múltiplex de dos flujos. La sonda capturará paquetes con cuatro identificadores: dos para datos y dos para control. Sin capturar los paquetes de control de handshake, es imposible determinar qué identificadores corresponden a cada flujo. Este problema también afecta a las mediciones de RTT y ancho de banda estimado (Estimated Bandwidth), ya que la sonda rastrea paquetes de medición que también contienen Socket IDs.
Al igual que con los flujos cifrados, la monitorización de flujos multiplexados requiere que la tarea de monitorización se inicie antes de que se establezca la sesión SRT.
Tamaño del búfer
El tamaño del búfer es un parámetro crítico al analizar SRT mediante captura de paquetes (sniffing). El tamaño del búfer de la sonda debe coincidir con el tamaño del búfer negociado entre la fuente y el receptor. Solo en este caso el comportamiento de recuperación de paquetes en la tarea de monitorización será idéntico al del receptor.
Durante la negociación entre pares, se acuerda el tamaño de búfer más grande y se transmite en los paquetes de control de handshake. La sonda utiliza este tamaño de búfer negociado. Sin embargo, si la sonda no logra capturar los paquetes de control de handshake, el usuario deberá introducir manualmente el tamaño del búfer en el formulario de creación de la tarea antes de iniciarla.
Parámetros de monitorización
A continuación se muestra la lista de métricas específicas de SRT recopiladas mediante monitorización no intrusiva.
Calculadas por el analizador:
- Tiempo máximo entre llegadas de paquetes (IAT) para paquetes de datos
- Pérdida de paquetes SRT (SRT Packet Loss)
- Descarte de paquetes SRT (SRT Packet Drop; medido en el lado de la tarea de monitorización, puede diferir de las estadísticas del receptor)
- Paquetes SRT recibidos (SRT Packet Receive)
- Paquetes SRT retransmitidos (SRT Packet Retransmit)
- Tasa de retransmisión SRT (SRT Retransmit Rate)
- Tasa de bits SRT (SRT Bitrate)
- Búfer de recepción SRT (SRT RcvBuf)
- Latencia SRT (SRT Latency)
Extraídas de los paquetes ACK capturados:
- Ancho de banda SRT (SRT Bandwidth)
- Tiempo de ida y vuelta suavizado SRT (SRT Smoothed Round-Trip Time, SRTT)
Extraídas de los paquetes NAK capturados (además de los cálculos realizados por la sonda):
- Pérdida de paquetes SRT (SRT Packet Loss)
Base de código
La monitorización no intrusiva ofrece ventajas significativas frente a otros métodos de monitorización, pero también requiere un esfuerzo de desarrollo considerable.
No fue posible tomar la biblioteca libsrt existente y modificarla, ya que está basada en un estándar que asume un intercambio secuencial de datos tanto durante el handshake como durante la transmisión de datos de la fuente al receptor. El funcionamiento basado en sockets está integrado arquitectónicamente en la biblioteca.
Por el contrario, la sonda en modo sniffer no envía ningún dato. No interfiere en el intercambio de paquetes y se limita a filtrar el tráfico para extraer los datos pertenecientes a una sesión específica. A continuación, la sonda analiza los paquetes descomponiéndolos en comandos y datos conforme al estándar SRT, y reconstruye el flujo recibido de la misma manera que lo haría un receptor.
Como resultado, la biblioteca de recepción fue desarrollada casi en su totalidad por el equipo de Elecard, reutilizando únicamente un pequeño conjunto de funciones auxiliares de libsrt (aproximadamente entre el 7 % y el 10 % de la base de código).
No nos desviamos del estándar SRT, ni lo ampliamos ni lo modificamos, ya que la sonda no envía ni un solo paquete a la sesión monitorizada y utiliza una biblioteca libsrt sin modificar.
Rendimiento
En el momento de redactar este artículo, aún no se han llevado a cabo pruebas de rendimiento a gran escala. No obstante, el subsistema de captura de paquetes lleva en producción el tiempo suficiente como para haber revelado varios retos relacionados con el rendimiento.
El proceso PCAP se ejecuta en un único núcleo de CPU y puede gestionar hasta aproximadamente 2 Gbit/s de tráfico entrante. En la última versión de la sonda, se ha incorporado un algoritmo inteligente capaz de crear múltiples procesos para que la captura no se convierta en un cuello de botella.
El proceso PCAP se encarga únicamente de seleccionar los paquetes pertenecientes a una sesión específica; los datos se transfieren después a otros procesos.
En esta fase, el análisis basado en captura de paquetes (sniffing) puede considerarse comparable en rendimiento al análisis SRT clásico.
Los componentes que más recursos consumen son siempre la decodificación de vídeo y el análisis avanzado de QoE, que son órdenes de magnitud más costosos computacionalmente que la recepción de datos. La decodificación de vídeo es idéntica en todos los enfoques de monitorización.
Conclusiones
La monitorización no intrusiva del protocolo SRT es una solución altamente eficaz que responde a una necesidad largamente demandada por la industria. A pesar de ciertas limitaciones y de una mayor complejidad de configuración en comparación con el método estándar, sus ventajas superan a los inconvenientes. Como ha demostrado la investigación, este enfoque permite recopilar todas las métricas de la señal disponibles en la monitorización SRT clásica.
Cabe destacar un factor adicional importante: el coste de la monitorización no intrusiva es prácticamente idéntico al del enfoque convencional, ya que no requiere un mayor rendimiento del hardware de la sonda. Dado que los equipos de conmutación necesarios casi siempre están ya presentes en los entornos de producción, no suponen un coste adicional en el despliegue.
 | Autor: Anton Proshutya — product manager de Elecard Boro. Trabaja en el ámbito del control de calidad de vídeo desde 2007. |
Elecard Boro — solución de software para el control de calidad y la medición de parámetros de QoS y QoE en flujos UDP, RTP, HTTP, HLS, DASH, SRT y RTMP en todos los segmentos de redes distribuidas. Monitorización de flujos en directo.