Penjelasan mendalam dan aplikasi praktis dari STUN/TURN/TURNS/SFU dalam 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 browser. Teknologi ini sedang distandarisasi oleh perusahaan seperti Google, karena memungkinkan komunikasi P2P hanya menggunakan API JavaScript, tanpa memerlukan plugin atau perangkat lunak tambahan.

WebRTC terdiri dari tiga komponen utama berikut:

getUser MediaAPI yang memperoleh audio dan video dari perangkat seperti kamera dan mikrofon.
Koneksi Rekan RTC: Sebuah API inti yang membangun komunikasi antar pihak dan bertukar media serta data.
Saluran Data RTCSaluran data yang dapat digunakan untuk transfer file, obrolan, dan banyak lagi.

API ini memungkinkan pengembangan banyak aplikasi waktu nyata, seperti panggilan video, konferensi audio, dan berbagi file. Namun, komunikasi di dunia nyata melibatkan penembusan NAT dan masalah firewall, sehingga pemahaman dan implementasi teknologi penembusan NAT seperti STUN/TURN/TURNS menjadi sangat penting.

Perbedaan dan peran STUN, TURN, dan TURNS

Untuk mencapai konektivitas peer-to-peer yang stabil dengan WebRTC, mekanisme traversal NAT sangat penting. Di sini, kami akan menjelaskan secara detail perbedaan teknis, skenario penggunaan, kelebihan, dan kekurangan STUN, TURN, dan TURNS, yang merupakan teknologi representatif.

STUN pada dasarnya adalah protokol yang digunakan untuk menentukan alamat eksternal seseorang dalam lingkungan NAT, sedangkan TURN adalah protokol yang berfungsi sebagai server relai ketika koneksi langsung tidak memungkinkan. Di sisi lain, TURNS mengenkripsi komunikasi TURN menggunakan TLS dan menggunakan port 443 yang sama dengan HTTPS, memungkinkan komunikasi di bawah firewall ketat seperti yang ditemukan di jaringan perusahaan.

Dengan memahami karakteristik setiap metode dan menggunakannya dengan tepat, Anda dapat meningkatkan tingkat keberhasilan dan kualitas komunikasi WebRTC.

Peran dan karakteristik STUN (UDP)

STUN (Session Traversal Utilities for NAT) adalah sebuah klien.Alamat IP eksternal dan portIni adalah protokol sederhana untuk mengetahui alamat IP Anda. Misalnya, jika PC Anda berada di belakang NAT, PC tersebut tidak mengetahui alamat IP globalnya sendiri, tetapi dapat memperoleh "alamat IP dan port seperti yang terlihat dari luar" dengan melakukan kueri ke server STUN.

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

Komunikasi STUN biasanya menggunakan UDP, dengan port default 3478 (UDP/3478). Karena hanya membutuhkan komunikasi UDP yang ringan dan sekali jalan, ia memiliki overhead dan latensi rendah, serta hampir tidak membebani server. Oleh karena itu, di lingkungan di mana komunikasi UDP diizinkan, STUN adalah metode pertama yang dicoba untuk melewati NAT.

Adegan Penggunaan STUN

STUN efektif di lingkungan di mana traversal NAT diperlukan tetapi komunikasi UDP itu sendiri tidak diblokir, seperti jaringan rumah dan koneksi seluler. Jika klien dapat memperoleh alamat IP dan port eksternal satu sama lain menggunakan STUN, mereka dapat membangun komunikasi langsung (peer-to-peer). Karena jalur komunikasinya langsung, latensi rendah dan kualitas dapat dipertahankan pada tingkat tinggi. Selain itu, karena server hanya membantu dalam pertukaran informasi IP, biaya dapat ditekan sangat rendah. Misalnya, dalam game online atau panggilan video, jika kedua perangkat berada di NAT yang relatif terbuka, STUN sudah cukup untuk koneksi peer-to-peer.

Keterbatasan dan kekurangan STUN

STUN hanyalah sarana untuk "menemukan alamat eksternal Anda sendiri," dan tergantung pada jenis NAT dan batasan firewall, mungkin tidak memungkinkan untuk membangun koneksi hanya menggunakan STUN. Secara khusus, dalam lingkungan NAT simetris atau firewall yang ketat, paket dari pihak lain mungkin tidak mencapai alamat yang diperoleh melalui STUN, sehingga komunikasi menjadi tidak mungkin.

