Probador WebSocket

Conecte a cualquier endpoint ws:// o wss://, envíe/reciba mensajes en vivo, vea historial completo con timestamps. Para depurar chat, subs GraphQL, MQTT-sobre-WS.

¿Tienes comentarios? Reporta errores, sugiere funciones o comparte tus ideas — leemos todos

Probador WebSocket - Probar Conexiones WebSocket en Tiempo Real

WebSocket es el protocolo que finalmente dio a los navegadores comunicación bidireccional en tiempo real, estandarizado en 2011 como RFC 6455 y ahora ubicuo: cada chat moderno, widget de deportes en vivo, editor colaborativo (Figma, Google Docs), feed de cotizaciones de trading, suscripción GraphQL, lobby de juego multijugador y la mayoría de sistemas de notificación en tiempo real corre sobre él. A diferencia del ciclo request-response HTTP, una conexión WebSocket queda abierta tras el handshake inicial, permite a cualquiera de las partes enviar un frame en cualquier momento, y sobrevive a proxies y firewalls corporativos porque empieza como un request HTTP Upgrade normal antes de cambiar protocolos. Depurar apps WebSocket es más difícil que depurar HTTP, sin embargo — la pestaña network de DevTools muestra el handshake pero es pobre visualizando el stream de mensajes en el tiempo. Este probador llena ese hueco. Escriba cualquier URL ws:// o wss://, haga clic en Conectar, y tiene un canal persistente en vivo: envíe mensajes de texto o JSON arbitrarios con el botón Enviar, vea cada frame enviado por el servidor aparecer en tiempo real con timestamp preciso, e identifique dirección del mensaje (enviado/recibido/eventos sistema como open/close/error) por color en el log. Útil para experimentar con echo.websocket.org durante un tutorial, validar que el bucle broadcast de su backend alcanza clientes conectados, reproducir condiciones de carrera, o observar tráfico heartbeat de un servicio con el que integra. Para trabajo de rendimiento va más allá de un cliente echo de juguete: un panel integrado de tiempo de ida y vuelta (RTT) mide los milisegundos entre cada frame JSON enviado y la siguiente respuesta recibida usando performance.now(), y luego rastrea latencia última, mínima, promedio y máxima junto a contadores de enviados/recibidos — para detectar jitter, un broker lento, o un backend que dejó de responder de un vistazo.

¿Qué es un WebSocket?

WebSocket es un protocolo que proporciona canales de comunicación full-duplex sobre una única conexión TCP. A diferencia de HTTP, que está basado en solicitud-respuesta, WebSocket permite:

- Comunicación bidireccional en tiempo real
- Conexión persistente entre cliente y servidor
- Menor latencia que polling
- Eficiente para aplicaciones en tiempo real

Usos comunes:
- Aplicaciones de chat
- Feeds y notificaciones en vivo
- Juegos en tiempo real
- Edición colaborativa
- Marcadores deportivos en vivo
- Tickers de acciones

Las URLs de WebSocket usan ws:// (inseguro) o wss:// (seguro con TLS).

¿Cómo pruebo un WebSocket?

Probar un WebSocket es simple:

1. Ingrese la URL de WebSocket (ws:// o wss://)
2. Haga clic en 'Conectar' para establecer conexión
3. Espere el estado 'Conectado'
4. Escriba un mensaje en el campo de mensaje
5. Haga clic en 'Enviar' para enviar el mensaje
6. Vea respuestas en el historial de mensajes
7. Haga clic en 'Desconectar' cuando termine

Servidores WebSocket de ejemplo para pruebas:
- ws://echo.websocket.org (devuelve mensajes de vuelta)
- wss://echo.websocket.org (echo seguro)

El historial de mensajes muestra todos los mensajes enviados y recibidos con marcas de tiempo.

¿Cómo mido la latencia de WebSocket (tiempo de ida y vuelta)?

Conéctese a un endpoint echo o heartbeat y envíe un frame: la herramienta mide los milisegundos entre su mensaje enviado y la siguiente respuesta recibida usando el reloj de alta resolución performance.now() del navegador, y muestra el resultado en el panel Latencia de Ida y Vuelta (RTT).

El panel muestra cuatro métricas en vivo:
- Última: el tiempo de ida y vuelta más reciente en ms
- Prom: la media acumulada de cada respuesta medida
- Mín/Máx: las respuestas más rápida y más lenta hasta ahora — la diferencia revela jitter
- Enviados/Recibidos: contadores totales de frames, para saber si el backend dejó de responder

Envíe varios frames para construir una muestra. Un promedio bajo y estable con un mín/máx ajustado indica un feed en tiempo real saludable; un máximo creciente o un contador de recibidos que va por detrás del de enviados apunta a un broker lento, jitter de red o un backend que cerró la conexión. Funciona mejor con endpoints echo/heartbeat donde cada frame enviado produce una respuesta (ej. wss://echo.websocket.org).

¿Cuál es la diferencia entre ws:// y wss://?

ws:// y wss:// son similares a http:// y https://:

ws:// (WebSocket):
- Conexión no cifrada
- Usa puerto 80 por defecto
- Los datos se transmiten en texto plano
- Menos seguro
- Bueno para desarrollo local

wss:// (WebSocket Seguro):
- Conexión cifrada usando TLS/SSL
- Usa puerto 443 por defecto
- Los datos están cifrados
- Más seguro
- Requerido para sitios web HTTPS
- Recomendado para producción

Los navegadores modernos requieren wss:// cuando la página web se sirve sobre HTTPS.

¿Por qué no puedo conectarme a algunos servidores WebSocket?

Los fallos de conexión pueden ocurrir por varias razones:

1. CORS/Seguridad: El servidor no permite conexiones de navegadores
2. Autenticación: El servidor requiere headers de autenticación
3. SSL/TLS: Contenido mixto (ws:// en página HTTPS)
4. Servidor Caído: El servidor WebSocket está offline
5. Firewall: El firewall de red bloquea WebSocket
6. URL Inválida: Formato de URL o puerto incorrecto

Solución de problemas:
- Verifique formato de URL (ws:// o wss://)
- Use wss:// en páginas HTTPS
- Verifique que el servidor esté ejecutándose
- Revise configuración CORS del servidor
- Pruebe echo.websocket.org para testing
- Revise la consola del navegador para errores

Probador WebSocket — Conecte a cualquier endpoint ws:// o wss://, envíe/reciba mensajes en vivo, vea historial completo con timestamps. Para — **Probador WebSocket**

¿Qué tipos de datos puedo enviar?

Este probador WebSocket envía mensajes de texto. WebSocket admite:

Mensajes de Texto:
- Texto plano
- Strings JSON
- Strings XML
- Cualquier formato de string

Mensajes Binarios:
- ArrayBuffer
- Blob
- Datos de archivo
(No admitido en este probador simple)

Formatos comunes:
- JSON: {"type": "message", "text": "Hello"}
- Texto plano: "Hello, World!"
- Comandos: "/join room123"

La mayoría de APIs WebSocket esperan formato JSON para comunicación de datos estructurados.

¿En qué se diferencia WebSocket de Server-Sent Events (SSE) y long-polling?

Los tres entregan push del servidor al navegador sin polling, pero con tradeoffs distintos. (1) WebSocket: full duplex (ambos lados hablan en cualquier momento), bajo overhead por mensaje (header de frame 2-14 bytes), payloads arbitrarios de texto o binario, protocolo de aplicación personalizado. Mejor para chat, juegos multijugador, edición colaborativa — cualquier cosa verdaderamente interactiva. (2) Server-Sent Events: solo unidireccional (servidor → cliente), API más simple (EventSource en navegadores), reconexión automática, solo texto UTF-8 plano. Mejor para feeds en vivo donde el cliente nunca habla de vuelta: precios de acciones, tickers de noticias, streaming de logs de servidor. SSE va sobre HTTP/2 plano así es más amigable con proxies intermedios. (3) Long-polling: el cliente hace un request HTTP que el servidor mantiene abierto hasta que llegan datos, luego reabre inmediatamente. Latencia y overhead más altos pero funciona en todas partes porque es HTTP plano. Las apps modernas usan WebSocket por defecto; caen a SSE para feeds unidireccionales; long-polling solo importa para entornos legacy sin soporte proxy adecuado.

¿Cuál es el tamaño máximo de mensaje y tasa que puedo pasar por un WebSocket?

El protocolo en sí permite frames de hasta 2^63 bytes — efectivamente ilimitado. Los límites reales vienen de su stack de runtime. Los navegadores limitan mensajes individuales alrededor de 64 MB antes de advertir o desconectar; el sweet spot práctico para mensajes a nivel aplicación es bajo 1 MB para evitar ahogar event loops JavaScript de un solo hilo. La librería 'ws' de Node.js tiene default 100 MB máximo pero es configurable. Para tasa, el hardware moderno sostiene 100.000+ mensajes pequeños por segundo por conexión WebSocket en localhost, cayendo a miles/seg en internet pública dependiendo del RTT. Si necesita más throughput, agrupe pequeñas actualizaciones en mensajes periódicos más grandes (ej. cadencia 16ms para clientes 60fps), use framing binario (ArrayBuffer) en lugar de JSON para evitar parsing de strings, y considere WebTransport (el sucesor basado en HTTP/3 diseñado para streams unreliable de baja latencia) para tráfico tipo juego. Evite enviar blobs masivos base64 sobre WebSocket; use una subida HTTP separada y señale finalización por el socket.

¿Mis datos están seguros?

Consideraciones de privacidad y seguridad:

- Todas las conexiones van directamente de su navegador al servidor WebSocket
- Ningún dato pasa por nuestros servidores
- No registramos ni almacenamos ningún mensaje
- Use wss:// para conexiones cifradas
- Evite enviar datos sensibles a servidores no confiables
- Los servidores de prueba pueden registrar sus mensajes

Mejores prácticas:
- Use wss:// en producción
- No envíe contraseñas o datos sensibles a servidores de prueba públicos
- Verifique autenticidad del servidor
- Use autenticación cuando sea requerida
- Pruebe con datos ficticios cuando sea posible