VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA ELEKTROTECHNIKY A KOMUNIKACNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
METODY MĚŘENÍ PŘENOSOVÝCH RYCHLOSTÍ BENCHMARKING METHODOLOGY OF NETWORK CONNECTIONS
BAKALÁŘSKÁ PRÁCE BACHELOR’S THESIS
AUTOR PRÁCE
JAN FRANC
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR
BRNO 2008
DOC. ING. VÁCLAV ZEMAN, PH.D.
ÊÇÍÑÕW ËXÛÒS ÌÛÝØÒ×ÝÕW Ê ÞÎÒT Ú¿µ«´¬¿ »´»µ¬®±¬»½¸²·µ§ ¿ µ±³«²·µ¿8²3½¸ ¬»½¸²±´±¹·3 F-¬¿ª ¬»´»µ±³«²·µ¿½3
Þ¿µ¿´?(-µ? °®?½» ¾¿µ¿´?(-µ# -¬«¼·¶²3 ±¾±® Ì»´»·²º±®³¿¬·µ¿
ͬ«¼»²¬æ α8²3µæ
×Üæ éèîëí ßµ¿¼»³·½µ# ®±µæ îððéñîððè
Ú®¿²½ Ö¿² í
Ò_ÆÛÊ ÌWÓßÌËæ
Ó»¬±¼§ ³4(»²3 °(»²±-±ª#½¸ ®§½¸´±-¬3 ÐÑÕÇÒÇ ÐÎÑ ÊÇÐÎßÝÑÊ_ÒSæ Ю±-¬«¼«¶¬» ¿ °±°·†¬» ¦?µ´¿¼²3 ³»¬±¼§ ³4(»²3 °(»²±-±ª#½¸ °¿®¿³»¬®' ¼¿¬±ª#½¸ -3¬3 ¦¿´±‚»²#½¸ ²¿ ×Ðò Ò¿ ¦?µ´¿¼4 «ª»¼»²7¸± ®±¦¾±®« ²¿ª®¸²4¬» ©»¾±ª±« ¿°´·µ¿½»ô µ¬»®? «³±‚²3 ±®·»²¬¿8²4 ¦¶·†ƒ±ª¿¬ ¦?µ´¿¼²3 °(»²±-±ª7 °¿®¿³»¬®§ °(·°±¶»²3 ¼± ײ¬»®²»¬«ò ß°´·µ¿½· µ±²½·°«¶¬» ¬¿µô ¿¾§ ¾§´¿ «‚·ª¿¬»´-µ§ °(3ª4¬·ª? ¾»¦ ²«¬²±-¬· ·²-¬¿´±ª¿¬ µ´·»²¬¿ ²¿ -¬®¿²4 «‚·ª¿¬»´»ò ÜÑÐÑÎËXÛÒ_ Ô×ÌÛÎßÌËÎßæ Åïà ڻ·¾»´ô Éò Û²½§µ´±°»¼·» °±83¬¿8±ª#½¸ -3¬3ô ݱ³°«¬»® Ю»--ô ïççêô ×ÍÞÒ èðóèëèçêóêéóîò Åîà ޮ¿¼²»®ô Íò ÎÚÝ îëìì ó Þ»²½¸³¿®µ·²¹ Ó»¬¸±¼±´±¹§ º±® Ò»¬©±®µ ײ¬»®½±²²»½¬ Ü»ª·½»-ô ×ÛÌÚô ïçççò Ì»®³3² ¦¿¼?²3æ
ïïòîòîððè
Ì»®³3² ±¼»ª¦¼?²3æ
Ê»¼±«½3 °®?½»æ
¼±½ò ײ¹ò Ê?½´¿ª Æ»³¿²ô иòÜò
ìòêòîððè
°®±ºò ײ¹ò Õ¿³·´ Ê®¾¿ô Ýͽò °(»¼-»¼¿ ±¾±®±ª7 ®¿¼§
ËÐÑÆÑÎÒTÒSæ ß«¬±® ¾¿µ¿´?(-µ7 °®?½» ²»-³3 °(· ª§¬ª?(»²3 ¾¿µ¿´?(-µ7 °®?½» °±®«†·¬ ¿«¬±®-µ? °®?ª» ¬(»¬3½¸ ±-±¾ô ¦»¶³7²¿ ²»-³3 ¦¿-¿¸±ª¿¬ ²»¼±ª±´»²#³ ¦°'-±¾»³ ¼± ½·¦3½¸ ¿«¬±®-µ#½¸ °®?ª ±-±¾²±-¬²3½¸ ¿ ³«-3 -· ¾#¬ °´²4 ª4¼±³ ²?-´»¼µ' °±®«†»²3 «-¬¿²±ª»²3 y ïï ¿ ²?-´»¼«¶3½3½¸ ¿«¬±®-µ7¸± ¦?µ±²¿ 8ò ïîïñîððð ;òô ª8»¬²4 ³±‚²#½¸ ¬®»-¬²4°®?ª²3½¸ ¼'-´»¼µ' ª§°´#ª¿¶3½3½¸ ¦ «-¬¿²±ª»²3 y ïëî ¬®»-¬²3¸± ¦?µ±²¿ 8ò ïìðñïçêï ;ò
Ô×ÝÛÒXÒS ÍÓÔÑËÊß ÐÑÍÕÇÌÑÊßÒ_ Õ ÊCÕÑÒË ÐÎ_Êß Ë’SÌ –ÕÑÔÒS ÜSÔÑ «¦¿ª(»²? ³»¦· -³´«ª²3³· -¬®¿²¿³·æ ïò п²ñ°¿²3 Ö³7²± ¿ °(3¶³»²3æ
Ö¿² Ú®¿²½
Þ§¬»³æ
б¼ Õ±¦·²½»³ îîéçô éëêêïô α‚²±ª °±¼ ο¼¸±†¬4³
Ò¿®±¦»²ñ¿ ø¼¿¬«³ ¿ ³3-¬±÷æ
ïðòêòïçèêô Ê¿´¿†-µ7 Ó»¦·(383
ø¼?´» ¶»² þ¿«¬±®þ÷ ¿ îò ʧ-±µ7 «8»²3 ¬»½¸²·½µ7 ª Þ®²4 Ú¿µ«´¬¿ »´»µ¬®±¬»½¸²·µ§ ¿ µ±³«²·µ¿8²3½¸ ¬»½¸²±´±¹·3 -» -3¼´»³ F¼±´²3 îììñëíô êðîðð Þ®²± î ¶»¶3³‚ ¶³7²»³ ¶»¼²? ²¿ ¦?µ´¿¼4 °3-»³²7¸± °±ª4(»²3 ¼4µ¿²»³ º¿µ«´¬§æ °®±ºò ײ¹ò Õ¿³·´ Ê®¾¿ô Ýͽò ø¼?´» ¶»² þ²¿¾§ª¿¬»´þ÷
X´?²»µ ï Í°»½·º·µ¿½» †µ±´²3¸± ¼3´¿ ïò Ð(»¼³4¬»³ ¬7¬± -³´±«ª§ ¶» ª§-±µ±†µ±´-µ? µª¿´·º·µ¿8²3 °®?½» øÊ–ÕÐ÷æ ¼·-»®¬¿8²3 °®?½» ¼·°´±³±ª? °®?½» ¾¿µ¿´?(-µ? °®?½» ¶·²? °®?½»ô ¶»¶3‚ ¼®«¸ ¶» -°»½·º·µ±ª?² ¶¿µ± òòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòò ø¼?´» ¶»² Ê–ÕÐ ²»¾± ¼3´±÷ Ò?¦»ª Ê–ÕÐæ
Ó»¬±¼§ ³4(»²3 °(»²±-±ª#½¸ ®§½¸´±-¬3
Ê»¼±«½3ñ†µ±´·¬»´ Ê–ÕÐæ
¼±½ò ײ¹ò Ê?½´¿ª Æ»³¿²ô иòÜò
F-¬¿ªæ
F-¬¿ª ¬»´»µ±³«²·µ¿½3
Ü¿¬«³ ±¾¸¿¶±¾§ Ê–ÕÐæ òòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòò Ê–ÕÐ ±¼»ª¦¼¿´ ¿«¬±® ²¿¾§ª¿¬»´· ªæ ¬·†¬4²7 º±®³4
ó °±8»¬ »¨»³°´?(' ï
»´»µ¬®±²·½µ7 º±®³4
ó °±8»¬ »¨»³°´?(' ï
îò ß«¬±® °®±¸´¿†«¶»ô ‚» ª§¬ª±(·´ -¿³±-¬¿¬²±« ª´¿-¬²3 ¬ª'®83 8·²²±-¬3 ¼3´± -¸±®¿ °±°-¿²7 ¿ -°»½·º·µ±ª¿²7ò ß«¬±® ¼?´» °®±¸´¿†«¶»ô ‚» °(· ¦°®¿½±ª?ª?²3 ¼3´¿ -» -?³ ²»¼±-¬¿´ ¼± ®±¦°±®« - ¿«¬±®-µ#³ ¦?µ±²»³ ¿ °(»¼°·-§ -±«ª·-»¶3½3³· ¿ ‚» ¶» ¼3´± ¼3´»³ °'ª±¼²3³ò íò Ü3´± ¶» ½¸®?²4²± ¶¿µ± ¼3´± ¼´» ¿«¬±®-µ7¸± ¦?µ±²¿ ª °´¿¬²7³ ¦²4²3ò
ìò ß«¬±® °±¬ª®¦«¶»ô ‚» ´·-¬·²²? ¿ »´»µ¬®±²·½µ? ª»®¦» ¼3´¿ ¶» ·¼»²¬·½µ?ò
X´?²»µ î ˼4´»²3 ´·½»²8²3¸± ±°®?ª²4²3 ïò ß«¬±® ¬±«¬± -³´±«ª±« °±-µ§¬«¶» ²¿¾§ª¿¬»´· ±°®?ª²4²3 ø´·½»²½·÷ µ ª#µ±²« °®?ª¿ «ª»¼»²7 ¼3´± ²»ª#¼4´»8²4 «‚3¬ô ¿®½¸·ª±ª¿¬ ¿ ¦°(3-¬«°²·¬ µ» -¬«¼·¶²3³ô ª#«µ±ª#³ ¿ ª#¦µ«³²#³ &8»´'³ ª8»¬²4 °±(·¦±ª¿²3 ª#°·-'ô ±°·-' ¿ ®±¦³²±‚»²·²ò îò Ô·½»²½» ¶» °±-µ§¬±ª?²¿ ½»´±-ª4¬±ª4ô °®± ½»´±« ¼±¾« ¬®ª?²3 ¿«¬±®-µ#½¸ ¿ ³¿¶»¬µ±ª#½¸ °®?ª µ ¼3´«ò íò ß«¬±® -±«¸´¿-3 -» ¦ª»(»¶²4²3³ ¼3´¿ ª ¼¿¬¿¾?¦· °(3-¬«°²7 ª ³»¦·²?®±¼²3 -3¬· ·¸²»¼ °± «¦¿ª(»²3 ¬7¬± -³´±«ª§ ï ®±µ °± «¦¿ª(»²3 ¬7¬± -³´±«ª§ í ®±µ§ °± «¦¿ª(»²3 ¬7¬± -³´±«ª§ ë ´»¬ °± «¦¿ª(»²3 ¬7¬± -³´±«ª§ ïð ´»¬ °± «¦¿ª(»²3 ¬7¬± -³´±«ª§ ø¦ ¼'ª±¼« «¬¿¶»²3 ª ²4³ ±¾-¿‚»²#½¸ ·²º±®³¿½3÷ ìò Ò»ª#¼4´»8²7 ¦ª»(»¶.±ª?²3 ¼3´¿ ²¿¾§ª¿¬»´»³ ª -±«´¿¼« - «-¬¿²±ª»²3³ y ìé¾ ¦?µ±²¿ 8ò ïïïñïççè ;òô ª °´¿¬²7³ ¦²4²3ô ²»ª§‚¿¼«¶» ´·½»²½· ¿ ²¿¾§ª¿¬»´ ¶» µ ²4³« °±ª·²»² ¿ ±°®?ª²4² ¦» ¦?µ±²¿ò
X´?²»µ í Æ?ª4®»8²? «-¬¿²±ª»²3 ïò ͳ´±«ª¿ ¶» -»°-?²¿ ª» ¬(»½¸ ª§¸±¬±ª»²3½¸ - °´¿¬²±-¬3 ±®·¹·²?´«ô °(·8»³‚ °± ¶»¼²±³ ª§¸±¬±ª»²3 ±¾¼®‚3 ¿«¬±® ¿ ²¿¾§ª¿¬»´ô ¼¿´†3 ª§¸±¬±ª»²3 ¶» ª´±‚»²± ¼± Ê–ÕÐò îò ʦ¬¿¸§ ³»¦· -³´«ª²3³· -¬®¿²¿³· ª¦²·µ´7 ¿ ²»«°®¿ª»²7 ¬±«¬± -³´±«ª±« -» (3¼3 ¿«¬±®-µ#³ ¦?µ±²»³ô ±¾8¿²-µ#³ ¦?µ±²3µ»³ô ª§-±µ±†µ±´-µ#³ ¦?µ±²»³ô ¦?µ±²»³ ± ¿®½¸·ª²·½¬ª3ô ª °´¿¬²7³ ¦²4²3 ¿ °±°(ò ¼¿´†3³· °®?ª²3³· °(»¼°·-§ò íò Ô·½»²8²3 -³´±«ª¿ ¾§´¿ «¦¿ª(»²¿ ²¿ ¦?µ´¿¼4 -ª±¾±¼²7 ¿ °®¿ª7 ª'´» -³´«ª²3½¸ -¬®¿²ô - °´²#³ °±®±¦«³4²3³ ¶»¶3³« ¬»¨¬« · ¼'-´»¼µ'³ô ²·µ±´·ª ª ¬3-²· ¿ ¦¿ ²?°¿¼²4 ²»ª#¸±¼²#½¸ °±¼³3²»µò ìò Ô·½»²8²3 -³´±«ª¿ ²¿¾#ª? °´¿¬²±-¬· ¿ &8·²²±-¬· ¼²»³ ¶»¶3¸± °±¼°·-« ±¾4³¿ -³´«ª²3³· -¬®¿²¿³·ò
Ê Þ®²4 ¼²»æ òòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòò
òòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòò
òòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòòò
Ò¿¾§ª¿¬»´
ß«¬±®
Abstrakt Úkolem bakalářské práce bylo prostudovaní a popsání základní metody měření přenosových parametrů datových sítí založených na IP. Vycházel jsem především ze standardů RFC, podle kterých se řídí většina Internetových protokolů. Jednotlivé postupy pro testování jsou popsány v RFC 2544. Na základě rozboru parametrů jsem navrhl koncepci a realizoval webovou aplikaci, která umožňuje orientačně zjišťovat základní přenosové parametry připojení do Internetu (downstream, upstream, latence, rozptyl rychlosti připojení). Aplikace nevyžaduje žádné doplňky ani moduly na straně uživatele. Je postavena na serverovém programovacím jazyku PHP s využitím relační databáze MySQL, ve které jsou uchována data a klientském skriptovacím jazyku JavaScript. Aplikace nabízí měření uvedených
parametrů
jak
návštěvníkům,
tak registrovaným uživatelům. Samozřejmostí je registrace uživatelů, práce s historií uskutečněných měření, posílání soukromých zpráv mezi registrovanými uživateli. Nad celou aplikací existuje administrátorský účet.
Klíčová slova metody měření přenosových rychlostí, přenosové parametry připojení, RFC 2544, měření parametrů připojení do Internetu, měření downstreamu, měření upstreamu
Abstract Study and basic benchmarking methodology description of network connections based on the IP was the objective of bachelor work. I resulted above all from RFC standards, by which are directed most of Internet protocols. Particular procedures for testing are explained in RFC 2544. On the basis of parameters analysis, I suggested conception and gave shape to web application which allows identify referenced basic transfer parameters of Internet connection (downstream, upstream, latency, scattering of connection speed). Application doesn’t require no add-ons and modules on user side. It is built on server programming language PHP with usage of relational MySQL database, in which are stored data. Client scripting language JavaScript is also used. Application offers measuring of mentioned parameters both to visitors and to registered users. Matter of course is user registration; work with history of carried out measuring, sending private messages between registered users. Above whole application exists administrator account.
Key words benchmarking methodology of network connections, transfer parameters of connection, RFC 2544, metering parameters of the Internet connection, metering downstream, metering upstream
Prohlášení Prohlašuji, že svou bakalářskou práci na téma Metody měření přenosových rychlostí jsem vypracoval samostatně pod vedením vedoucího bakalářské a s použitím odborné literatury a dalších informačních zdrojů, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení § 152 trestního zákona č. 140/1961 Sb.
V Brně dne 2. června 2008
................................................
Poděkování Děkuji vedoucímu bakalářské práce Doc. Ing. Václavu Zemanovi, Ph.D. za odbornou metodickou pomoc a cenné rady při zpracování bakalářské práce.
V Brně dne 2. června 2008
................................................
ÚVOD............................................................................................................................9 1.
SÍTĚ ....................................................................................................................10 1.1. 1.2. 1.3. 1.3.1. 1.3.2.
2.
ETHERNET ..................................................................................................10 ISO OSI......................................................................................................11 TCP/IP .......................................................................................................12 INTERNET PROTOCOL ..................................................................................12 TCP A UDP ................................................................................................13
STANDARDY PRO TESTY.................................................................................14 2.1. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7. 2.2.8. 2.2.9. 2.2.10. 2.2.11. 2.2.12. 2.2.13.
RFC 1242...................................................................................................14 RFC 2544...................................................................................................15 DUT – DEVICE UNDER TEST..........................................................................15 NASTAVENÍ DUT..........................................................................................17 TESTOVACÍ RÁMCE.......................................................................................17 PROTOKOLOVÉ ADRESY, PORTY....................................................................18 RYCHLOST TESTOVÁNÍ .................................................................................18 SHLUKOVÝ PROVOZ .....................................................................................19 POSLOUPNOST TESTŮ ..................................................................................19 TEST PROPUSTNOSTI ...................................................................................19 TEST ZPOŽDĚNÍ – LATENCE ..........................................................................20 TEST ZTRÁTOVOSTI RÁMCŮ ..........................................................................21 TEST BACK-TO-BACK RÁMCŮ ........................................................................22 ZOTAVENÍ PO PŘETÍŽENÍ ...............................................................................22 ZOTAVENÍ PO RESTARTU ..............................................................................23
3.
DOSTUPNÉ WEBOVÉ APLIKACE PRO MĚŘENÍ..............................................24
4.
NÁVRH WEBOVÉ APLIKACE ............................................................................26 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.2. 4.3. 4.4.
5.
ŘEŠENÍ WEBOVÉ APLIKACE ...........................................................................33 5.1. 5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.1.5. 5.2. 5.3. 5.4. 5.5.
6.
HTML .........................................................................................................26 VÝVOJ HTML ..............................................................................................27 STRUKTURA SOUBORU HTML.......................................................................27 TAGY V HTML .............................................................................................28 KÓDOVÁNÍ V HTML......................................................................................28 DYNAMICKÉ GENEROVÁNÍ HTML ..................................................................29 PHP ...........................................................................................................30 BASH ..........................................................................................................30 MYSQL DATABÁZE.......................................................................................31 MĚŘENÍ PŘENOSOVÝCH PARAMETRŮ.............................................................33 DOWNSTREAM .............................................................................................34 UPSTREAM ..................................................................................................35 LATENCE .....................................................................................................36 ROZPTYL.....................................................................................................36 FRONTA MĚŘENÍ ..........................................................................................36 VÝPIS USKUTEČNĚNÝCH MĚŘENÍ ...................................................................37 POSÍLÁNÍ SOUKROMÝCH ZPRÁV.....................................................................38 REGISTRACE UŽIVATELŮ...............................................................................39 ÚČET ADMINISTRÁTORA................................................................................40
ZÁVĚR ................................................................................................................41
LITERATURA .............................................................................................................42
8
Úvod S rozvojem výpočetní techniky a informačních technologií vzrůstají požadavky na vzájemné propojení od sebe vzdálených počítačů. Terminálové sítě, které poskytovaly více uživatelům přístup k jednomu počítači, však nenabízely možnost přístupu k více počítačům tak, aby bylo možné využívat data a programy na nich uložené. Z tohoto důvodu začaly vznikat počítačové sítě, jejichž rozvoj pořád probíhá. S množstvím připojených počítačů do sítě také narůstá objem přenášených dat. Chceme-li po síti přenášet data náročná na šířku přenosového pásma, např. uskutečnit videohovor nebo poslouchat internetové rádio ve vyšší kvalitě, měli bychom vědět, zdali je maximální možná přenosová rychlost našeho připojení pro uvedenou službu dostačující. Pro zjištění síťových parametrů můžeme použít hardwarové nebo softwarové nástroje. Hardwarové zařízení se vyznačuje vysokou přesností naměřených parametrů Testy přenosových parametrů jsou provedeny podle definovaných standardů pro měření. Protikladem je vysoká cena, nedostupnost a mnohdy je použití hardwarového zařízení komplikované. Komerčních softwarových nástrojů dodržujících standardy pro měření je několik. Většina volně dostupných aplikací pro měření přenosových parametrů je realizována jako webová aplikace. Žádná z těchto aplikací se ale nedrží standardů pro měření. Abych mohl navrhnout aplikaci, která bude odpovídat standardům pro měření, je zapotřebí si uvědomit princip fungování sítí, který je popsán v následujících kapitolách. Nastudoval jsem a teoreticky rozebral standard RFC 2544, který popisuje metody měření. Na základě těchto informací jsem navrhl a naprogramoval webovou aplikaci, která umožňuje orientačně zjišťovat základní přenosové parametry připojení do Internetu.
9
1.
Sítě
Pro vzájemnou komunikaci počítačů v rámci počítačové sítě jsou používány síťové protokoly. Síťových protokolů existuje celá řada. Komunikace je řešena pomocí jednotlivých síťových vrstev. Počet vrstev závisí na tom, jakou soustavu síťových protokolů – síťového modelu použijeme. V internetu se používá protokolů TCP/IP. Kromě protokolu TCP/IP existuje model ISO OSI, který standardizoval Mezinárodní standardizační úřad (ISO). Rodina protokolů TCP/IP využívá čtyři vrstvy a protokoly ISO OSI používají vrstev sedm [1].
Obr. 1 – Vrstvy prokolu TCP/IP a ISO OSI
1.1. Ethernet Nejčastěji používaným typem síťového rozhraní je Ethernet. Rozšířenost Ethernetu spočívá v jednoduchosti protokolu a jeho snadné implementaci. Zajišťuje služby fyzické a linkové vrstvy ISO OSI modelu. Fyzická vrstva popisuje elektrické či optické signály používané při komunikaci mezi počítači. Na fyzické vrstvě je vytvořen tzv. fyzický okruh. Na fyzický okruh mezi dva
10
počítače bývají často vkládána další zařízení např. modemy, které modulují signál na telefonní vedení. Linková vrstva poskytuje spojení mezi dvěma sousedními systémy. Seřazuje přenášené rámce, stará se o nastavení parametrů přenosu linky, oznamuje neopravitelné chyby. Formátuje fyzické rámce, opatřuje je fyzickou adresou – MAC adresu (Media Access Control). MAC adresa je unikátní a přidělena výrobcem síťové karty. Linková vrstva uspořádává data z fyzické vrstvy do logických celků známých jako rámce (frames).
1.2. ISO OSI Vrstvy modelu OSI - open system interconnect popisují veškeré činnosti a služby v síti. Každá z těchto vrstev zabezpečuje určité činnosti a pro jejich realizaci využívá služeb nižších vrstev. Komunikaci mezi dvěma vrstvami stejné úrovně popisuje tzv. virtuální (zdánlivý) protokol. Je nutné si definovat základní pojmy: Zpráva je datová jednotka obsahující nějakou ucelenou informaci např. vyžádaný textový soubor nebo potvrzení jeho příjmu. Délka zprávy může být rozdílná, není tedy vždy možné ji přenášet po síti celou, a proto je pro potřeby přenosu rozdělena na menší části konstantní délky tzv. pakety. Pro vlastní přenos po síťovém médiu musí být paket doplněn o další nezbytné údaje (cílová a zdrojová adresa, synchronizační posloupnost, kontrolní součet) a takto doplněný paket se označuje jako rámec.
Obr. 2 – Formát rámců lokální sítě Ethernet II a IEEE 802.3 §
Preambule - Skládá se z 8 byte, střídavě binární 0 a 1. Poslední byte má tvar 10101011 a označuje začátek vlastního rámce. Preambule slouží k synchronizaci. Poslední byte se někdy nazývá omezovač počátku rámce (Starting Frame Delimiter, SFD).
§
Cílová adresa - Fyzická MAC adresa o délce 48 Bitů. Adresa může být individuální (unicast), skupinová (multicast) a všeobecná (broadcast).
11
§
Zdrojová adresa - Fyzická adresa stejného typu jako cílová, ale je to vždy individuální adresa konkrétní stanice (rozhraní).
§
§
Typ protokolu nebo délka §
Pro Ethernet II je to pole určující typ vyššího protokolu.
§
Pro IEEE 802.3 udává toto pole délku pole dat.
Data - Pole dlouhé minimálně 46 oktetů a maximálně 1500 oktetů. Minimální délka je nutná pro správnou detekci kolizí.
§
Kontrolní součet - (Frame Check Sequence, FCS) 32 bitový cyklický kontrolní kód, který se počítá ze všech polí s výjimkou preambule a FCS. Slouží ke kontrole správnosti dat - příjemce si jej vypočítá z obdrženého rámce a pokud výsledek nesouhlasí s hodnotou pole, rámec zahodí jako vadný.
1.3. TCP/IP Rodina protokolů TCP/IP se až na výjimky nezabývá fyzickou a linkovou vrstvou. V praxi se i v Internetu používají pro fyzickou a linkovou vrstvu často protokoly vyhovující normám ISO OSI, které standardizoval ITU. Vztah mezi protokoly ISO OSI a TCP/IP spočívá v tom, že každá skupina má vlastní definici svých vrstev i protokolů jednotlivých vrstev. Proto jsou protokoly ISO OSI a TCP/IP obecně nesouměřitelné. V praxi však je třeba využívat komunikační zařízení vyhovující ISO OSI pro přenos IP paketů nebo např. naopak realizovat služby podle ISO OSI přes Internet.
1.3.1.
Internet Protocol
Internet Protocol – IP protokol odpovídá komunikaci na síťové vrstvě modelu. IP protokol přenáší tzv. IP datagramy mezi vzdálenými počítači. Každý IP datagram ve svém záhlaví nese adresu příjemce, což je úplná směrovací informace pro dopravu IP datagramu k adresátovi. Síť tedy může přenášet každý IP datagram samostatně. IP datagramy tak mohou k adresátovi dorazit v jiném pořadí, než v jakém byly odeslány. Každé síťové rozhraní v rozsáhlé síti Internet má svou celosvětově jednoznačnou IP adresu [5].
12
1.3.2.
TCP a UDP
Protokoly TCP a UDP odpovídají transportní vrstvě. Protokol TCP dopravuje data pomocí TCP segmentů, které jsou adresovány jednotlivým aplikacím. Protokol UDP dopravuje data pomocí tzv. UDP datagramů. Protokoly TCP a UDP zajišťují spojení mezi aplikacemi běžícími na vzdálených počítačích. Protokoly TCP a UDP ale také mohou zajišťovat komunikaci mezi lokálními procesy. Rozdíl mezi protokoly TCP a UDP spočívá v tom, že protokol TCP je spojovanou službou. Příjemce potvrzuje přijímaná data. V případě ztráty dat - ztráty TCP segmentu si příjemce vyžádá zopakování přenosu. Protokol UDP přenáší data pomocí datagramů, který je obdobou telegramu. Odesílatel odešle datagram a už se nezajímá o jeho doručení. Jednotlivé TCP a UDP protokoly jsou definovány příslušným portem.
13
2.
Standardy pro testy
Při výrobě a uvádění do provozu každého zařízení jsou kladeny požadavky na kvalitu, spolehlivost, bezporuchovost a technické parametry. Aby bylo možné tato kritéria posuzovat a srovnávat jednotlivá zařízení, jsou zavedeny normy a standardy, které popisují chování daného systému. Pro popis Internetových protokolů a systémů existují RFC. RFC je zkratka anglického výrazu request for comments - žádost o komentáře a používá se pro označení řady standardů a dalších dokumentů. Přestože RFC jsou oficiálně považovány za doporučení oproti normám, které je potřeba dodržovat, řídí se podle nich významná část Internetu a počítačových sítí. Jednotlivé RFC dokumenty jsou vydávány editorem RFC podle příkazů Internet Architecture Board. Každé RFC má při vydání přiděleno číslo. Žádné vydané RFC se nikdy neruší, pouze může být v budoucnu upraveno vydáním novějšího RFC. Všechna RFC lze volně získat na adrese http://www.ietf.org/rfc.html. Každé RFC je dostupné v podobě čistého ASCI textu v angličtině. Na rozdíl od klasických norem a standardů vydávaných normotvornými institucemi (ISO, ANSI, ČNI) vznikají RFC odlišným způsobem. Původními autory jednotlivých RFC jsou výzkumní a vývojoví pracovníci, návrháři, výrobci a uživatelé technologií ze sdružení Internet Engineering Task Force (IETF), kteří se snaží řešit konkrétní problém, jehož řešení nabídnou ve formě návrhu RFC internetové veřejnosti jako tzv. Internet Draft. Pokud je dané řešení, které obvykle již dobře funguje v rámci nějakého pilotního provozu, uznáno za přínosné, dokument se vydá jako RFC. Sestavovaní standardů jednotlivci či malými skupinami na základě praktických zkušeností má mnohé výhody oproti formálnějším procesům standardizačních komisí u úřadů typu ISO. Standardy vytvořené pomocí RFC jsou vzhledem k neexistenci jakékoliv skutečné moci na jejich vynucování až na výjimky dodržovány, přičemž pomohly rozšíření Internetu do dnešních celosvětových rozměrů. Bližší informace o procesu tvorby RFC jsou uvedeny v RFC 2026 The Internet Standards Process, Revision 3. První RFC dokument RFC 1 Host Software napsal Steve Crocker z Kalifornské univerzity a byl vydán 7. dubna 1969 [16].
2.1. RFC 1242 Sdružení Internet Engineering Task Force (IETF) vydávající RFC je rozděleno do různých skupin. Pracovní skupina Benchmarking Methodology Working Group (BMWG) popisuje různé metody provádění testů včetně jednoznačné prezentace
14
naměřených hodnot. BMWG se především zaměřuje na problematiku testování jednoho či několika málo zařízení. První dokument, který BMWG vydala, byl v roce 1991 RFC 1242 Benchmarking Terminology for Network Interconnection Device. Dokument definuje klíčové pojmy, které jsou používány v dalších RFC vydaných BMWG. V RFC 1242 jsou definovány pojmy propustnost sítě, zpoždění, odezva a také hardwarové prvky jako router, bridge, repeater. Jednoznačnou definicí těchto pojmů je vyloučen různý výklad [2].
2.2. RFC 2544 V roce 1999 vydala BMWG RFC 2544 Benchmarking Methodology for Network Interconnect Devices, kterým byla nahrazena RFC 1944 z roku 1996. RFC popisuje výkonnostní testy síťových zařízení včetně jednoznačné prezentace naměřených hodnot [3]. RFC 2544 rozlišuje výrazy „MUST“ - musí, „SHOULD“ - měl by a „MAY“ – volitelné – může nebo smí. Podle splnění požadavků uvedených výrazů potom testy odpovídají úplně nebo částečně specifikacím RFC [4].
2.2.1.
DUT – device under test
RFC popisuje zapojení testovaného zařízení DUT – device under test a teorii nad propojováním sítí. Při vývoji, návrhu a ladění zařízení se používá komplementární přístup, kdy analyzujeme jednotlivé moduly a prvky uvnitř zařízení a jejich práci s daty. V praxi potom při testech považujeme testované zařízení za černou skříňku. Není podstatná vnitřní struktura, zapojení, provedení nebo prvky, ze kterých je vyrobeno. Rovněž se nezajímáme o softwarovou stránku zařízení, jak se v něm data zpracovávají a posílají dál. Pro testovaní zařízení můžeme použít tři varianty zapojení testovaného zařízení - DUT a zařízení posílající a přijímající zaslaná testovací data. Ideálním a jednoduchým řešením je použití testovacího zařízení s vysílacím i přijímacím portem. Zasílání testovacích dat probíhá z vysílacího portu testovacího zařízení do DUT a z něj do přijímacího portu testovacího zařízení – obr. 3. Lze pak rychle a elegantně vyhodnotit vlastnosti, charakteristiky a výkon DUT. Možnou variantou měření je oddělení vysílacího a přijímacího portu na dvě nezávislá testovací zařízení – obr. 4. Pro vyhodnocení testu je potom nutné mít stavové informace. Při testování vícenásobných síťových zařízení mohou být DUT zapojeny v sérii – obr. 5.
15
Obr. 3 – DUT a testovací zařízení, které plní funkci vysílacího i přijimacího portu
Obr. 4 – DUT a testovací zařízení s odděleným vysílacím i přijimacím portem
Obr. 5 - Testování vícenásobných síťových zařízení DUT zapojených v sérii 16
2.2.2.
Nastavení DUT
Konfigurace testovaného zařízení musí přesně odpovídat nastavení uvedeném v testovací zprávě. Očekává se, že budou aktivní a zahrnuty do testu všechny protokoly, které testovaný prvek síťové infrastruktury podporuje. Všechny prováděné testy by měly být provedeny beze změny v konfiguraci testovaného zařízení. Další informace jsou uvedeny v dodatku A standardu RFC 2544, který je považován za průvodce, ale není závazný.
2.2.3.
Testovací rámce
Při testování v sítích TCP/IP musí být použity přesné formáty rámce uvedené v příloze C RFC 2544. Při použití jiných formátů rámce než definovaných v příloze C musí být tyto uvedeny v testovací zprávě. Všechny popisované testy by měly být provedeny několikrát. Minimální počet délek testovacích rámců je pět. Do testování by měly být zahrnuty především rámce s nejmenší a největší přípustnou délkou pro testované médium. Interval mezi velikostmi rámců by měl být dostatečný. Pro Ethernet jsou velikosti 64, 128, 256, 512, 1024, 1280 a 1518 Byte. Velikost rámců by měla být také v závislosti na MTU (Maximum Transmission Unit) a fragmentaci [4]. Důležité je ověřování příchozích rámců. Testovací zařízení by mělo během testu zahazovat příchozí rámce, které nejsou aktuálně přeposílanými testovacími rámci. Zahozené příchozí rámce nejsou započítány do celkového počtu přijatých rámců. Často se jedná o pakety obsahující směrovací informace, ARP dotazy. Měli bychom kontrolovat, jestli se shoduje velikost odeslaných a příchozích rámců. Rovněž pokud každý rámec obsahuje unikátní identifikační číslo, kterým potom rámce vytváří sekvenci, měli bychom sledovat pořadí, ve kterém se vrátily zpět, jestli nedošlo při přenosu k jejich duplicitě nebo ztrátě. Při testování specifického zařízení je vhodné zvolit testy jemu odpovídající. Pro testování propustnosti routeru bychom se měli zaměřit na potenciálně problematickou oblast. Jedná se především o všesměrové vysílání. Je doporučeno, aby každý stý zasílaný rámec obsahoval všesměrovou - broadcastovou cílovou adresu. Tento rámec musí byt směrovačem přeposlán na všechna rozhraní. Rovněž je vhodné zasílat rámce obsahující dotazy protokolů pro správu sítě – SNMP - Simple Network Management Protocol a zjišťovat reakci DUT. Je potřeba se zaměřit také na nastavení směrovacích tabulek a bezpečnostních filtrů routeru. Nakonfigurovaná pravidla určují průchod paketů vycházející ze zdrojových a cílových adres. Pokud testovací zařízení podporuje 17
generování síťového provozu vyhovujícího daným podmínkám, je žádoucí co nejvíce podmínek zahrnout do testů. Testy s dodatečnými podmínkami by měly být vykonávány až po dokončení testů bez podmínek. Následně potom s každou podmínkou zvlášť.
2.2.4.
Protokolové adresy, porty
Při testování je doporučeno začít pouze s jedním testovacím tokem dat. Znamená to použití právě jedné zdrojové a právě jedné cílové adresy. Je potřeba si ale uvědomovat, že v reálném provozu je datových toků podstatně více. Po dokončení testu jedním tokem dat by se mělo pokračovat dalšími testy s toky dat, které budou mít náhodně generované cílové adresy nebo rovnoměrné rozložení těchto adres. Rozsah adres pro IP datagramy je uveden v příloze C standardu. Musíme také brat v úvahu, že v reálných sítích data tečou oběma směry, nikoliv pouze jedním. V datových sítích se velmi často setkáváme s prvky, které mají více portů. Jedná se např. o routery. V takovém případě bychom měli otestovat každý port zvlášť, abychom odhalili případnou chybu vyskytující se pouze na daném portu. Je vhodné generovat provoz, který DUT přijme na různých vstupních portech a pošle na všechny výstupní porty ve stejné chvíli. RFC 2544 nespecifikuje testy realizované na různých protokolech a mediích současně. Stejně tomu je u různých délek rámců v jednom testu. Definována je pouze velikost rámců. Testování více zařízení najednou je považováno přístupem end-to-end jako jedno DUT. Je potřeba si uvědomit, že při takovémto testu může vznikat na některém ze zařízení zpoždění.
2.2.5.
Rychlost testování
V testech bychom měli použít maximální možnou rychlost zasílání rámců dané velikosti na zařízení. Hodnoty rychlostí jsou uvedeny v příloze B standardu RFC. U hodnot uvedených pro Ethernet je potřeba si uvědomit, že povolená odchylka od hodinového taktu podle IEEE 802.3 pro toto rozhraní je ± 0,01%. Nemůžeme tedy zaručit, že každé zařízení dokáže pracovat s rychlostmi uvedenými v příloze B. Ztráta ± 0,02% je považována za povolenou.
18
2.2.6.
Shlukový provoz
Při skutečném síťovém provozu se zřídka setkáváme s konstantní zátěží. Pro přiblížení realitě je doporučeno generovat shlukový provoz – bursty traffic. Rámce uvnitř shluku jsou generovány tak, aby mezi sebou měly co nejmenší mezery. Požadavkem tohoto testu je zjistit nejmenší interval mezi shluky, kde nedochází ke ztrátě žádného rámce. Shluky mohou obsahovat 16, 64, 256 nebo 1024 rámců.
2.2.7.
Posloupnost testů
Sada testů je složena z několika dílčích testů. Postup provádění těchto dílčích testů: 1. Pokud je testované zařízení router, pošleme směrovací aktualizaci na vstupní port a počkáme 2 sekundy, abychom si byli jisti, že směrovač aktualizaci zpracoval 2. Pošleme rámce, které „naučí“ DUT kam má posílat testovací rámce a počkáme 2 sekundy 3. Spustíme samotný test a počkáme nejméně 60 sekund, u některých časově náročných testů lze tuto dobu zkrátit, ale výsledek je zapotřebí ověřit testem trvajících minimálně 60 sekund 4. Počkáme 2 sekundy na poslední příchozí rámce 5. Nejméně 5 sekund necháme DUT na stabilizování Po dokončení testu následuje popis postupu testování a prezentace získaných hodnot.
2.2.8.
Test propustnosti
Cílem testu je zjistit propustnost definovanou v RFC 1242. Jedná se o maximální rychlost zasílání paketů, při které nejsou zahozeny žádné odeslané pakety. Do testovaného zařízení pošleme určitý počet rámců o určité rychlosti a sledujeme počet přeposlaných nebo zpracovaných rámců. Pokud je počet přijatých rámců stejný jako počet odeslaných, zvýšíme rychlost vysílání paketů. Pokud je ale menší a některé rámce se při komunikaci ztratily, snížíme rychlost vysílání. Poté test znovu opakujeme. Propustnost je tedy považována za nejvyšší rychlost v rámcích za sekundu, při které je roven počet vyslaných a přijatých rámců. Výsledky testování by měly být prezentovány v podobě grafu. Na ose x jsou vyneseny délky rámců, na ose y rychlost v rámcích za sekundu. Graf by měl obsahovat nejméně dvě křivky. Jedna z křivek by měla zobrazovat maximální teoretickou propustnost
19
daného média při různých velikostech rámců. Další potom prezentují naměřené hodnoty při testu. Doprovodný text by měl informovat o použitém protokolu, formátu testovacího toku a typu média. Při použití pouze jediné hodnoty k propagačním účelům se předpokládá, že to bude právě ta, při které testované zařízení dosahuje největšího výkonu. Hodnota musí být uvedena v rámcích za sekundu, volitelně v Bitech či Bytech za sekundu. Závěr musí obsahovat nejvyšší naměřenou hodnotu, velikost rámce, na které byla naměřena, teoretickou maximální rychlost média pro danou velikost rámce a typ protokolu použitého při testu. Technická specifikace zařízení by měla obsahovat úplnou tabulku výsledků. V dokumentu není přesně specifikováno kolik rámců má být posláno na testované zařízení. Udává pouze standardní délku trvání testu 60 sekund a její potencionální zkrácení. Přesný počet poslaných rámců je možné dopočítat z rychlosti zasílání. Způsob provádění testu je ve standardu popsán neurčitě.
2.2.9.
Test zpoždění – latence
Latence v datových sítích vyjadřuje čas, za který data doputují do cílového místa. S rostoucí latencí se zvětšuje doba odezvy. Vysoká doba odezvy pro některé aplikace je nepřípustná - např. VoIP telefonie. Cílem testu je najít zpoždění - velikost latence podle definice v RFC 1242. Při testování latence je zapotřebí rozlišit typ zařízení, protože jsou tři možnosti zpracování paketů. 1. Store and forward - celý paket nejprve načteme a až poté je přeposlán na dané rozhraní. Tato metoda je používána především u switche a routeru. Zpoždění v tomto případě definujeme jako časový interval mezi průchodem posledního bitu vstupního rámce na vstupním portu a průchodem prvního bitu výstupního rámce na výstupním portu. 2. Bit forwarding - paket je okamžitě zaslán na příslušné rozhraní. Pracují takto např. repeatery (opakovače), tedy zařízení operující na první vrstvě síťového modelu ISO/OSI. Latence je definována jako časový interval mezi průchodem prvního bitu vstupního rámce na vstupním portu a průchodem prvního bitu výstupního rámce na výstupním portu.
20
3. Cut through - jedná se o spojení metody Store and forward a Bit forwarding. Paket není načten celý, ale je načtena pouze hlavička. Po načtení hlavičky se zahájí přeposílání. Zpoždění je potom definováno jako časový interval mezi průchodem posledního bitu hlavičky na vstupním portu a objevením prvního bitu na výstupním portu. Před začátkem testování je zapořebí zjistit propustnost pro rámce dané délky odpovídající DUT - u Ethernetu 64, 128, 256, 512, 1024, 1280 a 1518 bytů). Pro každou takovou délku vygenerujeme testovací rámce a zašleme je rychlostí naměřenou v testu propustnosti. Tok dat by měl trvat minimálně 120 sekund. Po uplynutí 60 sekund by měl být do rámce vložen identifikující tag. Čas kompletního odeslání je zaznamenáván. Přijímající část zařízení musí tento rámec rozpoznat a zaznamat čas jeho příchodu. Zpoždění je rozdílem času příchodu a času odeslání. Každý test musí být opakován minimálně dvacetkrát. Výsledná hodnota zpoždění je aritmetickým průměrem všech naměřených hodnot. Testovací rámec by měl pokaždé směřovat do jiné cílové sítě, adresa zařízení zůstává pořád stejná. V testovací zprávě musí být uvedena použitá definice zpoždění podle RFC 1242. Výsledky testu by měly být uvedeny v tabulce. Počet řádků tabulky má odpovídat počtu délek rámců, kterými byl test proveden. Jednotlivými položkami potom velikost rámců, rychlost vysílání rámců, typ testovaného média a naměřenou hodnotu zpoždění.
2.2.10. Test ztrátovosti rámců Definice ztrátovosti paketů - frame loss rate - je popsána v RFC 1242. Ztrátovost je procentuální údaj vyjadřující poměr počtu paketů odeslaných vůči počtu paketů skutečně přijatých. Pro změření ztrátovosti rámců vyšleme na DUT určitý počet rámců určitou rychlostí. Zařízení by mělo tyto vyslané rámce přijmout a přeposlat dále. V prvním dílčím testu by měly být rámce zasílány stejnou rychlostí jako je maximální teoretická rychlost pro danou velikost rámce na testovaném médiu. Další dílčí testování by mělo být prováděno s postupně nižší vysílací rychlostí. Maximální krok snižování rychlosti je 10%, doporučeno je provádět kroky v menších intervalech. Snižování rychlosti provádíme dokud nenastane ve dvou po sobě následujících dílčích testech nulová ztráta rámce. Naměřené hodnoty by měly být zobrazeny v grafu. Na osu x je prezentována rychlost vysílání v procentech teoretické maximální rychlosti testovaného média. Osu y 21
prezentuje ztrátovost v procentech. Rozsah obou os je 0 - 100 %. Graf může obsahovat více křivek, které mohou vyjadřovat ztrátovost např. pro různé délky rámců nebo použité protokoly.
2.2.11. Test back-to-back rámců Back-to-back rámce podle definice v RFC 1242 jsou rámce, které mají pevnou délku a jsou vyslány za sebou. Časový interval mezi dvěma po sobě vyslanými rámci by měl být co nejmenší povolený na testovaném médiu. Cílem testu Back-to-back rámců je zjistit, jak je zařízení schopno s nimi pracovat. Do testovaného zařízení zašleme shluk back-to-back rámců. Pokud počet přijatých rámců odpovídá počtu odeslaných rámců, zvětšíme počet rámců ve shluku. Pokud některé rámce nebyly doručeny, počet rámců snížíme. Test provedeme znovu. Výsledkem testu je počet rámců v nejdelším shluku, které testované zařízení zpracovalo bez ztráty rámce. Každý dílčí test musí trvat minimálně 2 sekundy a měl by být
proveden
minimálně
padesátkrát. Výsledná
hodnota
testování je
rovna
aritmetickému průměru dílčích naměřených hodnot. Testovací zpráva by měla obsahovat tabulku s naměřenými hodnotami. Počet řádků odpovídá počtu různých délek rámců, které byly testovány. Sloupce by měly obsahovat velikost rámce, naměřený, průměrný výsledek a je vhodné doplnit odchylku.
2.2.12. Zotavení po přetížení Cílem testu je zjistit čas, který testované zařízení potřebuje pro zotavení po přetížení. Před testováním času zotavení po přetížení je zapotřebí znát propustnost zařízení pro danou délku rámce. Zašleme po dobu minimálně 60 sekund tok rámců rychlostí 110% zjištěnou v testu propustnosti. Pokud je tato rychlost vyšší než maximální rychlost daného média, vysíláme rámce maximální rychlostí média. Potom snížíme vysílací rychlost na polovinu předchozí rychlosti. Zaznamenáme čas snížení rychlosti a sledujeme čas posledního ztracení testovacího rámce. Čas potřebný k zotavení po přetížení odpovídá rozdílu těchto dvou časů. Testování by mělo být několikrát opakováno. Výsledná hodnota je aritmetickým průměrem všech dílčích testů. Výsledky testování by měly být uvedeny v tabulce. Řádky budou reprezentovat jednotlivé velikosti testovacích rámců. Sloupce budou obsahovat velikost rámce, propustnost pro jednotlivé typy datového toku a čas nutný pro zotavení po přetížení.
22
2.2.13. Zotavení po restartu Cílem testu je zjištění rychlosti, kterou je schopno zařízení zotavit se po hardwarovém nebo softwarovém restartu. Před testováním času zotavení po přetížení je zapotřebí znát propustnost zařízení pro nejmenší povolenou délku rámce na testovaném médiu. Testovací datový tok složený z minimální velikosti rámců zašleme na zařízení rychlostí změřenou v testu propustnosti. Evidujeme čas přijetí posledního rámce před restartem a čas přijetí prvního rámce po restartu. Zotavení po restartu je doba, která je rozdílem těchto dvou hodnot. Při testování chování při přerušení napájení, odpojení od zdroje by mělo trvat 10 sekund. Tento test by měl být prováděn pouze s adresami sítí připojených k testovanému zařízení přímo, není zapotřebí čekat na aktualizaci směrovacích tabulek. Výsledkem měření by měla být jednoduchá sada údajů obsahující časy zotavení pro jednotlivé typy restartu.
23
3.
Dostupné webové aplikace pro měření
Webová aplikace je rychlou a elegantní cestou ke zjištění základních parametrů připojení do Internetu. Princip funkce jednotlivých aplikací pro orientační měření je podobný, ale výrazně se liší v alespoň částečném dodržování standardu RFC 2544 pro testovaní parametrů přenosových rychlostí. Je nutné také zdůraznit, že před zahájením testováni je vhodné vypnout ostatní aplikace, které využívají kapacitu našeho připojení k Internetu. Vyvarujeme se tím zkresleným výsledkům testu. Důležitým faktorem je umístění testovací aplikace. Měla by být provozována na páteřní konektivitě. Z počítače připojeného do sítě v České republice není vhodné používat testovací aplikace běžící v zahraničí, protože tranzitní – zahraniční konektivita je u většiny poskytovatelů výrazně poddimenzována a výsledný test je omezen tímto úzkým hrdlem. Zaměřil jsem se tedy na aplikace, které běží v České republice. Je žádoucí, aby místo, kde je server umístěn mělo také uzavřeno peeringové smlouvy s jednotlivými členy NIXu – Neutral Internet eXchange – zájmového sdružení právnických osob, které sdružuje poskytovatele Internetových služeb v ČR s cílem propojení jejich internetových sítí. Test je spuštěn buď ihned po vstupu na testovací stránku, nebo je potřeba kliknout pro jeho zahájení. Po spuštění testu začne webový prohlížeč stahovat testovací soubor o velikosti od 100kB do 5000kB. Záleží, jak je aplikace koncipována. Některé aplikace nechávají na uživateli, aby zvolil sám velikost testovaného souboru. Sofistikovanější začnou se souborem o velikosti 100kB a v případě, že je tento soubor stažen za více než 5 sekund, považuje se test za úspěšně dokončený a jsou vypsány naměřené hodnoty, případně zapsány do databáze pro porovnávání s ostatními testy. V opačném případě, kdy je soubor stažen za časový interval menší než 5 sekund, je vypočtena nová velikost testovacího souboru. Tento soubor by měl být na základě prvního nepřesného testu stažen za déle jak 5 sekund. Maximální velikost vygenerovaného testovacího souboru je 5000 kB. Test se považuje za platný i v případě, že byl vykonán za dobu kratší než 5 sekund. Toto omezení maximální velikosti je pravděpodobně kvůli možnému přetížení testovacího serveru. Některé aplikace vůbec neumožňují testovaní přenosové rychlosti uploadu. Ty, které jej podporují, používají data získaná při testu z downloadu, nebo je generují. Maximální velikost dat pro upload se pohybuje okolo 2000 kB. Jedná se většinou o polovinu dat z testu downloadu. Dat pro testovaní uploadu se používá menší množství, protože drtivá
24
většina Internetových připojení je asymetrických. Přenosová rychlost pro download a upload se tedy liší. Test odezvy slouží k přibližnému určení odezvy - pingu klienta vůči serveru. Odezva je měřena pomocí webového prohlížeče. Měří se rychlost návratu požadavku zaslaného od klienta k serveru a zpět. Tato metoda testu je vzhledem k použité technologii velmi orientační. Protože je zatížena odezvou webového serveru je v porovnaní s běžným pingem zkreslená. Přehled jednotlivých aplikací: §
§
http://www.dsl.cz/mereni-rychlosti [7] §
Testovací server má konektivitu s dobrou odezvou
§
Generuje si sám velikost testovacích souborů
§
Graficky přívětivě zpracovaný graf
§
Nemá statistky naměřených hodnot
http://rychlost.cz/ [8] §
Možnost výběru z několika testovacích serverů, ale přesto relativně dlouhá síťová odezva
§
§
Testuje stabilitu připojení
§
Podle whois databáze IP adres vypisuje poskytovatele
§
Při testech se snaží dodržovat RFC 2544
http://nastroje.lupa.cz/mereni-rychlosti/ [9] §
Pomalý testovací server
§
Dlouhá odezva serveru
Další aplikace pro měření jsou umístěny na pomalých serverech a nesnaží se vůbec dodržovat standard. Jedná se spíše o laická řešení.
25
4.
Návrh webové aplikace
Na základě informací vyplývajících z existujících dokumentů o principech a postupech měření a po důkladné analýze dostupných webových aplikací pro měření jsem přistoupil k samotnému návrhu aplikace. Požadavkem zadání bakalářské práce bylo, aby aplikace byla koncipována jako webová a byla schopna zjistit základní parametry připojení do Internetu. Těmito parametry jsou přenosová rychlost stahovaného souboru ze serveru směrem k uživateli (downstream), přenosová rychlost odesílaného souboru směrem od uživatele na server (upstream), zpoždění komunikace přenášených dat mezi serverem a uživatelem (latence) a informace vypovídající o stabilitě připojení (rozptyl). Aplikace má umožňovat měření pro neregistrované, ale také i pro registrované uživatele, jejich registraci. Uskutečněná měření mají být ukládána a registrovaný uživatel má mít možnost si prohlížet jejich historii s možností filtrování výpisu. Nad celou aplikací by měl existovat administrátorský účet. Z uvedených požadavků také vyplynulo, že aplikaci je vhodné řešit jako serverovou. Tím jsem se vyvaroval případné nekompatibilitě mezi různými systémy nebo komponenty a verzemi webových prohlížečů. Webovou aplikaci pro měření jsem se rozhodl realizovat v programovacím jazyku PHP s využitím MySQL databáze pro ukládání naměřených dat. Pro měření síťové odezvy – pingu jsem využil skriptovacího jazyku Bash, který je k dispozici na serveru s operačními systémy Unix/Linux. Na straně uživatele jsem mimo JavaScriptu eliminoval všechny aktivní prvky, které by mohly měření komplikovat. Pro pochopení principu webové aplikace v jednoduchosti uvedu základní informace o použitých prostředcích pro její vývoj – jazyk HTML, PHP, Bash, databáze MySQL.
4.1. HTML Celosvětová počítačová síť WWW (World Wide Web) se zrodila v Conseil Européen pour la recherche nucléaire, výzkumném centru fyziky poblíž Ženevy ve Švýcarsku. Svůj nápad v roce 1989 prezentoval Tim Berners-Lee, který byl zaměstnancem ve výpočetním středisku CERNu. V tu chvíli si ještě vůbec nepředstavoval, že jeho nápad bude implementován v takovém rozsahu. Jednalo se především o zlepšení vzájemných výměn dokumentů mezi vědci prostřednictvím počítačů a počítačové sítě. Odlišnost spočívala v tom, že texty v dokumentech odkazovaly na jiné dokumenty. Přínosem bylo, že během čtení jednoho dokumentu můžeme rychle přejít na jiný dokument, který obsahuje přímo příslušný text. Za první hypertextový systém lze považovat Timův „Enquire“, který mu sloužil pro osobní potřeby. První prototyp
26
webového prohlížeče „NeXT“, od stejného autora, byl prezentován v roce 1990. V dalším roce Tim Berners-Lee prezentoval vlastní HTTP protokol (HyperText Transfer Protokol). Zobrazoval pomocí něj různě nalinkované textové dokumenty mezi sebou a to velice jednoduchým způsobem. Textový formát dat pro http přenos byl založen na systému SGML (Standard Generalized Mark-up Language) a pojmenován HTML – HyperText MarkUp Language [6].
4.1.1.
Vývoj HTML
Rychlost vývoje HTML poukazuje na skutečnost, že se jedná o jeden z nejrychleji se rozvíjejících prostředků lidské komunikace. Od vzniku HTML jazyka až doposud jsou považovány za důležité milníky vývoje tyto verze: §
Verze 2.0 – První verze, která odpovídá syntaxi SGML. Doplňuje původní specifikaci o interaktivní formuláře.
§
Verze 3.2 – Vydána v květnu 1996. Připravovaná verze 3.0 byla zastaralá dříve, než byl její návrh dokončen (nové verze prohlížečů ji překonaly). Standard byl vydán konsorciem W3C, stejně jako následující verze. Přidává k jazyku tabulky, zarovnávání textu a stylové elementy pro ovlivňování vzhledu.
§
Verze 4.0 – Vydána v prosinci 1997. Do specifikace jazyka přidala nové prvky pro tvorbu tabulek, formulářů a nově byly definovány rámy (frames). Tato verze se snaží dosáhnout původního účelu – prvky by měly vyznačovat význam (sémantiku) jednotlivých částí dokumentu, vzhled má být ovlivňován připojovanými styly. Naopak některé prezentační elementy byly zavrhnuty.
§
Verze 4.01 – Tato verze opravuje chyby předchozí verze a přidává některé nové tagy (značky). Je to poslední verze HTML, které se již dále nevyvíjí a je nahrazena novějším XHTML, jehož základem je právě tato poslední verze HTML.
4.1.2.
Struktura souboru HTML
Jazyk HTML má pevně definovanou základní strukturu, která se skládá z těchto částí: §
Deklarace Document Type Definition – je povinná od verze 4.01, je prvním řádkem v souboru HTML, jedná se o direktivu
§
Kořenový element – element html (párové značky a ) reprezentuje celý dokument. Je nepovinný, ale je doporučeno ho používat.
27
§
Hlavička elementu – jsou to metadata, která se vztahují k celému dokumentu. Definují především název dokumentu, jazyk, kódování, klíčová slova, popis, použitý styl zobrazení. Hlavička je uzavřena mezi párovými značkami a
§
Tělo dokumentu – obsahuje vlastní text dokumentu. Vymezuje se párovými značkami a
Příklad zdrojového kódu HTML [6]: <meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
Titulek stranky Text www stranky
4.1.3.
Tagy v HTML
Vlastní stránka vzniká z textu, který formátujeme za pomoci html značek – tzv. tagů. Tagy mohou být párové a nepárové. Rozdíl mezi nimi je takový, že párové značí oblast, ve které platí, tedy začátek a konec. Nepárové tagy představují samostatnou jednotku v html kódu – např. zalomení řádku
nebo vodorovná čára
.
4.1.4.
Kódování v HTML
Počítač chápe každý znak jako číslo od 0 do 255 (jeden byte). Američané a Angličané si vystačí se 128 znaky. Těmto základním 128 znakům bez diakritických znamének se říká ASCII (American Standard Code for Information Interchange). Dalšími čísly od 128 do 255 byly označeny diakritické znaky jazyků západní Evropy, a tak vznikl kód Latin-1. České znaky v něm nejsou obsaženy (s výjimkou á, í, š a ž). Pro neazbukové jazyky střední a východní Evropy vznikly různé konvence, které zachovávají význam prvních 128 znaků ASCII (normální písmena), ale dalších 128 znaků si definují po svém. A právě různá přiřazení diakritických znaků číslům od 128 do 255 se označují jako kódování (případně jako znaková sada). U html stránek se nejčastěji používají tato tři kódování češtiny: §
ISO 8859-2 – standardní kódování používané především na Unixu a na Linuxu, ale i v mnoha Windows programech. Někdy se označuje jako Latin 2, ISO Latin 2. Microsoft ho nazývá jako "Středoevropské jazyky (ISO)".
28
§
Windows-1250 – jeho obliba na webových stránkách spočívá zejména kvůli tomu, že ho většina editorů na Windows používá jako základní kódování, např. FrontPage, HomeSite nebo Notepad (poznámkový blok). V produktech od společnosti Microsoft se kódování Windows-1250 označuje jako "Středoevropské jazyky" bez přívlastku.
§
UTF-8 – je nejčastějším zápisem znakové sady Unicode. Unicode je na rozdíl od výše zmíněných znakových sad určeno pro všechny světové jazyky najednou, protože znakům přiřazuje čísla až do 16 miliónů (zapisuje se většinou dvěma byty). Jde o nejmodernější kódování. Kódování UTF-8 je dnes v prohlížečích dobře podporováno, lze ho proto bez problémů používat.
Na základě tohoto rozboru jsem se rozhodl aplikaci realizovat v kódování UTF-8. Jedná se jak o kódování zdrojových souborů, tak i dat uložených v MySQL databázi.
4.1.5.
Dynamické generování HTML
Pro dynamické generování HTML stránek je možné použít několik serverových skriptovacích jazyků. V současné době mezi nepoužívanější patří jazyk PHP nebo ASP od společnosti Microsoft. Hlavním rozdílem mezi těmito dvěma řešeními je ten, že PHP je šířen pod licencí typu open-source a lze ho tedy jednodušeji provozovat na různých platformách. Dynamické generování HTML spočívá vložením PHP nebo ASP syntaxe přímo do HTML kódu. Po zpracování interpretem na straně serveru na daném místě získáme zpracovanou hodnotu. Příklad dynamické části kódu HTML: <meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
Aktuální čas Zavoláním této stránky v prohlížeči se nám zobrazí aktuální čas ve formátu Hodina:minuta:sekunda. Při obnovení stránky bude na bez jakékoliv změny zdrojového
29
kódu vypsán opět aktuální čas. Můžeme tedy tvrdit, že stránka se dynamicky generuje. V našem případě je její obsah závislý na čase [6].
4.2. PHP PHP (Hypertext Preprocessor) je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek. Nejčastěji se začleňuje přímo do struktury jazyka HTML, XHTML či WML, což je velmi výhodné pro tvorbu webových aplikací. PHP lze ovšem také použít i k tvorbě konzolových a desktopových aplikací. PHP skripty jsou prováděny na straně serveru, k uživateli je přenášen až výsledek jejich činnosti. Syntaxe jazyka kombinuje hned několik programovacích jazyků (Perl, C, Pascal a Java). PHP je nezávislé na platformě, skripty fungují bez úprav na mnoha různých operačních systémech. Obsahuje rozsáhlé knihovny funkcí pro zpracování textu, grafiky, práci se soubory, podporu pro práci s většinou databázových serverů. V PHP jsem naprogramoval celou aplikaci pro měření základních přenosových parametrů
připojení. Skripty v PHP zajišťují samotné měření přenosové rychlosti,
spolehlivosti, interpretují výsledek měření latence, pomocí SQL dotazů zajišťují komunikaci s databází – jak pro zápis naměřených hodnot, tak výpis hodnot uložených v databázi.
Obr. 6 – Třívrstvá architektura klient – server – databáze
4.3. Bash Bash - Bourne Again SHell je standardní interpret příkazů v Linuxu založený na Bourne shell. Funguje jako rozhraní mezi uživatelem a systémem. Jelikož je součástí GNU projektu, je portován na všechny unixové systémy. Propojením s jazykem PHP pomocí spustitelných souborů bych docílil elegantního testování pingu. Po zavolání bashového skriptu s parametry testovaného cíle jsou zaslány ICMP pakety. Při návratu paketů zpět jsou parsovány do pole a vypsány jako výsledek testovací funkce. V případě timeoutu je testování považováno za neúspěšné – uživatel má zakázán příjem ICMP paketů.
30
4.4. MySQL databáze MySQL je databázový systém, vytvořený švédskou firmou MySQL AB, nyní většinu autorských práv vlastní Sun Microsystems. MySQL je multiplatformní relační databáze. Komunikace s ní probíhá pomocí jazyka SQL. Podobně jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s některými rozšířeními. Pro svou snadnou implementovatelnost na různé operační systémy, výkon a především díky tomu, že se jedná o volně distribuovaný software, má vysoký podíl na v současné době používaných databázích [15]. Mezi základní pojmy patří relace. Relaci, aniž by bylo potřeba zavádět jakékoliv matematické definice, si lze představit jako tabulku, která se skládá ze sloupců a řádků. Sloupce odpovídají jednotlivým vlastnostem (atributům) entity. Tabulka je základním stavebním kamenem pro budování celé databáze. Relace tedy odpovídá celé tabulce a prvku relace odpovídá jeden konkrétní řádek. Jeden řádek bývá často nazýván databázovým záznamem. Soubor tabulek (relací) pak tvoří celou databázi (relační schéma). Z výše uvedených důvodů je patrné, ze vhodné navržení tabulek je základním stavebním kamenem každého databázového systému a každá chyba potom může značně komplikovat vývoj aplikace nebo její funkčnost. Strukturu databáze aplikace jsem navrhl s 5 tabulkami – users, mereni, pm, prihlaseni, fronta. Tabulka users – uchovává informace o registrovaných uživatelích, unikátní login, heslo, jméno, příjmení, e-mailovou adresu, aktivační klíč, pomocí kterého nově registrovaný uživatel aktivuje svůj účet, úroveň oprávnění – jedná se o uživatele nebo administrátora, čas registrace, zda-li si uživatel přeje zveřejňovat svá měření a jestli již účet aktivoval a má povoleno přihlášení nebo nikoliv. Tabulka mereni – obsahuje záznamy měření jednotlivých parametrů připojení – downstream, upstream, latenci, stabilitu, IP adresu uživatele, čas kdy bylo měření provedeno. Tabulka pm – registrovaní uživatelé mají možnost si mezi sebou posílat privátní zprávy, které jsou uloženy v této relaci, atributy jsou odesílatel zprávy a příjemce, předmět, text, čas odeslání, přečtení zprávy, smazání do koše a úplné smazání.
31
Tabulka fronta – určena pro vytváření fronty při měření, obsahuje id uživatele, velikost přenášených dat downstreamu a upstreamu, čas zahájení měření. Tabulka prihlaseni – jedná se o logovací tabulku, do které se při přihlášení registrovaného uživatele zapíše datum a čas.
Obr. 7 – ERD - entitně relační diagram – struktura tabulek databáze
32
5.
Řešení webové aplikace
Po dokončení návrhu struktury databáze a algoritmů jsem přistoupil k programování. V mnoha případech se algoritmy po teoretické stránce správné ukázaly jako nefunkční nebo zatížené značnou chybou při měření. Bylo zapotřebí je upravovat a výsledný webový program ladit v praxi na různých typech připojení do Internetu. Existují sice nástroje pro omezení šířky přenosového pásma na aplikační vrstvě, ale nedokážou nasimulovat dlouhou latenci, která je zvláště velká u připojení typu GPRS/EDGE. Postupným vývojem se aplikaci podařilo odladit a výsledky měření se dají považovat za přesné.
Obr. 8 – Funkční schéma webové aplikace
5.1. Měření přenosových parametrů Aplikace umožňuje měření čtyř přenosových parametrů připojení do Internetu – downstream, upstream, latence, rozptyl rychlosti připojení. Každý z uvedených parametrů je naprogramován jako funkce. Uživatel si vybere, které z těchto parametrů chce měřit a po zahájení měření jsou volány jednotlivé funkce.
33
Obr. 9 – Hlavní stránka aplikace
5.1.1.
Downstream
Princip funkce zajišťující měření přenosové rychlosti směrem od serveru k uživateli spočívá ve stažení souboru známé velikosti ze serveru a změření času, za který byl soubor stažen. Na základě těchto dvou informací potom vypočítáme rychlost, jakou byl soubor stažen. Aplikace je navržena tak, aby umožňovala měření různých typů připojení do Internetu od modemového připojení typu Dial-UP nebo mobilní GPRS/EDGE přes PCL, DSL linky až po vysokorychlostní sítě. Aby měření vykazovalo relevantní výsledky a zároveň netrvalo příliš dlouho, provedeme nejprve měření stažením referenčního souboru o velikosti 30kB. Získáme tak orientační přenosovou rychlost uživatele. Podle doby, za jakou byl referenční soubor stažen se určí, jak velkým souborem provedeme hlavní měření.
34
Doba stažení referenčního souboru 30 kB
Velikost souboru pro měření
Více než 6000 ms
32 kB
6000 ms až 1600 ms
64 kB
1600 ms až 200 ms
512 kB
200 ms až 24 ms Rychleji než 24 ms
5000 kB 20000 kB
Tabulka 1 – Varianty velikostí souborů pro hlavní měření Při zahájení měření je funkcí v JavaScriptu zavolána adresa s vybranou velikostí souboru a zároveň je zaznamenán čas, kdy měření začalo. Samotné měření probíhá stažením souboru, který je předán v HTML tagu <iframe> jako unikátní adresa s využitím modulu webového serveru Apache mod_rewrite (podstrčení obsahu v URL). Tím je ošetřeno případné uložení staženého souboru do cache prohlížeče a zajištění relevantnosti výsledku. Po dokončení stažení souboru je opět funkcí v JavaScriptu zaznamenán čas, kdy měření bylo dokončeno. Čas započetí měření a ukončení od sebe odečteme a zjistíme tak dobu měření. Podle zvolené velikosti souboru potom jednoduše vypočítáme rychlost, jakou byl soubor stažen.
5.1.2.
Upstream
Algoritmus funkce pro měření přenosové rychlosti směrem od uživatele k serveru je obdobný jako u měření downstreamu. Podle orientační rychlosti odeslání referenčního objemu dat se zvolí, jaké množství dat bude na server odesláno při hlavním měření. Princip je založen na zaslání formuláře od uživatele na server. Ve formuláři je obsažen skrytý input element (type="hidden"). Jeho velikost určujeme na základě vykonání referenčního měření. Abychom byli schopni spustit stopky v čase zahájení odesílání dat na server, je potřeba formulář umístit do vloženého rámce (iframe) a nastavit tomuto HTML tagu parametr onload - t.j. po kompletním načtení všech elementů daného rámce do prohlížeče. V parametru onload figuruje zavolání JavaScriptové funkce, která zapíná stopky a automaticky odesílá formulář na server. Pro referenční soubor je to velikost 30kB, pro hlavní měření jsou varianty velikostí odesílaných dat shodné jako u downstreamu – tabulka 1. Naplněný formulář odešleme na server. Po dokončení odeslání dat opět zaznamenáme aktuální čas a vypočteme dobu odesílání, ze které zjistíme skutečnou přenosovou rychlost.
35
5.1.3.
Latence
Cílem dalšího testu je najít zpoždění - velikost latence. Použitím protokolu ICMP je ze serveru k uživateli zaslána příkazem ping sada 4 paketů. Za latenci je považován průměr ze zaslaných 4 paketů. Protože je tento test prováděn zasíláním ICMP paketů ze strany serveru, je nutné aby měl uživatel povolen příjem ICMP paketů. Pokud má ICMP pakety blokovány na firewallu nebo na routeru, test se považuje za neúspěšný a latenci nelze určit.
5.1.4.
Rozptyl
Přenosové parametry připojení do Internetu často značně kolísají. Abychom vyjádřili, jak je připojení stabilní, pětkrát za sebou stáhneme ze serveru soubor o velikosti odpovídající rychlosti připojení (10kB nebo 64kB). Velikost tohoto testovacího souboru je vybrána na základě předchozích měření. Jestliže měření dowstreamu a upstreamu neprovádíme, je zvolena velikost 10kB. Měření je realizováno funkcí v JavaScriptu a provádí se na relativně malé velikosti souborů. Je proto zatíženo chybou a lze ho považovat spíše za orientační. Ze získaného vzorku přenosových rychlostí je zapotřebí spočítat, jak velké jsou výkyvy rychlostí u jednotlivých měření. Při vývoji aplikace jsem se snažil navrhnout optimální vzorec, který by vyjadřoval stabilitu připojení v procentech. Ani po značné snaze se nepodařilo vzorec zoptimalizovat tak, aby výsledná hodnota měla vypovídající charakter. Rozhodl jsem se
tedy použít již existující statistickou funkci rozptyl
vyjádřenou v procentech, která vyhovuje požadavku. Jedná se o charakteristiku variability rozdělení pravděpodobnosti náhodné veličiny, která vyjadřuje variabilitu rozdělení souboru náhodných hodnot kolem její střední hodnoty.
5.1.5.
Fronta měření
Aby bylo možné eliminovat přesnost měření vzniklou přetížením serveru, aplikace obsahuje frontu měření. Při zahájení měření se zjišťuje, zda-li není fronta plná na základě sečtení právě probíhajícího přenosu pro aktuálně měřené uživatele. V případě, že pro měření je volná kapacita, je zahájeno měření uživatele. Do doby, než dojde k měření uživatele se stránka obnovuje každých 5 vteřin. Po uvolnění fronty je zahájeno měření a do tabulky v databázi je zapsán záznam popisující uživatelovo měření. Po dokončení měření je záznam z tabulky právě probíhajících měření smazán. Je ošetřena i situace, kdy uživatel zavře okno prohlížeče během měření. V takovémto případě je uživatelův záznam smazán z tabulky právě probíhajících měření po uplynutí doby delší než 5 minut.
36
5.2. Výpis uskutečněných měření Každé dokončené měření je vypsáno uživateli na stránku, ale je také vloženo do databáze. Na hlavní stránce aplikace se zobrazuje výpis posledních 10 uskutečněných měření, kde jsou vypsána měření registrovaných uživatelů, kteří mají nastaveno, že jejich měření jsou veřejná, a rovněž měření neregistrovaných uživatelů. Jako neregistrovaný uživatel si můžeme také prohlížet stránku s uskutečněnými měřeními. Jedná se totožný výpis, který ale není omezen posledními 10 měřeními. Je stránkován po 50 měřeních. Stránkování je inteligentně vyřešeno a stránky se dynamicky vypisují právě kolem nakliknuté stránky. Nemůže tedy časem dojít k zahlcení stránky výpisem počtu stránek, které by vedlo k rozbití HTML layoutu. Registrovaní uživatelé mají v menu položku „Uskutečněná měření“. Jedná se o výpis jimi uskutečněných měření. Výpis položek je také stránkován. Rozšířením je možnost filtrování si zobrazení pouze měření uskutečněných za poslední 2 hodiny, 4 hodiny, 12 hodin a 24 hodin. Stránkování se po nastavení filtru upraví. Každou položku výpisu je možné z databáze smazat v případě přihlášení s administrátorským účtem.
Obr. 10 – Výpis uskutečněných měření
37
5.3. Posílání soukromých zpráv Rozšířením oproti zadaní je posílání soukromých zpráv. Každý registrovaný uživatel může jinému registrovanému uživateli zaslat zprávu, která obsahuje předmět a text. Všechny textové formuláře jsou ošetřeny proti pokusu o útok na aplikaci pomocí SQL injection – jedná se techniku napadení databázové vrstvy programu vsunutím kódu přes neošetřený vstup a vykonání vlastního, pozměněného, SQL dotazu. Zprávy jsou členěny do standardních složek - přijaté (Inbox), odeslané (Sent), smazané (Deleted). Při zvolení položky „Soukromé zprávy“ se dostaneme automaticky do přijatých soukromých zpráv (Inbox). Pro jednoznačné rozlišení nově příchozích zpráv je výpis barevně nastylován pomocí kaskádových stylů CSS. Nové nepřečtené zprávy jsou podbarveny a podle počtu nových zpráv se dynamicky mění i název odkazu pro soukromé zprávy. Se zprávami lze realizovat standardní operace jako je odpovědět na příchozí zprávu nebo ji vymazat. Uživatelem odeslané zprávy se automaticky ukládají do složky odeslaných zpráv (Sent). Aby Inbox nebo Sent nezůstával zahlcen množstvím zpráv, uživatel má možnost si zprávy mazat. Při smazání je zpráva přesunuta do složky smazaných zpráv (Deleted). Postupem času může uživatel zhodnotit, že zprávu již nemá smysl uchovávat ani mezi smazanými. Může ji tedy odstranit i odtud. V databázi se nastaví, že zpráva je smazaná úplně a uživateli se již nikdy nezobrazí. Z důvodů evidence a případného dohledávání ze strany administrátora však zprávy v databázi zůstávají.
Obr. 11 – Rozhraní pro soukromé zprávy
38
5.4. Registrace uživatelů Pokud uživatel chce využít všech možností, které aplikace nabízí, musí se zaregistrovat. Registrací uživatel získá přehled o pouze jím provedených měřeních, může si nastavovat, zda-li jsou jeho měření veřejná pro ostatní uživatele a může ostatním registrovaným uživatelům zasílat soukromé zprávy. Rozšířením pro registrované uživatele je možnost nastavení, jakou velikostí souboru bude probíhat hlavní měření downstreamu a upstreamu z předem nadefinovaných variant (32kB, 64kB, 512kB, 5MB, 20MB). Pokud uživatel zvolí velikost souboru, není prováděno referenční měření. Při registraci je uživatel povinen vyplnit uživatelské jméno – login, heslo, jméno a příjmení, e-mailovou adresu a nastavení, jestli jsou jeho měření veřejná nebo nikoliv. Tuto volbu lze samozřejmě, jako i všechny ostatní osobní údaje, kromě loginu, kdykoliv změnit v části „Osobní údaje“ po přihlášení. Po potvrzení údajů zadaných do políček formuláře se na serveru ověří, jestli vyplněné přihlašovací jméno již neexistuje, shodujíli se obě položky hesla. Stejně tak je ověřen správný formát e-mailové adresy, na kterou je zaslán e-mail, regulárním výrazem. Pro aktivaci účtu, abychom se mohli přihlásit a pracovat s aplikací, je zapotřebí potvrdit registraci. V zaslané e-mailové zprávě je odkaz, který obsahuje unikátní klič vytvořený při registraci. Po kliknutí na tento odkaz se účet aktivuje a můžeme se přihlásit do systému.
Obr. 12 – Vygenerovaný e-mail pro potvrzení registrace 39
5.5. Účet administrátora U každé aplikace, která pracuje s větším množstvím dat a údajů je vhodné, aby existoval administrátorský účet. Zjednoduší se tím správci práce, že se nemusí přihlašovat přímo databáze, ale může se všemi daty pohodlně pracovat přes webové rozhraní. Pokud se přihlásíme s administrátorským účtem, v menu se nám zobrazí nová položka „Stav registrací“. Jedná se o výpis nových, doposud nepotvrzených, uživatelských registrací. Máme možnost registraci potvrdit a účet aktivovat bez toho, aniž by uživatel musel potvrdit aktivaci zaslanou prostřednictvím e-mailu nebo založenou registraci smazat. Po smazání se účet neaktivuje ani v případě potvrzení e-mailu, který byl uživateli zaslán. Ve výpisu uskutečněných měření administrátor vidí všechna uskutečněná měření od všech, kteří aplikaci pro měření použili. Jak registrovaní uživatelé, tak i neregistrovaní. Výpis je stránkován po 15 měřeních. Stránkování je inteligentně vyřešeno a stránky se dynamicky vypisují právě kolem nakliknuté stránky. Nemůže tedy časem dojít k zahlcení stránky výpisem počtu stránek, které by vedlo k rozbití HTML layoutu. Je možné si také výpis filtrovat na zobrazení pouze měření uskutečněných za poslední 2 hodiny, 4 hodiny, 12 hodin a 24 hodin. Stránkování se po nastavení filtru upraví. Každou položku výpisu je možné z databáze smazat.
40
6.
Závěr
Cílem bakalářské práce bylo prostudovaní a popis základní metody měření přenosových parametrů datových sítí založených na IP. Vycházel jsem především ze standardů RFC, podle kterých se řídí většina internetových protokolů. Jednotlivé postupy pro testování jsou popsány v RFC 2544. Na základě rozboru parametrů jsem navrhl koncepci a realizoval webovou aplikaci, která umožňuje orientačně zjišťovat základní přenosové parametry připojení do Internetu. Těmito parametry je přenosová rychlost stahovaného souboru ze serveru směrem k uživateli (downstream), přenosová rychlost odesílaného souboru směrem od uživatele na server (upstream), zpoždění komunikace přenášených dat mezi serverem a uživatelem (latence) a informace vypovídající o stabilitě připojení (rozptyl). Webová aplikace je naprogramována tak, aby na straně uživatele nevyžadovala instalaci žádných doplňků ani modulů. Je postavena na serverovém programovacím jazyku PHP s využitím relační databáze MySQL, ve které jsou uchována data a klientském skriptovacím
jazyku
JavaScript.
Vlastní
měření
přenosových
rychlostí
je
zoptimalizováno vzhledem k typu a rychlosti daného připojení. Aplikace umožňuje měření návštěvníkům i registrovaným uživatelům, samozřejmostí je také registrace uživatelů s následnou aktivací účtu kliknutím na potvrzovací odkaz v automaticky zaslaném emailu. Všechna uskutečněná měření jsou ukládána a registrovaný uživatel má možnost si prohlížet jejich historii s možností filtrování výpisu. Rozšířením oproti zadaní je posílání soukromých zpráv mezi registrovanými uživateli. Nad celou aplikací existuje administrátorský účet. Stanovený cíl bakalářské práce byl splněn ve všech ohledech, přesto by však do budoucna bylo možné zlepšit přesnost měření rozptylu připojení, která je pouze orientační. Aplikace by rovněž poskytovala vyšší komfort v případě zakomponování možnosti pro automatické vícenásobné proměření jednotlivých směrů připojení a následného výpočtu průměrné rychlosti. Výsledkem by byly přesnější hodnoty.
41
Literatura [1] FEIBEL, W.: Encyklopedie počítačových sítí, Computer Press, 1996, ISBN 8085896-67-2. [2] BRANDER,
S.
RFC
1242:
Benchmarking
Terminology
for
Network
Terminology
for
Network
Interconnection Devices, IETF, 1991. [3] BRANDER,
S.
RFC
1944:
Benchmarking
Interconnection Devices, IETF, 1996. [4] BRANDER, S. RFC 2544: Benchmarking Methodology for Network Interconnect Devices, IETF, 1999. [5] DOSTÁLEK, L., KABELOVÁ, A.: Velký průvodce protokoly TCP/IP a systémem DNS Computer Press, Praha, 2000 [6] KOSEK, J. PHP - Tvorba interaktivních internetových aplikací. Grada Publishing, Praha, 1999 [7] Aplikace
pro
měření
rychlosti
[online],
dostupné
na
URL:
http://www.dsl.cz/mereni-rychlosti [8] Aplikace pro měření rychlosti [online], dostupné na URL: http://rychlost.cz [9] Aplikace
pro
měření
rychlosti
[online],
dostupné
na
URL:
http://nastroje.lupa.cz/mereni-rychlosti/ [10] HOULETTE, F. SQL příručka programátora. SoftPress, Praha, 2001 [11] HERNANDEZ, M. Návrh databází. Grada Publishing, Praha, 2005 [12] Informační portál interval.cz [online], dostupné na URL: http://interval.cz/ [13] POŠMURA, V. Apache, příručka správce WWW serveru. Computer Press, Praha, 2002 [14] PÍSEK, S. JavaScript, efektní nástroj oživení WWW stránek. Grada Publishing, Praha, 2001 [15] ŠIMŮNEK, M. SQL kompletní kapesní průvodce. Grada Publishing, Praha, 1999 [16] Server s dokumenty RFC [online], dostupné na URL http://www.ietf.org/rfc.html
42
