Escribimos nuestro protocolo encima de UDP

Las primeras transmisiones en vivo de la escena aparecieron en Rusia hace casi 70 años y se transmitieron desde una estación de televisión móvil (PTS), que parecía un trolebús y le permitía transmitir desde fuera del estudio. Y hace solo tres años, Periscope permitió usar un teléfono móvil en lugar de un "trolebús".

Pero esta aplicación tenía una serie de problemas relacionados, por ejemplo, con demoras en la transmisión, la incapacidad de ver transmisiones en alta calidad, etc.


Seis meses después, en el verano de 2016, Odnoklassniki lanzó su aplicación móvil de transmisión OK Live, en la que intentaron resolver estos problemas.

Alexander Tobol es responsable de la parte técnica del video en Odnoklassniki y en Highload ++ 2017 habló sobre cómo escribir su protocolo UDP y por qué podría ser necesario.

De la transcripción de su informe, aprenderá todo sobre otros protocolos de transmisión de video, cuáles son los matices y qué trucos a veces se requieren.


Dicen que siempre debemos comenzar con la arquitectura y los conocimientos tradicionales, ¡supuestamente es imposible sin esto! Entonces hagámoslo.

Arquitectura y conocimientos tradicionales

En la siguiente diapositiva se encuentra el diagrama de arquitectura de cualquier servicio de transmisión: el video se alimenta a la entrada, se convierte y se transmite a la salida . Agregamos un poco más de requisitos a esta arquitectura: el video debe suministrarse desde computadoras de escritorio y teléfonos móviles, y la salida debe ir a las mismas computadoras de escritorio, teléfonos móviles, smartTV, Chromcast, AppleTV y otros dispositivos; todo ese video se puede reproducir.


A continuación, pasamos a los términos de referencia. Si tienes un cliente, tienes TK. Si eres una red social, no tienes TK. ¿Cómo inventarlo?

Por supuesto, puede entrevistar a los usuarios y descubrir todo lo que quieren. Pero será un montón de deseos que no se correlacionan con lo que la gente realmente necesita.

Decidimos ir en sentido contrario y vimos lo que los usuarios NO querían ver desde el servicio de transmisión.

• Lo primero que el usuario no quiere es ver el retraso al comienzo de la transmisión .
  
• El usuario no quiere ver una imagen de transmisión de baja calidad .
  
• Si la transmisión es interactiva cuando el usuario se comunica con su audiencia (transmisiones en vivo, llamadas, etc.), entonces no quiere ver el retraso entre el transmisor y el espectador .
  

Así es como se ve un servicio de transmisión normal. Veamos qué se puede hacer para hacer un servicio de transmisión regular en lugar del habitual.


Puede comenzar mirando todos los protocolos de transmisión, seleccionar los más interesantes y compararlos. Pero lo hicimos de manera diferente.

¿Qué tienen los competidores?

Comenzamos explorando los servicios de la competencia. Open Periscope: ¿qué tienen?

Como siempre, lo principal es la arquitectura.


Sara Hyder, ingeniera principal de Periscope, escribe que usan Wowza para el backend. Si leemos un poco más de artículos, veremos qué transmiten utilizando el protocolo RTMP y lo distribuiremos en RTMP o en HLS. Veamos cuáles son estos protocolos y cómo funcionan.

Probamos Periscope en nuestros tres requisitos principales.

Tienen una velocidad de inicio aceptable (menos de un segundo en buenas redes), una calidad constante de aproximadamente 600 px (no HD) y, al mismo tiempo, los retrasos pueden ser de hasta 12 segundos .

Por cierto, ¿cómo medir el retraso en la transmisión?

Esta es una fotografía de una medición de retraso. Hay un teléfono móvil con temporizador. Encendemos la transmisión y vemos la imagen de este teléfono en la pantalla. Durante 0,15 milisegundos, la imagen cayó en el sensor de la cámara y se retiró de la memoria de video a la pantalla del teléfono. Después de eso, encendemos el navegador y vemos la transmisión.

¡Ay! Ella está un poco retrasada, unos 12 segundos.

Para encontrar las razones del retraso, perfilamos la transmisión de video.

Entonces, hay un teléfono móvil, el video sale de la cámara y entra al búfer de video. Aquí los retrasos son mínimos (≈0.15 ms). Luego, el codificador codifica la señal, la empaqueta en un paquete y la envía al buffer del zócalo. Todo vuela a la web. Además, lo mismo sucede en el dispositivo receptor.

