Sesiones de visualización¶
media.play.sessions
Una sesión de visualización es el estado que Sapsan mantiene para el acceso de un espectador a un stream. Vincula las solicitudes del reproductor con la autorización y registra la actividad, los bytes entregados y el uso del archivo. Esto permite observar la visualización en su conjunto, aunque la entrega consista en muchas solicitudes HTTP independientes.
Por ejemplo, un reproductor HLS solicita una lista maestra, las calidades y una secuencia de segmentos. La adaptación de calidad y las nuevas conexiones HTTP no deberían convertir por sí solas una visualización en cientos de espectadores. Sapsan encuentra la sesión existente y asocia con ella las solicitudes posteriores.
Cómo se agrupan las solicitudes HTTP¶
Para la reproducción HTTP habitual, la identidad se compone de los siguientes datos:
- Nombre del stream — el recurso multimedia solicitado.
- Tipo de acceso — la reproducción se distingue de la publicación.
- Dirección IP del cliente — teniendo en cuenta los proxies de confianza configurados.
- Token de acceso — para un ticket JWT validado, se utiliza el identificador de su concesión
jti.
Sapsan utiliza estos datos para buscar la sesión en cada solicitud. Si ya existe una sesión correspondiente, la solicitud actualiza su actividad. Si no, se crea una nueva y se comprueba el acceso. Una solicitud de fragmento también puede iniciar una sesión: obtener la lista maestra no es un primer paso obligatorio.
El servidor asigna el identificador de sesión. Un cliente HTTP habitual no necesita generar su propio UUID de sesión ni conservar una cookie especial. User-Agent se registra en las estadísticas, pero no forma parte de la clave de agrupación indicada.
El token debe llegar a las solicitudes relacionadas. En la reproducción HTTP, el parámetro ?token= tiene prioridad sobre Authorization: Bearer …. La emisión y entrega de JWT se describen en tokens de acceso.
Este registro depende de la identidad elegida, no del dispositivo físico. Varios reproductores con la misma IP, el mismo token y el mismo stream pueden compartir una sesión. Cambiar la IP o el identificador del token puede crear una nueva. Para contabilizarlos por separado, emita tickets distintos y configure correctamente los proxies de confianza.
Ciclo de vida y estadísticas¶
Las solicitudes y los datos entregados mantienen la actividad de la sesión. Si no hay actividad durante 60 segundos, la sesión caduca; la limpieza se realiza periódicamente, por lo que el cierre no tiene por qué coincidir con el de la pestaña del navegador.
Un registro de sesión abierto y un espectador activo son indicadores distintos. La implementación actual activa la sesión después de entregar 10 KiB de datos. Por tanto, una sola solicitud de una lista pequeña no aumenta necesariamente el número de espectadores activos. El umbral mide bytes entregados y no demuestra que una persona haya visto la imagen. El registro de sesiones cerradas solo incluye las que llegaron a estar activas.
Se registra la siguiente información:
- Tiempo — apertura, última actividad, duración y cierre.
- Entrega — protocolo y número de bytes entregados.
- Cliente — IP,
User-Agente identificador de usuario, si lo proporciona la autorización. - Archivo — un indicador de acceso a DVR. Después de retroceder al archivo, permanece activado incluso al volver al directo.
La transición directo → archivo → directo no crea por sí sola tres visualizaciones. Del mismo modo, las solicitudes de segmentos y las conexiones de red no deben sumarse como si fueran espectadores.
Calidad de entrega SRT¶
Una sesión abierta por SRT lleva un corte protocolar de la entrega — contadores actuales de la conexión en la respuesta de sesiones activas:
| Campo | Significado |
|---|---|
rtt_ms, rtt_max_ms |
RTT actual y máximo durante la vida de la sesión |
send_buffer_packets |
paquetes en el búfer de envío — señal temprana de congestión en el espectador |
packets_sent |
paquetes enviados — el denominador de la proporción de pérdidas |
lost_packets |
pérdidas: huecos en la secuencia saliente de paquetes |
drop_too_late_packets |
de las pérdidas — paquetes saltados como caducados: la latencia no alcanzó a recuperarlos |
drop_requests |
de las pérdidas — paquetes descartados por orden del receptor: el espectador informó de que ya no necesita ese rango |
retransmitted_packets |
paquetes reenviados — respuestas a los informes NAK del espectador |
naks_received |
informes NAK del espectador: cuántas veces reportó pérdidas |
health |
veredicto de salud de la conexión: ok, degraded o bad |
Los valores de una sesión activa se actualizan: el nodo fija periódicamente los contadores en el registro de la sesión. Al cerrarse, el registro del nodo recibe los totales finales y el veredicto de la última ventana.
El veredicto health describe la ventana de entrega — el último minuto de la conexión, no toda su vida: la proporción de pérdidas y el RTT actual frente al doble de la latencia de entrega. Los fallos pasados quedan en el pasado: cuando la ventana se limpia, el veredicto vuelve a ok, y el cuándo se caía se lee en la historia del corte (véase la historia por minutos). Un corte de conexión no estropea el veredicto: una sesión limpia cerrada por un espectador que enmudeció conserva el veredicto de su última ventana, y la marcha misma la describe la razón de cierre.
Las sesiones de otros protocolos no llevan sección srt en absoluto — la ausencia del campo no significa pérdidas cero.
Historia por minutos de la sesión¶
Las sesiones con propietario user_id — del mapa de clientes de la entrega o de la etiqueta de propietario — se escriben en el almacén de métricas de central en puntos por minutos: el gráfico de una sesión se construye con el mismo mecanismo que los gráficos de la entrada del stream. Cada serie lleva las etiquetas name (stream), user_id y session:
| Serie | Qué muestra |
|---|---|
stream_play_srt_session_rtt_seconds, ..._rtt_max_seconds |
RTT — actual y máximo |
stream_play_srt_session_send_buffer_packets |
búfer de envío, paquetes |
stream_play_srt_session_packets_sent_total, ..._bytes_total |
paquetes y bytes enviados |
stream_play_srt_session_lost_packets_total |
pérdidas |
stream_play_srt_session_drop_too_late_packets_total, ..._drop_requests_total |
pérdidas por causa: saltados como caducados y descartados por orden del receptor |
stream_play_srt_session_retransmitted_packets_total, ..._naks_received_total |
retransmisiones e informes NAK |
Las series se leen en el servidor Prometheus integrado de central con la misma consulta de rango que las series del stream. La profundidad del detalle es la ventana del almacén, seis horas por defecto; un reinicio del plano de métricas borra la historia. Más profundo que la ventana están los totales generales del registro cerrado — bytes, duración, razón de cierre. Las sesiones anónimas no crean series: sin propietario no hay gráficos, y no ceros.
Autorización de la sesión¶
El método principal recomendado para permitir el acceso es un ticket JWT. El streamer lo valida localmente, mientras el estado de sesión vincula las solicitudes y su tráfico. Que ya exista una sesión abierta no elimina la validación del JWT en la siguiente solicitud HTTP.
Para las integraciones antiguas con un backend de autorización externo, el permiso se conserva durante un periodo definido. Dentro de esta ventana, las solicitudes posteriores reutilizan la decisión; cuando caduca, se requiere una nueva autorización. auth_duration, con un valor predeterminado de 180 segundos, corresponde a la vigencia de la decisión de autorización, no al tiempo de espera por inactividad de 60 segundos.
Comprobar las solicitudes HTTP posteriores y finalizar una respuesta continua ya abierta son operaciones distintas. La existencia de una sesión no significa que un cambio en la decisión de autorización interrumpa al instante cualquier entrega MPEG-TS en curso.
Diferencia respecto a la validación de enlaces en un edge nginx¶
La validación de un enlace firmado determina si se admite una solicitud concreta. Por ejemplo, el módulo secure_link de nginx comprueba la autenticidad del enlace y su caducidad. El registro de la visualización requiere un estado que relacione las solicitudes individuales del reproductor.
| Tarea | Solo validación del enlace | Registro de sesiones de Sapsan |
|---|---|---|
| Permitir una solicitud de segmento | Valida el enlace presentado | Comprueba el acceso y vincula la solicitud con una visualización. |
| Contabilizar una visualización | Las solicitudes individuales no definen por sí solas sus límites | Registra la actividad y el ciclo de vida de la sesión. |
| Contabilizar el tráfico | Hay datos de cada solicitud | Los bytes se acumulan en la sesión. |
| Analizar el rebobinado y el protocolo | Requiere agregación adicional | Esta información forma parte del registro de sesión. |
| Recopilar datos de varios edges | Requiere un mecanismo común de registro | Central recopila datos de los streamers y proporciona un historial del clúster. |
Nginx puede integrarse con estado y analítica externos. La comparación se refiere a una configuración en la que el edge solo valida enlaces: esa comprobación por sí sola no equivale al registro de sesiones de visualización.
Sesión del clúster y cambio entre edges¶
Con balanceo de carga, un espectador puede iniciar la reproducción en el edge A y continuar en el edge B. Para analizar esa visualización, central recopila datos de los servidores, guarda las sesiones cerradas en un registro común y genera un historial con una etapa de combinación de registros.
En el historial del clúster, los registros con una misma identidad reconocida se combinan si sus intervalos se solapan o están separados por no más de 30 minutos. Los bytes entregados se suman, el intervalo temporal abarca la unión y nodes enumera los servidores participantes. Esto proporciona un modelo de visualización lógica sobre los registros individuales de los servidores.
La implementación actual tiene una limitación: la lectura del historial se basa en la práctica en valores completos de id coincidentes. Al abrir la reproducción en otro edge, este ID puede cambiar porque incluye la hora de apertura. Por tanto, todavía no se garantiza la combinación de todos los cambios entre edges. El identificador del ticket JWT por sí solo no elimina esta limitación de la salida actual del historial.
La lista actual de sesiones activas y el historial combinado de sesiones cerradas son vistas distintas. El número de filas de la lista activa no permite deducir automáticamente el número de personas únicas durante un periodo ni el resultado de la combinación histórica.
Consulta mediante la API¶
Sesiones actuales del stream en central:
curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
'http://central:8080/central/api-v4/play-sessions/active?stream=cam1&limit=100'
Historial con combinación de registros:
curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
'http://central:8080/central/api-v4/play-sessions/closed?stream=cam1&limit=100'
La respuesta contiene un array sessions. Los campos id, bytes, duration y dvr describen la visualización; node y nodes, la participación de los streamers. uncovered_nodes indica los servidores cuya recopilación de datos está incompleta. Un servidor sin cobertura no debe considerarse un servidor con cero espectadores.
Para el diagnóstico local, el streamer ofrece las rutas correspondientes /streamer/api-v4/play-sessions/active y /streamer/api-v4/play-sessions/closed. La recopilación del historial en central es asíncrona: cerrar una sesión localmente no significa que aparezca de inmediato en el registro común.