Optimalizace přenosových parametrů pro satelitní spojení

1. Úvod do problematiky:

Satelitní spoje obecně „trpí“ přenosovým zpožděním, které odpovídá komunikaci na vzdálenost cca 2 x 38 400 km (komunikace mezi dvěma body v ČR přes satelit KA-SAT na pozici 9°E) při rychlosti světla. Kdyby na stejnou vzdálenost komunikovala stejná zařízení přes kanál se stejnou datovou propustností na optickém nebo metalickém vedení, bylo by zpoždění téměř o 1/3 větší, protože by se energie šířila výrazně pomaleji, než je tomu ve volném prostoru. V praxi má ale satelitní spojení o několik set ms větší zpoždění, než pozemní spoje.

S tím samozřejmě některé přenosové protokoly navržené v minulém století (TCP/IP z roku 1969) nepočítají, a proto mohou výrazně brzdit přenos. Jde o parametr „TCP windows size“, tedy max. objem dat, který lze přenést bez potvrzení. Ten je standardně v OS Windows nastaven na 64 kB (512 kbit). U routeru Cisco to je jen 4128 B (32 kbit). Pokud při přenosovém zpoždění na sdíleném satelitním kanálu je dosahována hodnota RTT (odezva na ping) např. 800 ms, bude max. dosažitelná přenosová rychlost 512/0,8 = 640 kbit/s, protože až po přijetí potvrzovacího paketu za 800 ms může vysílací strana pokračovat v odesílání dat. Reálná rychlost je vždy menší, protože vlivem velikosti souboru a délky paketu (MTU) dojde obvykle k odesílání posledního paketu každého bloku 64 kB v neúplné velikosti (64000/1500=42,6667 – tedy 42 paketů délky 1500 B a 1 paket délky 1000 B). Pokud ale nebude navíc odpovídat délka uživatelského paketu délce satelitního paketu, dojde buď ke snížení využití efektivity satelitního kanálu (aplikační paket kratší než satelitní) nebo k fragmentaci aplikačních paketů, což zvýší jejich počet pro přenos přes satelit a zvětší objem přenášených dat. Proto je třeba upravit hodnoty TCP windows size a MTU tak, aby odpovídaly parametrům přenosového kanálu (rychlosti a zpoždění – nesmí se nastavovat max. hodnota, protože při ztrátě paketu by bylo nutno opravovat zbytečně veliký blok dat). To lze někdy udělat na terminálu, málokdy ale na serveru. Potom i při symetrickém přenosovém kanálu budou dosahovány výrazně asymetrické přenosové rychlosti. Je jasné, že každá ztráta paketu a opakování odeslání bloku se na aplikační vrstvě projeví dalším výrazným zpomalením.

Výrobci satelitních systémů s tím počítají, a proto jsou obvykle v terminálech i na HUBu instalovány nástroje k eliminaci přenosového zpoždění, tzv. IP akcelerátory, které dokážou TCP komunikace výrazně urychlit i bez zásahu do nastavení uživatelských terminálů a jiných prvků v síti. Jde např. o přenos přes satelit bez potvrzení nebo s velkým TCP windows size a lokálním potvrzováním satelit-terminál, stejně jako např. o techniku načítání webových stránek stanicí HUB a odesláním na terminál místo toho, aby si objekty na stránkách „říkal“ počítač standardní technikou po několika objektech, čímž se ušetří mnoho satelitních skoků. Spojení potom dokáže využít plnou přenosovou kapacitu satelitního kanálu. Každý výrobce má vlastní způsob akcelerace.

Horší to je v případě šifrovaného přenosu, typicky v IP tunelu. Akcelerátory v tom případě „nevidí“ záhlaví IP paketů a akcelerace není možná. Přenosová rychlost odpovídá TCP windows size a zpoždění na trase, další výrazné omezení může být způsobeno nevhodným nastavením MTU a tokovými kontrolami samotné aplikace.

