zpět do archivu článků |
rejstřík |
předchozí díl |
následující díl
Jiří Peterka: Co je čím ... v počítačových sítích (72):
FTP - II.
V předchozím dílu jsme se začali zabývat konkrétními
vlastnostmi protokolu FTP, který má v rodině protokolů
TCP/IP na starosti netransparentní přenos souborů. Přitom
jsme se věnovali hlavně způsobu, jakým se tento protokol
vyrovnává s odlišnostmi různých počítačů a jejich operačních
systémů v pohledu na soubory, jejich vnitřní strukturu a
vlastní obsah. Dnes se již dostaneme k tomu, jak přenos
souborů podle protokolu FTP v praxi probíhá - kým je
iniciován, kým je řízen, jakými příkazy atd.
Implementace protokolu FTP vychází z architektury
klient-server, kterou jsme si přiblížili již v 64. dílu
seriálu. Předpokládá tedy existenci dvou navzájem
nerovnoprávných složek: klienta a serveru. Složka v roli
klienta je iniciátorem, z jehož popudu k přenosům souborů
dochází, a server je druhou stranou, která přitom
spolupracuje. Server tedy nabízí jako svou službu spolupráci
na přenosu souborů, a klient je tím, kdo o tuto službu
žádá. Typicky je složka v roli klienta představována
aplikačním programem, který si uživatel spouští na svém
počítači, a složka v roli serveru démonem (FTP démonem
v prostředí Unixu, resp. obdobným systémovým procesem
v jiném prostředí) na tom počítači, ze kterého či na který
uživatel chce přenést nějaký soubor. Vlastní směr přenosu
(od serveru ke klientovi či naopak) přitom není pro
rozlišení obou složek relevantní.
Trvale jen nezbytné minimum
 |
