networking - protocolo - ¿Por qué RTP usa UDP en lugar de TCP?
protocolo rtp (10)
Además de todas las otras respuestas agradables y correctas, este artículo proporciona una buena comprensión de las diferencias entre TCP y UDP.
Quería saber por qué UDP se usa en RTP en lugar de TCP? Las principales herramientas de VoIP solo usaban UDP ya que pirateé algunos de los OSS de VoIP.
Como señaló DJ, TCP trata de obtener un flujo de datos confiable, ralentizará la transmisión y retransmitirá los paquetes dañados para lograr eso.
UDP no se preocupa por la confiabilidad de la comunicación, y no ralentizará ni retransmitirá datos.
Si su aplicación necesita un flujo de datos confiable, por ejemplo, para recuperar un archivo de un servidor web, usted elige TCP.
Si a su aplicación no le preocupan los paquetes dañados o perdidos, y no necesita incurrir en la sobrecarga adicional para proporcionar la confiabilidad adicional, puede elegir UDP en su lugar.
El VOIP no se mejora significativamente con la transmisión confiable de paquetes, y de hecho, en algunos casos, las cosas en TCP como la retransmisión y el retroceso exponencial en realidad pueden dañar la calidad de VOIP. Por lo tanto, UDP fue una mejor opción.
Los otros son correctos, sin embargo, realmente no te dicen la razón REAL por qué. Saua lo insinúa, pero aquí hay una respuesta más completa.
Audio y video es en tiempo real. Si está escuchando una radio o viendo televisión, y la señal se interrumpe, no se reanuda donde lo dejó. Simplemente está "observando" la señal mientras se transmite, y si no puede observar en un momento dado, lo pierdes.
La razón, es simple. Retrasar. VOIP intenta mucho para minimizar la cantidad de retraso desde el momento en que alguien habla en un extremo y lo obtiene de su lado, y su respuesta vuelve. De lo contrario, a medida que ocurran los errores, la cantidad de retraso entre el momento en que la persona habló y el momento en que se recibió la señal aumentaría continuamente hasta que se volviera inútil.
Recuerde, cada retraso de una retransmisión tiene que volver a reproducirse, y eso causa que se retrasen más datos, y luego otro error causa un retraso aún mayor. La única solución factible es simplemente colocar cualquier información que no se pueda mostrar en tiempo real.
Un retraso de 1 segundo de la retransmisión significaría que ahora sería 1 segundo desde el momento en que dije algo hasta que lo escuchó. Un segundo retraso de 1 segundo significa que son 2 segundos desde el momento en que digo algo hasta que lo escuchas. Esto es acumulativo porque los datos se reproducen a la misma velocidad a la que se habla, y así sucesivamente ...
RTP podría estar orientado a la conexión, pero luego tendría que eliminar (u omitir) los datos para mantenerse al día con los errores de retransmisión, así que ¿para qué molestarse con los gastos generales extra?
Me gustaría agregar rápidamente lo que Matt H dijo en respuesta a la respuesta de Stobor. Matt H mencionó que los paquetes RTP sobre UDP pueden ser sumados para que, si están corruptos, se vuelvan a enviar. Esta es una función opcional en la mayoría de las PBX. En Asterisk, por ejemplo, puede habilitar / deshabilitar sumas de comprobación en el tráfico RTP sobre UDP en el archivo de configuración rtp.conf con la siguiente línea:
rtpchecksums=yes ; or no if you prefer
¡Aclamaciones!
RTP es bastante insensible a la pérdida de paquetes, por lo que no requiere la fiabilidad de TCP.
El UDP tiene menos sobrecarga para los encabezados, por lo que un paquete puede transportar más datos, por lo que el ancho de banda de la red se utiliza de manera más eficiente.
UDP proporciona una transmisión de datos rápida también.
Entonces UDP es la opción obvia en casos como este.
Se han dado muchas buenas respuestas, pero me gustaría señalar una cosa explícitamente:
Básicamente, es bueno tener una transmisión de datos completa para el audio / video en tiempo real, pero no es estrictamente necesario (como otros han señalado):
El hecho importante es que algunos datos que llegan demasiado tarde no tienen valor. ¿De qué sirve la información faltante para un cuadro que debería haberse mostrado hace un segundo?
Si usara TCP (que también garantiza el orden correcto de todos los datos), no podrá acceder a los datos más actualizados hasta que el anterior se transmita correctamente. Esto es doblemente malo: tienes que esperar a la retransmisión de los datos anteriores y los nuevos datos (que ahora están retrasados) probablemente sean tan inútiles.
Por lo tanto, RTP realiza algún tipo de transmisión de mejor esfuerzo en el sentido de que intenta transferir todos los datos disponibles a tiempo, pero no intenta retransmitir los datos que se perdieron o se corrompieron durante la transferencia (*). Simplemente continúa con la vida y espera que los datos actuales más importantes lleguen correctamente.
(*) en realidad no conozco los detalles de RTP. Tal vez trate de retransmitir, pero si lo hace, entonces no será tan agresivo como TCP (que nunca aceptará ningún dato perdido).
Técnicamente, los paquetes RTP se pueden intercalar a través de una conexión TCP. Aquí hay muchas respuestas excelentes. Dos puntos menores adicionales:
RFC 4588 describe cómo se podría usar la retransmisión con datos RTP. La mayoría de los clientes que reciben transmisiones RTP emplean un búfer para dar cuenta de la inestabilidad en la red que suele durar de 1 a 5 segundos, lo que significa que hay tiempo disponible para que una retransmisión reciba los datos deseados.
El tráfico RTP se puede intercalar a través de una conexión TCP. En la práctica, cuando se hace esto, la diferencia entre el RTP entrelazado (es decir, sobre TCP) y el RTP enviado a través de UDP es la forma en que estos dos funcionan sobre una red con pérdida con ancho de banda insuficiente disponible para el usuario. La secuencia de TCP Intercalado terminará siendo desigual ya que el jugador espera continuamente en un estado de almacenamiento en búfer para que lleguen los paquetes. Dependiendo del jugador, puede saltar para ponerse al día. Con una conexión RTP obtendrás artefactos (manchas / rasgaduras) en el video.
UDP se usa a menudo para varios tipos de tráfico en tiempo real que no necesita un orden estricto para ser útil. Esto se debe a que TCP impone un orden antes de pasar datos a una aplicación (de manera predeterminada, puede solucionar esto configurando el puntero URG, pero nadie parece hacer esto nunca) y eso puede ser altamente indeseable en un entorno en el que más bien obtenga datos actuales en tiempo real que obtener datos viejos de manera confiable.
UDP se usa donde sea que se envíen los datos, que no necesita ser recibido exactamente en el destino, o donde no se necesita una conexión estable.
TCP se usa si los datos se deben recibir exactamente, bit a bit, sin pérdida de bits.
Para la transmisión de video y sonido, algunos bits que se pierden en el camino no afectan el resultado de una manera, se puede mencionar, algunos píxeles fallan en una imagen de una transmisión, nada que afecte a un usuario, en DVD la velocidad de bits perdida es mayor.
solo una observación: cada paquete enviado en un flujo RTP recibe un número uno más alto que su predecesor. Esto permite que el destino determine si falta algún paquete. Si un paquete se extravía, la mejor acción para el destino es aproximar el vaue perdido por interpolación. La retransmisión no es una opción proctica ya que el paquete retransmitido sería demasiado tarde para ser útil.