From: Alex Tutubalin <lexa@lexa.ru>
To: apache-talk@lists.lexa.ru, apache-rus@lists.lexa.ru
Subject: Announce: mod_uid 1.0.0
Привет,
всех с новым годом и всем новогодний подарок - модуль для правильного
подсчета пользователей.
ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_uid-1.0.0.tar.gz
Выдержка из документации (удалены куски про директивы и инсталляцию):
mod_uid.c version 1.0
модуль, выдающий "правильные" cookies для подсчета посетителей сайта
Оглавление
I. Copyright
II. Назначение
III. Установка
IV. Конфигурация
V. Формат cookie
VI. Что можно записать в лог
VII. Почему не mod_usertrack
VIII. TODO
I. Copyright
Copyright (C) 2000-2002 Alex Tutubalin, lexa@lexa.ru
Допускается распространение и использование в производных продуктах на
условиях аналогичных Apache License - должен быть сохранен копирайт автора и
ссылка на http://www.lexa.ru/lexa, производный продукт не должен называться
mod_uid
Прототип этого модуля был сделан автором при работе в компании Rambler,
данная версия cущественно переработана.
Автор благодарит Дмитрия Хрусталева за ценные советы.
II. Описание
Стандартные средства Apache не дают разумных средств трэкинга пользователей
(о проблемах mod_usertrack написано ниже), данный модуль их предоставляет.
Что он делает:
* если пользователь отдал заголовок Cookie с правильным cookie-name, то
записывает эту Cookie в notes c именем uid_got (потом, соответственно,
это можно записать в лог)
* если пользователь пришел без нужной cookie - выдает ему заголовок
Set-Cookie и записывает выданную cookie в notes с именем uid_set (и это
можно тоже записать в лог)
* если включена встроенная поддержка P3P, то при выдаче заголовка
Set-Cookie выдается и заголовок P3P
Достоинства:
* в cookie присутствует дата ее выдачи и "номер сервиса" (т.е. число,
задаваемое при настройке), что позволяет понять когда пользователь
пришел на наш сайт впервые и куда именно он пришел.
* поддержана многосерверная работа - при аккуратной настройке (либо при
полном ее отсутствии :) гарантируется, что выданная пользователю cookie
будет уникальна
* выданная пользователю и полученная от него cookie не смешиваются в
лог-файле
* cookies имеют длину 128 бит, что позволяет для работы с ними в
анализаторе логов (быстрый поиск и т.п.) использовать готовый код,
предназначенный для работы с IPv6 (например, libpatricia)
* Поддержана P3P (в минимальном объеме)
[ установка и конфигурация описаны в документации модуля ]
III. Формат Cookie
Формат куки: В двоичном виде: unsigned int cookie[4], где
cookie[0] - "номер сервиса" (задается через UIDService)
cookie[1] - время выдачи (unix time)
cookie[2] - pid процесса выдавшего куку
cookie[3] - старшие 24 бита - уникальный секвенсер в пределах процесса
(стартовое значение - 0x030303),
младшие 8 бит - номер версии куки (сейчас - 2)
Эти 128 бит переводятся в network byte order, кодируются в base64 и отдаются
клиенту (в версии 1 все отдавалось в host order, что затрудняло поддержку
кластеров серверов с разной архитектурой).
Уникальность
Очевидно, что полную гарантию может дать только страховой полис и если в
пределах одного домена будет выдано более чем 2^128 cookies, то какие-то из
них будут повторяться. Однако при разработке формата cookie были приложены
усиля к тому, чтобы при разумном количестве cookies они были бы уникальными.
1. В случае, если "номера сервиса" уникален (свой у каждого сервера) в
пределах данного домена, разные серверы будут с гарантией выдавать
разные cookies.
2. Включение в cookie времени выдачи и pid подразумевает, что pid-ы разных
процессов не повторяются в течение одной секунды. На всех известных мне
Unix-системах это так - pid-ы монотонно возрастают до некоего максимума
- 2^16 или более - т.е. для повторения cookie[1]/cookie[2] в рамках
одного сервера нужно делать больше чем 2^16 fork() в секунду, что на
сегодняшний день малореально.
3. Секвенсер (старшие 24 бита в cookie[3]) позволяет удостовериться в
уникальности cookie в пределах одного процесса в течение одной секунды.
Разрядность секвенсера позволяет выдавать до 1.0E+07 cookies одним
процессом в секунду.
VI. Что можно записать в лог
mod_uid пишет в notes ("заметки") одно из двух значений:
1. Если от клиента была получена cookie, она помещается в note "uid_got"
2. Если клиенту была выдана cookie, она помещается в note "uid_set"
Cookies пишутся в лог как 4 32-битных 16-ричных числа в host-order (т.е. для
версии 2 производится преобразование network-host, для версии 1 - все
пишется как есть в предположении, что архитектура сервера с момента выдачи
cookie не изменилась) В LogFormat эти notes можно использовать в виде
\"%{uid_got}n\" и \"%{uid_set}n\" соответственно.
При использовании LogFormat такого вида:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{uid_got}n\" \"%{uid_set}n combined_cookie
мы получим примерно такие записи в log-е
Выданная клиенту Cookie:
62.104.212.93 - - [05/Jan/2002:00:02:06 +0300] "GET / HTTP/1.0" 200
13487 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x
4.90)" "-" "ruid=000000013C36184E00009A2100002901"
Полученная от клиента Cookie:
216.136.145.172 - - [05/Jan/2002:00:14:59 +0300] "GET /buttons/but-support-e.gif
HTTP/1.0" 200 252 "http://apache.lexa.ru/english/meta-http-eng.html"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
"ruid=000000013C361B5000009A0100009501" "-"
Такой формат без проблем понимается распространенными анализаторами логов,
включая Webtrends, который по такому логу с удовольствием считает Visitors.
VII. Почему не mod_usertrack из поставки Apache
Потому что у него есть несколько недостатков:
* нет гарантий, что двум пользователям не будет выдана одинаковая cookie,
хотя конечно включение getpid(), remote_ip и времени до миллисекунд
сводит эту вероятность к минимуму
* нет поддержки многосерверной работы - а в этом случае возможность
выдачи одинаковой cookie возрастает
* в логе хочется иметь возможность видеть и выданную пользователю cookie,
причем видеть ее отдельно, mod_usertrack их перемешивает.
* Хочется иметь "номер сервиса" (см. выше) - чтобы понимать на какой из
наших сервисов пользователь зашел при первом своем визите.
VIII. TODO
1. Поддержка разных форматов (Netscape/Cookie/Cookie2 - как в
mod_usertrack), но только если появится реальная необходимость - пока
таковой необходимости не замечено.
2. Есть смутное подозрение, что на multithread-apache и многопроцессорных
машине инкремент sequencer-а нужно обложить mutex-ами
Алексей Тутубалин
mailto: lexa@lexa.ru
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =
