networking - protocolo - puertos tcp y udp

TCP vs UDP en transmisión de video (13)

Acabo de regresar a casa de mi examen de programación de redes, y una de las preguntas que nos hicieron fue: "Si vas a transmitir video, ¿usarías TCP o UDP? Da una explicación tanto del video almacenado como de 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 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 completo no obtiene ningún paquete. La transmisión de video se pausará y, una vez transcurrido 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 perdió y continuará enviándole la transmisión en vivo. Como una suposición, el ancho de banda es más alto que la velocidad 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, de esa manera Si la pérdida de paquetes ocurre nuevamente, no lo notará.

Ahora, puedo pensar en algunos electrodomésticos donde no sería una buena idea, como por ejemplo videoconferencias, donde siempre debes estar al final de la transmisión, porque demorar durante un video-chat es simplemente horrible, pero durante un partido de fútbol o un concierto, ¿qué importa si estás solo un minuto detrás de la corriente? Además, tiene la garantía de 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. ¿Hay algún inconveniente que desconozca sobre el uso de TCP para transmisión en vivo? ¿O debería ser realmente así, si tiene ancho de banda, debería ir a TCP dado que es "más agradable" para la red (control de flujo)?

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

Para algunos fanáticos del fútbol, bastante. Se ha señalado que los retrasos de hasta unos pocos segundos 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, puede escuchar los gritos y los gemidos de los muchachos al lado (que están viendo un programa analógico sin audio) antes de poder ver los movimientos del juego que los causaron.

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

Además de todas las otras razones, UDP puede usar multidifusión. El soporte de miles de usuarios de TCP que transmiten la misma información desperdicia ancho de banda. Sin embargo, hay otra razón importante para usar TCP.

TCP puede pasar mucho más fácilmente a través de cortafuegos y NAT. Dependiendo de su NAT y operador, es posible que ni siquiera sea capaz de recibir una transmisión UDP debido a problemas con la perforación UDP.

Depende. ¿Qué tan crítico es el contenido que estás transmitiendo? Si es crítico usa TCP. Esto puede causar problemas en el ancho de banda, la calidad del video (es posible que deba usar una calidad inferior para tratar la latencia) y la latencia. Pero si necesita que el contenido garantizado llegue allí, ú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 sobrecarga.

Desventajas del uso de TCP para video en vivo:

Normalmente, los dispositivos de transmisión de video en vivo no están diseñados con la transmisión TCP en mente. 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. Los videos pregrabados 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.
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.
El video en vivo es normalmente un flujo de ancho de banda constante grabado desde una cámara; las transmisiones de video pregrabado salen de un disco. La dinámica de pérdida de respaldo de TCP hace que sea más difícil ofrecer videos en vivo cuando las transmisiones de origen tienen un ancho de banda constante (como ocurriría en un evento en vivo). Si realiza una búfer de una cámara en el disco, asegúrese de tener suficiente memoria intermedia para eventos de red impredecibles y tasas variables de envío / desaprobación de TCP. Tenga en cuenta que si TCP pierde demasiados paquetes, la conexión fallece; por lo tanto, UDP le da 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.

FYI, por favor no use la palabra "paquetes" cuando describa redes. Las redes envían "paquetes".

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 fue entregado debe ser verificado, verificado y reenviado. UDP no usa este requisito. Por lo tanto, 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.

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

El caso de uso también dicta ajustes de codificación para el video. Cuando se difunde un partido de fútbol, la atención se centra en la calidad y para la videoconferencia, el foco está en la latencia.

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

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

Multicast simplificará el software de transmisión porque el hardware de red administrará la distribución de paquetes a los clientes. Los clientes se suscriben a canales de multidifusión y la red se reconfigurará para enrutar los paquetes al nuevo suscriptor. Por defecto, todos los canales están disponibles para todos los clientes y se pueden enrutar 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 a la autorización consiste en encriptar 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 en internet.

Para la entrega de video a través de Internet debe usarse TCP. Cuando se usa UDP, los desarrolladores terminan reimplementando la retransmisión de paquetes, por ejemplo. Bittorrent p2p live protocol.

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

Este buffer debe existir de alguna forma. Lo mismo es cierto para el buffer de fluctuación en el lado del jugador. Se llama "memoria intermedia del zócalo" y el software del servidor puede saber cuándo está lleno este búfer y descartar los fotogramas de video adecuados para transmisiones en vivo. Es mejor utilizar el método de unidifusión / TCP porque el software del servidor puede implementar la lógica de descarte de fotogramas adecuada. Los paquetes aleatorios faltantes en el caso de UDP solo crearán una mala experiencia de usuario. como en este video: http://tinypic.com/r/2qn89xz/9

"Multicast 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 muere, por lo tanto, UDP le da 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".

UDP tampoco se preocupa por eliminar cuadros enteros o grupos de marcos, por lo que no le da más control sobre la experiencia del usuario.

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

El video codificado no es tolerante a fallas. Cuando se transmite por un transporte no confiable, se agrega la corrección de errores hacia adelante al contenedor de video. Un buen ejemplo es el contenedor MPEG-TS utilizado en transmisión de video satelital 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 los paquetes perdidos.

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

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

El resultado de paquetes faltantes son artefactos como este:

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

Mientras leía el debate TCP UDP noté un error lógico. Una pérdida de paquetes TCP que causa un retraso de un minuto que se convierte en un búfer de un minuto no se puede correlacionar con UDP cayendo un minuto completo mientras 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 los paquetes de reenvío TCP intentan 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 destino. Todos esperamos, pero sabemos que no 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.

Cualquier cosa que fluya obtiene la mayor cantidad de beneficios de UDP. La pérdida de paquetes que causa un retraso de un minuto para TCP no causaría un retraso de un minuto para UDP. Teniendo en cuenta que la mayoría de los sistemas usan múltiples flujos de resolución haciendo 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.

Para el streaming de video, el ancho de banda es probablemente la restricción en el sistema. Al utilizar la 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 podría usar un protocolo confiable de multidifusión, uno se llama Pragmatic General Multicast (PGM), no sé nada al respecto y supongo que no está muy extendido en su uso.

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

Si su transmisión en vivo estaba usando TCP / IP, entonces se vería forzado a esperar esos paquetes caídos antes de que pudiera continuar procesando datos más nuevos.

Eso es doblemente malo:

los datos antiguos se vuelven a transmitir (probablemente para un cuadro que ya se visualizó y, por lo tanto, no tiene ningún valor) y
los nuevos datos no pueden llegar hasta que los datos antiguos hayan sido retransmitidos

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

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

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

Caso 1: los paquetes consecutivos se pierden por una duración de 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 utiliza TCP, el reproductor de video del cliente puede elegir reiniciar la transmisión en el primer paquete perdido (timeshift) O eliminar todos los paquetes retrasados y reiniciar la transmisión de video sin Timeshift. - Si se usa UDP, no hay elección en el lado del cliente, reinicio de video en vivo sin ningún Timeshift. => TCP igual o mejor.

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

Te recomiendo que veas el nuevo protocolo en vivo p2p 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.

Todas las respuestas de ''usar UDP'' suponen una red abierta y un enfoque ''lo más importante posible''. Es bueno para redes de audio / video dedicadas de jardín cerrado de estilo antiguo, que son un tipo que se desvanece.

En el mundo real, su transmisión pasará por firewalls (que eliminarán multicast 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.

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

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

Una de las compensaciones más grandes de TCP es la variabilidad del rendimiento que se puede lograr entre el emisor y el receptor. Al transmitir videos por Internet, los paquetes de video deben atravesar múltiples enrutadores a través de Internet, cada uno de estos enrutadores está conectado con diferentes conexiones de 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. Por lo tanto, a su vez, se reduce el rendimiento efectivo de inmediato. Ahora imagine una red con transmisión TCP usando 6-7 saltos de enrutador para el cliente (un escenario muy normal), si cualquiera de los enrutadores intermedios pierde cualquier paquete, el TCP para ese enlace reducirá la velocidad de transmisión. De hecho, el flujo de tráfico entre los enrutadores sigue una especie de forma de reloj de arena; siempre gong arriba y abajo entre uno de los enrutadores intermedios. Renderizar el efectivo a través de poner mucho más bajo en comparación con el UDP de mejor esfuerzo.
Como ya sabrá, TCP es un protocolo basado en acuses de recibo. Digamos, por ejemplo, que un emisor está a 50ms de distancia (es decir, latencia por dos puntos). Esto significaría que el tiempo que tarda un paquete en enviarse a un receptor y receptor para enviar un acuse de recibo sería de 100 ms; por lo tanto, el rendimiento máximo posible en comparación con la transmisión basada en UDP ya se ha reducido a la mitad.
El TCP no admite la multidifusión o el nuevo estándar emergente de multidifusión AMT. Lo que significa que los CDN no tienen la oportunidad de reducir el tráfico de red al replicar los paquetes, cuando muchos clientes miran el mismo contenido. Eso en sí mismo es una razón suficientemente importante para que CDN (como Akamai o Level3) no vaya con TCP para transmisiones en vivo.