Utilisateur:Feyd-Aran/Brouillon

Une page de Wikipédia, l'encyclopédie libre.
Fichier:Logo-webrtc.png
logo WebRTC

WebRTC est une API JavaScript visant à normaliser les échanges de médias (audios ou vidéos) ainsi que de données en peer-to-peer entre navigateurs web. Ce standard informatique est développé conjointement depuis 2011 par le World Wide Web Consortium (W3C) et l'Internet Engineering Task Force (IETF).

L'API repose sur une architecture triangulaire puis pair à pair dans laquelle un serveur central est utilisé pour mettre en relation deux pairs désirant échanger des flux de médias ou de données qui échangent ensuite sans autre relais. Cette architecture et la pile de protocoles utilisée pose des questions de sécurité et d'utilisation en relation avec d'autres technologies (comme les NAT ou les pare-feux) qui sont pour la plupart en cours de résolution par l'IETF et le W3C.

Historique[modifier | modifier le code]

Les échanges directs entre navigateurs ne sont pas une nouveauté introduite par le W3C et l'IETF mais les recherches et implémentations précédentes n'étaient pas standards (à cause de l'utilisation de plugins propriétaires tels qu'Adobe Flash ou Microsoft ActiveX) et souvent mal documentées[1]. Ces protocoles et plugins furent à la source de difficultés d'interopérabilité et de mise à jour pour les sites utilisant ces systèmes. Bien que ces implémentations permettaient une utilisation allant jusqu'à la vidéoconférence (telle que celle proposée par Adobe avec le Real Time Media Flow Protocol[2]) , elles reposaient sur des plugins propriétaires et en étaient donc dépourvues de standards[3].

Les applications internet riches étant perçues comme une évolution naturelle ses pages web statiques, ces applications ont rapidement offert la possibilité d'héberger des animations de texte, des dessins ou des fonctionalités de drag and drop mais aussi un streaming audio et vidéo bidirectionnel[4].

Adobe Flash, Oracle JavaFX ou Microsoft Silverlight détenaient, en 2011, environ 50% du marché que représentaient ces applications[5].

Malgré les efforts de standardisation menés par le W3C et l'IETF, d'autres entreprises continuent de développer leurs propres standards en parallèle, telles que Microsoft avec URCP (Universal Rate Control Protocol)[6].

Le standard WebRTC[modifier | modifier le code]

Le standard WebRTC a pour objectif de permettre l'échange de flux audios, vidéos ou de données entre navigateurs sans utiliser de plugin extérieur. L'API permet une implémentation simple et rapide et une utilisation aisée de l'audio et de la vidéo[7].

Description générale de la norme[modifier | modifier le code]

Architecture d'une application WebRTC

L'architecture de l'API WebRTC repose sur une construction triangulaire impliquant un serveur et deux pairs[3]. Les deux navigateurs téléchargent depuis un serveur une application JavaScript vers leur contexte local. Le serveur est utilisé comme point de rendez vous afin de coordonner les échanges entre navigateurs jusqu'à ce que la connexion directe entre navigateurs soit établie. L'application téléchargée utilise l'API WebRTC pour communiquer avec le contexte local. Le but est d'avoir une application cliente en JavaScript et HTML5 interagissant avec le navigateur au travers de l'API WebRTC[3].

Les flux d'échanges entre navigateurs peuvent rencontrer divers serveurs qui se chargeront de modifier, traduire ou gérer le signal au besoin, permettant par exemple la traversée de Firewalls, proxys ou NAT[8].

Afin d'établir une connexion utilisant le standard WebRTC, les navigateurs A et B doivent être connectés simultanément à la page du service et télécharger la page HTML ainsi que le code JavaScript permettant de maintenir la connexion ouverte par HTTPS ou socket. Lorsque le navigateur A souhaite établir la connexion avec B, l'API instancie un objet PeerConnection qui, une fois créé, permet d'établir des flux de médias ou de données. Il est aussi nécessaire, pour une vidéoconférence par exemple, que les utilisateurs A et B acceptent le partage de leur webcam et/ou de leur microphone.

