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.
#38