Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Charakteristiky síťových připojení
červen 07
Charakteristiky síťových připojení

Zrovna před pár dny jsem jednal s technickou podporou svého domácího internetového připojení od UPC a zase jsem narazil na hooodně neoblomné představy o tom, jaké charakteristiky má síťové připojení a jak je měřit.

Měl jsem problém se vzdálenou plochou. Tuhlo to, zasekávalo se to a padalo. Začalo to dělat najednou a trvalo to nějakou hodinu, tak jsem si řekl, že zavolám na support, jestli třeba něchtějí někde něco restartnout.

Pánovi jsem řekl, že mají nerovnoměrné zpoždění a hrozně výpadků paketů. Řekl jsem mu kde přesně. To jsem si sám změřil. Pán mě ale nechal změřit šířku pásma pomocí nějakého webového měřáku, která byla samozřejmě v pořádku. Tradá. U nás všechno ok, trhněte si.

Tak si pojďme udělat bleskovou osvětu.

Šírka pásma není konec světa

Většina lidí vidí na internetovém připojení jenom jeho šířku pásma. Teda myslím tím ty magabity, které vám každý prodává. Poskytovatelé se předhání v tom, kolik kdo má megabitů a zdá se, že když nemáte doma víc megabitů, než kamarád, tak jste v partě nula.

To je ale jen jedna charakteristika, která je zajímavá tak akorát kvůli stahování filmů. Pro firemní prostředí je to informace obvykle v celku na nic.

Tři charakteristiky sítě, které byste měli znát

Síťová připojení mají moooc různých charakteristik, my se tu budeme zabývat jen třemi vééélmi základními. A budu do toho shrnovat dokonce víc charakteristik souvisejících.

  • šířka pásma (bandwidth, obvykle rychlost, neboli průtočnost, jak tomu říká moje mamka) - měří se to například v Kbps, nebo Mbps. A udává to objem dat, který jste schopno protlačit linkou v jednom směru, když to do ní budete hustit pod tlakem. Je to vlastně velikost trubky. Do tlustší trubky se vleze víc vody. Do tunelu s více pruhy se vleze víc aut současně.
    To je relativně důležité pro stahování velkých objemů dat, jako jsou filmy, virtuálky a databázové soubory, nebo backupy. Zpočítáte z toho například, za jak dlouhou dobu se takový soubor stáhne. Když jsem například schopen do tunelu strčit 3 auta za sekundu, tak za minutu jich tam nacpu 180.
    Podniková data ale obvykle nejsou tak veliká, aby to byla podstatná charakteristika. Z databází stahujete do aplikací data v řádech KB, soubory Wordu jsou o velikostech máááximálně několika MB (pokud tedy zase paní Kovaříková neposílá svoje fotky a videa z dovolené). Takže stáhnout takový soubor je chvililinka, i pokud máte linku jen třeba 1 Mbps.
  • zpoždění (latency, round-trip-time RTT) - se měří obvykle v milisekundách (ms), v horším případě v sekundách. Tuhle informaci uvidíte například ve výstupu příkazu PING. Jedná se o dobu, za jakou auto projede tunelem - v případě RTT tedy dobu, za jakou projede tunelem tam a zpět včetně režie na otočení.
    Pro velká data tohle moc nehraje roli. Jestliže víme, že tunel z předchozího příkladu je dlouhý třeba 5 sekund, a přitom jsme schopni tam tlačit 3 auta za sekundu, tak těch 180 aut přepravíme za 65 sekund. Takže nepodstatný rozdíl.
    Jenže pro podnikové aplikace je to velmi podstatné. Protokoly sdílených souborů (SMB), SQL, nebo RPC a DCOM jsou velmi ukecané. Na rozdíl třeba od HTTP. Na to, abyste si přes HTTP stáhli video, potřebujete zaslat vy cca 3 požadavky na jejichž odpovědi čekáte a potom už jen přijímáte pod tlakem to video. Takže jestliže je RTT mezi vámi a web serverem například 50 ms, tak ty úvodní 3 požadavky budou trvat 150 ms a pak už vám fičí film podle šířky pásma.
    Podnikové aplikace jsou na tom jinak. Jen k tomu, abyste se podívali na obsah sdíleného adresáře (bez ohledu na to, kolik je v něm souborů), musíte si se serverem pohovořit na 80 a více RTT. Jsou to malinké pakety, ale je to hodně otoček. Jakobyste do tunelu posílali jeden malinký pomalý náklaďáček, který prostě musí projet tam a zpět 80krát. Například s šířkou linky 2 Mbps si soubor Wordu o velikost 100 KB stáhnete za 400ms. To je blik. Ale ještě předtím musíte hovořit 80 x 50ms = 4 sekundy, jenom abyste se přihlásili a přečetli si atributy. Tahle ukecaná režie strašlivě závisí na latency a nikoliv na šířce pásma.
  • ztrátovost (packet loss rate PLR) - hodnotí, kolik paketů se ztratí při přenosu nějakého počtu paketů. Udává se to tedy v kusech, nebo bajtech. V kusech za sekundu, nebo spíš v kusech třeba na milión přenesených paketů, nebo třeba v B/GB.
    Tohle zase není důležité pro velké soubory. TCP protokol všechno, co se ztratí, přepošle znovu. Přeposílka nastává po 2 sekundách, jestliže paket nedorazil. Takže každý přenos velkého souboru bude trvat nejhůře o 2 sekundy déle, než kdyby se nic neztrácelo (za předpokladu, že se neztratí nic z přeposlaných paketů).
    Ale je to důležité pro real/time aplikace. Například hlas, nebo obraz, v podnikovém prostředí vzdálená plocha (terminal services, remote desktop services, RDP). Vemte si, že na přenos obrazu a hlasu potřebujete plynulý tok paketů. Může to chvilku trvat, než se můj hlas dostane na druhou stranu. Ale potřebuju, aby se tam všechny pakety dostaly po stejné době, ve stejném pořadí. Jestli se něco ztratí a vy to přepošlete po 2 sekundách, na druhé straně budou znít některá slova v opačném pořadí.
    Multimédia to mohou vyřešit například tím, že těch několik ztracených paketů prostě nepřeposílají a jednoduše je vyignorují. Bude horší kvalita, ale aspoň to nebude přeskakovat.
    Vzdálená plocha (RDP) si to ale dovolit nemůže. Když kliknu, musí se to stát. Nemůžete některá písmena z klávesnice jen tak vynechat, to by se uživatel posral. Jestli nějaký paket nedorazí, musí se přeposlat. Přeposílka trvá 2 sekundy. Obrazovka terminálu bude 2 sekundy tuhá.