Selain itu, di beberapa jaringan perusahaan, komunikasi UDP itu sendiri mungkin diblokir, dalam hal ini permintaan STUN tidak akan terkirim. Singkatnya, STUN adalah mekanisme untuk "menentukan apakah komunikasi langsung dimungkinkan," dan tidak berfungsi di lingkungan di mana komunikasi langsung secara fisik tidak mungkin. Oleh karena itu, STUN digunakan pada tahap pertama akuisisi kandidat di ICE (dijelaskan kemudian), dan jika STUN tidak mencukupi, ia dirancang untuk beralih ke TURN, yang akan dijelaskan kemudian.

Peran dan karakteristik TURN (UDP)

TURN (Traversal Using Relays around NAT) adalah protokol yang bertindak sebagai relay ketika komunikasi langsung melalui STUN tidak memungkinkan. Server TURN bertindak sebagai titik relay yang dapat diakses secara global, bertindak sebagai perantara antara klien dan mitra komunikasi untuk meneruskan paket. Klien terhubung ke server TURN dan memperoleh alamat IP dan port relay yang disebut kandidat relay. Sejak saat itu, media dan data dipertukarkan dengan pihak lain melalui server TURN tersebut.

TURN biasanya juga berkomunikasi menggunakan UDP, jadi selama UDP tersedia, ia dapat meneruskan paket media dengan cara yang sangat mirip dengan komunikasi langsung. Secara default, ia menerima protokol TURN pada port 3478 (UDP), sama seperti STUN. Bahkan jika nomor port UDP dibatasi oleh kebijakan firewall, TURN masih dapat berjalan pada port yang diizinkan, seperti UDP/443. Selama UDP tersedia, ia dapat memberikan penerusan waktu nyata yang lebih baik daripada TCP.

Skenario penggunaan TURN

TURN sangat penting ketika koneksi langsung dengan pihak lain tidak dapat terjalin. Misalnya,Hal ini dapat terjadi ketika salah satu atau kedua pihak berada di balik firewall ketat perusahaan, atau ketika upaya pemblokiran UDP gagal antara NAT simetris.Dalam lingkungan seperti itu, komunikasi tidak mungkin dilakukan tanpa melalui server TURN, sehingga TURN bertindak sebagai garis pertahanan terakhir.

WebRTC bertujuan agar semua pihak dapat berkomunikasi secara langsung, tetapi jika hal ini tidak memungkinkan, komunikasi dapat berlanjut dengan beralih ke TURN. Dalam pengoperasian sebenarnya, strategi umum adalah pertama-tama mencoba koneksi langsung dengan STUN, dan hanya beralih ke relay TURN jika itu gagal. Misalnya, dalam konferensi video melalui jaringan perusahaan, jika pihak-pihak tidak dapat berkomunikasi secara langsung, komunikasi secara otomatis beralih melalui server TURN, memungkinkan pengguna untuk melanjutkan percakapan tanpa menyadarinya.

Manfaat TURN

Keunggulan terbesarnya adalah keandalan. Dalam lingkungan NAT atau firewall apa pun, selama komunikasi dapat terjalin dari klien ke server TURN, komunikasi peer-to-peer pada akhirnya dapat dicapai. Selain itu, karena TURN merupakan perluasan dari protokol STUN, implementasi server tunggal (seperti coturn, yang akan dibahas nanti) dapat menangani permintaan STUN dan TURN. Setelah koneksi terjalin, media selanjutnya diteruskan sebagai aliran data, sehingga dari perspektif pengguna, komunikasi berjalan lancar dengan hanya sedikit penundaan.

Kekurangan TURN

Kelemahan terbesarnya adalah konsumsi sumber daya dan latensi. Dengan TURN, semua data audio dan video melewati server, yang membutuhkan bandwidth dan daya pemrosesan yang signifikan di sisi server. Misalnya, dengan asumsi panggilan video satu lawan satu mengkonsumsi bandwidth 1 Mbps dalam satu arah, perhitungan sederhana menunjukkan bahwa 1000 pengguna simultan akan membutuhkan bandwidth relay sebesar 1 Gbps. Oleh karena itu, biaya operasional server TURN tinggi, dan layanan skala besar membutuhkan banyak server relay TURN untuk dapat diskalakan.

Selain itu, jalur komunikasi yang lebih panjang meningkatkan latensi, yang menyebabkan jeda waktu dan penurunan kualitas video dan audio. Di samping itu, TURN tidak sepenuhnya peer-to-peer dibandingkan dengan STUN, sehingga sedikit kurang aman (meskipun server TURN biasanya hanya meneruskan RTP/datagram yang tidak terenkripsi dan tidak menginterpretasikan isinya).

Secara umum, TURN sebaiknya hanya digunakan bila diperlukan. Bahkan, banyak komunikasi WebRTC dapat dihubungkan langsung menggunakan STUN, dan statistik Google melaporkan bahwa sekitar 861 panggilan TP3T diselesaikan tanpa perantara (peer-to-peer). Hanya sekitar 141 kasus TP3T yang tersisa yang memerlukan TURN, dan penting untuk menyiapkan infrastruktur TURN untuk 141 kasus TP3T tersebut.

Peran dan karakteristik TURNS (TLS melalui TCP/443)

TURNS adalah singkatan dari "TURN over TLS," yang merupakan metode enkripsi komunikasi relay menggunakan protokol TURN dengan TLS (Transport Layer Security).Komunikasi TURN dilindungi oleh TLS (HTTPS)Layanan ini sering kali diakses melalui port TCP 443.Karena port 443 sama dengan nomor port HTTPS, maka lebih mudah untuk melewati firewall perusahaan, yang merupakan keuntungan karena memudahkan untuk melewati proxy dan sensor.。

Sebagai contoh, dalam jaringan perusahaan, hanya port 80 dan 443 yang diizinkan untuk komunikasi eksternal. Bahkan dalam kasus seperti itu, server TURN yang menggunakan komunikasi TLS pada port 443 kemungkinan besar dapat melewati koneksi. Selain itu, karena dienkripsi menggunakan TLS, isi komunikasi lebih kecil kemungkinannya untuk dicegat oleh pihak ketiga dan lebih aman.

Dalam WebRTC, pengaturannya""url": "turns:turnserver:443""Seperti pada skema URIgiliran:Dengan menentukan opsi ini, Anda dapat menggunakan server TURN yang dienkripsi TLS ini.

Skenario penggunaan TURNS

Dalam komunikasi WebRTC di bawah batasan ketat, seperti di dalam jaringan perusahaan, TURNS berguna ketika semua metode lain diblokir. Bahkan di lingkungan di mana semua port UDP dan TCP umum diblokir, banyak kebijakan mengizinkan komunikasi jika diperlakukan sama seperti komunikasi HTTPS, menjadikan TURN pada port TLS 443 sebagai pilihan terakhir yang praktis.

Ini juga digunakan dalam situasi di mana port tertentu ditutup pada jaringan Wi-Fi publik, atau ketika sisi klien hanya dapat melakukan komunikasi TLS. Singkatnya,Pertama, coba UDP, lalu TCP jika itu tidak berhasil, dan jika itu juga gagal, coba TLS pada port 443.Ini diposisikan sebagai tahap akhir dari proses penggantian bertahap.

Manfaat TURNS

Keunggulan terbesarnya adalah ketahanan firewall yang tinggi. Komunikasi terenkripsi TLS sulit dibedakan dari HTTPS umum, sehingga meningkatkan kemungkinan lolos bahkan dari filter yang ketat. Terutama saat mengimplementasikan sistem konferensi web di perusahaan, perlu untuk mengizinkan koneksi dari jaringan internal ke luar, dan komunikasi TCP/443 TLS lebih mudah diterima dari perspektif kebijakan keamanan. Selain itu, karena terenkripsi, kerahasiaan komunikasi ke server relai itu sendiri terjamin (namun, konten itu sendiri, seperti video, seringkali sudah dienkripsi pada lapisan WebRTC).

Kekurangan TURNS

Kelemahan terbesarnya adalah penurunan performa. Selain penundaan dan beban dari TURN itu sendiri, ada juga beban tambahan dari TLS dan TCP. TCP memiliki mekanisme pengiriman ulang yang berfungsi ketika paket hilang untuk transportasi yang andal, tetapi tidak cocok untuk media waktu nyata, dan jika terjadi kehilangan, video dan audio mungkin tidak dapat diputar dengan lancar.

Selain itu, TCP rentan terhadap pemblokiran antrean (head-of-line blocking) karena kontrol urutan paket.Dibandingkan dengan UDP, jitter (fluktuasi) juga meningkat.Selain itu, beban CPU dari pemrosesan enkripsi dan dekripsi TLS juga bertambah. Akibatnya, dilaporkan bahwa terjadi penundaan tambahan sebesar 50ms atau lebih dalam pengukuran aktual, yang menyebabkan kelambatan yang terasa bagi pengguna. Secara khusus, dalam konferensi video, penundaan yang meningkat ini dapat mengganggu kecepatan percakapan dan membuat perbedaan waktu menjadi lebih kentara.

Dengan demikian, meskipun TURNS dapat dianggap sebagai "jalan terakhir" dalam hal kualitas, TURNS juga merupakan jalur penyelamat yang andal dalam situasi di mana tidak ada pilihan lain selain memastikan komunikasi terjalin.

Dalam beberapa tahun terakhir, pendekatan baru (TURN over QUIC) telah dipertimbangkan yang beroperasi pada port UDP 443 dan menggunakan DTLS/QUIC sebagai pengganti TLS, tetapi masih dalam tahap standardisasi dan belum umum digunakan.

Alur komunikasi ketika UDP STUN tidak tersedia

Artikel ini menjelaskan, langkah demi langkah, bagaimana pemrosesan WebRTC ICE berlangsung ketika STUN melalui UDP tidak tersedia. Kita akan meneliti bagaimana negosiasi ICE beralih ke skenario di mana UDP sepenuhnya diblokir, seperti pada jaringan perusahaan.

Klien mengirimkan permintaan IP eksternal (UDP/3478) ke server STUN:
Klien WebRTC (peramban)Server esPermintaan Pengikatan (permintaan untuk memverifikasi alamat eksternal) dikirim melalui port UDP 3478 ke server STUN yang ditentukan. Ini adalah tahap pertama pengumpulan kandidat ICE, dan jika berhasil, server akan mengembalikan alamat IP global dan nomor port-nya sendiri, dan ditambahkan ke daftar kandidat sebagai Kandidat Refleksif Server (kandidat srflx).
Paket UDP diblokir oleh firewall dan tidak ada respons yang diterima.
Dalam kasus ini, komunikasi UDP tidak dapat mencapai luar karena pengaturan firewall jaringan. Oleh karena itu, permintaan ke server STUN tidak sampai ke server, atau respons tidak dikembalikan ke klien. Akibatnya, klienTidak dapat menerima respons STUN.Oleh karena itu, alamat IP eksternal tidak dapat ditentukan. Agen ICE menunggu respons selama periode waktu tertentu, tetapi kemudian mengalami batas waktu (timeout). Dari perspektif pengguna, proses koneksi masih berlangsung pada titik ini dan tidak ada pesan kesalahan yang ditampilkan, tetapi pada kenyataannya...Pengumpulan kandidat gagalSedang dalam proses.
Pemeriksaan koneksi langsung ICE gagal karena tidak ditemukan kandidat Server Reflexive:
Biasanya, jika STUN berhasil, klien akan memiliki kandidat host (alamat IP lokalnya) serta kandidat refleksif server (alamat IP globalnya), dan akan melakukan pengecekan koneksi dengan menggabungkannya dengan kandidat serupa pada pihak lawan. Namun, jika STUN gagal dan tidak ada kandidat IP global,Jumlah kandidat untuk koneksi langsung antar individu sangat terbatas.Hal ini bisa terjadi. Misalnya, jika kedua pihak hanya memiliki alamat IP pribadi, mereka tidak akan dapat terhubung satu sama lain. Akibatnya, ICE akan menentukan bahwa "koneksi langsung tidak dimungkinkan." Jika server ICE (TURN) tidak dikonfigurasi, seluruh ICE akan dianggap gagal pada tahap ini, dan koneksi WebRTC tidak akan terjalin (konsol pengembang akan menampilkan...).ICE gagalやStatus koneksi ICE: gagalKesalahan seperti berikut akan ditampilkan.
Mencoba mendapatkan kandidat relay TURN (melalui TCP/TLS/443):
Sekalipun STUN gagal mendapatkan kandidat secara langsung,Server esJika server TURN ditentukan, agen ICE akanSelanjutnya berartiMari kita lanjutkan. Dalam skenario ini, UDP tidak berfungsi, jadi klien akan mencoba terhubung ke server TURN menggunakan TCP atau TLS (misalnya).turns:turn.example.com:443Jika dikonfigurasi, proses jabat tangan TLS akan dimulai. Untungnya, firewall mengizinkan komunikasi HTTPS pada TCP 443, sehingga koneksi TLS TURN berhasil. Klien mengamankan alamat relay pada server TURN untuk penerusan,Kandidat EstafetKandidat relai diperoleh. Ini adalah "tujuan kandidat virtual untuk komunikasi melalui server TURN." Di sisi lain, mitra komunikasi (sisi jarak jauh) juga akan memperoleh kandidat relai, atau jika jaringannya baik, ia akan memiliki kandidat langsung atau kandidat STUN sejak awal. Dalam hal apa pun, jika setidaknya satu sisi memiliki kandidat relai, sisi lain dapat mencoba untuk terhubung ke server TURN tersebut.
Pembentukan koneksi ICE (atau kegagalan akhir) melalui relay:
Setelah kedua pihak memperoleh kandidat relay yang tersedia (dalam contoh ini, kandidat relay untuk satu atau keduanya), ICE menggunakannya untuk melakukan pengecekan koneksi. Karena komunikasi melalui server TURN dapat diteruskan setelah kesepakatan dibuat dengan server, saluran media dibuka meskipun lalu lintas UDP langsung tidak dapat melewati antar pihak. Hal ini memungkinkan pengguna untuk memulai komunikasi video dan audio. Setelah koneksi terjalin, meskipun ada overhead karena TCP melalui TLS, percakapan itu sendiri menjadi mungkin. Sebaliknya, jika ini juga gagal (misalnya, jika proxy perusahaan mendeteksi dan memblokir komunikasi TLS non-HTTP, atau jika otentikasi dengan server TURN gagal), sayangnya, ICE gagal secara keseluruhan dan koneksi dihentikan. Aplikasi harus mendeteksi situasi ini dan memberi tahu pengguna dengan pesan seperti "Koneksi tidak dapat dibuat."

