Je samozřejmé, že nejpravděpodobnější odpovědí bude: když není omezení u nás, tak bude u kolegy na druhé straně. Někdy však nemusí být odpověď tak jednoduchá, problém prostě může být někde na trase. Například chceme uspořádat videokonferenci, obě strany jsou připojeny k Internetu dostatečně rychle, přesto je spojení příliš pomalé. Důležitou informací pro nás v takové chvíli může být, zda je to způsobeno přetížením sítě, či prostě tím, že některá linka na trase je příliš pomalá. Tedy zda se máme o spojení pokusit jindy, nebo od takových pokusů upustit zcela.
Pokud přijmeme notoricky známou základní myšlenku komunikace (nejen počítačové), že její rychlost je dána nejužším místem, je řešení výše uvedeného problému jednoduché. Najít nejpomalejší linku na trase. To se však jednoduše řekne a hůře dělá. Údaje o přenosové rychlosti linek v drtivé většině případů nikde nevydolujeme, takže nezbývá nic jiného než tuto hodnotu změřit. Znovu – idea jednoduchá, provedení těžké až nemožné.
Nejprve je nutno si uvědomit, co máme k měření vlastně k dispozici. Není toho mnoho, pouze dva jednoduché údaje, které shrneme pod již vžité názvy ping a traceroute. Tedy možnost protokolu ICMP zvanou ECHO_REQUEST, která umožňuje poslat libovolnému stroji s vlastní IP adresou paket jisté velikosti a ten má „povinnost“ poslat nám tento zpátky. Z tohoto procesu lze získat dvě důležité informace – velikost námi poslaného paketu a dobu od jeho odeslání k jeho opětovnému přijetí. Traceroute pak vyžívá údaje TTL (time to live), který určuje životnost paketu. Při každém průchodu paketu přes některý uzel tento sníží hodnotu TTL o jedničku. V případě nulové hodnoty TTL pak dochází k odeslání chybového zprávy o velikosti 56 bytů. Zvyšováním hodnoty TTL od jedničky výše lze tedy postupně získat síťové adresy všech uzlů na trase.
Výzbroj již máme pohromadě, je však dobré říci hned zpočátku, že tyto údaje nemusí být vždy zcela přesné a někdy nemusí být ani dostupné. Problémy způsobují různé firewally, NAT atd., které filtrují provoz, případně počítače přes ně připojené vůbec nemají veřejné IP adresy. Druhou věcí je základní nepřesnost těchto údajů. Některé uzly např. nemusí snižovat hodnotu TTL, takže se při hledání vůbec neobjeví. Mnohem důležitější problém je však spojen s nastavením routerů. Častým způsobem útoků je přetěžování právě pomocí paketů ICMP, proto je obvyklé, že zpracování ICMP požadavků má velmi nízkou prioritu. To přináší pochopitelně neblahý vliv na celé měření. Ještě více nepříjemná je však vlastnost směrování na Internetu, kdy není vůbec zaručeno, že pakety putují v obou směrech po té samé trase.
Existují dvě základní metody měření přenosové rychlosti spojení, a to s využitím buď jednotlivých paketů či jejich dvojic. Aby nedošlo k zmatení, co chceme vlastně měřit – nejužší místo na trase. Později si ukážeme, že se naše metoda dá použít na více obecný případ.
Technika měření prostřednictvím přenosu jednoduchého paketu využívá základního poznatku, že rychlejší linka potřebuje na přenos (je zde myšlen fyzický přenos bez čekání ve frontě) paketu méně času než linka pomalejší. V ideálním případě by tak přenosová rychlost linky měla jít spočítat na základě velikosti paketu, doby jeho přenosu a konstanty zpoždění. To je způsobeno fyzikálními vlivy (ať je linka seberychlejší, data budou tam a zpět putovat maximálně tak rychle jako světlo) a zpracováním údajů při směrování atd. Zdánlivě jsme si příliš nepomohli, jak zjistit ono zpoždění? Odpověď je jednoduchá, vezmeme paket s minimální velikostí a změříme dobu jeho putování, tu prohlásíme za hledanou konstantu (přesněji: určíme konstantu z přímky, viz dále). To můžeme provést, protože samotný přenos malého počtu dat je proveden v zanedbatelném čase, naměřená hodnota je tedy skutečně ono zpoždění. Poté provedeme měření pro paket o velikosti např. 1500 bytů (vetší nemá smysl zkoušet, protože bývají při přenosu děleny) a spočítáme rychlost, všechny potřebné údaje máme.
Reálná situace nám však není tak úplně nakloněna. Často se stane, že paket musí čekat ve frontě a tím je pochopitelně takto jednoduché řešení značně ohroženo. Tento problém se však dá obejít – vyzkoušíme poslat několik paketů a jako směrodatnou vezmeme minimální časovou hodnotu pro příslušnou velikost paketu. Předpokládáme, že se nám tedy alespoň jednou podařilo nečekat ve frontě či se tomuto případu přiblížit. Abychom měli lepší představu o tom, jak vypadají podklady pro naše zkoumání, podívejme se na následující obrázek znázorňující graficky výsledek popsané metody:
Je vidět, že podstatným údajem je přímka, kterou můžeme proložit přes jednotlivé minimální hodnoty časů pro příslušné velikosti paketů. Ze sklonu lze vyčíst přenosovou rychlost linky, čím rychleji roste, tím je linka pomalejší. Pochopitelně, reálně vypadají hodnoty trochu jinak a vzniká problém s tím, jak proložit přímku, ale to je problém čistě technického charakteru (ve skutečnosti je otázka proložení křivky velmi podstatná). Další problém vzniká u velmi rychlých linek, zde je již rozdíl v přenosu malých i velkých paketů tak nízký, že přímka je téměř rovnoběžná s osou. Z toho také vyplývá, že měření je přesnější u pomalých linek.
Druhou základní metodou měření je technika využívající zajímavého triku. Jeho první výskyt se datuje do roku 1993, kdy jím Bolot měřil rychlost linky mezi USA a Francií. Nejlépe ji asi osvětluje následující obrázek:
Podstatou je vyslání dvou identických paketů těsně za sebou. V místě s nižší přenosovou rychlostí dojde k tomu, že se zvětší doba pro jejich přenos, pokud poté následuje rychlá linka, vytvoří se mezi nimi zpoždění, protože první paket je již celý odesílán po další lince, zatímco druhý stále ještě putuje úzkým místem. Z časového rozdílu, který vznikne od přijetí prvního paketu do přijetí druhého pak lze jednoduše spočítat přenosovou rychlost.
Je důležité si uvědomit, že tentokrát se nemusíme starat o konstantu zpoždění, protože ta je pro oba pakety stejná a vyruší se při počítání rozdílu. Problém samozřejmě vzniká, pokud se ve frontě mezi oba pakety dostanou jiná data, tím se pochopitelně rozdíl uměle zvětší.
Uvedli jsme si základní triky pro měření nejužšího místa na přenosové trase. Samozřejmě, jde pouze o hlavní myšlenky, jejich technická realizace, tak aby dávaly použitelné výsledky, vyžaduje mnoho drobných i podstatnějších vylepšení. Využívá se teoretických i praktických poznatků, silnou roli hraje statistika. Důležitou a za zmínku stojící myšlenkou je, že lze tento postup zobecnit, a tedy neurčovat pouze rychlost nejužšího místa na trase, ale rychlost všech linek jednotlivě. Nejprve provedeme pozorování na první lince (tedy spoje vedoucího z našeho počítače do nejbližšího uzlu). Pokud používáme první z popsaných metod, tak při zjišťování charakteristiky druhé linky odečteme od výsledků hodnoty získané z charakteristiky první linky, tedy její konstantu zpoždění a dobu na přenos příslušně velkého paketu spočítanou ze zjištěné rychlosti. Takto postupujeme dále. Je dobré si uvědomit, že pro další počítání není důležité, zda dříve naměřené hodnoty jsou přesnou přenosovou rychlostí linky, ale především, zda vyjadřují přesnou charakteristiku linky za daných okolností a při daném způsobu měření – obě hodnoty totiž mohou být odlišné!
Podíváme-li se na konkrétní implementace, tak pokud je autorovi známo, jsou všechny kvalitní produkty určeny výhradně pro UNIXové platformy. Je to dáno tím, že jde spíše o výsledky akademických výzkumů a nikoliv komerční aplikace. Asi nejlepší je pathchar, který má i řadu klonů jako clink či pchar. Jeho pomocí lze získat charakteristiku celé přenosové trasy. Nevýhodou je nutnost pracovat s velkým počtem vzorků, což pochopitelně prodlužuje dobu potřebnou pro měření, odměnou jsou však velmi kvalitní výsledky. Pro určování nejužšího místa trasy slouží např. kvalitní sprobe. Z dalších produktů podobného zaměření bych jmenoval např. nettimer, iperf, netperf, nettest, nttcp, pathrate či treno.
Zatím jsme se zabývali prakticky pouze teorií, o patologických případech jsme se zmiňovali zpravidla z důvodu možnosti prezentovat jejich řešení. Jsou však problémy, jejichž řešení je velmi obtížné či zcela nemožné. Je jasné, že např. linka OC-3 (155 Mb/s) se bude při měření projevovat jako OC-1, protože OC-3 je vlastně spojení tří linek OC-1. Paket se však přenáší vždy pouze po jedné z nich, takže zjištěná rychlost bude třetinová. Jenže stejnou rychlost vrátí i test linky OC-12, OC-48 či OC-192, které jsou mnohonásobně rychlejší. Problematickou kapitolou jsou také u nás dosti populární bezdrátové sítě a jiná nestandardní řešení (z hlediska našeho částečně idealizovaného Internetu). Problémů je však pochopitelně mnohem více.
Na závěr se podívejme na jeden z kvalitních výsledků pathcharu, kde je možno získat i porovnání se skutečnými hodnotami:
Pokud jde o současný vývoj teoretických i praktických výzkumů v dané oblasti, pracuje se na několika dílčích problémech. Pochopitelně největšímu zájmu se těší principiální snaha dosáhnout co možná nejpřesnější výsledků s minimálním počtem testování, tedy vytvořit přesnou a přitom rychlou utilitu – to se totiž zatím zcela nepodařilo.
