💠 🥤 🙎 HighLoad ++, Mikhail Raichenko (ManyChat): presque sans magie, ni à quel point il est facile de distribuer un flux vidéo térabit 🙎🏽 👊🏿 👢

La prochaine conférence HighLoad ++ se tiendra les 6 et 7 avril 2020 à Saint-Pétersbourg. Détails et billets ici . HighLoad ++ Moscou 2018. Salle «Delhi + Calcutta». 8 novembre, 14 h Résumés et présentation .

Je travaille dans l'équipe VKontakte et je développe un système de diffusion vidéo.
Dans le rapport, je partagerai les caractéristiques du développement du backend, l'évolution de notre système et les solutions techniques auxquelles nous sommes parvenus: 

comment nous avons fait le backend de diffusion vidéo et le processus d'évolution tel qu'il est;
l'impact des exigences commerciales et opérationnelles sur l'architecture;
«Attendez» et «réessayez» échouera;
comment les tâches les plus simples sont compliquées par le nombre d'utilisateurs;
comment réduire la latence sans UDP;
Nous effectuons des tests de résistance 2 fois par jour, ou ce que Clover nous a aidé.

Mikhail Raichenko (ci-après - MR): - Une petite excursion. Je vais vous parler des personnes qui nous diffusent, du direct (en direct), des plateformes sur lesquelles nous recevons le flux vidéo et que nous distribuons. À la fin, je parlerai de l’architecture actuelle du live, de ses limites et de ses capacités, ainsi que de la façon dont l’architecture actuelle a survécu à un effet tel que «Clover».

À propos des diffusions en direct. Plan du rapport

Tout d'abord, je vais parler un peu des diffusions en direct et des streamers eux-mêmes, en nous envoyant du contenu vidéo que nous montrons à d'autres téléspectateurs.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

Tous les services de diffusion ressemblent à ceci:

nous avons un streamer, il nous envoie un flux RTMP et nous montrons le public - rien de surprenant, rien de surnaturel.

D'où vient le flux vidéo? Une source importante de trafic pour nous est notre application mobile VKlife. Qu'est-ce qui est bon chez lui? Dans celui-ci, nous pouvons contrôler entièrement la façon dont nous encodons la vidéo. Nous pouvons faire de nombreuses optimisations du côté client, de sorte que plus tard, avec un minimum de délais, le montrer à nos téléspectateurs.

Parmi les inconvénients: les applications mobiles fonctionnent au-dessus des réseaux. Il peut s'agir de la 3G ... Dans tous les cas, ce sont presque toujours les réseaux mobiles, qui introduisent quelques retards - vous devez en outre tamponner les données côté application, afin que le flux se déroule aussi bien que possible.

La deuxième source est les streamers avec OBS, Wirecast ou ceux qui diffusent à partir d'autres applications de bureau. Il s'agit d'un public assez large. Parfois ce sont des séminaires, parfois - des flux de jeu (il y en a surtout beaucoup à partir de telles applications). Du positif: il y a peu d'applications de ce type, nous pouvons donner à nos streamers de bonnes recommandations de réglage. Mais en même temps, il y a beaucoup de paramètres et n'envoyez pas tout à fait le flux que nous voulons.

La troisième catégorie est le flux RTMP des serveurs de médias. Il peut s'agir de très petits serveurs multimédias, c'est-à-dire d'un format domestique: une personne diffuse une vue sur la rue ou autre chose. Ou des émissions assez sérieuses de nos partenaires: il peut y avoir n'importe quoi, il n'y en a pas beaucoup, mais au fond elles sont très importantes pour nous.

Qui regarde?

Encore une fois, il s'agit d'une application mobile - tout est clair ici. Le plus gros problème est la latence du réseau. Des pros: nous pouvons personnaliser le lecteur - c'est pratique pour nous, bien, mais pas partout il s'avère à 100%.

Lecteur Web sur vk.com. Ici aussi, tout est simple - c'est un lecteur Web classique que vous pouvez ouvrir pour regarder. Une audience suffisamment large sur vk.com, beaucoup de téléspectateurs sur les émissions. Certaines émissions sont suspendues dans notre section «Vidéo» - il peut y en avoir des dizaines de milliers (parfois sans aucun RP), surtout s'il s'agit d'un contenu intéressant.

En conséquence, les chaînes sont suffisamment grandes pour les téléspectateurs qui sont assis sur un lecteur Web. Par conséquent, il y a beaucoup de trafic, y compris pour une diffusion.

Le troisième est le lecteur Web VKontakte sur un site tiers. Vous pouvez commencer à diffuser tout ce que vous voulez et accrocher un lecteur Web VKontakte sur votre site Web. Vous pouvez devenir notre partenaire si vous avez du contenu intéressant: vous pouvez le suspendre vous-même, vous pouvez accrocher avec nous - comme vous le souhaitez. Vous pouvez organiser vos émissions de cette manière, et tout fonctionnera.

Comparaison avec les appels vidéo

Dans les appels vidéo, certaines distorsions d'image seront annulées. Les appels vidéo sont plus simples: nous pouvons dégrader considérablement l'image, mais en même temps nous devons maintenir une très bonne latence. Avec un long délai, le service sera absolument impossible à utiliser.

Dans les émissions dans ce sens, c'est un peu l'inverse: nous devons maintenir une qualité d'image élevée, mais en même temps, nous pouvons augmenter la latence en raison de nombreux facteurs. Par exemple, le lecteur met en mémoire tampon le flux d'une manière ou d'une autre (il peut être une seconde, deux afin de survivre à la dégradation du réseau, par exemple), par conséquent, il n'a pas besoin de retards d'une seconde, milliseconde dans la plupart des cas. Vous pouvez vous efforcer pour cela, mais la nourriture n'est pas une condition préalable.

Avec une vidéo ordinaire, la situation est exactement le contraire. Nous avons besoin d'une très bonne qualité. Dans le même temps, il est souhaitable de minimiser la taille de la vidéo, le rapport de débit binaire et la qualité, de sorte qu'avec le débit minimum, donner la meilleure solution. Des pros: nous ne sommes pas limités dans le temps: au moment du téléchargement de la vidéo, nous avons suffisamment de temps pour optimiser la vidéo, voir comment la compresser de la meilleure façon, faire quelque chose, la faire glisser dans des caches, si nécessaire - en général, tout est suffisant D'ACCORD.

En direct, la situation est, encore une fois, le contraire: nous avons très peu de temps pour le transcodage. En même temps, il y a peu d'opportunités, mais il n'y a aucune attente pour la diffusion. Le public nous pardonnera si nous avons du soutien ou si la qualité n'est pas très bonne.

Première version

C'est assez attendu: en

fait, c'est un peu différent:

"Streamer - serveur multimédia - niveau de cache - téléspectateurs". En principe, cette version vous permet d'évoluer assez fortement. Je dirais qu'il devrait déjà résister à des dizaines de milliers de spectateurs. Il a d'autres inconvénients ...

Par exemple, si vous regardez ce circuit (diapositive précédente), vous pouvez voir qu'il n'est pas tolérant aux pannes. Il faut deviner avec le serveur média pour bien équilibrer l'audience. Nous ne pouvons pas bloquer de nombreux caches sur chaque serveur - c'est tout simplement cher. Par conséquent, nous avons regardé, réalisé que c'était simple et clair, il y avait quelques possibilités de mise à l'échelle, mais évidemment quelque chose manquait ... Et nous avons commencé à formuler des exigences.

Besoins en infrastructure

Qu'est-ce qui est important?

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
Livraison aux régions. Aussi un point important! Il est stupide de faire glisser tout le contenu vidéo de Pétersbourg ou de Moscou vers une sorte de Novossibirsk, Iekaterinbourg, ou même de Saint-Pétersbourg à Moscou. Ce n'est pas très bon, car le retard du réseau sera long - il y aura des retards, tout sera en retard, et ce n'est pas bon. Par conséquent, notre infrastructure doit tenir compte du fait que nous livrons du contenu aux régions.
Commodité de fonctionnement et de surveillance. Une propriété importante. Étant donné que le système est volumineux, il existe de nombreux téléspectateurs, il est important d'envoyer des alertes aux administrateurs à temps en cas de problème, y compris la surveillance des produits et des mesures techniques.

À quoi ressemble l'infrastructure de diffusion maintenant?

En conséquence, nous sommes arrivés à une infrastructure assez simple mais efficace ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

De façon intéressante? Équilibrage! Dans ce schéma, nous choisissons l'équilibrage, essayons d'envoyer des téléspectateurs qui regardent le même flux vers chaque serveur de périphérie. La localité du cache est très importante ici, car il peut y avoir de nombreux serveurs périphériques; et si nous n'observons pas à la fois le temporaire et la localité du cache du point de vue du flux, nous surchargerons la couche interne. Cela ne nous plairait pas non plus.

Par conséquent, nous équilibrons de la manière suivante: nous sélectionnons un certain serveur périphérique pour la région dans laquelle nous envoyons des spectateurs, et nous envoyons jusqu'à ce que nous commencions à comprendre qu'un certain remplissage s'est produit et doit être envoyé à un autre serveur. Le circuit est simple et fonctionne de manière très fiable. Naturellement, pour différents flux, vous choisissez une séquence différente de serveurs Edge (la séquence dans laquelle nous envoyons des spectateurs). Par conséquent, l'équilibrage fonctionne tout simplement.

Nous donnons également au client un lien vers un serveur Edge disponible. Ceci est fait pour qu'en cas de panne du serveur de périphérie, nous puissions rediriger le visualiseur vers un autre. Autrement dit, lorsque le téléspectateur regarde la diffusion, il reçoit un lien vers le serveur souhaité toutes les quelques secondes. S'il comprend que le lien doit être différent, il change (le joueur bascule) et continue de regarder la diffusion à partir d'un autre serveur.

Un autre rôle important des serveurs Edge est la protection du contenu. Toute la protection du contenu y a lieu essentiellement. Nous avons notre propre module nginx pour cela. Il est quelque peu similaire à Security Link.

Mise à l'échelle et équilibrage

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

L'un des principaux protocoles que nous avions était RTMP (non seulement pour l'entrée, mais aussi pour la distribution de contenu). Le principal avantage est une faible latence. Cela peut prendre une demi-seconde, une seconde, deux secondes. En fait, les avantages s'arrêtent là ...

Ce protocole de streaming est difficile à surveiller - il est fermé dans un sens, malgré le fait qu'il existe une spécification. Le lecteur Flash ne fonctionne plus (en fait, c'est «déjà tout»). Besoin d'assistance au niveau CDN - vous avez besoin de modules nginx spéciaux ou de votre propre logiciel pour transférer le flux normalement. Il existe également des difficultés avec les clients mobiles. Dans les clients mobiles, il est très mal pris en charge - des améliorations spéciales sont nécessaires, et tout cela est très difficile.
Le deuxième protocole que nous avons utilisé est HLS. Cela a l'air assez simple: c'est un fichier texte, le soi-disant fichier d'index. Il contient des liens vers des fichiers d'index avec différentes autorisations, et les fichiers eux-mêmes contiennent des liens vers des segments multimédias.

Comment est-il bon? C'est très simple, même s'il est un peu vieux. Il vous permet d'utiliser CDN, c'est-à-dire que vous n'avez besoin que de nginx pour distribuer le protocole HLS. C'est compréhensible en termes de suivi.

Voici ses avantages:

facilité d'utilisation - nginx en tant que serveur proxy;
il est facile de surveiller et de prendre des mesures (il vous suffit de surveiller à peu près la même chose que ce que vous surveillez sur votre site Web);
Maintenant, ce protocole est le principal pour la livraison de contenu.

Moins significatif:

latence élevée.

La latence HLS est en fait imbriquée dans le protocole lui-même; comme un long temps de mise en mémoire tampon est nécessaire, le joueur est obligé d'attendre au moins lorsqu'un morceau est chargé, mais dans le bon sens, il doit attendre que deux morceaux (deux segments multimédias) soient chargés, sinon en cas de décalage, le client chargera le lecteur, et cela n'affecte pas très bien expérience utilisateur.

Le deuxième point qui donne un délai dans HLS est la mise en cache. La liste de lecture est mise en cache sur la couche interne et sur les serveurs Edge. Même si nous mettons en cache, relativement parlant, pendant une seconde ou une demi-seconde, cela représente environ plus 2-3 secondes de retard. Au total, il s'avère de 12 à 18 secondes - ce n'est pas très agréable, évidemment c'est mieux.

Amélioration de HLS

Avec ces réflexions, nous avons commencé à améliorer HLS. Nous l'avons amélioré de manière assez simple: donnons un peu plus tôt le dernier segment multimédia de la playlist, pas encore enregistré. Autrement dit, dès que nous avons commencé à écrire le dernier segment média, nous l'annonçons immédiatement dans la playlist. Que se passe-t-il en ce moment? .. Le

temps tampon des joueurs est réduit. Le joueur croit qu'il a déjà tout téléchargé et commence calmement à télécharger les segments souhaités. De cette façon, nous «trichons» un peu le joueur, mais si nous surveillons bien «l'acier» (les charges dans le lecteur), cela ne nous fait pas peur - nous pouvons arrêter de donner le segment à l'avance, et tout reviendra à la normale.

Le deuxième point: nous gagnons un total d'environ 5-8 secondes. D'où viennent-ils? Cette durée de segment est de 2 à 4 secondes par segment, plus le temps de mise en cache de la liste de lecture (cela représente encore 2-3 secondes). De plus, notre retard diminue considérablement. Le délai est réduit de 12-15 secondes à 5-7.

Quoi d'autre est bon dans cette approche? C'est en fait gratuit! Il suffit de vérifier si les joueurs sont compatibles avec cette approche. Ceux qui sont incompatibles, nous les envoyons aux anciennes URL et nous envoyons les lecteurs compatibles aux nouvelles URL. Nous n'avons pas besoin de mettre à niveau les anciens clients qui prennent en charge cela, ce qui est également important. Nous n'avons en fait pas besoin de modifier, de libérer les joueurs dans les clients mobiles. Nous n'avons pas besoin de développer un lecteur web. Cela semble assez bon!

Parmi les inconvénients - la nécessité de contrôler le flux vidéo entrant. Dans le cas d'un client mobile, nous pouvons le faire assez facilement (lorsque le flux provient d'un client mobile), ou transcoder sans échec, car le lecteur doit savoir combien de temps cela prend pour un segment de temps multimédia. Et puisque nous l'annonçons avant qu'il ne soit réellement enregistré, nous devons savoir combien de temps il faudra pour l'enregistrer.

Mesures de qualité

Ainsi, nous avons amélioré HLS. Maintenant, je veux dire comment nous surveillons et quelles mesures de qualité nous tirons:

L'une des principales mesures de qualité est l'heure de début. Idéalement, c'est lorsque vous faites défiler le client mobile avant la diffusion, appuyez sur le bouton et cela démarre immédiatement. Ce serait idéal si cela commence avant d'appuyer sur le bouton, mais, malheureusement, uniquement lorsque vous appuyez sur.
Le deuxième point est le retard du signal. Nous pensons que quelques secondes sont très bonnes, 10 secondes sont tolérables, 20-30 secondes sont très mauvaises. Pourquoi c'est important? Par exemple, pour les concerts et certains événements publics, il s'agit d'une métrique absolument sans importance, il n'y a pas de rétroaction; nous montrons simplement le flux - il vaut mieux ne pas prendre de retard qu'un léger retard. Et pour un flux où une sorte de conférence se déroule ou où une personne dit quelque chose et lui pose des questions, cela commence à être important, car ils posent beaucoup de questions dans les commentaires et je veux que le public reçoive des commentaires le plus tôt possible.

Une autre mesure importante est la mise en mémoire tampon et les retards. En fait, cette métrique est importante non seulement du point de vue du client et de la qualité, mais du point de vue de la mesure dans laquelle nous pouvons «étirer» la livraison de HLS, de la quantité de données que nous pouvons extraire de nos serveurs. Par conséquent, nous surveillons à la fois le temps tampon moyen dans les lecteurs et «l'acier».

Le choix de la qualité des joueurs est compréhensible: les changements inattendus sont toujours ennuyeux.

Par conséquent, il s'agit également d'une mesure importante.

surveillance

Nous avons de nombreuses mesures de surveillance, mais ici, j'ai choisi ces mesures qui fonctionnent toujours en cas de problème:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

Je vais maintenant vous expliquer comment nous avons géré une application telle que "Player" lorsque nous avons utilisé notre infrastructure pour diffuser un flux vidéo avec des questions et des réponses.

Clover est un quiz en ligne. L'hôte dit quelque chose, demande: des questions tombent - vous répondez. 12 questions, 10 minutes de jeu, à la fin - une sorte de prix. Qu'est-ce qui est si compliqué? C'est la croissance!

A droite se trouve ce graphique: Le

pic [sur le graphique] est la charge sur les serveurs en termes d'API au moment du démarrage de «Clover». Le reste du temps est le flux habituel d'émissions. Cela ne peut pas être égal au nombre de téléspectateurs. C'est peut-être le nombre de demandes et la charge.

C'est difficile: en 5 minutes, un million de spectateurs sont venus vers nous au sommet. Ils commencent à regarder la diffusion, à s'inscrire, à effectuer une sorte d'action, à demander une vidéo ... Cela semble être un jeu très simple, mais cela se produit dans un laps de temps très court (toutes les actions, y compris le jeu final) - cela donne une charge assez élevée.

Quelles questions et quels défis avons-nous rencontrés?

Croissance rapide. Parfois, c'était + 50% par semaine. Si, par exemple, vous avez 200 000 personnes mercredi, alors samedi ou dimanche, il pourrait y en avoir déjà 300. C'est beaucoup! Des problèmes commencent à faire surface qui n'étaient pas visibles auparavant.
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

L'architecture nous convient parfaitement et je peux la recommander en toute sécurité. HLS restera avec nous le protocole principal pour au moins le site Web et au moins le protocole de sauvegarde pour tout le reste. Peut-être que nous passerons au MPEG-DASH.

RTMP abandonné. Malgré le fait qu'il donne un délai plus faible, nous avons décidé de régler le HLS. Peut-être envisager d'autres véhicules de livraison, y compris DASH comme alternative.

Nous améliorerons le solde entrant. Nous voulons également effectuer un basculement transparent pour l'équilibrage entrant, de sorte qu'en cas de problème sur l'un des serveurs de médias pour le client, la commutation soit complètement invisible.

Peut-être développerons-nous des systèmes de livraison des serveurs de périphérie au client. Ce sera probablement une sorte d'UDP. Lequel - nous réfléchissons maintenant et nous sommes au stade de la recherche.

En fait, c'est tout. Merci à tous!

Des questions

Question du public (ci-après - A): - Merci beaucoup pour le rapport! Seul le conférencier d'Odnoklassniki a pris la parole, et il a dit qu'ils devaient réécrire le streamer, l'encodeur, l'encodeur ... Utilisez-vous de telles solutions ou utilisez celles en stock qui sont sur le marché (comme Harmonic, etc.)?

MR: - Maintenant, nous avons des solutions tierces en rotation. Parmi les solutions open source que nous avons utilisées, nous avions nginx, le module RTMP (depuis longtemps). D'une part, il nous a plu car il travaillait, assez simple. Nous nous sommes battus très longtemps pour qu'il travaille de manière stable. Maintenant, il passe de Nginx-RTMP à sa propre solution. Nous pensons maintenant avec un transcodeur. Le récepteur, à savoir la partie réceptrice, a également été réécrit de Nginx-RTMP vers sa solution.

