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.