Starší komentáře ke článku: Realtime komunikace Java appletů přes firewall - teoretický rozbor
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 10.12.2002 7:11:39
Super clanek, kdy vyjde pokracovani?
Datum vložení: 10.12.2002 10:36:45
Na pokračování pracuji, bude se jednat o kompletní implementaci popsané komunikace. Myslím, že by to do týdne mohlo být hotové.
Datum vložení: 10.12.2002 9:06:06
A co ked v ceste bude aplikacny firewall/proxy...
Datum vložení: 10.12.2002 10:39:32
Presně nevím, co myslíte aplikačním firewallem. Domnívám se, že také pouze filtruje síťovou komunikaci a pouští jen povolené protokoly (což HTTP zpravidla je). Kdyžtak otázku upřesněte.
Datum vložení: 10.12.2002 14:00:08
Já mám firefall, který, pokud má požadavek ať už zvenčí, nebo zevnitř, na nějž se nevztahují žádné stávající filtry, se mě zeptá, jestli má požadavek propustit. To by při této technologii zobrazil po každém timeoutu i zprávě zobrazil dva dotazy, kdybych filtr nepřidal. Co možnost volby způsobu přenosu.
Datum vložení: 10.12.2002 14:26:28
A ptá se vás také na každou webovou stránku a každý obrázek zvlášť? Pokud ne, neměl by se ptát ani v tomto případě.
Samozřemně způsob přenosu můžete ovlivnit tak, že změníte komunikační protokol nebo port, ale právě komunikace jiná než HTTP:80 bývá u firewallů problematická.
Datum vložení: 11.12.2002 15:59:52
Mám pocit, že to co popisujete není firewall v pravém slova smyslu, ale tvz. "personal firewall". Personal firewall není skutečná zeď, přes kterou musí vše projít. Je to program, který jakoby sedí nad winsock.dll (v případě Windows) a kontroluje všechny přenosy. Ale kontroluje to tak, že "sleduje, co se vedle děje", nejde vše skrz něj. Není to tak bezpečné jako skutečný firewall, ale běžně se to používá, pokud máte jednotlivý počítač připojený napevno k internetu (třeba přes kabel. TV).
Ale zpět k problému: jak jste řekl, máte tam nějaké filtry, které automaticky povolují/zakazují určitý druh komunikace, určitým aplikacím, pomocí určitých protokolů, na určitých portech. Co není ošetřeno, na to si program vyžádá jednorázové povolení. Je to tak? Abyste mohl normálně surfovat po internetu, máte nejspíš povolenou HTTP komunikaci na portu 80 (nebo 8080 v případě proxy) pro váš oblíbený prohlížeč. Pokud je tomu tak, vztahuje se toto nastavení i na http spojení navázané pomocí Java appletu umístěného na stránce a váš firewall se tedy na nic ptát nebude.
Datum vložení: 11.12.2002 17:00:34
Este raz: predstavne si ze sme na LANke, mame direct pripojenie na ine (bez proxy, mozeme pouzivat vsetky porty). Na gateway je firewall + aplikacny firewall 9aplikacny fw je to preto ze nepreacuje na linkovej vrstve OSI ale az na aplikacnej).
Firewall roby klasicky packet filtering a connection trackig. Aplikacny firewall len pre http poziadavky a kontroluje spravnost http voci protokolu (neake rfcXXXX).
Normalny firewall zisti ze sa jedna o http tak to preda aplikacnemu firewalu. Tento si skontroluje spravnost hlavicky a podla udajov v nej obsiahutych dalej skontroluje zvysok prenosu ak to nesedy tak tento paket jednoducho zrusi. Aplikacny HTTP firwall na prave zbranit tunelovaniu HTTP protokolu. Kazdy ap.fw zabranuje vyuzivaniu danej prenosovej trasy pre dany protokol na vyuzivanie inym protokolom. Zabranuje to prave tym ze kontroluje validitu prenasanych dat.
> Ale zpět k problému: jak jste řekl, máte tam nějaké filtry, které
> automaticky povolují/zakazují určitý druh komunikace, určitým aplikacím,
> pomocí určitých protokolů, na určitých portech. Co není ošetřeno, na to si
> program vyžádá jednorázové povolení. Je to tak? Abyste mohl normálně
> surfovat po internetu, máte nejspíš povolenou HTTP komunikaci na portu
> 80 (nebo 8080 v případě proxy)
Moja situacia je ina: na internet mam pripojenie o rychlosti 11MBps (ktore mozem uplne vyzivat -> bezne taham 500kb/sec) ked chcem nenusim mat v ceste ziadny firewall, ale mam taky ktory zakazuje vsetky spojenia z vonku ak neboli predtym inicializovane z vnutra, od seba mozem vyuzivat vsetko.
Datum vložení: 11.12.2002 22:20:18
> ...mam taky ktory zakazuje vsetky spojenia z vonku ak neboli predtym inicializovane z vnutra...
Přesně tak. Předmětem článku je právě nápad, že jak toto řešit. V uvedeném postupu jsou právě všechny spojení inicializovány ZEVNITŘ. V tom je právě ten fígl.
Datum vložení: 11.12.2002 23:56:59
Ano je jasne ze budu z vnutra, ale ak to nebu korekne http poziadavky tak moze byt problem... A o to mi islo...
Datum vložení: 10.12.2002 15:56:00
alikacny firewall = normalny fw + analyzuje prenasane data a zistuje ci zodpovedaju protokolu napr:
pri http moze zistovat pritomnost hlavicky, korektnost POST/GET, bez poziadavky vam neda ziadne data...
Datum vložení: 10.12.2002 23:10:35
No proxy vlastne nekouka na pakety tak jako firewall (pakety jdou od klienta k serveru), ale klient komunikuje s proxy a proxy komunikuje se serverem. Takze spravna hlavicka dotazu i odpovedi je nutnost! Ale to pro server ani pro klienta snad neni byt problem, ne?
Datum vložení: 13.12.2002 12:34:54
Správná hlavička by teoreticky nemela být problém. Trochu to komplikuje fakt, ze v Javě, která je součástí MS IE jsou třídy pro URLConnection a HttpURLConnection nekompatibilní se standardem Javy, proto se těžko posílá informace o tom, zda se jedná o dotaz GET či POST.
Datum vložení: 10.12.2002 23:02:33
HTTP Proxy (tedy jak nekdo uvadi - aplikacni firewall) nedela nic jineho nez, ze klientovi dotazy preposila dal na server a pripadne si uklada odpoved aby ji byla schopna priste poskytnout sama. Z toho plyne:
a) je nutne zajistit, aby odpoved nebyla v ulozena v cache
b) je treba vyporadat se s predcasne ukoncenym spojenim (timeout proxy < timeout klienta .... pokud klient ceka odpoved "neni zprava" mohl by mit problem, pokud ceka dokud spojeni "nespadne" mohl by byt OK)
Uvedene reseni by pri masivnim nasazeni mohlo dosahnout urciteho limitu. Kazdy klient si po vyznamne dlouhou dobu drzi spojeni se serverem - tedy blokuje cast prostredku serveru (jeden proces/vlakno). Bezny web server neni na takovouto situaci navrzen - jeho ukolem je rychle obslouzit klienta a hned byt pripraven na dalsiho. Jak vysoky je ten limit?
Rychle jsem udelal maly test (Apache 1.3.27, mod_perl 1.27, Windows2000). Skript ktery bezi 100 sekund a kazdou sekundu vypise aktualni cas. Otevrel jsem jedno okno IE a zobrazil hlavni stranku serveru, kliknul na skript a po 100 sekundach sem dostal vysledek (nuda). Otevrel jsem druhe okno (a prvni vratil na homepage) v obou kliknu na skript. Cekal jsem 100 sekund nez jsem mel prvni vysledek - potom dalsich 100 sekund nez jsem mel druhy vysledek. Apache 1.3.xx pro Windows ve spojeni s mod_perl neumi vice procesu - pouze jeden! Nevim jak to bude ve spojeni s PHP nebo necim jinym ale nebude se to moc lisit. Apache pro linux ma procesu vic a umi si je podle potreby pridat, ale taky ma sve limity (cca par desitek procesu). Limity jsou do jiste miry konfigurovatelne v httpd.conf.
Je velmi vhodne pouzit vlastni pro tento pripad navrzeny server ale i tak muzem narazit na limit operacniho systemu - vite nekdo kolik spojeni muze byt najednou otevrenych v beznych OS? - nic neni nevycerpatelne.
To je taky duvod proc sluzby u kterych se ocekava "dlouha doba spojeni a mnoho klientu" - tedy napr stream audio nebo video nejsou reseny pres TCP (natoz HTTP) ale UDP (nespojovany prenos datagramu).
Datum vložení: 11.12.2002 0:06:22
aplikacny firewall a proxy nemusi byt to ise :). Proxy je zvycajlne akasi nadstavba ap. fw. ale nemusi obsahovat ap. fw.
Vacsina takychto java apletov prevazne viazne ak klient je za ap. fw alebo proxy. Preto ma to zaujimalo :)
Raz som skusal spravit chat trosku inaksie:
server: TCP deamon ktory pri bud posielal text od pripoj uzivatelov, alebo poslal kazdych 30sec znak ktory sa v browery nezobrazil (aby sa zabranilo timeoutu spojenia). Problem bol len s IE po prijati cca 8MB dat sa zrubalo. Takto to bolo pri kazdom IE :(
Datum vložení: 11.12.2002 16:12:35
Apache Group nikdy nevydala ostrou stabilní verzi Apache pro Windows. Vždy upozorňovala, že je to pouze pro testovací účely, takže by nikdo neměl Apache na Windows používat ve skutečném provozu. Na Linuxu, jak jste sám řekl, tento problém není.
Existuje ale jiný háček a to omezený počet navázaných spojení mezi http serverem a prohlížečem, který je podle RFC stanoven tuším na 2. Dá se to sice v prohlížeči přenastavit na víc, ale je to proti pravidlům a každý to tak rozhodně nemá. Pokud bude napevno navázané 1 spojení, vše ostatní bude probíhat pouze přes to druhé zbývající - např. všechny obrázky půjdou po sobě. Nic nepůjde paralelně. Ale když jde o Java applet, tak možná už žádná jiná komunikace přes prohlížeč není nutná.
Uvedené omezení se samozřejmě týká 1 serveru a 1 klienta. Neovlivní to http spojení s jinými web servery - můžete tedy v jiném okně prohlížeče surfovat po jiných stránkách naplno přes 2 spojení.
Datum vložení: 11.12.2002 9:10:47
Mam dojem ze v <B>netscape (6.x) a potazmo mozille (1.x) "lepší řešení"</B> fungovat <B>nebude</B>. V mych experimentech se tyto prohlizece při nacitani dat via HTTP z java apletu kousnou, dokud neni pozadavek vyrizen. Tzn. pokud by 2 minuty zadna zprava neprijde, browser bude smutne premyslet a nebude schopen odpovidat na user requesty. Btw: pri implementaci komunikace v techto prohlizecich pravdepodobne narazite jinde. V IE jsem zatim na problemy nenarazil.
Datum vložení: 11.12.2002 9:46:46
Nedavno jsem delal komunikaci applet-servlet pomoci AS miniRMI connectoru:
<a href='http://dione.zcu.cz/~toman40/AS_miniRMI_Connector' target='_blank'>http://dione.zcu.cz/~toman40/AS_miniRMI_Connector</a>
V pristi verzi miniRMI bude pravdepodobne implementovan i HTTP streaming, tedy moznost realtime callbacku ze serveru.
Datum vložení: 18.12.2002 9:48:13
Ahoj Jirko.
Zajímavý článek. Bude nebo už je tento typ komunikace v provozu pro ověření reálnosti uvedeného řešení? Jestli ano, rád ho ověřím přes Mozillu.
Zdraví
Tomáš
Datum vložení: 13.4.2004 20:33:16
koukám, že tady někdo něco zkoušel přes Mozillu. :))
Datum vložení: 19.12.2002 14:46:17
napadlo me jeste - co takhle pouzit dve spojeni ,ktere by se castecne prekrivala a mezi nimiz by se prepinalo, tzn. prvni spojeni by zaslalo
pozadavek a cekalo na odpoved ... behem tyhle doby by se otevrelo dalsi
spojeni kteremu by bylo predano plne rizeni po prijeti odpovedi pro
prvni spojeni. a takhle dokola - tzn. ze navenek by nebyly prodlevy pri mezi jednotlivimy spojenimy - samosebou ze jen za predpokladu ze ( timeout > cas potrebny pro vytvoreni spojeni ) Proc tohle cele? No rekneme ,ze navazovani a unkoncovani spojeni nas casove neco bude stat - takze by bylo vhodnejsi to delat v momente kdy mame trochu casu navic (timeout) :) Dalsi vec je ze by nas tohle reseni stalo 2 Thready na serveru ... ;)