Apache: Модуль Apache mod_unique

RU EN

Пункт 206. Модуль Apache mod_unique_id

Этот модуль предоставляет волшебный токен для каждого запроса, который гарантированно будет уникальным для «всех» запросов при очень специфических условиях. Уникальный идентификатор уникален даже для нескольких машин в правильно сконфигурированном кластере машин. Переменной среды UNIQUE_ID присваивается идентификатор для каждого запроса. Уникальные идентификаторы полезны по разным причинам, которые выходят за рамки этого документа.

Теория

Сначала краткий обзор того, как сервер Apache работает на машинах Unix. В настоящее время эта функция не поддерживается в Windows NT. На машинах Unix Apache создает несколько дочерних процессов, которые обрабатывают запросы по одному. Каждый дочерний элемент может обслуживать несколько запросов за время своего существования. Для целей этого обсуждения дети не делятся никакими данными друг с другом. Мы будем называть дочерние процессы httpd процессами .

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

Машины в вашем кластере должны удовлетворять этим требованиям. (Даже если у вас есть только одна машина, вы должны синхронизировать ее часы с NTP.)

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

Что касается предположений об операционной системе, мы предполагаем, что pids (идентификаторы процессов) соответствуют 32-битам. Если операционная система использует более 32 бит для pid, исправление тривиально, но должно быть выполнено в коде.

Учитывая эти предположения, в один момент времени мы можем отличить любой процесс httpd на любой машине в кластере от всех других процессов httpd. Для этого достаточно IP-адреса машины и pid процесса httpd. Процесс httpd может обрабатывать несколько запросов одновременно, если вы используете многопоточный MPM. Чтобы идентифицировать потоки, мы используем индекс потоков, который Apache httpd использует внутри. Таким образом, чтобы генерировать уникальные идентификаторы для запросов, нам нужно только различать разные моменты времени.

Чтобы различать время, мы будем использовать метку времени Unix (секунды с 1 января 1970 года по Гринвичу) и 16-битный счетчик. Временная метка имеет гранулярность только в одну секунду, поэтому счетчик используется для представления до 65536 значений в течение одной секунды. Четверки ( ip_addr, pid, time_stamp, counter ) достаточно для перечисления 65536 запросов в секунду на процесс httpd. Однако со временем возникают проблемы с повторным использованием pid, и для решения этой проблемы используется счетчик.

Когда создается дочерний элемент httpd, счетчик инициализируется ( текущие микросекунды, деленные на 10 ) по модулю 65536 (эта формула была выбрана для устранения некоторых проблем с дисперсией битов младшего разряда микросекундных таймеров в некоторых системах). При создании уникального идентификатора используется временная отметка времени поступления запроса на веб-сервер. Счетчик увеличивается каждый раз, когда генерируется идентификатор (и разрешается пролонгировать).

Ядро генерирует pid для каждого процесса по мере его разветвления, и pid разрешено менять (во многих Unix они 16-битные, но более новые системы расширены до 32-битных). Таким образом, со временем один и тот же pid будет использоваться повторно. Однако, если он не используется повторно в течение одной секунды, он не разрушает уникальность нашей четверки. То есть мы предполагаем, что система не порождает 65536 процессов за интервал в одну секунду (на некоторых Unix-системах может быть даже 32768 процессов, но даже это маловероятно).

Предположим, что время по какой-то причине повторяется. То есть предположим, что системные часы сбились и возвращаются к прошедшему времени (или они слишком далеко вперед, корректно сбрасываются, а затем возвращаются к будущему времени). В этом случае мы можем легко показать, что можем повторно использовать pid и отметку времени. Выбор инициализатора для счетчика призван помочь победить это. Обратите внимание, что мы действительно хотим, чтобы случайное число инициализировало счетчик, но в большинстве систем нет доступных чисел ( например , вы не можете использовать rand(), потому что вам нужно заполнить генератор, а не можете его заполнить). со временем, потому что время, по крайней мере, с разрешением в одну секунду повторяется). Это не идеальная защита.

Насколько хороша защита? Предположим, что одна из ваших машин обслуживает не более 500 запросов в секунду (что является очень разумным верхним пределом на момент написания этой статьи, потому что системы обычно делают больше, чем просто разгребают статические файлы). Для этого потребуется несколько дочерних элементов, которые зависят от того, сколько у вас одновременных клиентов. Но мы будем пессимистами и предположим, что один ребенок способен обслуживать 500 запросов в секунду. Существует 1000 возможных начальных значений счетчика, так что две последовательности из 500 запросов перекрываются. Таким образом, существует вероятность 1,5%, что если время (с разрешением в одну секунду) повторяется, этот дочерний элемент будет повторять значение счетчика, и уникальность будет нарушена. Это был очень пессимистичный пример, а с реальными ценностями это еще менее вероятно. Если ваша система такова, что это все же может произойти, то, возможно, вам следует сделать счетчик 32-битным (путем редактирования кода).

Вы можете быть обеспокоены тем, что часы «переводятся назад» во время летнего перехода на летнее время. Однако это не проблема, потому что здесь используется время UTC, которое «всегда» идет вперед. Обратите внимание, что Unix на базе x86 может потребовать правильной настройки, чтобы это было правдой - они должны быть настроены так, чтобы считать, что часы материнской платы находятся в UTC, и соответствующим образом компенсировать. Но даже несмотря на это, если вы используете NTP, ваше время UTC будет правильным вскоре после перезагрузки.

Переменная UNIQUE_ID среды строится путем кодирования 144-битного (32-битный IP-адрес, 32-битный pid, 32-битная отметка времени, 16-битный счетчик, 32-битный индекс потока) четверного числа с использованием алфавита способом, аналогичным кодированию MIME base64, [A-Za-z0-9@-] создавая 24 символа. [A-Za-z0-9+/] Однако на самом деле алфавит MIME base64 + должен / быть специально закодирован в URL-адресах, что делает их менее желательными. Все значения кодируются в сетевом порядке байтов, поэтому кодирование сопоставимо для разных архитектур с различным порядком байтов. Фактический порядок кодирования: отметка времени, IP-адрес, pid, счетчик. У такого порядка есть цель, но следует подчеркнуть, что приложения не должны анализировать кодировку. Приложения должны рассматривать все закодированное UNIQUE_ID как непрозрачный токен, который можно сравнивать с другими UNIQUE_ID только для равенства.

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

Мы считаем, что это относительно портативное решение этой проблемы. Сгенерированные идентификаторы имеют практически бесконечный срок службы, поскольку будущие идентификаторы могут быть увеличены по мере необходимости. По сути, не требуется никакого обмена данными между машинами в кластере (требуется только синхронизация NTP, что требует небольших накладных расходов), и не требуется никакого обмена данными между процессами httpd (связь подразумевается в значении pid, назначенном ядром). В очень специфических ситуациях идентификатор может быть сокращен, но необходимо предполагать больше информации (например, 32-битный IP-адрес является излишним для любого сайта, но для него нет переносимой более короткой замены).