Planteamiento y alcance
Usted es responsable de APIs de pagos, cambio de contraseñas o creación de pedidos. El edge habilita TLS 1.3 0-RTT, y un gateway puede reenviar solicitudes que contienen Early-Data: 1. Explique cuándo devolver 425, cuándo proceder y cómo reintenta el cliente una vez completado el handshake. Esto se adapta a entrevistas de backend, plataforma e infraestructura de APIs.
El RFC 8470 define 425 como la negativa del servidor a asumir el riesgo de procesar una solicitud que podría reproducirse; no es un código genérico de reintento por "servidor ocupado". Asuma que el gateway puede preservar la señal de Early-Data y que el servicio puede distinguir las operaciones de solo lectura de los efectos secundarios.
Qué está evaluando el entrevistador
- Si usted separa el beneficio de latencia de 0-RTT del riesgo de reproducción (replay risk) en lugar de tratar cada 4xx como una entrada ordinaria del cliente.
- Si puede rastrear las responsabilidades del cliente, el gateway y la aplicación en cuanto a la espera, los reintentos y la idempotencia.
- Si puede convertir las condiciones del RFC, la no capacidad de almacenamiento en caché y la temporización de reintentos en una política de API comprobable.
Una respuesta débil memoriza "425 significa Too Early". Una respuesta sólida toma una decisión a partir de los efectos secundarios, la señal Early-Data, una clave de idempotencia y una ventana de reintentos acotada, y luego explica cómo una mala configuración podría cobrarle dos veces a un cliente.
Preguntas de aclaración para hacer primero
- ¿Lleva la solicitud
Early-Data: 1, o puede el edge demostrar que llegó en early data? El RFC 8470 desaconseja inventar respuestas 425 sin esa señal. - ¿La operación crea un efecto secundario externo? La lectura de un pedido puede continuar; un cobro, un cambio de contraseña o la emisión de un cupón deben esperar al handshake o usar un registro estricto de idempotencia.
- ¿El gateway reintentará automáticamente? Si es así, verifique que reintente después del handshake y que el gateway y el SDK no realicen un reintento cada uno.
- ¿El cliente admite una clave de idempotencia y un límite de reintentos? Sin ellos, deshabilitar 0-RTT para la operación es más seguro que tratar 425 como un permiso para reintentar indefinidamente.
Una respuesta de 30 segundos
"Primero verifico que la solicitud haya llegado a través de TLS early data con Early-Data: 1, y luego clasifico sus efectos secundarios. El trabajo de solo lectura puede continuar; los pagos y cambios de contraseña esperan en el gateway o reciben un 425. El cliente reintenta solo después de que se completa el handshake, y el servicio utiliza una clave de idempotencia junto con una restricción de unicidad para evitar la ejecución duplicada. El gateway preserva la señal, posee una única política de reintentos y monitoreamos la tasa de 425, el éxito de los reintentos y los efectos secundarios duplicados. Si la cadena no puede demostrar estas condiciones, deshabilito 0-RTT para los endpoints de escritura".
Solución paso a paso
1. Identificar la señal de riesgo
El RFC 8470 exige que los intermediarios preserven el significado de Early-Data al reenviar early data. Un servicio solo debe considerar 425 cuando la solicitud podría ser reproducida. Devolver 425 sin evidencia convierte una falla de red ordinaria en un rechazo de seguridad engañoso.
2. Clasificar por efecto secundario
Clasifique los endpoints como de solo lectura, de repetición segura o no seguros de repetir. GET /orders/123 es normalmente de solo lectura; emitir un cupón de un solo uso, cobrar a una tarjeta o cambiar una contraseña no es de repetición segura. La clase no segura debe esperar a que se complete el handshake o persistir una clave de idempotencia antes de cualquier efecto secundario.
3. Asignar un único responsable del reintento
Después de un 425, el cliente espera el handshake TLS y envía la solicitud nuevamente; el reintento no debe usar early data. Un gateway puede asumir la responsabilidad de ese reintento, pero el contrato debe especificarlo; de lo contrario, tanto el gateway como el SDK pueden reintentar. Establezca un retroceso exponencial, un recuento máximo de intentos y un motivo visible para cada reintento.
4. Hacer de la idempotencia la segunda defensa
Exija una clave de idempotencia para las escrituras. El servicio almacena un registro único indexado por tenant, endpoint y clave, con al menos los estados de procesamiento, éxito y falla reintentable. Un duplicado devuelve el resultado original o una respuesta explícita de en progreso. La idempotencia no reemplaza al 425: la primera ejecución aún puede reproducirse después del commit en la base de datos y antes de que la respuesta llegue al cliente.
5. Mantener la coherencia entre gateways e instancias
Cada instancia debe aplicar la misma política de Early-Data. Si un gateway no está seguro de que el upstream comprende la señal, espera al handshake o rechaza la solicitud temprana; no debe reenviar silenciosamente una escritura a un servicio solo HTTP. Registre en los logs un ID de solicitud, el estado de Early-Data, el motivo del 425 y un hash de la clave de idempotencia, nunca el contenido del pago.
6. Probar las rutas de falla
Pruebe solicitudes con y sin Early-Data: 1, el primer reintento después del handshake, reintentos del gateway, un timeout del cliente seguido de un reenvío y dos instancias compitiendo por una misma clave de idempotencia. Valide que un efecto secundario no seguro ocurra una sola vez y que 425 no se almacene en caché.
La alternativa más simple es deshabilitar 0-RTT por completo. Tiene un límite de seguridad claro pero agrega latencia de handshake. Para una pequeña cantidad de endpoints donde el ahorro de latencia es irrelevante, deshabilitarlo es más seguro que mantener una política entre múltiples capas.
Respuesta de muestra de alta calidad
"No usaría 425 como un error general de limitación de tasa (throttling). Primero verifico si existe Early-Data: 1, y luego pregunto si la operación tiene un efecto secundario. La lectura de un pedido puede continuar; los endpoints de pago y cambio de contraseña esperan en el gateway o devuelven 425. El cliente reintenta exactamente después del handshake, con una política de SDK acotada. El servicio también requiere una clave de idempotencia, aplica una restricción de unicidad de tenant más clave y almacena el estado de procesamiento y los resultados finales para que una respuesta perdida no cause un segundo cobro. Los gateways y las instancias comparten una sola política, y monitoreamos la tasa de 425, el éxito de los reintentos y la ejecución duplicada. Si Early-Data no se puede propagar, deshabilito 0-RTT para las escrituras en lugar de adivinar".
Errores comunes
- Usar 425 como sustituto de 429 → El desencadenante y la acción del cliente son diferentes → Use 425 solo cuando exista riesgo de reproducción en early data.
- Devolver 425 para cada solicitud → Las lecturas se bloquean y los clientes pueden reintentar indefinidamente → Clasifique los efectos secundarios y límite los reintentos.
- Reintentar en 0-RTT nuevamente → La ventana de reproducción permanece abierta → Exija un handshake completado antes de reenviar.
- Colocar la idempotencia solo en la aplicación → Un gateway u otra instancia pueden ejecutarse primero → Aplique una política unificada en el edge, el servicio y la persistencia.
- Registrar en logs el cuerpo completo del pago → La depuración expone datos confidenciales → Registre identificadores, el motivo y un hash ofuscado de la clave.
Preguntas de seguimiento y respuestas
¿Qué pasa si el gateway elimina el encabezado Early-Data?
Trátelo como una falta de capacidad: el gateway debe esperar al handshake o rechazar la solicitud temprana. La aplicación no puede inferir 0-RTT a partir de una solicitud ordinaria; corrija la propagación de la señal antes de habilitar las escrituras.
¿Qué pasa si el cliente agota el tiempo de espera y envía de nuevo antes de ver el 425?
Use la misma clave de idempotencia para que la segunda solicitud lea el estado en progreso o final de la primera solicitud. Para una escritura peligrosa sin clave, devuelva un error diagnosticable y use un flujo de trabajo manual o de compensación; no adivine si se realizó un cobro.
¿Qué pasa si los reintentos tienen éxito con frecuencia pero empeoran el SLO de latencia?
Compare la tasa de 425, la latencia p95 del primer intento exitoso, los efectos secundarios duplicados y el éxito comercial por endpoint y user agent. Si el beneficio de la escritura no compensa la latencia, mantenga 0-RTT solo para lecturas seguras o deshabilítelo para esa clase de endpoint.