¿Por qué UDP con confiabilidad (implementado en la capa de aplicación) no es un sustituto de TCP?

25

TCP proporciona confiabilidad en la capa de transporte, mientras que UDP no. Entonces, UDP es rápido. Pero, un protocolo en la capa de aplicación puede implementar un mecanismo confiable mientras se usa UDP.

En este sentido, ¿por qué UDP con confiabilidad (implementado en la capa de Aplicación) no es un sustituto de TCP en el caso de que UDP sea más rápido que TCP mientras necesitamos confiabilidad?

mallea
fuente
66
¿Por qué cada aplicación proporciona su propio mecanismo de confiabilidad cuando simplemente pueden confiar en otro protocolo ampliamente disponible como TCP?
Nakrule
14
¿Y cómo propone implementar la confiabilidad en la capa de aplicación sin ralentizar la pila?
JFL
66
" Dado que el encabezado UDP es más pequeño que el del TCP, podemos aprovechar el tamaño de los datos " . El problema con ese pensamiento es que probablemente comerá gran parte de la carga útil UDP con encabezados de protocolo de capa de aplicación que disminuirán los datos utilizables en el UDP carga útil. La diferencia entre el tamaño del encabezado TCP y UDP es de solo 12 bytes. Además, UDP está realmente diseñado para pequeñas cargas útiles, por ejemplo, 576 bytes; recuerde que UDP simplemente perderá datagramas, y cuantos más datos haya en un datagrama, más datos se perderán cuando se pierda un datagrama.
Ron Maupin
21
Stack Overflow está plagado de programadores que intentan, y no logran, crear protocolos similares a TCP utilizando UDP. Los programadores más experimentados les dicen que lo abandonen y que solo usen TCP. Todos piensan que pueden hacer un mejor trabajo, pero es muy poco probable.
Ron Maupin
11
Sé que esto no es parte de su pregunta directamente, pero una razón por la que UDP puede ser mejor es que puede implementar solo las partes de confiabilidad que necesita. Con TCP obtienes confiabilidad sobre pedidos y entregas. Esto significa que TCP puede tener problemas mientras espera a que se reenvíe un mensaje anterior. Con UDP, puede decidir que todo lo que desea es la entrega, pero si algún mensaje llega fuera de servicio, no espere a los que faltan, simplemente los descarta. El obstáculo al que se enfrentan las personas es tratar de replicar TCP al 100%. En ese caso, solo use TCP.
William Mariager

Respuestas:

47

TCP es casi tan rápido como puedes hacer algo con sus propiedades de confiabilidad. Si solo necesita, por ejemplo, secuenciación y detección de errores, UDP puede funcionar perfectamente. Esta es la base de la mayoría de los protocolos en tiempo real, como voz, transmisión de video, etc., donde el retraso y la fluctuación son más importantes que la corrección de errores "absoluta".

Fundamentalmente, TCP dice que eventualmente se puede confiar en sus flujos. La rapidez con que depende depende de los distintos temporizadores, velocidades, etc. El tiempo necesario para resolver errores puede ser impredecible, pero las operaciones básicas son tan rápidas como sea posible cuando no hay errores. Si un sistema sabe algo sobre los tipos de errores que son probables, podría hacer algo que no es posible con TCP. Por ejemplo, si los errores de un solo bit son especialmente probables, puede usar la codificación de corrección de errores para esos errores de bits: sin embargo, esto se implementa mucho mejor en la capa de enlace. Como otro ejemplo, si las ráfagas cortas de pérdida de paquetes completos son comunes, puede abordar esto con transmisión múltiple sin esperar la pérdida, pero obviamente esto es costoso en ancho de banda. O, alternativamente, reduzca la velocidad hasta que la probabilidad de error sea insignificante: también costoso en ancho de banda. En el final,

En términos de implementación, descubrirá que los siglos de programador invertidos en TCP lo harán más rápido que cualquier cosa general que pueda permitirse, así como más confiable en los oscuros casos extremos.

TCP proporciona: un método ubicuo de conexión (esencial cuando los sistemas de comunicación no tienen un control común) que proporciona un flujo de bytes confiable, ordenado (y deduplicado), bidireccional, en ventana, con control de congestión en redes de salto múltiple de distancia arbitraria.

