Resumen

  • RFC 1144 permitía representar una cabecera IPv4/TCP mínima de cuarenta octetos mediante unos pocos octetos, un identificador de conexión y cambios respecto al paquete anterior.
  • La optimización vivía en un enlace: antes de seguir por Internet, el descompresor reconstruía la cabecera ordinaria.
  • Si una trama se perdía, los dos extremos podían recordar bases distintas; el checksum, el estado de descarte y una cabecera completa devolvían la sincronía.

Ochenta y dos octetos para conversar

La RFC 1144 analizó en 1990 enlaces serie de 300 a 19.200 bit/s. Una cabecera mínima de IPv4 más TCP ocupaba cuarenta octetos. Un carácter tecleado producía un paquete de 41 octetos y su eco otro igual. El cálculo histórico exigía unos 4.000 bit/s para completar ambos dentro de 200 milisegundos.

En una transferencia grande, miles de octetos de datos diluyen el coste fijo. En una conversación remota, el encabezado casi era el paquete. Además, un bloque voluminoso ya en transmisión podía impedir que el eco pequeño saliera a tiempo. La compresión buscaba recuperar capacidad, pero sobre todo tiempo humano.

No se borró ningún significado

El diseño partió de que todos los campos servían para algo. Lo repetitivo no era su existencia sino su valor. Direcciones y puertos seguían constantes durante la conexión; secuencia, reconocimiento, ventana e Identificación IP solían cambiar con regularidad; sólo algunas piezas eran imprevisibles en cada envío.

Compresor y descompresor guardaban una cabecera previa por conversación. Un CID pequeño señalaba el contexto. UNCOMPRESSED_TCP instalaba la versión completa; COMPRESSED_TCP enviaba una máscara, diferencias codificadas y valores que no podían inferirse con seguridad. Al otro lado, la cabecera se reconstruía antes de entregar el datagrama a IP.

Los extremos TCP podían permanecer ajenos. La representación compacta sólo existía entre dos sistemas del enlace lento. Esta frontera evitaba convertir una mejora local en una variante incompatible del protocolo global.

La pauta valía más que el campo

La secuencia puede avanzar tantos octetos como datos acaba de transportar un paquete. El ACK puede seguir el avance en sentido contrario. La Identificación IP suele variar poco. RFC 1144 codificó esas diferencias pequeñas y reservó atajos para los patrones dominantes de eco interactivo y transferencia unidireccional.

También definió salidas. Fragmentos, SYN, FIN, RST, paquetes sin ACK, cambios de longitud, opciones inesperadas y transiciones irregulares se enviaban sin compresión diferencial. Cuando la próxima cabecera no podía deducirse del contexto, el emisor dejaba de fingir que sí.

El documento obtuvo cerca de tres octetos de cabecera media en las trazas descritas. No es una cifra aplicable a toda red. El dato importante es que la economía procedía de la continuidad entre paquetes, no de declarar inútiles cuarenta octetos del estándar.

Una pérdida separaba las memorias

Una diferencia aplicada a la base equivocada crea otro paquete. Si una trama compacta no llegaba, el compresor ya había avanzado su contexto y el descompresor no. La siguiente trama podía parecer bien formada y, sin embargo, reconstruir números de secuencia o ACK erróneos.

TCP aportó una red de seguridad. Su checksum solía detectar la reconstrucción incoherente. El descompresor entraba en estado de descarte y no intentaba interpretar más tramas comprimidas hasta recibir un contexto completo. Las retransmisiones y ACK duplicados de TCP ayudaban a que el compresor enviara ese refresco sin crear un diálogo de corrección propio.

El checksum no prueba identidad ni elimina todos los riesgos. Sí convierte el contexto en una obligación explícita: si se omiten datos porque ambos lados supuestamente los recuerdan, la pérdida de acuerdo necesita un límite y una salida.

El contexto se convirtió en arquitectura

La RFC 2507 amplió el modelo en 1999. Una cabecera completa establece estado; las siguientes hacen referencia a él. Para otros protocolos añadió generaciones, refrescos periódicos y solicitudes. Para TCP incluyó reparación sin diferencias y tratamiento del reordenamiento.

El número de contextos también limita el resultado. Muchos flujos pueden expulsarse entre sí y causar CID thrashing: cada conversación reaparece como nueva y vuelve a pagar la cabecera completa. Elegir qué flujo conserva memoria pasa a ser una decisión de asignación.

La RFC 4413 clasificó después los campos por comportamiento real. El marco ROHC y el perfil ROHC-TCP hicieron explícitos los estados, la inicialización, los refrescos, la realimentación y los CRC para enlaces con pérdidas y reordenamiento. No son una sustitución compatible en el cable de RFC 1144; llevan su pregunta esencial a cabeceras y enlaces más difíciles.

Fuentes y límites

El conjunto cerrado comprende RFC 1144, RFC 2507, RFC 4413, RFC 4995 y RFC 6846. Documenta mecanismos y ejemplos, no implantación actual, configuraciones de proveedores, ganancias universales ni una longitud fija de tres octetos.