Drobné tipy pro lepší propustnost sítě na Linuxu

Na indickém ZDNetu vyšlo několik tipů pro zvýšení síťové propustnosti na Linuxu. Zabývají se nastavením velikosti bufferů nebo povolením zvětšování TCP okna.

25.6.2007 07:16 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Michal Fecko]

"TCP okno" [TCP window] -> neprekladá sa to skor ako "skupina paketov" alebo "pocet paketov"? Opravte ma ak sa mýlim

[Luboš Doležel (Doli)]

Já okno chápu jako možnou maximální prodlevu mezi odesláním definovaného objemu dat (stanoveno velikostí okna) a potvrzením přijetí druhou stranou - jinak se data považují za ztracená.

[johniez]

Demo okna ve flashi, o prodlevu nejde..

[Luboš Doležel (Doli)]

O prodlevu ve výsledku jde. Jde tu o to, že se po každém kousku dat nečeká na přijetí potvrzení.

[petris]

Okno je počet dat/paketů, žádná prodleva.

[Luboš Doležel (Doli)]

Pokud to chápu správně, tak kdyby nebylo okno, tak by jedna strana před posíláním dalších dat vždy čekala na potvrzení, takže odezva sítě (prodleva) by se odrážela na rychlosti spojení.

[petris]

Způsobů komunikace jak s okénkem, tak bez okénka je několik. Okénko se používá proto, že umožňuje regulovat rychlost toku (nezahltí linku) a přitom je přenos poměrně efektivní.

Pokud Vás zajímá jak s okénkem TCP manipuluje, koukněte do wikipedie, je to tam popsáno docela srozumitelně - rozhodně to není tak, že by se po nějaké prodlevě opakovalo celé okno, ale okno plave (Data se potvrzují postupně a postupně se posílají další).

k tomu

Já okno chápu jako možnou maximální prodlevu...

To je timeout. Okno je opravdu jen o tom, kolik dat/paketů můžu "mít na cestě".

[Filip Jirsák]

Mluvíte o tom samém. "Normálně" by bylo nutné odeslat jeden paket a čekat na jeho potvrzení. Pak odeslat další a čekat, atd. Okno mi umožní poslat těch dat víc (kolik se jich vejde do aktuálního okna) a teprve pak se čeká na potvrzení. Pokud se mi od nějakého paketu vrátí potvrzení (a mám potvrzení i všechny předchozí pakety), mohou si okno posunout až za tento potvrzený paket. Pokud mi tak v okně vznikne volné místo, můžu poslat zase další pakety, než okno zaplním. S rychlostí linky to nemá nic společného, jde o zvýšení interaktivity – jednotlivé strany na sebe nemusí navzájem čekat (resp. čekat na potvrzení z druhé strany). Velikost okna určuje právě "dobu" (vyjádřenou přeneseným množstvím dat), po jakou není nutné "čekat" na potvrzení – proto to Luboš nazývá prodlevou.

[petris]

Jak jsem již psal, protokolů je hodně a ten který popisujete tím

"Normálně" by bylo nutné odeslat jeden paket a čekat na jeho potvrzení.

je pouze jejich podmnožina. Můžete mít třeba protokol, který na žádná potvrzení nečeká a posílá tak rychle, co mu HW stačí. Třeba u přenosu hlasu se data většinou posílají takovou rychlostí jakou přicházejí a nepotvrzuje se každý paket (když se jich pár ztratí tak se nic neděje), ale jen se strany informují o tom, že udržují spojení.

Také Váš popis okna neodpovídá tomu, jak to funguje u TCP (o kterém ta zprávička byla). Potvrzují se totiž byty a ne pakety. A potvrzení říká, že od tohoto bytu můžu příjmat = všechny nižší už mám.

Velikost okna určuje právě "dobu" (vyjádřenou přeneseným množstvím dat), po jakou není nutné "čekat" na potvrzení

Doba se v bytech měřit nedá a to i přesto, že je napsaná v uvozovkách.

[johniez]

ja ziju v domneni ze se potvrzuji pakety..

[petris]

A zjevně nejste sám. Naštěstí jsem Vás díky této diskuzi vyvedl z šedi potvrzování paketů na světlo potvrzování bytů.

[Filip Jirsák]

Potvrzují se nikoli pakety, ale sekvenční číslo, které se u TCP/IP zvyšuje s délkou paketu v bajtech. Tváří se to tedy (na příjemci) jako by se potvrzovaly pakety, protože klient těžko dostane data z půlky paketu. Na odesílateli se to tak tvářit nemusí, protože pakety mohou být cestou fragmentovány na menší a příjemce může potvrdit příjem těchto menších částí. Ostatně sekvenční čísla slouží mimo jiné právě pro identifikaci paketů, protože vzhledem k možnosti fragmentace je není možné očíslovat jinak než po nejmenších kouscích, na které je možné je rozdělit – tudíž po bytech.

[petris]

Potvrzují se nikoli pakety, ale sekvenční číslo, které se u TCP/IP zvyšuje s délkou paketu v bajtech. Tváří se to tedy (na příjemci) jako by se potvrzovaly pakety, protože klient těžko dostane data z půlky paketu. Na odesílateli se to tak tvářit nemusí, protože pakety mohou být cestou fragmentovány na menší a příjemce může potvrdit příjem těchto menších částí.

Fragmentaci paketů provádí nižší (linková) vrstva a stejně tak fragmenty na druhé straně opět skládá, takže spojová vrstva (TCP) dostane opět celý segment nebo nic, pokud se nějaká část ztratí.

Z toho vyplývá že k potvrzování nějakých menších paketů, jak o tom Vy píšete, nemůže dojít. Podle Vás by museli switche, které pracují na druhé vrstvě a mohou provádět fragmentaci, rozumět protokolu vyšší vrstvy a při fragmentaci rozkopírovávat TCP hlavičku (která se navíc ani do nejmenších možných paketů nevejde).

Ostatně sekvenční čísla slouží mimo jiné právě pro identifikaci paketů, protože vzhledem k možnosti fragmentace je není možné očíslovat jinak než po nejmenších kouscích, na které je možné je rozdělit – tudíž po bytech.

To je už naprostý nesmysl, protože při fragmentaci IP paketu se údaje o fragmentaci uloží do IP hlavičky a IP paketu je naprosto jedno, co má v sobě zabaleno za data.

[Filip Jirsák]

Máte pravdu, fragmentuje se až na úrovni IP. To jsem si nikdy neuvědomil, že IP fragmentace a TCP potvrzování není nijak propojené, takže ztráta jednoho fragmentu znamená nutnost nového přenosu celého původního TCP paketu. Koukám, že velké MTU na jednom konci TCP/IP spojení nemusí být žádná výhoda, pokud je na druhém konci nějaké rádio s tendencí občas něco ztratit.

[petr_p]

Což je taky důvod, proč se v IPv6 fragmentace považuje za sprosté slovo a raději se u prvního spojení určí MTU cesty, údaj si OS zanese do směrovací cache a pak se jede poměrně bezstarostně.

Jenže vysvětlete tohle 02, který ICMP Packet too Big / Fragmentation Needed pošle jednou z deseti případů.

[Filip Jirsák]

Takže velká výhoda TCP/IP – že každý paket jednoho spojení může jít úplně jinou cestou – je rázem pryč. Nebo je to tak, že MTU se určí na začátku a aby se zbytečně neposílaly velké pakety, když je jasné, že nejspíš neprojdou – ale přesto je možné později pakety fragmentovat, když se změní podmínky v síti?

[Michal Kubeček]

Fragmentaci paketů provádí nižší (linková) vrstva

Tady jste se trochu přepsal, není to linková vrstva, ale síťová.

[Luboš Doležel (Doli)]

A demo nefunguje. Flash verze 9 tomu prý nestačí.

[Käyttäjä 11133]

V mém flashi 9 to funguje :)

[petris]

Zatím vždy, když jsem se s tím setkal, tak se tomu česky říkalo okno. Je to počet paketů/velikost dat, která můžu odeslat bez čekání na potvrzení.