El desarrollo web ya no es lo que era. Hace unos a\u00f1os bastaba con recargar la p\u00e1gina para ver lo nuevo, pero ahora los usuarios esperan que la informaci\u00f3n fluya sola, sin interrupciones. Por eso, saber configurar WebSocket en servidor<\/strong> ha dejado de ser un extra curioso para convertirse en una herramienta casi indispensable. A diferencia del HTTP, donde el rollo es \u00abyo te pido, t\u00fa me das\u00bb de manera unidireccional, WebSockets abre una puerta de doble v\u00eda. El servidor y el cliente hablan a la vez, en tiempo real.<\/p>\n Es lo que hay detr\u00e1s de los chats modernos, de los juegos multijugador o de esas herramientas de colaboraci\u00f3n donde ves escribir a tu compa\u00f1ero al instante. Vamos a ver c\u00f3mo montar esto en tu entorno de hosting para que funcione r\u00e1pido y no se caiga.<\/p>\n Antes de poner manos a la tecla, hay que pararse un momento. \u00bfPor qu\u00e9 no usar las soluciones de antes? El polling<\/em> o el long-polling<\/em> son como llamar a la puerta cada cinco segundos para preguntar si hay novedades. Es ineficiente, genera tr\u00e1fico por todas partes y a\u00f1ade una latencia que el usuario nota.<\/p>\n WebSockets mantiene una \u00fanica conexi\u00f3n abierta. Persistente.<\/p>\n Lo mejor de este enfoque es:<\/p>\n Si la velocidad es cr\u00edtica en tu aplicaci\u00f3n, configurar bien el servidor no es opcional, es el principio de todo.<\/p>\n Necesitas un servidor que aguante el tipo. Las conexiones persistentes no son amigables con todos los entornos. En planes VPS o Dedicados como los de RedServicio.net<\/strong> no tendr\u00e1s problema, pero cuidado con el hosting compartido b\u00e1sico: a menudo ponen trabas en los puertos o limitan el tiempo de ejecuci\u00f3n de los procesos.<\/p>\n Revisa esta lista antes de empezar:<\/p>\n Tip de experto:<\/em> Si est\u00e1s en local, comprueba que el firewall deja pasar el tr\u00e1fico por el puerto que vayas a usar (el 8080 o 3000 son comunes para desarrollo, el 443 para cuando esto sea en serio).<\/p>\n<\/div>\n Para el ejemplo nos iremos a Node.js y la librer\u00eda Empieza inicializando el proyecto e instalando lo necesario:<\/p>\n Crea un archivo const WebSocket = require(‘ws’); wss.on(‘connection’, (ws) => { ws.on(‘message’, (message) => { ws.on(‘close’, () => { Con este script tienes un servidor en el 8080. Cuando alguien entra, escucha lo que env\u00ede y lo pasa a los dem\u00e1s. Un chat b\u00e1sico, pero efectivo.<\/p>\n Dejar el servidor WebSocket al descubierto en un puerto alto, como el 8080, no es buena idea en producci\u00f3n. Especialmente si quieres usar HTTPS y tu dominio. Aqu\u00ed entra Nginx. Actuar\u00e1 como intermediario: recibe las peticiones en el 443 (HTTPS) y las pasa a tu aplicaci\u00f3n Node.js.<\/p>\n Abre la configuraci\u00f3n de tu sitio en Nginx (suele estar en server { location \/ws { F\u00edjate bien en las cabeceras No te conf\u00edes. Una conexi\u00f3n WebSocket sin cifrar (ws:\/\/) es un blanco f\u00e1cil para ataques de tipo \u00abMan-in-the-Middle\u00bb. En producci\u00f3n, usa siempre WebSockets Seguros (wss:\/\/), que son WebSockets tunelizados con TLS\/SSL.<\/p>\n Al configurar Nginx con tus certificados SSL (los de Let’s Encrypt son gratis y funcionan bien), cifras todo lo que va entre el cliente y Nginx. Luego, Nginx env\u00eda el tr\u00e1fico ya descifrado a tu Node.js en Recomendaci\u00f3n de seguridad:<\/strong> Cierra el puerto 8080 en el firewall para que solo acepte conexiones locales. As\u00ed evitas que alguien se conecte directamente a tu aplicaci\u00f3n WebSocket salt\u00e1ndose a Nginx.<\/p>\n<\/div>\n Te falta el cliente. En tu HTML o JS frontend, usa la API nativa const socket = new WebSocket(‘wss:\/\/tu-dominio.com\/ws’);<\/p>\n socket.addEventListener(‘open’, function (event) { socket.addEventListener(‘message’, function (event) { F\u00edjate en el A veces las cosas no salen como se espera. La conexi\u00f3n se muere a los pocos minutos si nadie dice nada. Normalmente es culpa de los proxies o firewalls intermedios que cortan lo que consideran \u00abconexiones muertas\u00bb.<\/p>\n La soluci\u00f3n es un mecanismo de latido (heartbeat)<\/strong>. Es decir, que el cliente o el servidor env\u00eden un paquete peque\u00f1o (\u00abping\u00bb) cada 30 o 60 segundos para avivar el fuego. En la librer\u00eda const wss = new WebSocket.Server({ \u00bfWebSockets funciona en hosting compartido?<\/strong> \u00bfCu\u00e1ntas conexiones concurrentes puede soportar mi servidor?<\/strong> Al principio, configurar WebSocket en servidor<\/strong> puede dar un poco de respeto. Pero una vez lo tienes, la diferencia en la experiencia de usuario es brutal. Hemos visto desde levantar un servidor con Node.js hasta poner a Nginx como guardi\u00e1n para asegurar la conexi\u00f3n con WSS. No olvides que la infraestructura es clave. En RedServicio.net<\/strong> tenemos planes preparados para soportar este tipo de cargas, con soporte t\u00e9cnico 24\/7 por si te atascas. Si no tienes claro qu\u00e9 hosting elegir para tu proyecto en tiempo real, pregunta a nuestro equipo; te echaremos una mano.<\/p>\n","protected":false},"excerpt":{"rendered":" Introducci\u00f3n a configurar WebSocket en servidor El desarrollo web ya no es lo que era. Hace unos a\u00f1os bastaba con […]<\/p>\n","protected":false},"author":2,"featured_media":872,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[3],"tags":[],"class_list":["post-870","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutoriales"],"yoast_head":"\n\u00bfPor qu\u00e9 implementar WebSockets en tu proyecto?<\/h2>\n
\n
Requisitos previos y preparaci\u00f3n del entorno<\/h2>\n
\n
Paso 1: Crear el servidor WebSocket con Node.js<\/h2>\n
ws<\/code>. Es ligera y cumple sobradamente. Su trabajo ser\u00e1 mantener las conexiones vivas y repartir los mensajes.<\/p>\nnpm init -y<\/code>
\nnpm install ws<\/code><\/p>\nserver.js<\/code>. Algo sencillo para escuchar conexiones:<\/p>\n
\nconst wss = new WebSocket.Server({ port: 8080 });<\/p>\n
\n console.log(‘Nuevo cliente conectado’);<\/p>\n
\n console.log(‘Recibido: %s’, message);
\n \/\/ Reenviar el mensaje a todos los clientes conectados
\n wss.clients.forEach((client) => {
\n if (client !== ws && client.readyState === WebSocket.OPEN) {
\n client.send(message);
\n }
\n });
\n });<\/p>\n
\n console.log(‘Cliente desconectado’);
\n });
\n});<\/p>\nPaso 2: Configurar Nginx como Proxy Inverso<\/h2>\n
\/etc\/nginx\/sites-available\/tu-dominio.com<\/code>) y a\u00f1ade este bloque location<\/code>:<\/p>\n
\n listen 443 ssl http2;
\n server_name tu-dominio.com;
\n # … configuraci\u00f3n de certificados SSL …<\/p>\n
\n proxy_pass http:\/\/localhost:8080;
\n proxy_http_version 1.1;
\n proxy_set_header Upgrade $http_upgrade;
\n proxy_set_header Connection \u00abupgrade\u00bb;
\n proxy_set_header Host $host;
\n proxy_cache_bypass $http_upgrade;
\n }
\n}<\/p>\nUpgrade<\/code> y Connection<\/code>. Son las que le dicen a Nginx: \u00abojo, aqu\u00ed cambiamos del HTTP est\u00e1ndar a WebSocket\u00bb. Sin esto, la conexi\u00f3n muere antes de nacer. Cuando termines, verifica y reinicia:<\/p>\nsudo nginx -t<\/code>
\nsudo systemctl restart nginx<\/code><\/p>\nPaso 3: Seguridad y WebSocket Seguro (WSS)<\/h2>\n
localhost<\/code>. Como eso pasa dentro del propio servidor, est\u00e1s seguro.<\/p>\nEjemplo de c\u00f3digo del lado del cliente (JavaScript)<\/h2>\n
WebSocket<\/code>:<\/p>\n
\n socket.send(‘\u00a1Hola Servidor!’);
\n});<\/p>\n
\n console.log(‘Mensaje del servidor: ‘, event.data);
\n});<\/p>\nwss:\/\/<\/code> y la ruta \/ws<\/code>. Es la misma que configuraste en Nginx. As\u00ed la conexi\u00f3n viaja por el canal seguro.<\/p>\nSolucionar problemas comunes<\/h2>\n
ws<\/code> hay opciones para esto, pero un simple script suele bastar:<\/p>\n
\n port: 8080,
\n clientTracking: true,
\n});<\/p>\nPreguntas Frecuentes<\/h3>\n
\nDepende. Muchos hostings compartidos ponen l\u00edmites a los puertos personalizados y a los procesos de larga duraci\u00f3n. Para algo serio y robusto, vete a un VPS o dedicado.<\/p>\n
\nAqu\u00ed entra en juego el hardware (RAM y CPU) y lo optimizado que est\u00e9 tu c\u00f3digo. Node.js se defiende bien por ser as\u00edncrono, pero cada conexi\u00f3n come memoria. En un servidor bien tuneado puedes manejar miles sin problemas.<\/p>\n<\/div>\nConclusi\u00f3n<\/h2>\n