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-кандидаты и полученные от STUN srflx-кандидаты. Если прямое соединение не удаётся, 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 сервисы предпочтительнее из-за отсутствия затрат на администрирование и мониторинг.