sockets - tiene - puertos tcp y udp
¿Qué usas cuando necesitas un UDP confiable? (13)
Si tiene una situación donde una conexión TCP es potencialmente demasiado lenta y una ''conexión'' UDP es potencialmente poco confiable, ¿qué usa? Existen varios protocolos UDP estándar confiables, ¿qué experiencias tienes con ellos?
La palabra clave en tu oración es ''potencialmente''. Creo que realmente necesita demostrarse a sí mismo que TCP es, de hecho, demasiado lento para sus necesidades si necesita confiabilidad en su protocolo.
Si desea obtener confiabilidad de UDP, básicamente va a volver a implementar algunas de las características de TCP sobre UDP, lo que probablemente hará que las cosas sean más lentas que solo usar TCP en primer lugar.
Si tiene una situación donde una conexión TCP es potencialmente demasiado lenta y una ''conexión'' UDP es potencialmente poco confiable, ¿qué usa? Existen varios protocolos UDP estándar confiables, ¿qué experiencias tienes con ellos?
Discuta un protocolo por respuesta y si alguien más ya ha mencionado el que usa, considere la posibilidad de votar y usar un comentario para elaborar 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. Varias opciones de UDP confiables están disponibles y cada una trae algunos elementos de TCP a UDP.
Sé que a menudo el TCP es la elección correcta, pero tener una lista de alternativas a menudo es útil para ayudar a llegar a esa conclusión. Cosas como Enet, RUDP, etc. que se basan en UDP tienen varios pros y contras, ¿los has usado? ¿Cuáles son tus experiencias?
Para evitar dudas no hay más información, esta es una pregunta hipotética y esperaba generar una lista de respuestas que detallaran las diversas opciones y alternativas disponibles para alguien que necesita tomar una decisión.
¿Consideró comprimir sus datos?
Como se indicó anteriormente, carecemos de información sobre la naturaleza exacta de su problema, pero la compresión de los datos para transportarlos podría ayudar.
¿Qué hay de SCTP ? Es un protocolo estándar de IETF (RFC 4960)
Tiene capacidad de fragmentación que podría ayudar a acelerar.
Actualización: una comparación entre TCP y SCTP muestra que los rendimientos son comparables a menos que se puedan usar dos interfaces.
Actualización: un buen artículo introductorio .
Como han señalado otros, su pregunta es muy general, y si algo es o no "más rápido" que TCP depende mucho del tipo de aplicación.
Por lo general, TCP es lo más rápido posible para la transmisión confiable de datos de un host a otro. Sin embargo, si su aplicación hace muchas ráfagas pequeñas de tráfico y espera respuestas, UDP puede ser más apropiado para minimizar la latencia.
Hay un punto medio fácil. El algoritmo de Nagle es la parte de TCP que ayuda a garantizar que el emisor no abrume al receptor de una gran cantidad de datos, lo que da como resultado la congestión y la pérdida de paquetes.
Si necesita la entrega fiable y ordenada de TCP, y también la respuesta rápida de UDP, y no tiene que preocuparse de que la congestión envíe 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 echarle un vistazo a la especificación QUIC de Google, ya que cubre muchos casos de esquina complicados y posibles ataques de denegación de servicio. Todavía no he jugado con una implementación de esto, y es posible que no desee o no necesite todo lo que proporciona, pero vale la pena leer el documento antes de embarcarse en un nuevo diseño UDP "confiable".
Un buen punto de partida para QUIC está here , en el blog Chromium.
El documento de diseño actual de QUIC se puede encontrar here .
He trabajado con ENET como un protocolo confiable de UDP y he escrito una versión asíncrona de sockets amigable para un cliente mío que lo está utilizando en sus servidores. Funciona bastante bien, pero no me gusta la sobrecarga que el ping punto a punto agrega a conexiones inactivas; Cuando tienes muchas conexiones haciendo ping a todos ellos con regularidad, hay mucho trabajo ocupado.
ENET le brinda la opción de enviar múltiples ''canales'' de datos y de que los datos enviados no sean fiables, confiables o estén secuenciados. También incluye el ping peer to peer antes mencionado que actúa como un mantener vivo.
El protocolo DCCP, estandarizado en RFC 4340 , "Protocolo de control de congestión de Datagram" puede ser lo que está buscando.
Parece implementado en Linux .
Es difícil responder a esta pregunta sin información adicional sobre el dominio del problema. Por ejemplo, ¿qué volumen de datos está usando? ¿Con qué frecuencia? ¿Cuál es la naturaleza de los datos? (por ej., ¿es único, uno solo de los datos? ¿O es una secuencia de datos de muestra? etc.) ¿Para qué plataforma está desarrollando? (por ejemplo, desktop / server / embedded) Para determinar qué quiere decir con "demasiado lento", ¿qué medio de red está usando?
Pero en (¡muy!) Términos generales, creo que vas a tener que esforzarte mucho para superar la velocidad de tcp, a menos que puedas hacer algunas suposiciones difíciles sobre los datos que estás tratando de enviar.
Por ejemplo, si los datos que está tratando de enviar son tales que puede tolerar la pérdida de un paquete único (por ejemplo, los datos muestreados regularmente donde la frecuencia de muestreo es mucho mayor que el ancho de banda de la señal), entonces probablemente pueda sacrifique algo de confiabilidad de transmisión asegurándose de que puede detectar corrupción de datos (por ejemplo, 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 poner una cantidad razonable de trabajo, es posible que descubra que está comenzando a construir esos elementos en una solución de espacio de usuario con todos los problemas de velocidad inherentes.
La mejor manera de lograr la confiabilidad mediante UDP es construir la confiabilidad en el propio programa de aplicación (por ejemplo, agregando mecanismos de reconocimiento y retransmisión)
Puede ser RFC 5405 , "Pautas de uso de Unicast UDP para diseñadores de aplicaciones" serán útiles para usted.
RUDP - Protocolo de datagrama de usuario confiable
Esto proporciona:
- Acuse de recibo de los paquetes recibidos
- Ventana y control de 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 Keep Alive y luego a ENet, pero no le da tantas opciones (es decir, todos los datos son confiables y secuenciados, no solo los bits que usted decida que deberían ser). Parece bastante sencillo de implementar.
Tenemos algunos clientes de la industria de defensa que usan UDT (transferencia de datos basada en UDP) (ver http://udt.sourceforge.net/ ) y estamos muy contentos con ello. Veo que también tiene una licencia BSD amigable.
RUDP . Muchos servidores de socket para juegos implementan algo similar.