Quelle est la différence entre WebRTC et WebSockets pour la communication de données de bas niveau
J'essaie de comprendre la différence entre WebRTC et WebSockets afin de mieux comprendre quel scénario appelle quoi. Je suis curieux de voir l'idée générale que deux parties (principalement basées sur le Web, mais potentiellement l'une étant une application serveur dédiée) se parlent.
Supposition:
- Clairement en ce qui concerne les réseaux ad-hoc, WebRTC gagne car il supporte nativement le protocole/méthode ICE.
Des questions:
- En ce qui concerne la communication directe entre deux parties connues dans le navigateur, si je ne compte pas sur l'envoi de données multimédias et que je ne suis intéressé que par l'envoi de données entières, WebRTC me donne-t-il des avantages par rapport aux webSockets autres que le cryptage des données?
- Concernant un serveur dédié parlant à un client basé sur un navigateur, quelle plateforme me donne un avantage? Il me faudrait coder un serveur WebRTC (est-ce possible à partir du navigateur?), Ou je devrais coder un serveur WebSocket (une recherche rapide sur Google me fait penser que c'est possible).
WebRTC spécifie le transport multimédia sur RTP .. qui peut fonctionner P2P dans certaines circonstances. Dans tous les cas pour établir une session webRTC, vous aurez également besoin d'un protocole de signalisation .. et pour cela WebSocket est un choix probable En d'autres termes: à moins que vous ne vouliez diffuser des médias en temps réel, WebSocket est probablement un meilleur choix.
Il y a une différence significative: Websockets fonctionne via TCP, WebRTC fonctionne via UDP. En fait, WebRTC est un protocole SRTP avec certaines fonctionnalités supplémentaires comme STUN, ICE, DTLS, etc. et des fonctionnalités VoIP internes telles que Adaptive Jitter Buffer, AEC, AGC, etc.
Ainsi, Websocket est conçu pour une communication fiable. C'est un bon choix si vous souhaitez envoyer des données qui doivent être envoyées de manière fiable.
Lorsque vous utilisez WebRTC, le flux transmis n'est pas fiable. Certains paquets peuvent être perdus dans le réseau. C'est mauvais si vous envoyez des données critiques, par exemple pour le traitement financier, le même problème est idéalement adapté lorsque vous envoyez un flux audio ou vidéo où certaines images peuvent être perdues sans aucun problème de qualité notable.
Si vous souhaitez envoyer un canal de données via WebRTC, vous devez disposer d'un algorithme de correction d'erreur directe pour restaurer les données en cas de perte d'une trame de données sur le réseau.
Question 1: Oui. La partie DataChannel de WebRTC vous offre des avantages dans ce cas, car elle vous permet de créer un canal d'égal à égal entre les navigateurs pour envoyer et recevoir toutes les données brutes que vous souhaitez. Websockets vous oblige à utiliser un serveur pour connecter les deux parties.
Question 2 Comme je l'ai dit dans la réponse précédente, les Websockets sont mieux si vous voulez une communication serveur-client, et il existe de nombreuses implémentations pour ce faire (ie jWebSocket ). Pour ajouter la prise en charge dans un serveur pour établir une connexion avec un WebRTC DataChannel, cela peut vous prendre quelques jours de vie et de santé. :)