WebRTC : le web hypermedia en P2P

Le développement de la communication en P2P sur le web a débuté en 2011 avec les premiers brouillons du standard Web Real-Time Communication (WebRTC) proposé par le

World Wide Web Consortium (W3C) et l’Internet Engineering Task Force (IETF)®_{. Web-}

RTC est une technologie qui fournit aux navigateurs web la possibilité de communiquer en temps-réel (Real-Time Communications) via une collection de standards, protocoles et

APIs JavaScript (Figure2.3). L’un des atouts de cette technologie est de permettre de façon simple et sans module d’extension la capture d’un flux audio et / ou vidéo (ex : applica- tions de VoIP), ainsi que l’échange de données arbitraires entre navigateurs sans nécessiter d’intermédiaires (ex : partage de fichier en P2P).

Techniquement,WebRTC supporte un canal temps-réel bidirectionnel pour l’échange de données. Contrairement à WebSocket, qui est basé sur TCP, WebRTC se base sur UDP

en intégrant une pile de plusieurs protocoles (Figure 2.3) qui lui offre des fonctionnalités similaires (fiabilité, ordonnancement, sécurité).

Plusieurs projets impliquant les protocoles proposés par WebRTC se sont intéressés à l’API MediaStream (flux continus audio et vidéo) mais très peu utilisent la partie dédiée au transfert de données DataChannel. Selon le site officiel de WebRTC9_{, plus d’un milliard} d’utilisateurs ont utilisé la technologie open source WebRTC. Ericsonn Labs a été parmi les premiers à implémenter une application WebRTC en 2011. La jeunesse du protocole (2011) fait que peu de travaux académiques l’utilisent pour créer desEVC 3D[Desprat et al., 2015b,

Steiakaki et al., 2016] et optimiser le partage de modèles 3D [Koskela et al., 2014]. Côté

commercial, un grand nombre d’applications et de services basés sur ce protocole ont fait leur apparition (par ordre d’importance) : des systèmes d’échanges audio / vidéo (VoIP)10_{, des} systèmes de partage de fichiers11 _{et autres applications (capture d’écran, réalité augmentée,}

9. https://webrtc.org

10. WebRTCWorld en liste un peu plus de 140 http://www.webrtcworld.com/webrtc-list.aspx.

Consulté le 07/07/2017.

jeux)12_{. WebRTC se retrouve également dans le domaine de l’optimisation de l’utilisation} des ressources pour la création deContent Delivery Networks(CDNs)[Zhang et al., 2013], de grilles de calcul comme dans browserCloud.js [Dias, 2015] ou pour faire des analyses visuelles collaboratives dans un environnement hétérogène [Li et al., 2015].

L’utilisation et la gestion de réseauxP2Psont des changements de paradigme qui peuvent représenter une barrière d’entrée auprès des développeurs web, habitués aux architectures client-serveur. Cependant, l’implantation de WebRTC, très semblable à WebSocket, rend la technologie facilement abordable dans un premier temps. L’attrait pour les propriétés du

P2P (distribution, résilience) est une motivation supplémentaire, en plus des implications sociales que cette architecture (partage, coopération, coût) dressent en faveur de l’intégration de WebRTC dans les applications web.

Les machines clientes et les terminaux d’extrémité (end systems) sont considérés comme « les ressources » dans un réseau P2P. En principe, ces ressources sont difficilement admi- nistrables à l’échelle dans un réseau non structuré ; la qualité de service peut en pâtir car la synchronisation est plus complexe. C’est également problématique pour simuler ces envi- ronnements car il n’existe pas de solution pérenne pour tester WebRTC à l’échelle ; chaque service doit créer son propre système de test. Dans un contexte industriel, il est peu pro- bable d’être confronté à une architecture P2P totalement décentralisée (sans serveur). Une solution centralisée permet d’utiliser la partie serveur pour télécharger l’application cliente qui contient la couche intergicielleP2P. Les serveurs sont aussi présents pour fournir à l’uti- lisateur différents services (ex : base de données, service de signalisation).

Figure 2.3 – Pile des protocoles IP : TCP vs UDP

Échange de données via RTCDataChannel L’APIRTCDataChannel ou DataChannel, issue de WebRTC, permet l’échange P2P de données arbitraires avec peu de latence et un bon débit sur la base des sessions RTCPeerConnection. DataChannel utilise de multiples canaux simultanés avec une gestion de priorité. L’API est aussi capable de gérer la fiabilité

12. Curation de ressources et modules WebRTC recensant plus de 100 projets https://github.com/ openrtc-io/awesome-webrtc. Consulté le 07/07/2017.

de la livraison des paquets et sécurise nativement les données avec le protocole Datagram Transport Layer Security (DTLS). Le contrôle de la congestion des flux et l’ordonnancement éventuel est effectué par les protocolesSCTPetReceiver-side Real-Time Congestion Control

(RRTCC).

Depuis 2011, les contributeurs du standard WebRTC font beaucoup d’efforts pour élargir et maintenir la compatibilité et interopérabilité entre les navigateurs. Cependant, certains navigateurs (comme Chrome) imposent une limite de taille pour l’envoi de messages conte- nant de la donnée brute, ce qui contrevient au principe énoncé par le standard.

Mécanisme de signalisation et problématiques réseaux

Le mécanisme de signalisation (signaling mecanism en anglais) permet de coordonner et d’envoyer des messages de contrôle durant une session. Le mécanisme de signalisation est utilisé pour échanger trois types d’information :

— des messages de contrôle sur la session pour ouvrir ou fermer un lien de communication et rapporter les erreurs ;

— les configurations réseaux (Interactive Connectivity Establishment (ICE) candidates, IP ou port de l’ordinateur) ;

— et les capacités média du navigateur (limite de débit, codecs, résolution, formats de donnée).

Un service de signalisation est nécessaire à la mise en relation des différents pairs au cours d’une session collaborative. Pour établir un canal entre deux navigateurs (initialiser une session WebRTC), il faut que chaque client se signale l’un à l’autre. Techniquement, la connexion est établie en passant par un tiers ou directement entre deux pairs une fois qu’ils ont reçu leurs identifiants de connexion. Une fois que la connexion est établie entre deux pairs, RTCDataChannel est capable, en théorie, d’être le canal de signalisation. Cette solution peut aider à réduire la latence (car les messages sont envoyés directement entre les pairs) mais n’est pas très fiable. L’utilisation d’un tiers (serveur) est, en pratique, quasi systématiquement privilégiée.

La Figure2.4représente le cas le plus complexe que l’on peut rencontrer pour établir une connexion WebRTC. Le plus simple des réseaux P2P peut être résumé comme deux machines connectées directement l’une à l’autre. Cette vision un peu utopique ne tient pas compte des routeurs qu’une connexion internet peut rencontrer. Chaque routeur peut posséder un

Network Address Translator (NAT) afin de faire correspondre les adresse IP à d’autres

adresse IP (dans le cas d’un intranet par exemple). Cela permet de faire communiquer des machines non uniques et non routables en faisant semblant d’utiliser des adresses externes,

Figure 2.4 – STUN, TURN et signalisation

uniques et routables. Pour permettre à un client situé derrière un routeur NATde connaître son adresse IP publique et le type de serveurNAT, l’utilisation d’un serveurSimple Traversal

of UDP through NATs (STUN) est requise. L’utilisation d’un NAT dynamique impose des

restrictions sur l’adresse de destination. Dans ce cas, le STUNest remplacé par l’utilisation d’un serveur Traversal Using Relays around NAT (TURN). LeTURN est considéré comme une extension duSTUN et fait office de proxy. Une fois que le client est parvenu à récupérer une adresse IP, il peut participer à l’initialisation d’une connexion WebRTC (signalisation). L’utilisation de protocoles tels queICE avec sonICE Frameworkpermet de faciliter la mise en relation des clients derrière un NAT. Le ICE Framework choisit le chemin le plus court entre les deux pairs et va utiliser le protocole adapté pour établir la connexion (STUN

d’abord puis en cas d’échec, TURN).