Entrevista de Backend: ¿Cómo ejecutarías WebSockets sobre HTTP/2 Extended CONNECT?

Prompt y contexto

Un gateway y sus clientes soportan HTTP/2, y un servicio en tiempo real necesita multiplexar streams de WebSocket en una sola conexión. Diseña una migración a RFC 8441: handshake, negociación de capacidades, compatibilidad con proxies, cierre de streams versus cierre de conexión, fallback y métricas de aceptación. Esta es una pregunta de backend sobre la semántica de extended-connect en HTTP/2.

Qué evalúa el entrevistador

1. Distinguir Extended CONNECT de HTTP/1.1 Upgrade.
2. Usar :protocol y SETTINGS_ENABLE_CONNECT_PROTOCOL correctamente.
3. Separar el cierre de streams HTTP/2 del cierre de la conexión.
4. Diseñar mecanismos de fallback para proxies y clientes no compatibles.
5. Medir el handshake, los errores de stream, la reutilización y la latencia.

Preguntas aclaratorias para hacer

• ¿El cliente, el proxy perimetral, el balanceador de carga, el gateway y el origen soportan RFC 8441?
• ¿Pueden las solicitudes ordinarias y los streams de WebSocket compartir una misma conexión HTTP/2?
• ¿El balanceador de carga preserva HTTP/2 de extremo a extremo o lo termina y reconstruye?
• ¿Los clientes antiguos pueden seguir utilizando HTTP/1.1 Upgrade?
• ¿El cliente es un navegador, un SDK nativo o una implementación RPC interna?

Una respuesta de 30 segundos

“Verificaría SETTINGS_ENABLE_CONNECT_PROTOCOL en cada salto. Un cliente compatible envía Extended CONNECT con :protocol = websocket; tras completarse con éxito, ese stream HTTP/2 transporta tramas de WebSocket. Un salto sin soporte recurre a HTTP/1.1 Upgrade. Cancelar un stream no debe cerrar toda la conexión. Durante el despliegue canary, monitorearía el éxito del handshake, el fallback, RST_STREAM, GOAWAY, la reutilización y la latencia del primer mensaje”.

Respuesta detallada

Paso 1: Negociar el soporte de la extensión

Los endpoints anuncian Extended CONNECT mediante HTTP/2 SETTINGS. El cliente envía el pseudo-encabezado :protocol únicamente tras confirmar el soporte; un proxy que elimine esta configuración debe desencadenar un fallback en lugar de una solicitud inválida.

SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
:method = CONNECT
:protocol = websocket
:authority = chat.example

El fragmento muestra los campos del handshake; el orden de las tramas sigue rigiéndose por HTTP/2 y RFC 8441.

Paso 2: Manejar el handshake y los datos del stream

Un Extended CONNECT exitoso crea un stream HTTP/2 que transporta la semántica de tramas WebSocket. No utiliza Connection, Upgrade, Sec-WebSocket-Key de HTTP/1.1 ni la ruta 101. El servidor sigue autenticando, validando el origen y negociando subprotocolos y extensiones.

Paso 3: Separar los ciclos de vida

Un RST_STREAM o el cierre normal de un stream afecta a un solo WebSocket, no a las demás solicitudes en la conexión. GOAWAY impide nuevos streams; los streams existentes requieren una política de finalización, migración o reconexión. La lógica de reconexión debe evitar reenviar mensajes que ya hayan sido confirmados.

Paso 4: Diseñar el fallback para proxies

Construye una matriz de capacidades para clientes, CDNs, balanceadores de carga y gateways. Si algún salto carece de soporte, utiliza HTTP/1.1 Upgrade o devuelve un error claro de falta de compatibilidad; no reenvíes :protocol como un encabezado ordinario. Conserva la autenticación, las validaciones de origen, los subprotocolos y el comportamiento de heartbeat en ambas rutas.

Paso 5: Control de flujo y contrapresión (backpressure)

Aplican tanto las ventanas de control de flujo de HTTP/2 como la cola de la aplicación. Delimita los buffers por stream y por conexión, observa los bloqueos de ventana y asegúrate de que un stream lento no bloquee las solicitudes ordinarias que comparten la conexión.

Paso 6: Canary y verificaciones de seguridad

Comienza con clientes internos y una sola región. Compara Extended CONNECT con HTTP/1.1 Upgrade en cuanto a éxito del handshake, latencia del primer mensaje, reconexiones, RST_STREAM, GOAWAY y errores de proxy. Los límites de TLS, origen, autenticación, subprotocolos y tamaño de mensaje se mantienen sin cambios.

Paso 7: Definir rollback y criterios de aceptación

Mantén un interruptor a nivel de cliente o de región para desactivar WebSockets sobre HTTP/2. Prueba escenarios de ausencia de SETTINGS, protocolos rechazados, cancelación de streams, GOAWAY, cambios de red y reconexiones duplicadas. Compara el orden de los mensajes, la latencia p95, el recuento de conexiones y la tasa de fallback antes de expandir el despliegue.

Respuesta modelo

“Establecería una matriz de capacidades de extremo a extremo y exigiría SETTINGS_ENABLE_CONNECT_PROTOCOL en cada salto. Los clientes compatibles envían Extended CONNECT con :protocol = websocket; el stream HTTP/2 exitoso transporta tramas de WebSocket, mientras que las rutas no compatibles utilizan HTTP/1.1 Upgrade. La autenticación, el origen, los subprotocolos, el heartbeat y los límites de tamaño se mantienen iguales.

RST_STREAM solo afecta a un WebSocket; GOAWAY afecta a los nuevos streams y requiere una política de finalización o reconexión. El canary mide el handshake, el fallback, las reconexiones, el p95 del primer mensaje, la reutilización y los errores de proxy, inyectando escenarios de ausencia de SETTINGS, protocolos rechazados, streams lentos y cambios de red”.

Errores comunes

• Tratar Extended CONNECT como un encabezado normal → los proxies pueden rechazarlo o enrutarlo mal → valida SETTINGS y los pseudo-encabezados.
• Enviar encabezados Upgrade de HTTP/1.1 → HTTP/2 no utiliza ese handshake → sigue RFC 8441.
• Cerrar la conexión ante un RST_STREAM → fallan solicitudes no relacionadas → separa el estado del stream del de la conexión.
• Ignorar GOAWAY → la reconexión y la finalización se vuelven ambiguas → define una política de ciclo de vida.
• Probar únicamente conexiones directas → las diferencias entre CDNs y balanceadores de carga rompen producción → prueba cada salto.
• Omitir la autenticación durante la migración → la extensión no altera los requisitos de seguridad de WebSocket → reutiliza la política existente.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no usar directamente WebSockets sobre HTTP/3?

RFC 9220 define la ruta para HTTP/3. RFC 8441 es un paso práctico cuando la infraestructura existente de extremo a extremo es HTTP/2; el soporte disponible y el costo de migración determinan la decisión.

Pregunta de seguimiento 2: ¿Puede un cliente intentar Extended CONNECT sin la configuración previa?

No. Se debe esperar la señal de capacidad y luego recurrir al fallback o reportar falta de soporte en lugar de enviar una solicitud inválida para el protocolo.

Pregunta de seguimiento 3: ¿Cómo se evitan mensajes duplicados tras un GOAWAY?

Usa números de secuencia del cliente o claves de idempotencia, persiste los offsets confirmados y reanuda desde un punto definido tras la reconexión.

Pregunta de seguimiento 4: ¿Cómo se localiza un proxy incompatible?

Captura SETTINGS, respuestas CONNECT y códigos de error salto por salto, segmentando por proxy, región y versión del cliente.