Resumen

  • RDP ofrecía mensajes fiables sobre IP, pero hacía opcional la entrega ordenada a la aplicación y fijaba esa decisión durante la apertura de la conexión.
  • ACK describía el tramo continuo recibido; EACK enumeraba segmentos correctos situados más allá de un hueco y evitaba retransmitirlos de nuevo.
  • La constancia del transporte no era un recibo de la aplicación: el usuario debía comprobar la entrega necesaria antes de cerrar y el registro IANA solo conservaba el número 27.

Una memoria sin agujeros, una red con desorden

Los autores de RFC 908 pensaban en carga remota, volcados de memoria y depuración. Copiar una imagen exige que todos sus bloques estén finalmente presentes. Un agujero no es aceptable. De ahí nacían números de secuencia, checksum, acuses positivos y retransmisión.

Pero “todos” no significa necesariamente “en el mismo orden en que fueron enviados”. Un bloque puede incluir suficiente contexto para ocupar su dirección final nada más llegar. Retenerlo porque otro bloque anterior se retrasó consume memoria y tiempo. En cambio, una secuencia de órdenes de depuración puede depender de la causalidad: insertar un punto de ruptura antes de continuar no es lo mismo que continuar antes de insertarlo.

RDP convirtió esa diferencia en un parámetro explícito. La solicitud Open indicaba entrega secuenciada o no secuenciada. La opción permanecía durante toda la conexión. Así, el transporte no tenía que adivinar la semántica del programa y el programa no tenía que renunciar a una recepción fiable para evitar una espera innecesaria.

El hueco seguía visible

Supongamos que los segmentos 100, 101, 102 y 103 salen de un host. El 101 se pierde. El 102 y el 103 pasan el checksum y caen dentro de la ventana aceptable. El receptor no adelanta su frontera acumulativa más allá de 100, porque todavía no posee una secuencia continua. Sin embargo, puede enviar EACK con los números 102 y 103.

Esa respuesta conserva dos hechos a la vez. Falta 101. Ya están 102 y 103. El emisor retransmite el ausente sin volver a enviar indiscriminadamente los posteriores. Cuando llega 101, el borde acumulativo puede avanzar a través de lo que ya estaba registrado.

EACK no elimina el control de flujo. La ventana se ancla en el último segmento recibido en orden. Si el hueco persiste, los nuevos envíos alcanzan el borde derecho y se detienen. El protocolo ahorra retransmisión, no concede una vía infinita alrededor de la pérdida.

Reconocer y entregar eran actos distintos

El segmento 102 podía recibir un EACK bajo ambos modos. La diferencia aparecía en la interfaz con el usuario. En modo no secuenciado, RDP podía copiar sus datos al búfer de la aplicación de inmediato. En modo secuenciado, registraba la llegada correcta pero esperaba a que 101 cerrara el hueco.

Por eso una captura necesita más de una columna. “Recibido con checksum válido”, “reconocido por ACK/EACK”, “copiado al usuario” y “aplicado con éxito” no son sinónimos. Cada paso añade una afirmación. Ninguno hereda automáticamente la autoridad del siguiente.

La elección se comunicaba en el SYN junto con el número inicial de secuencia, el máximo de segmentos pendientes y el tamaño máximo aceptado. Una observación que empieza después del SYN puede ver la misma secuencia de EACK y no saber si la aplicación estaba autorizada a ver los mensajes adelantados. El inicio de conexión es parte del significado de los paquetes posteriores.

Límites locales dentro de reglas comunes

Cada extremo declaraba su capacidad de búfer mediante el número máximo de segmentos no reconocidos y el tamaño máximo del segmento. El emisor debía respetar los límites del receptor. Los valores no eran una clasificación universal de rendimiento; eran condiciones concretas de esa conexión.

El diseño separaba así dos clases de decisión. La regla compartida decía cómo identificar, aceptar, reconocer y retransmitir. La decisión local decía cuánto podía alojar cada implementación y si su aplicación requería orden. Lo común era estricto sin ocupar el terreno que solo el programa podía entender.

RDP también describía aperturas simultáneas. Si dos SYN se cruzaban, cada host podía contestar con su propio SYN y el ACK del recibido. Los estados CLOSED, LISTEN, SYN-SENT, SYN-RCVD, OPEN y CLOSE-WAIT daban una época a los números de secuencia y a las capacidades negociadas.

Para detectar algunas conexiones medio abiertas, RDP podía enviar NUL. NUL usaba el siguiente número de secuencia y esperaba un acuse. La respuesta indicaba que el RDP remoto aún reconocía la conexión. No certificaba que el cargador estuviera listo ni que el depurador hubiese ejecutado una orden.

Cerrar no completaba el trabajo

La sencillez de la terminación evita una confusión importante. Una petición de cierre enviaba RST y entraba en CLOSE-WAIT antes de liberar el registro. RFC 908 asignaba al usuario la tarea de determinar que los datos estaban entregados de forma fiable antes de pedir el cierre.

El transporte, por tanto, no ofrecía un commit final. Un ACK atestiguaba aceptación por el RDP destino. La entrega no secuenciada podía atestiguar una copia a un búfer. Aún hacían falta pruebas propias para saber si una imagen quedó íntegra, si una orden tuvo efecto o si una transacción se volvió durable.

Esa frontera también protege contra una lectura de seguridad exagerada. El checksum detectaba el tipo de corrupción para el que fue diseñado. Ni la versión original ni la posterior lo convertían en autenticación criptográfica de un par.

La versión 2 nació de ejecutar la versión 1

En RFC 1151, la experiencia de 1986 y 1987 corrigió varios supuestos. El checksum no lineal de 32 bits tenía un coste inesperadamente dependiente de la representación del host; optimizaciones sobre equipos comparables variaban por un factor de cinco. La versión 2 adoptó el checksum TCP de 16 bits.

También amplió los puertos internos de RDP de ocho a dieciséis bits. Puesto que cambiaban campos del encabezado, aumentó el número de versión. Además, corrigió la actualización de SND.UNA: tras reconocer SEG.ACK, el segmento no reconocido más antiguo debía ser SEG.ACK + 1.

No conviene transformar esa publicación en una historia de triunfo. RFC 1151 dice que la demanda limitada de implementaciones no justificó reescribir toda la especificación. Demuestra que hubo experimentación suficiente para descubrir problemas; no demuestra cuánto código adoptó las correcciones.

El registro de números de protocolo de IANA conserva RDP en el valor 27. Eso impide que el nombre y el número se separen en el registro. No prueba tráfico actual, una versión concreta, soporte de EACK ni conformidad de un producto.

La lección cabe en cuatro pruebas

Un SYN válido prueba una época de conexión y sus opciones. Un checksum válido prueba la integridad limitada de un segmento. ACK y EACK prueban formas distintas de recepción. El resultado de la aplicación necesita su propio recibo.

RDP fue preciso porque no comprimió esas pruebas en la palabra “fiable”. Permitió que aplicaciones distintas compartieran un mecanismo de recuperación sin recibir una política de orden que algunas no necesitaban. Y obligó a las que sí dependían de la secuencia a declararlo desde el comienzo.

Fuentes