TURN Server: co to jest, jak działa i gdzie jest używany

Co to jest TURN Server

TURN Server (Traversal Using Relays around NAT) — to usługa sieciowa zdefiniowana w RFC 5766 i zaktualizowana w RFC 8656, która retransmituje ruch UDP i TCP między dwoma klientami, gdy bezpośrednie połączenie P2P jest niemożliwe z powodu ograniczeń NAT lub zapór ogniowych. W architekturze WebRTC serwer TURN pełni rolę końcowego mechanizmu rezerwowego, gwarantującego połączenie w każdych warunkach sieciowych.

W przeciwieństwie do STUN, który po prostu informuje klienta o jego zewnętrznym adresie, serwer TURN aktywnie uczestniczy w przesyłaniu danych. Każda para łączy się z serwerem TURN i wysyła do niego swoje dane medialne. Serwer TURN z kolei przekazuje te dane drugiej parze. W rezultacie między parami nie istnieje bezpośrednie połączenie — cały ruch przechodzi przez serwer przekaźnikowy, co gwarantuje dostarczenie nawet przy najbardziej restrykcyjnych ograniczeniach NAT.

Protokół TURN

TURN jest rozszerzeniem protokołu STUN. Komunikaty TURN używają tego samego 20-bajtowego nagłówka i mechanizmu atrybutów. Kluczową różnicą jest to, że TURN definiuje nowe typy komunikatów (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) i atrybuty niezbędne do zarządzania przekaźnikowymi alokacjami. Klient tworzy alokację na serwerze TURN za pomocą komunikatu Allocate, otrzymuje adres przekaźnikowy (relayed transport address) i używa go do wysyłania i odbierania danych przez serwer.

Jak działa serwer TURN

Serwer TURN działa według następującej sekwencji kroków. Klient wysyła Allocate Request z uwierzytelnieniem (username, credential). Serwer sprawdza dane logowania i tworzy alokację — tymczasowe powiązanie adresu przekaźnikowego (IP:port na serwerze TURN) z klientem. Serwer zwraca Allocate Response z relayed transport address — adresem, którego inne pary będą używać do wysyłania danych temu klientowi przez serwer TURN.

Po utworzeniu alokacji klient może wysyłać dane przez serwer TURN za pomocą komunikatów Send Indication lub przez kanały (ChannelBind). Po otrzymaniu danych od klienta serwer TURN sprawdza uprawnienia (permissions) i retransmituje dane do docelowej pary. Aby odbierać dane przychodzące, klient musi wcześniej utworzyć uprawnienie dla pary, od której oczekuje danych, w przeciwnym razie serwer TURN odrzuci przychodzący pakiet. Uprawnienie tworzy się za pomocą komunikatu CreatePermission z podaniem adresu IP pary.

Alokacja i czas życia

Alokacja na serwerze TURN ma ograniczony czas życia — domyślnie 10 minut. Klient musi okresowo wysyłać Refresh Request, aby przedłużyć alokację. Czas życia podawany jest w sekundach w atrybucie LIFETIME. W przypadku braku odświeżenia serwer usuwa alokację i zwalnia adres przekaźnikowy. Zalecany interwał odświeżania to 5 minut (300 sekund) dla zabezpieczenia przed utratą pakietów Refresh.

Konfiguracja serwera TURN w WebRTC

W WebRTC serwer TURN konfiguruje się przez ustawienia RTCPeerConnection w tablicy iceServers. Serwery TURN mogą korzystać zarówno z transportu UDP, jak i TCP lub TLS. Do uwierzytelniania zwykle używa się tymczasowych danych logowania (TURN credentials), generowanych na serwerze aplikacji i ograniczonych czasowo.

Rozważmy przykład konfiguracji serwera TURN w JavaScript z uwierzytelnieniem za pomocą tokena 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);

W tym przykładzie serwer TURN jest podawany razem z serwerem STUN w jednolitej konfiguracji ICE. Proces ICE najpierw spróbuje użyć kandydatów host i srflx uzyskanych od STUN. Jeśli bezpośrednie połączenie się nie powiedzie, ICE automatycznie przełączy się na kandydata przekaźnikowego uzyskanego z serwera TURN. Parametr iceTransportPolicy: "all" zezwala na kandydatów przekaźnikowych — alternatywna wartość "relay" zabrania wszystkich kandydatów oprócz TURN, co jest przydatne do testowania.

