FSP protokol - Internetová Legenda (3)

Softwarový design je umění

Dobře navrhnout program nebo přenosový protokol je umění. Pokud navrhujete program namísto protokolu, velmi záleží na použitém programovacím jazyku. Čím vyšší a čím dynamičtější programovací jazyk použijete, tím dostanete větší možnost vytvořit elegantní návrh. Správný návrh je jednoduchý a elegantní, což zvyšuje jeho čitelnost a výrazně snižuje množství chyb.

Jako příklad mohu uvést databázovou aplikaci napsanou v dynamicky typovaném jazyce, který navíc umožňuje i dynamické vytváření tříd za běhu. V klasickém statickém jazyce je nutné datové struktury v době překladu synchronizovat se strukturou tabulek. Elegantní návrh se ovšem podívá do databáze na strukturu dat a automaticky si vygeneruje příslušné třídy. Při jejich generování lze zohlednit u jednotlivých proměnných patřičný typ dat včetně integritních omezení CHECK, DOMAIN, REFERENCES, NOTNULL, CASCADE. Tento článek ale není zaměřen na tématiku psaní databázových aplikací v dostatečně dynamických jazycích, proto se vrátíme zpět k FSP, které bylo nakódováno v nudném jazyce K+R C.

Analýza problému

Ještě důležitější věcí je provést analýzu problému, který chceme řešit. Po správně provedené analýze se následně snažíme vyřešit všechny problémové oblasti, a pokud možno nepřidělávat žádné problémy navíc. FSP chtělo vyřešit problémy spojené s FTPčkováním z anonymních archivů. Podíváme se na ně.

Anonymní FTP v 90. letech: případová studie

S problémy anonymního FTP jsem se zabýval podrobněji v prvním dílu. Uvedu je proto už jen heslovitě.

1. Už samotné navázání TCP spojení se nemusí povést, jelikož linky jsou značně přetížené.
2. Na anonymní FTP server je nutné se přihlásit. Proč? Co je komu do mojí email adresy? Vždyť je to ANONYMNÍ FTP server.
3. Server trpěl mánií ověřovat si email adresy pomocí ident protokolu. Sice většinou uživatele nevyhodil, pokud nebyl spokojen s výsledkem, ale znamenalo to protlačit linkou další TCP spojení s dvouminutovým timeoutem, než se nás FTP server milostivě rozhodl přihlásit.
4. To přihlášení se nemusí povést (čti téměř nikdy se nepovedlo), jelikož je tam již mnoho userů s podobnými zájmy.
5. To ovšem neznamená, že by další useři vytrvale nebombardovali server TCP spojeními, jelikož se tam chtějí nalogovat také.
6. To ovšem zatěžuje server, jelikož se musí forknout a obsloužit další spojení alespoň do doby, než uživatele vykopne.
7. Většinou ho stejně vykopnout ani nestačil, neboť TCP spojení zhavarovalo.
8. To ovšem poznal až o mnoho sekund později, a tak v paměti zbytečně zabírala místo další kopie ftpd. Paměti byl vždy nedostatek.
9. . Kopie ftpd zabírala nejen paměť, ale i kapacitu linky, neboť resendovala data v TCP output queue a po odpískání ještě plašila zvěř RST packety.
10. Všechny problémy spojené s vyhazovem uživatelů by odpadly, pokud bychom spouštěli in.ftpd z inetd a inetd uměl limitovat počet připojení. Což tehdy neuměl.
11. Někteří umělci (např. já) se běžně přihlašovali na anonymní FTP server vícekrát. Dělalo se to proto, abyste v případě, že se vám složí jedno spojení, měli po ruce náhradní a mohli pokračovat. To ovšem zvyšuje celkový počet přihlášených uživatelů a blokuje ostatním přístup k FTP serveru.
12. Výpis adresáře vyžaduje DALŠÍ TCP spojení. Pravděpodobnost, že zařve alespoň jedno ze dvou TCP spojení, je logicky větší než v případě jednoho.
13. To samé platí i pro vlastní přenos souboru.
14. Výpisy adresářů vyžadovaly (a až na pár výjimečných ftpd vyžadují dodnes) od serveru spouštění externího programu /bin/ls. Což znamená fork a pravděpodobně i trochu zaswapování si.
15. Tento program vypisoval soubory v site-specific formátu, který se značně lišil podle OS použitého na serveru. Unixy byly v pohode, ale vyskytovaly se i hrůzy typu VMS, S/390, MVS/ESA, které vyžadovaly nadstandardní inteligenci nutnou pro orientaci v těchto výpisech, a to nejen proto, že velikost souboru nebyla uváděna v bajtech.
16. Výpisy adresářů se prakticky nedaly univerzálně přeparsovat pro použití ve scriptech. Vyžadovaly drobné úpravy pro konkrétní stroje.
17. ASCII transfer mód byl default, což byla největší missfeatura FTP protokolu proklínána všude možně. Už jste se dostali tak daleko a vaše data byla zákeřně přepadena ASCII módem.
18. Také se občas stávalo že ASCII mód byl použit už při nahrávání dat na server.

