Filoverføring med WebRTC lar to nettlesere sende en fil til hverandre uten å laste den opp til skylagring. Det høres enkelt ut, men internett ble ikke laget for at to hjemmedatamaskiner skal ringe hverandre direkte. Denne veiledningen går gjennom hva som faktisk skjer – signalering, NAT, STUN, ICE, TURN, DTLS og datakanaler – på enkel norsk, med StrongFolder som eksempel.
Hva er WebRTC?
WebRTC (Web Real-Time Communication) er et sett med nettleser-API-er og nettverksprotokoller, standardisert av W3C og IETF, for sanntidstilkoblinger mellom nettlesere. Chrome, Edge, Firefox, Safari og Opera støtter alle dette. Det ble laget for video- og taleanrop, men har også datakanaler som frakter alle slags binære data – og det er nettopp det en fil er.
Den viktigste egenskapen: når en WebRTC-tilkobling er satt opp, går dataene mellom de to endepunktene, ikke inn i en servers lagring. Det er det som gjør P2P-filoverføring i nettleseren mulig.
Hvorfor kan ikke to nettlesere bare koble seg til hverandre?
Fordi nesten ingen enheter har sin egen offentlige adresse. Den bærbare PC-en din står bak en hjemmeruter, en brannmur på kontoret eller nettverket til en mobiloperatør. Ruteren utfører NAT (Network Address Translation): mange private enheter deler én offentlig IP-adresse, og ruteren slipper bare inn trafikk som svarer på noe som er sendt innenfra.
Så to nettlesere har tre problemer før noen fildata kan flyte:
- De vet ikke hvordan de skal nå hverandre – ingen av dem vet at den andre finnes.
- De vet ikke sin egen offentlige adresse – bare den private, som 192.168.1.20.
- Ruterne deres kan blokkere uoppfordret innkommende trafikk.
WebRTC løser hvert problem med en egen mekanisme.
Hvordan fungerer en filoverføring med WebRTC, trinn for trinn?
Her er hele flyten, fra du klikker «del» til den siste byten:
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
Trinn 1–2 – Signalering. Avsenderen velger filer; tjenesten registrerer metadataene som trengs for lenken. Når mottakeren åpner lenken, er begge nettleserne koblet til en signaleringsserver. WebRTC definerer ikke hvordan signaleringen skal fungere; StrongFolder bruker PeerJS med en egen signaleringsserver.
Trinn 3 – Tilbud og svar. Den ene nettleseren lager et tilbud (offer) i SDP (Session Description Protocol): «Jeg vil ha en datakanal, her er krypteringsfingeravtrykket og egenskapene mine.» Den andre svarer med et svar (answer). Begge går via signaleringsserveren.
Trinn 4 – STUN. Hver nettleser spør en STUN-server: «Hvilken adresse og port ser du at jeg kommer fra?» Svaret er den offentlige adressen slik ruteren har tilordnet den. STUN-servere håndterer en bitte liten forespørsel og ingen fildata; StrongFolder bruker offentlige STUN-servere, blant annet Googles, og egne.
Trinn 5 – ICE-kandidater. Hver nettleser samler kandidater – mulige måter å nå den på: den lokale nettverksadressen (host), den offentlige adressen fra STUN (server-reflexive) og en adresse på et TURN-relé (relayed). Kandidatene utveksles via signaleringen.
Trinn 6 – Tilkoblingstester. ICE (Interactive Connectivity Establishment) tester kandidatpar og velger det beste som virker. Er begge enhetene på samme Wi-Fi, vinner en lokal vei. Hvis ruterne tillater det, vinner en direkte vei over internett («hole punching»). Hvis ingenting direkte virker, brukes veien via relé.
Trinn 7 – DTLS. Før noen data flyter, gjennomfører nettleserne et DTLS-håndtrykk (TLS tilpasset UDP) og sjekker at sertifikatfingeravtrykkene stemmer med dem i tilbudet og svaret. Fra nå av er alt kryptert.
Trinn 8 – Datakanal. Over DTLS kjører SCTP, som gir datakanalen pålitelig levering i riktig rekkefølge. I StrongFolder ber mottakerens nettleser om en fil, avsenderens nettleser leser den fra disken i biter og sender dem, og mottakeren skriver hver bit til disken etter hvert som den kommer – så selv svært store filer trenger aldri å få plass i minnet.
Hva betyr STUN, TURN, ICE og de andre begrepene?
| Begrep | Hva det gjør | Ser fildata? | Standard |
|---|---|---|---|
| Signalering | Sender tilbud, svar og kandidater mellom nettleserne | Nei | Ikke standardisert (avhenger av appen) |
| NAT | Ruterfunksjon som deler én offentlig IP mellom mange enheter | — | — |
| STUN | Forteller en nettleser dens offentlige adresse og port | Nei | IETF RFC 8489 |
| ICE | Samler kandidater og velger en vei som virker | Nei | IETF RFC 8445 |
| TURN | Videresender trafikk når ingen direkte vei virker | Bare krypterte pakker | IETF RFC 8656 |
| DTLS | Krypterer tilkoblingen (TLS for UDP) | Krypterer dem | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP-datakanal | Pålitelig levering av biter i riktig rekkefølge | Frakter dem (kryptert) | IETF RFC 8831 |
Alle disse er kort forklart i ordlisten.
Når brukes et TURN-relé, og hva ser det?
Et relé er reserveløsningen, ikke standarden. ICE bruker det bare når ingen direkte kandidatpar får kontakt – typisk på nettverk med symmetrisk NAT (enkelte mobiloperatører), bedriftsbrannmurer som blokkerer utgående UDP, eller visse VPN-er.
Hvis en direkte tilkobling er umulig (streng bedriftsbrannmur, enkelte mobilnett), går den krypterte datastrømmen via en relé-server (TURN) fra StrongFolder. Reléet videresender dataene og lagrer dem ikke.
Reléet mottar DTLS-krypterte pakker og sender dem videre. Det kan se at trafikk flyter, hvor mye og når – ikke hva som er inni. En overføring via relé kan være tregere enn en direkte, fordi hver byte tar en ekstra tur gjennom reléet. Hvis en overføring er uvanlig treg, prøv et annet nettverk: en mobil hotspot eller Wi-Fi hjemme kobler ofte direkte der et kontornettverk ikke gjør det.
Gratis · i nettleseren · uten registrering
Hvor sikker er krypteringen i WebRTC?
WebRTC gjør kryptering obligatorisk: det finnes ingen måte å åpne en ukryptert datakanal på. DTLS bruker moderne chifre som forhandles fram av de to nettleserne, og nye nøkler lages for hver tilkobling.
Det finnes ett ærlig forbehold som gjelder alle WebRTC-tjenester. De to nettleserne bekrefter hverandre gjennom fingeravtrykk av sertifikatene, som utveksles via signaleringsserveren. Du stoler dermed på at tjenestens signalering ikke tukler med dem. Derfor beskriver StrongFolder beskyttelsen sin som kryptering under overføring – ikke som ende-til-ende-kryptering med nøkler du har selv, og ikke som «zero-knowledge». For et bredere syn på hva «sikker» betyr, les Sikker fildeling og Sikkerhet og personvern.
Hvorfor må avsenderens nettleser være åpen?
Fordi avsenderens nettleser er kilden. Det finnes ingen kopi på en server å falle tilbake på: datakanalen leser biter fra avsenderens disk bare mens fanen er åpen og enheten er våken. Avsenderens nettleserfane må være åpen og på nett til mottakeren er ferdig med nedlastingen – filene kommer fra avsenderens enhet, ikke fra en server. Hvordan du planlegger for dette, står i Hvorfor avsenderen må være på nett.
Hvor rask er filoverføring med WebRTC?
Det finnes ingen fast hastighet. Taket er det tregeste leddet på veien: vanligvis avsenderens opplastingshastighet. Som tommelfingerregel tar 1 GB omtrent 2,7 minutter med 50 Mbit/s, omtrent 80 sekunder med 100 Mbit/s og godt under ett minutt på et raskt lokalt nettverk. Virkelige overføringer går litt under disse tallene på grunn av protokolloverhead, diskhastighet og, med relé, det ekstra hoppet. Én lenke kan åpnes av flere mottakere; hver av dem laster ned direkte fra avsenderen. Flere nedlastinger samtidig deler avsenderens opplasting.
Oppsummering
En filoverføring med WebRTC er en kort forhandling etterfulgt av en lang, kryptert datastrøm: signaleringen introduserer nettleserne, STUN og ICE finner en vei gjennom NAT, TURN videresender som siste utvei, og DTLS-krypterte datakanaler frakter filen fra disk til disk. For den praktiske siden – hva dette betyr for deg som avsender – begynn med P2P-filoverføring i nettleseren og Slik fungerer StrongFolder.