Un chat de soporte implementado en Node.js funciona perfectamente en el escenario: veinte probadores, latencia instantánea. En producción en el mismo VPS, 300 agentes conectados: el servidor encuentra "demasiados archivos abiertos", nginx devuelve 502 y las conexiones se interrumpen cada 60 segundos porque nadie notó el proxy_read_timeout predeterminado.
WebSocket no es un HTTP un poco más largo. Es un modelo de recursos diferente: conexiones persistentes, memoria por cliente, latidos y, a menudo, transmisión que amplifica cada mensaje. Hospedar en tiempo real sin un plan significa convertir el éxito de un producto en un incidente de infraestructura predecible.
WebSocket versus HTTP: lo que realmente consume una conexión
| Recurso | Solicitud HTTP corta | Abrir WebSocket |
|---|---|---|
| Descriptores de archivos | 1 luego liberado | 1 horas mantenidas |
| Memoria del servidor de aplicaciones | Trabajador de piscina reciclado | Búfer + estado de sesión |
| Procesador | Pico para consultar | Latidos del corazón + mensajes continuos |
| Apoderado | Sin estado, fácil | Actualización + tiempo de espera para configurar |
| Ampliación | Único horizontal | Se requiere afinidad o pub/sub |
Regla general: calcule 50 KB a 200 KB de memoria por conexión dependiendo de la pila (el nodo, GB y Elixir varían). 5000 conexiones × 100 KB ≈ 500 MB, antes del código comercial.
El número que mata primero no es la CPU, es
ulimit -ny el tiempo de espera del proxy.
Proxy inverso: nginx frente a la aplicación en tiempo real
Configuración mínima de nginx:
ubicación /ws/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualización";
proxy_set_header Anfitrión $anfitrión;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
Puntos a menudo olvidados: el límite global worker_connections nginx versus conexiones WebSocket; Terminación TLS en el proxy: algunos hosts limitan las conexiones SSL simultáneas; HTTP/2 en el lado del cliente público, Actualización HTTP/1.1 en sentido ascendente.
Consulte también Proxy de tiempo de espera de WebSocket y Nginx o Apache.
Escalado horizontal: afinidad versus corredor
Opción A: sesiones fijas. El equilibrador de carga enruta al cliente al mismo nodo. Sencillo, frágil si el nodo cae (reconexión masiva).
Opción B: Redis pub/sub o adaptador Socket.IO. Mensajes enrutados entre nodos; Conexiones distribuidas. Requerido de dos o más instancias.
Opción C: Servicio administrado (Pusher, Ably, centro Mercure administrado). Complejidad de la subcontratación; costo por mensaje.
Para un MVP serio, la opción B en dos VPS pequeños supera a un único servidor grande sin pub/sub.
Hosting: preguntas para hacerle al proveedor
Antes de elegir, pregunte si se permiten conexiones largas (las compartidas a menudo se cortan), cuál es el límite de descriptores de archivos, si UDP o QUIC están filtrados para WebTransport, si el balanceador de carga de capa 7 admite la actualización de WebSocket y si anti-DDoS puede bloquear falsamente conexiones lentas.
Cloud VPS (Hetzner, OVH, Scaleway) con nginx sigue siendo la combinación más predecible para WebSocket autohospedado.
Latidos, reconexión y observabilidad
Envíe un ping/pong de aplicación cada 30 segundos para detectar conexiones muertas. Aplique un retroceso exponencial en el lado del cliente para evitar que el servidor se apresure al reiniciar. Mida las conexiones activas, los mensajes por segundo y la latencia de entrega del percentil 99. Planifique una parada elegante: señal de parada, aceptación de parada, drenaje durante 30 segundos.
La cumbre: el tiempo real escala en conexiones, no en visitas a páginas
Vender “chat en vivo” sin cifras máximas de conexión, tiempo de espera de proxy y plan de publicación/subscripción es vender una característica que no sobrevive al primer éxito.
Decide y avanza sin puntos ciegos
Primero calcule el máximo de conexiones × memoria y verifique "ulimit". Configure los tiempos de espera de nginx antes del lanzamiento. Pruebe la reconexión después de la implementación, no solo el viaje nominal. Planifique la publicación/subscripción de Redis antes del segundo servidor. Configure un panel de conexiones activas con alerta al 80% del umbral.
Explora VPS y la nube en el directorio y la comparación.
Preguntas frecuentes
¿Cuántas conexiones WebSocket puede contener un servidor?
Depende de la memoria por conexión, descriptores de archivos y nginx. Son posibles miles de conexiones inactivas; mucho menos si cada mensaje desencadena un trabajo pesado.
¿Necesita una sesión fija detrás de un equilibrador de carga?
Sí, si el estado vive en la memoria de procesos. De lo contrario, utilice Redis pub/sub o un centro dedicado para compartir el estado entre nodos.
¿Compartido es compatible con WebSocket?
A menudo de forma parcial o con tiempos de espera breves (de 30 a 60 segundos). Consulte la documentación del proveedor de alojamiento: algunos paneles cortan conexiones largas.
¿Nginx o Apache por delante de Node.js WebSocket?
Nginx es más común con encabezados de actualización y proxy_read_timeout adaptados (a menudo 3600 segundos o más). Apache mod_proxy_wstunnel funciona pero es menos común en producción en tiempo real.
El tiempo real se mide en conexiones abiertas, no en visitantes únicos del último mes.