<html>
<head>
<meta content="text/html; charset=iso-8859-2"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Szia,<br>
<br>
<blockquote
cite="mid:CAEdf6LdrkNKt4digR3RROV2FjFNsHZCXO38vkFQtc31t4OKQqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Érthető. Erre mit
csinál a szoftver fejlesztő? Mindent becsomagol HTTP-be
80/443-as porton, merthogy az jobb eséllyel átmegy.</div>
</blockquote>
<div><br>
</div>
<div>Alapvetően nem a "jobb eséllyel átmegy" a vezérelv,
hanem az, hogy a felépített infrastruktúra meghágása
nélkül tud működni és ugyanúgy lehet szűrni, ellenőrizni,
engedélyezni és tiltani, mint a http forgalmat, mert
tulajdonképpen http forgalom.</div>
</div>
</div>
</div>
</blockquote>
<br>
Miben tudod jobban szűrni, ellenőrizni?<br>
<br>
<br>
<blockquote
cite="mid:CAEdf6LdrkNKt4digR3RROV2FjFNsHZCXO38vkFQtc31t4OKQqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div>Ha odamész a hálózatosokhoz, hogy Neked kellene egy
bináris egyedi socket két gép között, akkor a minimum az,
hogy leakasztják a korbácsot, mert nincs dobozos
szoftverük arra, hogy ezt a forgalmat szűrni, ellenőrizni,
engedélyezni és tiltani tudják.</div>
</div>
</div>
</div>
</blockquote>
<br>
Engedélyezni és tiltani minden tűzfal tud. Ha nem tudna, akkor nem
lenne tűzfal.<br>
Szűrni, ellenőrizni akkor lehet valamit, ha ismered a kommunikációt.
Attól, hogy WebSocketet használsz még, semmilyen "dobozos" tűzfal
nem fogja tudni szűrni a forgalmat alkalmazás specifikus módon.
Vannak UTM-ek, amik elterjedtebb protokollokat ismernek és tudnak
szűrni, de ha Te készítesz valamit, azt jó eséllyel nem fogja tudni
(két lehetőség marad: enged vagy tilt).<br>
Legfeljebb örül a hálózatos, hogy nem kell foglalkoznia a kérdéssel,
mert úgyse tudja szűrni (innentől kezdve az a kérdés, hogy miként
engedik/tiltják a http-t, ami adott esetben más megítélés alá esik).
Ellenben egy másik porton futó protokoll esetén írhatná a kérelmeket
stb.<br>
<br>
Nem ismerem a WebSocketet (nem használtam), ha jól értem a Wikipedia
alapján az az elsődleges hozzáadott értéke, hogy folyam
strukturálását teszi lehetővé (azaz tudod, hol kezdődik egy üzenet
egység, hol végződik, duplex stb. ilyen alacsony szinttel nem kell
foglalkoznod), ezt szabványosan. Ez teljesen rendben van.<br>
Amire én tettem a megjegyzést: szépen becsomagolták HTTP jellegű
forgalomba, hogy jobban át lehessen menni a tűzfalakon, holott ezt a
funkcionalitást nemcsak HTTP jelleggel lehetett volna megoldani).
Jó-jó, átmegy több helyen, csak kérdés, hogy ez mennyire megoldás.<br>
<br>
Nekem ez olyan, mint a motoroknál alkalmazott turbó: kérdés, hogy a
választott technológia mekkora távlatban értelmezhető válasznak. A
motoroknál a turbó szerintem kényszer megoldás, az "apps over http"
pedig kényelmi megoldás. Valahogyan működik, aminek működnie kell,
de a valódi célhoz nem jutottunk közelebb.<br>
<br>
Attila<br>
<br>
</body>
</html>