# Näin WebRTC-tiedostonsiirto toimii

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

> WebRTC-tiedostonsiirto etenee kolmessa vaiheessa. Signalointipalvelin esittelee kaksi selainta toisilleen; STUN ja ICE etsivät verkkoreitin kotireitittimien (NAT) läpi ja turvautuvat TURN-välityspalvelimeen, jos suoraa reittiä ei ole; sitten selaimet avaavat DTLS-salatun datakanavan ja suoratoistavat tiedoston paloina, suoraan tai välityspalvelimen kautta, tallentamatta sitä.

WebRTC-tiedostonsiirron avulla kaksi selainta voi lähettää toisilleen tiedoston lataamatta sitä
pilvitallennukseen. Se kuulostaa yksinkertaiselta, mutta internetiä ei rakennettu siihen, että
kaksi kotitietokonetta soittaisi toisilleen suoraan. Tämä opas käy selkokielellä läpi, mitä
todella tapahtuu – signalointi, NAT, STUN, ICE, TURN, DTLS ja datakanavat – käyttäen
esimerkkinä StrongFolderia.

**Key facts**

- **WebRTC** on selainstandardi suoriin, salattuihin yhteyksiin kahden laitteen välillä; tiedostotyökalut käyttävät sen **datakanavia**.
- **Signalointi** esittelee selaimet toisilleen; **STUN** ja **ICE** etsivät reitin reitittimien (**NAT**) läpi; **TURN-välityspalvelin** välittää liikenteen, kun suoraa reittiä ei ole.
- **Salaus:** jokainen datakanava käyttää **DTLS:ää** – WebRTC:ssä ei ole salaamatonta tilaa.
- StrongFolder käyttää PeerJS:ää WebRTC:n päällä, StrongFolderin signalointipalvelinta, julkisia STUN-palvelimia (myös Googlen) ja omia TURN-välityspalvelimiaan. Tiedostoja ei koskaan ladata StrongFolderin palvelimelle eikä tallenneta sinne.
- Tiedosto virtaa paloina lähettäjän levyltä vastaanottajan levylle; lähettäjä pysyy verkossa.

## Mikä WebRTC on?

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc) (Web Real-Time Communication) on joukko selainrajapintoja ja
verkkoprotokollia, jotka W3C ja IETF ovat standardoineet selainten välisiä reaaliaikaisia
yhteyksiä varten. Chrome, Edge, Firefox, Safari ja Opera tukevat sitä kaikki. Se tehtiin video-
ja äänipuheluita varten, mutta siinä on myös **datakanavat**, jotka kuljettavat mitä tahansa
binääridataa – ja sitä tiedosto juuri on.

Keskeinen ominaisuus: kun WebRTC-yhteys on muodostettu, data kulkee **kahden päätepisteen
välillä**, ei palvelimen tallennustilaan. Juuri tämä tekee
[P2P-tiedostonsiirron selaimessa](https://help.strongfolder.com/en/guides/p2p-file-transfer/) mahdolliseksi.

## Miksi kaksi selainta ei voi vain yhdistää toisiinsa?

Koska lähes millään laitteella ei ole omaa julkista osoitetta. Kannettavasi on kotireitittimen,
toimiston palomuurin tai mobiilioperaattorin verkon takana. Reititin tekee
[NAT](https://help.strongfolder.com/en/glossary/#nat)-osoitteenmuunnoksen (Network Address Translation): monta yksityistä
laitetta jakaa yhden julkisen IP-osoitteen, ja reititin päästää sisään vain liikenteen, joka
vastaa jotain sisältä lähetettyä.

Niinpä kahdella selaimella on kolme ongelmaa ennen kuin tiedostodataa voi kulkea:

1. Ne eivät tiedä, **miten tavoittaa toisensa** – kumpikaan ei tiedä toisen olemassaolosta.
2. Ne eivät tiedä **omaa julkista osoitettaan** – vain yksityisen, kuten 192.168.1.20.
3. Niiden reitittimet voivat **estää pyytämättömän saapuvan liikenteen**.

WebRTC ratkaisee jokaisen ongelman omalla mekanismillaan.

## Miten WebRTC-tiedostonsiirto toimii vaihe vaiheelta?

Tässä koko kulku ”jaa”-napsautuksesta viimeiseen tavuun:

```
 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
```

**Vaiheet 1–2 – Signalointi.** Lähettäjä valitsee tiedostot; palvelu kirjaa linkkiä varten
tarvittavat metatiedot. Kun vastaanottaja avaa linkin, molemmat selaimet ovat yhteydessä
[signalointipalvelimeen](https://help.strongfolder.com/en/glossary/#signaling). WebRTC ei määrittele, miten signalointi toimii;
StrongFolder käyttää PeerJS:ää ja omaa signalointipalvelintaan.

**Vaihe 3 – Tarjous ja vastaus.** Toinen selain luo **tarjouksen** (offer) SDP-muodossa (Session
Description Protocol): ”Haluan datakanavan, tässä ovat salaussormenjälkeni ja ominaisuuteni.”
Toinen vastaa **vastauksella** (answer). Molemmat kulkevat signalointipalvelimen kautta.

**Vaihe 4 – STUN.** Kumpikin selain kysyy [STUN](https://help.strongfolder.com/en/glossary/#stun)-palvelimelta: ”Mistä osoitteesta
ja portista näet minun tulevan?” Vastaus on sen julkinen osoite sellaisena kuin reititin sen
muuntaa. STUN-palvelimet käsittelevät pienen pyynnön eivätkä mitään tiedostodataa; StrongFolder
käyttää julkisia STUN-palvelimia, myös Googlen, sekä omiaan.

**Vaihe 5 – ICE-kandidaatit.** Kumpikin selain kerää **kandidaatteja** – mahdollisia tapoja
tavoittaa se: lähiverkon osoitteensa (host), STUNilta saadun julkisen osoitteensa
(server-reflexive) ja osoitteen TURN-välityspalvelimella (relayed). Ne vaihtavat kandidaatit
signaloinnin kautta.

**Vaihe 6 – Yhteystarkistukset.** [ICE](https://help.strongfolder.com/en/glossary/#ice) (Interactive Connectivity Establishment)
testaa kandidaattipareja ja valitsee parhaan toimivan. Jos molemmat laitteet ovat samassa
Wi-Fissä, paikallinen reitti voittaa. Jos reitittimet sallivat, suora internetreitti (”hole
punching”) voittaa. Jos mikään suora ei toimi, käytetään välitettyä reittiä.

**Vaihe 7 – DTLS.** Ennen kuin mitään dataa kulkee, selaimet suorittavat [DTLS](https://help.strongfolder.com/en/glossary/#dtls)-
kättelyn (UDP:lle sovitettu TLS) ja tarkistavat, että varmenteiden sormenjäljet vastaavat
tarjouksessa ja vastauksessa olevia. Tästä eteenpäin kaikki on salattua.

**Vaihe 8 – Datakanava.** DTLS:n päällä toimii SCTP, joka antaa datakanavalle luotettavan,
järjestyksessä etenevän toimituksen. StrongFolderissa vastaanottajan selain pyytää tiedostoa,
lähettäjän selain lukee sen levyltä paloina ja lähettää ne, ja vastaanottaja kirjoittaa jokaisen
palan levylle sen saapuessa – joten hyvin suurtenkaan tiedostojen ei tarvitse mahtua muistiin.

## Mitä STUN, TURN, ICE ja muut termit tarkoittavat?

| Termi | Mitä se tekee | Näkeekö tiedostodatan? | Standardi |
|---|---|---|---|
| Signalointi | Välittää tarjoukset, vastaukset ja kandidaatit selainten välillä | Ei | Ei standardoitu (sovelluskohtainen) |
| NAT | Reitittimen toiminto, joka jakaa yhden julkisen IP:n monelle laitteelle | — | — |
| STUN | Kertoo selaimelle sen julkisen osoitteen ja portin | Ei | IETF RFC 8489 |
| ICE | Kerää kandidaatit ja valitsee toimivan reitin | Ei | IETF RFC 8445 |
| TURN | Välittää liikenteen, kun suora reitti ei toimi | Vain salatut paketit | IETF RFC 8656 |
| DTLS | Salaa yhteyden (TLS UDP:lle) | Salaa sen | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP-datakanava | Palojen luotettava, järjestyksessä etenevä toimitus | Kuljettaa sen (salattuna) | IETF RFC 8831 |

Kaikki nämä on selitetty lyhyesti [sanastossa](https://help.strongfolder.com/en/glossary/).

## Milloin TURN-välityspalvelinta käytetään, ja mitä se näkee?

Välityspalvelin on varavaihtoehto, ei oletus. ICE käyttää sitä vain, kun mikään suora
kandidaattipari ei yhdisty – tyypillisesti verkoissa, joissa on **symmetrinen NAT** (jotkin
mobiilioperaattorit), **yrityspalomuureja**, jotka estävät lähtevän UDP:n, tai tiettyjä VPN:iä.

Jos suora yhteys ei ole mahdollinen (tiukka yrityksen palomuuri, jotkin mobiiliverkot), salattu tiedostovirta kulkee StrongFolderin välityspalvelimen (TURN) kautta. Välityspalvelin vain välittää datan eikä tallenna sitä.

Välityspalvelin vastaanottaa DTLS-salattuja paketteja ja välittää ne eteenpäin. Se näkee, että
liikennettä kulkee, kuinka paljon ja milloin – ei sitä, mitä sisällä on. Välitetty siirto voi olla
hitaampi kuin suora, koska jokainen tavu tekee ylimääräisen matkan välityspalvelimen kautta. Jos
siirto on epätavallisen hidas, kokeile toista verkkoa: puhelimen yhteyspiste tai koti-Wi-Fi
yhdistyy usein suoraan, kun toimistoverkko ei.

[Lähetä tiedostot nyt](https://strongfolder.com)
## Kuinka turvallinen WebRTC:n salaus on?

WebRTC tekee salauksesta pakollisen: salaamatonta datakanavaa ei voi avata mitenkään. DTLS
käyttää moderneja salausalgoritmeja, joista selaimet neuvottelevat, ja jokaista yhteyttä varten
luodaan uudet avaimet.

On yksi rehellinen varauma, joka koskee jokaista WebRTC-palvelua. Selaimet tunnistavat toisensa
varmenteiden **sormenjälkien** avulla, jotka vaihdetaan signalointipalvelimen kautta. Luotat siis
siihen, ettei palvelun signalointi peukaloi niitä. Siksi StrongFolder kuvaa suojaustaan
**siirronaikaiseksi salaukseksi** – ei päästä päähän -salaukseksi hallussasi olevilla avaimilla
eikä ”zero-knowledge”-ratkaisuksi. Laajemman näkemyksen siitä, mitä ”turvallinen” tarkoittaa,
saat oppaista [Turvallinen tiedostojen jakaminen](https://help.strongfolder.com/en/guides/secure-file-sharing/) ja
[Tietoturva ja yksityisyys](https://help.strongfolder.com/en/security/).

## Miksi lähettäjän selaimen on pysyttävä auki?

Koska lähettäjän selain *on* lähde. Ei ole palvelimella olevaa kopiota, johon turvautua:
datakanava lukee paloja lähettäjän levyltä vain, kun välilehti on auki ja laite hereillä.
Lähettäjän selainvälilehden on pysyttävä auki ja verkossa, kunnes vastaanottaja on ladannut kaiken – tiedostot tulevat lähettäjän laitteelta, eivät palvelimelta. Siihen varautumisesta kerrotaan oppaassa
[Miksi lähettäjä pysyy verkossa](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

## Kuinka nopea WebRTC-tiedostonsiirto on?

Kiinteää nopeutta ei ole. Ylärajan asettaa reitin hitain lenkki: yleensä lähettäjän
**lähetysnopeus**. Nyrkkisääntönä 1 GB vie noin 2,7 minuuttia 50 Mbit/s:n nopeudella, noin 80
sekuntia 100 Mbit/s:n nopeudella ja selvästi alle minuutin nopeassa lähiverkossa. Todelliset siirrot
jäävät hieman näiden lukujen alle protokollan lisäkuorman, levyn nopeuden ja välityspalvelinta
käytettäessä ylimääräisen välietapin vuoksi. Saman linkin voi avata useampi vastaanottaja; jokainen lataa suoraan lähettäjältä. Useat samanaikaiset lataukset
jakavat lähettäjän lähetyskaistan.

## Yhteenveto

WebRTC-tiedostonsiirto on lyhyt neuvottelu, jota seuraa pitkä, salattu tiedostovirta: signalointi
esittelee selaimet toisilleen, STUN ja ICE etsivät reitin NATin läpi, TURN välittää viimeisenä
keinona, ja DTLS-salatut datakanavat kuljettavat tiedoston levyltä levylle. Käytännön puolesta –
mitä tämä tarkoittaa sinulle lähettäjänä – aloita oppaista
[P2P-tiedostonsiirto selaimessa](https://help.strongfolder.com/en/guides/p2p-file-transfer/) ja
[Näin StrongFolder toimii](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Mikä on WebRTC-datakanava?

Datakanava on WebRTC:n osa, joka kuljettaa mielivaltaisia tavuja kahden selaimen välillä äänen tai videon sijaan. Se käyttää SCTP:tä DTLS:n päällä UDP:n päällä, joten se on salattu ja voidaan määrittää luotettavaksi ja järjestyksessä toimivaksi – juuri sitä tiedostojen siirto vaatii.

### Mitä eroa on STUNilla ja TURNilla?

STUN-palvelin vain kertoo selaimelle, miltä sen julkinen osoite näyttää, jotta selaimet voivat yrittää suoraa yhteyttä; sen kautta ei kulje tiedostodataa. TURN-palvelin on välityspalvelin: kun mikään suora reitti ei toimi, salattu tiedostovirta kulkee sen kautta. StrongFolderilla on omat TURN-välityspalvelimensa, jotka välittävät eivätkä tallenna dataa.

### Näkeekö signalointipalvelin tiedostoni?

Ei. Signalointipalvelin välittää selainten välillä vain yhteysviestejä – istuntokuvauksia ja verkkokandidaatteja. Tiedostodata kulkee datakanavan kautta, joko suoraan tai TURN-välityspalvelimen kautta.

### Onko WebRTC-tiedostonsiirto salattu?

WebRTC salaa jokaisen datakanavan DTLS:llä, joten tiedostovirta on salattu siirron aikana jokaisessa yhteydessä. WebRTC ei salli salaamattomia datakanavia. Selaimet neuvottelevat avaimet keskenään; niiden sormenjäljet kulkevat signaloinnin kautta, minkä vuoksi kyse on siirronaikaisesta salauksesta eikä päästä päähän -salauksesta itse hallinnoimillasi avaimilla.

### Miksi WebRTC-siirto joskus epäonnistuu tai pysyy hitaana?

Yleensä verkkoreitin takia: tiukka palomuuri tai VPN estää suoran UDP:n, jolloin yhteys siirtyy TURN-välityspalvelimelle TCP:n kautta tai ei muodostu lainkaan. Kokeile toista verkkoa (esimerkiksi puhelimen yhteyspistettä), kytke VPN pois päältä tai pyydä IT-osastoa sallimaan WebRTC.

### Voiko TURN-välityspalvelin lukea tiedostojani?

Välityspalvelin välittää DTLS-salattuja paketteja selainten välillä. Se näkee salatun liikenteen, koot ja ajoituksen, ei tiedoston sisältöä, eikä StrongFolderin välityspalvelin tallenna välittämäänsä.