TFTP (Trivial File Transfer Protocol) – das einfache Dateiübertragungsprotokoll
Damit der Datenaustausch zwischen zwei Computersystemen im Netzwerk funktioniert, ist eine gemeinsame Verständigungsbasis unverzichtbar. Eines der einfachsten, zu diesem Zweck entwickelten Protokolle ist das Trivial File Transfer Protocol (TFTP), das insbesondere in den Anfängen des Internets eine wichtige Rolle gespielt hat.
Was ist TFTP (Trivial File Transfer Protocol)?
Das Trivial File Transfer Protocol, kurz TFTP, ist ein sehr einfaches Client-Server-Protokoll, das den Transfer von Dateien in Computernetzwerken regelt. Eine erste Spezifikation wurde im Juni 1981 in RFC 783 veröffentlicht. Der aktuelle Standard ist im 1992 erschienenen RFC 1350 nachzulesen. Das TFTP-Protokoll setzt standardmäßig auf dem ebenfalls minimalistischen Transportprotokoll UDP (User Datagram Protocol) auf, das eine Datenübertragung ohne feste Verbindung zwischen den Kommunikationspartnern vorsieht. Die Implementierung von TFTP auf Basis anderer Protokolle ist grundsätzlich aber ebenfalls möglich.
Das paketorientierte Dateiübertragungsprotokoll, das Teil der TCP/IP-Protokollfamilie ist, wurde extra so konzipiert, dass es möglichst klein und leicht zu implementieren ist. Aus diesem Grund beschreibt es lediglich Methoden, um Dateien oder Mails von einem Server zu lesen bzw. auf diesen zu schreiben. Eine Auflistung von Verzeichnissen oder die Rechtevergabe über chmod – wie es das besser bekannte FTP (File Transfer Protocol) erlaubt – sind mit TFTP nicht möglich. Für Anfragen nutzt TFTP den Port 69. Im Anschluss gelingt die Kommunikation über individuell vergebene Port-Nummern (zwischen 1024 und 65535), die der TFTP-Server dem anfragenden Client in Form von TIDs (Transfer Identifiers) übermittelt.
Viele Betriebssysteme haben bereits eigene TFTP-Clients und -Server implementiert, die Sie für den Dateitransfer über das Protokoll nutzen können. Viele Linux- und Windows-Versionen (insbesondere die Server-Editionen) bieten beispielsweise standardmäßig die Kommandozeilentools tftpd (Server) und tftp (Client). Darüber hinaus gibt es verschiedene Drittanbieterlösungen wie die Open-Source-Software Tftpd32, die sowohl einen Server als auch einen Client enthält.
So funktioniert das TFTP-Protokoll
Der Dateitransfer via TFTP basiert immer auf einer Client-Anfrage, bei der entweder Schreib- oder Lesezugriffe erbeten werden. Diese Anfrage dient gleichzeitig als Verbindungsgesuch, dem automatisch stattgegeben wird, wenn der Server den Zugriff akzeptiert. Im Anschluss senden Client oder Server die entsprechende Datei in Blöcken, die eine festgelegte Größe haben. In den ersten Protokollversionen galt dabei noch der fixe Wert von 512 Bytes – seit RFC 2348 haben Server und Client die Möglichkeit, die Blockgröße individuell auszuhandeln.
Ursprünglich war die Größe der via TFTP verschickten Dateien auf 32 MB begrenzt. Mit dem 1998 veröffentlichten RFC 2347 ist diese Grenze jedoch auf 4 GB angehoben worden.
Der Versand findet Block für Block statt, wobei jeder empfangene Block durch ein Bestätigungspaket („Acknowledgement“) quittiert werden muss, bevor der nächste verschickt werden kann. Ein Datenpaket, das kleiner als die festgelegte Bytegröße ist, kennzeichnet das Ende des Dateitransfers. Geht ein Paket während des Transfers verloren, kommt es beim Empfänger zu einem Timeout, in dessen Folge er sein zuletzt geschicktes Paket erneut sendet. Auf diese Weise erfährt der Sender des verlorenen Pakets, dass er dieses erneut transferieren muss. Fehler, die während der TFTP-Dateiübertragung entstehen, führen zu Fehlerpaketen, die die Übertragung in den meisten Fällen beenden. Mögliche Fehlerquellen sind die folgenden drei Ereignisse:
- Die Anfrage kann nicht zufriedenstellend beantwortet werden, beispielsweise weil die Datei nicht gefunden wurde, weil der Nutzer nicht existiert oder aufgrund einer Zugriffsverletzung (geschützte Datei etc.).
- Client oder Server empfangen ein Paket, das nicht durch eine Verzögerung oder durch Duplizierung im Netzwerk erklärt werden kann, was etwa bei einem falsch gebildeten Paket der Fall ist.
- Der Zugriff auf eine notwendige Ressource geht verloren, z. B. wenn nicht mehr genügend Festplattenspeicher übrig ist.
Wie sind TFTP-Pakete aufgebaut?
Das TFTP-Protokoll unterstützt insgesamt fünf Typen von Paketen, die sich jeweils durch ein eigenes, 16 Bit langes „Opcode“-Feld (Operations-Code) mit dem entsprechenden Wert ankündigen:
| Opcode | Paket-Typ | BeÂschreiÂbung | |
|---|---|---|---|
| 1 | RRQ (Read request) | Anfrage für LeÂseÂzuÂgriff | |
| 2 | WRQ (Write request) | Anfrage für SchreibÂzuÂgriff | |
| 3 | DATA (Data) | DaÂtenÂpaÂket | |
| 4 | ACK (AckÂnowÂledgment) | BeÂstäÂtiÂgungsÂnachÂricht | |
| 5 | ERROR (Error) | FehÂlerÂnachÂricht |
Der opcode-Wert ist allerdings nicht die einzige Komponente, in der sich der Aufbau der aufgelisteten Paket-Typen unterscheidet.
Aufbau von TFTP-Lese-(RRQ) und Schreibzugriff-Paketen (WRQ)
Die initiativen Anfragen, die ein TFTP-Client sendet, um Dateien auf dem TFTP-Server lesen (RRQ-Paket) bzw. auf den Server schreiben (WRQ-Paket) zu können, unterscheiden sich lediglich hinsichtlich des Operations-Codes. Ansonsten zeichnen sich beide Paket-Typen durch folgendes, gleiches Format aus:
Sowohl RRQ- als auch WRQ-Nachrichten starten mit dem protokolltypischen, 16 Bit langen Opcode-Feld. Wie die erste Tabelle zeigt, nutzen RRQ-Pakete an dieser Stelle den Wert „1“, während WRQ-Pakete durch den Wert „2“ gekennzeichnet sind. Es folgt eine Bit-Sequenz im NetASCII-Format mit variabler Größe; diese enthält den Namen der Datei, die gelesen bzw. gesendet werden soll. Das Ende kennzeichnet ein aus Nullen bestehendes 8-Bit-Feld.
Beim NetASCII-Format handelt es sich um ein spezielles, in 8 Bit verpacktes ASCII-Format, das die selten gebrauchten Kontrollzeichen undefiniert lässt. Es enthält den kompletten Block der 95 druckbaren Zeichen von x20 bis x7E (32–126) sowie einige Sonderzeichen (insbesondere NUL, CR, LF).
Eine weitere Zeichenkette, deren Länge variabel ist, enthält schließlich die Information über den Transfermodus der Daten. Hierbei gibt es die drei Varianten „netascii“, „octet“ (für den Transfer einer Datei im 8-Bit-Format) und „mail“ (für den Transfer an eine E-Mail-Adresse). Auch das Ende dieses Felds wird durch eine angehängte 8-Bit-Gruppe aus Nullen gekennzeichnet.
Aufbau von TFTP-Datenpaketen (DATA)
DATA-Pakete enthalten die Dateien, die zwischen Client und Server ausgetauscht werden sollen. Da die Übermittlung dieser Daten in Blöcken stattfindet, enthält eine TFTP-DATA-Nachricht immer nur einen Teil der Datei – mit Ausnahme von Dateien, deren Gesamtgröße kleiner als die standardmäßig definierten 512 Bytes bzw. die individuell festgelegte Blockgröße ist. Das Format der Datenpakete sieht folgendermaßen aus:
Auch DATA-Pakete beginnen mit dem Opcode-Feld, dem in diesem Fall der Wert „3“ zugeordnet wird. Die darauffolgende 16-Bit-Sequenz kennzeichnet die Nummer des Datenblocks, wobei der Wert „1“ als Startnummer dient. Dieser Wert erhöht sich mit jedem weiteren Datenblock, der zu der Datei gehört, automatisch um 1. Die Blöcke selbst finden sich derweil im Datenfeld wieder, das zwischen 0 und 512 Bytes (4096 Bit) groß ist, sofern TFTP-Server und -Client keine andere Maximalgröße für die Blöcke ausgehandelt haben. Wird die jeweilige Maximalgröße ausgefüllt, ist dies ein Signal dafür, dass das DATA-Paket nicht den letzten Datenblock der Datei enthält. Dieser letzte Block, der das Ende des Datentransfers kennzeichnet, ist immer um mindestens ein Byte kleiner. Sollte der zu übertragende Dateirest zufällig exakt die Größe des Blocks haben, muss der Sender noch ein Paket mit leerem Datenblock nachreichen.
Aufbau der ACK-Pakete des TFTP-Protokolls
Alle WRQ-Pakete sowie alle Datenpakete, die nicht das Ende des Dateitransfers kennzeichnen, werden bei funktionierender Kommunikation über das Trivial File Transfer Protocol durch ACK-Nachrichten bestätigt (außer es kommt zu einem Timeout).
Requests, die Lesezugriff auf eine Datei fordern (RRQ-Pakete), werden nicht durch ACK-, sondern durch DATA-Pakete bestätigt.
Der Aufbau dieser sehr simplen Bestätigungsnachrichten sieht folgendermaßen aus:
Die ACK-Nachrichten der TFTP-Protokoll-Kommunikation bestehen aus dem 16 Bit langen Opcode, der den Wert „4“ annimmt, und der ebenfalls 16 Bit langen Nummer des Datenblocks, den die ACK-Nachricht bestätigt. Handelt es sich um eine Antwort auf eine WRQ-Anfrage, hat das ACK-Paket die Datenblock-Nummer „0“.
Aufbau der TFTP-Fehlernachrichten (ERROR)
ERROR-Nachrichten werden von Client oder Server verschickt, sobald es bei der TFTP-Kommunikation zu einem Fehler kommt. In der Konsequenz können diese Nachrichtenpakete eine mögliche Antwort auf sämtliche bereits aufgelisteten Paket-Typen sein. Die Fehlerpakete sind dabei grundsätzlich wie folgt aufgebaut:
Nach dem auch in ERROR-Nachrichten voranstehenden Opcode (Wert „5“) folgt ein 16 Bit langes Feld, das den Fehlercode enthält. So steht der Wert „1“ beispielsweise dafür, dass die entsprechende Datei nicht gefunden werden konnte, während der Wert „6“ dem empfangenden System verrät, dass die Datei bereits existiert. Die sich anschließende Fehlernachricht hilft dem Nutzer, das Problem zu verstehen. Auch aus diesem Grund ist diese Zeichenkette mit variabler Größe typischerweise im NetASCII-Format. Den Abschluss bildet ein 8-Bit-Feld aus Nullen.
Die Vor- und Nachteile von TFTP
TFTP überzeugt in erster Linie durch seine Schlichtheit. Das Protokoll soll das Schreiben und Lesen von Dateien ermöglichen und erfüllt diese Rolle, ohne dass eine Verbindung zwischen Client und Server etabliert werden muss. In der Konsequenz ist das TFTP-Protokoll nicht nur einfach zu implementieren, sondern auch Wegbereiter einer schnellen Dateiübertragung. Individuelle Transfer Identifier (TIDs) und einzigartige Datenblock-Nummern schaffen dabei die Basis dafür, dass die jeweilige Datei vollständig beim Empfänger ankommt.
Das Fehlen einer Verschlüsselung sowie eines Authentifizierungs- bzw. Zugriffskontrollmechanismus macht den Versand sensibler Dateien via TFTP allerdings zu einer höchst riskanten Angelegenheit, weshalb hierfür sicherere Alternativen wie das komplexere FTP eingesetzt werden sollten. Ferner ist das Löschen und Umbenennen von Dateien auf vielen TFTP-Servern nicht erlaubt.
Wo kommt das Trivial File Transfer Protocol zum Einsatz?
Das TFTP-Protokoll ist eng an das sogenannte Netzwerk-Booting (auch „Bootstrapping“) geknüpft. Bei dieser Technik, die insbesondere in den 1980er Jahren zum Einsatz kam, bezieht und startet ein Netzwerk-Computer das Betriebssystem von einem zentralen Server. Insbesondere für Terminals und festplattenlose Workstations, die keine Installation eines eigenen Betriebssystems ermöglichten, war die Entwicklung und Implementierung von TFTP daher von entscheidender Bedeutung. Unterstützung fand das Dateiübertragungsprotokoll durch das 1985 veröffentlichte BOOTP, durch das die Netzwerk-Clients die Adresse des TFTP-Servers automatisch beziehen konnten.
Zur Anzeige dieses Videos sind Cookies von Drittanbietern erforderlich. Ihre Cookie-Einstellungen können Sie hier aufrufen und ändern. Heute kommt das Trivial File Transfer Protocol wesentlich seltener zum Einsatz. In Netzwerken, deren Teilnehmer heutzutage standardmäßig über eigene Betriebssysteme verfügen, ist die Netzwerk-Boot-Methode nur noch vereinzelt und in abgewandelter Form wiederzufinden. So können beispielsweise Systeminstallationen, Wartungen, Firmware-Updates oder Virus-Scans über sogenannte Hilfsbetriebssysteme zu einer Reduzierung des Administrationsaufwands beitragen. Auch in den nicht flüchtigen Festwertspeichern (ROM-Speichern) sind Implementierungen von TFTP nicht ungewöhnlich, da diese dank der Verbindungslosigkeit des Protokolls nur wenig Aufwand bedeuten. Ferner dienen TFTP-Server zur Absicherung von Konfigurationen und System-Images von Cisco-Routern und -Switches sowie zur Ablage von Gebührendatensätzen bei Siemens-Telefonanlagen.