¿Qué es un WebSocket? Handshake, frames y datos de duplex completo

Introducción

Un WebSocket es un canal de comunicación persistente y de duplex completo que comienza con un handshake de apertura compatible con HTTP y luego intercambia frames de WebSocket. Cualquiera de los extremos puede enviar mensajes de aplicación cuando tiene datos, sin crear una nueva solicitud HTTP por cada mensaje.

El protocolo suministra enmarcado, mensajes de control, reglas de enmascarado, semánticas de cierre y campos de handshake relacionados con el origen. No define el esquema de mensaje de la aplicación, modelo de autorización, historial de eventos o estrategia de recuperación de estado. Esos permanecen como trabajo de diseño para el servicio.

El handshake de apertura

El cliente envía una solicitud HTTP con Upgrade, Connection, Sec-WebSocket-Key, Sec-WebSocket-Version y, a menudo, preferencias de origen y subprotocolo. Un servidor que acepta calcula el valor necesario Sec-WebSocket-Accept y devuelve 101 Switching Protocols.

Después de esa respuesta, las semánticas del mensaje HTTP ordinario ya no enmarcan los datos en esa conexión. RFC 6455 define el protocolo WebSocket, incluidos los campos de handshake, esquemas URI registrados, distribución de frames y códigos de cierre.

Frames y mensajes

Los datos de la aplicación se transportan en mensajes de texto o binarios. Un mensaje puede ocupar un frame o estar fragmentado a través de varios frames. Los frames de control transportan señales de cierre, ping y pong, y tienen restricciones que mantienen la gestión de conexión receptiva.

Los clientes de navegador enmascaran los frames que envían a los servidores; los servidores no enmascaran los frames enviados a los clientes. El enmascarado no es cifrado. Utiliza wss para que TLS proporcione confidencialidad, integridad y autenticación del servidor. La validación de la carga útil del mensaje sigue perteneciendo a la aplicación.

El duplex completo cambia la forma de la API

Con HTTP de solicitud-respuesta, una acción del cliente se empareja naturalmente con una respuesta. El tráfico de WebSocket puede llegar en cualquier dirección en cualquier momento, por lo que la aplicación necesita tipos de mensaje, identificadores de correlación, reglas de ordenamiento, sobres de error y negociación de versión.

Un comando debe indicar si espera un reconocimiento, un resultado o un flujo de actualizaciones. Los eventos deben incluir suficiente información de identidad y versión para aplicarse idempotentemente. Sin un contrato explícito, un socket se convierte en un flujo de objetos JSON ambiguos que es difícil de evolucionar.

Ciclo de vida de la conexión y recuperación de estado

Un WebSocket puede cerrarse debido a la política de la aplicación, implementación del servidor, estado de red inactiva, suspensión del dispositivo, comportamiento del proxy o pérdida de ruta. Los frames de ping y pong pueden probar la vitalidad, pero no restauran eventos empresariales perdidos.

Diseña la reconexión por separado de la sincronización de estado. Después de una nueva conexión, el cliente puede enviar un ID de evento visto por última vez, solicitar una instantánea o volver a suscribirse a temas. El Estándar de WebSockets de WHATWG define el comportamiento de la API del navegador mientras deja la recuperación de la aplicación al servicio.

Fronteras de seguridad

Valida el origen para los clientes de navegador, autentica al usuario, autoriza cada suscripción y comando, aplica límites de tamaño de mensaje y rechaza subprotocolos no soportados. Un socket conectado no es una autorización permanente; los permisos y la expiración de la sesión pueden cambiar mientras sigue abierto.

Evita colocar secretos duraderos en URLs porque los puntos finales pueden aparecer en los registros. Aplica límites de tasa y concurrencia por identidad, analiza las cargas útiles de manera defensiva y cierra conexiones con códigos controlados. TLS protege el transporte, mientras que la autorización comercial protege los recursos.

Escalado y presión de regreso

Un servidor WebSocket mantiene el estado de conexión para muchos clientes. Las implementaciones de múltiples instancias necesitan una capa de enrutamiento o publicación-suscripción para que un evento producido en un nodo llegue a una conexión propiedad de otro. Drenar conexiones durante la implementación también necesita un proceso explícito.

Un cliente lento puede acumular mensajes salientes más rápido de lo que la red los acepta. Limita cada cola de envío, coalescencia de actualizaciones de estado reemplazables y desconecta a los clientes que no pueden mantenerse al día bajo una política documentada. La referencia de la API de WebSocket de MDN nota que la interfaz clásica del navegador no proporciona presión de regreso incorporada.

¿Qué es un WebSocket? Plan de validación de apretón de manos, marcos y datos de doble dirección

