Trivial File Transfer Protocol (TFTP) ist ein für seine Einfachheit bemerkenswertes Dateiübertragungsprotokoll. Es wird allgemein für die automatisierte Übertragung der Konfiguration oder Stiefeldateien zwischen Maschinen in einer lokalen Umgebung verwendet. Im Vergleich zu FTP wird TFTP äußerst beschränkt, keine Beglaubigung zur Verfügung stellend, und wird interaktiv von einem Benutzer selten verwendet.

Wegen seines einfachen Designs konnte TFTP mit einem sehr kleinen Betrag des Gedächtnisses durchgeführt werden.

Es ist deshalb nützlich, um Computer wie Router zu starten, die keine Datenspeichergeräte haben können. Es ist ein Element der Vorstiefelausführungsumgebung (PXE) Netzstiefelprotokoll,

wo es im firmware ROM / NVRAM der Netzkarte des Gastgebers durchgeführt wird.

Es wird auch verwendet, um kleine Datenmengen zwischen Gastgebern in einem Netz, wie IP-Telefonfirmware oder Betriebssystemimages zu übertragen, wenn ein entfernter X Fenstersystemterminal oder jeder andere dünne Kunde von einem Netzgastgeber oder Server startet. Die anfänglichen Stufen von einem Netz haben Installationssysteme gestützt (wie Solaris-Starthilfe, Roter Hut lassen An, Symantec Geist und Remote Installation Services von Windows NT) verwenden TFTP, um einen grundlegenden Kern zu laden, der die wirkliche Installation durchführt.

TFTP wurde zuerst 1980 durch IEN 133 definiert.

Es wird zurzeit vor RFC 1350 definiert. Es hat einige Erweiterungen auf das TFTP Protokoll gegeben, das in später dokumentiert ist

RFC'S (sieh die Abteilung auf Erweiterungen, unten). TFTP basiert teilweise auf dem früheren Protokoll EFTP, der ein Teil des Protokoll-Gefolges des JUNGEN HUNDS war. TFTP Unterstützung ist erst als ein Teil von 4.3 BSD geschienen.

Wegen des Mangels an der Sicherheit ist es gefährlich, es über das Internet zu verwenden. So wird TFTP allgemein nur in privaten, lokalen Netzen verwendet.

Übersicht

Trivial File Transfer Protocol (TFTP) ist ein einfaches Protokoll, um Dateien zu übertragen. Es ist oben auf User Datagram Protocol (UDP) mit dem Hafen Nummer 69 durchgeführt worden. TFTP wird entworfen, um klein und leicht zu sein, durchzuführen, und deshalb hat er an den meisten Eigenschaften eines regelmäßigen FTP Mangel. TFTP liest nur und schreibt Dateien (oder Post) von\zu einem entfernten Server. Es kann Verzeichnisse nicht verzeichnen, und hat zurzeit keine Bestimmungen für die Benutzerbeglaubigung.

In TFTP beginnt jede Übertragung mit einer Bitte, eine Datei zu lesen oder zu schreiben, die auch dient, um um eine Verbindung zu bitten. Wenn der Server die Bitte gewährt, wird die Verbindung geöffnet, und die Datei wird in festen Länge-Blöcken von 512 Bytes gesandt. Jedes Datenpaket enthält einen Datenblock, und muss durch ein Anerkennungspaket anerkannt werden, bevor das folgende Paket gesandt werden kann. Ein Datenpaket der weniger als 512 Bytes Signalbeendigung einer Übertragung. Wenn ein Paket im Netz verloren wird, wird der beabsichtigte Empfänger Pause und kann sein letztes Paket wiederübersenden (der Daten oder eine Anerkennung sein kann), so den Absender des verlorenen Pakets veranlassend, dieses verlorene Paket wiederzuübersenden. Der Absender muss gerade ein Paket verfügbar für die Weitermeldung behalten, da die Schloss-Schritt-Anerkennung versichert, dass alle älteren Pakete erhalten worden sind. Bemerken Sie, dass sowohl an einer Übertragung beteiligte Maschinen als Absender als auch Empfänger betrachtet werden. Man sendet Daten und erhält Anerkennungen, der andere sendet Anerkennungen und erhält Daten.

