[apache-rus] Announce: mod_uid 1.0.0

[Alex Tutubalin <lexa@xxxxxxx>]

Привет,

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

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@xxxxxxx

Допускается распространение и использование в производных продуктах на
условиях аналогичных 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@xxxxxxx
=============================================================================
=               Apache-Rus@xxxxxxxxxxxxx mailing list                       =
Mail "unsubscribe apache-rus" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/mail-archive                =