¿Tu aplicación autoalojada necesita conexiones persistentes? Lista de comprobación para WebSockets, SSE y long polling

Por qué las conexiones persistentes son una cuestión de selección de la aplicación, no solo de configuración del proxy

El requisito de una conexión persistente cambia más aspectos que la configuración de un proxy inverso. Afecta a la ruta de red entre una persona usuaria y la aplicación, a cómo se drenan los despliegues, a qué ocurre tras cambios de autenticación, a cómo se coordinan varias instancias de la aplicación y a qué señales necesitan los operadores durante un incidente.

Empieza por la experiencia de usuario en lugar de por una preferencia de protocolo. Una aplicación puede funcionar perfectamente con HTTP normal de solicitud-respuesta para tareas administrativas, informes periódicos y actualizaciones no urgentes. Otras experiencias pueden parecer incompletas si las actualizaciones se retrasan o si una sesión interactiva se reconecta repetidamente. La pregunta correcta no es «¿Puede el proxy admitir WebSockets?», sino «¿Qué flujo de trabajo de usuario depende de una conexión abierta o mantenida repetidamente, y cuál es el comportamiento aceptable cuando no está disponible?».

Para un despliegue gestionado, confirma los requisitos en la documentación actual del proveedor de la aplicación y prueba el flujo de trabajo real después del despliegue. Airbip ejecuta instancias de aplicaciones como cargas de trabajo Docker en servidores en la nube y automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt. Esto puede simplificar la infraestructura en torno a una aplicación compatible, pero no sustituye la necesidad de validar el comportamiento en tiempo real específico de la aplicación, el diseño de identidad, el tratamiento de datos y la responsabilidad operativa.

• Identifica la pantalla, el flujo de trabajo o la integración exactos que necesitan una entrega oportuna.
• Define si la aplicación necesita solo actualizaciones del servidor al navegador o mensajería interactiva bidireccional.
• Registra el mecanismo de respaldo previsto: actualización manual, sondeo periódico, notificación retrasada, cola de reintentos o un estado sin conexión claro.
• Trata los requisitos de transporte en tiempo real como un criterio de aceptación antes de la migración, no como una tarea de ajuste posterior al lanzamiento.

WebSockets, eventos enviados por el servidor y long polling: diferencias operativas

Los WebSockets comienzan con un protocolo de enlace de apertura HTTP y después intercambian mensajes enmarcados a través de la conexión establecida. Son adecuados cuando una aplicación necesita un canal bidireccional continuo. RFC 6455 también define tramas de control Ping y Pong, que los extremos pueden utilizar para comprobaciones de disponibilidad o capacidad de respuesta.

Los eventos enviados por el servidor, conocidos habitualmente como SSE, usan la interfaz EventSource del navegador y el tipo de contenido text/event-stream. SSE está diseñado para la entrega de eventos del servidor a la página. Suele ser una buena opción cuando el navegador recibe principalmente actualizaciones y envía cualquier comando mediante solicitudes HTTP normales. EventSource se reconecta después de que una conexión se cierre, salvo que el servidor envíe HTTP 204 No Content; también puede proporcionar una cabecera Last-Event-ID al reconectarse, lo que permite al servidor determinar el último identificador de evento recibido.

El long polling mantiene una solicitud HTTP hasta que se produce una actualización, un cambio de estado o un tiempo de espera, tras lo cual el cliente normalmente abre otra solicitud. Puede funcionar con infraestructura HTTP conocida, pero cada entrega sigue siendo un intercambio completo de solicitud-respuesta HTTP. Las solicitudes pendientes consumen recursos en clientes, servidores, pasarelas y proxies, por lo que sus características operativas merecen pruebas deliberadas con la concurrencia prevista.

• Elige WebSockets cuando el producto requiera un canal bidireccional continuo y el proveedor documente ese transporte.
• Considera SSE para flujos unidireccionales del servidor al navegador, usando solicitudes HTTP para las acciones del cliente.
• Considera long polling cuando la aplicación lo admita y las actualizaciones casi en tiempo real sean útiles, pero no sea necesaria una conexión actualizada de forma continua.
• No supongas que un patrón es intrínsecamente más sencillo: la complejidad operativa depende de la aplicación, el comportamiento del cliente y cada intermediario de la ruta.

