IP

Univerzita Karlova v Praze Matematicko-fyzikální fakulta

BAKALÁŘSKÁ PRÁCE

Petr Musil Vliv asymetrie na efektivnost TCP/IP Katedra softwarového inţenýrství

Vedoucí bakalářské práce: RNDr. Ing. Jiří Peterka Studijní program: Informatika, Správa počítačových systémů

2008

Poděkování Velmi děkuji svému vedoucímu bakalářské práce za jeho cenné rady a připomínky, které mi pomohli rozmyslet, zpracovat a napsat tuto práci. Děkuji také knihovně Matematicko-fyzikální fakulty, která mi obstarala studijní literaturu.

Prohlašuji, ţe jsem svoji bakalářskou práci napsal samostatně a výhradně s pouţitím citovaných pramenů. Souhlasím se zapůjčováním i zveřejňováním práce. V Moravských Budějovicích dne 3. srpna 2009 Petr Musil

2

Obsah 1.

Úvod, motivace a průvodce po bakalářské práci ...........................................6

2.

Problematika asymetrie ...................................................................................7

3.

2.1

Co se myslí asymetrií ................................................................................7

2.2

Připojení k internetu a asymetrie ..............................................................7

2.3

Asymetrie v rukou marketingu .................................................................8

Posouzení jednotlivých protokolů .................................................................10 3.1

Zdůvodnění výběru protokolů .................................................................10

3.1.1 3.1.2 3.1.3

Dělení a popis protokolů ovlivnitelných asymetrií ..........................10 Vrstva síťového rozhraní .................................................................10 Vrstva síťová ....................................................................................11

3.1.4 Vrstva transportní.............................................................................11 3.1.5 Vrstva aplikační ...............................................................................11 3.1.6 Ethernet ............................................................................................12 3.2 TCP .........................................................................................................12 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.4 3.3

HTTP, FTP a další ..................................................................................20

3.3.1 3.3.2 3.3.3 4.

Popis fungování ...............................................................................12 Popis segmentu ................................................................................13 Kontrola toku ...................................................................................15 Kontrola zahlcení .............................................................................16 Časovače v TCP ...............................................................................18 Spočítání nákladů .............................................................................18 HTTP metody, hlavičky, spojení .....................................................20 Rozpočet HTTP ...............................................................................21 FTP a jeho datová rozvaha ...............................................................22

Empirické ověření teoretických závěrů ........................................................24 4.1

Způsob a podoba měření .........................................................................24

4.1.1

Co se měří a proč .............................................................................24 3

4.1.2 Jak se měří........................................................................................25 4.2 Popis testovacího prostředí .....................................................................24 4.2.1 Skripty a jejich činnost.....................................................................26 4.2.2 Postup zjišťování výsledků ..............................................................27 4.2.3 Problémy s virtuální sítí ...................................................................27 4.3 Závěry a výsledky plynoucí z naměřených hodnot .................................28 4.3.1 4.3.2 4.3.3 4.3.4

Dopad asymetrie ..............................................................................28 Dopad ztrát rámců ............................................................................28 Výsledky v grafech ..........................................................................29 Srovnání dopadů ..............................................................................31

5.

Srovnání s již publikovanými výsledky ........................................................33

6.

Zhodnocení výsledků ......................................................................................34

7.

Obsah CD ........................................................................................................35

Literatura..................................................................................................................36 Přílohy .......................................................................................................................37

4

Název práce: Vliv asymetrie na efektivnost TCP/IP Jméno autora: Petr Musil Katedra (ústav): Katedra softwarového inţenýrství Vedoucí bakalářské práce: RNDr. Ing. Jiří Peterka E-mail vedoucího: [email protected] Abstrakt: Cílem předloţené práce je určit, do jaké míry můţe asymetrie rychlostí přenosové cesty ovlivnit efektivitu protokolů ze skupiny TCP/IP. V práci se nejprve posoudí podle standardu, kterým je protokol definován, jak moc ovlivní maximální vyuţití přenosové kapacity v jednom směru, zatíţení opačného směru přenosové cesty. Následně se provede praktická zkouška. Budou posuzovány nejběţnější a často pouţívané protokoly přenosové a aplikační. Výsledky pak budou porovnány s jiţ existujícími odhady a závěry. Závěrem bude prohlášeno, jaká míra asymetrie je ještě přijatelná, aby bylo moţno vyuţít maximální kapacitu přenosové cesty. Klíčová slova: asymetrie, TCP/IP, ADSL, efektivita

Title: Vliv asymetrie na efektivnost TCP/IP Author: Petr Musil Department: Katedra softwarového inţenýrství Supervisor: RNDr. Ing. Jiří Peterka Supervisor’s e-mail address: [email protected] Abstract: The goal of present work is to determine, how does asymmetry of tranfer path (its transfer rate) influence effectiveness of TCP/IP protocols. Protocol, which is defined by the standard, is judged theoretically at first. How much does maximum exploit of tranfer rate in one direction influence load of the oposite direction of transfer path. The empirical test is made consequently. Application and transmission protocols which are often used are judged. The results are than compared with already publicated guesses and conclusions. There is going to be declared maximum ratio of transfer rates of the transfer path at the end, in condition of fully exploitation of one transfer direction. Keywords: asymmetry, TCP/IP, ADSL, effectiveness

5

Kapitola 1 Úvod, motivace a průvodce po bakalářské práci V současnosti je zcela obvyklé, ţe při připojování k Internetu jsou udávány dvě rychlosti. Jednou rychlostí jsou data přenášena ke koncovému uţivateli a jinou typicky mnohem menší, jsou přenášena od uţivatele. Tato tendence je patrná jak u připojení přes místní smyčku (ADSL, VDSL a jiné), mobilní technologie (EDGE, CDMA, UMTS), tak i přes vedení kabelové televize (EuroDOCSIS). Předmětem této práce je spočítat za pomoci dokumentů RFC (Request for comment), které popisují přenosové protokoly rodiny TCP/IP, jaká velká míra asymetrie uţ přestavuje problém. Lhostejno, zda se jedná o technologii ADSL nebo jinou, zajímají nás pouze poměr rychlostí na linkové vrstvě. Nikoliv technologie vrstvy fyzické. Problémem rozumíme situaci, kdy pro pomalou rychlost spojení směrem od uţivatele – upstream, není moţno zcela vyuţít rychlost směrem k uţivateli – downstream. V následující kapitole bude popsán problém asymetrie zevrubněji. Posléze provedeme vlastní teoretickou, čili početní, analýzu. Na závěr budou uvedeny výsledky empirického měření a srovnání mých výsledků a závěrů s těmi, které uţ byly dříve publikovány.

6

Kapitola 2 Problematika asymetrie 2.1 Co se myslí asymetrií V této práci se bude asymetrií rozumět nestejná nominální rychlost při přenosu dat směrem od koncového bodu do sítě Internet a směrem ke koncovému bodu na úrovni fyzické vrstvy. Mírou asymetrie pak chápeme poměr mezi rychlostmi. Koncovým bodem rozumíme pracovní stanici, pomocí které jsou vyuţívány sluţby Internetu, tj. procházení stránek, sdílení souborů, sledování streamovaného vysílání, přístup k elektronické poště a mnoho dalšího. Důvodem omezení je skutečnost, ţe v dnešním světě se asymetrie přenosové cesty vyskytuje převáţně v připojení koncových uzlů k síti Internet. Převaţující většina uzlů, které jsou k Internetu připojovány vysokorychlostním připojením1, jsou připojovány s ohledem na fakt, ţe se koncový uţivatel chová především jako konzument. Nepotřebuje tolik data odesílat, protoţe neposkytuje ţádné sluţby, jako spíš data přijímat, protoţe sluţby spotřebovává.

2.2 Připojení k Internetu a asymetrie Nejprve krátce k historii ADSL. Prvním standardem, který jej definuje je ANSI T1.413 z American National Standards Institute. První komerční implementace standardu se objevuje v roce 1995. Ten předpokládal, při maximálním vyuţití rychlostí, míru asymetrie 8:1 ve prospěch downlinku (směr ke koncovému bodu). V průběhu doby se vydávání standardů popisující a vylepšující ADSL ujal ITU (International Telecommunication Union) a v současnosti je nejmodernějším ITU 992.5 známý jako ADSL2+, vydán 2003. Ten má stejnou rychlost směrem od uţivatele jako původní ANSI standard. Nicméně míra asymetrie narostla na 24:1 (opět při maximálním vyuţití předpokládaných rychlostí).

1

Dnes ovšem neexistuje konsenzus o tom, jakou přenosovou rychlost má spojení mít, abychom ho

označili jako vysokorychlostní. Pro naše účely budeme uvaţovat definici národní broadbandové strategie. [8]

7

Nejčastější a nejjednodušší fyzické připojení koncových uţivatelů k síti Internet je skrze jiţ existující kabelový rozvod. Nejčastěji se jedná o tzv. místní smyčku, která byla původně zavedena kvůli hlasovým sluţbám – telefonování. Alternativou je připojení přes rozvody kabelové televize nebo řešení bezdrátová. Podíváme-li se krátce na vývoj připojení koncových uzlů a uţivatelů k Internetu, první rozšířenou technikou, která místní smyčku vyuţívá, bylo vytáčené připojení. Modemy vyuţívaly frekvenční pásmo určené pro hovor. Rychlost připojení kolísala podle kvality linky, vzdálenosti od ústředny a dalších vlivů. Jednalo se o symetrické připojení. Následovalo ISDN (Integrated Services Digital Network). Technologie plné digitalizace od účastníka k účastníkovi. Nicméně stále je vyuţívána jen malá část potenciální přenosové kapacity místní smyčky. Rychlost u ISDN byla v běţně dostupné variantě 64 kbps (to je trochu jinak B kanál a taj) v obou směrech. Následují technologie xDSL, vyuţívající vyšší pásmo frekvencí, neţ bylo uţíváno pro běţný hovor. Navíc se zvyšuje míra vyuţití linky a také, u většiny variant, přichází myšlenka asymetrie. Fyzikální limity není moţno u místní smyčky obejít, ale s nástupem ADSL, přichází asymetrie vycházející z předpokladu, ţe není potřeba, aby měl koncový uzel stejný poměr rychlostí na vstupu a výstupu, ale ţe jeden směr je moţné zvýhodnit a tak uţivatelům nabídnout vyšší komfort při práci s Internetem. Z čeho vyplývá tento předpoklad? Za koncovým uzlem jsou typicky uţivatelé, kteří jsou především spotřebiteli nebo konzumenty sluţeb, ale sami ţádná data (videa, hudbu, soubory) neposkytují. Pokud se znevýhodní, z pohledu přenosové rychlosti, směr do Internetu, nemělo by to na uţivatele nijak negativně dopadnout.

