WebRTC vs Websockets: si WebRTC peut faire de la vidéo, de l'audio et des données, pourquoi ai-je besoin de Websockets? [fermé]

Je cherche donc à créer une application de chat qui permettra la vidéo, l'audio et le texte. J'ai passé un peu de temps à rechercher des Websockets et WebRTC pour décider lequel utiliser. Étant donné qu'il existe de nombreuses applications vidéo et audio avec WebRTC, cela semble être un choix raisonnable, mais y a-t-il d'autres choses à considérer? Sentez-vous libre de partager vos pensées.

Des choses comme:

• En raison de son nouveau WebRTC est disponible uniquement sur certains navigateurs, tandis que WebSockets semble être dans plus de navigateurs.

• Évolutivité - Websockets utilise un serveur pour la session et WebRTC semble être p2p.

• Multiplexage / plusieurs salles de chat - Utilisé dans Google+ Hangouts, et je suis toujours en train de visualiser des applications de démonstration sur la façon de les mettre en œuvre.

• Serveur - Websockets a besoin de RedisSessionStore ou RabbitMQ pour évoluer sur plusieurs machines.

WebRTC est conçu pour une communication haute performance et de haute qualité de données vidéo, audio et arbitraires. En d'autres termes, pour des applications exactement comme 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 connu sous le nom de signalisation. Cependant, une fois la signalisation effectuée, la vidéo / l'audio / les données sont diffusées directement entre les clients, ce qui évite le coût des performances de la diffusion via un serveur intermédiaire.

WebSocket, d'autre part, est conçu pour la communication bidirectionnelle entre le client et le serveur. Il est possible de diffuser de l'audio et de la vidéo sur WebSocket (voir ici par exemple), mais la technologie et les API ne sont pas intrinsèquement conçues pour une diffusion efficace et robuste comme le WebRTC.

Comme d'autres réponses l'ont dit, WebSocket peut être utilisé pour la signalisation.

Je tiens à jour une liste de ressources WebRTC : je vous recommande vivement de commencer par consulter la présentation Google I / O de 2013 sur WebRTC.

WebSockets:

• Norme IETF ratifiée (6455) avec prise en charge sur tous les navigateurs modernes et même les anciens navigateurs utilisant le polyfill web-socket-js.

• Utilise une prise de contact compatible HTTP et des ports par défaut, ce qui facilite son utilisation avec l'infrastructure de pare-feu, de proxy et de serveur Web existante.

• API de navigateur beaucoup plus simple. Fondamentalement, un constructeur avec quelques rappels.

• Client / navigateur vers serveur uniquement.

• Prend uniquement en charge le transport fiable et en ordre car il est construit sur TCP. Cela signifie que les pertes de paquets peuvent retarder tous les paquets suivants.

WebRTC:

• Commençant tout juste à ê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 est navigateur à navigateur dans des circonstances idéales, mais même alors, il nécessite presque toujours un serveur de signalisation pour configurer les connexions. Les solutions de serveurs de signalisation les plus courantes utilisent actuellement WebSockets.

• La couche transport est configurable avec une application capable de 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 lui-même).

Les Websockets utilisent le protocole TCP.

WebRTC est principalement UDP.

Ainsi, la principale raison d'utiliser WebRTC au lieu de Websocket est la latence. Avec le streaming Websocket, vous aurez une latence élevée ou une lecture saccadée à faible latence. Avec WebRTC, vous pouvez obtenir une faible latence et une lecture fluide, ce qui est essentiel pour les communications VoIP.

Essayez simplement de tester ces technologies avec une perte de réseau, soit 2%. Vous verrez des retards importants dans le flux Websocket.

webRTC ou websockets? Pourquoi ne pas utiliser les deux.

Lors de la création d'un chat vidéo / audio / texte, webRTC est certainement un bon choix car il utilise la technologie peer to peer et 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 impliquer une sorte de mécanisme de signalisation. Les sockets Web pourraient être un bon choix ici, mais webRTC est le chemin à parcourir pour les informations vidéo / audio / texte. Les salles de chat sont accomplies dans la signalisation.

Mais, comme vous le mentionnez, tous les navigateurs ne prennent pas en charge webRTC, les websockets peuvent donc parfois être une bonne solution de rechange pour ces navigateurs.

La comparaison de websocket et de webrtc est injuste.

Websocket est basé sur TCP. La limite du 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, il appartient 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 à l'aide de websocket.

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 parfois des serveurs TURN sont nécessaires, mais ils n'ont pas accès au corps des messages qu'ils transfèrent).

Selon votre application, cela peut ou non être important.

Si vous envoyez de grandes quantités de données, l'économie de coûts de bande passante cloud due à l'architecture P2P de webRTC peut également être utile.

Webrtc fait partie de la connexion peer to peer. Nous savons tous qu'avant de créer une connexion d'égal à égal, il faut un processus d'établissement de liaison pour établir une connexion d'égal à égal. Et les websockets jouent le rôle de processus de négociation.

Websocket et WebRTC peuvent être utilisés ensemble, Websocket comme canal de signal de WebRTC et webrtc est un canal vidéo / audio / texte, WebRTC peut également être en UDP également en relais TURN, le relais TURN prend en charge TCP HTTP et HTTPS. De nombreux projets utilisent Websocket et WebRTC ensemble.