🈴 💪🏻 🍳 HighLoad ++, Mikhail Raichenko (ManyChat): casi sin magia, o lo fácil que es distribuir la transmisión de video terabit 📅 🎡 👨🏾‍🔧

La próxima conferencia HighLoad ++ se llevará a cabo los días 6 y 7 de abril de 2020 en San Petersburgo. Detalles y entradas aquí . HighLoad ++ Moscú 2018. Sala "Delhi + Calcuta". 8 de noviembre, 2 p.m. Resúmenes y presentación .

Trabajo en el equipo de VKontakte y estoy desarrollando un sistema de transmisión de video.
En el informe, compartiré las características del desarrollo del backend, cómo ha evolucionado nuestro sistema y las soluciones técnicas a las que hemos llegado: 

cómo hicimos el backend de transmisión de video y el proceso de evolución tal como es;
el impacto de los requisitos comerciales y operativos en la arquitectura;
"Esperar" e "intentar de nuevo" fallará;
cómo las tareas más simples se complican por la cantidad de usuarios;
cómo reducir la latencia sin UDP;
Realizamos pruebas de estrés 2 veces al día, o con lo que Clover nos ayudó.

Mikhail Raichenko (en adelante - MR): - Una pequeña excursión. Te contaré sobre las personas que nos transmiten, sobre el live (live), sobre qué plataformas recibimos la transmisión de video y cuáles distribuimos. Al final, hablaré sobre la arquitectura actual de la vida, sobre sus limitaciones y capacidades, así como sobre cómo la arquitectura actual sobrevivió a un efecto como "Clover".

Sobre transmisiones en vivo. Resumen del informe

Primero, hablaré un poco sobre las transmisiones en vivo y las transmisiones en sí mismas, enviándonos contenido de video que mostramos a otros espectadores.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

Todos los servicios de transmisión se ven más o menos así:

tenemos un transmisor, nos envía una transmisión RTMP y mostramos a la audiencia: nada sorprendente, nada sobrenatural.

¿De dónde viene la transmisión de video? Una fuente importante de tráfico para nosotros es nuestra aplicación móvil VKlife. ¿Qué hay de bueno en él? En él, podemos controlar completamente cómo codificamos el video. Podemos hacer muchas optimizaciones en el lado del cliente, para que luego, con retrasos mínimos, se lo muestremos a nuestros espectadores.

De las desventajas: las aplicaciones móviles funcionan sobre redes. Puede ser 3G ... En cualquier caso, casi siempre se trata de redes móviles, lo que introduce algunos retrasos: debe almacenar adicionalmente los datos en el lado de la aplicación, para que la transmisión se ejecute de la manera más fluida posible.

La segunda fuente son los streamers con OBS, Wirecast o aquellos que transmiten desde otras aplicaciones de escritorio. Esta es una audiencia bastante grande. A veces se trata de seminarios, a veces, transmisiones de juegos (especialmente muchas de estas aplicaciones). De lo positivo: hay pocas aplicaciones de este tipo, podemos dar a nuestros streamers buenas recomendaciones de ajuste. Pero al mismo tiempo, hay muchas configuraciones y no enviamos la transmisión que queremos.

La tercera categoría es la transmisión RTMP de los servidores de medios. Estos pueden ser servidores de medios muy pequeños, es decir, un formato de inicio: una persona transmite una vista de la calle o algo más. O transmisiones bastante serias de nuestros socios: puede haber cualquier cosa, no hay muchas transmisiones de este tipo, pero básicamente son muy importantes para nosotros.

¿Quién está mirando?

Nuevamente, esta es una aplicación móvil: todo está claro aquí. El mayor problema es la latencia de la red. De los profesionales: podemos personalizar el reproductor: es conveniente para nosotros, bueno, pero no en todas partes, resulta 100%.

Reproductor web en vk.com. Aquí, también, todo es simple: es un reproductor web normal que puedes abrir para ver. Una audiencia suficientemente grande en vk.com, muchos espectadores en las transmisiones. Algunas transmisiones se cuelgan en nuestra sección de "Video": puede haber decenas de miles (a veces sin ningún PR), especialmente si este es un contenido interesante.

En consecuencia, los canales son lo suficientemente grandes para los espectadores que están sentados en un reproductor web. Por lo tanto, hay mucho tráfico, incluso para una transmisión.

El tercero es el reproductor web VKontakte en un sitio de terceros. Puede comenzar a transmitir todo lo que desee y colgar un reproductor web VKontakte en su sitio web. Puede convertirse en nuestro socio si tiene contenido interesante: puede colgarlo por su cuenta, puede colgar con nosotros, como lo desee. Puede organizar sus transmisiones de esta manera, y todo funcionará.

Comparación con videollamadas

En las videollamadas, se disculpará la distorsión de la imagen. Las videollamadas son más simples: podemos degradar significativamente la imagen, pero al mismo tiempo debemos mantener una muy buena latencia. Con un largo retraso, el servicio será absolutamente imposible de usar.

En las transmisiones en este sentido, es un poco al revés: debemos mantener una alta calidad de imagen, pero al mismo tiempo podemos aumentar la latencia debido a muchos factores. Por ejemplo, el jugador amortigua el flujo de una forma u otra (puede ser un segundo, dos para sobrevivir a la degradación de la red, por ejemplo), por lo tanto, no necesita un segundo retraso de milisegundos en la mayoría de los casos. Puede luchar por esto, pero la comida no es un requisito previo.

Con el video ordinario, la situación es exactamente lo contrario. Necesitamos muy buena calidad. Al mismo tiempo, es deseable minimizar el tamaño del video, la relación de velocidad de bits y calidad, de modo que con el flujo mínimo, proporcione la mejor solución. De los profesionales: no estamos limitados en el tiempo: al momento de descargar el video, tenemos suficiente tiempo para optimizar el video, ver cómo comprimirlo de la mejor manera, hacer algo, arrastrarlo a cachés, si es necesario; en general, todo es suficiente OKAY.

En vivo, la situación es, nuevamente, lo contrario: tenemos muy poco tiempo para transcodificar. Al mismo tiempo, hay pocas oportunidades, pero no hay expectativas para la transmisión. El público nos perdonará si tenemos apoyo o si la calidad no es muy buena.

Primera versión

Es bastante esperado: en

realidad, es un poco diferente:

"Streamer - servidor de medios - nivel de caché - espectadores". En principio, esta versión le permite escalar con bastante fuerza. Yo diría que ya debería soportar decenas de miles de espectadores. Tiene otros inconvenientes ...

Por ejemplo, si observa este circuito (diapositiva anterior), puede ver que no tolera fallas. Debemos adivinar con el servidor de medios para equilibrar bien a la audiencia. No podemos colgar muchas cachés en cada servidor, es simplemente costoso. Por lo tanto, miramos, nos dimos cuenta de que era simple y claro, había algunas posibilidades de escalado, pero obviamente faltaba algo ... Y comenzamos a formular requisitos.

Requisitos de infraestructura

¿Qué es importante?

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
Entrega a las regiones. También un punto importante! Es estúpido arrastrar todo el contenido de video desde Petersburgo o Moscú a algún tipo de Novosibirsk, Ekaterimburgo, o incluso desde San Petersburgo a Moscú. Esto no es muy bueno, ya que la demora de la red será larga: habrá retrasos, todo se retrasará, y esto no es bueno. Por lo tanto, nuestra infraestructura debe tener en cuenta que entregamos contenido a las regiones.
Conveniencia de operación y monitoreo. Una propiedad importante. Dado que el sistema es grande, hay muchos espectadores, es importante enviar alertas a los administradores a tiempo en caso de cualquier problema, incluido el monitoreo del producto y las métricas técnicas.

¿Cómo se ve la infraestructura de transmisión ahora?

Como resultado, llegamos a una infraestructura bastante simple pero efectiva ...

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

Interesantemente? Equilibrio! En este esquema, elegimos el equilibrio, intentamos enviar a los espectadores que miran la misma transmisión a cada servidor perimetral. La localidad de caché es muy importante aquí, porque puede haber muchos servidores perimetrales; y si no observamos tanto la ubicación temporal como la local del caché desde el punto de vista de la secuencia, sobrecargaremos la capa interna. Tampoco nos gustaría eso.

Por lo tanto, equilibramos de la siguiente manera: seleccionamos un determinado servidor perimetral para la región a la que enviamos espectadores y enviamos hasta que comencemos a comprender que se ha producido algún llenado y que se debe enviar a otro servidor. El circuito es simple y funciona de manera muy confiable. Naturalmente, para diferentes transmisiones, usted elige una secuencia diferente de servidores perimetrales (la secuencia en la que enviamos espectadores). En consecuencia, el equilibrio funciona de manera bastante simple.

También le damos al cliente un enlace a un servidor perimetral disponible. Esto se hace para que, en caso de falla del servidor perimetral, podamos redirigir el visor a otro. Es decir, cuando el espectador mira la transmisión, recibe un enlace al servidor deseado una vez cada pocos segundos. Si comprende que el enlace debe ser diferente, cambia (el jugador cambia) y continúa viendo la transmisión desde otro servidor.

Otra función importante de los servidores perimetrales es la protección de contenido. Toda la protección del contenido tiene lugar esencialmente allí. Tenemos nuestro propio módulo nginx para esto. Es algo similar a Security Link.

Escalado y balanceo

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

?

Uno de los principales protocolos que teníamos era RTMP (no solo para la entrada, sino también para la distribución de contenido). La principal ventaja es la baja latencia. Puede ser medio segundo, segundo, dos segundos. De hecho, los beneficios terminan allí ...

Este protocolo de transmisión es difícil de monitorear; en cierto sentido, está cerrado, a pesar de que hay una especificación. El reproductor Flash ya no funciona (de hecho, es "ya todo"). Necesita soporte a nivel CDN: necesita módulos especiales nginx o su propio software para transferir la transmisión normalmente. También hay algunas dificultades con los clientes móviles. Fuera de la caja en clientes móviles, es muy poco compatible: se necesitan mejoras especiales, y todo esto es muy difícil.
El segundo protocolo que utilizamos es HLS. Parece bastante simple: es un archivo de texto, el llamado archivo de índice. Contiene enlaces a archivos de índice con diferentes permisos, y los archivos contienen enlaces a segmentos de medios.

¿Cómo es él bueno? Es muy simple, a pesar de ser un poco viejo. Le permite usar CDN, es decir, solo necesita nginx para distribuir el protocolo HLS. Es comprensible en términos de monitoreo.

Aquí están sus ventajas:

facilidad de operación: nginx como servidor proxy;
es fácil de monitorear y tomar métricas (es suficiente para que pueda monitorear casi lo mismo que lo que monitorea en su sitio web);
Ahora este protocolo es el principal para la entrega de contenido.

Significativo menos:

alta latencia.

La latencia HLS está realmente anidada en el protocolo mismo; Dado que se requiere un tiempo de almacenamiento en búfer prolongado, el jugador se ve obligado a esperar al menos cuando se carga un fragmento, pero en el buen sentido, debe esperar hasta que se carguen dos fragmentos (dos segmentos de medios), de lo contrario, en caso de un retraso, el cliente tendrá la carga del reproductor, y esto no afecta muy bien experiencia de usuario.

El segundo punto que produce un retraso en HLS es el almacenamiento en caché. La lista de reproducción se almacena en caché en la capa interna y en los servidores perimetrales. Incluso si almacenamos en caché, en términos relativos, durante un segundo o medio segundo, esto es aproximadamente más 2-3 segundos de retraso. En total, resulta de 12 a 18 segundos; esto no es muy agradable, obviamente es mejor.

Mejorando HLS

Con estos pensamientos, comenzamos a mejorar HLS. Lo mejoramos de una manera bastante simple: demos el último segmento de medios de la lista de reproducción, aún no grabado, un poco antes. Es decir, tan pronto como comenzamos a escribir el último segmento de medios, lo anunciamos inmediatamente en la lista de reproducción. ¿Qué está pasando en este momento? .. Se

reduce el tiempo de amortiguación en los jugadores. El jugador cree que ya ha descargado todo, y con calma comienza a descargar los segmentos deseados. De esta manera, "engañamos" al jugador de esta manera, pero si controlamos bien el "acero" (cargas en el jugador), no nos asusta, podemos dejar de dar el segmento por adelantado y todo volverá a la normalidad.

El segundo punto: ganamos un total de aproximadamente 5-8 segundos. ¿De dónde vienen? Este tiempo de segmento es de 2 a 4 segundos por segmento, más el tiempo para almacenar en caché la lista de reproducción (esto es otros 2-3 segundos). Nuestro retraso está disminuyendo, además, significativamente. El retraso se reduce de 12-15 segundos a 5-7.

¿Qué más hay de bueno en este enfoque? En realidad es gratis! Solo necesitamos verificar si los jugadores son compatibles con este enfoque. Los que son incompatibles, los enviamos a las URL antiguas y enviamos reproductores compatibles a las nuevas URL. No necesitamos actualizar clientes antiguos que admitan esto, lo cual también es importante. En realidad, no necesitamos modificar, liberar jugadores en clientes móviles. No necesitamos desarrollar un reproductor web. Se ve lo suficientemente bueno!

De los inconvenientes: la necesidad de controlar la transmisión de video entrante. En el caso de un cliente móvil, podemos hacer esto con bastante facilidad (cuando la transmisión proviene de un cliente móvil), o transcodificar sin falta, ya que el reproductor debe saber cuánto tiempo lleva un segmento de medios. Y dado que lo anunciamos antes de que se grabe, necesitamos saber cuánto tiempo tomará cuando lo grabemos.

Métricas de calidad

Por lo tanto, hemos mejorado HLS. Ahora quiero decir cómo monitoreamos y qué métricas de calidad disparamos:

una de las principales métricas de calidad es la hora de inicio. Idealmente, esto es cuando se desplaza por el cliente móvil antes de la transmisión, presiona el botón y comienza de inmediato. Sería ideal si comienza antes de presionar el botón, pero, desafortunadamente, solo cuando presiona.
El segundo punto es el retraso de la señal. Creemos que unos segundos son muy buenos, 10 segundos son tolerables, 20-30 segundos son muy malos. ¿Por qué es importante? Por ejemplo, para conciertos y algunos eventos públicos esta es una métrica absolutamente sin importancia, no hay comentarios; solo mostramos la transmisión: es mejor no retrasarse que un ligero retraso. Y para una transmisión en la que se realiza algún tipo de conferencia o una persona le dice algo y le hacen preguntas, esto comienza a ser importante, porque hacen muchas preguntas en los comentarios y quiero que la audiencia reciba comentarios lo antes posible.

Otra métrica importante es el almacenamiento en búfer y los retrasos. De hecho, esta métrica es importante no solo desde el punto de vista del cliente y la calidad, sino desde el punto de vista de cuánto podemos "estirar" la entrega de HLS, cuánto podemos extraer datos de nuestros servidores. Por lo tanto, controlamos tanto el tiempo de amortiguación promedio en los jugadores como el "acero".

La elección de la calidad en los jugadores es comprensible: los cambios inesperados siempre son molestos.

En consecuencia, esta también es una métrica importante.

Supervisión

Tenemos muchas métricas de monitoreo, pero aquí elegí esas métricas que siempre funcionan si algo sale mal:

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

«», ?

Ahora le diré cómo manejamos una aplicación como "Reproductor" cuando usamos nuestra infraestructura para transmitir una transmisión de video con preguntas y respuestas.

Clover es un cuestionario en línea. El anfitrión dice algo, pregunta: las preguntas se caen, tú respondes. 12 preguntas, 10 minutos del juego, al final, algún tipo de premio. ¿Qué es tan complicado? ¡Esto es crecimiento!

A la derecha está este gráfico: el

pico [en el gráfico] es la carga en los servidores en términos de la API en el momento del inicio de "Clover". El resto del tiempo es el flujo habitual de transmisiones. Esto no puede equipararse al número de espectadores. Quizás esta sea la cantidad de solicitudes y la carga.

Es difícil: en 5 minutos nos llegó un millón de espectadores en la cima. Comienzan a ver la transmisión, se registran, realizan algún tipo de acción, solicitan un video ... Parece un juego muy simple, pero esto sucede en un período de tiempo muy corto (todas las acciones, incluido el juego final), esto da una carga bastante alta.

¿Qué preguntas y desafíos enfrentamos?

Crecimiento rápido. A veces era + 50% por semana. Si, por ejemplo, tienes 200 mil personas el miércoles, entonces el sábado o el domingo ya podrían haber sido 300. ¡Eso es mucho! Comienzan a surgir problemas que antes no eran visibles.
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 . , , . . , , . .

?

La arquitectura nos conviene por completo, y puedo recomendarla con seguridad. HLS permanecerá con nosotros el protocolo principal para al menos el sitio web y al menos el protocolo de respaldo para todo lo demás. Quizás cambiemos a MPEG-DASH.

