Nous écrivons notre protocole sur UDP

Les premières émissions en direct de la scène sont apparues en Russie il y a près de 70 ans et ont été diffusées à partir d'une station de télévision mobile (PTS), qui ressemblait à un trolleybus et permettait de diffuser depuis l'extérieur du studio. Et il y a seulement trois ans, Periscope a autorisé l'utilisation d'un téléphone mobile au lieu d'un «trolleybus».

Mais cette application présentait un certain nombre de problèmes liés, par exemple, aux retards de diffusion, à l'incapacité de regarder des émissions en haute qualité, etc.


Six mois plus tard, à l'été 2016, Odnoklassniki a lancé son application mobile de streaming OK Live, dans laquelle ils ont essayé de résoudre ces problèmes.

Alexander Tobol est responsable de la partie technique de la vidéo à Odnoklassniki et à Highload ++ 2017, il a expliqué comment écrire votre protocole UDP et pourquoi cela pourrait être nécessaire.

À partir de la transcription de son rapport, vous apprendrez tout sur les autres protocoles de streaming vidéo, quelles sont les nuances et quelles astuces sont parfois nécessaires.


Ils disent que nous devrions toujours commencer par l'architecture et les savoirs traditionnels - c'est soi-disant impossible sans cela! Alors faisons-le.

Architecture et savoirs traditionnels

Sur la diapositive ci-dessous se trouve le schéma d'architecture de tout service de streaming: la vidéo est envoyée à l'entrée, convertie et transmise à la sortie . Nous avons ajouté un peu plus d'exigences à cette architecture: la vidéo doit être fournie par les ordinateurs de bureau et les téléphones mobiles, et la sortie doit aller aux mêmes ordinateurs de bureau, téléphones mobiles, smartTV, Chromcast, AppleTV et autres appareils - tout ce que la vidéo peut être lu.


Ensuite, nous passons au mandat. Si vous avez un client, vous avez des savoirs traditionnels. Si vous êtes un réseau social, vous n'avez pas de savoirs traditionnels. Comment le maquiller?

Vous pouvez bien sûr interroger les utilisateurs et découvrir tout ce qu'ils veulent. Mais ce sera tout un tas de désirs qui ne correspondent pas à ce dont les gens ont vraiment besoin.

Nous avons décidé d'aller dans le sens inverse et avons vu ce que les utilisateurs ne voulaient PAS voir du service de diffusion.

• La première chose que l'utilisateur ne veut pas est de voir le retard au début de la diffusion .
  
• L'utilisateur ne souhaite pas voir une image de flux de faible qualité .
  
• Si la diffusion est interactive lorsque l'utilisateur communique avec son public (retransmissions en direct, appels, etc.), il ne veut pas voir le délai entre le streamer et le spectateur .
  

Voici à quoi ressemble un service de streaming normal. Voyons ce qui peut être fait pour faire un service de streaming régulier au lieu de celui habituel.


Vous pouvez commencer par regarder tous les protocoles de streaming, sélectionner les plus intéressants et les comparer. Mais nous l'avons fait différemment.

Qu'ont les concurrents?

Nous avons commencé par explorer les services aux concurrents. Open Periscope - qu'est-ce qu'ils ont?

Comme toujours, l'essentiel est l'architecture.


Sara Hyder, l'ingénieur principal de Periscope, écrit qu'ils utilisent Wowza pour le backend. Si nous lisons un peu plus d'articles, nous verrons ce qu'ils diffusent en utilisant le protocole RTMP et le distribuerons soit en RTMP soit en HLS. Voyons ce que sont ces protocoles et comment ils fonctionnent.

Nous testons Periscope sur nos trois exigences principales.

