TURN Server: шта је, како ради и где се користи

Шта је TURN Server

TURN Server (Traversal Using Relays around NAT) — то је мрежни сервис дефинисан у RFC 5766 и ажуриран у RFC 8656, који прослеђује UDP и TCP саобраћај између два клијента када директна P2P веза није могућа због ограничења NAT-а или firewall-а. У 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 услуге су пожељније због изостанка трошкова администрирања и мониторинга.