Básicamente, hay dos puntos difíciles principales a considerar:

• codificación / decodificación de video;
  
• protocolos de red
  

Codificación / Decodificación de video

Les contaré un poco sobre la codificación. Lo encontrarás de todos modos si haces transmisión en vivo de baja latencia.

¿Qué es un video? Este es un conjunto de marcos, pero no del todo simple. Los marcos son de tres tipos: I, P y B-frame:

• I-frame es solo jpg. De hecho, este es un marco de referencia, no depende de nadie y contiene una imagen clara.
  
• El marco P depende únicamente de los marcos anteriores.
  
• El complicado marco B puede depender del futuro. Esto significa que para calcular el cuadro b, es necesario que los cuadros futuros también provengan de la cámara. Solo entonces se puede decodificar un b-frame con cierto retraso.
  

Esto muestra que los marcos B son perjudiciales . Intentemos eliminarlos.

1. Si transmite desde un dispositivo móvil, puede intentar habilitar el perfil de línea de base . Deshabilitará el marco B.
   
2. Puede intentar configurar el códec y reducir la demora para cuadros futuros para que los cuadros lleguen más rápido.
   
3. Otra cosa importante al ajustar el códec es la inclusión de CBR (velocidad de bits constante).
   

El funcionamiento de los códecs se ilustra en la diapositiva anterior. En este ejemplo, el video es una imagen estática, su codificación ahorra espacio en el disco, porque casi nada cambia allí, y la tasa de bits del video es baja. Se están produciendo cambios: la entropía está creciendo, la tasa de bits de video está creciendo, es genial almacenarla en el disco.

Pero en el momento en que comenzaron los cambios activos, y la tasa de bits aumentó, lo más probable es que todos los datos no ingresen a la red. Esto es exactamente lo que sucede cuando haces una videollamada y comienzas a girar, y tu suscriptor ralentiza la imagen. Esto se debe al hecho de que la red no tiene tiempo para adaptarse al cambio de la velocidad de bits.

Uno debe incluir CBR . No todos los códecs de Android lo admitirán correctamente, pero se esforzarán por conseguirlo. Es decir, debe comprender que con CBR no obtendrá la imagen perfecta del mundo, como en la imagen inferior, pero vale la pena encenderla.

4. Y en el backend necesita agregar el códec de latencia cero a H264; esto le permitirá no hacer dependencias en marcos para el futuro.

Protocolos de transferencia de video

Considere qué protocolos de transmisión ofrece la industria. Los dividí condicionalmente en dos tipos:

1. protocolos de transmisión;
   
2. protocolos de segmento.
   

Los protocolos de transmisión son protocolos del mundo de las llamadas p2p: RTMP, webRTC, RTSP / RTP . Se diferencian en que los usuarios acuerdan qué canal tienen, seleccionan la tasa de bits del códec según el canal. Y también tienen equipos adicionales de este tipo, como "dame un tiro de referencia". Si perdió un marco, en estos protocolos puede solicitarlo nuevamente.

La diferencia entre los protocolos de segmento es que nadie negocia con nadie. Cortan el video en segmentos, almacenan cada segmento en varias calidades y el cliente puede elegir qué segmento mirar. Cada segmento comienza con un marco de referencia.

Considere los protocolos con más detalle. Comencemos con los protocolos de transmisión y descubramos qué problemas podemos encontrar si usamos protocolos de transmisión para la transmisión de transmisión.

Protocolos de transmisión

Periscope usa RTMP. Este protocolo apareció en 2009, y al principio Adobe no lo especificó por completo. Luego tuvo un cierto tipo de dificultad con el hecho de que Adobe quería vender exclusivamente su servidor. Es decir, RTMP se desarrolló bastante difícil. Su principal problema es que usa TCP , pero por alguna razón Periscope lo eligió.



Si lees en detalle, resulta que Periscope usa RTMP para transmitir con un pequeño número de espectadores. Solo tales transmisiones, si tiene un canal insuficiente, lo más probable es que no pueda verlo.



Considere un ejemplo específico. Hay un usuario con un canal de comunicación estrecho que está viendo su transmisión. Usted está de acuerdo con él en RTMP sobre la baja tasa de bits y comienza a transmitirlo personalmente.

Un usuario con Internet genial viene a ti, tú también tienes Internet genial, pero ya has acordado una baja calidad con alguien, y resulta que este tercero con Internet genial está viendo una transmisión de mala calidad, a pesar de que podría se ven bien

Decidimos solucionar este problema. Hicimos posible que RTMP se truncara individualmente para cada cliente, es decir, los streamers negocian con el servidor, transmiten con la mayor calidad posible y cada cliente recibe la calidad que la red le permite.

Wow!

Pero aún así, tenemos RTMP sobre TCP, y nadie nos ha asegurado que bloqueemos el comienzo de la cola.



Esto se ilustra en la figura: recibimos fotogramas de audio y video, RTMP los empaqueta, tal vez los mezclan de alguna manera y vuelan a la red.

Pero supongamos que perdemos un paquete. Es posible que se haya descartado el mismo paquete amarillo perdido, que generalmente es una trama P de alguna anterior. Quizás, como mínimo, uno podría reproducir audio. Pero TCP no nos dará el resto de los paquetes, ya que garantiza la entrega y la secuencia de los paquetes . De alguna manera debemos lidiar con esto.


Hay otro problema con el uso del protocolo TCP en la transmisión.

Digamos que tenemos un búfer y un alto ancho de banda de red. Generamos paquetes de alta resolución desde nuestro códec allí. Entonces, ¡op! - La red comenzó a funcionar peor. En el códec, ya hemos indicado que la tasa de bits debe reducirse, pero los paquetes ya están en la cola y no puede eliminarlos de allí de ninguna manera. TCP está desesperado por impulsar paquetes HD a través de nuestro 3G.

No tenemos administración de búfer, ni priorización, por lo que TCP es extremadamente inadecuado para la transmisión .



Echemos un vistazo a las redes móviles ahora. Puede ser sorprendente para los residentes de las ciudades capitales, pero nuestra red móvil promedio se ve así:

• Tráfico de 1.1 Mbps;
  
• 0.1% de pérdida de paquetes;
  
• RTT promedio de 300 ms.
  

Y si observa algunas regiones y operadores específicos, tienen un porcentaje promedio de pérdida de paquetes diarios de más del 3% , y el RTT de 600 ms es normal.

TCP es, por un lado, un protocolo genial: es muy difícil enseñarle a un automóvil a conducir de inmediato en carreteras y fuera de carretera. Pero enseñarle a ella también a volar por redes inalámbricas fue muy difícil.

Perder incluso el 0.001% de los paquetes resulta en una reducción del 30% en el rendimiento. Es decir, nuestro usuario no utiliza el canal en un 30% debido a la ineficiencia del protocolo TCP en redes con pérdida aleatoria de paquetes.

En ciertas regiones, la pérdida de paquetes alcanza el 1%, luego el usuario tiene aproximadamente el 10% del ancho de banda.

Por lo tanto, no haremos TCP .

Veamos qué más hay en el mundo de la transmisión desde UDP.

El protocolo WebRTC ha funcionado muy bien para llamadas p2p. En sitios muy populares escriben que usarlo para llamadas es muy bueno, pero para entregar videos y música no es bueno.

Su principal problema es que descuida las pérdidas . Con todas las situaciones extrañas, él simplemente cae.

Todavía hay algún problema en su apego a las llamadas, el hecho es que encripta todo. Por lo tanto, si difunde transmisiones y no hay necesidad de encriptar toda la transmisión de audio / video al iniciar WebRTC, de todos modos pondrá a prueba su procesador. Puede que no necesites esto.



La transmisión RTP es el protocolo básico para transmitir datos a través de UDP. A continuación, en la diapositiva a la derecha, hay un conjunto de extensiones y RFC que tuvieron que implementarse en WebRTC para adaptar este protocolo a las llamadas. En principio, puede intentar hacer algo como esto: marque un conjunto de extensiones a RTP y obtenga la transmisión UDP. Pero es muy dificil .

El segundo problema es que si uno de sus clientes no admite ninguna extensión, entonces el protocolo no funcionará.

Protocolos de segmento

Un buen ejemplo de un protocolo de video segmentado es MPEG-Dash . Consiste en un archivo de manifiesto que publica en su portal. Contiene enlaces a archivos en diferentes calidades, al principio del archivo hay un índice que dice en qué lugar del archivo comienza qué segmento.



