Проблема с cookie в cj-скрипте

Я экспериментирую с сж-скриптом. Он определяет уникальность посетителей по IP. Но я вижу, что имеется определенное количество прокси-кликов, хотя прокси-серверные ip тоже учитываются:

Код:

$ip=$_SERVER["REMOTE_ADDR"]; if ($_SERVER["HTTP_X_FORWARDED_FOR"]){     $ip=$_SERVER["HTTP_X_FORWARDED_FOR"]; }

Поэтому я решил еще вставлять им куки для пущей точности определения уников. Поместил в in.php и out.php такой код:

Код:

if (!isset($_COOKIE["cookie"])) {    setcookie ('cookie',  SessionID() , time()+60*60*24*1,  '/ '); }

Загрузил на сервер, пошел погулять. Через несколько часов смотрю результаты: вроде все нормально, куки вставляются, считаются pageviews и клики. Потом смотрю статсы сиджа - оказывается прода, начиная именно с того часа, когда я загрузил новые in.php и out.php резко упала больше чем в два раза!!! Хотя уники по-прежнему считаются по ip, куки действуют просто в тестовом режиме, чтобы посмотреть, как они будут работать, и по идее никак не должны влиять ни на что вообще. Я срочно сношу скрипты с куками и загружаю старые - прода немедленно возвращается на утраченные позиции.
В чем дело???

И еще один вопрос: а как вообще лучше всего отслеживать уники? по ip, по кукам или может по сессиям. Ведь если по сессиям, тогда не важно прокси - не прокси, cookies enabled или disabled. По идее должна быть 100%-ная точность. Но могут ли тут быть какие-нибудь минусы?

Erectronic писал:

Потом смотрю статсы сиджа - оказывается прода, начиная именно с того часа, когда я загрузил новые in.php и out.php резко упала больше чем в два раза!!!

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

Erectronic писал:

И еще один вопрос: а как вообще лучше всего отслеживать уники? по ip, по кукам или может по сессиям. Ведь если по сессиям, тогда не важно прокси - не прокси, cookies enabled или disabled. По идее должна быть 100%-ная точность. Но могут ли тут быть какие-нибудь минусы?

Стопроцентной точности ты не добьешься. Лучший вариант IP+Cookie. Тоесть ставишь Куку и запоминаешь IP, а потом читаешь и в зависимости от полученных данных делаешь соответствующие выводы

Erectronic писал:

И еще один вопрос: а как вообще лучше всего отслеживать уники? по ip, по кукам или может по сессиям. Ведь если по сессиям, тогда не важно прокси - не прокси, cookies enabled или disabled. По идее должна быть 100%-ная точность. Но могут ли тут быть какие-нибудь минусы?

Только один - у тебя сервер ляжет на более или менее серьезном траффике

von Stoltz писал:

Только один - у тебя сервер ляжет на более или менее серьезном траффике

при сессиях создается на каждую сесиию реальній файл в tmp директории, ложатся форумы иногда, а не то что сиджи

iww писал:

при сессиях создается на каждую сесиию реальній файл в tmp директории, ложатся форумы иногда, а не то что сиджи

Объясни поподробнее плз. Они ложатся именно из-за создания файла на каждую сессию? А если, допустим, записывать ту же инфу не в отдельные файлы, а, к примеру, в sql-базу?

Erectronic писал:

Объясни поподробнее плз. Они ложатся именно из-за создания файла на каждую сессию? А если, допустим, записывать ту же инфу не в отдельные файлы, а, к примеру, в sql-базу?

Там несколько сложностей. Во-первых, для обработки сессии требуется либо установить идентифицирующую сессию куку, либо передавать идентификатор сессии через GET (стандартный параметр SID в пхп), и от этого никуда не деться. Во-вторых, никакой разницы по сути нет - создаются ли отдельные файлы или же это пишется в БД (в БД даже хуже, потому что идет дополнительная нагрузка за счет того, что надо еще крутить мускуль). Самое главное, что идет постоянное обращение к диску, который, как известно, самое тормозное место современного железа. А под каждого посетителя необходимо сессию создать, если она еще не создана, либо записать изменения (например, продлить сессию при активности пользователя).
Ну и в-третьих - непонятно, зачем вообще нужна сессия, если тебе не нужен ни трекинг, ни хранение каких бы то ни было пользовательских переменных, а только определение уникальности.
+1 за IP + куки.

Alchimik писал:

в БД даже хуже, потому что идет дополнительная нагрузка за счет того, что надо еще крутить мускуль

В каком-то сидж-скрипте (EasyCJ ?) сделано на расположенных постоянно в памяти mysql таблицах. Двойная выгода налицо: не надо придумывать свой интерфейс хранения и обмена данными, и обмен с папятью всегда быстрее чем с диском (хотя могут быть нюансы)

to Alchimik

Спасибо за ценный совет! (беспесды)
Нет как раз таки трекинг то мне и нужен. И мне нужно хранить в бд referrera и сколько раз серфер от этого реферера кликнул по линкам.
А разве для трекинга по IP и кукам не нужно обращение к диску???
Лично у меня на данный момент ип как раз таки и записывается в мускуль. Разве есть разница будет ли туда записываться ип или SID??? Или ты предлагаешь хранить все IP и куки пришедшие за, допустим, сутки в оперативной памяти? Так тогда наверное сервак гораздо быстрее полетит...
По моему тут не будет разницы в количестве нагрузки на сервер. Или может я не прав?
Меня интересует какая статистика будет ТОЧНЕЕ по ип+куки или по сессиям?
Ведь по ип+куки невозможно учесть анонимные прокси, которые не принимают куки. С другой стороны при каждом reload'e страницы, если у серфера нет куки, SID будет меняться. Правильно?
Так какой вариант в итоге будет точнее?

Ну и еще важна степень конфиденциальности. Т.к. как ты понимаешь куку, в которой хранится не только SID, но также, допустим, реферер, pageviews, кликии т.д., злонамеренный читер может изменять как угодно по своему усмотрению.

Все-таки еще раз повторю первый вопрос. Почему у меня резко упала прода после того как скрипт начал пытаться вставлять куки???
У меня только одна мысль: Может серферу при каждом клике на галерный линк выскакивает alert:
Глубокоуважаемый господин Пупкин! Злоебучий сервер zhopa-s-ruchkoy.com собирается поставить вам куку и с помощью нее ежедневно оповещать все прогрессивно человечество о том, сколько раз в день и в каких позах Вы дрочите. Желаете установить? Да. Нет.

Есть такая вероятность?

Cibtor писал:

В каком-то сидж-скрипте (EasyCJ ?) сделано на расположенных постоянно в памяти mysql таблицах. Двойная выгода налицо: не надо придумывать свой интерфейс хранения и обмена данными, и обмен с папятью всегда быстрее чем с диском (хотя могут быть нюансы)

Очень интересно!
Может быть ты все-таки помнишь в каком ИМЕННО сж-скрипте это сделано?
Очень хотелось бы знать как прописать в коде, чтобы mysql таблицы хранились только в памяти и не сохранялись каждый раз на диск.

Erectronic писал:

Очень интересно! Может быть ты все-таки помнишь в каком ИМЕННО сж-скрипте это сделано? Очень хотелось бы знать как прописать в коде, чтобы mysql таблицы хранились только в памяти и не сохранялись каждый раз на диск.

Не помнюв каком скрипте, но написали его наши, еще на крутопе это обсуждалось.
Вот цитата из доки по mysql:

Код:

Таблицы HEAP. Для HEAP-таблиц используются хэш-индексы; эти таблицы хранятся в памяти. Благодаря этому обработка их осуществляется очень быстро, однако в случае сбоя MySQL будут утрачены все данные, которые в них хранились. Тип HEAP очень хорошо подходит для временных таблиц!

Erectronic писал:

to Alchimik Спасибо за ценный совет! (беспесды) Нет как раз таки трекинг то мне и нужен. И мне нужно хранить в бд referrera и сколько раз серфер от этого реферера кликнул по линкам. А разве для трекинга по IP и кукам не нужно обращение к диску??? Лично у меня на данный момент ип как раз таки и записывается в мускуль. Разве есть разница будет ли туда записываться ип или SID??? Или ты предлагаешь хранить все IP и куки пришедшие за, допустим, сутки в оперативной памяти? Так тогда наверное сервак гораздо быстрее полетит...

Не предлагаю. Что же я, клинический идиот?
Я не знаю, как у тебя сделано, и на какое время ты ставишь куку. Какие-то скрипты считают дрочера, пришедшего через час, уже уникальным, какие-то ставят куки на сутки. Если пойти по пути использования таблицы типа HEAP, то по окончании действия куки надо считать статистику кроном и сбрасывать статистику в отдельную таблицу, чтобы данные не потерять, и подумать об оптимизации сервера MySQL.

Erectronic писал:

По моему тут не будет разницы в количестве нагрузки на сервер. Или может я не прав?

Будет. Ты IP для трекинга можешь вообще у себя на диске не хранить, а тоже в куку запихать. Или вообще сделать IP частью идентификационной куки. У тебя тогда получится, что все данные (уникальный идентификатор юзера и его IP) будут храниться у дрочера, а тебе только останется считать клики. И ты их точно так же будешь писать в таблицу HEAP, а потом кроном считать статистику и сливать в таблицу на диск.

Erectronic писал:

Меня интересует какая статистика будет ТОЧНЕЕ по ип+куки или по сессиям? Ведь по ип+куки невозможно учесть анонимные прокси, которые не принимают куки. С другой стороны при каждом reload'e страницы, если у серфера нет куки, SID будет меняться. Правильно? Так какой вариант в итоге будет точнее?

Точнее будет вариант с сессиями, однозначно. Там ты сможешь отслеживать и нокуки траф. Для этого юзеру, который куки не ставит, ты передаешь идентификатор сессии через GET как раз с этим параметром SID, и обработав этот SID, опять получишь переменные именно этого юзера.

Erectronic писал:

Ну и еще важна степень конфиденциальности. Т.к. как ты понимаешь куку, в которой хранится не только SID, но также, допустим, реферер, pageviews, кликии т.д., злонамеренный читер может изменять как угодно по своему усмотрению.

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

Erectronic писал:

Все-таки еще раз повторю первый вопрос. Почему у меня резко упала прода после того как скрипт начал пытаться вставлять куки??? У меня только одна мысль: Может серферу при каждом клике на галерный линк выскакивает alert: Глубокоуважаемый господин Пупкин! Злоебучий сервер zhopa-s-ruchkoy.com собирается поставить вам куку и с помощью нее ежедневно оповещать все прогрессивно человечество о том, сколько раз в день и в каких позах Вы дрочите. Желаете установить? Да. Нет. Есть такая вероятность?

Ну смотря откуда у тебя траф. Прием куки зависит от установок безопасности броузера, и странно было бы предположить, что у тебя такое количество параноидальных дрочеров с параноидальными установками безопасности. Правда, есть еще броузер lynx, который свыдает алерт на куку по умолчанию, но я плохо себе представляю дрочера, сидящего на lynx'e
У тебя там отдельно считается нореферер, нокуки и прочий отдельный траф? Может, там прода выросла? Или ищи баг, может клики были по-прежнему, просто не считались и считались криво.

Erectronic писал:

Очень хотелось бы знать как прописать в коде, чтобы mysql таблицы хранились только в памяти и не сохранялись каждый раз на диск.

Тип таблицы указывается при ее создании.

Cibtor писал:

Не помнюв каком скрипте, но написали его наши, еще на крутопе это обсуждалось.

Не в этом топике случаем? http://crutop.nu/vbulletin/showthread.php?t=51776

Alchimik писал:

Ну смотря откуда у тебя траф. Прием куки зависит от установок безопасности броузера, и странно было бы предположить, что у тебя такое количество параноидальных дрочеров с параноидальными установками безопасности. Правда, есть еще броузер lynx, который свыдает алерт на куку по умолчанию, но я плохо себе представляю дрочера, сидящего на lynx'e У тебя там отдельно считается нореферер, нокуки и прочий отдельный траф? Может, там прода выросла? Или ищи баг, может клики были по-прежнему, просто не считались и считались криво.

Кажется, с куками я разобрался. По-моему дело в том, что РНР посылает куки в виде http-header'a. У меня скрипты, которые ставили куки, посали еще другие хедеры после этого [типа редирект и т.д.]. Я стал вставлять куки с морды сиджа через <img src=cookie.php> и все стало нормально.

Alchimik писал:

Не предлагаю. Что же я, клинический идиот? Я не знаю, как у тебя сделано, и на какое время ты ставишь куку. Какие-то скрипты считают дрочера, пришедшего через час, уже уникальным, какие-то ставят куки на сутки. Если пойти по пути использования таблицы типа HEAP, то по окончании действия куки надо считать статистику кроном и сбрасывать статистику в отдельную таблицу, чтобы данные не потерять, и подумать об оптимизации сервера MySQL.

У меня уники длятся сутки.
Но почему бы и действительно не хранить все айпи за сутки в памяти? Допустим имеем 1 млн уников в день. IP - это 15 байт [максимум 12 цифр + 3 точки]. Получается 15 мегабайт на млн уников - ерунда. И бэкапить их кроном каждую минуту на диск из heap-таблицы на случай если она ляжет и надо будет восстановление.
Очень хотелось бы посмотреть исходник какого-нибудь рнр-скрипта [не обязательно сж], который работает с heap-таблицами.

Alchimik писал:

Будет. Ты IP для трекинга можешь вообще у себя на диске не хранить, а тоже в куку запихать. Или вообще сделать IP частью идентификационной куки. У тебя тогда получится, что все данные (уникальный идентификатор юзера и его IP) будут храниться у дрочера, а тебе только останется считать клики. И ты их точно так же будешь писать в таблицу HEAP, а потом кроном считать статистику и сливать в таблицу на диск. Точнее будет вариант с сессиями, однозначно. Там ты сможешь отслеживать и нокуки траф. Для этого юзеру, который куки не ставит, ты передаешь идентификатор сессии через GET как раз с этим параметром SID, и обработав этот SID, опять получишь переменные именно этого юзера.

Мне кажется вариант с сессиями для сиджа не подходит. Ведь стоит нокуки-дрочеру перезагрузить морду и он уже снова уник.
Все же я склоняюсь к варианту что ип + куки наиболее точно.
А еще я решил поэкспериментировать и стал учитывать не только ip, но и HTTP_ACCEPT_LANGUAGE и HTTP_USER_AGENT

Код:

$ip = $ip.eregi_replace ( "[^a-z|0-9]", "",$_SERVER["HTTP_ACCEPT_LANGUAGE"].$_SERVER["HTTP_USER_AGENT"]);

Получились такие, например, результаты
64.12.116.5enusMozilla40compatibleMSIE60AOL90WindowsNT51NETCLR114322
64.12.116.5enusMozilla40compatibleMSIE60AOL90WindowsNT50
64.12.116.5enusMozilla40compatibleMSIE60AOL90WindowsNT51SV1NETCLR103705NETCLR114322MediaCenterPC31
64.12.116.5enusMozilla40compatibleMSIE60AOL90Windows98Win9x490PeoplePal62
64.12.116.5rs1644c008e5a1q00rs214c34814b5bq00rs389453fd044q00Mozilla40compatibleMSIE60AOL90WindowsNT51FunWebProductsNETCLR114322
64.12.116.5enusMozilla40compatibleMSIE60AOL90WindowsNT51SV1NETCLR114322

Это по ходу юзеры сидящие за aol-proxy. И хуяк - 6 уников вместо одного.
Или вот еще
65.77.132.240enusMozilla40compatibleMSIE60Windows98
65.77.132.240engbMozilla40compatibleMSIE60WindowsNT51
65.77.132.240enusMozilla40compatibleMSIE50Windows98DigExt
65.77.132.240deMozilla40compatibleMSIE60WindowsNT51NETCLR1
65.77.132.240enusMozilla40compatibleMSIE60WindowsNT51FunWebProd
65.77.132.240engbMozilla40compatibleMSIE60WindowsNT50NETCLR1
65.77.132.240enusMozilla40compatibleMSIE60WindowsNT51Q342532

Определяемость уникальности резко повысилась [примерно на 10-15 процентов] и все мои сиджи резко поползли вверх[на 25 процентос за двое суток]. И это без кук. Сейчас буду добавлять куки. Может быть еще повысится. А если не повысится - то ну их нах. Я почему-то думаю, что не повысится - уж больно куки ненадежная штука. Зато вот если добавить еще HTTP_ACCEPT_CHARSET, тогда наверное вообще будет почти 100проц точность.

Erectronic писал:

Но почему бы и действительно не хранить все айпи за сутки в памяти? Допустим имеем 1 млн уников в день. IP - это 15 байт [максимум 12 цифр + 3 точки]. Получается 15 мегабайт на млн уников - ерунда. И бэкапить их кроном каждую минуту на диск из heap-таблицы на случай если она ляжет и надо будет восстановление.

IP - это 4 байта, а не 15. подумай: 0-255 = 1 байт. ip2long...
точки в уме проставляй

assault писал:

IP - это 4 байта, а не 15. подумай: 0-255 = 1 байт. ip2long... точки в уме проставляй

Точно.
Как же до меня раньше не доходило.
Утешает только, что не один я - лох.
Вот например строчка из скрипта TTT:

Код:

mysql_query("CREATE TABLE ttt_iplog (   ip varchar(15) NOT NULL default '' ......")

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

Erectronic писал:

64.12.116.5enusMozilla40compatibleMSIE60AOL90WindowsNT51NETCLR114322.

а с этой билибердой что делать будешь? сильно длинные записи нефиксированной длины = жуткая потеря скорости.
предложение: IP у нас 4 байта. сделай какую-нить фишку а-ля чексум длиной байта 4, который вычислять из юзер-агентов, языка и т.д.
методов много, подумай... ;)

Вот еще лохи:
Это из авроры:

Код:

CREATE TABLE `tm_cj_iplog` (   `_ip` int(11) NOT NULL default '0' .......

А теперь cjoverkill

Код:

mysql_query("CREATE TABLE cjoverkill_filter_ip (    ip_from int(10) unsigned NOT NULL default '0',    ip_to int(10) unsigned NOT NULL default '0',

Далее SMARTTRAFFICTRADER

Код:

CREATE TABLE stt_iplog (ip VARCHAR(15) PRIMARY KEY

А может действительно проще и экономнее не преобразовывать ип в 4 байта

Код:

$ipdec = explode ( ".", $ip); foreach($ipdec as $key) {    $iphex .= dechex($key); }

а прямо так и писать в таблицу?
Или все они действительно лохи?

assault писал:

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

eregi_replace мне нужен для защиты от так называемых sql injection attacks. Чтобы не пихать в бд все что ни попадя. Или там достаточно strreplace'ом удалить ' и ; ? Или может вообще не стоить насчет этих атак париться?

assault писал:

а с этой билибердой что делать будешь? сильно длинные записи нефиксированной длины = жуткая потеря скорости. предложение: IP у нас 4 байта. сделай какую-нить фишку а-ля чексум длиной байта 4, который вычислять из юзер-агентов, языка и т.д. методов много, подумай... ;)

Может быть создать отдельную таблицу для юзер-агентов и языков и дописывать к IP их id в этой таблице? Или лучше чексум?

И еще. Так стоит ли все-таки юзать еще куки или ну их нах?

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

int(11) занимает 4 байта, а твой

Код:

$ipdec = explode ( ".", $ip); foreach($ipdec as $key) {    $iphex .= dechex($key); }

займет, если не ошибаюсь - 9, да плюс еще потеряется время на выполнение этого кода

В общем - не изобретай велосипед, займись чем-то полезным

von Stoltz писал:

Послушай, родной, ты бы поаккуратнее в выражениях, особенно когда не прав Stek далеко не лох, по крайней мере, его вариант лучше того, что предложил ты. int(11) занимает 4 байта, а твой Код: $ipdec = explode ( ".", $ip); foreach($ipdec as $key) {    $iphex .= dechex($key); } займет, если не ошибаюсь - 9, да плюс еще потеряется времяa на выполнение этого кода В общем - не изобретай велосипед, займись чем-то полезным

Родной, я ни на кого наезжать не пытаюсь.
Знаю, что сам лох, потому и ищу мудрого совета.
А разве код Stekа не займет времени?

Код:

_ip=crc32($_SERVER['REMOTE_ADDR'])

Я сейчас протестировал - тоже занимает время, хотя и ровно в 2 раза меньше, чем мой.
Понял - мой код полное говно. Зауважал.
Предлагаю другой. Тоже 4 байта, и занимает столько же времени, но по-моему немного лучше:

Код:

$ip = ip2long($ip);

За каким хером понадобилось вычислять чексум из IP?

Erectronic писал:

Вот еще лохи:...

не путай varchar(15) это для "111.222.222.111", а int(10) это для ip2long("111.222.222.111") - результат функции есть четырехбайтное число. я же писал раньше ip2long()
а насчет

Код:

Может быть создать отдельную таблицу для юзер-агентов и языков и дописывать к IP их id в этой таблице? Или лучше чексум?

я бы эксперементальным путем установил бы, что быстрее: делать чексум или все писать... а потом сотни тысяч раз сверять записи...

Код:

eregi_replace мне нужен для защиты от так называемых sql injection attacks. Чтобы не пихать в бд все что ни попадя. Или там достаточно strreplace'ом удалить ' и ; ? Или может вообще не стоить насчет этих атак париться?

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

делай таблицу: IP, Чексум, Время входа.
ставь куки.
и далее:
есть куки: не уник.
нет куки:
проверять ИП и Чексум
и т.д...

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

2 assault: Спасибо за ценные советы

assault писал:

я же писал раньше ip2long()

ну и увалень же я
учиться, учиться и еще раз учиться........

А может еще лучше сделать как авторы cjoverkill [однозначно я лох а не они] через функцию mysql

Код:

$sql=@mysql_query("SELECT * FROM cjoverkill_filter_ip WHERE ip_from=INET_ATON('$ip_froma') OR ip_to=INET_ATON('$ip_toa')");

`INET_ATON(expr)'
Given the dotted-quad representation of a network address as a
string, returns an integer that represents the numeric value of
the address. Addresses may be 4 or 8 byte addresses:

mysql> SELECT INET_ATON("209.207.224.40");
-> 3520061480

The generated number is always in network byte order; for example
the above number is calculated as `209*256^3 + 207*256^2 + 224*256
+40'.

Erectronic писал:

А может еще лучше сделать как авторы cjoverkill [однозначно я лох а не они] через функцию mysql Код: $sql=@mysql_query("SELECT * FROM cjoverkill_filter_ip WHERE ip_from=INET_ATON('$ip_froma') OR ip_to=INET_ATON('$ip_toa')");

не думаю, что лучше. алгоритм везде один, только в мускуль надо передать в данном случае не 4-ре байта, а до 15, после чего мускуль сделает то же самое, что и ip2long. почти в 4-ре раза быстрее
а реально, думаю, разницу хрен заметишь.

assault писал:

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

А сколько раз в сутки это оптимально делать?