Cara Kerja JS: Komunikasi WebRTC dan P2P

Hari ini kami menerbitkan terjemahan bagian 18 dari serangkaian materi yang didedikasikan untuk segala sesuatu yang berkaitan dengan JavaScript. Di sini kita akan berbicara tentang teknologi WebRTC, yang bertujuan mengatur pertukaran data langsung antara aplikasi browser secara real time.

Ulasan

Apa itu WebRTC? Untuk memulainya, perlu dikatakan bahwa singkatan RTC adalah singkatan dari Real Time Communication (komunikasi dalam waktu nyata). Ini saja memberi banyak informasi tentang teknologi ini.

WebRTC menempati ceruk yang sangat penting di antara mekanisme platform web. Sebelumnya, teknologi P2P (koneksi peer-to-peer, point-to-point, peer-to-peer, peer-to-peer) yang digunakan oleh aplikasi seperti obrolan desktop memberi mereka peluang yang tidak dimiliki proyek web. WebRTC membuat perbedaan untuk teknologi web.

WebRTC, jika kita melihat teknologi ini secara umum, memungkinkan aplikasi web untuk membuat koneksi P2P, yang akan kita bahas di bawah ini. Selain itu, kami akan membahas topik-topik berikut di sini untuk menunjukkan gambaran lengkap dari struktur internal WebRTC:

• Komunikasi P2P.
• Firewall dan teknologi NAT Traversal.
• Pemberian sinyal, sesi dan protokol.
• API WebRTC

Komunikasi P2P

Misalkan dua pengguna telah meluncurkan, masing-masing di browser mereka sendiri, sebuah aplikasi yang memungkinkan Anda untuk mengatur obrolan video menggunakan WebRTC. Mereka ingin membuat koneksi P2P. Setelah keputusan dibuat, kita memerlukan mekanisme yang memungkinkan browser pengguna untuk menemukan satu sama lain dan menjalin komunikasi dengan mempertimbangkan mekanisme perlindungan informasi yang tersedia dalam sistem. Setelah membuat koneksi, pengguna akan dapat bertukar informasi multimedia secara real time.

Salah satu kesulitan utama yang terkait dengan koneksi P2P browser adalah browser pertama-tama harus saling menemukan, dan kemudian membangun koneksi jaringan berdasarkan soket untuk menyediakan transfer data dua arah. Kami menyarankan untuk mendiskusikan kesulitan yang terkait dengan pemasangan koneksi tersebut.

Ketika aplikasi web membutuhkan beberapa data atau sumber daya, aplikasi itu mengunduhnya dari server dan hanya itu. Alamat server diketahui oleh aplikasi. Jika kita berbicara, misalnya, tentang membuat obrolan P2P, yang operasinya didasarkan pada koneksi langsung peramban, alamat peramban ini tidak diketahui sebelumnya. Akibatnya, untuk membuat koneksi P2P, Anda harus menghadapi beberapa masalah.

Firewall dan Protokol Traversal NAT

Komputer biasa, sebagai suatu peraturan, tidak memiliki alamat IP eksternal statis yang ditugaskan kepadanya. Alasan untuk ini adalah bahwa komputer seperti itu biasanya terletak di belakang firewall dan perangkat NAT.

NAT adalah mekanisme yang menerjemahkan alamat IP lokal internal yang terletak di belakang firewall ke alamat IP global global. Teknologi NAT digunakan, pertama, untuk alasan keamanan, dan kedua, karena pembatasan yang diberlakukan oleh IPv4 pada jumlah alamat IP global yang tersedia. Itu sebabnya aplikasi web menggunakan WebRTC tidak boleh bergantung pada kenyataan bahwa perangkat saat ini memiliki alamat IP statis global.

Mari kita lihat cara kerja NAT. Jika Anda berada di jaringan perusahaan dan terhubung ke WiFi, komputer Anda akan diberi alamat IP yang hanya ada di belakang perangkat NAT Anda. Misalkan ini adalah alamat IP 172.0.23.4. Namun, untuk dunia luar, alamat IP Anda mungkin terlihat seperti 164.53.27.98. Akibatnya, dunia luar melihat permintaan Anda berasal dari alamat 164.53.27.98, tetapi berkat NAT, jawaban atas permintaan yang dibuat oleh komputer Anda untuk layanan eksternal akan dikirim ke alamat internal Anda 172.0.23.4. Ini terjadi menggunakan tabel terjemahan. Harap dicatat bahwa selain alamat IP, nomor port juga diperlukan untuk jaringan.

Mengingat bahwa NAT terlibat dalam proses interaksi sistem Anda dengan dunia luar, peramban Anda, untuk membangun koneksi WebRTC, perlu mengetahui alamat IP komputer tempat peramban yang ingin Anda komunikasikan jalankan.

Di sinilah server STUN (Session Traversal Utilities for NAT) dan TURN (Traversal Using Relays around NAT) memasuki server. Untuk memastikan pengoperasian teknologi WebRTC, permintaan terlebih dahulu dibuat ke server STUN, untuk mengetahui alamat IP eksternal Anda. Bahkan, kita berbicara tentang permintaan yang dibuat ke server jauh untuk mencari tahu dari alamat IP apa server menerima permintaan ini. Setelah menerima permintaan serupa, server jarak jauh akan mengirim respons yang berisi alamat IP yang terlihat.

Berdasarkan asumsi bahwa skema ini operasional dan Anda menerima informasi tentang alamat dan port IP eksternal Anda, maka Anda dapat memberi tahu peserta lain dalam sistem (kami akan memanggil mereka teman sebaya) tentang cara menghubungi Anda secara langsung. Rekan-rekan ini juga dapat melakukan hal yang sama menggunakan STUN atau MENGHIDUPKAN server dan dapat memberi tahu Anda alamat mana yang ditugaskan untuk mereka.

Pemberian sinyal, sesi dan protokol

Proses menemukan informasi jaringan, yang dijelaskan di atas, adalah salah satu bagian dari sistem pensinyalan besar, yang, dalam kasus WebRTC, didasarkan pada standar JSEP (JavaScript Session Establishment Protocol). Signaling termasuk penemuan sumber daya jaringan, pembuatan dan manajemen sesi, keamanan komunikasi, koordinasi parameter media, penanganan kesalahan.

Agar koneksi berfungsi, rekan harus menyetujui format data yang akan mereka tukarkan, dan mengumpulkan informasi tentang alamat jaringan komputer tempat aplikasi tersebut berjalan. Mekanisme pensinyalan untuk berbagi informasi penting ini bukan bagian dari API WebRTC.

Pensinyalan tidak didefinisikan oleh standar WebRTC, dan itu tidak diterapkan dalam API-nya untuk memberikan fleksibilitas dalam teknologi dan protokol yang digunakan. Pemberian sinyal dan server yang mendukungnya adalah tanggung jawab pengembang aplikasi WebRTC.

Berdasarkan asumsi bahwa aplikasi WebRTC Anda yang berjalan di browser dapat menentukan alamat IP eksternal browser menggunakan STUN, seperti dijelaskan di atas, langkah selanjutnya adalah membahas parameter sesi dan membuat koneksi dengan browser lain.

Diskusi awal parameter sesi dan pembentukan koneksi dibuat menggunakan protokol pensinyalan / komunikasi yang berspesialisasi dalam komunikasi multimedia. Protokol ini, di samping itu, bertanggung jawab untuk mematuhi aturan di mana sesi dikelola dan diakhiri.

Salah satu protokol ini disebut SIP (Session Initiation Protocol). Harap dicatat bahwa karena fleksibilitas subsistem pensinyalan WebRTC, SIP bukan satu-satunya protokol pensinyalan yang dapat digunakan. Protokol pensinyalan yang dipilih, di samping itu, harus bekerja dengan protokol lapisan aplikasi yang disebut SDP (Session Description Protocol), yang digunakan saat menggunakan WebRTC. Semua metadata yang terkait dengan data multimedia ditransmisikan menggunakan protokol SDP.

Setiap peer (yaitu, aplikasi yang menggunakan WebRTC) yang mencoba untuk menghubungi peer lain menghasilkan seperangkat rute kandidat untuk protokol ICE (Interactive Connectivity Establishment). Calon mewakili kombinasi alamat IP, port, dan protokol transport yang dapat digunakan. Harap dicatat bahwa satu komputer dapat memiliki banyak antarmuka jaringan (kabel, nirkabel, dan sebagainya), sehingga dapat ditetapkan beberapa alamat IP, satu untuk setiap antarmuka.

Berikut adalah diagram dengan MDN yang menggambarkan proses pertukaran data di atas.

Proses pertukaran data diperlukan untuk membangun koneksi P2P

Buat koneksi

Setiap rekan kerja pertama-tama mengetahui alamat IP eksternal seperti yang dijelaskan di atas. Kemudian, "saluran" data pensinyalan dibuat secara dinamis, yang berfungsi untuk mendeteksi rekan dan mendukung pertukaran data di antara mereka, untuk membahas parameter sesi dan pemasangannya.

"Saluran" ini tidak dikenal dan tidak dapat diakses oleh dunia luar, diperlukan pengenal unik untuk mengaksesnya.

Harap perhatikan bahwa karena fleksibilitas WebRTC, dan fakta bahwa proses pensinyalan tidak ditentukan oleh standar, konsep "saluran" dan urutan penggunaannya mungkin sedikit berbeda tergantung pada teknologi yang digunakan. Bahkan, beberapa protokol tidak memerlukan mekanisme "saluran" untuk mengatur pertukaran data. Kami, untuk keperluan materi ini, menganggap bahwa "saluran" dalam implementasi sistem digunakan.

Jika dua atau lebih rekan kerja terhubung ke "saluran" yang sama, rekan kerja mendapatkan kesempatan untuk bertukar data dan mendiskusikan informasi sesi. Proses ini mirip dengan template penerbit-pelanggan . Secara umum, rekan yang memulai koneksi mengirimkan "penawaran" menggunakan protokol pensinyalan seperti SIP atau SDP. Inisiator mengharapkan untuk menerima "respons" dari penerima proposal, yang terhubung ke "saluran" yang dianggap.

Setelah jawaban diterima, proses menentukan dan mendiskusikan kandidat ICE terbaik yang dikumpulkan oleh setiap pesta berlangsung. Setelah kandidat ICE optimal dipilih, parameter data yang akan dipertukarkan antara rekan-rekan dan mekanisme routing jaringan (alamat IP dan port) disepakati.

Kemudian, sesi soket jaringan aktif dibuat di antara rekan-rekan. Selanjutnya, masing-masing rekan menciptakan aliran data lokal dan titik akhir saluran data, dan transmisi dua arah data multimedia mulai menggunakan teknologi yang diterapkan.

Jika proses negosiasi untuk memilih kandidat ICE terbaik tidak berhasil, yang kadang-kadang terjadi karena kesalahan firewall dan sistem NAT, opsi cadangan digunakan, yang terdiri dalam menggunakan, sebagai relay, server TURN. Proses ini melibatkan server yang bertindak sebagai perantara yang menyampaikan data yang dipertukarkan antar rekan. Harap dicatat bahwa skema ini bukan koneksi P2P nyata di mana rekan-rekan mengirim data secara langsung satu sama lain.

Saat menggunakan fallback menggunakan TURN untuk pertukaran data, setiap rekan tidak lagi perlu tahu cara berkomunikasi dengan orang lain dan cara mentransfer data ke sana. Alih-alih, rekan perlu tahu server TURN eksternal mana yang perlu mengirim data multimedia secara real time dan dari server mana mereka perlu menerima selama sesi komunikasi.

Penting untuk dipahami bahwa sekarang ini adalah cara cadangan untuk mengatur komunikasi. TURN-server harus sangat andal, memiliki bandwidth yang besar dan daya komputasi yang serius, mendukung pekerjaan dengan data yang berpotensi besar. Menggunakan server TURN, oleh karena itu, jelas mengarah pada biaya tambahan dan peningkatan kompleksitas sistem.

API WebRTC

Ada tiga kategori utama API yang ada di WebRTC:

• API Pengambilan Media dan Streaming bertanggung jawab atas penangkapan dan streaming media. API ini memungkinkan Anda untuk terhubung ke perangkat input, seperti mikrofon dan webcam, dan menerima aliran media dari mereka.
• API RTCPeerConnection Menggunakan API dari kategori ini, dimungkinkan, dari satu titik akhir WebRTC, untuk mengirim, secara real time, aliran data audio atau video yang ditangkap melalui Internet ke titik akhir lain dari WebRTC. Menggunakan API ini, Anda dapat membuat koneksi antara mesin lokal dan rekan jauh. Ini menyediakan metode untuk menghubungkan ke rekan jauh, untuk mengelola koneksi, dan untuk memantau statusnya. Mekanismenya digunakan untuk menutup koneksi yang tidak perlu.
• API RTCDataChannel Mekanisme yang diwakili oleh API ini memungkinkan transfer data sewenang-wenang. Setiap saluran data dikaitkan dengan antarmuka RTCPeerConnection.

Mari kita bicara tentang API ini.

Pengambilan dan Aliran Media API

Media Capture and Streams API, sering disebut sebagai Media Stream API atau Stream API, adalah API yang mendukung bekerja dengan aliran data audio dan video, metode untuk bekerja dengannya. Dengan menggunakan API ini, Anda dapat menetapkan batasan terkait dengan tipe data, di sini ada panggilan balik untuk penyelesaian operasi yang berhasil dan tidak berhasil yang digunakan saat menggunakan mekanisme asinkron untuk bekerja dengan data, dan peristiwa yang dimunculkan selama operasi.

Metode getUserMedia() dari getUserMedia() API meminta izin kepada pengguna untuk bekerja dengan perangkat input yang menghasilkan stream MediaStream dengan trek audio atau video yang berisi jenis media yang diminta. Aliran semacam itu dapat mencakup, misalnya, trek video (sumbernya adalah perangkat keras atau sumber video virtual, seperti kamera, perekam video, layanan berbagi layar, dll.), Trek audio (sumber audio fisik atau virtual juga dapat membentuknya, seperti mikrofon, konverter analog-ke-digital, dan sebagainya), dan mungkin jenis trek lainnya.

Metode ini mengembalikan janji yang diselesaikan ke objek MediaStream . Jika pengguna menolak permintaan untuk izin atau media yang sesuai tidak tersedia, maka janji tersebut akan diselesaikan, masing-masing, dengan kesalahan PermissionDeniedError atau NotFoundError .

Anda dapat mengakses singleton MediaDevice melalui objek navigator :

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

Perhatikan bahwa ketika Anda memanggil metode getUserMedia() , Anda harus memberikannya objek constraints yang memberi tahu API jenis aliran apa yang harus dikembalikan. Di sini Anda dapat mengonfigurasi banyak hal, termasuk kamera yang ingin Anda gunakan (depan atau belakang), kecepatan bingkai, resolusi, dan sebagainya.

Mulai dari versi 25, browser berbasis Chromium memungkinkan Anda mentransfer audio dari getUserMedia() elemen audio atau video (namun, perhatikan bahwa secara default elemen media akan dinonaktifkan).

Metode getUserMedia() juga dapat digunakan sebagai simpul input untuk API Audio Web :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

Keterbatasan terkait dengan perlindungan informasi pribadi

Pengambilan data tanpa izin dari mikrofon atau kamera adalah gangguan serius dengan kehidupan pribadi pengguna. Oleh karena itu, penggunaan getUserMedia() menyediakan untuk penerapan persyaratan yang sangat spesifik untuk memberi tahu pengguna tentang apa yang terjadi dan untuk mengelola izin. Metode getUserMedia() harus selalu mendapatkan izin pengguna sebelum membuka perangkat input apa pun yang mengumpulkan media, seperti webcam atau mikrofon. Browser dapat menawarkan opsi pengaturan izin satu kali untuk suatu domain, tetapi mereka diharuskan untuk meminta izin setidaknya pertama kali mereka mengakses perangkat media, dan pengguna harus secara eksplisit memberikan izin tersebut.

