Dotaz: Jeden stahuje, ostatní si nevrznou.

[Jirka]

Zdravím všechny,
potřeboval bych trochu popostrčit, co hledat a případně s jakým programem máte zkušenosti, manuály už si dohledám.
Klienti se připojují na net přes server, který zastává funkci routeru. Problém je v tom, že když jeden začne sosat (je jedno, přes jaký protokol), zabere celou šířku pásma a z jinýho počítače pak vázne komunikace ven i dovnitř.

Nechci to nastavovat natvrdo, pokud bude na síti volno, ať ji ten jeden využije celou, ale když se připojí kdokoliv další, musí na každého zbýt obousměrně minimálně 32kB/s prostoru.
Máte tip, jak to udělat? Díky.

---

---

Odpovědi

[Petr Šobáň]

QoS, klasifikace provozu

[Karel]

Kdesi jsem četl názor, že pomocí QoS lze řešit jen to, co teče ode mne pryč. To co teče z venku ke mě (download) prý ovlivnit nejde.

Může se mi prosím někdo fundovaný k tomuto tvrzení vyjádřit.

Díky.

[Petr Šobáň]

Ano, ovšem když QoS zjistí že teče moc k tobě tak omezí odesílání žádostí o data a tím pádem i klesne příchozí trafic.

Jinak žádná služba nemůže omezit to co k tobě teče, to může pouze stroj - zařízení na druhém konci.

PS. Jak chceš někomu zakázat aby ti posílal data? Nijak ty je akorát můžeš ignorovat. A když ti zahltí linku tak je tvůj PC nedostupný....

[Max]

Nepletl bych si to s útokem . Regulérní příchozí traffic lze samozřejmě regulovat. Když jsem si s tím kdysi dávno hrál, tak to fungovalo na bázi zahazování packetů. Prostě shapper občas zahodil nějaké packety (nepotvrdil jejich přijetí) a druhá strana pak snížila rychlost odesílání.
Dost často se k omezování příchozího trafficu využívalo IMQ.
Samozřejmě to není zcela ideální/přesná záležitost :-/.
Zdar Max

[Karel]

Proč "používalo"? Resp. co se používá dnes? Je z čeho vybírat?

PS: Líbí se mi kontrolní otázka (zadejte aktuální rok)

[Jirka]

ad PS: jen aby na serveru měli kluci dobře seštelovaný hodiny
Samozřejmě díky všem za odpovědi, nějak se s tím poperu.

[Petr Šobáň]

Jasně útok je něco jiného a jediné co s tím jde dělat je zahazovat to.

Samozřejmě slušný stroj spomalí posílání jak nedostane potvrzení že paket dorazil sníží rychlost a nebude se pokoušet tě zavalit hromadou paketů.

[j]

Tos cet dobre, jenze se to tyce konkretniho rozhrani => pokud omezis rozhrani do vnitrni site, je to z pohledu toho routeru odchozi provoz. Pokud staci rozdelovat traffic rovnomerne podle IPcek, je to pomerne trivilani. Je ale dobry vytvorit nejakou rezervu (aspon 200kbit) kvuli narazovym aktivitam (browseni po webu ...), protoze vzdy nejakou dobu trva, nez to zareaguje.

Pouzivam http://sourceforge.net/projects/htbinit/ - funguje to velmi slusne (je to vpodstate jen script zlidstujici konfiguraci).

[tomfi]

Něco nastavit pujde podle toho článku co byl zmíněn, ale je třeba si být vědom, že když nastavíte rychlostní limity moc vysoko, tak v době kdy poskytovatel krouhne rychlost, budete ve stejné situaci jako předtím.

Ona rychlost přenosu po síti se ovlivňujete buď zpožděním (cíli to doručím pomaleji než je rychlost linky) nebo zahozením... z toho vyplývá, že když já ten provoz nezbrzdím nebo nezahazuji dřív než poskytovatel budete na tom podobně jako před nastavováním (zahazovat a tudíž zpomalovat bude v tu chvíli poskytovatel, a tomu je jedno který paket zahodí/zpomalí, což na síti sám pozoruješ :) ). Proto se nastavuje "s rezervou", ona to totiž není rezerva, ale spíš prostor pro samotnou manipulaci s QoS.

Jinak je samo problém s určením maximální rychlosti když nemá člověk garantovanou rychlost od poskytovatele. Teoreticky je možné ovlivňovat limity dynamicky podle délky front... když se mi kupí pakety ve frontě na routeru znamená to, že poskytovatel je posílá rychleji a je možné zvýšit limity... naopak když jsou fronty prázdné a paket jakmile je přijat je okamžitě odeslán, znamená to, že můžu zvýšit limit. Ale nevím jestli už to existuje jako hotový řešení, nebo jestli bys musel programovat sám :).

[tomfi]

oprava, při tom když jsou fronty prázdné je dobré snižovat postupně limity podle provozu, minimální garantované rychlosti a tak podobně.

[tomfi]

Je to tak, že když už to přišlo na rozhraní, tak proč to před zpracování nějak ovlivňovat? (už to přeci přišlo, takže není třeba zpomalovat ani zahodit z obavy, že by to neprošlo na druhou stranu).

Proto se klasicky tvaruje a ořezává provoz až na výstupu z rozhraní - aby se předcházelo zahlcení linky. Když už provoz úzkým hrdlem prošel (download směr) tak už má problematickou část sítě za sebou :).

Nicméně když chcete ovlivňovat QoS sám, musí být úzké hrdlo pod vaší kontrolou (například má router obě rozhraní 1Gbps, ale poskytovatel Vám dává menší rychlost)... proto se pro tyto účely vytváří úzké hrdlo tam kde technicky být nemusí podle principu "přijde to na router (ke mě), a já to sám omezím", tím pak máte "pod kontrolou" oba směry (down i up), protože v obou je Váš router úzkým hrdlem.

Takže ano, neovlivňujeme to co příjde na samotný router, ale ovlivníme co router opouští směrem k cíli.

[MMMMMMMMM]

Kdysi dávno před lety jsem řešil podobnou věc (teď už to díky technologii současného ISP neřeším) a vyšlo mi z toho IMQ+ESFQ pro mou linku, která nebyla garantovaná a rychlost kolísala. Vývoj IMQ je stále aktivní, ESFQ asi ne, což neznamená, že nefunguje - na abíčku jsem našel třeba tohle http://www.abclinuxu.cz/poradna/linux/show/74643