RTMP abandonado. A pesar de que da un retraso menor, decidimos que sintonizaríamos el HLS. Quizás considere otros vehículos de reparto, incluido DASH como alternativa.

Mejoraremos el saldo entrante. También queremos realizar una conmutación por error perfecta para el equilibrio entrante, de modo que en caso de problemas en uno de los servidores de medios para el cliente, el cambio sea completamente invisible.

Quizás desarrollaremos sistemas de entrega desde servidores perimetrales hasta el cliente. Lo más probable es que sea algún tipo de UDP. Cuál - ahora estamos pensando y estamos en la etapa de investigación.

En realidad, eso es todo. ¡Gracias a todos!

Preguntas

Pregunta de la audiencia (en adelante - A): - ¡Muchas gracias por el informe! Solo habló el orador de Odnoklassniki, y él me dijo que tenían que reescribir el streamer, el codificador, el codificador ... ¿Usas tales soluciones o usas las que están en el mercado (como Harmonic, etc.)?

MR: - Ahora tenemos soluciones de terceros que giran. De las soluciones de código abierto que utilizamos, teníamos nginx, el módulo RTMP (durante mucho tiempo). Por un lado, nos complació porque trabajó, bastante simple. Luchamos durante mucho tiempo para que trabajara de manera estable. Ahora se está moviendo de Nginx-RTMP a su propia solución. Estamos pensando con un transcodificador ahora. El receptor, es decir, la parte receptora, también se ha reescrito desde Nginx-RTMP para su solución.

Y:- Quería hacer una pregunta sobre cómo cortar RTMP en HLS, pero como lo entiendo, ya respondiste ... Dime, ¿tus soluciones son de código abierto?

MR: - Estamos considerando lanzarlo en código abierto. Preferiríamos lanzarlo, pero la pregunta es el momento del lanzamiento en código abierto. Simplemente ponga la fuente en Internet; esto no es suficiente. Debe pensar, hacer algunos ejemplos de implementación. ¿Y con qué propósito lo preguntas? ¿Quiere usar?

R: - ¡Porque también me encontré con Nginx-RTMP! Es, por decirlo suavemente, no es compatible durante mucho tiempo. El autor ni siquiera responde preguntas particulares ...

MR: - Si lo desea, puede escribir al correo. Dar para uso propio? Podemos estar de acuerdo. Realmente planeamos abrirlo.

Y:- También dijiste que puedes pasar de HLS a DASH. HLS no se adapta?

MR: - Esta es una pregunta sobre lo que podemos, o quizás no. Depende en gran medida de lo que haremos en términos de investigación de métodos de entrega alternativos (es decir, UDP). Si encontramos algo "completamente" bueno, entonces probablemente no tocaremos HLS. Si parece que MPEG-DASH es más cómodo, tal vez lo moveremos. No parece ser muy difícil, pero no estamos seguros de si es necesario o no. La sincronización entre flujos, entre cualidades y otras cosas es claramente mejor allí. Hay ventajas

A: - Con respecto a las alertas. Usted habló sobre el hecho de que si las transmisiones dejan de transmitirse, entonces esto es inmediatamente una alerta. Y no captó algo independiente de usted: el proveedor se cayó, Megafon se cayó y la gente dejó de transmitir.

MR:- Digamos que algo independiente de nosotros es básicamente todo tipo de vacaciones, etc. Sí, lo hicieron. Bueno, lo hicieron, sí. Los administradores miraron: hoy son las vacaciones, el resto de las características están bien, se calmaron.

A: - Y sobre la escala. ¿A qué nivel se escala? Por ejemplo, solicité una transmisión desde el teléfono. ¿Recibiré de inmediato un cierto enlace con el servidor de cenizas correcto?

MR: - Aparecerá un enlace de inmediato y, si es necesario, lo cambiará (si hay problemas en un servidor específico).

A: - ¿Quién cambiará?

MR: - Reproductor móvil o reproductor web.

A: - ¿Reiniciará la transmisión o qué?

MR: - Un nuevo enlace le llegará a donde debería ir en vivo. Él irá allí y volverá a preguntar la corriente.

Y:- ¿A qué nivel tienes cachés? Y listas de reproducción, y fragmentos, o simplemente eso ...

MR: - ¡Y listas de reproducción, fragmentos! Se almacena en caché de manera un poco diferente, tanto en términos de tiempo como en términos del retorno del tiempo, pero almacenamos en caché ambos.

