TURN Server: vad är det, hur fungerar det och var används det

Vad är TURN Server

TURN Server (Traversal Using Relays around NAT) — är en nätverkstjänst definierad i RFC 5766 och uppdaterad i RFC 8656, som vidarebefordrar UDP- och TCP-trafik mellan två klienter när direkt P2P-anslutning är omöjlig på grund av NAT-begränsningar eller brandväggar. I WebRTC-arkitekturen fungerar TURN-servern som en slutlig reservmekanism som garanterar anslutning under alla nätverksförhållanden.

Till skillnad från STUN, som bara talar om för klienten dess externa adress, deltar TURN-servern aktivt i dataöverföringen. Varje peer upprättar en anslutning till TURN-servern och skickar sina mediadata till den. TURN-servern vidarebefordrar dessa data till den andra peer. Som ett resultat finns det ingen direkt anslutning mellan peers — all trafik går genom reläservern, vilket garanterar leverans även under de strängaste NAT-begränsningarna.

TURN-protokollet

TURN är en utökning av STUN-protokollet. TURN-meddelanden använder samma 20-byte-huvud och attributmekanism. Den viktigaste skillnaden är att TURN definierar nya meddelandetyper (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) och attribut som behövs för hantering av reläallokeringar. Klienten skapar en allokering på TURN-servern via Allocate-meddelandet, får en relätransportadress (relayed transport address) och använder den för att skicka och ta emot data via servern.

Hur fungerar TURN-servern

TURN-servern fungerar enligt följande steg. Klienten skickar en Allocate-förfrågan med autentisering (username, credential). Servern kontrollerar inloggningsuppgifterna och skapar en allokering — en tillfällig koppling av reläadressen (IP:port på TURN-servern) till klienten. Servern returnerar ett Allocate-svar med relayed transport address — adressen som andra peers kommer att använda för att skicka data till denna klient via TURN-servern.

Efter att allokeringen har skapats kan klienten skicka data via TURN-servern med hjälp av Send Indication-meddelanden eller via kanaler (ChannelBind). När data tas emot från klienten kontrollerar TURN-servern behörigheterna (permissions) och vidarebefordrar data till målpeern. För att ta emot inkommande data måste klienten först skapa en behörighet för den peer från vilken den förväntar sig data, annars kommer TURN-servern att avvisa det inkommande paketet. Behörigheten skapas via CreatePermission-meddelandet med angivande av peerens IP-adress.

Allokering och livslängd

Allokeringen på TURN-servern har en begränsad livslängd — som standard 10 minuter. Klienten måste periodiskt skicka en Refresh-förfrågan för att förlänga allokeringen. Livslängden anges i sekunder i LIFETIME-attributet. Vid utebliven Refresh tar servern bort allokeringen och frigör reläadressen. Rekommenderat uppdateringsintervall är 5 minuter (300 sekunder) för att skydda mot förlust av Refresh-paket.

Konfiguration av TURN-server i WebRTC

I WebRTC konfigureras TURN-servern via RTCPeerConnection-inställningarna i iceServers-arrayen. TURN-servrar kan använda både UDP och TCP eller TLS-transport. För autentisering används vanligtvis tillfälliga inloggningsuppgifter (TURN credentials), genererade på applikationsservern och tidsbegränsade.

Låt oss titta på ett exempel på konfiguration av TURN-server i JavaScript med autentisering via HMAC-SHA1-token.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

I detta exempel anges TURN-servern tillsammans med STUN-servern i en enhetlig ICE-konfiguration. ICE-processen kommer först att försöka använda host-kandidater och srflx-kandidater erhållna från STUN. Om den direkta anslutningen misslyckas växlar ICE automatiskt till reläkandidaten som erhållits från TURN-servern. Parametern iceTransportPolicy: "all" tillåter reläkandidater — det alternativa värdet "relay" förbjuder alla kandidater utom TURN, vilket är användbart för testning.

Autentisering av TURN-servern

För att förhindra obehörig användning kräver TURN-servern autentisering. Standardmetoden är att använda tidsbegränsade inloggningsuppgifter (time-limited credentials), genererade på applikationsservern med HMAC-SHA1. Applikationsservern krypterar användarnamnet med TURN-serverns hemliga nyckel och returnerar användarnamnet och inloggningsuppgifterna till klienten. Klienten skickar dem vidare till RTCPeerConnection-konfigurationen och webbläsaren använder dem när den skapar en allokering på TURN-servern. Efter att inloggningsuppgifterna har upphört att gälla får klienten nya från applikationsservern.

TURN vs STUN: jämförelse

TURN och STUN löser liknande NAT-passageuppgifter men skiljer sig fundamentalt i mekanism och kostnad. TURN vidarebefordrar trafik och fungerar som medlare, medan STUN bara hjälper till att bestämma den externa adressen för direkt P2P-anslutning. Valet mellan dem bestäms av peerens NAT-typ och prestandakrav.

I praktiken används TURN-servern endast för anslutningar där P2P är omöjligt. Enligt Google-data (WebRTC-statistik, 2023) kräver cirka 15–20% av alla WebRTC-anslutningar TURN-vidarebefordran. Återstående 80–85% upprättas via STUN eller lokala host-kandidater. Vid design av applikationen bör en budget avsättas för TURN-trafik på 15–20% av den totala mediadatavolymen om målgruppen inkluderar användare från företagsnätverk och regioner med strikta NAT-begränsningar.

Kostnad och prestanda för TURN-server

TURN-servern förbrukar betydande resurser eftersom all mediatrafik går genom den. Varje aktivt samtal med TURN-vidarebefordran använder serverbandbredd som motsvarar den totala mediagenomströmningen (inkommande + utgående ström). För ett videosamtal i HD-kvalitet (720p) kan detta vara 1,5–2,5 Mb/s per anslutning i varje riktning, det vill säga 3–5 Mb/s total trafik genom TURN-servern.

Det finns flera alternativ för att distribuera TURN-infrastruktur. Gratis offentliga TURN-servrar rekommenderas inte för produktion på grund av bristande kvalitets- och säkerhetsgarantier. Kommersiella leverantörer (Twilio Network Traversal Service, Xirsys, Metered) erbjuder TURN som en tjänst med betalning per gigabyte trafik — den typiska kostnaden är $0,005–0,02 per gigabyte. Egen distribution baserad på coturn (open-source TURN-server) kräver en server med tillräcklig bandbredd och konfigurering av övervakning.

• coturn — den mest populära open-source TURN-servern, som används i de flesta produktionssystem, stödjer UDP-, TCP-, TLS- och DTLS-transport.
• Twilio — kommersiell tjänst som erbjuder TURN + STUN med betalning per trafik och autentisering via tillfälliga tokens.
• Xirsys — specialiserad TURN-leverantör med globalt servernätverk och detaljerad användningsanalys.
• Metered.ca — TURN-tjänst med gratis gräns på upp till 50 GB per månad och betalning för överskridande.
• Self-hosted coturn — full kontroll över konfigurationen, men kräver serveradministration och inställning av tillgänglighetsövervakning.

När du väljer en lösning för TURN-servern bör du ta hänsyn till användarnas geografi, trafikkostnader och säkerhetskrav. För applikationer med tusentals samtidiga samtal kan self-hosted coturn på servrar med bred bandbredd (1+ Gb/s) vara mer ekonomiskt än kommersiella leverantörer. För små projekt med tiotals användare är kommersiella TURN-tjänster att föredra på grund av avsaknaden av administrations- och övervakningskostnader.