Co udělá MTU na šifrovaném kanále? Pokud je používáno MTU např. 1500 B, pak vlivem GRE enkapsulace dojde k přidání 24 B a paket musí být rozdělen na dva. Každý bude mít kromě dat ještě 20 B IP hlavičku a 24 B GRE hlavičku. Účinnost přenosu tím dále klesá. V případě TCP windows size 64 kB a MTU 1500 B bude místo 42 celých paketů 1500 B a jednoho kratšího odesláno přes GRE 42 celých a 43 kratších paketů, tedy 2x tolik.

Určitým řešením je použití VPN protokolů pracujících na UDP místo TCP. Tím lze eliminovat vliv TCP windows size, UDP protokol ale není přes satelit „akcelerován“, aplikace proto nedokáže využít plnou kapacitu satelitního kanálu. Spojení založené na IPSec by naopak akceleraci mělo dokázat využít. Jak bude který protokol „běhat“ rychle přes satelit se nedá předem určit. V síti je obvykle více prvků, které mohou výsledek ovlivnit. Nejlépe je použít diagnostický nástroj na zjištění optimálního hodnoty TCP windows size vzhledem k přenosové kapacitě kanálu a MTU, aby nedocházelo ke zbytečné fragmentaci paketů. Obecně lze říci, že vlivem VPN a nevhodného nastavení může dojít ke snížení přenosové rychlosti o 50 až 90% z max. přenosové kapacity. Každá VPN se chová trochu jinak. Základem je ale obecně zjištění optimálního nastavení MTU a v případě komunikací založených na TCP i optimalizaci TCP windows size.

Níže uvádím několik příkladů rychlosti satelitního přenosu podle protokolu nebo aplikace:

Příklad: test přes satelit kasat s rychlostí stahování max. 10 Mbit/s

• download internet, bez VPN – reálná kapacita cca 7,2 Mbit/s

download VPN, koncept GRE over IPSec, nutno vypnout keepalive na tunelu – reálná kapacita 2 Mbit/s

• download VPN, koncept EzVPN – reálná kapacita 600 kbit/s

Při testech je nejhorších výsledků dosahováno ve VPN na SSL. Obvykle jen desítky kbit/s při odesílání dat z terminálu na server a stovky kbit/s při stahování dat ze serveru na satelitním kanálu s kapacitou v Mbit/s. Lepší výsledky dává IPSec na TCP a ještě lepší IPSec na UDP.

Ještě horší výsledky ale poskytují některé šifrované aplikace. Nejpomalejší a pro satelit nejméně vhodnou aplikací pro komunikaci PC-PC je vzdálená plocha. Na satelitním kanálu 512 kbit/s běhá na rychlosti kolem 10 kbit/s. Na stejném kanálu dosáhneme s VNC a TeamViewer kolem 30 až 50 kbit/s.

 

2. Možnosti řešení:

2.1   TCP windows size:

o   Podle požadované přenosové rychlosti a změřeného zpoždění na ping – RTD, RTT upravit TCP Windows size

• Příklad pro rychlost 10 Mbit/s, RTD 800 ms 10 000 x 0,8/8 = 1 000 kB

o   Je tedy třeba upravit v registrech hodnotu RWIN z původních 64 na 1 000 kB  – ale pozor, novější verze Windows to již nemusí umožňovat ..

• Pro PC s OS Windows lze nástroj pro optimalizaci stáhnout z http://www.speedguide.net/files/TCPOptimizer.exe
• V PC s OS Linux lze upravit hodnoty pomocí:
• 1. /proc/sys/net/ipv4/tcp_window_scaling; Set „1“ to activate window scaling option(RFC 1323)
• 2. /proc/sys/net/ipv4/tcp_timestamps; Set „1“ to activate timestamps
• 3. /proc/sys/net/core/rmem_max; Set maximum size of TC receive window.
• 4. /proc/sys/net/core/wmem_max; Set maximum size of TCP transmit window.
• 5. /proc/sys/net/core/rmem_default; Set default size of TCP receive window.
• 6. /proc/sys/net/core/wmem_default; Set default size of TCP transmit window.

 

• V routeru lze upravit hodnoty pomoci : Router#conf t a dále Router(config)# ip tcp window-size 1 000 000 – jednotka je B
• Další možností je použít protokol UDP, který není brzděn čekáním na potvrzovací pakety. Záleží ale na aplikaci, zda je možné si protokol zvolit.

