Zusammenfassung

  • Im Prototypversuch aus RFC 2348 sank die Zeit für 2,25 MB von 23,85 auf 4,90 Sekunden, wenn die Blöcke auf einem Pfad ohne Zwischengateway von 512 auf 8.192 Oktette wuchsen.
  • Die Blocknutzlast wurde 16-mal größer; die gemessene Zeit sank um etwa 80 Prozent, nicht um den Faktor 16. RFC 2348 selbst warnt, dass Fragmentierung und Reassemblierung oberhalb der Pfad-MTU Aufwand erzeugen.

Das ursprüngliche TFTP setzte auf einen einfachen Takt: Datenblock empfangen, bestätigen, auf den nächsten warten. Die üblichen 512 Oktette hielten den Austausch überschaubar – ein Vorteil für kleine Systeme, etwa plattenlose Rechner mit begrenztem Boot-ROM. Auf einem lokalen Netz mit größeren Frames konnte die Bestätigungspause jedoch einen spürbaren Teil des Transfers ausmachen.

Im Mai 1998 machte RFC 2348 die Option blksize verhandelbar. Den allgemeinen Mechanismus hatte RFC 2347 festgelegt: Der Client hängt Optionen an eine Lese- oder Schreibanforderung; der Server kann mit einem OACK antworten. Bei der Blockgröße durfte er höchstens den vom Client gewünschten Wert bestätigen. Der Server konnte keine Option von sich aus anfordern. Der Client musste den bestätigten Wert verwenden oder die Übertragung abbrechen. Verstand ein älterer Server die Option nicht, konnte der gewöhnliche TFTP-Ablauf weitergehen. Die Erweiterung war abwärtskompatibel angelegt, keine Pflichtänderung für alle Endpunkte.

Zulässig waren 8 bis 65.464 Oktette Nutzdaten pro Block; der vier Oktette lange TFTP-Header zählte nicht mit. Als Ethernet-Beispiel führte die RFC 1.428 Oktette an, nachdem TFTP-, UDP- und IP-Header berücksichtigt wurden. Das war eine Rechenillustration, kein universeller Wert. Eine Einigung zwischen den beiden TFTP-Prozessen bewies nicht, dass jeder Link, Tunnel und Zwischenhop das resultierende IP-Datagramm ohne Fragmentierung transportieren konnte.

Die Autoren lieferten einen Prototypversuch mit klar begrenzten Bedingungen: zwei HP-UX-9000-Systeme, ein wenig belastetes Ethernet, Octet-Modus und Dateien von 2,25 MB. Die angegebenen Zeiten waren Mittelwerte aus jeweils fünf Übertragungen; getestet wurde mit und ohne ein Zwischengateway. Bei 512 Oktetten lagen sie bei 23,85 beziehungsweise 37,05 Sekunden. Bei 8.192 Oktetten waren es 4,90 und 6,15 Sekunden. Die Übertragungszeit verkürzte sich damit um den Faktor 4,87 ohne und 6,02 mit Gateway – eine Verringerung von ungefähr 79,5 beziehungsweise 83,4 Prozent.

Das „16x“ der Vergleichstabelle bezeichnet das Verhältnis der Blockgrößen: 8.192 geteilt durch 512. Es bedeutet nicht, dass die Datei 16-mal schneller ankam. Der ausgewiesene Rückgang um etwa 80 Prozent passt zu den Rohzeiten. Blockgröße, Paketanzahl und Wandzeit sind verschiedene Größen. Der Gewinn bleibt dennoch beträchtlich: Größere Blöcke senkten die Anzahl der Daten- und Bestätigungspakete, die Zahl der Wartephasen sowie den Rahmen- und Verarbeitungsaufwand je Paket.

Die Einschränkung stand direkt daneben. Überschritt die Blockgröße die Pfad-MTU, verursachten IP-Fragmentierung und Reassemblierung zusätzlichen Aufwand; mit mehr Gateways sollte dieser stärker ins Gewicht fallen. Was im Test-Ethernet passte, musste hinter einem kleineren Link oder zusätzlicher Kapselung nicht mehr passen. Der Versuch untersuchte keine breite Auswahl an Internetpfaden, veröffentlichte keine Streuung der Messwerte und bestimmte keine allgemein optimale Blockgröße. Er dokumentierte einen Prototyp unter benannten Bedingungen, keine Einsatzstatistik.

Später kam eine andere Stellschraube hinzu: RFC 7440 definiert windowsize, also mehrere aufeinanderfolgende Blöcke vor der nächsten Bestätigung. Blockgröße und Fensterbreite verändern den Aufwand des Wartens auf unterschiedliche Weise. Die wesentlich spätere RFC 8900 behandelt die betriebliche Fragilität von IP-Fragmentierung; sie ist kein nachträglicher Beweis, dass der Versuch von 1998 scheiterte. Die Warnung der ursprünglichen RFC genügt: Ein ausgehandelter Wert bestätigt nicht die Eignung des ganzen Pfades.

Die historische Pointe lautet daher nicht „größer ist immer schneller“. RFC 2348 ließ ein einfaches Protokoll seine Transporteinheit an die Netzeigenschaften anpassen, zeigte unter expliziten Bedingungen einen deutlichen Gewinn und benannte die MTU-Grenze, an der er schrumpfen konnte. Der Messwert war keine Zauberzahl, sondern ein Anlass, den tatsächlich genutzten Pfad zu prüfen.

Die Basis steht in RFC 1350. Zeitüberschreitungs- und Übertragungsgrößenoptionen aus derselben Zeit beschreibt RFC 2349; sie helfen, blksize von anderen verhandelbaren Parametern zu unterscheiden.