 |
|
|
|
Создание простейшей биллинговой системы
Создание простейшей биллинговой системы Наверное, хотя бы один раз в жизни каждому из нас приходилось покупать Интернет по Dial-Up. А раз так, то каждый из нас сталкивался с биллинговой системой: подсчетом количества времени, трафика (мегабайт) и денег. В сумме весь данный комплекс программ и называется биллинговой системой. Но биллинговые системы используются не только у интернет-сервис-провайдеров (Internet Service Provider). Если на вашей АТС поминутная оплата переговоров по коммутируемой линии, то на этой АТС также обязательно должна работать биллинговая система. Если вы пользуетесь мобильным телефоном, то у компании-провайдера телефонных услуг также существует огромный комплекс биллинговых программ. В нашем контексте (для ИСП) «биллинговая система» имеет смысл как комплекс программ для учета количества секунд и байт, затраченных пользователем в Интернете. Вы можете спросить, почему же именно секунд и байт? Очень просто – это базовые единицы измерения. Ведь именно из секунд мы можем получить остальные значения: минуты, часы, сутки и так далее; из байт – килобайты, мегабайты и т. д. «А деньги?» – возразите вы. Да, все правильно, но исходя из секунд и байт, вы сможете, установив тариф, получить деньги. Биллинговые системы бывают разные, их можно примерно разделить по нескольким признакам:
Вы вправе не согласиться с такой классификацией и выделить еще несколько признаков. Например, такой: вид вывода информации. Но автор намеренно решил не относить данный признак к так называемым «основным», так как нет единого стандарта на вывод информации. Новичкам нагляднее будет рабочая программа под управлением MS Windows, для опытных системных администраторов предпочтительнее будет увидеть консольную программу под управлением UNIX – но в итоге можно спорить сколько угодно и не прийти к единому мнению. Единственной альтернативой будет использование платформы Web и, как следствие, использование программы apache web server, а в самой программе – генерация html-страниц для показа через Сеть. Анализ биллинговых систем на рынке софта Если вы решили приобрести уже готовый биллинг, для начала определитесь: что именно вам нужно. Для некоторых провайдеров может быть выгоднее купить уже готовый комплекс биллинговых программ, нежели писать их самим, для этого сделаем небольшой анализ рынка биллинговых систем. На нашем рынке программного обеспечения вы можете найти практически любые биллинги, их разрабатывают многие компании, но очень мало кто может позволить себе купить данные программные продукты в силу их огромной стоимости. Например, биллинговые системы для телефонных компаний стоят начиная от $500000. А это уже совершенно другой уровень, нежели компании интернет-провайдера, тут биллинг можно приобрести и за $200. Но все упирается в то, что именно будет делать данный биллинг! В среднем цена достаточно хорошего биллинга колеблется от $500 до $5000 для компаний ИСП. И как вы понимаете, за разные суммы создаются и разные биллинги. Биллинги также могут либо работать с определенным оборудованием, либо нет. Например, если вы приобрели себе оборудование модемного пула Cisco – это уже дополнительное оборудование к обычному компьютеру, и, как следствие, возрастает цена минимального биллинга с $200 до $500. Так же имеются нюансы юридического плана. Если вы покупаете биллинговую систему у компании с гарантией или ответственностью компании перед вами, то в зависимости от договора цена может возрасти от двух до десятков раз. Если же вы заказываете создание биллинга у программиста или группы программистов (для ускорения написание системы), то зачастую вы получаете готовую систему, но если что-то пойдет не так, вы будете отвечать перед вашими клиентами сами. Есть еще нюанс. Компании всегда предоставляют уже готовую систему, с одной стороны, это очень удобно, к вам приедут знающие специалисты и создадут всю систему «под ключ» буквально за несколько дней, но есть и обратная сторона медали: биллинговая система будет у вас не уникальная, а это в свою очередь значит, что вас смогут «взломать». Так как опытные хакеры могут найти одну «дыру» в системе и, соответственно, могут взломать и все подобные системы. В данном случае даже самая простая, но уникальная система будет в огромном выигрыше, т.к. ни у кого больше такой нет. Итак, несколько замечаний по поводу выбора программ биллинга в зависимости от того, что именно вам надо подсчитывать и каким именно оборудованием вы можете располагать. Но нельзя считать взгляд автора единственным и непогрешимым, тем более в области информационных технологий можно одно и то же сделать многими способами. Если вам надо подсчитывать время пребывания пользователя на модемном пуле по коммутируемой линии, то вам легче всего будет заказать биллинг у программиста. Это дешево (около $200); система будет формировать свои выводы в виде html-страниц как единственного универсального средства отображения информации. Причем за $200 вы получите готовый уникальный биллинг. Если же вы хотите организовать биллинг на принципе анализа log-файлов, то данный комплекс программ будет еще дешевле – около $100-150. Данные биллинги будут работать практически на любом оборудовании, все зависит от того, что именно вы поставите как модемный пул. Для маленькой компании интернет-сервис-провайдера автор советует приобрести расширитель COM-портов, так как на один компьютер архитектуры PC можно поставить не более 2 портов. Компьютер класса более чем 486DX/16 Мб RAM/1.2 Гб HDD – это для биллинг-сервера, но при этом вам придется поставить отдельно веб-сервер на другом компьютере, либо увеличить производительность данного компьютера. Создание биллинг-комплекса с использованием дополнительного оборудования, например, модемного пула Cisco, сразу увеличит ваши затраты, но, с другой стороны, если у вас есть деньги на такую дорогую аппаратуру, то вам уже не страшно будет услышать цены на данные комплексы. По данным сети IRC только модуль снятия статистики с аппаратуры Cisco будет стоить от $200 до $1000, не учитывая саму биллинг-статистику. Данный вид биллинга автор советует заказывать уже не программисту-одиночке, а команде программистов. Это будет более дешевый выход. В зависимости от принципа снятия статистики очень варьируется стоимость разработки системы.
В любом случае настройка программ-серверов и компьютеров-серверов – это отдельная сумма. Т.е. автор приводит цены, исходя из данных Интернета (irc.tsua.net, канал #billing). Цены в разных регионах могут отличаться и очень сильно за счет «выезда к клиенту» и т. д., в статье цены приводятся «чистые», т.е. телеработа, без выезда к клиенту, клиент сам устанавливает комплекс на своем оборудовании. В любом случае вы можете зайти в сеть IRC на канал, посвященный биллинговым системам и получить помощь или консультацию. Данная статья не претендует на полное описание всех возможных биллингов, все их описать в одной статье невозможно. Темой данной статьи является создание простейшего биллинга для маленького новоиспеченного интернет-сервис-провайдера. Создание простейшей биллинговой системы Стадия 1: анализ Для примера рассмотрим создание простейшей биллинговой системы, построенной по принципу скриптов-счетчиков для снятия трафика и подсчета времени, затраченного пользователем в Интернете. Данная статистика больше будет приемлема для провайдера, использующего модемный пул. Мы будем создавать биллинговую систему, ориентируясь на операционную систему Linux, так как она открыта, ее можно свободно купить или загрузить из Интернета. Исходя из выбранного дистрибутива Linux, мы выберем компьютер и приступим к написанию. Дистрибутивов Linux существует огромное количество. Есть дистрибутивы, которые больше ориентированы на серверы; есть те, которые больше ориентированы на графику; есть такие, которые пытаются потягаться с MS Windows на поприще рабочих станций, и это у них очень хорошо получается. В нашем же случае необходимо выбрать сервер. Хотя из любого дистрибутива Linux можно сделать самому руками и сервер, и рабочую станцию, и мультимедийную станцию, но все-таки лучше выбирать изначально сервер-ориентированный дистрибутив. Таким, на взгляд автора, является дистрибутив RedHat – самый распространенный дистрибутив по части серверных операционных систем. Многим он может не понравиться, или не нравится уже сейчас, – вы вправе выбрать любой другой дистрибутив и, автор думает, у вас все получится без изменения исходных кодов, приведенных в данной статье. Многие могут высказаться за операционную систему FreeBSD, но у нее есть небольшой недостаток – новичку в ней очень тяжело разобраться. А данная статья рассчитана на новичков в этом деле. Итак, мы выбрали ветвь RedHat-дистрибутивов. Теперь надо определиться с версией. Автор предлагает брать последнюю (на момент написания статьи) – 7.3 – стабильная последняя версия. Для данного дистрибутива нужен достаточно мощный компьютер, а так как мы рассчитываем на довольно слабый компьютер, то лучше взять клон дистрибутива RedHat украинской команды BlackCat Linux Team. Они ввели дополнительный компонент, повышающий безопасность дистрибутива. Он разрабатывался, когда еще не было таких мощных машин, и будет себя прекрасно чувствовать на слабом компьютере. Плату расширения COM-портов можете выбрать самостоятельно: тут не возникнет проблем. Для всех них существуют драйверы под RedHat 6.2. Наш выбор: BlackCat Linux 6.2 на P-MMX-166/32 RAM/2 Гб HDD. Стадия 2: реализация Для реализации задуманного нам потребуются знания операционной системы Linux, немного программирования на языке Perl и Bash. Bash на самом деле не язык программирования, а язык написания скриптов, как и Perl. Если кто-то захочет, то сможет это все реализовать на любом другом языке программирования. Итак, для того чтобы начинать писать, нам надо знать как это все работает в операционной системе. Схема довольно-таки простая.
Начнем по порядку. Пользователь звонит на сервер. Модем поднимает трубку и происходит установка связи двух модемов. Когда связь установлена, процесс входа пользователем в Сеть переходит во вторую фазу – фазу авторизации. Затем, после авторизации, наступает фаза поднятия TCP/IP-протокола. Вот так происходит вход пользователя в Сеть в Linux. Выход происходит в обратном порядке. Сначала опускается TCP/IP-протокол, затем выход-авторизация, затем разрыв связи. Иногда бывает, что происходит разрыв связи не по воле пользователя. Тогда немного меняется схема: сначала происходит разрыв связи, затем уже снятие TCP/IP-протокола, и последнее – выход-авторизация. Мы внесем некоторые изменения в данную схему, а именно: добавим дополнительный блок. После установки соединения и полной авторизации будет выполняться наша маленькая программа, которая будет сохранять имя пользователя, время его входа и любые другие данные, которые могут потребоваться в вашей системе. Так же добавим дополнительное звено и в выходную цепочку, поставив дополнительное звено после выход-авторизации.
На практике это произойдет путем редактирования двух файлов auth-up и auth-down, находящихся в директории [/etc/ppp]. Добавим в конец обоих файлов по строке: /etc/ppp/billing-up {PEERNAME} /etc/ppp/billing-down {PEERNAME} соответственно. Данные строчки после авторизации или выход-авторизации запустят наши программы биллинговой системы. Через пробел в наши скрипты мы добавляем любые переменные, которые захотим передать в программу. Переменная {PEERNAME} имеет значение имени пользователя или, точнее сказать, его логина. О том, как сделать полную авторизацию с паролем через собственную систему биллинга, будет отдельная статья. Так как нам необходимо было передать в биллинговую систему не только имя пользователя, но и время его входа – мы воспользуемся языком программирования Perl и вызовем функцию системного времени. auth-up 1.#!/usr/bin/perl 2.# Программа auth-up 3.# Сохранение логина пользователя и времени его входа 4.$username = $ARGV[1]; 5.open(FL, ‘> /etc/ppp online.usr’); 6.print(FL, “$username “, localtime, “ ”); Строка 01 – обязательная, она сообщает, что это Perl-программа. Строка 04 – мы переприсваиваем имя пользователя из массива в переменную, этого можно и не делать, – это сделано для наглядности. Строка 05 – открываем файл для записи, в данном файле будет храниться строка: что за пользователь зашел и во сколько (в формате UTC). Строка 06 – собственно, запись имени пользователя и времени его входа в систему. auth-down 1.#!/usr/bin/perl 2.# Программа auth-down 3.# Окончательный анализ пребывания пользователя в Интернете. 4.$username = $ARGV[1]; 5.open(FL, ‘< /etc/ppp/online.usr’); 6.read(FL, $temp); 7.close(FL); 8.chomp($temp); 9.@user = split(/ /,$temp); 10.$logintime = $user[2]; 11.$logouttime = localtime; 12.$timeonline = $logouttime — $logintime; 13.open(FL, ‘>> /var/log/inet.usr’); 14.print(FL, “User: $username, LogIn: $logintime, LogOut: $logouttime, OnLineTime: $timeonline”); Первые строки программы такие же, как и в предыдущей программе. Строка 04 – переприсваивание имени пользователя. Строки 05-07 – открытие файла, чтение из него строки, закрытие файла, или, точнее, освобождение дескриптора файла. Строка 08 – это обрезание лишних пробелов и символа перевода каретки. Строка 09 – разбиение строки на массив переменных. Переприсваиваем в строке 10 время входа пользователя для наглядности. Узнаем время выхода пользователя в строке 11. В строке 12 узнаем, сколько времени пробыл пользователь на линии, данное число представляет собой количество секунд. В строке 13 открываем файл для добавления записи о пользователе. Строка 14, собственно, сама запись: фиксируем имя пользователя, время входа, время выхода и время, проведенное пользователем на линии. Данная система биллинга очень простая: она считает только лишь время, проведенное пользователем на линии. Для того чтобы считать количество байт, которые пользователь загрузил или выгрузил из Интернета, нужно усложнить наши программы. В каждом конкретном случае надо подходить отдельно. Для той операционной системы, которую мы выбрали для написания биллинга, свойственно ядро (kernel) версии 2.2.х. В данном ядре была реализована система контроля за IP-пакетами – на уровне IP-цепочек (ipchains). Для версии ядра 2.4.х уже реализована система Netfilter, с управлением через IP-таблицы (iptables). Она более гибкая и более совершенная, нежели цепочки. Но в выбранной операционной системе применены цепочки, вы можете сами пересобрать ядро более высокой версии, но это уже отдельная тема. Существует очень много способов подсчета трафика, автор приводит для примера один из них: принцип счетчика. Чтобы подсчитать количество байт, загруженных или выгруженных пользователем, необходимо создать правило цепочек для конкретного IP, так как Linux использует для идентификации IP-пакетов IP-адреса. И каждому пользователю, подключенному по модему, всегда выдается IP-адрес, причем реально выдается два IP-адреса: один – на модем со стороны сервера, второй – на модем пользователя. Конечно же, IP-адреса выдаются не на физически работающий модем, а на компьютер. Для создания правила цепочки необходимо знать IP-адрес, который выдался пользователю. Для этого существует специальный параметр в скриптах auth-up и auth-down, данный параметр называется {RE-MOTEIP}. Его надо передать в программу, которая будет создавать правило. А так же в программу, которая будет снимать показания счетчика и удалять после выхода пользователя счетчик. Данные программы будут count-up и count-down, их вызов надо будет проставить из скриптов auth-up и auth-down соответственно: /etc/ppp/count-up {PEERNAME} {REMOTEIP} /etc/ppp/count-down {PEERNAME} {REMOTEIP} Именем цепочки будет служить имя пользователя, вернее, его логин. ipchains –N {PEERNAME} Создание новой цепочки с именем пользователя. ipchains –F {PEERNAME} Удаление всех правил в цепочке. ipchains –Z {PEERNAME} Удаление пустой цепочки. ipchains –L {PEERNAME} –nvx Извлечение статистики по цепочке {PEERNAME} в полном формате, не сокращая количество байт. ipchains –A input –s {REMOTEIP}/32 –d 0/0 –j {PEERNAME} Добавление правила в цепочку input, которое будет срабатывать при появлении пакета с исходным адресом нашего пользователя {REMOTEIP}/32 и адресом назначения любым (0/0), причем будет происходить переход в цепочку с именем нашего пользователя {PEERNAME}. ipchains –A output –d {REMOTEIP}/32 –s 0/0 –j {PEERNAME} Добавление правила в цепочку output, которое будет срабатывать при появлении пакета с адресом назначения нашего пользователя {REMOTEIP}/32, а исходный адрес может быть любым (0/0), причем переход будет происходить в цепочку с именем {PEERNAME}. ipchains –D input –s {REMOTEIP}/32 –d 0/0 –j {PEERNAME} Удаление правила из цепочки input. ipchains –D output –d {REMOTEIP}/32 –s 0/0 –j {PEERNAME} Удаление правила из цепочки output. Из этих команд вы сами можете создать какую хотите систему счетчиков по образу и подобию программ, приведенных выше. Стадия 3: ограничения на тестирование До начала тестирования системы надо сразу узнать количество ограничений, присущих данной, крайне простой, системе биллинга. Во-первых, имя пользователя может быть только лишь цифробуквенным и не более 8 символов. Во-вторых, данная система не будет работать, если пользователи будут заходить одновременно с разных модемов, так как это будет уже коммерческим биллингом. Для реализации этого пункта нужно не так уж много сил, но автор специально не приводит в статье эти изменения. Вы их всегда можете узнать или получить в Сети IRC, бесплатно или нет, – это уже все зависит от вас. В-третьих, данная система формирует только выходной текстовый файл (/var/log/inet.usr), но не формирует вывода в html-страницах. Этот пункт также можно реализовать при небольших затратах сил. Остальное не столь существенно как первые три пункта. Ну вот и все. Если у кого-нибудь возникли вопросы по данной теме, изменения или дополнения к статье, автор будет рад вам ответить. |
ДЕНИС МЯСНИЧЕНКО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
