Canaux de données WebRTC au-delà des appels vidéo_

WebRTC est souvent considéré comme une technologie de visioconférence avec quelques API supplémentaires.

Cela laisse de côté l'une de ses capacités les plus intéressantes : RTCDataChannel.

Les canaux de données permettent aux navigateurs d'échanger des données d'application arbitraires via la même infrastructure pair-à-pair que WebRTC utilise pour les médias. Cela ouvre la porte à :

• outils de collaboration
• multijoueur navigateur
• transfert de fichiers assisté par les pairs
• synchronisation locale en premier à faible latence

Ce que le Peer-to-Peer vous apporte réellement

L'attrait principal n'est pas idéologique. C'est architectural.

Si deux navigateurs peuvent échanger des données directement, vous réduisez la quantité de trafic qui doit transiter par votre propre infrastructure backend. Cela peut diminuer :

• la bande passante serveur
• les coûts de relais
• les goulets d'étranglement centraux

Mais cela ne se produit que lorsque un chemin direct est possible.

Les éléments que les gens négligent

Un déploiement WebRTC réel nécessite toujours :

• signalement
• échange de candidats ICE
• STUN pour la découverte de réseau
• TURN pour un relais de secours lorsque la connectivité directe échoue

Cela signifie qu'un système WebRTC n'est pas "sans serveur". Il est "pas toujours relayé par le serveur de votre application."

TURN est particulièrement important car de nombreux utilisateurs réels se trouvent derrière des conditions de NAT ou de pare-feu qui empêchent une connectivité pair-à-pair propre.

Une forme minimale

La configuration côté navigateur ressemble généralement à ceci :

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
 
const channel = pc.createDataChannel("sync");
 
channel.onmessage = (event) => {
  console.log("reçu", event.data);
};

Ensuite, le reste du travail consiste en signalement : offres, réponses et candidats ICE.

Ce chemin de signalement est spécifique à l'application. WebRTC ne vous le fournit pas.

Où les canaux de données s'intègrent bien

Ils sont bien adaptés lorsque :

• la latence est importante
• les pairs échangent un état transitoire
• le produit fonctionne toujours si certaines sessions transitent par TURN

Ils ne sont pas adaptés lorsque :

• chaque transfert doit être audité de manière centrale
• le stockage hors ligne et la capacité de reprendre compte plus que le transport en direct
• le modèle commercial ne peut pas tolérer d'infrastructure de relais de toute façon

Pour la livraison de gros fichiers, le pair-à-pair semble attrayant, mais la capacité de reprise, la persistance et les attentes multi-appareils poussent souvent les équipes à revenir vers le stockage d'objets.

Donc, la réponse honnête est : les canaux de données WebRTC sont puissants, mais ne constituent pas un remplacement global pour le transport médié par le serveur.

Lectures complémentaires

• MDN : Utiliser les canaux de données WebRTC
• MDN : Introduction aux protocoles WebRTC