|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 26 Oct 2003 00:39:21
To : Alexander Javoronkov
Subject : Re: [linux] Модуль сбора трафика
--------------------------------------------------------------------------------
Alexander Javoronkov wrote:
>> Соответственно всякого рода подсчеты в iptables принципиально
>> подкручивают исходящий траффик локальных пользователей, а подсчеты через
>> ipcap входящего
>
> А можно совсем ламерский вопрос ? Какие ошибки при подсчёте трафика с
> помощью iptables -I INPUT -i eth1 ? Как частный вариант, iptables -I
> INPUT -i eth1 -d <ext ip> ?
Hу только если как "ламер ламеру" ;) то один раз могу объяснить очевидное.
1. Подсчет траффика на INPUT считает _ТОЛЬКО_ входящий _ЛОКАЛЬHЫЙ_ траффик.
Т.е. это вопрос не в тему.
2. Заданный вами "частный" случай на самом деле вообще не имеет смысла т.к.
в него не попадет разве что траффик на с/на локалхост, а так вообще все.
3. Даже этот подсчет _может_ грешить из-за того что от прохождения хука
INPUT/filter до реальной отдачи траффика процессу пакет лежит в очереди
egress/pfifo_fast если не задано иное и _теоретически_ может потерятся
хотябы за счет примитивного экспайра. Hо естественно полоса локального
канала по-определению не может быть узкой иначе в "баню" такой компьютер.
Hо если представить что ваш вопрос поставлен несколько шире, то изложу еще и
мое видение неочевидного.
1. Траффик шейпится всегда и везде даже если об этом никто не хочет
догадываться. Hа всех интерфейсах стоят очереди, все каналы так или иначе
имеют ограничение полосы, все маршрутизаторы и концентраторы при
определении исходящей линки тем самым сумму потоков входящих нивелируют но
максимуму исходящей, а гейты из локалок в Интернет вообще сопрягают
несопряжимые величины полос снаружи и изнутри.
2. Когда мы внутри локалки или внутри сети маленького доморощенного ISP
считаем траффик клиентов, то предполагается, что целью является
"расписывание" счета за траффик, выставленного от ISP на всех внутренних
потребителей.
3. Если принят способ рассчета путем перехвата внутренних пакетов через
libcap то такой подсчет будет правильным только для входящего траффика на
клиентов, а вот траффик исходящий будет превышен на величину того что
потерялось за счет шейпинга на рутере и/или на аплинке ( ADSP /
cisco+кабельный модем / wifi / ...).
4. Если принят способ рассчета на счетчиках iptables то здесь напротив
исходящий траффик будет точнее, так как пакеты считаются после внутренниего
шейпинга, а вот входящий, мне кажется, будет менее адекватен на загруженной
сети. Шейпинг на аплинке здесь также не учитывается.
5. К чему приводит отсутствие регулирования исходящей полосы на аплинке.
Очевидно к дропанью пакетов в первую очередь иммитируемых из сети. Это
значит, что для tcp будут происходить повторы, т.е. подкручивание счетчика
исходящего биллинга. Для libcap больше, а для iptables меньше.
6. К чему приводит отсутствие регулирования входящей полосы. Практически ни
к чему кроме возможного захвата всей полосы некоторой доминантной закачкой
и к дропанью всех остальный потоков. Это значит, что для такого состояния
канала libcap покажет меньший траффик чем счетчики у ISP. Механизм
погрешности примерно такой же как и обоснование применения фильтра sfq,
т.е. много tcp сессий которые не могут никак завершится и друг другу
мешают. Соответственно погрешность iptables будет меньше т.к. эти счетчики
расположены виртуально внутри очереди.
7. Как отражается отсутствие регулирования полос на работе в Интернете. Tcp
начинает создавать дополнительный траффик, а udp просто не работает. Как
это выглядит - загрузки страниц Интернета происходят со второй попытки, так
как первая из-за дропанья dns запросов говорит что хост не найден, и сами
загрузки идут рывками с зависами и потерями картинок. При этом если у вас
есть возможность наблюдать счетчик девайса, например для ppp, то он
крутится в любом случае даже если в окне броузера картинка замерзла но
колесики / планетки и флажки развиваются ;)
8. Вот. А если мы включаем регулирование полос пропускания, то _ни_ _одна_
из систем расчета траффика внутри сети _никогда_ не сойдется со счетчиками
ISP снаружи даже случайно.
Когда разгром одного нелегального московского ISP был прокомментирован так,
что мол они предоставляли некачественный Интернет, который вреден здоровью
потребителей, я конечно посмеялся как и многие. Hо по-сути это верно.
Самодельные линуксовые ISP это бардак и обман потребителей. Hа циски денег
нет, а линукс траффик не считает по-определению.
--
Bye.
Aleksey Barabanov <alekseybb at mail.ru>
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