Todo el video se divide en segmentos, por ejemplo, durante 3 segundos, cada segmento comienza con un marco de referencia. Si ve un video de este tipo y su tasa de bits cambia, entonces solo en el lado del cliente comienza a tomar el segmento de la calidad que necesita.

Otro ejemplo de transmisión segmentada es HLS .

MPEG-Dash es una solución de Google, funciona bien en Android, y la solución de Apple es más antigua, tiene una serie de ciertas desventajas.



El primero de ellos es que el manifiesto principal contiene enlaces a manifiestos secundarios, los manifiestos secundarios para cada cualidad específica contienen enlaces a cada segmento individual, y cada segmento individual está representado por un archivo separado.

Si miras aún más en detalle, entonces dentro de cada segmento está MPEG2-TS. Este protocolo también se creó para el satélite; su tamaño de paquete es de 188 bytes . Es muy incómodo empacar video en este tamaño, especialmente porque siempre le proporciona un encabezado pequeño.

De hecho, esto es difícil no solo para los servidores, que para procesar 40 GB de tráfico deben recolectar 26 millones de paquetes , sino que también es difícil para el cliente. Por lo tanto, cuando reescribimos el reproductor iOS en MPEG-Dash, incluso vimos algunas mejoras de rendimiento.



Pero Apple no se queda quieto. En 2016, finalmente anunciaron que tienen la oportunidad de extraer un fragmento de MPEG4 en HLS. Luego prometieron agregar esto solo para desarrolladores, pero parece que ahora debería aparecer soporte para macOS e iOS.

Es decir, parece que la transmisión de fragmentos es conveniente: ven, toma el fragmento deseado, comienza desde el marco de referencia, funciona.

Menos: está claro que el marco de referencia desde el que comenzó no es el marco que el que transmite ahora lo tiene. Por lo tanto, siempre hay un retraso .

En general, es posible terminar HLS con demoras del orden de 5 segundos, alguien dice que logró obtener 4, pero en principio, la decisión de usar la transmisión de fragmentos para la traducción no es muy buena .

Dificultad vs retraso

Veamos todos los protocolos disponibles y ordénelos por dos parámetros:

• la latencia que dan entre la transmisión y el espectador;
• complejidad

Cuanto más corto es el retraso que garantiza el protocolo, más complejo es.

Que queremos

Queremos hacer un protocolo UDP para la transmisión de 1 a N con un retraso comparable a la comunicación p2p, con la opción de cifrado opcional de paquetes dependiendo de si la transmisión es privada o pública.

¿Qué otras opciones hay? Puede esperar, por ejemplo, cuando Google lance su QUIC.

Te diré un poco de qué se trata. Google está posicionando Google QUIC como un reemplazo para TCP, una especie de TCP 2.0. Se ha desarrollado desde 2013, ahora no tiene una especificación, pero está completamente disponible en Google Chrome, y me parece que a veces lo encienden a algunos usuarios para ver cómo funciona. En principio, puede acceder a la configuración, activar QUIC, ir a cualquier sitio de Google y obtener este recurso a través de UDP.

Decidimos no esperar hasta que todos especifiquen y presentar nuestra decisión.

Requisitos de protocolo:

1. Multithreading , es decir, tenemos varias transmisiones: control, video, audio.
   
2. Una garantía de entrega opcional : el flujo de control tiene una garantía del 100%, el video que menos necesitamos, podemos dejar el cuadro allí, aún nos gustaría el audio.
   
3. Priorización de transmisiones : para que el audio avance y el gerente generalmente voló.
   
4. Cifrado opcional : ya sea todos los datos o solo encabezados y datos críticos.
   

Este es un triángulo estándar: si es una buena red, alta calidad y baja latencia. Tan pronto como aparece una red inestable, los paquetes comienzan a desaparecer, equilibramos la calidad y el retraso. Tenemos una opción: esperar hasta que la red mejore y enviar todo lo que se ha acumulado, o dejarlo y vivir de alguna manera con él.

Si clasifica los protocolos según este principio, se puede ver que cuanto más corto es el tiempo de espera, peor es la calidad , una conclusión bastante simple.