Klasické dopady

Obvykle se setkávám s tím, že ve firmách jedou špatně sdílené soubory, SQL klientské aplikace a RDP přes nějaké "pomalé" linky. Zákazníci se to obvykle snaží řešit tím, že nakupují pořád "rychlejší" a "rychlejší" (rozuměj Mbps) linky a ono to pořád a pořád nepomáhá. To je tím, že sice dostávají širší tunel, ale ten je hrooozně dlouhý, nebo je v něm místo asfaltové vozovky píškoviště.

To, co vidíte na ADSL například, je tragédie pro intranetové aplikace. Hodně dobré ADSL je 50 ms. Když máte sklad, obchod, nebo pobočku na nějaké vesnici, máte 500 ms a horší. S tímhle vám SQL klienti ani sdílené soubory, přihlašování a zásady skupin (Group Policy) pojedou jen velmi pomalu. Je tam moc otoček a přitom skoro nic nepřenášíte.

Dá se to tedy nějak vyřešit? Ano, použijte vzdálenou plochu (RDP). Vzdálená plocha není ukecaná. Jeden klik tam, jeden obrázek, nebo text zpět. Pokud nemáte ztrátovost, vzdálená plocha je jednoznačně odpověď.

Ztrátovost na takových linkách je ale taky občas tragická. Máte agregaci. Když to zařízení neutáhnou, prostě začnou zahazovat. Stačí, aby se kámoš od vedle hodil marod a dal si stáhnout nějaký filmeček. A čučíte do vytuhlé apošky, RDPčko se seká, nebo přímo padá.

Řešení

Nejprve si to zanalizujte. Jakou máte šířku pásma? Skutečně vás tohle omezuje? Skutečně tu linku tak využíváte? Není to tím, že máte moc velkou latency (RTT)? A nemůže to být spíš ztrátovostí?

Řešením je pak přejít na jiný protokol. Použijte HTTP na stahování souborů (SharePoint) místo sdílených souborů. Přejděte na vzdálenou plochu (RDP), pokud máte moc dlouhé ms, ale při tom stabilní neztrátovost.

Je lepší RDP přes VPN, nebo přes RDP/TS Gateway?

Podle toho, jaké VPPodle toho, jaké VPN používáte. Jsou obecně dva typy. Nazval bych connection oriented>packet based. Třeba PPTP a SSTP jsou realizované pomocí spojení, buď přímo na TCP, nebo něčem podobném (GRE a PPTP). Zatímco L2TP, IPSec a DirectAccess jsou jen paketové.

Co to znamená? No paketové VPNky (L2TP, IPSec a DirectAccess) pouze šifrují skutečnou komunikaci, obalí to do svého paketu a vyšlou do sítě. Jestli se paket ztratí, VPN sama to neřeší. Proč by měla? Nejspiš stejně tunelujete uvnitř TCP, a to si potom ten paket přepošle samo. Pokud to nebylo TCP, je to jedno, ten vnitřní protokol je na to snad zvyklý (DNS, NTP, apod.). Takže charakteristika těchto tří VPN je stejná, jako toho normálního protokolu, který přenáší. A vůbec se to nemění, jestli je to zabaleno uvnitř VPN, nebo není.

Problém je s PPTP a SSTP. Tyhle dva protokoly mají vlastní connection oriented kanál, ve kterém si sami zajišťují vlastní potvrzení a zaručené doručení paketů. To znamená, že když vypadne VPN paket, sám PPTP, nebo SSTP protokol to přepošle. Jenže to koliduje s vnitřním TCP. Pokud vypadne jeden kus TCP uvnitř VPN paketu, přepošle to nejspíš i samo TCP. Vzniknout tak vlastně dvě přeposílky.

Protokolově to nevadí. Vadí to na ztrátových sítích (packet loss). Jeden výpadek by ještě nic neznamenal. Jenže jeden výpadek vlastně namnoží pakety. Výpadky jsou jen pravděpodobnostní míra. Ale pokud je najednou víc paketů, je vyšší pravděpodobnost, že zase nějaký vypadne. Když vypadne s vyšší pravděpodobností, zase se namnoží.

To je kladná zpětná vazba na výpadek, která to celé může zabetonovat. Dojde k zácucku. To znáte, když voláte do rádia a máte ho puštěné u telefonu, začne to pískat.

Potom padají RDP, sdílené soubory (SMB), odpojují se namapované disky, SQL klienti, Outlook apod.

Lepší jsou rozhodně paketové VPN jako je L2TP, IPSec nebo DirectAccess. Jen v případě RDP se to dá vyřešit ještě pomocí RD Gateway (TS Gateway). To není VPN, ale je to HTTPS (nechci říct tunelované), zašifrované a bezpečné RDP připojení, takže vlastně VPN nepotřebujete.

Je to lepší s IPv6?

Tak to těžko. IPv6 je jenom paketový protokol. TCP je úplně stejné. Žádná změna. Nedávno jsem slyšel chválu na IPv6 v souvislosti s DirectAccess. Tak to je přesně ono. Nejde o IPv6, ale o to, že DirectAccess běží na IPSec a to je jen paketová VPN.

Jak to změříte?

Round-Trip-Time (RTT) je krásně vidět v PINGu. Ping někdy neměří přesně tu službu a server, ktery měřit potřebujete, tak můžete použít například skript z mého nedávného článku.

Pokud potřebujete měřit ztrátovost, použijte čítač z Performance Monitor konzole zvaný TCPv4/Segments Retransmitted/sec.

Závěr

Nespoléhejte se na šířku pásma. To je zajímavé pro velké downloady a internet. V intranetu vás zajímá velmi round-trip-timetrong>RTT) a pro vzdálená připojení packet-loss-rate (PLR). Jako VPN VPN používejte raději IPSec, pro vzdálenou plochu rozhodně RD Gateway.

 

Comments

Re: Charakteristiky síťových připojení

Hezký článek...
Michal on 8.6.2012 10:05

Re: Charakteristiky síťových připojení

Peknej clanecek. Dobre jsem se zasmal u ztratovosti a RDP :-)
pipp on 8.6.2012 12:40

vliv zatížení na zpoždění

To taky každej neví, ale když internetovou rouru zacpete, tak zpoždění brutálně vyleze. Asi jako se nikdo nediví, že v páteční špičce může jet z centra Prahy na výpadovku hodinu, i když nebude zúžená vozovka :) Takže neměřit zpoždění na prázdno, ale v reálným provozu!

Zrovna nedávno jsem to zkoušel a při vytížení 50Mbit linky na 60% mi vylezlo zpoždení z jednotek ms na desítky ms, při větším vytížení na stovky ms!
Borek on 9.6.2012 0:03

Re: Charakteristiky síťových připojení

no to vypadá zřejmě na nějakou agregaci. prostě jak se ta zařízení začala přecpávat, tak to muselo vyřizovat i další požadavky od ostatních účastníků a šlo to dolů. ještě by to mohlo mít nějaké záměrné brždění - prostě když garantují propustnost, mohou sami ušetřit tím, že prodlouží latency a nikdo si nemůže stěžovat :-)
ondas on 10.6.2012 8:37

Re: Charakteristiky síťových připojení

Agregaci to nemá, je to garantovaná linka za krvavý peníze. Ale možná ji šiděj, to mě nenapadlo. Taky mě to překvapilo, čekal bych že se to projeví až při úplným zacpání linky, kdy budou požadavky sedět ve frontě. No brzo asi přejdem na 100Mbit optiku (taky garantovanou).
Borek on 10.6.2012 12:30

Re: Charakteristiky síťových připojení

Jo a ta současná linka je od GTS - bezdrát v licenčním pásmu. Možná to může hrát nějakou roli.
Borek on 10.6.2012 12:32

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments