Millions d'appels vidéo par jour ou «Appelle maman!»

Du point de vue de l'utilisateur, les services d'appel semblent assez simples: vous allez à la page d'un autre utilisateur, vous appelez, il décroche, vous lui parlez. Dehors, il semble que tout soit simple, mais peu savent faire un tel service. Mais Alexander Tobol ( alatobol ) sait non seulement, mais partage aussi volontiers son expérience.



Poursuivez la version texte du rapport sur la Sibérie HighLoad ++, à partir de laquelle vous apprendrez:

• comment les services d'appels vidéo fonctionnent sous le capot;
• combien il est beau de percer le NAT - cela sera intéressant pour les spécialistes du jeu qui ont besoin d'une connexion peer-to-peer;
• comment WebRTC fonctionne, quels protocoles il inclut;
• comment puis-je régler WebRTC via BigData.

À propos de l'orateur: Alexander Tobol dirige le développement des plates-formes vidéo et bande sur ok.ru.

Historique des appels vidéo

Le premier appareil d'appel vidéo est apparu en 1960, il s'appelait un picherphone, utilisait des réseaux dédiés et était extrêmement cher. En 2006, Skype a ajouté des appels vidéo à son application. En 2010, Flash a pris en charge le protocole RTMFP et nous, à Odnoklassniki, avons lancé des appels vidéo Flash. En 2016, Chrome a cessé de prendre en charge Flash, et en août 2017, nous avons redémarré les appels avec la nouvelle technologie, dont je parlerai aujourd'hui. Après avoir finalisé le service, nous avons reçu pendant six mois une augmentation significative du nombre d'appels terminés avec succès. Récemment, nous avons également des masques dans les appels.

Architecture et savoirs traditionnels

Puisque nous travaillons dans un réseau social, nous n'avons pas de tâches techniques et nous ne savons pas ce que sont les savoirs traditionnels. Habituellement, l'idée entière tient sur une seule page et ressemble à ceci.


L'utilisateur souhaite appeler d'autres utilisateurs à l'aide d'une application Web ou iOS / Android. Un autre utilisateur peut avoir plusieurs appareils. L'appel arrive sur tous les appareils, l'utilisateur décroche le téléphone sur l'un d'eux, il parle. Tout est simple.

Spécifications techniques

Afin de faire un service d'appel de qualité, nous devons comprendre quelles caractéristiques nous voulons suivre. Nous avons décidé de commencer par chercher ce qui agaçait le plus l'utilisateur.

L'utilisateur est vraiment ennuyé s'il décroche le téléphone et est obligé d'attendre que la connexion soit établie.


L'utilisateur est ennuyé si la qualité de l'appel est mauvaise - quelque chose est interrompu, la vidéo est dispersée, le son bouillonne.


Mais surtout l'utilisateur est agacé par le retard des appels. La latence est l'une des caractéristiques importantes des appels. Avec une latence dans une conversation de l'ordre de 5 secondes, il est absolument impossible de mener un dialogue.


Nous avons déterminé pour nous-mêmes des caractéristiques acceptables:

• Démarrer - nous avons décidé qu'il était bon de commencer l'appel dans une seconde. C'est-à-dire la connexion après que l'utilisateur a répondu, ne devrait pas prendre plus d'une seconde.
• La qualité est un indicateur très subjectif. Vous pouvez mesurer, par exemple, le rapport signal / bruit (SNR), mais il manque encore des trames et autres artefacts. Nous avons mesuré la qualité de manière plutôt subjective et évalué le bonheur des utilisateurs.
• La latence doit être inférieure à 0,5 seconde. Si la latence est supérieure à 0,5 seconde, vous entendez déjà des retards et commencez à vous interrompre.

Polycom est un système de conférence installé dans nos bureaux. Nous avons des latences moyennes de polycom de l'ordre de 1,3 seconde. Avec un tel retard, vous ne vous comprenez pas toujours. Si le délai augmente à 2 secondes, le dialogue ne sera pas possible.


Comme nous avions déjà lancé la plateforme, nous nous attendions à peu près à un million d'appels par jour. C'est mille appels en parallèle. Si tous les appels sont lancés via le serveur, il y aura mille appels mégabits par appel. C'est seulement 1 gigabit / sec un seul serveur de fer sera suffisant.

Internet vs TTX

Qu'est-ce qui peut vous empêcher d'obtenir de telles fonctionnalités intéressantes? Internet!


Sur Internet, il y a des choses comme le temps d'aller-retour (RTT), qui ne peuvent pas être surmontées, il y a une bande passante variable, il y a le NAT.

Auparavant, nous mesurions la vitesse de transmission dans les réseaux de nos utilisateurs.


Nous l'avons ventilé par type de connexion, avons examiné le RTT moyen, la perte de paquets, la vitesse et avons décidé de tester les appels sur les valeurs moyennes de chacun de ces réseaux.


Il existe d'autres problèmes sur Internet:

• Perte de paquets - nous avons mesuré 0,6% de perte de paquets aléatoire (nous ne prenons pas en compte la perte de paquets de congestion avec un nombre excessif de paquets).
• Réorganisation - vous envoyez des paquets dans le même ordre et le réseau les trie à nouveau.
• Jitter - envoie un flux vidéo ou audio à un certain intervalle, et les paquets se regroupent du côté client en paquets, par exemple, en raison de la mise en mémoire tampon sur les périphériques réseau.
• NAT - il s'est avéré que plus de 97% des utilisateurs sont derrière NAT. Nous parlerons pourquoi, quoi et comment.

Considérez les paramètres réseau répertoriés ci-dessus avec un exemple simple.

J'ai paginé le site Web de l'Université d'État de Novossibirsk depuis mon bureau et j'ai reçu un ping si étrange.


La gigue moyenne dans cet exemple est de 30 ms, c'est-à-dire que l'intervalle moyen entre les temps de ping adjacents est d'environ 30 ms et le ping moyen est de 105 ms.

Qu'est-ce qui est important dans les appels, pourquoi allons-nous nous battre pour le P2P?


Évidemment, si nous parvenons à établir une connexion p2p entre nos utilisateurs qui essaient de se parler à Saint-Pétersbourg, plutôt que via un serveur situé à Novossibirsk, nous économiserons environ 100 ms aller-retour et du trafic vers ce service.

Par conséquent, la majeure partie de l'article est consacrée à la fabrication de bons p2p.

Histoire ou héritage

Comme je l'ai dit, nous avons un service d'appel depuis 2010 et nous l'avons redémarré.


En 2006, lorsque Skype a commencé, Flash a acheté Amicima, qui a fabriqué RTMFP. Flash avait déjà RTMP, qui peut en principe être utilisé pour les appels, et il est souvent utilisé pour le streaming. Flash a ensuite ouvert la spécification RTMP. Je me demande pourquoi ils avaient besoin de RTMFP? En 2010, nous avons utilisé RTMFP.

Comparez les exigences des protocoles d'appel et des protocoles de streaming réels et voyez où se trouve cette frontière.


RTMP est plus un protocole de streaming vidéo. Il utilise TCP, il a un retard cumulé. Si vous disposez d'une bonne connexion Internet, les appels vers RTMP fonctionneront.

Le protocole RTMFP , malgré la différence en une seule lettre, est le protocole UDP. Il est exempt de problèmes de mise en mémoire tampon - ceux qui sont sur TCP; Il est privé de blocage en tête de ligne - c'est lorsque vous avez perdu un paquet, et TCP ne renvoie pas les paquets suivants jusqu'à ce qu'il soit temps d'envoyer à nouveau le perdu. RTMFP était capable de gérer NAT et connaissait un changement dans l'adresse IP des clients. Par conséquent, nous avons lancé le Web sur RTMFP en 2010.


Ce n'est qu'en 2011 que le projet initial de WebRTC est apparu, qui n'était pas encore pleinement opérationnel. En 2012, nous avons commencé à prendre en charge les appels sur iOS / Android, puis quelque chose d'autre s'est produit, et en 2016, Chrome a cessé de prendre en charge Flash. Nous devions faire quelque chose.


Nous avons regardé tous les protocoles VoIP: comme toujours, pour faire quelque chose, nous commençons par regarder les concurrents.

Concurrents ou par où commencer

Nous avons choisi les concurrents les plus populaires: Skype, WhatsApp, Google Duo (similaire à Hangouts) et ICQ.

Pour commencer, nous avons mesuré le retard.


C'est facile à faire. Ci-dessus, une photographie dans laquelle:

• Chronomètre (voir téléphone en haut à gauche), qui indique l'heure (03:08).
• Le téléphone à proximité passe un appel et prend le premier téléphone sous forme de vidéo. À partir du moment où l'image est entrée dans l'appareil photo du téléphone et que vous l'avez vue, cela a pris environ 100 ms.
• Un appel vers un autre téléphone (blanc) et une fois de plus. Ici, le retard est d'environ 310 ms avec Google Duo.

Je ne révélerai pas encore toutes les cartes, mais nous nous sommes assurés que ces appareils ne pouvaient pas établir de connexions p2p. Bien sûr, les mesures ont été effectuées dans différents réseaux, et ce n'est qu'un exemple.


