WebSocket: limitaciones de HTTP y comunicación en tiempo real

Al finalizar este tema

Comprenderá cuáles son las limitaciones de HTTP y podrá explicar cómo las resuelve WebSocket.

¿Cómo muestra KakaoTalk los mensajes al instante?

Si envía "¿Ya comiste?" por KakaoTalk, aparece inmediatamente en la pantalla del destinatario. No tarda ni un segundo.

Sin embargo, esto no es posible con el protocolo de comunicación básico de la web, HTTP. HTTP tiene una estructura en la que el servidor solo responde cuando el cliente lo solicita. Es como una carta: solo puede recibir si alguien le envía algo, y debe preguntar primero "¿hay algo nuevo?" para obtener una respuesta.

¿Cómo implementar un chat en tiempo real con HTTP? El cliente tendría que preguntar al servidor cada 0.5 segundos: "¿hay nuevos mensajes?". Esto se llama sondeo (Polling); como sigue preguntando aunque no haya mensajes, la carga del servidor es muy alta.

Tres soluciones

SSE (Server-Sent Events) es un método en el que el servidor envía datos unilateralmente al cliente. Es adecuado cuando solo se necesita la dirección de Servidor → Cliente, como en cotizaciones bursátiles o notificaciones. Sin embargo, si el cliente necesita enviar algo al servidor, debe realizar una solicitud HTTP separada.

WebSocket es como un teléfono. Una vez establecida la conexión, ambos lados pueden hablar en cualquier momento. El cliente envía y el servidor también. La conexión permanece abierta hasta que se cierra.

Cómo funciona WebSocket

Comienza con HTTP. Se establece un protocolo de enlace (handshake) para indicar "cambiemos a WebSocket":

Cliente → Servidor: "Por favor, actualice a WebSocket" (solicitud HTTP)
Servidor → Cliente: "OK, cambio realizado" (respuesta HTTP 101)

Desde este momento, la comunicación se realiza mediante el protocolo ws:// en lugar de HTTP

Una vez establecida la conexión, no es necesario intercambiar encabezados en cada transmisión, como ocurre con HTTP. Solo se transmiten los datos, lo que reduce la sobrecarga y mejora el rendimiento.

Uso práctico

Aunque existe la API WebSocket nativa, en la práctica se suelen utilizar bibliotecas como socket.io, ya que gestionan automáticamente la reconexión en caso de pérdida de conexión, la administración de salas y otras funciones.

// Servidor (Node.js + socket.io)
io.on('connection', (socket) => {
  socket.on('chat', (msg) => {
    io.emit('chat', msg);  // Enviar a todos los clientes
  });
});

// Cliente
const socket = io('http://localhost:3000');
socket.emit('chat', '¿Ya comiste?');     // Enviar al servidor
socket.on('chat', (msg) => {           // Recibir del servidor
  console.log(msg);
});

El servidor puede enviar emit y el cliente puede enviar emit: ambos pueden enviar datos. Este es el punto clave de la comunicación bidireccional.

Cuándo usar cada protocolo

La mayoría de las funciones web son suficientes con HTTP. El criterio para decidir es: "¿Necesita el servidor enviar primero algo al cliente?".

Consideraciones al usar WebSocket

WebSocket mantiene una conexión abierta, lo que genera problemas diferentes a los de HTTP:

¿Qué pasa si la conexión se interrumpe? — Si un usuario entra en un túnel de metro, la conexión se interrumpe. En este caso, debe reconectarse automáticamente y recuperar los mensajes perdidos durante la interrupción. socket.io realiza la reconexión, pero debe implementar la recuperación de mensajes usted mismo.

¿Qué pasa si hay muchos usuarios conectados simultáneamente? — HTTP cierra la conexión después de una solicitud y respuesta, pero WebSocket mantiene una conexión abierta para cada usuario. Si hay 10.000 usuarios conectados simultáneamente, el servidor gestiona 10.000 conexiones. La gestión de recursos del servidor es más compleja que con HTTP.

Seguridad — WebSocket también debe utilizar un protocolo encriptado wss://, al igual que HTTPS. ws:// (sin encriptación) permite que los datos sean interceptados.

Puntos clave

HTTP es como una carta (se necesita una solicitud para obtener una respuesta), WebSocket es como un teléfono (ambos pueden comunicarse en cualquier momento). WebSocket realiza un "apretón de manos" con HTTP y luego cambia al protocolo ws://, y la conexión permanece abierta hasta que se interrumpe. En la mayoría de los casos, HTTP es suficiente. El criterio para decidir es: "¿Necesita el servidor enviar primero algo?".