TURN Server: co to je, jak funguje a kde se používá

Co je TURN Server

TURN Server (Traversal Using Relays around NAT) — je síťová služba definovaná v RFC 5766 a aktualizovaná v RFC 8656, která přenáší UDP a TCP provoz mezi dvěma klienty, když přímé P2P spojení není možné kvůli omezením NAT nebo firewallů. V architektuře WebRTC slouží TURN server jako konečný záložní mechanismus, který zaručuje spojení za všech síťových podmínek.

Na rozdíl od STUN, který pouze informuje klienta o jeho externí adrese, TURN server se aktivně účastní přenosu dat. Každý peer naváže spojení s TURN serverem a odesílá mu svá médiová data. TURN server následně přesměruje tato data druhému peeru. Výsledkem je, že mezi peery neexistuje přímé spojení — veškerý provoz prochází přenosovým serverem, což zaručuje doručení i za těch nejpřísnějších omezení NAT.

Protokol TURN

TURN je rozšířením protokolu STUN. Zprávy TURN používají stejnou 20bajtovou hlavičku a stejný mechanismus atributů. Klíčový rozdíl je v tom, že TURN definuje nové typy zpráv (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) a atributy potřebné pro správu přenosových alokací. Klient vytváří alokaci na TURN serveru prostřednictvím zprávy Allocate, obdrží přenosovou adresu (relayed transport address) a používá ji pro odesílání a příjem dat prostřednictvím serveru.

Jak funguje TURN server

TURN server pracuje podle následující posloupnosti kroků. Klient odešle požadavek Allocate s autentizací (username, credential). Server zkontroluje přihlašovací údaje a vytvoří alokaci — dočasné připojení přenosové adresy (IP:port na TURN serveru) ke klientovi. Server vrátí odpověď Allocate s přenosovou adresou (relayed transport address) — adresou, kterou budou ostatní peery používat pro odesílání dat tomuto klientovi prostřednictvím TURN serveru.

Po vytvoření alokace může klient odesílat data prostřednictvím TURN serveru pomocí zpráv Send Indication nebo prostřednictvím kanálů (ChannelBind). Při příjmu dat od klienta TURN server zkontroluje oprávnění (permissions) a přenese data cílovému peeru. Pro příjem příchozích dat musí klient nejprve vytvořit oprávnění pro peera, od kterého očekává data, jinak TURN server příchozí paket odmítne. Oprávnění se vytváří prostřednictvím zprávy CreatePermission s uvedením IP adresy peera.

Alokace a životnost

Alokace na TURN serveru má omezenou životnost — standardně 10 minut. Klient musí pravidelně odesílat požadavek Refresh Request pro prodloužení alokace. Životnost je uvedena v sekundách v atributu LIFETIME. Pokud není Refresh odeslán, server alokaci smaže a uvolní přenosovou adresu. Doporučený interval obnovení je 5 minut (300 sekund) pro ochranu proti ztrátě paketů Refresh.

Konfigurace TURN serveru ve WebRTC

Ve WebRTC se TURN server konfiguruje prostřednictvím nastavení RTCPeerConnection v poli iceServers. TURN servery mohou používat jak UDP, tak TCP nebo TLS přenos. Pro autentizaci se obvykle používají dočasné přihlašovací údaje (TURN credentials), generované na aplikačním serveru a časově omezené.

Podívejme se na příklad konfigurace TURN serveru v JavaScriptu s autentizací pomocí tokenu HMAC-SHA1.

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);

V tomto příkladu je TURN server uveden společně se STUN serverem v jednotné konfiguraci ICE. Proces ICE nejprve zkusí použít kandidáty host a kandidáty srflx získané od STUN. Pokud přímé spojení selže, ICE automaticky přepne na přenosového kandidáta získaného z TURN serveru. Parametr iceTransportPolicy: "all" povoluje přenosové kandidáty — alternativní hodnota "relay" zakazuje všechny kandidáty kromě TURN, což je užitečné pro testování.

Autentizace TURN serveru

Pro zabránění neoprávněnému použití TURN server vyžaduje autentizaci. Standardním přístupem je použití dočasných přihlašovacích údajů (time-limited credentials), generovaných na aplikačním serveru pomocí HMAC-SHA1. Aplikační server zašifruje uživatelské jméno tajným klíčem TURN serveru a vrátí klientovi uživatelské jméno a přihlašovací údaje. Klient je předá do konfigurace RTCPeerConnection a prohlížeč je použije při vytváření alokace na TURN serveru. Po vypršení platnosti přihlašovacích údajů klient získá nové z aplikačního serveru.

TURN vs STUN: srovnání

TURN a STUN řeší podobné úkoly překonávání NAT, ale zásadně se liší mechanismem a náklady. TURN přenáší provoz a funguje jako prostředník, zatímco STUN pouze pomáhá určit externí adresu pro přímé P2P spojení. Výběr mezi nimi je určen typem NAT peerů a požadavky na výkon.

V praxi se TURN server používá pouze pro spojení, kde P2P není možný. Podle údajů Google (statistiky WebRTC, 2023) přibližně 15–20% všech WebRTC spojení vyžaduje přenos TURN. Zbývajících 80–85% je navázáno prostřednictvím STUN nebo místních kandidátů host. Při navrhování aplikace je třeba vyčlenit rozpočet na provoz TURN ve výši 15–20% celkového objemu médiových dat, pokud cílová skupina zahrnuje uživatele z podnikových sítí a regionů s přísnými omezeními NAT.

Náklady a výkon TURN serveru

TURN server spotřebovává významné zdroje, protože veškerý médiový provoz prochází přes něj. Každé aktivní spojení s přenosem TURN využívá šířku pásma serveru rovnající se celkové kapacitě médiového provozu (příchozí + odchozí tok). Pro videohovor v HD kvalitě (720p) to může být 1,5–2,5 Mb/s na spojení v každém směru, tedy 3–5 Mb/s celkového provozu přes TURN server.

Existuje několik možností nasazení TURN infrastruktury. Bezplatné veřejné TURN servery se nedoporučují pro produkci kvůli chybějícím zárukám kvality a bezpečnosti. Komerční poskytovatelé (Twilio Network Traversal Service, Xirsys, Metered) nabízejí TURN jako službu s platbou za gigabajt provozu — typické náklady jsou $0,005–0,02 za gigabajt. Vlastní nasazení na základě coturn (open-source TURN server) vyžaduje server s dostatečnou šířkou pásma a konfigurací monitorování.

• coturn — nejoblíbenější open-source TURN server, používaný ve většině produkčních systémů, podporuje UDP, TCP, TLS a DTLS přenos.
• Twilio — komerční služba nabízející TURN + STUN s platbou za provoz a autentizací pomocí dočasných tokenů.
• Xirsys — specializovaný poskytovatel TURN s globální sítí serverů a podrobnou analýzou použití.
• Metered.ca — služba TURN s bezplatným limitem až 50 GB měsíčně a platbou za překročení.
• Self-hosted coturn — plná kontrola nad konfigurací, ale vyžaduje správu serveru a nastavení monitorování dostupnosti.

Při výběru řešení pro TURN server je třeba zohlednit geografii uživatelů, náklady na provoz a bezpečnostní požadavky. Pro aplikace s tisíci souběžných hovorů může být self-hosted coturn na serverech s širokým pásmem (1+ Gb/s) úspornější než komerční poskytovatelé. Pro malé projekty s desítkami uživatelů jsou komerční služby TURN výhodnější kvůli absenci nákladů na správu a monitorování.