WebSockets vs. Server-Sent Events vs. Long-Polling vs. WebRTC vs. WebTransport

Long Polling y patrones de sondeo

• Algunos echan de menos el long polling por su simplicidad y su compatibilidad con HTTP; otros sostienen que las implementaciones del mundo real muestran que no es “estúpidamente simple” una vez que consideras timeouts, proxies, reintentos y el orden de los mensajes.
• Se elogia el long polling por su interoperabilidad con herramientas y APIs HTTP genéricas.
• Varios señalan que cualquier sistema de tipo push necesita una forma de rehidratar el estado completo y manejar las actualizaciones perdidas; en ese punto, el sondeo simple o los “endpoints de eventos” con cursor pueden resultar atractivos.
• Debate sobre escalabilidad: un lado dice que el long polling escala linealmente como otras técnicas; otro observa que la rotación adicional de suscripciones y la sobrecarga de RTT/paquetes lo hacen “el menos escalable” en la práctica.

Server-Sent Events (SSE)

• Muy apreciado por su simplicidad, su fácil integración con stacks básicos (p. ej., Apache + PHP) y su compatibilidad con CDNs.
• Se ve como “long polling/Comet estandarizado” sobre respuestas fragmentadas.
• Limitaciones: solo texto (binario requiere base64 o codificaciones especiales), límites de conexión impuestos por el navegador con HTTP/1.1 y control limitado de cabeceras en la API nativa EventSource.
• Entre los paliativos están la multiplexación HTTP/2/3, el sharding de dominios, SharedWorkers/broadcast channels y clientes SSE personalizados con opciones más ricas.
• Algunos informan problemas de fiabilidad de SSE en entornos cerrados/empresariales y con ciertos frameworks de servidor.

WebSockets

• Populares como opción predeterminada para tiempo real bidireccional, a menudo con JSON-RPC encima.
• Críticas: más difíciles de escalar y operar, falta de multiplexación y backpressure incorporados (aunque el nuevo WebSocketStream pretende ayudar), y problemas persistentes con firewalls/redes corporativas en algunos entornos.
• Muchos usan bibliotecas que proporcionan alternativas de reserva (long polling, SSE, etc.) para lidiar con proxies rotos y navegadores antiguos.

WebRTC y WebTransport

• WebRTC funciona de forma fiable en la práctica para atravesar NAT y está ampliamente desplegado; es más adecuado para P2P y medios ricos, y menos para server push simple.
• WebTransport se valora por los streams, el backpressure y evitar el head-of-line blocking; algunos ya lo usan para juegos.
• Preocupación: UDP/HTTP/3 puede estar bloqueado en algunas redes, obligando a implementaciones duales con WebSockets.

Streaming HTTP y variantes

• Varios destacan el streaming genérico de respuestas HTTP (p. ej., JSONL sobre fetch streams, transportes HTTP-streaming) como una opción potente, a menudo infrautilizada, y a veces preferida frente a SSE para streams finitos.

Autenticación, segundo plano y móvil

• Las APIs de navegador para SSE/WebSockets hacen incómodas las cabeceras de autenticación personalizadas; las cookies son la solución más común, o bien clientes personalizados.
• El comportamiento en móvil y en segundo plano es problemático: radios, timeouts y la duración de vida de los workers pueden romper conexiones “siempre activas”; las APIs de push y los botones de refresco siguen siendo fallbacks importantes.