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

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?

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

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.

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

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?

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.

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.

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.