Кризис и интернет реклама?

26.04.2009 от vvd

В последние месяцы бросается в глаза резко упавшее качество рекламы, прокручиваемой Google. На скриншоте внизу, например, из пяти объявлений четыре — развод посетителей на деньги через СМС, при этом два сайта откровенно мошеннических (про mob-spy я даже гуглу жаловался, не удаляют). Интересно, такие объявления это признак неразвитого рынка, или уже особенность кризиса, порезавшего рекламные бюджеты?

googleadsbadtimes.png

Рубрики: Интернет, Мысли | Комментариев нет »

Полный HTTP referrer в Google Analytics

28.12.2008 от vvd

Если вы используете Google Analytics, то наверняка сталкивались с проблемой недоступности полных входящих ссылок при отчете referring sites — в ссылках обрезаются все параметры GET запроса (то, что идет после „?”). В результате, например, невозможно определить тему ссылающегося на вас форума, referrer ограничится чем либо вроде showtopic.php или index.php.

analytics_ref.png

До недавних пор данная проблема докучала не сильно, так как при желании я находил полный referrer в log файлах веб-сервера. Однако, после того как появились сайты на сторонних хостингах с недоступными логами, а на своем сервере перед apache был поставлен кеширующий прокси, такой фокус уже не проходит. Что бы не изобретать велосипед (ставить еще один трекер), пришлось искать решение проблемы средствами analytics.

Вкратце, решение состоит в том, что для каждой показанной странице в базу данных analytics попадает запись с заполненным пользовательским полем (user defined value), которое и содержит реферрер с обратной ссылкой. Определить пользовательское поле можно с помощью изменения JS кода, устанавливаемого на страницах сайта. Но гораздо эффективнее создать специальный фильтр, применив его ко всем сайтам профиля. В результате не потребуется «перелопачивать» код analitycs на всех сайтах профиля. Параметры фильтра приведены на рисунке ниже:

analytics_filter.png

Далее, создаем пользовательский отчет приблизительно следующего вида:

analytics_custom_report.png

Отдельный отчет, кстати, можно и не делать, просто в случае необходимости выбирать в качестве dimension user defined value.

И вуаля! Полные входящие ссылки в Google Analytics готовы:

analytics_udv.png

Рубрики: Интернет | 1 Комментарий »

Американский IP адрес

30.09.2008 от vvd

По заявкам читателей, небольшая инструкция о том, как (и зачем) удобно лазать в сети с IP адреса, определяемого в базе Maxmind как американский.

Вначале, зачем это вообще может понадобиться. Некоторые сайты предоставляют разный контент в зависимости от расположения пользователя. Например, на Youtube есть куча роликов только для американских или британских зрителей (лицензионные ограничения). Некоторые сайты и вовсе закрыты для пользователей из РФ, в связи с высоким уровнем мошенничества российских клиентов при покупках (характерный пример, сайт Hegre Art). Почувствуй, в общем, себя ущербным.

Для меня лично американский IP понадобился для удобного просмотра рекламных объявлений, размещаемых рекламодателями в Google Adwords. Многие рекламные кампании проводятся с гео-таргетингом для США, в результате из России не видно кучи объявлений конкурентов (на пример, выдача Adwords по запросу saas в России вообще отсутствует), а зачастую и нужный сервис проще всего найти по платному объявлению. Вторая причина — сайты, закрытые для неамериканских пользователей. Многие API и online базы данных для веб-приложений (например, MLS листинги), превентивно закрываются администраторами от внешнего мира (причины объясняют вопросами безопасности).

Бесплатно посмотреть на сеть «иностранными» глазами можно воспользовавшись анонимными прокси серверами (т.н. анонимизаторами, пример). Минус этих сервисов в обильной рекламе и невозможности работы с многими AJAX сайтами.

Если возможность ходить по сайтам с иностранного адреса вам нужна постоянно, она потребует небольшого количества денег на полноценное прокси подключение. В сети много сервисов, предлагающих прокси на основе VPN (например, по протоколу PPTP). Услуга, как правило, достаточно недорога ($5 в месяц), но неудобна — вам придется постоянно подключать/отключать сетевое подключение при необходимости ходить в сеть через/без прокси. Дело в том, что VPN будет медленнее прямого подключения (за счет дополнительной 8000км. петли РФ-США), и сидеть постоянно с прокси вам быстро надоест :-). Да и bittorrent, например, запускать с американского сервиса я остерегаюсь (у владельцев сервера есть ваши номер кредитки и почтовый адрес).

