Network Working Group G. Malkin Request for Commments: 2347 Bay Networks Updates: 1350 A. Harkin Obsoletes: 1783 Hewlett Packard Co. Category: Standards Track Mayo 1998 Opción del Tamaño de Bloque para TFTP Estado de esta Memoria Este documento es la especificación de un protocolo estándar para la comunidad de Internet, y propone discusiones y promueve sugerencias para mejorarlo. Por favor refiérase a la edición actual de los "Protocolos Oficiales y Estándares de Internet" (STD 1) para conocer el estado actual del estándar y de este protocolo. La distribución de esta memoria es ilimitada. Información del Copyright Copyright (C) La Sociedad de Internet (1998). Todos los derechos reservados. Extracto El Protocolo Trivial de Transferencia de Archivos [1] es un protocolo simple, de paso a paso regulado, para la transferencia de archivos que permite a un cliente leer o escribir un archivo en un servidor remoto. Uno de los usos primarios de este protocolo, es el arranque de nodos, desprovistos de unidad de disco, en una red local. Se usa precisamente el TFTP, porque es muy sencilla su implementación en pequeños nodos que acostumbran a tener limitada la capacidad en ROM. Pero el tamaño del bloque de transferencia de 512 bytes, es poco eficiente cuando se está dentro de una red LAN, donde el MTU puede tener 1500 bytes o más. Este documento describe una opción para el TFTP que permitirá al cliente y al servidor, negociar el tamaño del bloque que mejor se adapte al medio. El mecanismo de la Negociación de Opciones se encuentra descrito en [2]. Especificación de la Opción de Tamaño de Bloque Los paquetes de petición de lectura o escritura, se han modificado para incluir la opción de tamaño de bloque tal como se ve a continuación: Malkin y Harkin Estándar [Pág. 1] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 +-------+---~~----+---+---~~---+---+----~~-----+---+---~~---+---+ | cod | archivo | 0 | modo | 0 | T. Bloque | 0 | octetos| 0 | +-------+---~~----+---+---~~---+---+------~~---+---+---~~---+---+ cod El campo de código de operación contendrá un 1 para peticiones de lectura o bien un 2 para peticiones de escritura, tal como está definido en [1]. archivo El nombre del archivo a leer o escribir, tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. modo Es el modo de la transferencia del archivo: "netascii", "octet", o "mail", tal como está definido en [1]. Este campo ha de terminarse con un byte nulo. Tamaño de bloque Es el nombre de la opción del tamaño de bloque: "blksize" (insensible a mayúsculas / minúsculas). Este campo ha de terminarse con un byte nulo. octetos El número de octetos que tendrá cada bloque se especifica en ASCII. Y puede tomar valores entre 8 y 65464 octetos ambos inclusive. Este campo ha de terminarse con un byte nulo Ejemplo: +-------+--------+---+--------+---+--------+---+--------+---+ | 1 | foobar | 0 | binary | 0 | blksize| 0 | 1432 | 0 | +-------+--------+---+--------+---+--------+---+--------+---+ Tenemos una petición de lectura de un archivo llamado "foobar", que se transferirá en modo binario, y un tamaño de bloque de 1432 bytes (El MTU de Ethernet, es menor que las longitudes de las cabeceras del UDP y del IP). Si el servidor tiene implementada la opción de tamaño de bloque, este responderá al cliente enviándole un Reconocimiento de la Opción (OACK). El valor devuelto en el reconocimiento será igual o menor que el valor especificado por el cliente. Entonces el cliente tendrá que usar el tamaño de bloque especificado en el OACK o bien enviar un paquete de error con el código 8, para finalizar la transferencia. Las reglas para determinar el último paquete de la transferencia se Malkin y Harkin Estándar [Pág. 2] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 mantienen sin cambios, como se describe en [1]. La recepción de un paquete de datos con una longitud menor que la negociada en el tamaño de bloque, indica que ese es el paquete final. Por lo tanto si el tamaño del primer bloque es menor que el tamaño de bloque negociado, es a la vez el paquete final. Si coincide que la longitud de los datos totales a transferir es un múltiplo exacto del tamaño del bloque, se envía un paquete extra sin datos para terminar la transferencia. Resultado de las pruebas Se ejecutaron las pruebas en un prototipo que usaba la opción de tamaño de bloque. Estas pruebas se ejecutaron en una red Ethernet ligeramente cargada, entre dos HP-UX 9000, y en modo "octet", con archivos de 2,25MB de tamaño. La media (5x) de los tiempos de transferencia con puerta de enlace (tiempo g) y sin ella (tiempo n) pueden observarse en la siguiente gráfica: Malkin y Harkin Estándar [Pág. 3] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 | 37 + g | 35 + | 33 + | 31 + | 29 + | 27 + | g T. bloque tiempo n tiempo g 25 + --------- -------- -------- s | n 512 23.85 37.05 e 23 + g 1024 16.15 25.65 g | 1432 13.70 23.10 u 21 + 2048 10.90 16.90 n | 4096 6.85 9.65 d 19 + 8192 4.90 6.15 o | s 17 + g | n 15 + | n 13 + | 11 + n | g 9 + | 7 + n | g 5 + n " 0 +------+------+--+---+------+------+--- 512 1K | 2K 4K 8K 1432 tamaño del bloque (bytes) La comparativa de los tiempos de transferencias entre el estándar de 512 bytes y las diferentes negociaciones de tamaño de bloque son: 1024 2x -32% 1432 2.8x -42% 2048 4x -54% 4096 8x -71% 8192 16x -80% Malkin y Harkin Estándar [Pág. 4] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 Como se podía intuir, los tiempos de transferencia mejoran al incrementar el tamaño del bloque. La razón de esta reducción del tiempo usado, se debe que se ha disminuido la cantidad de paquetes a enviar. Por ejemplo, si pasamos de un tamaño de bloque de 512 bytes a 1024 bytes, no solo estamos usando la mitad de los paquetes de datos, si no que también los paquetes de reconocimiento han bajado a la mitad (además el número de veces que el transmisor ha de esperar el ACK, también mejora). Otro efecto de mejora que se obtiene es la mejor eficiencia en los tiempos de procesado de cada paquete. Claro que si el tamaño del bloque excede del MTU, entonces se producirá una fragmentación y vuelta a ensamblar de la IP lo que volverá a añadir tiempo de procesado. Esto se notará aún más cuando aumente el número de puertas de enlace en esa línea. Consideraciones de seguridad El protocolo TFTP básico no posee mecanismos de seguridad. Esto es así porque no tiene capacidad de renombrar, borrar o sobre escribir archivos. Este documento no añade ningún tipo de seguridad al TFTP; de todas maneras esta especificación de la negociación de opciones tampoco añade ningún riesgo adicional de seguridad. Referencias [1] Sollins, K., "El Protocolo TFTP (Revisión 2)", STD 33, RFC 1350, MIT, julio 1992. [2] Malkin, G., y A. Harkin, "Negociación de Opciones para el TFTP", RFC 2347, Xylogics, Inc., Hewlett Packard Co., mayo 1998. Dirección de los Autores Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 10821 Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com Art Harkin Networked Computing Division Malkin y Harkin Estándar [Pág. 5] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 Hewlett-Packard Company 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com Traductor: Gabriel Ortí i Flores Barcelona Malkin y Harkin Estándar [Pág. 6] RFC 2348 Opción del Tamaño de Bloque para TFTP mayo 1998 Declaración completa sobre los Derechos de la propiedad intelectual Derechos de la propiedad intelectual (C) La Sociedad de Internet (1998). Todos los derechos reservados. Puede copiarse este documento y/o sus traducciones, también pueden ser añadidos a otros documentos, y se pueden elaborar trabajos derivados que añadan o por otra parte expliquen o ayuden en su aplicación para ser, copiadas, publicadas y distribuidas, totalmente o en parte, sin restricción de ningún tipo, siempre y cuando se incluyan de forma íntegra el aviso de copyright anterior y este párrafo en todas las copias y los trabajos derivados. Por lo tanto, este documento no puede modificarse de forma alguna, quitando el aviso del derecho de la propiedad intelectual o referencias a la La Sociedad de Internet u otras organizaciones de Internet, excepto cuando sea necesario debido al desarrollo de estándares de Internet y en ese caso deben seguirse los procedimientos para los derechos de la propiedad intelectual definidos en los estándares de Internet, o según se requiera cuando se traduzca a otras lenguas distintas del inglés Los permisos concedidos limitados lo son a perpetuidad y no se revocarán por La Sociedad de Internet, sus sucesores o concesionarios. Este documento y la información contenida en él se proporcionan "TAL CUAL" LA SOCIEDAD DE INTERNET Y LA DIVISIÓN DE INGENIERIA DE INTERNET DECLINAN TODAS LAS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUYENDO PERO NO LIMITANDO A CUALQUIER GARANTÍA QUE EN EL USO DE LA INFORMACIÓN CONTENIDA NO SE INFRINGIRÁ NINGÚN DERECHO O CUALQUIER GARANTÍA IMPLÍCITA DE COMERCIALIZACIÓN O LA APTITUD PARA UN PROPÓSITO PARTICULAR. Malkin y Harkin Estándar [Pág. 7]