# Come funziona il trasferimento file con WebRTC

Source: https://help.strongfolder.com/it/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> Il trasferimento file con WebRTC avviene in tre fasi. Un server di signaling presenta due browser; STUN e ICE trovano un percorso di rete attraverso i router di casa (NAT), ripiegando su un relay TURN se non esiste un percorso diretto; poi i browser aprono un canale dati cifrato con DTLS e trasmettono il file a pezzi, direttamente o tramite il relay, senza conservarlo.

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.

**Key facts**

- **WebRTC** è uno standard del browser per connessioni dirette e cifrate tra due dispositivi; gli strumenti per i file usano i suoi **canali dati**.
- Il **signaling** presenta i browser; **STUN** e **ICE** trovano un percorso attraverso i router (**NAT**); un **relay TURN** inoltra il traffico quando non esiste un percorso diretto.
- **Crittografia:** ogni canale dati usa **DTLS** — WebRTC non ha una modalità non cifrata.
- StrongFolder usa PeerJS sopra WebRTC, un server di signaling di StrongFolder, server STUN pubblici (compresi quelli di Google) e i propri relay TURN. I file non vengono mai caricati né conservati su un server di StrongFolder.
- Il file passa a pezzi dal disco del mittente a quello del destinatario; il mittente resta online.

## Che cos'è WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/).

## 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](https://help.strongfolder.com/en/glossary/#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:

1. Non sanno **come raggiungersi** — nessuno dei due sa che l'altro esiste.
2. Non conoscono **il proprio indirizzo pubblico** — solo quello privato, come 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

## 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.

[Invia file ora](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/)
e [Sicurezza e privacy](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) e
[Come funziona StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Che cos'è un canale dati WebRTC?

Un canale dati è la parte di WebRTC che trasporta byte di qualsiasi tipo tra due browser invece di audio o video. Funziona con SCTP su DTLS su UDP, quindi è cifrato e può essere configurato come affidabile e ordinato — proprio ciò che serve per trasferire file.

### Qual è la differenza tra STUN e TURN?

Un server STUN si limita a dire a un browser com'è il suo indirizzo pubblico, così i due browser possono provare a collegarsi direttamente; nessun dato dei file passa da lì. Un server TURN è un relay: quando nessun percorso diretto funziona, il flusso cifrato passa attraverso di esso. StrongFolder gestisce i propri relay TURN, che inoltrano i dati e non li conservano.

### Il server di signaling vede i miei file?

No. Il server di signaling trasmette tra i browser solo messaggi di connessione — descrizioni della sessione e candidati di rete. I dati dei file passano sul canale dati, direttamente o tramite un relay TURN.

### Il trasferimento file con WebRTC è cifrato?

WebRTC cifra ogni canale dati con DTLS, quindi il flusso dei file è cifrato in transito su ogni connessione. WebRTC non consente canali dati non cifrati. Le chiavi vengono negoziate dai due browser; le loro impronte passano attraverso il signaling, ed è per questo che si tratta di crittografia in transito e non di crittografia end-to-end con chiavi gestite da te.

### Perché un trasferimento WebRTC a volte fallisce o resta lento?

Di solito per via del percorso di rete: un firewall rigido o una VPN bloccano l'UDP diretto, quindi la connessione ripiega su un relay TURN via TCP, oppure non riesce proprio a collegarsi. Prova un'altra rete (per esempio l'hotspot del telefono), disattiva la VPN o chiedi all'IT di consentire WebRTC.

### Un relay TURN può leggere i miei file?

Il relay inoltra pacchetti cifrati con DTLS tra i due browser. Vede traffico cifrato, dimensioni e tempi, non il contenuto dei file, e il relay di StrongFolder non conserva ciò che inoltra.