19. TCP timeouty byly největším problémem. TCP protokol funguje se značnými problémy již v sítích s patnáctiprocentní konstantní packet loss rate. V RFC dokumentech popisujících data flow rate management v TCP protokolu se počítá s max. deseti procenty, což je strop, při kterém je schopna pracovat většina současných implementací.

    Pokud TCP protokol zjistí, že se mu ztrácejí packety, sníží congestion window a zvýší resend timeouty. Domnívá, že packety se ztrácejí, jelikož je posílá moc rychle. Základní idea TCP je, že by se o přenosové pásmo měli všichni uživatelé podělit. TCP protokol nemá rád, pokud máte smůlu a ztratíte více přeposílaných packetů za sebou. Zvýší pak timeout moc drasticky a aplikace obvykle vypadne na timeout. Stejně tak potřebuje, aby na každé TCP spojení zbylo minimálně 5Kbit/s. Problematika okolo TCP je docela zajímavá a nechám si ji i s testy různých implementací na samostatný článek. Nás v tomto okamžiku zajímá jen fakt, že packet loss rate se pohybovala mezi 30–50 % a na dálkové TCP spojení zbyl zhruba jeden kilobit.

20. Navíc TCP protokol má druhou vlastnost, kterou jsme v případě anonymního FTP moc nedoceňovali. TCP se rádo se roztahuje a zabere co největší přenosové pásmo. Pokud vám na modemové lince běžela 2–3 FTP spojení, mohli jste na interaktivní telnet rychle zapomenout. Odezva se pohybovala v desítkách sekund.

Problémy s provozováním anonymního FTP serveru

1. Pro každého připojeného uživatele je potřeba kopie ftpd, což zabírá značné množství paměti.
2. Každá kopie spouští navíc externí /bin/ls
3. A spotřebuje dva sockety
4. Vzhledem k povaze TCP lze s jistotou předpokládat, že vaše linka bude vytížena na 100 %

Je pravda, že se nikdo v těchto dobách do provozování FTP serveru moc nehrnul. Pro 15 uživatelů současně byla potřeba mašina s minimálně 16 MB RAM, kterých nebylo mnoho.

Požadavky na optimální řešení

1. Podporovat větší množství klientů než doposud
2. Nevyžadovat od klienta email adresu, není žádný důvod, proč by se musel na server přihlašovat
3. Omezit vícenásobné přihlášení z jedné IP adresy
4. Zvýšit celkovou spolehlivost přenosu souborů
5. Šetřit přenosové pásmo. Přenos souborů je neinteraktivní aplikace a tudíž může počkat. Nechceme zbytečně zaplácávat síť
6. Preferovat spíše spolehlivost před rychlostí
7. Možnost pokračovat v přerušeném přenosu
8. Standardizovat výpisy adresářů
9. ASCII transfer mód je zlo
10. Větší škálovatelnost na straně serveru. Neforkovat, nespouštět externí programy, šetřit sockety
11. Výpisy adresářů by měly být rychlejší, přenosy souborů mohou být pomalejší.
12. Umožnit použití větších timeoutů při přenosu. Ideální by bylo přesunout správu timeoutů na klienta
13. Obejít nevhodné chování TCP protokolu na ucpaných linkách.
14. Celkově zjednodušit přenosový protokol. Chceme pouze přenášet soubory a vypisovat adresáře. K tomu není potřeba taková mašinerie jako FTP. FTPD 6.00 ze základního systému FreeBSD-5 umí 55 příkazů.
15. Uploady by měly být atomické
16. Nevyžadovat superuživatelská práva pro spuštění serveru

Pokud chceme hodnotit, zda design FSP byl, nebo nebyl správný, musíme mít tyto body stále na paměti. FSP bylo vytvořeno jako „light anonymní FTP“, nikdo od něj nepožadoval bezpečnost přenášených dat jako např. od sftp.

Příště se dočtete

V příštím dílu se už konečně podíváme podrobněji na to, jak FSP technologie přenos souborů od základů překopala, a to takovým způsobem, že jej admini považovali (a stále považují) za neuvěřitelnou zvrhlost. Já jsem vždy považoval (a stále považuji) FSP za vynikající dílo v oblasti softwarového designu, jelikož odstranilo všechny nedostatky stávající anonymní FTP technologie.