Qué son los WebSockets y por qué no son HTTP más rápido

El error que comete casi todo el mundo

Hay una frase fuerte que circula y que comparto: casi todos los desarrolladores no entienden los WebSockets. Los tratan como una especie de HTTP un poco más rápido, y no lo son ni de lejos. Son un cambio de fondo en cómo se comunican el navegador y el servidor.

Y no es un detalle de listillos: entenderlo de verdad cambia cómo diseñas cualquier cosa que necesite datos en vivo. Te lo voy a explicar con una analogía tonta que lo deja clarísimo, y luego te digo cuándo te interesan y cuándo no. Sin tecnicismos.

La analogía que lo explica todo

Imagina que le estás escribiendo a un amigo por mensajes. Lo normal sería que, cuando él responde, su mensaje te llega solo, ¿verdad?

Pues la web tradicional no funciona así. Funciona como si, para enterarte de si te ha respondido, tuvieras que coger el móvil cada segundo y gritar: “¿ya has contestado? ¿ya has contestado? ¿ya has contestado?”. Una y otra vez. Suena de locos. Te gastaría la batería, perderías el tiempo y tu amigo acabaría bloqueándote.

Pero eso es exactamente cómo funciona HTTP, el protocolo de la web de siempre: el cliente pregunta, el servidor responde, y cuelgan. Si quieres datos en vivo, tu navegador tiene que volver a preguntar una y otra vez. A eso se le llama polling, y es justo el “¿ya has contestado?” repetido hasta la saciedad.

Por qué HTTP se queda corto para el tiempo real

HTTP nació para algo concreto y lo hace de maravilla: pedir una página, recibirla, fin. Pregunta y respuesta. Para navegar por webs, perfecto.

El problema aparece cuando quieres datos que llegan solos, sin que tú los pidas: un mensaje de chat nuevo, la cotización de una acción que cambia, una notificación, la posición de los jugadores en una partida. Con HTTP puro, la única forma de “enterarte” es preguntar sin parar. Y eso tiene un coste:

Gasta recursos a saco: cada pregunta es una conexión nueva, con su saludo y su despedida. Multiplica eso por miles de usuarios preguntando cada segundo.
Llega tarde. Si preguntas cada segundo, en el peor caso te enteras un segundo tarde. Para un chat o un juego, eso se nota.
Es absurdo. La mayoría de las veces preguntas “¿hay algo nuevo?” y la respuesta es “no”. Esfuerzo tirado.

Por eso, montar tiempo real sobre HTTP a base de preguntar es como el del móvil gritando: funciona, pero es un disparate.

Qué son los WebSockets de verdad

Aquí entran los WebSockets, y la diferencia es de concepto, no de velocidad. Un WebSocket abre una conexión permanente y bidireccional entre el navegador y el servidor. En vez de “pregunto, respondes, colgamos” mil veces, se abre una línea y se queda abierta.

Volviendo a la analogía: en lugar de gritarle a tu amigo cada segundo, es como tener una llamada de teléfono abierta entre los dos. Cualquiera puede hablar cuando quiera, y el otro lo oye al instante, sin tener que preguntar. El servidor puede mandarte datos en el momento en que ocurren, sin que tú los pidas, y tú puedes mandarle a él igual. Las dos direcciones, a la vez, por la misma línea.

Esa es la diferencia que casi nadie pilla: no es “HTTP más rápido”, es otra forma de comunicarse. HTTP es mandarse cartas; WebSocket es tener una llamada abierta.

Cuándo usarlos (y cuándo no)

Que sean geniales no significa usarlos para todo. La regla es simple:

Usa WebSockets cuando necesites tiempo real de verdad: chats, notificaciones instantáneas, juegos multijugador, cotizaciones en vivo, edición colaborativa (varios escribiendo a la vez), paneles que se actualizan solos. Todo lo que sea “datos que llegan cuando ocurren”.
Quédate con HTTP normal para lo de siempre: cargar una página, enviar un formulario, pedir datos cuando el usuario hace clic. Si la comunicación es “pregunto cuando me hace falta”, HTTP es más simple y perfecto. No metas una llamada abierta donde basta con una carta.

Meter WebSockets donde no hacen falta es complicarte la vida; no usarlos donde sí, es montar el “¿ya has contestado?” y sufrir. La gracia es saber cuál toca.

Un matiz: tampoco son la solución a todo

Que conste, los WebSockets tienen su coste: mantener miles de conexiones abiertas a la vez consume recursos en el servidor, y hay que gestionarlas con cabeza (reconexiones cuando se cae la red, caídas, escalado cuando hay mucha gente conectada). Por eso no se usan para todo, solo donde el tiempo real lo justifica de verdad. Para cargar una página o enviar un formulario, el viejo HTTP sigue siendo más simple, más barato y perfectamente válido. La clave, como casi siempre, es usar la herramienta adecuada para cada cosa y no por moda.

Lo que me llevo de todo esto

Los WebSockets no son un HTTP turbo: son una conexión abierta y de doble sentido, una llamada en vez de un intercambio de cartas. Entender esa diferencia es lo que te permite diseñar bien cualquier cosa que necesite datos en vivo, en lugar de montar parches que preguntan sin parar.

Así que la próxima vez que veas un chat que actualiza al instante o una cotización que se mueve sola, ya sabes que, casi seguro, detrás no hay nadie gritando “¿algo nuevo?” cada segundo: hay una línea abierta esperando a que pase algo. Y esa, créeme, es una forma mucho más sensata de comunicarse.

Preguntas frecuentes

¿Qué son los WebSockets?

Son una tecnología que abre una conexión permanente y bidireccional entre el navegador y el servidor. En lugar del esquema de HTTP (pregunto, respondes, colgamos), la línea se queda abierta y ambos pueden enviarse datos en el momento en que ocurren, sin tener que preguntar una y otra vez. Es como tener una llamada de teléfono abierta en vez de intercambiar cartas.

¿En qué se diferencian los WebSockets de HTTP?

HTTP funciona por pregunta y respuesta: el cliente pide, el servidor contesta y la conexión se cierra. Para datos en vivo, eso obliga a preguntar sin parar (polling), lo que gasta recursos y llega tarde. Los WebSockets mantienen una conexión abierta y de doble sentido, por la que el servidor puede enviar datos al instante en cuanto suceden. No son HTTP más rápido, son otra forma de comunicarse.

¿Cuándo conviene usar WebSockets?

Cuando necesitas tiempo real de verdad: chats, notificaciones instantáneas, juegos multijugador, cotizaciones en vivo, edición colaborativa o paneles que se actualizan solos. En general, todo lo que sean datos que deben llegar en el momento en que ocurren, sin que el usuario los pida. Para cargar páginas o enviar formularios, HTTP normal es más simple y suficiente.

¿Qué es el polling y por qué es un problema?

El polling es preguntarle al servidor “¿hay algo nuevo?” repetidamente, que es la forma de simular tiempo real con HTTP. El problema es que gasta muchos recursos (cada pregunta es una conexión nueva), introduce retraso (te enteras en la siguiente pregunta) y la mayoría de las veces la respuesta es “no”, así que es esfuerzo desperdiciado. Los WebSockets eliminan esa necesidad de preguntar.

Fuentes

Compártelo si te ha resultado útil, sobre todo con quien crea que los WebSockets son HTTP con prisa.

¿Habías pillado la diferencia, o también pensabas que eran un HTTP más rápido? Cuéntame.

Y… la próxima vez que un chat actualice solo, ya sabes que hay una línea abierta esperando.