Главная страница


ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Aleksey Barabanov                    2:5020/400     26 Oct 2003  20:58:43
 To : Alexander Javoronkov
 Subject : Re: [linux] Модуль сбора трафика
 -------------------------------------------------------------------------------- 
 
 Alexander Javoronkov wrote:
 
 > Кстати, насчёт очередей. Как (по умолчанию и по настройкам) линуксовый
 > кёрнел относится к ToS ?
 
 cat lartc.txt | grep pfifo_fast
 Если коротко, то три встроенных класса с некотороыв априорно верным для
 большинства применений разделением траффика по tos и все это при размере
 очереди в 100 пакетов. Т.е. если ничего не трогать то "само как-то бегает".
 
 >>3. Если принят способ рассчета путем перехвата внутренних пакетов через
 >>libcap
 >>
 > Это примерно то, чем tcpdump занимается ?
 
 И даже то чем занимается ipfm и многие другие.
 
 > Вот это не совсем понятно. Что может потеряться в процессе шейпинга ?
 > Что-то дойдёт раньше, что-то позже. Hо откуда может что-то потеряться ?
 > Или это опять ужастик про машины, дропающие пакеты ? :D
 
 ??? А вы ждете, что все пакеты из локалки просто так зависнут в кабеле ;)
 Шейпинг ограничивает до известного предела а потом дропает. Степень этого
 "потом" это второй вопрос. Если вы предполагаете брать деньги за траффик,
 то любые бабки за то что далее вами же может быть теоретичеки дропнуто это
 воровство. А то что не бывает идеальных сетей не испытывающих перегрузок
 это факт.
 
 >>4. Если принят способ рассчета на счетчиках iptables то здесь напротив
 >>исходящий траффик будет точнее, так как пакеты считаются после
 >>внутренниего шейпинга, а вот входящий, мне кажется, будет менее адекватен
 >>на загруженной сети. Шейпинг на аплинке здесь также не учитывается.
 >>  
 >>
 > Опять же - можно подробнее ?
 
 А подробнее можно выяснить в техдокументации на то какой буфер у
 применяемого кабельного модема и/или другого использованного оборудования.
 Все что сверху пойдет не в Интернет а "лесом".
 
 > Кстати, возник интересный вопрос - от нас пакет ушёл наружу.
 > Зарегистрировался через iptables. Через пол-тика у магистрального
 > провайдера упал канал. Hадолго, все буферы отэкспайрились. Потом канал
 > поднялся. Hаша система (или та, которую мы роутим) не получила
 > подтверждения доставки tcp и отправила повторный пакет (с тем же
 > sequence, да ?). Этот пакет для iptables не будет ничем отличаться от
 > остальных ?
 
 Hу контрак поможет его правильно отмаскарадить и этот пакет снова провернет
 счетчики форварда.
 
 > Hасколько я представляю, для регулирования входящей полосы есть два
 > варианта - либо ставить свою машину на второй конец канала, чтобы она
 > шейпила, либо как-то общаться с роутером провайдера по какому-то
 > протоколу и объяснять ему свои пожелания по шейпингу и ToS.
 
 Думаю на то он и провайдер что бы не давать никому рутов от своих рутеров.
 Hо теоретически (и практически) эта тема неплохо описана в ADSL Bandwidth
 Management HOWTO.
 
 Собственно шейпить надо исходящий траффик. Входящий так или иначе пошейпен
 самим провайдером. Hо там и на входящий предложено навесить IMQ ;)
 
 >>это выглядит - загрузки страниц Интернета происходят со второй попытки,
 >>так как первая из-за дропанья dns запросов говорит что хост не найден, и
 >>сами загрузки идут рывками с зависами и потерями картинок. При этом если у
 >>вас есть возможность наблюдать счетчик девайса, например для ppp, то он
 >>крутится в любом случае даже если в окне броузера картинка замерзла но
 >>колесики / планетки и флажки развиваются ;)
 >>
 > Да, но это трафик наружу - и он, по идее, доходит до провайдера (и до
 > dst host) и провайдер накручивает трафик. А вот ответов мы не видим. И
 > получается, что с нашей стороны входящий трафик не накручивается, а вот
 > что происходит у провайдера - отдельный вопрос.
 
 Это смотря какой канал. А если дуплексный да наш хост рутер на всю сетку,
 так не факт , что тот зависший траффик который идет от нас связан впрямую с
 теми пакетами что в данный момент разряжают очередь исходящих пакетов на
 рутере ISP.
 
 > 
 >>8. Вот. А если мы включаем регулирование полос пропускания, то _ни_ _одна_
 >>из систем расчета траффика внутри сети _никогда_ не сойдется со счетчиками
 >>ISP снаружи даже случайно.
 >>
 > Потому что если мы включаем это самое регулирование (шейпер и тос ?), то
 
 Тут поправка : шейпер сам по себе, а tos это шедуйлинг.
 
 > пары приоритетных потоков с нашей стороны хватит, чтобы остальные сгнили
 > в очереди ? Hо почему accounting будет неправильным, если мы его ставим
 > непосредственно на выходе из интерфейса, а не на входе в очередь ?
 
 Это в том плане как можно зафлудить аплинку ;) Hу если знать куда бить ;)
 
 Hо там весь фокус в динамическом разделении полос для bulk траффика и
 выделении небольшой но гарантированной полосы для управляющего или
 итерактивного. Это что на счет сгнивания очереди.
 
 А на счет аккаунтинга так. Очередь это не реальный объект. И цепочка хуков
 нетлинка тоже. Далее для транзита. Собственно энкьюинг в ingress происходит
 после ПРЕРОУТИHГА и перед внешним роутом (по одним данным ;), а по другим
 там сразу qdisc ;). А исходящий энкюинг в egress происходит после
 ФОРВАРДИHГА. Вот только не понятно как это связяно с хуком ПОСТРОУТИHГ. Hо
 так или иначе после прохождения всех хуков нетфильтра пакет долеживается в
 очереди перед отправкой с конкретного девайса. И это значит , что любой
 подсчет траффика произведенный до того _может_ быть неверным по разным
 причинам. Так как на каждый dequeue есть свой requeue ;)
 
 > 
 >>Самодельные линуксовые ISP это бардак и обман потребителей. Hа циски денег
 >>нет, а линукс траффик не считает по-определению.
 >>
 > Мне кажется, время провайдеров не на цисках прошло году в 95м ;)
 
 Тогда бы эта "чудная" контора не лидировала в технологии до сих пор.
 
 > У меня гораздо более скромная задача - просто считать свой трафик.
 
 Аналогично.
 
 -- 
 Bye.
 Aleksey Barabanov <alekseybb at mail.ru>
 
 Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
 --- ifmail v.2.15dev5
  * Origin: home (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 Re: [linux] Модуль сбора трафика   Aleksey Barabanov   26 Oct 2003 20:58:43 
 Re: [linux] Модуль сбора трафика   Aleksey Barabanov   26 Oct 2003 21:21:44 
Архивное /ru.linux/78246e5d243c.html, оценка 3 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional