Hunter

Felgyorsíthatja a letöltéseket az új rendszer

Képzeljünk el egy Internet kapcsolatot, ami olyan gyors, hogy egy teljes mozifilmet mindössze öt másodperc alatt sikerül segítségével letölteni, vagy TV minőségű videó szerverekhez enged valósidejű hozzáférést. Ezt ígéri a Kaliforniai Technológiai Intézet, a Caltech egyik fejlesztő csapata, akik egy új rendszerrel készülnek előrukkolni, mely a Fast TCP névre hallgat. A Fast TCP talán legnagyobb erénye, hogy használható a jelenlegi Internet infrastruktúrán is.

Steven Low, a csapat vezetője az Internet mai működését egy olyan útszakaszhoz hasonlítja, ahol a látótávolság mindössze 10 méter. Lassan növeljük a jármű sebességét, egészen addig, míg egy akadály elénk nem kerül, akkor ugyanis bele kell taposni a fékbe. "Ez még meg is felelne, ha egy parkolóban autóznánk" - mondta Low. "A főúton azonban jóval tovább kellene látnunk, ezt fogja biztosítani a Fast TCP."

Ma minden Interneten zajló forgalom a Bob Kahn és Vinton Cerf által a hetvenes években kifejlesztett Transmission Control Protocol-t (TCP) használja. A TCP a nagy file-okat körülbelül 1500 byte-os kis csomagokra bontja, melyek mindegyike szállítja a küldő és a fogadó címét. A küldő számítógép továbbítja a csomagot, vár egy jelre a fogadótól, ami nyugtázza a biztonságos átérést, majd küldi a következő csomagot. Ha nem jön visszajelzés, a küldő ugyanazt a csomagot újra elküldi fele akkora sebességgel, egészen addig ismételve egyre lassabban a folyamatot, amíg sikerrel nem jár.

Ez annyit jelent, hogy akár a vonal legapróbb hibája rendkívül döcögőssé teszi a kapcsolatot. Mivel a Fast TCP ugyanazokat a csomagméreteket használja, mint a hagyományos TCP, az üzeneteket szállító hardver továbbra is alkalmazható. A különbség a szoftverben és a küldő számítógép hardverében rejlik, mely folyamatosan méri az elküldött csomagok és a visszaigazolás megérkezéséhez szükséges időt. Ez felfedi a vonal késedelmeit, korai figyelmeztetést adva a lehetséges csomagvesztésekről. A Fast TCP szoftver ezt használja fel, hogy megbecsülje a legmagasabb adatrátát, amit a kapcsolat adatvesztés nélkül képes biztosítani. Mivel a csomagok azonos méretűek a TCP által használtakkal, az Internetes berendezéseket nem kell módosítani és nincs szükség új hardver beépítésére az adatokat fogadó számítógépekbe sem.

A Fast TCP első gyakorlati tesztjére novemberben került sor egy konferencia keretében. A Caltech kutatói a kaliforniai Sunnyvale-től 10.000 kilométerre fekvő genfi CERN-hez másodpercenkénti 925 megabites átlaggal küldtek adatokat. A hagyományos TCP ugyanezen az úton mindössze 266 megabitet ér el. Tíz Fast TCP rendszer csoportosításával a kutatók másodpercenkénti 8,6 gigabites adatátviteli sebességet értek el, ami a hagyományos broadband kapcsolat hatezerszerese.

