TCP vs UDP en transmisión de video

Acabo de llegar a casa de mi examen de programación de redes y una de las preguntas que nos hicieron fue "Si va a transmitir video, ¿usaría TCP o UDP? Dé una explicación tanto para el video almacenado como para las transmisiones de video en vivo". . A esta pregunta, simplemente esperaban una respuesta breve de TCP para video almacenado y UDP para video en vivo, pero pensé en esto de camino a casa, y ¿es necesariamente mejor usar UDP para transmitir video en vivo? Quiero decir, si tienes el ancho de banda para eso y dices que estás transmitiendo un partido de fútbol o un concierto, ¿realmente necesitas usar UDP?

Digamos que mientras está transmitiendo este concierto o lo que sea usando TCP, comienza a perder paquetes (algo malo sucedió en alguna red entre usted y el remitente), y durante un minuto entero no recibe ningún paquete. La transmisión de video se detendrá y, después de que pase el minuto, los paquetes comenzarán a pasar nuevamente (IP encontró una nueva ruta para usted). Lo que sucedería entonces es que TCP retransmitiría el minuto que perdiste y continuaría enviándote la transmisión en vivo. Como supuesto, el ancho de banda es mayor que la tasa de bits en la transmisión y el ping no es demasiado alto, por lo que en un corto período de tiempo, el minuto que perdió actuará como un búfer para la transmisión para usted, de esa manera , si la pérdida de paquetes vuelve a ocurrir, no lo notará.

Ahora, puedo pensar en algunos aparatos cuando esto no sería una buena idea, como por ejemplo las videoconferencias, en las que necesita estar siempre al final de la corriente, debido a retraso durante un videocharlas es simplemente horrible, pero durante un partido de fútbol o un concierto, ¿qué importa si estás un minuto detrás de la transmisión? Además, se le garantiza que obtendrá todos los datos y sería mejor guardarlos para verlos más tarde cuando lleguen sin errores.

Entonces esto me lleva a mi pregunta. ¿Existe algún inconveniente que no conozca sobre el uso de TCP para la transmisión en vivo? ¿O debería ser realmente, que si tiene el ancho de banda para ello debería optar por TCP dado que es "más agradable" para la red (control de flujo)?

Inconvenientes de usar TCP para video en vivo:

1. Normalmente, los dispositivos de transmisión de video en vivo no están diseñados teniendo en cuenta la transmisión TCP. Si usa TCP, el sistema operativo debe almacenar en búfer los segmentos no reconocidos para cada cliente. Esto es indeseable, particularmente en el caso de eventos en vivo; presumiblemente su lista de clientes simultáneos es larga debido a la singularidad del evento. Las transmisiones de video pregrabadas generalmente no tienen tanto problema con esto porque los espectadores escalonan su actividad de reproducción; por lo tanto, TCP es más apropiado para reproducir un video a pedido.
2. La multidifusión IP reduce significativamente los requisitos de ancho de banda de video para grandes audiencias; TCP evita el uso de multidifusión IP, pero UDP es adecuado para multidifusión IP.
3. El video en vivo es normalmente un flujo de ancho de banda constante grabado con una cámara; Las secuencias de vídeo pregrabadas salen de un disco. La dinámica de pérdida de retroceso de TCP dificulta la entrega de video en vivo cuando las transmisiones de origen tienen un ancho de banda constante (como sucedería para un evento en vivo). Si almacena el búfer en el disco de una cámara, asegúrese de tener suficiente búfer para eventos de red impredecibles y velocidades de envío / retroceso de TCP variables. UDP le brinda mucho más control para esta aplicación, ya que UDP no se preocupa por las caídas de la capa de transporte de red.

Para su información, no utilice la palabra "paquetes" al describir las redes. Las redes envían "paquetes".

pero durante un partido de fútbol o un concierto, ¿qué importa si estás un minuto detrás de la corriente?

Para algunos fanáticos del fútbol, ​​bastante. Se ha observado que los retrasos de incluso unos pocos segundos presentes en las transmisiones de video digital debido a la codificación (o lo que sea) pueden ser muy molestos cuando, durante eventos de alto perfil como los partidos de la copa del mundo, puedes escuchar los vítores y gemidos de los muchachos. en la puerta de al lado (que están viendo un programa analógico sin editar) antes de ver los movimientos del juego que los causaron.

Creo que para alguien que se preocupa mucho por los deportes (y ese es el grupo más grande de clientes que pagan por la televisión digital, al menos aquí en Alemania), estar un minuto atrasado en una transmisión de video en vivo sería completamente inaceptable (como en, ellos ' cambiar a su competidor cuando esto no suceda).

Por lo general, una transmisión de video es algo tolerante a fallas. Entonces, si algunos paquetes se pierden (debido a la sobrecarga de algún enrutador en el camino, por ejemplo), aún podrá mostrar el contenido, pero con una calidad reducida.

Si su transmisión en vivo estaba usando TCP / IP, entonces se vería obligado a esperar esos paquetes descartados antes de poder continuar procesando datos más nuevos.

Eso es doblemente malo:

• datos antiguos sean re-transmitida (que es probablemente por un marco que ya estaba representada y por lo tanto sin valor) y
• los datos nuevos no pueden llegar hasta después de que los datos antiguos se hayan vuelto a transmitir

Si su objetivo es mostrar la información más actualizada posible (y para una transmisión en vivo generalmente desea estar actualizado, incluso si sus marcos se ven un poco peores), entonces TCP funcionará en su contra.

Para una transmisión grabada, la situación es ligeramente diferente: probablemente estará almacenando mucho más en búfer (¡posiblemente varios minutos!) Y preferiría que los datos se retransmitieran a tener algunos artefactos debido a paquetes perdidos. En este caso, TCP es una buena combinación (esto aún podría implementarse en UDP, por supuesto, pero TCP no tiene tantos inconvenientes como para el caso de transmisión en vivo).

Hay algunos casos de uso adecuados para el transporte UDP y otros adecuados para el transporte TCP.

El caso de uso también dicta la configuración de codificación del video. Cuando se retransmiten partidos de fútbol, ​​la atención se centra en la calidad y en las videoconferencias, la latencia.

Cuando se usa multidifusión para entregar video a sus clientes, se usa UDP.

El requisito de multidifusión es un costoso hardware de red entre el servidor de transmisión y el cliente. En la práctica, esto significa que si su empresa posee una infraestructura de red, puede utilizar UDP y multidifusión para la transmisión de video en vivo. Incluso entonces, la calidad de servicio también se implementa para marcar paquetes de video y priorizarlos para que no ocurra pérdida de paquetes.

La multidifusión simplificará el software de transmisión porque el hardware de red se encargará de distribuir paquetes a los clientes. Los clientes se suscriben a canales de multidifusión y la red se reconfigurará para enrutar paquetes al nuevo suscriptor. De forma predeterminada, todos los canales están disponibles para todos los clientes y pueden enrutarse de manera óptima.

Este flujo de trabajo dificulta el proceso de autorización. El hardware de red no diferencia a los usuarios suscritos de otros usuarios. La solución para la autorización es cifrar el contenido de video y habilitar el descifrado en el software del reproductor cuando la suscripción es válida.

El flujo de trabajo de unidifusión (TCP) permite al servidor verificar las credenciales del cliente y solo permite suscripciones válidas. Incluso permite solo cierto número de conexiones simultáneas.

La multidifusión no está habilitada a través de Internet.

Para enviar vídeo a través de Internet, se debe utilizar TCP. Cuando se usa UDP, los desarrolladores terminan reimplementando la retransmisión de paquetes, por ejemplo. Protocolo en vivo Bittorrent p2p.

"Si usa TCP, el sistema operativo debe almacenar en búfer los segmentos no reconocidos para cada cliente. Esto es indeseable, particularmente en el caso de eventos en vivo".

Este búfer debe existir de alguna forma. Lo mismo ocurre con el búfer de fluctuación en el lado del reproductor. Se llama "búfer de conexión" y el software del servidor puede saber cuándo este búfer está lleno y descartar los cuadros de video adecuados para transmisiones en vivo. Es mejor utilizar el método de unidifusión / TCP porque el software del servidor puede implementar una lógica de caída de tramas adecuada. Los paquetes faltantes aleatorios en el caso de UDP solo crearán una mala experiencia de usuario. como en este video: http://tinypic.com/r/2qn89xz/9

"La multidifusión IP reduce significativamente los requisitos de ancho de banda de video para grandes audiencias"

Esto es cierto para las redes privadas, la multidifusión no está habilitada a través de Internet.

"Tenga en cuenta que si TCP pierde demasiados paquetes, la conexión se interrumpe; por lo tanto, UDP le brinda mucho más control para esta aplicación, ya que a UDP no le importan las caídas de la capa de transporte de red".

UDP tampoco se preocupa por eliminar fotogramas completos o grupos de fotogramas, por lo que no brinda más control sobre la experiencia del usuario.

"Por lo general, una transmisión de video es algo tolerante a fallas"

El video codificado no es tolerante a fallas. Cuando se transmite a través de un transporte no confiable, la corrección de errores de reenvío se agrega al contenedor de video. Un buen ejemplo es el contenedor MPEG-TS utilizado en la transmisión de video por satélite que transporta varias transmisiones de audio, video, EPG, etc. Esto es necesario ya que el enlace por satélite no es una comunicación dúplex, lo que significa que el receptor no puede solicitar la retransmisión de paquetes perdidos.

Cuando tiene comunicación dúplex disponible, siempre es mejor retransmitir datos solo a los clientes que tienen pérdida de paquetes y luego incluir la sobrecarga de corrección de errores en el flujo enviado a todos los clientes.

En cualquier caso, los paquetes perdidos son inaceptables. Los fotogramas descartados están bien en casos excepcionales cuando el ancho de banda se ve obstaculizado.

El resultado de los paquetes faltantes son artefactos como este:

Algunos decodificadores pueden romperse en flujos que faltan paquetes en lugares críticos.

Te recomiendo que mires el nuevo protocolo p2p live Bittorent Live .

En cuanto a la transmisión, es mejor usar UDP, primero porque reduce la carga en los servidores, pero sobre todo porque puede enviar paquetes con multidifusión, es más simple que enviarlo a cada cliente conectado.

Depende. ¿Qué importancia tiene el contenido que está transmitiendo? Si es crítico, use TCP. Esto puede causar problemas en el ancho de banda, la calidad del video (es posible que deba usar una calidad más baja para lidiar con la latencia) y la latencia. Pero si necesita el contenido para garantizar su llegada, úselo.

De lo contrario, UDP debería estar bien si la transmisión no es crítica y sería preferible porque UDP tiende a tener menos gastos generales.

Uno de los mayores problemas con la entrega de eventos en vivo en Internet es la 'escala', y TCP no escala bien. Por ejemplo, cuando está transmitiendo un partido de fútbol en vivo, a diferencia de la reproducción de una película a pedido, la cantidad de personas que miran puede ser 1000 veces más. En tal escenario, el uso de TCP es una sentencia de muerte para las CDN (redes de distribución de contenido).

Hay un par de razones principales por las que TCP no escala bien:

1. Uno de los mayores inconvenientes de TCP es la variabilidad del rendimiento que se puede lograr entre el remitente y el receptor. Cuando se transmite video a través de Internet, los paquetes de video deben atravesar múltiples enrutadores a través de Internet, cada uno de estos enrutadores está conectado con conexiones de diferente velocidad. El algoritmo TCP comienza con una ventana TCP pequeña, luego crece hasta que se detecta la pérdida de paquetes, la pérdida de paquetes se considera un signo de congestión y TCP responde reduciendo drásticamente el tamaño de la ventana para evitar la congestión. Así, a su vez, se reduce el rendimiento efectivo de forma inmediata. Ahora imagine una red con transmisión TCP usando 6-7 saltos de enrutador hacia el cliente (un escenario muy normal), si alguno de los enrutadores intermedios pierde algún paquete, el TCP para ese enlace reducirá la velocidad de transmisión. De hecho, el flujo de tráfico entre enrutadores sigue una especie de forma de reloj de arena; siempre gong arriba y abajo entre uno de los enrutadores intermedios. Hacer que el rendimiento sea mucho más bajo en comparación con el UDP de mejor esfuerzo.

2. Como ya sabrá, TCP es un protocolo basado en reconocimiento. Digamos, por ejemplo, que un remitente está a 50 ms de distancia (es decir, latencia entre dos puntos). Esto significaría que el tiempo que tarda un paquete en enviarse a un receptor y el receptor para enviar un acuse de recibo sería de 100 ms; por tanto, el rendimiento máximo posible en comparación con la transmisión basada en UDP ya se ha reducido a la mitad.

3. El TCP no admite la multidifusión o el nuevo estándar emergente de multidifusión AMT. Lo que significa que las CDN no tienen la oportunidad de reducir el tráfico de red replicando los paquetes, cuando muchos clientes están viendo el mismo contenido. Eso en sí mismo es una razón suficientemente importante para que los CDN (como Akamai o Level3) no utilicen TCP para transmisiones en vivo.

Mientras leía el debate sobre TCP UDP, noté una falla lógica. Una pérdida de paquete TCP que causa un retraso de un minuto que se convierte en un búfer de un minuto no puede correlacionarse con la caída de UDP durante un minuto completo mientras se experimenta la misma pérdida. Una comparación más justa es la siguiente.

TCP experimenta una pérdida de paquetes. El video se detiene mientras TCP reenvía los paquetes en un intento de transmitir paquetes matemáticamente perfectos. El video se retrasa por un minuto y continúa donde lo dejó después de que el paquete faltante llega a su destino. Todos esperamos, pero sabemos que no nos perderemos ni un solo píxel.

UDP experimenta una pérdida de paquetes. Por un segundo durante la transmisión de video, una esquina de la pantalla se vuelve un poco borrosa. Nadie se da cuenta y el espectáculo continúa sin buscar los paquetes perdidos.

Todo lo que se transmite obtiene los mayores beneficios de UDP. La pérdida de paquetes que provoca un retraso de un minuto en TCP no provocaría un retraso de un minuto en UDP. Teniendo en cuenta que la mayoría de los sistemas usan flujos de resolución múltiple, lo que hace que las cosas se vuelvan bloqueadas cuando se mueren de hambre por paquetes, tiene aún más sentido usar UDP.

UDP FTW al transmitir.

Si el ancho de banda es mucho mayor que la tasa de bits, recomendaría TCP para la transmisión de video en vivo unidifusión.

Caso 1: Los paquetes consecutivos se pierden durante varios segundos. => el video en vivo se detendrá en el lado del cliente, sea cual sea la capa de transporte (TCP o UDP). Cuando la red se recupera: - si se usa TCP, el reproductor de video del cliente puede elegir reiniciar la transmisión en el primer paquete perdido (cambio de tiempo) O descartar todos los paquetes tardíos y reiniciar la transmisión de video sin cambio de tiempo. - si se usa UDP, no hay opción en el lado del cliente, el video se reinicia en vivo sin ningún cambio de tiempo. => TCP igual o mejor.

Caso 2: algunos paquetes se pierden aleatoriamente y con frecuencia en la red. - si se utiliza TCP, estos paquetes se retransmitirán inmediatamente y con un búfer de fluctuación correcto, no habrá impacto en la calidad / latencia del flujo de video. - si se utiliza UDP, la calidad del video será deficiente. => TCP mucho mejor

Para la transmisión de video, el ancho de banda es probablemente la restricción del sistema. El uso de multidifusión puede reducir en gran medida la cantidad de ancho de banda ascendente utilizado. Con UDP puede multidifundir fácilmente sus paquetes a todos los terminales conectados. También puede usar un protocolo de multidifusión confiable, uno se llama Pragmatic General Multicast (PGM), no sé nada al respecto y supongo que no está muy extendido en su uso.

Además de todas las otras razones, UDP puede usar multidifusión. Dar soporte a miles de usuarios de TCP que transmiten los mismos datos desperdicia ancho de banda. Sin embargo, existe otra razón importante para utilizar TCP.

TCP puede pasar mucho más fácilmente a través de firewalls y NAT. Dependiendo de su NAT y operador, es posible que ni siquiera pueda recibir un flujo UDP debido a problemas con la perforación de orificios UDP.

Todas las respuestas de 'use UDP' asumen una red abierta y se acercan a 'rellenarlo tanto como pueda'. Bueno para redes de audio / video dedicadas de jardín cerrado de estilo antiguo, que son del tipo que desaparece.

En el mundo real, su transmisión pasará a través de firewalls (que eliminarán la multidifusión y, a veces, udp), la red se comparte con otras aplicaciones más importantes ($$$), por lo que desea castigar a los abusadores con escalado de ventanas.

Esta es la cuestión, es más una cuestión de contenido que de tiempo. El protocolo TCP requiere que un paquete que no se entregó se verifique, verifique y vuelva a entregar. UDP no usa este requisito. Entonces, si envió un archivo que contiene millones de paquetes usando UDP, como un video, si algunos de los paquetes faltan en el momento de la entrega, lo más probable es que no se pierdan.