Predevsim pro wifi spoje by se velice hodily komprimovane tunely, ktere by dokazali zvysit propustnost a snad i spolehlivost zaruseneho wifi spoje. Jak takovy tunel realizovat a jaky komprimacni program pouzit? Urcite jde pouzit SSH, ale po urcite dobe pry muze vytuhnout, navic pry dost zatezuje CPU. Slysel jsem, ze nejrychlejsi a nejlepsi komprimacni algoritmus pro linux je Bzip2 (ale winrar 3.20 komprimuje na woknech lepe :-).
V CZfree by bylo dobre udelat jakousi virtualni komprimovanou (pod)sit, kde by se nekomprimovaly cele packety, ale pouze datova cast, takze pokud by bylo za sebou vice linuxovych routeru, ktere by byly soucasti one virtualni kompr. site, nemusely by prichazejici data rozbalit a znovu zabalit na odchodu, ale rozbalili by se az na stroji, ktery by byl posledni v one virtualni komprimovane siti. Proste vytvorit mnozinu primo spojenych (nebo i neprimo) routeru, ve ktere by datova cast packetu putovala zabalena a rozbalila by se az na hranici teto mnoziny, nebo u adresata nachazejiciho se uvnitr. Jak by se to snaselo s OSPF netusim, ale snad by to slo udelat. Neni jiz takova nebo podobna vec hotova? Samozrejme je, ze soucasti teto site by mohli byt pouze silnejsi stroje, ktere by zvladali data komprimovat, aniz by se zvysil ping a aniz by se snizila stabilita HostAP.
Dalsi moznosti je IPV6,to uz take podporuje nativne kompresi, ale nasazovat jej v CZFree jeste asi dlouho nepujde. Je mi jasne, ze kvuli PL se nemuzou komprimovat cele packety, ale prave jen datova cast, aby to bylo odolne. To by tedy mely umet nejake VPN, jestli to chapu dobre. Ale stejne mi nejde do hlavy, proc je PL problem, kdyz to pojede pres TCP, to ma prece retransmisi v sobe a je plne transparentni, takze ve skutecnosti to SSH nebo PPTP vubec zadny PL nevidi, nebo ano? Jake reseni by tedy bylo pro CZfree nejlepsi, aby se to zaroven snaselo s OSFP?
No, takze ten tunel by to chtelo ani ne kvuli zvyseni rychosti, ale spise aby se zlepsila kvalita spoje. Jestli jsem te Lado dobre pochopil, tak to je mozne, treba pomoci VPN. K tomu Squidu; nejde tam take zapnout gzip tak, aby to zvladali alespon ty novejsi browsery? Predpokladam, ze zrovna freegate squid pouziva a kdyz ne, tak ze bzry zacne, protoze to je rozhodne dobra vec (shaping snad neni s HTB problem). Umi to treba IE 5 nebo 6? To je ale pouze inet, navic mi tunel pripada lepsi nez bezny provoz, protoze tunel je jenom jedno spojeni, kdezto normalne jich muze jit po jednom spoji treba stovky a intuice mi napovida, ze to jedno spojeni by se melo chovat lepe.
Na to muzu rict jedine - komprimovat je nejlepsi vzdy na aplikacni urovni - tedy posilat obrazky v jpg misto bmp a mp3 misto wav. Zadny algoritmus na nizsich vrstvach at V42bis u modemu nebo zlib komprese u SSH, ci jakakoliv jina obdoba u jineho systemu nemuze nikdy dosahnout tak vysokeho stupne komprese ze vcelku jasnych duvodu. Tohle jsou zjevne pripady a asi nikoho dneska nenapadne pouzivat bmp a wav, ale jsou jine priklady - bohuzel treba u tech web serveru by bylo moznosti nepreberne - jednak dynamicky generovane stranky nelze cacheovat, pritom hromada serveru by si vystacila se statickymi strankami, ktere by se pregenerovaly pouze v pripade zmeny v publikacnim systemu. Take lze pouzit jiz zminovanou kompresi - staci uz jenom pokud si na web serveru soubory zakomprimujete gzipem a to i treba html stranky (overeno Apache na Linuxu) a v prohlizeci se rovnou rozbali a otevrou jako nekomprimovane, pritom u tech statickejch stranek by komprimace nebyla zadny problem v podobe zateze procesoru. Samozrejme o takove drobnosti jako vycisteni HTML od zbytecnosti ani nemluve. Jinak pokud zde padla zminka o connected foru - pak v tomto pripade by absolutne nejlepsi kompresi bylo nepouzivat web server, ale news server. News jsou nesrovnatelne prehlednejsi nez system otevirani diskusnich temat v tomhle systemu, jsou datove nesrovnatelne mene narocne, kdyz se data neobalujou hromadou HTML balastu atd. Pritom kazdy kdo si umi nastavit POP3/IMAP a SMTP tak dokaze si nastavit i NNTP (to jen pro nekoho, kdo by tvrdil, ze to je pro normalni lidi moc slozite).
No a pak nam zbyde pouze nekolik protokolu, ktere jaksi nepodporuji zadnou kompresi a to jsou prave SMTP, POP3, IMAP, NNTP (mozna jeste neco), kde by se nejaka komprese z povahy prenasenych dat zcela jiste umplatnila a tam mi prijde celkem rozumne pouzit tunelovani pomoci komprimovaneho SSH - duvodem je jednoduchost pouziti a v podstate end to end komprese nezatezujici prenosovou cestu, pritom obvykle nekomprimujete nekolik ruznych streamu, ale jen jeden (to s cim prave delate), takze se moc neprojevi ta diskvalifikace ve fair queue algoritmech nebo pri vypadku paketu.
03.07.2003 v 10:16