Qué experiencias de usuario pueden depender de conexiones persistentes

Las conexiones persistentes normalmente se justifican por patrones de interacción, no por una etiqueta de categoría como CRM, analítica o colaboración. Un indicador de presencia en directo, una superficie de edición compartida, una consola operativa que se actualiza continuamente, una respuesta de IA transmitida en streaming o un canal de notificaciones dentro del producto pueden depender de una entrega oportuna desde el servidor. Sin embargo, la misma aplicación suele contener muchas páginas que no lo necesitan.

Clasifica cada flujo de trabajo por sus consecuencias. Una actualización retrasada de un panel puede ser tolerable. Una interfaz de control que deja a un operador con incertidumbre sobre si se recibió una acción puede no serlo. Del mismo modo, una función de colaboración puede necesitar indicar que su canal en directo se está reconectando en lugar de mostrar silenciosamente un estado desactualizado.

Pregunta al proveedor si el comportamiento es necesario para la corrección, preferible para la capacidad de respuesta o simplemente una mejora opcional. Pregunta también si la aplicación tiene un modo degradado compatible. No deduzcas los requisitos de transporte a partir del marketing del producto o de la presencia de una interfaz de navegador.

• Colaboración: el estado compartido, la presencia, los comentarios o las alertas pueden necesitar una propagación rápida.
• Interfaces operativas: los cambios de estado, el progreso de trabajos y las alertas pueden necesitar un indicador explícito de actualización.
• Notificaciones: determina si el correo electrónico retrasado o la consulta dentro de la aplicación son mecanismos de respaldo aceptables.
• Interfaces de IA: distingue una respuesta transmitida en streaming de una solicitud que puede simplemente completarse antes de mostrar el resultado.
• Integraciones: establece si los eventos entrantes, las confirmaciones de entrega salientes o ambos dependen de un canal de larga duración.

Lista de comprobación previa a la adopción: documentación del proveedor, ruta de red, autenticación, escalado y comportamiento ante fallos

Antes de adoptar o migrar una aplicación, crea un breve perfil de conexiones respaldado por evidencias. La documentación del proveedor de la aplicación debe ser la fuente principal para los transportes compatibles, las rutas de los extremos, las cabeceras requeridas, el comportamiento de autenticación, las indicaciones sobre proxies, el diseño de múltiples instancias y el comportamiento de respaldo esperado. Si la documentación no es clara, prueba el flujo de trabajo específico en un entorno representativo en lugar de hacer suposiciones.

Traza toda la ruta: navegador o cliente, DNS, terminación TLS, capa de distribución de contenido o seguridad si existe, proxy inverso, balanceador de carga, carga de trabajo de la aplicación y cualquier componente para compartir mensajes que requiera la aplicación. Una configuración que parece correcta en el extremo de la aplicación puede verse anulada por un intermediario anterior con un tiempo de espera de inactividad más corto o una política de conexión que no permite el tráfico previsto.

La autenticación necesita especial atención porque una conexión puede durar más que una solicitud de página. Establece cómo autentica la aplicación la conexión inicial, cómo gestiona las credenciales caducadas y qué ocurre cuando se revoca el acceso mientras un canal está abierto. Trátalos como cuestiones de diseño específicas de la aplicación que deben verificarse, no como propiedades universales del transporte.

• Obtén la documentación del proveedor sobre proxies y escalado para el modo de despliegue previsto.
• Enumera todos los intermediarios de red y sus políticas de conexión, cabeceras y tiempos de espera.
• Verifica los requisitos de TLS y dominio personalizado; Airbip admite un subdominio de Airbip o un dominio personalizado compatible.
• Documenta la autenticación en el establecimiento de conexión, la caducidad del token o la sesión, el cierre de sesión y la revocación de acceso.
• Prueba las reconexiones previstas, las actualizaciones del navegador, los reinicios de la aplicación y la indisponibilidad temporal del proxy.
• Confirma el modelo compatible de la aplicación para múltiples instancias antes de diseñar para el escalado horizontal.

Preguntas para un proveedor de alojamiento gestionado o un equipo interno de plataforma

Las preguntas útiles son concretas y están vinculadas al comportamiento documentado de la aplicación. Un equipo de plataforma puede explicar la capa de enrutamiento, el proceso de dominios y certificados, los controles de ciclo de vida, el enfoque de copias de seguridad y los límites de su servicio. No puede prometer responsablemente que un transporte de aplicación no documentado, una biblioteca cliente o una integración de terceros funcionará correctamente sin validación.

Para los despliegues de Airbip, los puntos de partida relevantes incluyen el modelo de cargas de trabajo Docker de la aplicación, la automatización de enrutamiento y TLS mediante Traefik y Let’s Encrypt, las comprobaciones de DNS, la gestión del ciclo de vida del servicio y las copias de seguridad diarias, semanales y mensuales configurables. Las copias de seguridad son importantes para la recuperabilidad, pero no sustituyen el drenaje de conexiones, la lógica de reintento del cliente ni un modo de fallo en tiempo real probado.

• ¿La versión prevista de la aplicación documenta extremos WebSocket, SSE o long polling y requisitos de proxy?
• ¿Dónde termina TLS y se admiten conexiones WebSocket seguras a lo largo de la ruta prevista?
• ¿Qué configuraciones de tiempo de espera se aplican en la capa de enrutamiento y qué capas ascendentes imponen sus propios límites?
• ¿Puede reiniciarse o actualizarse la aplicación con una experiencia de reconexión definida para el usuario?
• Si se utiliza más de una instancia de aplicación, ¿qué componente comparte eventos, presencia o estado relacionado con las conexiones?
• ¿Qué registros y métricas están disponibles durante un incidente de conexión?
• ¿Qué responsabilidades permanecen en manos del cliente respecto al acceso de usuarios, la configuración de la aplicación, la retención de datos y la gobernanza?

Proxies inversos y balanceadores de carga: actualizaciones de protocolo, tiempos de espera, cabeceras reenviadas y límites de conexión

Para WebSockets, valida el protocolo de enlace de apertura HTTP a través de toda la ruta. Traefik documenta compatibilidad con WS y WSS sin un middleware de WebSocket independiente y afirma que conserva cabeceras relevantes del protocolo de enlace, como Origin y Sec-WebSocket-Key. Este es un comportamiento útil de la infraestructura, pero la aplicación desplegada debe seguir aceptando el origen público, construir URL externas correctas y aplicar sus propias reglas de seguridad.

Las cabeceras reenviadas son importantes cuando una aplicación necesita conocer el host, el esquema o la dirección de cliente originales. Traefik añade automáticamente X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto y X-Forwarded-Server durante el proxy. Verifica cómo confía la aplicación en las cabeceras reenviadas y cómo las interpreta, especialmente cuando existe otro proxy delante de la capa de enrutamiento.

Los tiempos de espera deben evaluarse como una cadena. Los puntos de entrada de Traefik exponen configuraciones de tiempo de espera de lectura, escritura e inactividad. Para long polling, RFC 6202 señala que un servidor o intermediario puede finalizar una solicitud pendiente con HTTP 408 o HTTP 504, y que el tiempo de espera limitante puede estar en la infraestructura y no en el navegador. SSE puede necesitar una salida periódica de mantenimiento porque algunos proxies antiguos pueden cerrar una conexión HTTP que, de otro modo, permanece inactiva. Los límites de conexión, la capacidad de descriptores de archivo y el uso de recursos ascendentes también deben revisarse para el número esperado de clientes simultáneos.

• Confirma el comportamiento del protocolo de enlace y de actualización de WebSocket de extremo a extremo, no solo en el proxy final.
• Alinea los heartbeats o keepalives de la aplicación con la política de inactividad relevante más corta, cuando la aplicación los admita.
• Configura y prueba las duraciones de solicitudes long polling frente a los tiempos de espera del servidor y de los intermediarios.
• Evita el almacenamiento en caché inadecuado de las rutas long polling mediante controles de caché HTTP estándar.
• Verifica el tratamiento del origen y la configuración de confianza en proxies de la aplicación.
• Realiza pruebas de capacidad con conexiones abiertas simultáneas y observa la presión de recursos en el proxy, el host y la aplicación.

