TURN Server: ano ito, paano ito gumagana at saan ginagamit

Ano ang TURN Server

TURN Server (Traversal Using Relays around NAT) — ay isang network service na tinukoy sa RFC 5766 at na-update sa RFC 8656, na nagre-relay ng UDP at TCP traffic sa pagitan ng dalawang client kapag hindi posible ang direktang P2P connection dahil sa mga limitasyon ng NAT o firewalls. Sa WebRTC architecture, ang TURN server ay gumaganap bilang huling mekanismo ng backup, na ginagarantiyahan ang koneksyon sa anumang kondisyon ng network.

Hindi tulad ng STUN na nagsasabi lang sa client ng external address nito, ang TURN server ay aktibong nakikilahok sa pagpapadala ng data. Bawat peer ay nagtatatag ng koneksyon sa TURN server at nagpapadala ng media data dito. Ang TURN server naman ay nagre-redirect ng data na ito sa ibang peer. Bilang resulta, walang direktang koneksyon sa pagitan ng mga peer — lahat ng traffic ay dumadaan sa relay server, na ginagarantiyahan ang paghahatid kahit sa pinakamahigpit na NAT restrictions.

TURN Protocol

TURN ay isang extension ng STUN protocol. Ang mga TURN message ay gumagamit ng parehong 20-byte header at attribute mechanism. Ang pangunahing pagkakaiba ay tinutukoy ng TURN ang mga bagong uri ng mensahe (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) at mga attribute na kinakailangan para sa pamamahala ng relay allocations. Gumagawa ang client ng allocation sa TURN server sa pamamagitan ng Allocate message, tumatanggap ng relayed transport address, at ginagamit ito para magpadala at tumanggap ng data sa pamamagitan ng server.

Paano gumagana ang TURN server

Ang TURN server ay gumagana ayon sa sumusunod na pagkakasunod-sunod ng mga hakbang. Nagpapadala ang client ng Allocate Request na may authentication (username, credential). Sinusuri ng server ang credentials at gumagawa ng allocation — pansamantalang pagbubuklod ng relay address (IP:port sa TURN server) sa client. Nagbabalik ang server ng Allocate Response na may relayed transport address — ang address na gagamitin ng ibang mga peer para magpadala ng data sa client na ito sa pamamagitan ng TURN server.

Pagkatapos ng paggawa ng allocation, ang client ay maaaring magpadala ng data sa pamamagitan ng TURN server gamit ang Send Indication messages o sa pamamagitan ng channels (ChannelBind). Sa pagtanggap ng data mula sa client, sinusuri ng TURN server ang mga permissions at nagre-relay ng data sa target na peer. Para makatanggap ng papasok na data, ang client ay dapat munang gumawa ng permission para sa peer na inaasahang magpapadala ng data, kung hindi ay tatanggihan ng TURN server ang papasok na packet. Ang permission ay ginagawa sa pamamagitan ng CreatePermission message na may IP address ng peer.

Allocation at lifetime

Ang allocation sa TURN server ay may limitadong lifetime — default na 10 minuto. Ang client ay dapat na pana-panahong magpadala ng Refresh Request para palawigin ang allocation. Ang lifetime ay nakasaad sa segundo sa LIFETIME attribute. Kung walang Refresh, tatanggalin ng server ang allocation at pakakawalan ang relay address. Inirerekomendang refresh interval ay 5 minuto (300 segundo) para sa proteksyon laban sa pagkawala ng Refresh packets.

Configuration ng TURN server sa WebRTC

Sa WebRTC, ang TURN server ay naka-configure sa pamamagitan ng RTCPeerConnection configuration sa iceServers array. Ang mga TURN server ay maaaring gumamit ng UDP, TCP, o TLS transport. Para sa authentication, karaniwang ginagamit ang mga temporary credentials (TURN credentials), na binuo sa application server at limitado sa oras.

Tingnan natin ang isang halimbawa ng configuration ng TURN server sa JavaScript na may authentication sa pamamagitan ng HMAC-SHA1 token.

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);

Sa halimbawang ito, ang TURN server ay tinukoy kasama ng STUN server sa iisang ICE configuration. Ang ICE process ay susubukan munang gumamit ng host candidates at srflx candidates na nakuha mula sa STUN. Kung ang direktang koneksyon ay nabigo, ang ICE ay awtomatikong lumipat sa relay candidate na nakuha mula sa TURN server. Ang parameter na iceTransportPolicy: "all" ay nagpapahintulot ng relay candidates — ang alternatibong value na "relay" ay nagbabawal sa lahat ng candidates maliban sa TURN, na kapaki-pakinabang para sa pag-test.

Authentication ng TURN server

Para maiwasan ang hindi awtorisadong paggamit, ang TURN server ay nangangailangan ng authentication. Ang standard approach ay ang paggamit ng time-limited credentials, na binuo sa application server gamit ang HMAC-SHA1. Ine-encrypt ng application server ang username gamit ang secret key ng TURN server at ibinabalik ang username at credential sa client. Ipinapasa ng client ang mga ito sa RTCPeerConnection configuration, at ginagamit ng browser ang mga ito sa paggawa ng allocation sa TURN server. Pagkatapos ng expiration ng credentials, ang client ay kumukuha ng bago mula sa application server.

TURN vs STUN: paghahambing

TURN at STUN ay lumulutas ng mga katulad na NAT traversal tasks, ngunit pangunahing nagkakaiba sa mekanismo at gastos. Ang TURN ay nagre-relay ng traffic, na gumaganap bilang tagapamagitan, samantalang ang STUN ay tumutulong lamang na matukoy ang external address para sa direktang P2P connection. Ang pagpili sa pagitan ng mga ito ay tinutukoy ng NAT type ng mga peer at mga kinakailangan sa performance.

Sa praktika, ang TURN server ay ginagamit lamang para sa mga koneksyon kung saan hindi posible ang P2P. Ayon sa data ng Google (WebRTC statistics, 2023), humigit-kumulang 15–20% ng lahat ng WebRTC connections ay nangangailangan ng TURN relay. Ang natitirang 80–85% ay itinatag sa pamamagitan ng STUN o lokal na host candidates. Sa pagdidisenyo ng application, dapat maglaan ng budget para sa TURN traffic sa halagang 15–20% ng kabuuang volume ng media data, kung ang audience ay may kasamang mga user mula sa corporate network at mga rehiyon na may mahigpit na NAT restrictions.

Gastos at performance ng TURN server

Ang TURN server ay kumokonsumo ng malaking resources dahil lahat ng media traffic ay dumadaan dito. Bawat aktibong tawag na may TURN relay ay gumagamit ng server bandwidth na katumbas ng kabuuang kapasidad ng media traffic (papasok + papalabas na stream). Para sa isang HD quality (720p) video call, ito ay maaaring 1,5–2,5 Mb/s bawat koneksyon sa bawat direksyon, o 3–5 Mb/s kabuuang traffic sa pamamagitan ng TURN server.

Mayroong ilang mga opsyon para sa pag-deploy ng TURN infrastructure. Ang mga libreng pampublikong TURN server ay hindi inirerekomenda para sa production dahil sa kawalan ng garantiya sa kalidad at seguridad. Ang mga commercial provider (Twilio Network Traversal Service, Xirsys, Metered) ay nag-aalok ng TURN bilang serbisyo na may bayad bawat gigabyte ng traffic — tipikal na gastos ay $0,005–0,02 bawat gigabyte. Ang self-hosted deployment batay sa coturn (open-source TURN server) ay nangangailangan ng server na may sapat na bandwidth at configuration ng monitoring.

• coturn — ang pinakasikat na open-source TURN server, ginagamit sa karamihan ng production systems, sumusuporta sa UDP, TCP, TLS at DTLS transport.
• Twilio — commercial service na nagbibigay ng TURN + STUN na may bayad bawat traffic at authentication sa pamamagitan ng temporary tokens.
• Xirsys — specialized TURN provider na may global server network at detalyadong usage analytics.
• Metered.ca — TURN service na may libreng limit hanggang 50 GB bawat buwan at bayad para sa sobra.
• Self-hosted coturn — buong kontrol sa configuration, ngunit nangangailangan ng server administration at pag-setup ng availability monitoring.

Sa pagpili ng solusyon para sa TURN server, isaalang-alang ang heograpiya ng mga user, gastos ng traffic, at mga kinakailangan sa seguridad. Para sa mga application na may libu-libong sabay-sabay na tawag, ang self-hosted coturn sa mga server na may malawak na bandwidth (1+ Gb/s) ay maaaring mas matipid kaysa sa commercial providers. Para sa maliliit na proyekto na may sampu-sampung user, mas gusto ang commercial TURN services dahil sa kawalan ng gastos sa administration at monitoring.