Queremos introducir nuestro protocolo en la zona donde los retrasos están cerca de WebRTC, pero al mismo tiempo poder impulsarlo un poco, porque después de todo no tenemos llamadas, sino transmisiones. El usuario finalmente quiere recibir una transmisión de calidad.

Desarrollo

Comencemos a escribir el protocolo UDP, pero primero mire las estadísticas.



Estas son nuestras estadísticas sobre redes móviles. Se puede ver que el Internet promedio es un poco más que megabit, la pérdida de paquetes de aproximadamente el 1% es normal y RTT en la región de 600 ms, en 3G, estos son solo valores promedio.

Nos centraremos en esto cuando escribamos el protocolo. ¡Vamos!

Protocolo UDP

Abrimos el socket UDP, quitamos los datos, empacamos, enviamos. Tomamos el segundo paquete del códec, aún lo enviamos. ¡Todo parece ser genial!



Pero obtenemos la siguiente imagen: si comenzamos a enviar aleatoriamente paquetes UDP al socket, según las estadísticas, para el paquete 21, la probabilidad de que llegue será del 85%. Es decir, la pérdida de paquetes ya será del 15%, lo que no es bueno. Esto necesita ser arreglado.



Esto se arregla como estándar. La ilustración ilustra la vida sin Pacer y la vida con Pacer .

Pacer es tal cosa que distribuye paquetes a tiempo y controla su pérdida; Analiza qué es la pérdida de paquetes ahora, dependiendo de esto, se adapta a la velocidad del canal.

Como recordamos, para las redes móviles, la pérdida de paquetes del 1-3% es la norma. En consecuencia, de alguna manera debemos trabajar con esto. ¿Qué pasa si perdemos paquetes?

Retransmitir

En TCP, como saben, hay un algoritmo de retransmisión rápido: enviamos un paquete, el segundo, si el paquete se pierde, luego de un tiempo (período de retransmisión) enviamos el mismo paquete.

Cuales son las ventajas? Sin problemas, sin redundancia, pero hay un punto negativo: algunos períodos de retransmisión .



Parece ser muy simple: después de un tiempo, debe repetir el paquete si no ha recibido la confirmación. Lógicamente, este puede ser un tiempo igual al tiempo 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. , , .



Wow! 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 , .

, .

UDP , .



, , p/b-. . , .

, , , , , , 0,5 .

, , , , p/b, , , .

MTU

Como estamos escribiendo el protocolo nosotros mismos, tendremos que lidiar con la fragmentación de IP. Creo que mucha gente sabe sobre esto, pero por si acaso, te lo contaré brevemente.



Tenemos un servidor, envía algunos paquetes a la red, llegan al enrutador y, a su nivel, la MTU (unidad de transmisión máxima) se vuelve inferior al tamaño del paquete que llegó. Divide el paquete en grande y pequeño (aquí 1100 y 400 bytes) y lo envía.

En principio, no hay problema, todo se reunirá en el cliente y funcionará. Pero si perdemos 1 paquete, descartamos todos los paquetes, además obtenemos costos adicionales para los encabezados de paquetes. Por lo tanto, si está escribiendo su protocolo, es ideal trabajar en la cantidad de MTU.

¿Cómo contarlo?

De hecho, Google no se molesta, coloca alrededor de 1200 bytes en su QUIC y no lo selecciona, porque la fragmentación de IP recopilará todos los paquetes.



Hacemos exactamente lo mismo: primero establecemos un tamaño predeterminado y comenzamos a enviar paquetes, dejamos que los fragmente.

Paralelamente, ejecute un subproceso separado y cree un socket con el indicador de prohibición de fragmentación para todos los paquetes. Si el enrutador encuentra dicho paquete y no puede fragmentar estos datos, lo descartará y posiblemente le enviará a través de ICMP que hay problemas, pero lo más probable es que ICMP se cierre y esto no sucederá. Por lo tanto, simplemente, por ejemplo, intentamos enviar tres veces un paquete de cierto tamaño en algún intervalo. Si no alcanza, creemos que se supera la MTU y la reducimos aún más.

Por lo tanto, al tener la MTU de la interfaz de Internet que está en el dispositivo, y alguna MTU mínima, simplemente seleccionamos la MTU correcta mediante búsqueda unidimensional. Después de eso, ajustamos el tamaño del paquete en el protocolo.

