≡En resumen
- WebSocket abre una conexión persistente y bidireccional: cliente y servidor pueden enviar mensajes cuando quieran.
- Nace para sustituir el HTTP polling, que obligaba a preguntar al servidor una y otra vez si había novedades.
- Si solo necesitas que el servidor envíe datos al navegador, Server-Sent Events (SSE) es más simple.
- En producción usa siempre wss://, autentica la conexión y valida el origen en el servidor.
- Para audio y vídeo entre usuarios se usa WebRTC; WebSocket suele servir de canal de señalización.
01 ¿Qué son los WebSockets?
WebSockets es el nombre que se da tanto al protocolo WebSocket como a la interfaz de programación que usan los navegadores para abrir estas conexiones. Resuelven un problema que la web arrastró durante años: HTTP funciona por petición y respuesta, así que el servidor no puede avisar al navegador de algo nuevo si el navegador no pregunta primero.
El propio RFC 6455 explica su motivación: la comunicación bidireccional en la web obligaba a abusar de HTTP para sondear al servidor, y WebSocket ofrece una alternativa al polling para la comunicación en dos sentidos.
02 ¿Cómo funciona WebSocket? Handshake y mensajes
-
1
El cliente pide el cambio de protocolo
Envía una petición HTTP GET con las cabeceras Upgrade: websocket, Connection: Upgrade y una clave aleatoria en Sec-WebSocket-Key.
-
2
El servidor acepta
Responde con el código 101 Switching Protocols y la cabecera Sec-WebSocket-Accept, calculada a partir de la clave y un identificador fijo definido en el RFC.
-
3
La conexión queda abierta
Desde ese momento ya no se habla HTTP: ambos extremos intercambian tramas (frames) sobre la misma conexión TCP.
-
4
Se envían mensajes en ambos sentidos
Las tramas pueden ser de texto (normalmente JSON) o binarias, y el cliente debe enmascarar todas las que envía al servidor.
-
5
Latidos y cierre
Las tramas ping y pong comprueban que la conexión sigue viva, y una trama de cierre la termina de forma ordenada.
| Código (opcode) | Tipo | Para qué sirve |
|---|---|---|
| 0x1 | Texto | Mensajes en UTF-8, habitualmente JSON |
| 0x2 | Binario | Datos binarios, como audio o estructuras comprimidas |
| 0x8 | Cierre | Termina la conexión de forma ordenada |
| 0x9 y 0xA | Ping y pong | Comprueban que la otra parte sigue conectada |
const ws = new WebSocket("wss://ejemplo.com/chat");ws.onmessage = (e) => mostrar(JSON.parse(e.data));ws.send(JSON.stringify({ tipo: "mensaje", texto: "Hola" }));
El formato de los mensajes lo decide tu aplicación; lo más común es JSON con un campo que indica el tipo de evento.
03 WebSocket vs HTTP polling vs Server-Sent Events
Antes de WebSocket, las aplicaciones simulaban el tiempo real con polling (preguntar cada pocos segundos) o long polling (dejar la petición abierta hasta que hubiera novedades). Hoy la alternativa más habitual a WebSocket es Server-Sent Events (SSE), un canal en un solo sentido del servidor al navegador sobre HTTP normal, con el tipo de contenido text/event-stream.
| Técnica | Dirección | Cómo funciona | Cuándo usarla |
|---|---|---|---|
| HTTP polling | Cliente pregunta | Peticiones repetidas cada X segundos | Datos que cambian poco y sin prisa |
| Long polling | Cliente pregunta, servidor retiene | La respuesta se envía cuando hay novedades y el cliente vuelve a preguntar | Compatibilidad con infraestructuras antiguas |
| Server-Sent Events | Solo servidor a cliente | Una respuesta HTTP que se mantiene abierta y envía eventos | Notificaciones, feeds, progreso de tareas, respuestas de IA en streaming |
| WebSocket | Bidireccional | Conexión persistente tras un handshake HTTP | Chats, colaboración, juegos, paneles con acciones del usuario |
| WebRTC | Entre navegadores | Audio, vídeo y datos punto a punto | Videollamadas y transmisión de medios |
04 Para qué sirven los WebSockets: usos reales
Chat y atención al cliente
Mensajes instantáneos, indicador de «escribiendo» y confirmaciones de lectura en tiempo real.
Colaboración
Documentos, pizarras o tableros que varios usuarios editan a la vez y ven cambiar al momento.
Paneles en vivo
Cotizaciones, seguimiento de flotas, pedidos de cocina o métricas de un sistema que se actualizan sin recargar.
Juegos multijugador
Posiciones y acciones de los jugadores enviadas en milisegundos en ambos sentidos.
Señalización de videollamadas
El intercambio inicial que necesita WebRTC para conectar a dos usuarios suele viajar por un WebSocket.
Notificaciones dentro de la app
Avisos mientras el usuario tiene la web abierta; con la web cerrada se necesitan notificaciones push.
En las videollamadas, el audio y el vídeo no viajan por el WebSocket sino por WebRTC, directamente entre los participantes. Y una diferencia importante con las notificaciones push: un WebSocket solo existe mientras la página o la app está abierta. Para avisar a un usuario que no está conectado hace falta el servicio push del sistema operativo o del navegador.
05 Cómo se implementa: servidor, escalado y seguridad
En el servidor, WebSocket encaja de forma natural en entornos orientados a eventos como Node.js, aunque hay implementaciones en casi todos los lenguajes y servicios gestionados que se encargan de mantener las conexiones. En muchas aplicaciones conviven dos canales: una API HTTP para leer y guardar datos, y un WebSocket para avisar de los cambios.
- ✓Usa siempre wss:// (cifrado con TLS) en producción.
- ✓Autentica la conexión con un token de sesión y comprueba permisos en cada mensaje, no solo al conectar.
- ✓Valida la cabecera Origin en el servidor para evitar conexiones desde webs ajenas.
- ✓Limita el tamaño y la frecuencia de los mensajes para frenar abusos.
- ✓Programa reconexión automática con espera creciente en el cliente.
- ✓Si tienes varios servidores, comparte los mensajes entre ellos con un sistema de publicación y suscripción.
- ✓Cierra la conexión cuando el usuario abandona la página: una conexión abierta puede impedir que el navegador guarde la página en su caché de navegación.
06 WebSocket hoy: HTTP/2, HTTP/3 y WebTransport
El RFC 6455 original funciona sobre HTTP/1.1. El RFC 8441 (2018) permitió abrir WebSockets dentro de una conexión HTTP/2 mediante un CONNECT extendido, y el RFC 9220 (2022) hizo lo mismo para HTTP/3. La documentación de MDN señala dos limitaciones de la interfaz clásica: no gestiona la contrapresión (si llegan mensajes más rápido de lo que se procesan, se acumulan en memoria) y por eso existen WebSocketStream, todavía no estándar, y WebTransport, que MDN presenta como candidato a sustituir a WebSocket en muchas aplicaciones.
Para la mayoría de proyectos, WebSocket sigue siendo la opción más compatible y documentada. Si estás planteando un producto con chat, colaboración o paneles en vivo, un equipo de desarrollo de aplicaciones web a medida puede ayudarte a elegir entre WebSocket, SSE o un servicio gestionado, y a llevar lo mismo a móvil dentro de un proyecto de desarrollo de aplicaciones móviles.
Preguntas frecuentes sobre WebSockets
Es un protocolo definido en el RFC 6455 que mantiene abierta una conexión bidireccional entre navegador y servidor, para que ambos puedan enviarse mensajes en tiempo real sin nuevas peticiones HTTP.
Para aplicaciones que necesitan intercambiar datos al instante en los dos sentidos: chats, edición colaborativa, juegos multijugador, paneles en vivo y señalización de videollamadas.
HTTP sigue un modelo de petición y respuesta iniciado siempre por el cliente. WebSocket empieza con una petición HTTP, pero después mantiene la conexión abierta y cualquiera de los dos extremos puede enviar datos cuando quiera.
WebSocket es bidireccional; SSE solo envía datos del servidor al navegador. SSE es más simple y funciona sobre HTTP normal, así que basta cuando el cliente solo necesita escuchar.
WebSocket conecta navegador y servidor para enviar mensajes. WebRTC conecta navegadores entre sí para audio, vídeo y datos; a menudo usa un WebSocket para la señalización inicial.
Lo son si se usan con wss:// (cifrado TLS), autenticación, validación del origen y control de permisos en cada mensaje. Sin esas medidas, una conexión abierta es una puerta de entrada más.
Por defecto el 80 para ws:// y el 443 para wss://, los mismos que HTTP y HTTPS, lo que facilita atravesar cortafuegos.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