Panoramica tecnica di Microsoft eCDN

Introduzione

Microsoft eCDN gestisce una rete CDN peer-to-peer (P2P) basata su WebRTC che fornisce flussi video HLS e MPEG-DASH. Non è necessario alcun plug-in o hardware aggiuntivo per il funzionamento della soluzione. È sufficiente un Web browser conforme a HTML5 o un'applicazione Desktop di Teams.

Microsoft eCDN risolve il problema di congestione della rete che si verifica durante eventi di streaming di grandi dimensioni, ad esempio riunioni a mani in mano. Se ogni dipendente tenta di watch contemporaneamente lo stesso flusso, il collegamento isp dell'ufficio diventa saturo. Tuttavia, quando microsoft eCDN viene distribuito, viene creata una rete mesh P2P efficiente durante questi eventi di streaming di grandi dimensioni, che riduce significativamente il carico sul collegamento ISP.

Essere un servizio basato su standard al 100% e solo SaaS significa anche:

1. Il tempo necessario per testare e distribuire Microsoft eCDN è di pochi giorni.

2. Microsoft eCDN è intrinsecamente sicuro, in quanto segue tutti gli standard di sicurezza di Microsoft O365 ed è costituito da codice JavaScript, che viene eseguito nell'ambiente sandbox limitato dei Web browser standard o del client della piattaforma di streaming.

Panoramica del sistema

Microsoft eCDN opera come un servizio che orchestra i peer fornendo al tempo stesso analisi e controllo. Il sistema è progettato per essere compatibile con gli standard e le tecnologie del settore esistenti. Ciò significa che è progettato per funzionare con:

• Protocolli di streaming basati su HTTP, ad esempio HLS e MPEG-DASH.

• Lettori video basati su HTML5 (JWPlayer, Video.js, Clappr, Kaltura e così via) e qualsiasi lettore Android o iOS nativo (ExoPlayer, AVPlayer e così via)

• Reti CDN basate su HTTP: Akamai, Fastly, CloudFront, Cloudflare, rete CDN di Azure e così via.

• Server di streaming: wowza, nimble, modulo Nginx rtmp e così via.

• Tecnologie DRM: Widevine, PlayReady, FairPlay e così via.

• Per essere completamente compatibile con, ma ancora in grado di aumentare le tecnologie e l'infrastruttura esistenti, il modello di distribuzione dei contenuti utilizzato da Microsoft eCDN è ibrido. Ovvero, ogni visualizzatore può scaricare contemporaneamente le risorse dalla rete P2P e dalla rete HTTP.

A livello generale, il sistema eCDN è composto da:

• Servizio di individuazione peering: responsabile dell'individuazione peer.

• Switchboard: responsabile della creazione delle connessioni P2P iniziali tra i visualizzatori.

• Pipeline di dati: utilizza tutti i dati di telemetria del servizio e lo archivia in un data warehouse per l'utilizzo dell'analisi.

• Plug-in lettore: responsabile dell'intercettazione e dell'inoltro delle richieste relative ai video all'SDK client.

• Client SDK: responsabile della richiesta intelligente di risorse video da HTTP/P2P e dell'unione dei buffer di dati in tempo reale.

  • Client SDK si connette al back-end (servizio di individuazione peering, switchboard, pipeline di dati).

  • Il servizio di individuazione invia all'SDK client un set di peer a suo avviso vantaggiosi per questo particolare visualizzatore. I peer vengono selezionati in base alla prossimità di rete, all'allocazione della cache, alla rilevanza del flusso, tra gli altri parametri.

  • Client SDK stabilisce connessioni al canale dati WebRTC con il set specificato di peer con l'aiuto del pannello comandi.

  • Le richieste HTTP generate dal lettore video vengono intercettate dal plug-in player e inoltrate a Microsoft eCDN Client SDK, che decide, in base alle misurazioni in tempo reale, se recuperare la risorsa desiderata dalla rete P2P o da HTTP o da entrambi contemporaneamente per fornire tale risorsa al lettore nel modo più efficiente e tempestivo.

  • Le richieste manifesto, la licenza DRM e la crittografia vengono sempre recuperate dal server perimetrale HTTP per ottenere la copia più recente e rispettare i meccanismi di autorizzazione.

  • In modo indipendente, Client SDK richiede l'autorizzazione per creare connessioni peer dal back-end Microsoft eCDN. Dopo l'autorizzazione, Client SDK inizia a scaricare le risorse da HTTP e P2P.

Panoramica della logica client

L'SDK client recupera il contenuto contemporaneamente da origini HTTP e P2P. Ciò significa che l'esperienza utente non sarà influenzata negativamente dai segmenti che non sono stati recuperati in tempo o perché la velocità di connessione dell'origine P2P non è sufficiente.

Sicurezza

Microsoft eCDN è conforme agli standard di sicurezza di Microsoft O365.

Il servizio è sicuro come qualsiasi servizio cdn tradizionale basato su server. Poiché si tratta di una soluzione ibrida, che usa eCDN in combinazione con un server HTTP tradizionale, viene sfruttata l'infrastruttura di sicurezza esistente (token, chiavi, cookie e così via) già installata da un cliente.

In termini di comunicazione, i peer sono connessi tra loro tramite il canale dati WebRTC, ovvero una pipe sicura che usa il protocollo SCTP tramite la crittografia DTLS. Inoltre, ogni visualizzatore è connesso al back-end tramite una connessione WebSocket sicura che usa la crittografia TLS. Pertanto, né i dati inviati tra i visualizzatori né i metadati inviati tra ogni visualizzatore e il back-end possono essere compromessi.

In termini di sicurezza del flusso, esistono diversi scenari:

Autenticazione all'avvio della sessione

In questo caso, ogni sessione inizia con il server che richiede al visualizzatore un ID utente e una password. Se queste credenziali sono valide, il server invierà il file manifesto al visualizzatore e il lettore video inizierà a richiedere segmenti e manifesti aggiuntivi dal server HTTP di conseguenza. Microsoft eCDN non si inserisce nel processo di convalida e il visualizzatore deve passare attraverso gli stessi controlli di autenticazione indipendentemente dal fatto che Microsoft eCDN venga distribuito o meno. Solo i visualizzatori autorizzati per un flusso possono partecipare alla condivisione P2P per tale flusso e condividono solo mentre stanno effettivamente guardando il flusso.

Tokenizzazione con tempo url

In questo caso, l'URL del manifesto ha un token aggiuntivo, che codifica alcuni dettagli sull'agente utente del visualizzatore (indirizzo IP, ora di scadenza e così via). Un utente malintenzionato che in qualche modo ottiene un URL manifesto tramite l'accesso o in altri modi può distribuirlo ai visualizzatori non autorizzati, ma tali visualizzatori non saranno in grado di accedere al flusso poiché l'URL del manifesto è tokenizzato e il server HTTP rifiuterà qualsiasi tentativo di convalida, a causa di indirizzi IP o altri agenti utente non corrispondenti o a causa della scadenza del tempo. Con Microsoft eCDN, tutte le richieste di manifesto vengono inviate direttamente al server HTTP in modo che la convalida non possa essere compromessa.

Protezione del contenuto del segmento video

Gli utenti non autorizzati che ottengono l'accesso agli URL di flusso potrebbero comunque tentare di accedere al contenuto dei segmenti video tramite altri peer. Nel caso in cui i segmenti non siano crittografati, esiste il rischio seguente: l'utente non autorizzato può ricevere l'URL di un segmento da un altro utente, trovare altri peer con questa risorsa pertinente e tentare di richiedere questa risorsa direttamente a questi utenti (anche se il server multimediale/rete CDN non consentirebbe l'accesso a questa risorsa).

Quando la tokenizzazione del contenuto è abilitata, si verifica che l'utente venga autenticato a livello di risorsa prima che altri peer possano inviare dati a tale utente. Si tratta di un meccanismo granulare che può concedere l'accesso a determinate risorse e rifiutare l'accesso ad altre risorse nella stessa sessione.

Altre misure di protezione includono la crittografia:

Crittografia

Si prenda, ad esempio, un flusso HLS protetto con la crittografia AES-128. Gli utenti malintenzionati possono inviare l'URL del manifesto a visualizzatori non autorizzati o anche ai segmenti video stessi, ma finché i visualizzatori non autorizzati non hanno accesso alla chiave di decrittografia, non saranno in grado di watch il flusso. La chiave può essere inviata all'utente finale in diversi modi, ad esempio tramite il manifesto principale o tramite la pagina HTML o un altro percorso. Indipendentemente da ciò, il servizio non si inserisce in questo processo e la chiave viene recapitata al lettore video usando lo stesso meccanismo indipendentemente dal fatto che il servizio venga distribuito o meno, il che significa che la chiave è altrettanto sicura con o senza Microsoft eCDN.

DRM

Il caso d'uso DRM è simile al caso d'uso della crittografia. L'unica differenza è che la licenza e le chiavi vengono distribuite dal meccanismo DRM anziché dall'emittente. Anche in questo caso, Microsoft eCDN non interferisce con la distribuzione della licenza o delle chiavi e quindi non le compromette.