Optimalizace TCP protokolu na WAN linkách

[sub_zero]

Pro všechny "postižené" tímhle problémem doporučuju přečíst práci od p. Grygárka. Je tam vysvětlena spousta principů o kterých tuším spousta lidí ani netuší
Později dodám ještě zbytek práce v nascanované podobě.

Kód: Vybrat vše

http://www.cs.vsb.cz/grygarek/TPS/projekty/0506Z/roh035-TCP-Optimization.pdf

[sub_zero]

Nasel jsem jeste jeden krasny a strucnej clanek kterej ukazuje, jak dulezity je mit spravne nastevenou velikost TCP Okna (webservery, file servery apod). Sice uznavam, ze sitovy akceleratory uz dneska asi malokdo pouziva a spis si ladi TCP/IP stack.

http://bradhedlund.com/2008/12/19/how-t ... nce-links/

[Walkeer]

Dodam, ze moderni OS se znazi optimalizovat TCP automaticky a to prosim vcetne W7

[sub_zero]

Dodam, ze moderni OS se znazi optimalizovat TCP automaticky a to prosim vcetne W7

jo? tak si prosim pripoj do mirror portu na switchi Wireshark a spust si nejaky stahovani z FTP na lince okolo 10ms a mozna se budes divit

[hapi]

windows_size.png (8.72 KiB) Zobrazeno 2252 x

[sub_zero]

Stando, nechce tu tabulku jeste upravit pro nejcastejsi RTT kolem 8-10ms? Je to celkem sikovna pomucka.

[hapi]

tohle jsem našel někde na netu a přesnej výpočet neznám ale těžký to asi nebude.

[sub_zero]

tohle jsem našel někde na netu a přesnej výpočet neznám ale těžký to asi nebude.

TCP-Window-Size-in-bits / Latency-in-seconds = Bits-per-second-throughput

[hapi]

tabulka hovoří jasně. Pokud je fixnutý window size na 16kB, tak prostě do netu horko těžko dáte s latencí 20ms rychlost na jedno spojení 6.6Mbit.

Jde tedy defakto o odeslání určitého bloku dat bez potvrzení z druhé strany. Ten blok dat je window size. Při 16kB se tedy odešle 16kB dat a pak se musí bezpodmínečně počkat na potvrzení z druhé strany že data přišli. Pak se začne s dalším přenosem. Pokud jsou chyby, window size resp. okno se snižuje aby omezilo ztrátovost. To může způsobit i shaping jelikož funguje třeba na principu zahazování paketů pro omezení datovýho toku. Pokud ale chyby nejsou ale je dlouhá latence, systemy na obou stranách by měly domlouvat postupem času větší okna pro komunikaci a na jeden zátah poslat víc dat aby efektivně využily dostupnou rychlost kterou mohou ject.

Podobně funguje například nstreme. Defakto shlukuje data do balíků a pošle přes wifi jako jeden velkej blok. Tady to je spíš kvůli tomu aby se ušetřily režijní data ale princip je stejnej. Proto je těžký vytížit NV2 na plno pomocí TCP a jednim spojení protože 4ms latence už je sakra hodně na 150Mbit jednim TCP spojením a defakto i docela nemožný.

Pokud tedy na vdsl máte latenci 20ms, je hodně pravděpodobné, že prostě nepřesahnete na testech bez změny TCP window size ani 10Mbit.

[hapi]

window_size.png (70.6 KiB) Zobrazeno 2222 x

[hapi]

Pokud někdo má v síti samba server tak ví, že ačkoliv tam má diskový pole rychlý jako kráva, všude gigový porty, všechno nej, tak stejně se zasekne někde na cca 300Mbit díky tomu, že samba server nedokáže přizpůsobit window size větší hodnotě než 16kB, aby dokázal protahnout víc. Tim pádem tam je latence někde na 0,5ms což by při defaultním 16kB window size bylo někde přes 300Mbit což odpovídá. Jak prosté vysvětlení.

[sub_zero]

Presne.. ovsem domaci LAN nas ISPky netrapi tak moc, jako WAN sit (tzn. od Tebe treba do Prahy). Tam je strasne dulezita optimalizace TCP, aby zakaznik dostal opravdu to, za co si plati.
Nejvetsi smrt jsou L4 prvky v siti, tam dochazi k nejhorsi destrukci. A proto se doporucuje povypinat flow controly, autonegace a vse fixnout natvrdo.

[hapi]

no a pak tu máme levelův problém kde se prostě window size nedařilo zvětšit a na vině byly L2 prvky.. ehm... hromada L2 prvků... velká hromada prvků. Přesněji 13 switchů za sebou v řadě.

No a proč vlastně ty musíš u klientů používat tcp optimizer když ostatní to dělat nemusí? Neni to divný? Vim že máte infrastrukturu hodně pokročilější než my a tyhle problemy nemáme. Navíc naše síť má větší latence než vaše včetně připojení do netu.

[sub_zero]

Protoze L2 a L4. Proto. Ja nikdy nerek, ze TCP optimizer v nejaky velky mire pouzivame. Reknem si na rovinu, pri WiFi pripojeni je to totalne k hovnu. Ale nasad si nejakej server /treba na Win 2008R2 s IIS nebo Apache/ a posad ho na rychlou linku. Bez vyladenyho TCP/IP stacku splaces nad vydelkem... Ten problem jsme meli s tim nasim Speedtestem.. Pak se predelal na ten Debian, poladil stack a jede jako vino.

[Walkeer]

no a pak tu máme levelův problém kde se prostě window size nedařilo zvětšit a na vině byly L2 prvky.. ehm... hromada L2 prvků... velká hromada prvků. Přesněji 13 switchů za sebou v řadě.

No a proč vlastně ty musíš u klientů používat tcp optimizer když ostatní to dělat nemusí? Neni to divný? Vim že máte infrastrukturu hodně pokročilější než my a tyhle problemy nemáme. Navíc naše síť má větší latence než vaše včetně připojení do netu.

Muzes mi prosim vysvetlit, co ma spolecneho L2 prvek s TCP/IP? Pokud se nepletu, tak ty L2 prvky nemaji o nejakem window size ani poneti, prave protoze operuji na 2. vrstve, kdezto TCP/IP zacina na 3.