Obr. 72.1. Představa složek v roli klienta a serveru protokolu FTP
Protokol FTP vychází vstříc takovému způsobu
implementace, který se snaží minimalizovat své nároky na
různé systémové prostředky - umožňuje žádat o jejich
přidělení až na základě skutečné potřeby, a po jejich
použití je zase vrátit. Konkrétní myšlenka je taková, že po
celou dobu komunikace mezi klientem a serverem (tedy po
celou dobu existence relace mezi nimi) musí existovat jen
to, co zajišťuje vysílání a příjem nejrůznějších příkazů
a odpovědí na ně mezi klientem a serverem, zatímco všechno
ostatní, co je potřeba pro vlastní přenos dat, může vznikat
dynamicky, až na základě skutečné potřeby.
Této představě odpovídá i vnitřní členění složek v
roli klienta a serveru i povaha komunikačních kanálů mezi
nimi - viz obr. 72.1.
Interpret protokolu a přenosový proces
Ta část složky v roli klienta, která existuje trvale
(resp. po celou dobu práce s aplikací, která protokol FTP
implementuje), je tzv. interpret protokolu (PI, Protocol
Interpreter). Jeho úkolem je nejprve navázat spojení
s partnerským interpretem protokolu na straně serveru,
a poté iniciovat jednotlivé akce a řídit jejich průběh. Činí
tak prostřednictvím příkazů, které zasílá svému partnerskému
interpretu protokolu na straně serveru, a dále tím, že na
své straně dynamicky vytváří a řídí tzv. přenosový proces
(DTP, Data Transfer Process), který pak zajišťuje vlastní
přenos dat na základě pokynů od svého interpretu protokolu
a pokynů druhé strany.
Řídící a datové spojení
Interpret protokolu na straně klienta navazuje spojení
se svým partnerským interpretem na straně serveru
prostřednictvím protokolu TCP - to znamená, že spojení mezi
oběma interprety má povahu spojovaného a spolehlivého
spojení. Interpret na straně serveru musí čekat na žádost
o navázání spojení na jednom z tzv. dobře známých portů
(konkrétně na portu č. 21). Jakmile je spojení navázáno,
existuje po celou dobu existence relace, ale je využíváno
jen pro pro potřeby řízení této relace - proto se mu také
říká řídící spojení (control connection).
Jakmile si oba interprety mezi sebou vykorespondují, že
má být proveden nějaký přenos, vytvoří za tímto účelem své
přenosové procesy. Ty si pak mezi sebou naváží samostatné
spojení (opět prostřednictvím protokolu TCP, tedy spolehlivé
a spojované), a jeho prostřednictvím pak zajistí vlastní
přenos dat. Proto se tomuto spojení také říká datové spojení
(data connection). Za povšimnutí stojí skutečnost, že
zatímco navázání řídícího spojení iniciuje klient (přesněji
interpret protokolu na straně klienta), povinnost iniciovat
navázání datového spojení má naopak server (resp. jeho
přenosový proces). Interpret protokolu na straně klienta
naopak instruuje svůj přenosový proces, aby čekal na
zadaném portu na navázání spojení.
Protokol FTP ovšem připouští i jinou možnost, než jen
přenos souborů mezi jedním klientem a jedním serverem.
Dovoluje, aby uživatel z jednoho počítače inicioval přenos
souborů mezi dvěma jinými počítači (tedy mezi dvěma
vzdálenými počítači). V tomto případě existuje složka v roli
klienta na počítači, na kterém pracuje uživatel, a na obou
vzdálených počítačích musí existovat složky v roli serveru.
Řídící spojení musí být navázána dvě, a to mezi interpretem
protokolu klientské složky a interprety obou serverů,
a jejich prostřednictvím instruuje klient oba servery, jak
mají zajistit požadovaný přenos. Datové spojení je pak ale
vytvářeno jen mezi oběma servery, tj. vlastní data již
neprochází přes klientský počítač.
Příkazy pro řízení přenosu
Interprety protokolu na straně klienta a serveru spolu
komunikují prostřednictvím jazyka, který je součástí
definice protokolu FTP. Tento jazyk je tvořen příkazy (které
vysílá interpret klienta) a odpověďmi na ně (které vysílá
interpret serveru). Jednotlivé příkazy lze rozdělit do tří
základních skupin, na:
- příkazy pro řízení přístupu (access control commands),
umožňují mj. zadat uživatelské jméno a heslo,
které pak složka v roli serveru bude používat při všech
následných požadavcích na přístup k souborům (viz též
70. díl)
- příkazy pro nastavení parametrů přenosu (transfer
parameter commands), které umožňují například změnit
implicitní čísla portů, používaných při navazování
datového spojení, nastavit režim přenosu, stanovit
reprezentaci dat či strukturu přenášeného souboru (viz
minulý díl seriálu).
- výkonné příkazy (FTP service commands), které iniciují
vlastní přenosy souborů a manipulaci s nimi
(přejmenovávání, rušení), práci s adresáři (přechody na
podadresář či na nadřazený adresář), výpisy obsahu
adresáře (vlastní výpis je pak přenášen prostřednictvím
datového spojení) apod.
Odpovědi
Každý příkaz generuje alespoň jednu odpověď (některé
dokonce více odpovědí). Jednotlivé odpovědi přitom mají
formu číselných kódů - trojmístných desítkových čísel - za
kterými následuje vysvětlující text. Představa je ovšem
taková, že rozhodující jsou pouze číselné kódy, které v sobě
nesou veškerou podstatnou informaci, zatímco text má pouze
vysvětlující charakter, a jeho obsah není navíc vůbec
závazný (tj. různé implementace mohou ke stejnému číselnému
kódu připojovat různé vysvětlující texty). Logika je taková,
že číselný kód je určen pro program, který odpovědi
vyhodnocuje. Ten může podle svého uvážení vysvětlující text
jednoduše ignorovat, nebo jej zobrazit uživateli, aby i on
byl pro něj srozumitelnou formou informován o odpovědích
serveru.
Zajímavý je i způsob kódování číselných odpovědí, který
vychází vstříc různé úrovni detailnosti při vyhodnocování
odpovědí. Číselný kód je trojmístný, a jeho první číslice
udává to, zda odpověď je dobrá, špatná či neúplná (viz
tabulka 72.2.). Nejjednodušší implementace se pak mohou
rozhodovat jen podle této první číslice, zatímco
propracovanější implementace mohou získat podrobnější
informace vyhodnocením druhé, ev. i třetí číslice.
1xx | předběžná kladná odpověď (požadovaná akce byla úspěšně zahájena, ještě bude následovat další zpráva o jejím průběhu) |
2xx | kladná odpověď (požadovaná akce byla úspěšně provedena, resp. dokončena) |
3xx | prozatímní kladná odpověď (příkaz byl přijat, ale pro zahájení požadované akce jsou nutné ještě další příkazy) |
4xx | dočasná záporná odpověď (požadovaná akce nebyla úspěšně provedena, ale důvod neúspěchu je dočasný, a má smysl žádat o nové provedení akce) |
5xx | trvalá záporná odpověď (požadovaná akce nebyla úspěšně provedena a nemá smysl se o ni pokoušet znovu) |
Tabulka 72.2: Význam první číslice odpovědi
FTP používá Telnet
Za povšimnutí stojí i konkrétní forma, v jaké jsou
jednotlivé příkazy a odpovědi na ně přenášeny řídícím
spojením. Příkazy i odpovědi mají zásadně textovou formu -
jména příkazů tvoří tří až čtyřpísmenné zkratky, a také
číselná část odpovědi je přenášena textově (jako trojice
desítkových číslic). Vzhledem k tomu se protokol FTP může
odvolávat na protokol Telnet a požadovat, aby tyto texty
byly přenášeny po řídícím spojení přesně tak, jak to činí
protokol Telnet. V praxi to znamená, že implementace
protokolu FTP pro přenos příkazů a odpovědí řídícím spojením
buďto sama využívá služeb již existující implementace
Telnetu, nebo si sama implementuje tu část protokolu Telnet,
kterou skutečně potřebuje (protože zdaleka nevyužívá všech
možností, na které protokol Telnet pamatuje).
Uživatelský vs. řídící jazyk
Důsledně textová podoba řídícího jazyka i využití
protokolu Telnet pro přenos příkazů a odpovědí nevylučuje,
aby na straně klienta vydával příkazy řídícího jazyka místo
interpretu protokolu přímo uživatel, který si otevře
vzdálenou terminálovou relaci s interpretem na straně
serveru (pokud přitom dodrží všechny konvence protokolu
FTP). Běžný případ to ale rozhodně není.
 |