Une fois cet objet PeerConnection créé par A, le navigateur envoie au serveur un paquet contenant les informations sur les médias partagés ainsi qu'une empreinte liant la connexion à A. Le serveur va décoder ce paquet et identifier qu'il s'agit d'une communication à destination de B et enverra donc un signal à B. B est notifié du souhait de A d'établir une connexion et accepte ou non sa requête. Si elle est acceptée, le même processus a lieu entre B et A cette fois afin d'établir la connexion bidirectionnelle. Une fois celle ci établie, les flux de médias ou de données peuvent être ajoutés à la connexion librement.

Dans le cadre par exemple d'un streaming vidéo en peer-to-peer entre navigateurs, l'utilisateur télécharge depuis un serveur les métadonnées de la vidéo qu'il souhaite regarder ainsi qu'une liste de pairs disponibles et ayant tout ou partie de la vidéo. L'établissement d'une connexion avec les pairs permet, par le flux de données, le téléchargement des morceaux de la vidéo qui sont réassemblés après vérification de leur intégrité puis lancement de la vidéo dans un lecteur HTML5[9].

L'API WebRTC[modifier | modifier le code]

L'API WebRTC est centrée autour de trois concepts principaux: PeerConnection, MediaStreams et DataChannel [10] et repose sur une pile de protocoles pour la plupart préexistants tels que (entre autres) UDP, ICE ou STUN.

PeerConnection[modifier | modifier le code]

Un objet PeerConnection représente le lien établi avec un navigateur distant, reposant sur le protocole UDP (habituellement une autre instance de l'application JavaScript tournant sur le client). Afin d'établir cette connexion pair à pair, il est nécessaire de s'appuyer sur un canal de communication établi par un serveur web et utilisant par exemple un objet XMLHttpRequest ou une WebSocket[10].

Pour obtenir une connexion, l'un des pair doit obtenir les informations locales (telles que les protocoles supportés pour l'audio ou la vidéo). Cette étape est permise par l'API via le protocole de description de session SDP. SDP se base sur la RFC 3264[11] de l'IETF définissant une approche requête / réponse. Lors de l'établissement d'une session, un pair crée une requête qui décrit ce qu'il désire faire et l'autre répond en spécifiant les options qui ont été sélectionnées[12]. Néanmoins, l'utilisation de SDP est en cours de remplacement au sein de la norme WebRTC par le protocole JSEP (JavaScript Session Establishment Protocol), notamment à cause des problèmes posés par le format de transmission de SDP, le blob d'information[13].

Dans le cadre de WebRTC, l'échange de ces requêtes et réponses par SDP se fait par un mécanisme laissé au choix de l'implémentation (typiquement un serveur Web utilisant une socket)[14],[5].

Ce processus utilisant SDP permet la négociation à la fois pour RTP (transport de médias) et pour SCTP (permettant le transport de données).

Afin d'assurer le passage au travers des NAT ou des parefeux, l'objet PeerConnection utilise les protocoles STUN et ICE[14]. En outre, l'utilisation d'UDP est privilégiée dans la mesure où il s'agit du protocole ayant la meilleure chance de traverser les NAT et pare-feux.

Une fois cette connexion pair à pair établie, chaque parti peut établir des MediaStreams ou DataStreams l'utilisant.

Data streams[modifier | modifier le code]

Schéma decrivant la pile de protocoles utilisé lors d'un échange de données via WebRTC.

Le canal de données offre un moyen d'échange de données génériques bidirectionnel et pair à pair[10].

Ces canaux de données sont créés entre pairs en utilisant l'objet PeerConnection. Ces données autres que les flux médias sont échangées via le protocole SCTP, lui-même encapsulé dans DTLS. Cette solution permet une interaction aisée avec les flux médias encapsulés parallèlement et le partage de la même couche transport par le même numéro de port.

