|
|
Еще одним интересным показателем является статистика запросов по «географическому» признаку – из какой страны и города было сделано обращение с последующей их группировкой по регионам. Однако файлы .log не позволяют получить данную информацию; из них можно почерпнуть только доменное имя или IP-адрес машины, с которой был заход на сервер. Все, что может сделать в этой ситуации программа сбора статистики — это определить страну по последним двум буквам доменного имени. Однако и это сделать невозможно, если «гость» представлен в файле .log своим IP-адресом, либо доменный адрес заканчивается на .com, .net, .edu и т.д., что совсем не обязательно означает США (скажем, домен skif.net находится в Донецке). Разумеется, определить в такой ситуации город нельзя уже ни в каком случае, а ведь эта информация тоже интересна.
Любому Internet-специалисту известно, что информацию о принадлежности IP-адреса или доменного имени можно получить на сервере www.checkdomain.com. Средства пакета java.net.* позволяют автоматизировать процесс подачи HTTP-запроса с указанием запрашиваемого адреса. Необходимо лишь, чтобы перед этим программа анализа файла .log подготовила файл со списком IP-адресов посетителей. Программа на языке Java перебирает все записи этого файла и для каждой из них генерирует запрос следующим образом (блоки обработки исключительных ситуаций для краткости опущены):
public static void main(String argv[]){ Geography ge = new Geography();ge.start(); } public Geography(){ f1 = new File(«Adresa»);d1 = new DataInputStream(new FileInputStream(f1)); }...public void run() {URL u;while(true) { if ((ret=d1.readLine()). length()!=0){ System.out.println(«Got string» +ret);ret=«http://www.checkdomain.com/cgi-bin/ checkdomain.pl?domain» +ret;u=new URL(ret);InputStream is = u.openStream();System.out.println(«Link to URL Okay»);}}}
Если соединение произошло успешно, из входного потока InputStream можно считывать HTML-код результирующего документа и производить его синтаксический разбор, что является наиболее содержательной и трудной частью работы.
Следует отметить ряд обстоятельства. Во-первых, особым образом должны обрабатываться внутренние адреса типа «192.168....», на которые не имеет смысла делать запрос. Во-вторых, запрос не всегда завершается удачей. Результирующий документ может либо содержать запись «Multiple entries for address ...» (адрес не распознается однозначным образом), либо не содержать никакой географической информации, например «Russian Institute for Public Networks». В этих случаях поставленная задача, видимо, неразрешима, однако подобных адресов, к счастью, немного. Так, на базе данных посетителей сервера Сургутского государственного университета, содержащей около 12 тыс. адресов, доля «трудных» адресов составила не более 2%.
И, наконец, главная проблема. При посылке запроса, содержащего доменное имя, выясняется, что доменные системы многих государств (в частности, всех стран СНГ, кроме России) серверу www.checkdomain.com не знакомы. Бесполезно запрашивать информацию об адресах, заканчивающихся на .ua, .by, .kz, .uz и т.д. Однако по IP-адресам этих хостов информация выдается. В этой связи предварительно необходимо все доменные имена в исходном файле преобразовать в IP-адреса. В операционной системе Unix это делает команда nslookup. Для автоматизации данного процесса написана вспомогательная программа на языке Си. Есть идеальное для таких целей средство – канал «команда shell – пользовательская программа», который открывается с помощью системного вызова popen. Программа анализирует выходной поток команды nslookup (он очень прост и четко структурирован), выделяет в нем IP-адрес и записывает его отдельной строкой в выходной файл, который затем станет входным для программы на Java. Если же получить IP-адрес не удалось, в выходной поток записывается первоначальный доменный адрес. Естественно, отличить во входном файле IP-адрес от доменного труда не составляет: первый состоит только из цифр и точек, второй же содержит хотя бы одну букву.
Получение сырых данных об адресах – самая трудная часть задачи, причем положительный результат принципиально не может быть гарантирован на 100%. По сути дела, речь идет об экспертной системе с нечеткой логикой принятия решений, где практически невозможно сформулировать всегда справедливое правило.
Цель синтаксического анализа – выделение двух слов названия (кода) страны и города, в котором зарегистрирован адрес машины посетителя. Ответ сервера www.checkdomain.com содержит гораздо больше информации, вплоть до фамилий и имен системных администраторов (думаю, названий страны и города вполне достаточно, ибо слишком много информации тоже иногда плохо). Главная трудность заключается в том, что строки, содержащие требуемую информацию, не структурированы и имеют практически произвольный порядок записей.
Наиболее благоприятный вариант выдачи информации о владельце IP-адреса имеет вид, приведенный во врезке.
Географическая информация может содержаться в следующих ключевых строках:
Любые из этих четырех строк могут отсутствовать. Если нет ни одной, наша задача неразрешима. Статистический анализ нашей базы данных IP-адресов показал, что наиболее надежной в смысле присутствия названия города является строка «Technical Contact», затем «Administrative Contact», и наименее надежна «Address». Именно в таком порядке эти строки и анализируются. Название страны берется из строки «Country», а в случае его отсутствия (что характерно для американских хостов) — из других строк. Возможна и ситуация, когда есть только строка «Contact» — без прилагательного.
Наиболее содержательная и при этом трудно формализуемая часть задачи – это синтаксический разбор строки «Technical Contact» (либо «Administrative Contact» или «Address»). Количество вариантов записи адреса в этой строке очень велико и, видимо, эту ситуацию изменить нельзя. Каждый администратор сети, заполняя заявку на выделение адресов и вписывая туда свои географические данные, делает это не всегда так аккуратно, как сотрудник владивостокской организации из примера на врезке, а по-своему, в соответствии со сложившимися национальными, региональными особенностями и личными традициями, поэтому унифицировать форму записи адреса невозможно. Перечислим лишь некоторые из этих особенностей.
Все это приводит к тому, что очень трудно выделить слово, обозначающее название города, а зачастую, и название страны, если нет строки «Country». Типичный ошибочный результат: в качестве названия города выдается совсем другое слово.
Несмотря на это, в результате скрупулезного статистического анализа можно сформулировать некоторые эвристические правила, увеличивающие вероятность удачного распознавания. Эти правила основываются как на формальных знаковых признаках, так и — в особо тонких случаях — на семантике анализируемого текста. Например, учитывается конкретное название страны при распознавании города, если именно для этой страны записи адресов обладают устойчивыми индивидуальными отличительными особенностями.
Приведем примеры таких правил.
Нет необходимости продолжать этот список, поскольку остальные правила (а их довольно много) слишком длинны и носят вероятностный характер.
Отметим особенно плохо преодолимые проблемы. В американских адресах часто вместо US указывается аббревиатура штата, которая совпадает с кодом другой страны, например CO – Колорадо, но и Колумбия, CA – Калифорния, но и Канада. Администратор сети может находиться в другой стране. В этом случае возникают выдачи типа «Страна: Узбекистан; Город: Москва», формально все правильно, но по смыслу абсурд; разрешение подобной ситуации требует семантического анализа.
Программная система Geography уже несколько месяцев работает в качестве ежесуточно запускаемого процесса cron на сервере городской администрации Сургута admsurgut.ru; с результатами ее работы можно ознакомиться в разделе «Статистика» (см. врезку). Точность распознавания названия города доведена до 90%, а распознавания страны – 100%.
В среднем, из 50 попыток распознавания только четыре завершаются сравнительной неудачей. Назовем причины некоторых неудач.
144.206.178.31: отсутствует пробел между строками, название города было записано так: 1Moscow. Программа не нашла подходящего слова и выдала сообщение о неудаче.
195.12.67.193: перед словом Moscow отсутствовал пробел. За название города было принято название улицы.
212.248.26.29: после слово Solyanka отсутствовало слово типа street, поэтому программа, не найдя причин пропустить это слово, приняла его за название города.
195.12.94.102: название города вообще отсутствовало, хотя название улицы (40 лет Октября) приведено. Так что этот случай неудачей считаться не может.
Безусловно, данный синтаксический разбор пока далек от того, который должны выполнять коммерческие программные продукты, однако постоянная доработка системы дает основания полагать, что точность распознавания удастся повысить.
Илья Труб — доцент кафедры прикладной математики Сургутского государственного университета. С ним можно связаться по адресу: trub@surgu.wsnet.ru
<DL> <P><DT><FONT COLOR="#000066"> <B>Owner:</B></FONT></DT> <DD>Vladivostok Long Distance And</DD> </P>
<P><DT><FONT COLOR="#000066"> <B>Address:</B></FONT></DT> <DD>International Telephone (VMTS)<BR>36, pr. Komarova st.,<BR>690600, Vladivostok, Russia</DD></P>
<P><DT><FONT COLOR="#000066"> <B>Country:</B></FONT></DT> <DD>RU</DD></P><P><DT><FONT COLOR="#000066"> <B>Administrative Contact:</B></FONT></DT> <DD>Konstantin U Kaplin (<A HREF="mailto:kku@vmts.ru" >kku@vmts.ru</A>)<BR>VMTS<BR>36, pr. Komarova st.<BR>690600 Vladivostok, Russia<BR>
Phone: +7 4232 406040<BR>Fax: +7 4232 406029</DD></P><P><DT><FONT COLOR="#000066"> <B>Technical Contact:</B></FONT> </DT><DD>Alexei V Golovin (<A HREF= "mailto:gav@vmts.ru">gav@vmts.ru</A>) <BR>VMTS<BR>36, pr. Komarova st.<BR>690600 Vladivostok, Russia<BR>
Phone: +7 4232 406040<BR>Fax: +7 4232 406029</DD></P><P><DT><FONT COLOR="#000066"> <B>Information Source:</B></FONT></DT> <DD><A HREF="checkdomain.pl?domain= 212.122.0.14&format=no"> Reseaux IP Europeens</A></DD></P></DL>
212.44.71.76 RU KALININGRAD
212.48.141.92 RU KAZAN
209.244.183.62 US LOUISVILLE
212.107.194.18 RU VLADIVOSTOK
intra.virus.ru RU MOSCOW194.84.9.252 RU MOSCOW
213.24.102.5 RU UFA
212.164.92.4 RU KEMEROVO
195.5.135.254 RU ST.PETERSBURG202.174.128.4 HK HONG195.161.195.163 RU KURGAN212.111.92.11 RU TOMSK
195.161.173.94 RU ROSTOV-ON-DON213.59.56.135 RU EKATERINBURG212.120.161.87 RU PERM144.206.178.31 RU Neudacha195.12.67.193 RU LUNACHARSKY194.67.221.29 KZ ALMATY212.248.26.29 RU SOLYANKA212.96.101.20 RU STAVROPOL
192.168.13.251 RU Surgutport.tuapse.ru RUSSIA TUAPSE212.252.6.233 TR ISTANBUL
62.24.70.140 CZ PRAHA195.50.84.44 GB LONDON
139.20.52.75 DE FREIBERG
53.122.216.254 GERMANY STUTTGART
62.244.28.189 UA KIEV
195.12.94.102 RU LET
Источник: http://www.osp.ru/os/2000/11/037.htm