Fonctionnement de JS: communications WebRTC et P2P

Aujourd'hui, nous publions une traduction de la partie 18 d'une série de documents dédiés à tout ce qui concerne JavaScript. Nous parlerons ici de la technologie WebRTC, qui vise à organiser l'échange de données direct entre les applications de navigateur en temps réel.

Revue

Qu'est-ce que WebRTC? Pour commencer, il convient de noter que l'abréviation RTC signifie Real Time Communication (communication en temps réel). Cela donne à lui seul beaucoup d'informations sur cette technologie.

WebRTC occupe une niche très importante parmi les mécanismes de la plate-forme Web. Auparavant, les technologies P2P (connexions peer-to-peer, point à point, réseaux peer-to-peer, peer-to-peer) utilisées par des applications telles que les chats de bureau leur offraient des opportunités que les projets Web n'avaient pas. WebRTC fait une différence pour les technologies Web.

WebRTC, si nous regardons cette technologie en termes généraux, permet aux applications Web de créer des connexions P2P, dont nous discuterons ci-dessous. De plus, nous couvrirons ici les sujets suivants afin de montrer l'image complète de la structure interne de WebRTC:

• Communications P2P.
• Pare-feu et technologie NAT Traversal.
• Signalisation, sessions et protocoles.
• API WebRTC

Communications P2P

Supposons que deux utilisateurs aient lancé, chacun dans leur propre navigateur, une application qui vous permet d'organiser un chat vidéo à l'aide de WebRTC. Ils veulent établir une connexion P2P. Une fois la décision prise, nous avons besoin d'un mécanisme permettant aux navigateurs des utilisateurs de se retrouver et d'établir une communication en tenant compte des mécanismes de protection des informations disponibles dans les systèmes. Après avoir établi une connexion, les utilisateurs pourront échanger des informations multimédias en temps réel.

L'une des principales difficultés associées aux connexions P2P des navigateurs est que les navigateurs doivent d'abord se découvrir, puis établir une connexion réseau basée sur des sockets pour assurer un transfert de données bidirectionnel. Nous vous suggérons de discuter des difficultés liées à l'installation de telles connexions.

Lorsqu'une application Web a besoin de données ou de ressources, elle les télécharge depuis le serveur et c'est tout. L'adresse du serveur est connue de l'application. Si nous parlons, par exemple, de créer un chat P2P, dont le fonctionnement est basé sur la connexion directe de navigateurs, les adresses de ces navigateurs ne sont pas connues à l'avance. Par conséquent, pour établir une connexion P2P, vous devrez faire face à certains problèmes.

Pare-feu et protocole NAT Traversal

En règle générale, les ordinateurs IP externes statiques ne sont pas affectés à des ordinateurs ordinaires. La raison en est que ces ordinateurs sont généralement situés derrière des pare-feu et des périphériques NAT.

NAT est un mécanisme qui traduit les adresses IP locales internes situées derrière un pare-feu en adresses IP globales externes. La technologie NAT est utilisée, d'une part, pour des raisons de sécurité, et d'autre part, en raison des restrictions imposées par IPv4 sur le nombre d'adresses IP globales disponibles. C'est pourquoi les applications Web utilisant WebRTC ne doivent pas se fier au fait que le périphérique actuel possède une adresse IP statique globale.

Voyons comment fonctionne NAT. Si vous êtes sur un réseau d'entreprise et connecté au WiFi, votre ordinateur se verra attribuer une adresse IP qui existe uniquement derrière votre appareil NAT. Supposons qu'il s'agisse de l'adresse IP 172.0.23.4. Pour le monde extérieur, cependant, votre adresse IP peut ressembler à 164.53.27.98. En conséquence, le monde extérieur considère vos demandes comme provenant de l'adresse 164.53.27.98, mais grâce à NAT, les réponses aux demandes faites par votre ordinateur à des services externes seront envoyées à votre adresse interne 172.0.23.4. Cela se produit à l'aide de tables de traduction. Veuillez noter qu'en plus de l'adresse IP, un numéro de port est également requis pour la mise en réseau.

Étant donné que NAT est impliqué dans le processus d'interaction de votre système avec le monde extérieur, votre navigateur, afin d'établir une connexion WebRTC, doit connaître l'adresse IP de l'ordinateur sur lequel le navigateur que vous souhaitez communiquer s'exécute.