Так что вместо VPN подклоючения искать следует т.н. SOCKS прокси. Суть протокола SOCKS состоит в том, что клиент (ваш браузер) устанавливает TCP/IP соединения с сервером, который обращается к IP адресата. Преимущетво SOCKS состоит в том, его могут использовать лишь те приложения, которым это действительно необходимо, остальные будут ходить в сеть «напрямую».

Важно понимать, что SOCKS прокси, даже по шифрованному каналу, не обеспечит вам полной приватности, т.к. DNS запросы будут по прежнему идти через вашего провайдера (и теоретически могут быть перехвачены оборудованием СОРМ-2, большой брат узнает какие сайты вы посещали).

А теперь самое интересное, роль SOCKS прокси может играть любой даже самый простой виртуальный (VPS) сервер. Например, level-1 unmanaged сервер от Tektonic за $15 в месяц. Так что это отличная возможность уйти с shared-хостинга, если вы вдруг используете таковой.

Настройки элементарны:

  1. Создаем на сервере обычного пользователя с паролем (используя панель управления, либо через командную строку).
  2. Скачиваем утилиты putty (ssh клиент для windows), plink (cli интерфейс к putty) и myentunnel (для удобного контроля ssh подключения через трей). Все утилиты размещаем в одном каталоге.
  3. Запускаем myentunnel и указываем адрес VPS сервера, имя и пароль пользователя. В опциях можно так же указать автоматический запуск при загрузке и переустановку соединения при разрыве связи.

Все готово! Теперь в любом приложении, поддерживающем SOCKS, вы можете прописать IP 127.0.0.1 и порт, указанный в myentunnel. Все данные пойдут через ssh подключение, и для мира вы будете видны как пользователь из США (или из той страны, где стоит VPS сервер).

Постоянно залезать в настройки прокси в браузере очень неудобно, поэтому имеет смысл поставить удобное расширение, позволяющее делать это моментально по клику. Для FireFox знаю два варианта адд-онов —  QuickProxy и FoxyProxy. QuickProxy выполнен в духе минимализма — всего одна иконка в статус-баре и практически лишен настроек, но лично меня устраивает абсолютно. FoxyProxy же много более функционален, например позволяет задавать шаблоны URL, по которым сайт переключается на прокси. Разбираться в настройках, правда, не было необходимости и желания.

Рубрики: Интернет | 1 Комментарий »

Почему не надо использовать OpenDNS

09.08.2008 от vvd

В последнее время, особенно после появления Kaminsky DNS Vulnerability, стало популярным советовать сменить в настройках сети адреса DNS серверов на «безопасные и быстрые» сервера OpenDNS. Если по поводу безопасности претензий нет, то вот по быстроте хочется отметить одну важную проблему.

Вначале несколько абзацев простой теории. Многие CDN провайдеры, Google, Yahoo и другие крупные сайты обслуживают запросы пользователей сразу с помощью нескольких датацентров, для распределения нагрузки. Технически это можно реализовать четырьмя способами. Первый — использовать отдельное доменное имя для каждой зоны обслуживания датацентра. Т.е. хост www.sitename.com укажет на центральный датацентр, но на HTTP запрос (например, из России) сервер выдаст 302 редирект на russia.sitename.com. Недостаток такого решения — зависимость от центрального датацентра, некрасивые URL в строке браузера, лишний HTTP запрос и обращение к DNS. На практике такой метод не применяется.

Второй способ балансировки нагрузки — использование нескольких A записей для хоста, каждая из которых будет указывать на отдельный датацентр. Это решение может применяться в пределах города или небольшой страны, но когда ваши сервера расположены по всему миру может случиться так, что клиент из США выберет в качестве IP адрес датацентра в лондоне, увеличив задержку при обращении к серверу на 50-100 мс. На практике такой способ тоже не применяется.

Третий способ — т.н. Geo DNS. Сервера DNS, авторитетные за домен sitename.com указывают в ответе ближайший датацентр, сверяясь с базой данных по местоположению клиентского IP. Таким образом, запросы с восточного побережья США не пойдут в Европу и даже в датацентр на западном побережье, сохраняется минимальное время доступа к ресурсу. Именно такой способ балансировки применяется почти всеми крупными компаниями.

