Option TFTP Taille de bloc

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 suggestions pour son amélioration. Prière de se référer à l'édition en cours des "Normes officielles des protocoles de l'Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé

Le protocole trivial de transfert de fichier [RFC1350] est un protocole simple de transfert de fichier, en mode rigide, qui permet à un client de mettre un fichier sur un hôte distant ou de l’en obtenir. 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 très simple à mettre en œuvre dans l’espace de ROM limité d’un petite nœud. Cependant, le choix d’une taille de bloc de 512 octets n’est pas le plus efficace lorsque utilisée sur un LAN dont la MTU permet 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 [RFC1782].

Spécification de l’option Taille de bloc

Le paquet TFTP Demande de lecture ou Demande d’écriture est modifié de façon à inclure l’option Taille de bloc comme suit :

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

| opc |nom-de-fichier| 0 | mode | 0 |taille-de-bloc| 0 | #octets| 0 |

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

opc

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

nom-de-fichier

C’est le nom du fichier à lire ou à écrire, comme défini dans la [RFC1350]. C’est un champ terminé par NUL.

mode

Mode du transfert de fichier : "netascii", "octet", ou "mail", comme défini dans la [RFC1350]. C’est un champ terminé par NUL.

taille-de-bloc

C’est l’option Taille de bloc, "blksize" (insensible à la cesse). C’est un champ terminé par NUL.

#octets

C’est le nombre d’octets dans un bloc, spécifié en ASCII. La valeurs valides sont dans la gamme entre "8" et "65 464" octets, inclus. C’est un champ terminé par NUL.

Par exemple :

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

| 1 | foobar | 0 | binaire | 0 | blksize | 0 | 1432 | 0 |

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

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

Si le serveur veut accepter l’option Taille de bloc, il envoie un Accusé de réception d’option (OACK) 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 8, pour mettre un terme au transfert.

Les règles pour déterminer le paquet final sont celle de la [RFC1350] inchangées.

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 taille du paquet, 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 achever le transfert.

Preuve du concept

Des essais de performances ont été effectués sur le prototype de mise en œuvre en utilisant diverses tailles de bloc. Les essais ont été effectués sur un Ethernet à faible charge, 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 (g-time) et sans (n-time) passerelle intermédiaire sont l’objet du graphe ci-dessous :

|

37 + g

|

35 +

|

33 +

|

31 +

|

29 +

|

27 +

| g blocksize n-time g-time

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

s | n 512 23,85 37,05

e 23 + g 1024 16,15 25,65

c | 1432 13,70 23,10

o 21 + 2048 10,90 16,90

n | 4096 6,85 9,65

d 19 + 8192 4,90 6,15

s |

17 + g

| n

15 +

| n

13 + |

11 + n

| g

9 +

|

7 + n

| g

5 + n

"

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

512 1K | 2K 4K 8K

1432

blocksize (octets)

La comparaison entre les temps de transfert (sans passerelle) entre la taille de bloc standard de 512 octets et les tailles de bloc négociées sont :

1024 2x -32%

1432 2.8x -42%

2048 4x - 54 %

4096 8x - 71 %

8192 16x - 80 %

Comme on l’avait prévu, les temps de transfert diminuent avec une augmentation 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és de réception est aussi divisé par deux (ainsi que le nombre de fois où l’émetteur doit attendre un ACK). Un effet secondaire est l’efficacité gagnée en réduisant le tramage par paquet et la redondance de traitement.

Bien sûr, si la taille de bloc excède la MTU du chemin, la fragmentation et le réassemblage IP vont commencer à rajouter de la redondante Cela sera plus remarqué si il y a un plus grand nombre de passerelles sur le chemin.

Considérations pour la sécurité

Les questions de sécurité ne sont pas discutées dans le présent mémoire.

Références

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

[RFC1782] G. Malkin, A. Harkin, "Extension d'option TFTP", mars 1995. (P.S.)

Adresse des auteurs