Comment fonctionne WebRTC?
Je suis intéressé par les connexions Peer-to-Peer dans le navigateur. Étant donné que cela semble possible avec WebRTC, je me demande comment cela fonctionne exactement.
J'ai lu quelques explications et vu des diagrammes à ce sujet et maintenant il est clair pour moi que l'établissement de la connexion fonctionne sur le serveur. Le serveur semble échanger des données entre le client qui souhaite se connecter les uns aux autres, afin de pouvoir établir une connexion directe, indépendante du serveur.
Mais c'est exactement ce que je ne comprends pas. Jusqu'à présent, je pensais que la seule façon de créer des connexions était d'écouter sur un port de l'ordinateur A et de se connecter à ce port à partir de l'ordinateur B. Mais cela ne semble pas être le cas dans WebRTC. Je pense qu'aucun des clients ne commence à écouter sur un port. D'une manière ou d'une autre, ils peuvent créer une connexion sans écouter les ports et accepter les connexions. Ni le client A, ni le client B ne commencent à agir en tant que serveur.
Mais comment? Quelles données sont échangées sur le serveur WebRTC, que les clients peuvent utiliser pour se connecter les uns aux autres?
Merci pour vos explications :)
Modifier
J'ai trouvé cet article. Ce n'est pas lié à WebRTC, mais je pense qu'il répond à une partie de ma question. Je ne suis pas sûr, difficile. Ce serait quand même cool, si quelqu'un pouvait me l'expliquer et me donner quelques liens supplémentaires.
WebRTC donne une offre SDP à l'application JS cliente pour l'envoyer (comme l'application JS le souhaite) à l'autre appareil, qui l'utilise pour générer une réponse SDP.
L'astuce est que le SDP comprend des candidats ICE ("essayez de me parler à cette adresse IP et à ce port"). ICE travaille pour percer les ports ouverts dans les pare-feu; cependant, si les deux côtés sont des NAT symétriques, cela ne sera généralement pas possible et un candidat alternatif (sur un serveur TURN) peut être utilisé.
Une fois qu'ils parlent directement (ou via TURN, qui est en fait un miroir de paquets), ils peuvent ouvrir une connexion DTLS et l'utiliser pour coder les flux multimédias SRTP-DTLS et envoyer des DataChannels via DTLS.
Edit: Acronymes ici: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ pour le reste, il y a Google. La plupart d'entre eux sont définis par l'IETF ( http://ietf.org/ )
Edit 2: Firefox et Chrome (et la spécification) sont passés à l'utilisation de "filet" pour les candidats ICE, de sorte que les candidats ICE sont généralement ajoutés après le visage à PeerConnection et échangés indépendamment de le SDP initial (bien que vous puissiez attendre que les candidats initiaux soient prêts avant d'envoyer une offre et les regrouper). Voir https://webrtcglossary.com/trickle-ice/ et https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
L'établissement d'une connexion WebRTC p2p se déroule en 3 étapes (10 000 pieds de vue d'ensemble):
Étape 1: Signalisation : les deux pairs se connectent à un serveur de signalisation (à l'aide de websockets sur 80/443, comète, SIP, etc.) et échangent des informations ( sur leurs capacités multimédias, IP publique: paires de ports lorsqu'elles deviennent disponibles, etc.)
Étape 2: Découverte : les appareils connectés au réseau local ou aux réseaux mobiles ne connaissent pas leur adresse IP publique (et port) où ils peuvent être atteints afin qu'ils utilisent Serveurs STUN/TURN situés sur Internet public pour découvrir leur paire ip: port (candidats ICE). Dans le processus, ils perforent un trou à travers le NAT/routeur qui est utilisé à l'étape 3:
Étape 3: Connexion P2P : une fois que les candidats ICE sont échangés via le canal de signalisation initial, chaque pair est conscient de l'ip: port de l'autre (et des trous ont été poinçonnés dans les NAT/routeurs) afin qu'une connexion UDP d'égal à égal puisse être établie.
Le schéma ci-dessus explique le processus avec 2 appareils connectés aux réseaux locaux. Cela fait partie d'un article que j'ai écrit qui traite de résolution des problèmes de connexion mais il explique bien le fonctionnement de WebRTC.
Une très bonne explication peut être trouvée dans ce livre http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE qui fournit les principes de base sur la façon dont WebRTC utilise la technologie ICE.
En particulier, en supposant que l'adresse IP du serveur STUN est connue, l'application WebRTC envoie d'abord une demande de liaison au serveur STUN. Le serveur STUN répond avec une réponse qui contient l'adresse IP publique et le port du client tels que vus depuis le réseau public.
Maintenant, l'application découvre son IP publique et son Tuple de port qui peuvent être envoyés à l'autre homologue via SDP. (notez que les SDP sont envoyés sur un canal de signalisation externe, par exemple une prise Web établie via un service Web)
Avec ce mécanisme en place, chaque fois que deux homologues veulent se parler via UDP, ils peuvent ensuite utiliser l'IP publique établie et les tuples de port pour échanger des données.
Malheureusement, dans certains cas, UDP peut être bloqué par un pare-feu. Pour résoudre ce problème, chaque fois que STUN échoue, nous pouvons utiliser le protocole Traversal Using Relays around NAT (TURN) comme solution de rechange, qui peut s'exécuter sur UDP et basculer sur TCP si tout le reste échoue.
Fonctionnement de WebRTC
Ce document fournit une introduction rapide et abstraite à WebRTC. Afin d'obtenir plus d'informations sur WebRTC, veuillez consulter la section Lectures complémentaires à la fin de ce document.
WebRTC
WebRTC (Web Real-Time Communication) est un ensemble de technologies développées pour la communication en temps réel duplex peer to peer entre les navigateurs. Comme son nom l'indique, il est compatible avec le Web et c'est un standard dans le W3C L'une des caractéristiques importantes de WebRTC est qu'il fonctionne même derrière les adresses NAT.
WebRTC utilise plusieurs technologies pour fournir une communication poste à poste en temps réel entre les navigateurs. Ces technologies sont * SDP (Session Description Protocol) * ICE (Interactivity Connection Establishment) * RTP (Real Time Protocol)
Il y a encore une chose qui est le serveur de signalisation est nécessaire pour exécuter WebRTC. Cependant, il n'y a pas de standard défini dans l'implémentation du serveur de signalisation. Chaque implémentation crée son propre style. Vous trouverez plus d'informations sur Signaling Server plus loin dans cette section.
Donnons quelques informations rapides sur les technologies ci-dessus.
SDP (Session Description Protocol)
SDP est un protocole simple et il est utilisé pour lequel les codecs sont pris en charge dans les navigateurs. Par exemple, supposons qu'il y a deux pairs ( Client A et Client B) qui seront connectés via WebRTC. Client A et Client B créez des chaînes SDP qui définissent les codecs pris en charge. Par exemple, Client A peut prendre en charge les codecs H264, VP8 et VP9 pour la vidéo, les codecs Opus et PCM pour l'audio. Client B peut prendre en charge uniquement H264 pour la vidéo et uniquement le codec Opus pour l'audio. Dans ce cas, les codecs qui seront utilisés entre Client A et Client B sont H264 et Opus. S'il n'y a pas de codecs communs entre homologues, la communication d'égal à égal ne peut pas être établie.
Vous pouvez avoir une question sur la façon dont ces chaînes SDP sont envoyées entre elles. C'est là que le serveur de signalisation a lieu.
ICE (établissement de connexion d'interactivité)
ICE est la magie qui établit la connexion entre pairs, même s'ils sont derrière NAT. Supposons à nouveau Client A et Client B se connecteront et examineront comment ICE est utilisé pour cela.
Client A découvre leur adresse locale et leur adresse Internet publique en utilisant le serveur STUN et envoie ces adresses à Client B via le serveur de signalisation. Chaque adresse reçue du serveur STUN est appelée ICE candidate
![]()
Dans l'image ci-dessus, il y a deux serveurs. L'un d'eux est STUN et l'autre est le serveur TURN.
Le serveur STUN est utilisé pour laisser Client A apprendre toutes ses adresses. Permettez-moi de donner un exemple pour cela, nos ordinateurs ont généralement une adresse locale dans le réseau 192.168.0.0 et il y a une deuxième adresse que nous voyons lorsque nous nous connectons à www.whatismyip.com , cette adresse IP est en fait l'adresse IP publique de notre passerelle Internet (modem, routeur, etc.) définissons donc le serveur STUN; Les serveurs STUN permettent aux pairs de connaître leurs adresses IP publiques et locales. Btw, Google fournit un serveur STUN gratuit (stun.l.google.com:19302).
Il y a un autre serveur, TURN Server, dans l'image. TURN Server est utilisé lorsque la connexion poste à poste ne peut pas être établie entre pairs. Le serveur TURN relaie simplement les données entre pairs.
Client B fait de même, obtient les adresses IP locales et publiques du serveur STUN et envoie ces adresses à Client A via le serveur de signalisation.
Client A reçoit Client B et essaie chaque adresse IP en envoyant des pings spéciaux afin de créer une connexion avec Client B. Si Client A reçoit une réponse de n'importe quelle adresse IP, il place cette adresse dans une liste avec son temps de réponse et d'autres informations d'identification de performance. Enfin Client A choisissez les meilleures adresses en fonction de ses performances.
Client B fait de même pour se connecter à Client A
RTP (Real Time Protocol)
RTP est un protocole mature pour la transmission de données en temps réel. Il est basé sur UDP. Le son et la vidéo sont transmis avec RTP dans WebRTC. Il existe un protocole frère de RTP dont le nom est RTCP (Real-time Control Protocol) qui fournit la QoS dans RTP communication. RTP est également utilisé dans RTSP (Real-time Streaming Protocol)
Serveur de signalisation
La dernière partie est le serveur de signalisation qui n'est pas défini dans WebRTC. Comme mentionné ci-dessus, Signaling Server est utilisé pour envoyer des chaînes SDP et des candidats ICE entre Client A et Client B. Le serveur de signalisation décide également quels homologues sont connectés les uns aux autres. La technologie WebSocket est généralement utilisée dans les serveurs de signalisation pour la communication.
Compatibilité
Au cours de la dernière année, tous les navigateurs, y compris Safari, Edge, ont publié de nouvelles versions prenant en charge WebRTC. Chrome, Firefox et Opera ont déjà pris en charge WebRTC pendant un certain temps. Le codec vidéo commun aux navigateurs est H264. Pour l'audio, Opus est courant dans les navigateurs. PCM peut également être utilisé pour l'audio codec mais AAC n'est pas utilisé même si AAC est pris en charge dans tous les navigateurs en raison de problèmes de licence. Les caméras IP prennent généralement en charge H264 pour le codec vidéo et PCM ou AAC pour le codec audio.
Lectures complémentaires et références
- exemples WebRTC
- Wikipedia ICE
- SDP
- RTP RFC
- Premiers pas avec WebRTC
- WebRTC.org
- Serveur STUN
- Wikipedia RTSP
Btw, je suis développeur chez Ant Media Server qui prend en charge une connexion WebRTC évolutive un-à-plusieurs et peer-to-peer WebRTC