Resumen

  • En una apertura simultánea, los dos extremos hacen un OPEN activo hacia el mismo par de sockets. Los SYN sin ACK se cruzan, ambos pasan a SYN-RECEIVED y los SYN-ACK posteriores establecen una única conexión.
  • La coordinación no necesita decidir primero quién es cliente. Cada parte demuestra que recibió el número inicial remoto y obtiene confirmación de que el suyo también llegó.
  • Muchos NAT aprendieron sólo la secuencia común «SYN saliente, SYN-ACK entrante». RFC 5382 tuvo que exigir que, si la política permite la conexión, también se conserve la ruta válida del SYN entrante cruzado.

La ilustración habitual repartió más poder del debido

Tres flechas hicieron de TCP una historia fácil de enseñar. Un extremo envía SYN, el otro responde SYN-ACK y el primero confirma. Pero RFC 793 no convirtió ese orden en una jerarquía universal. El mismo texto dice que dos procesos que se abran activamente uno hacia otro serán conectados correctamente, una flexibilidad importante para componentes distribuidos y asíncronos.

«Cliente» y «servidor» son funciones útiles de aplicación. En TCP, lo que establece la asociación no es el rango de quien habla primero, sino la coincidencia de sockets y la sincronización de dos espacios de secuencia.

La apertura simultánea no era una reparación para un accidente exótico. Formaba parte del diseño inicial. La figura más popular describía una trayectoria; con el tiempo, algunos sistemas intermedios la trataron como si fuera la única gramática.

Los SYN se cruzaron y el estado convergió

A elige 100 como número inicial y B elige 300. Cada uno emite un SYN y entra en SYN-SENT. Al recibir el SYN desnudo del otro, ninguno concluye que su propia tentativa perdió. Cada pila registra el origen remoto, pasa a SYN-RECEIVED y envía SYN-ACK: A confirma 301 y B confirma 101.

Cuando llegan esas respuestas cruzadas, las dos partes ya conocen el inicio remoto y saben que el suyo fue reconocido. RFC 9293 conserva la secuencia corregida: ambos recorren CLOSED → SYN-SENT → SYN-RECEIVED → ESTABLISHED.

La lógica sigue siendo un apretón de tres pasos aunque el dibujo contenga dos iniciativas paralelas. Cada número inicial debe ser enviado, recibido y reconocido. TCP pide reciprocidad de evidencia, no una flecha ceremonialmente primera.

El más uno era una prueba, no decoración

SYN ocupa un lugar en el espacio de secuencia. Por eso un SYN situado en 300 se confirma con 301. La cifra declara que el control que inaugura la secuencia ya está incluido en la historia aceptada por el receptor. Un ACK vacío no consume espacio, evitando una cadena absurda de reconocimientos de reconocimientos.

Las secuencias no se fusionan. Cada extremo conserva su numeración de envío. RFC 6528 añadió después una componente pseudoaleatoria secreta vinculada al cuádruple de direcciones y puertos para dificultar ataques de predicción. Que ambos inicien no significa que compartan origen numérico ni secreto.

Así puede existir una conexión sin árbitro. Cada nodo comprueba los mismos tipos de hechos desde su posición: identidad del par, número remoto vigente y confirmación del número propio.

Dos llamadas locales no producían dos objetos de red

Un programador podía imaginar dos conexiones porque las dos aplicaciones habían ejecutado una llamada activa. RFC 1122 deshizo expresamente esa intuición: el resultado es una sola conexión, y fue una decisión intencional que no debía «arreglarse».

Para A, el socket local de A se empareja con el remoto de B. Para B, el mismo par aparece invertido. Son dos perspectivas de la misma identidad. Duplicarla obligaría a elegir después cuál de los gemelos transporta los bytes y cuál es un artefacto de la API.

El protocolo separó procedimiento local de realidad compartida. Puede haber dos solicitudes y varios registros pendientes, pero al converger el cuádruple y la secuencia sólo existe una asociación establecida.

El nombre del estado no bastaba

Una pila en SYN-RECEIVED puede haber llegado desde una escucha pasiva o desde su propio OPEN activo. RFC 1122 y RFC 9293 obligan a recordar esa procedencia, porque la reacción ante un reset y el retorno a LISTEN no son idénticos.

También un SYN antiguo y duplicado puede parecer una nueva apertura simultánea. RFC 793 no elimina la ruta válida para evitar la confusión. Usa reconocimientos, ventanas de secuencia y resets aceptables para decidir si el paquete pertenece a la encarnación actual.

Es una advertencia contra las máquinas de estados sin memoria causal. Dos casillas con el mismo rótulo pueden requerir decisiones distintas. Borrar el camino de entrada ahorra campos, pero también borra la evidencia necesaria para recuperarse con seguridad.

El NAT memorizó el caso frecuente

En el patrón cliente-servidor, el SYN saliente crea una traducción y el siguiente paquete entrante suele ser SYN-ACK. Durante una apertura simultánea, llega otro SYN. RFC 5382 documentó NAT que lo bloqueaban como no solicitado y otros que traducían mal el SYN-ACK que salía después.

El problema no era necesariamente una política que prohibía comunicación entre pares. Era una implementación que había reducido el estado TCP a la trayectoria que veía con más frecuencia. Los dos extremos podían ser conformes y, aun así, la caja intermedia declaraba imposible su conversación.

Una política puede decir «no permito este flujo». Si ya lo permite, el seguimiento no debe decir «esta transición válida no es TCP». RFC 5382 exige precisamente que los NAT tramiten todas las secuencias válidas para conexiones autorizadas, incluida la apertura simultánea.

Esperar seis segundos hizo visible la incertidumbre

Si el SYN remoto llega al NAT antes que el SYN local, todavía no existe el mapeo que revelaría el encuentro. Responder de inmediato con RST o un error ICMP acelera el diagnóstico de un paquete realmente erróneo, pero obliga al remoto a abandonar una apertura que el SYN local retrasado habría legitimado.

RFC 5382 estableció una espera mínima de seis segundos. Si durante ella aparece el SYN saliente correspondiente, el primer paquete puede descartarse en silencio y su retransmisión encontrará ya la traducción. Si no aparece, el NAT puede notificar el error de acuerdo con su seguridad.

El número expresa un compromiso, no una propiedad natural. La caja paga memoria y demora para no convertir una observación incompleta en una negativa irreversible. Esta tensión entre señal rápida y opción futura es el verdadero coste de poner inteligencia temporal en el camino.

ICE convirtió la vieja posibilidad en candidato

La expansión de los NAT dio a la apertura simultánea una nueva función: dos pares internos podían crear estado saliente y tratar de encontrarse sin depender siempre de un relay. Hacían falta intercambio previo de direcciones, puertos y coordinación temporal, pero TCP ya sabía resolver los SYN cruzados.

RFC 6544 definió candidatos TCP activos, pasivos y S-O para ICE. Un candidato S-O indica que ambos agentes intentarán abrir. El mismo RFC recomienda reunir alternativas y relays porque la compatibilidad de sistemas operativos y redes no es uniforme.

Que el estándar exija la función no garantiza que cada API la exponga ni que cada acceso la preserve. El mecanismo es una capacidad del extremo; la posibilidad de usarla es una propiedad de toda la ruta.

La simetría sobrevivió porque estaba fundada en evidencia

El diseño común era mínimo y estricto: identificar un par, elegir dos secuencias frescas, reconocer lo recibido y conservar el historial necesario. Sobre esa base, cada aplicación podía llamar, escuchar o probar varias rutas. Ninguna autoridad permanente debía adjudicar el papel legítimo.

Los NAT mostraron el peligro de convertir una costumbre en mandato. El orden más frecuente parecía tan natural que una alternativa definida desde 1981 se volvió sospechosa. RFC 5382 no inventó una excepción; recordó a los intermediarios que su política y la gramática del protocolo eran cosas distintas.

Cuando ambos extremos llamaron, TCP no creó dos líneas ni eligió un vencedor. Hizo converger dos iniciativas mediante pruebas locales. Esa economía de autoridad es parte de la historia de Internet, aunque no quepa en el dibujo más sencillo.

Fuentes y límites de la evidencia

La reconstrucción se apoya en RFC 793, RFC 1122, RFC 5382, RFC 6528, RFC 6544 y RFC 9293. No ofrecen un censo actual de API, NAT o uso. Pérdidas y retransmisiones pueden cambiar la captura sin cambiar el razonamiento.