2.3 Asymetrie v rukou marketingu Doposud popisovaná asymetrie je definovaná v samotných standardech, které popisují technologie na fyzické vrstvě. Existuje ovšem ještě jeden typ asymetrie. Ta má zdůvodnění pouze v marketingové politice prodejce.

8

Strategie je jednoduchá – větší čísla se lépe propagují a většinu uţivatelů zajímá především to, jak rychle stahují. Ne uţ tolik, jak rychle odesílají data do sítě, protoţe tato rychlost je přímo neomezuje při prohlíţení stránek nebo stahování souborů. Prodává se především rychlost stahování, protoţe právě ta, v očích zákazníka, je nejvíce omezující. Tyto tendence vedly uţ k uvedení nabídky připojení k Internetu s asymetrií 32 : 1 (konkrétně 16 Mbps / 0,5 Mbps) [12].

9

Kapitola 3 Posouzení jednotlivých protokolů Komunikační protokoly se rozdělují podle své činnosti do hierarchického systému vrstev. Kaţdá vrstva obsahuje protokoly, kterými komunikuje se stejnou vrstvou na jiném uzlu. Systém je hierarchický, protoţe vţdy platí, ţe vyšší vrstva vyuţívá sluţeb od niţší vrstvy. Jsou známy dvě dělení, buď do sedmi vrstev podle ISO/OSI, nebo do čtyř vrstev rodiny podle rodiny protokolů TCP/IP. Tato práce poplatná svému názvu bude zkoumat pouze protokoly TCP/IP, proto také bude uvaţovat čtyři vrstvy.

3.1 Zdůvodnění výběru protokolů 3.1.1 Dělení a popis protokolů ovlivnitelných asymetrií Komunikační protokoly, lze dělit podle mnoha různých kritérií. Z pohledu vlivu asymetrie na jejich efektivitu, ale nebudeme posuzovat všechny druhy. Škodlivý vliv asymetrie se můţe projevit jen u těch protokolů, u kterých přenos informací (bytů, zpráv) jedním směrem vynucuje i komunikaci i ve směru opačném. Nemá valný smysl uvaţovat protokoly, které jsou nespojované a nespolehlivé. U nich není důvod k tomu, aby během přenosu probíhala komunikace i opačným směrem. Naopak pokud se jedná o spolehlivý přenos, tak je přinejmenším nutné neustále odesílat protistraně potvrzení o správnosti přijatých dat. V případě, ţe potvrzení nedojde, část dat se posílá znova. V případě spojovaných přenosů je uţ z podstaty věci potřeba navázat spojení. To vyţaduje vzájemnou komunikaci při přechodech mezi různými stavy – minimálně dvěma: spojeno, nespojeno.

3.1.2 Vrstva síťového rozhraní Podívejme se nyní na jednotlivé vrstvy síťové hierarchie rodiny TCP/IP a vyberme z kaţdé protokoly, které budou dále analyzovány. První základní je vrstva síťového rozhraní. Jejím úkolem je jednak přistupovat přímo k fyzickému médiu, přenášejí se pomocí ní jednotlivé bity.

10

Krom toho také zahrnuje úkoly, které náleţí ve ISO/OSI vrstvě linkové, to je především fyzické adresování (ale také kontrolu dat, tvorbu a rozeznávání rámců a další). V této vrstvě nejsou přesně definovány ţádné protokoly. Coţ umoţňuje, aby IP protokol fungoval „nad“ vším (myšlenou jakoukoliv technologií linkové vrstvy). Ve vrstvě síťového rozhraní je například i ADSL a jeho následovníci.

3.1.3 Vrstva síťová Další vrstva v pořadí je síťová. Jejím hlavním úkolem je vytvořit iluzi ploché sítě, ve které platí představa, ţe kaţdé dva uzly si sousedí. Především se jedná o směrování. Omezíme-li se na protokoly TCP/IP, tak do ní patří pouze nespojovaný nespolehlivý IP protokol a protokoly pro správu sítě (Internet Control Message Protocol). Ţádný nevyhovuje dříve předepsaným kritériím výběru.

3.1.4 Vrstva transportní Hlavním úkolem transportní vrstvy je pro vyšší vrstvy skrýt specifické vlastnosti vrstev pod ní. Případně nabídnout vyšší vrstvě – aplikační – poţadovanou kvalitu, kterou niţší vrstvy nenabízí. Transportní vrstvě náleţí v rodině TCP/IP pouze dva protokoly. Nespojovaný nespolehlivý UDP, který analyzován nebude, a spojovaný spolehlivý TCP. Protokol TCP – Transport Control Protocol je nejvyuţívanějším protokolem na Internetu, a proto mu bude věnováno nejvíce prostoru. Existují protokoly, které mají potenciál nahradit TCP, a také patří do transportní vrstvy. Nicméně jejich reálné rozšíření je minimální, a tak nebudou diskutovány. Jedná se především o RSVP, SCTP a DCCP.

3.1.5 Vrstva aplikační Protokoly této vrstvy, pokud mají splnit zadaná kritéria, jsou pouze nad protokolem TCP. V této vrstvě je velké mnoţství různých protokolů zprostředkovávajících celou řadu funkcí. Pro posouzení si vybereme pouze ty nejpouţívanější. Z nich ještě navíc budou vybrány ty, které slouţí k přenosu velkých objemů dat, protoţe právě na nich se případné sníţení efektivity asymetrií projeví z pohledu uţivatele Internetu nejvíce. RTSP, NFS, FTP a HTTP.

11

3.1.6 Ethernet Během dalších úvah a výpočtů se bude uvaţovat na úrovni linkové vrstvy pouze technologie Ethernetu. Jak bylo řečeno výše, asymetrie je problém především přípojek k Internetu a navíc jen koncových uţivatelů. Koncoví uţivatelé mají stanice, které mají síťové karty fungující výhradně na Ethernetu. Budeme uvaţovat pouze dvoubodový nesdílený spoj bez kolizí. Důvodem je to, ţe případné kolize ovlivní oba směry stejnou měrou, a tím efekt vlastní asymetrie sniţují.

3.2 TCP Transport Control Protocol je po protokolu IP (Internet Protocol) základním komunikačním protokolem Internetu. Umoţňuje spolehlivý a spojovaný přenos nad nespolehlivou a nespojovanou sítí. Aplikačním protokolům vytváří iluzi bytové roury, kterou v obou směrech tečou jednotlivé byty. Protokol je detailně popsán v následujících dokumentech RFC 793 (první verze z roku 1981), RFC 1122 (definuje opravy k první verzi) a RFC 1323 (rozšíření pro vyšší výkonnost).

3.2.1 Popis fungování Popsat do detailu fungování celého TCP je naprosto nad rámec této práce. Jedná se totiţ o velmi komplexní a rozsáhlý protokol. Uveďme pouze jeho základní rysy a charakteristiky. TCP je protokol, který nabízí vyšší vrstvě (aplikační) představu obousměrného bytového proudu. Realita je ovšem jiná. Byty jsou ukládány do mezipaměti a odesílány v dávkách, které jsou vkládány do IP datagramu. Aplikace si nicméně můţe vyţádat okamţité odeslání obsahu mezipaměti. Spojení je navazováno mezi dvěma entitami a je identifikováno dvojicí IP adresa a číslo portu odesílatele a stejná dvojice pro příjemce. To umoţňuje, aby v rámci jednoho uzlu (jedné adresy na síťové vrstvě – IP adresy), bylo navázáno několik spojení a tato se dala rozlišit. Při navazování proběhne třífázový hand-shake (čili potřesení si rukou), které vypadá následovně. Ten, kdo ţádá o spojení (klient), vyšle ţádost, kterou příjemce potvrdí. V opačném případě spojení není navázáno. Pokud příjemce ţádosti potvrdí spojení, tak ţádající strana potvrdí příjemci, ţe přijala jeho potvrzení spojení. Aţ tehdy je spojení navázáno a ve stavu, kdy je moţné začít přenášet vlastní data. 12

Jak bylo řečeno výše, TCP je spolehlivý protokol, odesílatel chce mít jistotu, ţe data byla přijata bez chyb. Vyţaduje tedy potvrzení o přijetí. V případě, ţe nepřijde včas, má se za to, ţe data nebyla doručena a přenos se opakuje. Navíc se přejde z kontinuálního potvrzování, kdy se odesílají další data, přestoţe nedávno odeslaná ještě nebyla potvrzena, na potvrzení jednotlivé – respektive po jednom s tzv. pomalým startem. Odešle se segment a čeká se na potvrzení, kdyţ přijde, tak se odešlou dva segmenty a čeká se na potvrzení. Tento exponenciální růst trvá tak dlouho, dokud ho nějaké jiné pravidlo protokolu nezastaví. Ukončení spojení se provádí třífázovým hand-shakem stejně jako navazování. Tento sloţitý systém je aplikován proto, ţe nad stavovým protokolem řeší většinu nestandardních situací, které mohou nastat ať uţ zpomalením, či výpadkem paketu a podobně. Nebudeme v této práci rozebírat dopodrobna všechny situace, které mohou nastat při navazování a ukončování spojení. Pokaţdé se totiţ jedná o pár paketů, coţ je pár stovek bytů. Z pohledu celého přenosu to je často jen zlomek. Podrobně se naopak zastavíme u technik vyuţívaných ve „středním pásmu“, to znamená při přenosu dat.

3.2.2 Popis segmentu Stručně popíšeme, jak vypadá bit po bitu TCP segment, jeho hlavička a datový náklad, který je vloţen do IP paketu, který je v ethernetovém rámci. Příklad je uveden v příloze, jedná se o tabulku číslo jedna. Kde jsou na kaţdém řádku uvedeny tři byty s bitovou granularitou. – preambule rámce podle standardu 802.3 (Ethernet) – MAC (medium access control) adresy příjemce a odesílatele na linkové vrstvě – v dalším poli je délka dat, která rámec obsahuje nebo o typ protokolu, který je nesen rámcem na úrovni síťové vrstvy, to záleţí na konkrétní podverzi ethernetu (v našem případě IP protokol – 80016) – verze IP protokolu (tj 4) – délka hlavičky IP protokolu v násobcích čtyř bytů – další byte identifikuje typ sluţby z pohledu priority dat, poţadavků na zpoţdění, vysoké spolehlivosti – celková délka datagramu v bytech, která zahrnuje hlavičku i data 13

– identifikace pro účely fragmentace, fragmenty stejného datagramu mají tuto hodnotu stejnou – příznaky povolující nebo zakazující fragmentaci, popřípadě určující zda se jedná o poslední fragment – offset fragmentu, který popisuje, kam v datagramu daný fragment patří – time to live – původně hodnota počtu sekund, po které můţe být datagram v síti, kaţdý modul, který datagram zpracovává, musí tuto hodnotu sníţit o jedna a pokud se stane, ţe hodnota tato je nula, datagram musí být zničen – určuje typ protokolu, který je nesen v datagramu (v našem případě 0616) – kontrolní součet hlavičky IP protokolu – zdrojová a cílová IP adresa – další volitelná nastavení, která ovšem nemusí být přítomná a my je nebudeme uvaţovat, protoţe budeme uvaţovat co nejmenší hlavičky, aby podmínky pro přenos dat byly co nejlepší a aby přenos omezovala hlavně asymetrie – zdrojový a cílový port TCP, slouţící k identifikaci sluţeb – sequence number – číslo, které udává pořadí dat segmentu v datovém proudu – acknowledgment number – pokud je nastaven řídící bit ACK, tak udává příští sekvenční číslo, které je očekáváno, ţe bude přijato od protistrany – velikost hlavičky TCP protokolu, udaná v násobcích čtyř bytů – řídící bity (pro nás nemají význam, nebudeme přesněji uvádět) – okénko, které určuje kolik bytů je příjemce ochoten přijmout, odesílatel nesmí odeslat víc neţ je tato hodnota, dokud nedostane od příjemce další segment s novou (aktualizovanou) hodnotou – kontrolní součet TCP hlavičky a textu – ukazatel na data, která jsou označena jako urgentní, počítáno od počátku dat, konkrétního segmentu, nicméně musí být nastaven kontrolní bit URG – volitelné rozšíření nebudeme uvaţovat víc neţ čtyři byty – pak uţ následuje jen kontrolní součet ethernetového rámce a povinná mezera mezi rámci v rozsahu 96 bitů

14

Tabulka 1 – Rozvržení rámce podle standardů (802.3, RFC 791, RFC 793) Bytová pozice 1–3 Preambule ethernetového rámce 4–6 7 znaků 17010 7–9 17110 – konst. 10 – 12 MAC adresa příjemce 13 – 15 16 – 18 MAC adresa odesílatele 19 – 21 Délka nebo Verze IP protokolu Délka IP hlavičky 22 – 24 „EtherType“ Příznak pro QoS 25 – 27 Celková délka hlavičky datagramu Identifikace pro 28 – 30 účely fragmentace Příznak Offset fragmentace TTL – max. počet „hopů“ 31 – 33 Určení protokolu Kontrolní sou34 – 36 čet hlavičky (IP) Cílová IP 37 – 39 adresa Zdrojová 40 – 42 IP adresa 43 – 45 Volby (IP hlavičky) 46 – 48 Zdrojový port (TCP) 49 – 51 Cílový port 52 – 54 Sequence number 55 – 57 Acknowledgment number Velikost TCP Další příznaky přenosu Vyhrazeno 58 – 60 hlavičky 61 – 63 Velikost okénka Kontrolní 64 – 66 součet Ukazatel na „urgentní“ data 67 – 69 Volby TCP (volitelné) 70 – 72

73 – 1522

Vlastní data TCP paketu

1523 – 1525 1526

Kontrolní součet ethernetového rámce

3.2.3 Kontrola toku Nabídka spolehlivého spojení vynucuje vyuţití jistých technik. Jednou ze základních je takzvané okénko. Kaţdý příchozí segment inzeruje pomocí okénka, kolik dat je moţno odeslat, aniţ by odesílatel přijal potvrzení o korektním doručení. 15

Úkolem je ochránit příjemce dat před zahlcením v případě, ţe není schopen přijímat tak rychle (např. různě výkonný odesílatel a příjemce). Nedostane-li odesílatel potvrzení, musí počkat a přestat odesílat data a příjemce dostane čas data zpracovat. Další okénko je evidováno v rámci entity TCP a nikam se neodesílá. Jedná se o okénko zahlcení sítě. Jeho úkolem je ochránit síť před zahlcením způsobeným nadměrným odesíláním dat. Funguje podobně jako předchozí. Nesmí se odeslat více dat bez dodaných potvrzení, neţ umoţňuje okénko. Zabrání se tak odesílání velkých proudů, které sítí neprojdou z důvodů zahlcení. Zatímco okénko inzerované v segmentech, si určuje entita sama na základě aktuální zátěţe, tak okénko zahlcení sítě se určuje pomocí několika různých algoritmů. První dvojice je pomalý start (ve standardech slow start) a vyhnutí se zahlcení (ve standardech congestion avoidance). Tyto se pouţívají při zahájení spojení nebo při výpadku vzniklém vypršením časovače pro znovu odeslání (retransmission timer).

3.2.4 Kontrola zahlcení Hovoříme o dvojici, protoţe do dosaţení hraniční hodnoty, která se průběţně mění, se pouţívá pomalý start a pak nastoupí vyhnutí se zahlcení. Pomalý start začíná buď na okénku zahlcení o velikosti jednoho aţ dvou maximálních segmentů (některá rozšíření počítají aţ čtyř) anebo na příjemcem povolené velikosti, která je udaná v okénku kontroly toku. Záleţí na tom, co je menší. Eviduje se také hraniční hodnota pro pomalý start, která je nastavena volitelně. Nejčastěji jako inzerovaná velikost mezipaměti (okénko kontroly toku) příjemce [6]. Po kaţdém úspěšně potvrzeném segmentu se okénko kontroly zahlcení zvětší právě o maximální velikost segmentu. Algoritmus pokračuje, dokud velikost okénka zahlcení nepřekročí hraniční hodnotu pro pomalý start, potom se pouţívá algoritmus vyhnutí se zahlcení. Tento zvětšuje okénko zahlcení jen jednou za dobu obrátky o nejvýše maximální velikost segmentu, ale jinak o hodnotu velikosti segmentu umocněnou na druhou dělenou aktuální velikostí okénka zahlcení. V případě, ţe pro některý segment vyprší čas, na časovači znovu odeslání nastane výpadek. Pak se algoritmus přepne na pomalý start a rozbíhá se na novo, jen s tím rozdílem, ţe se sníţí hraniční hodnota na polovinu (ne však méně neţ dvojnásobek maximální velikosti segmentu) a okénko zahlcení se nastaví znovu na maximální velikost segmentu.

16

Druhá dvojice jsou algoritmy rychlé znovu-odeslání, rychlá obnova (fast retransmit/fast recovery). Tyto se snaţí eliminovat prodlevu, kdy se při výpadku segmentu čeká na doběhnutí časovače znovu-odeslání, přičemţ příjemce uţ ví, ţe mu data nepřišla v pořadí, ve kterém byla očekávána. Příčinou můţe být jednak výpadek, jednak přeházení pořadí segmentů při přenosu sítí. Algoritmy jsou zaloţeny na tom, ţe pokud taková situace nastane, odešle se zvláštní potvrzení segmentu, který byl očekáván a nedorazil. Pokud odesílatel dostane aspoň tři takové segmenty, tak to povaţuje za výpadek. To je svým způsobem riziko, protoţe se můţe jednat pouze o přeházení segmentů na cestě (proto se čeká tři segmenty, nestačí jen jeden). Stejně jako u předcházejících dvou algoritmů, existuje hraniční velikost okénka, při které dojde k přepnutí na algoritmus vyhnutí se zahlcení. Nicméně ještě před tím, neţ se tak stane, se rozběhne algoritmus rychlé obnovy z výpadku. Nepokračuje se vyuţitím pomalého startu, protoţe je zbytečně „pomalý“. Hraniční hodnota pro pomalý start je nastavena na polovinu současné velikosti okénka zahlcení nejméně však dvojnásobek maximální velikosti segmentu. Okénko zahlcení se nastaví na velikost hraniční hodnoty pro pomalý start plus trojnásobek maximální velikosti segmentu a se zvětšuje se s kaţdým přijatým potvrzením segmentu, který chyběl a byl znovu odeslán. Další potvrzení, ţe tento chybí, znamenají ve skutečnosti to, ţe příjemce jiţ přijal jiné segmenty a má je uloţené v mezipaměti. To aţ do té doby, neţ přijde potvrzení těch dat, která byla poslána těsně před rozhodnutím přejít do stavu rychlé znovu-odeslání. Pak se okénko zahlcení nastaví na hodnotu hraniční pro přechod na pomalý start a TCP se také přepne na tento algoritmus. Je třeba zmínit několik předpokladů pro úspěšné fungování těchto algoritmů. Dodrţovat úzus zpoţděných potvrzení segmentů, tak jak je to uvedeno v [7]. Pokud se bude potvrzovat po větších celcích dat, tak bude méně potvrzení, coţ bude mít negativní dopad na výkon algoritmů, které chrání proti zahlcení. Konkrétně můţeme zmínit pomalejší náběh pomalého startu. Ten by se v krajním případě mohl dostat aţ do stavu, kdy by se okénko zahlcení zvětšilo jen o velikost jednoho maximálního segmentu za dobu obrátky. Coţ odpovídá rychlosti algoritmu vyhnutí se zahlcení (congestion avoidance) v nejlepším případě.

