Il trasferimento file con WebRTC permette a due browser di inviarsi un file senza caricarlo su un cloud. Sembra semplice, ma internet non è nato perché due computer di casa si chiamassero direttamente. Questa guida spiega cosa succede davvero — signaling, NAT, STUN, ICE, TURN, DTLS e canali dati — in modo semplice, usando StrongFolder come esempio.
Che cos'è WebRTC?
WebRTC (Web Real-Time Communication) è un insieme di API del browser e di protocolli di rete, standardizzati dal W3C e dall'IETF, per connessioni in tempo reale tra browser. Chrome, Edge, Firefox, Safari e Opera lo supportano tutti. È nato per le chiamate video e vocali, ma ha anche dei canali dati che trasportano qualsiasi dato binario — che è esattamente ciò che è un file.
La proprietà chiave: una volta stabilita una connessione WebRTC, i dati passano tra i due estremi, non nell'archivio di un server. È questo che rende possibile il trasferimento file P2P nel browser.
Perché due browser non possono semplicemente collegarsi tra loro?
Perché quasi nessun dispositivo ha un proprio indirizzo pubblico. Il tuo portatile sta dietro a un router di casa, a un firewall aziendale o alla rete di un operatore mobile. Il router esegue il NAT (Network Address Translation): molti dispositivi privati condividono un solo indirizzo IP pubblico e il router lascia entrare solo il traffico che risponde a qualcosa inviato dall'interno.
Quindi due browser devono risolvere tre problemi prima che possa passare un solo dato:
- Non sanno come raggiungersi — nessuno dei due sa che l'altro esiste.
- Non conoscono il proprio indirizzo pubblico — solo quello privato, come 192.168.1.20.
- I loro router possono bloccare il traffico in entrata non richiesto.
WebRTC risolve ciascun problema con un meccanismo distinto.
Come funziona un trasferimento file WebRTC, passo passo?
Ecco il flusso completo, dal clic su "condividi" all'ultimo byte:
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Passaggi 1–2 — Signaling. Il mittente sceglie i file; il servizio registra i metadati necessari per il link. Quando il destinatario apre il link, entrambi i browser sono collegati a un server di signaling. WebRTC non definisce come funziona il signaling; StrongFolder usa PeerJS con un proprio server di signaling.
Passaggio 3 — Offerta e risposta. Un browser crea un'offerta in SDP (Session Description Protocol): "Voglio un canale dati, ecco la mia impronta di crittografia e le mie capacità". L'altro replica con una risposta. Entrambe passano dal server di signaling.
Passaggio 4 — STUN. Ogni browser chiede a un server STUN: "da quale indirizzo e porta mi vedi arrivare?". La risposta è il suo indirizzo pubblico così come lo mappa il router. I server STUN gestiscono una richiesta minuscola e nessun dato dei file; StrongFolder usa server STUN pubblici, compresi quelli di Google, e i propri.
Passaggio 5 — Candidati ICE. Ogni browser raccoglie dei candidati — i possibili modi per raggiungerlo: il suo indirizzo sulla rete locale (host), il suo indirizzo pubblico ottenuto da STUN (server-reflexive) e un indirizzo su un relay TURN (relayed). Si scambiano i candidati tramite il signaling.
Passaggio 6 — Verifiche di connettività. ICE (Interactive Connectivity Establishment) prova le coppie di candidati e sceglie la migliore che funziona. Se entrambi i dispositivi sono sulla stessa rete Wi-Fi, vince un percorso locale. Se i router lo consentono, vince un percorso diretto via internet ("hole punching"). Se nulla di diretto funziona, si usa il percorso tramite relay.
Passaggio 7 — DTLS. Prima che passi qualsiasi dato, i browser eseguono un handshake DTLS (TLS adattato a UDP) e verificano che le impronte dei certificati corrispondano a quelle dell'offerta e della risposta. Da qui in poi tutto è cifrato.
Passaggio 8 — Canale dati. Sopra DTLS funziona SCTP, che garantisce al canale dati una consegna affidabile e ordinata. In StrongFolder il browser del destinatario richiede un file, il browser del mittente lo legge dal disco a pezzi e li invia, e il destinatario scrive ogni pezzo sul disco appena arriva — così anche i file molto grandi non devono mai stare tutti in memoria.
Cosa significano STUN, TURN, ICE e gli altri termini?
| Termine | Cosa fa | Vede i dati dei file? | Standard |
|---|---|---|---|
| Signaling | Trasmette offerte, risposte e candidati tra i browser | No | Non standardizzato (dipende dall'app) |
| NAT | Funzione del router che condivide un IP pubblico tra molti dispositivi | — | — |
| STUN | Comunica a un browser il suo indirizzo e la sua porta pubblici | No | IETF RFC 8489 |
| ICE | Raccoglie i candidati e sceglie un percorso funzionante | No | IETF RFC 8445 |
| TURN | Inoltra il traffico quando nessun percorso diretto funziona | Solo pacchetti cifrati | IETF RFC 8656 |
| DTLS | Cifra la connessione (TLS per UDP) | Li cifra | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Canale dati SCTP | Consegna affidabile e ordinata dei pezzi | Li trasporta (cifrati) | IETF RFC 8831 |
Tutti questi termini sono spiegati brevemente nel glossario.
Quando si usa un relay TURN e cosa vede?
Il relay è il piano di riserva, non la norma. ICE lo usa solo quando nessuna coppia di candidati diretti si collega — tipicamente su reti con NAT simmetrico (alcuni operatori mobili), firewall aziendali che bloccano l'UDP in uscita o alcune VPN.
Se una connessione diretta non è possibile (firewall aziendale rigido, alcune reti mobili), il flusso cifrato passa attraverso un server relay (TURN) di StrongFolder. Il relay inoltra i dati e non li conserva.
Il relay riceve pacchetti cifrati con DTLS e li passa oltre. Può vedere che c'è traffico, quanto e quando — non cosa contiene. Un trasferimento tramite relay può essere più lento di uno diretto, perché ogni byte fa un viaggio in più attraverso il relay. Se un trasferimento è insolitamente lento, prova un'altra rete: l'hotspot del telefono o il Wi-Fi di casa spesso si collegano direttamente dove una rete aziendale non ci riesce.
Gratis · nel browser · senza registrazione
Quanto è sicura la crittografia di WebRTC?
WebRTC rende la crittografia obbligatoria: non c'è modo di aprire un canale dati non cifrato. DTLS usa cifrari moderni negoziati dai due browser e per ogni connessione vengono create nuove chiavi.
C'è un'avvertenza onesta che vale per ogni servizio WebRTC. I due browser si verificano a vicenda tramite impronte dei certificati che vengono scambiate attraverso il server di signaling. Ti fidi quindi del fatto che il signaling del servizio non le manometta. Per questo StrongFolder descrive la propria protezione come crittografia in transito — non come crittografia end-to-end con chiavi in tuo possesso, e non come "zero-knowledge". Per una visione più ampia di cosa significa "sicuro", leggi Condivisione sicura dei file e Sicurezza e privacy.
Perché il browser del mittente deve restare aperto?
Perché il browser del mittente è la sorgente. Non c'è una copia sul server su cui ripiegare: il canale dati legge i pezzi dal disco del mittente solo finché la scheda è aperta e il dispositivo è attivo. La scheda del browser del mittente deve restare aperta e online finché il destinatario non ha finito di scaricare — i file arrivano dal dispositivo del mittente, non da un server. Come organizzarsi è spiegato in Perché il mittente resta online.
Quanto è veloce il trasferimento file con WebRTC?
Non c'è una velocità fissa. Il tetto è il collegamento più lento del percorso: di solito la velocità di upload del mittente. A grandi linee, 1 GB richiede circa 2,7 minuti a 50 Mbit/s, circa 80 secondi a 100 Mbit/s e ben meno di un minuto su una rete locale veloce. I trasferimenti reali sono un po' sotto questi valori per via del sovraccarico dei protocolli, della velocità del disco e, con un relay, del passaggio in più. Lo stesso link può essere aperto da più destinatari; ognuno scarica direttamente dal mittente. Più download contemporanei si dividono l'upload del mittente.
In sintesi
Un trasferimento file WebRTC è una breve negoziazione seguita da un lungo flusso cifrato: il signaling presenta i browser, STUN e ICE trovano un percorso attraverso il NAT, TURN fa da relay come ultima risorsa e i canali dati cifrati con DTLS portano il file da disco a disco. Per il lato pratico — cosa significa per te come mittente — inizia da Trasferimento file P2P nel browser e Come funziona StrongFolder.