Las claves verificadas
- WebSocket abre una sesión bidireccional en la que navegador y servidor pueden enviar y recibir mensajes sin polling. Ver evidencia
- El protocolo WebSocket usa un handshake de apertura y un mecanismo de tramas sobre TCP. Ver evidencia
- Sec-WebSocket-Key y Sec-WebSocket-Accept participan en el handshake HTTP de WebSocket. Ver evidencia
- La especificación WebSockets define el comportamiento de las conexiones WebSocket en la plataforma web. Ver evidencia
Qué es WebSocket y qué cambia frente a una petición HTTP
WebSocket permite abrir una sesión de comunicación bidireccional entre un navegador y un servidor. Después de conectarse, ambos extremos pueden enviar mensajes sin que el navegador tenga que consultar una y otra vez si hay novedades. Es útil cuando la aplicación necesita recibir cambios mientras está abierta.
También puede servirte: Qué es un webhook y en qué se diferencia de una API
La conexión comienza con un handshake HTTP y pasa a usar el protocolo WebSocket. El estándar define tramas de mensajes sobre TCP. Eso no convierte cada aplicación en tiempo real por sí solo: el servidor, la red y la forma de procesar las actualizaciones siguen influyendo en la demora observable.
WebSocket, polling y webhook no resuelven lo mismo
Con polling, el navegador abre solicitudes repetidas para preguntar si hay cambios. WebSocket mantiene una conexión y admite mensajes en ambos sentidos. Un webhook, en cambio, entrega un evento desde un servicio a una URL configurada; está pensado para integraciones entre servidores, no para actualizar directamente la pantalla de un navegador.
Un tablero colaborativo, un chat o una cotización que debe actualizarse mientras se mira la pantalla pueden aprovechar una conexión persistente. Si un dato se consulta de manera ocasional o a pedido, una API HTTP común suele ser más simple. La elección depende de la frecuencia, número de conexiones y necesidad de que el servidor inicie mensajes.
Guía para decidir si hace falta WebSocket
Antes de implementarlo, definí si la interfaz necesita recibir eventos durante una sesión activa. Si la respuesta es sí, detallá qué mensajes viajan, quién puede abrir la conexión, cuándo se reintenta y cómo se recupera el estado después de una desconexión. Mantener conexiones abiertas requiere monitoreo y límites del lado del servidor.
La API WebSocket habitual no incorpora backpressure, según MDN: si los mensajes llegan más rápido de lo que la página puede procesar, puede acumular trabajo. Por eso conviene diseñar mensajes pequeños, manejar reconexiones y no usar una conexión permanente cuando un intercambio puntual por HTTP responde mejor a la necesidad.
Qué aporta VisteEsto: Nuestro trabajo en esta nota
VisteEsto separa WebSocket, polling y webhook y ofrece una guía de decisión basada en dirección, persistencia y frecuencia de los mensajes.
Fuentes, actualizaciones y metodología 3 fuentes
Fuentes consultadas
- Fuente secundariaMDN: WebSocket API
- Fuente primariaRFC 6455: The WebSocket Protocol
- Fuente primariaWHATWG: WebSockets Standard
Historial de actualización
- Publicación inicial con fuentes primarias sobre el protocolo y la especificación web.
Cómo elaboramos esta nota
Definimos la consulta principal “qué es WebSocket y cuándo conviene usarlo”, contrastamos los datos con 3 fuentes —2 primarias— y revisamos contexto, imágenes y posibles vacíos antes de publicar. Conocé nuestra política editorial y de verificación.
