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 (71):
FTP - I.
V minulém dílu jsme si naznačili, že přenos a sdílení
souborů v počítačových sítích může být řešeno dvěma
principiálně odlišnými způsoby: transparentně
a netransparentně. Dnes se již dostaneme k tomu, jak je
v síťovém modelu TCP/IP zajišťován netransparentní přenos
- tedy k protokolu FTP.
Nejprve si ale znovu zopakujme, v čem je rozdíl mezi
transparentním a netransparentním řešením: v případě
netransparentního přístupu si uživatel plně uvědomuje rozdíl
mezi místními soubory a soubory na vzdáleném počítači,
a musí se sám a explicitně starat o jejich přenos, zatímco
v případě netransparentního přístupu místní a vzdálené
soubory splývají, pro uživatele mezi nimi není žádný
principiální rozdíl, a veškerou agendu spojenou
s předstíráním této iluze na sebe přebírá síťový software
a operační systém.
Minule jsme se již také zmínili o tom, že síťový model
TCP/IP pamatuje na obě varianty. Pro netransparentní
variantu nabízí hned dva protokoly - protokol FTP (File
Transfer Protocol, doslova: protokol pro přenos souborů),
který lze označit jako "plnohodnotný", vybavený množstvím
různých schopností a funkcí, a dále mnohem jednodušší
protokol TFTP (Trivial File Transfer Protocol), poskytující
jen základní funkce, ale zato implementačně jednodušší,
a často i rychlejší. Naše povídání začneme filosofií
protokolu FTP.
FTP je starší než TCP/IP
Na protokolu FTP je dobře patrný jeden význačný rys
celého síťového modelu TCP/IP - totiž skutečnost, že
nevznikl naráz, od zeleného stolu, ale postupným vývojem
a zdokonalováním. Jak jsme si uvedli již ve 42. dílu tohoto
seriálu, protokoly TCP/IP získaly svou dnešní podobu zhruba
v letech 1977 až 1979, a do sítě ARPANET se začaly
prosazovat přibližně od roku 1980, kdy se z ARPANETu
postupně stává zárodek dnešního Internetu. První verze
protokolu FTP pro netransparentní přenos souborů však
pochází již z roku 1971, a od té doby prošla dlouhým
vývojem, podporovaným širokou diskusí uživatelské
veřejnosti. Od začátku osmdesátých let, kdy i protokol FTP
přešel na používání transportního protokolu TCP (místo
původního transportního protokolu NCP sítě ARPANET) se ale
již zásadněji neměnil.
Správné zasazení protokolu FTP do historického rámce
nám pomůže snáze pochopit některé jeho koncepční rysy.
Jak se FTP vyrovnává s různorodostí
Již minule jsme si naznačili, že přenos a sdílení
souborů mezi různými uzlovými počítači může narážet na mnohé
problémy. Ukázali jsme si některé z nich, které vyplývají
z odlišného pohledu různých operačních systémů na soubory,
a to na "novodobém" příkladu Unixu a MS DOSu. V době, kdy
koncepce protokolu FTP vznikala a utvářela se, však
existovaly ještě mnohem základnější rozdíly mezi
jednotlivými počítači - některé z nich používaly osmibitové
byty a 32-bitová slova, zatímco jiné 36-bytová slova.
Některé pracovaly s textem tak, že jeho jednotlivé znaky
ukládaly do 8-bitových bytů v kódu EBCDIC (zejména
střediskové počítače IBM) nebo v kódu ASCII, zatímco jiné
ukládaly znaky po čtveřicích do 36-bitových slov (každý znak
do 9 bitů), a ještě jiné jich do 36-bitových slov "nacpaly"
až pět (každý znak do sedmi bitů). Některé počítače přitom
umisťovaly jednotlivé řádky textu do záznamů (records) pevné
délky, zatímco jiné chápaly text jako lineární posloupnost
jednotlivých znaků, členěnou vloženými znaky pro přechod na
novou řádku.
Protokol FTP se vyrovnává se všemi těmito odlišnostmi v
podstatě jediným možným způsobem: zavádí jednotný tvar, ve
kterém jsou data skutečně přenášena, a ponechává na obou
koncových účastnících, aby zajistili veškeré potřebné
převody z/do místních konvencí.
Zároveň ale protokol FTP vychází vstříc i případům, kdy
by jediný a neměnný přenosový tvar byl neefektivní,
a umožňuje jej v určitém rozmezí a po dohodě obou stran
měnit. V podstatě lze říci, že tento přenosový tvar má tři
stupně volnosti: režim přenosu, strukturu souborů
a reprezentaci dat.
Reprezentace dat
Při vlastním přenosu jsou veškerá data přenášena
zásadně jako 8-bitové byty. Protokol FTP však počítá s tím,
že počítače, na kterých jsou tato data uchovávána, mohou
používat jiné konvence - například 36-bitová slova, jiný
způsob ukládání jednotlivých znaků do celých slov (viz
výše), jiný znakový kód než ASCII, apod. Z tohoto důvodu
musí být na straně příjemce a/nebo odesilatele zajišťovány
potřebné konverze. Jejich provádění ovšem vyžaduje, aby obě
strany věděly, co si vlastně mezi sebou přenáší: zda jde
o text, složený z jednotlivých znaků, nebo zda jde o binární
data, která mají být chápána jako lineární posloupnost bitů,
nebo zde jde například o přenos jednotlivých bytů
nestandardní velikosti (např. devítibitových bytů).
Protokol FTP implicitně předpokládá, že přenášená data
představují ASCII text. Ten se pak skutečně přenáší v
tom formátu, který pro ASCII text požaduje protokol Telnet
(viz 68. díl). Jednotlivé znaky jsou tedy přenášeny jako
8-bitové, a řádky jsou oddělovány dvojicí znaků CRLF.
Odesilatel proto musí převádět jednotlivé znaky z takového
kódu a způsobu zobrazení, jaký používá jeho počítač, na
právě popsaný přenosový tvar (tj. převádět je do kódu ASCII,
ukládat po jednom do osmi bitů, a přechody na nové řádky
reprezentovat dvojicí znaků CR a LF). Analogicky se musí
chovat i příjemce.
Protokol FTP však umožňuje, aby se obě strany dohodly
na jiném významu přenášených dat. Možnosti jsou následující:
- text v kódu EBCDIC (přenášená data jsou tvořena
jednotlivými znaky, tyto jsou opět znázorněny v 8 bitech,
ale pro jejich kódování je místo znakového kódu ASCII použit
znakový kód EBCDIC). Tato varianta vychází vstříc přenosům
textů mezi střediskovými počítači IBM, které používají právě
znakový kód EBCDIC, a eliminuje tak dvojí konverzi každého
znaku.
- binární data (tzv. image type). V tomto případě obě
strany chápou přenášená data jako spojitou posloupnost bitů,
které jsou členěny na 8-bitové byty jen pro potřeby
vlastního přenosu.
- byty nestandardní velikosti (tzv. local byte). V tomto
případě může odesilatel stanovit, jak velké byty sám
používá, a dát příjemci možnost se tomu přizpůsobit.
Například počítač, který pracuje s 36-bitovými slovy, může
na tuto skutečnost upozornit příjemce, a ten pak může
například ukládat jednotlivá 36-bitová slova do dvou
32-bitových slov apod. Zde je ovšem třeba si uvědomit, že
jde jen o "logickou" velikost bytu, která slouží oběma
stranám jako vodítko pro provádění potřebných konverzí.
Nastavení nestandardní velikosti bytu nemá žádný vliv na
skutečnost, že vlastní data jsou doopravdy přenášena v
8-bitových bytech.
Struktura souborů
Další odlišností, se kterou se protokol FTP musel
vyrovnat, je rozdílný pohled na to, jak je soubor vnitřně
členěn. Zda je například považován za lineární posloupnost
bytů, nebo je členěn na sekvenční záznamy (records), nebo
zda je tvořen navzájem nezávislými stránkami, které jsou
opatřeny indexy, a mohou vytvářet nespojitý soubor.
V této souvislosti je opět třeba mít na paměti, že
různé systémy mohou pro jeden a tentýž druh souboru používat
jinou vnitřní strukturu - například texty se na většině
počítačů uchovávají v textových souborech, tvořených
lineární posloupností jednotlivých znaků (bytů), ale
například na střediskových počítačích IBM jsou textové
soubory organizovány jako posloupnosti záznamů pevné délky.
I zde pak musí nastoupit vhodné konverze na jedné straně či
na obou současně, ale opět platí zásada, že každý musí
vědět, co se vlastně přenáší.
Pokud není řečeno jinak, protokol FTP implicitně
předpokládá, že přenášený soubor nemá žádnou vnitřní
strukturu, a je tvořen lineární posloupností jednotlivých
datových bytů (tato možnost je označována jako file
structure). Další možnosti, na kterých se mohou zúčastněné
strany dohodnout, je soubor členěný na sekvenční záznamy
(record structure) a soubor, členěný na stránky (page
structure).
Režim přenosu
Třetím stupněm volnosti je režim přenosu dat. Důvodem
pro zavedení více různých režimů byla zřejmě snaha vyrovnat
se s nedokonalostí a omezenou kapacitou přenosových cest.
Protokol FTP totiž umožňuje provádět i určitou kompresi
přenášených dat, a také zotavit se z výpadku spojení v
průběhu přenosu a po obnovení spojení v něm pokračovat.
Implicitní režim přenosu (označovaný jako stream mode)
je takový, kdy přenášená data jsou chápána jen jako spojitý
proud (stream) bytů, a jako taková jsou také přenášena.
Je ovšem možně zvolit i jiný režim (blokový režim,
block mode), při kterém jsou přenášená data členěna do
bloků, a každý z nich je opatřen hlavičkou (která obsahuje
mj. údaj o délce bloku, příznak posledního bloku apod.). V
tomto režimu je pak možné vkládat mezi bloky, obsahující
vlastní data, i malé speciální bloky (identifikované
příznakem ve své hlavičce), které ve skutečnosti slouží jako
záložky (kontrolní body). Po výpadku spojení a jeho
následném obnovení je pak možné využít existence těchto
značek k indikaci místa, odkud má být přerušený přenos
opakován.
Třetím možným režimem přenosu je tzv. zhuštěný režim
(compressed mode), při kterém jsou přenášená data
komprimována. Nejde však o žádnou propracovanou a efektivní
kompresní techniku, jaké známe ze současné doby, ale jen
o pouhou eliminaci znaků, které se opakují několikrát za
sebou (typickým příkladem jsou posloupnosti mezer
v textových souborech). Takováto posloupnost stejných znaků
je pro potřeby přenosu nahrazena pouze jedním exemplářem
příslušného znaku a údajem o tom, kolikrát se v originále
opakuje.
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