Uwierzytelnianie serwera TURN

Aby zapobiec nieautoryzowanemu użyciu, serwer TURN wymaga uwierzytelnienia. Standardowym podejściem są tymczasowe dane logowania (time-limited credentials), generowane na serwerze aplikacji przy użyciu HMAC-SHA1. Serwer aplikacji szyfruje nazwę użytkownika z tajnym kluczem serwera TURN i zwraca klientowi nazwę użytkownika i dane logowania. Klient przekazuje je w konfiguracji RTCPeerConnection, a przeglądarka używa ich przy tworzeniu alokacji na serwerze TURN. Po wygaśnięciu ważności danych logowania klient otrzymuje nowe z serwera aplikacji.

TURN vs STUN: porównanie

TURN i STUN rozwiązują podobne zadania NAT traversal, ale zasadniczo różnią się mechanizmem i kosztem. TURN retransmituje ruch, peŁniąc rolę pośrednika, podczas gdy STUN pomaga jedynie określić zewnętrzny adres do bezpośredniego połączenia P2P. Wybór między nimi zależy od typu NAT par i wymagań dotyczących wydajności.

W praktyce serwer TURN jest używany tylko do tych połączeń, w których P2P jest niemożliwy. Według danych Google (statystyki WebRTC, 2023), około 15–20% wszystkich połączeń WebRTC wymaga retransmisji TURN. Pozostałe 80–85% nawigowanych jest przez STUN lub przez lokalnych kandydatów host. Przy projektowaniu aplikacji należy uwzględnić budżet na ruch TURN w wysokości 15–20% całkowitego wolumenu danych medialnych, jeśli grupa docelowa obejmuje użytkowników z sieci korporacyjnych i regionów z restrykcyjnymi ograniczeniami NAT.

Koszt i wydajność serwera TURN

Serwer TURN zużywa znaczne zasoby, ponieważ cały ruch medialny przechodzi przez niego. Każde aktywne połączenie z retransmisją TURN wykorzystuje przepustowość serwera równą łącznej przepustowości ruchu medialnego (strumień przychodzący + wychodzący). W przypadku połączenia wideo w jakości HD (720p) może to wynosić 1,5–2,5 Mb/s na połączenie w każdym kierunku, czyli łącznie 3–5 Mb/s ruchu przez serwer TURN.

Istnieje kilka opcji wdrożenia infrastruktury TURN. Bezpłatne publiczne serwery TURN nie są zalecane do środowiska produkcyjnego ze względu na brak gwarancji jakości i bezpieczeństwa. Komercyjni dostawcy (Twilio Network Traversal Service, Xirsys, Metered) oferują TURN jako usługę z płatnością za gigabajt ruchu — typowy koszt wynosi $0,005–0,02 za gigabajt. Własne wdrożenie oparte na coturn (open-source TURN server) wymaga serwera z wystarczającą przepustowością i konfiguracją monitorowania.

• coturn — najpopularniejszy open-source TURN server, używany w większości systemów produkcyjnych, obsługuje transport UDP, TCP, TLS i DTLS.
• Twilio — komercyjna usługa oferująca TURN + STUN z płatnością za ruch i uwierzytelnieniem za pomocą tymczasowych tokenów.
• Xirsys — specjalistyczny dostawca TURN z globalną siecią serwerów i szczegółową analityką użycia.
• Metered.ca — usługa TURN z bezpłatnym limitem do 50 GB miesięcznie i płatnością powyżej limitu.
• Self-hosted coturn — pełna kontrola nad konfiguracją, ale wymaga administrowania serwerem i konfiguracji monitorowania dostępności.

Przy wyborze rozwiązania dla serwera TURN należy uwzględnić geografię użytkowników, koszt ruchu i wymagania dotyczące bezpieczeństwa. W przypadku aplikacji z tysiącami jednoczesnych połączeń self-hosted coturn na serwerach z szerokim łączem (1+ Gb/s) może być bardziej ekonomiczny niż komercyjni dostawcy. W przypadku małych projektów z kilkudziesięcioma użytkownikami komercyjne usługi TURN są preferowane ze względu na brak kosztów administrowania i monitorowania.