TCP vs UDP en transmisión de video

96

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)?

Alxandr
fuente
no puede usar TCP sin ningún retraso incorporado (eso es algo en lo que todos están de acuerdo) pero puede usar TCP + UDP para proporcionar buena calidad si se graba la sesión.
bestsss

Respuestas:

87

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".

Mike Pennington
fuente
Lo siento, lo cambiaré. Sin embargo, una pregunta, ¿no es IPv6 (sí, lo sé, es posible que todavía no sea compatible con la multidifusión), por lo que también debería TCP sobre IPv6?
Alxandr
1
Ah, y también, el video grabado de un evento en vivo probablemente se guarde en el disco de todos modos, teniendo que retransmitir una pequeña parte de eso, ¿realmente dolería tanto?
Alxandr
1
@Alxandr, no estoy familiarizado con nada en IPv6 que facilite la multidifusión de TCP. ¿Qué característica de IPv6 tiene en mente?
Mike Pennington
2
@Alxandr, incluso si usa direcciones Anycast, no resuelve el problema fundamental con el servicio de multidifusión sobre TCP ... TCP identifica los sockets como una tupla cuádruple de (src ip, src port, dst ip, dst port). Si todos los clientes usan la misma ip src, de alguna manera debe enrutar los paquetes IPv6 a ellos según el puerto src y mantener el estado de pérdida entre todos los clientes. Esto frustra el propósito de la multidifusión, que era enviar una copia de los paquetes a cada receptor
Mike Pennington
Veo. Gracias por la respuesta :). Solo tenía curiosidad por esto, así que pensé en ver qué pensaba la gente de esto. Y parece que los fanáticos del fútbol del mundo e Internet en sí están en mi contra, así que supongo que es mi pérdida ^ _ ^
Alxandr
26

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).

Michael Borgwardt
fuente
Recuerdo que la gente también se quejaba de eso en Suiza.
Tara
21

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).

Joachim Sauer
fuente
1
Pero como expliqué, muchas de las transmisiones "en vivo" que usamos hoy probablemente no tendrían ningún problema con un retraso de medio minuto y, por lo tanto, obtendría automáticamente un búfer, de modo que no verá los paquetes perdidos en todas. ¿No sería probablemente preferible esto si tuviera que guardar los datos?
Alxandr
2
@Alexandr: en ese caso, está suavizando la definición de una transmisión "en vivo", ¿no es así ;-)
Joachim Sauer
Sí, lo sé, pero intenté explicar eso también en la pregunta. Aunque parece que el problema principal sería el almacenamiento en búfer de datos antiguos (para retransmitir) y la multidifusión (al menos con IPv4)
Alxandr
En cualquier caso, no desea paquetes descartados, provocará artefactos visuales que se propagarán en múltiples marcos. La solución adecuada es eliminar fotogramas completos y UDP definitivamente no es una solución para la congestión de la red en la reproducción de video.
Alex
Por defecto, una transmisión de video no es tolerante a fallas
Alex
9

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: artefactos

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

Alex
fuente
-1 para multidifusión no está habilitado a través de Internet. No está en todas partes, pero algunos pares ofrecen servicio de multidifusión. Un ejemplo es SeattleIX que activó la multidifusión en 2009
Mike Pennington
2
@ Mike Pennington: pocos proveedores no son "Internet", por lo que mi afirmación sigue siendo cierta. Solo está señalando un subconjunto muy pequeño de la infraestructura y esperando que otros se unan a esta práctica. Cíñete a los hechos.
Alex
1
Cuando encuentre un punto para debatir cuánta multidifusión se ejecuta a través de Internet, hágamelo saber
Mike Pennington
4

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.

Andrey Nikishaev
fuente
3

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.

Webs
fuente
3

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.

Waqas
fuente
2

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.

usuario3439082
fuente
1
Olvidas que la mayoría de los códecs de video tienen al menos un poco de redundancia mediante el uso de códigos de corrección de errores. De todos modos, se puede ignorar un solo paquete descartado porque los datos ya estaban disponibles y es posible que el decodificador ni siquiera se dé cuenta.
Andy
2

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

Stan33
fuente
1

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.

ojos mil
fuente
1

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.

Andy
fuente
0

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.

nim
fuente
0

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.

Ángel
fuente