WebRTC (Web Real-Time Communication) est une technologie ouverte qui permet la communication en temps r\u00e9el de la voix, de la vid\u00e9o et des donn\u00e9es entre navigateurs. Elle est en cours de standardisation par diverses entreprises, dont Google, comme m\u00e9canisme permettant la communication P2P via des API JavaScript uniquement, sans n\u00e9cessiter de plug-ins ou de logiciels suppl\u00e9mentaires.<\/p>\n\n\n\n
WebRTC se compose de trois composants principaux\u00a0:<\/p>\n\n\n\n
Ces API permettent le d\u00e9veloppement de nombreuses applications en temps r\u00e9el telles que les appels vid\u00e9o, les conf\u00e9rences audio, le partage de fichiers, etc. Cependant, dans les communications r\u00e9elles, il existe des probl\u00e8mes avec la travers\u00e9e NAT et les pare-feu, il est donc essentiel de comprendre et de mettre en \u0153uvre des technologies de travers\u00e9e NAT telles que STUN\/TURN\/TURNS.<\/p>\n\n\n\n
Pour obtenir une connexion pair \u00e0 pair stable avec WebRTC, un m\u00e9canisme de travers\u00e9e NAT est essentiel. Cet article d\u00e9taille les diff\u00e9rences techniques, les sc\u00e9narios d'utilisation, ainsi que les avantages et les inconv\u00e9nients des technologies STUN, TURN et TURNS.<\/p>\n\n\n\n
STUN est un protocole utilis\u00e9 principalement pour d\u00e9terminer l'adresse externe d'un utilisateur dans un environnement NAT, tandis que TURN fait office de serveur relais lorsqu'une connexion directe est impossible. TURNS, quant \u00e0 lui, chiffre ses communications avec TLS et utilise le m\u00eame num\u00e9ro de port 443 que HTTPS, ce qui permet de communiquer derri\u00e8re des pare-feu stricts, comme sur les r\u00e9seaux d'entreprise.<\/p>\n\n\n\n
En comprenant les caract\u00e9ristiques de chacun et en les utilisant de mani\u00e8re appropri\u00e9e, vous pouvez augmenter le taux de r\u00e9ussite et la qualit\u00e9 des communications WebRTC.<\/p>\n\n\n\n
STUN (Session Traversal Utilities for NAT) est un protocole qui permet aux clients deAdresse IP et port externes<\/strong>Il s'agit d'un protocole simple permettant de conna\u00eetre l'adresse IP d'un PC. Par exemple, si un PC est derri\u00e8re un NAT, il ne conna\u00eet pas sa propre adresse IP globale, mais il peut obtenir \u00ab\u00a0son adresse IP\u00a0: port vu de l'ext\u00e9rieur\u00a0\u00bb en interrogeant le serveur STUN.<\/p>\n\n\n\n Le serveur STUN agit comme un miroir, renvoyant les informations source de la requ\u00eate re\u00e7ue telles quelles. Ainsi, le client peut conna\u00eetre sa propre adresse IP globale et le num\u00e9ro de port attribu\u00e9 par le NAT (Server Reflexive Candidate).<\/p>\n\n\n\n La communication STUN s'effectue g\u00e9n\u00e9ralement via UDP, le port par d\u00e9faut \u00e9tant 3478 (UDP\/3478). Comme elle n\u00e9cessite une communication UDP l\u00e9g\u00e8re et mono-coup, elle pr\u00e9sente une faible surcharge, une faible latence et une charge serveur quasi nulle. Par cons\u00e9quent, dans les environnements o\u00f9 la communication UDP est autoris\u00e9e, la travers\u00e9e NAT via STUN est tent\u00e9e en premier.<\/p>\n\n\n\n Il est efficace dans les environnements o\u00f9 la travers\u00e9e NAT est n\u00e9cessaire, mais o\u00f9 la communication UDP elle-m\u00eame n'est pas bloqu\u00e9e, comme les r\u00e9seaux domestiques et les lignes mobiles. Si STUN peut obtenir l'adresse IP externe de l'autre appareil, les clients peuvent \u00e9tablir une communication directe (pair \u00e0 pair). Comme le chemin de communication est direct, les d\u00e9lais sont r\u00e9duits et la qualit\u00e9 est maintenue \u00e0 un niveau \u00e9lev\u00e9. De plus, comme le serveur ne participe qu'\u00e0 l'\u00e9change d'informations IP, les co\u00fbts sont tr\u00e8s faibles. Par exemple, pour les jeux en ligne ou les appels vid\u00e9o, si les deux appareils sont dans un NAT relativement ouvert, STUN suffit \u00e0 \u00e9tablir une connexion pair \u00e0 pair.<\/p>\n\n\n\n STUN est simplement un moyen de \u00ab\u00a0trouver sa propre adresse externe\u00a0\u00bb et, selon le type de NAT et les restrictions du pare-feu, il peut \u00eatre impossible de se connecter en utilisant uniquement ce moyen. En particulier, dans les environnements NAT sym\u00e9triques ou avec pare-feu strict, les paquets provenant de l'autre partie peuvent ne pas atteindre l'adresse obtenue par STUN, rendant la communication impossible.<\/p>\n\n\n\n De plus, la communication UDP elle-m\u00eame peut \u00eatre bloqu\u00e9e sur les r\u00e9seaux d'entreprise, auquel cas les requ\u00eates STUN n'atteignent pas l'appareil. En r\u00e9sum\u00e9, STUN est un m\u00e9canisme permettant de d\u00e9terminer si une communication directe est possible et ne fonctionne pas dans les environnements o\u00f9 elle est physiquement impossible. C'est pourquoi STUN est utilis\u00e9 dans ICE (d\u00e9crit ci-dessous) pour identifier les candidats \u00e0 la premi\u00e8re \u00e9tape, et est con\u00e7u pour revenir \u00e0 TURN (d\u00e9crit ci-dessous) si STUN est insuffisant.<\/p>\n\n\n\n TURN (Traversal Using Relays around NAT) est un protocole qui agit comme un relais lorsque la communication directe est impossible avec STUN. Le serveur TURN agit comme un point de relais accessible \u00e0 tous entre le partenaire de communication et l'autre partie, transf\u00e9rant les paquets. Le client se connecte au serveur TURN et obtient une adresse IP et un port de relais, appel\u00e9s \u00ab\u00a0candidat relais\u00a0\u00bb. L'\u00e9change de m\u00e9dias et de donn\u00e9es avec l'autre partie s'effectue ensuite via ce serveur TURN.<\/p>\n\n\n\n TURN communique \u00e9galement normalement via UDP. Ainsi, tant que ce protocole est utilis\u00e9, il peut relayer les paquets multim\u00e9dias de mani\u00e8re similaire \u00e0 une communication directe. Par d\u00e9faut, le protocole TURN est accept\u00e9 sur le port 3478 (UDP), comme STUN. M\u00eame si le num\u00e9ro de port UDP est restreint par la politique de pare-feu, TURN peut \u00e9galement \u00eatre ex\u00e9cut\u00e9 sur un port autoris\u00e9 tel que UDP\/443. Tant que le protocole UDP est utilis\u00e9, le relais offre des performances temps r\u00e9el sup\u00e9rieures \u00e0 celles du protocole TCP.<\/p>\n\n\n\n TURN est essentiel lorsqu'une connexion directe ne peut \u00eatre \u00e9tablie. Par exemple,C'est le cas lorsque l'une ou les deux parties se trouvent derri\u00e8re un pare-feu d'entreprise strict, ou lorsque les deux parties ont des NAT sym\u00e9triques et que le perforation UDP \u00e9choue.<\/span>Dans un tel environnement, la communication n'est pas possible sans relais via un serveur TURN, donc TURN fonctionne comme une sorte de dernier recours.<\/p>\n\n\n\n WebRTC vise \u00e0 permettre \u00e0 tous les pairs de communiquer directement. M\u00eame si cela n'est pas possible, la communication peut se poursuivre en utilisant TURN. En pratique, la strat\u00e9gie g\u00e9n\u00e9rale consiste \u00e0 essayer d'abord de se connecter directement \u00e0 STUN, puis \u00e0 ne basculer sur le relais TURN qu'en cas d'\u00e9chec. Par exemple, lors d'une visioconf\u00e9rence sur un r\u00e9seau interne, si les deux parties ne peuvent pas communiquer directement, la communication bascule automatiquement vers le serveur TURN, permettant \u00e0 l'utilisateur de poursuivre la conversation sans m\u00eame s'en rendre compte.<\/p>\n\n\n\n Le principal avantage r\u00e9side dans la fiabilit\u00e9. Quel que soit l'environnement NAT ou pare-feu utilis\u00e9, tant que la communication entre le client et le serveur TURN est \u00e9tablie, une communication pair \u00e0 pair est possible. De plus, TURN \u00e9tant une extension de STUN en termes de protocole, une impl\u00e9mentation serveur unique (comme coturn, d\u00e9crite ci-dessous) peut traiter les requ\u00eates STUN et TURN. Une fois la connexion \u00e9tablie, les m\u00e9dias suivants sont relay\u00e9s sous forme de flux, ce qui, du point de vue de l'utilisateur, garantit une communication fluide, \u00e0 l'exception de quelques retards.<\/p>\n\n\n\n Ses principaux inconv\u00e9nients sont la consommation de ressources et la latence. Avec TURN, toutes les donn\u00e9es audio et vid\u00e9o doivent transiter par le serveur, ce qui requiert une bande passante et une puissance de traitement consid\u00e9rables c\u00f4t\u00e9 serveur. Par exemple, si l'on suppose qu'un appel vid\u00e9o individuel consomme une bande passante unidirectionnelle de 1 Mbit\/s, un simple calcul permet de supposer que 1\u00a0000 utilisateurs l'utilisent simultan\u00e9ment, une bande passante relais de 1 Gbit\/s est n\u00e9cessaire. Cela engendre des co\u00fbts d'exploitation \u00e9lev\u00e9s pour un serveur TURN, et les services \u00e0 grande \u00e9chelle n\u00e9cessitent la pr\u00e9paration et la mise \u00e0 l'\u00e9chelle de plusieurs serveurs relais TURN.<\/p>\n\n\n\n De plus, plus le chemin de communication est long, plus le d\u00e9lai est important, ce qui entra\u00eene un d\u00e9calage temporel et une baisse de la qualit\u00e9 vid\u00e9o et audio. De plus, compar\u00e9e \u00e0 la communication pair-\u00e0-pair utilisant STUN, la communication via TURN n'est pas strictement pair-\u00e0-pair\u00a0; elle est donc l\u00e9g\u00e8rement inf\u00e9rieure en termes de confidentialit\u00e9 (bien que les serveurs TURN ne relaient g\u00e9n\u00e9ralement que des RTP\/datagrammes non chiffr\u00e9s et n'en interpr\u00e8tent pas le contenu).<\/p>\n\n\n\n En g\u00e9n\u00e9ral, TURN ne doit \u00eatre utilis\u00e9 qu'en cas de n\u00e9cessit\u00e9. En effet, la plupart des communications WebRTC peuvent \u00eatre connect\u00e9es directement via STUN, et les statistiques de Google montrent qu'environ 861 appels TP3T au total sont \u00e9tablis sans relais (peer-to-peer). Seuls les 141 TP3T restants n\u00e9cessitent TURN, mais il est important de disposer d'une infrastructure TURN pour ces 141 TP3T.<\/p>\n\n\n\n TURNS est l'abr\u00e9viation de \u00ab TURN over TLS \u00bb et est un protocole qui crypte la communication relais \u00e0 l'aide du protocole TURN avec TLS (Transport Layer Security).Communication TURN s\u00e9curis\u00e9e par TLS (HTTPS)<\/span>et sert souvent sur le port TCP 443.Le port 443 est le m\u00eame num\u00e9ro de port que HTTPS, il peut donc facilement traverser les pare-feu d'entreprise et permet de contourner facilement les proxys et la censure.<\/span>.<\/p>\n\n\n\n Par exemple, un r\u00e9seau d'entreprise interne peut autoriser uniquement les communications externes sur les ports 80 et 443, mais m\u00eame dans ce cas, il existe de fortes chances que les communications puissent passer si le serveur TURN utilise les communications TLS sur le port 443. De plus, comme les communications sont crypt\u00e9es \u00e0 l'aide de TLS, elles sont s\u00e9curis\u00e9es et difficiles \u00e0 intercepter pour des tiers.<\/p>\n\n\n\n Dans WebRTC, les param\u00e8tres TURNS est utile pour la communication WebRTC dans des environnements tr\u00e8s restreints, comme les r\u00e9seaux d'entreprise, o\u00f9 tous les autres moyens sont bloqu\u00e9s. M\u00eame dans les environnements o\u00f9 tous les ports UDP et TCP g\u00e9n\u00e9raux sont bloqu\u00e9s, de nombreuses politiques autorisent la communication de la m\u00eame mani\u00e8re que la communication HTTPS. TURN sur le port TLS 443 constitue donc un dernier recours.<\/p>\n\n\n\n Il est \u00e9galement utilis\u00e9 dans les situations o\u00f9 certains ports sont ferm\u00e9s sur les r\u00e9seaux locaux sans fil publics, ou lorsque seule la communication TLS est possible c\u00f4t\u00e9 client.D'abord UDP, si cela ne fonctionne pas alors TCP, si cela ne fonctionne pas alors TLS vers 443<\/span>\u00ab Elle se positionne comme l\u2019\u00e9tape finale d\u2019un repli progressif.<\/p>\n\n\n\n Son principal avantage r\u00e9side dans sa haute r\u00e9sistance aux pare-feu. Les communications chiffr\u00e9es TLS sont difficiles \u00e0 distinguer du HTTPS standard\u00a0; elles sont donc plus susceptibles de passer \u00e0 travers des filtres stricts. En particulier, lors de l'introduction d'un syst\u00e8me de webconf\u00e9rence dans une entreprise, il est n\u00e9cessaire d'autoriser les connexions externes depuis le r\u00e9seau interne, mais les communications TLS via TCP\/443 sont plus susceptibles d'\u00eatre accept\u00e9es dans le cadre des politiques de s\u00e9curit\u00e9. De plus, gr\u00e2ce au chiffrement, la confidentialit\u00e9 des communications avec le serveur relais est assur\u00e9e (*Cependant, le contenu lui-m\u00eame, comme la vid\u00e9o, est souvent d\u00e9j\u00e0 chiffr\u00e9 au niveau de la couche WebRTC).<\/p>\n\n\n\n Le principal inconv\u00e9nient r\u00e9side dans la baisse des performances. Outre le d\u00e9lai et la charge de TURN, il faut tenir compte de la surcharge de TLS et TCP. TCP est un transport fiable et dispose d'un m\u00e9canisme de retransmission en cas de perte de paquets, mais il n'est pas adapt\u00e9 aux m\u00e9dias en temps r\u00e9el. En cas de perte, la lecture vid\u00e9o et audio peut \u00eatre perturb\u00e9e.<\/p>\n\n\n\n De plus, TCP est sujet au blocage en t\u00eate de ligne en raison de l'ordre des paquets,La gigue (fluctuation) augmente \u00e9galement par rapport \u00e0 l'UDP.<\/span>De plus, le traitement du chiffrement et du d\u00e9chiffrement TLS sollicite davantage le processeur. Par cons\u00e9quent, un d\u00e9lai suppl\u00e9mentaire de 50 ms ou plus a \u00e9t\u00e9 signal\u00e9, provoquant un d\u00e9calage perceptible par les utilisateurs. En particulier, lors des visioconf\u00e9rences, ce d\u00e9lai accru peut ralentir le rythme des conversations et entra\u00eener des d\u00e9calages temporels notables.<\/p>\n\n\n\n De cette fa\u00e7on, TURNS peut \u00eatre consid\u00e9r\u00e9 comme une m\u00e9thode de \u00ab dernier recours \u00bb en termes de qualit\u00e9, mais c'est aussi une bou\u00e9e de sauvetage fiable dans les situations o\u00f9 il n'y a pas d'autre option que d'\u00e9tablir une communication.<\/p>\n\n\n\n Ces derni\u00e8res ann\u00e9es, une nouvelle approche (TURN over QUIC) qui fonctionne sur le port UDP 443 et utilise DTLS\/QUIC au lieu de TLS a \u00e9t\u00e9 envisag\u00e9e, mais elle est toujours en cours de normalisation et n'est pas couramment utilis\u00e9e.<\/p>\n\n\n\n Nous allons expliquer \u00e9tape par \u00e9tape le d\u00e9roulement du traitement ICE WebRTC lorsque STUN sur UDP n'est pas disponible. Prenons l'exemple d'un blocage total d'UDP, par exemple sur un r\u00e9seau d'entreprise, et voyons comment la n\u00e9gociation ICE se r\u00e9sorbe.<\/p>\n\n\n\n Voici le d\u00e9roulement de la n\u00e9gociation ICE dans les environnements difficiles o\u00f9 UDP est inutilisable. En r\u00e9sum\u00e9, les candidats sont test\u00e9s dans l'ordre \u00ab\u00a0H\u00f4te \u2192 STUN \u2192 TURN\u00a0\u00bb, et en cas d'\u00e9chec, la connexion \u00e9choue. Il est important que les d\u00e9veloppeurs comprennent ce comportement et incluent au minimum un serveur TURN\/TURNS dans la liste des serveurs ICE, afin que, m\u00eame dans le pire des cas, la communication puisse \u00eatre \u00e9tablie. De plus, lors des requ\u00eates des utilisateurs, un d\u00e9pannage est n\u00e9cessaire, par exemple en d\u00e9duisant un probl\u00e8me li\u00e9 \u00e0 l'environnement r\u00e9seau (blocage UDP, par exemple) \u00e0 partir d'informations telles que \u00ab\u00a0\u00c9chec ICE\u00a0\u00bb et en v\u00e9rifiant les param\u00e8tres de serveur TURN manquants.<\/p>\n\n\n\nSc\u00e9narios d'utilisation de STUN<\/strong><\/h4>\n\n\n\n
Limites et inconv\u00e9nients du STUN<\/h4>\n\n\n\n
R\u00f4le et fonctionnalit\u00e9s de TURN (UDP)<\/h3>\n\n\n\n
Sc\u00e9narios d'utilisation de TURN<\/h4>\n\n\n\n
Avantages de TURN<\/strong><\/h4>\n\n\n\n
Inconv\u00e9nients de TURN<\/strong><\/h4>\n\n\n\n
R\u00f4le et fonctionnalit\u00e9s de TURNS (TLS sur TCP\/443)<\/h3>\n\n\n\n
"urls": "tours:toursserveur:443"<\/code>Dans le sch\u00e9ma URI\u00a0:tours:<\/code>Vous pouvez utiliser ce serveur TURN chiffr\u00e9 TLS en sp\u00e9cifiant<\/p>\n\n\n\nSc\u00e8nes o\u00f9 TURNS est utilis\u00e9<\/h4>\n\n\n\n
Avantages de TURNS<\/h4>\n\n\n\n
Inconv\u00e9nients de TURNS<\/h4>\n\n\n\n
Flux de communication lorsque UDP STUN n'est pas disponible<\/h2>\n\n\n\n
Client WebRTC (navigateur)serveurs de glace<\/code>Une demande de liaison (demande de v\u00e9rification de l'adresse externe) est envoy\u00e9e au serveur STUN sp\u00e9cifi\u00e9 via le port UDP 3478. Il s'agit de la premi\u00e8re \u00e9tape de la collecte des candidats ICE et, en cas de succ\u00e8s, le serveur renvoie sa propre adresse IP globale et son num\u00e9ro de port, et est ajout\u00e9 \u00e0 la liste des candidats en tant que candidat r\u00e9flexif du serveur (candidat srflx).<\/li>
Dans ce cas, les param\u00e8tres du pare-feu r\u00e9seau emp\u00eachent les communications UDP d'atteindre l'ext\u00e9rieur. Par cons\u00e9quent, les requ\u00eates adress\u00e9es au serveur STUN n'atteignent pas ce dernier, ou la r\u00e9ponse n'atteint pas le client. Par cons\u00e9quent, le clientR\u00e9ponse STUN non re\u00e7ue<\/strong>L'adresse IP externe est inconnue. L'agent ICE attend une r\u00e9ponse pendant un certain temps, puis expire. Du point de vue de l'utilisateur, la connexion est toujours en cours de traitement et aucun message d'erreur ne s'affiche, mais en r\u00e9alit\u00e9,Impossible de rassembler les candidats<\/strong>Cela se produit actuellement.<\/li>
Normalement, si STUN r\u00e9ussit, le client dispose d'un serveur r\u00e9flexif (votre adresse IP globale) en plus de l'h\u00f4te (votre adresse IP locale) et v\u00e9rifie la connexion en la combinant avec celle du pair distant. Cependant, en l'absence d'adresse IP globale candidate suite \u00e0 un \u00e9chec STUN,Les candidats aux connexions directes entre pairs sont extr\u00eamement limit\u00e9s<\/strong>Par exemple, si les deux parties ne disposent que d'adresses IP priv\u00e9es, elles ne pourront pas se joindre, m\u00eame en essayant de se connecter. ICE d\u00e9terminera alors que la communication directe est impossible. Si le serveur ICE (TURN) n'est pas configur\u00e9, l'ensemble du syst\u00e8me ICE sera consid\u00e9r\u00e9 comme un \u00e9chec \u00e0 ce stade et la connexion WebRTC ne sera pas \u00e9tablie (la console d\u00e9veloppeur afficheraL'ICE a \u00e9chou\u00e9<\/code>et ... et\u00c9tat de la connexion ICE\u00a0: \u00e9chec<\/code>etc. seront affich\u00e9s).<\/li>
M\u00eame si l\u2019acquisition directe de candidats par STUN \u00e9choue,serveurs de glace<\/code>Si un serveur TURN est sp\u00e9cifi\u00e9 dansProchaines \u00e9tapes<\/strong>Dans cet exemple, comme UDP n'est pas disponible, le client essaiera de se connecter au serveur TURN en utilisant TCP ou TLS (par exemple,tours:turn.example.com:443<\/code>(Si configur\u00e9, le protocole TLS d\u00e9marrera.) Heureusement, le pare-feu autorise la communication HTTPS sur TCP 443, la connexion TURN via TLS est donc r\u00e9ussie. Le client s\u00e9curise une adresse relais sur le serveur TURN.Candidat au relais<\/strong>L'autre c\u00f4t\u00e9 obtiendra des candidats relais, qui sont des \u00ab\u00a0candidats virtuels pour la communication via le serveur TURN\u00a0\u00bb. Parall\u00e8lement, l'autre c\u00f4t\u00e9 (le c\u00f4t\u00e9 distant) obtiendra \u00e9galement des candidats relais, ou, si le r\u00e9seau est sans probl\u00e8me, des candidats directs ou STUN. Dans tous les cas, si au moins un c\u00f4t\u00e9 poss\u00e8de des candidats relais, l'autre c\u00f4t\u00e9 peut tenter de se connecter \u00e0 ce serveur TURN.<\/li>
Une fois que les deux homologues ont des candidats disponibles (un ou les deux candidats relais dans cet exemple), ICE les utilise pour v\u00e9rifier la connexion. Une fois la communication \u00e9tablie via le serveur TURN avec le serveur, elle peut \u00eatre relay\u00e9e, de sorte que le canal multim\u00e9dia est ouvert m\u00eame si le protocole UDP ne passe pas directement entre les homologues. Cela permet aux communications vid\u00e9o et audio entre les utilisateurs de commencer. Une fois la connexion \u00e9tablie, une surcharge est g\u00e9n\u00e9r\u00e9e par TCP sur TLS, mais la conversation elle-m\u00eame est possible. \u00c0 l'inverse, en cas de d\u00e9faillance (par exemple, si un proxy d'entreprise d\u00e9tecte et bloque une communication TLS non HTTP, ou si l'authentification du serveur TURN \u00e9choue), ICE \u00e9chouera et la connexion sera abandonn\u00e9e. L'application doit d\u00e9tecter cette situation et signaler \u00e0 l'utilisateur que la connexion n'\u00e9tait pas possible, etc.<\/li><\/ol>\n\n\n\nCr\u00e9ation et configuration d'un serveur STUN\/TURN\/TURNS \u00e0 l'aide de coturn<\/h2>\n\n\n\n