Библиотека Интернет Индустрии I2R.ru

В начале 2000 года, когда инвесторы начали объявлять о покупке российских Интернет-проектов, часто можно было слышать, что показателем успешности и, следовательно, инвестиционной привлекательности проекта, является его положение в рейтингах.

По большому счету, на тот момент было всего несколько таких рейтингов (Рамблер Топ100, Топ лист, stars100 и ряд менее популярных). Кроме того, еще зимой на конференции «Инренет-бизнес Россия 2000» Антон Носик, признанный позже человеком года в российском Интернете, утверждал, что при отсутствии явных конкурентов для успешности проекта необходимо придумать врага, с которым следует беспощадно бороться. В качестве такового он предлагал использовать свою позицию в рейтинге.

Совершенно очевидно, что если и инвесторы, и руководители успешных проектов указывают на рейтинг как на один из индикаторов, влияющих на принятие решений относительно судьбы Интернет-проектов, то этот инструмент будет внимательнейшим образом изучен, и его коррекция теми или иными технологическими приемами будет взята на вооружение разработчиками и руководителями Интернет-проектов.

Развернувшаяся этим летом дискуссия о состоятельности рейтинга Рамблера, появление модерируемого Топ200.ru, пристальное внимание PWC к SpyLog и возникновение в этой системе Интернет-аудита рейтинга являются ярким тому подтверждением. Интерес к данному вопросу вызван и так называемой проблемой операционного аудита сайтов, необходимость которого была озвучена на семинарах ММВБ и РТС, посвященных выводу акций Интернет-компаний на эти торговые площадки.

Собственно, вопрос у всех (и у защитников рейтингов, и у их противников) один: можно фальсифицировать результаты автоматического рейтинга или нет?

Мы не будем вдаваться в тонкости политической подоплеки разгоревшейся дискуссии, а рассмотрим только технический аспект проблемы.

В общем можно выделить два типа систем подсчета рейтинга:
1. Подсчет кликов в линки, расположенные непосредственно на топе (домашней странице).
2. Размещения ссылки на скрипт, считающий показы – хиты, и/или уникальных посетителей, и/или хосты (типичный пример www.rambler.ru/top100/) на сайте, участвующем в рейтинге.

Рейтинги первого типа мы рассматривать не будем, т.к. не они делают погоду в операционном аудите. Остановимся на втором типе.

При регистрации в системе такого типа вам будет выдан приблизительно следующий Html код, который следует разместить на страницах вашего сайта: <img src="http://www.counter.ru/top100.cnt?11111" alt="Counter\'s Top100 Service" width=1 height=1 border=0>.

Содержательная часть данного html кода для нас - это «src=http://www.counter.ru/top100.cnt?11111», так что остальную часть html кода мы опустим.

Теперь рассмотрим, что происходит при загрузке страницы, участвующей в рейтинге. Загрузив html страницу (только html код), браузер запускает так называемый html parser (html анализатор), который последовательно ее обрабатывает, встречая таг img, браузер подгружает картинку, делая http запрос по URL (Universal Resource Locator – Универсальный Локатор Ресурсов), указанному в данном таге.

Таким образом, встретив <img src=http://www.counter.ru/top100.cnt?11111...>, браузер запрашивает данный ресурс, который, в свою очередь, является CGI скриптом, генерирующим картинку с логотипом счетчика рейтинга. Кроме того, этот скрипт вносит изменения в БД участников, по которой впоследствии и складывается рейтинг.

Здесь следует немного углубиться в процесс обмена информации в рамках World Wide Web по протоколу HTTP, именно таким образом пользователи и получают информацию с серверов в окна своих браузеров.

Нас в данный момент интересует не то, что получает браузер пользователя, а то, какую информацию о пользователе и его программном обеспечении и параметрах соединения может получить сервер из запроса клиента. Именно эта информация и учитывается счетчиком при построении рейтинга.

Ее можно получить из параметров TCP-соединения, службы доменных имен (DNS), сервиса аутентификации или из HTTP-запроса. При этом получают: IP-адрес, доменное имя, параметры соединения, параметры ПО клиента и параметры HTTP-запроса.

Начнем с конца. Рассмотрим http-запрос к данному скрипту. Как правило, для успешного выполнения скрипта Http-заголовок должен содержать следующие поля:

User-agent задает тип агента. Под агентом понимается программа, генерирующая http- запросы и обрабатывающая http- ответы, например, ваш Web- браузер. Referer задает URL документа, который содержит ссылку на затребованный URI (т.е. URI исходного документа ссылки). В нашем случае при обращении к скрипту коунтера это должен быть URL страницы, на которой расположена ссылка (так IMG, в SRC которого указан URL счетчика) на скрипт, считающий показы – хиты и уникальные хосты.

