Resumen

  • Aceptar datos 0-RTT prueba una decisión de transporte, no que el efecto empresarial se confirmó una sola vez.
  • La aceptación exige unir la señal de datos tempranos, el dominio antirrepetición, los reintentos y el resultado autoritativo de la aplicación.

Un cliente reanuda una conexión para aprovisionar un servicio y envía un POST antes de que termine el handshake. Un punto de presencia acepta los datos tempranos; al perderse la respuesta, el cliente o un intermediario reintenta por otro punto. El panel muestra baja latencia y éxito. Sigue abierta la pregunta importante: ¿se creó una instancia o dos?

Es un mecanismo hipotético, no una acusación. RFC 8446 permite datos 0-RTT cuando cliente y servidor comparten material de reanudación, pero advierte que no hay garantía de no repetición entre conexiones. La protección para todo un despliegue requiere memoria compartida o un control equivalente sobre lo ya aceptado. Esa coordinación tiene costes, y no todos los sistemas la mantienen con el mismo alcance.

Por eso un ticket aceptado en un borde no demuestra que otro borde vaya a rechazar la misma operación lógica. RFC 9001 hace explícita la consecuencia para QUIC: los datos de aplicación recibidos en 0-RTT pueden procesarse más de una vez. El protocolo de aplicación debe definir qué uso acepta y cómo reduce la repetición. Completar después el handshake no convierte una acción temprana en una transacción única.

HTTP aporta una señal de procedencia. RFC 8470 define Early-Data: 1 para que un intermediario conserve el hecho de que la solicitud viajó como dato temprano en un salto previo. Esperar a terminar un handshake posterior no elimina ese riesgo. Cuando un servidor no quiere procesar una solicitud que podría repetirse, puede responder 425 Too Early; el reintento se envía fuera de datos tempranos.

La semántica importa tanto como el transporte. RFC 9110 llama idempotente a un método cuyo efecto previsto es el mismo tras varias solicitudes idénticas que tras una. Un POST no se vuelve idempotente por incluir una clave. La aplicación puede diseñarlo para reintentos seguros, pero debe definir alcance, retención, conflictos y un resultado autoritativo que todos los caminos consulten.

El error operativo es usar una medición de una capa como garantía de otra. El contador 0-RTT registra uso de una ruta rápida; el log de TLS o QUIC registra estado de conexión; un código HTTP registra una respuesta. Ninguno cuenta por sí solo las confirmaciones duraderas ni demuestra que el reintento no alcanzó otro dominio.

El recibo necesario une identidad de solicitud, método y recurso, decisión de datos tempranos, borde y origen, alcance antirrepetición, propagación de Early-Data, 425 y reintento, identificador transaccional, cantidad de confirmaciones y resultado final. No expone secretos, pero sí el ámbito que gobernó su aceptación.

0-RTT sigue siendo útil para lecturas y operaciones diseñadas para tolerar repetición. La disciplina consiste en no convertir una mejora de latencia en una promesa de negocio. La aplicación, no el handshake, debe demostrar que el efecto previsto ocurrió como máximo una vez.

Fuentes