WebRTC vs WebSocket (et webhooks, et HTTP) | We.Inc
WebRTC vs WebSocket : médias et data channels pair à pair contre un socket client-serveur, pourquoi WebRTC a toujours besoin de signalisation, plus webhook vs WebSocket et HTTP vs WebSocket.
Un WebSocket maintient une connexion bidirectionnelle entre un navigateur et votre serveur, et chaque message passe par ce serveur. WebRTC connecte les navigateurs directement entre eux pour l'audio, la vidéo et des données quelconques, chiffrées avec DTLS et SRTP. On les utilise souvent ensemble : un WebSocket transporte les messages de signalisation qui établissent l'appel WebRTC.
WebRTC et WebSocket comparés
Question
WebRTC
WebSocket
Qui parle à qui
Navigateur à navigateur (pair à pair)
Navigateur à serveur
Conçu pour
Audio, vidéo, partage d'écran, données entre pairs
Messages entre l'application et le serveur
Mise en place
Offre, réponse et candidats ICE via votre propre signalisation
Une seule négociation HTTP Upgrade
Options de livraison
Les data channels peuvent être ordonnés ou non, fiables ou non
Ordonnée et fiable
Chiffrement
Toujours actif (DTLS, SRTP)
Seulement avec wss://
Besoin d'un serveur
Pour la signalisation, et des relais TURN quand les pairs ne peuvent pas se connecter directement
Oui, c'est l'autre extrémité
Choisissez ce que vous construisez dans l'assistant ci-dessous et il indique la technologie adaptée, avec la raison. Il couvre aussi les deux questions souvent mélangées avec celle-ci : les webhooks, qui vont de serveur à serveur, et les simples requêtes HTTP.
Choisissez la fonctionnalité la plus proche de la vôtre.
Lisez quelle technologie convient et pourquoi.
Faites défiler jusqu'aux sections de code pour une ébauche de signalisation et un exemple de data channel.
Utilisez les deux tableaux vers la fin pour les comparaisons avec les webhooks et HTTP.
N'utilisez pas WebRTC pour pousser des mises à jour depuis votre serveur. Le serveur n'y est pas un pair, et un WebSocket ou un flux d'événements est bien plus simple.
Prévoyez le budget d'un relais TURN avant de lancer les appels. Certains réseaux bloquent les connexions directes entre pairs, et alors tous les médias passent par le relais que vous payez.
Gardez un serveur de signalisation bête : il ne fait que transmettre offres, réponses et candidats. MDN décrit la charge utile comme une boîte noire que le serveur n'a pas besoin de comprendre.
Pour un jeu ou un flux de curseurs en direct entre pairs, ouvrez le data channel avec ordered à false et maxRetransmits à 0 pour qu'un paquet en retard ne bloque jamais les plus récents.
Questions fréquentes
WebRTC remplace-t-il les WebSockets ?
Non. WebRTC n'a aucun moyen intégré pour que deux navigateurs se trouvent, il vous faut donc toujours un canal pour échanger les messages de mise en place. Un WebSocket est le choix habituel, même si MDN précise que n'importe quel transport convient.
WebRTC peut-il envoyer de simples données, pas seulement de la vidéo ?
Oui. RTCPeerConnection.createDataChannel() ouvre un canal pour du texte ou des données binaires entre pairs, et son API est volontairement proche de celle de WebSocket, avec send() et un événement message.
Quelle est la différence entre un webhook et un WebSocket ?
Un webhook est une requête HTTP qu'un serveur envoie à une URL sur un autre serveur quand un événement se produit, puis la connexion se termine. Un WebSocket est une connexion qui reste ouverte pour qu'un navigateur et un serveur continuent d'échanger.
Un WebSocket est-il plus rapide que HTTP ?
Pour beaucoup de petits messages, en général oui, puisque la négociation n'a lieu qu'une fois et que chaque message suivant évite les en-têtes de requête. Pour charger une page ou un fichier, le HTTP ordinaire est le bon outil et profite du cache.
WebRTC reste-t-il pair à pair avec beaucoup de participants dans un appel ?
Chaque connexion relie deux pairs, donc un maillage complet grossit vite à mesure que des personnes rejoignent. Beaucoup de produits d'appel plus importants font passer les médias par un serveur qui retransmet les flux, ce qui se situe hors de l'API WebRTC du navigateur elle-même.
Pourquoi WebRTC a toujours besoin d'un serveur
Avant que deux navigateurs puissent se connecter, chacun doit connaître la description de session de l'autre, une offre et une réponse SDP, ainsi qu'une liste d'adresses réseau possibles appelées candidats ICE. WebRTC vous laisse le soin d'acheminer ces messages.
Une fois ceux-ci échangés, ICE essaie les candidats, STUN aidant chaque côté à découvrir son adresse publique. Si aucune route directe ne fonctionne, le trafic se rabat sur un serveur TURN qui le relaie. Ensuite, les médias circulent entre les pairs, pas par votre serveur de signalisation.
Webhook vs WebSocket
Ils résolvent des problèmes différents. Un webhook permet à un service, comme un prestataire de paiement ou un hébergeur de code, de signaler à votre backend qu'il s'est passé quelque chose, en envoyant une requête HTTP à une URL que vous avez enregistrée. Rien ne reste ouvert, et aucun navigateur n'intervient.
Un WebSocket garde une ligne active vers le navigateur d'un utilisateur. Un schéma courant utilise les deux : un webhook indique à votre serveur qu'une commande a été payée, puis votre serveur pousse cette nouvelle vers la page ouverte du client via un WebSocket.
HTTP vs WebSocket
Le HTTP simple fonctionne par requête et réponse : le client demande, le serveur répond, et les réponses GET peuvent être mises en cache par les navigateurs et les CDN. C'est le bon choix par défaut pour les pages, les fichiers et la plupart des appels d'API.
Un WebSocket commence comme une requête HTTP, puis change de protocole avec une réponse 101 et reste ouvert. Ne l'utilisez que lorsque le serveur doit envoyer des données que le client n'a pas demandées, ou que les messages sont assez fréquents pour que le coût par requête compte.
Mise en place de WebRTC via un WebSocket
Appelant : créer une offre et un data channel
Le WebSocket ne fait que transmettre les messages de mise en place. L'URL STUN est un exemple à remplacer par le serveur de votre choix.
Appelé : répondre et recevoir le canal
L'autre côté reçoit le canal via l'événement datachannel au lieu de le créer.
Un canal non ordonné, sans renvoi, pour l'état d'un jeu
maxRetransmits et maxPacketLifeTime ne peuvent pas être définis ensemble ; choisissez-en un.
Webhook vs WebSocket en un coup d'œil
Webhook vs WebSocket
Question
Webhook
WebSocket
Qui se connecte
Un serveur appelle un autre serveur
Un client garde une ligne ouverte vers un serveur
Durée de vie
Une requête HTTP par événement
Ouvert jusqu'à ce que l'un des côtés le ferme
Sens
De l'émetteur au récepteur
Dans les deux sens
Usage typique
Événements de paiement, de dépôt ou de formulaire
Chat en direct, tableaux de bord, présence
HTTP vs WebSocket en un coup d'œil
HTTP vs WebSocket
Question
Requête HTTP
WebSocket
Qui initie un message
Toujours le client
L'un ou l'autre côté
Connexion
Requête, puis réponse
Passée en 101, puis reste ouverte
Mise en cache
Les réponses GET et HEAD peuvent être mises en cache
Aucune
Schémas d'URL
ws:// (port 80), wss:// (port 443)
Appel vidéo entre deux personnes
WebRTC, avec un WebSocket pour la signalisation
L'audio et la vidéo doivent aller directement d'un interlocuteur à l'autre avec peu de latence. Un petit serveur WebSocket ne transmet que l'offre, la réponse et les candidats pendant la mise en place.
Salon de discussion de groupe dans une application web
WebSocket
Les messages doivent être stockés, modérés et envoyés à tous les membres du salon, ils ont donc de toute façon leur place sur votre serveur. Un socket par utilisateur est la solution simple.
Envoyer un gros fichier vers le navigateur d'un ami
Data channel WebRTC
Un data channel fiable et ordonné transfère les octets de pair à pair, donc votre serveur ne stocke ni ne relaie jamais le fichier, sauf si TURN est nécessaire.
Coups rapides d'un jeu à deux joueurs
Data channel WebRTC, non ordonné
Sans ordre ni renvoi, une mise à jour de position perdue est ignorée au lieu de retarder les plus récentes. Si vous avez besoin d'un serveur arbitre, utilisez plutôt un WebSocket vers celui-ci.
Un prestataire de paiement confirme une commande
Webhook
Le serveur du prestataire appelle une URL sur votre serveur quand le paiement réussit. Aucun navigateur n'intervient, et rien n'a besoin de rester ouvert.
Charger une page produit et ses données
HTTP simple
Une requête et une réponse suffisent, et les réponses GET peuvent être mises en cache. Une connexion persistante ajouterait un coût sans aucun bénéfice.