2.2   MTU:

Nejjednodušší metodou k e zjištění max. délky paketu, který projde k cíli bez fragmentace je použití nástroje ping s parametrem –f , který zakazuje fragmentaci. Podmínkou ale je, aby v cestě nebo cílem nebylo zařízení, které má zákaz odpovídat na ping – tedy pakety ICMP (Internet Control Message Protocol). Standardní velikost paketu je 1500 B. Vlivem šifrování nebo nastavením některého prvku v síti ale tato velikost může přesáhnout max. MTU.  Některé aplikace si zjišťují průchodnost sítě před započetím komunikace.

Zjistit optimální nastavení MTU lze opět pomocí programu TCP optimizer.

Ručně to můžeme zjistit v několika krocích podle příkladu níže:

Ping www.google .cz –f –l  1472

• místo názvu domény lze použít IP adresu, pokud ji známe
• -f zakazuje fragmentaci
• -l xxxx udává délku testovacího paketu

Příkaz PING na www.google.cz [173.194.35.87] – 1472 bajtů dat:

Odpověď od 173.194.35.87: bajty=1472 čas=11ms TTL=58

Odpověď od 173.194.35.87: bajty=1472 čas=22ms TTL=58

Odpověď od 173.194.35.87: bajty=1472 čas=12ms TTL=58

Odpověď od 173.194.35.87: bajty=1472 čas=13ms TTL=58

 

Statistika ping pro 173.194.35.87:

Pakety: Odeslané = 4, Přijaté = 4, Ztracené = 0 (ztráta 0%),

Přibližná doba do přijetí odezvy v milisekundách:

Minimum = 11ms, Maximum = 22ms, Průměr = 14ms

 

Příkaz PING na www.google.cz [173.194.35.87] – 1475 bajtů dat:

Paket musí být fragmentován, je však nastaven příznak DF (nefragmenovat).

Paket musí být fragmentován, je však nastaven příznak DF (nefragmenovat).

Paket musí být fragmentován, je však nastaven příznak DF (nefragmenovat).

Paket musí být fragmentován, je však nastaven příznak DF (nefragmenovat).

 

Statistika ping pro 173.194.35.87:

Pakety: Odeslané = 4, Přijaté = 0, Ztracené = 4 (ztráta 100%),

 

Je vidět, že paket s délkou 1472 bajt sítí projde, ale 1475 bajt by již bez fragmentace nemohl být sítí přenesen. Těch několik bajtů navíc by si vyžádalo další paket, který by ale obsahoval kromě záhlaví jen těch pár chybějících bajtů a snížil by tak účinnost přenosu asi na 50%.

Následně je třeba na hraničních routerech, případně na zdrojovém zařízení, nastavit MSS (Maximum Segment Size) na hodnotu, která nevyžaduje cestou v síti fragmentaci.

 

2.3   VPN:

• Uživatel se obvykle připojuje do již existující VPN a nemá tak příliš na výběr.Pokud je zabezpečené připojení realizováno tunelem mezi tzv. hraničními routery, pak na koncovém PC není co nastavovat kromě TCP Windows size.  Je spíše na správci routeru, aby nalezl optimální nastavení pro satelitní přenos. Pokud je koncovým zařízením např. videokamera, je možné laborovat s protokolem pro odesílání paketů s cílem najít ten nejefektivnější, resp. nejrychlejší. Protože pakety v tunelu nelze na satelitu akcelerovat, měl by dát lepší výsledek protokol UDP než TCP, odeslání dat můžou brzdit streamovací protokoly s kontrolou doručení paketů a zjišťováním průchodnosti trasy.
• Pokud se uživatel satelitního připojení připojuje do VPN pomocí klienta na pracovní stanici, může mít na výběr mezi protokoly TCP a UDP. Např. IPSec/TCP nebo IPSec/UDP. Je třeba vyzkoušet, který typ dá pro danou aplikaci lepší výsledek, resp. přenosovou rychlost.