TFTP verwendet normalerweise UDP als sein Transportprotokoll, aber es ist nicht eine Voraussetzung. Datenübertragung wird auf dem Hafen 69 begonnen, aber die Daten wechseln über Häfen werden unabhängig vom Absender und Empfänger während der Initialisierung der Verbindung gewählt. Die Häfen werden aufs Geratewohl gemäß den Rahmen des gewählt

der Netzwerkanschluss des Stapels, normalerweise von der Reihe von Ephemeren Häfen.

TFTP definiert drei Weisen der Übertragung: netascii, Oktett und Post. Netascii ist eine modifizierte Form von ASCII, der in RFC 764 definiert ist. Es besteht aus einer 8-Bit-Erweiterung des ASCII 7-Bit-Typenabstands von 0x20 bis 0x7F (die druckfähigen Charaktere und der Raum) und acht der Kontrollcharaktere. Die erlaubten Kontrollcharaktere schließen die Null (0x00), das Linienfutter (LF, 0x0A), und die Wagen-Rückkehr (CR, 0x0D) ein. Netascii verlangt auch, dass das Ende des Linienanschreibers auf einem Gastgeber übersetzt wird

dem Charakter-Paar CR LF für die Übertragung, und dass jedem CR entweder von einem LF oder von der Null gefolgt werden muss.

Oktett berücksichtigt die Übertragung von willkürlichen 8-Bit-Bytes mit der erhaltenen zur gesandten Datei identischen Datei. Richtiger, wenn ein Gastgeber eine Oktett-Datei erhält und sie dann zurückgibt, muss die zurückgegebene Datei zum Original identisch sein. Die Postübertragungsweise verwendet Übertragung von Netascii, aber die Datei wird einem E-Mail-Empfänger durch das Spezifizieren dass die E-Mail-Adresse des Empfängers als der Dateiname gesandt. RFC 1350 hat diese Weise der veralteten Übertragung erklärt.

Keine Sicherheit oder Beglaubigung werden durch die Protokoll-Spezifizierung zur Verfügung gestellt. Durchführungen von Unix schränken häufig Dateiübertragungen auf ein einzelnes konfiguriertes Verzeichnis ein, und nur von Dateien mit der Weltlesbarkeit zu lesen, und nur bereits vorhandenen Dateien zu schreiben, die Welt writeability haben.

Protokoll walkthrough

1. Der Einleiten-Gastgeber A sendet einen RRQ (gelesene Bitte), oder WRQ (schreiben Sie Bitte) das Paket dem Gastgeber S am wohl bekannten Hafen Nummer 69, den Dateinamen und die Übertragungsweise enthaltend.
2. S antwortet mit einem ACK (Anerkennung) Paket zu WRQ und direkt mit einem DATEN-Paket zu RRQ. Paket wird von einem frisch zugeteilten ephemeren Hafen gesandt, und alle zukünftigen Pakete dem Gastgeber S sollten zu diesem Hafen sein.
3. Der Quellgastgeber sendet numerierte DATEN-Pakete dem Bestimmungsort-Gastgeber, allen außer dem letzten, das einen lebensgroßen Datenblock (512 Bytes) enthält. Der Bestimmungsort-Gastgeber antwortet mit numerierten ACK Paketen für alle DATEN-Pakete.
4. Das End-DATEN-Paket muss weniger als ein lebensgroßer Datenblock enthalten, um Zeichen zu geben, dass es das letzte ist. Wenn die Größe der übertragenen Datei ein genaues Vielfache der Block-Größe ist, sendet die Quelle ein End-DATEN-Paket, das 0 Bytes von Daten enthält.
5. Empfänger antwortet jedem, welche DATEN mit dem verbundenen ACK numeriert haben. Absender antwortet auf den ersten erhaltenen ACK eines Blocks mit DATEN des folgenden Blocks.
6. Wenn ein ACK nicht schließlich erhalten wird, sendet ein wiederübersenden Zeitmesser DATEN-Paket wieder.

Zusätzliche Details

