Penjelasan dan praktik menyeluruh tentang STUN/TURN/TURNS/SFU di WebRTC

12 april 2025

Daftar isi

Apa itu WebRTC?

WebRTC (Web Real-Time Communication) adalah teknologi terbuka yang memungkinkan komunikasi audio, video, dan data secara real-time antar peramban. WebRTC sedang distandarisasi oleh berbagai perusahaan, termasuk Google, sebagai mekanisme yang memungkinkan komunikasi P2P hanya menggunakan API JavaScript, tanpa memerlukan plug-in atau perangkat lunak tambahan.

WebRTC terdiri dari tiga komponen utama:

dapatkanMediaPengguna: API untuk memperoleh audio dan video dari perangkat seperti kamera dan mikrofon.
Koneksi RTCPeer:API inti untuk membangun komunikasi antara rekan dan bertukar media dan data.
Saluran Data RTC: Saluran data yang dapat digunakan untuk mengirim berkas, mengobrol, dll.

API ini memungkinkan pengembangan berbagai aplikasi waktu nyata seperti panggilan video, konferensi audio, berbagi berkas, dll. Namun, dalam komunikasi aktual, terdapat masalah dengan traversal NAT dan firewall, sehingga penting untuk memahami dan menerapkan teknologi traversal NAT seperti STUN/TURN/TURNS.

Perbedaan dan peran STUN, TURN, dan TURNS

Mekanisme traversal NAT sangat penting untuk mencapai koneksi peer-to-peer yang stabil dengan WebRTC. Artikel ini memberikan penjelasan mendetail tentang tiga teknologi utama, STUN, TURN, dan TURNS, termasuk perbedaan teknis, skenario penggunaan, serta kelebihan dan kekurangannya.

STUN adalah protokol yang terutama digunakan untuk menemukan alamat eksternal sendiri dalam lingkungan NAT, sementara TURN adalah protokol yang berfungsi sebagai server relai ketika koneksi langsung tidak memungkinkan. Di sisi lain, TURNS mengenkripsi komunikasi TURN dengan TLS dan menggunakan port 443, sama seperti HTTPS, sehingga memungkinkan komunikasi di balik firewall yang ketat seperti jaringan perusahaan.

Dengan memahami karakteristik masing-masing dan menggunakannya secara tepat, Anda dapat meningkatkan tingkat keberhasilan dan kualitas komunikasi WebRTC.

Peran dan Karakteristik STUN (UDP)

STUN (Session Traversal Utilities for NAT) adalah protokol yang memungkinkan klien untukAlamat IP dan port eksternalMisalnya, jika PC Anda berada di belakang NAT, ia tidak mengetahui alamat IP globalnya sendiri, tetapi ia dapat memperoleh "IP:port seperti yang terlihat dari dunia luar" dengan menanyakan server STUN.

Server STUN bertindak seperti cermin, mengembalikan informasi sumber permintaan yang diterima persis seperti aslinya. Hasilnya, klien dapat mengetahui alamat IP globalnya sendiri dan nomor port yang ditetapkan oleh NAT (Server Reflexive Candidate).

Komunikasi STUN biasanya dilakukan melalui UDP, dengan port default 3478 (UDP/3478). Karena hanya memerlukan komunikasi single-shot yang ringan melalui UDP, komunikasi ini memiliki overhead yang rendah, latensi yang rendah, dan hampir tidak membebani server. Oleh karena itu, dalam lingkungan yang mengizinkan komunikasi UDP, traversal NAT menggunakan STUN dicoba terlebih dahulu.

Skenario penggunaan STUN

Ini efektif di lingkungan yang mengharuskan traversal NAT tetapi komunikasi UDP itu sendiri tidak terblokir, seperti jaringan rumah atau jaringan seluler. Jika STUN dapat memperoleh IP dan port eksternal masing-masing, klien dapat membangun komunikasi langsung (peer-to-peer). Karena jalur komunikasinya langsung, latensi rendah dan kualitas tetap terjaga pada tingkat tinggi. Selain itu, karena server hanya memfasilitasi pertukaran informasi IP, biayanya tetap sangat rendah. Misalnya, dalam gim daring atau panggilan video, jika kedua perangkat berada di belakang NAT yang relatif terbuka, STUN cukup untuk mengaktifkan koneksi peer-to-peer.

Keterbatasan dan Kerugian STUN

STUN hanyalah cara untuk "menemukan alamat eksternal Anda sendiri", dan tergantung pada jenis NAT dan batasan firewall, koneksi mungkin tidak dapat dilakukan hanya dengan menggunakan cara ini. Khususnya, dalam lingkungan NAT simetris atau firewall yang ketat, paket dari pihak lain mungkin tidak mencapai alamat yang diperoleh oleh STUN, sehingga komunikasi menjadi mustahil.

Selain itu, komunikasi UDP sendiri mungkin terblokir di jaringan perusahaan, sehingga permintaan STUN sendiri mungkin tidak diterima. Singkatnya, STUN adalah mekanisme untuk menentukan apakah komunikasi langsung memungkinkan, dan mekanisme ini tidak akan berfungsi di lingkungan di mana komunikasi langsung secara fisik mustahil. Karena alasan ini, STUN digunakan dalam ICE (dijelaskan di bawah) untuk mendapatkan kandidat tahap pertama, dan jika STUN tidak mencukupi, mekanisme ini dirancang untuk kembali ke TURN, yang dijelaskan di bawah.

Peran dan karakteristik TURN (UDP)

TURN (Traversal Menggunakan Relay di Sekitar NAT) adalah protokol yang bertindak sebagai relai perantara ketika komunikasi langsung tidak memungkinkan menggunakan STUN. Server TURN bertindak sebagai titik relai yang dapat diakses secara global, bertindak sebagai perantara antara mitra komunikasi dan pihak lain untuk meneruskan paket. Klien terhubung ke server TURN dan mendapatkan alamat IP dan port relai, yang dikenal sebagai kandidat relai. Setelah itu, pertukaran media dan data dengan pihak lain terjadi melalui server TURN tersebut.

TURN juga biasanya berkomunikasi melalui UDP, sehingga selama UDP digunakan, TURN dapat meneruskan paket media dengan cara yang mirip dengan komunikasi langsung. Secara default, protokol TURN diterima pada port 3478 (UDP), sama seperti STUN. Meskipun kebijakan firewall Anda membatasi nomor port UDP, Anda juga dapat menjalankan TURN pada port yang diizinkan seperti UDP/443. Selama UDP tersedia, penerusan dengan kinerja waktu nyata yang lebih tinggi daripada TCP dimungkinkan.

Skenario penggunaan TURN

TURN penting ketika koneksi langsung tidak dapat dibuat. Misalnya,Hal ini terjadi ketika satu atau kedua belah pihak berada di balik firewall perusahaan yang ketat, atau ketika kedua belah pihak memiliki NAT simetris, yang dapat menyebabkan kegagalan pengetikan lubang UDP.Dalam lingkungan seperti itu, komunikasi tidak mungkin dilakukan tanpa meneruskan melalui server TURN, jadi TURN bertindak sebagai semacam pilihan terakhir.

WebRTC bertujuan agar semua rekan dapat berkomunikasi secara langsung, tetapi meskipun hal ini tidak memungkinkan, komunikasi dapat dilanjutkan dengan menggunakan TURN. Dalam pengoperasiannya, strategi umumnya adalah mencoba koneksi langsung menggunakan STUN terlebih dahulu, dan baru beralih ke relai TURN jika gagal. Misalnya, dalam konferensi video melalui jaringan internal, jika dua rekan tidak dapat berkomunikasi secara langsung, sistem akan secara otomatis beralih ke komunikasi melalui server TURN, yang memungkinkan percakapan berlanjut tanpa sepengetahuan pengguna.

Manfaat TURN

Keunggulan terbesarnya adalah keandalan. Bahkan di lingkungan NAT atau firewall apa pun, komunikasi peer-to-peer pada akhirnya dapat tercapai selama komunikasi dapat terjalin dari klien ke server TURN. TURN juga merupakan perluasan dari protokol STUN, sehingga satu implementasi server (seperti coturn, yang dijelaskan di bawah) dapat memproses permintaan STUN dan TURN. Setelah koneksi terjalin, media selanjutnya diteruskan sebagai aliran, sehingga komunikasi menjadi lancar dari sudut pandang pengguna, dengan sedikit penundaan.

Kekurangan TURN

Kelemahan terbesarnya adalah konsumsi sumber daya dan latensi. Dengan TURN, semua data audio dan video melewati server, sehingga membutuhkan bandwidth dan daya pemrosesan yang sangat besar di sisi server. Misalnya, jika kita berasumsi bahwa panggilan video satu-ke-satu menghabiskan bandwidth 1Mbps dalam satu arah, maka dengan perhitungan sederhana, 1.000 pengguna simultan akan membutuhkan bandwidth relai sebesar 1Gbps. Hal ini membuat biaya operasional server TURN tinggi, dan layanan berskala besar memerlukan penyediaan beberapa server relai TURN agar dapat ditingkatkan skalanya.

Selain itu, jalur komunikasi yang lebih panjang meningkatkan latensi, yang mengakibatkan jeda waktu video dan audio serta penurunan kualitas. Lebih lanjut, dibandingkan dengan komunikasi peer-to-peer melalui STUN, TURN tidak sepenuhnya peer-to-peer, sehingga sedikit kurang aman dalam hal kerahasiaan (meskipun server TURN biasanya hanya menyampaikan RTP/datagram yang tidak terenkripsi dan tidak menginterpretasikan kontennya).

Secara keseluruhan, TURN sebaiknya hanya digunakan jika diperlukan. Faktanya, sebagian besar komunikasi WebRTC dapat dihubungkan langsung menggunakan STUN, dan statistik Google menunjukkan bahwa sekitar 861 TP3T dari semua panggilan dibuat tanpa relai (peer-to-peer). Hanya sekitar 141 TP3T sisanya yang memerlukan TURN, tetapi penting untuk memiliki infrastruktur TURN untuk 141 TP3T tersebut.

Peran dan fitur TURNS (TLS melalui TCP/443)

TURNS adalah singkatan dari "TURN over TLS," yang berarti bahwa komunikasi relai melalui protokol TURN dienkripsi lebih lanjut dengan TLS (Transport Layer Security).Komunikasi TURN diamankan oleh TLS (HTTPS)Sering disajikan pada port TCP 443.Port 443 adalah nomor port yang sama dengan HTTPS, sehingga dapat dengan mudah melewati firewall perusahaan dan menerobos proxy serta penyensoran..

Misalnya, jaringan internal perusahaan mungkin hanya mengizinkan komunikasi eksternal melalui port 80 dan 443, tetapi bahkan dalam kasus ini, jika server TURN menggunakan komunikasi TLS melalui port 443, ada kemungkinan besar komunikasi tersebut dapat diteruskan. Selain itu, karena komunikasi dienkripsi TLS, komunikasi tersebut aman dan sulit disadap oleh pihak ketiga.

Dalam WebRTC, pengaturannya"urls": "turns:turnsserver:443"Dalam skema URI,berubah:Anda dapat menggunakan server TURN terenkripsi TLS ini dengan menentukan

Skenario penggunaan TURNS

TURNS berguna untuk komunikasi WebRTC di lingkungan yang sangat terbatas, seperti jaringan perusahaan, di mana semua cara lain diblokir. Bahkan di lingkungan di mana semua port UDP dan TCP umum diblokir, banyak kebijakan mengizinkan komunikasi selama diperlakukan sama dengan komunikasi HTTPS, sehingga TURN melalui port TLS 443 secara efektif merupakan pilihan terakhir.

Ini juga digunakan dalam situasi di mana port tertentu ditutup pada LAN nirkabel publik, atau ketika hanya komunikasi TLS yang memungkinkan di sisi klien.Pertama UDP, jika tidak berhasil maka TCP, jika tidak berhasil maka TLS ke 443Ini diposisikan sebagai tahap akhir dari kemunduran bertahap.

Manfaat TURNS

Keunggulan terbesarnya adalah ketahanannya terhadap firewall yang tinggi. Komunikasi terenkripsi TLS sulit dibedakan dari HTTPS standar, sehingga lebih mudah melewati filter yang ketat sekalipun. Khususnya, ketika memperkenalkan sistem konferensi web ke perusahaan, koneksi eksternal dari jaringan internal harus diizinkan, dan komunikasi TLS melalui TCP/443 lebih mungkin diterima berdasarkan kebijakan keamanan. Selain itu, karena terenkripsi, kerahasiaan komunikasi ke server relai itu sendiri dapat terjamin (perlu diketahui bahwa konten itu sendiri, seperti video, seringkali sudah dienkripsi pada lapisan WebRTC).

Kerugian dari TURNS

Kelemahan terbesarnya adalah penalti kinerja. Selain latensi dan beban TURN itu sendiri, terdapat overhead tambahan dari TLS dan TCP. TCP menyediakan transportasi yang andal dan memiliki mekanisme transmisi ulang jika terjadi kehilangan paket, tetapi tidak cocok untuk media waktu nyata (real-time), dan kehilangan paket dapat menyebabkan video dan audio tidak dapat diputar dengan lancar.

Selain itu, TCP rentan terhadap pemblokiran head-of-line karena urutan paket,Jitter (fluktuasi) juga meningkat dibandingkan dengan UDPLebih lanjut, pemrosesan enkripsi dan dekripsi TLS memberikan beban tambahan pada CPU. Akibatnya, dilaporkan terjadi penundaan tambahan sebesar 50 ms atau lebih, yang menyebabkan kelambatan yang dapat dirasakan oleh pengguna. Khususnya dalam konferensi video, peningkatan penundaan ini dapat memperlambat tempo percakapan dan menyebabkan perbedaan waktu yang signifikan.

