WebSocket vs Server-Sent Events vs long polling vs WebRTC vs WebTransport
- En las aplicaciones web modernas en tiempo real, la capacidad de enviar eventos del servidor al cliente es esencial.
- Esta necesidad llevó al desarrollo de varios métodos, cada uno con sus propias ventajas y desventajas.
- Al principio, la única opción disponible era el long polling, pero después apareció WebSocket como una solución más robusta para la comunicación bidireccional.
- Después de WebSocket, se ofreció Server-Sent Events (SSE) como un método más simple para la comunicación unidireccional del servidor al cliente.
- El protocolo WebTransport ofrece un enfoque más eficiente, flexible y escalable, y parece que innovará aún más este campo.
- Para casos de uso específicos, WebRTC también puede considerarse para eventos entre servidor y cliente.
¿Qué es long polling?
- El long polling es la primera técnica de "hack" que hizo posible un método de mensajería entre servidor y cliente utilizable en el navegador a través de HTTP.
- A diferencia del polling tradicional, en el que el cliente solicita datos periódicamente al servidor, el long polling establece una conexión con el servidor que permanece abierta hasta que haya datos nuevos disponibles.
- Cuando el servidor tiene nueva información, envía una respuesta al cliente y cierra la conexión.
- El cliente inicia una nueva solicitud inmediatamente después de recibir la respuesta del servidor, y este proceso se repite.
- Este método permite actualizaciones de datos más inmediatas y reduce el tráfico de red innecesario y la carga del servidor.
- Sin embargo, aún puede introducir latencia y es menos eficiente que otras tecnologías en tiempo real como WebSocket.
¿Qué es WebSocket?
- WebSocket proporciona un canal de comunicación full-duplex a través de una sola conexión persistente entre el cliente y el servidor.
- Esta tecnología permite el intercambio de datos entre el navegador y el servidor sin la sobrecarga del ciclo de solicitud-respuesta de HTTP, por lo que es adecuada para la transmisión de datos en tiempo real.
- WebSocket representa un gran avance frente al HTTP tradicional, ya que una vez establecida la conexión, ambos lados pueden enviar datos de forma independiente, lo que lo hace ideal para escenarios que requieren baja latencia y actualizaciones de alta frecuencia.
¿Qué son los Server-Sent Events?
- Server-Sent Events (SSE) proporciona un método estándar para enviar actualizaciones del servidor al cliente a través de HTTP.
- A diferencia de WebSocket, SSE está diseñado solo para la comunicación unidireccional del servidor al cliente, por lo que es ideal en situaciones en las que el cliente necesita recibir actualizaciones en tiempo real sin necesidad de enviar datos al servidor.
¿Qué es la API de WebTransport?
- WebTransport es una API moderna diseñada para una comunicación eficiente y de baja latencia entre clientes web y servidores.
- Aprovecha el protocolo HTTP/3 QUIC para habilitar diversas capacidades de transferencia de datos.
- WebTransport es una herramienta potente para aplicaciones que requieren redes de alto rendimiento, como juegos en tiempo real, live streaming y plataformas colaborativas.
- WebTransport se encuentra actualmente en etapa de working draft y todavía no ha sido adoptado ampliamente.
¿Qué es WebRTC?
- WebRTC (comunicación web en tiempo real) es un proyecto open source y un estándar de API que permite capacidades de comunicación en tiempo real (RTC) dentro de navegadores web y aplicaciones móviles sin necesidad de infraestructura de servidor compleja ni de instalar plugins adicionales.
- WebRTC admite conexiones peer-to-peer para el intercambio de audio, video y datos entre navegadores.
- WebRTC está diseñado para funcionar a través de NAT y firewalls, y utiliza protocolos como ICE, STUN y TURN para establecer conexiones entre pares.
Limitaciones de las tecnologías
- Solo WebSocket y WebTransport permiten enviar datos en ambos sentidos.
- La restricción de 6 solicitudes por dominio limita la usabilidad de todos los métodos persistentes de mensajería entre servidor y cliente.
- En las aplicaciones móviles, el sistema operativo mueve automáticamente la app al background tras cierto tiempo de inactividad y cierra las conexiones abiertas.
- En entornos empresariales, muchos proxies y firewalls bloquean conexiones que no son HTTP, lo que dificulta integrar servidores WebSocket en la infraestructura.
Comparación de rendimiento
- Para comparar directamente el rendimiento de WebSocket, SSE, long polling y WebTransport, hay que evaluar aspectos clave como latencia, throughput, carga del servidor y escalabilidad en distintas condiciones.
Latencia
- WebSocket: ofrece la menor latencia gracias a la comunicación full-duplex mediante una sola conexión persistente.
- Server-Sent Events: ofrece baja latencia para la comunicación del servidor al cliente, pero no puede enviar mensajes al servidor sin solicitudes HTTP adicionales.
- Long polling: produce mayor latencia porque depende de establecer una nueva conexión HTTP para cada transmisión de datos.
- WebTransport: se espera que ofrezca baja latencia similar a WebSocket, con las ventajas de un multiplexado más eficiente y mejor control de congestión gracias al protocolo HTTP/3.
Throughput
- WebSocket: puede alcanzar un throughput alto gracias a la conexión persistente, pero este puede degradarse cuando el cliente no puede procesar los datos tan rápido como el servidor puede enviarlos.
- Server-Sent Events: puede hacer broadcast de mensajes a muchos clientes con menos sobrecarga que WebSocket, por lo que puede lograr mayor throughput en comunicaciones unidireccionales del servidor al cliente.
- Long polling: generalmente ofrece menor throughput debido a la sobrecarga de abrir y cerrar conexiones con frecuencia.
- WebTransport: se espera que admita alto throughput tanto para streams bidireccionales como unidireccionales dentro de una sola conexión, y puede superar a WebSocket en escenarios que requieren múltiples streams.
Escalabilidad y carga del servidor
- WebSocket: mantener una gran cantidad de conexiones WebSocket puede aumentar significativamente la carga del servidor, lo que puede afectar la escalabilidad en aplicaciones con muchos usuarios.
- Server-Sent Events: al tener menos sobrecarga de conexión que WebSocket, es más escalable en escenarios donde principalmente se requieren actualizaciones del servidor al cliente.
- Long polling: es el menos escalable debido a la alta carga del servidor generada por el establecimiento frecuente de conexiones.
- WebTransport: como está diseñado para aprovechar la eficiencia de HTTP/3 en el manejo de conexiones y streams, ofrece alta escalabilidad al tiempo que reduce la carga del servidor en comparación con WebSocket y SSE.
Recomendaciones y adecuación por caso de uso
- En el panorama de las tecnologías de comunicación entre servidor y cliente, cada una tiene ventajas únicas y una adecuación específica según el caso de uso.
- Server-Sent Events (SSE) es la más simple de implementar y puede evitar problemas técnicos al sortear restricciones de firewalls empresariales.
- WebSocket destaca en escenarios donde se requiere comunicación bidireccional persistente.
- WebTransport presenta dificultades de adopción, no cuenta con amplio soporte en frameworks de servidor, incluido Node.js, y no es compatible con Safari.
- Long polling no se recomienda para la mayoría de los casos de uso por su ineficiencia y la alta sobrecarga de establecer repetidamente nuevas conexiones HTTP.
Problemas conocidos
- Todas las tecnologías de streaming en tiempo real tienen problemas conocidos.
- El cliente puede perder eventos ocurridos en el servidor cuando está conectándose, reconectándose o sin conexión.
- Los firewalls empresariales pueden causar problemas al usar tecnologías de streaming.
Opinión de GN⁺
- Este artículo compara varias tecnologías de comunicación que los desarrolladores pueden usar al construir aplicaciones web en tiempo real, por lo que ofrece información útil para elegir una tecnología.
- WebSocket y SSE ya se usan ampliamente y, en particular, WebSocket es muy popular en aplicaciones que requieren comunicación bidireccional, como chats en tiempo real o juegos.
- WebTransport todavía está en fase de borrador y no tiene soporte amplio, por lo que podría ser difícil aplicarlo en proyectos reales. Sin embargo, vale la pena seguirlo de cerca por su gran potencial como tecnología basada en HTTP/3.
- Aunque long polling es una tecnología antigua, todavía puede ser útil en ciertas situaciones, especialmente cuando la compatibilidad con sistemas legacy es importante.
- Al elegir una tecnología de comunicación en tiempo real, se deben considerar los requisitos de la aplicación, los navegadores compatibles, la infraestructura del servidor y el grado de madurez de la tecnología.
1 comentarios
Opiniones de Hacker News
Expresa afinidad por Server Sent Events (SSE), mientras menciona la falta de control de flujo (backpressure) y multiplexación en WebSockets, la imposibilidad de enviar datos binarios con SSE y los posibles problemas de adopción de WebTransport.
Señala la dificultad de implementar funcionalidades en tiempo real en entornos corporativos y los límites para resolver problemas por culpa de la burocracia, y propone como solución simple agregar un botón de recargar.
Asumiendo HTTP/2 o superior, opina que la combinación de EventSource y fetch() podría ser tan buena como otros protocolos que usan una sola conexión TCP, y también menciona el uso de UDP en HTTP/3.
Dice no entender por qué WebSockets y SSE no permiten enviar headers en la solicitud inicial, y señala que eso deja la autenticación de servicios en tiempo real en manos de quien lo implemente.
Menciona los problemas de gestionar WebSockets y SSE a gran escala, la necesidad de observabilidad especial en el backend, la dificultad de depurar en dispositivos móviles, el costo de las conexiones de red y lo complicado de mantener estado.
Comparte su experiencia procesando actualizaciones en tiempo real mediante server push/HTTP streaming en un sistema de subastas en línea diseñado en los años 90.
Expresa nostalgia por la simplicidad de long polling y, al mismo tiempo, menciona una valoración positiva de WebRTC.
Como alguien que trabaja en Stream, recomienda usar websockets con pings de keep-alive cada 30 segundos en la mayoría de los casos, y menciona considerar WebTransport por su baja latencia para juegos en tiempo real o transmisión de voz.
Presenta una opinión crítica sobre el artículo por no mencionar las ventajas de la comunicación basada en UDP de WebRTC.