WebSocket
Monitoreo de WebSocket
El handshake de actualización, el socket sigue abierto un momento después, y el primer mensaje.
Pruébalo ahora
Una comprobación, desde un lugar, ahora mismo, y nada se guarda. Un monitor verifica desde cada ubicación en la que operamos y confirma un fallo desde otros dos continentes antes de que alguien sea despertado, lo cual una sola mirada no puede mostrarte.
Para qué sirve
Tu chat, tu panel en vivo, tu feed de precios, tu editor colaborativo, tu lobby de juego: todo eso es un WebSocket, y es la parte de un producto que falla mientras cada capa debajo sigue en verde. La página carga, la API responde, el certificado está bien, el puerto está abierto, y el socket nunca se abre.
O se abre y se cierra de nuevo doscientos milisegundos después, que desde el lado del usuario es una pantalla que deja de actualizarse silenciosamente y que nadie reporta como un outage. Refrescan, funciona por un minuto, se rinden. Así que esto no se detiene en el handshake: observa el socket por un momento después, de la misma manera que la verificación TCP puede insistir en un saludo en lugar de estar satisfecho con un puerto abierto.
Y el que realmente hace que la gente pierda dinero: el feed que está conectado y ha dejado de publicar. Danos un mensaje para enviar y un patrón que la respuesta debe coincidir, o solo un patrón, y un feed silencioso es un fallo en lugar de una fila verde que parece saludable.
Como cada chequeo aquí, se ejecuta desde Amsterdam, New York, Sydney and Singapore, y un fallo se confirma desde otros dos continentes antes de despertar a nadie. Cómo funciona.
Lo que puedes configurar
Todo lo siguiente está en el formulario cuando añades uno, en todos los planes.
- Dirección
- Una dirección ws:// o wss://, con la ruta. Un host y puerto es la verificación TCP, que es una pregunta diferente.
- Enviar esto primero
- Un frame de texto, enviado tan pronto como el socket se abre, para un endpoint que responde en lugar de publicar.
- Mensaje esperado
- Una expresión regular que un frame debe coincidir. Rellenarla es lo que hace que un frame sea necesario.
- Cuánto tiempo esperar por ello
- Segundos. Separado del timeout de conexión, porque un feed que publica cada treinta segundos es saludable y fallaría un límite de tiempo tipo handshake.
- Timeout
- Cuánto tiempo puede tomar el handshake en sí.
- Confirmaciones
- Cuántos otros continentes deben estar de acuerdo antes de que alguien sea despertado.
Preguntas
¿Por qué no puedo simplemente apuntar el monitor HTTPS hacia él?
Porque la respuesta saludable se registraría como una interrupción. Un WebSocket comienza como un HTTP GET con Upgrade: websocket y un Sec-WebSocket-Key, y un servidor que responde a un GET simple con 400 o 426 está funcionando exactamente como debería. Un monitor HTTPS ve ese código de estado y te informa como offline mientras todo funciona perfectamente.
¿Qué hace realmente la verificación?
Completa el handshake de actualización, lo que significa un 101 con el Sec-WebSocket-Accept derivado de la clave que envió, y luego mantiene el socket un momento para ver si permanece abierto. Después cuelga. No mantiene una conexión entre revisiones, así que nada de esto parece un cliente para tu servidor.
Mi feed está silencioso la mayor parte del tiempo. ¿Eso fallará?
No. Un socket que se abre y no dice nada está saludable a menos que completes un mensaje esperado, porque un feed sin nada que publicar no es un feed roto. Complétalo y las reglas cambian a propósito: entonces se requiere un frame dentro del tiempo de espera que configures, que es como detectas un feed que está conectado y se ha detenido.
¿Cuál es la diferencia entre 1000 y 1011 en un cierre?
1000 es un cierre normal y 1011 es el servidor diciendo que encontró una condición de la que no pudo recuperarse, y ambos llegan como un socket que se fue. El código de cierre y la razón están en el fallo, en lugar de ser simplificados como desconectado, porque dirigen a quien lo está arreglando a dos lugares diferentes.
¿Soportas Socket.IO, SignalR, STOMP o MQTT?
No, y lo decimos en lugar de insinuar lo contrario. Esas son estructuras sobre WebSocket, cada una con su propio handshake y su propia idea de un namespace, y una revisión que las hable a medias sería peor que una que no lo haga. La revisión básica aún te dice que el transporte debajo de ellas está activo.
¿Revisa el certificado en una dirección wss://?
Sí. Una conexión wss:// se verifica contra el almacén de confianza pública como cualquier otra, así que un certificado expirado, uno autofirmado o un error de coincidencia de hostname falla la revisión. Los días restantes son una pregunta para un monitor de certificados, y vale la pena ejecutarlo junto a este.
¿Puedo revisar un socket en mi propia red?
No, y esta es la negativa de la que menos nos arrepentimos. Un WebSocket hacia una dirección interna es un túnel bidireccional de larga duración abierto por nuestra infraestructura según un horario, lo que es una versión peor de una falsificación de solicitud del lado del servidor que una consulta única. La dirección se resuelve inmediatamente antes de conectar y se rechaza una privada.
Mi cliente se reconecta solo. ¿Por qué vigilar el socket también?
Debería, y un cliente sin lógica de reintento es el problema más grande de los dos, así que ese trabajo no se desperdicia. Sí significa que tu cliente oculta exactamente lo que vale la pena saber. Un socket que acepta una conexión, la mantiene por treinta segundos y la cierra hará que un cliente que se reconecta parezca casi conectado durante horas, mientras que cada mensaje enviado en los intervalos se pierde. Esto conecta, completa el handshake y mantiene el socket, así que un servidor que falla de esta manera falla la revisión en lugar de ser encubierto por la lógica de reintento del otro lado.