TCP vs UDP para transmisión de video

Requisito previo: Modelo TCP/IP , Protocolo de datagramas de usuario (UDP)

En esta era de Internet moderno con entretenimiento, educación, juegos y todo tipo de necesidades que se transmiten en vivo todos los días, la demanda de una transmisión de video ininterrumpida es muy firme. Para sumergirse en el tema de qué protocolo es mejor para la transmisión de video, uno debe estar familiarizado con los protocolos TCP y UDP .

TCP en la transmisión de paquetes:

• TCP es un protocolo que negocia una sesión formal con su socio. TCP envía datos y acepta reconocimiento. 
• TCP garantiza la entrega. 
• También ajusta su tasa de envío de acuerdo con su estimación de la capacidad de la red para enviar los datos. Estima el ancho de banda, la pérdida y la latencia y si se han deteriorado, disminuirá el caudal y si han mejorado, aumentará el caudal.  
• Si un paquete de datos se pierde durante la transmisión, finalmente se retransmite.

Transmisión normal de TCP:
TCP aumenta gradualmente la cantidad de datos que envía hasta que el enlace se satura. Primero comienza lento y envía más y más datos a un ritmo creciente. En la fase de evitación de congestión, para evitar la congestión, aumenta gradualmente los datos. En la etapa final, ajusta los datos a una velocidad que el receptor puede procesar cómodamente, conocida como estado estacionario.

La reacción de TCP a los paquetes perdidos:
cuando se pierde un paquete, ya sea porque el búfer de la red está sobrellenado o porque el receptor recibe más datos de los que puede almacenar en el búfer, el paquete perdido no se reconocerá, por lo que TCP asume que envió los datos demasiado rápido. y así comienza el lento comienzo de nuevo. Cuando se descarta un segundo paquete, el flujo se corta nuevamente. Si las caídas son sucesivas, entonces la tasa caerá tanto que a la vez solo se envía un paquete.

Podemos ver un escenario que representa la reacción de TCP a los paquetes perdidos a continuación: 

En este escenario, la fuente A envía 10 paquetes de datos D1 a D10 al destinatario B y, durante la transmisión, se pierde un paquete de datos D6. 

• La fuente A establece una conexión TCP con la fuente B.
• A envía el paquete de datos D1 y el paquete de datos D2 a la Fuente B.
• B pide el paquete de datos D3.
• A envía D3 junto con los paquetes de datos D4, D5 y D6.
• Pero D6 se pierde durante la transmisión, digamos debido a que el búfer de B se sobrellenó.
• B entonces pide el paquete de datos D6.
• A esta vez envía solo un paquete, un comienzo lento de nuevo.
• B vuelve a pedir D6.
• A sigue enviando los paquetes D8 y D9 individualmente, mientras que B sigue pidiendo D6.
• El receptor no ha enviado 4 acuses de recibo solicitando D6, el TCP ahora asume que el paquete se ha perdido; de lo contrario, se suponía que estaba mal enrutado en la red. Entonces, A finalmente retransmite D6.
• B ahora pide el paquete de datos D10.
• A envía D10 y luego se realiza el proceso de cierre de la conexión.

Observamos que un solo paquete descartado causó un proceso de inicio lento y un proceso de evitación de congestión para no permitir el aumento en el flujo de tráfico. Cayó de nuevo a un solo paquete a la vez. Por lo tanto, la pérdida de un solo paquete reduce nuestro rendimiento hasta en un 50 %.
Llegamos a ciertas conclusiones de que:

• TCP es sensible a la pérdida de paquetes, la latencia (retraso) y el ancho de banda disponible.
• TCP se ajusta a él utilizando un inicio lento, evitando la congestión y estimando la latencia del tiempo de ida y vuelta (RTT).

Por lo tanto, si su cliente exige un ancho de banda superior al que el remitente podría proporcionar y hay una pérdida de datos, entonces la latencia es inevitable. Ahora, si pensamos en una transmisión de video en vivo y, debido a algunas de las causas mencionadas anteriormente, se produce una pérdida de paquetes, entonces el rendimiento de la transmisión en vivo se verá muy deteriorado porque el protocolo estará ocupado retransmitiendo los paquetes perdidos. Esto hará que el espectador se quede atrás de lo que realmente se está transmitiendo en el video en vivo. 

UDP:
UDP también es un protocolo de capa de transporte. No tiene idea de si los datos llegan o no con éxito. Se envía tan pronto como la aplicación proporciona datos y tan pronto como el sistema operativo dice que está bien. Esencialmente no tiene conocimiento de recepción o falla. UDP hace tres cosas:

• Identifica el proceso de envío y recepción mediante números de puerto.
• Ejecuta una comprobación de errores en el encabezado UDP.
• Registra un cheque en el encabezado UDP.

Por lo tanto, vemos que UDP no proporciona ningún medio para recuperar los paquetes perdidos. No le importa si cada paquete ha llegado a su destino o no. Si vuelve a pensar en la transmisión de video en vivo, una pérdida en un paquete de datos no retrasará el video para recuperar el paquete perdido. La calidad del video se deteriorará según la pérdida, desde un pequeño cuadrado en la esquina de la pantalla distorsionado hasta la pantalla completa, pero el ritmo del video permanecerá alineado con la transmisión en vivo real.

Protocolo en tiempo real:

• UDP en sí mismo no proporciona muchas características que sí ofrece TCP. Pero superponiéndolo con otro protocolo, podemos lograr algunas características iguales a las de TCP.
• En las conferencias de voz o video, algunas de las características de TCP se agregan mediante la inserción de un protocolo llamado Real Time Protocol (RTP). Si colocamos el encabezado RTP con UDP, RTP agregará números de secuencia, algunas marcas de tiempo y un identificador de la fuente de audio o video y también permitirá que el protocolo llamado RTCP informe la pérdida.
• Al usar RTP con UDP, los paquetes de voz se envían con un espaciado uniforme según la salida del códec.
  Por ejemplo, en voz se envían cada 20ms (1/50seg). Y en video, se envían cuando se llena un paquete IP.

Por lo tanto, UDP puede ser muy sensible a la pérdida de voz si se pierden varios paquetes sucesivos, el audio cae momentáneamente y lo notamos. Pero si pierde un solo paquete, es una quincuagésima parte de un segundo de un sonido y su oído no es sensible para detectarlo. Pero en el caso del video, debido a que se necesitan tantos paquetes de video para pintar un solo cuadro, la calidad puede reducirse y se vuelve evidente en forma de pequeños cuadrados o pequeños cortes en la pantalla que cambian a un color diferente porque los datos no t vienen con el fin de pintarlo correctamente. En una transmisión de audio o video en tiempo real, las redes normalmente no deberían exhibir pérdidas > 0.25%.

Por lo tanto, UDP junto con otros protocolos como RTP, WebRTC y RTSP pueden brindar una mejor experiencia de transmisión de video que TCP.