Skype interrompt encore un peu. Il s'est avéré qu'avec Skype, au cas où il ne parviendrait pas à connecter p2p, le délai est de 1,1 s.

Notre environnement de test était compliqué. Nous avons testé dans différentes conditions (EDGE, 3G, LTE, WiFi), pris en compte que les canaux sont asymétriques, et je donne les valeurs moyennes de toutes les mesures.


Afin d'estimer la consommation de la batterie, la charge du processeur et tout le reste, nous avons décidé que vous pouvez simplement mesurer la température du téléphone avec un pyromètre et supposer qu'il s'agit d'une charge moyenne sur le GPU du téléphone par processeur, batterie. En principe, il est très désagréable de porter un téléphone chaud à votre oreille, et même de le tenir entre vos mains. Il semble à l'utilisateur que l'application va maintenant utiliser toute sa batterie.


Le résultat est:

• Les plus lents dans le retard étaient ICQ et Skype, et les plus rapides - Telegram. Ce n'est pas une comparaison complètement correcte, car Telegram n'a pas d'appels vidéo, mais leur latence audio est minimale. WhatsApp (environ 200 ms) et Hangouts - 390 ms fonctionnent très bien.
• Par température, Telegram mange le moins sans vidéo et Skype le plus.
• En termes de temps de réponse , Telegram établit la connexion pour la durée la plus longue et la plus rapide WhatsApp et Google Duo.

Génial, nous avons obtenu quelques métriques!


Nous avons testé la qualité de la vidéo et de la voix sur différents réseaux, avec différentes gouttes et tout le reste. En conséquence, nous sommes arrivés à la conclusion que la vidéo de la plus haute qualité se trouve sur Google Duo et que la voix est sur Skype , mais cela se trouve dans les «mauvais» réseaux lorsqu'il y a déjà une distorsion. En général, tout le monde travaille approximativement médiocre. WhatsApp a l'image la plus floue.

Voyons voir sur quoi tout cela est implémenté.


Skype a son propre protocole propriétaire, et tout le monde utilise soit une modification de WebRTC, soit généralement directement WebRTC. Hangouts, Google Duo, WhatsApp, Facebook Messenger peuvent fonctionner avec le Web, et ils ont tous WebRTC sous le capot. Ils sont tous tellement différents, avec des caractéristiques différentes, et ils ont tous un WebRTC! Il faut donc pouvoir le cuisiner correctement. De plus, il y a Telegram, dont certaines parties de WebRTC sont responsables de la partie audio, il y a ICQ, qui a longtemps forgé WebRTC et a continué à développer sa propre voie.

WebRTC L'architecture

WebRTC implique la présence d'un serveur de signalisation, un intermédiaire entre les clients, qui est utilisé pour échanger des messages lors de l'établissement d'une connexion p2p entre eux. Après avoir établi une connexion directe, les clients commencent à échanger des données multimédias entre eux.

WebRTC Démo

Commençons par une démo simple. Il existe 5 étapes simples pour établir une connexion WebRTC.


Il dit ceci:

1. Prenez une vidéo et établissez une connexion entre pairs, transférez une sorte de iceServers (ce n'est pas immédiatement clair de quoi il s'agit).
   
2. Créez une offre SDP et envoyez-la à la signalisation, et la signalisation WebRTC ne l'implémentera en aucune façon.
   
3. Ensuite, vous devez créer un wrapper pour celui provenant de la signalisation, et cela ne fait pas non plus partie de WebRTC.
   
4. Échangez encore quelques candidats.
   
5. Obtenez enfin le flux vidéo à distance.
   

Voyons ce qui se passe là-bas et ce dont nous avons besoin pour nous mettre en œuvre.


Nous regardons l'image de bas en haut. Il existe une bibliothèque WebRTC déjà intégrée au navigateur, prise en charge par Chrome, Firefox, etc. Vous pouvez la créer sous Android / iOS et communiquer avec elle via l'API et SDP (Session Description Protocol), qui décrit la session elle-même. Ci-dessous, je vais vous dire ce qui y est inclus. Pour utiliser cette bibliothèque dans votre application, vous devez établir une connexion entre les abonnés via la signalisation. La signalisation est aussi votre service que vous devez écrire vous-même, WebRTC ne le fournit pas.

Plus loin dans l'article, nous discuterons du réseau dans l'ordre, puis de la vidéo / audio, et à la fin, nous écrirons notre signalisation.

Réseau WebRTC ou p2p (en fait c2s2c)

