Resumen

  • RFC 7413 permite que un cliente que conserva una cookie del servidor envíe datos de aplicación en el SYN y que el servidor los entregue antes de completar el saludo de tres pasos.
  • El ahorro puede llegar a un viaje de ida y vuelta, pero los datos iniciales pueden repetirse; una operación que no tolere duplicados no debe adelantarse.
  • La función depende de claves de cookie, límites al trabajo no confirmado, memoria negativa por trayecto y un retorno comprobable al saludo TCP ordinario.

El primer paquete de TCP suele pedir permiso para empezar. Con TCP Fast Open también puede traer la primera solicitud. El servidor que reconoce una cookie válida puede pasar esos bytes a la aplicación cuando la conexión aún está en formación. El tiempo ahorrado no procede de enviar más deprisa, sino de mover trabajo a un instante anterior.

RFC 7413, publicado en diciembre de 2014, describió esta técnica como protocolo experimental. La categoría evita una lectura triunfalista: el texto abre un espacio de implementación y evaluación, no certifica que todos los servidores, clientes o caminos lo utilicen bien. Su promesa es condicional: hasta un RTT menos cuando existe una relación previa, el primer mensaje cabe en el segmento inicial y la aplicación entiende las nuevas consecuencias.

La primera conexión sirve para obtener la cookie. El cliente envía una opción Fast Open vacía; el servidor devuelve en el SYN-ACK una etiqueta de autenticación opaca. En una conexión posterior, el cliente incluye esa cookie junto con datos en el SYN. Si el servidor la valida, puede reconocer el SYN y los datos, entregar la solicitud y enviar una respuesta antes de terminar el saludo. Si la rechaza, descarta los datos tempranos y reconoce solo el SYN.

La cookie demuestra que la dirección de origen fue alcanzable con anterioridad. No identifica a una persona ni autoriza una compra. RFC 7413 reserva entre 4 y 16 bytes y describe normalmente una MAC vinculada a la dirección IP del cliente. El servidor puede caducarla cambiando su clave; también puede aceptar más de una durante una transición. Por eso la vida de la clave, el solapamiento y la recuperación después de una rotación forman parte de la disponibilidad del servicio.

El precio semántico es la repetición. El saludo normal ayuda a rechazar SYN antiguos o duplicados. Fast Open permite entregar datos antes de que esa frontera haya quedado atrás. En ciertas circunstancias, la aplicación puede recibir el primer bloque más de una vez. RFC 7413 exige que TFO no se active por defecto y que la aplicación lo solicite de manera explícita por puerto de servicio.

La pregunta correcta no es si el protocolo «soporta» una operación, sino si repetirla conserva el resultado esperado. Un GET suele ser apto. Un POST que cambia estado, cobra o crea un recurso no lo es sin protección transaccional. Un identificador único puede ayudar a deduplicar, pero la cookie de Fast Open no ofrece ejecución única. Adelantar bytes no adelanta la certeza.

También se adelanta el coste. Antes de confirmar el saludo, el servidor puede gastar CPU y memoria o generar una respuesta para una dirección todavía no verificada por completo. El RFC define un contador de solicitudes Fast Open pendientes y obliga a desactivar la vía rápida para nuevas conexiones al superar el límite. La degradación conserva el servicio: se descartan los datos iniciales y la conexión sigue mediante TCP ordinario.

Entre cliente y servidor, algunos dispositivos eliminan SYN con carga útil u opciones desconocidas. El diseño asume esa realidad. Si vence el temporizador, el cliente retransmite un SYN sin datos ni opción Fast Open. Las respuestas negativas deben almacenarse; el RFC recomienda suspender temporalmente TFO para la combinación concreta de direcciones y puertos. Sin memoria, cada conexión vuelve a comprar la misma demora.

El beneficio completo también exige que la primera unidad de aplicación quepa en el espacio disponible. Las opciones TCP reducen ese espacio y el MSS memorizado establece otro límite. Si falta parte de la solicitud, el servidor debe esperar a los paquetes posteriores y se desvanece buena parte del ahorro. Mantener conexiones útiles sigue siendo preferible a crear una sucesión de conexiones breves solo para exhibir una apertura rápida.

TCP Fast Open merece un lugar en la historia de los protocolos porque expuso con claridad la contabilidad de la latencia. Un RTT menos requiere estado adicional: qué direcciones demostraron alcanzabilidad, qué claves siguen válidas, qué operaciones pueden repetirse, cuánto trabajo se acepta sin confirmación y qué caminos obligan a retirarse. La optimización funciona cuando esa contabilidad es visible; falla cuando «más rápido» oculta quién asume el riesgo.

Sources