Uraian di atas menjelaskan proses negosiasi ICE dalam lingkungan yang menantang di mana UDP tidak tersedia. Singkatnya, sistem mencoba kandidat dalam urutan "host → STUN → TURN," dan jika tidak ada yang berhasil, koneksi gagal. Penting bagi pengembang untuk memahami perilaku ini dan, setidaknya, menyertakan server TURN/TURNS dalam daftar server ICE untuk memastikan bahwa komunikasi dapat terjalin bahkan dalam skenario terburuk. Lebih lanjut, ketika menerima pertanyaan dari pengguna, diperlukan pemecahan masalah, seperti menyimpulkan masalah lingkungan jaringan (misalnya, pemblokiran UDP) dari informasi seperti "ICE gagal," dan memeriksa pengaturan server TURN yang hilang.

Membangun dan mengkonfigurasi server STUN/TURN/TURNS menggunakan coturn.

Jika Anda menyiapkan server STUN/TURN sendiri, gunakan implementasi sumber terbuka. coturnUmumnya digunakan (Coturn). Coturn adalah implementasi server yang mendukung STUN dan TURN, dan juga dapat mendukung TURNS (TLS) tergantung pada konfigurasinya. Di sini, kami akan menjelaskan prosedur dan poin konfigurasi untuk menginstal Coturn pada server Linux dan membangun server yang menyediakan STUN/TURN/TURNS. Selain itu, file konfigurasi tipikal (turnserver.confSaya juga akan menunjukkan contohnya.

Instalasi dan pengaturan dasar

memasang

Dalam kasus Ubuntu atau Debian,tepatAnda dapat menginstal paket coturn dari sini. Misalnya, Anda dapat menginstal dan mengkonfigurasinya agar berjalan otomatis dengan perintah berikut.

# 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

Perintah di atas akan menjalankan server coturn sebagai daemon. Secara default, file konfigurasi /etc/turnserver.conf Sekarang kita akan memuat file tersebut, lalu melanjutkan untuk mengeditnya (pastikan untuk membuat cadangan sebelum mengedit).

Pengaturan dasar

turnserver.confSekarang, mari kita siapkan item-item berikut.

Realm dan nama server: Ini adalah nama domain atau pengidentifikasi server TURN. Ini dapat digunakan selama otentikasi klien WebRTC, tetapi secara umum, string apa pun dapat diterima. Contoh: ranah=contoh.com，nama-server=contoh.com。
port pendengar: Ini adalah nomor port UDP yang digunakan oleh TURN dan STUN untuk mendengarkan. Port default-nya adalah 3478.mendengarkan-ipAnda juga dapat mengikat ke NIC tertentu, tetapi biasanya0.0.0.0Kami menerima semua pertanyaan.
port mendengarkan tls: Ini adalah nomor port TCP yang digunakan untuk mendengarkan TLS (TURNS). Umumnya, port 443 atau 5349 yang ditentukan. Contoh: port mendengarkan tls=443。
auto-ip: Jika server itu sendiri berada di belakang NAT, tentukan alamat IP globalnya sendiri (ini memungkinkan server untuk mengenali pemetaan antara alamat IP internal dan eksternal). Ini tidak diperlukan untuk server yang memiliki alamat IP global langsung.
Metode otentikasi: Protokol TURN WebRTC menggunakan otentikasi jangka panjang (Long-Term Credentials),lt-cred-mechAktifkan Mekanisme Kredensial Jangka Panjang.pengguna=nama pengguna:kata sandiAtur nama pengguna dan kata sandi Anda dalam format berikut:gunakan rahasia otentikasiAutentikasi dinamis dilakukan menggunakan (yang terakhir adalah autentikasi berbasis token, yang efektif untuk meningkatkan keamanan, tetapi di sini kita akan menggunakan autentikasi pengguna statis sederhana sebagai contoh).
Pengaturan log: Untuk pemecahan masalahberkas logKemudian, jalur file log ditentukan.GeorgeAnda harus mengaktifkan pencatatan log terperinci.

Pengaturan firewall

Di sisi server, untuk STUN/TURNPort UDP 3478, dan untuk TURN/TLSPort TCP 443Anda perlu membuka port (atau 5349). Selain itu, karena TURN relay menggunakan port UDP 10000-20000 secara default, Anda juga perlu membuka rentang port ini di server (jika diperlukan).pelabuhan kecilとport maksimum(Rentang dapat diubah.)

Berikut ini mencerminkan pengaturan dasar yang disebutkan di atas./etc/turnserver.confBerikut contohnya.

# 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 domain di atas,contoh.comSaya telah memperoleh sertifikat Let's Encrypt dan menggunakannya untuk konfigurasi TLS.lt-cred-mechAktifkan otentikasi jangka panjang,penggunaIni mengatur otentikasi nama pengguna dan kata sandi yang sederhana. Dalam pengoperasian sebenarnya...gunakan rahasia otentikasiとrahasia otentikasi statisMeskipun disarankan untuk menggunakan metode berbasis token untuk menerbitkan kredensial sementara, kami akan mengabaikan penjelasan tersebut 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 menggunakanturnserverKarena dieksekusi oleh pengguna, port 443 tidak dapat diikat begitu saja. Sebagai solusi alternatif,/etc/default/coturnUbah pengguna eksekusi menjadi root,setcapMemerintahturnserverfile yang dapat dieksekusilayanan_ikat_jaringan_capAda beberapa cara untuk memberikan izin. Misalnya, dalam kasus terakhir,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverMenjalankan perintah ini akan memungkinkan pengguna non-root untuk terhubung ke port bernomor rendah. Selain itu, tentukan jalur yang benar untuk file sertifikat (cert/pkey) dan atur izin file agar pengguna coturn dapat membacanya. Setelah mengubah pengaturan...sudo systemctl restart coturnMulai ulang layanan dan periksa log untuk mencari kesalahan.

Pemeriksaan operasional

Setelah server Coturn dijalankan, kita akan melakukan pengujian menggunakan klien STUN untuk memverifikasi operasinya, dan kemudian mencoba membuat koneksi ICE dari aplikasi WebRTC di browser.klien setrummemerintah(apt-get install stun-client(Dapat diimplementasikan dengan)stunclient <IP server> 3478Menjalankannya seperti ini akan memungkinkan Anda untuk menguji apakah Anda dapat memperoleh alamat IP eksternal Anda. Selain itu, di browser, kandidat ICE akan tercantum dalam log alat pengembang.srflx(Refleksif Server) kandidat danmenyampaikanSilakan periksa apakah Anda telah mendapatkan kandidat tersebut. Jika tidak berhasil, lakukan pemecahan masalah pada poin-poin berikut.

Periksa apakah port yang diperlukan sudah terbuka di pengaturan firewall server (iptables atau grup keamanan cloud).
Periksa apakah URI, port, dan informasi otentikasi yang benar telah dikonfigurasi dalam pengaturan server ICE sisi klien (akan dijelaskan nanti).
turnserver.confのduniaPastikan pengaturan sesuai dengan autentikasi klien (ini biasanya bukan masalah pada WebRTC berbasis browser karena secara otomatis menetapkan realm, tetapi berhati-hatilah dengan implementasi kustom).
coturn log (/var/log/turnserver.log) Periksa apakah ada kesalahan otentikasi (PENGGUNA YANG SALAHKesalahan seperti di atas menunjukkan ketidakcocokan antara nama pengguna dan kata sandi.

Jika pengaturan di atas sudah benar, server STUN/TURN/TURNS Anda sendiri akan berjalan, memungkinkan koneksi WebRTC di berbagai lingkungan jaringan.

Contoh konfigurasi server ICE di klien WebRTC (JavaScript)

Agar dapat menggunakan server STUN/TURN yang baru saja kita buat di sisi aplikasi WebRTC (browser),Konfigurasi Server ICEIni sudah selesai. Dalam API WebRTC JavaScript,Koneksi Rekan RTCSaat membuat konfigurasi, Anda dapat menentukan daftar server STUN/TURN. Selanjutnya, kami akan menunjukkan contoh kode konkret yang menentukan semua server STUN/TURN/TURNS dan menjelaskan artinya.

Pertama, buat objek konfigurasi untuk server ICE. Gunakan nama domain server Anda.putar.contoh.com(Ganti sesuai kebutuhan) STUN tidak memerlukan otentikasi, jadi hanya URI yang ditentukan, sedangkan TURN/TURNS memerlukan otentikasi, sehingga nama pengguna dan kata sandi juga ditentukan.

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

Yang di atasServer esLarik tersebut memiliki tiga entri yang ditentukan.

KEJUTAN: setrum:turn.example.com:3478
Ini menentukan alamat server STUN Anda sendiri (jika port dihilangkan, 3478 akan digunakan). STUN digunakan untuk deteksi traversal NAT dan pengambilan kandidat, dan browser pertama-tama mencoba untuk menanyakan server ini melalui UDP untuk mendapatkan kandidat Server Reflexive.
TURN (UDP): putar:putar.example.com:443?transport=udp
Server TURN saya sendiriPort UDP 443Ini adalah pengaturan yang akan digunakan. Informasi otentikasi adalah nama pengguna yang Anda atur di coturn sebelumnya.webrtcuserdan kata sandisecretpass123Ini menentukan parameter kueri.?transport=udpDengan menambahkan opsi ini, sistem akan mencoba koneksi TURN menggunakan UDP (jika tidak ditentukan, browser akan mencoba UDP terlebih dahulu, dan jika gagal, browser juga akan mencoba TCP). Pengaturan ini memastikan bahwa meskipun koneksi langsung melalui STUN gagal, kandidat untuk relay TURN pada port UDP 443 (kandidat relay) akan ditemukan.
PUTAR (TLS/TCP): turns:turn.example.com:443
TURN menggunakan TLSIni adalah konfigurasi server TURNS. Di sini juga, nama pengguna dan kata sandi ditentukan. Browser membuat koneksi TLS ke entri ini pada port TCP 443 dan mengambil kandidat relay TURN. Ini adalah kandidat relay pilihan terakhir; bahkan jika komunikasi UDP sama sekali tidak mungkin, keberadaan kandidat ini memberikan harapan untuk membangun komunikasi.

Koneksi Rekan RTCKetika data ini dihasilkan, sistem secara berurutan mencoba terhubung ke server ICE yang ditentukan dan mengumpulkan kandidat. Agen ICE pertama-tama memperoleh kandidat STUN (srflx), dan kemudian secara bersamaan memperoleh kandidat TURN (relay). Algoritma ICE kemudian menggabungkan kandidat-kandidat ini, melakukan pengecekan koneksi, dan memilih jalur optimal. Pengembang tidak perlu mengetahui prosedur lebih lanjut.

titik: Seperti yang dijelaskan di atasSiapkan beberapa pilihan.Itu penting. Misalnya,setrum:Jika Anda hanya menentukan TURN, dalam lingkungan di mana UDP diblokir, tidak akan ditemukan kandidat dan koneksi akan gagal. Demikian pula, hanya menentukan TURN (UDP) akan gagal dalam lingkungan di mana hanya TCP yang diizinkan. Oleh karena itu, jika memungkinkan,berbelok:とgiliran:Menyertakan keduanya pada server ICE memberikan redundansi, memastikan setidaknya satu kandidat yang valid ditemukan di lingkungan mana pun (tentu saja, server TURN juga harus mendukung UDP dan TCP/TLS). Klien (browser) akan secara otomatis memilih jalur yang tersedia, sehingga urutan daftar bukanlah masalah utama. Malahan,Kebijakan Transportasi EsをmenyampaikanKecuali dinyatakan lain, browser memprioritaskan koneksi langsung, jadi menyertakan entri STUN akan mencegah penggunaan server TURN secara tidak perlu. Selain itu, menyertakan server yang tidak relevan (seperti alamat yang tidak ada) dalam daftar server ICE dapat menyebabkan penundaan karena waktu habis (timeout), jadi sebaiknya hanya menyertakan server yang benar-benar tersedia.

Terakhir, mari kita jalankan aplikasi WebRTC dengan pengaturan ini dan verifikasi status koneksinya. Gunakan alat pengembang browser Anda...peerConnection.getStats()Gunakan, atauchrome://webrtc-internals(Di Chrome) Anda dapat memeriksa Kandidat ICE dan status koneksi. Jika berfungsi seperti yang diharapkan, seharusnya secara otomatis beralih ke koneksi langsung (P2P) di lingkungan yang menyediakan UDP, dan ke koneksi TURN/TLS di lingkungan yang tidak menyediakan UDP.

Perbedaan antara SFU dan TURN

Relay WebRTC secara umum terbagi menjadi "TURN" dan "SFU," tetapi peran, konfigurasi, dan penggunaannya berbeda secara signifikan. Bagian ini merangkum perbedaan teknis di antara keduanya.

TURN: Sebuah relay sebagai alternatif untuk peer-to-peer

TURN (Traversal Using Relays around NAT) adalah server relay tambahan yang digunakan di lingkungan di mana komunikasi WebRTC P2P tidak memungkinkan. Pada dasarnya, ketika STUN tidak berfungsi karena NAT atau firewall, server TURN mencegat paket antar peer dan meneruskannya. Karena setiap peer mengirimkan alirannya secara individual ke mitra komunikasinya masing-masing, konfigurasinya masih berupa tipe mesh, dan TURN bertindak sebagai "pengganti".

komposisiSetiap pengguna mengirimkan data melalui relay ke pengguna lain (pada dasarnya jaringan mesh).
SkalabilitasRendah (beban meningkat seiring bertambahnya jumlah orang)
Konten siaranHanya dilakukan penerusan paket sederhana; tidak dilakukan analisis atau optimasi media.

SFU: Relai efisien untuk panggilan multi-orang

Selective Forwarding Unit (SFU) adalah server relai cerdas yang digunakan dalam konferensi web multi-peserta.Setiap klien mengirimkan satu aliran data ke SFU, yang kemudian secara selektif meneruskannya ke peserta lain.Perangkat ini juga dapat melakukan proses seperti deteksi pembicara, penyesuaian kualitas gambar, dan optimasi latensi, sehingga memungkinkan penyiaran yang skalabel dan berkinerja tinggi.

komposisiKonfigurasi bintang di mana setiap klien terhubung ke SFU dengan satu koneksi tunggal.
SkalabilitasTinggi (Hanya satu pesan yang dikirim meskipun jumlah orang bertambah)
Konten siaranHal ini memungkinkan kontrol atas tujuan transfer dan optimasi media.

Tabel perbandingan TURN dan SFU

Fitur	BERBELOK	SFU
Tujuan	Metode alternatif jika penerusan NAT tidak memungkinkan	Komunikasi waktu nyata dengan banyak orang
Konfigurasi komunikasi	Mesh (dikirim ke setiap penerima secara individual)	Konfigurasi bintang (transmisi tunggal)
Fungsi relai	Relai sederhana (transparan)	Transfer dan optimasi selektif tersedia.
Skalabilitas	rendah	mahal
Kontrol media	tidak ada	Ya (misalnya, deteksi pembicara, penyesuaian resolusi)

TURN hanyalah "jalan terakhir yang digunakan ketika komunikasi P2P tidak memungkinkan," dan dari segi konfigurasinya, ia merupakan relay yang melengkapi jaringan mesh P2P. Di sisi lain,SFU adalah arsitektur relai yang dirancang sejak awal agar efisien untuk panggilan multi-orang.Karena peran mereka pada dasarnya berbeda, penting untuk mendesainnya tanpa membingungkan keduanya.

ringkasan

Artikel ini memberikan penjelasan rinci tentang perbedaan teknis dan penggunaan STUN, TURN, dan TURNS untuk pengguna WebRTC tingkat menengah hingga mahir, serta cara membangun server menggunakan coturn, beserta contoh kode, dan bagaimana ICE berperilaku di lingkungan jaringan yang menantang.

SERANGMeskipun ringan, perangkat ini memungkinkan komunikasi langsung dalam lingkungan NAT.BERBELOKHal ini menjadi jalur penting untuk membangun komunikasi bahkan dalam situasi sulit.BELOKDengan menggabungkan elemen-elemen ini, WebRTC dapat dimanfaatkan bahkan di lingkungan khusus seperti di dalam sebuah perusahaan.

Setiap metode memiliki kelebihan dan kekurangannya masing-masing, jadi idealnya, Anda harus terhubung langsung menggunakan STUN jika memungkinkan dan hanya menggunakan relay TURN jika benar-benar diperlukan. Dalam pengembangan aplikasi WebRTC yang sebenarnya, dengan menyediakan beberapa jalur seperti yang dijelaskan di sini dalam pengaturan server ICE, dan dengan mengkonfigurasi dan mengoperasikan coturn dengan benar di sisi server, Anda dapat menyediakan komunikasi real-time yang stabil di berbagai lingkungan jaringan.

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

Saya mendorong Anda untuk menggunakan informasi dalam artikel ini untuk mengatasi tantangan NAT traversal di produk Anda sendiri. Dengan demikian, pengguna dapat menikmati komunikasi yang lancar tanpa menyadarinya, berkat pemrosesan koneksi yang dirancang secara cerdas yang terjadi di balik layar.

URLをコピーしました！