V principu to funguje asi nasledovne:
TCP protokol pouziva pri prenosu datove bloky, ktere jsou po uspesnem prenosu (ne kazdy blok musi byt nutne dorucen) potvrzovany, aby se na potvrzeni nemuselo cekat prilis dlouho, vysilaji se bloky po skupinach a potvrzuje se najednou cela skupina, pokud nejaky blok skupiny neni potvrzen, je v nasledujici skupine zopakovan. Prijemcuv software pote prijate bloky seradi do puvodniho poradi a preda dale. Toto vse vyzaduje pridat najaka data navic a obcas preci jen trochu cekat.Uvedena "optimalizace" spociva ve zmene(=zvetseni) pouzite delky bloku, tim se zmensi mnozstvi pridanych dat v pomeru k prenasenym aplikacnim datum, a zvetseni poctu bloku ve skupine. Vychazi se z predpokladu, ze soucane technologie prenosu dat modemem jiz sami resi detekci a opravu chyb, cili samotne TCP bloky jsou vzdy prenaseny beze ztrat a vypadku. V praxi jsou ale data po trase mezi obemi koncovymi body (mezi ISP)fyzicky prenasena technologiemi Ethernet, ATM a SDH, atp.(plati pro Evropu a CR), ktere vsak vyzaduji uplne jinou "optimalizaci", takze jsem nikdy nepozoroval sebemensi urychleni. Mozna je jina situace v USA, kde zatim stale velke mnozstvi spoju vyuziva technologie FDDI, ktera se od Ethernetu a ATM velmi vyrane lisi, tam bych v nejake urychleni mozna i veril. Navic pokud je mi znamo, vyse zminena nastaveni v prostredi Windows plati globalne, tj. pro vsechna rozhrani a dle mych zkusenosti po provedeni teto "optimalizace" dochazi ke snizeni prenosove rychlosti protokolu TCP na lokalni siti LAN. Takze pokud pozivate danny pocitac jako sitovou stanici nerkuli server, v zadnem pripade by jsem uvedenou modifikaci nedoporucoval. Nastaveni Windows TCP/IP je totiz defaultne "optimalizovano" prave pro 10/100 megabitovy Ethernet.
P.S.: Uvedeny vyklad byl pro zkraceni, znacne zjednodusen, podrobnosti viz. odpovidajici RFC nebo jina odborna literatura.
S pozdravem, RaStr.