Même si le webRTC est toujours en phase de développement, plusieurs essais concluants sont prometteurs. Certains développeurs ont même réussi à établir une communication peer 2 peer sans utiliser un serveur. Mais cela reste possible seulement au niveau d’un même réseau local. Au-delà, un serveur est requis pour relayer le trafic comme il se doit.
Pourquoi utiliser un serveur ?
En communiquant deux navigateurs en temps réel, le webRTC n’aura aucun problème lorsque la connexion s’établit au sein d’un même réseau local. Des soucis se posent cependant lorsqu’un pair souhaite atteindre un autre pair en dehors du réseau. Ceci s’explique par le fait qu’il devra percer plusieurs « couches » telles qu’un proxy (masquant l’adresse IP), un pare-feu (bloquant certains ports et protocoles) ou encore un NAT (routant le trafic). Pour tous les contourner, la technique Interactive Connectivity Establishment entre en jeu. ICE essaie tous les moyens possibles pour connecter les pairs. Elle peut commencer par l’utilisation de l’adresse IP d’un pair obtenu à partir du système d’exploitation et de la carte réseau du périphérique. Et si cette méthode échoue, elle doit solliciter l’aide d’un serveur appelé STUN. Si STUN ne suffit pas, le serveur TURN prend le relais.
Le protocole STUN
Cet acronyme signifie Session Traversal Utilities for NAT. Son objectif est de fournir à l’utilisateur, par une demande, son adresse IP publique (ou externe) ou le type de NAT qu’il utilise. Grâce à ces informations, l’utilisateur du WebRTC peut échanger des données ou communiquer. Mais il arrive que l’architecture réseau et le type de périphérique NAT soient complexes (cas d’un réseau d’entreprise par exemple), le serveur STUN n’arrive plus à détecter l’adresse externe. C’est alors que le TURN prend le relais. Il faut ici noter que la décision d’utiliser l’un ou l’autre serveur est coordonnée par ICE.
Le serveur TURN à la rescousse
Signifiant en anglais Traversal Using Relays around NAT, TURN est le serveur de relais. Il est plus robuste que le précédent, puisqu’il permet de traverser plusieurs types de NAT. Cependant, son action conduit à un coût important généré par l’usage de bande passante. C’est justement pour cette raison, qu’il n’est pas disponible publiquement. Parfois, il faudra payer un service TURN hébergé pour pouvoir en bénéficier. Le protocole ICE suggère donc en premier l’utilisation de STUN. Et ce n’est que lorsqu’on est en présence de NAT « symétriques » ou de situations plus complexes qu’on fait appel à une requête auprès du serveur TURN.