La configuration d'une connexion p2p semble être assez simple.


Nous avons Alice et Bob qui veulent établir une connexion p2p. Ils prennent leurs adresses IP, ils ont un serveur de signalisation auquel ils sont tous les deux connectés, et par lequel ils peuvent échanger ces adresses. Ils échangent des adresses, et oh! Ils ont les mêmes adresses, quelque chose s'est mal passé!


En fait, les deux utilisateurs sont très probablement assis derrière des routeurs Wi-Fi et ce sont leurs adresses IP grises locales. Le routeur leur fournit une fonctionnalité telle que la traduction d'adresses réseau (NAT). Comment fonctionne-t-elle?


Vous avez un sous-réseau gris et une adresse IP externe. Vous envoyez un paquet à Internet à partir de votre adresse grise, NAT remplace votre adresse grise par du blanc et se souvient du mappage: quel port il a envoyé, à quel utilisateur et à quel port il correspond. Lorsque le paquet de retour arrive, il se résout par ce mappage et l'envoie à l'expéditeur. Tout est simple.

Vous trouverez ci-dessous une illustration de l'apparence de ma place.


Il s'agit de mon adresse IP interne et de l'adresse du routeur (d'ailleurs, également grise). Si vous tracez et voyez l'itinéraire, nous verrons mon routeur Wi-Fi: un paquet d'adresses de fournisseur gris et une IP blanche externe. Ainsi, en fait, j'aurai deux NATs: l'un sur lequel je suis en Wi-Fi, et l'autre autre chez le fournisseur, à moins, bien sûr, de m'acheter une adresse IP externe dédiée.

NAT est si populaire parce que:

• de nombreux IPv4 sont toujours manquants et il n'y a pas suffisamment d'adresses;
• NAT semble protéger le réseau;
• c'est une fonction standard du routeur: connectez-vous au Wi-Fi, il y a du NAT là, ça fonctionne.

Par conséquent, seulement 3% des utilisateurs sont assis avec une adresse IP externe, tandis que tous les autres passent par NAT.

NAT vous permet d'accéder en toute sécurité à toutes les adresses blanches. Mais si vous n'êtes allé nulle part, personne ne peut venir à vous.


Établir une connexion p2p est un problème. En fait, Alice et Bob ne peuvent pas s’envoyer de paquets s’ils sont tous deux derrière NAT.

WebRTC dispose d' un protocole STUN pour résoudre ce problème. Il est proposé de déployer un serveur STUN. Puis Alice se connecte au serveur STUN, obtient son adresse IP, l'envoie à Bob via la signalisation. Bob obtient également son adresse IP et l'envoie à Alice. Ils s'envoient des paquets et traversent ainsi le NAT.


Question : Alice a un port spécifique ouvert, NAT / Firewall a déjà été rompu à ce port et Bob est ouvert. Ils connaissent leurs adresses respectives. Alice essaie d'envoyer le paquet à Bob; il envoie le paquet à Alice. Pensez-vous qu'ils peuvent parler ou non?

En fait, vous avez raison dans tous les cas, le résultat dépend du type de paire NAT que les utilisateurs ont.

Traduction d'adresses réseau

Il existe 4 types de NAT:

1. NAT à cône plein;
   
2. NAT à cône restreint;
   
3. Port à cône restreint NAT;
   
4. NAT symétrique
   

Dans la version de base, Alice envoie un paquet au serveur STUN, elle ouvre un port. Bob découvre en quelque sorte son port et envoie un paquet de retour. S'il s'agit d'un NAT à cône complet - le plus simple qui mappe simplement le port externe au port interne, alors Bob sera en mesure d'envoyer immédiatement un paquet à Alice, d'établir une connexion et ils parleront.


Voici le schéma d'interaction: Alice d'un port envoie un paquet au port STUN, STUN lui répond avec son adresse externe. STUN peut répondre à partir de n'importe quelle adresse, s'il s'agit d'un NAT à cône complet, il passera toujours par NAT, et Bob peut répondre à la même adresse.


Dans le cas du NAT à cône restreint, les choses sont un peu plus compliquées. Il se souvient non seulement du port à partir duquel vous devez mapper vers l'adresse interne, mais également de l'adresse externe vers laquelle vous êtes allé. Autrement dit, si vous avez établi une connexion uniquement avec le serveur IP STUN, personne d'autre sur le réseau ne pourra vous répondre et le paquet de Bob n'atteindra pas.


Comment ce problème est-il résolu? Dans un schéma simple (voir l'illustration ci-dessous) comme celui-ci: Alice envoie un paquet à STUN, il lui répond avec son IP. STUN peut y répondre depuis n'importe quel port tant qu'il est NAT à cône restreint. Bob ne peut pas répondre à Alice car il a une adresse différente. Alice répond avec un paquet, connaissant l'adresse IP de Bob. Elle ouvre NAT à Bob, Bob lui répond. Hourra, ils ont parlé.


Une option légèrement plus compliquée est le NAT à cône restreint au port . Néanmoins, seul STUN doit répondre exactement à partir du port auquel il a été accédé. Tout fonctionnera aussi.

La chose la plus nuisible est le NAT symétrique .


Au début, tout fonctionne exactement de la même manière - Alice envoie le paquet au serveur STUN, il répond depuis le même port. Bob ne peut pas répondre à Alice, mais elle envoie le paquet à Bob. Et ici, malgré le fait qu'Alice envoie un paquet au port 4444, le mappage lui alloue un nouveau port. Le NAT symétrique diffère en ce que chaque fois qu'une nouvelle connexion est établie, chaque fois qu'elle émet un nouveau port sur le routeur. En conséquence, Bob bat dans le port à partir duquel Alice est allée à STUN, et ils ne peuvent pas se connecter.

Dans le sens opposé, si Bob a une adresse IP ouverte, Alice peut simplement venir le voir et établir une connexion.

Toutes les options sont rassemblées dans un tableau ci-dessous.


Cela montre que presque tout est possible, sauf lorsque nous essayons d'établir des connexions via NAT symétrique avec NAT à cône restreint de port ou NAT symétrique à l'autre extrémité.


Comme nous l'avons découvert, p2p n'a pas de prix pour nous en termes de latence, mais s'il n'a pas été possible de l'installer, WebRTC nous propose un serveur TURN. Lorsque nous avons réalisé que p2p ne s'installera pas, nous pouvons simplement nous connecter à TURN, qui va proxy tout le trafic. Cependant, en même temps, vous paierez pour le trafic et les utilisateurs peuvent avoir des retards supplémentaires.

Pratique

Google dispose de serveurs STUN gratuits. Vous pouvez les mettre dans la bibliothèque, cela fonctionnera.

Les serveurs TURN ont des informations d'identification (identifiant et mot de passe). Très probablement, vous devrez élever le vôtre, il est plutôt difficile de le trouver gratuitement.

Exemples de serveurs STUN gratuits de Google:

• étourdissement: stun.l.google.com: 19302
• étourdissement: stun1.l.google.com: 19302
• étourdissement: stun2.l.google.com: 19302
• étourdissement: stun3.l.google.com: 19302

Et un serveur TURN gratuit avec des mots de passe: url: 'turn: 192.158.29.39: 3478? Transport = udp', identifiant: 'JZEOEt2V3Qb0y27GRntt2u2PAYA =', nom d'utilisateur: '28224511: 1379330808 ′.

Nous utilisons coturn .


En conséquence, 34% du trafic passe par la connexion p2p, tout le reste est mandaté via le serveur TURN.

Quoi d'autre est intéressant dans le protocole STUN?

STUN vous permet de déterminer le type de NAT.


Lien de diapositive

Lors de l'envoi d'un paquet, vous pouvez indiquer que vous souhaitez recevoir une réponse du même port ou demander à STUN de répondre à partir d'un port différent, d'une IP différente, ou même d'une IP et d'un port différents. Ainsi, pour 4 requêtes au serveur STUN, vous pouvez déterminer le type de NAT .


Nous avons compté les types de NAT et nous avons constaté que presque tous les utilisateurs ont soit NAT symétrique soit NAT à cône restreint de port. Par conséquent, il s'avère que seul un tiers des utilisateurs peuvent établir une connexion p2p.

Vous pouvez vous demander pourquoi je vous dis tout cela si vous pouviez simplement prendre le STUN de Google, le mettre dans WebRTC, et il semble que tout fonctionnera.

Parce que vous pouvez déterminer vous-même le type de NAT.


Il s'agit d'un lien vers une application Java qui ne fait rien de compliqué: il envoie simplement un ping à différents ports et différents serveurs STUN, et regarde quel port il voit à la fin. Si vous avez Open Full cone NAT, le serveur STUN aura le même port. Avec le NAT à cône restreint, vous aurez différents ports pour chaque demande STUN.


Avec Symmetric NAT, ça se passe comme ça dans mon bureau. Il existe des ports complètement différents.

Mais parfois, il existe un modèle intéressant: pour chaque connexion, le numéro de port augmente d'une unité.


Autrement dit, de nombreux NAT sont configurés de manière à augmenter ou diminuer le port d'une constante. Cette constante peut être trouvée et ainsi traverser le NAT symétrique.


Ainsi, nous traversons le NAT - nous allons à un serveur STUN, à un autre, regardons la différence, comparons et essayons à nouveau de donner notre port déjà avec cet incrément ou décrément. Autrement dit, Alice essaie de donner à Bob son port, déjà ajusté pour une constante, sachant que la prochaine fois, ce sera juste cela.


Nous avons donc réussi à souder 12% d'égal à égal .

En fait, parfois, les routeurs externes avec la même IP se comportent de la même manière. Par conséquent, si des statistiques sont collectées et si le NAT symétrique est une caractéristique du fournisseur, et non une caractéristique du routeur Wi-Fi de l'utilisateur, alors le delta peut être prédit, l'envoyer immédiatement à l'utilisateur afin qu'il l'utilise et ne passe pas trop de temps à le déterminer.

Relais CDN ou que faire si vous ne parvenez pas à établir une connexion P2P

Si nous utilisons toujours le serveur TURN et ne travaillons pas en p2p, mais en mode réel, en passant tout le trafic via le serveur, nous pouvons toujours ajouter un CDN. À moins, bien sûr, que vous ayez une aire de jeux. Nous avons nos propres sites CDN, donc pour nous, c'était assez simple. Mais il fallait déterminer où il valait mieux envoyer une personne: sur un site CDN ou, disons, sur une chaîne vers Moscou. Ce n'est pas une tâche très triviale, nous l'avons donc fait:

1. Accidentellement délivré à certains utilisateurs du site de Moscou, certains - à distance.
   
2. Nous avons collecté des statistiques sur l'IP de l'utilisateur, sur les serveurs et sur les caractéristiques du réseau.
   
3. Par maxMind, nous avons regroupé les sous-réseaux, regardé les statistiques et avons pu comprendre par IP quel utilisateur avait le serveur TURN le plus proche pour la connexion.
   

Il y a un CDN à Novossibirsk. Si tout fonctionne pour vous via Moscou, le 99e centile de RTT est de 1,3 seconde. Grâce à CDN, tout fonctionne beaucoup plus rapidement (0,4 seconde).

Est-il toujours préférable d'utiliser une connexion p2p et de ne pas utiliser de serveur? Un exemple intéressant est les deux fournisseurs de Krasnoyarsk Optibyte et Mobra (les noms peuvent avoir changé). Pour une raison quelconque, la connexion entre eux sur p2p est bien pire que via MSK. Ils ne sont probablement pas amis entre eux.


Nous avons analysé tous ces cas, envoyant des utilisateurs au hasard vers p2p ou via MSK, collecté des statistiques et construit des prédictions. Nous savons que les statistiques doivent être mises à jour, donc pour certains utilisateurs, nous établissons spécialement différentes connexions pour vérifier si quelque chose a changé dans les réseaux.

Nous avons mesuré des caractéristiques aussi simples que le temps d'arrondi, la perte de paquets, la bande passante - il reste à apprendre à les comparer correctement.


Comment comprendre ce qui est le mieux: Internet à 2 Mbit / s, RTT 400 ms et perte de paquets de 5% ou 100 Kbit / s, délai de 100 ms et perte de paquets insuffisante?

Il n'y a pas de réponse exacte, l'évaluation de la qualité des appels vidéo est très subjective. Par conséquent, après la fin de l'appel, nous avons demandé aux utilisateurs d'évaluer la qualité des astérisques et de définir les constantes en fonction des résultats. Il s'est avéré que, par exemple, RTT est inférieur à 300 ms - cela n'a plus d'importance, le débit binaire est plus important.

Notes d'utilisateurs plus élevées sur Android et iOS. On voit que les utilisateurs iOS sont plus susceptibles de mettre une unité et plus souvent cinq. Je ne sais pas pourquoi, probablement, les spécificités de la plateforme. Mais nous avons tiré les constantes le long de celles-ci, de sorte que nous avions, comme il nous semble, du bien.

Revenons à notre aperçu de l'article, nous discutons toujours du réseau.

À quoi ressemble la configuration de la connexion?


Nous envoyons des serveurs STUN et TURN à PeerConnection (), une connexion est établie. Alice découvre son IP, l'envoie à la signalisation; Bob apprend l'IP d'Alice. Alice obtient l'IP de Bob. Ils échangent des paquets, peuvent traverser le NAT, définir TURN et communiquer.


Dans les 5 étapes de l'établissement de la connexion dont nous avons discuté précédemment, nous avons déterminé les serveurs, déterminé où les obtenir et les candidats ICE sont des adresses IP externes que nous échangeons via la signalisation. Les adresses IP internes des clients, si elles se trouvent dans la plage d'un réseau Wi-Fi, peuvent également être tentées de percer.

Passons à la partie de la vidéo.

Vidéo et audio

WebRTC prend en charge un certain ensemble de codecs vidéo et audio, mais vous pouvez y ajouter votre propre codec. Fondamentalement pris en charge par H.264 et VP8 pour la vidéo . VP8 est un codec logiciel, il consomme donc beaucoup de batterie. H.264 n'est pas disponible sur tous les appareils (il est généralement natif), la priorité par défaut est donc sur VP8.

À l'intérieur du SDP (Session Description Protocol), il y a négociation de codec: lorsqu'un client envoie une liste de ses codecs, l'autre envoie la sienne en priorité, et ils conviennent des codecs à utiliser pour la communication. Si vous le souhaitez, vous pouvez modifier la priorité des codecs VP8 et H.264, et pour cette raison, vous pouvez économiser la batterie sur certains appareils, où 264 est natif. Voici un exemple de la façon dont cela peut être fait. Nous l'avons fait, il nous a semblé que les utilisateurs ne se plaignaient pas de la qualité, mais en même temps la charge de la batterie était beaucoup moins consommée.

Pour l'audio, WebRTC a OPUS ou G711 , généralement tous les OPUS fonctionnent toujours, rien n'a besoin d'être fait avec.

Voici les mesures de température après 10 minutes d'utilisation.


Il est clair que nous avons testé différents appareils. Ceci est un exemple d'iPhone, et sur celui-ci, l'application OK utilise le moins la batterie, car la température de l'appareil est la moins élevée.

La deuxième chose que vous pouvez activer si vous utilisez WebRTC est de désactiver automatiquement la vidéo lorsque la connexion est très mauvaise .


Si vous avez moins de 40 Kbps, la vidéo se désactivera. Il vous suffit de cocher la case lors de la création de la connexion, la valeur seuil peut être configurée via l'interface. Vous pouvez également définir le débit binaire de démarrage minimal et maximal.


C'est une chose très utile. Si lorsque vous établissez une connexion, vous savez à l'avance le débit que vous attendez, vous pouvez le transférer, l'appel commencera à partir de celui-ci et vous n'aurez pas besoin d'adapter le débit. De plus, si vous savez que vous avez souvent des pertes de paquets ou des baisses de bande passante sur votre canal, la valeur maximale peut également être limitée.

WhatsApp fonctionne avec des vidéos très savonneuses, mais avec de petits retards, car il comprime agressivement le débit binaire d'en haut.

Nous avons collecté des statistiques à l'aide de MaxMind et l'avons cartographié.


Il s'agit d'une qualité de départ approximative que nous utilisons pour les appels dans différentes régions de la Russie.

Signalisation

Vous devrez très probablement écrire cette partie si vous souhaitez passer des appels. Il y a toutes sortes d'embûches. Rappelez-vous à quoi ça ressemble.


Il existe une application avec signalisation qui se connecte et échange avec SDP, et le SDP ci-dessous est l'interface avec WebRTC.

Voici à quoi ressemble une signalisation simple:


Alice appelle Bob. Il se connecte, par exemple, via une connexion Web-socket. Bob reçoit une poussée sur son téléphone portable ou son navigateur, ou dans une sorte de connexion ouverte, se connecte via une prise Web et après cela, le téléphone commence à sonner dans sa poche. Bob décroche le téléphone, Alice lui envoie ses codecs et autres fonctionnalités WebRTC qu'elle prend en charge. Bob lui répond de la même façon, et après cela, ils échangent les candidats qu'ils ont vus. Hourra, appelle!

Tout semble assez long. Tout d’abord, tant que vous n’établissez pas de connexion Web, jusqu’à ce que la poussée arrive et tout le reste, le téléphone de Bob ne sonne pas dans sa poche. Alice attendra tout le temps, pensera où est Bob, pourquoi il ne décroche pas le téléphone. Après confirmation, tout cela prend quelques secondes, et même sur de bonnes connexions, il peut être de 3 à 5 secondes, et sur de mauvaises connexions, les 10.

Nous devons y faire quelque chose! Vous me direz que tout peut être fait très simplement.



Si vous avez déjà une connexion ouverte pour votre application, vous pouvez immédiatement envoyer un push pour établir une connexion, vous connecter au serveur de signalisation souhaité et commencer immédiatement à passer des appels.

Puis une autre optimisation. Même si le téléphone sonne toujours dans votre poche et que vous ne l'avez pas décroché, vous pouvez en fait échanger des informations sur les codecs pris en charge, les adresses IP externes, commencer à envoyer des paquets vidéo vides et, en général, tout sera réchauffé. Une fois que vous aurez décroché le téléphone, tout ira bien.

Nous l'avons fait, et il semblait que tout était cool. Mais non.


Le premier problème est que les utilisateurs annulent souvent l'appel. Ils cliquent sur «Appeler» et annulent immédiatement. En conséquence, la poussée va à l'appel et l'utilisateur disparaît (il a perdu Internet ou autre chose). Pendant ce temps, le téléphone de quelqu'un sonne, il décroche et on ne l'attend pas là-bas. Par conséquent, notre optimisation primitive afin de commencer à appeler le plus rapidement possible ne fonctionne pas vraiment.


Avec une annulation d'appel rapide, il y a une deuxième chose nuisible. Si vous générez l'ID de votre conversation sur le serveur, vous devez attendre une réponse. C'est-à-dire que vous créez un appel, obtenez un ID et seulement après cela, vous pouvez faire ce que vous voulez: envoyer des paquets, échanger, y compris annuler l'appel. C'est une très mauvaise histoire, car il s'avère que tant que la réponse n'est pas arrivée, vous ne pouvez en fait rien annuler du client. Par conséquent, il est préférable de générer une sorte d'ID sur le client tel qu'un GUID et de dire que vous avez démarré l'appel. Les gens font souvent cela: ils ont appelé, annulé et rappelé immédiatement. Pour éviter que cela ne soit gâché, faites un GUID et soumettez-le.


Cela ne semble rien, mais il y a un autre problème. Si Bob a deux téléphones, ou ailleurs, le navigateur reste ouvert, alors tout notre schéma magique pour échanger des paquets, établir une connexion ne fonctionne pas s'il a soudainement répondu à partir d'un autre appareil.

Que faire? Revenons à notre schéma de base de signalisation lente simple et optimisons-le, envoyons le push un peu plus tôt. L'utilisateur commencera à se connecter plus rapidement, mais cela économisera quelques sous.


Que faire de la partie la plus longue après avoir décroché le téléphone et commencé l'échange?


Vous pouvez effectuer les opérations suivantes. Il est clair qu’Alice connaît déjà tous ses codecs et peut les envoyer aux deux téléphones de Bob. Elle peut résoudre toutes ses adresses IP et également les envoyer à la signalisation, ce qui les gardera dans sa file d'attente, mais n'enverra à aucun des clients afin qu'ils commencent à établir une connexion avec elle à l'avance.

Que peut faire Bob? offer, , , , , , . , codec negotiation, signaling , , . Candidates signaling.

, signaling . , , .

. Google Duo WhatsApp.


, - . , signaling, , , , , , . .

?


: , . , , — signaling , , - , , , .


, , , . . , , , , . , .

, 24/7, -, .




web-socket - load balancer, signaling- -, . Zookeeper Leader Election, signaling, conversation. conversation, .

, NewSQL Cassandra . , . , signaling, , signaling, - , Leader Election Zookeeper, , , .

:

• - , , IP signaling
• Signaling , .
• , , , , .
• .

, .

Cassandra, ( ).

, :

• iceServers ;
• Session Description Protocol;
• ;
• signaling WebRTC , IP ;
• !

:

• delay ;
• ;
• .

Ouah!

Security. Man in the middle attack for WebRTC

man in the middle attack for WebRTC. , WebRTC , RTP, 1996 , SDP 1998 SIP.


— RFC RTP, RTP WebRTC.

RFC — audio level, , audio level , . , SDP, , . congestion, -.

WebRTC . 2011 , 2013 Firefox, iOS/Android, 2014 Opera. , - , .


signaling, , DTLS Handshake . , signaling, «» , , , .


, , , HTTPS, WSS .. — ZRTP, , , Telegram.

Telegram , , . , , , , p2p .

Comment ça marche?


— . , , . . K, , , .

, , K ₁ K ₂ . . . K ₁ K ₂ , . K ₁ K ₂ : , — , — , . , , - , , .

• «» NAT type symmetric NAT.
• , : 2 relay, , CDN; .
• , .
• signaling.

, RTMFP, , WebRTC, , . ! 4 .

, :

• WebRTC ( https://webrtc.org/native-code/development/ ), iOS/Android, ;
• coturn ( https://github.com/coturn/coturn );
• signaling.

, .

HighLoad++ 4-.

, . , 19 (10 9 -) , - . , , .