2008-12-12 17 views
26

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.¿Por qué RTP usa UDP en lugar de TCP?

+0

¿Por qué UDP se usa en RTP pero no en TCP? Suena como una pregunta incorrecta. -> ¿Por qué RTP usa UDP en lugar de TCP? –

+0

Gracias ahora corregido :) – mahesh

+0

¿Qué tal "me gustaría saber por qué se usa UDP en RTP pero por qué TCP no?"? ¿Eso podría estar más cerca de lo que quieres decir? –

Respuesta

50

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

VOIP no se mejora significativamente con la transmisión confiable de paquetes, y de hecho, en algunos casos, 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.

+5

Me gustaría señalar que UDP proporciona una suma de comprobación en el paquete. Entonces, si recibes un mensaje UDP, es lo que se envió. Pero si fue malo, se descarta, su aplicación no lo verá. TCP le pediría al otro extremo retransmitir. Hay situaciones en las que TCP no siempre es el más eficiente (por ejemplo, transmitir el mismo archivo a múltiples destinos) y, por lo tanto, algunos protocolos de nivel de aplicación se crean sobre UDP. – Matt

+1

UDP es una mejor opción si su red no garantiza el orden de entrega o la transmisión. Esta ventaja debe ser compensada por el jitter-buffer para reordenar paquetes y, a veces, para interpolarlos. –

3

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.

2

RTP es bastante insensible a la pérdida de paquetes, por lo que no requiere la fiabilidad de TCP.

UDP tiene menos sobrecarga para los encabezados, de modo 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 también proporciona transmisión de datos rápida.

Así que UDP es la opción obvia en casos como este.

0

UDP se utiliza dondequiera 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 utiliza si los datos se deben recibir exactamente, bit a bit, sin pérdida de bits.

Para transmisión de video y sonido, algunos bits que se pierden en el camino no afectan el resultado de una manera, es posible mencionar algunos píxeles que fallan en una imagen de una secuencia, nada que afecte a un usuario, en DVD la tasa de bit perdida es más alta.

19

les ha dado un montón de buenas respuestas, pero me gustaría señalar una cosa explícitamente:

Básicamente un flujo de datos completa es una cosa agradable para tener en tiempo real de audio/vídeo, pero su no estrictamente necesario (como han señalado otros):

Lo 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: tiene 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, ya que intenta transferir todos los datos disponibles a tiempo, pero no intenta retransmitir los datos que se perdieron/dañaron 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).

+1

le gustó su 3er párrafo "Si usa TCP ..." :) :) – mahesh

+0

TCP ¿Nunca aceptará ningún dato perdido? ... ¿Alguna vez ha falsificado un paquete TCP o usado WiFi con poca cobertura? – Jay

+0

@Jay: lo que quiero decir es que si el paquete 1 se elimina en algún lugar y el paquete 2 aparece, entonces la aplicación del usuario nunca verá los datos del paquete 2 hasta que el paquete 1 se retransmita correctamente. Y eso es en realidad parte de por qué el TCP sobre conexiones deficientes es tan doloroso. –

1

Además de todas las otras respuestas agradables y correctas this article da una buena comprensión acerca de las diferencias entre TCP y UDP.

+0

Gracias mlarsen. Me gustó el enlace :) – mahesh

+0

Enlace muerto. Ahora esta respuesta no es útil en absoluto. –

+0

El artículo ahora se puede encontrar aquí: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ – mbelow

11

Los otros son correctos, sin embargo, realmente no le 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 reproducirse, y eso causa que se retrasen más datos, y luego otro error provoca 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 a partir de la retransmisión significa 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 con 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 errores de retransmisión de todos modos, ¿por qué molestarse con el gasto adicional?

+0

Me gustó la respuesta Mystere :) – mahesh

0

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.

0

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 el asterisco, por ejemplo, puede activar/desactivar las sumas de comprobación en su RTP sobre el tráfico UDP en el fichero de configuración rtp.conf con la siguiente línea:

rtpchecksums=yes ; or no if you prefer 

Salud!

5

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.

+0

+1 para que RTP pueda ejecutar TCP. Además, RTP sobre TCP puede presentar problemas de encuadre. RFC 4103, por ejemplo, no define su propio encuadre, por lo que si intenta ejecutarlo a través de TCP, deberá definir su propio protocolo de encuadre. –

Cuestiones relacionadas