WebRTC vs Websockets: Jika WebRTC dapat melakukan Video, Audio, dan Data, mengapa saya perlu Websockets? [Tutup]

Jadi saya ingin membuat aplikasi obrolan yang memungkinkan video, audio, dan teks. Saya menghabiskan waktu meneliti Websockets dan WebRTC untuk memutuskan mana yang akan digunakan. Karena ada banyak aplikasi video dan audio dengan WebRTC, ini terdengar seperti pilihan yang masuk akal, tetapi adakah hal lain yang harus saya pertimbangkan? Jangan ragu untuk membagikan pemikiran Anda.

Hal-hal seperti:

• Karena WebRTC baru tersedia hanya pada beberapa browser, sementara WebSockets tampaknya berada di lebih banyak browser.

• Skalabilitas - Websockets menggunakan server untuk sesi dan WebRTC tampaknya p2p.

• Multiplexing / multiple chatroom - Digunakan di Google+ Hangouts, dan saya masih melihat aplikasi demo tentang cara menerapkan.

• Server - Websockets membutuhkan RedisSessionStore atau RabbitMQ untuk skala di beberapa mesin.

WebRTC dirancang untuk komunikasi berkualitas tinggi, data video, audio, dan arbitrer yang berkinerja tinggi. Dengan kata lain, untuk aplikasi persis seperti yang Anda gambarkan.

Aplikasi WebRTC memerlukan layanan melalui mana mereka dapat bertukar metadata jaringan dan media, sebuah proses yang dikenal sebagai pensinyalan. Namun, setelah pensinyalan terjadi, video / audio / data dialirkan langsung antara klien, menghindari biaya kinerja streaming melalui server perantara.

WebSocket di sisi lain dirancang untuk komunikasi dua arah antara klien dan server. Dimungkinkan untuk melakukan streaming audio dan video melalui WebSocket (lihat di sini sebagai contoh), tetapi teknologi dan API tidak secara inheren dirancang untuk streaming yang efisien dan kuat seperti WebRTC.

Seperti balasan lain katakan, WebSocket dapat digunakan untuk pensinyalan.

Saya memelihara daftar sumber daya WebRTC : sangat disarankan Anda mulai dengan melihat presentasi Google I / O 2013 tentang WebRTC.

WebSockets:

• Standar IETF (6455) yang telah diratifikasi dengan dukungan di semua browser modern dan bahkan browser lama menggunakan web-socket-js polyfill.

• Menggunakan handshake yang kompatibel dengan HTTP dan port default sehingga lebih mudah digunakan dengan firewall, proxy, dan infrastruktur server web yang ada.

• API browser yang lebih sederhana. Pada dasarnya satu konstruktor dengan beberapa panggilan balik.

• Klien / browser ke server saja.

• Hanya mendukung transportasi yang andal dan berurutan karena dibangun pada TCP. Ini berarti paket drop dapat menunda semua paket selanjutnya.

WebRTC:

• Baru mulai didukung oleh Chrome dan Firefox. MS telah mengusulkan varian yang tidak kompatibel. Komponen DataChannel belum kompatibel antara Firefox dan Chrome.

• WebRTC adalah peramban ke peramban dalam keadaan ideal tetapi meskipun demikian hampir selalu membutuhkan server pemberi sinyal untuk mengatur koneksi. Solusi server pensinyalan yang paling umum saat ini menggunakan WebSockets.

• Lapisan transport dapat dikonfigurasi dengan aplikasi yang dapat memilih jika koneksi dalam urutan dan / atau dapat diandalkan.

• API browser yang kompleks dan berlapis-lapis. Ada JS lib untuk menyediakan API yang lebih sederhana tetapi ini masih muda dan cepat berubah (seperti WebRTC itu sendiri).

Soket web menggunakan protokol TCP.

WebRTC terutama UDP.

Jadi alasan utama menggunakan WebRTC bukan Websocket adalah latensi. Dengan streaming websocket Anda akan memiliki latensi tinggi atau pemutaran berombak dengan latensi rendah. Dengan WebRTC Anda dapat mencapai pemutaran latensi rendah dan lancar yang merupakan hal penting untuk komunikasi VoIP.

Coba saja uji teknologi ini dengan kehilangan jaringan, yaitu 2%. Anda akan melihat keterlambatan tinggi dalam aliran Websocket.

webRTC atau websockets? Mengapa tidak menggunakan keduanya.

Saat membuat obrolan video / audio / teks, webRTC jelas merupakan pilihan yang baik karena menggunakan teknologi peer to peer dan setelah koneksi menyala dan berjalan, Anda tidak perlu meneruskan komunikasi melalui server (kecuali menggunakan TURN).

Saat mengatur komunikasi webRTC Anda harus melibatkan semacam mekanisme pensinyalan. Soket web bisa menjadi pilihan yang baik di sini, tetapi webRTC adalah cara untuk mencari info video / audio / teks. Ruang obrolan diselesaikan dalam pensinyalan.

Tetapi, seperti yang Anda sebutkan, tidak semua browser mendukung webRTC, jadi soket web terkadang bisa menjadi pengganti yang bagus untuk browser tersebut.

Membandingkan websocket dan webrtc tidak adil.

Websocket didasarkan pada bagian atas TCP. Batas paket dapat dideteksi dari informasi header dari paket websocket tidak seperti tcp.

Biasanya, webrtc menggunakan websocket. Pensinyalan untuk webrtc tidak ditentukan, terserah penyedia layanan pensinyalan seperti apa yang ingin ia gunakan. Mungkin SIP, HTTP, JSON atau pesan teks / biner.

Pesan pensinyalan dapat dikirim / diterima menggunakan websocket.

Keamanan adalah salah satu aspek yang Anda lewatkan.

Dengan Websockets data harus melalui server web pusat yang biasanya melihat semua lalu lintas dan dapat mengaksesnya.

Dengan WebRTC, data dienkripsi end-to-end dan tidak melewati server (kecuali kadang-kadang TURN server diperlukan, tetapi mereka tidak memiliki akses ke isi pesan yang diteruskan).

Tergantung pada aplikasi Anda ini mungkin atau tidak masalah.

Jika Anda mengirim data dalam jumlah besar, penghematan biaya bandwidth cloud karena arsitektur P2P webRTC mungkin layak dipertimbangkan juga.

Webrtc adalah bagian dari koneksi peer to peer. Kita semua tahu bahwa sebelum membuat koneksi peer to peer, diperlukan proses jabat tangan untuk membangun koneksi peer to peer. Dan websockets memainkan peran proses jabat tangan.

Websocket dan WebRTC dapat digunakan bersama-sama, Websocket sebagai saluran sinyal WebRTC, dan webrtc adalah saluran video / audio / teks, juga WebRTC dapat di UDP juga di MENGHIDUPKAN relay, MENGHIDUPKAN relay mendukung TCP HTTP juga HTTPS. Banyak proyek menggunakan Websocket dan WebRTC secara bersamaan.