hapi píše:to je všechno sice hezký jenomže tohle bych pochopil kdyby se rychlost snížila o pár procent a ne o většinu obzvlášť když se na hranici linky jednim spojením nikdy nevyškrábeš například natestu dáš 20-30Mbit a linka je 200Mbit. To mi nejde do hlavy.
Ještě k tomuhle. Ty efekty někdy nesnižují o pár procent, ale na zlomky maximálky v závislosti na některých soubězích. Ale můj soukromý názor je, že majoritní problém je v prasácky napsaných aplikacích (měl jsem tu čest to mlátit do hlavy už pěkné řádce programátorů, jak se to ne/má dělat a řada jich koukala jak bagr na tvrdou hlínu, přestože je to roky živí).
Pokud chceš se dobrat toho, proč to dává tak málo a máš k dispozici jen ten přenášený stream dat, tak se dá z toho hodně odchadnout, pokud k tomu je i odchycená aplikace, jak následují systémové/knihovní volání, tak často problém se přemění ve zvracení a dál není na síťové vrstvě co řešit.
Jinak obecně, pokud chceš u konkrétního spojení se někam dobrat, tak předpokládám, že jseš schopen ho celé odchytit a koukal bych na toto:
V SYN/SYN ACK fázi se mrknout jak je MSS, hlavně s ohledem na skutečně to, co projde sítí. Kdo používá něco jako PPPoE/L2TP/MPLS a nemá pro koncové klienty oblíbené MTU 1500 a MSS přitom bude nastaveno na MTU 1500, tak ho čekají problémy. Někdo už zjsitil, že když je nastaveno DF v paketu tak občas spojení nejede vůbec (debilní firewally po cestě/u klienta bránící MTU discovery), tak to řeší shazováním DF (nemělo by se, ale když už to i ROS umí) a má klid, ale s efektem, že když je MSS moc dlouhé, tak pak každý paket se fragmentne na dva a přenosová efektvivita jde do háje, hlavně na wifinách. Jiný bod je, pokud MSS se nastřelí moc nízko. Defaultně se určuje tak, že pokud koncová IP padá do lokální sítě, tak se MSS navrhne z MTU LAN-TCP-IP záhlaví, pokud to jde dál, tak některé systémy mají snahu tam cpát default 576, což není ono, tisíce malých paketů ucpou kde co. Nezapomenout případně na aktivní TCP rozšiřující hlavičky, které ten výpočet o 20 bajtů trochu nakopnou (např meření RTT). Následně mrknout dál do dat, zda nedochází k fragmentaci paketů, která to efektivně srazí dolů, třeba vlastnostmi sítě o kus dál za naší hranicí u protistrany.
Dále mrknout, zda došlo k vyjednání windows scale a pokud ano, tak v jakých hodnotách. Pokud dojde na scale faktorem 2^10 a více, tak už se může projevit to, co jsem psal, že minimální úkrok v okně dolů je už dost velký na nevytížení linky (nicméně by neměl jít na zlomek kapacity, u 2^12 a více to už bude úlet na normánlí koncové síti - programátor to kapánek přestřelil).
Taktéž v SYN/SYN ACK mrknout, zda došlo na vyjendání podpory ECN, pokud ano, tak koukat, zda nedošlo za přenosu pak k nastavení ECN bitu od routerů jako žádost o snížení toku (to tvrzení výše, že RED znamená vždy zahazování paketů není úplně přesné, pokud si spojení vyjedná ECN, tak limitující prvek používající RED prvně přistoupí k nastavování ECN a teprve když nezareagují komunikující konce, tak je začne dropovat, nicméně ROS v kombinaci s REDem ECN nepodporuje, samotný linux to s tc umí, stejně tak Cisco a další). Windows ECN umí od Vist/W2K8, ale výchozí stav je vypnuto, linux umí také.
Pokud je vidět za běhu dat působení ECN, tak to něco po cestě se snaží řezat. Pokud vypadávají pakety, tak opět buď řeže něco bez podpory ECN nebo ztráta dat, která pak má dopad na rychlost a je třeba hledat kde se děje, ale to už je pak jiné kolo problému.
Dále se dívat, co dělá nabízené max okno hlášené klientem. Pokud nejsou výpadky paketů a ani ECN do toho nekecá, tak to má být rozumně se držící hodnota dle algoritmu v daném OS to najet na něco ustáleného. Pokud ta hodnota padá dolů a zase vyskakuje, případně se drží hodně nízko, tak to nezvládl autor aplikace klienta - přebírá data po malých blocích z vyrovnávacích bafrů a ne dost hbitě a toto působí zpoždění. Pokud bude okno padat až na nulu, tak autor byl totální trotl a asi si nastavil wake up watermark na velikosti 100% plného bafru a tím to zabije. OS nabafruje plný bafr pro TCP daného spojení, pak ohlásí protistraně tou nulou v okně, že nemůže dále přijímat a až to aplikace načte, tak opět ohlásí, že se může jet dále = prvotřídní zabiják výkonu.
Pokud okno nabízené klientem se drží pořád ustáleně daného maxima, tak se podívat, jak na to reaguje vysílací strana. Jednak zda po ACK rychle jdou další data a kolik jich je. Pokud dojde míň dat, než je okno, tak odesílací strana nestačí krmit odesílací bafr, buď ho má příliš nízký a krmí po malých částech, případně i opět debilita autora na Ntou, že si nastaví low watermark na prázdný bafr, tak bude docházet k opožděnému ack přiijatých dat, takže dojde-li méně dat než okno, tak přijímající klient bude čekat nějakou dobu, než je potvrdí (myšlenka stacku je, že je škoda posílat prazdný ACK, chvíli počkáme, zda nebude i něco dat k odeslání protistraně, linux takto nyní čeká tuším 40 ms, RFC připouští až 500 ms). Toto opožděné potvrzování je velice účinná brzda přenosu. Účinně toto brzdí i v mnohem nenápadnější formě, kdy k opožděnému potvrzování dochází jen částečně. To je případ, kdy odesílací strana má bafr nastavený na velikost, která neopovídá násobkům velikosti okna a aplikace jede synchronně, kdy chce budit až je bafr prázdný, pak to dopadne tak, že se část dat přesune v několika oknech rychle poslaných a pak následuje ten konec daného bafru menší než okno, ten se potvrdí opožděně a vysílací strana opět něco pak dokrmí. Toto stlačí přenosovku také, al enneí to na toku na první pohled vidět, až při projití celé sekvence se pak i dá určit, jak velký odesílací bafr má server. Záleží na kombinaci velikosti okna, velikosti odesílaného bafru a jak má aplikace nestaveny limity pro informování, zda má dodat/vyčíst další data a i jak nastavuje některé další vlastnosti socketu. Potom může nastat jiný případ (podobně odesílací i přijímací strana), kdy přenos řeší asynchronně, ale neberou rozumně limity pro buzení na přebírání dat a strká se to a odesílá s každým paketem a menším blokem blokem dat, pak počítatč akorát mlátí dokola tuny systémových volání na kopírování dat a 100x málo kopírovaných dat umořilo osla (a to i v případě použití sendfile() s blbě nastavenými parametry socketu)....
Takže pokud si odchytíš celé takovéto pomalé spojení i s časy, tak se dá analýzou dospět k tomu, kde to pravdpěodobně stojí. Přeji příjemnou zábavu, než ti napadne sníh.
To asi shaping nebude.....
(Linuxaci prominou)