web udp public
1.0.0
Este repositorio es para expresar la necesidad pública de una tecnología que permita la comunicación de baja latencia entre el servidor y el cliente , sin confiabilidad obligatoria y/o mecanismos de entrega ordenados del protocolo de transporte subyacente.
Y dé forma a los requisitos a partir de las necesidades existentes y las posibles aplicaciones futuras. Motivar a los miembros del W3C, la comunidad IETF y los proveedores de navegadores a iniciar un debate y proponer RFC para impulsar un mayor desarrollo de una solución.
Las relaciones públicas y las discusiones en Temas son bienvenidas. Corre la voz, los RT son bienvenidos.
Web evolucionó rápidamente en los últimos años, mejorando las capacidades de red utilizando tecnologías como: WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC .
Dichas tecnologías tienen área de aplicación propia y plataforma web habilitada para tener:
y muchas más experiencias ricas y poderosas
En los últimos años ha nacido otro medio: los juegos HTML5 . Adobe Flash está desapareciendo y la industria de los juegos HTML5 está creciendo constantemente.
Lo que llevó al nacimiento de IO Games, uno de los juegos multijugador más accesibles que existen. Algunos de los ejemplos populares: agar.io, slither.io y muchos más. Todos ellos dependen de la única tecnología viable actualmente para la comunicación servidor-cliente en tiempo real: WebSockets. WebRTC para servidor-cliente es demasiado complejo (leer más).
Pero esto limita las capacidades de la red, ya que TCP para juegos tiene límites . Vale la pena mencionar que no se trata solo de los juegos : hay muchos casos de uso para comunicaciones servidor-cliente de baja latencia, poco confiables y desordenadas.
Latencia y congestión . TCP tiene una entrega de paquetes confiable y ordenada y es un protocolo basado en conexión. La necesidad de UDP (o alternativa) sobre TCP no está en duda, ya que se analiza ampliamente en muchos artículos sobre los beneficios de UDP (o alternativa) sobre TCP en diferentes casos. Aquí intentamos simplemente resumirlo. Vale la pena mencionar que UDP es la opción de protocolo de transporte más popular, pero no la única, para este esfuerzo.
Fiabilidad : esto no siempre es lo que desea la lógica de la aplicación; es posible que la información obsoleta ya no sea relevante y se pueda ignorar. TCP garantizará la entrega de paquetes, lo que genera congestiones que provocan picos de latencia debido a la necesidad de reconocimientos y reenvío de paquetes. UDP (o alternativa) no garantiza la confiabilidad inmediata, por lo que evita problemas de congestión que pueden usarse como beneficio para garantizar que los datos más recientes se entreguen lo antes posible.
Entrega ordenada : TCP utiliza secuenciación y reconocimientos para garantizar la lectura ordenada y la reenvío de paquetes. Esto conduce a un bloqueo de la lectura, lo que genera picos de latencia y empeora si el entorno de red tiene una mayor pérdida de paquetes.
Protocolo que no garantiza confiabilidad y entrega ordenada lista para usar, lo que permite al desarrollador implementar cualquiera de las técnicas además si es necesario o utilizar enfoques híbridos. Esto proporciona tiempos de entrega estables y baja latencia en entornos de red que no son perfectos. Con control de congestión para mitigar la sobrecarga de la infraestructura de Internet para abordar los problemas de seguridad.
Una de las opciones para resolver esto es agregar una nueva extensión al protocolo WebSockets existente utilizando la mecánica de negociación descrita en RFC 6455. Lo que implementaría una funcionalidad adicional para establecer comunicación de protocolo UDP (o alternativo). Esto se beneficiaría del modelo de seguridad existente de WebSockets basado en el origen y permitiría a los desarrolladores seguir un enfoque progresivo en el que pueden recurrir a la lógica TCP si dicha extensión no es compatible con ninguna de las partes (servidor o cliente).
Otro enfoque sería desarrollar una API completamente nueva, muy similar a WebSockets, que abordaría características únicas de la lógica de red UDP (o alternativa), además de proporcionar potencialmente características adicionales para los desarrolladores con opciones detalladas sobre cómo enviar mensajes.
El estado actual de WebRTC es demasiado complejo y fue diseñado principalmente para la comunicación entre pares. Debido a esto, no se adopta bien para la comunicación servidor-cliente y requiere muchos recursos de desarrollador. En pocas palabras, no es compatible con desarrolladores web en solitario como lo son los WebSockets en la actualidad. Opción potencial de ampliar la especificación para modularizar y simplificar los requisitos que permitirían el uso de algunas partes de WebRTC, haciéndola más accesible para escenarios de servidor-cliente y una API simplificada que la haría más accesible para los desarrolladores web.
Existe un borrador de especificación de la API WebTransport que permite a las aplicaciones web establecer conexiones de red interactivas, bidireccionales y multiplexadas, con soporte para comunicaciones confiables y no confiables.
Dicha implementación de API y protocolo subyacente debe abordar los problemas de seguridad para que sea compatible con la web:
La API debe abordar esos problemas de seguridad, sin complicar demasiado la API para el front-end ni la implementación para el back-end. Por eso UDPSocket no es una opción.
Lista de posibles protocolos subyacentes que se pueden utilizar para una implementación:
