¿Por qué el número de secuencia en RTP difiere de los de TCP?

Una respuesta un poco larga. De hecho, la respuesta es que simplemente la idea del transporte RTP es muy diferente a la del TCP.

Se diferencian por varias razones, en las que puedo pensar en este momento:

  • RTP no es un protocolo de capa 4. Un paquete RTP debe estar encapsulado por TCP o (en la mayoría de los casos) UDP. De hecho, RTP puede considerarse como una capa superior en términos de pila OSI. Un protocolo de capa superior NO conocerá el encabezado del paquete de un protocolo de capa inferior: el encabezado TCP o UDP se eliminará cuando el resto del paquete se pase al proceso RTP. Por lo tanto, no tiene oportunidad de ver qué número de secuencia estaba usando TCP o UDP. Recuerde, el paquete está siendo formado por RTP primero, luego se pasa a TCP / UDP. RTP no tiene oportunidad de saber de antemano qué número de secuencia utilizará Layer-4.
  • Incluso si es posible, no solo copiaría el número de secuencia TCP o UDP. La forma en que TCP maneja el número de secuencia no es la forma en que RTP quiere que sea. En RTP, la secuencia aumenta en uno para cada contenido de datos. TCP maneja toda la numeración de manera bastante diferente. En RTP, el proceso de transmisión no se preocupa por la pérdida de paquetes, pero solo quiere detectarlo. El manejo se deja a la aplicación. Una aplicación de video puede repetir la última imagen en ausencia de un nuevo paquete, o una aplicación de audio puede generar un ruido de confort, etc. De hecho, no necesita algoritmos complejos para calcular el número de secuencia (como en TCP), solo necesita Una simple. Y en TCP, la diferencia entre dos paquetes consecutivos no es la misma en todos los casos, ajusta el tamaño de la ventana y la ventana de congestión y, por lo tanto, la diferencia numérica de dos paquetes consecutivos puede variar bastante. TCP conoce la longitud del paquete, etc. para manejarlo. Pero RTP no (como está en la capa superior).
  • La mayoría de los casos RTP se transfiere usando UDP, ya que tiene sus propias subcapas para manejar otras cosas como secuenciación, sincronización, etc. En el encabezado UDP no hay ningún número de secuencia …
  • La longitud de seq en el encabezado RTP es de 16 bits, donde TCP usa 32 bits.

Con todos los protocolos de red, tiene la posibilidad de pérdida de paquetes de datos o retrasos. Dos paquetes pueden tomar diferentes rutas de enrutamiento desde el origen a los destinos y pueden llegar fuera de servicio o no llegar. (paquete perdido)

En general, los números de secuencia TCP y RTP tienen los mismos propósitos básicos de detectar paquetes perdidos y ayudar a ordenar el flujo de paquetes en un mensaje coherente. Por razones de seguridad (ataques de inyección de paquetes), los protocolos comienzan con un valor inicial “aleatorio” y luego se incrementan en un patrón predecible. También es un gran lugar para ocultar puertas traseras de red / protocolo de nivel profundo.

Las diferencias entre los dos se vuelven importantes cuando considera los usos de los protocolos. TCP es un protocolo “sin pérdidas”. Si no se reciben paquetes (detectados por espacios de números de secuencia), el proceso hace una pausa / almacenamientos intermedios y luego solicita nuevamente el paquete al remitente. El subprocesamiento múltiple puede disminuir la demora, pero en última instancia, necesita el “mensaje completo en orden” para continuar. Estos retrasos de menos de un segundo pueden sumarse y dar lugar a retrasos notables. Esta es la razón por la cual TCP no se usa generalmente para transmisión “en tiempo real”. (películas, VOIP, HFT, etc.)

RTP utiliza un sistema “sin estado” más flexible. En algunas configuraciones, se ejecuta sobre el protocolo UDP. Su principal ventaja sobre TCP es que es mucho más rápido y más tolerante a alguna pérdida de paquetes. Hay una cierta cantidad de “superposición de datos” en los paquetes RTP. En el caso de que se pierda el paquete, es posible usar los números de secuencia RTP y las marcas de tiempo de los paquetes recibidos previamente para deducir / adivinar de manera determinista la carga útil faltante. El proceso no es perfecto pero, por lo general, es lo suficientemente bueno. Es por eso que el video transmitido puede aparecer un poco apagado durante la congestión de la red. Su dispositivo también puede ralentizarse un poco debido al aumento repentino del drenaje de cómputo al tratar de calcular estos valores.

More Interesting

¿Por qué las capas de sesión, presentación y aplicación en el modelo OSI se combinan en una sola capa de aplicación en el modelo de Internet?

¿Cómo se distribuyen las IP?

TCP / IP: ¿Cuál es la forma correcta de transferir datos? Comprimir los datos cifrados o cifrar los datos comprimidos?

¿Qué dispositivos serían más adecuados para usar con una dirección IP estática? ¿Qué dispositivos serían más adecuados para usar con una dirección IP dinámica?

Si estoy creando una aplicación de Android para comunicarme con un robot (Linux + Python) a través de TCP, ¿la aplicación debería ser el servidor o el cliente, y por qué?

Cómo obtener una dirección IP de Nueva York para siempre

¿Vale la pena aprender programación de sockets?

¿Un enrutador tendrá que convertir los bits que recibe del cable en paquetes significativos?

¿Cuáles son las funciones de 7 capas del modelo de referencia OSI?

¿Cómo mide el proveedor de servicios de Internet nuestro uso de Internet?

Cómo hacer que Linux deje de enviar redireccionamientos IPv6 ICMP

¿Puede ser arrestado solo por su dirección IP?

A diferencia de ICMP traceroute, estos paquetes UDP no tienen un número de secuencia que pueda usarse para hacer coincidir el error ICMP con la solicitud original correspondiente. ¿Qué campo se usa para hacer coincidir una solicitud con una respuesta en este caso?

¿Cuál es la estructura o el formato de un paquete ARP?

Para el backend de una aplicación, ¿debería usar un servidor web http y un servidor de aplicaciones TCP o eliminar la capa del servidor de aplicaciones y hablar directamente con el servidor de actores Akka que maneja la lógica?