SCTP supporte nativement plusieurs flux de données de façon bidirectionnel (jusqu'à 65536 dans chaque direction) au sein d'une association SCTP et gère les priorités. De cette façon, il est possible de favoriser les messages de haute priorité face aux gros objets à la priorité basse. Chaque flux représente une connexion logique unidirectionnelle[12].

Afin d'assurer la confidentialité et l'authenticité des paquets SCTP échangés, chaque flux repose sur le protocole DTLS.

Au sein d'un canal de données, les applications peuvent transmettre des messages de façon ordonnée ou désordonnée. L'ordre de remise est préservé uniquement dans le cas d'une transmission de paquets ordonnés envoyés sur le même lien de données.

Un flux de données est créé lorsque l'un des pairs appelle une méthode CreateDataChannel() pour la première foi après avoir créé un objet PeerConnection. Chaque appel suivant à CreateDataChannel() créera un nouveau flux de données au sein de la connexion SCTP existante[10].

Le protocole DTLS n'a pas pour seul rôle d'encapsuler les paquets SCTP. Dans le cadre d'un multiplexage avec des flux médias, le protocole DTLS encapsule la gestion des clés et la négotiation des paramètres pour le protocole SRTP, utilisé pour la gestion des flux médias. Il y a donc dépendance du flux média vis à vis du flux de données[15].

Media streams[modifier | modifier le code]

Schéma decrivant la pile de protocoles utilisé lors d'un échange de médias via WebRTC.

Un MediaStream est une représentation d'un flux de données spécifique audio ou vidéo. Il permet la prise en charge des actions sur le flux média telles que l'affichage, l'enregistrement et l'envoi à un pair distant. Un MediaStream peut être local ou distant.

Afin d'être utilisé, un MediaStream local doit demander l'accès aux ressources multimédia de l'utilisateur via la fonction getUserMedia(). L'application spécifie le type de média (audio ou vidéo) auquel elle souhaite accéder et le navigateur autorise ou refuse l'accès à la ressource demandée. Une fois que le média n'est plus utilisé, l'application peut révoquer son propre accès avec la méthode stop() sur le flux média local[10].

Les flux médias sont transportés par le biais du protocole RTP, utilisable sur tout protocole de transport implémentant une abstraction de datagram (UDP par exemple). La confidentialité, authentification des messages et la protection contre les répétitions est apportée par l'utilisation sécurisée de RTP, SRTP.

La gestion des clés pour SRTP est assurée par DTLS et donc le flux de données. Il est donc impossible d'avoir un flux média indépendant d'un flux de données là où l'inverse est envisageable.

Il est possible d'associer plusieurs flux médias sur une même connexion SRTP qui utiliseront des ressources médias différentes ou non. Dans ce cas, les sources de chaque flux sont clairement identifiées comme des SSRC[12].

Multiplexage media / data[modifier | modifier le code]

L'API WebRTC prévoit le multiplexage de flux données ou média reposant sur une seule connexion de niveau transport. Ce multiplexage fait que les trois protocoles STUN, SRTP et DTLS coexistent au même niveau du modèle et qu'il est nécessaire de démultiplexer les paquets arrivant. Pour cela, le premier octet indiquant la nature du contenu UDP sert à déterminer de quel protocole il s'agit[16]. Une valeur de 0 ou 1 indique un paquet STUN, une valeur entre 20 et 63 indique un paquet DTLS une valeur de 128 à 191 indique un paquet SRTP.

L’intérêt principal de ce multiplexage est qu'il facilite le passage par NAT ou pare-feux en évitant par exemple qu'un paquet média ne soit bloqué alors qu'un paquet de données ne puisse passer[16].

Problèmes posés par WebRTC et solutions potentielles[modifier | modifier le code]

Sécurité des applications[modifier | modifier le code]

Article détaillé : Sécurité des systèmes d'information.

Plusieurs problèmes de sécurité se posent lors de l'utilisation de WebRTC:

  • JavaScript peut être téléchargé depuis n'importe quel site sans consentement de l'utilisateur.
  • Les utilisateurs doivent pouvoir être capables de donner leur agrément à l'utilisation de ressources médias locales comme les caméras et microphones.
  • La confidentialité et l'authentification doivent être garantis dans tout échange pour éviter les attaques telles que l'attaque de l'homme du milieu.
  • Les informations privées de l'utilisateur ne doivent pas être dévoilées à des tiers sans le consentement de celui ci.

Si certains de ces problèmes sont inhérents à toute communication sur l'Internet, d'autres problèmes ont été résolus par l'implémentation de WebRTC. Ainsi les échanges de médias sont sécurisés par le protocole SRTP[12].

Gérer la perte de paquets[modifier | modifier le code]

Le protocole UDP étant déconnecté et n'utilisant pas de système de vérification de réception des paquets (contrairement au protocole TCP par exemple), la perte de paquets est un problème pouvant se poser lors des transmissions de pair à pair de flux médias. Deux méthodes se présentaient afin de limiter la perte de paquets dus aux problèmes de réseau:

  • NACK (Negative Acknowledgment) qui permet de signaler à l'émetteur une réception échouée ou l'absence de transmission.
  • FEC (Forward Error Correction), un code de contrôle qui permet au récepteur de vérifier que la totalité des paquets est arrivée correctement.
  • RPS (Reference Picture Selection)

Lors de l'envoi d'un flux média, l'émetteur découpe le flux et calcule une somme de contrôle (FEC) qui est envoyée avec ces paquets. A la réception, les FEC sont recalculés pour vérifier l'absence d'erreurs et les données stockées dans une mémoire tampon. Si des paquets manquent, ils sont redemandés.

Dans le cadre de l'API WebRTC, une solution hybride entre NACK et FEC a été implémentée, accompagnée de layers temporels afin d'équilibrer la qualité de la vidéo, sa fluidité et le temps de réponse d'une extrémité de la connexion à l'autre[17].

Ainsi, dans le cadre d'une transmission média, la mémoire tampon servant à la construction des images est de taille variable, dépendant de la longueur des paquets et de la fluidité de rendu optimale calculée par l'application. Du coté de l'émetteur, un optimisateur de flux calcule périodiquement la qualité du trafic sur le réseau et adapte dynamiquement la taille des paquets afin d'éviter au maximum collisions et pertes[18].

En outre, le calcul de FEC étant la partie la plus longue du processus, l'optimisation de flux permet d'en varier la fréquence, créant ainsi une FEC/NACK adaptative qui répond au mieux aux problèmes rencontrés durant la transmission.

Transiter par des firewalls ou le NAT[modifier | modifier le code]

Transiter au travers d'un firewall[modifier | modifier le code]

WebRTC peut être difficile à utiliser en entreprise dans la mesure où celles ci ont souvent des politiques de sécurité en informatique incompatibles avec les besoins de l'API. En effet, WebRTC est basé sur des flux peer-to-peer entre navigateurs et ces flux sont très sensibles à la latence lors qu'il s'agit de flux médias. En outre, les serveurs utilisés pour faire transiter les paquets peuvent être éloignés géographiquement des pairs qui communiquent ou avoir une bande passante trop faible pour permettre un transit correct des paquets.

Des approches existent déjà pour franchir un parefeux:

  • Le RTP symétrique est une implémentation de RTP basée sur UDP qui utilise les mêmes ports en entrée et en sortie, afin de simuler un flux bidirectionnel et éviter le blocage arbitraire de paquets.
  • Le protocole ICE, qui utilise des paquets de tests pour déterminer les règles de filtrage du parefeu et est aussi utilisé pour traverser un NAT.

Néanmoins les entreprises utilisent de plus en plus des SBC, des parefeux de niveau application, utilisant un contrôle des flux de signaux et médias (ALG). Ces SBC posent des difficultés pour WebRTC dans la mesure où le flux de signaux n'est pas standardisé par l'API et laissé libre de choix à l'implémentation. De plus, les SBC se placent comme intermédiaires dans la transmission du client vers le serveur, mais le protocole DTLS utilisé par WebRTC ne permet pas l'observation par un tiers de par son chiffrement. Enfin, les SBC utilisent les flux de signaux pour authentifier les flux de données, mais l'API WebRTC ne standardisant pas les flux de signaux, leur utilisation est impossible dans un but d'identification[19].

L'une des solutions pour venir à bout des difficultés posées par les SBC serait que les entreprises convertissent les flux entrant en sessions SIP, utilisent cette encapsulation pour traverser le SBC puis décapsulent le flux pour le transmettre à l'application. Cependant cette approche en man-in-the-middle est rendue difficile par la variété des utilisations de WebRTC et par le chiffrement des flux de contrôle et de média de l'API[19].

Transiter au travers d'un NAT[modifier | modifier le code]

Afin d'être utilisable si l'un des pairs se situe derrière un NAT , WebRTC utilise le protocole ICE. Deux technique principales sont utilisées pour traverser ce genre de difficultés.

  • La première technique est souvent appelée Hole Punching (en): l'appareil à l'intérieur du NAT envoie un paquet STUN à un serveur en dehors du NAT. Le serveur répond en informant l'envoyeur de l'adresse IP et du port apparent avec lequelle paquet a été envoyé, sur lequel les deux communiqueront.
  • La seconde technique utilise un relais intermédiaire. Le protocole utilisé pour cela est Traversal Using Relays around NAT (en) l'entreprise déploie un serveur TURN au sein de la zone démilitariése (DMZ) avec lequel le pair interne communique. Le serveur se charge de vérifier que ce pair a les droits requis et de surveiller les flux médias qui passent par lui, faisant ainsi de lui l'endroit idéal pour surveiller le trafic. Le serveur sert ainsi de point de relais aux paquets WebRTC qui transitent entre un pair et l'autre[20].

Etat actuel de la norme[modifier | modifier le code]

W3C et IETF[modifier | modifier le code]

La norme WebRTC est développée conjointement par le W3C et l'IETF afin de permettre aux navigateurs des communications temps réel en pair à pair. ces groupes travaillent en collaboration:

  • IETF prend en charge l'établissement de la liste des protocoles à utiliser.
  • Le W3C fournit l'API JavaScript implémentant ces protocoles et donne aux développeurs la possibilité de l'utiliser pour leurs applications[5].

Premières implémentations[modifier | modifier le code]

Un système de vidéoconférence utilisant l'API WebRTC pouvant accueillir jusqu'à 8 participants en simultanée.

Un site permettant le partage de fichiers en ligne

Un support inégal par les navigateurs[modifier | modifier le code]

Le standard étant récent, l'intégration au sein des différents navigateurs est encore limitée et à l'heure actuelle, seules les versions stables de Google Chrome, Mozilla Firefox et Opera proposent le support de l'API WebRTC[21].

L'API étant en outre conçue pour être indépendante du support, ces trois navigateurs sont capables de communiquer entre eux librement[22].

Pour l'instant, ni Safari ni Internet Explorer ne supportent la technologie[23],[21]. Cependant Microsoft a déjà exprimé sa volonté de proposer le support du standard pour une future version d'Internet Explorer là où Apple n'a encore rien précisé concernant Safari[21].

Bibliographie[modifier | modifier le code]

  • (en) Lin Li et Xiping Zhang, « Research On The Integration of RTCWeb Technology with IP Multimedia Subsystem », Image and Signal Processing (CISP), 2012 5th International Congress on,‎ , p. 1158-1161 (ISBN 978-1-4673-0964-6, DOI 10.1109/CISP.2012.6469705)
  • (en) Marcin Davies, Joachim Zeiss et Rene Gabner, « Evaluating two approaches for browser-based real-time multimedia communication », Proceedings of the 10th International Conference on Advances in Mobile Computing & Multimedia,‎ , p. 109-117 (ISBN 978-1-4503-1307-0, DOI 10.1145/2428955.2428982)
  • (en) Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero et Simon Pietro Romano, « On the Seamless Interaction between WebRTC Browsers and SIP-Based Conferencing Systems », Communications Magazine, IEEE, vol. 51, no 4,‎ , p. 42-47 (ISSN 0163-6804, DOI 10.1109/MCOM.2013.6495759)
  • (en) Stephan Holmer, Mikhal Shemer et Marco Paniconi, « Handling Packet Loss in WebRTC », International Conference on Image Processing (ICIP 2013),‎ , p. 1860-1864 (lire en ligne)
  • (en) Hoanh Huu Tho Le et YoungHan Kim, « Circle-mesh overlay for P2P-based RTCWeb conferencing system », Ubiquitous and Future Networks (ICUFN), 2013 Fifth International Conference on,‎ , p. 489-494 (DOI 10.1109/ICUFN.2013.6614869)
  • (en) Kundan Singh et Venkatesh Krishnaswamy, « A case for SIP in JavaScript », Communications Magazine, IEEE, vol. 51, no 4,‎ , p. 28-33 (DOI 10.1109/MCOM.2013.6495757)
  • (en) Christian Vogt, Max Jonas Werner et Thomas Schmidt, « Content-centric User Networks: WebRTC as a Path to Name-based Publishing », 21st IEEE Intern. Conf. on Network Protocols (ICNP 2013), PhD forum, IEEEPress,‎ (lire en ligne)
  • (en) Salvatore Loreto, Vijay Gurbani et Jörg Ott, « Web-Base Communications (guest editorial) », Communications Magazine, IEEE, vol. 51, no 4,‎ , p. 18-19 (DOI 10.1109/MCOM.2013.6495755)
  • (en) Martin Becke, Erwin Rathgeb, Sebastian Werner, Irene Rüngeler, Michael Tüxen et Randall Stewart, « Data Channel Considerations for RTCWeb », Communications Magazine, IEEE, vol. 51, no 4,‎ , p. 34-41 (DOI 10.1109/MCOM.2013.6495758)
  • (en) Colin Perkins, « Can congestion-controlled interactive multimedia traffic co-exist with TCP? », Proceedings of the 2012 ACM workshop on Capacity sharing,‎ , p. 45-46 (ISBN 978-1-4503-1780-1, DOI 10.1145/2413219.2413232)
  • (en) Arno Baker, Riccardo Pétrocco, Michael Dale, Jan Gerber, Victor Grishchenko, Diego Rabaioli et Johan Pouwelse, « Online video using BitTorrent and HTML5 applied to Wikipedia », Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on,‎ , p. 1-2 (DOI 10.1109/P2P.2010.5569984)
  • (en) Pedro Rodriguez, Javier Cervino, Irena Trajkoska et Joaquin Salvachua, « Advanced videoconferencing services based on WebRTC », Proceedings of the IADIS International Conferences Web Based Communities and Social media,‎ (ISBN 978-972-8939-72-4)
  • (en) Jukka Nurminen, Antony Meyn, Eetu Jalonen, Yrjo Raivio et Raul Garvia Marrero, « P2P media streaming with HTML5 and WebRTC », IEEE International Conference on Computer Communications,‎
  • (en) Tjrek de Greef, Charlie Gullström, Leif Handberg, Peter Parnes et Harold Nefs, « Shared mediated workspaces », Presence Live 2012,‎ (lire en ligne)

Notes et références[modifier | modifier le code]

  1. ↑ S. Loreto 2012, p. 68
  2. ↑ Real Time Media Flow Protocol
  3. ↑ a b et c C. Jennings 2013, p. 20
  4. ↑ P. Rodriguez 2012, p. 1
  5. ↑ a b et c P. Rodriguez 2012, p. 2
  6. ↑ Présentation d'URCP sur le site de Microsoft
  7. ↑ T.J. de Greef 2012, p. 3
  8. ↑ S. Loreto 2012, p. 69
  9. ↑ J. Nurminen 2013, p. 2
  10. ↑ a b c d et e S. Loreto 2012, p. 71
  11. ↑ (en) « An Offer/Answer Model with the Session Description Protocol (SDP) », Request for comments no 3264,
  12. ↑ a b c et d C. Jennings 2013, p. 21 Erreur de référence : Balise <ref> incorrecte : le nom « Jennings_p21 » est défini plusieurs fois avec des contenus différents.
  13. ↑ 2012
  14. ↑ a et b S. Loreto 2012, p. 70
  15. ↑ C. Jennings 2013, p. 23
  16. ↑ a et b C. Jennings 2013, p. 22
  17. ↑ S. Holmer 2013, p. 1860
  18. ↑ S. Holmer 2013, p. 1861
  19. ↑ a et b A. Johnston 2013, p. 49
  20. ↑ A. Johnston 2013, p. 51
  21. ↑ a b et c T.J. De Greef 2012, p. 4
  22. ↑ http://www.webrtc.org/
  23. ↑ http://iswebrtcreadyyet.com/
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Feyd-Aran/Brouillon&oldid=134364472 ».