TURN Server: apa itu, cara kerja dan di mana digunakan

Apa itu TURN Server

TURN Server (Traversal Using Relays around NAT) — adalah layanan jaringan yang didefinisikan dalam RFC 5766 dan diperbarui dalam RFC 8656, yang mentransmisikan ulang traffic UDP dan TCP antara dua klien ketika koneksi langsung P2P tidak memungkinkan karena keterbatasan NAT atau firewall. Dalam arsitektur WebRTC, server TURN bertindak sebagai mekanisme cadangan terakhir, menjamin koneksi dalam kondisi jaringan apa pun.

Berbeda dengan STUN yang hanya memberi tahu klien alamat eksternalnya, server TURN secara aktif berpartisipasi dalam transmisi data. Setiap peer membuat koneksi dengan server TURN dan mengirim data medianya ke sana. Server TURN kemudian meneruskan data ini ke peer lain. Hasilnya, tidak ada koneksi langsung antar peer — semua traffic melewati server relai, yang menjamin pengiriman bahkan dalam keterbatasan NAT yang paling ketat.

Protokol TURN

TURN adalah perpanjangan dari protokol STUN. Pesan TURN menggunakan header 20-byte yang sama dan mekanisme atribut yang sama. Perbedaan utamanya adalah TURN mendefinisikan jenis pesan baru (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) dan atribut yang diperlukan untuk mengelola alokasi relai. Klien membuat alokasi di server TURN melalui pesan Allocate, menerima alamat transport relai (relayed transport address) dan menggunakannya untuk mengirim dan menerima data melalui server.

Bagaimana cara kerja server TURN

Server TURN bekerja berdasarkan urutan langkah berikut. Klien mengirim Allocate Request dengan otentikasi (username, credential). Server memeriksa kredensial dan membuat alokasi — ikatan sementara alamat relai (IP:port di server TURN) dengan klien. Server mengembalikan Allocate Response dengan relayed transport address — alamat yang akan digunakan peer lain untuk mengirim data ke klien ini melalui server TURN.

Setelah pembuatan alokasi, klien dapat mengirim data melalui server TURN menggunakan pesan Send Indication atau melalui saluran (ChannelBind). Saat menerima data dari klien, server TURN memeriksa izin (permissions) dan mentransmisikan ulang data ke peer tujuan. Untuk menerima data masuk, klien harus terlebih dahulu membuat izin untuk peer yang diharapkan datanya, jika tidak server TURN akan menolak paket masuk. Izin dibuat melalui pesan CreatePermission dengan menentukan alamat IP peer.

Alokasi dan masa berlaku

Alokasi di server TURN memiliki masa berlaku terbatas — secara default 10 menit. Klien harus secara periodik mengirim Refresh Request untuk memperpanjang alokasi. Masa berlaku ditentukan dalam detik di atribut LIFETIME. Jika tidak ada Refresh, server menghapus alokasi dan membebaskan alamat relai. Interval penyegaran yang disarankan adalah 5 menit (300 detik) untuk melindungi dari kehilangan paket Refresh.

Konfigurasi server TURN di WebRTC

Di WebRTC, server TURN dikonfigurasi melalui pengaturan RTCPeerConnection di array iceServers. Server TURN dapat menggunakan transport UDP, TCP, atau TLS. Untuk otentikasi biasanya digunakan kredensial sementara (TURN credentials), yang dihasilkan di server aplikasi dan terbatas waktu.

Mari kita lihat contoh konfigurasi server TURN di JavaScript dengan otentikasi melalui token 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);

Dalam contoh ini, server TURN ditentukan bersama dengan server STUN dalam konfigurasi ICE terpadu. Proses ICE pertama-tama akan mencoba menggunakan kandidat host dan kandidat srflx yang diperoleh dari STUN. Jika koneksi langsung gagal, ICE secara otomatis beralih ke kandidat relai yang diperoleh dari server TURN. Parameter iceTransportPolicy: "all" mengizinkan kandidat relai — nilai alternatif "relay" melarang semua kandidat kecuali TURN, yang berguna untuk pengujian.

Otentikasi server TURN

Untuk mencegah penggunaan tidak sah, server TURN memerlukan otentikasi. Pendekatan standar adalah menggunakan kredensial sementara (time-limited credentials), yang dihasilkan di server aplikasi menggunakan HMAC-SHA1. Server aplikasi mengenkripsi nama pengguna dengan kunci rahasia server TURN dan mengembalikan nama pengguna dan kredensial ke klien. Klien meneruskannya ke konfigurasi RTCPeerConnection, dan browser menggunakannya saat membuat alokasi di server TURN. Setelah kredensial kedaluwarsa, klien mendapatkan yang baru dari server aplikasi.

TURN vs STUN: perbandingan

TURN dan STUN memecahkan tugas NAT traversal yang serupa, tetapi secara fundamental berbeda dalam mekanisme dan biaya. TURN mentransmisikan ulang traffic, bertindak sebagai perantara, sementara STUN hanya membantu menentukan alamat eksternal untuk koneksi langsung P2P. Pilihan di antara keduanya ditentukan oleh jenis NAT peer dan persyaratan kinerja.

Dalam praktiknya, server TURN hanya digunakan untuk koneksi di mana P2P tidak memungkinkan. Menurut data Google (statistik WebRTC, 2023), sekitar 15–20% dari semua koneksi WebRTC memerlukan transmisi ulang TURN. Sisanya 80–85% dibuat melalui STUN atau kandidat host lokal. Saat merancang aplikasi, anggaran untuk traffic TURN harus dialokasikan sebesar 15–20% dari total volume data media jika audiens mencakup pengguna dari jaringan korporat dan wilayah dengan keterbatasan NAT yang ketat.

Biaya dan kinerja server TURN

Server TURN mengonsumsi sumber daya yang signifikan karena semua traffic media melewatinya. Setiap panggilan aktif dengan transmisi ulang TURN menggunakan bandwidth server yang sama dengan kapasitas total traffic media (aliran masuk + keluar). Untuk panggilan video berkualitas HD (720p), ini bisa mencapai 1,5–2,5 Mb/s per koneksi di setiap arah, atau 3–5 Mb/s total traffic melalui server TURN.

Ada beberapa opsi untuk menerapkan infrastruktur TURN. Server TURN publik gratis tidak direkomendasikan untuk produksi karena tidak ada jaminan kualitas dan keamanan. Penyedia komersial (Twilio Network Traversal Service, Xirsys, Metered) menawarkan TURN sebagai layanan dengan pembayaran per gigabyte traffic — biaya tipikal $0,005–0,02 per gigabyte. Implementasi sendiri berbasis coturn (server TURN open-source) memerlukan server dengan bandwidth yang memadai dan konfigurasi monitoring.

• coturn — server TURN open-source paling populer, digunakan di sebagian besar sistem produksi, mendukung transport UDP, TCP, TLS, dan DTLS.
• Twilio — layanan komersial yang menyediakan TURN + STUN dengan pembayaran per traffic dan otentikasi melalui token sementara.
• Xirsys — penyedia TURN khusus dengan jaringan server global dan analitik penggunaan terperinci.
• Metered.ca — layanan TURN dengan batas gratis hingga 50 GB per bulan dan pembayaran untuk kelebihan.
• Self-hosted coturn — kontrol penuh atas konfigurasi, tetapi memerlukan administrasi server dan pengaturan monitoring ketersediaan.

Saat memilih solusi untuk server TURN, pertimbangkan geografi pengguna, biaya traffic, dan persyaratan keamanan. Untuk aplikasi dengan ribuan panggilan simultan, self-hosted coturn di server dengan bandwidth lebar (1+ Gb/s) bisa lebih ekonomis daripada penyedia komersial. Untuk proyek kecil dengan puluhan pengguna, layanan TURN komersial lebih disukai karena tidak adanya biaya administrasi dan monitoring.