Это интересно.
Как рассчитать объем потребляемого сервером трафика.
Начнем с терминов и определений. Трафик - это, собственно говоря, и есть объем - объем передаваемой по сети информации. Однако на компьютерном жаргоне принято понимать под трафиком сам поток этой информации, а то и количество посетителей сайта за определенный промежуток времени. Поэтому, чтобы не путаться в терминологии, будем обозначать объем проходящей по каналу связи информации словосочетанием "объем трафика".
Трафик бывает входящий и исходящий. Входящий трафик - это та информация, которую вы получаете из сети на ваш сервер. Исходящий - это переданная вами информация.
При работе с понятием "трафик" и "объем трафика" нас совершенно не интересует, какая именно информация была принята или передана. Существует точка учета трафика - в нашем конкретном случае это точка соединения сервера с сетью. И наша задача - поставить в этой точке своеобразный "счетчик", который "накручивал" бы значение объема информации, проходящей через него в обе стороны за определенное время - скажем, за сутки или за месяц.
Объем трафика за месяц - это та самая величина, которую необходимо учитывать при выборе тарифа подключения. Понятно, что в этом важном вопросе не хочется ошибиться ни в ту, ни в другую сторону. Если оплачиваемый вами по тарифу объем окажется меньше реального, за трафик сверх тарифа придется платить гораздо дороже, чем за тот же объем информации в пределах тарифа. Наоборот - тоже плохо, вы будете платить откровенно лишние деньги. Существует "золотая середина", которая должна учитывать реальные объемы трафика, с которыми вы работаете в среднем за месяц.
В чем же сложность вопроса, вынесенного в заголовок статьи? Дело в том, что любая информация "путешествует" по сети Интернет в виде отдельных пакетов - блоков данных относительно небольшого объема. Каждый из блоков снабжен адресом отправителя и получателя и совершает свое путешествие самостоятельно. Так что для учета объема трафика необходимо суммировать объем каждого пакета. Существуют различные методы контроля пакетов, зависящие от архитектуры сервера и особенностей серверного ПО.
Попытки просчитать объем потребляемого трафика "вручную" не могут привести к высокой точности результата. Существуют различные программы для подсчета трафика, однако все они в той или иной степени грешат против истины. Проблема - в не учитываемом обычными путями "скрытом" трафике, который присутствует при любом сеансе связи. Отсюда - частые нарекания в адрес провайдеров по поводу якобы завышения ими объемов потребленного трафика.
Что же не попадает в видимую часть трафика? Служебные пакеты: ICMP-пакеты, TCP-пакеты вхождения в связь, UDP-запросы к DNS, FTP-трафик. Пакеты, принятые, но не пропущенные сервером: отфильтрованные FireWall-ом, искаженные при передаче по каналу связи и т. п. Наконец, активность автоматических программ: ботов, обновлений, в конце концов, проникших на сервер вирусов, рассылающих спам.
Теперь разберемся, как надо и как не надо считать объем трафика. Основные методы получения данных о потреблении трафика следующие.
Перехват пакетов
Для решений, которые сами маршрутизируют трафик, наиболее удобным способом его учета является перехват пакетов, проходящих сквозь сервер. При этом система записывает в базу данных сведения об адресате и отправителе пакета, его размер, а также возможную дополнительную информацию. Удобство учета трафика в случае пользования Colocation очевидно - один сервер равен одному потребителю трафика. Для виртуального же хостинга производится суммирование указанных записей за определенный период и соотнесение получателя / отправителя с каждым реальным пользователем системы, что и дает информацию о потреблении трафика этим пользователем.
Анализ журналов
Для тех корпоративных решений, которые стремятся выдать больше данных по трафику, необходим анализ файлов журналов внешних или собственных серверов. Например, анализ журнала почтового сервера позволяет определить, кому из пользователей зачесть трафик в объеме размера почтового сообщения. Обработка лог-файлов прокси сервера поможет не только показать объем полученного пользователем трафика, но и точно указать объект, закачка которого привела к этому потреблению.
Некоторые решения, вообще говоря, являются всего лишь анализаторами лог-файлов прокси серверов и, хоть это позволяет выдать довольно большой объем информации, но в ряде случаев его может быть явно недостаточно. Оптимальным вариантом является скоординированный сбор данных из всех возможных источников: перехват пакетов, анализ журналов, если это приводит к более полному отражению ситуации с потреблением трафика.
Сетевой протокол Cisco NetFlow
Как правило, провайдеры используют в качестве коммутационного оборудования продукцию фирмы Cisco Systems. Данное оборудование сертифицировано Министерством связи РФ. Для учета трафика, потребленного, например, абонентами выделенных линий, в маршрутизаторах Cisco используется фирменная технология Cisco NetFlow. Данная технология использует для доставки учетных данных транспортный протокол UDP без подтверждений. На обычном языке это означает, что она никак не склонна завышать потребляемый трафик - наоборот, в ряде случаев результат ее подсчетов оказывается несколько заниженным.
NetFlow был опубликован в виде стандарта IETF: Internet Protocol Flow Information eXport (IPFIX). IPFIX основан на реализации Netflow v9 (RFC 3954). Многие другие поставщики сетевого оборудования уже добавляют поддержку IPFIX в свои устройства.
Сетевой поток (network flow) определялся различными способами. Традиционное определение Cisco должно использовать 7-кортежный ключ, где поток - однонаправленная последовательность пакетов с использованием всех 7 значений:
- IP-адрес источника;
- IP-адрес получателя;
- Порт источника для UDP или TCP, 0 для остальных протоколов;
- Порт получателя для TCP или UDP, тип и код для ICMP, или 0 для других протоколов;
- Протокол IP;
- Входной интерфейс;
- Тип сервиса IP.
Гибкий Netflow (FNF, Flexible Netflow) и IPFIX поддерживают определяемые пользователем ключи потока.
Когда роутер определит, что поток завершен, он выводит записи потока. Когда роутер видит новый трафик для существующего потока, он сбрасывает счетчик. Кроме того, завершение сеанса TCP в TCP потоке заставляет маршрутизатор закончить поток. Маршрутизаторы также могут быть сконфигурированы для вывода записей потока в фиксированном интервале, даже если этот все еще продолжается. В Гибком NetFlow (FNF) администратор может определить свойства потока netflow на другом роутере.
Расположенные на компьютере или сервере программы учета трафика, каких рекламируют сейчас немало, могут просто считать полезные данные без учета размеров заголовков IP-пакетов и т. п., и цифры уже будут получаться другими. Возможно, часть трафика просто будет проходить мимо таких программ.
Разумеется, можно попытаться "на глаз" оценить объем трафика, потребляемого вашим сервером (сайтом). Такой грубый расчет не будет учитывать служебных пакетов и действий автоматических программ, но кое-что с его помощью понять можно. Итак,
Считаем объем трафика вручную
Определим средний размер страницы вашего сайта. Для этого можно воспользоваться, например, Web Page Analyzer. Пусть средний размер страницы - 120 кБ (эта цифра достаточно реальна для страниц, не перегруженных картинками большого формата).
Если на вашем сайте стоит счетчик посетителей, то и среднее число посетителей в день вы можете определить. Если нет - можно проанализировать статистику по логам веб-сервера. Если посещаемость будет, скажем, 1000 уникальных посетителей в день и на каждого из них придется по 1,8 просмотров страниц (это также вполне реальная цифра статистики), то трафик за месяц составит:
30 * 1,8 * 1000 * 120 = 6500 МБ.
Если размеры страниц сильно отличаются, цифра может оказаться совершенно другой. Например, вы сделали обзор софта со скриншотами. Такая страница может легко "затягивать" и на 300 кБ. И если на эту страницу придется значительная часть посетителей (что очень вероятно, если обзор хороший), то трафик будет существенно отличаться от рассчитанных значений.
Прибавим около 10% от рассчитанного значения на служебный трафик. Что мы получаем? Достаточно раскрученный сайт, который посещают в сутки 1000 уникальных посетителей, будет потреблять объем (исходящего!) трафика в пределах 7 - 8 ГБ в месяц. Напомним, что речь идет об обычном сайте, с текстом и одной-двумя картинками на странице, а не о фотогалерее или сборнике видеоклипов.
Входящий трафик обычно намного меньше и зависит от объемов закачиваемой вами на сайт информации. Его также можно приблизительно прикинуть. Суммарный трафик для рассмотренного случая очень примерно будет составлять 9 - 12 ГБ в месяц.
Основа проверенного знания - практика
А вообще, для правильного выбора тарифного плана необходимо оценить потребляемый трафик на практике. Тем более, что датацентр ColoCAT предоставляет прекрасную возможность попробовать свои силы в течение тестового периода и первый месяц не платить за услуги связи и не делать окончательный выбор. Через месяц пользования услугами вы оцените объем вашего трафика и поймете, к какому тарифному плану подключаться.
В заключении хотелось бы сказать несколько слов о безлимитном тарифном плане. Современный потребитель, на собственном опыте убедившийся в верности выражения о местонахождении бесплатного сыра, видит в подобных предложениях очередную мышеловку. И отчасти он прав. Многие мелкие провайдеры предлагают "безлимит" в наиболее дешевых из своих планов, таким образом приманивая клиентов. Но очевидный расчет показывает, что такое предложение честным быть не может. Чтобы не разориться и держать "потолок" разрекламированного безлимита, такие провайдеры вынуждены ограничивать объем трафика каждого клиента. Для этих провайдеров критичной является и величина объема их общего трафика, ведь они, в свою очередь, покупают его у крупных поставщиков услуг.
Датацентры находятся обычно в диаметрально полярном положении. Их каналы связи высочайшей мощности не нуждаются в подсчете каждого пропущенного по ним килобайта. Поэтому для датацентров безлимитный тарифный план является честным предложением для клиента попросту не считать каждую свою копейку. Тем более, что он и не является самым дешевым предложением и рассчитан исходя из реального достаточно активного пользования сетью.
Ограничения здесь не накладываются, но не стоит путать понятия. "Безлимит" для нашего человека является синонимом выражения "много и на халяву". На самом деле это далеко не так. Понятие "безлимит" вовсе не означает, что клиент может беспрепятственно перекачивать терабайты данных в месяц. При таком подходе он будет представлять реальную угрозу для провайдера. С другой стороны, скачать огромный объем или набрать миллионную аудиторию посетителей еще нужно умудриться.
Поэтому определим понятие "безлимитный тарифный план" как такой план, который базируется на учете среднестатистических данных для крупных клиентов. Этот план основан на взаимном доверии клиента и провайдера друг к другу и избавляет обоих от необходимости погрязать в рутине взаимных расчетов. Безлимитный план удобен и выгоден каждой из сторон.
Итак, мы попытались раскрыть здесь некоторые тонкости учета трафика и рассказать о возможностях выбора тарифного плана. А выбор вам, как водится, делать самим.
