IP síť pro multimédia – pověry a fámy

Rozhodli jsme se tento problém vyzkoušet a navrhnout řešení, které by vyhovovalo potřebám sdílení multimediálních titulů z jediného disku na serveru.

Na čem jsme testovali?
Testovací sestava byla navržena tak, aby vyhovovala průměrným nárokům (server HP ML 370 512MB RAM se zrcadlenými SCSI disky na 10 000 otáčkách za přibližně 80 000 Kč a pracovní stanice s procesory Intel Celeron, 256MB RAM za přibližně 20 000 Kč. Tedy dnes spíš spodní hranice nákupu výpočetní techniky.
Zapojení testovací sítě

Dráty, karty switche
Samozřejmě tento problém nikdy nevyřešíte bez solidní sítě s optimalizovanými parametry. Opět jsme zvolili zlatou střední cestu, pracovní stanice připojené pomocí síťových adaptérů SMC 1255TX na standardu Fast Ethernet a v případě druhé učebny integrované Fast Ethernet adaptéry Realtek. Server byl připojen svou integrovanou gigabitovou kartou na 48 port switch 3COM se dvěma Gigabit Ethernet porty (3COM SWITCH 4250T 48PORT 10/100 + 2×10/100/1000). Na připojených stanicích jsme nešetřili, prostě připojili jsme všech 48, přece nebudeme troškaři. Konfigurace switche ani síťových adaptérů nebyla nijak upravována (vše default).

Jak jsme testovali?
AVI, MPEG, MP3? Jaký formát zvolit a jak testovat? Vyřešil to za nás kolega, který si dovezl z INVEXu prezentační video ve formátu DVD. Tak proč ne :O) DVD přehrávané ze sdíleného disku na 48 PC, to už je docela zajímavý datový tok, proti kterému jsou multimediální výukové aplikace opravdu drobností. K tomu přidáme ještě dalších 80 PC, které využívají aplikace z téhož serveru a eLearning systém Moodle.

Testovací sestava – server HP s SCSI disky (10 000 ot/min) v RAID 1

Jaký komunikační protokol?
Obecně IPX má poměrně navrch proti TCP/IP. S tímto názorem jsem se za dobu své praxe setkal několikrát. Z desítek realizovaných projektů v IP sítích je dnes již jasné, že TCP/IP protokol zaručí dostatečnou datovou propustnost, pokud je náležitě zoptimalizován. Pro detailní analýzu můžete použít například Sniffer Pro, Optiview Protocol Expert, EtherPeek NX nebo Ethereal. Srovnání jednotlivých aplikací najdete zde.

Klasické Linux – Samba parametry pro přenos TCP/IP

Schopnosti TCP/IP stacku
Od původního standardu TCP/IP z roku 1981 (RFC 791, 792, 793) uplynulo mnoho let a tento standard byl rozšiřován. Navzdory tomu je dosud udržována kompatibilita — TCP z roku 1981 by stále mohlo komunikovat se současnými implementacemi. K pochopení TCP/IP doporučuji tuto přednášku. Můžete si ji sosnout zde, nebo se podívat přímo na semináře. Zde přinášíme ještě kompletní dokumentaci v češtině.

Window scaling (technika okna) — RFC1323 z roku 1992. Původní TCP umožňovalo maximální velikost okna (t.j. dat, jež byla odeslána, ale ještě nebyla potvrzena) 65535. Toto rozšíření umožňuje tuto velikost libovolně zvyšovat. Linux i FreeBSD je podporují, nicméně pro použití je třeba na socketu pomocí syscallu setsockopt nastavit větší příchozí buffer. Implicitní hodnota bufferu je menší než 65536, aby nedošlo k zaplnění paměti, pokud je otevřeno mnoho socketů. 

TCP Window

Path MTU discovery — RFC1191 z roku 1990 — toto rozšíření umožňuje zjistit Maximum transmission unit (neboli maximální velikost packetu) na cestě mezi dvěma spojenými počítači. Díky tomuto rozšíření může TCP posílat packety potřebné velikosti a není třeba je pak fragmentovat na routerech. Funguje to tak, že packety jsou posílány s příznakem, že nesmějí být fragmentovány; pokud je někde po cestě menší MTU, než je velikost packetu, je packet zahozen a odesilateli je poslána ICMP zpráva o přílišné velikosti packetu. Odesilatel poté začne posílat menší packety. Linux i FreeBSD toto rozšíření podporují. Pro standard Ethernet platí RFC894 a velikost MTU 1500.

Timestamps — také RFC1323. Ke každému packetu je přiřazen čas, kdy byl odeslán. Tento čas je možno použít k přesnému měření, jak dlouho trvá round-trip (t.j. čas od odeslání packetu do jeho přijetí). Dále tento čas funguje jako ochrana proti přetečení seq čísla — na gigabitovém Ethernetu dojde k přetečení za 34 sekund. Packet může však v síti držet až 4 1/4 minuty. Teoreticky by tedy mohlo docházet k tomu, že se staré packety budou míchat do současného spojení. V praxi je toto témeř nemožné, neboť packety se nikde po dobu 34 sekund nedrží. Podle nejnovějších standardů je možno tento čas použít i k rozpoznání, zda došlo k předčasnému znovuposlání packetu, na sítích, které mají velmi proměnlivý round-trip. Timestampy podporuje Linux i FreeBSD. 