17

3.2.5 Časovače v TCP Persistence timer [11] – Kdyţ příjemce odešle odesílateli potvrzující segment s okénkem kontroly toku s hodnotou nula, odesílatel přestane odesílat. V případě, ţe následný segment s aktualizací okénka nebude doručen, dojde k problému. Obě strany budou čekat na reakci té druhé. Pokud vyprší tento časovač, tak odesílatel pošle příjemci dotaz na potvrzení velikosti okénka kontroly toku. Retransmission timer [10] – V tomto textu časovač znovu-odeslání. Hodnota tohoto časovače je známa jako RTO (retransmission timeout). Slouţí k zajištění doručení dat v případě absence potvrzení segmentu. V případě vypršení časovače se odešlou nejstarší data, která ještě nebyla potvrzena znovu, a zároveň se toto chápe jako výpadek pro účely algoritmů kontroly zahlcení. Velikost RTO se zdvojnásobí (násobení se musí provádět nejméně do hodnoty 60 sekund) a časovač se znovu spustí. Počáteční hodnota RTO by měla být nejméně tři sekundy. Během výpočtů pak nesmí klesnout pod hodnotu jedné sekundy. Standard také vyţaduje pouţití Karnova algoritmu, který říká, ţe se přepočty RTT (round trip time – čas obrátky, tj. doba mezi odesláním segmentu a potvrzení jeho přijetí) nesmí dělat ze segmentů, které byly odeslány víc neţ jednou. Vlastní vzorce pro odhady RTT tady uvádět nebudeme, pro další úvahy to nemá význam. RTO se většinou nastaví RTO = RTT + 4 * O kde O je střední odchylka RTT, respektive její odhad. Pro přesný vztah na výpočet odkazuji na [10]. Keep-alive timer [11][7] – Vyprší-li čas na časovači keep-alive, odešle se prázdný segment a čeká se, zda bude potvrzen. Pokud nepřijde do stanovené doby, povaţuje se spojení za ukončené. Velikost si určuje sama aplikace běţící nad TCP.

3.2.4 Spočítání nákladů Prověřme náklady na upstream a downstream při stahování. Velikost přenášených dat určíme tak, ţe se zaplní právě milion ethernetových rámců. Jeden rámec má podle standardu nejvýše 1526 bytů (viz výše), přičemţ 74 bytů tvoří reţii. Za předpokladu uţití TCP nad IP nad Ethernetem. Jeden milion rámců představuje 1 452 000 000 bytů vlastních dat, coţ je asi 1,35 GiB2. Doba přenosu tolika rámců bude za předpokladu 1 Gbps Ethernetu a při uváţení mezirámcových mezer (těch bude 999 999). Celkem se bude přenášet 1 000 000 x 1526 x 8 + 999 999 x 96 2

Prefixy jsou pouţívány v souladu se standardem IEEE 1541-2002

18

bitů, coţ bude trvat 12,304 sekund. Efektivní rychlost tak bude asi 944,08 Mbps (za předpokladu nulových ztrát a plynulého nepřerušovaného (ţádné kolize nebo nedostatečný výkon systému) přenosu. Zpětný provoz vynucuje v protokolu TCP jednak okénko pro kontrolu toku příjemce. Jeho maximální hodnota je 65 535. Příjemce podle standardu [1] nemůţe nastavit více, takţe jakmile odesílatel odešle data, musí čekat na potvrzení. Pokud se budeme odvolávat na toto omezení, tak po kaţdých 45 rámcích (obsahující 45 x 1452 bytů vlastních dat), které mají maximální velikost, přijde jeden, který má pouze 269 bytů (195 vlastní data a 74 reţie protokolů). Pak uţ musí příjemce odeslat segment s potvrzením o přijetí. Segment je obsaţen v rámci, který nenese ţádná data, neboť potvrzení je součást hlavičky TCP a nemá v sobě obsaţeny různé rozšiřující volby v hlavičkách IP a TCP protokolů, o velikosti 74 bytů. Coţ je prakticky nejmenší moţná velikost rámce, který obsahuje protokoly TCP nad IP. Porovnejme velikost dat přenášených od odesílatele k příjemci a naopak. Od odesílatele jde 45 rámců maximální velikosti a jeden o 269 bytech. K němu jde jedno potvrzení o 74 bytech. To dává asymetrii datového nákladu 931,61 : 1. Toto omezení, tedy zjevně omezením příliš není. Významnějším limitem bude omezení související se správným fungování algoritmů bránících zahlcení. V tomto textu uţ o něm bylo hovořeno (kapitola 3.2.4). Podle obecných vlastností, které má splňovat kaţdá implementace TCP [7], by měla povolovat zpoţděná potvrzení přijatých dat. V případě, ţe ho povoluje, tak musí po kaţdých dvou segmentech o plné velikosti přijít potvrzení a zároveň dvě potvrzení od sebe nesmí být více jak 0,5 sekundy. Stejný poţadavek přináší i [6]. Výpočet pro takový případ vypadá následovně. Dva segmenty o maximální velikosti to jsou dva rámce 1526 bytů kaţdý. Pak příjemce odešle 74 bytový rámec, který nese potvrzení. Coţ představuje asymetrii 41,24 : 1 (1526 x 2 / 74). Je také moţné potvrzovat kaţdý přijatý segment zvlášť, byť to není vynuceno standardem. V takovém případě se asymetrie datových nákladů bude rovnat 20,62 : 1 (1526 / 74). V praxi se ukazuje, ţe entity TCP se pohybují někde mezi těmito dvěma hodnotami. To jest mezi potvrzováním kaţdého segmentu plné velikosti a kaţdého druhého takového segmentu.

19

3.3 HTTP, FTP Běţný uţivatel Internetu se nejčastěji setká se dvěma protokoly. HTTP – Hypertext transfer protocol a FTP – File transfer protocol. Při jejich analýze budeme předpokládat, ţe si uţivatel přeje stáhnout 20 stránek či souborů o velikosti 60 kiB skládajících se z průměrně 40 objektů3.

3.3.1 HTTP metody, hlavičky, spojení Cílem této práce není a ani nemůţe být podrobnější zmapování celého protokolu http, který se ponejvíce vyuţívá při přenosu webovských stránek. Zmíníme a popíšeme tady jen hlavní základy nutné pro sestavení datové rozvahy. Budeme uvaţovat verzi protokolu HTTP 1.1. Tady je důleţité verzi zdůraznit, protoţe tato verze na rozdíl od té předchozí (1.0) umoţňuje tzv. trvalé spojení, a tak uţ není nutné otevírat nové spojení kvůli kaţdému objektu na stránce. Tím se totiţ ušetří na reţii za navazování spojení, na které má asymetrie velký vliv. Příkazy, které odesílá klient serveru, jsou nazývány metody. Je jich definováno osm a my budeme uvaţovat prakticky jen jedinou – GET. Pouţívá se právě k vyţádání souboru od protistrany (typicky serveru). Za metodou GET se odesílá řádek, obsahující doplňující hlavičky, které specifikují některé další podrobnosti (informace o prohlíţeči, autentizační údaje, typy stránek a jazyky, které klient zvládne zpracovat a podobně). Odpovědí mu je řádek se stavem zpracování ţádosti. To je číselný třímístný kód, jenţ můţe být také následován hlavičkami. Budeme předpokládat běţnou situaci, kdy jsou vyuţity při odeslaní ţádosti o stránku hlavičky host (obsahuje DNS jméno serveru), user-agent (popisuje prohlíţeč klienta), accept a pod.(přijímaný jazyk, typy obsahu, kódové stránky), keep-alive (jak dlouho se má udrţovat spojení), typ spojení a cookie. Taková hlavička zabere přibliţně 650 bytů (uvedená hodnota je přibliţná, protoţe hlavička můţe nabývat různého počtu různě velkých polí). Hlavičku odpovědi serveru naopak záměrně zanedbáme, abychom simulovali nejhorší situaci z pohledu asymetrie a jejího vlivu. Poté celá odpověď serveru zabere pouze 17 bytů v nákladové části HTTP protokolu. Konkrétně se jedná o řádek „HTTP/1.1 200 OK\r\n“.

3

Zjištěna programem wget, kterým byla staţena část portálu zive.cz. Jednalo se asi o 80 stránek.

20

3.3.2 Rozpočet HTTP Nejprve je potřeba navázat spojení TCP. To se provede pro kaţdou stránku zvlášť (tj. dvacetkrát). Navázání a ukončení spojení představuje ve směru do sítě zátěţ dva prázdné segmenty při navazování (2 x 74 bytů) a dva segmenty při ukončení. V opačném směru, tedy ze sítě, je to při ukončování dva segmenty a při navazování jeden. Celkově se jedná o 296 bytů na upstreamu a 222 na downstreamu. Kaţdá stránka má 40 objektů a kaţdý tento objekt bude vyţádán metodou GET a po přenesení potvrzen stavovou zprávou s kódem 200, který indikuje korektní přenesení. Segment s metodou GET má kolem 650 bytů (plus reţie 74 bytů), bude přenesen 40 krát tj. (650 + 74) x 40 = 28 960 Stavová zpráva o 17 bytech (plus 74 reţie) je přidána k datům od odesílatele. Navíc první segment od odesílatele, nejen ţe nese stavovou zprávu, ale navíc potvrzuje přijetí segmentu s metodou GET. Zbytek zátěţe tvoří data odesílaná podle pravidel TCP. Můţeme počítat s tím, ţe jednotlivé díly stránky mají průměrnou velikost v řádu kiB. Jsou proto přeneseny v jednom nebo dvou plných segmentech. Uvaţujeme-li stránku o 40 částech, které se takto stahují, tak celkový počet segmentů bude 40 aţ 80. Předpokládejme pro jednoduchost plné segmenty, těch bude 43 (aby přenesly 60 kiB). V takovém případě se můţe v segmentu posílaném k serveru s dotazem na další data (metoda GET) potvrdit i sekvence právě přijatá. Celkově pak tato část zátěţe představuje náklad pouze na downstreamu a to oněch 60 kiB dat plus reţie (43 krát 74 bytů) sečteno se stavovou zprávou (kód 200) o 17 bytech, která bude poslána 40 krát. 60 x 1024 + 43 x 74 + 40 x 17 = 65 302 Podtrţeno sečteno, na upstreamu jsme napočítali 296 bytů na navázání spojení a 28 960 na poţadavky na stránky. Celkem 29 256 bytů. Downstream vypadá následovně 222 na spojení a 65 302 přenosu vlastních dat, která navíc obsahují i potvrzení segmentů odeslaných příjemcem (obsahující metodu GET). Celkem 65 524 bytů. Tady nám vychází asymetrie 2,24 : 1!

21

3.3.3 FTP a jeho datová rozvaha FTP je určen pro přenos a správu souborů mezi počítači. Umoţňuje na architektuře klient server posílat sobory na server, mazat je, číst nebo měnit uspořádání adresářů a podobně. Navíc do jisté míry dává moţnosti autentizace při přístupu. Nicméně platí pro něj to stejné, co u HTTP. Z celé a široké škály moţností budeme diskutovat pouze ty, které se přímo týkají přesunu souborů ze serveru na klienta. Základní fungování je podobné jako u HTTP. Pošleme na server nějakou ţádost v podobě příkazu a on nám vrátí zprávu se stavem. Buď ţe je to v pořádku nebo je potřeba dodat další informace nebo o chybách. Co je rozdílem, je vyuţití portů. Jsou tu v podstatě navázána dvě spojení. Jedno na port serveru číslo 21 slouţí k posílání příkazů. K přenosu dat pak slouţí spojení na port 20, který otevře klient – pak se jedná o aktivní reţim. Pokud to není moţné, třeba kvůli firewallu, pošle se poţadavek server, který otevře port (pouţívají se ty, které nejsou vyhrazené pro konkrétní účel) a pošle ho klientovi. Ten s ním naváţe spojení přes svůj vybraný port. Pro naše účely je prakticky jedno, o který druh spojení se jedná. Provedeme podobný rozpočet jako u HTTP. S tím rozdílem, ţe se dokument nebude dělit a jeho velikost zůstane stejná 60 kiB. Rozebereme si komunikaci. Nejprve se navazuje TCP spojení, to přestavuje dva segmenty na upstream a jeden na downstream (všechny o 74 bytech). Pak server pošle odpověď s uvítacím kódem 220, coţ je 114 bytů na vrub downstreamu. Následuje 90 bytový rámec s identifikačními údaji (příkaz USER), který odesílá klient. Nyní můţe přijít potvrzení segmentu, a pak výzva k zaslání hesla. Nebo se dá potvrzení připojit k výzvě (331 Please specify the password\r\n). Ta představuje 108 bytů na směr ke klientovi. Velikosti rámců, které tady uvádíme, jsou dané součtem velikosti nejmenšího rámce obsahujícího protokoly IP a TCP tj 74 bytů s vlastní zprávou od serveru nebo klienta. Následuje příkaz PASS a specifikace hesla (85 bytů). Pak přijde potvrzení hesla (uvaţujeme anonymní přístup, kaţdé heslo je přijato). Hned po té přijde klientovi potvrzení o úspěšném přihlášení (94 bytů). Na to pošle klient ţádost o pasivní reţim (příkaz PASV), to je 80 bytů. Odpovědí je příslušný port, na který se má navazovat komunikace se serverem (124 bytů – 74 reţie a 50 příslušné hodnoty). Znovu se naváţe spojení jen na jiných portech. Pak přijde výzva klienta o poţadovaný soubor příkazem RETR (velikost je různá, záleţí na délce cesty, zvolme 60 bytů a reţie tj. 134 bytů). Odpověď serveru s sebou můţe nést potvrzení 22

předchozího segmentu. Je v ní psáno, ţe se zahajuje přenos (180 bytů). Vlastní přenos pak probíhá na dohodnutých portech. Řídí se výše uvedeným pravidlem po dvou plných segmentech jedno potvrzení. Podtrţeno sečteno. 768 bytů se musí přenést od serveru (včetně ukončení spojení), neţ započne vlastní přenos dat, který je proveden 42 plnými segmenty a jedním 456 bytovým. Coţ představuje na linkové vrstvě 1526 x 42 + (456 + 74) = 64 622 spolu s reţií FTP před započetím přenosu 65 390 bytů. Upstream bude vypadat z hlediska rozpočtu dat následovně. 833 je reţie klienta FTP. Na vlastní přenos půjde 23 potvrzení přijatých dat o 74 bytech. Celkem na linkové vrstvě (uţ včetně reţie) 833 + 74 x 23 = 2 535 Dostáváme asymetrii 25,49 : 1.

23

Kapitola 4 Empirické ověření teoretických závěrů 4.1 Způsob a podoba měření 4.1.1 Co se měří a proč Byly vybrány dva základní protokoly z rodiny TCP/IP, které jsou jednak spojované a jednak velmi vyuţívané. Především domácími uţivateli, jichţ především se asymetrie týká. Jedná se o protokoly HTTP a FTP. Měření má ukázat jaký dopad na tyto protokoly bude mít asymetrie přenosových rychlostí v závislosti na ztrátovosti4 paketů. Budeme uvaţovat šest různých asymetrií 1:1 (ţádná asymetrie), 4:1, 16:1, 32:1, 64:1 a 128:1. Za předpokladu pěti různých ztrátovostí. Důvodem, proč se starat o ztrátovost, je obecná vlastnost přenosových cest. Jen ideální spojení má nulovou ztrátovost. V reálném případě je ztráta paketů způsobena celou řadou různých faktorů. Jedná se o fyzické příčiny přeslechy na přenosovém médiu, rušení a podobně. Jinou příčinou je veliká rozlehlost a sloţitost sítě Internet. Ta způsobuje, ţe na jednotlivých směrovačích nebo serverech můţe nahodile docházet ke krátkodobým vysokým zatíţením, která vedou k výraznému prodlouţení doby přenesení, resp. vystavení paketu. To ovšem některé protokoly (TCP) za jistých okolností (při překročení časového limitu na doručení segmentu) mohou chápat jako výpadek. Je faktem, ţe ztrátovost paketů při připojení k Internetu je velmi proměnlivá. Hlavní příčinou je vysoká rychlost změn zátěţe a jejich nahodilost, která souvisí s velkou komplexností Internetu, jak bylo zmíněno výše. Z těchto důvodů bylo při měření pouţito několika různých ztrátovostí paketů, aby se dalo posoudit, jak velkou měrou ovlivní kvalitu přenosu na asymetrické přenosové cestě.

4

Je počet paketů, které nejsou doručeny včas (záleţí na protokolu). Jednotkou jsou procenta

24

Pro měření bylo pouţito prostředí virtualizované sítě. Virtuální síť přináší do měření řadu výhod. Jedná se o „laboratorní“ prostředí, ve kterém neexistují ţádné rušivé jevy, jako komunikace dalších uţivatelů na síti, zpomalení směrovačů vlivem zátěţe, nekvalitní přenosové cesty a podobně. V konečném důsledku by pak tyto jevy mohly vést ke zkreslení výsledku měření.

4.1.2 Jak se měří Měření probíhalo ve virtualizačním prostředí vmWare Workstation. Tento produkt umoţňuje vytvářet virtuální počítače, a poté je přidávat do takzvaných týmů. V rámci těchto týmů pak existují virtuální LAN segmenty, do kterých lze připojovat síťové karty virtuálních počítačů. Kaţdý segment má svoje jméno, přenosovou rychlost a nastavení, které udává, jaká je pravděpodobnost, ţe dojde ke ztrátě paketu, čili ztrátovosti rámců. Nejprve bylo v rámci jednoho týmu vytvořeno šest virtuálních počítačů. Jeden bude slouţit jako server a ostatní budou klienti. Zbylých pět počítačů je připojeno k serveru skrze síťovou kartu, která je připojena do síťového segmentu s příslušnou ztrátovostí. Na serveru je pět síťových karet, které jsou také připojeny k síťovým segmentům. Jinými slovy, kaţdý počítač má vlastní síť, kterou se připojuje k serveru a kaţdá tato síť má vlastní ztrátovost. Na serveru byly náhodným generátorem vytvořeny soubory o nominálních velikostech dvacet, osmnáct, devět a pět megabytů dat. Různé velikosti byly vybrány proto, ţe jak stoupá asymetrie a ztrátovost, dá se očekávat pokles přenosové rychlosti. Cíl je takový, aby kaţdé stahování trvalo přibliţně stejně dlouho, pak jsou všechny výsledky statisticky stejně relevantní. Počítač, který byl označen jako server, běţel na operačním systému na bázi linuxu. Konkrétně se jednalo o Ubutnu 9.04 „Jaunty Jackalope“ 32bit. verze [2]. Ovšem s jednodušším grafickým rozhraním Xfce, z důvodu niţší náročnosti na výkon procesoru a pamětí. Na serveru nainstalován systém Apache verze 2.2, který bude implementovat protokol http a stahování data nad ním. Apache byl vybrán, protoţe je nejčastěji nasazeným webovým serverem na Internetu [3]. Jako implementace ftp protokolu byl zvolen produkt vsftpd. Celým jménem Very secure FTP daemon [4].

25

Počítače, které slouţily jako klientské stanice, byly osazeny stejným operačním systémem jako server. Kromě standardního softwarového vybavení, na ně byl přidán pouze program Wonder Shaper [5]. Ten totiţ umoţňuje z příkazové řádky nastavit rychlost přenosu dat z počítače a do počítače. Jeho pouţití ovšem způsobuje nepříjemnou komplikaci, totiţ prudký pokles propustnosti, a to aţ na hodnoty kolem 35 kbps. Coţ ovšem není velký problém, ba naopak nízká rychlost stahování minimálně zatíţí procesor a zbytek systému. Výsledky měření tak nebudou ovlivněny nedostatečným výkonem. Po celou dobu měření se zátěţ procesoru virtuálních počítačů pohybovala v jednotkách procent. Vlastní stahování dat probíhalo s pouţitím utility wget, která umoţňuje stahovat jak skrze protokol FTP, tak i HTTP.

4.2 Průběh měření 4.2.1 Skripty a jejich činnost Bylo vytvořeno několik skriptů. Všechny najdete na přiloţeném CD. Virtuální počítače byly pojmenovány dívčími jmény. Jméno serveru je Samantha. Skript Samantha_netw_skript.sh slouţí k nasta-vení síťových rozhraní (především IP adresy, masky sítí a směrovací záznamy), vypnutí DHCP klienta a ke spuštění webového serveru. Další skripty provádí to samé, s výjimkou spouštění Apache, na klientských stanicích. Jejich názvy jsou ve tvaru jméno počítače a _netw_skript.sh. Hlavní skript, který provádí vlastní stahování souborů, se jmenuje prostě skript.sh. Ten nastaví postupně všech šest asymetrií pomocí programu Wonder Shaper. Pro kaţdou asymetrii dvacetkrát stáhne soubor určené velikosti nejdříve pomocí protokolu http pak ftp. Zároveň průběţně zpracovává logy, které vytváří program wget, do podoby pro snadnější čtení naměřených rychlostí. Staţené soubory jsou skriptem průběţně mazány. Velikosti souborů pro jednotlivé asymetrie byly určeny následovně – pro 1:1 se stahoval 20 MB velký soubor stejně jako pro 4:1, pro 16:1 a 32:1 je 18 MB, pro 64:1 je 9 MB a konečně pro 128:1 je 5 MB.

26

Určení bylo provedeno zkušebním staţením za zadaných podmínek (ztrátovost a asymetrie) s důrazem na to, aby všechna měření trvala přibliţně stejně dlouho. Výsledek je tak statisticky spravedlivější. Kdyby totiţ stahování při vysokých asymetriích trvalo například desetkrát déle, mnohem snáz by se nahodilosti síťového provozu rozmělnily.

4.2.2 Postup zjišťování výsledků Výsledky, které program wget vydává, odpovídají průměrné hodnotě rychlosti stahování, která je vypočtena dle jednoduchého vztahu velikost stahovaného souboru vydělená časem, po který měření probíhalo. Pro kaţdou asymetrii byla provedena série dvaceti měření, při kterých proběhlo stáhnutí souborů o velikostech uvedených výše. Z těchto dvaceti měření se spočítal aritmetický průměr, jenţ byl uveden do tabulky, a stejně tak i rozptyl. Tabulka je uvedena jako příloha této práce.

4.2.3 Problémy s virtuální sítí Zastavme se ještě u vlastního virtualizačního nástroje vmWare. Nastavení ztrátovosti paketů, pro něj není zřejmě prioritou, protoţe fungovalo poměrně podivně. Po nastavení hodnot, bylo třeba podle návodu restartovat virtuální stroje. Nicméně i po opakovaném restartování někdy naměřené hodnoty ztrátovosti (měřeno utilitou ping) neodpovídaly zadání. Proto je součástí prováděcího skriptu i průběţné měření této hodnoty. Během stahování souborů byla hodnota ztrátovosti stabilní, přes nepřetrţitou několika denní síťovou aktivitu. Nicméně hodnoty, které byly nastaveny – 0%, 0,2%, 1%, 2% a 5% se podařilo dosáhnout jen z části. Respektive měření prokázalo 1,97% místo dvou a 4,86% místo pěti. Ostatní hodnoty vyšly s přesností na dvě desetinná místa.

27

4.3 Závěry a výsledky plynoucí z naměřených hodnot 4.3.1 Dopad asymetrie Uvaţme nejprve dopad samotné asymetrie a odmysleme si ztráty paketů. Představme si ideální přenosové médium. Pokud nastavíme nominální přenosovou rychlost směrem k uţivateli i od uţivatele 35 kBps, poté je průměrná naměřená efektivní rychlost 32,83 kBps při pouţití protokolu FTP. Pro protokol HTTP je to 32,89. Nominální kapacita je vyuţita na 94 %. Zbytek jde na vrub reţie spojovaného a spolehlivého přenosu. Při poměru downstream ku upstream 4:1 jsou hodnoty efektivní rychlosti také velmi dobré. Nominální kapacita je vyuţita opět asi na 94 %. S poměrem 16:1 přichází první sníţení rychlosti. To je ale pouze tabulkové. Maximální rychlost byla Wonder Shaperem omezena i na downstreamu. Důvodem bylo fakt, ţe na vstupu přijímá pouze celá čísla. Poměry asymetrie by nicméně vyţadovaly pouţití racionálních čísel. Proto pro všechny asymetrie od 16:1 platí, ţe nominální rychlost na downstreamu je omezena na 256 kbps. Faktické vyuţití maximální přenosové rychlosti při poměru 16:1 je opět 94 %. Skutečný zlom nastává u poměru 32:1. Tady dojde k jistému poklesu vyuţití přenosového média. U protokolu HTTP na 80 % a stejně tak u FTP. Další nárůst asymetrie vede k prudkému poklesu vyuţití nominální rychlosti na přenosové cestě směrem ze sítě. U 64:1 je to kolem 53 % a u 128:1 uţ pouze 36 % u HTTP a 33 % u FTP. Poprvé se projevuje významnější rozdíl mezi protokoly aţ u takto vysoké asymetrie. Při niţších poměrech vychází HTTP i FTP z pohledu dopadu asymetrie rovnocenně.

4.3.2 Dopad ztrát rámců Vliv, který má na kvalitu přenosu mnoţství ztracených paketů, nelze posoudit tak přímočaře jako to bylo učiněno v předchozím odstavci. Je potřeba odečíst vliv asymetrie. Budeme tedy porovnávat jen odpovídající asymetrie v různých ztrátovostech.

28

Jednoduše lze říci, ţe pokud se paket nedoručí, je potřeba znovu provést odeslání. Efektivní rychlost následně klesá. Souvisí to s reţií, která je nezbytná ke znovu odeslání, popřípadě změně fungování protokolu (především se tím myslí přechod na jednotlivé potvrzování v TCP). Hlavním problém je, jak uţ bylo zmíněno dříve v textu, ţe reţie spojená se opakovaným odesíláním, výzvami a podobně, je rovnoměrněji rozdělená mezi směr ze sítě a do sítě. Coţ způsobí větší citlivost přenosu na asymetrii.

Představme si situaci, kdy na lince není ţádná asymetrie. Z naměřených hodnot vyplývá, ţe při nízkém počtu ztracených paketů (0,2%), je situace stejná jako při nulové ztrátě. Oba vycházejí prakticky na stejno. Rozdíl mezi nimi je na úrovni statistické chyby jedeno procento. S rostoucím počtem ztracených paketů (1%) se situace mírně mění. Oproti situaci beze ztrát klesne efektivní rychlost o šest procentních bodů. Nejvyšší měřená ztrátovost, kdy téměř kaţdý dvacátý paket nedorazil, vedla k poklesu efektivní rychlosti aţ na úroveň 68%, coţ je sníţení oproti bezeztrátové lince o téměř 28%.

4.3.3 Výsledky v grafech

Graf 1

29

Graf 2

Podíl efektivní rychlosti na nominální je zachycen v následujících grafech.

Graf 3

30

Graf 4

4.3.4 Srovnání dopadů V nejhorší situaci, kdy se téměř kaţdý dvacátý rámec na síti nepřenesl a poměr rychlostí do sítě a ze sítě dosáhl 128:1, se srazila efektivní rychlost na pouhou ani ne pětinu (18,9 %) nominální rychlosti downstreamu. Z uvedených hodnot vyplývá, ţe asymetrie škodí efektivní rychlosti poměrově víc neţ běţná nekvalita spoje. Zatímco uţ 32:1, coţ je dnes pro zákazníka dosaţitelná hodnota, sníţila efektivní rychlost téměř o sedminu. Stejný pokles daný ztrátovostí je patrný aţ u dvou aţ tří jednotek procent nepřenesených paketů. Přičemţ v domácí bezdrátové síti na standardu 802.11g při nezarušeném kanálu a signálu označeném jako dobrý, tato hodnota nepřesáhne jedno procento. O drátových spojích ani nemluvě. Z druhé strany ovšem musíme připustit, ţe při velkém počtu ztracených rámců se stírají rozdíly mezi jednotlivými poměry rychlostí. Pokud uváţíme oněch asi 5% ztrát. Tak se efektivní rychlost u asymetrií od 1:1 aţ po 32:1 neliší. Vyuţití nominální rychlosti se potom pohybuje kolem 70 %. Jak u protokolu ftp, tak i http.

31

Na základě měření můţeme prohlásit, ţe asymetrie přenosové cesty má od určité hodnoty velmi negativní vliv na vyuţití kapacity downstreamu. V případě velmi nekvalitního spojení se ale vliv asymetrie, pokud není velmi vysoká (128:1), neprojeví. Za rozumnou míru asymetrie můţeme povaţovat ještě hodnotu 16:1. Podrobné výsledky měření jsou uvedeny v příloze. Tabulka 2 a 3.

32

Kapitola 5 Srovnání s již publikovanými výsledky K problematice asymetrie se vztahuje například dokument Balakrishnana Request for comments 3449. TCP Performance Implications of Network Path Asymmetry. Čili dopady asymetrie síťových cest na výkonnost TCP. Autorský kolektiv se v jeho první části zaměřil především na konkrétní příčiny, které vedou ke sníţení výkonu přenosu na linkách s vysokou asymetrií. V další části dokumentu jsou navrhovaná řešení. Tato práce a [15] se rozcházejí především v tom, ţe my hledáme odpověď na to, kolik – jak velká asymetrie představuje problém, nicméně řešení uţ není naším cílem. Na druhou stranu v [15] není kvantitativní stránka věci řešena. Autoři neuvádějí, jaká míra asymetrie vede k jakému poklesu výkonu. Jako hlavní příčiny poklesu výkonu TCP na asymetrických linkách byly shledány především problémy při práci s potvrzováním větších dávek segmentů jediným potvrzením. Tato praktika totiţ nepříznivě ovlivňuje výkon algoritmů kontroly zahlcení, jak bylo zmiňováno výše (3.2.4). Navíc podle Balakrishnana zvyšuje pravděpodobnost výpadku, protoţe s většími dávkami rámců se směrovače hůře vypořádají. Mezi navrhovaná řešení tohoto problému patří podle [15] například komprese hlaviček (RFC 3150, 3135, 1144) nicméně pro tunelování nebo pro rozšířené volby TCP (třeba šifrování IPsec) je to nepouţitelné. Navíc na linkách špatné kvality vykazuje prudký pokles výkonu. Aspekty řešení tohoto problému nebudeme dále rozebírat, protoţe nenalézáme srovnání, neboť řešením problému asymetrie se tato práce nezabývá.

33

Kapitola 6 Zhodnocení výsledků Na předchozích stránkách bylo prokázáno, ţe asymetrie rychlostí přenosových cest způsobuje pokles efektivní rychlosti. Uvaţujeme-li uţivatelské protokoly HTTP a FTP, je tento pokles patrný od hodnoty 32 : 1, jak naznačují praktická měření. Teoretický výpočet na základně dokumentů definujících protokoly TCP ukazuje, ţe asymetrie v hodnotách od 23 : 1 aţ do 46 : 1 se nemusí, ale můţe projevit. Záleţí to na konkrétní strategii entity, která implementuje vlastní protokol. Kolik segmentů maximální velikosti bude potvrzováno, není totiţ určeno na dolní hranici. Jak bylo řečeno výše, standard vyţaduje, aby to bylo po dvou. Pokud ovšem je to po jednom, ničemu to neškodí. Jen to zhoršuje dopad asymetrie, ale o tom, zda linka je nebo není asymetrická, nemá TCP entita informace. Nemá odkud je mít. Proto hovoříme o intervalu, ve kterém se chyba projeví. Při zkoumání protokolů aplikačních se ukazuje, ţe problém asymetrie je velmi výrazný především na malých souborech v případě FTP. Pro HTTP platí obdobné pozorování. Čím více prvků o malé velikosti na stránce je, tím horší dopad asymetrie bude mít. Konkrétní výpočet pro poměrně dosti členitou stránku ukázal, ţe i zdánlivě mírná asymetrie kolem 3 : 1, můţe způsobovat při prohlíţení problémy. Musíme na tomto místě vyslovit jistou pochybnost. Rychlost stáhnutí malých stránek, za předpokladu vyuţití vysokorychlostního připojení podle definice, je dost velká na to, aby i zhoršení způsobené asymetrií, které by i násobně rychlost zmenšilo, nebylo pozorováno, protoţe omezujícím faktorem mohou být rychlost klientské stanice, server a podobně. Z výše uvedených důvodů vyvozuji, ţe skutečné subjektivně pozorovatelné zpomalení nastane při mírách asymetrie vyšších neţ 23 : 1.

34

Obsah CD Na CD, které je přiloţené k této práci najdete jednak všechny bashové skripty, kterými bylo měření provedeno, jednak kompletní výsledky měření programem wget. Stejně tak i tabulku na zpracování výsledků. Vliv asymetrie na efektivnost TCP.pdf – vlastní bakalářská práce ve formátu

pdf Vliv asymetrie na efektivnost TCP.doc – vlastní bakalářská práce ve formátu

doc Stahování na asymetrickém spoji.xls – tabulka pro zpracování dat měření Samantha_netw_skript.sh – skript, který nastavuje síťování na serveru

poskytujícím data pro stahování JménoPočítače-ztrátavprocentech ztráta – sloţka s výsledky konkrétních

virtuálních strojů, ztráta v procentech udává poměrný počet nedoručených rámců asym_míraasymetrie_velikostMB.txt – obsahuje výstupy programu wget pro

kaţdé jednotlivé měření na dané míře asymetrie, hodnota velikost pak udává velikost stahovaného souboru asym_míraasymetrie_výtah.txt – obsahuje zkrácený výstup, který souţí ke

snadnějšímu zápisu do tabulky pořadí_ping_test.txt – během stahování byly rovnoměrně prováděny testy

utilitou ping, aby byla zjištěna momentální ztrátovost skript.sh – kaţdý stroj obsahoval tento skript, řídí stahování jak přes protokol

FTP tak i HTTP JménoPočítače_netw_skript.sh – nastavuje síťové rozhraní pro kaţdý

konkrétní počítač

35

Literatura [1] RFC 791 [2] http://www.ubuntu.cz/ [3] http://news.netcraft.com/archives/web_server_survey.html (dne 21. 6. 2009) [4] http://vsftpd.beasts.org/ [5] http://lartc.org/wondershaper/ [6] RFC 2581 [7] RFC 1122 [8] http://web.mvcr.cz/archiv2008/micr/files/2060/nbbs.pdf [9] Standard IEEE 802.3 [10] RFC 2988 [11] Tanenbaum S. Andrew (2003): Computer Networks. Prentice Hall PTR [12] http://www.cz.o2.com/osobni/internet/internet_a_email-vysokorychlostni_pripojeniinternet_plus-internet_plus.html

[13] RFC 2616 [14] RFC 959 [15] RFC 3449

36

Přílohy Tabulka 2 – Hodnoty naměřené ve virtuální síti na protokolu http. Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl

Ztracených paketů 0,0% Ztracených paketů 0,2% 1:1 4:1 16:1 32:1 64:1 128:1 1:1 4:1 16:1 32:1 64:1 128:1 31,9 32,9 29,9 25,2 15,5 5,5 32,2 32,2 29,6 25,6 15,4 5,5 32,9 32,9 29,9 25,4 16,8 11,3 32,5 32,4 29,7 25,3 17,7 10,9 32,9 32,9 30,0 25,6 15,6 10,8 32,5 32,4 29,6 25,4 16,8 10,9 32,9 32,9 30,0 25,3 15,9 10,5 32,3 32,5 29,7 25,3 17,0 10,3 32,9 32,9 30,1 25,1 14,8 10,7 32,6 32,3 29,8 25,7 17,4 10,6 32,9 32,9 30,0 25,2 16,2 10,7 32,4 32,4 29,7 25,4 16,7 11,0 32,4 32,9 30,1 25,4 15,4 11,2 32,4 32,3 29,9 25,2 16,9 11,2 32,9 32,9 30,0 25,9 16,5 10,6 32,5 32,3 29,9 25,3 17,2 10,4 32,9 32,9 30,0 24,8 16,8 10,1 32,5 32,4 29,6 25,0 17,2 10,0 32,9 32,9 30,0 25,4 16,1 10,8 32,4 32,3 29,8 25,4 17,3 5,6 32,9 32,9 30,0 25,3 17,3 10,0 32,4 32,3 29,7 25,2 16,8 10,6 32,9 32,9 29,9 25,5 17,4 11,3 32,4 32,4 29,7 25,0 17,0 10,4 32,6 32,9 30,0 26,1 16,8 10,3 32,4 32,3 29,8 25,3 16,7 10,9 32,6 32,9 30,0 25,5 16,1 10,7 32,2 32,1 29,8 25,5 17,2 11,1 32,9 32,9 30,0 25,3 17,6 11,4 32,4 32,4 29,0 25,5 17,0 10,1 32,9 32,9 30,0 25,8 17,5 10,5 32,3 32,3 29,8 25,1 16,7 10,2 32,9 32,9 30,0 25,6 17,0 10,9 32,4 32,2 29,8 25,5 16,7 10,1 32,9 32,9 30,1 25,5 16,2 11,1 32,2 32,5 29,8 25,3 16,1 10,9 32,9 32,9 29,9 25,5 14,1 11,1 32,2 32,4 29,6 25,5 16,4 10,4 32,7 32,8 30,0 25,5 16,7 11,3 32,1 32,5 29,8 25,5 16,8 10,3 35,0 35,0 32,0 32,0 32,0 32,0 35,0 35,0 32,0 32,0 32,0 32,0 32,89 33,00 30,09 25,76 17,06 11,56 32,37 32,35 29,71 25,35 16,85 10,07 0,06 0,00 0,00 0,08 0,80 1,48 0,02 0,01 0,03 0,03 0,23 2,42 Ztracených paketů 1,0% Ztracených paketů 2,0% 1:1 4:1 16:1 32:1 64:1 128:1 1:1 4:1 16:1 32:1 64:1 128:1 30,4 30,9 28,9 25,3 14,7 5,5 29,1 29,2 26,3 25,3 14,2 5,5 31,1 31,3 28,5 25,2 15,7 9,2 29,7 29,5 27,5 24,5 15,4 7,8 31,0 30,9 28,9 24,9 15,9 9,0 29,5 29,0 27,5 24,9 14,1 8,2 30,7 31,1 28,5 25,1 16,1 9,2 29,0 29,6 27,8 24,5 15,5 8,2 30,7 30,9 28,6 24,0 15,3 8,8 29,8 28,2 27,1 24,7 16,0 8,5 30,9 30,7 28,7 24,6 15,7 9,9 29,1 29,6 27,4 24,5 15,6 8,0 30,9 31,1 28,2 25,2 16,4 8,9 29,5 28,8 27,2 24,5 15,4 7,9 31,4 30,9 28,6 24,4 16,2 8,8 29,8 29,2 27,3 24,8 15,1 8,1 31,2 30,9 28,8 25,1 16,4 8,9 29,3 28,9 27,2 24,7 15,8 8,0 30,9 30,9 28,4 25,2 16,8 9,7 28,7 28,7 26,9 24,9 15,7 7,7 31,0 30,9 29,1 24,8 17,0 9,3 29,2 29,0 27,8 24,7 15,6 8,1 30,9 31,2 28,5 25,1 15,3 9,0 29,7 29,6 27,9 24,5 15,8 8,1 31,1 30,6 28,8 25,3 15,9 8,8 29,4 28,9 27,2 24,4 15,4 7,8 30,9 30,9 28,7 25,1 16,7 8,9 29,5 29,1 27,5 24,7 15,6 8,5 31,0 30,8 28,3 25,1 15,6 9,2 29,7 29,2 27,5 24,5 15,4 7,9 30,8 31,0 28,9 25,0 15,6 9,5 28,8 29,4 27,0 24,5 15,6 7,8 31,2 31,1 28,5 25,2 16,6 9,1 29,4 29,3 27,4 22,9 15,1 7,9 30,8 30,7 28,9 24,5 16,3 9,5 28,7 29,3 27,7 25,4 14,7 8,2 31,1 30,9 29,1 24,9 16,8 9,1 28,0 28,7 27,4 24,5 15,8 7,8 30,8 30,9 28,6 24,7 16,8 8,7 28,9 29,3 27,8 25,0 15,4 8,6 35,0 35,0 32,0 32,0 32,0 32,0 35,0 35,0 32,0 32,0 32,0 32,0 30,94 30,93 28,68 24,94 16,09 8,95 29,24 29,13 27,37 24,62 15,36 7,93 0,05 0,03 0,06 0,11 0,36 0,74 0,20 0,12 0,13 0,23 0,24 0,37

37

Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl

Ztracených paketů 4,9% 1:1 4:1 16:1 32:1 64:1 128:1 24,5 24,7 22,8 24,0 11,4 5,3 23,4 22,8 22,6 22,7 11,6 5,7 21,3 25,3 23,7 22,5 13,4 5,8 24,1 23,0 22,4 22,9 12,6 6,3 24,4 24,1 23,5 23,1 13,3 5,4 24,4 23,5 23,2 23,0 12,8 5,5 23,8 23,2 22,9 22,9 12,8 6,3 23,3 24,7 23,5 23,1 12,4 6,3 24,4 22,6 23,6 23,8 13,6 6,1 24,1 24,5 23,1 22,8 13,4 6,2 23,5 23,8 22,6 22,7 13,0 6,5 23,3 22,3 22,8 22,9 12,7 6,3 23,9 19,9 17,8 23,1 13,2 6,2 23,2 24,6 23,3 23,4 12,0 6,2 24,3 23,9 21,8 22,8 13,1 5,8 23,6 25,5 22,1 24,3 11,9 6,4 23,0 23,4 23,4 22,4 13,4 6,0 24,0 24,0 23,7 22,5 12,5 5,6 23,9 23,3 22,6 22,3 13,4 6,3 24,0 24,3 23,4 23,1 13,0 6,8 35,0 35,0 32,0 32,0 32,0 32,0 23,72 23,67 22,74 23,02 12,78 6,04 0,50 1,47 1,56 0,26 0,39 0,16

Tabulka 3 – Hodnoty naměřené ve virtuální síti na protokolu ftp. Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl

Ztracených paketů 0,0% Ztracených paketů 0,2% 1:1 4:1 16:1 32:1 64:1 128:1 1:1 4:1 16:1 32:1 64:1 128:1 32,4 32,7 29,8 25,6 16,7 5,5 31,8 32,3 29,6 25,3 17,4 10,2 32,9 32,9 30,0 25,6 16,1 10,8 32,1 32,5 29,8 25,6 16,7 11,1 32,8 32,9 30,1 25,7 15,7 10,9 32,0 32,3 29,8 25,4 16,7 10,6 32,8 32,9 30,1 25,6 16,7 10,1 32,5 32,1 29,8 25,8 16,5 11,1 32,9 32,9 30,1 25,5 16,9 10,5 32,4 32,2 29,9 25,6 17,1 10,9 32,9 32,9 30,1 25,7 16,7 11,3 32,3 32,5 29,8 25,4 17,3 9,6 32,9 32,9 30,1 25,6 17,6 10,3 32,5 32,2 29,8 25,1 17,2 10,3 32,9 32,9 30,1 25,9 17,4 11,2 32,2 32,4 29,8 25,5 17,1 11,3 32,9 32,9 30,1 25,7 16,9 11,2 32,5 32,1 29,8 25,7 16,3 10,4 32,9 32,9 30,1 25,8 17,8 11,3 32,3 32,4 29,8 26,1 17,1 11,5 32,9 32,6 30,1 25,6 17,2 11,4 32,3 32,3 29,7 25,3 16,4 9,4 32,9 32,9 30,0 25,9 17,4 11,4 32,5 32,4 29,7 25,4 17,0 10,6 32,9 32,6 30,1 25,7 16,5 11,0 32,3 31,8 29,4 25,4 16,3 10,4 32,7 32,2 30,0 25,4 16,0 10,8 32,3 32,3 29,6 25,7 17,0 11,1 32,9 32,7 29,8 25,5 15,1 10,7 32,3 32,1 29,9 25,3 17,2 10,8 32,9 32,9 29,8 25,4 16,0 10,9 32,3 32,3 29,8 25,3 16,6 10,3 32,9 32,9 30,0 25,3 16,3 10,5 32,4 32,3 29,8 24,9 16,6 10,8 32,4 32,9 30,1 25,1 17,9 10,2 32,1 32,5 29,4 25,4 17,3 11,2 32,9 32,9 30,1 25,3 17,2 10,7 32,5 32,5 29,8 25,5 17,4 10,5 32,9 32,9 30,1 25,5 17,3 11,1 32,3 32,4 29,8 25,4 17,6 8,4 35,0 35,0 32,0 32,0 32,0 32,0 35,0 35,0 32,0 32,0 32,0 32,0 32,83 32,82 30,04 25,57 16,77 10,59 32,30 32,30 29,74 25,46 16,94 10,53 0,02 0,03 0,01 0,04 0,52 1,49 0,03 0,03 0,02 0,06 0,15 0,50

38

Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl Číslo měření 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Max Průměr Rozptyl

Ztracených paketů 1,0% Ztracených paketů 2,0% 1:1 4:1 16:1 32:1 64:1 128:1 1:1 4:1 16:1 32:1 64:1 128:1 30,6 30,6 28,8 24,6 16,5 9,0 29,2 29,2 27,2 24,3 15,4 8,1 30,9 30,5 28,9 25,4 17,1 8,6 29,3 28,8 26,8 25,2 15,4 8,2 31,1 31,1 28,8 25,5 16,0 8,7 28,9 29,2 26,9 24,4 15,0 7,7 31,1 31,4 29,0 25,1 15,9 9,0 28,9 28,8 27,8 25,1 14,7 7,5 31,2 31,0 28,8 25,2 15,8 8,2 29,1 28,8 27,2 24,8 14,7 7,4 30,9 30,9 28,6 24,9 16,4 9,0 29,6 29,3 26,9 25,4 15,0 7,8 31,1 31,3 28,7 25,3 16,8 9,4 28,6 29,7 27,3 25,1 15,1 8,1 31,1 30,6 28,9 25,2 16,1 9,2 29,6 29,3 27,4 24,8 15,0 8,0 30,7 30,8 28,5 25,5 15,5 9,5 29,2 29,3 27,2 24,9 15,0 7,9 31,1 30,2 28,5 25,1 16,0 9,0 29,1 29,2 27,1 24,4 15,4 8,3 31,2 31,0 28,9 24,8 16,6 8,6 29,3 29,4 27,9 24,9 14,7 8,2 31,4 30,8 28,3 25,2 15,9 9,4 29,2 29,5 26,7 25,1 15,3 8,0 31,0 31,1 29,3 25,2 14,4 8,8 28,9 29,5 25,5 24,4 15,2 8,2 31,0 30,6 28,6 25,0 16,2 8,8 29,0 29,3 27,3 24,9 15,0 8,2 31,1 30,8 28,8 24,8 15,2 8,9 28,9 29,3 27,8 25,4 15,2 7,8 30,4 31,2 28,3 25,4 16,0 8,6 28,5 28,9 26,8 24,6 15,0 8,0 31,2 31,3 28,7 25,0 14,8 9,2 28,8 29,6 27,3 25,0 15,5 8,5 31,1 30,9 28,4 25,5 16,1 9,8 29,3 29,7 26,8 24,9 14,8 7,6 31,0 31,1 28,7 25,8 14,9 9,2 28,5 29,4 26,8 25,3 15,1 8,6 30,9 31,0 29,0 24,8 15,6 9,7 29,3 29,1 27,7 25,3 15,6 7,8 35,0 35,0 32,0 32,0 32,0 32,0 35,0 35,0 32,0 32,0 32,0 32,0 31,01 30,91 28,73 25,17 15,89 9,03 29,06 29,27 27,12 24,91 15,11 8,00 0,05 0,09 0,06 0,09 0,44 0,15 0,09 0,07 0,27 0,11 0,07 0,09 Ztracených paketů 4,9% 1:1 4:1 16:1 32:1 64:1 128:1 23,4 24,5 23,9 23,5 12,5 6,3 24,8 25,4 22,3 23,6 12,8 6,6 25,2 24,8 23,2 23,4 12,0 6,1 24,4 23,6 22,8 23,2 12,8 5,8 24,1 22,7 22,7 24,2 13,6 5,4 23,4 24,2 23,2 22,9 11,2 5,9 24,8 23,0 23,3 24,3 12,3 6,1 23,2 24,8 22,3 23,9 13,2 6,4 24,6 23,8 22,4 23,3 12,9 6,2 24,6 23,2 23,2 23,0 13,0 5,3 24,1 24,0 20,5 22,3 13,5 6,2 22,3 22,7 23,3 22,9 13,1 6,0 24,1 24,3 23,2 23,1 13,3 6,2 24,5 23,7 21,5 23,4 14,0 6,3 24,0 23,7 23,6 23,3 13,3 6,5 24,5 24,1 22,0 21,9 13,0 5,5 24,0 24,4 23,5 23,9 13,1 5,9 22,6 24,4 20,8 24,4 11,5 5,9 24,2 23,6 22,3 23,9 12,1 6,1 23,0 24,5 21,1 23,0 13,4 6,2 35,0 35,0 32,0 32,0 32,0 32,0 23,99 23,97 22,56 23,37 12,83 6,04 0,57 0,49 0,89 0,38 0,48 0,12

39