Dengan cara ini, TURNS dapat dianggap sebagai "pilihan terakhir" dalam hal kualitas, tetapi juga merupakan jalur hidup yang dapat diandalkan dalam situasi di mana tidak ada pilihan lain selain memastikan komunikasi.

Dalam beberapa tahun terakhir, pendekatan baru (TURN over QUIC) yang beroperasi pada port UDP 443 dan menggunakan DTLS/QUIC alih-alih TLS telah dipertimbangkan, tetapi masih dalam proses standarisasi dan belum digunakan secara luas.

Aliran komunikasi saat UDP STUN tidak dapat digunakan

Kami akan menjelaskan langkah demi langkah bagaimana pemrosesan WebRTC ICE berlangsung ketika STUN melalui UDP tidak tersedia. Mari kita asumsikan situasi di mana UDP diblokir sepenuhnya, seperti pada jaringan perusahaan, dan ikuti bagaimana negosiasi ICE mengalami fallback.

Klien mengirimkan kueri IP eksternal (UDP/3478) ke server STUN:
Klien WebRTC (peramban)server esPermintaan Pengikatan (permintaan untuk memverifikasi alamat eksternal) dikirim ke server STUN yang ditentukan melalui port UDP 3478. Ini adalah langkah pertama dalam mengumpulkan kandidat ICE, dan jika berhasil, server akan mengembalikan alamat IP global dan nomor port-nya sendiri, dan menambahkannya ke daftar kandidat sebagai Kandidat Refleksif Server (kandidat srflx).
Paket UDP diblokir oleh firewall dan tidak ada respons:
Dalam kasus ini, pengaturan firewall jaringan mencegah komunikasi UDP menjangkau pihak luar. Oleh karena itu, permintaan ke server STUN tidak sampai ke server, atau responsnya tidak sampai ke klien. Akibatnya, klienTidak ada respons STUN yang diterima, alamat IP eksternal tidak dapat diketahui. Agen ICE menunggu respons selama jangka waktu tertentu, tetapi terjadi batas waktu. Dari sudut pandang pengguna, koneksi masih berlangsung dan tidak ada pesan kesalahan yang ditampilkan, tetapi kenyataannya,Gagal mengumpulkan kandidatHal ini sedang terjadi saat ini.
Pemeriksaan koneksi langsung ICE gagal karena tidak ada kandidat Server Reflexive yang tersedia:
Biasanya, jika STUN berhasil, klien akan memiliki kandidat Host (IP lokalnya) serta kandidat Server Reflexive (IP globalnya), dan akan memeriksa koneksi dengan menggabungkannya dengan kandidat yang sama dari rekan di ujung yang jauh. Namun, jika STUN gagal dan tidak ada kandidat IP global,Kandidat yang sangat terbatas untuk koneksi langsung dengan rekan sejawatMisalnya, jika kedua pihak hanya memiliki alamat IP privat, mereka tidak akan dapat saling menghubungi meskipun mencoba terhubung. Akibatnya, ICE akan menentukan bahwa "komunikasi langsung tidak memungkinkan." Jika server ICE (TURN) tidak dikonfigurasi, seluruh ICE akan dianggap gagal pada tahap ini, dan koneksi WebRTC tidak akan dibuat (konsol pengembang akan menampilkanICE gagaldan ... danStatus koneksi ICE: gagalatau kesalahan lainnya akan ditampilkan).
Upaya untuk mendapatkan kandidat relai TURN (melalui TCP/TLS/443):
Bahkan jika akuisisi kandidat langsung melalui STUN gagal,server esJika server TURN ditentukan diLangkah SelanjutnyaDalam skenario ini, UDP tidak didukung, jadi klien mencoba untuk terhubung ke server TURN menggunakan TCP atau TLS (misalnya,putaran:putar.contoh.com:443(Jika dikonfigurasi, jabat tangan TLS akan dimulai.) Untungnya, firewall mengizinkan komunikasi HTTPS pada TCP 443, sehingga koneksi TURN melalui TLS berhasil. Klien mengamankan alamat relai di server TURN,Kandidat EstafetPihak lain akan mendapatkan kandidat relai (kandidat). Ini adalah "kandidat virtual untuk komunikasi melalui server TURN." Sementara itu, pihak lain (pihak jarak jauh) juga akan mendapatkan kandidat relai, atau jika jaringan bebas masalah, akan mendapatkan kandidat langsung atau kandidat STUN. Bagaimanapun, jika setidaknya satu pihak memiliki kandidat relai, pihak lain dapat mencoba terhubung ke server TURN tersebut.
Pembentukan koneksi ICE (atau kegagalan akhirnya) melalui relai:
Setelah kedua peer mendapatkan kandidat yang tersedia (satu atau kedua kandidat relay dalam contoh ini), ICE menggunakannya untuk memeriksa koneksi. Komunikasi melalui server TURN dapat di-relay setelah terhubung dengan server, sehingga saluran media tetap terbuka meskipun UDP tidak terhubung langsung antar peer. Hal ini memungkinkan komunikasi video dan audio antar pengguna dimulai. Setelah koneksi terhubung, terdapat overhead TCP melalui TLS, tetapi percakapan itu sendiri tetap dimungkinkan. Sebaliknya, jika terjadi kegagalan di sini juga (misalnya, proksi perusahaan mendeteksi dan memblokir komunikasi TLS non-HTTP, atau autentikasi server TURN gagal), sayangnya, ICE akan gagal dan koneksi akan dihentikan. Aplikasi harus mendeteksi situasi ini dan memberi tahu pengguna, misalnya "Koneksi gagal."

Ini adalah alur negosiasi ICE dalam lingkungan yang keras di mana UDP tidak dapat digunakan. Singkatnya, kandidat dicoba dalam urutan "host → STUN → TURN", dan jika tidak berhasil, koneksi akan gagal. Penting bagi pengembang untuk memahami perilaku ini dan setidaknya menyertakan server TURN/TURNS dalam daftar server ICE, agar komunikasi tetap dapat terjalin bahkan dalam situasi terburuk. Lebih lanjut, ketika menerima pertanyaan dari pengguna, diperlukan pemecahan masalah, seperti menyimpulkan masalah dengan lingkungan jaringan (seperti pemblokiran UDP) dari informasi seperti "ICE gagal" dan memeriksa apakah server TURN telah dikonfigurasi dengan benar.

Membangun dan mengonfigurasi server STUN/TURN/TURNS menggunakan coturn

Jika Anda ingin membuat server STUN/TURN Anda sendiri, gunakan implementasi sumber terbuka. coturnPenggunaan coturn merupakan hal yang umum. Coturn adalah implementasi server yang mendukung STUN dan TURN, dan tergantung pada konfigurasinya, ia juga dapat mendukung TURNS (TLS). Artikel ini menjelaskan cara menginstal coturn di server Linux dan cara membangun server yang menyediakan STUN/TURN/TURNS, serta poin-poin konfigurasinya. Selain itu, kami akan menjelaskan berkas konfigurasi umum (turnserver.conf) juga ditampilkan.

Instalasi dan Konfigurasi Dasar

Install

Untuk Ubuntu atau Debian,tepatAnda dapat menginstal paket coturn dari baris perintah. Misalnya, gunakan perintah berikut untuk menginstalnya dan mengaturnya agar dimulai secara otomatis.

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

Ini akan memulai server coturn sebagai daemon. Secara default, server akan menggunakan berkas konfigurasi /etc/turnserver.conf Ini akan memuat berkas, dan Anda kemudian dapat mengeditnya (buat cadangan sebelum mengedit untuk berjaga-jaga).

Pengaturan dasar

turnserver.confSekarang, atur item berikut:

wilayah dan nama server: Ini adalah nama domain atau pengenal server TURN. Nama ini dapat digunakan saat mengautentikasi klien WebRTC, tetapi pada dasarnya dapat berupa string apa pun. Contoh: wilayah=contoh.com,nama-server=example.com.
port pendengaran: Nomor port UDP untuk mendengarkan TURN dan STUN. Default-nya adalah 3478.mendengarkan-ipAnda juga dapat mengikat ke NIC tertentu dengan0.0.0.0Kami menerima semuanya.
port-pendengar-tls: Ini adalah nomor port TCP untuk mendengarkan TLS (TURNS). Umumnya, Anda akan menentukan 443 atau 5349. Contoh: port-pendengaran-tls=443.
ip eksternal: Jika server itu sendiri berada di belakang NAT, tentukan IP globalnya sendiri (ini memungkinkan server mengenali pemetaan antara IP internal dan IP eksternal). Hal ini tidak diperlukan jika server memiliki IP global langsung.
Metode autentikasi: WebRTC TURN menggunakan kredensial jangka panjang,lt-cred-mech(Mekanisme Kredensial Jangka Panjang) diaktifkan.pengguna=nama pengguna:kata sandiAtur nama pengguna dan kata sandi dalam formatgunakan-rahasia-otorisasi(Yang terakhir adalah autentikasi berbasis token, yang efektif untuk meningkatkan keamanan, tetapi di sini kami akan menunjukkan autentikasi pengguna statis sederhana sebagai contoh.)
Pengaturan Log: Untuk pemecahan masalahberkas logTentukan jalur file log dibertele-teleAnda mungkin ingin mengaktifkan pencatatan verbose.

Pengaturan firewall

Di sisi server, untuk STUN/TURNPort UDP 3478, dan untuk TURN/TLSPort TCP 443(atau 5349) harus terbuka. Selain itu, relai TURN menggunakan rentang UDP 10000-20000 secara default, jadi buka juga rentang port ini di server (jika perlu).pelabuhan mindanport maksimum(Rentang dapat diubah dengan

Berikut adalah daftar pengaturan yang mencerminkan pengaturan dasar di atas./etc/turnserver.confBerikut ini adalah sebuah contoh:

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

Pada gambar di atas, domaincontoh.comKami memperoleh sertifikat Let's Encrypt dan menggunakannya untuk konfigurasi TLS.lt-cred-mechAktifkan autentikasi jangka panjang denganpenggunaOtentikasi nama pengguna dan kata sandi sederhana dikonfigurasi menggunakangunakan-rahasia-otorisasidanrahasia-otorisasi-statisMetode yang disarankan adalah menggunakan metode berbasis token untuk menerbitkan kredensial sementara, tetapi kami tidak akan membahasnya di sini.

Tindakan pencegahan saat menggunakan TLS

Saat menjalankan Coturn pada port 443, Anda perlu berhati-hati dengan izin port di lingkungan Linux. Port di bawah 1024 disebut port istimewa dan biasanya tidak dapat dibuka tanpa hak akses root. Paket coturn Ubuntu secara default menggunakantukang putarKarena dijalankan oleh pengguna, port 443 tidak dapat diikat sebagaimana adanya./etc/default/coturnUbah pengguna yang berjalan menjadi root, atausetcapDengan perintahtukang putarke file yang dapat dieksekusicap_net_bind_serviceAda beberapa cara untuk memberikan izin. Misalnya, dalam kasus terakhir,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverDengan menjalankan perintah ini, Anda dapat mengikat port bernomor rendah meskipun Anda bukan pengguna root. Selain itu, harap tentukan jalur yang benar ke berkas sertifikat (cert/pkey) dan atur izin berkas agar pengguna coturn dapat membacanya. Setelah mengubah pengaturan,sudo systemctl restart coturnMulai ulang layanan dan periksa log untuk melihat apakah ada kesalahan.

Pemeriksaan operasi

Setelah memulai server Coturn, kami akan mengujinya menggunakan klien STUN untuk memeriksa operasinya, lalu mencoba menghubungkan ke ICE dari aplikasi WebRTC di peramban.klien yang menakjubkanmemerintah(apt-get install stun-client(Dapat dipasang distunclient <IP server> 3478Anda dapat mencoba mendapatkan IP eksternal Anda dengan menjalankan perintah berikut. Selain itu, di peramban Anda, kandidat ICE akan tercantum dalam log alat pengembang, jadisrflx(Server Refleksif) kandidat danmenyampaikanSilakan periksa apakah Anda mendapatkan kandidat. Jika tidak, coba langkah-langkah pemecahan masalah berikut:

Apakah port yang diperlukan terbuka dalam pengaturan firewall server (iptables dan grup keamanan cloud)?
Apakah URI, port, dan informasi autentikasi yang benar ditetapkan dalam pengaturan server ICE sisi klien (dijelaskan di bawah)?
turnserver.confdariduniaPeriksa apakah pengaturannya cocok dengan autentikasi klien (ini biasanya tidak menjadi masalah pada versi WebRTC browser, karena secara otomatis menetapkan wilayah, tetapi berhati-hatilah jika Anda memiliki implementasi khusus).
catatan coturn (/var/log/turnserver.log) dan periksa apakah ada kesalahan otentikasi (PENGGUNA YANG SALAHJika terjadi kesalahan seperti di atas, nama pengguna/kata sandi tidak cocok.

Dengan pengaturan di atas, Anda akan memiliki server STUN/TURN/TURNS Anda sendiri yang berjalan dan akan dapat mendukung koneksi WebRTC di berbagai lingkungan jaringan.

Contoh konfigurasi server ICE untuk klien WebRTC (JavaScript)

Untuk benar-benar menggunakan server STUN/TURN yang baru saja kita buat di aplikasi WebRTC (browser),Pengaturan Server ICEDalam API WebRTC JavaScript,Koneksi RTCPeerAnda dapat menentukan daftar server STUN/TURN saat membuat file . Di bawah ini, kami akan menunjukkan contoh kode konkret yang menentukan semua server STUN/TURN/TURN dan menjelaskan artinya.

Pertama, buat objek konfigurasi untuk server ICE.turn.example.com(Ganti sebagaimana mestinya) STUN tidak memerlukan autentikasi, jadi tentukan saja URI-nya, tetapi TURN/TURNS memerlukan autentikasi, jadi tentukan juga nama pengguna dan kata sandinya.

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

Di atasserver esSusunan tersebut memiliki tiga entri.

TERKEJUT: setrum:putar.contoh.com:3478
Menentukan alamat server STUN Anda sendiri (jika nomor port dihilangkan, 3478 akan digunakan). STUN digunakan untuk menentukan traversal NAT dan mendapatkan kandidat. Peramban akan terlebih dahulu meminta server ini melalui UDP untuk mendapatkan kandidat Server Reflexive.
BELOK (UDP): putar:putar.contoh.com:443?transportasi=udp
Server TURN Anda sendiriPort UDP 443Ini adalah pengaturan yang akan digunakan. Nama pengguna yang ditetapkan di coturn sebelumnya sebagai informasi autentikasi.pengguna webrtcuserdan kata sandisecretpass123Parameter kueri telah ditetapkan.?transportasi=udpDengan menambahkan ini, koneksi TURN akan dicoba melalui UDP (jika tidak ditentukan, peramban akan mencoba UDP terlebih dahulu, dan jika gagal, akan mencoba TCP juga). Dengan pengaturan ini, meskipun koneksi langsung melalui STUN normal gagal, Anda akan memiliki kandidat untuk relai TURN pada port UDP 443.
TURN (TLS/TCP): putaran:putar.contoh.com:443
PUTAR dengan TLS, yaitu pengaturan server TURNS. Nama pengguna dan kata sandi juga ditentukan di sini. Peramban akan membuat koneksi TLS ke entri ini pada port TCP 443 untuk mendapatkan kandidat relai TURN. Ini adalah kandidat relai pilihan terakhir, dan meskipun komunikasi melalui UDP tidak memungkinkan sama sekali, ada peluang untuk membangun komunikasi jika kandidat ini tersedia.

Koneksi RTCPeerSetelah agen ICE menghasilkan srflx, agen tersebut mencoba terhubung ke server ICE yang ditentukan untuk mengumpulkan kandidat. Agen ICE pertama-tama mendapatkan kandidat STUN (srflx), kemudian mendapatkan kandidat TURN (relai) secara paralel. Algoritme ICE kemudian menggabungkan kandidat-kandidat ini, melakukan pemeriksaan koneksi, dan memilih rute optimal. Pengembang tidak perlu terlalu memahami prosedur lebih lanjut.

titik: Seperti yang disebutkan di atasSiapkan beberapa kandidatpenting. Misalnya,setrum:Jika Anda hanya menentukan TURN (UDP), tidak akan ada kandidat yang ditemukan di lingkungan yang memblokir UDP, dan koneksi akan gagal. Demikian pula, jika Anda hanya menentukan TURN (UDP), koneksi akan gagal di lingkungan yang hanya mengizinkan TCP. Oleh karena itu, jika memungkinkan,berbelok:danberubah:Dengan menyertakan keduanya di server ICE, redundansi tercapai sehingga setidaknya satu kandidat valid dapat ditemukan di lingkungan apa pun (tentu saja, server TURN juga harus mendukung UDP dan TCP/TLS). Klien (peramban) akan secara otomatis memilih jalur yang tersedia, sehingga urutan daftar bukan masalah besar. Jika saya harus mengatakan,Kebijakan Transportasi EsdarimenyampaikanKecuali Anda menentukan ini, peramban akan memprioritaskan koneksi langsung, jadi jika Anda memasukkan entri STUN, Anda akan terhindar dari penggunaan server TURN yang tidak perlu. Selain itu, jika Anda memasukkan server yang tidak relevan (seperti alamat yang tidak ada) dalam daftar server ICE, ada kemungkinan penundaan karena menunggu batas waktu, jadi sebaiknya hanya masukkan server yang Anda yakini tersedia.

Terakhir, jalankan aplikasi WebRTC dengan pengaturan ini diterapkan dan verifikasi status koneksi.koneksi rekan.getStats()atauchrome://webrtc-internalsAnda dapat memeriksa Kandidat ICE dan status koneksi di Chrome. Jika berfungsi seperti yang diharapkan, koneksi akan otomatis kembali ke koneksi langsung (P2P) di lingkungan yang menyediakan UDP, dan ke koneksi melalui TURN/TLS di lingkungan yang sulit.

Perbedaan antara SFU dan TURN

Relai WebRTC secara umum dapat dibagi menjadi "TURN" dan "SFU", tetapi peran, konfigurasi, dan penggunaannya sangat berbeda. Di sini, kami akan menjelaskan perbedaan teknisnya.

TURN: Relay sebagai alternatif peer-to-peer

TURN (Traversal Menggunakan Relay di Sekitar NAT) adalah server relai tambahan yang digunakan di lingkungan yang tidak memungkinkan komunikasi WebRTC P2P. Server TURN bertindak sebagai relai antar-peer, merelai paket terutama ketika STUN tidak berfungsi karena NAT atau firewall. Karena setiap peer mengirimkan aliran secara individual ke mitra komunikasinya masing-masing, konfigurasinya pada dasarnya adalah mesh, dan TURN diposisikan sebagai "pinch hitter".

komposisi:Setiap pengguna saling mengirim melalui relay (secara efektif berupa mesh)
Skalabilitas: Rendah (semakin banyak orang, semakin besar bebannya)
Konten siaran: Hanya transfer paket sederhana, tidak ada analisis atau pengoptimalan media

SFU: Relai efisien untuk panggilan multi-pihak

SFU (Selective Forwarding Unit) adalah server relai cerdas yang digunakan dalam konferensi web multi-peserta.Setiap klien mengirimkan satu aliran ke SFU, yang secara selektif meneruskannya ke peserta lain.Ia juga melakukan deteksi pembicara, penyesuaian kualitas gambar, dan pengoptimalan latensi, yang memungkinkan penyiaran berskala dan berkinerja tinggi.

komposisi: Tipe bintang di mana setiap klien terhubung ke satu SFU
Skalabilitas:Mahal (hanya satu transmisi meskipun jumlah orang bertambah)
Konten siaran:Kontrol tujuan transfer dan optimasi media dimungkinkan

Bagan perbandingan TURN vs SFU

Fitur	BERBELOK	SFU
Tujuan	Alternatif ketika traversal NAT tidak memungkinkan	Komunikasi multi-orang secara real-time
Konfigurasi Komunikasi	Mesh (saling mengirimkan)	Tipe bintang (transmisi tunggal)
Fungsi relai	Relai sederhana (transparan)	Penerusan dan pengoptimalan selektif tersedia
Skalabilitas	rendah	mahal
Kontrol Media	tidak ada	Ya (misalnya deteksi speaker, penyesuaian resolusi)

TURN hanyalah "pilihan terakhir ketika komunikasi P2P tidak memungkinkan," dan merupakan relai yang melengkapi jaringan P2P.SFU adalah arsitektur relai yang dirancang agar efisien sejak awal untuk panggilan multi-pihak.Karena peran keduanya pada dasarnya berbeda, penting untuk merancangnya tanpa membingungkan keduanya.

ringkasan

Artikel ini memberikan penjelasan terperinci bagi pengguna WebRTC tingkat menengah hingga mahir tentang perbedaan teknis antara STUN, TURN, dan TURNS, serta contoh cara membangun server menggunakan coturn dan bagaimana ICE berperilaku di lingkungan jaringan yang keras.

TERKEJUTringan dan memungkinkan komunikasi langsung di lingkungan NAT,BERBELOKmenyediakan jalur komunikasi dalam situasi sulit, danBERPUTARDengan menggabungkan semuanya, ini membuka jalan bagi WebRTC untuk digunakan dalam lingkungan khusus seperti dalam sebuah perusahaan.

Masing-masing memiliki kelebihan dan kekurangannya sendiri, jadi idealnya Anda harus terhubung langsung dengan STUN bila memungkinkan, dan hanya menggunakan relai TURN bila benar-benar diperlukan. Dalam pengembangan aplikasi WebRTC yang sebenarnya, dengan menyiapkan beberapa rute dalam konfigurasi server ICE seperti yang diperkenalkan di sini, dan dengan mengonfigurasi dan mengoperasikan coturn dengan benar di sisi server, Anda dapat menyediakan komunikasi waktu nyata yang stabil di berbagai lingkungan jaringan.

WebRTC adalah bidang kompleks yang menggabungkan API browser dan teknologi jaringan, tetapi memahami cara kerja STUN/TURN dan ICE sangat penting untuk menciptakan aplikasi yang andal.

Kami harap Anda mempertimbangkan informasi dalam artikel ini dan mencoba mengatasi tantangan traversal NAT pada produk Anda sendiri. Dengan demikian, pengguna akan dapat menikmati komunikasi yang lancar tanpa menyadarinya berkat pemrosesan koneksi yang dirancang dengan cermat dan dilakukan di balik layar.

URLをコピーしました！