WebSocket es de doble vía. El cliente y el servidor pueden enviar de forma independiente después del apretón de manos. Valida esa afirmación a lo largo del camino de producción completo. Comienza con un pequeño intercambio representativo, registra el comportamiento negociado en el cliente y en el borde, y confirma que la aplicación recibe los campos, marcos o eventos que espera a través de la misma puerta de enlace, proxy, punto de terminación del certificado y política de red utilizada por el tráfico real.

Convierte la primera suposición de diseño en un ejercicio de falla: Requiere wss para los endpoints de producción. Luego examina la presión de recursos alrededor de la segunda suposición: Valida los valores de Origen del navegador. Una implementación correcta debería fallar dentro de los límites documentados, liberar el estado de conexión y el búfer, y dejar un rastro que explique el resultado sin exponer credenciales o cargas útiles privadas.

La edición colaborativa y los tableros de control interactivos ejercitan diferentes partes del diseño, por lo que las pruebas de compatibilidad deberán incluir ambas formas de tráfico donde sean relevantes. Añade un navegador actual, un cliente no navegador, un camino de red más lento y el intermediario más antiguo soportado. Registra la selección de versión, la duración de conexión, la antigüedad del mensaje o respuesta, la profundidad de cola y la razón de cierre para la ruta preferida y su alternativa.

Revisa la semántica y el transporte como capas separadas durante la prueba. Una conexión exitosa no prueba que la aplicación manejó correctamente el orden, la autorización, la cancelación, la caché, la reproducción o la recuperación de estado. Del mismo modo, un error de aplicación no prueba que el protocolo negociado falló. Etiqueta las observaciones con el recurso, el alcance del usuario, la operación lógica y el identificador de conexión, luego compara lo que cada endpoint creyó que ocurrió. Esta separación hace que el trabajo de capacidad sea más útil también: los equipos pueden ver si la latencia provino de la configuración de conexión, la entrega en red, la cola, el procesamiento de la aplicación, la serialización o un receptor lento. Mantén el contenido privado fuera de la telemetría rutinaria mientras retienes suficientes datos de tiempo y resultado para reproducir la decisión.

Dónde aparece ¿Qué es un WebSocket? Apretón de manos, marcos y datos de doble dirección en la práctica

¿Qué es un WebSocket? Lista de verificación de producción de apretón de manos, marcos y datos de doble dirección

• Requiere wss para los endpoints de producción. Convierte este punto en una prueba de aceptación escrita para que los revisores puedan distinguir el comportamiento previsto de un detalle de implementación accidental.
• Valida los valores de Origen del navegador. Nombra el componente que posee la configuración y la persona o equipo que responde cuando su comportamiento observado cambia.
• Autenticar antes de aceptar suscripciones privilegiadas. Captura la señal relevante en los registros o trazas, luego verifica que la señal sobreviva a cada proxy, puerta de enlace y límite de servicio en la ruta real.
• Autoriza cada tipo de mensaje. Prueba la decisión con un caso normal, un par lento, una conexión cerrada, una entrada de gran tamaño y un desajuste de versión o capacidad.
• Establece tamaños máximos de marco y mensaje. Documenta el valor predeterminado seguro y la condición exacta que permite una excepción; las excepciones ocultas se convierten en problemas de interoperabilidad durante cambios posteriores.
• Define políticas de ping, inactividad y cierre. Verifica este comportamiento desde un navegador o cliente representativo en lugar de confiar solo en una prueba de unidad local o en una pantalla de configuración del lado del servidor.
• Colas salientes limitadas por conexión. Establece un límite de recursos finito y haz que el rechazo resultante sea visible tanto para los operadores como para la aplicación que llama.
• Versiona el contrato de mensaje de la aplicación. Preserva suficientes identificadores para correlacionar un intercambio lógico a través del cliente, borde, aplicación y cualquier trabajador asincrónico.
• Proporciona recuperación de estado basada en instantáneas o cursores. Revisa la elección después de un cambio de forma de tráfico porque la cantidad de conexiones, el tamaño de carga y la frecuencia de mensajes pueden alterar el diseño correcto.
• Drene y observe conexiones durante los despliegues. Mantenga la ruta de respaldo observable y probada para que la compatibilidad no dependa de una ruta antigua que dejó de funcionar silenciosamente.

Conclusión

WebSocket es dúplex completo. El cliente y el servidor pueden enviar de forma independiente después del apretón de manos. Las aplicaciones definen su propio contrato. El encuadre del protocolo no crea temas, comandos, permisos ni repeticiones. Aplique esos dos hechos con límites explícitos, estado observable y una ruta de respaldo que sea probada por clientes representativos en lugar de asumida por la configuración.

Referencias

• Documentación de Scrapeless Scraping Browser
• Resumen del producto Scrapeless Scraping Browser
• Guía de captura de marcos de Scrapeless WebSocket