1. User-agent;
2. Referer,

иначе запрос к ресурсу (скрипту, считающему клики) будет не засчитан в рейтинговой системе ресурсов Интернета.

Первый идентифицирует тип браузера, робота, поискового паука и т.д. , а второй – ресурс (URL), который ссылается на данный скрипт. Поле User-аgent дает возможность коунтеру отсеивать запросы роботов, поисковых систем, индексирующих данную страницу и т.д.

Поле Referer является необходимым для идентификации ресурса, участвующего в рейтинге. Если бы не было данного поля, то администраторы сайтов могли бы размещать один и тот же счетчик (вернее его URL) на нескольких страницах и разных сайтах.

Комментарий: Здесь еще есть некоторые ограничения, а именно: несколько хитов с одного и того же хоста засчитываются, если время между их кликами (обращениями) больше 30 секунд. Некоторые системы рейтингов идентифицируют уникальность пользователя не только по ip, но и по выданному ему ключику cookie (например, SpyLog). Таким образом вы можете идентифицировать пользователя, даже если он заходит на страницу из-под разных прокси-серверов. Но нас эти обстоятельства впоследствии волновать не будут, так как мы будем ориентироваться на уникальные ip–хосты, которые являются основой построения любого рейтинга.

Пример: bash-2.01$ telnet counter.counter.ru 80 GET http://counter.counter.ru/top100.cnt?11111 HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) Referer: http://www.our-site.ru/our_url/article.shtml?id=1292 HTTP/1.0 200 OK Server: thttpd/2.16 29feb00 counter\'s Top100/1.2.0 Content-type: image/gif Date: Wed, 05 Jul 2000 13:08:37 GMT Accept-Ranges: bytes --- здесь тело http ответа –-- Connection closed by foreign host.

Вот, собственно, и все, что надо знать, чтобы понять принцип работы рейтинговой системы. Теперь давайте рассмотрим возможность «накрутки» рейтинга, т.е. имитации посещения страниц на сайтах типа top100, работающих по принципу, описанному выше. Сам top100 не такой примитивный счетчик, как было описано выше, но и его можно «накрутить». Называть конкретно эти сайты мы не будем, так как всем понятно, о каких из них пойдет речь.

Во-первых, нам никто не мешает сформировать http-запрос вручную (т.е. программным способом), выставить какие нам угодно Referer, User-аgent и другие поля http-заголовка, зайти с какого-нибудь хоста и занести его ip-адрес в свою или чужую (что тоже возможно) копилку.

Понятно, что мы не будем бегать от компьютера к компьютеру и дергать счетчик, так как много не надергаешь, хотя штук 100 за день можно J. Надо сказать, что в некоторых категориях электронных рейтинговых систем и это не мало. Вспомним, что есть такая вещь, как прокси-сервер.

Proxy-сервер подменят наш ip своим, а именно это нам и нужно, что бы осуществлять накрутку с одного рабочего места.

Прокси-сервер – сервер, который служит посредником между клиентом и Web-сервером, ftp-сервером, в общем, между клиентами и серверами, предоставляющими тот или иной сервис (ключевое слово в данном случае «посредник»). На самом деле он еще может выполнять множество функций: кеширования, аутентификации и т.д., но для изучения поставленной нами задачи это не важно. Для нас главное то, что это посредник.

Таким образом, зная некоторое количество адресов прокси-серверов, которые могут прокидывать http-запросы к скрипту, считающему хиты и хосты от своего имени, мы можем увеличить свой рейтинг на это самое количество. Для вывода url в 20 лучших нам может потребоваться разное количество уникальных адресов. Все зависит от того, в какой категории рейтинга зарегистрирован сайт. В любом случае, если мы имеем в своем распоряжении их более 100, это уже неплохо.

Задача, на первой взгляд, кажется простой. НО!.. Основная часть прокси-серверов прокидывает http-запросы только с фиксированных пулов ip-адресов, а оставшееся количество открытых для всех proxy очень мало, и притом их еще надо найти.

Как это сделать? Путей может быть несколько:

1. Найти адреса прокси-серверов в списках, публикуемых на некоторых сайтах.
2. Написать сканер для поиска прокси-серверов, прокидывающих http-запросы.

Первый метод мы использовать не будем, так как многие ведущие сайты типа top100 ведут списки таких прокси-серверов, и в них уже есть большинство адресов серверов, опубликованных в Интернете. Служба эксплуатации рейтинга не дремлет и постоянно улучшает свою работу.

Следует заметить, что огульное отклонение открытых анонимных прокси – это не метод. Достаточно большое количество «честных» запросов идет через эти сервера. Интернет уже проходил через полное игнорирование открытых релеев в ходе борьбы со спамом, и это ни к чему не привело.

Написание сканера, результаты

Напишем сканер, который будет посылать запросы на 80 и 3128 порты - традиционные порты, по которым работают прокси-сервера, перебирая последовательно заданный нами пул адресов. Возьмем пул размером 2 сети класса А. Посылая http-запрос, мы будем смотреть, что возвращает нам proxy-сервер. И если он возвращает затребованный нами ресурс, например html-страницу, значит данный прокси успешно прокидывает посылаемые нами http-запросы.

Что касается непосредственно самой реализации алгоритма написания, то отметим следующие, на наш взгляд, принципиальные моменты:

1. Тайм-аут при установлении соединения мы будем брать 1 секунду, дабы не затягивать сканирование.

2. Чтобы отсканировать такое большое количество ip-адрессов – порядка 34 млн., нам нужно будет создавать не один процесс, а несколько, работающих параллельно, так как иначе сканирование затянется на месяцы (речь идет о программе по Unix). Я брал 17 процессов, таким образом у меня получалось порядка 12-15 ip в секунду. Трафик при этом составлял около 3-5 килобайт в секунду (как видите, не очень много). Трафик в данном случае зависит от количества успешных tcp-соединений, а их будет не очень много, я бы даже сказал, что они будут редки.

3. Нужно быть готовым ко всякого рода кляузам и жалобам, хотя сканирование никто не запрещал (поисковые системы занимаются, например, тем же самым сканированиям). Многие владельцы Интернет-ресурсов относятся к этому очень трепетно и при обнаружении сканирования начинают бомбить жалобными письмами вашего провайдера.

В результате вы можете написать ПО, при помощи которого существует возможность отсканировать как небольшую сеть, так и всю сеть Internet, (в конфигурационном файле можно указывать диапазоны сканируемых адресов, количество процессов для того или иного диапазона, работающих параллельно, и т.д.). Единственными ограничениями выступают: пропускная способность канала, мощность вашей машины и либеральность провайдера.

Теперь о предполагаемых результатах сканирования. За 10 дней можно получить порядка 2500 адресов. После этого, пройдясь по параметрам соединений с этими серверами, возможно отобрать порядка 800 адресов, а впоследствии, после опытного тестирования, цифра может уменьшиться до 450 уникальных ip-адрессов.

Отметим порядок проверки. При проверке прокси-серверов – в качестве уникальных хостов – следует посылать http-запросы по некоторому адресу, а затем обрабатывать статистику, Web-сервера, обслуживающего запросы по выбранному нами адресу (на этом адресе следует иметь права администратора сервера).

Почему так отличаются первоначальное значение 2500 и значение после окончательной проверки 800? Дело в том, что некоторые прокси-сервера настроены таким образом, что принимают http-запросы по многим адресам, а посылают эти запросы конечному адресату с одним и тем же обратным адресом. Другими словами, вы обращаетесь, скажем, к 2 адресам 111.111.111.1 и 111.111.111.2, и они оба успешно прокинули ваш запрос, т.е. вернули затребованный вами URL. Но в логе Web-сервера, которому принадлежит непосредственно этот URL, содержатся две записи с одинаковыми ip-адрессами 111.111.111.1, таким образом, место двух уникальных хостов у нас только один.

Если объяснять этот феномен с точки зрения настройки http-сервера, то получиться, что он содержит настройки для виртуальных серверов 111.111.111.1 и 111.111.111.2 и в дополнение работает еще как прокси-сервер.

Порой бывает, что на одном прокси-сервере висят целые пулы адресов виртуальных Веб-серверов, и поэтому в логе сканера оказываются последовательности из 250, а то и больше уникальных адресов, на самом же деле уникальный адрес только один.

Накручиваем рейтинг, результаты

Прежде чем перейти непосредственно к накручиванию рейтинга, давайте рассмотрим ключевые моменты.

1. Накручивать надо таким образом, чтобы соблюдались традиционная динамика дня и другие естественные колебания нагрузки, в противном случае, о вас могут нехорошо подумать, а то и удалить ваш ресурс из рейтинга. Хотя я думаю, что это маловероятно, так как следить за каждым URL, участвующим в рейтинге, а их тысячи, непросто, и требует больших усилий, в том числе и моральных.

2. Если вы собираетесь использовать «накрутку» ежедневно, не наглейте, выводите свой сайт (URL) на те места, которым он хотя бы приблизительно соответствует.

3. Практика показывает, что можно использовать и особенности психологии пользователей рейтингов, а также дизайн-изыски. Например, красная стрелочка около вашего ресурса, показывающая рост интереса, довольно активно стимулирует посетителей рейтинга кликать на вашу ссылку.

Покаемся и сознаемся, что в течение трех месяцев занимались «накруткой» счетчиков абсолютно пустой страницы, при обращении к которой выскакивала сакраментальная фраза “Server under construction». И что любопытно, сайт попадал на заданную позицию в любом рейтинге (мы не «наглели» и выше РБК, Ленты и прочих корифеев себя ни в одной из категорий не ставили). Никакие ограничения на подсчет, которые объявлялись разработчиками этих систем, принципиально не влияли на процедуру накрутки. Увеличивалось только число прокси-серверов, через которые пробрасывались запросы.

Вместо заключения

Хотелось бы заметить, что существуют еще и другие способы накрутки рейтингов. Например, такой простой и популярный, и вместе с тем эффективный, что не упомянуть о нем было бы некорректно. Он основан на использовании встроенных фреймов. Если вы имеете страницу, которая хорошо посещается, то, разместив на ней встроенный фрейм c url другой страницы, вы сможете накрутить данный url.

<iframe src=http://our_url frameborder=0 vspace=0 hspace=0 width=1 height=1 marginwidth=0 marginheight=0 scrolling=no>

Данный метод хорош в том случае, если у вас есть уже трафик, и вы можете его перенаправить на другой URL. Но трафик это самое дорогое, поэтому, чтобы он у вас был, надо очень сильно потрудиться.

А теперь выскажем свое мнение по поводу «накрутки». Понаблюдав за рейтингом, мы пришли к выводу, что 30-40% сайтов, попадающих в ведущие двадцатки тех или иных категорий, занимаются «накруткой». Конечно, здесь можно сильно ошибаться, как в ту, так и другую сторону, так как судить об этом приходится только по некоторым косвенным факторам:

1. Некоторые сайты, накрутив себе рейтинг до той или иной позиции в первой половине дня и исчерпав, по всей видимости, при этом количество имеющихся у него уникальных ip, неизменно вылетают из двадцатки во второй половине дня.

2. Стоит накрутить себе рейтинг, как в таблице начинаются ничем не объяснимые, как только накруткой, перестановки.

В любом случае, накрутка имеет место, и с этим трудно поспорить.

Конечно, владельцы рейтинговых сайтов пытаются бороться с этим явлением. К примеру, SpyLog выдает каждому пользователю ключик (cookies), по которому впоследствии идентифицирует уникальность пользователя, но это тоже ничего не значит, так как мы (Вы J) можем формировать любые http-запросы с любыми заголовками, в частности, и такие, которые учитывают механизм cookies. Более того, такой подход требует дополнительных вычислительных ресурсов, необходимых для ведения БД уникальных ключей. Есть еще и другие полумеры, введение БД анонимных проксей и т.д., но все это только полумеры, которые не решают проблемы, а только лишний раз напоминают нам, что она существует.

Накрутка практикуется и в баннерных системах, но здесь все несколько сложней. Если вы решили накрутить себе показы или клики, то:

1. Соотношение кликов должно составлять около 2 % от количества показов.

2. В случае, если вы соберетесь выкупить показы или получить деньги за клики по баннерам с вашего сайта, то при наличии большого количества прокси, кликнувших или показавших баннер, с вами просто не будут даже разговаривать.

Но кое-что и здесь можно предпринять: накручивать баннеры на сайтах конкурента, например, кликая с десяти прокси его баннеры по 1000 раз в день. Тем самым вы дискредитируете его, что, в конце концов, приведет к тому, что ему вообще не заплатят деньги за клики.

Также всегда надо помнить, что, если вы купили n-е количество показов или кликов, то кто-нибудь всегда имеет возможность их у вас скрутить.

Это нехорошо, и вам могут намылить шею (и правильно сделают), поэтому самым надежным способом является размещение баннера на сайте не на количество показов или кликов, а на определенное время. Другими словами, надо меняться баннерами или покупать место, опираясь не на показы, а на время, в течение которого будет размещен ваш баннер на том или ином сайте.

Интернет приближается к своему тридцатилетнему рубежу. В нем до сих существует множество технологических «дыр», которые выявляют и анализируют несметное число «исследователей». В конечном итоге, не технологии определяют статут того или иного ресурса, а репутация его создателей и пользователей при условии соответствия решений современному техническому и технологическому уровню. Главное сейчас – выработать отраслевую этику, которая придет на смену этике пионеров Сети.