WebRTC vs Websockets: Si WebRTC peut faire de la vidéo, de l'audio et des données, pourquoi ai-je besoin de Websockets?
Donc, je cherche à construire une application de chat qui permettra la vidéo, l'audio et le texte. J'ai passé un peu de temps à rechercher Websockets et WebRTC pour décider lequel utiliser. Comme il existe de nombreuses applications vidéo et audio avec WebRTC, cela semble être un choix raisonnable, mais y a-t-il d'autres éléments à considérer? Sentez-vous libre de partager vos pensées.
Des choses comme:
Du fait qu’il est nouveau, WebRTC n’est disponible que sur certains navigateurs, alors que Websockets semble appartenir à un plus grand nombre de navigateurs.
Evolutivité - Websockets utilise un serveur pour la session et WebRTC semble être p2p
Multiplexage/plusieurs salles de discussion - Utilisé dans les hangouts Google+ et je suis toujours en train de regarder des applications de démonstration sur la mise en œuvre.
Serveur - Websockets a besoin de RedisSessionStore ou de RabbitMQ pour s'adapter à plusieurs ordinateurs
WebRTC est conçu pour la communication haute performance, de haute qualité, de données vidéo, audio et arbitraires. En d'autres termes, pour les applications exactement ce que vous décrivez.
Les applications WebRTC ont besoin d'un service via lequel elles peuvent échanger des métadonnées réseau et multimédia, un processus appelé signalisation. Cependant, une fois que la signalisation a eu lieu, les données vidéo/audio/sont directement transmises entre les clients, ce qui évite les coûts de performance liés à la diffusion via un serveur intermédiaire.
WebSocket, quant à lui, est conçu pour la communication bidirectionnelle entre le client et le serveur. Il est possible de diffuser du contenu audio et vidéo via WebSocket (voir ici par exemple), mais la technologie et les API ne sont pas conçus de manière intrinsèque pour une diffusion efficace et robuste en continu. la façon dont WebRTC est.
Comme d'autres réponses l'ont dit, WebSocket peut être utilisé pour la signalisation.
Je tiens à jour une liste de ressources WebRTC : nous vous recommandons vivement de commencer par consulter la présentation de Google I/O 2013 à propos de WebRTC.
WebSockets:
Norme IETF ratifiée (6455) avec prise en charge de tous les navigateurs modernes et même d'anciens navigateurs utilisant Web-socket-js polyfill.
Utilise une liaison compatible HTTP et des ports par défaut facilitant son utilisation avec les infrastructures de pare-feu, de proxy et de serveur Web existantes.
API de navigateur beaucoup plus simple. Fondamentalement, un constructeur avec quelques rappels.
Client/navigateur sur serveur uniquement.
Ne prend en charge que le transport fiable dans l’ordre, car il est construit sur TCP. Cela signifie que les abandons de paquets peuvent retarder tous les paquets suivants.
WebRTC:
Tout commence à être pris en charge par Chrome et Firefox. MS a proposé une variante incompatible. Le composant DataChannel n'est pas encore compatible entre Firefox et Chrome.WebRTC fonctionne de navigateur en navigateur dans des circonstances idéales, mais même dans ce cas, il est presque toujours nécessaire de faire appel à un serveur de signalisation pour configurer les connexions. Les solutions de serveur de signalisation les plus courantes utilisent actuellement WebSockets.
La couche de transport est configurable avec une application pouvant choisir si la connexion est en ordre et/ou fiable.
API de navigateur complexe et multicouche. Il existe des bibliothèques JS pour fournir une API plus simple, mais elles sont jeunes et évoluent rapidement (tout comme WebRTC elle-même).
Les Websockets utilisent le protocole TCP.
WebRTC est principalement UDP.
Par conséquent, la raison principale d'utiliser WebRTC au lieu de Websocket est la latence. Avec le streaming Websocket, vous obtiendrez une lecture à latence élevée ou instable avec une latence faible. Avec WebRTC, vous pouvez obtenir une lecture fluide et à faible temps de latence, élément crucial pour les communications VoIP.
Essayez simplement de tester ces technologies avec une perte de réseau, soit 2%. Vous verrez des délais importants dans le flux Websocket.
webRTC ou websockets? Pourquoi ne pas utiliser les deux.
Si vous créez un chat vidéo/audio/texte, webRTC est un bon choix car il utilise la technologie peer to peer. Une fois la connexion établie, vous n'avez pas besoin de passer la communication via un serveur (sauf si vous utilisez TURN).
Lors de la configuration de la communication webRTC, vous devez utiliser un mécanisme de signalisation. Les Websockets pourraient être un bon choix ici, mais webRTC est la voie à suivre pour les informations vidéo/audio/texte. Les salles de discussion sont accomplies dans la signalisation.
Mais, comme vous l'avez dit, tous les navigateurs ne prennent pas en charge webRTC. Par conséquent, les Websockets peuvent parfois constituer une solution de secours intéressante pour ces navigateurs.
La sécurité est un aspect que vous avez manqué.
Avec Websockets, les données doivent passer par un serveur Web central, qui voit généralement tout le trafic et peut y accéder.
Avec WebRTC, les données sont chiffrées de bout en bout et ne transitent pas par un serveur (sauf que des serveurs TURN sont parfois nécessaires, mais ils n'ont pas accès au corps des messages qu'ils transmettent).
Selon votre application, cela peut être important ou non.
Si vous envoyez de grandes quantités de données, il peut également être intéressant de réduire les coûts liés à la bande passante dans le cloud grâce à l'architecture P2P de webRTC.
La comparaison de Websocket et de webrtc est injuste.
Websocket est basé sur TCP. La limite de paquet peut être détectée à partir des informations d'en-tête d'un paquet websocket, contrairement à TCP.
En règle générale, webrtc utilise Websocket. La signalisation pour webrtc n’est pas définie, c’est au fournisseur de services quel type de signalisation il souhaite utiliser. Il peut s'agir de SIP, HTTP, JSON ou de tout message texte/binaire.
Les messages de signalisation peuvent être envoyés/reçus via Websocket.
Webrtc fait partie de la connexion peer to peer. Nous savons tous qu'avant de créer une connexion entre homologues, un processus d'établissement de liaison est nécessaire pour établir une connexion entre homologues. Et les Websockets jouent le rôle de processus de poignée de main.
Websocket et WebRTC peuvent être utilisés ensemble, Websocket en tant que canal de signal de WebRTC et webrtc est un canal vidéo/audio/texte. WebRTC peut également être au format UDP également dans TURN relay, Prise en charge de relais TURN TCP HTTP et HTTPS également. De nombreux projets utilisent Websocket et WebRTC ensemble.