A jelenleg fejlesztés alatt álló "Internet 2" infrastruktúra, melyet a világ 200 egyeteme közötti tudományos adatforgalomra szánnak, a hagyományos TCP-t fogja használni, ami másodpercenként 350 megabites sebességet tesz majd lehetővé, azonban a Caltech technológiájával itt is jelentős sebességnövekedés érhető majd el. A sávszélesség-faló szórakoztatóipar szintén nagyon szeretne hozzájutni a Fast TCP-hez. A Caltech már tárgyal a Microsofttal és a Disney-vel a felhasználásokról.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • nyunyu #57
    En csak azt nem ertem az egeszben, hogy mi tartott eddig ebben a fejlesztesben? Feltalalni a spanyolviaszt?

    Mar a TCP is kepes a csuszoablakos aramlas-szabalyozasra (ami itt gyakorlatilag a Fast TCP lenyeges ujitasakent van feltuntetve, meg ha nem is neveztek neven), csak eddig ezt miert nem hasznaltuk?

    Ja, hogy nagyobb puffer szukseges hozza a routerekbe, mint a klasszikus "eltarolok 1 csomagot, aztan addig probalkozom, amig meg nem jon a nyugtaja" tipusu low-cost, eredetileg lassu, megbizhatatlan kapcsolt vonalra meretezett megoldashoz?

    Mai 1-a 10^-9 bithibaaranyu optikai osszekottetesek vilagaban ennek nyilvan semmi ertelme sincs, mert csak lassitja az adatatvitelt, hiszen amig visszajon a nyugta az Atlanti-ocean tuloldalarol, azalatt legalabb 10-20 masik csomagot at lehetne kuldeni a csuszoablakos modszerrel.
    Sot.
  • Bucser #55
    de az a 66 K/ec az annyi amennyit egy atlagos letöltésénél az első névleges sebességmérésnmél savszelben lefoglal feléd a server ujra és ujra. De a technologia lényege az hogy ki is hasznalja a rendelkezésre állo savszelt és nem csak ott van és lehetősége van ra. mert a mostani tcp felezi a savszelt. szal ha 66K/sec-d van és elküldi ezzel a sebességgel az adatot de visszaigazolas nem jön akkor ujra küldi 33 K/seccel de ugyanugy 66 K/secet foglal le maganak az adatcsomag. az uj technologia lényege az hogy annyit foglal le amennyit kihasznal és nem annyit amennyit maximum igénybe fog venni. a letöltésvezérlők pedig mar a bejövő adatfolyam sebességét is korlatozzak. szal ha 2 fajlt töltessz akkor mind1 honnan jön többel meg fogjak felezni a max savszeledet az egyik és a masik fajl között. szal ha az egyik helyről jöhetne 300-al de csak 66-od van a masikrol meg 33-al max akkor mind2 helyről 33-al fog jönni.
  • dikki*yysw #53
    Hú de sötét emberek vannak, tényleg.
  • Omegared #52
    :)) Egyszerűen megoldottad. Én is ezt próbáltam elmagyarázni csak nem ment... :DD

    A te példád jobb :)
  • Bucser #51
    Na itt egyetlen dologrol van szó a cikket elolvasva. Meglévő fizikai savszelességet folymatosan ellenőrzött és nem automatikusan feleződő és lassulo adatfolyammal atlagban hatekonyabba lehet tenni mint amilyen most. otthoni felhasznalonak ez azt garantalhatja esetleg, hogy az az 512 Kbit/sec nem fog ugralni masodpercenként 0,4 kbit és 512 kbit között hanem megallapit egy értéket amin fogadni tud azon az utvonalon és folymatosan ugy küldi mondjuk 400kbit-el.és 10* 400 kbit még mindig több mint 5*512kbi+5*100kbit ami a folyamatos ingadozasbol jön... nem igaz???? ÉS most olvaassatok el ujra és ennek függvényében gondoljatok at, hogy baromsag-e ami a cikkben van irva... a 10*400Kbit csak egy sarkjitott példa volt mint pl a borsoszemes magyarazat Omegared billjéből:))
  • Csabi #43
    Termeszetesen ha valakinek pl. az 512-es dsl-je nem megy 512 korul, akkor annak segit. De en azt irtam, hogy 512 fole nem fog menni, mert sokan ezt hiszik.
  • Omegared #42
    Ha kicsit értenél a dologhoz akkor rájönnél mekkora hülyeséget írtál...
    Egy 512-es Dsl nél mennyi a letöltési max? 70 valamennyi Kbit /sec? Mondd meg nekem mindíg annyi? Neked sohasincs ingadozás??

    Ez a Fast Tcp ezen segít. Segít leküzdeni a torlódásokat, maximalizálja a keresztmetszet kihasználtságát...
  • Omegared #41
    De ez a technológia pont azt segíti hogy ki is tudd használni azt az 512kbitet. Mert az egész átlagot nézve most elég veszteségesen működik minden... Értsétek meg az elméleti sávszélesség csak a jéghegy csúcsa ebben a mókában...
  • Csabi #39
    Aki pl. egy 512kbites adsl-el csatlakozik a szolgaltatojahoz, annak max 512kbit-el fog jonni az adat. Lehet, hogy az uj technologia hasznalataval a szolgaltato szerverere sokkal gyorsabban fog megerkezni, de te onnan a mestersegesen lekorlatozott egyebkent sok megabitre kepes adsl vonalon keresztul fogod megkapni. Ugyhogy otthon internetezoknek nem kell orulniuk, nincs miert :)
  • Omegared #38
    Sokan még mindíg nem értik.

    Embrio mondta:
    Harmadik, az adatvesztes-t nem tudod befolyasolni azzal hogy lassaban kuldesz, max a szazalekos arany lesz jobb mivel kevesebbet kuldesz de lenyegeben nem lesz tobb adatod.

    Ez így nem igaz.

    Az egész adatátvitelnél a lényeg a sebesség átlag az idő függvényében és nem a pillanatnyi Kbit/sec.

    Nézzük a jelenlegi helyzetet.
    Adott kiszolgáló a kérés után elkezdi küldeni az első csomagot azzal a maximális sebességgel amit képes elérni. Ideális esetben átjut a csomag és a visszaigazolást is megkapja a kiszolgáló. Ezután küldi a következőt, ellenőriz, majd megint és így tovább. A gond akkor kezdődik ha a hálón valahol elakad egy csomag, vagy nem jön meg a megerősítés az adat vételéről. Ekkor a kedves kiszolgáló elkezdi felezni a küldési sebességet (a hiba kb. olyan mintha egy tölcsérbe öntenél borsót, ha sokat öntessz és gyorsan eldugul a tölcsér szája, vagy csak nagyon lassan mennek át a szemek) addig amíg nincs visszaigazolás.

    Lényegében a Fast Tcp sem szünteti ezt meg azonnal, csak folyamatosan figyeli az adattovábbítás folyamtának paramétereit, és ezek segítségével próbálja dinamikusan kikalkulálni azt a maximális küldési sebességet amit még csomagveszteség nélkül elbír a háló. Ergó azért lesz gyorsabb ezzel a technológiával a nyet mert segítségével egy effektíve folyamatos, (elméletileg) csomagveszteség nélküli adatfolyam hozható létre. Nem mint most amikor az adatátviteli sebesség úgy viselkedik mint a hullámvasút. Elég megnézni egy letöltésmanagert munka közben, és a letöltés után a sebesség
    átlagot.

    [FOS]Johnny: te meg olvasd el a cikket...

    Bye:
    Omegared