Architettura e flusso dei dati¶
Drovio si basa su WebRTC per offrire un'esperienza rapida e a bassa latenza, con le migliori codifiche audio e video del momento, AV1, VP9 e VP8, mantenendo al contempo un'architettura peer-to-peer altamente sicura e attenta alla riservatezza.
Panoramica¶
Drovio si compone di un software server, Drovio Server, disponibile solo nell'edizione Enterprise, e di un software client, l'applicazione Drovio. La soluzione fornisce anche un client web, che permette di partecipare a qualsiasi sessione di condivisione dello schermo o a qualsiasi chiamata senza scaricare, installare o sottoscrivere nulla.
Il percorso interattivo qui sotto segue una sessione dall'autenticazione fino ai flussi, e indica i protocolli e le porte coinvolti a ogni fase.
Flusso di connessione¶
HTTPS · TLS 1.2 / 1.3 · 443
L'autenticazione su Drovio avviene in HTTPS, TLS 1.2 o 1.3. Vengono poi aperte connessioni WebSocket tra Drovio Server e i client per trasportare l'insieme della segnalazione.
Nell'edizione Enterprise, i protocolli e le suite di cifratura attivati si impostano con http.tls_protocols e http.tls_cipher_suites.
WebSocket (WSS) · 443
La segnalazione, nel senso di WebRTC, designa lo scambio delle capacità di diffusione, i codec audio e video, e delle capacità di rete tra le estremità, cioè i client. Gli SDP e i candidati ICE circolano tra l'host e l'ospite tramite Drovio Server, su WebSocket.
Il SDP, Session Description Protocol, serve a enumerare i flussi supportati. In parallelo, i candidati ICE disponibili sono raccolti su ciascuna estremità, e ognuno indica un possibile indirizzo IP, una porta e un livello di trasporto. Vengono scambiati e formano delle coppie di candidati. Più coppie sono trattenute ma una sola è selezionata per portare la comunicazione peer-to-peer, salvo in caso di reinizializzazione ICE, che impone di rinegoziare la connessione e di selezionarne un'altra. Drovio se ne occupa in modo trasparente.
STUN · UDP 443
Durante la segnalazione, i client possono appoggiarsi a un server STUN, Session Traversal Utilities for NAT, per attraversare un NAT. La loro unica ragion d'essere è rispondere alla domanda «qual è il mio indirizzo IP pubblico?».
DTLS-SRTP / SCTP · UDP 1024-65535
Le connessioni peer-to-peer si stabiliscono poi direttamente tra i client. Un flusso video in diretta dello schermo o dell'applicazione dell'host è inviato agli ospiti, accompagnato se del caso da un flusso audio, microfono o audio di sistema. Anche gli ospiti possono condividere il proprio microfono e inviare azioni di mouse e di tastiera, che l'host può revocare in qualsiasi momento, vedere Accesso e controllo delle sessioni. Drovio Server non interviene durante la sessione di condivisione dello schermo, se non per raccogliere qualche statistica destinata a migliorare l'esperienza, vedere Statistiche.
TURN · UDP/TCP 443 · UDP 49152-65535
Quando i firewall o le regole di NAT sono troppo restrittivi, le connessioni dirette non possono stabilirsi tra i client. Dei server relay, TURN per Traversal Using Relays around NAT, servono allora a trasmettere i pacchetti da un client all'altro. La comunicazione resta cifrata end-to-end : un relay trasmette pacchetti che non può decifrare, dato che le chiavi sono negoziate tra le sole estremità.
Nell'edizione Cloud, i server STUN e TURN sono ospitati su AWS e distribuiti in tutto il mondo. Portano circa il 15% delle sessioni di condivisione dello schermo, ed è il server geograficamente più vicino all'utente a essere impiegato all'occorrenza. Nell'edizione Enterprise, questi server sono facoltativi: possiamo aiutarvi a distribuire i vostri quando la condivisione dello schermo deve passare da Internet, vedere Server relay (TURN).
Un relay non è un proxy aperto. Ottenere un'allocazione richiede credenziali a durata limitata derivate da un segreto condiviso, le allocazioni scadono dopo qualche minuto, e il relay rifiuta le destinazioni di loopback e di multicast, cosicché non può essere rivolto contro le reti interne. TLS 1.0 e 1.1 vi sono disattivati, la sua lista di suite di cifratura è ristretta alle suite ECDHE moderne, e non annuncia la sua versione software.
Riepilogo dei protocolli e delle porte¶
| Fase | Protocollo/i | Porta/e |
|---|---|---|
| Autenticazione | HTTPS (TLS 1.2 / 1.3) | TCP 443 |
| Segnalazione | HTTPS e WebSocket (WSS) | TCP 443 |
| STUN | UDP | 443 |
| Condivisione dello schermo (peer-to-peer) | DTLS-SRTP, DTLS-SCTP | UDP 1024-65535, in uscita e in ritorno |
| TURN (relay) | UDP / TCP per raggiungere il relay, poi UDP per i flussi trasmessi dal relay | 443, poi 49152-65535 |
A proposito dell'intervallo peer-to-peer. 1024-65535 non è un elenco di
porte da aprire su un server. Sono le porte media di WebRTC : a ogni
sessione, ciascuna estremità sceglie una porta effimera che le è propria e la
annuncia come candidato ICE. Ciò che un firewall deve autorizzare è l'UDP in
uscita e il suo traffico di ritorno, non una porta fissa. Là dove non è
possibile, la sessione ripiega su TURN e tutto passa dalla porta 443.
A proposito delle porte del relay. 49152-65535 è l'intervallo di
allocazione del server relay stesso, non quello dei client. Nell'edizione Cloud,
i nostri relay ascoltano solo sulla 443, in UDP come in TCP, il che
attraversa la maggior parte dei firewall aziendali. Nell'edizione Enterprise,
siete voi a scegliere le porte: la guida
Server relay (TURN) suggerisce la 80 e la
443 per la stessa ragione.