Selain itu, aturan yang terkait dengan memberi tahu pengguna tentang apa yang terjadi adalah penting di sini. Browser diperlukan untuk menampilkan indikator yang menunjukkan penggunaan mikrofon atau kamera. Tampilan indikator semacam itu tidak bergantung pada keberadaan indikator sistem perangkat keras yang mengindikasikan pengoperasian perangkat tersebut. Selain itu, browser harus menunjukkan indikator bahwa izin untuk menggunakan perangkat input telah diberikan, bahkan jika perangkat tidak digunakan pada suatu waktu untuk merekam data yang relevan.

Antarmuka RTCPeerConnection

Antarmuka RTCPeerConnection adalah koneksi WebRTC antara komputer lokal dan rekan jauh. Ini menyediakan metode untuk menghubungkan ke sistem jarak jauh, untuk mendukung koneksi dan memantau statusnya, dan untuk menutup koneksi setelah tidak lagi diperlukan.

Berikut adalah diagram arsitektur WebRTC yang menunjukkan peran RTCPeerConnection.


Peran RTCPeerConnection

Dari perspektif JavaScript, pengetahuan utama yang dapat diambil dari analisis diagram ini adalah bahwa RTCPeerConnection mengabstraksi pengembang web dari mekanisme kompleks yang terletak di level sistem yang lebih dalam. Codec dan protokol yang digunakan oleh WebRTC melakukan pekerjaan yang baik untuk memungkinkan pertukaran data real-time, bahkan ketika menggunakan jaringan yang tidak terpercaya. Berikut adalah beberapa tugas yang diselesaikan oleh mekanisme ini:

• Masking packet loss.
• Pembatalan gema.
• Adaptasi Bandwidth.
• Penyangga dinamis untuk menghilangkan jitter.
• Kontrol volume otomatis.
• Pengurangan dan penindasan kebisingan.
• "Membersihkan" gambar.

API RTCDataChannel

Seperti halnya data audio dan video, WebRTC mendukung transmisi real-time dari tipe data lainnya. API RTCDataChannel memungkinkan Anda untuk mengatur pertukaran data sewenang-wenang P2P.

Ada banyak skenario untuk menggunakan API ini. Inilah beberapa di antaranya:

• Game
• Obrolan teks waktu-nyata.
• Transfer file.
• Organisasi jaringan desentralisasi.

API ini ditujukan untuk penggunaan kapabilitas RTCPeerConnection API yang paling efisien dan memungkinkan Anda untuk mengatur sistem pertukaran data yang kuat dan fleksibel dalam lingkungan P2P. Di antara fitur-fiturnya adalah sebagai berikut:

• Bekerja efektif dengan sesi menggunakan RTCPeerConnection.
• Dukungan untuk beberapa saluran komunikasi yang digunakan secara bersamaan dengan penentuan prioritas.
• Dukungan untuk metode pengiriman pesan yang andal dan tidak dapat diandalkan.
• Manajemen Keamanan Terpadu (DTLS) dan Kemacetan.

Sintaks di sini mirip dengan yang digunakan ketika bekerja dengan teknologi WebSocket. Metode send() dan acara message diterapkan di sini:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC di dunia nyata

Di dunia nyata, komunikasi WebRTC membutuhkan server. Sistem tidak terlalu rumit, terima kasih kepada mereka, urutan tindakan berikut diterapkan:

• Pengguna saling menemukan dan bertukar informasi tentang satu sama lain, misalnya nama.
• Aplikasi klien WebRTC (rekan) bertukar informasi jaringan.
• Peers bertukar informasi tentang data media, seperti format dan resolusi video.
• Aplikasi klien WebRTC membuat koneksi melewati gateway NAT dan firewall.

Dengan kata lain, WebRTC membutuhkan empat jenis fungsi server:

