Trivial File Transfer Protocol - Trivial File Transfer Protocol

Trivial File Transfer Protocol ( TFTP ) är en enkel lockstep File Transfer Protocol som tillåter en kund att få en fil från eller sätta en fil på en fjärr värd . En av dess primära användningsområden är i de tidiga stadierna av noder som startas från ett lokalt nätverk . TFTP har använts för den här applikationen eftersom den är mycket enkel att implementera.

TFTP standardiserades först 1981 och den nuvarande specifikationen för protokollet finns i RFC 1350.

Översikt

På grund av sin enkla design kan TFTP enkelt implementeras med kod med ett litet minnesavtryck . Det är därför det valda protokollet för de inledande skedena av alla nätverksstartstrategier som BOOTP , PXE , BSDP , etc., när man riktar in sig från datorer med mycket resurser till mycket låga resurser Single-board-datorer (SBC) och System on a Chip (SoC) ). Det används också för att överföra firmware -bilder och konfigurationsfiler till nätverksapparater som routrar , brandväggar , IP -telefoner etc. Idag är TFTP praktiskt taget oanvänd för internetöverföringar.

TFTP: s design påverkades av det tidigare protokollet EFTP , som var en del av PARC Universal Packet -protokollpaketet . TFTP definierades först 1980 av IEN 133. I juni 1981 publicerades TFTP -protokollet (revision 2) som RFC 783 och uppdaterades senare i juli 1992 av RFC 1350 som bland annat fixade Sorcerer's Apprentice Syndrome . I mars 1995 definierade TFTP Option Extension RFC 1782, uppdaterat senare i maj 1998 av RFC 2347, alternativförhandlingsmekanismen som fastställer ramen för filöverföringsalternativ som ska förhandlas före överföringen med hjälp av en mekanism som överensstämmer med TFTP: s ursprungliga specifikation.

TFTP är ett enkelt protokoll för överföring av filer, implementerat ovanpå UDP/IP- protokollen med hjälp av välkänt portnummer 69. TFTP var utformad för att vara liten och enkel att implementera, och därför saknar den de flesta avancerade funktioner som erbjuds av mer robusta filöverföringsprotokoll. TFTP läser och skriver bara filer från eller till en fjärrserver. Det kan inte lista, ta bort eller byta namn på filer eller kataloger och det har inga bestämmelser för användarautentisering. Idag används TFTP i allmänhet bara på lokala nätverk (LAN).

Detaljer

(W1) Host A begär att skriva

(W2) Server S bekräftar begäran

(W3) Värd A skickar numrerade datapaket

(R1) Värd A begär att läsa

(R2) Server S skickar datapaket 1

(R3) Värd A bekräftar datapaket 1

I TFTP initieras en överföring genom att klienten skickar en begäran om att läsa eller skriva en viss fil på servern. Begäran kan valfritt innehålla en uppsättning förhandlade överföringsparametrar som föreslås av klienten under de villkor som anges av RFC 2347. Om servern beviljar begäran skickas filen i block med fast längd om 512 byte som standard eller det antal som anges i blockstorleken förhandlat alternativ definierat av RFC 2348. Varje block av överförd data, som vanligtvis transporteras inom ett enda IP -paket för att undvika IP -fragmentering, måste bekräftas av ett bekräftelsepaket innan nästa block kan skickas. Ett datapaket på mindre än 512 byte eller de överenskomna blockstorleksoptionssignalerna avslutar en överföring. Om ett paket går vilse i nätverket tar den avsedda mottagaren timeout och kan sända sitt sista paket igen (vilket kan vara data eller en bekräftelse), vilket leder till att avsändaren av det förlorade paketet skickar det förlorade paketet igen. Avsändaren måste bara ha ett paket till hands för vidarebefordran, eftersom bekräftelsen på låssteget garanterar att alla äldre paket har mottagits korrekt. Lägg märke till att båda enheterna som är involverade i en överföring betraktas som avsändare och mottagare. Den ena skickar data och tar emot bekräftelser, den andra skickar bekräftelser och tar emot data.

TFTP definierar tre överföringssätt: netascii, oktett och post.

1. Netascii är en modifierad form av ASCII , definierad i RFC 764. Den består av en 8-bitars förlängning av 7-bitars ASCII-teckenutrymmet från 0x20 till 0x7F (de utskrivbara tecknen och mellanslag) och åtta av kontrolltecknen. De tillåtna kontrolltecknen inkluderar noll (0x00), radmatning (LF, 0x0A) och vagnretur (CR, 0x0D). Netascii kräver också att slutet av radmarkören på en värd översätts till teckenparet CR LF för överföring, och att alla CR måste följas av antingen en LF eller noll.
2. Octet möjliggör överföring av godtyckliga råa 8-bitars byte, med den mottagna filen resulterande byte per byte identisk med den som skickas. Mer korrekt, om en värd tar emot en oktettfil och sedan returnerar den, måste den returnerade filen vara identisk med originalet.
3. E -postöverföringsläge använder Netascii -överföring, men filen skickas till en e -postmottagare genom att ange mottagarens e -postadress som filnamn. RFC 1350 förklarade detta överföringssätt föråldrat.

TFTP använder UDP som sitt transportprotokoll . En överföringsbegäran initieras alltid riktad mot port 69, men dataöverföringsportarna väljs oberoende av avsändaren och mottagaren under initialiseringen av överföringen. Portarna väljs slumpmässigt enligt parametrarna i nätverksstacken, vanligtvis från intervallet av flyktiga portar .

1. Den initierande värden A skickar ett RRQ (läsförfrågan) eller WRQ (skrivförfrågan) -paket till värd S vid portnummer 69, som innehåller filnamnet, överföringsläget och eventuellt alla förhandlade alternativ enligt villkoren i RFC 2347.
2. S svarar med ett alternativ ACK om alternativ användes, och ett ACK -paket (kvittering) till WRQ och direkt med ett DATA -paket till RRQ. Paket skickas från en slumpmässigt tilldelad flyktig port , och alla framtida paket till värd S bör dirigeras till denna port.
3. Källvärden skickar numrerade DATA-paket till destinationsvärden, alla utom de sista som innehåller ett block av full storlek (standard 512 byte). Destinationsvärden svarar med numrerade ACK -paket för alla DATA -paket.
4. Det sista DATA-paketet måste innehålla mindre än ett block av full storlek för att signalera att det är det sista. Om storleken på den överförda filen är en exakt multipel av blockstorleken, skickar källan ett sista DATA-paket som innehåller 0 byte data.
5. Mottagaren svarar på varje DATA med tillhörande numrerad ACK. Avsändaren svarar på den första mottagna ACK för ett block med DATA för nästa block.
6. Om en ACK inte så småningom tas emot skickar en vidaresändningstimer DATA-paket igen.

TFTP har alltid kopplats till nätverksstart. Ett av de första försöken i detta avseende var Bootstrap Loading med TFTP -standard RFC 906, publicerad 1984, som etablerade 1981 publicerade Trivial File Transfer Protocol -standard RFC 783 för att användas som standardfilöverföringsprotokoll för bootstrap -laddning. Den följdes strax efter av Bootstrap Protocol- standarden RFC 951 (BOOTP), publicerad 1985, vilket gjorde det möjligt för en diskfri klientmaskin att upptäcka sin egen IP-adress, adressen till en TFTP-server och namnet på ett Network Bootstrap-program (NBP) som ska överföras till TFTP, laddas in i minnet och köras. Dynamic Host Configuration Protocol standard RFC 2131 (DHCP) som publicerades 1997 förbättrade BOOTP -funktioner. Slutligen släpptes Preboot Execution Environment (PXE) version 2.0 i december 1998 och uppdateringen 2.1 offentliggjordes i september 1999 och räknade med TFTP som dess filöverföringsprotokoll. Intel har nyligen beslutat att i stor utsträckning stödja PXE inom den nya UEFI -specifikationen som utökar TFTP -stödet till alla EFI/UEFI -miljöer.

Det ursprungliga protokollet har en gräns för överföringsfil på 512 byte/block x 65535 block = 32 MB. År 1998 utökades denna gräns till 65535 byte/block x 65535 block = 4 GB med TFTP -blockstorlek RFC 2348. Om den definierade blockstorleken producerar en IP -paketstorlek som överstiger den lägsta MTU vid någon punkt i nätverksvägen, IP -fragmentering och återmontering kommer inte bara att lägga till mer overhead utan också leda till totalt överföringsfel när den minimalistiska IP -stackimplementeringen i en värds BOOTP- eller PXE -ROM inte (eller misslyckas med korrekt) implementerar IP -fragmentering och återmontering. Om TFTP -paket ska hållas inom standard -MTU för Ethernet (1500), beräknas blockstorleksvärdet som 1500 minus rubriker för TFTP (4 byte), UDP (8 byte) och IP (20 byte) = 1468 byte/block, detta ger en gräns på 1468 byte/block x 65535 block = 92 MB. Idag stöder de flesta servrar och klienter blocknummerrullning (blockräknare går tillbaka till 0 eller 1 efter 65535) vilket ger en väsentligen obegränsad överföringsfilstorlek.

Eftersom TFTP använder UDP måste den tillhandahålla sin egen transport- och sessionstöd. Varje fil som överförs via TFTP utgör en oberoende utbyte. Klassiskt utförs denna överföring i låssteg, med endast ett paket (antingen ett block av data eller en "bekräftelse") alternativt i flygning på nätverket när som helst. På grund av denna enda datablockstrategi istället för att skicka en större mängd oavbrutna datablock innan överföringen pausas för att vänta på motsvarande bekräftelse (fönster), ger TFTP låg genomströmning, särskilt över länkar med hög latens . Microsoft introducerade fönstret TFTP i Windows 2008 som en del av deras Windows Deployment Services (WDS), i januari 2015 publicerades TFTP Windowsize Option RFC 7440. Detta förbättrar avsevärt prestanda för saker som PXE -uppstart utan att IP -fragmenteringens bieffekt ibland observeras på Blocksize Option RFC 2348

Säkerhetshänsyn

TFTP innehåller inga inloggnings- eller åtkomstkontrollmekanismer. Var försiktig när du använder TFTP för filöverföringar där autentisering, åtkomstkontroll, konfidentialitet eller integritetskontroll behövs. Observera att dessa säkerhetstjänster kan levereras ovanför eller under det lager där TFTP körs. Man måste också vara försiktig med de rättigheter som tilldelas en TFTP -serverprocess för att inte kränka säkerheten för serverns filsystem. TFTP installeras ofta med kontroller så att endast filer som har offentlig läsåtkomst är tillgängliga via TFTP. Att lista, radera, byta namn och skriva filer via TFTP är vanligtvis inte tillåtet. TFTP -filöverföringar rekommenderas inte där de inneboende protokollbegränsningarna kan ge upphov till oöverstigliga ansvarsproblem.

IETF -standarddokumentation

Se även

• Enkelt filöverföringsprotokoll
• Exekveringsmiljö före start

Referenser