Vlákno názorů k článku HTB - jemný úvod od Lubomír Bulej - Pekny clanek, snad bych doplnil jen par nepodstatnych...

  • Článek je starý, nové názory již nelze přidávat.
  • 31. 8. 2003 23:35

    Lubomír Bulej (neregistrovaný)

    Pekny clanek, snad bych doplnil jen par nepodstatnych detailu:

    TCP protokol je celkem slusny moloch, ktery je navrzen v prvni rade pro spolehlivy a az v druhe rade efektivni prenos. Rychlost prenosu je regulovana nekolika parametry jejichz hodnoty jsou odvozovany z rady ukazatelu o kvalite prenosove trasy, vypocitavanych periodicky behem prenosu.

    Dnesni TCP protokoly nezacinaji posilat data nejvyssi moznou rychlosti, ale zhruba stejnou rychlosti, jakou dochazi potvrzeni od druhe strany. Funguje to tak, ze vysilajici strana neposila hned tolik dat, kolik se prijmajici strana vychlouba, ze muze prijmout, naopak, nasadi pomerni nizky limit, ktery ale postupne zvysuje az do velikosti okna udavaneho prijmajicim. Tomuto algoritmu se rika slow start. Limitu na strane vysilajiciho, ktery omezuje okno prijmajiciho se rika congestion window a predstavuje nastroj pro rizeni toku vysilanych dat na strane vysilace. Tento limit vyjadruje odhad zahlceni site vysilajicim. [RFC2001]

    Vysledkem je, ze TCP postupne zrychluje dokud se zda linka kvalitni a pomerne drasticky zpomaluje kdyz dochazi ke ztrate paketu.

    Traffic shaping, jak nazev napovida, je o tvarovani toku, tedy nedochazi k zahazovani paketu jak pise autor, ale k jejich ukladani do front, pricemz k zahazovani paketu dochazi az kdyz neni misto ve fronte. Timto zpusobem je mozne tvarovat libovolne toky, jde jen o to, jestli to pro ne dava smysl. S tim jak se prodluzuje delka fronty roste doba prenosu paketu a tedy fakt, ze TCP zpomali prenos je dan primarne tim, ze potvrzeni, ktera prichazeji od prijmajiciho potvrzuji data v mnozstvi zhruba odpovidajicimu nastavenemu limitu toku.

    Jiny zpusob rizeni provozu se nazyva traffic policing, ktery byva spojen s prubeznym merenim velikosti toku a znackovanim paketu, ktere presahuji limity. Ty jsou pak prenosovou trasou zahazovany bud rovnou, pripadne prednostne :-)

    Efekt pro TCP je trochu jiny, protoze dochazi ke ztrate paketu, coz v TCP protokolu vyvolava reakci na zahlceni site, pri kterem se pomerne drasticky zpomaluje a pomalu (linearne oproti exponencialnimu narustu u slow start) se zvysuje rychlost vysilani.

    Tedy v kontextu "zahazovanim paketu prinutime TCP zbrzdit" je vhodne se zminit o obsluzne strategii RED (Random Early Drop), ktera jako by byla TCP sita na miru. Tato strategie nahodne zahazuje pakety s pravdepodobnosti, ktera roste s tim, jak se velikost toku blizi nastavenemu limitu.

    Nicmene clanek byl samozrejme o HTB, takze nema smysl zbytecne odbihat o tematu :-)

  • 1. 9. 2003 15:44

    PaJaSoft (neregistrovaný)

    K tomu bych jen dodal, ze DROP packetu je az ta nejzassi moznost. Naopak, podivam-li se na statistiku, pak vidim, ze:

    class cbq 10:1 parent 10: leaf 8001: rate 128Kbit (bounded) prio no-transmit
    Sent 5600201704 bytes 5499392 pkts (dropped 0, overlimits 13399024)
    borrowed 0 overactions 1278383 avgidle 179877 undertime 0

    A to je casto hodne skrceny (linka je nekolikanasobek teto tridy) - presto k zahazovani nedochazi, vyrovna se s tim TCP sam pomoci potvrzovaciho mechanismu...

  • 10. 3. 2006 13:42

    vodic (neregistrovaný)
    Priznam se, ze mi hruzou vstaly vlasy na hlave, kdyz jsem cetl, ze brzdeni toku se deje pomoci zahazovani paketu. Jsem rad, ze jste me uklidnil, ze HTB opravdu pakety "pouze" opozduje.
  • 2. 8. 2007 22:28

    anonymní
    overlimit v htb je udajne drop.
    a pak ma kazda trida jeste ve statistikach cisla pro pakety ve frontach... ty se eventualne zacnou dropovat...