• Berarti untuk menemukan pengguna dan mengatur interaksi mereka.
• Pemberian sinyal.
• Lewati NAT dan firewall.
• Relay server digunakan ketika koneksi P2P tidak dapat dibuat.

Protokol STUN dan ekstensi MENGHIDUPKAN digunakan oleh ICE untuk memungkinkan RTCPeerConnection untuk bekerja dengan mekanisme bypass NAT dan untuk mengatasi kesulitan lain yang dihadapi ketika mengirimkan data melalui jaringan.

Seperti yang telah disebutkan, ICE adalah protokol untuk menghubungkan rekan, seperti dua klien obrolan video. Pada awal sesi komunikasi, ICE mencoba untuk menghubungkan rekan secara langsung, dengan penundaan sesedikit mungkin, melalui UDP. Selama proses ini, server STUN memiliki satu tugas: untuk membiarkan rekan di belakang NAT mempelajari alamat dan port publiknya. Lihatlah daftar server STUN yang tersedia ini (Google juga memiliki server semacam itu).


STUN server

Deteksi Kandidat ICE

Jika koneksi UDP tidak dapat dibangun, ICE mencoba membuat koneksi TCP: first - over HTTP, then - over HTTPS. Jika koneksi langsung tidak dapat dibuat - khususnya, karena ketidakmampuan untuk memotong NAT perusahaan dan firewall, ICE menggunakan perantara (relay) dalam bentuk server TURN. Dengan kata lain, ICE pertama-tama akan mencoba menggunakan STUN dengan UDP untuk koneksi langsung dari rekan-rekan, dan jika ini tidak berhasil, ia akan menggunakan opsi mundur dengan penyewa dalam bentuk server MENGHIDUPKAN. Istilah "pencarian kandidat" mengacu pada proses mencari antarmuka dan port jaringan.


Menemukan antarmuka dan port jaringan yang sesuai

Keamanan

Aplikasi komunikasi waktu nyata atau plugin terkait dapat menyebabkan masalah keamanan. Secara khusus, kita berbicara tentang hal-hal berikut:

• Data media yang tidak terenkripsi atau data lain dapat dicegat di sepanjang jalur antara browser, atau antara browser dan server.
• Aplikasi dapat, tanpa sepengetahuan pengguna, merekam dan mengirimkan data video dan audio ke penyerang.
• Bersama-sama dengan plug-in atau aplikasi yang tampak tidak berbahaya, virus atau perangkat lunak berbahaya lainnya bisa sampai ke komputer pengguna.

WebRTC memiliki beberapa mekanisme yang dirancang untuk menangani ancaman ini:

• Implementasi WebRTC menggunakan protokol aman seperti DTLS dan SRTP .
• Untuk semua komponen sistem WebRTC, penggunaan enkripsi adalah wajib. Ini juga berlaku untuk mekanisme pensinyalan.
• WebRTC bukan plugin. Komponen WebRTC berjalan di kotak pasir peramban, dan tidak dalam proses terpisah. Komponen diperbarui ketika browser diperbarui.
• Akses ke kamera dan mikrofon harus diberikan secara eksplisit. Dan, ketika kamera atau mikrofon digunakan, fakta ini jelas ditampilkan di antarmuka pengguna browser.

Ringkasan

WebRTC adalah teknologi yang sangat menarik dan kuat untuk proyek-proyek yang menggunakan transfer data apa pun antar browser secara real time. Penulis materi mengatakan bahwa perusahaannya, SessionStack , menggunakan mekanisme tradisional untuk bertukar data dengan pengguna, yang melibatkan penggunaan server. Namun, jika mereka menggunakan WebRTC untuk memecahkan masalah yang terkait, ini akan memungkinkan pengorganisasian pertukaran data secara langsung antara browser, yang akan menyebabkan penurunan keterlambatan dalam transfer data dan untuk mengurangi beban pada infrastruktur perusahaan.

Pembaca yang budiman! Apakah Anda menggunakan teknologi WebRTC dalam proyek Anda?