FSP protokol - Internetová Legenda (4)

Hacker Wen-King Su: Hrdina počítačové revoluce

Hrdina počítačové revoluce Wen-King Su se rozhodl odpovědět na výzvu, kterou představovalo anonymní FTP. Na FSP, které nazýval ‚Anonymní FTP udělané správně‘, začal pracovat již v roce 1989, ačkoliv první veřejná release FSP 1.0 byla uveřejněna až v prosinci 1991. Verze 2.0 vzápětí rychle následovala – ještě tentýž měsíc. Její největší výhodou byla existence man pages, jelikož FSP je program se zcela originálním ovládáním.

To umožnilo použití FSP mezi širší veřejností. FSP byla bomba – koncept, který WKS navrhl, se v praxi prokázal jako skvělý. Na rozdíl od anonymního FTP totiž skvěle (čti spolehlivě) fungoval. Další verze následovaly poměrně rychle za sebou, a to až do května 1993, kdy vyšla poslední oficiální stabilní verze 2.7.1, která byla po mnoho dalších let nejpoužívanější verzí FSP. Existovaly sice betaverze 2.8, ale ty se sháněly velice obtížně.

*** FSP je Anonymní FTP udělané správně ***

Kuchařka

Přenos souboru znamená přenést bajty tvořící požadovaný soubor F z anonymního archivu A k uživateli U s využitím sítě S pracující s přenosovým protokolem P. K tomu je potřeba rozsekat soubor F na části o velikosti packetu P, který je schopna síť S přenést. Jelikož síť S negarantuje spolehlivé přenášení packetů P, je nutné v packetu P kromě vlastních dat přenášet i hlavičku H obsahující řídící informace, aby se nám data D obsažená v packetech P nepopletla a složila soubor F, tak aby platilo A.F == U.F.

Právě jste byli seznámeni se základní design myšlenkou FSP. Jelikož je základní myšlenka přenosu souboru velice jednoduchá, implementace by měla být jednoduchá také. Nejjednodušší věci fungují nejspolehlivěji.

Sítě založené na Internet Protokolu (IP)

Jak již název napovídá, sítě založené na IP protokolu přenášejí IP packety. V IP hlavičce čítající obvykle 20 bajtů se kromě nudných řídících informací nacházejí i tři důležité věci: Adresa odesilatele, adresa příjemce a protokol, který je v IP packetu zabalen.

Pokud čekáte, že v IP packetu byl zabalen přímo FSP protokol, musím vás zklamat. Nebyl. Ačkoliv je to jeden z dost rozšířených mýtů. V unixovém prostředí by to bylo totiž dost nepraktické. V embedded systémech balím FSP packety přímo do layer 2 rámců, jelikož je to tak jednodušší.

Nejen TCP je živ Internet

Uživatelským aplikacím pracujícím v IP sítích není posílání IP packetů přímo z aplikace umožněno z bezpečnostních důvodů (např. možnost měnit adresu odesilatele). Aplikacím jsou přístupné dva protokoly TCP a UDP. Protokol UDP pouze rozšiřuje IP protokol o čísla portů. TCP protokol přidává čísla portů také a navíc garantuje aplikační úrovni spolehlivý přenos dat v rámci navázaného spojení.

V IP síti se neztrácejí UDP nebo TCP packety. V IP síti se ztrácejí IP packety, a to bez ohledu na to, jaký protokol je v nich zabalen. Pokud TCP vrstva zjistí ztrátu dat, provede tomu odpovídající akci. V případě UDP musí tuto akci provést sama aplikace. UDP tak umožňuje větší kontrolu nad vlastním přenosem.

Zničil jste mi spojení Cimrmane! Tak to zkuste bez něj!

Protokol FSP využívá, na rozdíl od FTP, UDP protokol. Touto velmi chytrou volbou se vyhnul řadě nevýhod spojených s TCP. UDP protokol nezná vůbec koncept spojení. Posíláte si a přijímáte packety, kam je libo a odkud je libo. Není třeba se o tom s cílovou stanicí nějak předem dohadovat.

Tím se zcela vyřešil problém s připojováním na server, s přihlašováním, s omezeným počtem anonymních uživatelů a s timeouty, které mohou u navázaného spojení nastat. Nepřipojujeme se. Tečka.

Potřebujeme data, ne spojení

Od serveru potřebujeme získat data. Tak si o ně řekneme postupem, který byl popsán v kuchařce. V kuchařce o žádném spojení nebyla řeč.

FSP klient: Chci 1024 bajtů z offsetu 2048 ze souboru /pub/fsp-2.8.1b22.tar.bz2
FSP server: Tady máš ty data.
FSP klient: zapíše si je do souboru.
FSP klient: Chci 1024 bajtů z offsetu 3072 ze souboru /pub/fsp-2.8.1b22.tar.bz2
FSP server: Tady máš ty data.
FSP klient: zapíše si je do souboru. 

Jak vidíte, přenos souboru je vlastně jednoduchá věc. Proč bychom to měli komplikovat.

Congestion window history

Některé protokoly založené na UDP implementují podobně jako TCP protokol congestion window techniku. Jsou to zejména známé protokoly pro sdílení souborů: NFS, AFS, CODA. V dávných dobách nebyly TCP implementace tak dobré jako dnes, a tak bylo v lokální síti výrazně rychlejší posílání dat tímto způsobem. Dnešní implementace TCP jsou už natolik dobré, že rozdíl NFS3 přes TCP nebo UDP je minimální. Pokud chceme využívat tuto techniku, je dnes mnohem snazší využít služeb TCP. Výhoda této techniky je ve zvýšení přenosové rychlosti, jelikož je možné mít několik packetů takříkajíc „na trati“. FSP tuto techniku záměrně neimplementuje.