T/TCP — Transakční TCP, RFC1644 z roku 1994 — umožňuje obejít standardní třípacketovou výměnu při navazování spojení, neboť ta je moc pomalá. Pomocí T/TCP je možno data poslat už v původním SYN packetu a přijmout odpověď v SYN/ACK packetu. V packetech je možno nastavit i bit FIN, čímž se způsobí, že nebudou žádné další packety potřeba na ukončení spojení; v takovém případě je možno uskutečnit celé spojení pouze pomocí dvou packetů — jednoho poslaného klientem a druhého poslaného serverem. Nové TCP optiony v onom RFC řeší problémy se ztracenými a přeposlanými packety — je třeba zajistit, aby se jedno spojení tvářilo stále jako jedno spojení, i když dojde ke ztrátě packetu. T/TCP podporuje pouze FreeBSD, Linux ne. Ve FreeBSD je implicitně vypnuté a je třeba ho povolit pomocí sysctl net.inet.tcp.rfc1644. T/TCP na klientovi nelze použít pomocí standardních syscallů connect a write; je třeba po vytvoření socketu pomocí socket provést současné připojení i poslání dat pomocí syscallu sendto (více informací viz man ttcp). Bohužel programátoři o T/TCP moc nevědí a většina programů ho nepoužívá. 

Selective acknowledgement — RFC2018 z roku 1996. V TCP příjemce tradičně informuje odesilatele o přijatých packetech pomocí ACK čísla — říká, že přijal všechna data se SEQ číslem menším, než je jeho odeslané ACK číslo. Pomocí selective acknowledgement může příjemce informovat odesilatele i o nesouvislých blocích přijatých dat. Selective acknowledgement je implementován jako TCP option, ve kterém mohou být až čtyři intervaly přijatých dat. Selective acknowledgement podporuje Linux, ale nikoli FreeBSD. 

Explicit congestion notification (ECN) — RFC3168 z roku 2001. Původní implementace TCP řešila zahlcení pomocí ICMP zprávy „Source quench” — zahlcený router odeslal tuto zprávu odesilateli, ten při přijetí snížil rychlost odesílání. Nebylo nijak specifikováno, jak moc má odesilatel omezit rychlost vysílání. Takové řešení moc nefungovalo a v osmdesátých letech docházelo často ke kolapsu internetu kvůli zahlcení. Van Jacobson tento problém vyřešil definováním nového standardu, podle něhož TCP zmenší velikost vysílacího okna na polovinu pokaždé, když dojde ke ztrátě a přeposlání packetu. Source quench zprávy již není třeba generovat ani na ně reagovat. Takovéto řešení se ukázalo velmi dobré a každé současné TCP je musí dodržovat. Zjistilo se, že na routerech není vhodné zahazovat packety až ve chvíli, kdy jim dojde fronta; mnohem efektivnější je zahazovat je náhodně, kde pravděpodobnost zahození packetu je úměrná velikosti fronty — takové řešení se nazývá Random early detection. Tím budou TCP spojení přiškrcována rovnoměrně. Explicit congestion notification je nové rozšíření, které znamená, že router packet místo zahození označí, příjemce informuje ve svém ACKu odesilatele, že dostal označený packet, a odesilatel při přijetí této informace sníží velikost odesílacího okna, jako by došlo ke ztrátě packetu. K žádné ztrátě packetu a znovuposlání však nedochází, proto je toto řešení efektivnější. ECN podporuje pouze Linux, FreeBSD ne. ECN je třeba zapnout při kompilaci jádra a povolit v /proc/sys/net/ipv4/tcp_ecn. Některé staré firewally bohužel packety s nastavenými ECN bity zahazují nebo na ně odpovídají RST packetem, proto je po zapnutí této featury možno očekávat problémy s připojováním na určitá místa. Nicméně takových míst rychle ubývá. 

Jak optimalizovat TCP/IP?
Jednoznačně doporučujeme převzít parametry přenosu z platformy Linux. Ušetříte si tak řadu starostí s poměrně různorodým přístupem výrobců síťových komponent k detekci parametrů komunikace a jak se říká lidově vyždímáte ze své sítě maximum.

TCP/IP paket na datovém rámci standardu Ethernet

Optimalizované parametry TCP/IP pro pracovní stanici Windows XP (2000) a Windows 2003 server

REGEDIT4

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]„EnablePMTUBHDetect“=dword:00000000
„EnablePMTUDiscovery“=dword:00000001
„SackOpts“=dword:00000001
„Tcp1323Opts“=dword:00000003
„TcpWindowSize“=dword:00002000
„GlobalMaxTcpWindowSize“=dword:00002000
„DefaultTTL“=dword:00000040
„MTU“ =dword:000005dc