C'est là que les serveurs STUN (Session Traversal Utilities for NAT) et TURN (Traversal Using Relays around NAT) entrent en scène. Pour garantir le fonctionnement de la technologie WebRTC, une demande est d'abord faite au serveur STUN pour connaître votre adresse IP externe. En fait, nous parlons d'une requête adressée à un serveur distant afin de savoir à partir de quelle adresse IP le serveur reçoit cette requête. Après avoir reçu une demande similaire, le serveur distant enverra une réponse contenant l'adresse IP visible pour lui.

En supposant que ce système est opérationnel et que vous avez reçu des informations sur votre adresse IP externe et votre port, vous pouvez alors dire aux autres participants au système (nous les appellerons pairs) comment vous contacter directement. Ces homologues peuvent également faire de même en utilisant des serveurs STUN ou TURN et peuvent vous dire quelles adresses leur sont attribuées.

Signalisation, sessions et protocoles

Le processus de recherche d'informations sur le réseau, décrit ci-dessus, fait partie d'un grand système de signalisation qui, dans le cas de WebRTC, est basé sur la norme JSEP (JavaScript Session Establishment Protocol). La signalisation comprend la découverte de ressources réseau, la création et la gestion de sessions, la sécurité des communications, la coordination des paramètres des médias, la gestion des erreurs.

Pour que la connexion fonctionne, les pairs doivent s'entendre sur les formats de données qu'ils échangeront et collecter des informations sur les adresses réseau de l'ordinateur sur lequel l'application s'exécute. Le mécanisme de signalisation pour partager ces informations critiques ne fait pas partie de l'API WebRTC.

La signalisation n'est pas définie par la norme WebRTC, et elle n'est pas implémentée dans son API afin d'offrir une flexibilité dans les technologies et protocoles utilisés. La signalisation et les serveurs qui la supportent sont à la charge du développeur de l'application WebRTC.

En supposant que votre application WebRTC exécutée dans le navigateur est capable de déterminer l'adresse IP externe du navigateur à l'aide de STUN, comme décrit ci-dessus, l'étape suivante consiste à discuter des paramètres de session et à établir une connexion avec un autre navigateur.

La discussion initiale des paramètres de session et l'établissement d'une connexion se fait à l'aide d'un protocole de signalisation / communication spécialisé dans les communications multimédias. Ce protocole est, en outre, responsable du respect des règles selon lesquelles la session est gérée et terminée.

L'un de ces protocoles est appelé SIP (Session Initiation Protocol). Veuillez noter qu'en raison de la flexibilité du sous-système de signalisation WebRTC, SIP n'est pas le seul protocole de signalisation qui peut être utilisé. De plus, le protocole de signalisation sélectionné doit fonctionner avec un protocole de couche d'application appelé SDP (Session Description Protocol), qui est utilisé lors de l'utilisation de WebRTC. Toutes les métadonnées liées aux données multimédias sont transmises à l'aide du protocole SDP.

Tout homologue (c'est-à-dire une application utilisant WebRTC) qui essaie de contacter un autre homologue génère un ensemble de routes candidates pour le protocole ICE (Interactive Connectivity Establishment). Les candidats représentent une combinaison d'adresse IP, de port et de protocole de transport qui peut être utilisée. Veuillez noter qu'un ordinateur peut avoir de nombreuses interfaces réseau (filaire, sans fil, etc.), de sorte qu'il peut se voir attribuer plusieurs adresses IP, une pour chaque interface.

Voici un diagramme avec MDN illustrant le processus ci-dessus d'échange de données.

Le processus d'échange de données nécessaire pour établir une connexion P2P

Établir une connexion

Chaque pair découvre d'abord son adresse IP externe comme décrit ci-dessus. Ensuite, des «canaux» de données de signalisation sont créés dynamiquement, qui servent à détecter les homologues et à soutenir l'échange de données entre eux, pour discuter des paramètres de session et de leur installation.

Ces «canaux» sont inconnus et inaccessibles au monde extérieur, un identifiant unique est nécessaire pour y accéder.

Veuillez noter qu'en raison de la flexibilité de WebRTC et du fait que le processus de signalisation n'est pas défini par la norme, le concept de «canaux» et l'ordre de leur utilisation peuvent varier légèrement selon les technologies utilisées. En fait, certains protocoles ne nécessitent pas de mécanisme de «canal» pour organiser l'échange de données. Aux fins de ce document, nous supposons que les "canaux" dans la mise en œuvre du système sont utilisés.

Si deux ou plusieurs homologues sont connectés au même «canal», les homologues ont la possibilité d'échanger des données et de discuter des informations de session. Ce processus est similaire à un modèle éditeur-abonné . En général, l'homologue initiant la connexion envoie une «offre» à l'aide d'un protocole de signalisation tel que SIP ou SDP. L'initiateur s'attend à recevoir une «réponse» du destinataire de la proposition, qui est connectée au «canal» considéré.

Une fois la réponse reçue, le processus de détermination et de discussion des meilleurs candidats ICE recueillis par chaque fête a lieu. Une fois les candidats ICE optimaux sélectionnés, les paramètres de données qui seront échangés entre homologues et le mécanisme de routage du réseau (adresse IP et port) sont convenus.

Ensuite, une session de socket réseau active est établie entre pairs. En outre, chaque homologue crée des flux de données locaux et des points d'extrémité des canaux de données, et la transmission bidirectionnelle des données multimédias commence à utiliser la technologie appliquée.

Si le processus de négociation pour choisir le meilleur candidat ICE échoue, ce qui se produit parfois en raison de la défaillance des pare-feu et des systèmes NAT, une option de sauvegarde est utilisée, qui consiste à utiliser, comme relais, un serveur TURN. Ce processus implique un serveur qui agit comme un intermédiaire qui relaie les données échangées entre pairs. Veuillez noter que ce schéma n'est pas une véritable connexion P2P dans laquelle les pairs se transmettent directement des données.

Lors de l'utilisation d'une solution de repli utilisant TURN pour l'échange de données, chaque pair n'a plus besoin de savoir comment communiquer avec les autres et comment y transférer des données. Au lieu de cela, les pairs doivent savoir quel serveur TURN externe doit envoyer des données multimédias en temps réel et à partir de quel serveur ils doivent recevoir pendant la session de communication.

Il est important de comprendre qu'il s'agissait désormais d'un moyen de secours pour organiser les communications. Les serveurs TURN doivent être très fiables, avoir une large bande passante et une puissance de calcul sérieuse, prendre en charge le travail avec des quantités potentiellement importantes de données. L'utilisation d'un serveur TURN entraîne donc évidemment des surcoûts et une augmentation de la complexité du système.

API WebRTC

Il existe trois catégories principales d'API qui existent dans WebRTC:

• L'API Media Capture and Streams est responsable de la capture et de la diffusion multimédia. Cette API vous permet de vous connecter à des périphériques d'entrée, tels que des microphones et des webcams, et d'en recevoir des flux multimédias.
• API RTCPeerConnection En utilisant l'API de cette catégorie, il est possible, à partir d'un point de terminaison de WebRTC, d'envoyer, en temps réel, le flux capturé de données audio ou vidéo via Internet à un autre point de terminaison de WebRTC. À l'aide de cette API, vous pouvez créer des connexions entre la machine locale et l'homologue distant. Il fournit des méthodes de connexion à un homologue distant, de gestion de la connexion et de surveillance de son état. Ses mécanismes sont utilisés pour fermer les connexions inutiles.
• API RTCDataChannel Les mécanismes représentés par cette API permettent le transfert de données arbitraires. Chaque canal de données est associé à une interface RTCPeerConnection.

Parlons de ces API.

Capture et flux de médias API

L'API Media Capture and Streams, souvent appelée API Media Stream ou Stream API, est une API qui prend en charge l'utilisation de flux de données audio et vidéo, des méthodes pour les utiliser. En utilisant cette API, vous pouvez définir des restrictions liées aux types de données, ici il existe des rappels pour la réussite et l'échec des opérations qui sont utilisées lors de l'utilisation de mécanismes asynchrones pour travailler avec des données, et des événements qui sont déclenchés pendant le fonctionnement.

La méthode getUserMedia() de l'API getUserMedia() demande à l'utilisateur l'autorisation de travailler avec des périphériques d'entrée qui produisent des flux MediaStream avec des pistes audio ou vidéo contenant les types de médias demandés. Un tel flux peut inclure, par exemple, une piste vidéo (sa source est une source vidéo matérielle ou virtuelle, telle qu'une caméra, un enregistreur vidéo, un service de partage d'écran, etc.), une piste audio (des sources audio physiques ou virtuelles peuvent également la former, comme un microphone, un convertisseur analogique-numérique, etc.) et éventuellement d'autres types de pistes.

Cette méthode renvoie la promesse qui se résout en l'objet MediaStream . Si l'utilisateur rejette la demande d'autorisation ou si le média correspondant n'est pas disponible, la promesse sera résolue, respectivement, avec une NotFoundError PermissionDeniedError ou NotFoundError .

Vous pouvez accéder au singleton MediaDevice via l'objet navigator :

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

Notez que lorsque vous appelez la méthode getUserMedia() , vous devez lui passer un objet de constraints qui indique à l'API quel type de flux il doit retourner. Ici, vous pouvez configurer beaucoup de choses, y compris la caméra que vous souhaitez utiliser (avant ou arrière), la fréquence d'images, la résolution, etc.

À partir de la version 25, les navigateurs basés sur Chromium vous permettent de transférer l'audio de getUserMedia() des éléments audio ou vidéo (cependant, notez que les éléments multimédias seront désactivés par défaut).

La méthode getUserMedia() peut également être utilisée comme nœud d'entrée pour l'API Web Audio :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

Limitations liées à la protection des informations personnelles

La capture non autorisée de données à partir d'un microphone ou d'une caméra est une grave interférence avec la vie personnelle de l'utilisateur. Par conséquent, l'utilisation de getUserMedia() prévoit la mise en œuvre d'exigences très spécifiques pour informer l'utilisateur de ce qui se passe et pour gérer les autorisations. La méthode getUserMedia() doit toujours obtenir la permission de l'utilisateur avant d'ouvrir tout périphérique d'entrée qui collecte des médias, comme une webcam ou un microphone. Les navigateurs peuvent offrir la possibilité de définir une autorisation unique pour un domaine, mais ils sont tenus de demander l'autorisation au moins la première fois qu'ils accèdent aux périphériques multimédias, et l'utilisateur doit explicitement accorder cette autorisation.

De plus, les règles relatives à la notification à l'utilisateur de ce qui se passe sont importantes ici. Les navigateurs doivent afficher un indicateur qui indique l'utilisation d'un microphone ou d'une caméra. L'affichage d'un tel indicateur ne dépend pas de la présence dans le système d'indicateurs matériels indiquant le fonctionnement de tels dispositifs. En outre, les navigateurs doivent afficher un indicateur indiquant que l'autorisation d'utiliser le périphérique d'entrée a été accordée, même si le périphérique n'est pas utilisé à un moment donné pour enregistrer les données pertinentes.

Interface RTCPeerConnection

L'interface RTCPeerConnection est une connexion WebRTC entre l'ordinateur local et l'homologue distant. Il fournit des méthodes pour se connecter à un système distant, pour prendre en charge la connexion et surveiller son état, et pour fermer la connexion une fois qu'elle n'est plus nécessaire.

Voici un diagramme d'architecture WebRTC illustrant le rôle de RTCPeerConnection.


Rôle RTCPeerConnection

Du point de vue JavaScript, la principale connaissance qui peut être tirée de l'analyse de ce diagramme est que RTCPeerConnection isole le développeur Web des mécanismes complexes situés aux niveaux les plus profonds du système. Les codecs et protocoles utilisés par WebRTC font un excellent travail afin de permettre l'échange de données en temps réel, même lors de l'utilisation de réseaux non fiables. Voici quelques-unes des tâches résolues par ces mécanismes:

• Masquage de la perte de paquets.
• Annulation d'écho.
• Adaptation de la bande passante.
• Mise en mémoire tampon dynamique pour éliminer la gigue.
• Contrôle automatique du volume.
• Réduction et suppression du bruit.
• "Nettoyage" de l'image.

API RTCDataChannel

Comme pour les données audio et vidéo, WebRTC prend en charge la transmission en temps réel d'autres types de données. L'API RTCDataChannel vous permet d'organiser un échange P2P de données arbitraires.

Il existe de nombreux scénarios d'utilisation de cette API. En voici quelques uns:

• Jeux
• Conversations textuelles en temps réel.
• Transfert de fichiers.
• Organisation de réseaux décentralisés.

Cette API vise à l'utilisation la plus efficace des capacités de l'API RTCPeerConnection et vous permet d'organiser un système d'échange de données puissant et flexible dans un environnement P2P. Ses caractéristiques sont notamment les suivantes:

• Travail efficace avec des sessions utilisant RTCPeerConnection.
• Prise en charge de plusieurs canaux de communication utilisés simultanément avec hiérarchisation.
• Prise en charge de méthodes fiables et peu fiables de remise des messages.
• Gestion de la sécurité intégrée (DTLS) et congestion.

La syntaxe ici est similaire à celle utilisée lors de l'utilisation de la technologie WebSocket. La méthode send() et l'événement message sont appliqués ici:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC dans le monde réel

Dans le monde réel, la communication WebRTC nécessite des serveurs. Les systèmes ne sont pas trop compliqués; grâce à eux, la séquence d'actions suivante est mise en œuvre:

• Les utilisateurs se découvrent et échangent des informations les uns sur les autres, par exemple des noms.
• Les applications client (pairs) WebRTC échangent des informations sur le réseau.
• Les pairs échangent des informations sur les données multimédias, telles que le format vidéo et la résolution.
• Les applications client WebRTC établissent une connexion en contournant les passerelles NAT et les pare-feu.

En d'autres termes, WebRTC a besoin de quatre types de fonctions serveur:

• Des moyens pour découvrir les utilisateurs et organiser leur interaction.
• Signalisation.
• Bypass NAT et pare-feu.
• Serveurs relais utilisés lorsqu'une connexion P2P ne peut pas être établie.

Le protocole STUN et son extension TURN sont utilisés par ICE pour permettre à RTCPeerConnection de fonctionner avec les mécanismes de contournement NAT et de faire face aux autres difficultés rencontrées lors de la transmission de données sur un réseau.

Comme déjà mentionné, ICE est un protocole pour connecter des pairs, comme deux clients de chat vidéo. Au tout début de la session de communication, ICE essaie de connecter les pairs directement, avec le moins de retard possible, via UDP. Au cours de ce processus, les serveurs STUN ont une seule tâche: laisser l'homologue derrière NAT apprendre son adresse publique et son port. Jetez un œil à cette liste de serveurs STUN disponibles (Google a également de tels serveurs).


Serveurs STUN

Détection des candidats ICE

Si la connexion UDP ne peut pas être établie, ICE essaie d'établir une connexion TCP: d'abord - sur HTTP, puis - sur HTTPS. Si une connexion directe ne peut pas être établie - en particulier, en raison de l'impossibilité de contourner les NAT et les pare-feu d'entreprise, ICE utilise un intermédiaire (relais) sous la forme d'un serveur TURN. En d'autres termes, ICE essaiera d'abord d'utiliser STUN avec UDP pour la connexion directe des pairs, et si cela ne fonctionne pas, il utilisera une option de secours avec un locataire sous la forme d'un serveur TURN. Le terme «recherche de candidats» fait référence au processus de recherche d'interfaces réseau et de ports.


Recherche d'interfaces et de ports réseau appropriés

La sécurité

Les applications de communication en temps réel ou les plugins associés peuvent entraîner des problèmes de sécurité. En particulier, nous parlons de ce qui suit:

• Les données multimédias non chiffrées ou d'autres données peuvent être interceptées le long du chemin entre les navigateurs, ou entre un navigateur et un serveur.
• Une application peut, à l'insu de l'utilisateur, enregistrer et transmettre des données vidéo et audio à un attaquant.
• Associé à un plug-in ou une application inoffensif, un virus ou un autre logiciel malveillant peut pénétrer dans l'ordinateur de l'utilisateur.

WebRTC dispose de plusieurs mécanismes conçus pour faire face à ces menaces:

• Les implémentations WebRTC utilisent des protocoles sécurisés comme DTLS et SRTP .
• Pour tous les composants des systèmes WebRTC, l'utilisation du chiffrement est obligatoire. Cela s'applique également aux mécanismes de signalisation.
• WebRTC n'est pas un plugin. Les composants WebRTC s'exécutent dans le sandbox du navigateur, et non dans un processus distinct. Les composants sont mis à jour lorsque le navigateur est mis à jour.
• L'accès à la caméra et au microphone doit être donné explicitement. Et, lorsqu'une caméra ou un microphone est utilisé, ce fait est clairement affiché dans l'interface utilisateur du navigateur.

Résumé

WebRTC est une technologie très intéressante et puissante pour les projets qui utilisent le transfert de toutes les données entre les navigateurs en temps réel. L'auteur du document dit que sa société, SessionStack , utilise des mécanismes traditionnels pour échanger des données avec les utilisateurs, impliquant l'utilisation de serveurs. Cependant, s'ils utilisaient WebRTC pour résoudre les problèmes correspondants, cela permettrait d'organiser l'échange de données directement entre les navigateurs, ce qui entraînerait une diminution du retard dans le transfert de données et réduirait la charge sur l'infrastructure de l'entreprise.

Chers lecteurs! Utilisez-vous la technologie WebRTC dans vos projets?