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.
Mikä WebRTC on?
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 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-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:
- Ne eivät tiedä, miten tavoittaa toisensa – kumpikaan ei tiedä toisen olemassaolosta.
- Ne eivät tiedä omaa julkista osoitettaan – vain yksityisen, kuten 192.168.1.20.
- 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. 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-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 (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- 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.
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.
Ilmainen · selaimessa · ei rekisteröitymistä
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 ja Tietoturva ja yksityisyys.
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.
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 ja Näin StrongFolder toimii.