Planteamiento y contexto
Un servicio habilita TLS 1.3 0-RTT para reducir la latencia del primer byte en conexiones reanudadas. Algunas solicitudes llegan antes de que se complete el handshake, y los datos tempranos (early data) pueden reproducirse en otra conexión. Explique cuándo una API debe devolver 425 Too Early, cómo reintenta un cliente y cómo los gateways y cada réplica del servicio se mantienen consistentes.
Esto encaja en entrevistas de backend, redes, infraestructura y seguridad. La prueba no consiste en memorizar un código de estado. Se trata de mapear el riesgo de reproducción a nivel de transporte con los efectos secundarios reales de un recurso, definiendo luego el límite entre 425, el aplazamiento (deferral), deshabilitar early data, las claves de idempotencia y la evidencia de auditoría.
Qué está evaluando el entrevistador
Una respuesta sólida indica que 425 significa que el servidor no se arriesgará a procesar una solicitud que podría ser reproducida. No es un error genérico de sobrecarga, autenticación o validación de negocio. La respuesta distingue los métodos seguros de los recursos con efectos secundarios, explica por qué solo el origen sabe si un recurso tolera early data y cubre el encabezado Early-Data, el reintento del cliente, el reenvío por gateways y la consistencia entre réplicas. También aborda tormentas de reintentos, estado compartido y efectos irreversibles.
Preguntas para clarificar primero
- ¿Llegó la solicitud realmente en early data o transporta un
Early-Data: 1de confianza? - ¿La operación muta el estado, cobra dinero, envía un pedido, emite un mensaje o desencadena un efecto secundario externo?
- ¿Puede el cliente reintentar de forma segura después del handshake, con una clave de idempotencia y un almacén de desduplicación?
- ¿Entiende el gateway 425 y Early-Data, y comparten todas las réplicas del origen una misma política?
- ¿Cómo afectan la reanudación, la carga, los tiempos de espera y los presupuestos de reintentos a la seguridad y la disponibilidad?
Una respuesta en 30 segundos
“425 es un rechazo por seguridad para una solicitud en early data que podría reproducirse, no una limitación de tasa genérica. El origen elige según el riesgo del recurso: una solicitud sin efectos secundarios o demostrablemente idempotente puede continuar o aplazarse, mientras que cobros, escrituras y acciones irreversibles deben esperar al handshake y pueden recibir 425. Un cliente que recibe 425 reintenta solo después del handshake; los gateways preservan la señal, cada réplica aplica la misma política y las claves de idempotencia junto con la desduplicación en el servidor protegen las solicitudes repetidas.”
Respuesta paso a paso
Paso 1: Identificar early data y el modelo de reproducción
TLS 1.3 0-RTT permite que un cliente envíe datos de aplicación antes de que se complete el handshake. Un handshake completado solo informa sobre los datos en esa conexión; no prueba que otra conexión no haya recibido los mismos bytes. Por lo tanto, un servicio no puede inferir unicidad a partir de una conexión exitosa.
Paso 2: Clasificar los efectos secundarios del recurso
El origen conoce la consecuencia de la reproducción para un recurso. Las lecturas, consultas y operaciones sin cambios de estado suelen tener un riesgo menor, pero verifique que las rutas de facturación y auditoría no tengan escrituras ocultas. Crear pedidos, cobrar tarjetas, emitir créditos, cambiar permisos y enviar mensajes pueden ejecutarse dos veces; rechácelos o aplácelos hasta que se complete el handshake.
Paso 3: Elegir entre aplazamiento, rechazo o deshabilitar 0-RTT
El RFC 8470 describe rechazar early data en TLS, esperar al handshake antes de procesar o devolver 425 para que el cliente reintente más tarde. Todas reducen el riesgo de reproducción; la elección depende de la política del recurso, el presupuesto de memoria, el comportamiento del cliente y la carga. No use 425 como sustituto de cada fallo de handshake.
Paso 4: Emitir 425 correctamente
Cuando una solicitud llega en early data o transporta Early-Data: 1 y no puede procesarse de forma segura, el origen devuelve 425. No es almacenable en caché por defecto, y su carga útil no es una representación de un recurso identificado. No emita 425 cuando el cliente no pueda reintentar o cuando la solicitud no fue early data, porque la recuperación puede ser imposible.
Paso 5: Definir los límites de reintento del cliente
Se espera que un cliente que usa early data reintente después de un 425, pero el reintento no debe usar early data nuevamente. Conserve la semántica de la solicitud, limite los intentos, aplique backoff y respete cancelaciones y límites de tiempo. Si la solicitud en sí no puede reintentarse de forma segura, reporte el fallo al llamador en lugar de reproducirla indefinidamente.
Paso 6: Reenviar la señal a través de gateways
Por lo general, un gateway no puede saber si un recurso en particular acepta early data. Al reenviar una solicitud que pudo haber sido reproducida, debe preservar o agregar Early-Data: 1; no debe eliminar la señal. Si el origen no admite el mecanismo, espere al handshake o rechace. Un gateway puede reintentar en nombre de un cliente solo cuando la seguridad se conoce explícitamente.
Paso 7: Mantener la consistencia entre réplicas
Cada réplica del origen, nodo de borde (edge) y worker asíncrono necesita la misma política de early data. Si una réplica aplaza mientras otra cobra de inmediato, un atacante o una diferencia de ruta puede crear efectos duplicados. Comparta la versión de la política, la clave de idempotencia, el registro de desduplicación y los campos observables entre las réplicas.
Paso 8: Probar el comportamiento de reintentos y sobrecarga
Pruebe un handshake completo, la reproducción hacia otra réplica, una solicitud que llega parcialmente antes del handshake, el reenvío en gateway, el tiempo de espera del cliente y la sobrecarga del servidor. Registre la tasa de early data, la tasa de 425, reintentos, claves duplicadas, efectos duplicados y crecimiento de colas. Bajo carga, las respuestas 425 o 503 repetidas pueden amplificar los reintentos, por lo que debe establecer presupuestos y poder deshabilitar 0-RTT globalmente.
Compensaciones y límites
0-RTT reduce la espera del primer byte en conexiones reanudadas, pero requiere análisis de reproducción, políticas consistentes y desduplicación. El nombre del método por sí solo no es suficiente: un método nominalmente seguro aún puede escribir en estados de facturación, auditoría o caché. Una política a nivel de recurso es más confiable.
Una clave de idempotencia reduce los efectos duplicados, pero no hace que toda solicitud sea apta para early data. El estado de desduplicación necesita un período de retención útil, visibilidad entre réplicas y un comportamiento definido para colisiones de claves, expiración de reintentos y fallos de almacenamiento. Para acciones irreversibles, esperar al handshake suele ser más claro que depender de una compensación compleja.
Plan de implementación y evidencia
Registre una política de early data para cada recurso: permitir, aplazar o 425. Agregue claves de idempotencia y desduplicación para escrituras, haga que el gateway propague Early-Data y registre en el origen el estado de la conexión, la versión de la política y la correlación de reintentos. Ejecute un ejercicio de reproducción entre réplicas y verifique que pedidos, cobros y mensajes no se dupliquen.
Tras el lanzamiento, observe las métricas de 425, reintentos y efectos secundarios por recurso y versión de cliente. Si los clientes violan las reglas de reintento, corrija el cliente o deshabilite 0-RTT en el borde en lugar de debilitar la protección del origen. El RFC 8470 requiere un manejo consistente entre gateway y origen, por lo que las verificaciones de despliegue deben cubrir cada ruta de ingreso.
Errores comunes y preguntas de seguimiento
Tratar 425 como limitación de tasa o sobrecarga
425 apunta a una solicitud en early data posiblemente reproducida. La alta concurrencia, una dependencia no disponible y la superación de cuotas tienen semánticas y comportamientos de backoff diferentes.
Devolver 425 para cada POST
El método es solo una pista. Decida a partir de la tolerancia a la reproducción del recurso y de una idempotencia y desduplicación confiables. Una escritura demostrablemente idempotente puede aplazarse o manejarse mediante una política específica del recurso.
Reintentar 425 usando 0-RTT nuevamente
El RFC 8470 exige que el reintento tras un 425 evite early data. De lo contrario, el cliente convierte la protección del servidor en otra oportunidad de reproducción.
Eliminar el encabezado Early-Data en un gateway
Eliminar la señal hace que el origen crea que la solicitud no atravesó early data. Conserve o agregue el encabezado, verifique el soporte de 425 en el origen y espere al handshake ante la duda.
¿Cómo demostraría que no hubo un cobro duplicado?
Ejecute un ejercicio de reproducción con una clave de idempotencia compartida entre réplicas, huella digital de la solicitud y una máquina de estados de cobro; luego verifique un único resultado de negocio final por operación. Pruebe también el fallo del almacén de desduplicación, un reintento de cliente tras tiempo de espera y entregas descendentes duplicadas; un código de estado HTTP por sí solo no es una prueba.