Si una aplicación no requiere ubicuidad (su software se ejecuta en ambos lados), o no necesita todas las características de TCP, muchas personas utilizan de manera rentable otros protocolos, a menudo además de UDP. Los ejemplos incluyen TFTP (minimalista, con manejo de errores realmente ineficiente, QUIC, que está diseñado para reducir los gastos generales (todavía marcado como experimental), y bibliotecas como lidgren, que tiene un control detallado sobre qué características de confiabilidad se requieren. [Gracias comentadores. ]

jonathanjo
fuente
77
Los protocolos personalizados "UDP con fiabilidad" también son extremadamente comunes en los videojuegos. Hay un montón de bibliotecas de redes con diversas implementaciones. Por lo general, desean que se ordenen los paquetes y tengan corrección de errores, sin querer retransmitir los paquetes perdidos (y recibir retrasos de todos los paquetes futuros).
BlueRaja - Danny Pflughoeft
Parece que estás diciendo "TCP es la solución general óptima, por lo que es compatible de forma nativa". +1
ikegami
1
@ BlueRaja-DannyPflughoeft Y a veces quieres paquetes confiables sin ordenar (por ejemplo, efectos visuales aplicados a jugadores cercanos).
user253751
@ BlueRaja-DannyPflughoeft si tiene una biblioteca de protocolos de ejemplo típica, estaré encantado de incorporarla a la respuesta
jonathanjo
1
@jonathanjo Uno que he usado es lidgren , que admite 5 métodos de entrega diferentes (desplácese hasta la parte inferior) . Unity y Unreal Engine también tienen sus propias API de red que se crean sobre UDP.
BlueRaja - Danny Pflughoeft
10

UDP con confiabilidad puede ser un sustituto de TCP. Ya tenemos un ejemplo: se llama QUIC .

De Wikipedia:

Entre otras aplicaciones, QUIC mejora el rendimiento de las aplicaciones web orientadas a la conexión que actualmente utilizan TCP. Lo hace estableciendo una serie de conexiones multiplexadas entre dos puntos finales a través del Protocolo de datagramas de usuario (UDP).

La ventaja de usar UDP en lugar de crear un nuevo protocolo de capa de transporte es que los enrutadores y otros dispositivos de red ya lo entienden.

Andrea Corbellini
fuente
QUIC tiene una característica un poco diferente de TCP. En algunos escenarios (red confiable o no encriptación es necesario) que en realidad es más lento: quora.com/...
estrafalario
También puede agregar canales de datos WebRTC a la lista que usa UDP a través de sctp. De hecho, cuando las conexiones UDP no son posibles entre pares, WebRTC fallará a TCP dejando una notable caída en el rendimiento.
JSON
@freakish slower es una generalización en este caso. Por ejemplo, QUIC agrega datos adicionales a los paquetes para reducir la retransmisión que afecta el rendimiento pero no la latencia.
JSON
4

Puede usar UDP para implementar la funcionalidad TCP en la capa de aplicación (confiabilidad, adaptabilidad). En primer lugar, también podría usar TCP a menos que algo que su aplicación realmente necesita no se pueda hacer con TCP. Si implementa esas funciones usted mismo, probablemente terminará mucho peor que con TCP. La sobrecarga adicional también disminuye la eficiencia general.

TCP no es lento, solo requiere un apretón de manos antes de transmitir y la ventana de transmisión para adaptarse al canal. Puede muy bien dar forma a su rendimiento en el canal de transmisión en cuestión y adaptarse a los cambios durante el flujo, todo lo cual UDP no puede hacer (por sí solo).

Sin embargo, los protocolos por encima de la capa de transporte están fuera de tema aquí.

Zac67
fuente
3
"Se podría usar UDP para implementar la funcionalidad TCP en la capa de aplicación (confiabilidad, adaptabilidad)". Creo que así es como prácticamente se implementan QUIC, µTP y, a menudo, SCTP. (A pesar de eso, generalmente los considero como en la mitad superior de la capa de transporte, mientras que UDP se encuentra en la mitad inferior.)
Grawity
1
@grawity Eso depende de su POV: desde la perspectiva de la aplicación, una capa intermedia es una extensión de la capa de transporte. Formalmente y desde la perspectiva de la red (dispositivo), todo es parte de la capa de aplicación.
Zac67
4

En una red limpia son bastante equivalentes. Hay casos en los que TCP se cuelga por períodos (¿Alguien ha visto una pantalla HTTP congelada al cargarse?) Pero no entregará basura ni mezclará paquetes y rara vez se rinde por completo.

UDP puede dar a la capa de aplicación más control sobre el tráfico a costa de una gran cantidad de trabajo.

La respuesta a su pregunta es, a veces se hace de esa manera. Los juegos que requieren baja latencia a menudo hacen exactamente eso. Es mucho más trabajo, pero la capacidad de controlar exactamente cuántos paquetes pendientes puede tener y con qué frecuencia se vuelven a probar a menudo vale la pena.

Entonces, en general, la diferencia es que TCP es una muy buena implementación de propósito general, pero hay propósitos específicos que UDP puede hacer que TCP haga muy mal o no haga nada, por ejemplo:

  • NUNCA te rindas (con TCP la conexión a veces se cuelga y tienes que romper la conexión y reiniciarla)
  • Enviar un flujo rápido de paquetes que no requieren respuestas y no le importa perderlos ocasionalmente (donde solo el paquete más reciente es importante, cualquier otro puede descartarse) - piense en las actualizaciones de posición del juego - puede obtener un poco "Salta" en lugar de cada paso, pero obtienes el mismo resultado más rápido y más confiable.
  • Tratar las redes dudosas analizando las caídas de paquetes y alterando dinámicamente la frecuencia y la rapidez con la que vuelve a intentarlo, tal vez incluso el tamaño máximo del paquete.

Pero en general no vale la pena, TCP es bastante óptimo, entonces ¿por qué hacer todo el trabajo extra y agregar una (gran) posibilidad de agregar errores y fallas de seguridad?

Bill K
fuente
3

UDP no es rápido porque es UDP. TCP no es lento porque es TCP.

Ambos protocolos están diseñados con ciertas garantías y el TCP sin formato tiene más garantías que el UDP sin formato.

Y la regla general es: el precio de las garantías es el rendimiento .

No hay nada que le prohíba implementar garantías TCP sobre UDP. Pero luego obtienes más garantías y tienes que pagar el precio. Por lo tanto, reduce el rendimiento a TCP o peor (debido a la sobrecarga UDP). A menos que conozca una mejor implementación de TCP, lo cual es poco probable. Y si lo hace entonces (con suerte) lo revela y hacemos que el TCP estándar sea más rápido. Y estamos de vuelta donde empezamos. :)

Puedes jugar con esas garantías también. Modifique ligeramente esto, modifique ligeramente eso. Y luego terminas con un protocolo como QUIC que está sobre UDP y es muy similar a TCP + TLS. En muchos casos es más rápido que TCP (aunque según este artículo, latencia de hasta 5% y almacenamiento en búfer de hasta 15%, lo que IMO no es un gran problema), pero en algunos escenarios (por ejemplo, red confiable o sin necesidad de cifrado) en realidad es más lento (vea una explicación aquí ).

También puede debilitar esas garantías y luego tiene más sentido. Por ejemplo, digamos que está transmitiendo y los paquetes antiguos no son interesantes. Solo lo más reciente. Pero la congestión sigue siendo importante. Entonces toma algunas garantías de TCP, pero no todas. Y sí, la gente realmente hace eso (por ejemplo, juegos en tiempo real). Esto le brinda un mejor rendimiento a costa de algunas garantías.

monstruoso
fuente
1

Tu idea sería buena en el espacio profundo.

La respuesta correcta es "depende" y "porque eso dañaría la red en su conjunto". TCP / IP es muy amable con las redes y se ajusta automáticamente a la velocidad adecuada para ser rápido pero no generar toneladas de paquetes de devolución ICMP.

Cuando un enrutador con poca RAM recibe repentinamente una gran cantidad de cualquier tipo de paquete, digamos de Tsunami, Bittorrent o FDT, lo deja caer y dispara al remitente un pequeño paquete de reconocimiento de fallas. Ahora su servidor UDP tiene que rastrear y retransmitir esa parte manualmente. Algunos enrutadores ISP dan forma a Bittorrent, ¿tanto que esto perjudica al Tsunami?

