Zusammenfassung

  • Ein Client schickte RRQ oder WRQ an den bekannten TID 69; nach Annahme antwortete der Server von einem selbst gewählten TID, und beide Werte wurden zu den UDP-Ports der restlichen Übertragung.
  • Ein falscher Quell-TID löste Fehler 5 aus, ohne den gültigen Transfer zu beenden; Korrekturen und spätere Optionen erweiterten Verhalten und Durchsatz, nicht die Beweiskraft des TID.

Die Regel musste einen Übergang verstehen

TFTP sollte mit wenig Code Dateien lesen oder schreiben. RFC 783 verzichtete auf Verzeichnislisten, umfassende Sitzungsbefehle und Benutzerauthentisierung. Das machte das Verfahren für kleine Startumgebungen attraktiv, verlagerte aber Verbindungszustand in wenige sichtbare Werte.

Der Client wählt einen TID und sendet die erste Anfrage an TID 69 des Servers. Bei einem Read Request kommt die positive Antwort als DATA 1 von einem neu gewählten Server-TID. Bei einem Write Request ist es ACK 0. Beide TIDs werden als Ports an UDP übergeben und gelten für alle weiteren Datagramme.

Port 69 ist somit die stabile Adresse für noch nicht angenommene Wünsche. Er ist nicht zwingend der Quellport der Datei. Ein zustandsloser Filter, der nur das bekannte Dienstetikett kennt, lässt die Türglocke durch und sperrt den Besucher nach dem Öffnen aus.

Das erste angenommene Paket schloss den Kreis

Nach der positiven Antwort muss jede Seite den erwarteten Quell-TID prüfen. Das dient auch einem rein netzbedingten Fall. Wird die erste Anfrage dupliziert, kann der Server für jede Kopie einen anderen Transfer beginnen und aus verschiedenen TIDs antworten.

Der Client setzt die erste angenommene Antwort fort. Eine spätere Antwort aus dem zweiten TID wird verworfen und erhält Fehlercode 5, Unknown transfer ID. Der bereits laufende Transfer bleibt unberührt.

RFC 1350 behandelt den falschen Quellport als den erkannten Fehler, der die Verbindung nicht beendet. Übliche ERROR-Pakete markieren dagegen das Ende und werden weder bestätigt noch erneut gesendet. Fehler 5 sagt nicht „der Transfer ist gescheitert“, sondern „dieses Datagramm gehört nicht zu diesem Transfer“.

Mehr kann der TID nicht belegen. Ein zufällig gewählter Port authentisiert keinen Server, schützt nicht gegen jede Fälschung und validiert weder Berechtigung noch Dateiinhalt. Er ist ein kurzlebiger Zuordnungsschlüssel.

Ein Block bildete das offene Ende

Im Grundverfahren folgt auf jeden DATA-Block ein ACK, bevor der nächste Block gesendet wird. Die Nummerierung beginnt bei eins. Ein Block unter 512 Oktetten signalisiert das Ende; bei einem exakten Vielfachen wird ein leerer Endblock benötigt.

Der Sender hält nur den aktuellen Block bereit. Der Empfänger muss kein Fenster umsortieren. Nach dem letzten ACK darf er kurz warten: Kommt der letzte DATA-Block erneut, war das ACK möglicherweise verloren und kann wiederholt werden.

Der offene Zustand bestand aus erwartetem TID, Blocknummer und Timer. Eine neue Nummer bedeutete Fortschritt, eine alte Nummer Wiederholung, ein fremder TID eine andere Unterhaltung. Diese kleine Zustandsmenge funktionierte nur, solange nicht jedes veraltete Signal neue Arbeit anordnen durfte.

Die Wiederholung wurde zum Verstärker

Die frühe Beschreibung erlaubte beiden Seiten, bei einem alten doppelten Datagramm das aktuelle Datagramm erneut zu senden. Nach Verzögerung und Timeout konnte eine späte Kopie eine neue Antwort erzeugen. Deren Kopie erzeugte wiederum eine Antwort. DATA und ACK liefen fortan doppelt.

RFC 1123 nannte dies Sorcerer's Apprentice Syndrome. Die Datei musste dabei nicht beschädigt werden. Zusätzliche Pakete verschärften die Verzögerung, die sie ausgelöst hatte, und konnten den Transfer in weitere Timeouts treiben.

Die verpflichtende Korrektur entzog einem doppelten ACK die Auslösebefugnis: Der DATA-Ursprung darf den aktuellen Block nicht allein deshalb erneut senden. Der passende Timeout oder der definierte Zustand entscheidet über Wiederholung. RFC 1350 ersetzte RFC 783 mit der korrigierten Regel.

Aushandeln hieß nicht aufzwingen

Stop-and-wait sparte Speicher und verschenkte auf leistungsfähigeren Wegen Kapazität. RFC 2347 fügte Optionen an RRQ und WRQ an. Nur der Client initiiert sie. Ein Server darf im OACK lediglich angefragte Optionen bestätigen, nicht unterstützte auslassen und unzulässige Werte nach der jeweiligen Regel behandeln.

Beim Lesen bestätigt ACK 0 den OACK, beim Schreiben DATA 1. Eine nicht bestätigte Option wird ignoriert. RFC 2348 machte die Blockgröße verhandelbar, RFC 2349 Timeout und Transfergröße. RFC 7440 ließ ein Fenster aufeinanderfolgender Blöcke zu, bevor das ACK für dessen letzten Block fällig wurde.

Ein größeres Fenster erhöht Durchsatz und die Menge noch nicht bestätigten Zustands. Es hebt die beiden TIDs nicht auf. Ebenso wenig ergänzt es Authentisierung, Verschlüsselung oder Dateiberechtigung. Es ist eine Einigung darüber, wie viel Arbeit zwischen zwei Fortschrittsbelegen stattfinden darf.

Die Datei blieb Sache der Umgebung

Eine Übertragung kann alle TIDs und Blocknummern korrekt verwenden und dennoch die falsche Boot-Datei liefern oder einen unerlaubten Pfad überschreiben. TFTP legt keine vertrauenswürdige Dateiwurzel und keine Herkunftsprüfung fest.

Netzreichweite, Lese- und Schreibrechte, Artefaktprovenienz, Firewall- oder NAT-Zustand und die Verbindung des Antrags auf 69 mit dem dynamischen Paar müssen außerhalb des Protokolls geregelt werden. Alle UDP-Ports zu öffnen, weil der Server einen auswählt, beseitigt die Grenze statt sie abzubilden.

TFTPs historische Pointe liegt deshalb nicht nur in Einfachheit. Ein öffentlicher Rendezvouspunkt und eine angenommene Unterhaltung besitzen verschiedene Befugnisse. Ein Fehler kann den gültigen Zustand schützen, indem er fremde Zugehörigkeit zurückweist. Und eine Leistungsverbesserung bleibt beherrschbar, wenn Vorschlag, Zustimmung, Endpunkte und Fortschritt weiterhin getrennt nachweisbar sind.

Quellen und Grenzen

Das frühe Verfahren steht in RFC 783, die Duplikatkorrektur in RFC 1123, die Revision in RFC 1350. Optionen definieren RFC 2347, RFC 2348, RFC 2349 und RFC 7440. Das IANA-Register führt Port 69. Die Quellen messen keine Verbreitung im Jahr 2026 und machen aus einem TID weder Identität noch Erlaubnis, Vertraulichkeit oder Inhaltsbeweis.