Option Taille de bloc TFTP

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (1998).

Résumé

Le protocole trivial de transfert de fichier (TFTP, Trivial File Transfer Protocol) [RFC1350] est un simple protocole de transfert de fichier, en mode rigide, qui permet à un client d'obtenir ou de mettre un fichier sur un hôte distant. Une de ses principales utilisations est l'amorçage de nœuds sans disque sur un réseau de zone locale. TFTP est utilisé parce qu'il est de mise en œuvre très simple dans l'espace de ROM limité d'un petit nœud. Cependant, le choix d'une taille de bloc de 512 octets n'est pas des plus efficaces pour l'utilisation sur un LAN dont la MTU peut être de 1500 octets ou plus.

Le présent document décrit une option TFTP qui permet au client et au serveur de négocier une taille de bloc plus applicable au support réseau. Le mécanisme d'extension d'option TFTP est décrit dans la [RFC2347].

Spécification de l'option Taille de bloc (Blocksize)

Le paquet TFTP Demande de lecture ou Demande d'écriture est modifié pour inclure l'option Taille de bloc comme suit. Noter que tous les champs sauf "opcode" sont terminés par NULL.

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

| opcode|filename| 0 | mode | 0 | blksize| 0 | #octets| 0 |

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

opcode

Le champ opcode contient soit un 1, pour les demandes de lecture, soit 2, pour les demandes d'écriture, comme défini dans la [RFC1350].

filename

Nom du fichier à lire ou écrire, comme défini dans la [RFC1350].

mode

Mode du transfert de fichier : "netascii", "octet", ou "mail", comme défini dans la [RFC1350].

blksize

L'option Taille de bloc, "blksize" (insensible à la casse).

#octets

Nombre d'octets dans un bloc, spécifié en ASCII. Les valeurs valides vont de "8" à "65464" octets, inclus. La taille de bloc se réfère au nombre d'octets de données ; elle n'inclut pas les quatre octets de l'en-tête TFTP.

Par exemple :

+-------+--------+---+--------+---+--------+---+--------+---+

| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |

+-------+--------+---+--------+---+--------+---+--------+---+

est une demande de lecture, pour le fichier nommé "foobar", en mode de transfert d'octet (binaire) avec une taille de bloc de 1428 octets (MTU Ethernet, moins les longueurs d'en-tête TFTP, UDP et IP).

Si le serveur veut accepter l'option blocksize (taille de bloc) il envoie un accusé de réception d'option (OACK, Option Acknowledgment) au client. La valeur spécifiée doit être inférieure ou égale à la valeur spécifiée par le client. Le client doit alors soit utiliser la taille spécifiée dans le OACK, soit envoyer un paquet ERREUR, avec le code d'erreur de 8, pour terminer le transfert.

Les règles pour déterminer le paquet final sont inchangées par rapport à la [RFC1350]. La réception d'un paquet de données avec une longueur de données inférieure à la taille de bloc négociée est le paquet final. Si la taille de bloc est supérieure à la quantité de données à transférer, le premier paquet est le paquet final. Si la quantité de données à transférer est un multiple entier de la taille de bloc, un paquet de données supplémentaire ne contenant pas de données est envoyé pour terminer le transfert.

Preuve du concept

Des essais de performances ont été effectués sur un prototype de mise en œuvre utilisant diverses tailles de bloc. Les essais ont été effectués sur un Ethernet à charge légère, entre deux HP-UX 9000, en mode "octet", sur des fichiers de 2,25 Mbits. Les temps de transfert moyens (5x) pour les chemins avec une passerelle intermédiaire (g-time) et sans (n-time) sont retracés comme suit :

|

37 + g

|

35 +

|

33 +

|

31 +

|

29 +

|

27 +

| g Taille de bloc n-time g-time

25 + ------------- ------ ------

s | n 512 23,85 37,05

e 23 + g 1024 16,15 25,65

c | 1428 13,70 23,10

o 21 + 2048 10,90 16,90

n | 4096 6,85 9,65

d 19 + 8192 4,90 6,15

e |

s 17 + g

| n

15 +

| n

13 +

|

11 + n

| g

9 +

|

7 + n

| g

5 + n

"

0 +------+------+--+---+------+------+---

512 1K | 2K 4K 8K

1428

Taille de bloc (octets)

Les comparaisons entre les temps de transfert (sans passerelle) entre la taille de bloc standard de 512 octes et la taille de bloc négociée sont :

1024 : 2 x -32%

1428 :2,8 x -42%

2048 : 4 x -54%

4096 : 8 x -71%

8192 : 16 x -80%

Comme prévu, le temps de transfert diminue avec l'accroissement de la taille de bloc. La raison de la réduction de temps est la réduction du nombre de paquets envoyés. Par exemple, en augmentant la taille de bloc de 512 octets à 1024 octets, non seulement le nombre de paquets de données est divisé par deux, mais le nombre de paquets d'accusé de réception est aussi divisé par deux (ainsi que le nombre de fois que le transmetteur de données doit attendre un ACK). Un effet secondaire est le gain d'efficacité par la réduction de la redondance de tramage et de traitement par paquet.

Bien sûr, si la taille de bloc excède la MTU du chemin, la fragmentation et le réassemblage IP vont commencer à ajouter de la redondance. Cela va se remarquer d'autant plus en fonction du nombre de passerelles sur le chemin.

Considérations sur la sécurité

Le protocole TFTP de base n'a pas de mécanisme de sécurité. C'est pourquoi il n'a pas de capacité de renommage, suppression ou écrasement de fichier. Le présent document n'apporte aucune sécurité à TFTP ; cependant, les extensions spécifiées n'ajoutent aucun risque supplémentaire pour la sécurité.

Références

[RFC1350] K. Sollins, "Protocole TFTP (révision 2)", STD 33, juin 1992. (MàJ par 1782-85, 2347_49)

[RFC2347] G. Malkin, A. Harkin, "Extension d'option TFTP", mai 1998. (D.S.)

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1998). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.