Summary

  • RFC 1692 definió TMux para reunir segmentos cortos de sesiones Telnet y Rlogin dirigidos al mismo host, reduciendo paquetes e interrupciones.
  • La envoltura con protocolo IP 18 ocultaba los puertos TCP a un router que solo supiera filtrarlos desde el paquete exterior. El RFC le indicaba que bloqueara TMux o inspeccionara cada segmento. RFC 4450 llevó el protocolo a Historic.

Un usuario escribe una letra. Su servidor de terminales envía un paquete diminuto. Otro usuario hace lo mismo, y luego otro. El enlace puede seguir holgado mientras el host se ocupa de cientos de llegadas separadas. En RFC 1692, publicado en agosto de 1994, los autores afirmaban que procesar un paquete de un octeto costaba al host casi tanto como procesar uno de 1.500. La cifra decisiva era paquetes por segundo, no solo bits por segundo.

Peter Cameron, David Crocker, Danny Cohen y Jon Postel aprovecharon que muchas sesiones del servidor terminaban en uno o dos hosts. TMux recogía varios segmentos cortos con destino común y los ponía en un único datagrama IP. Cada segmento llevaba delante cuatro octetos con su longitud, su protocolo de transporte original y una suma de control del pequeño encabezado. El paquete exterior se identificaba como protocolo 18. En destino, el receptor separaba el contenido y entregaba cada pieza a TCP o UDP; la aplicación veía sus segmentos habituales.

La agrupación necesitaba un pequeño compás de espera. El primer segmento iniciaba un temporizador. Si llegaban otros antes de vencer, compartían el paquete; si el búfer se llenaba, salía en ese momento. El texto proponía 20 a 30 milisegundos configurables y situaba el límite probable cerca de una décima de segundo, porque un terminal interactivo debía responder con rapidez. Los segmentos grandes, por ejemplo los superiores a 700 octetos, convenía enviarlos por separado. Un envío con un solo segmento habría pagado la espera sin comprar casi nada.

El emisor podía usar TMux solo si sabía que el otro host lo entendía. El RFC ofrecía una consulta ENQ: un paquete vacío con protocolo 18. Una respuesta TMux válida confirmaba la capacidad; los intentos sin respuesta se espaciaban, mientras los datos podían seguir por datagramas normales. La memoria de esa capacidad debía caducar, ya que un reinicio podía cambiar lo que el host aceptaba. No hacía falta convertir toda la conexión al nuevo formato para siempre.

En la sección de seguridad apareció la deuda de la optimización. Un router con una regla basada en puertos TCP solo veía el protocolo 18 de fuera. Dentro estaban los puertos originales. Los paquetes grandes de la misma conexión podían circular como IP/TCP corriente y recibir un trato distinto. La salida que daba RFC 1692 era concreta: si el router filtra por puerto y no entiende TMux, debe bloquearlo en ambos sentidos; si lo entiende, puede abrir el lote y rechazar los segmentos que incumplan la regla.

TMux fue Proposed Standard. Una revisión de 2004–2005 preguntó qué especificaciones antiguas merecían nueva implantación o mantenimiento; RFC 4450 incluyó TMux entre las que pasaron a Historic. Ese es su estado en el RFC Editor. La promesa de menor carga no desaparece del papel. Tampoco desaparece el precio: alguien tiene que leer dentro de la envoltura para conservar una política que depende de los puertos.

Fuentes