El protocolo Tsunami usa UDP con un canal de control en TCP. http://tsunami-udp.sourceforge.net/ Encontré un estudio que muestra que es más lento que una cosa llamada FDT.

El legendario protocolo de transferencia rápida de datos (FDT) de CERN es capaz de saturar cualquier red utilizando múltiples flujos TCP. Probablemente sea más rápido, ya que causa menos retransmisiones que el tsunami, que inunda la red con tanta UDP, parte de la cual no llega hasta el final.

UDP es utilizado por aplicaciones poco confiables: transmisión de audio, entrada / actualización de juegos IO, "ping" es en realidad ICMP pero no está garantizado, Bittorrent, mosh ssh es increíblemente sensible, telefonía VOIP, multidifusión, DNS se envía a través de UDP AFAIK. Cualquier cosa que no le importe el extraño paquete que falta y puede "ponerse al día" al instante.

TCP / IP fue realmente la invención asesina que permitió a los desarrolladores de aplicaciones, así que solo configúrelo y olvídese. Un socket es un par de puertos y direcciones IP, y fueron diseñados para poder configurarse y permanecer durante horas, días e incluso semanas sin volver a conectarse. Correo electrónico, web, IRC y, literalmente, todas las aplicaciones asesinas usan TCP. Pero puede obtener pausas extrañas en la descarga que de repente se aceleran ... y en el espacio profundo las conexiones pueden agotar el tiempo, lo que hace que las transferencias al estilo Tsunami sean las mejores para las transferencias de archivos interestelares: ¡podría encontrar algo allí!

La prueba está en los comentarios finales de este extracto de estudio de ciencias, que mencionan la distancia cada vez mayor que estoy haciendo sobre el espacio profundo. Https://uscholar.univie.ac.at/get/o:300623.pdf

Sin congestión, el rendimiento de FDT y GridFTP con TCP es más alto que Tsunami y UDT. El rendimiento más alto de FDT es 2,34 Gb / s con un RTT de 1 ms, pero disminuye rápidamente después de 100 ms en comparación con GridFTP, que funciona mejor que FDT cuando el RTT de enlace es más largo de 100 ms. Curiosamente, el rendimiento del tsunami no disminuyó con el aumento de RTT, lo que demuestra que tiene el control de congestión más efectivo con el aumento de RTT.

Por otra parte ... en realidad hay un protocolo espacial que se parece mucho al correo electrónico que sería mejor para el espacio. Las aplicaciones no tienen que preocuparse por los valores de tiempo de espera como siempre.

Tomachi
fuente
0

TCP! = UDP + Fiabilidad

TCP no es simplemente UDP con confiabilidad adicional. TCP ofrece más funciones que solo confiabilidad. Puede leer sobre ellos en muchos de los RFC.

Cualquiera de estas características "podría" implementarse en la capa de aplicación. Finalmente, se convierte en un punto en el que comienzas a reinventar la rueda.

Para nombrar algunas características TCP tiene ...

  • Creación y terminación de conexiones: realiza apretones de manos y cierres de conexiones

  • Control de flujo: garantiza que el emisor y el receptor transmitan a velocidades donde ambos pueden manejar la velocidad de datos.

  • Control de congestión de extremo a extremo: permite que los nodos finales aceleren su rendimiento en función de las pérdidas. Lea sobre el inicio lento, evitar la congestión y la recuperación rápida.

En mi experiencia, UDP se usa cuando la velocidad es una preocupación sobre la confiabilidad. Puede agregar algún nivel de confiabilidad a nivel de aplicación que no sea 100% tan confiable como TCP. Por ejemplo, si aún desea un rendimiento rápido, puede implementar la corrección de errores de reenvío (FEC) donde transmite los datos más de una vez. Todavía obtiene un buen rendimiento y cierto nivel de confiabilidad (tenga en cuenta la confiabilidad de TCP bastante) sin todo el chat chit de ida y vuelta para obtener paquetes perdidos. El oficio es que aumenta la utilización de la red, pero puede ser adecuado para aplicaciones en tiempo real como juegos o streaming.

Jaybers
fuente
Podría describir esas características adicionales como una cuestión de confiabilidad, en última instancia.
user207421