De hecho, a veces cambia. Nos sorprendió, pero en el proceso de cambiar Wi-Fi, etc. MTU está cambiando. Es mejor no detener este proceso paralelo y corregir MTU de vez en cuando.



Mayor distribución de MTU en el mundo. Tenemos alrededor de 1100 bytes en el portal.

Cifrado

Dijimos que queremos gestionar opcionalmente el cifrado. Hacemos la opción más simple: Diffie-Hellman en curvas elípticas. Lo hacemos opcionalmente: encriptamos solo los paquetes de control y encabezados para que man-in-the-middle no pueda recibir la clave de transmisión, interceptarla, etc.



Si la transmisión es privada, también podemos agregar cifrado de todos los datos.

Los paquetes se cifran con AES-256 de forma independiente, por lo que la caída de paquetes no afecta el cifrado de paquetes adicionales.

Priorización

Recuerde, queríamos más priorización del protocolo.



Tenemos metadatos, marcos de audio y video, los enviamos con éxito a la red. Luego, nuestra red se incendia en el infierno y durante mucho tiempo no funciona: entendemos que necesitamos descartar paquetes.

Principalmente descartamos los paquetes de video, luego tratamos de descartar el audio y nunca tocamos los paquetes de control, porque datos como cambios de resolución y otros problemas importantes pueden pasar por ellos.

Bollo adicional sobre UDP

Si va a escribir su protocolo UDP, por ejemplo, con comunicación bidireccional, debe comprender que existe NAT Unbinding y la posibilidad de que no pueda encontrar el cliente desde el servidor.



En la diapositiva, hay momentos en que no fue posible llegar al cliente desde el servidor a través de UDP.

Muchos escépticos dicen que los enrutadores están diseñados de tal manera que NAT Unbinding principalmente desplaza las rutas UDP. Pero lo anterior muestra que si Keep-Alive o ping son menos de 30 segundos, entonces con una probabilidad del 99% será posible llegar al cliente.

Disponibilidad UDP en dispositivos móviles en el mundo

Google dice que el 6%, pero resultó que el 7% de los usuarios móviles no pueden usar UDP . En este caso, dejamos nuestro hermoso protocolo con priorización, cifrado y todo, solo en TCP.

En UDP, VOIP ahora funciona en WebRTC, Google QUIC, y muchos juegos funcionan en UDP. Por lo tanto, no creo que UDP se cierre en dispositivos móviles.

Como resultado, nosotros:

• Reducido el retraso entre el streamer y el observador a 1 s.
  
• Eliminamos el efecto acumulativo en los buffers, es decir, la transmisión no se queda atrás.
  
• El número de puestos en la audiencia ha disminuido .
  
• Pudieron soportar la transmisión en dispositivos móviles FullHD.
  

• El retraso en nuestra aplicación móvil OK Live es de 25 ms - 10 ms más largo que el escáner de la cámara, pero no da tanto miedo.
  
• La transmisión por Internet muestra un retraso de solo 690 ms - ¡espacio!
  

¿Qué más se puede transmitir en Odnoklassniki?

• Acepta nuestro protocolo OKMP desde dispositivos móviles;
  
• puede aceptar RTMP y WebRTC;
  
• distribuye HLS, MPEG-Dash, etc.
  

Si tuvo cuidado, notó que dije que podemos tomar, por ejemplo, WebRTC del usuario y convertirlo a RTMP.



Hay un matiz. De hecho, WebRTC es un protocolo orientado a paquetes y utiliza el códec de audio OPUS. No puede usar OPUS en RTMP.

En los servidores de back-end, utilizamos RTMP en todas partes. Por lo tanto, tuvimos que hacer algunas correcciones más en FF MPEG, lo que nos permite empujar OPUS a RTMP, convertirlo a AAC y dárselo a los usuarios que ya están en HLS o algo más.

¿Cómo se ve dentro de nosotros?

• Los usuarios que utilizan uno de los protocolos cargan el video original en nuestro servidor de carga.
  
• Allí implementamos el protocolo.
  
• Enviamos RTMP a uno de los servidores de transformación de video.
  
• El original siempre se almacena en un almacenamiento distribuido para que no se pierda nada.
  
• Después de eso, todos los videos van al servidor de distribución.
  

Para el hierro, tenemos lo siguiente:


Te contaré un poco más sobre la tolerancia a fallas:

• Los servidores de carga se distribuyen en diferentes centros de datos, respaldan diferentes IP.
  
• Los usuarios vienen, reciben IP en DNS.
  
• El servidor de carga envía el video a los servidores de corte, ellos cortan y entregan a los servidores de distribución.
  
• Para transmisiones más populares, comenzamos a agregar una mayor cantidad de servidores de distribución.
  
• Guardamos todo lo que vino del usuario en el repositorio, para que luego podamos crear un archivo de difusión y no perder nada.
  
• Almacenamiento tolerante a fallas distribuido en tres centros de datos.
  

Para determinar qué servidor es actualmente responsable de la traducción, utilizamos ZooKeeper . Para cada traducción, almacenamos un nodo y hacemos nodos efímeros para cada servidor. De hecho, esto es lo que permite que una secuencia cree una cola de servidores que procesará. Siempre el líder actual en esta línea está involucrado en el procesamiento de flujo.

Probaremos la tolerancia a fallas rápidamente. Comenzamos de inmediato con la desaparición de todo el centro de datos.

Que va a pasar

• El usuario DNS tomará la siguiente IP de otro servidor de carga.
  
• En este momento, ZooKeeper comprenderá que el servidor en ese centro de datos ha muerto y seleccionará el servidor de corte para otro.
  
• Los servidores de descarga descubrirán quién es ahora responsable de la transformación de esta transmisión y la distribuirán.
  

En principio, todo esto sucederá con retrasos mínimos.

Usando el protocolo en el producto

Creamos la aplicación móvil OK Live streaming. Está completamente integrado con el portal. Los usuarios allí pueden comunicarse, realizar transmisiones en vivo, hay un mapa de transmisiones, una lista de transmisiones populares, en general, todo lo que pueda desear.



También agregamos la capacidad de transmitir en FullHD. Puede conectar una cámara de acción en Android a un dispositivo Android.



Ahora tenemos un mecanismo que permite transmisiones en vivo. Por ejemplo, trazamos una línea directa con el Presidente a través de OK Live y la transmitimos a todo el país . Los usuarios observados y a través de la transmisión entrante podrían salir al aire y hacer sus preguntas.

Es decir, de hecho, dos transmisiones entrantes con un retraso mínimo proporcionan un cierto formato de conferencia pública.

De hecho, nos encontramos en algún lugar en 2 segundos, un segundo allí y otro segundo. Recuerda ese "carro" del que hablé al principio del artículo, ahora se parece a 2 enormes camiones. Para la transmisión de TV, eliminar de la cámara y simplemente mezclar todo con un retraso de aproximadamente 1-2 s es completamente normal.

De hecho, logramos reproducir algo comparable con el TCP moderno actual.



Las transmisiones en vivo son la tendencia actual. Durante el último año y medio en el portal OK, se han triplicado (no sin la ayuda de la aplicación OK Live).



Todas las transmisiones se graban por defecto. Tenemos alrededor de 50 mil transmisiones por día, esto genera alrededor de 17 terabytes de tráfico por día, pero en general todo el video en el portal genera aproximadamente un petabyte de datos por mes.



¿Qué obtuvimos?

• Podría garantizar la duración de la demora entre el transmisor y la audiencia.
  
• Creamos la primera aplicación móvil FullHD para transmitir en un canal de Internet móvil que cambia dinámicamente.
  
• Tenemos la oportunidad de perder centros de datos y al mismo tiempo no interrumpir la transmisión.
  

¿Qué aprendiste?

• Qué es el video y cómo transmitirlo.
  
• Que puede escribir su protocolo UDP si sabe con certeza que tiene una tarea muy específica y usuarios específicos.
  
• Acerca de la arquitectura de cualquier servicio de transmisión: el video ingresa a la entrada, se convierte y sale.
  

En Highload ++ Siberia, Alexander Tobol promete hablar sobre el servicio de llamadas OK, será interesante saber qué se logró aplicar a partir de lo que se discutió en este artículo y qué tuvo que implementarse nuevamente.

En la misma sección, se planean informes sobre temas altamente especializados:

• Eugene Rossinsky (ivi) en el sistema para recopilar estadísticas detalladas sobre el funcionamiento de los nodos CDN.
  
• Anton Rusakova (Badoo) sobre la integración de sistemas de pago sin utilizar su propia facturación.