Tftp protocol de transfer de date simplu
Capitolul 15 TFTP: un simplu protocol de transfer de date
TFTP - un simplu protocol de transfer de fișiere. El a folosit, de obicei, pentru sistemele diskless (stații de lucru sau terminale X). Spre deosebire de File Transfer Protocol (FTP - File Transfer Protocol), pe care le descrie in capitolul 27, și care utilizează TCP, TFTP utilizează UDP. Acest lucru se face pentru a se asigura că protocolul a fost la fel de simplu și mai scurt posibil. Implementările TFTP (și de dorit UDP, IP, și un driver de dispozitiv) poate încăpea în memoria permanentă (ROM).
Schimbul între client și server începe cu clientul interogări server sau pentru a citi sau scrie fișierul clientului. Sistemul standard de încărcare diskless prima cerere - o cerere de citire (RRQ). Figura 15.1 prezintă formatul mesajelor cinci TFTP. (Codurile operațiunilor 1 și 2 au același format.)
Primii 2 octeți ai mesajului TFTP este codul de operare (opcode). Cererea de citire (RRQ) și cererea de scriere (WRQ) numele fișierului (numele fișierului) specifică fișierul pe server pe care clientul dorește sau își asumă nici o înregistrare. Am arătat în mod specific în figura 15.1, care este numele fișierului se termină cu un octet nul. Mod (modul) este un șir de caractere ASCII: netascii sau octetul (orice combinație de litere mari sau mici), care se termină de asemenea, în octet 0. netascii înseamnă că datele sunt linii de text ASCII, fiecare linie se termină cu un 2 caractere retur de car secvență, urmat de linie de trecere (notată - CR / LF).
Figura 15.1 Formatul cinci mesaje TFTP.
Atât client și server trebuie să fie capabil să efectueze conversia în format între acestea, precum și orice alte (un alt Delimitator siruri de caractere), care este utilizat pe gazda locală. Transferul octetul indică faptul că datele vor fi transmise sub formă de octeți de 8-biți fără interpretare.
În cazul unei cereri de scriere (WRQ) clientul trimite WRQ, indicând numele fișierului și modul. Dacă fișierul poate fi scris de către client, serverul răspunde cu o confirmare (ACK), cu un număr de bloc 0. Clientul trimite primele 512 octeți de numărul blocului de fișier egal cu 1, serverul răspunde cu un număr de bloc ACK egal cu 1.
Acest tip de protocol de transfer de date numit de stop-and-wait (stop-and-wait). Este folosit numai în protocoale simple precum TFTP. Vom vedea în „Resize“ în capitolul 20 că TCP furnizează alte forme de probă, care vă permite să obțineți rezultate superioare. TFTP este conceput în așa fel încât punerea în aplicare a fost la fel de ușor ca posibil, și nu pentru a crește capacitatea.
Ultimul tip de mesaje TFTP, acest mesaj de eroare, codul de operare (Opcode) este egal cu 5. Aceasta este exact ceea ce serverul răspunde în cazul în care o citire sau scriere cerere nu poate fi procesată. citi sau scrie erori în timpul transferului de fișiere și duce la ceea ce este trimis un mesaj de eroare, iar transferul este terminată. Numărul de eroare (număr de eroare) include un cod de eroare digitale, urmat de mesajul de eroare în format ASCII, care pot conține informații suplimentare furnizate de sistemul de operare.
Să vedem cum funcționează protocolul TFTP. Vom lansa clientul TFTP pe BSDI gazdă și de a obține un fișier text cu SVr4 gazdă:
BSDI% tftp SVr4 începe TFTP client
tftp> obține test1.c obține fișierul de pe server
A primit 962 octeți în 0,3 secunde
tftp> quit compus lacrima
BSDI% ls -l test1.c cati bytes a fișierului?
-rw-r - r-- personalului 1 rstevens 914 20 martie 11:41 test1.c
BSDI% wc -l test1.c și cât de multe rânduri?
48 test1.c
Primul lucru care atrage atenția este faptul că fișierul pe Unix conține 914 octeți, dar TFTP trimite 962 octeți. Utilizarea WC de program, vom vedea că fișierul de 48 de linii, astfel încât 48 de noi personaje rând din Unix au fost suplimentate cu până la 48 de perechi de CR / LF, deoarece TFTP implicit transmite modul netascii.
Cifra 15.2 arată schimbul de pachete.
1 0.0 bsdi.1106> svr4.tftp: 19 RRQ "test1.c"
2 0.287080 (0.2871) svr4.1077> bsdi.1106: udp 516
3 0.291178 (0.0041) bsdi.1106> svr4.1077: udp 4
4 0.299446 (0,0083) svr4.1077> bsdi.1106: udp 454
5 0.312320 (0,0129) bsdi.1106> svr4.1077: udp 4
Figura 15.2 Pinging dacă TFTP.
Linia 1 prezintă o cerere de citire de la client la server. UDP portul de destinație pentru TFTP - bine-cunoscutul port-69, tcpdump arată pachetele TFTP și imprimă RRQ și numele de fișier. Lungimea datelor UDP imprimate ca 19 octeți și se obține după cum urmează: 2 octeți - opcode, 7 octeți - numele fișierului de un octet de la 0 până la netascii 8 octeți și 1 octet este egal cu 0.
Pachetul următor vine de la server (linia 2) și conține 516 octeți: 2 octeți - opcode, 2 octeți - numărul de unități, și 512 octeți de date. Linia 3 - confirmarea acestei date: 2 octeți - octet opcode și 2 - numărul de bloc.
Și ultimul pachet de date (linia 4) conține 450 octeți de date. 512 octeți de date în rândul 2 și acestea cuprind 450 octeți 962 octeți de date recepționate de către client.
Rețineți că tcpdump nu imprimă mai multe informații despre protocolul TFTP pentru liniile de 2 - 5, cum a făcut-o, interpreta mesajul TFTP pe linia 1. Acest lucru se datorează faptului că numărul portului serverului este schimbat între liniile 1 și 2. protocolul TFTP impune ca clientul a trimis primul pachet (The RRQ sau WRQ) pentru a avansa un bine-cunoscut server port UDP (69). Serverul gaseste orice port efemer nefolosit (1077 în figura 15.2), care este apoi utilizat de către server pentru nou schimb de pachete între client și server. numărul de port client (1106 în acest exemplu) nu se schimba. tcpdump nu are nici o idee că portul 1077 pe SVr4 gazdă utilizat serverul TFTP.
Motivul pentru modificarea numărul portului de server, este faptul că serverul nu trebuie să abordeze portul bine-cunoscut pe o cantitate mare de timp necesar pentru a transfera fișierul (care poate dura de la câteva secunde la câteva minute). În schimb, un port bine-cunoscut rămâne disponibil pentru un alt client TFTP, care poate trimite în cererea dumneavoastră. În timp ce în acest moment transferul se realizează printr-un alt port.
Cu referire la Figura 10.6. server de RIP pe care clientul ar trebui să trimită mai mult de 512 octeți, trimite ambele datagrame UDP cu un port de server cunoscut. În cazul TFTP (din cauza diferențelor de protocol), interacțiunea dintre client și server nu se realizează (care, așa cum am spus, poate dura de la câteva secunde până la minute) de durată. În cazul în care un server de proces va folosi portul bine-cunoscut tot timpul pentru a transfera fișiere, este necesar de a refuza toate cererile ulterioare care vor veni de la alți clienți, sau un server de proces trebuie să fie capabil de a efectua mai multe transferuri de fișiere către mai mulți clienți în același timp cu același port (69). Cea mai simplă soluție este ca switch-uri de server la un alt port după primirea RRQ sau WRQ. Clientul specifică un nou port când primește un prim pachet de date (linia 2 din figura 15.2), și apoi trimite toate confirmarea ulterioară (liniile 3 și 5) pe noul port.
În „Exemplul“ în capitolul 16, vom vedea cum să folosească TFTP atunci când pornirea terminale X.
Rețineți că pachetele TFTP (Figura 15.1) nu conțin date cu privire la numele de utilizator sau parola. Această încălcare în caracteristică secretul TFTP. Deoarece TFTP a fost proiectat pentru a fi utilizat în procesul de boot, aceasta nu oferă un nume de utilizator și o parolă.
Această caracteristică a TFTP a fost folosit de mulți hackeri pentru a obține copii ale fișierului parolei Unix, și apoi decripta parolele. Pentru a preveni un astfel de acces, de cele mai multe servere TFTP guvernează în prezent fișierele care pot fi preparate folosind TFTP (de obicei, fișierele din directorul / tftpboot în sistemele Unix). Acest director conține fișiere numai ghetei sistemele necesare fără disc.
Pentru un plus de securitate, un server TFTP pe un sistem Unix, stabilește, de obicei, ID-ul de utilizator (UID) și ID-ul grupului (GID), în valoarea care nu poate fi atribuită unui utilizator real. Acest lucru permite accesul numai la fișierele care sunt disponibile pentru citire și scriere tuturor.
TFTP - un protocol simplu proiectat astfel încât să se potrivească în ROM și să fie utilizate numai în procesul de sisteme fără disc. Acesta utilizează o cantitate mică de formate de mesaje și protocol cu un stop-and-wait.
Pentru a permite mai multor clienți să fie încărcate în același timp, serverul TFTP oferă mai multe forme de funcționare simultană. Din moment ce UDP nu oferă o conexiune unică între client și server (așa cum face TCP), serverul TFTP creează un nou port UDP pentru fiecare client. Acesta permite clienților să emită o datagrama pentru a fi demultiplexat modul de server UDP, în funcție de numerele de porturi de destinație, în loc de a face aceasta serverul în sine.
Protocolul TFTP nu oferă securitate. Cele mai multe implementari permite accesul prin TFTP numai la fișierele care sunt necesare atunci când descărcarea.
În capitolul 27, ne vom uita la protocolul de transfer de fișiere (FTP - File Transfer Protocol), care este proiectat pentru uz general, și oferă, de asemenea debit mare pentru transferul de fișiere.