ET:- Je voulais poser une question sur le découpage de RTMP sur HLS, mais si je comprends bien, vous avez déjà répondu ... Dites-moi, vos solutions sont-elles open-source?

MR: - Nous envisageons de le publier en open source. Nous préférons plutôt le publier, mais la question est le moment de la sortie en open source. Il suffit de mettre la source sur Internet - cela ne suffit pas. Vous devez réfléchir, faire quelques exemples de déploiement. Et dans quel but demandez-vous? Voulez-vous utiliser?

R: - Parce que j'ai aussi rencontré Nginx-RTMP! Il est, pour le moins, pas pris en charge depuis très longtemps. L'auteur ne répond même pas particulièrement aux questions ...

MR: - Si vous voulez, vous pouvez écrire au mail. Donner pour son propre usage? Nous pouvons être d'accord. Nous prévoyons vraiment de l'ouvrir.

ET:- Vous avez également dit que vous pouvez passer de HLS à DASH. HLS ne convient pas?

M.: - C'est une question sur ce que nous pouvons, ou peut-être pas. Cela dépend grandement de ce que nous allons faire en termes de recherche de méthodes de livraison alternatives (c'est-à-dire UDP). Si nous trouvons quelque chose de «complètement» bon, alors nous ne toucherons probablement pas HLS. S'il semble que MPEG-DASH est plus confortable - nous allons peut-être le déplacer. Cela ne semble pas très difficile, mais nous ne savons pas si c'est nécessaire ou non. La synchronisation entre les flux, entre les qualités et d'autres choses y est clairement meilleure. Il y a des avantages.

R: - Concernant les alertes. Vous avez parlé du fait que si les flux cessent de couler, alors c'est immédiatement une alerte. Et vous n'avez pas attrapé quelque chose d'indépendant de vous: le fournisseur est tombé, Megafon est tombé et les gens ont cessé de diffuser? ..

MR:- Disons simplement que quelque chose d'indépendant de nous est essentiellement toutes sortes de vacances et ainsi de suite. Oui, ils ont. Eh bien, oui. Les administrateurs ont regardé - aujourd'hui c'est les vacances, le reste des caractéristiques vont bien - ils se sont calmés.

R: - Et sur la mise à l'échelle. À quel niveau évolue-t-il? Par exemple, j'ai demandé un flux depuis le téléphone - vais-je recevoir immédiatement un certain lien avec le bon serveur ash?