A: - Con respecto a la creación de servidores de cenizas? ¿Tuviste tal situación que miras a 2 millones de espectadores en una transmisión, no tienes tiempo para algo y recoges rápidamente algún servidor de cenizas? ¿O aumenta todo por adelantado con un margen?

Señor:- Quizás esto no fue así. En primer lugar, el stock siempre es pequeño o grande, no importa. En segundo lugar, no sucede que una transmisión de repente se vuelva súper popular. Podemos predecir bien el número de espectadores. Básicamente, para tener mucha gente, debemos hacer un esfuerzo. En consecuencia, podemos ajustar el número de espectadores de la transmisión, según los esfuerzos que se realicen.

R: - Dijiste que mides los retrasos instrumentales por parte del jugador. ¿Cómo?

MR: - Muy simple. En fragmentos (en los segmentos de medios) tenemos una marca de tiempo, en el nombre del segmento de medios, en el reproductor simplemente la devolvemos. Si no es explícito en absoluto, regresa.

R: Recuerdo haber intentado ejecutar el peering en WebRTC. ¿Por qué rechazado?

Señor:"No puedo responder esta pregunta por ti, sucedió sin mí". No puedo decir por qué lo intenté y no puedo decir por qué me negué.

A: - Con respecto al receptor y al servidor de medios. Según tengo entendido, solía tener Nginx-RTMP, ahora, tanto allí como allí, tiene soluciones personalizadas. De hecho, este es un servidor de medios que representa a otros servidores de medios, y ya están en la caché y en el borde.

MR: - Entonces, en realidad no. Esta es una solución hecha a sí misma, pero es diferente tanto en términos de un servidor de medios como en términos de un receptor. Nginx-RTMP: era una especie de cosechadora que podía hacer ambas cosas. Nuestros interiores del receptor y el servidor de medios son muy diferentes, tanto por código como en todas partes. Lo único que los une es el procesamiento RTMP.

A: - Con respecto al equilibrio entre los bordes. ¿Como sucedió esto?

MR: - Medimos el tráfico, lo enviamos al servidor deseado. No entendí un poco la pregunta ...

R: - Explicaré: el usuario solicita una lista de reproducción a través del reproductor - devuelve las rutas relativas a manifiestos y fragmentos o rutas absolutas, por ejemplo, por IP o dominio?

MR: - Las rutas son relativas.

R: - Es decir, ¿no hay equilibrio cuando un usuario visualiza una transmisión?

MR: - Sucede. Bastante complicado. Podemos usar la redirección 301 cuando sobrecargamos el servidor. Si vemos que todo está completamente mal allí, para segmentos podemos enviarlo a otro servidor.

A: - ¿Pero debería estar conectado a la lógica del jugador?

Señor:- No, solo esta parte no debe coserse. Redirección 301 Simplemente, el jugador debería poder salir del enlace 301. Podemos enviarlo a otro servidor desde el lado del servidor en el momento de la sobrecarga.

A: - Es decir, le pregunta al servidor, ¿y el servidor se lo da?

MR: Sí. Esto no es muy bueno, por lo tanto, la lógica del jugador se usa para retuitear enlaces al caso de falla de uno de los servidores; esto ya está en la lógica del jugador.

R: - ¿Y no trataste de trabajar no según un pariente, sino según rutas absolutas: cuando le pides al jugador que haga algo de magia, averigua dónde hay recursos y dónde no, y ya das listas de reproducción que indican un servidor específico?

Señor:- En realidad, parece una solución de trabajo. ¡Si hubieras venido entonces, habríamos pesado los dos! Pero la solución actual también está funcionando, por lo que realmente no quiero saltar de una a la otra, aunque, quizás, esto también parezca una solución que funcione.

A: - Dime, ¿esto es de alguna manera amigable con la multidifusión? HLS, según tengo entendido, absolutamente nada ...

MR: - En la implementación actual, probablemente no tenemos nada en el sistema con la multidifusión en vivo. No incluimos el concepto de multidifusión allí. Quizás en algún lugar en las profundidades de la magia administrativa, hay algo dentro de la red, pero está oculto para todos y nadie lo sabe ...

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

HighLoad ++, Mikhail Raichenko (ManyChat): casi sin magia, o lo fácil que es distribuir la transmisión de video terabit