WebRTC på én linje
WebRTC (Web Real-Time Communication) lader to browsere oprette en direkte, krypteret forbindelse til hinanden – uden plugins og uden at trafikken skal gennem en central server.
Du har sikkert brugt det uden at vide det: mange videomøder og opkald i browseren bygger på WebRTC.
De fire byggesten
1. Signaling – at finde hinanden
To browsere kender ikke hinandens adresser på forhånd. De skal udveksle en lille "beskrivelse" af forbindelsen (kaldet SDP) og en liste over mulige netværksveje (ICE-kandidater). Det sker via en server – hos SendDirekte vores egen – men det er kun små tekstbeskeder, aldrig selve filen.
2. STUN – at finde sin offentlige adresse
De fleste enheder sidder bag en router og kender ikke deres egen offentlige adresse. En STUN-server svarer blot: "sådan ser du ud udefra". Med den oplysning kan de to browsere ofte "punche hul" gennem routerne og forbinde direkte.
3. TURN – omvejen (som SendDirekte ikke bruger)
Nogle netværk tillader ikke direkte forbindelser. Så kan trafikken sendes via en TURN-relæserver. Det betyder, at al data – også filen – går gennem en server. SendDirekte bruger ikke relæ til filer; kan en direkte forbindelse ikke oprettes, stopper overførslen.
4. DataChannels – selve dataene
Når forbindelsen er oprettet, kan browserne sende vilkårlige data over en RTCDataChannel. SendDirekte bruger én kanal til korte kontrolbeskeder og én til filens indhold, sendt i bidder på 64 KB.
Er WebRTC krypteret?
Ja – altid. WebRTC-standarden kræver, at forbindelser krypteres (DTLS for data). Nøglerne laves af de to browsere, så en server imellem kan ikke læse data.
Men krypteret er ikke det samme som anonymt: for at forbinde direkte skal de to parter kende hinandens IP-adresser.
Hvorfor virker det ikke altid?
Firmanetværk, skolenetværk og nogle mobilnetværk kan blokere de forbindelser, WebRTC bruger – eller sidde bag "streng NAT", der gør det svært at forbinde direkte. Du kan tjekke dit netværk med forbindelsestesten.