MR: - Un lien viendra immédiatement et, si nécessaire, vous commutera (s'il y a des problèmes sur un serveur spécifique).

R: - Qui va changer?

MR: - Lecteur mobile ou lecteur web.

R: - Il redémarrera le flux ou quoi?

MR: - Un nouveau lien viendra à lui où il devrait aller en direct. Il ira là-bas et demandera à nouveau le flux.

ET:- A quel niveau avez-vous des caches? Et des listes de lecture, et des morceaux, ou juste ça? ..

MR: - Et des listes de lecture, des morceaux! Il se cache un peu différemment, à la fois en termes de temps et en termes de retour de temps, mais nous mettons en cache les deux.

R: - Concernant la création de serveurs Ash? Avez-vous eu une telle situation que vous regardez 2 millions de téléspectateurs sur une émission, que vous n'avez pas le temps pour quelque chose et que vous récupérez rapidement un serveur Ash? Ou soulevez-vous tout à l'avance avec une marge?

Monsieur:- Peut-être que non. Premièrement, le stock est toujours petit ou grand - peu importe. Deuxièmement, il n’arrive pas qu’une émission devienne soudainement super populaire. Nous pouvons bien prévoir le nombre de téléspectateurs. En gros, pour avoir beaucoup de monde, il faut faire un effort. En conséquence, nous pouvons ajuster le nombre de téléspectateurs de l'émission, en fonction des efforts déployés.

R: - Vous avez dit que vous mesurez les retards instrumentaux de la part du joueur. Comment?

MR: - Très simple. Dans les morceaux (dans les segments multimédias), nous avons un horodatage, au nom du segment multimédia - dans le lecteur, nous le renvoyons simplement. S'il n'est pas explicitement du tout, il revient.

R: - Je me souviens avoir essayé d'exécuter le peering sur WebRTC. Pourquoi refusé?

Monsieur:"Je ne peux pas répondre à cette question pour vous - c'est arrivé sans moi." Je ne peux pas dire pourquoi j'ai essayé et je ne peux pas dire pourquoi j'ai refusé.

R: - Concernant le récepteur et le serveur multimédia. Si je comprends bien, vous aviez Nginx-RTMP, maintenant là et là, vous avez des solutions faites par vous-même. En fait, il s'agit d'un serveur multimédia qui fait office de proxy pour d'autres serveurs multimédia, et ils sont déjà dans le cache et en périphérie.

MR: - Donc, pas vraiment. Il s'agit d'une solution autodidacte, mais elle est différente à la fois en termes de serveur multimédia et en termes de récepteur. Nginx-RTMP - c'était une sorte de moissonneuse qui pouvait faire les deux. Nos intérieurs du récepteur et du serveur multimédia sont très différents - à la fois par code et partout. La seule chose qui les unit est le traitement RTMP.

R: - Concernant l'équilibre entre les bords. Comment cela peut-il arriver?

MR: - Nous mesurons le trafic, l'envoyer au serveur souhaité. Je n'ai pas compris un peu la question ...

R: - Je vais expliquer: l'utilisateur demande une liste de lecture via le lecteur - il renvoie les chemins relatifs aux manifestes et aux morceaux ou aux chemins absolus, par exemple, par IP ou domaine? ..

MR: - Les chemins sont relatifs.

R: - Autrement dit, il n'y a pas d'équilibrage lors de la visualisation d'un flux par un seul utilisateur?

MR: - Ça arrive. Assez délicat. Nous pouvons utiliser la redirection 301e lors de la surcharge du serveur. Si nous voyons que tout est complètement mauvais là-bas, pour les segments, nous pouvons l'envoyer à un autre serveur.

R: - Mais cela devrait être connecté à la logique du joueur?

Monsieur:- Non, juste cette partie ne doit pas être cousue. 301e redirection! Simplement, le joueur devrait pouvoir quitter la 301e liaison. Nous pouvons l'envoyer à un autre serveur du côté serveur au moment de la surcharge.

R: - Autrement dit, il demande au serveur, et le serveur le lui donne?

MR: - Oui. Ce n'est pas très bon, par conséquent, la logique du joueur est utilisée pour retweeter les liens vers le cas de défaillance d'un des serveurs - c'est déjà dans la logique du joueur.

R: - Et vous n'avez pas essayé de travailler non pas de manière relative, mais absolue: lorsque vous demandez au joueur de faire de la magie, découvrez où il y a des ressources et où pas, et donnez déjà des listes de lecture indiquant un serveur spécifique?

Monsieur:- En fait, cela ressemble à une solution de travail. Si vous étiez venu alors, nous aurions pesé les deux! Mais la solution actuelle fonctionne également, donc je ne veux pas vraiment passer de l’un à l’autre, même si cela ressemble peut-être aussi à une solution de travail.

R: - Dites-moi, est-ce en quelque sorte amical avec la multidiffusion? HLS, si je comprends bien, absolument rien ...

M.: - Dans la mise en œuvre actuelle, nous n'avons probablement rien dans le système avec la multidiffusion en direct. Nous n'y incluons pas le concept de multidiffusion. Peut-être quelque part dans les profondeurs de la magie administrative, il y a quelque chose à l'intérieur du réseau, mais il est caché à tout le monde et personne ne le sait ...

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

HighLoad ++, Mikhail Raichenko (ManyChat): presque sans magie, ni à quel point il est facile de distribuer un flux vidéo térabit