Hlavní navigace

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

Petr Tesařík

V prvním díle si povíme, proč je Internet přes modem pomalejší, než by odpovídalo rychlosti samotných modemů. Spojení mezi ISP a uživatelem sice brzdí, ale více, než je záhodno. Také nastíníme způsoby, jak je možné čas ušetřit, a s čím nám tedy mohou pomoci programy zvané akcelerátory. V díle druhém se pak podíváme na praktické výsledky pěti z nich.

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.

Našli jste v článku chybu?

21. 2. 2005 16:59

Zdenek Pavlas (neregistrovaný)
Od nuly se nezacina hlavne proto, protoze klient casto recykluje lokalni cisla portu, a je treba rozlisit stare a nove TCP sessions.

Nmap tu "nahodnost" testuje hlavne kvuli OS fingerprintingu. Kdysi lide pouzivali rsh a .rhosts, tak se spoofnutim adresy dalo nekam vlamat, ale to uz je myslim davno pryc.

Nedavno na LKML bezela debata, ze zcela nahodna sekvencni cisla NEJSOU vhodna, prave kvuli pozadavku na zabraneni "aliasingu" s nedavno ukoncenymi TCP sessions.





21. 2. 2005 15:20

TomK (neregistrovaný)
Mas pravdu, overoval jsem si ty GIFy v CProxy a opravdu se prenaseni (zrejme) downsamplovane na nizsi rozliseni a Cproxy je pak u klienta resampluje na puvodni velikost vcetne antialiasingu, pricemz se (z principu komprese pouzite v GIF) zvysi jejich datovy objem nad "puvodni" GIF.
Vitalia.cz: Bižuterie tisícinásobně překračuje povolené limity

Bižuterie tisícinásobně překračuje povolené limity

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Podnikatel.cz: 3, 2, 1..EET startuje. Na co nezapomenout?

3, 2, 1..EET startuje. Na co nezapomenout?

Měšec.cz: Banky mlží o nákladech na předčasnou splátku hypotéky

Banky mlží o nákladech na předčasnou splátku hypotéky

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Vitalia.cz: Analýza letáků: Na co lákají do prodejen?

Analýza letáků: Na co lákají do prodejen?

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

Měšec.cz: Vklad na cizí účet je draze zpoplatněn (přehled)

Vklad na cizí účet je draze zpoplatněn (přehled)

Měšec.cz: Za palivo zaplatíte mobilem (TEST)

Za palivo zaplatíte mobilem (TEST)

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

Root.cz: Mirai má nový cíl 5 milionů routerů

Mirai má nový cíl 5 milionů routerů

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru