Introducción técnica a Microsoft eCDN
Introducción
Microsoft eCDN opera una red CDN punto a punto (P2P) basada en WebRTC que ofrece secuencias de vídeo HLS y MPEG-DASH. No se necesita ningún complemento o hardware de cliente o software adicional para que la solución funcione. Todo lo que necesita es un explorador web compatible con HTML5 o una aplicación de escritorio de Teams.
Microsoft eCDN resuelve el problema de congestión de red que se produce durante eventos de streaming de gran tamaño, como reuniones de todas las manos. Si cada empleado intenta watch la misma secuencia al mismo tiempo, el vínculo isp de la oficina se satura. Sin embargo, cuando se implementa Microsoft eCDN, se forma una red de malla P2P eficaz durante estos grandes eventos de streaming, lo que reduce significativamente la carga en el vínculo ISP.
Ser un servicio 100 % basado en estándares y solo SaaS también significa:
El tiempo que se tarda en probar e implementar Microsoft eCDN es solo unos días.
Microsoft eCDN es intrínsecamente seguro, ya que sigue todos los estándares de seguridad de Microsoft O365 y consta de código JavaScript, que se ejecuta en el entorno limitado y de espacio aislado de los exploradores web estándar o el cliente de la plataforma de streaming.
Información general del sistema
Microsoft eCDN funciona como un servicio que organiza a los compañeros al tiempo que proporciona análisis y control. El sistema está diseñado para ser compatible con los estándares y tecnologías existentes del sector. Esto significa que está diseñado para trabajar con:
Protocolos de streaming basados en HTTP, como HLS y MPEG-DASH.
Reproductores de vídeo basados en HTML5 (JWPlayer, Video.js, Clappr, Kaltura, etc.) y cualquier reproductor nativo de Android o iOS (ExoPlayer, AVPlayer, etc.)
CDN basadas en HTTP: Akamai, Fastly, CloudFront, Cloudflare, Azure CDN, etc.
Servidores de streaming: Wowza, Nimble, módulo Nginx rtmp, etc.
Tecnologías DRM: Widevine, PlayReady, FairPlay, etc.
Con el fin de ser completamente compatible con, pero aún así poder aumentar las tecnologías y la infraestructura existentes, el modelo de entrega de contenido que Microsoft eCDN emplea es híbrido. Es decir, cada visor puede descargar recursos de la red P2P y de la red HTTP simultáneamente.
En un nivel alto, el sistema eCDN se compone de:
Servicio de detección de emparejamiento: responsable de la detección del mismo nivel.
Panel de conmutación: responsable de crear las conexiones P2P iniciales entre los visores.
Canalización de datos: consume toda la telemetría del servicio y la almacena en un almacenamiento de datos para el consumo de análisis.
Complemento player: responsable de interceptar y reenviar solicitudes relacionadas con vídeo al SDK de cliente.
SDK de cliente: responsable de solicitar de forma inteligente recursos de vídeo de HTTP/P2P y de unir los búferes de datos en tiempo real.
El SDK de cliente se conecta con el back-end (servicio de detección de emparejamiento, panel de conmutación, canalización de datos).
El servicio de detección envía al SDK de cliente un conjunto de elementos del mismo nivel que cree que beneficiarán a este visor en particular. Los elementos del mismo nivel se seleccionan en función de la proximidad de red, la asignación de caché, la relevancia de la secuencia, entre otros parámetros.
El SDK de cliente establece conexiones de canal de datos WebRTC con el conjunto especificado de elementos del mismo nivel con la ayuda de switchboard.
Las solicitudes HTTP generadas por el reproductor de vídeo son interceptadas por el complemento player y reenviadas al SDK de cliente de Microsoft eCDN, que decide, en función de las medidas en tiempo real, si se captura el recurso deseado desde la red P2P o desde HTTP o de ambos de forma simultánea para proporcionar ese recurso al reproductor de la manera más eficaz y oportuna.
Las solicitudes de manifiesto, la licencia DRM y el cifrado siempre se recuperan del servidor perimetral HTTP para obtener la copia más actual y cumplir los mecanismos de autorización.
De forma independiente, el SDK de cliente solicita autorización para crear conexiones del mismo nivel desde el back-end de Microsoft eCDN. Una vez autorizado, el SDK de cliente comienza a descargar recursos de HTTP y P2P.
Introducción a la lógica de cliente
El SDK de cliente captura el contenido simultáneamente de orígenes HTTP y P2P. Esto significa que la experiencia del usuario no se verá afectada negativamente por segmentos que no se han capturado a tiempo o porque la velocidad de conexión del origen P2P es insuficiente.
Seguridad
Microsoft eCDN es compatible con los estándares de seguridad de Microsoft O365.
El servicio es tan seguro como cualquier servicio DE CDN tradicional basado en servidor. Dado que se trata de una solución híbrida, que usa eCDN en combinación con un servidor HTTP tradicional, aprovechamos la infraestructura de seguridad existente (tokens, claves, cookies, etc.) que ya tiene un cliente.
En términos de comunicación, los elementos del mismo nivel están conectados entre sí a través del canal de datos WebRTC, que es una canalización segura que usa el protocolo SCTP a través del cifrado DTLS. Además, cada visor está conectado al back-end a través de una conexión websocket segura que usa el cifrado TLS. Por lo tanto, no se pueden poner en peligro los datos enviados entre los visores ni los metadatos enviados entre cada visor y el back-end.
En términos de seguridad de secuencias, hay varios escenarios:
Autenticación al iniciar la sesión
En este caso, cada sesión comienza con el servidor solicitando al visor un identificador de usuario y una contraseña. Si estas credenciales son válidas, el servidor enviará el archivo de manifiesto al visor y el reproductor de vídeo comenzará a solicitar segmentos y manifiestos adicionales desde el servidor HTTP en consecuencia. Microsoft eCDN no se inserta en el proceso de validación y el visor debe pasar por las mismas puertas de autenticación independientemente de si microsoft eCDN está implementado o no. Solo los espectadores autorizados para una secuencia pueden participar en el uso compartido de P2P para esa secuencia y solo lo comparten mientras realmente están viendo la secuencia.
Tokenización con tiempo de dirección URL
En este caso, la dirección URL del manifiesto tiene un token adicional, que codifica algunos detalles sobre el agente de usuario del visor (dirección IP, tiempo de expiración, etc.). Un usuario malintencionado que de alguna manera obtiene una dirección URL de manifiesto mediante el inicio de sesión o de otras maneras puede distribuirla a visores no autorizados, pero esos visores no podrán acceder a la secuencia ya que la dirección URL del manifiesto está tokenizada y el servidor HTTP rechazará los intentos de validación, ya sea debido a errores de coincidencia de dirección IP u otro agente de usuario o debido a la expiración del tiempo. Con Microsoft eCDN, todas las solicitudes de manifiesto se envían directamente al servidor HTTP, por lo que la validación no se puede poner en peligro.
Protección de contenido de segmentos de vídeo
Los usuarios no autorizados que obtienen acceso a las direcciones URL de flujo pueden seguir intentando acceder al contenido de los segmentos de vídeo a través de otros elementos del mismo nivel. En el caso de que los segmentos no estén cifrados, existe el siguiente riesgo: el usuario no autorizado puede recibir la dirección URL de un segmento de un usuario diferente, buscar otros elementos del mismo nivel que tengan este recurso pertinente e intentar solicitar este recurso directamente a estos usuarios (aunque el servidor multimedia o cdn no permita el acceso a este recurso).
Cuando se habilita la tokenización de contenido, nos aseguramos de que el usuario se autentica en el nivel de recurso antes de que otros elementos del mismo nivel puedan enviar datos a ese usuario. Se trata de un mecanismo granular que puede conceder acceso a determinados recursos y rechazar el acceso a otros recursos en la misma sesión.
Otras medidas de protección incluyen el cifrado:
Cifrado
Vamos a tomar, por ejemplo, un flujo HLS que está protegido con el cifrado AES-128. Los usuarios malintencionados pueden enviar la dirección URL del manifiesto a visores no autorizados o incluso a los propios segmentos de vídeo, pero mientras los visores no autorizados no tengan acceso a la clave de descifrado, no podrán watch la secuencia. La clave se puede enviar al usuario final de varias maneras, por ejemplo, a través del manifiesto principal, o a través de la página HTML o alguna otra ruta de acceso. Independientemente, el servicio no se inserta en este proceso y la clave se entrega al reproductor de vídeo con el mismo mecanismo independientemente de si el servicio se implementa o no, lo que significa que la clave es igual de segura con o sin Microsoft eCDN.
DRM
El caso de uso de DRM es similar al caso de uso del cifrado. La única diferencia es que la licencia y las claves se distribuyen por el mecanismo DRM en lugar de por el emisor. También aquí, Microsoft eCDN no interfiere con la distribución de la licencia o las claves y, por lo tanto, no las pone en peligro.