Ils ont une vitesse de démarrage acceptable (moins d'une seconde sur de bons réseaux), une qualité constante d' environ 600 px (pas HD), et en même temps des retards pouvant aller jusqu'à 12 secondes .

Au fait, comment mesurer le retard dans la diffusion?

Il s'agit d'une photographie d'une mesure de retard. Il y a un téléphone portable avec une minuterie. Nous activons la diffusion et voyons l'image de ce téléphone sur l'écran. Pendant 0,15 milliseconde, l'image est tombée sur le capteur de l'appareil photo et a été supprimée de la mémoire vidéo sur l'écran du téléphone. Après cela, nous activons le navigateur et regardons la diffusion.

Aïe! Elle est un peu en retard - environ 12 secondes.

Pour trouver les raisons du retard, nous profilons le streaming vidéo.

Donc, il y a un téléphone portable, la vidéo sort de la caméra et entre dans le buffer vidéo. Ici, les retards sont minimes (≈0,15 ms). Ensuite, l'encodeur code le signal, l'emballe dans un paquet et l'envoie au tampon de socket. Tout vole sur le Web. De plus, la même chose se produit sur l'appareil récepteur.

Fondamentalement, il y a deux principaux points difficiles à considérer:

• encodage / décodage vidéo;
  
• protocoles réseau .
  

Encodage / décodage vidéo

Je vais parler un peu du codage. Vous le rencontrerez de toute façon si vous effectuez un streaming en direct à faible latence.

Qu'est-ce qu'une vidéo? Il s'agit d'un ensemble de cadres, mais pas tout à fait simple. Les cadres sont de trois types: cadres I, P et B:

• I-frame est juste jpg. En fait, c'est un cadre de référence, il ne dépend de personne et contient une image claire.
  
• La trame P dépend uniquement des trames précédentes.
  
• La trame B délicate peut dépendre de l'avenir. Cela signifie que pour calculer l'image b, il est nécessaire que les images futures proviennent également de la caméra. Ce n'est qu'alors qu'une trame b peut être décodée avec un certain retard.
  

Cela montre que les trames B sont nuisibles . Essayons de les supprimer.

1. Si vous diffusez à partir d'un appareil mobile, vous pouvez essayer d'activer le profil de base . Cela désactivera le cadre B.
   
2. Vous pouvez essayer de configurer le codec et de réduire le délai pour les futures trames afin que les trames arrivent plus rapidement.
   
3. Une autre chose importante dans le réglage du codec est l' inclusion de CBR (débit binaire constant).
   

Le fonctionnement des codecs est illustré dans la diapositive ci-dessus. Dans cet exemple, la vidéo est une image statique, son encodage économise de l'espace disque, car presque rien n'y change et le débit vidéo est faible. Des changements sont en cours - l'entropie augmente, le débit vidéo augmente - c'est génial de stocker sur le disque.

Mais au moment où les changements actifs ont commencé et que le débit binaire a augmenté, toutes les données ne se glisseraient probablement pas dans le réseau. C'est exactement ce qui se passe lorsque vous passez un appel vidéo et commencez à tourner, et votre abonné ralentit l'image. Cela est dû au fait que le réseau n'a pas le temps de s'adapter à l'évolution du débit binaire.

Il faut inclure CBR . Tous les codecs Android ne le prendront pas correctement en charge, mais ils s'efforceront de le faire. Autrement dit, vous devez comprendre qu'avec CBR, vous n'obtiendrez pas l'image parfaite du monde, comme dans l'image du bas, mais cela vaut la peine de l'activer.

4. Et sur le backend, vous devez ajouter le codec de zérolatence à H264 - cela vous permettra de ne pas faire de dépendances dans les frames pour le futur.

Protocoles de transfert vidéo

Tenez compte des protocoles de streaming proposés par l'industrie. Je les ai conditionnellement divisés en deux types:

1. protocoles de streaming;
   
2. protocoles de segment.
   

Les protocoles de streaming sont des protocoles issus du monde des appels p2p: RTMP, webRTC, RTSP / RTP . Ils diffèrent en ce que les utilisateurs conviennent du canal dont ils disposent, sélectionnez le débit binaire du codec en fonction du canal. Et ils ont aussi des équipes supplémentaires de ce genre, comme «donnez-moi un coup de référence». Si vous avez perdu une trame, dans ces protocoles, vous pouvez la demander à nouveau.

La différence entre les protocoles de segment est que personne ne négocie avec personne. Ils coupent la vidéo en segments, stockent chaque segment dans différentes qualités, et le client peut choisir le segment à regarder. Chaque segment commence par un cadre de référence.

Examinez les protocoles plus en détail. Commençons par les protocoles de streaming et voyons quels problèmes nous pouvons rencontrer si nous utilisons des protocoles de streaming pour le streaming de diffusion.

Protocoles de streaming

Periscope utilise RTMP. Ce protocole est apparu en 2009, et au début Adobe ne l'a pas entièrement spécifié. Il a ensuite eu une certaine difficulté avec le fait qu'Adobe voulait vendre exclusivement son serveur. Autrement dit, RTMP développé assez difficile. Son principal problème est qu'il utilise TCP , mais pour une raison quelconque, Periscope l'a choisi.



Si vous lisez en détail, il s'avère que Periscope utilise RTMP pour diffuser avec un petit nombre de téléspectateurs. De telles émissions, si votre chaîne est insuffisante, vous ne pourrez probablement pas la regarder.



Prenons un exemple spécifique. Il y a un utilisateur avec un canal de communication étroit qui regarde votre émission. Vous êtes d'accord avec lui sur RTMP sur le faible débit binaire et commencez à diffuser pour lui personnellement.

Un utilisateur avec un internet cool vient à vous, vous avez aussi un internet cool, mais vous avez déjà convenu d'une mauvaise qualité avec quelqu'un, et il s'avère que ce troisième avec internet cool regarde un flux de mauvaise qualité, malgré le fait qu'il puisse bien paraître.

Nous avons décidé de résoudre ce problème. Nous avons permis à RTMP d'être tronqué individuellement pour chaque client, c'est-à-dire que les streamers négocient avec le serveur, diffusent à la qualité la plus élevée possible et chaque client reçoit la qualité que le réseau lui permet.

Ouah!

Mais encore, nous avons RTMP sur TCP, et personne ne nous a assuré de bloquer le début de la file d'attente.



Ceci est illustré dans la figure: nous recevons des trames audio et vidéo, RTMP les emballe, peut-être les mélangent-ils d'une manière ou d'une autre et s'envolent vers le réseau.

Mais supposons que nous perdions un paquet. Il est possible que le même paquet jaune perdu - il s'agit généralement d'une trame P de certains précédents - ait pu être supprimé. Peut-être, au minimum, on pourrait lire de l'audio. Mais TCP ne nous donnera pas le reste des paquets, car il garantit la livraison et la séquence des paquets . Nous devons en quelque sorte y faire face.


Il y a un autre problème avec l'utilisation du protocole TCP en streaming.

Disons que nous avons un tampon et une bande passante réseau élevée. Nous y générons des paquets haute résolution à partir de notre codec. Alors - op! - le réseau a commencé à mal fonctionner. Au niveau du codec, nous avons déjà indiqué que le débit doit être abaissé, mais des paquets prêts à l'emploi sont déjà dans la file d'attente et vous ne pouvez en aucun cas les supprimer de là . TCP est désespéré de pousser les paquets HD à travers notre 3G.

Nous n'avons pas de gestion de tampon, pas de priorisation, donc TCP est extrêmement inapproprié pour la diffusion en continu .



Jetons maintenant un œil aux réseaux mobiles. Cela peut être surprenant pour les résidents des capitales, mais notre réseau mobile moyen ressemble à ceci:

• 1,1 Mbps de trafic;
  
• Perte de paquets de 0,1%;
  
• RTT moyen de 300 ms.
  

Et si vous regardez certaines régions et certains opérateurs spécifiques, ils ont un pourcentage de perte de paquets quotidien moyen de plus de 3% , et le RTT à partir de 600 ms est normal.

TCP est, d'une part, un protocole génial - il est très difficile d'apprendre à une voiture à conduire tout de suite sur les autoroutes et hors route. Mais lui apprendre alors aussi à survoler les réseaux sans fil était très difficile.

Perdre même 0,001% des paquets entraîne une réduction de 30% du débit. Autrement dit, notre utilisateur n'utilise pas le canal de 30% en raison de l'inefficacité du protocole TCP dans les réseaux avec perte de paquets aléatoire.

Dans certaines régions, la perte de paquets atteint 1%, puis l'utilisateur dispose d'environ 10% de la bande passante.

Par conséquent, nous ne ferons pas TCP .

Voyons ce qu'il y a d'autre dans le monde du streaming depuis UDP.

Le protocole WebRTC a très bien fonctionné pour les appels p2p. Sur des sites très populaires, ils écrivent que l'utiliser pour les appels est très cool, mais pour diffuser des vidéos et de la musique, ce n'est pas bon.

Son principal problème est qu'il néglige les pertes . Avec toutes les situations étranges, il tombe juste.

Il y a toujours un problème dans son attachement aux appels, le fait est qu'il crypte tout. Par conséquent, si vous diffusez des émissions, et qu'il n'est pas nécessaire de crypter l'intégralité du flux audio / vidéo en démarrant WebRTC, vous aurez quand même une tension sur votre processeur. Vous n'en aurez peut-être pas besoin.



Le streaming RTP est le protocole de base pour la transmission de données via UDP. Ci-dessous sur la diapositive à droite se trouve un ensemble d'extensions et de RFC qui ont dû être implémentées dans WebRTC afin d'adapter ce protocole pour les appels. En principe, vous pouvez essayer de faire quelque chose comme ça - composer un ensemble d'extensions à RTP et obtenir le streaming UDP. Mais c'est très difficile .

Le deuxième problème est que si l'un de vos clients ne prend en charge aucune extension, le protocole ne fonctionnera pas.

Protocoles de segment

MPEG-Dash est un bon exemple de protocole vidéo segmenté. Il se compose d'un fichier manifeste que vous publiez sur votre portail. Il contient des liens vers des fichiers de différentes qualités, au début du fichier, il y a un index qui indique à quel endroit du fichier quel segment commence.



La vidéo entière est divisée en segments, par exemple, pendant 3 secondes, chaque segment commence par une image de référence. Si vous regardez une telle vidéo et que votre débit change, alors du côté client, vous commencez à prendre le segment de la qualité dont vous avez besoin.

Un autre exemple de streaming segmenté est HLS .

MPEG-Dash est une solution de Google, elle fonctionne bien sous Android, et la solution Apple est plus ancienne, elle présente un certain nombre d'inconvénients.



Le premier d'entre eux est que le manifeste principal contient des liens vers des manifestes secondaires, les manifestes secondaires pour chaque qualité spécifique contiennent des liens vers chaque segment individuel, et chaque segment individuel est représenté par un fichier distinct.

Si vous regardez encore plus en détail, alors à l'intérieur de chaque segment se trouve MPEG2-TS. Ce protocole a également été conçu pour le satellite; sa taille de paquet est de 188 octets . Il est très gênant d’emballer des vidéos de cette taille, en particulier parce que vous les fournissez tout le temps avec un petit en-tête.

En fait, cela est difficile non seulement pour les serveurs qui, pour traiter 40 Go de trafic, doivent collecter 26 millions de paquets , mais cela est également difficile pour le client. Par conséquent, lorsque nous avons réécrit le lecteur iOS sur MPEG-Dash, nous avons même constaté des gains de performances.



Mais Apple ne reste pas immobile. En 2016, ils ont finalement annoncé qu'ils avaient la possibilité de pousser un fragment de MPEG4 dans HLS. Ensuite, ils ont promis de l'ajouter uniquement aux développeurs, mais il semble que le support de macOS et iOS devrait maintenant apparaître.

Autrement dit, il semblerait que le streaming de fragments soit pratique - venez, prenez le fragment souhaité, commencez par le cadre de référence - cela fonctionne.

Moins: il est clair que le cadre de référence à partir duquel vous avez commencé n'est pas le cadre que celui qui diffuse maintenant le possède. Par conséquent, il y a toujours un retard .

En général, il est possible de terminer HLS à des retards de l'ordre de 5 secondes, quelqu'un dit qu'il a réussi à en obtenir 4, mais en principe, la décision d'utiliser le streaming de fragments pour la traduction n'est pas très bonne .

Difficulté vs retard

Examinons tous les protocoles disponibles et trions-les selon deux paramètres:

• la latence qu'ils donnent entre l'émission et le spectateur;
• complexité

Plus le délai garanti par le protocole est court, plus il est complexe.

Que voulons-nous?

Nous voulons faire un protocole UDP pour le streaming de 1 à N avec un retard comparable à la communication p2p, avec l'option de cryptage optionnel des paquets selon qu'il s'agit d'une diffusion privée ou publique.

Quelles sont les autres options? Vous pouvez attendre, par exemple, lorsque Google publie son QUIC.

Je vais vous dire un peu ce que c'est. Google positionne Google QUIC en remplacement de TCP - une sorte de TCP 2.0. Il a été développé depuis 2013, maintenant il n'a pas de spécification, mais il est entièrement disponible dans Google Chrome, et il me semble qu'ils l'activent parfois pour certains utilisateurs afin de voir comment cela fonctionne. En principe, vous pouvez accéder aux paramètres, activer QUIC, accéder à n'importe quel site Google et obtenir cette ressource via UDP.

Nous avons décidé de ne pas attendre qu'ils le précisent tous et de déposer notre décision.

Exigences du protocole:

1. Le multithreading , c'est-à-dire que nous avons plusieurs flux - contrôle, vidéo, audio.
   
2. Une garantie de livraison facultative - le flux de contrôle est garanti à 100%, la vidéo dont nous avons le moins besoin - nous pouvons y déposer l'image, nous aimerions toujours l'audio.
   
3. Hiérarchisation des flux - pour que l'audio avance, et le gestionnaire a généralement volé.
   
4. Cryptage optionnel : soit toutes les données, soit uniquement les en-têtes et les données critiques.
   

Il s'agit d'un triangle standard: si un bon réseau, alors haute qualité et faible latence. Dès qu'un réseau instable apparaît, les paquets commencent à disparaître, on équilibre entre qualité et délai. Nous avons le choix: soit attendre que le réseau s'améliore et envoyer tout ce qui s'est accumulé, soit abandonner et vivre avec.

Si vous triez les protocoles selon ce principe, il est clair que plus le temps d'attente est court, plus la qualité est mauvaise - une conclusion assez simple.

Nous voulons coincer notre protocole dans la zone où les retards sont proches de WebRTC, mais en même temps pouvoir pousser un peu, car après tout nous n'avons pas d'appels, mais des émissions. L'utilisateur souhaite finalement recevoir un flux de qualité.

Développement

Commençons à écrire le protocole UDP, mais regardons d'abord les statistiques.



Ce sont nos statistiques sur les réseaux mobiles. On peut voir que l'Internet moyen est légèrement plus que mégabits, une perte de paquets d'environ 1% est normale, et RTT dans la région de 600 ms - sur 3G, ce ne sont que des valeurs moyennes.

Nous nous concentrerons sur cela lors de la rédaction du protocole - allons-y!

Protocole UDP

On ouvre le socket UDP, on retire les données, on emballe, on envoie. Nous prenons le deuxième pack du codec, nous envoyons toujours. Tout semble super!



Mais nous obtenons l'image suivante: si nous commençons à envoyer au hasard des paquets UDP à la socket, selon les statistiques, au 21e paquet, la probabilité qu'il atteindra ne sera que de 85%. Autrement dit, la perte de paquets sera déjà de 15%, ce qui n'est pas bon. Cela doit être corrigé.



Ceci est fixé en standard. L'illustration illustre la vie sans Pacer et la vie avec Pacer .

Pacer est une chose qui répartit les paquets dans le temps et contrôle leur perte; Il regarde ce qu'est la perte de paquets maintenant, en fonction de cela, il s'adapte à la vitesse du canal.

Comme nous nous en souvenons, pour les réseaux mobiles, la perte de paquets de 1 à 3% est la norme. En conséquence, nous devons en quelque sorte travailler avec cela. Et si nous perdons des colis?

Retransmettre

En TCP, comme vous le savez, il existe un algorithme de retransmission rapide: nous envoyons un paquet, le second, si le paquet est perdu, puis après un certain temps (période de retransmission), nous envoyons le même paquet.

Quels en sont les avantages? Pas de problèmes, pas de redondance, mais il y a un moins - une certaine période de retransmission .



Cela semble très simple: après un certain temps, vous devez répéter le colis si vous n'avez pas reçu de confirmation à ce sujet. Logiquement, cela peut être un temps égal au temps de ping. ping — , RTT time , , .

, , , , jitter: ping-. , , 46 . jitter — 50.



. RTT , , acknowledge . , RFC6298, TCP , .

jitter. jitter ping 15%. , retransmit period , , 20% , RTT.



retransmit. acknowledge . , , . retransmit period, . , .

, retransmit . , , packet loss 5%, 400 , 400 1 packet-drop, , retransmit period , .

, . , , acknowledge . , — , , speculative retransmit .

retransmit, .

. , Forward Error Correction ? , , XOR. , , .



Ouah! round trip, .

, , ? XOR — , Reed-Solomon, Fountain codes .. : K , N , N .

!

, , , Forward Error Correction negative acknowledgement.

NACK

, parity protection ( ) , .

NACK:

• , negative acknowledgement, .
  
• FEC.
  

, :

1. , FEC + NACK;
   
2. , Fast retransmit.
   

, .



, , ( ). , , 11 , 60-80 . , , .

6 .



, , . , . , Wi-Fi 22 5 , 3G 34 8 .



: , 90% packet loss 10 , gap 25 , — FEC + NACK Fast retransmit?

, , , Google, QUIC 2013 , Forward Error Correction , , . 2015 .

FEC + NACK, .

, .



, , c :

• 1 / ;
  
• 1% packet loss;
  
• 300 RTT;
  
• 1 000 — ;
  
• 1 000 .
  

10 . packet loss 1% 1 000 10. — 100 1 — , 2 , .

, . 500- , 10 .

:

• 500 Forward Error Correction. , .
  
• NACK, , .
  
• Fast Retransmit, .
  

Forward Error Correction , — gap 200-300 .

Fast Retransmit

: , 10 , , , retransmit period , .



, retransmit period 350 , packet gap — 25-30 , 100. , , retransmit , .

, .

Lorsque vous écrivez votre protocole sur UDP et que vous avez la possibilité d'envoyer des paquets, vous obtenez des chignons supplémentaires.



Il y a un tampon d'envoi, il contient une trame de référence, des trames p / b. Ils vont régulièrement en ligne. Ensuite, ils ont cessé d'aller sur le réseau, et à leur tour, d'autres paquets sont arrivés.

Vous comprenez qu'en fait, tous les packages qui sont dans la file d'attente ne sont plus intéressants pour le client, car, par exemple, plus de 0,5 s se sont écoulés et il vous suffit de coller l'écart sur le client et de continuer à vivre.

Vous pouvez, ayant des informations sur ce qui est stocké dans ces packages, nettoyer non seulement le cadre de référence, mais aussi tous les p / b qui en dépendent, et ne laisser que les données nécessaires et complètes dont le client peut alors avoir besoin.

MTU

Puisque nous écrivons le protocole nous-mêmes, nous devrons faire face à la fragmentation IP. Je pense que beaucoup de gens le savent, mais juste au cas où, je vous le dirai brièvement.



Nous avons un serveur, il envoie des paquets au réseau, ils arrivent au routeur et à son niveau le MTU (unité de transmission maximale) devient inférieur à la taille du paquet qui est arrivé. Il divise le paquet en grand et petit (ici 1100 et 400 octets) et envoie.

En principe, il n'y a pas de problème, tout se rassemblera sur le client et fonctionnera. Mais si nous perdons 1 paquet, nous supprimons tous les paquets, et nous obtenons des coûts supplémentaires pour les en-têtes de paquets. Par conséquent, si vous écrivez votre protocole, il est idéal de travailler avec la quantité de MTU.

Comment le compter?

En fait, Google ne dérange pas, met environ 1200 octets dans son QUIC et ne le sélectionne pas, car alors la fragmentation IP collectera tous les paquets.



Nous faisons exactement la même chose - d'abord nous définissons une taille par défaut et commençons à envoyer des paquets - laissez-les les fragmenter.

En parallèle, exécutez un thread séparé et créez un socket avec l'indicateur d'interdiction de fragmentation pour tous les paquets. Si le routeur rencontre un tel paquet et ne peut pas fragmenter ces données, il abandonnera le paquet et vous enverra éventuellement via ICMP qu'il y a des problèmes, mais très probablement, ICMP sera fermé et cela ne se produira pas. Par conséquent, nous essayons simplement, par exemple, trois fois d'envoyer un paquet d'une certaine taille à un certain intervalle. S'il n'atteint pas, nous pensons que le MTU est dépassé et le réduisons encore.

Ainsi, ayant le MTU de l'interface Internet qui se trouve sur l'appareil et un minimum de MTU, nous sélectionnons simplement le MTU correct par une recherche unidimensionnelle. Après cela, nous ajustons la taille du paquet dans le protocole.

En fait, cela change parfois. Nous avons été surpris, mais en train de changer de Wi-Fi, etc. MTU est en train de changer. Il est préférable de ne pas arrêter ce processus parallèle et de corriger MTU de temps en temps.



Distribution MTU plus élevée dans le monde. Nous avons obtenu environ 1100 octets sur le portail.

Cryptage

Nous avons dit que nous voulions éventuellement gérer le chiffrement. Nous faisons l'option la plus simple - Diffie-Hellman sur les courbes elliptiques. Nous le faisons facultativement - nous chiffrons uniquement les paquets de contrôle et les en-têtes afin que l'homme du milieu ne puisse pas recevoir la clé de diffusion, l'intercepter, etc.



Si la diffusion est privée, nous pouvons également ajouter le cryptage de toutes les données.

Les paquets sont chiffrés avec AES-256 indépendamment, de sorte que la suppression de paquets n'affecte pas le chiffrement ultérieur des paquets.

Priorisation

Rappelez-vous, nous voulions plus de priorisation du protocole.



Nous avons des métadonnées, des trames audio et vidéo, nous les envoyons avec succès sur le réseau. Ensuite, notre réseau brûle en enfer et pendant longtemps ne fonctionne pas - nous comprenons que nous devons abandonner les paquets.

Nous supprimons principalement les paquets vidéo, puis essayons de supprimer l'audio et de ne jamais toucher aux paquets de contrôle, car des données telles que les changements de résolution et d'autres problèmes importants peuvent les traverser.

Chignon supplémentaire sur UDP

Si vous écrivez votre protocole UDP, par exemple, avec une communication bidirectionnelle, vous devez comprendre qu'il existe une dissociation NAT et la possibilité que vous ne puissiez pas retrouver le client à partir du serveur.



Sur la diapositive, il est parfois impossible d'atteindre le client depuis le serveur via UDP.

De nombreux sceptiques affirment que les routeurs sont conçus de telle manière que NAT Unbinding évince principalement les routes UDP. Mais ce qui précède montre que si Keep-Alive ou ping est inférieur à 30 secondes, alors avec une probabilité de 99%, il sera possible d'atteindre le client.

Disponibilité UDP sur les appareils mobiles dans le monde

Google indique 6%, mais il s'est avéré que 7% des utilisateurs mobiles ne peuvent pas utiliser UDP . Dans ce cas, nous laissons notre beau protocole avec priorisation, chiffrement et tout, uniquement sur TCP.

Sur UDP, VOIP fonctionne désormais sur WebRTC, Google QUIC et de nombreux jeux fonctionnent sur UDP. Par conséquent, je ne pense pas que UDP sera fermé sur les appareils mobiles.

En conséquence, nous:

• Réduction du délai entre le streamer et l'observateur à 1 s.
  
• Nous nous sommes débarrassés de l'effet cumulatif dans les tampons, c'est-à-dire que la diffusion n'est pas en retard.
  
• Le nombre de stands dans le public a diminué .
  
• Ils ont pu prendre en charge le streaming sur les appareils mobiles FullHD.
  

• Le délai dans notre application mobile OK Live est de 25 ms à 10 ms plus long que le scanner de la caméra fonctionne, mais ce n'est pas si effrayant.
  
• La diffusion sur le Web montre un retard de seulement 690 ms - espace!
  

Quoi d'autre peut diffuser sur Odnoklassniki

• Accepte notre protocole OKMP à partir d'appareils mobiles;
  
• peut accepter RTMP et WebRTC;
  
• distribue HLS, MPEG-Dash, etc.
  

Si vous avez fait attention, vous avez remarqué que j'ai dit que nous pouvons prendre, par exemple, WebRTC de l'utilisateur et le convertir en RTMP.



Il y a une nuance. En fait, WebRTC est un protocole orienté paquets et utilise le codec audio OPUS. Vous ne pouvez pas utiliser OPUS dans RTMP.

Sur les serveurs principaux, nous utilisons RTMP partout. Par conséquent, nous avons dû apporter quelques correctifs supplémentaires dans FF MPEG, ce qui nous permet de pousser OPUS en RTMP, de le convertir en AAC et de le donner aux utilisateurs déjà en HLS ou autre chose.

À quoi ça ressemble en nous?

• Les utilisateurs utilisant l'un des protocoles téléchargent la vidéo originale sur notre serveur de téléchargement.
  
• Là, nous déployons le protocole.
  
• Nous envoyons RTMP à l'un des serveurs de transformation vidéo.
  
• L'original est toujours stocké dans un stockage distribué afin que rien ne soit perdu.
  
• Après cela, toutes les vidéos vont au serveur de distribution.
  

Pour le fer, nous avons les éléments suivants:


Je vais vous en dire un peu plus sur la tolérance aux pannes:

• Les serveurs de téléchargement sont distribués dans différents centres de données, se tiennent derrière différentes IP.
  
• Les utilisateurs viennent, reçoivent IP sur DNS.
  
• Upload-server envoie la vidéo aux serveurs de découpage, ils coupent et donnent aux serveurs de distribution.
  
• Pour les diffusions plus populaires, nous commençons à ajouter un plus grand nombre de serveurs de distribution.
  
• Nous sauvegardons tout ce qui vient de l'utilisateur dans le référentiel, afin que plus tard, nous puissions créer une archive de diffusion et ne rien perdre.
  
• Stockage tolérant aux pannes réparti sur trois centres de données.
  

Pour déterminer quel serveur est actuellement responsable de la traduction, nous utilisons ZooKeeper . Pour chaque traduction, nous stockons un nœud et créons des nœuds éphémères pour chaque serveur. En fait, c'est une telle chose qui permet à un flux de créer une file d'attente de serveurs à traiter. Le leader actuel de cette ligne est toujours engagé dans le traitement des flux.

Nous testerons rapidement la tolérance aux pannes. Nous commençons immédiatement par la disparition de l'intégralité du datacenter.

Que va-t-il se passer?

• L'utilisateur DNS prendra la prochaine IP d'un autre serveur de téléchargement.
  
• À ce moment, ZooKeeper comprendra que le serveur de ce centre de données est mort et sélectionnera le serveur de découpage pour un autre.
  
• Les serveurs de téléchargement sauront qui est désormais responsable de la transformation de ce flux et le distribueront.
  

En principe, tout cela se produira avec un minimum de retards.

Utilisation du protocole dans le produit

Nous avons créé l'application mobile de streaming OK Live. Il est entièrement intégré au portail. Les utilisateurs peuvent communiquer, effectuer des diffusions en direct, il existe une carte des diffusions, une liste des diffusions populaires - en général, tout ce que vous pouvez souhaiter.



Nous avons également ajouté la possibilité de diffuser en FullHD. Vous pouvez connecter une caméra d'action sur Android à un appareil Android.



Nous avons maintenant un mécanisme qui permet des diffusions en direct. Par exemple, nous avons établi une ligne directe avec le président via OK Live et l'avons diffusée dans tout le pays . Les utilisateurs regardaient et à travers le flux venant en sens inverse pouvaient se mettre en ondes et poser leurs questions.

En fait, deux flux entrants avec un délai minimum fournissent un certain format de conférence publique.

En fait, nous nous sommes rencontrés quelque part en 2 secondes - une seconde là-bas et une seconde de retour. Rappelez-vous ce «chariot» dont j'ai parlé au début de l'article - il ressemble maintenant à 2 énormes camions. Pour la diffusion télévisée, retirer de l'appareil photo et simplement tout mélanger avec un retard d'environ 1 à 2 s est tout à fait normal.

En fait, nous avons réussi à reproduire quelque chose de comparable avec le TCP moderne actuel.



Les émissions en direct sont la tendance actuelle. Depuis un an et demi sur le portail OK, ils ont triplé (non sans l'aide de l'application OK Live).



Toutes les émissions sont enregistrées par défaut. Nous avons environ 50 000 flux par jour, ce qui génère environ 17 téraoctets de trafic par jour, mais en général, toute la vidéo sur le portail génère environ un pétaoctet de données par mois.



Qu'avons-nous obtenu:

• Pourrait garantir la durée du délai entre le streamer et le public.
  
• Nous avons créé la première application FullHD mobile pour le streaming sur un canal Internet mobile à évolution dynamique.
  
• Nous avons eu la possibilité de perdre des centres de données et en même temps de ne pas interrompre la diffusion
  

Qu'avez-vous appris:

• Qu'est-ce qu'une vidéo et comment la diffuser?
  
• Que vous pouvez écrire votre protocole UDP si vous savez avec certitude que vous avez une tâche très spécifique et des utilisateurs spécifiques.
  
• À propos de l'architecture de tout service de streaming - la vidéo entre en entrée, convertit et quitte.
  

Chez Highload ++ Siberia, Alexander Tobol promet de parler du service d'appel OK, il sera intéressant de savoir ce qui a réussi à être appliqué à partir de ce qui a été discuté dans cet article, et ce qui a dû être mis en œuvre complètement à nouveau.

Dans la même section, des rapports sont prévus sur des sujets hautement spécialisés:

• Eugene Rossinsky (ivi) sur le système de collecte de statistiques détaillées sur le fonctionnement des nœuds CDN.
  
• Anton Rusakova (Badoo) sur l'intégration des systèmes de paiement sans utiliser leur propre facturation.