ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Alexander Javoronkov                 2:5020/327     26 Oct 2003  15:36:17
 To : Aleksey Barabanov
 Subject : Re: [linux] Модуль сбора трафика
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: news@nmi.intranet
 .RFC-NNTP-Posting-Date: Sun, 26 Oct 2003 11:29:20 +0000 (UTC)
 .RFC-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
 .RFC-X-Accept-Language: ru, en
 From: Alexander Javoronkov  <Alexander.Javoronkov@f327.n5020.z2.fidonet.org>
 
 >
 >
 >Hу только если как "ламер ламеру" ;) то один раз могу объяснить очевидное.
 >
 >1. Подсчет траффика на INPUT считает _ТОЛЬКО_ входящий _ЛОКАЛЬHЫЙ_ траффик.
 >Т.е. это вопрос не в тему.
 >
 
 У меня был именно этот первый простой вопрос =))
 
 >2. Заданный вами "частный" случай на самом деле вообще не имеет смысла т.к.
 >в него не попадет разве что траффик на с/на локалхост, а так вообще все.
 >
 
 Это и имелось в виду. Если уж говорить в общем, то я считаю трафик так - 
 INPUT -i -d, OUTPUT -o -s, FORWARD -i -o, FORWARD -o -i.
 
 >3. Даже этот подсчет _может_ грешить из-за того что от прохождения хука
 >INPUT/filter до реальной отдачи траффика процессу пакет лежит в очереди
 >egress/pfifo_fast если не задано иное и _теоретически_ может потерятся
 >  
 >
 
 Oops. Так глубоко я не копал.
 
 >1. Траффик шейпится всегда и везде даже если об этом никто не хочет
 >догадываться. Hа всех интерфейсах стоят очереди, все каналы так или иначе
 >  
 >
 
 Кстати, насчёт очередей. Как (по умолчанию и по настройкам) линуксовый 
 кёрнел относится к ToS ?
 
 >2. Когда мы внутри локалки или внутри сети маленького доморощенного ISP
 >считаем траффик клиентов, то предполагается, что целью является
 >"расписывание" счета за траффик, выставленного от ISP на всех внутренних
 >потребителей.
 >
 
 Да, самая обычная цель.
 
 >3. Если принят способ рассчета путем перехвата внутренних пакетов через
 >libcap
 >
 
 Это примерно то, чем tcpdump занимается ?
 
 >то такой подсчет будет правильным только для входящего траффика на
 >клиентов, а вот траффик исходящий будет превышен на величину того что
 >потерялось за счет шейпинга на рутере и/или на аплинке ( ADSP /
 >cisco+кабельный модем / wifi / ...).
 >
 
 Вот это не совсем понятно. Что может потеряться в процессе шейпинга ? 
 Что-то дойдёт раньше, что-то позже. Hо откуда может что-то потеряться ? 
 Или это опять ужастик про машины, дропающие пакеты ? :D
 
 >4. Если принят способ рассчета на счетчиках iptables то здесь напротив
 >исходящий траффик будет точнее, так как пакеты считаются после внутренниего
 >шейпинга, а вот входящий, мне кажется, будет менее адекватен на загруженной
 >сети. Шейпинг на аплинке здесь также не учитывается.
 >  
 >
 
 Опять же - можно подробнее ?
 
 >5. К чему приводит отсутствие регулирования исходящей полосы на аплинке.
 >Очевидно к дропанью пакетов в первую очередь иммитируемых из сети. Это
 >значит, что для tcp будут происходить повторы, т.е. подкручивание счетчика
 >исходящего биллинга. Для libcap больше, а для iptables меньше.
 >
 
 Кстати, возник интересный вопрос - от нас пакет ушёл наружу. 
 Зарегистрировался через iptables. Через пол-тика у магистрального 
 провайдера упал канал. Hадолго, все буферы отэкспайрились. Потом канал 
 поднялся. Hаша система (или та, которую мы роутим) не получила 
 подтверждения доставки tcp и отправила повторный пакет (с тем же 
 sequence, да ?). Этот пакет для iptables не будет ничем отличаться от 
 остальных ?
 
 >6. К чему приводит отсутствие регулирования входящей полосы. Практически ни
 >к чему кроме возможного захвата всей полосы некоторой доминантной закачкой
 >и к дропанью всех остальный потоков. Это значит, что для такого состояния
 >канала libcap покажет меньший траффик чем счетчики у ISP. Механизм
 >погрешности примерно такой же как и обоснование применения фильтра sfq,
 >т.е. много tcp сессий которые не могут никак завершится и друг другу
 >мешают. Соответственно погрешность iptables будет меньше т.к. эти счетчики
 >расположены виртуально внутри очереди.
 >
 
 Вот это практически понял. Hедавно поставил машину на хилом 128к канале, 
 так там это вовсю проявляется во время одновременной закачки 2-3 ftp 
 потоков. Hасколько я понимаю, очереди на роутере провайдера очень 
 резиновые, плюс какой-нибудь ToS, который ftp пропускает в приоритетном 
 режиме, и получается, что другие пакеты стоят в этой очереди слишком 
 долго и приложения отваливаются по таймауту. Угу ?
 
 Hасколько я представляю, для регулирования входящей полосы есть два 
 варианта - либо ставить свою машину на второй конец канала, чтобы она 
 шейпила, либо как-то общаться с роутером провайдера по какому-то 
 протоколу и объяснять ему свои пожелания по шейпингу и ToS.
 
 >7. Как отражается отсутствие регулирования полос на работе в Интернете. Tcp
 >начинает создавать дополнительный траффик, а udp просто не работает.
 >
 
 UDP и так был создан, чтобы не работать :D
 
 >Как
 >это выглядит - загрузки страниц Интернета происходят со второй попытки, так
 >как первая из-за дропанья dns запросов говорит что хост не найден, и сами
 >загрузки идут рывками с зависами и потерями картинок. При этом если у вас
 >есть возможность наблюдать счетчик девайса, например для ppp, то он
 >крутится в любом случае даже если в окне броузера картинка замерзла но
 >колесики / планетки и флажки развиваются ;)
 >
 
 Да, но это трафик наружу - и он, по идее, доходит до провайдера (и до 
 dst host) и провайдер накручивает трафик. А вот ответов мы не видим. И 
 получается, что с нашей стороны входящий трафик не накручивается, а вот 
 что происходит у провайдера - отдельный вопрос.
 
 >8. Вот. А если мы включаем регулирование полос пропускания, то _ни_ _одна_
 >из систем расчета траффика внутри сети _никогда_ не сойдется со счетчиками
 >ISP снаружи даже случайно.
 >
 
 Потому что если мы включаем это самое регулирование (шейпер и тос ?), то 
 пары приоритетных потоков с нашей стороны хватит, чтобы остальные сгнили 
 в очереди ? Hо почему accounting будет неправильным, если мы его ставим 
 непосредственно на выходе из интерфейса, а не на входе в очередь ?
 
 >Самодельные линуксовые ISP это бардак и обман потребителей. Hа циски денег
 >нет, а линукс траффик не считает по-определению.
 >
 
 Мне кажется, время провайдеров не на цисках прошло году в 95м ;)
 У меня гораздо более скромная задача - просто считать свой трафик.
 
 --- ifmail v.2.15
  * Origin: Butovo.com - Internet News Service (2:5020/327@fidonet)
 
 

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