Ty sis nevzal klíče? Počkej venku.

Po chvíli přemýšlení nad FSP vás napadne následující scénář, ve kterém odešleme více žádostí, aniž bychom čekali na odpověď serveru.

FSP klient: Chci 1024 bajtů z offsetu 2048 ze souboru /pub/fsp-2.8.1b22.tar.bz2
FSP klient: Chci 1024 bajtů z offsetu 3072 ze souboru /pub/fsp-2.8.1b22.tar.bz2
FSP server: Tady máš ty (první) data.
FSP server: Ty sis nevzal klíče? No to máš blbý, já jsem ti je posílal, takže budeš muset minutu počkat, nebo je jdi zatím hledat.
FSP klient: zapíše si (první) data do souboru, druhá nedostane. 

V dobách, kdy jsme běželi na Netware, se tomuto postupu říkalo burst mód. Ačkoliv IPX neimplementovalo techniku congestion window, nebránilo se této technice. Wen-King Su nebyl zjevně žádný začátečník a takové chování nejen předvídal, ale dokonce i znemožnil.

Klíčování

FSP protokol není stoprocentně stateless. Každá odpověď serveru obsahuje 16bitový, serverem náhodně zvolený klíč. Tento klíč musí klient uvést ve svém dalším požadavku. Pokud jej neuvede, bude muset minutu čekat venku, než se s ním server začne znovu bavit. Původní verze fspd měla místo 60 dokonce 300 sekund. To bylo dost kruté.

Pomaleji to už nejde

Cílem této techniky je snížit přenosovou rychlost a tím i zatížení sítě na nejnižší možnou míru. Přenos souborů je neinteraktivní úloha, a proto může počkat a nechat síť volnou pro ostatní aplikace. V praxi dosahuje FSP prokolol na volné lince 2,5–3× menší přenosovky než TCP. Na zatížené lince je vzhledem k agresivní nátuře TCP ještě pomalejší, což je přesně to, co chceme. Chceme spolehlivě přenášet soubory a nezacpávat si síť.

Netlačte se, po jednom!

Klíče jsou přidělovány fsp serverem na základě IP adresy odesilatele. Pokud bude chtít více uživatelů z jednoho stroje přistupovat ke stejnému fsp serveru současně, budou si muset předávat obdržené klíče od serveru mezi sebou. Toto předávání se dělá v praxi přes SysV IPC nebo přes soubory v /tmp. Více přihlášení z jedné IP adresy tedy možné je, ale spotřebovaná bandwidth zůstává stejná, jako kdyby byl připojen jen jeden uživatel.

Máte ty packety moc dlouhý, já vám je zkrátím

Rychlost přenosu FSP téměř přímoúměrně závisí na velikosti přenášených packetů. FSP protokol používá standardně packety o velikosti 1024 bajtů dat + 12 bajtů FSPv2 hlavička. Pokud potřebujeme FSP více přibrzdit, je nejlepší velikost packetů snížit. Administrátoři fspd to s oblibou dělají. Snížení velikosti packetu na minimálních 64+12 bajtů jemně naznačí návštěvníkům, aby se poohlédli po jiné sajtě.

Rychleji by to nešlo?

Novější verze fspd umějí zpracovávat i větší packety. Pokud velkost packetů zvýšíme zhruba na 2*MSS, dostaneme se až na rychlost srovnatelnou s TCP. Tyto packety se však musí na IP úrovni fragmentovat, čímž klesá spolehlivost jejich přenosu, protože pokud nedorazí druhá půlka, je první půlka zahozena. Není to vhodné používat na příliš ucpaných nebo ztrátových linkách. Maximální velikost odesílaných packetů závisí v každém případě na konfiguraci fspd, klient si koneckonců může požadovat, co chce.

Neříkej mi to dvakrát, já tě slyším

Technika klíčování ve FSP umožňuje ještě jednu hezkou věc. Podle použitého klíče můžeme zjistit, zda nám klient posílá novou žádost, nebo zda opakuje starou, protože se námi posílaná odpověď na cestě ztratila.

Abychom zabránili klientům v příliš rychlém přeposílání žádosti se starým klíčem, je v FSP protokolu definováno, že server odpoví na žádost podloženou starým klíčem až po uplynutí tří sekund od doby odeslání poslední odpovědi.

Přesné měření round trip time

V designu FSP bylo pamatováno ještě na jednu sympatickou věc. Klient si může packet před odesláním na server označkovat a server mu při odpovědi tuto značku vrátí. Pokud klient bude u každého svého odesílaného packetu tuto značku měnit, může po obdržení odpovědi přesně spočítat RTT, pokud ví, kdy packet odesílal. Podle RTT zjistí, jak má dlouho čekat na odpověď od serveru před opakováním žádosti. Kromě toho musí ještě počítat s tím, že mu server dřív než za tři sekundy stejně nic nepošle.

Závěr

Takže po dnešku již máte nějakou základní představu o FSP: light weight přenosovém protokolu. Tím jsme zdaleka nevyčerpali všechny věci okolo FSP.