Résumé

  • Dans l’essai de la RFC 2348, le transfert de 2,25 Mo passe de 23,85 à 4,90 secondes sans passerelle intermédiaire lorsque le bloc passe de 512 à 8 192 octets.
  • La charge utile est seize fois plus grande, mais le temps mesuré baisse d’environ 80 %, pas d’un facteur seize. Le texte prévient que la fragmentation et le réassemblage au-delà du MTU du chemin ajoutent des coûts.

Le TFTP traditionnel misait sur la simplicité. Un client demandait un fichier, recevait un bloc, l’acquittait puis attendait le suivant. Le format de 512 octets convenait aux systèmes modestes — notamment aux machines sans disque qui démarraient depuis une ROM limitée — mais chaque bloc imposait aussi un aller-retour d’acquittement. Sur un réseau local dont le MTU autorisait des trames plus grandes, une partie du temps pouvait être absorbée par cette cadence plutôt que par les données.

En mai 1998, la RFC 2348 a proposé une option blksize négociée. La RFC 2347 avait défini le mécanisme général : le client ajoutait l’option à sa requête de lecture ou d’écriture et le serveur répondait éventuellement par un OACK. Celui-ci pouvait accepter une valeur inférieure ou égale à la demande; le serveur ne pouvait pas proposer une option que le client n’avait pas sollicitée. Le client devait employer la valeur acquittée ou interrompre le transfert. Un serveur ancien pouvait ignorer l’option et poursuivre selon le TFTP ordinaire. Il s’agissait d’une extension compatible, pas d’un remplacement silencieux du protocole.

La plage prévue allait de 8 à 65 464 octets de données par bloc, sans compter l’en-tête TFTP de quatre octets. La RFC donnait 1 428 octets comme exemple calculé à partir d’un MTU Ethernet après déduction des en-têtes TFTP, UDP et IP. Ce chiffre illustrait un calcul; il ne désignait pas une valeur universelle. L’accord entre les deux extrémités TFTP ne prouvait pas que chaque lien, tunnel ou segment intermédiaire pouvait transporter le datagramme sans fragmentation.

La RFC publiait aussi une expérience de prototype : deux systèmes HP-UX 9000, un Ethernet peu chargé, le mode octet, des fichiers de 2,25 Mo et la moyenne de cinq transferts. Les auteurs comparaient un chemin sans passerelle intermédiaire à un autre qui en comportait une. À 512 octets, les durées étaient respectivement de 23,85 et 37,05 secondes; à 8 192 octets, de 4,90 et 6,15 secondes. Le temps écoulé a donc été divisé par environ 4,87 sans passerelle et 6,02 avec passerelle, soit une baisse proche de 79,5 % et 83,4 %.

Le « 16x » du comparatif de la RFC se lit correctement comme le rapport entre tailles de bloc : 8 192 divisé par 512. Il ne décrit pas une vitesse multipliée par seize. La baisse d’environ 80 % concorde avec les durées brutes. Distinguer rapport de taille, nombre de paquets et temps mural évite de transformer le résultat en slogan. L’amélioration n’en reste pas moins forte : des blocs plus larges réduisaient le nombre de paquets de données, d’acquittements et d’attentes, ainsi que le coût de traitement par paquet.

La limite figurait dans le même document. Si le bloc dépassait le MTU du chemin, la fragmentation et le réassemblage IP ajoutaient des frais; les auteurs s’attendaient à ce que le problème se voie davantage à mesure que les passerelles s’accumulaient. Le test n’explorait ni une grande variété de chemins Internet, ni la variance des mesures, ni un bloc optimal pour tous les réseaux. Il décrivait un mécanisme et un résultat de prototype borné, pas un recensement des déploiements.

Des travaux ultérieurs ont exploré un autre réglage. La RFC 7440 définit windowsize, qui autorise plusieurs blocs consécutifs avant l’attente d’un acquittement. La profondeur de fenêtre et la taille des blocs sont deux leviers distincts. La RFC 8900, publiée bien plus tard, traite de la fragilité opérationnelle de la fragmentation IP; elle ne prouve pas que l’essai de 1998 ait échoué. L’avertissement contemporain suffisait déjà : une valeur négociée ne certifie pas le chemin entier.

La leçon historique est plus précise que « plus gros, c’est plus rapide ». Une petite machine pouvait demander une unité de transfert mieux adaptée au réseau, les auteurs montraient un gain marqué dans des conditions explicites, puis la RFC nommait la frontière où ce gain pouvait s’éroder. Le chiffre utile n’était donc pas une valeur magique, mais un point de départ pour mesurer le chemin réellement emprunté.

Le cadre initial vient de RFC 1350; les options de temporisation et de taille de transfert publiées à la même époque sont dans RFC 2349. Ces documents aident à distinguer la taille de bloc des autres paramètres négociables.