Наконец, четвертый вариант балансировки, он основывается на маршрутизации IP адресов в сети Интернет. Для определения кратчайшего маршрута от IP x.x.x.x до y.y.y.y провайдеры используют специальный протокол BGP. Для заинтересованных читателей принцип работы подробно изложен в приведенной ссылке, в кратце же, Интернет поделен на т.н. автономные системы (AS), которые соединены между собой. Каждой AS принадлежит одна или несколько IP сетей, и кратчайший путь маршрутизаторы рассчитывают по количеству промежуточных автономных систем до точки назначения. BGP, кстати, имеет кучу недостатков и проблем, но об этом уже в другой раз, пока вернемся к балансировке. Компания, владеющая сайтом sitename.com получает автономную систему, и анонсирует свою сеть одновременно во всех датацентрах. Таким образом, маршрутизатор в Европе, скорее всего, будет отправлять пакеты на IP адрес хоста www.sitename.com не в США, а скажем к ближайшему серверу в Лондоне. Почему скорее всего? Потому что как я указывал выше, BGP маршрутизация основана на определении кратчайшего маршрута по количеству промежеточных автономных систем, но не по географическому принципу. На практике может оказаться и так, что от клиента в России меньше промежуточных AS до датацентра в США, но не в Лондоне. Но в принципе, более-менее такая балансировка работает. Применяет ли кто такой способ для распределения нагрузки на веб-сервера не знаю, но вот OpenDNS использует его для распределения запросов к своим DNS, будучи подлключена напрямую к NTT (Tier 1 carrier).

Так вот проблема заключается в том, что сервера OpenDNS расположены всего в пяти датацентрах, а у Google, Yahoo и CDN провайдеров их гораздо больше. Указывая сервер OpenDNS в настройках сети на своем компьютере, IP адреса запрашиваемых хостов для пользователя определяет ближайший к нему сервер OpenDNS. Тот, в свою очередь, обращается к серверу, авторитетному для запрашиваемой зоны. И в случае использования Geo балансировки авторитетный DNS сервер вернет IP адрес датацентра, ближайшего к OpenDNS, но не пользователю! Для примера возьмем хост www.yahoo.com. Первый пинг запущен с Linux машины с локальным DNS клиентом, второй — с Windows машины с OpenDNS в качестве DNS.


debian:/tmp> ping -c 10 -n www.yahoo.com
PING www.yahoo-ht3.akadns.net (87.248.113.14) 56(84) bytes of data.
64 bytes from 87.248.113.14: icmp_seq=1 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=2 ttl=54 time=72.5 ms
64 bytes from 87.248.113.14: icmp_seq=3 ttl=54 time=68.6 ms
64 bytes from 87.248.113.14: icmp_seq=4 ttl=54 time=68.8 ms
64 bytes from 87.248.113.14: icmp_seq=5 ttl=54 time=72.3 ms
64 bytes from 87.248.113.14: icmp_seq=6 ttl=54 time=87.5 ms
64 bytes from 87.248.113.14: icmp_seq=7 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=8 ttl=54 time=87.4 ms
64 bytes from 87.248.113.14: icmp_seq=9 ttl=54 time=71.7 ms
64 bytes from 87.248.113.14: icmp_seq=10 ttl=54 time=74.7 ms

--- www.yahoo-ht3.akadns.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9131ms
rtt min/avg/max/mdev = 68.647/74.353/87.547/6.811 ms

C:\Documents and Settings\vvd>ping -n 10 www.yahoo.com

Обмен пакетами с www.yahoo-ht3.akadns.net [69.147.76.15] по 32 байт:

Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=149мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53

Статистика Ping для 69.147.76.15:
Пакетов: отправлено = 10, получено = 10, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 137мсек, Максимальное = 172 мсек, Среднее = 145 мсек

Таким образом, получили разницу в RTT в 70 миллисекунд. Много это или мало, и каким образом влияет на загрузку страницы? Технически, каждый HTTP запрос к сайту Yahoo будет отрабатываться на 70 мс медленнее, что для тяжелой страницы должно дать заметное замедление. Я проверил это с помощью Firebug, и получил среднюю скорость загрузки головной страницы с OpenDNS в 6-7 секунд и 4-5 секунд с DNS местного провайдера. Каждый элемент закружается примерно на 150-200мс медленнее, и спасает только Firefox 3, поддерживающий большее чем по стандарту количество HTTP подключений к серверу.

Какой из всего написанного вывод? Используйте DNS вашего интернет провайдера! Если он уязвим к атакам, звоните и требуйте чинить. Можно поставить и свой собственный DNS клиент, но делать это стоит лишь в случае если вы не выключаете ПК на ночь или имеете домашний сервер. В противном случае, при каждом перезапуске компьютера DNS будет терять кеш и делать лишние запросы к авторитетным серверам. Это замедлит первональное обращение к сайтам и создаст дополнительную совсем не нужную нагрузку на сервера, ответственные за зоны первого уровня.

Рубрики: Интернет | Комментарии (2) »