Sokszorosára gyorsítja a hálózati alkalmazásokat a Riverbed technológiája

Sokszorosára gyorsítja a hálózati alkalmazásokat a Riverbed technológiája
2017-03-03T09:36:13+01:00
2017-03-04T14:32:48+01:00
2022-10-19T18:35:33+02:00
  • A Riverbed a fejlesztő számára a világon semmit nem jelent ám, ez a felhőplatform sávszélességét javítja kiválasztott végpontok felé, és első körben a felhőplatform belügye (második körben meg biztos egy megvásárolható szolgáltatása lesz). Az alkalmazásod továbbra is pont akkora forgalmat bonyolít, ami az éppen aktív felhasználók kiszolgálásához szükséges.
    Fejlesztés közben meg "véletlenül" biztos nem fogsz Riverbedre optimalizálni (már ha ilyen egyáltalán létezik, hiszen az alkalmazás szempontjából továbbra is külön kommunikálsz az egyes kliensekkel), mert ahhoz olyan cégnek kell fejlesztened, ahol adott a SteelHead végpont. Arról meg azért felhős fejlesztőként valószínűleg tájékoztatják az embert, ha nem ő maga (vagy a csoportja) kezdeményezte a végpont létesítését.
    Mutasd a teljes hozzászólást!
  • Viszont, ha te ezzel optimalizálod az alkalmazásod, majd hírtelen megszünik a Riverbed akkor ott maradsz egy hatalmas network overhead-el.

    Már ugyan miért maradnál ott? Ezek az eszközök tök függetlenül működnek attól, hogy a Riverbed létezik -e vagy sem. De ha nem így lenne és tényleg megszűnnének működni a Riverbed eltűnésével, akkor sem valamiféle plusz "overheaddel" maradnál ott, hanem egyszerűen csak annyi lenne a forgalmad, mint egyébként is lett volna.

    Azt mondom az elgondolás jó, van létjogosultsága is fölleg a JSON alapú API-knál, de én megvárnám amíg szabványosítják.

    Ugye abszolút nem érted hogyan működik ez a dolog? Javaslom olvasd át a cikket, nézd meg a videót, és olvasd át az elejétől ezt a topikot! Aztán kérdezz, ha valami még mindig nem világos. Szívesen válaszolok.
    Mutasd a teljes hozzászólást!
  • Viszont, ha te ezzel optimalizálod az alkalmazásod, majd hírtelen megszünik a Riverbed akkor ott maradsz egy hatalmas network overhead-el.
    Azt mondom az elgondolás jó, van létjogosultsága is fölleg a JSON alapú API-knál, de én megvárnám amíg szabványosítják.
    Mutasd a teljes hozzászólást!
  • Nem. Ez (ti. SteelHead) egy önálló, infrastrukturális célhardver, egy külön dobozban ("appliance"). Használatához az alkalmazásokkal - akár a sajátjaiddal, akár harmadik felektől származókkal - semmit nem kell csinálni. Egyszerűen csak keresztül kell vezetni a hálózati forgalmuk ezen az eszközön, és ő intéz mindent magától, anélkül, hogy ebből az alkalmazás, illetve az alkalmazások - vagy akár a felhasználók - bármit észre vennének vagy akár csak vehetnének (a gyorsabb működést leszámítva, persze). Gyakorlatilag olyan, mint egy router, csak sokkal többet csinál utóbbinál.

    Van egyébként azt hiszem szoftveres változata is, de arra is ugyanaz igaz. Csak az nem saját hardveren fut, hanem a befogadó gépén. De amúgy ugyanúgy működik, mint pl. egy VPN vagy Tor kliens - hogy ti. azt leszámítva, hogy a gépen nyilván fel kell konfigurálni meg át kell vezetni az általa kreált virtuális interfészen a forgalmat, az végfelhasználói alkalmazásokat semmilyen módon nem kell felkészíteni kezelésére, és nem is veszik észre, ha rajta keresztül működnek.
    Mutasd a teljes hozzászólást!
  • Sztem tevedsz, nem azt mondja, hogy semmit nem kell az alkalmazásodba beépiteni, hanem hogy ha integrálod a rendszert nem kell foglalkoznod vele mert megy magától. De a magát a De-duplication filtert mind kliens mind szervert oldalon el kell helyezni.
    (Különben varázslatnak hívnák)
    Mutasd a teljes hozzászólást!
  • Magát a dokumentumok különbözeti továbbítását azért nem most és ők találták fel (nem vagyok nagy *nix-es, de a diff-patch párosról még én is hallottam).

    Nem. Ahogy a Bentley sem találta fel a kereket. Ennek ellenére a diff-patch és Riverbed megoldásai között kb. ugyanannyi a különbség, mint a kerék és egy Bentley között.
    Mutasd a teljes hozzászólást!
  • Elbeszélünk egymás mellett.

    azokat a részeket, amik egyszer már megvannak a céloldalon, nem küldi át újra. Akkor sem, ha azok nem diszkrét fájlok, hanem csak az alrészei egy korábban átküldött dokumentumnak, fájlnak, vagy bármilyen más olyan adatfolyamnak/adathalmaznak, amit ő képes kisebb, önmagukban is értelmezhető és kezelhető adategységekre bontani.

    Én ezt nevezem tömörítésnek, csak cseles az alaphelyzet, hiszen látszólag független adatfolyamokban keres redundanciát. Az alkalmazásadatok csak úgy jött ide, hogy nyilván azon lehet sokat fogni, különösen, ha sok user dolgozik egyvalamin, és mind külön nyitja meg a felhőn. Magát a dokumentumok különbözeti továbbítását azért nem most és ők találták fel (nem vagyok nagy *nix-es, de a diff-patch párosról még én is hallottam).
    Mutasd a teljes hozzászólást!
  • Micsoda hangzatos nevet adtak egy hálozati Cache-nek.

    Ennek valamiféle hétköznapi "hálózati cache"-hez annyi köze van és olyan összehasonlítani vele, mint a rollert hasonlítani egy Bentley Bentayga-hoz. Nyilván utóbbi kettőről is elmondható, hogy mindkettő kerekeken gurul - mint ahogy a Riverbed termékeiben is van valamiféle gyorstárazás. De a hasonlóságok itt véget is érnek, és a megoldások komplexitása, valamint az, hogy végeredményként mit kapunk bennük és általuk, nem említhető egy lapon sem egymással. Sem a roller és a Bentley, sem valamiféle hálózati cache és a Riverbed esetén.

    Az legalább biztos, hogy müködik, de nagyon erős a függőség a szolgáltatóhoz ha valaki implementálja vagy a szolgáltató esetleg modosit a dolgon....

    Nem. Pont az a lényeg, hogy teljesen transzparens módon működik az egész. Sem a hálózat logikai felépítését, sem az alkalmazásokat, sem a kommunikációt semmilyen értelemben nem kell hozzáilleszteni a termékhez, és semmit nem kell implementálni. Egyszerűen csak pl. ezeket a SteelHead-eket be kell kötni a végpontokon, és a "varázslat" kvázi magától megtörténik. Azure esetén nyilván nem személyesen köti be az ember, hanem egyszerűen szolgáltatásként igénybe veszi. De ez azon, hogy az alkalmazásokon, szoftvereken és a magasabb rétegekben semmit nem kell hozzáigazítani ehhez, semmit nem változtat.
    Mutasd a teljes hozzászólást!
  • 1) De, az alkalmazás-adatok tömörítése a lényeg. 97%-ot nem tudsz fogni TCP, stb. fejléceken ("konténer"), és a közleményben is szerepel

    Nem, nem az alkalmazásadatok tömörítése a lényeg. Hanem az, hogy azokat a részeket, amik egyszer már megvannak a céloldalon, nem küldi át újra. Akkor sem, ha azok nem diszkrét fájlok, hanem csak az alrészei egy korábban átküldött dokumentumnak, fájlnak, vagy bármilyen más olyan adatfolyamnak/adathalmaznak, amit ő képes kisebb, önmagukban is értelmezhető és kezelhető adategységekre bontani.

    A konténer alatt egyébként csak te értetted a "TCP, stb. fejlécek"-et - érthetetlen okból, mert azokat direkt külön kiemeltem máshol. Én viszont valójában ezen kifejezés alatt az alkalmazásszintű kommunikációs-, adat- és dokumentumkeretekre (pl. OOXML, MS Compound Document Format, SQL szintaxisfa, stb., vagy ennél is magasabb szintű modellek) gondoltam. Ezek azok amiket fel kell tudnia dolgoznia ahhoz, hogy hatékonyan tudjon egy kvázi tartalmi és kommunikációs diff-et készíteni, és aztán azzal, hogy csak a diff-et küldi át ténylegesen a kábelen, rengeteg hálózati forgalmat spórolni.

    Ezen kívül nyilván tömörít is vagy akár tömöríthet is a hagyományos értelemben is, de - ahogy már korábban írtam - ez legfeljebb marginálisan befolyásolja a spórolás mértékét a fenti mechanizmus révén elérhetőhöz képest.
    Mutasd a teljes hozzászólást!
  • Micsoda hangzatos nevet adtak egy hálozati Cache-nek. Az legalább biztos, hogy müködik, de nagyon erős a függőség a szolgáltatóhoz ha valaki implementálja vagy a szolgáltató esetleg modosit a dolgon....
    Mutasd a teljes hozzászólást!
  • Most nincs időm mélyen veszekedni, de azért két észrevétel.

    1) De, az alkalmazás-adatok tömörítése a lényeg. 97%-ot nem tudsz fogni TCP, stb. fejléceken ("konténer"), és a közleményben is szerepel a "egy összetett dokumentummódosítás esetén is valójában csak a megváltozott, illetve különbözeti részek kerüljenek ténylegesen átküldésre a hálózati kábeleken, az azonos részek újra és újra elküldését megspórolva" magyarázat

    2) Egy dolog viszont tényleg szellemes, és rosszul tippeltem (mostanra viszont elolvastam): az alkalmazás tanúsítványát nem kell betenni a kliensoldali dobozba, mert az SSL handshake a valódi, felhős szerverrel történik és utána a session key(-ek) kerülnek csak át a dobozba.
    Mutasd a teljes hozzászólást!
  • Szerintem ott a megoldás az első sorban, hogy provided that SteelHeads are deployed locally to both the client-side and server-side of the network

    Igen, és?

    Ezt túl gyorsan írtad. A titkosítás akkorát dob az entrópián, hogy gyakorlatilag tömöríthetetlen az eredmény, különösen szótár-alapon.

    Kevered a szezont a fazonnal. Nem a titkosított adathalmaz kerül szótár alapú "tömörítésre" (ami csak egy hasonlat volt részemről), hanem az azt befoglaló container, illetve hálózati adatfolyam, aminek a titkosított adathalmaz csak egy "szava" (a felhasznált hasonlat értelmében). Aminek összetettsége vagy belső - klasszikus módszerekkel történő - tömöríthetősége viszont ezzel összefüggésben nem, illetve csak marginálisan befolyásolja azt, hogy mennyire vehető ki a redundancia az őt befoglaló kommunikációs folyamból.

    Szóval az ördög a részletekben rejtőzik, úgy lesz ebből jobb felhasználói élmény, hogy egy újabb dobozt kell helyben kerülgetni. Pont amit a felhősítés alapvetően megszűntetni volna hivatott.

    Egyrészt a felhősítés nem egy dobozt szüntet meg hanem százakat, ezreket. Másrészt a dobozok eltüntetése mellett millió másik előnye van (skálázódás, befektetés/költség, biztonság, stb. vonatkozásában). De ami adott esetben a legfontosabb, hogy ez az egész nem a felhősítésről szól, mert ezek a termékek éppen úgy és éppen olyan jól működnek akkor is, ha teljesen privát és klasszikus (nem-felhős) felépítésű, de geográfiailag szétszórt privát (pl. vállalati vagy infrastrukturális) hálózat végpontjainak, illetve alhalmazainak összekötésére használják. Ott is kiválóan csökkentik a WAN forgalmat, akkor is, ha semmilyen felhőszolgáltatás nem kerül igénybevételre, csak pl. egy cég különböző telephelyei vannak összekötve egymással.

    A felhőhöz, illetve konkrétan pl. az Azure-hoz csak annyi köze van az egésznek, hogy az Azure is támogatja ennek használatát - tehát a rajta futó alkalmazások esetében is lehet használni, annak ellenére, hogy azok esetében a felhős végpont legfeljebb csak logikai értelemben áll az ügyfél irányítása alatt, de a hardverhez, hálózati infrastruktúrához nem fér hozzá. Tehát egy saját ilyent dobozt nem tudna odavinni és bekötni a felhős végpont elé. Viszont mivel az Azure támogatja ezek használatát (plusz szolgáltatásként, nyilván), ezért a dolog ettől függetlenül megoldható rajta is.
    Mutasd a teljes hozzászólást!
  • Nem igazán. Egyrészt, mert az SSL sem jelent gondot számára.

    Szerintem ott a megoldás az első sorban, hogy provided that SteelHeads are deployed locally to both the client-side and server-side of the network

    Másrészt, mert őt nem érdekli, hogy titkosítva van -e egy adott adatblokk, mert neki az éppen úgy csak egy bájtsor, mint ha titkosítatlan lenne.

    Ezt túl gyorsan írtad. A titkosítás akkorát dob az entrópián, hogy gyakorlatilag tömöríthetetlen az eredmény, különösen szótár-alapon.

    HTML Book - ből kiderülnek a részletek is, így már persze működhet, de a dolog trivialitása lecsökken, mert a kliens felé eső oldalon (cégnél, esetleg ISP-nél) is ott kell lennie egy ilyen SSL-fordító+tömörítő proxy-nak, ráadásul egy "igazi" tanúsítvánnyal, hogy a te nevedben elvégezhesse az aláírást a kliens gépek felé.

    Szóval az ördög a részletekben rejtőzik, úgy lesz ebből jobb felhasználói élmény, hogy egy újabb dobozt kell helyben kerülgetni. Pont amit a felhősítés alapvetően megszűntetni volna hivatott.
    Így könnyű...
    Mutasd a teljes hozzászólást!
  • Ez jól hangzik, csak titkosítással eléggé ki lehet lőni.

    Nem igazán. Egyrészt, mert az SSL sem jelent gondot számára. Másrészt, mert őt nem érdekli, hogy titkosítva van -e egy adott adatblokk, mert neki az éppen úgy csak egy bájtsor, mint ha titkosítatlan lenne. És amíg a container formátumot/adatfolyamot értelmezi tudja, addig gyorstárazni is tudja annak elemeit egymástól függetlenül.

    Persze ha valaki egy teljesen egyedi, saját protokollt használ, amit a Riverbed nem tud értelmezni, és azon valami olyan titkosítást, ami folyamatosan elváltoztatja ugyanannak a titkosítatlan adatblokknak/-folyamnak is a formáját az újbóli átküldésekkor, akkor azzal ez a technológia sem fog tudni mit kezdeni. (Működni fog vele, csak a hálózati forgalmat nem fogja tudni érdemben csökkenteni, vagy maximum csak annyira, amennyire a generikus tömörítés, a kommunikációs fejlécek binárisra kódolása, stb. lehetővé teszi.)

    De ilyenkor is a protokollértelmezés az alapprobléma, nem az, hogy titkosítva vannak az adatok, illetve a kommunikáció. A másik oldalon ki az az őrült, aki manapság nem szabványos SSL-t használ a titkosított kommunikációra és adatcserére, hanem valami saját dolgot?
    Mutasd a teljes hozzászólást!
  • Ez jól hangzik, csak titkosítással eléggé ki lehet lőni. A kép a userek és a felhő közé teszi a redundancia-eliminációt, márpedig ott már titkosítottan kéne mennie az adatoknak, és nem a Riverbed tanusítványával, hanem az enyémmel. Erre írtam a keménytojásos megjegyzést, hogy a konformancia kedvéért hamarosan (vagy már akár most) az is titkosított lesz, ami nem titkos.
    Persze ha a tanusítványomat felhővel használom, akkor nyilván meg kell bíznom a felhőszolgáltatóban, szóval végülis működhet. Az alkalmazásnak valamilyen szinten azért tudnia kell róla - legalább annyira, hogy milyen könyvtárat használjon a titkosításhoz, mert abba épül bele ez a megoldás.
    Mutasd a teljes hozzászólást!
  • Szóval cache-elés kilőve, marad a load-balancing.

    Nem. Ez tényleg kiszedi a redundanciát a hálózati forgalomból. Darabokra szedi a hálózati forgalmat megfelelő csomagértelmezők segítségével, és ha olyan részt talál benne, amit a közelmúltban már elküldött a célállomás felé, akkor ahelyett, hogy elküldené, egyszerűen csak egy hivatkozási számot továbbít a helyén - ami nyilván akár egy a millióhoz arányban is kisebb lehet. A célállomás aztán amikor megkapja ezt a hivatkozást, a gyorstárából előszedi az annak megfelelő adatblokkot, és már azt behelyettesítve - tehát az információs folyam eredeti, nyers állapotát visszaállítva - továbbítja a tényleges feldolgozó gép vagy alkalmazás felé az adatokat.

    Az egész olyan, mint a szótár alapú tömörítés, csak itt a működés elosztott, a szótár szavait pedig az ismert hálózati protokollok, illetve az azokon keresztül áramló - szintén ismert - dokumentum és adathalmazok elemi egységei adják. Amik pl. egy Word dokumentum esetén az egyes szövegbekezdések, képek, egy adatbázis esetén az egyedi rekordok, blob-ok, stb. - mindez a hálózati forgalomból transzparensen kiszedve az eszköz által.

    Ennek köszönhetően érhet el pl. az említett Office 365 esetén is 97%-os forgalomcsökkentést az olyan esetekben, amikor pl. valaki (vagy valakik, pl. egy cégen belül, kollaboratív munka során) minimális módosításokkal újra és újra fel-, illetve letölti(k) ugyanazt a dokumentumot.
    Mutasd a teljes hozzászólást!
  • A cím és az egymondatos összefoglaló (A cég megoldásai kiveszik a redundanciát a hálózati forgalomból) alapján azt tippeltem, hogy valaki feltalálta a cache-elő proxy-t, vagy esetleg a load-balancingot. Utána viszont az jutott az eszembe, hogy ma már a keménytojás receptjét is titkosított kapcsolaton szokás továbbítani, különben ugye a keresők majd "nem találják meg" (persze megtalálják, csak lejjebb rangsorolva a 120-ik oldalra), a böngészők meg rémisztgetik a felhasználót. Szóval cache-elés kilőve, marad a load-balancing.

    Igazából a cikket átfutva is ezek a gondolatok maradtak bennem, bár a vége felé láttam benne valami AppInternals izét is.
    Mutasd a teljes hozzászólást!
  • lejön 86ezer sornyi JS, meg minden hülyeség, amit teliokádnak a magukat okosnak gondoló webfejlesztők.

    Ez nem feltétlenül okosság függvénye, hanem egyrészt szükség lehet rá az oldal működéséhez, másrészt indokolt lehet a használatuk akár gazdaságossági, üzleti okoknál fogva is. Pl. egy reklámokból élő oldalnak le kell töltenie mérőkódokat, reklámkódokat is (hiszen ezek nélkül elméletileg igen, de gyakorlatilag nem működhet), de egy üzleti alkalmazás esetében is célszerű lehet már kész, bár "túlméretes" könyvtárak használata ahelyett, hogy mindent újra és újra megír az ember. (Teszem hozzá, ugye te is reklámszűrsz, így te is aktívan hozzájárulsz ahhoz, hogy ne legyen pénz és idő az oldalak optimalizálására - aztán megreklamálod, hogy nincsenek optimalizálva.)

    Ez egyébként asztali vagy mobilos alkalmazások esetében is így, illetve még inkább így van (ti. hogy azokban még inkább pazarolnak a programozók racionális megfontolásból és bénaságból is), csak mivel azok esetében élesen elválasztódik egymástól a letöltés és a telepítés, valamint a használat folyamata, illetve eleve kisebbek az elvárások ezen a téren velük kapcsolatban (teljesen elfogadható ha a program percekig csorog le vagy percekig települ, miközben egy weboldalnál már akkor agyvérzést kapsz, ha 2-3 mp-en belül nem töltődik be), így nem annyira ötlik szembe, hogy azokat (is) mennyire "pazarló" módon írták meg.

    Egyébként meg a cikkben írt technológia ezen túl sokat nem segít az egyéni webező esetében, hanem az alapvetően csak akkor tud bármit is csinálni, ha egy széles, nagy számú felhasználói bázisról beszélünk, ami korlátos számú közös ponton, csatornán keresztül ér el egy adott szolgáltatás, illetve azon legalább részben azonos tartalmakat, dokumentumokat. Egy vállalat tipikusan ilyen, illetve ha valaki geográfiailag sokfelé osztott rendszert üzemeltet, amit nem kifejezetten ilyen működésre optimalizált részekből rakosgatott össze, akkor is rengeteget segíthet egy ilyen transzparens hálózati forgalomoptimalizáció, mint amit ezek a termékek is nyújtanak.
    Mutasd a teljes hozzászólást!
  • Jó ötlet, én attól kapok frászt, amikor betöltök egy hello world egyszerűségű weboldalt, és lejön 86ezer sornyi JS, meg minden hülyeség, amit teliokádnak a magukat okosnak gondoló webfejlesztők. "De hát van keresztmetszet, bírja a HW". Bár inkább azzal jönnek elő, hogy "őket nem érdekli a HW". Nagyon visszafogottan fogalmazva, elk*rvult a szakma. :)
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd