Pregunta

Si tiene una situación en la que una conexión TCP es potencialmente demasiado lenta y una 'conexión' UDP es potencialmente demasiado poco confiable, ¿qué utiliza?Existen varios protocolos UDP estándar confiables, ¿qué experiencias tiene con ellos?

Analice un protocolo por respuesta y, si alguien más ya ha mencionado el que usted utiliza, considere votarlo y utilizar un comentario para dar más detalles si es necesario.

Estoy interesado en las diversas opciones aquí, de las cuales TCP está en un extremo de la escala y UDP en el otro.Hay varias opciones UDP confiables disponibles y cada una trae algunos elementos de TCP a UDP.

Sé que a menudo TCP es la opción correcta, pero tener una lista de alternativas suele ser útil para llegar a esa conclusión.Cosas como Enet, RUDP, etc. que se basan en UDP tienen varias ventajas y desventajas. ¿Las ha utilizado? ¿Cuáles son sus experiencias?

Para evitar dudas, no hay más información, esta es una pregunta hipotética y esperaba que provocara una lista de respuestas que detallaran las diversas opciones y alternativas disponibles para alguien que necesita tomar una decisión.

¿Fue útil?

Solución

Es difícil responder a esta pregunta sin información adicional sobre el dominio del problema.Por ejemplo, ¿qué volumen de datos estás utilizando?¿Con qué frecuencia?¿Cuál es la naturaleza de los datos?(p.ej.¿Son datos únicos y únicos?¿O es un flujo de datos de muestra?etc.) ¿Para qué plataforma está desarrollando?(p.ej.escritorio/servidor/incrustado) Para determinar lo que quiere decir con "demasiado lento", ¿qué medio de red está utilizando?

Pero en términos (¡muy!) generales, creo que tendrás que esforzarte mucho para superar a TCP en velocidad, a menos que puedas hacer algunas suposiciones concretas sobre los datos que estás intentando enviar.

Por ejemplo, si los datos que intenta enviar son tales que puede tolerar la pérdida de un solo paquete (p. ej.datos muestreados regularmente donde la frecuencia de muestreo es muchas veces mayor que el ancho de banda de la señal), entonces probablemente pueda sacrificar cierta confiabilidad de la transmisión asegurándose de que puede detectar la corrupción de datos (p. ej.mediante el uso de un buen crc)

Pero si no puede tolerar la pérdida de un solo paquete, entonces tendrá que comenzar a introducir los tipos de técnicas de confiabilidad que ya tiene TCP.Y, sin realizar una cantidad razonable de trabajo, es posible que esté comenzando a incorporar esos elementos en una solución de espacio de usuario con todos los problemas de velocidad inherentes que conlleva.

Otros consejos

Qué pasa SCTP.Es un protocolo estándar del IETF (RFC 4960)

Tiene capacidad de fragmentación que podría ayudar a aumentar la velocidad.

Actualizar:a comparación entre TCP y SCTP muestra que las prestaciones son comparables a menos que se puedan utilizar dos interfaces.

Actualizar:a buen artículo introductorio.

ENET- http://enet.bespin.org/

Trabajé con ENET como un protocolo UDP confiable y escribí una versión compatible con sockets asíncronos para un cliente mío que lo usa en sus servidores.Funciona bastante bien, pero no me gusta la sobrecarga que el ping de igual a igual agrega a conexiones que de otro modo estarían inactivas;cuando tienes muchas conexiones, hacer ping a todas ellas regularmente es un trabajo muy intenso.

ENET le brinda la opción de enviar múltiples 'canales' de datos y que los datos enviados no sean confiables, confiables o estén secuenciados.También incluye el ping de igual a igual antes mencionado que actúa como un sistema de mantenimiento de la actividad.

Tenemos algunos clientes de la industria de defensa que utilizan UDT (transferencia de datos basada en UDP) (consulte http://udt.sourceforge.net/) y estamos muy contentos con ello.Veo que también tiene una licencia BSD amigable.

RUDP - Protocolo de datagramas de usuario confiable

Esto proporciona:

  • Acuse de recibo de paquetes recibidos
  • Control de ventanas y congestión
  • Retransmisión de paquetes perdidos
  • Overbuffering (más rápido que la transmisión en tiempo real)

Parece un poco más configurable con respecto a mantener vivos que ENet, pero no ofrece tantas opciones (es decir,todos los datos son confiables y están secuenciados, no solo los bits que usted decide que deben estarlo).Parece bastante sencillo de implementar.

Como otros han señalado, su pregunta es muy general y si algo es "más rápido" que TCP depende en gran medida del tipo de aplicación.

TCP es generalmente lo más rápido posible para la transmisión confiable de datos de un host a otro.Sin embargo, si su aplicación realiza muchas ráfagas pequeñas de tráfico y espera respuestas, UDP puede ser más apropiado para minimizar la latencia.

Hay un término medio fácil. algoritmo de nagle es la parte de TCP que ayuda a garantizar que el remitente no abrume al receptor con un gran flujo de datos, lo que resulta en congestión y pérdida de paquetes.

Si necesita la entrega confiable y ordenada de TCP, y también la respuesta rápida de UDP, y no necesita preocuparse por la congestión al enviar grandes flujos de datos, puede desactivar el algoritmo de Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Cualquiera que decida que la lista anterior no es suficiente y que quiere desarrollar su PROPIO UDP confiable definitivamente debería echar un vistazo a la especificación QUIC de Google, ya que cubre muchos casos complicados y posibles ataques de denegación de servicio.Todavía no he probado una implementación de esto y es posible que no quieras o necesites todo lo que proporciona, pero vale la pena leer el documento antes de embarcarte en un nuevo diseño UDP "confiable".

Un buen punto de partida para QUIC es aquí, en el Blog de Chromium.

El documento de diseño QUIC actual se puede encontrar aquí.

Si tiene una situación en la que una conexión TCP es potencialmente demasiado lenta y una 'conexión' UDP es potencialmente demasiado poco confiable, ¿qué utiliza?Existen varios protocolos UDP estándar confiables, ¿qué experiencias tiene con ellos?

La palabra clave en su oración es "potencialmente".Creo que realmente necesitas demostrarte a ti mismo que TCP es, de hecho, demasiado lento para tus necesidades si necesitas confiabilidad en tu protocolo.

Si desea obtener confiabilidad de UDP, básicamente volverá a implementar algunas de las características de TCP además de UDP, lo que probablemente hará que las cosas sean más lentas que simplemente usar TCP en primer lugar.

Protocolo DCCP, estandarizado en RFC 4340, "Protocolo de control de congestión de datagramas" puede ser lo que está buscando.

Parece implementado en Linux.

Tal vez RFC 5405, "Pautas de uso de Unicast UDP para diseñadores de aplicaciones" le resultarán útiles.

¿Consideró comprimir sus datos?

Como se indicó anteriormente, carecemos de información sobre la naturaleza exacta de su problema, pero comprimir los datos para transportarlos podría ayudar.

RUDP.Muchos servidores de socket para juegos implementan algo similar.

La mejor manera de lograr confiabilidad usando UDP es construir la confiabilidad en el propio programa de aplicación (por ejemplo, agregando mecanismos de reconocimiento y retransmisión).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top