Resumen

  • En la prueba de la RFC 2348, transferir 2,25 MB tomó 23,85 segundos sin una puerta de enlace intermedia con bloques de 512 octetos, y 4,90 segundos con bloques de 8.192.
  • El bloque sí era 16 veces mayor; el tiempo bajó alrededor de 80 %, no 16 veces. La propia RFC advertía que superar el MTU del camino añade fragmentación y reensamblaje.

El TFTP clásico intercambiaba simplicidad por espera. El cliente recibía un bloque de datos, lo confirmaba y esperaba el siguiente. Los 512 octetos de la especificación básica resultaban razonables para máquinas pequeñas —incluidos equipos sin disco que arrancaban desde una ROM limitada—, pero obligaban a pausar tras cada bloque. En una LAN capaz de transportar tramas mayores, esa pausa y el procesamiento de muchos paquetes podían pesar más que la carga útil.

En mayo de 1998, la RFC 2348 propuso negociar blksize. La RFC 2347 había definido la estructura: el cliente añadía opciones a una solicitud de lectura o escritura y el servidor podía responder con un OACK. Para el tamaño de bloque, el servidor solo podía aceptar una cifra igual o menor que la solicitada; no podía iniciar una opción por su cuenta. El cliente debía usar el valor confirmado o terminar la transferencia. Un servidor que no entendiera la negociación podía ignorarla y continuar con TFTP normal. La extensión era compatible con el intercambio anterior, no un cambio impuesto a todos los equipos.

RFC 2348 permitió entre 8 y 65.464 octetos de datos por bloque, sin contar los cuatro octetos de cabecera TFTP. Presentó 1.428 octetos como ejemplo calculado a partir de un MTU Ethernet, descontando cabeceras TFTP, UDP e IP. Era una ilustración, no una recomendación universal. Que dos extremos aceptaran el mismo valor no demostraba que todos los enlaces, túneles y saltos intermedios pudieran llevar el datagrama sin fragmentarlo.

El documento aportó datos de una prueba de concepto: dos equipos HP-UX 9000, Ethernet con poca carga, modo octeto y archivos de 2,25 MB. Se promediaron cinco transferencias, una serie sin puerta de enlace intermedia y otra con una. Con bloques de 512 octetos, los tiempos publicados fueron 23,85 y 37,05 segundos. Con 8.192, fueron 4,90 y 6,15. El tiempo se redujo unas 4,87 veces en la primera ruta y 6,02 en la segunda; en porcentaje, cerca de 79,5 % y 83,4 %.

Así se entiende el «16x» del cuadro comparativo: 8.192 es dieciséis veces 512. No significa que el archivo haya llegado dieciséis veces más rápido. La caída cercana al 80 % coincide con los tiempos brutos de la prueba. Son magnitudes distintas: tamaño de bloque, cantidad de paquetes y duración total. Separarlas no resta mérito al resultado. Los bloques grandes redujeron los paquetes de datos y sus acuses, el número de esperas y el trabajo por paquete.

La condición que podía mermar el beneficio aparece en la misma RFC. Cuando el bloque excedía el MTU del camino, la fragmentación y el reensamblaje IP añadían sobrecarga; el efecto podía hacerse más visible al atravesar más puertas de enlace. Un valor eficaz en el Ethernet de la prueba podía encajar mal tras un enlace más estrecho o una encapsulación. El experimento no midió una colección diversa de rutas de Internet, no publicó la variación estadística y no identificó un tamaño óptimo general. Es un resultado de prototipo bajo condiciones descritas, no un censo de instalaciones.

Más tarde apareció otro control. La RFC 7440 definió windowsize: varios bloques consecutivos antes de esperar un acuse. Tamaño de bloque y profundidad de ventana afectan la espera de maneras diferentes; no son el mismo ajuste. Y la RFC 8900, muy posterior, analiza la fragilidad de la fragmentación IP en la operación. No demuestra que la prueba de 1998 fallara; la advertencia original ya basta para delimitarla.

La lección no es «más grande siempre es más rápido». La propuesta convirtió una unidad fija en una elección negociable, reportó una mejora importante en un entorno acotado y dejó escrita la frontera de MTU que podía cambiar el resultado. El trabajo del operador empieza después: medir el camino por el que circula la transferencia concreta.

El punto de partida de TFTP está en la RFC 1350. Las opciones de tiempo de espera y tamaño de transferencia, publicadas en la misma época, están en la RFC 2349; permiten separar blksize de otros parámetros negociados.