tcpdump kimenetet nem ertem - ack csomagban mikor/miert van/nincs payload?

A tcpdump kimenet alapjan nincs idoelteres, persz lehet, hogy csak kicsi a felbontasa.
pontosan, igen, mert az idozites a peer-en (aki a 19, 20, 21 csomagot kuldte) zajlik, ezeket az idoadatot meg a kliens me'ri. altalaban egy gyors (~100mbit) halozatnal az elso 3-4 re-transmission mar kb 1/20 masodperc alatt lezajlik, ahol mar eleve az egyes csomagok kozotti ido is exponencialisan no", tehat ilyen szintu idoziteket nem realtime kernel eseten a madzag masik vegen mar nem lehet pontosan me'rni.

Tudsz errol konkretumot hogy mukodik?
ugy nagyvonalakban kb igy mukodik: van X es Y gep, azok kommunikalnak. az X gep kuld adatot, akkor a seq(X) szamlalo mellett van egy hossz is (L), mikor ezt Y megkapja, akkor visszakuld egy ack(Y)-t, amire igaz lesz, hogy seq(X)+L=ack(Y). namarmost az ethernet/ip az csomagokat kuld, igy egy csomagba kerul az is hogy ezeket az ack-okat Y megkuldje X-nek. tfh hogy egy "kicsi" (~40 byteos) csomag kuldesee ugyanannyiba kerul mint egy nagy (~1500 byteos), mert olyan a hardver.

nomarmost ekkor ha 10mega/sec-cel tolti X az adatot Y-be es elva'rna' hogy _minden_ csomagocska utan jojjon ack, akkor a masik iranyu savszelesseg is drasztikusan leesne (1:1 lenne a kuldott/fogadott csomagok aranya). ezert az van, hogy Y leszol X-nek hogy mennyi adatot kuldhet "felelotlenul" (ez a tcp window), az X az kuldi az adatot, es csak akkor kezd el nyafogni (retransmission, stb), ha ez az ablakmeret mar betelt, de me'g nem kapott ack-okat. ezert amikor "toltesz 1000-rel", akkor ez az ablak szepen megno" (aka'r a 64k-s hata'rt is atlepheti, ha van erre tcp option tamogatas), ekkor X nyugotan tolti fel a cuccot, Y meg neha ack-ol, mikor jonak latja. ez igy tok jol hangzik, de: amint X befejezte az adatkuldest, es nem telt be az ablak, akkor Y nem feltetlenul ackol rogton, hiszen me'g azt hiszi hogy majd jon adat. ekkor X kuld egy push bitet is (lasd tcp flags), es erre mar Y eszbekap, es ack-olja az adatot, de ez egy ures ack (sot, itt ha csak egyiranyu az adatforgalom, akkor Y lenyegeben payload nelkuli csomagokat kuld csak).

fokozva, http: itt az van hogy X kuld adatot (relative keveset: http request header), majd Y valaszol (relative sokat: honlap, kepek, stb). a http request header par csomagba belefer (akar egybe is, ha sok a cookie es/vagy postdata, akkor tobbe), de a window mar eleve gyorsan megszalad, akar 2-3 csomag lekuldese eseten (alapesetben exponencialisan no", 1024, 1280, 1536, 2048, 2560, 3072, 4096... asszem kb ez a szekvencia). a http request header utolso csomagjaval megy a push bit is, erre Y azonnal valaszol egy ack-kal, de utana rogton megy is az adat (honlap). viszont mi van akkor, ha ez a push-ra adott ack elveszik? akkor X egy ido utan ujrakuldene' a http request header-t, mondvan, hogy "biztos azert nem jott ack mert Y nem kapta meg". de, megkapta, csak X nem kapta meg, hogy Y megkapta... viszont Y rogton adatot is kuldene (mondvan hogy a http req megjott, mehet a moka). ilyenkor ha nem allitana be az ack-ot, akkor X az tovabbra is kuldene ujra a http req-t (amit Y persze lenyel, mondvan hogy ez mar megjott, hiszen ha seq(X)+L < ack(Y) fennall, akkor olyan adat jott le ami mar egyszer jott es Y tudomast is vett rola). igy viszont ha me'g az adat melle' Y beallitja az ack(Y)-t (de nem noveli, mert mar X nem kuld adatot) is, a megfelelo" tcp flag mellett (ack bit=1), akkor X mar nem fogja ujrakuldeni a http request header-t.

egy ilyen baromi egyszeru" master-slave protokol mint a http eseten is tudnak tehat vicces dolgok kialakulni, egy nem ennyire egyszeru adatforgalom meg huzosabb...