# Slik fungerer filoverføring med WebRTC

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

> Filoverføring med WebRTC skjer i tre faser. En signaleringsserver introduserer to nettlesere; STUN og ICE finner en nettverksvei gjennom hjemmerutere (NAT), med et TURN-relé som reserve hvis ingen direkte vei finnes; deretter åpner nettleserne en DTLS-kryptert datakanal og strømmer filen i biter, direkte eller via reléet, uten å lagre den.

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.

**Key facts**

- **WebRTC** er en nettleserstandard for direkte, krypterte tilkoblinger mellom to enheter; verktøy for fildeling bruker **datakanalene** dens.
- **Signalering** introduserer nettleserne; **STUN** og **ICE** finner en vei gjennom rutere (**NAT**); et **TURN-relé** videresender trafikken når ingen direkte vei finnes.
- **Kryptering:** hver datakanal bruker **DTLS** – WebRTC har ingen ukryptert modus.
- StrongFolder bruker PeerJS oppå WebRTC, en egen signaleringsserver, offentlige STUN-servere (blant annet Googles) og egne TURN-reléer. Filer lastes aldri opp til eller lagres på en server hos StrongFolder.
- Filen strømmer i biter fra avsenderens disk til mottakerens disk; avsenderen er på nett hele tiden.

## Hva er WebRTC?

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

1. De vet ikke **hvordan de skal nå hverandre** – ingen av dem vet at den andre finnes.
2. De vet ikke **sin egen offentlige adresse** – bare den private, som 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

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

[Send filer nå](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/) og [Sikkerhet og personvern](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

## 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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) og
[Slik fungerer StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Hva er en WebRTC-datakanal?

En datakanal er den delen av WebRTC som frakter vilkårlige byte mellom to nettlesere i stedet for lyd eller video. Den kjører SCTP over DTLS over UDP, så den er kryptert og kan settes opp som pålitelig og ordnet – akkurat det filoverføring trenger.

### Hva er forskjellen mellom STUN og TURN?

En STUN-server forteller bare en nettleser hvordan den offentlige adressen dens ser ut, slik at de to nettleserne kan prøve å koble seg direkte sammen; ingen fildata går gjennom den. En TURN-server er et relé: når ingen direkte vei virker, går den krypterte datastrømmen gjennom den. StrongFolder driver egne TURN-reléer, som videresender og ikke lagrer data.

### Ser signaleringsserveren filene mine?

Nei. Signaleringsserveren sender bare tilkoblingsmeldinger – øktbeskrivelser og nettverkskandidater – mellom nettleserne. Fildataene går over datakanalen, enten direkte eller via et TURN-relé.

### Er filoverføring med WebRTC kryptert?

WebRTC krypterer hver datakanal med DTLS, så datastrømmen er kryptert under overføringen på hver tilkobling. WebRTC tillater ikke ukrypterte datakanaler. Nøklene forhandles fram av de to nettleserne; fingeravtrykkene deres går via signaleringen, og derfor er dette kryptering under overføring og ikke ende-til-ende-kryptering med nøkler du selv styrer.

### Hvorfor feiler eller går en WebRTC-overføring noen ganger tregt?

Som regel på grunn av nettverksveien: en streng brannmur eller VPN blokkerer direkte UDP, så tilkoblingen faller tilbake til et TURN-relé over TCP eller ikke kobler til i det hele tatt. Prøv et annet nettverk (for eksempel en mobil hotspot), slå av VPN-en eller be IT-avdelingen tillate WebRTC.

### Kan et TURN-relé lese filene mine?

Reléet videresender DTLS-krypterte pakker mellom de to nettleserne. Det ser kryptert trafikk, størrelser og tidspunkter, ikke innholdet i filen, og reléet til StrongFolder lagrer ikke det det videresender.