|
|
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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/78246e5d243c.html, оценка из 5, голосов 10
|