v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 8: TELNET, FTP a NFS Jií Peterka, 2005
v. 2.2 Pipomenutí: aplikace v jsou vesms postaveny na architektue klient/server souástí aplikaní vrstvy jsou takovéásti aplikací, které jsou nutné pro interoperabilitu a "základní fungování" konkrétní služby obdobn jako v RM ISO/OSI nap. transport zpráv a soubor uživatelské rozhraní již není souástí aplikaní vrstvy není svázáno standardy trend k "platformizaci" pvodn samostatné služby se stávají nadstavbou nad WWW historický vývoj: zpoátku se používaly pedevším tyto aplikace: TELNET penos soubor (FTP) el. pošta (SMTP, FRC 822) pozdji také: sdílení soubor (NFS) Gopher. dnes pevládá (krom pošty): WWW (jako samostatná aplikace i jako platforma pro provozování dalších aplikací, nap. vyhledávacích služeb, adresá, ) 2
v. 2.2 Vzdálené pihlašování (remote login) cílem je možnost "používat aplikace na dálku" uživatel je na místním poítai, ale aplikace bží na vzdáleném poítai týká se aplikací fungujících na bázi výpoetního modelu "host/terminál" typicky: starších aplikací fungujících ve znakovém režimu aplikací které ani nemusí poítat s tím že fungují v prostedí sít podmínka: aplikace musí podporovat tzv. terminálové relace musí své výstupy posílat "skrz OS" na terminál a své vstupy pijímat "skrz OS" z terminálu takto se dje nap. v prostedí UNIXu nesmí "jít napevno" do videoram a klávesnicového bufferu jako v MS DOS také operaní systém musí podporovat terminálové relace 3
v. 2.2 Pedstava výpoetního modelu host/terminál aplikace aplikace terminál operaní systém procesor pam soubory programy vstupy výstupy terminál hostitelský poíta 4
v. 2.2 Pedstava terminálové relace aplikace hostitelský poíta poítaová sí hostitelský poíta (lokální) (lokální) terminálová terminálová relace vzdálená vzdálená terminálová terminálová relace relace relace A B T A1 T A2 T A3 T B1 T B2 T B3 terminál terminál terminál terminál terminál terminál 5
v. 2.2 Vzdálené pihlašování v TELNET hlavní prostedek pro realizaci vzdáleného pihlašování v rámci, snaží se být maximáln univerzální snaží se nevázat na konkrétní systémové prostedí (nebýt závislý na operaním systému) podporuje terminálové relace mezi rznými platformami na stran uživatele poítá i s terminálovou emulací... nabízí jen jednoduché služby, a nikoli nap. možnost automatického pihlašování apod. podporuje pouze znakové uživatelské rozhraní rlogin vzniknul v prostedí BSD Unixu je vázán na prostedí Unixu (BSD Unixu), a podporuje tzv. trusted hosts dokáže si nkteré informace vytáhnout ze svého okolí (nap. jméno uživatele a jeho heslo)...... a pak je využít, nap. pro automatické pihlášení uživatele na vzdáleném poítai ICA (WinFrame, MS Terminal Server) novéešení, podporuje grafiku ásten také: systém X Window 6
v. 2.2 Terminálová emulace vs. TELNET aplikace TELNET server IP sí emulátor terminálu (lokální) terminálová relace A protokol TELNET TELNET klient hostitelský poíta vzdálená vzdálená terminálová terminálová relace T A1 T A2 T relace A3 T 1 T B3 terminál terminál terminál poíta, emulující jednoúelový terminál 7
v. 2.2 TELNET - principy TELNET server je realizován na aplikaní úrovni jako systémová úloha - démon, a nikoli uvnit OS výhoda: snazší modifikace nevýhoda: ne každý OS tomu vychází vstíc nevýhoda: je to mén efektivní než pímé zabudování do OS TELNET klient TELNET server aplikace Operaní systém Operaní systém IP sí používá se se TCP 8
v. 2.2 TELNET základní problém každý terminál je jiný liší se: v rozsahu schopností v parametrech v režimu fungování znakový celoobrazovkový formuláový s odlišnostmi terminál se lze vyrovnat pizpsobením stylem každý s každým... nebo pes spolený mezistupe, s pizpsobením typu každý s jedním a jeden s každým v pípad TELNETu jde hlavn o tvar, v jakém se mají data penášet sítí TELNET zavádí jeden, pevn daný mezistupe: virtuální terminál NVT (Network Virtual Terminal) NVT má vždy stejné vlastnosti reálné terminály se mu pizpsobují (jsou mapovány z/do NVT) NVT pedevším definuje formát skuten penášených dat 9
v. 2.2 TELNET - pedstava platforma 1 platforma 2 TELNET klient TELNET server aplikace zde zde je je používán používán specifický specifický formát formát platformy, platformy, na na které které "stojí" "stojí" klient klient zde jsou data penášena ve formátu NVT zde zde je je používán používán specifický specifický formát formát platformy, platformy, na na které které "stojí" "stojí" klient klient 10
v. 2.2 Vlastnosti NVT NVT je spoleným jmenovatelem...... povinným minimem, které musí umt všechny reálné terminály NVT odpovídá jednoduchému ádkovému terminálu TELNET obsahuje mechanismy, pomocí kterých se klient se serverem mohou dohodnout na lepším jde o tzv. options NVT odpovídá jednoduchému znakovému terminálu, tj.: data jsou lenna na ádky data jsou penášena po znacích komunikuje se pouze poloduplexn používá se lokální echo pvodní pedstava: NVT odpovídá klávesnici a tiskárn 11
v. 2.2 Vlastnosti NVT pro penos využívá spolehlivé penosové služby TCP (ale jen poloduplexním zpsobem) penos je znakov orientovaný a vždy 8-bitový (tj. jednotlivé znaky se penáší vždy v 8 bitových bytech)... ale standardn se pedpokládá penos 7-bitových ASCII znak je povinnost zobrazovat 95 tisknutelných ASCII znak (s kódy 32 až 127)... a povinnost interpretovat znaky NULL, CR a LF dále je pesn definován význam znak BEL, BS, HT, VT, FF (ale jejich interpretace není povinná) ostatní znaky nemají mít žádný efekt požaduje se, aby klávesnice byla schopna generovat všech 128 ASCII znak znak, kterým je zakonena ádka (resp. znaky), musí TELNET klient nahradit dvojicí znak CR a LF klient server naopak nahradí CR a LF takovým znakem (znaky), které na jeho stran pedstavují zakoneníádky penos 8-bitových znak je jedním z volitelných režim (options) 12
v. 2.2 TELNET -ídící píkazy NVT poítá i s implementací ídících mechanism nap. pro perušení práv probíhajícího programu, pomocí CTRL+C)...a k tomu potebuje penášet ídící píkazy, povely atd. ídící píkazy mají zásadn znakovou povahu (tvoí je ídící znaky) pro zajištní transparence se používá prefixace (uvození) speciálním znakem IAC (Interpret As Command), s kódem 255 pípadný výskyt znaku IAC v datech se eší jeho zdvojením. ídící píkazy jsou trojího druhu: editaní píkazy: umožují mazat znak a ádku ídící píkazy: umožují perušit probíhající proces, zastavit jeho výstup... dohadovací píkazy: umožují obma stranám dohodnout se na pípadných rozšíeních oproti NVT 13
v. 2.2 TELNET - rozšíení umožují obma stranám dohodnout se na jiném, než co vyplývá z pevn daných vlastností NVT, nap.: zda budou komunikovat v plném duplexu, že penášená data budou odesílána po ádcích s možností jejich lokální editace že budou používat vzdálené echo jakou velikost displeje budou používat jaký zpsob ízení toku budou používat zásada: použití rozšíení je dobrovolné kterákoli strana má právo navrhnout použití konkrétního rozšíení (tj. jak klient, tak i server) druhá strana má právo použití rozšíení odmítnout k dohadování slouží samostatné píkazy: WILL ("já chci používat rozšíení.") odpov: DO vs. DON'T DO ("chci abys ty používal rozšíení.") odpov: WILL vs. WON'T 14
v. 2.2 TELNET - rozšíení pesná specifikace jednotlivých rozšíení (íselný kód, sémantika) není apriorn uzavena (omezena) nová rozšíení mohou vznikat postupn (a být definována prostednictvím dokument RFC) existuje dokonce i mechanismus pro rozšiování rozšíení další píklad rozšíení: výmna informací o konkrétním typu terminálu umožuje aplikacím lépe pizpsobit svj výstup možnostem terminálu (nap. pímým nastavováním kurzoru na zadanou pozici apod.) pro jednotlivá rozšíení mže dojít k podrobnjším licitacím TELNET jejich prbh nespecifikuje... je definován až samotným rozšíením (a mže tedy být pro nj specifický) TELNET definuje pouze zpsob zajištní transparence dat pi další licitaci 15
v. 2.2 Vzdálené pihlašování vs. práce se soubory cíl: chci pracovat se souborem, který se nachází na jiném poítai pesnji: chci zpracovávat obsah vzdáleného souboru, pomocí aplikace, která bží na mém uzlu!!!... úelem není dostat se do role vzdáleného terminálu jiného uzlu!!! pak by byl soubor zpracováván aplikací bžící na vzdáleném poítai 16
v. 2.2 Penos vs. sdílení soubor penos soubor: jde o netransparentníešení uživatel/aplikace si uvdomuje, že soubor se nachází na vzdáleném poítai uživatel/aplikace musí explicitn znát umístní souboru na vzdáleném poítai uživatel/aplikace musí explicitn podnikat urité kroky ke zpístupnní souboru typicky: vzdálený soubor se celý penese na "místní" poíta a zde se zpracuje oznauje se jako "file transfer" v rámci eší protokol FTP (File Transfer Protocol) sdílení soubor: jde o transparentníešení uživatel/aplikace si neuvdomuje, že soubor se nachází na vzdáleném poítai uživatel/aplikace nemusí explicitn znát umístní souboru na vzdáleném poítai uživatel/aplikace nemusí podnikat žádné explicitní kroky ke zpístupnní souboru typicky: vzdálený soubor se "chová" ("tváí") jako místní soubor, a také se s ním jako s místním pracuje oznauje se jako "file sharing" v rámci eší protokol NFS (Network File System) 17
v. 2.2 Problémy penosu a sdílení soubor protokoly pro penos a sdílení se musí vyrovnat s mnoha úskalími, typu: rozdílnost v pohledu na soubory, jejich jména, pípony... vlastnictví soubor, jejich atributy... problém je i se zajištním vícenásobného pístupu k souborm lze použít obecné techniky typu: uzamykání celých soubori jejich ástí replikace ponechat vše na uživateli... ešení je snazší u netransparentního pístupu (file transfer) kde lze požadovat po uživateli, aby rozdílnosti vyešil vlastním rozhodnutím napíklad aby zadal atributy místního souboru, do kterého má být penesen (zkopírován) obsah vzdáleného souboru 18
v. 2.2 Protokol FTP (File Transfer Protocol) je starší než rodina protokol pochází již z roku 1971 (vznikl nad protokolem NCP) teprve pozdji portován nad penosové protokoly... pesnji nad protokol TCP protokol FTP vzniknul v dob, kdy se operaní systémy a platformy lišily více než dnes mj. ve velikosti slov, znázornní znak, nap.: nkdo umisoval tyi 9-bitové znaky do jednoho 36-bitového slova jiný OS umístil do 36-bitového slova pt 7- bitových znak... musí musíse se mu mu íci, íci, co co bude bude penášet (zvolit jeden z režim) dnes ale vtšina tchto "dávných" vlastností není podporována protože mezitím došlo ke znanému sjednocení jediný významnjší pozstatek: snaha konvertovat text pi jeho penosu mezi rznými platformami napíklad kódování, konce ádek, FTP pracuje ve dvou režimech: textovém provádí konverze implicitn binárním konverze neprovádí 19
v. 2.2 FTP textové penosy FTP zavádí jednotný formát dat pro poteby penosu veškeré konverze z/do tohoto formátu ponechává na koncových uzlech umožuje ale obma stranám dohodnout se v konkrétním pípad na jiném formátu (kvli vtší efektivnosti penosu) FTP penáší data zásadn jako 8-bitové byty pro text používá FTP stejný formát, jako protokol TELNET: jednotlivé znaky penášeny v 8 bitech konec ádky = CR+LF kódování ASCII alternativní možností je použití kódu EBCDIC, použití nestandardní velikosti bytu atd. 20
v. 2.2 FTP pedstava a penos soubor dnes se již nepoužívá FTP implicitn chápe soubor jako dále nestrukturovaný (bez vnitní struktury) - oznaováno jako file structure alternativn je schopen se na nj dívat jako na posloupnost stejn velkých záznam (records) - record structure nebo jako na množinu stránek (které mohou tvoit nespojitý soubor) - page structure implicitn je obsah souboru penášen jako spojitý proud dat (tzv. stream mode) alternativou je blokový režim (block mode), pi kterém je možné vkládat mezi bloky zarážky, a po ev. výpadku spojení se k nim vracet další alternativou je zhuštný režim (compressed mode), kdy je používána jednoduchá metoda komprese (eliminující opakující se znaky) 21
v. 2.2 FTP - implementace vychází z modelu klient/server klient je typicky aplikaním programem server obvykle systémovým procesem (démonem, rezidentním programem apod.) návrh protokolu je uzpsoben možnosti úsporné implementace (takové, která si nárokuje vtšinu systémových zdroj až v okamžiku jejich skutené poteby) zajištní potebných funkcí v rámci FTP je rozdleno mezi dva subjekty: interpret protokolu (PI, Protocol Interpreter) penosový proces (DTP, Data Transfer Process) interpret protokolu existuje trvale, penosový proces vzniká až na základ konkrétního požadavku používají se dv rzná spojení: ídící (pro penos píkaz) datové (pro penos soubor) 22
v. 2.2 Implementace protokolu FTP požadavek na penos penos souboru klient uživatelské rozhraní interpret protokolu ídící spojení interpret protokolu systém soubor penosový proces datové spojení penosový proces systém soubor využívají se transportní služby protokolu TCP 23
v. 2.2 Datové a ídící spojení oddlení datového a ídícího spojení je výhodné: kvli zajištní transparence kvli možnosti perušit probíhající penos kvli možnosti signalizovat konec souboru uzavení datového spojení signalizuje konec souboru lze penášet soubory které bhem penosu narstají definice FTP (RFC) požaduje aby datové spojení bylo 1 pro všechny penášené soubory v praxi se pro každý penášený soubor používá 1 (samostatné, nové) datové spojení ídící spojení "pežívá" po celou dobu relace, datová spojení se mní ídící spojení iniciuje (navazuje) klient ze svého (dynamicky pidleného) portu na port 21 ruší se až explicitním píkazem datové spojení iniciuje (navazuje) server ze svého portu 20 na port klienta, ze kterého bylo navázáno ídící spojení passive-mode: datové spojení nenavazuje server, ale klient kvli firewallm, které neakceptují žádosti o otevení spojení vedoucí dovnit na "náhodný" port 24
v. 2.2 Uživatelé a FTP FTP je user aware - uvdomuje si existenci uživatel server pi pístupu k místním souborm vždy vystupuje jménem konkrétního uživatele FTP potebuje mechanismy pro pihlášení uživatele a jeho autentikaci (ovení identity) uživatelé se v rámci "FTP relace" musí identifikovat musí se pihlásit místním uživatelským jménem a prokázat platným heslem anonymní FTP konvence: má-li být nco veejn pístupné, uživatelé se hlásí jako "anonymous" a heslo není významné, obvykle se požaduje emailová adresa kvli statistikám 25
v. 2.2 ídící jazyk FTP FTP definuje vlastníídící jazyk píkazy ídícího jazyka jsou penášeny ídícím spojením ídící píkazy mají textovou povahu, a jsou penášeny ve stejném tvaru, jakou pedpokládá protokol TELNET resp. pro jejich penos mohou být využívány již existující implementace TELNETu píkazy lze rozdlit na: ízení pístupu (access control commands) - nap. pro zadání uživatelského jména a hesla nastavení parametr pístupu (transfer parameter commands) - nap. pro zmnu implicitních ísel port, pro nastavení režimu penosu apod. výkonné píkazy (FTP service commands) - pro vlastní penos soubor, rušení, pejmenovávání atd., pro pechody mezi adresái apod. 26
v. 2.2 Odpovdi na píkazy FTP každý píkaz vyvolá alespo jednu odpov odpovdi majííselný charakter (s textovým komentáem) odpovdi tvoí trojmístnéíslo: prvnííslice vyjaduje celkový charakter odpovdi druháíslice upesuje odpov tetí ješt blíže specifikuje hierarchický charakter odpovdí vychází vstíc rzné inteligenci proces, které je vyhodnocují hloupý klient i server se mže spokojit jen s prvnííslicí chytrý klient (server) využije všechny íslice 1xx 2xx 3xx 4xx 5xx pedbžná kladná odpov (akce byla zahájena, budou ješt další odpovdi) kladná odpov prozatímní odpov (jsou nutné další píkazy) doasná záporná odpov (nepodailo se, ale je vhodné opakovat) trvalá záporná odpov (nepodailo se a nemá smysl opakovat) 27
v. 2.2 Píklad klient server RETR <soubor>... požadavek zaátek prbh innosti konec 160 ASCII retrieve of <soubor> started.. probíhá penos 226 Transfer completed, 123456 bytes transferred textový komentá generování lze lze vypnout 28
v. 2.2 ídící vs. uživatelský jazyk pevn definován a závazný je ídící jazyk píkazy ídícího jazyka mohou být vysílány run, pomocí TELNETu (na porty FTP) v praxi je na stran klienta vždy implementováno njaké uživatelské rozhraní (ádkové, grafické,.. ) toto rozhraní mže nabízet uživateli v podstat jakýkoli "uživatelský" (ídící) jazyk a pekládat jej do ídícího jazyka ídící jazyk RETR STORE LIST CWD typické pro ádkové klienty uživatelský jazyk GET PUT DIR CD 29
v. 2.2 Píklad 30
v. 2.2 Píklad (ádkový klient) Píkaz uživatele pro pro vypsání obsahu adresáe 31
v. 2.2 Píklad (grafický klient) píkaz kopírování soubory místního poítae soubory vzdáleného poítae 32
v. 2.2 Píklad (grafický klient) vzdálené soubory 33
v. 2.2 TFTP Trivial FTP existují situace, kdy protokol FTP není nejvýhodnjší: nap. pro tzv. bootstrap bezdiskových stanic je píliš složitý pro nkteré jednoduché OS je problém jej implementovat v rámci rodiny existuje oezaná verze FTP pod názvem TFTP (Trivial FTP) používá se hlavn pro "natažení" tzv. boot image pi startu bezdiskových stanic využívá penosových služeb protokolu UDP (FTP využívá TCP) TFTP si spolehlivost zajišuje sám, využívá jednotlivé potvrzování penáší data po blocích velikosti 512 byt TFTP nezná pojem uživatele nezajišuje žádné pihlašování na vzdáleném poítai ponechává na implementaci, jak se vyeší pístupová práva. Obvykle: pro TFTP dostupné je to, co je dostupné pro všechny uživatele TFTP nezajišuje na vzdáleném poítai žádné systémové akce typu ls, cwd, rm apod. nezná pojem aktuálního adresáe uživatel musí explicitn zadat úplnou pístupovou cestu k souboru, který má na mysli (a musí jej znát) 34
v. 2.2 Protokol NFS (Network File System) protokol pro transparentní sdílení soubor (file sharing) v rámci není jediný, ale je nejrozšíenjší má jiný pvod než klasické protokoly pochází od firmy Sun Microsystems (pvodn byl proprietárním ešením) posléze byl NFS pedložen IAB (IETF) ke standardizaci dnes je standardem (RFC 1094) a jeho specifikace jsou public domain vznikl v prostedí Unixu (SunOS, na bázi BSD Unixu) je ale koncipován jako otevený (jako univerzální síové rozšíení systém soubor na rzných platformách) není vázán ani na SunOS, ani na Unix jako takový dnes je implementován snad na všech platformách pipouští, aby klient i server stáli na rzných platformách 35
v. 2.2 Protokol NFS (Network File System) NFS je bezestavovým protokolem každý jednotlivý požadavek klienta vi serveru je uzavený, ped a po provedení píkazu se server nachází ve stejném stavu velmi to zjednodušuje zajištní korektnosti komunikace klienta a serveru (reakci na nestandardní situace, výpadky,..) bezestavovost NFS je klíem k velké robustnosti NFS není nutné ošetovat rzné výpadky a singularity bezestavový charakter pipouští pouze použití idempotentních operací (takových, které lze vícekrát opakovat se stejným efektem) nelze nap. používat píkazy typu pošli mi dalšíást souboru XY mohou to být pouze píkazy typu pošli mi M byt souboru XY, poínaje bytem N dvod úspšnosti NFS 36
v. 2.2 Problémy kolem NFS je možné realizovat všechny požadavky na pístup k souborm pomocí idempotentních operací? NE, nelze nap. provést OPEN (otevení), a soubor ponechat otevený, obdobn pro CLOSE NFS eší tak, že pro poteby vyízení každého jednotlivého požadavku soubor nejprve oteve, a pak jej zase ihned zave nkteré pípady nelze obejít jako u OPEN a CLOSE nap. APPEND (pidání za aktuální konec souboru) NFS eší zákazem takovýchto operací NFS si klade za cíl být použitelný na rzných platformách nemže se proto vázat na konvence žádné specifické platformy pi odkazech na soubory nemže používat specifikace pístupových cest typu /usr/bin/neco.txt (které jsou závislé na platform) pístupové cesty sestavuje vždy až klient podle místních konvencí, server používá vždy jen "jednorozmrná" jména soubor a adresá poátení "pimontování" (mount) ásti adresáového stromu není bezestavové NFS eší vylenním do tzv. MOUNT SERVERU 37
v. 2.2 Pedstava dlá dláto, to, co co NENÍ bezestavové dlá dláto, to, co co JE JE bezestavové klient klient a a server server pi pi vzájemné vzájemnékomunikaci používají používajísystémové identifikace identifikace soubor soubor (a (a adresá) adresá) tzv. tzv. file filehandle 38
v. 2.2 Systémová identifikace - handle pro odkazy na konkrétní soubory se v rámci NFS používají tzv. systémové identifikace (file handles) pro klienta je handle identifikátorem (dále nedlitelnou posloupností bit) pro server handle obsahuje ti složky, identifikující systém soubor soubor instanci souboru systémová identifikace (handle) jednoznan identifikuje bu soubor, nebo adresá systémové identifikace pidluje server, klient je pouze používá systémové identifikace mají absolutní povahu (a nikoli relativní, NFS nezná pojem aktuálního adresáe) systémová identifikace (handle) je ukazatelem na jedno konkrétní místo v rámci systému soubor serveru když klient vlastní systémovou identifikaci adresáe, mže si vyžádat výpis jeho obsahu souástí výpisu je seznam znakových etzc, popisujících jednotlivé soubory a podadresáe klient si mže vyžádat na serveru systémovou identifikaci zadaného souboru v adresái (i identifikaci podadresáe)...... serveru pitom musí pedat systémovou identifikaci adresáe, a znakový etzec popisující soubor i podadresá 39
v. 2.2 MOUNT server klient musí získat alespo jeden vstupní bod do systému soubor serveru (alespo jednu systémovou identifikaci) pak má k dispozici prostedky pro procházení celého stromu (systému soubor serveru) poskytnutí "prvního" handle ale není v silách NFS serveru vyžaduje specifikaci pístupové cesty první handle poskytuje MOUNT server!! MOUNT server eší další innosti, které také nemže zajišovat NFS server vede evidenci zpístupovaných (exportovaných) adresáových strom poátení "pimontování" adresáového stromu vetn ovení identity uživatele a jeho pístupových práv MOUNT server je typicky ešen na aplikaní úrovní nezáleží na jeho rychlosti NFS server bývá souástí jádra a je optimalizován na rychlost 40
v. 2.2 Implementace NFS poprvé významnji použit koncept tzv. vzdáleného volání procedur prostednictvím protokolu RPC - Remote Procedure Call) jde v zásad o zmnu na úrovni programování programátor nemusíešit asynchronní komunikaci, ale pouze volá pedem pipravené procedury knihovního charakteru implementace RPC je ešena tak, že mže být využita i samostatn mimo implementaci NFS dále je využit také protokol XDR (external Data Representation) samostatný standard, který definuje spolený penosový mezitvar je standardem v rámci definuje jednotný zpsob reprezentace penášených dat, nezávislý na konkrétní architektue píjemce a odesilatele definuje jazyk pro nezávislý popis tchto dat také XDR je implementováno samostatn, jako RPC 41