TURN Server: какво е, как работи и къде се използва

Какво е TURN Server

TURN Server (Traversal Using Relays around NAT) — това е мрежова услуга, дефинирана в RFC 5766 и актуализирана в RFC 8656, която ретранслира UDP и TCP трафик между два клиента, когато директната P2P връзка е невъзможна поради ограничения на NAT или защитни стени. В архитектурата на WebRTC TURN сървърът действа като финален резервен механизъм, гарантиращ връзка при всякакви мрежови условия.

За разлика от STUN, който просто съобщава на клиента неговия външен адрес, TURN сървърът активно участва в предаването на данни. Всеки пир установява връзка с TURN сървъра и изпраща своите медийни данни към него. TURN сървърът, от своя страна, ги пренасочва към другия пир. В резултат между пировете няма директна връзка — целият трафик преминава през релейния сървър, което гарантира доставката дори при най-строги NAT ограничения.

Протоколът TURN

TURN е разширение на протокола STUN. Съобщенията на TURN използват същата 20-байтова заглавна част и механизма на атрибутите. Ключовата разлика — TURN дефинира нови типове съобщения (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) и атрибути, необходими за управление на релейните allocation. Клиентът създава allocation на TURN сървъра чрез съобщение Allocate, получава релеен адрес (relayed transport address) и го използва за изпращане и приемане на данни през сървъра.

Как работи TURN сървърът

TURN сървърът работи по следната последователност от стъпки. Клиентът изпраща Allocate Request с удостоверяване (username, credential). Сървърът проверява данните и създава allocation — временна привръзка на релейния адрес (IP:порт на TURN сървъра) към клиента. Сървърът връща Allocate Response с relayed transport address — адрес, който другите пирове ще използват, за да изпращат данни на този клиент през TURN сървъра.

След създаването на allocation клиентът може да изпраща данни през TURN сървъра чрез съобщения Send Indication или чрез канали (ChannelBind). При получаване на данни от клиента TURN сървърът проверява permissions (разрешения за изпращане на данни до определени пирове) и ретранслира данните до целевия пир. За получаване на входящи данни клиентът трябва предварително да създаде permission за пира, от който очаква данни, в противен случай TURN сървърът ще отхвърли входящия пакет. Permission се създава чрез съобщение CreatePermission с посочване на IP адреса на пира.

Allocation и време на живот

Allocation на TURN сървъра има ограничено време на живот — по подразбиране 10 минути. Клиентът трябва периодично да изпраща Refresh Request, за да удължи allocation. Времето на живот се посочва в секунди в атрибута LIFETIME. При липса на Refresh сървърът изтрива allocation и освобождава релейния адрес. Препоръчителен интервал на опресняване — 5 минути (300 секунди) за защита от загуба на Refresh пакети.

Настройка на TURN сървър в WebRTC

В WebRTC TURN сървърът се настройва чрез конфигурацията на RTCPeerConnection в масива iceServers. TURN сървърите могат да използват UDP, TCP или TLS транспорт. За удостоверяване обикновено се използват временни данни за достъп (TURN credentials), генерирани на сървъра на приложението и ограничени във времето.

Да разгледаме пример за настройка на TURN сървър в JavaScript с удостоверяване чрез 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);

В този пример TURN сървърът се посочва заедно с STUN сървъра в единна ICE конфигурация. ICE процесът първо ще се опита да използва host кандидатите и srflx кандидатите, получени от STUN. Ако директната връзка не успее, ICE автоматично преминава на relay кандидат, получен от TURN сървъра. Параметърът iceTransportPolicy: "all" разрешава relay кандидати — алтернативната стойност "relay" забранява всички кандидати освен TURN, което е полезно за тестване.

Удостоверяване на TURN сървъра

За предотвратяване на неоторизирана употреба TURN сървърът изисква удостоверяване. Стандартният подход — временни данни за достъп (time-limited credentials), генерирани на сървъра на приложението чрез HMAC-SHA1. Сървърът на приложението криптира потребителското име с таен ключ на TURN сървъра и връща на клиента username и credential. Клиентът ги предава в конфигурацията на RTCPeerConnection, а браузърът ги използва при създаването на allocation на TURN сървъра. След изтичане на срока на credentials клиентът получава нови от сървъра на приложението.

TURN vs STUN: сравнение

TURN и STUN решават сродни задачи на NAT traversal, но принципно се различават по механизъм и цена. TURN ретранслира трафика, изпълнявайки ролята на посредник, докато STUN само помага да се определи външният адрес за директна P2P връзка. Изборът между тях се определя от типа NAT на пировете и изискванията за производителност.

На практика TURN сървърът се използва само за тези връзки, при които P2P е невъзможен. Според данни на Google (WebRTC статистика, 2023), около 15–20% от всички WebRTC връзки изискват TURN ретранслация. Останалите 80–85% се установяват чрез STUN или чрез локални host кандидати. При проектирането на приложението трябва да се заложи бюджет за TURN трафик в размер на 15–20% от общия обем медийни данни, ако аудиторията включва потребители от корпоративни мрежи и региони със строги NAT ограничения.

Цена и производителност на TURN сървъра

TURN сървърът консумира значителни ресурси, тъй като целият медиен трафик преминава през него. Всеки активен разговор с TURN ретранслация използва честотна лента на сървъра, равна на общата пропускателна способност на медийния трафик (входящ + изходящ поток). За видеоразговор в HD качество (720p) това може да възлиза на 1,5–2,5 Мбит/с на връзка във всяка посока, тоест 3–5 Мбит/с общ трафик през TURN сървъра.

Съществуват няколко варианта за разгръщане на TURN инфраструктура. Безплатните публични TURN сървъри не се препоръчват за продакшън поради липса на гаранции за качество и сигурност. Търговските доставчици (Twilio Network Traversal Service, Xirsys, Metered) предоставят TURN като услуга с плащане за гигабайт трафик — типичната цена е $0,005–0,02 за гигабайт. Самостоятелното разгръщане на базата на coturn (open-source TURN сървър) изисква сървър с достатъчна пропускателна способност и настройка на мониторинг.

• coturn — най-популярният open-source TURN сървър, използван в повечето продакшън системи, поддържа UDP, TCP, TLS и DTLS транспорт.
• Twilio — търговска услуга, предоставяща TURN + STUN с плащане за трафик и удостоверяване чрез временни токени.
• Xirsys — специализиран TURN доставчик с глобална мрежа от сървъри и подробна аналитика на използването.
• Metered.ca — TURN услуга с безплатен лимит до 50 ГБ на месец и плащане над лимита.
• Self-hosted coturn — пълен контрол върху конфигурацията, но изисква администриране на сървъра и настройка на мониторинг на достъпността.

При избора на решение за TURN сървъра трябва да се вземат предвид географията на потребителите, цената на трафика и изискванията за сигурност. За приложения с хиляди едновременни разговори self-hosted coturn на сървъри с широк канал (1+ Гбит/с) може да е по-икономичен от търговските доставчици. За малки проекти с десетки потребители търговските TURN услуги са за предпочитане поради липсата на разходи за администриране и мониторинг.