Obr. 72.3. Příklad průběhu relace protokolu FTP
Obvyklá implementace protokolu FTP obsahuje vedle
interpretu příkazů a přenosového procesu ještě i uživatelské
rozhraní, které zajišťuje komunikaci mezi uživatelem
a interpretem příkazů (viz obr. 72.1.). Toto rozhraní pak
může nabízet v podstatě jakýkoli "uživatelský" jazyk, který
pak ve spolupráci s interpretem protokolu překládá do
řídícího jazyka, a ten již je pro všechny implementace
jednotný. Z pohledu uživatele (který využívá služeb
protokolu FTP prostřednictvím uživatelského jazyka) se proto
různé implementace FTP mohou "tvářit" jinak (mohou používat
různé příkazy pro tytéž činnosti, místo řádkového rozhraní
mohou používat grafické uživatelské rozhraní apod.), ale
díky používání jednotného řídícího jazyka by se měly všechny
správně domluvit.
Příklad průběhu relace mezi klientem a serverem ukazuje
obrázek 72.3.
zpět do archivu článků | rejstřík |
předchozí díl |
následující díl
Tento článek může být volně šířen, pokud se tak děje pro studijní účely, na nevýdělečném základě a se zachováním tohoto dovětku. Podrobnosti hledejte zde, resp. na adrese
http://ksi.ms.mff.cuni.cz/~peterka/archiv/copyleft.htm