Cómo afectan las conexiones persistentes a los despliegues de múltiples instancias y al diseño de sesiones

Una sola instancia de aplicación puede evitar muchas cuestiones de sistemas distribuidos, pero no elimina la necesidad de gestionar reconexiones y reinicios. Cuando el tráfico se sirve mediante múltiples instancias, un cliente conectado puede estar vinculado a una instancia mientras se crea un evento en otra. Si la aplicación requiere difusiones, presencia compartida o entrega a usuarios conectados en otros lugares, necesita su mecanismo documentado para compartir mensajes o eventos relacionados con las conexiones entre instancias.

La guía de HAProxy sobre WebSockets ilustra el problema subyacente: cada servidor WebSocket tiene su propia lista de clientes conectados, por lo que la entrega entre servidores o la difusión requiere compartir los mensajes entre los servidores. La afinidad del balanceador de carga puede ser relevante para algunos modelos de sesión de aplicación, pero no sustituye de forma general al estado compartido. No puede hacer que un evento sea conocido por una instancia que no lo ha recibido.

Revisa el estado por separado: las sesiones de usuario, el estado de autorización, la propiedad de la conexión, el estado de suscripción, el historial de eventos y los trabajos en segundo plano pueden tener requisitos de almacenamiento o coordinación diferentes. Escala únicamente con una arquitectura compatible con el proveedor y prueba que un cliente se reconecte a una instancia diferente.

• Determina si la aplicación admite oficialmente más de una instancia activa.
• Identifica dónde se almacenan las sesiones, las suscripciones y el historial de eventos.
• Confirma cómo se propagan las difusiones entre instancias y la entrega dirigida.
• Prueba la pérdida de una instancia mientras los clientes permanecen conectados a otras.
• No dependas de la afinidad del balanceador de carga como único diseño para eventos compartidos o estado duradero.
• Asegúrate de que los clientes que se reconectan puedan restaurar el estado o solicitar de forma segura una vista actual.

Señales de supervisión: clientes conectados, desconexiones, tasas de reconexión, patrones de error y presión de recursos

Los canales persistentes necesitan observabilidad que distinga una conexión silenciosa pero sana de una rota. Recopila los recuentos de conexiones cuando el proxy o la aplicación los expongan, pero interprétalos junto con la antigüedad de las conexiones, los motivos de desconexión, los intentos de reconexión, los fallos del protocolo de enlace, los errores de respuesta y la actualización visible para el usuario. No existe un umbral saludable universal: los niveles normales dependen de la población de clientes de la aplicación, la duración esperada de las sesiones, la actividad de lanzamientos y la forma del tráfico.

Realiza el seguimiento tanto del comportamiento del servicio como del cliente. Un aumento de la tasa de desconexiones puede indicar un desajuste de tiempos de espera, una interrupción de red, un evento de despliegue o un problema de la aplicación. Un aumento de reconexiones tras la recuperación del servicio puede crear su propio pico de carga. RFC 6455 recomienda reconexiones retrasadas con demoras cada vez mayores después de un cierre anormal, lo que ayuda a los clientes a evitar saturar un servicio que se está recuperando.

La supervisión de recursos sigue siendo esencial. Long polling puede acumular solicitudes HTTP pendientes. Las conexiones de larga duración pueden mantener sockets y consumir recursos del proxy, el sistema operativo y la aplicación. Supervisa la capacidad de conexión relevante, CPU, memoria, actividad de red y registros de errores a través de toda la ruta; después, investiga los cambios respecto a una línea de referencia en lugar de depender de objetivos numéricos tomados de otros contextos.

• Clientes conectados actuales y máximos, segmentados por extremo cuando esté disponible.
• Fallos del protocolo de enlace, fallos de autorización y códigos de respuesta inesperados.
• Motivos de desconexión y distribución de la duración de las conexiones.
• Tasa de reconexión, comportamiento de demora de reintentos y eventos correlacionados de despliegue o red.
• Solicitudes long polling pendientes y respuestas por tiempo de espera como 408 o 504.
• Presión de recursos de CPU, memoria, sockets y red en el proxy, el host y la aplicación.
• Un indicador de actualización o desconexión orientado al usuario cuando la aplicación lo proporcione.