Consigna y contexto
Una gateway HTTP/3 maneja conexiones de larga duración y solicitudes multiplexadas. Durante un despliegue, debe rechazar nuevo trabajo, finalizar las solicitudes aceptadas y cerrarse de forma segura tras un tiempo límite. Diseñe un apagado gradual con GOAWAY de RFC 9114 y explique su límite con el cierre de conexión QUIC y los reintentos de HTTP.
Qué está evaluando el entrevistador
Distinguir GOAWAY, que limita solicitudes futuras, de CONNECTION_CLOSE, que finaliza la conexión QUIC. GOAWAY de HTTP/3 transporta un límite de ID de flujo de solicitud; un servidor puede comenzar con un valor más amplio y reducirlo hasta un límite final. Cubra flujos concurrentes, el conocimiento del cliente sobre solicitudes no procesadas, idempotencia, propagación en proxies, tiempos de espera y observabilidad.
Preguntas aclaratorias para hacer primero
Forma de las solicitudes y conexiones
Pregunte sobre sondeo largo (long polling), cargas de archivos, WebTransport, POSTs no idempotentes y proxies inversos. El tiempo de finalización y el riesgo de reintento difieren según el tipo de flujo.
Objetivo de drenado y tiempos límite
Aclare si se trata de drenado de conexiones, mantenimiento de nodos o aislamiento de fallas. Establezca un plazo máximo de drenado, un plazo de cierre forzado (hard-close) y el tamaño del lote de despliegue; de lo contrario, las conexiones antiguas pueden consumir capacidad indefinidamente.
Capacidad del cliente
Confirme que los clientes y proxies procesen GOAWAY, admitan reconexión y migración, y puedan distinguir entre “nuevo flujo rechazado” y “solicitud ejecutada pero respuesta perdida”.
Estructura de respuesta de 30 segundos
“GOAWAY de HTTP/3 anuncia un límite de ID de flujo de solicitud; tras recibirlo, un par no debe crear nuevas solicitudes por encima de ese límite. El servidor primero envía un valor amplio, deja de asignar nuevo trabajo y luego envía un valor final menor para que el cliente sepa qué solicitudes podrían no haber sido aceptadas. Los flujos aceptados se drenan; tras el tiempo límite, el servidor utiliza CONNECTION_CLOSE de QUIC. Un cliente reintenta únicamente cuando puede comprobar que una solicitud no fue ejecutada y que la operación es segura de repetir”.
Respuesta detallada paso a paso
Paso 1: Separar GOAWAY de CONNECTION_CLOSE
GOAWAY es un mensaje de control de HTTP/3 que limita el ID de flujo de solicitud más alto; no termina la conexión de inmediato. CONNECTION_CLOSE finaliza QUIC y puede interrumpir solicitudes activas. Drene primero con GOAWAY y cierre únicamente al cumplirse el tiempo límite estricto.
Paso 2: Usar un límite amplio y luego estrecho
Envíe un ID grande que cubra las solicitudes concurrentes observadas, deje de aceptar nuevo trabajo y luego envíe un ID final más pequeño. El cliente no debe interpretar el proceso de reducción como un permiso para crear nuevas solicitudes. Mantenga el orden y el estado de las tramas de control para que la lógica de reconexión sea determinista.
Paso 3: Manejar solicitudes aceptadas, no iniciadas y desconocidas
Los flujos aceptados por debajo del límite final continúan. Las solicitudes por encima de este no fueron aceptadas y pueden reintentarse en una nueva conexión. Si el servidor no puede saber si una solicitud no idempotente se ejecutó, exponga una clave de idempotencia o una consulta de estado en lugar de reintentar a ciegas.
Paso 4: Diseñar el comportamiento de proxies y migración
Un proxy inverso que recibe un GOAWAY ascendente debe dejar de asignar nuevas solicitudes a esa conexión y propagar el estado de drenado hacia los clientes descendentes. La migración de conexiones QUIC no es una migración de solicitudes; cambiar de ruta no transfiere de forma segura un flujo HTTP en ejecución.
Paso 5: Establecer tiempos límite de drenado y cierre forzado
Registre la hora de GOAWAY, el último flujo activo y las solicitudes restantes. Al agotarse el tiempo de drenado, cancele los flujos no finalizados; al cumplirse el tiempo de cierre forzado, envíe CONNECTION_CLOSE y libere la conexión. Limite la cantidad de instancias que se drenan simultáneamente para que la capacidad no colapse.
Paso 6: Proteger los reintentos y los efectos secundarios
Reintente únicamente métodos idempotentes con confirmación de no haber sido ejecutados o escrituras que incluyan una clave de idempotencia, con retroceso exponencial y un presupuesto de reintentos. Una respuesta perdida no prueba que la solicitud no se haya ejecutado; los pagos y las modificaciones de inventario requieren deduplicación del lado del servidor.
Paso 7: Verificar el despliegue
En un canary, inyecte solicitudes largas, flujos concurrentes, reconexiones, valores reducidos de GOAWAY, propagación en proxies y cierre forzado. Monitoree nuevos flujos rechazados, duración del drenado, flujos no finalizados, tasa de reintentos, efectos secundarios duplicados, errores de conexión y margen de capacidad. Verifique la latencia p99 y la tasa de errores a lo largo del despliegue.
Respuesta de ejemplo de alta calidad
Detendría la asignación de nuevas conexiones, enviaría un GOAWAY amplio para frenar nuevos flujos y luego enviaría un límite final menor tras observar las solicitudes concurrentes. Los flujos aceptados por debajo del límite se drenan; solo tras el tiempo límite se cancelan y se cierra la conexión QUIC. Los clientes reintentan únicamente operaciones idempotentes confirmadas como no ejecutadas, utilizando claves de idempotencia para escrituras no idempotentes. Los proxies propagan el estado de drenado, mientras que la migración nunca se trata como una transferencia de solicitudes. Las pruebas canary cubren solicitudes largas, flujos concurrentes, reintentos, comportamiento de proxies y efectos duplicados.
Errores comunes
- Error: Cerrar QUIC inmediatamente después de GOAWAY. → Por qué falla: Se interrumpen las solicitudes activas. → Solución: Drenar primero y cerrar al alcanzar el tiempo límite estricto.
- Error: Tratar el límite de GOAWAY como un registro de ejecución. → Por qué falla: Un ID de flujo expresa un rango, no la finalización en la aplicación. → Solución: Confirmar con el estado de la aplicación y claves de idempotencia.
- Error: Reintentar cada solicitud fallida. → Por qué falla: Una respuesta perdida puede ocurrir después de haberse producido un efecto secundario. → Solución: Limitar los reintentos a operaciones idempotentes o con clave.
- Error: Asumir que la migración de conexión transfiere solicitudes activas. → Por qué falla: Un cambio de ruta no modifica el estado del flujo HTTP. → Solución: Usar una nueva conexión para reintentos seguros.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué pueden reducirse los valores de GOAWAY?
El servidor puede primero cubrir las solicitudes concurrentes observadas y luego establecer el límite final para nuevos flujos. La reducción permite que el cliente converja sin tener que adivinar todo el trabajo en tránsito en la primera señal.
Pregunta de seguimiento 2: ¿Cómo sabe un cliente si una solicitud fue aceptada?
Comparar un ID de flujo con el límite final identifica un rango posible, no si se ejecutó el código de la aplicación. Combínelo con la respuesta, el error de conexión y una consulta de estado de idempotencia.
Pregunta de seguimiento 3: ¿Se propaga GOAWAY automáticamente a través de los proxies?
No debe asumirse. Un proxy es un endpoint HTTP/3 independiente y debe traducir el drenado ascendente en políticas de conexión y enrutamiento descendentes.
Pregunta de seguimiento 4: ¿Por qué cancelar los flujos antes del cierre forzado?
La cancelación libera recursos de la aplicación y registra un motivo claro, lo que permite a los clientes distinguir un tiempo de espera de drenado de una falla de red. El cierre de QUIC es el límite final de la conexión, no un mecanismo de limpieza de la aplicación.