Автор статьи: Хроленок Андрей
Вся проблема геотаргетинга, как в баннерных системах, так и в системах статистики по сайтам, сводится только к тому, как наиболее эффективно и точно определить географическое местоположение конкретного IP-адреса. При этом, за исключением особых случаев, нет необходимости (да и возможности) определять географию точнее, чем название города.
Всем известен традиционный способ решения: поддержание списков блоков IP-адресов и привязка их к городам, либо конкретным провайдерам в этих городах.
Методика проста, но у нее есть явные минусы. Во-первых, блоки адресов, хоть и в малых количествах в единицу времени, постоянно перемещаются и это происходит децентрализовано. А во-вторых, всю базу придется набирать «с нуля» (это объем работ, сравнимый, например, с переписью населения), т.к. никто из уже имеющих такую базу делиться ею забесплатно не будет.
Конечно, есть возможность облегчить старт, сделав приблизительную базу, используя регистрационные записи в системе DNS, но точность там недостаточная. В итоге вся информация должна перепроверяться и уточняться, что может быть даже сложнее постепенного наполнения базы.
Второй способ мною придумывался с нуля и с учетом того, что на поддержание базы не было возможности посадить кого-либо — все должен был бы делать только я сам. Не имея уверенности, что я не изобретаю велосипед и предполагая, что способ может быть сильно новым, опишу его детально.
Все сети можно условно разделить на сети телекоммуникационных провайдеров и все прочие. Первые отличаются тем, что они преимущественно имеют большую географическую протяженность, охватывающую несколько городов (или стран), малую численность и контактируют с другими сетями во многих точках. Вторые же, наоборот, за малыми исключениями, компактны (умещаются в пределах одного города) и соединяются с сетью телекоммуникационных провайдеров в одной-двух точках. Плюс ко всему сейчас очень часто используют брандмауэры, так что весь трафик на такие сети в какой-то момент проходит через сильно малое по количеству число точек (эдакие стремнины информационного потока).
Каждая точка ветвления трафика — это компьютер, либо роутер, а значит — IP-адрес при трассировке пути следования пакетов. Также логично предположить, что трафик, идущий из любой сети второго типа при заходе в сеть первого типа (провайдерскую) пройдет как минимум через один роутер перед тем, как он покинет пределы города, в котором находится создающая трафик сеть. Более того, при транспортировке по сети провайдера трафик проходит роутеры, каждый из которых тоже можно привязать к конкретному городу (исключение — спутники), а сами эти роутеры трафик создавать не могут, потому они всегда будут фигурировать как промежуточные узлы. Если же учитывать, что оборудование таких роутеров, линий связи между ними и их прокладка — дело довольно дорогостоящее, получается, что провайдеры редко будут значительно менять топологию несущей сети, включая адреса роутеров.
Если найти возможность отслеживать местоположение роутеров провайдеров, можно на основе этой информации в автоматическом режиме отслеживать изменение географического положения крупных блоков IP-адресов и создавать базу классического типа для геотаргетинга.
Для такого отслеживания у системы геотаргетинга поддерживается база блоков IP-адресов и база известных роутеров. Во время работы, если обнаруживается ранее не встречавшийся IP-адрес, до него сразу (немедленная реакция важна чтобы отслеживать диалапщиков, которых чуть позже может уже и не быть на связи) инициируется трассирование пути (traceroute), а потом на основе полученной цепочки адресов и информации из базы известных роутеров компьютером строится предположение о географическом местонахождении конкретного адреса. Администратору остается лишь проконтролировать правильность версии и дать команду на пополнение баз этой информацией.
В начале база блоков адресов будет заполняться блоками из буквально одного адреса, потому надо вводить какие-то допущения. Например, вряд ли (если это не одинокая полярная станция) в блоке только один адрес будет соответствовать конкретному городу, скорее всего не менее 128 адресов из блока (уже облегчение работы). Далее, если вдруг получилось, что два соседних блока указывают на один город, проще их собрать в единый блок, дабы не занимали место в базе. Если же при трассировке оказывается, что трафик в эти блоки прошел через один и тот же промежуточный адрес, который также считается находящимся в этом городе, можно с большой долей вероятности говорить, что и последующие трассировки, проходящие через этот адрес, будут указывать на тот же город.
Для увеличения точности работы и борьбы с возможным накоплением ошибок можно использовать следующие механизмы: для каждого известного роутера запоминается его DNS-адрес, вычисляемый через обратные зоны в DNS, если DNS-адрес изменился — что-то не так и стоит перепроверить географию роутера. Во-вторых, для каждого роутера и для каждого блока адресов ставится какой-то большой таймаут (год-два), по истечении которого география роутера или блока должна быть также перепроверена.
Такая схема, при первоначально близких к классическому методу трудозатратах, в перспективе должна привести к относительно быстрому заполнению баз и, как результат, к резкому уменьшению трудозатрат на поддержание актуальности уже работающей базы.
