TURN Сервер: що це, як працює та де використовується

Що таке TURN Сервер

TURN Сервер (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-кандидати та отримані від STUN srflx-кандидати. Якщо пряме з’єднання не вдається, ICE автоматично переключиться на relay-кандидат, отриманий від TURN сервера. Параметр iceTransportPolicy: "all" дозволяє relay-кандидати — альтернативне значення "relay" забороняє будь-які кандидати, крім TURN, що корисно для тестування.

Автентифікація TURN сервера

Для запобігання неавторизованому використанню TURN сервер вимагає автентифікації. Стандартний підхід — тимчасові облікові дані (time-limited credentials), що генеруються на сервері додатка з використанням HMAC-SHA1. Сервер додатка шифрує ім’я користувача з секретним ключем TURN сервера та повертає клієнту username і credential. Клієнт передає їх у конфігурацію RTCPeerConnection, браузер використовує їх при створенні allocation на TURN сервері. Після закінчення терміну дії credential клієнт отримує нові від сервера додатка.

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 сервіси переважніші через відсутність витрат на адміністрування та моніторинг.