• Die ursprünglichen Versionen von TFTP, vor RFC 1350, haben einen besonders schlechten Protokoll-Fehler gezeigt, der das Lehrling-Syndrom des Zauberers genannt wurde (nach "dem Lehrling des Zauberers" Segment der Fantasie), als es entdeckt wurde.
• In den frühen Tagen der Arbeit am TCP/IP Protokoll-Gefolge war TFTP häufig das erste auf einem neuen Gastgeber-Typ durchgeführte Protokoll, weil es so einfach war.

Erweiterungen

• Das ursprüngliche Protokoll hat eine Dateigröße-Grenze von 32 Mb. 1998 wurde diese Grenze zu 4 GB durch RFC 2347 erweitert, der Auswahl-Verhandlung und RFC 2348 eingeführt hat, der Verhandlung der Block-Größe eingeführt hat. Wenn der Server und Kundenunterstützungsblocknummer-Bildumlauf, Dateigröße im Wesentlichen unbegrenzt ist.
• Da TFTP UDP verwertet, muss er seinen eigenen Transport und Sitzungsunterstützung liefern. Jede über TFTP übertragene Datei setzt einen unabhängigen Austausch ein. Klassisch wird diese Übertragung im Schloss-Schritt, mit nur einem Paket (entweder ein Datenblock oder eine 'Anerkennung') jemals im Flug im Netz jederzeit durchgeführt. Wegen dieses Mangels an der Fenstertechnik stellt TFTP niedrigen Durchfluss über hohe Latenz-Verbindungen zur Verfügung. Bemerken Sie, dass Windows 2008 pipelined TFTP als ein Teil von Windows Deployment Services (WDS) eingeführt hat und ein 8 Paket-Fenster standardmäßig verwendet. Das verbessert drastisch Leistung für Dinge wie das PXE-Starten.

Bekannte TFTP Durchführungen

GNU inetutils: Das GNU-Projektnetzgefolge schließt eine TFTP Durchführung des Kunden/Servers ein

tftp-hpa: Ein opensource TFTP Gastgeber laut der BSD-Lizenz veröffentlicht.

atftp: eine GPL Durchführung des Kunden/Servers des TFTP Protokolls für Linux

: ein GPL, mehreingefädelter TFTP Server für Linux

TFTP Server: ein freier beweglicher TFTP Server für das Apfel-iPhone und iPad

TFTP Server: TFTP Server für OS X

Tftpd32: ein opensource (EUPL) IPv6 bereiter TFTP und DHCP Server/Dienst für Windows

haneWIN DHCP: ein shareware TFTP und DHCP Server/Dienst für Windows

Siehe auch

• SSH Datei überträgt Protokoll
• Dateiübertragungsprotokoll
• Einfaches Dateiübertragungsprotokoll
• Liste von TCP und UDP Hafen-Zahlen

Weiterführende Literatur

• RFC 906 - das Stiefelstrippe-Laden mit TFTP, R. Finlayson, Juni 1984.
• RFC 1350 - TFTP Protokoll (Revision 2), K. R. Sollins, Juli 1992. (Das hat das Vorangehen, RFC 783 und früher FTP RFCs zurück zum ursprünglichen IEN 133 ersetzt)
• RFC 1785 - TFTP Auswahl-Verhandlungsanalyse, G. Malkin, A. Harkin, März 1995.
• RFC 2090 - TFTP Mehrwurf-Auswahl, A. Emberson, Februar 1997. (Status: Experimentell)
• RFC 2347 - TFTP Auswahl-Erweiterung, G. Malkin, A. Harkin, Mai 1998. (Das hat das Vorangehen, RFC 1782 ersetzt)
• RFC 2348 - TFTP Blocksize Auswahl, G. Malkin, A. Harkin, Mai 1998. (Das hat das Vorangehen, RFC 1783 ersetzt)
• RFC 2349 - TFTP Pause-Zwischenraum und Übertragungsgröße-Optionen, G. Malkin, A. Harkin, Mai 1998 (Hat das das Vorangehen, RFC 1784 ersetzt).
• RFC 3617 - Schema von Uniform Resource Identifier (URI) und Anwendbarkeitserklärung für Trivial File Transfer Protocol (TFTP), E. Lear, Oktober 2003.