Test akcelerátorů Internetu: proč je dial-up pomalý?

V nadpisu tohoto článku se píše o „Internetu“, ale hned na začátek čestně přiznávám, že ve skutečnosti se budeme věnovat výhradně webu. Proč zrovna webu? Inu, ze zkušenosti mohu říci, že kromě techniků lidé obvykle ztotožňují Internet s tím, co vidí ve svém webovém prohlížeči (koneckonců se to přece jmenuje Internet Explorer, ne?). Jedinou významnější výjimkou je elektronická pošta, nicméně spousta uživatelů používá web i k mailování (a k mnoha dalším činnostem, k nimž se vůbec nehodí). Zkoumání obecného Internetu proto přenechme akademikům a hnidopichům (případně kombinaci obojího), a my ostatní budeme „rychlostí Internetu“ rozumět rychlost webu, resp. čas potřebný k zobrazení www stránky. Dále budeme pro jednoduchost předpokládat, že taková stránka je napsána v (X)HTML a že se přenáší protokolem HTTP.

Neuškodí, když začneme trochu zeširoka (netrpělivci, čtěte až přespříští odstavec). Z pohledu uživatele Internet obsahuje nějaké informace, které se mu zobrazují v prohlížeči ve formě stránek. Jednu takovou stránku často tvoří data, která poskytují různé servery. Nebudeme se příliš zabývat tím, co musí webový server udělat mezi přijetím požadavku a odesláním dat, přestože i to pochopitelně ovlivňuje, za jak dlouho se stránka uživateli zobrazí, a zaměříme se na tok dat mezi prohlížečem a servery, protože právě v tom se od sebe různé způsoby připojení k Internetu liší.

Podívejme se, jak celý proces zobrazení webové stránky zhruba probíhá. Na začátku je obvykle potřeba převést jméno serveru na IP adresu (dotaz DNS). Poté se prohlížeč spojí s daným serverem a vyžádá si stránku. Když se stránka načítá, prohlížeč ji průběžně parsuje, získává informace o dalších objektech ve stránce obsažených (obrázky, stylesheety, rámce, javascript aj.) a stahuje je stejným způsobem jako původní stránku. V průběhu parsování většina prohlížečů již také zobrazuje částečný obsah stránky. Reálná situace je o něco složitější, ale k tomu se dostaneme za chvíli; teď se vrátíme k rychlosti modemového připojení k Internetu.

Zdálo by se, že úzkým hrdlem je linka mezi ISP a uživatelem – její přenosová rychlost je maximálně 56 kbit/s u k­lasického dialupu a 128 kbit/s u ISDN při spojení obou kanálů, zatímco rychlosti na páteřní síti se pohybují nejméně o tři řády výš. Jak je ale tato kapacita skutečně využita a kde nastávají zdržení?

DNS

Klient vždy musí nejprve vyslat UDP paket s dotazem na DNS server ISP a čekat, než se tento server rekurzivně dopracuje až k odpovědi, kterou pošle zpět. U často vyžadovaných dotazů (např. www.lupa.cz :-) bude příslušná odpověď v cache, takže odpadne rekurze, ale i tak je tu určitá prodleva.

Navázání spojení TCP

Klient navazuje spojení s každým serverem, někdy i více spojení s jediným serverem. Každé zahájení spojení s sebou nese přinejmenším jedno čekání (mezi odesláním TCP paketu s nastaveným bitem SYN a přijetím paketu SYN ACK).

Vlastní přenos dat

Přímo z koncepce protokolu TCP vyplývá, že kapacita linky nebude ani v ideálním případě využita na maximum. Začněme velikostí MTU. Ta bývá u modemových serverů menší (typicky 576 bytů) než na serverech (většinou 1500 bytů), takže dochází k fragmentaci. V praxi však ztráta nebude nijak drastická: při minimální délce hlavičky protokolu IP (20 bytů) se fragmentací proplýtvá cca 0,44 procenta šířky pásma.

Výrazněji se projevuje velikost okna TCP, resp. algoritmus TCP Slow Start (viz RFC 2581). Jde o to, že vysílající strana ve spojení TCP se snaží maximalizovat velikost okna, aby se eliminovaly prodlevy při čekání na potvrzení ACK. Počáteční okno je ovšem malé, aby se zabránilo případnému zahlcení sítě. Při přenosu větších bloků dat to nevadí, protože velikost okna se celkem rychle ustálí na ideální hodnotě, ale to se zpravidla netýká persistentních spojení HTTP, pokud se přenáší postupně několik malých souborů (např. ikony).

Konkurence paralelních spojení

Jak jsme uvedli výše, prohlížeč se stahováním dalších objektů nečeká, až se dokončí přenos kódu HTML, ale rovnou naváže další spojení. Jenže paralelně probíhající přenos využívá prakticky celou šířku pásma ve směru ke klientovi, a tím se zvětšuje latence. Je sice pravda, že důležitější je latence v opačném směru (kvůli paketům ACK), ale i příliš velké zpoždění paketu ve směru k uživateli má za následek, že příslušný ACK nebude včas odeslán a vysílající strana znovu zbytečně pošle data, která už klient má.

Ve směru od serveru se pochopitelně také občas ztratí či zpozdí paket ACK, takže klient musí zopakovat požadavek HTTP. Ačkoliv je tady situace lepší, protože retransmit probíhá ve směru od klienta (tj. kapacita linky nebývá problém), prodlouží se časový limit, a když se ztratí i další pakety ACK, může se v nejhorším případě dostat až do oblasti exponenciálních časů (viz STD007). Uživatel to většinou diagnostikuje jako „zamrzlé spojení“ a klikne na tlačítko Obnovit…

Zmíněné problémy se projevují tím výrazněji, čím více paralelních spojení je otevřeno. Běžně používané prohlížeče se naštěstí nesnaží otevřít najednou více spojení než určité maximum, ale i to je pro vytáčené linky příliš vysoké.

Kde se dá ušetřit?

Všechny výše uvedené problémy kromě posledního řeší použití proxy. Prohlížeč se pak nemusí zajímat o DNS, spojení s proxy bude trvalé, a to i v případě, že požadujeme stránky z různých serverů. Dobře nastavená proxy pro dial-upy by měla mít i vhodné MTU. Tady bych se chtěl zmínit o zachytávajících proxy („intercepting proxy“; nesprávně, zato častěji, označované jako transparentní proxy). Z uvedených problémů taková proxy pomůže jenom s MTU.

Konkurenci paralelních spojení řeší akcelerátory, a to tak, že se samy chovají jako proxy na klientském počítači a k nadřízenému proxy serveru otevírají jediné spojení.

To je zřejmě vše, co lze získat optimalizací spojení TCP/IP. Tím ovšem nejsou vyčerpány všechny možnosti, jak zkrátit čas potřebný pro zobrazení stránky.

Komprese

Protože HTML je z pohledu teorie informace vysoce redundantní, přímo se nabízí možnost jej komprimovat. Oproti přímému připojení umožní použití proxy (a to i zachytávájící proxy) použít kompresi gzip i tam, kde webové servery posílají obsah nekomprimovaný. Jak ale uvidíme, úspora nemusí být nijak velká.

Při modemovém přenosu dat může dojít ke kompresi na několika úrovních. Na té nejnižší stojí modemové protokoly, např. tedy V.42bis či V.44. O něco výš stojí při vytáčeném spojení protokol PPP, který také nabízí několik metod komprese, na Windows nejčastěji MPCC (Microsoft Point-to-Point Compression). Na nejvyšší úrovni pak stojí „Content-Encoding“ protokolu HTTP (např. gzip). Je zřejmé, že při kompresi na vyšší úrovni dostanou protokoly nižší úrovně data s nižší mírou redundance a dosáhnou horších kompresních poměrů. Lidově řečeno, co zkomprimuje HTTP, na tom už si MPCC vyláme zuby. Naopak, když na úrovni HTTP budeme přenášet nezkomprimovaný kód HTML, bude komprese na úrovni PPP vysoce efektivní. Neméně důležité je, že spousta formátů dat je komprimovaná sama o sobě (GIF, JPEG, MPEG, AVI, OGG, …), takže při jejich přenosu už se nic nezkomprimuje.

Předchozí odstavec se týká bezeztrátové komprese. U obrázků však přichází v úvahu i ztrátová komprese, kde dojde ke snížení kvality. Také tuto možnost akcelerátory využívají a dokonce umožňují, aby si uživatel sám vybral, jaký kompromis mezi kvalitou a velikostí mu nejlépe vyhovuje.

Nepřenášet nepotřebná data

Svým způsobem sem patří i techniky proti zbytečným retransmitům na úrovni TCP, ale těžištěm této metody je filtrování reklamních bannerů. Podstatnou, ba mnohdy převážnou část webových stránek totiž tvoří reklama, kterou uživatelé vnímají jako irelevantní. Kromě bannerů akcelerátory dokážou zablokovat i některé typy dat (např. flash).

       

Další možností, která se nabízí, je přenášet data v pořadí podle relevance. Prohlížeče totiž začínají zobrazovat stránku dříve, než stáhnou všechny v ní obsažené objekty, a uživatele většinou text zajímá více než obrázky. Opravdu málokdy uživatel čeká na úplné natažení stránky a i v tom případě jistě uvítá, když může začít číst co nejdříve. Přitom ve chvíli, kdy se otevře několik paralelních spojení, může být načítání textu brzděno právě obrázky. Pokud je mi známo, tímto směrem se zatím nikdo nevydal.

A co dál?

Příště opustíme teoretické úvahy a podíváme se zcela prakticky, jak se daří zkrátit čas přenosu pěti českým akcelerátorům.