Resumen

  • TCP Accelerated Open comparaba el CC del SYN con el último CC válido del cliente. Si era mayor, RFC 1644 permitía actualizar la caché y entregar los datos sin esperar el 3WHS completo.
  • CC.NEW declaraba inválida la continuidad de la caché y obligaba a validar de forma normal; CC.ECHO permitía al cliente comprobar que el SYN/ACK correspondía a su apertura.
  • El mecanismo contenía duplicados antiguos del transporte. No era una identidad, una autorización ni un recibo de commit. RFC 6247 lo pasó a Historic por falta de uso general y problemas de seguridad comunicados.

Una comparación local habilitaba la entrega

El RFC 1644 fue una especificación Experimental para intercambios breves de solicitud y respuesta. En el primer SYN, el cliente podía incluir datos y un contador de conexión de 32 bits. El servidor guardaba el último valor válido visto para ese host.

Un valor mayor hacía pasar la prueba TAO. El servidor trataba el SYN como nuevo, sustituía el valor de caché y pasaba la solicitud al proceso. Un valor menor o igual no autorizaba la misma inferencia: podía ser un duplicado antiguo o un reordenamiento, de modo que se ejecutaba el establecimiento normal de tres pasos.

La prueba resolvía una incertidumbre concreta sobre la encarnación del transporte. Dependía de que el contador creciera de forma monótona y de que la memoria por cliente siguiera representando al mismo contexto. No demostraba quién estaba detrás del host ni qué resultado producirían los bytes.

Cuando el cliente reiniciaba, podía perder la continuidad del contador. CC.NEW hacía visible ese hecho: invalidaba la entrada del servidor y forzaba 3WHS. En la respuesta, CC.ECHO devolvía el contador de apertura para que el cliente validara el SYN/ACK. El eco vinculaba segmentos; no autenticaba a una empresa, usuario o servicio.

La aplicación necesitaba su propio comprobante

RFC 1644 habló de operación «como máximo una vez» dentro del transporte y aclaró que la palabra transacción no incluía semántica de commit de aplicación. Su intercambio mínimo seguía siendo de tres segmentos.

Entre la entrega y el efecto final caben muchos estados. El programa puede no analizar la solicitud, rechazar permisos, ejecutar una parte, escribir de forma duradera, llamar a otro sistema o completar el trabajo mientras se pierde la respuesta. Si el cliente no recibe un resultado, CC no distingue esas posibilidades.

Por eso una orden con efecto económico necesita un identificador de operación estable, deduplicación duradera y un recibo de resultado generado dentro de la autoridad de la aplicación. Reintentar solo porque falta el SYN/ACK o la respuesta puede repetir el trabajo aunque el transporte no haya reproducido el mismo paquete.

Tampoco debe modernizarse retrospectivamente el experimento. RFC 6247 reclasificó T/TCP como Historic: no tuvo uso extendido y se habían comunicado problemas de seguridad. RFC 9293 contiene la base actual de TCP. El RFC de 1994 no acredita implementación presente, compatibilidad con middleboxes ni seguridad de una ruta.

La salida rápida conservaba memoria

Para conexiones cortas, CC ayudaba a reconocer encarnaciones y abreviar TIME-WAIT. La condición no desaparecía: una conexión que superara el máximo tiempo de vida de segmento todavía debía conservar el retraso ordinario. Si el intercambio crecía o las hipótesis dejaban de cumplirse, T/TCP volvía a la conducta TCP normal.

El valor de este caso histórico está en la separación de recibos. La caché decide si el transporte puede actuar. Solo la aplicación puede declarar qué operación aceptó, ejecutó y dejó durable.

Fuentes y límites

No prueban ejecución exacta, identidad autenticada, despliegue contemporáneo ni resultado comercial.