Php блокировка PHP


Блокировка файлов от записи на PHP

При частых обращениях к файлам (для чтения или записи) может возникнуть такая ситуация, когда один процесс осуществляет запись в файл, а второй в это же время считывает данные из файла. Еще хуже, если данные считываются из файла, обрабатываются и обратно записываются. Таким образом, если не ставить блокировку на файлы на время их обработки, может возникнуть ситуация, при которой данные будут одновременно обрабатываться несколькими и процессами и могут быть искажены или потеряны.

Для блокировки и разблокировки файлов мы рекомендуем Вам использовать стандартную функцию PHP flock() с флагами LOCK_EX и LOCK_UN. Флаг LOCK_EX используется для эксклюзивной блокировки файла (т.е. доступ к файлу будет доступен только процессу, поставившему блокировку), а LOCK_UN — для снятия блокировки с файла.

Чтобы было понятнее, давайте рассмотрим пример блокировки и разблокировки файла file.txt:

php
$fh = fopen ( «file.txt» , «a+» ); //открываем для чтения/записи
flock ( $fh , LOCK_EX ); //блокируем файл
fseek ( $fh , 0 ); //ставим указатель на начало файла
while (! feof ( $fh )) $line . = fread ( $fh , 2048 ); //считываем из файла

//здесь производим обработку считанных данных

ftruncate ( $fh , 0 ); //очищаем файл
fwrite ( $fh , $Res_$line ); //записываем в файл
flock ( $fh , LOCK_UN ); //снимаем блокировку
fclose ( $fh ); //закрываем файл
?>

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

Как видите, ничего сложного на самом деле в блокировке файлов нет, и на скорости работы сайта не сказывается. Подобная блокировка файлов используется и на нашем сайте для подсчета количества посетителей онлайн. Но с блокировкой файлов стоит обращаться осторожно, т.к. может возникнуть ситуация когда блокировка файла может быть по какой-либо причине не снята и тогда в файл невозможно будет что-либо записать.

php Блокировка сессии — в чем причина, как это работает. «Почему все страницы сайта начинают зависать»

Primary tabs

Forums:

Как проявляется проблема

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

Причины блокировок

  • По умолчанию php хранит сессии в файлах
  • После того как вызвана session_start() файл данной сессии (файлы других сессий тут ни при чем) блокируется скриптом и не разблокируется до тех пор, пока не данные скрипт не завершится или не вызовет session_write_close().

Как исправить/избежать блокировки сессий

Сразу закрывать сессию, после проделанных с ней операций (т.е. писать код иначе)
Использовать нестандартное хранилище сессий, в котором нет блокировок (например redis)

Key Words for FKN + antitotal forum (CS VSU):

  • Log in to post comments
  • 1339 reads

Wed, 10/10/2020 — 16:58

поясните, пожалуйста

Сразу закрывать сессию, после проделанных с ней операций

— что это означает фактически?
Явно вызывать закрытие сессии?


  • Не является ли само по себе ошибкой то, что скрипт «не завершается»? Есть ли смысл при этом закрывать сессию вручную вместо того, чтобы оптимизировать работу скрипта?
    • Log in to post comments

    Wed, 10/10/2020 — 17:06

    примеры ситуаций, где возможна блокировка сессий

    да, явно вызывать закрытие сессии, напрямую или средствами фреймворка, в конечно итоге это должно приводить к вызову session_close().

    Не является ли само по себе ошибкой то, что скрипт «не завершается»?

    Архитектурной да, но не фактической. Например ваш сайт делает запрос к APIшке, которая в этот конкретный момент вдруг стала отвечать резко дольше, чтобы не заблокировать все страницы сайта для пользователя с данной сессией, следует перед таким опасным местом в коде (перед обращение к API) закрыть сессию, если ваша система держит её открытой.

    Есть ли смысл при этом закрывать сессию вручную вместо того, чтобы оптимизировать работу скрипта?

    т.е. как было сказано выше не всегда можно её оптимизировать (если это внешняя система, разве что кешировать запросы кроном, так чтобы клиент всегда обращался к кешу, но это тоже не очень хорошо если есть задача показывать самое актуальное),
    более того, другой пример:
    если у вас много ajax-а значит у вас не очень простое приложение, и скорее всего в нем есть операции, которые выполняются не очень быстро, а значит механизм стандартного хранения просто приведёт к тому, что запросы, которые должны обрабатываться параллельно (для чего аякс и используют), могут начать строиться в очередь.

    _____________
    матфак вгу и остальная классика =)

    лучший способ получить блокировку в php

    Я пытаюсь обновить переменную в APC, и будет много процессов, пытающихся это сделать.

    APC не предоставляет функции блокировки, поэтому я рассматриваю возможность использования других механизмов … то, что я нашел до сих пор, это GET_LOCK () и mysql’s flock (). Что еще стоит рассмотреть?

    Обновление: я нашел sem_acquire, но он блокирует блокировку.

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

    Причина, по которой apc_add является правильным решением, заключается в том, что она избегает условия гонки, которое в противном случае существовало бы между проверкой блокировки и установкой ее на «заблокированную вами». Поскольку apc_add устанавливает значение только в том случае, если оно еще не установлено («добавляет» его в кеш), он гарантирует, что блокировка не может быть приобретена двумя вызовами одновременно, независимо от их близости во времени. Никакое решение, которое не проверяет и не устанавливает блокировку в одно и то же время, по своей сути будет страдать от этого состояния гонки; требуется одна атомная операция для успешной блокировки без состояния гонки.

    Поскольку блокировки APC будут существовать только в контексте этого выполнения php, это, вероятно, не лучшее решение для общей блокировки, поскольку оно не поддерживает блокировки между хостами. Memcache также предоставляет функцию добавления атомов и, следовательно, может также использоваться с этой методикой – одним из способов блокировки между хостами. Redis также поддерживает атомные функции «SETNX» и TTL и является очень распространенным методом блокировки и синхронизации между хостами. Howerver, OP запрашивает решение для APC в частности.

    Если точкой блокировки является предотвращение попыток нескольких процессов заполнить пустой ключ кеша, почему бы вам не заблокировать блокировку?

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

    Собственно, проверьте, будет ли это работать лучше, чем предложение Питера.

    используйте эксклюзивный замок и, если вам удобно, поставьте все остальное, которое попыталось заблокировать файл в 2-3-секундном сне. Если все сделано правильно, ваш сайт будет испытывать зависание в отношении заблокированного ресурса, но не орды скриптов, борющихся за кеширование.

    Если вы не возражаете, основывая свою блокировку на файловой системе, вы можете использовать fopen () с режимом «x». Вот пример:


    Я понимаю, что это год, но я просто наткнулся на этот вопрос, проведя некоторое исследование самостоятельно по блокировке в PHP.

    Мне кажется, что решение может быть возможно с использованием самого APC. Назовите меня сумасшедшим, но это может быть приемлемым подходом:

    На практике я мог бы добавить еще одну функцию, чтобы создать ключ для использования здесь, чтобы предотвратить столкновение с существующим ключом APC, например:

    Параметр $expire – прекрасная возможность использования APC, поскольку он предотвращает ведение блокировки навсегда, если ваш скрипт умирает или что-то в этом роде.

    Надеюсь, этот ответ будет полезен для всех, кто спотыкается здесь через год.

    Фактически, я обнаружил, что мне вообще не нужна блокировка … учитывая то, что я пытаюсь создать, является карта всех ассоциаций path => path для автозагрузки, неважно, один процесс перезаписывает то, что нашел другой (это очень маловероятно, если оно правильно закодировано), потому что в любом случае данные получат его. Таким образом, решение оказалось «не замками».

    У EAccelerator есть методы для этого; eaccelerator_lock и eaccelerator_unlock .

    Не могу сказать, если это лучший способ справиться с работой, но, по крайней мере, это удобно.

    Использование так просто.

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

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

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

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

    Блокировки сессий в PHP и их отладка

    Буквально несколько дней назад на сайте 1С-Битрикс была опубликована статья Николая Рыжонина о возможностях сократить случаи блокировки сессий для долгих обработок запросов. Мы же в своей статье решили в целом пройтись подробнее — почему эти блокировки происходят, почему PHP-процессы «залипают» на инициализации сессий — session_start() — и как с этим бороться.

    Время от времени у наших клиентов в процессе отладки запросов, которые долго выполняются, возникает вопрос — почему сессии начинают долго работать? Выглядит проблема примерно так — неожиданно пользователь, пытаясь открывать новые страницы на сайте, не может дождаться их открытия, а если пользователь генерирует большое число таких запросов, это происходит уже у всех посетителей сайта. Apache/PHP-FPM забиваются процессами, ожидающими снятия блокировки с файла сессий, и часто — помогает только перезапуск этих сервисов.

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

    Стандартный обработчик сессий в PHP реализует их хранение в файлах путем хранения сериализованного содержимого массива $_SESSION в файле в директории, заданной переменной session.save_path. При старте сессии функцией session_start PHP либо создает и открывает, либо повторно открывает файл сессии. При этом PHP выставляет глобальную блокировку на чтение этого файла на время работы с ним. Сделано это преднамеренно — в противном случае в условиях многопоточности несколько скриптов могут открыть один и тот же файл с сессией, изменить значения ее переменных, а затем закрыть и записать сессию в файл, и таким образом данные одного из скриптов будут утеряны.
    Объяснить это можно простым примером: пусть есть скрипты 1.php и 2.php и некая сессия в которой уже выставлены следующие переменные:

    1.php:

    2.php:

    Если бы в PHP не была реализована блокировка сессий, а скрипты выполнились бы одновременно, результаты выполнения работы скрипта 1.php не были бы сохранены в сессии.

    Все это в принципе приемлемо, до той поры, пока скрипты выполняются несколько сотен миллисекунд (что типично для веба), однако активное использование AJAX-а, активная разработка, сложные внутренние портальные системы создают большой риск для длительной блокировки сессий, источник которой приходится довольно нетривиально ловить.

    Для примера — довольно часто мы видим, как некие сложные процессы, выполнение которых занимает длительное время, реализуют через AJAX-запрос. Пользователь заходит на страницу, где запускает, например, процесс импорта данных из внешнего сервиса. Импорт происходит в скрипте, через AJAX-запрос. Пока импорт происходит, пользователь может открыть и другие страницы. Если вдруг работа внешнего сервиса замедляется, а скрипт, занимающийся импортом использует сессии — файл сессий останется заблокированным на время выполнения этого скрипта. Соответственно ни одна страница сайта для этого пользователя не будет открыта до завершения его работы. Скрипт выполняется десятки секунд? Все это время сайт будет полностью недоступен для пользователя.

    Мастер Йода рекомендует:  Где вы будете плыть быстрее — в воде или сиропе

    Ловить подобную проблему, если она начинает происходить массово, очень сложно. Если мы решим просто отследить, где висят запросы пользователя — большая часть запросов окажется висящими в состоянии session_start() — раздраженные пользователи пытаются снова и снова открыть недоступные страницы. Для того, чтобы ловить подобныю проблемы, мы рекомендуем использовать профилирующий модуль XHProf от фейсбука с последующей фильтрацией результатов его работы. XHProf сохраняет результаты работы в файл с сериализованным массивом статистики, который потом сам же использует для профилировки. Таким образом мы получаем набор файлов с результатами выполнения каждого запроса пользователя. Для того чтобы выбрать нужные нам результаты, необходимо открыть каждый файл и проверить, какое время выполнения занимала функция session_start() — нас интересуют только те, где выполнения скрипта было долгим, а выполнение этой функции — коротким, те самые скрипты, которые привели к блокировке. Мы для фильтрации используем следующий скрипт:
    session_start’, $data) || !array_key_exists(‘wt’, $data[‘run_init::main/include.php==>session_start’])) <
    $sessionStart = 0;
    > else <
    $sessionStart = $data[‘run_init::main/include.php==>session_start’][‘wt’];
    >

    if ($total > $thresholdTotal && $sessionStart

    Что такое блокировка файлов в PHP [duplicate]

    Я пытаюсь понять неблокирование flock и аргумент beblock


    Документация говорит о willblock:

    Необязательный третий аргумент устанавливается равным 1, если блокировка блокируется (условие ошибки EWOULDBLOCK).

    Воспроизведение в тестовой среде параллельного условия, если другой процесс приобрел блокировку, функция стаи будет немедленно возвращать FALSE (не блокировать)

    . Так почему я должен заботиться about $ beblock value, если возвращаемое значение функции flock в неблокирующем режиме allready говорит мне, что блокировка не может быть получена?

    Я не могу получить разницу между функцией flock, возвращающей FALSE и $ аргумент beblock, установленный в 1, и то, что аргумент $ beblock полезен для.

    1 ответ

    Это связано с тем, что flock() может потерпеть неудачу не только потому, что замок уже получен где-то в другом месте. В таком случае он не блокирует ожидание блокировки, но сразу же возвращает false. Другими словами, с помощью LOCK_NB , если flock возвращает false и willblock = 1, значит, он попытался получить блокировку, но он уже получен где-то в другом месте. Но если flock с LOCK_NB возвращает false и beblock = 0, то это означает, что что-то действительно плохое происходит, и стая даже не рассматривала возможность ожидания блокировки, поскольку это было совершенно невозможно.

    Также, чтобы устранить любую путаницу будущих читателей, стоит отметить, что проверка EWOULDBLOCK имеет смысл только для flock () с флагом LOCK_NB , так как в режиме блокировки это либо успех, либо блок или сбой, и никакой блок.

    Вы можете подтвердить это, посмотрев на php исходный код для flock :

    EWOULDBLOCK установлен только в том случае, если operation & LOCK_NB && ret == -1 && (errno == EACCES || errno == EAGAIN) .

    Если вас больше интересует реализация, вы также можете прочитать man fcntl , в основном части о F_SETLK и F_SETLKW :

    Получить блокировку (когда l_type — F_RDLCK или F_WRLCK) или освободить блокировку (когда l_type — F_UNLCK) в байтах, заданных полями l_whence, l_start и l_len блокировки. Если конфликтующая блокировка удерживается другим процессом, этот вызов возвращает -1 и устанавливает errno в EACCES или EAGAIN.

    Что касается F_SETLK, но если конфликтующая блокировка сохраняется файл, затем дождитесь, когда этот замок будет выпущен. Если сигнал улавливается во время ожидания, то вызов прерывается и (после возврата обработчика сигнала) возвращается немедленно (с возвращаемым значением -1 и errno, установленным в EINTR).

    Блокировка выполнения PHP-скрипта (cron, lock)

    korwru

    Новичок

    Может ли кто поделиться кодом, как временно заблокировать повторный запуск PHP скрипта, если он ещё не успел выполниться.

    Запуск осуществляется по cron’у 1 раз в 1 минуту.
    Скрипт импортирует каталог товаров, создаёт/изменяет разделы и теоретически он может не успеть выполниться в отведённое время.

    1) Прописать set_time_limit(0); — не вариант.
    2) Планировал создавать lock-файл, но похоже чего-то недопонимаю. Кому интересно — обсуждение было тут

    Вурдалак

    I’d like to model your domain

    weregod

    unserializer

    korwru

    Новичок

    Также на форуме нашёл высказывание:

    zerkms

    TDD infected


    Также на форуме нашёл высказывание:

    Правильно ли я понимаю, чтобы подобное не случилось, в конце файла нужно закрыть процессы следующим образом:

    Linker

    Новичок

    А ведь совсем не обязательно блокировать сам исполняемый файл.
    Можно при запуске скрипта Cron’ом проверять, есть ли определённый файл и если нет — создавать пустой файл (не важно как называется, как удобно)
    а затем скрипт дальше делает, что там нужно и по окончанию работы файл удаляет.
    А если файл есть, скрипт ничего не делает — die или exit

    Если по времени критично, то вообще стоит сделать файл очереди, в котором будут помечаться этапы выполнения скрипта,
    Т.е. Cron запускает скрипт, скрипт читает файл очереди, и продолжает, если есть что продолжать или, если предыдущий запуск отработал до конца, начинает заново.
    Как-то так.

    P.S. Поторопился и не прочитал, что у вас по ссылке
    А в чём проблема? Может просто путь не правильно указан? Всё должно быть нормально.

    zerkms

    TDD infected

    Linker

    Новичок

    zerkms

    TDD infected

    Linker
    Лапша — потому что if(file_exists()) & touch() не атомарны.

    Поэтому и нужно:

    Не получили эксклюзивный лок — выходим
    Получили эксклюзивный лок — работаем

    Порядок выполнения PHP скриптов или как заблокировать повторное выполнение

    Вопрос если при первой запущенной копии скрипта (он уже создал файл lock.txt), запустить его ещё раз, то вторая копия будет выполняться только после того, как 1 закончит свою работу. Грубо говоря — будет выведено 6 раз echo. А я ожидал, что если повторно запускаю скрипт и он видит файл с блокировкой, то он выходит по die.

    1) Подскажите, из-за чего такое происходит?
    2) Возможно ли прекращать выполнение второй запущенной копии, а не дожидаться её повторного выполнения.

    Запускаю на Denwere
    PHP Version 5.3.3

    В FF 6.0.2 — глючит, Opera 11.51 — глючит. В IE 8 — работает.
    Вывод: В случае необходимости используем браузер IE 🙂

    3 ответа 3

    Такая блокировка не надежная. Дело в том, что если в скрипте произойдет ошибка, либо если скрипт будет убит извне, то файл не будет удален и все последующие запуски будут безуспешными. Для того, что бы этого избежать необходимо использовать flock(). Алгоритм примерно следующий:

    Что-же касается запуска долгоиграющих скриптов, то полноценных способов тут два:

    1. Форкать/запускать еще один скрипт в отдельном процессе, а текущий завершать.
    2. При использовании PHP-FPM, вызывать функцию fastcgi_finish_request(). Тогда запрос корректно завершится, а скрипт продолжит работать сколько угодно долго.

    Вариант-же с явной отправкой заголовка Content-Length, не очень хороший, поскольку:


    1. Подходит только в случае если php работает через mod_php apache’а. Т.н. c nginx’ом такой фокус уже не прокатит.
    2. Во некоторых браузерах соединение не будет закрыто и как следствие иконка загрузки страницы будет крутиться до тех пор пока скрипт окончательно не завершиться (или пока пользователь не нажмет кнопку Stop)

    Защита сайта от сканирования и хаотичных интенсивных запросов

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

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

    Достаточно эффективной мерой защиты сайта от сканирования будет разграничение прав доступа к ресурсам сайта. Информацию о структуре сайта поможет скрыть модуль apache mod_rewrite изменяющий ссылки. А сделать неэффективным сканирование ссылок и, одновременно, снизить нагрузку поможет установка временной задержки между частыми запросами исходящими от одного пользователя. Для поддержания эффективной защиты от сканирования и хаотичных интенсивных запросов необходим регулярный аудит вэб-ресурсов.

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

    К эффективным методам защиты сайта от хаотичных интенсивных запросов относятся: установка временной задержки между запросами в определенный промежуток времени, создание черного и белого списков, установка для поисковых систем временной задержки между запросами страниц сайта в файле robots.txt и установка периода обновления страниц в файле sitemap.xml.

    Мной был реализован один из методов по защите сайта от сканирования и хаотичных интенсивных запросов, который заключается в подсчете количества запросов в определенный промежуток времени и установке временной задержки при превышении установленного порога. В частности этот метод делает неэффективным или даже бесполезным способ взлома пароля путём перебора, потому что затраченное на перебор время будет слишком велико. Готовый php скрипт под капотом.

    1. Данные о реализуемом php-скрипте

    В настоящее время на практике используются различные подходы к защите любой компьютерной информации, в том числе и информации, располагаемой на Интернет-ресурсе. Данные подходы могут быть определены следующими характеристиками:
    — наличием формализованных требований, как к набору, так и к параметрам всех механизмов защиты, которые регламентируются большинством современных требований к обеспечению общей компьютерной безопасности (иначе говоря, требованиями, определяющими, что именно должно быть предусмотрено разработчиками);
    — наличием реальных механизмов защиты, которые реализуются в процессе защиты любой компьютерной информации. К таким механизмам защиты, прежде всего, относя встроенные в операционную систему средства защиты, по той простой причине, что в большинстве своем используемые на веб-сервере скрипты пользуются встроенными в операционную систему механизмами защиты или же наследуют используемые в них методы. Именно на базе этих механизмов и используемых в них методов определяется общий уровень защиты всего веб-сервера;
    — существующей статистикой различных угроз безопасности компьютерной информации. В частности, это данные об уже осуществленных успешных атаках на какие-либо информационные ресурсы. Ведение данной статистики призвано помочь определить, насколько эффективны предпринятые меры защиты, а также дать оценку уровню выдвигаемых требований к созданию защиты на веб-сервере.

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

    Данный метод защиты сайта следует реализовать путем написания php-скрипта. Использование такого рода скрипта поможет защитить содержимое сайта от сканирования проводимого при помощи программ-краулеров и, одновременно, поможет существенно замедлить проведение сканирования сайта «вручную». Кроме того, использование подобного скрипта обеспечит прекрасную защищенность абсолютно всех страниц сайта от различных видов хаотичных интенсивных запросов, что в свою очередь даст возможность снизить нагрузку на оборудование веб-сервера.

    Разрабатываемый скрипт должен иметь возможность настройки. В частности необходимо заранее предусмотреть возможность изменения части параметров скрипта. Иначе говоря, в скрипте должно быть:
    — наличие возможности настройки времени блокировки IP-адреса пользователя;
    — наличие возможности задать интервал времени, в который будет проверяться активность пользователя, иначе говоря, время, в течение которого будет вестись учет количества запросов, поступивших от одного определенного пользователя;
    — наличие возможности установки количества запросов, которые один пользователь сможет отправить на страницы сайта в течение заданного временного интервала;
    — наличие возможности создания списка «всегда разрешенных IP-адресов». IP-адреса, внесенные в данный список, никогда не будут заблокированы;
    — наличие возможности создания списка «всегда запрещенных IP-адресов», т.е. скрипт всегда будет блокировать IP-адреса, которые внесены в данный список.

    Мастер Йода рекомендует:  Как начать разбираться в 3D-моделировании и Unity 3D

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

    Логика работы разрабатываемой системы защиты сайта, создаваемой в виде php-скрипта, приведена на рисунке:

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

    В одну из таких директорий скрипт будет помещать на хранение IP-адреса активных, на данный момент пользователей, эта директория будет носить название active. А в другую директорию мы будем вносить файлы, название которых будет включать IP-адреса временно заблокированных пользователей (директория block).

    Кроме IP-адреса, в процессе работы скрипта, также понадобиться информация об активности пользователя. Для этого в название файла, содержащего IP-адрес пользователя, мы также будем вносить точное системное время, когда он проявил «первую», в заданный промежуток времени, активность, т.е. первый раз за определенный (заранее установленный) промежуток времени отправил запрос к странице сайта. В случае, если пользователь в заданный интервал времени превысил заранее определенное в скрипте количество отправленных запросов к страницам сайта, скрипт удалит файл, содержащий его IP-адрес из директории активных пользователей. После чего запишет новый файл (название которого будет содержать IP-адрес только что заблокированного пользователя) в директорию, содержащую заблокированные IP-адреса. Таким образом, в директориях кэширования (active и block) будут временно сохраняться файлы с такими названиями как: 127.0.0.1_1302615293, 195.80.91.151_1302615389, 95.30.17.60_1302615457, 77.39.54.104_ 1302615504 и тому подобные.

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

    Отдельно следует отметить тот момент, что для директорий кэширования, т.е. папок active и block, обязательно нужно выставить права доступа владельца файла или 777. Иначе говоря, атрибуты данных папок, указанные на сервере, должны давать скрипту право на запись, право на чтение, а также право на выполнение. Права доступа 777 обязательно должны быть установлены для всех групп пользователей.

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

    Информацию о текущих пользователях (в частности, об их IP-адресах) мы будем брать из суперглобального массива $_SERVER[]. Данный массив создается веб-сервером. В нем содержатся значения разнообразных переменных окружения. Для работы с IP-адресами пользователей нам понадобиться использовать такие переменные окружения, содержащиеся в суперглобальном массиве $_SERVER[]:
    — $_SERVER[‘HTTP_X_FORWARDED_FOR’];
    — $_SERVER[‘HTTP_CLIENT_IP’];
    — $_SERVER[‘HTTP_X_CLUSTER_CLIENT_IP’];
    — $_SERVER[‘HTTP_PROXY_USER’];
    — $_SERVER[‘REMOTE_ADDR’].

    Переменная окружения $_SERVER[‘HTTP_X_FORWARDED_FOR’] дает нам возможность определить IP-адрес клиента, если он использует для работы прокси-сервер. Переменная окружения $_SERVER[‘HTTP_CLIENT_IP’] дает возможность получить IP-адрес клиента, если он не использует прокси-сервер, для работы в Интернете. Переменная окружения $_SERVER[‘HTTP_X_CLUSTER_CLIENT_IP’] дает возможность получить IP-адрес клиента, в случае, если на сайте не используется криптографический протокол SSL, обеспечивающий безопасное соединение между сервером и клиентом. Переменная окружения $_SERVER[‘HTTP_PROXY_USER’] дает возможность определить IP-адрес клиента, который использует в работе прокси-сервер.

    Переменная окружения $_SERVER[‘REMOTE_ADDR’] дает возможность получить IP-адрес удаленного пользователя. Во время тестирования на локальной машине данный IP-адрес будет равен 127.0.0.1. В то же время в сети данная переменная вернет либо IP-адрес клиента, либо IP-адрес последнего используемого пользователем прокси-сервера (при помощи которого данный клиент попал на веб-сервер). Таким образом, используя одновременно множество различных переменных окружения из массива $_SERVER[] (все используемые переменные приведены выше), у нас будет возможность определить реальный IP-адрес пользователя, даже в том случае, если он попытается его «замаскировать» при помощи какого-либо прокси-сервера.

    Для устойчивой работы скрипта на любой из страниц сайта, вне зависимости от ее уровня вложенности, будем использовать возможность приведения к абсолютному виду путей к директориям кэширования (active и block). Использование такого подхода даст нам возможность запускать скрипт с любой страницы сайта и при этом не опасаться того, что изначально указанные в скрипте относительные пути к директориям кэширования на какой-то из страниц окажутся неверными.

    Как уже упоминалось, разрабатываемый скрипт должен иметь возможность настройки. В частности необходимо заранее предусмотреть возможность изменения части параметров скрипта (времени блокировки IP-адреса пользователя, интервала времени, за который будет учитываться количество запросов отправляемых к страницам ресурса, а также количества разрешенных запросов в данный интервал времени). Данные параметры изначально в скрипте будут задаваться при помощи констант.


    В частности, подобными константами в скрипте будут указаны такие пара-метры:
    — время блокировки IP-адреса пользователя указываемое в секундах (const blockSeconds);
    — интервал времени, в который будут учитываться запросы от одного пользователя к страницам сайта. Данный интервал также будет указываться в секундах (const intervalSeconds);
    — количество запросов к страницам веб-сайта, которые сможет отправить один пользователь за заданный временной промежуток (const intervalTimes).
    Отдельно в скрипте следует определить такие массива, содержащие строчные данные:
    — массив значений тех IP-адресов, которые внесены в «список всегда разрешенных IP-адресов» (объявление массива public static $alwaysActive = array(‘’));
    — массив значений тех IP-адресов, которые внесены в «список всегда запрещенных IP-адресов» (объявление массива public static $alwaysBlock = array(‘’)).
    Для правильной работы скрипта, а также для его отладки необходимо предусмотреть наличие в скрипте нескольких флагов. Отметим, что использование подобных флагов также поможет в процессе защиты содержимого сайта от сканирования и различных хаотичных интенсивных запросов. К таким флагам можно отнести:
    — флаг возможности подключения всегда активных пользователей (const isAlwaysActive);
    — флаг возможности подключения всегда заблокированных пользователей (const isAlwaysBlock).
    Разработанный скрипт содержит один класс TBlockIp. Данный класс включает такие методы:
    — checkIp(). Данный метод реализовывает возможность произведения проверки IP-адреса пользователя на его блокировку или же на активность. При этом пропускаются IP-адреса, внесенные в список «всегда разрешенных IP-адресов», а IP-адреса внесенные в список «всегда запрещенных IP-адресов» наоборот блокируются. В случае, если пользовательский IP-адрес не найден в массиве возможных IP-адресов – скрипт создаст идентификатор нового активного IP-адреса;
    — _getIp(). Данный метод дает возможность получить текущий IP-адрес пользователя, выбираемый из всех возможных IP-адресов (фильтрация производиться до выявления нужного IP-адреса клиента). Метод возвращает полученный IP-адрес.

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

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

    2 Листинг программы

    Данный скрипт можно внедрить непосредственно в индексную страницу, либо отдельно в php файле, включив его вызов в самой начале индексного файла.

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

    В это случае нужно создать в корне папку «block», в ней еще папки «active» и «block» и файл «index.php» (сюда копируем выше приведенный код).

    3 Тестирование php-скрипта, внедренного в сайт

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

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

    Опытному пользователю или программисту нередко сложно понять проблемы, которые возникают у неискушенных пользователей. Одним из способов решения проблемы будет найти тестеров, которые и будут представлять действия типовых пользователей. В прошлом использовался следующий подход – сначала на рынок выпускалась бета-версия разработанного Web-приложения. После того, как большинство ошибок, предположительно, было исправлено, данное приложение публиковали для небольшого количества пользователей, которые, соответственно, создадут небольшую интенсивность входящего трафика. После проведения такого рода теста разработчики получают массу различных комбинаций данных и вариантов использования разработанной системы, о которых ее разработчики даже и не догадывались [13, стр. 394].

    Созданный php-скрипт должен делать именно то, для чего, собственно говоря, он и был создан. Применительно к разработанному и созданному в данной работе php-скрипту можно сказать так: если пользователь сможет отправить за определенный промежуток времени (по умолчанию 15 секунд) больше заданного количества запросов (по умолчанию – 3 запроса) к страницам сайта и скрипт не заблокирует его IP-адрес, значит, в работу написанного Web-приложения закралась ошибка. В целом, тестирование представляет собой деятельность, которая направлена на выявление подобного рода несоответствий, существующих между ожидаемым поведением написанного php-скрипта и действительным его поведением. За счет выявления несоответствия в поведении скрипта, а также его некорректного поведения еще во время разработки, у разработчика есть возможность существенно снизить вероятность того, что с такого рода поведением скрипта столкнется и пользователь. Проводить тестирование программы (в нашем случае, написанного php-скрипта) можно как вручную, так и при помощи специализированных онлайнсервисов.

    3.1 Тестирование вручную

    При тестировании написанного php-скрипта вручную, нам необходимо проверить выполняет ли скрипт возложенные на него задачи. В частности, ограничивает ли количество запросов к страницам сайта, исходящим от одного и того же пользователя, в случае, если их частота превышает допустимый предел в определенный промежуток времени. Для проверки работоспособности скрипта нам, прежде всего, необходимо внедрить его в код сайта. Для этого можно воспользоваться такой языковой конструкцией:
    include «block/index.php»;

    При таком включении скрипт должен быть расположен в папке block. Следует учесть, что в случае, если система управления содержимым сайта использует для страниц создание, так называемых Friendly URL, т.е. веб-адресов, которые удобны для восприятия человеком (в данном случае имеется ввиду создание каких-либо многоуровневых структур, например, /news/sport/2003/10/), или же загружает страницы с адресом отличным от корня папки (например, /news/sport.php), возникнет необходимость правильного указания адреса к скрипту. В подобной ситуации вполне может быть указан абсолютный путь к скрипту.

    Само по себе тестирование написанного php-скрипта будет заключаться в отправке запросов к страницам сайта. В процессе тестирования нам нужно проверить: пропускает ли созданный скрипт заданное максимальное количество запросов (по умолчанию – 3 запроса) в определенный промежуток времени (по умолчанию – 15 секунд). Прежде всего, нам необходимо проверить как скрипт справляется со своей основной функцией, т.е. непосредственной блокировкой интенсивных запросов на страницы сайта, исходящих от одного и того же пользователя. Проверка количества запросов, которые могут быть отправлены к страницам сайта, показала, что на протяжении отведенных пятнадцати секунд отправить к страницам сайта более трех запросов нет возможности. В частности, если пользователь отправляет больше трех запросов, то получает сообщение о временной блокировке, приведенное на рисунке:

    Таким образом, тестирование показало, что скрипт работает именно так, как предполагалось: блокирует пользователя на определенное время (по умолчанию – на одну минуту) в случае, если в определенный интервал времени количество запросов от одного пользователя превышает заданный показатель (по умолчанию – 3 запроса). Следующим этапом тестирования будет проверка, работоспособности отдельных функций написанного php-скрипта. В частности, нужно проверить, как будет работать скрипт если IP-адрес тестирующего пользователя будет добавлен в список «всегда разрешенных IP-адресов». Также нужно проверить, как будет вести себя скрипт, если IP-адрес тестирующего пользователя будет добавлен в список «всегда запрещенных IP-адресов».

    Мастер Йода рекомендует:  В Интернет утекли данные 9 млн клиентов «Билайна»

    После добавления IP-адреса тестирующего пользователя в список «всегда разрешенных IP-адресов» ограничение на количество отправляемых к страницам сайта запросов оказалось снятым, и переходить по ссылкам (или обновлять страницу) можно было неограниченное количество раз. Иначе говоря, функция, которую должен выполнять список «всегда разрешенных IP-адресов» правильно работает. После добавления IP-адреса тестирующего пользователя в список «всегда запрещенных IP-адресов» отправить хотя бы один запрос к странице сайта не удалось. Вместо содержимого веб-ресурса в браузере появляется сообщение о блокировке, приведенное на рисунке:

    Другими словами, функция, которую должен выполнять список «всегда запрещенных IP-адресов» работает правильно. Данная функция полностью блокирует пользователя, IP-адрес которого внесен в список «всегда запрещенных IP-адресов». Таким образом, функции разграничения доступа, которые реализованы при помощи наличия списка «всегда разрешенных IP-адресов», а также наличия списка «всегда запрещенных IP-адресов» работают верно и скрипт ведет себя именно так, как изначально предполагалось. Иначе говоря, скрипт предоставляет неограниченный доступ к страницам сайта для тех пользователей, IP-адреса которых внесены в список «всегда разрешенных IP-адресов» и полностью запрещает доступ тем пользователям, чьи IP-адреса обнаруживаются в списке «всегда запрещенных IP-адресов». Тестирование написанного php-скрипта вручную показало, что все функции скрипта, а значит и сам скрипт, работают правильно, т.е. именно так как изначально задумано.

    3.2 Тестирование при помощи онлайн-сервисов

    Тестирование написанного php-скрипта, при помощи онлайнсервисов, даст возможность узнать, точное количество трафика необходимого для загрузки страниц сайта, а также поможет точно установить «пропускную способность» написанного php-скрипта для запросов, которые будут отправляться различными автоматическими сервисами или же программами. Последний параметр очень важен, ведь одной из задач скрипта является защита сайта от сканирования при помощи программ-краулеров. Такого рода тестирование не только поможет сделать вывод об необходимом количестве трафика и процессорного времени, но и о том, доступна ли будет информация представленная на сайте для программных средств, запрашивающих страницы в автоматическом режиме. Для начала оценим среднее время загрузки страниц сайта, при разных скоростях соединения. Также оценим и размер загружаемых пользователем страниц. Для проведения такого рода тестирования воспользуемся онлайн-сервисом, расположенным по адресу analyze.websiteoptimization.com. Размеры загружаемых страниц, определенные сервисом, приведены на рисунке:

    С учетом того, что тестируемый нами сайт состоит лишь из одной страницы, размер которой составляет 1511 байт, она загрузиться за 0,51 секунды (при скорости соединения 56 К) или за 0,21 секунды (при скорости соединения пользователя 1,44 Mbps). Скорость загрузки страниц при разной скорости соединения пользователя приведена на рисунке:

    Как видно из приведенной на рисунке информации, даже при самой низкой скорости соединения (14,4 К) страница сайта грузится довольно быстро – за 1,4 секунды. В то же время, если скорость соединения пользователя довольно высока (в частности, 1,44 Mbps), то страница будет загружена буквально моментально (за 0,21 секунды). Отметим, что низкая скорость загрузки на данном ресурсе корректируется на коэффициент потери пакетов (этот коэффициент равен 0,7). Также учитывается и время задержки равное в среднем 0,2 секунды на загрузку одной страницы. Именно эти параметры и объясняют, почему существенный рост скорости соединения не приводит к столь же существенному сокращению времени загрузки страницы. Отметим, что данный сервис кроме оценки основных параметров загрузки страниц сайта также предоставляет общие результаты анализа сайта и, конечно же, рекомендации направленные на улучшение всех параметров загрузки страниц сайта. Результаты анализа и рекомендации сервиса приведены на рисунке:

    Как видно из рисунка, все показатели тестируемого сайта по всем анализируемым параметрам находятся в пределах нормы. В частности, сервис констатирует, что количество страниц сайта, объектов на них, а также размеры этих страниц и объектов находятся в допустимых пределах. Исходя из полученных данных оптимизация тестируемому сайту не требуется, ведь сайт соответствует нормам по всем анализируемым параметрам. Иначе говоря, объемы загружаемой с сайта информации (или страниц сайта) довольно малы и позволяют экономить ресурсы как веб-сервера, так и пользователя. Т.е. разработанный скрипт не нагружает сайт и, фактически, его присутствие не заметно. Что подчеркивает проведенное тестирование. Проверку скорости загрузки страниц сайта, а также их доступности для других скриптов можно выполнить при помощи такого онлайн-сервиса как www.pr-cy.ru. Результат теста, сделанного при помощи данного онлайн-сервиса, приведен на рисунке:

    Как видно, из полученных данных при средней скорости загрузки 30,31 Кб/сек, время загрузки страницы составляет 0,05 секунды. В то же время при средней скорости 37,89 Кб/сек, время загрузки страницы составляет уже 0,04 секунды. В то же время, тестирование показало, что разработанный в данной работе скрипт блокирует больше трех запросов к страницам сайта, исходящих от одного IP-адреса и тем самым снижает излишнюю нагрузку и весьма усложняет попытки или вовсе делает невозможным подбор пароля к сайту.

    3.3 Результаты тестирования php-скрипта, внедренного в сайт

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


    Тестирование сайта, в который внедрен разработанный php-скрипт, показало, что все показатели тестируемого сайта по всем анализируемым параметрам находятся в пределах нормы. В частности, сервис констатирует, что количество страниц сайта, объектов на них, а также размеры этих страниц и объектов находятся в допустимых пределах. Исходя из полученных данных оптимизация тестируемому сайту не требуется, ведь сайт соответствует нормам по всем анализируемым параметрам. Иначе говоря, объемы загружаемой с сайта информации (или страниц сайта) довольно малы и позволяют экономить ресурсы как веб-сервера, так и пользователя. Ранее скрипт использовался на сайтах по изучению английского языка и английских слов, но позднее были предприняты более серьезные меры защиты. Однако, на первых порах, данный скрипт существенно снижал нагрузку на недорогой хостинг и позволял крутить сайты с посещаемостью 5000+ хостов в сутки.

    Кроме того, тестирование сайта показало, что скорость загрузки страниц тестируемого сайта довольно высока. Также, скрипт заблокировал проведение тестирования сайта, когда количество запросов отправленных с IP-адреса данного онлайн-сервиса превысило допустимый в разработанном скрипте предел (максимальное количество запросов с одного IP-адреса, установленное в скрипте, равно трем запросам за 15 секунд).

    Другими словами, защита сайта от сканирования и хаотичных интенсивных запросов работает именно так, как и предусматривалось изначально. Другими словами, если количество запросов, исходящих с одного IP-адреса (в случае, если IP-адрес пользователя не находится в списке «всегда разрешенных IP-адресов» или же в списке «всегда запрещенных IP-адресов»), превышает допустимый лимит в определенный интервал времени, то IP-адрес пользователя будет временно заблокирован вне зависимости от того, отправлялись запросы при помощи браузера, программы и использовался ли при отправке запросов прокси-сервер (для маскировки реального IP-адреса пользователя).

    PHP «Блокировка файлов»

    Добрый день, форумчане. Не могу разобраться самостоятельно, пожалуйста объясните дубу.

    «Реализовать два скрипта, пишущих в файл, используя блокировку.
    а)Написать первый скрипт, который записывает в файл в цикле числа от 1 до 10. В каждой итерации поставить sleep(1).
    б)Написать второй скрипт, который записывает в файл в цикле числа от 11 до 20. И снова в каждой итерации поставить sleep(1).
    в)Блокировку ставить не надо!
    г)Запустить первый скрипт и через 2-3 секунды второй.
    д)Посмотреть содержимое файла.
    е)Поставить блокировку.
    ж)Снова запустить первый скрипт, а через 2-3 секунды второй.
    з)Посмотреть содержимое файла и сделать вывод.»

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

    20.03.2020, 10:11

    Тысячные числа исправлять к примеру с «1200» на «1 200», «12000» на «12 000» и т.д
    Собственно числа исправлять к примеру с «1200» на «1 200», «12000» на «12 000», «120000» на.

    Вопрос по locking, php, mysql &#8211 Блокировка таблицы MySQL с помощью PHP

    Проблема в том, что если я запускаю второй скрипт во время работы первого скрипта. Таблицаis not заперта. И я могу читать любые данные из него.

    Мне нужно, чтобы он был заблокирован и вернул ошибку.

    Как заставить это работать?

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

    Это может не помочь ответить на ваш вопрос, но вы должны прекратить использование mysql_* функции. Они устарели. Вместо этого используйтеPDO (поддерживается начиная с PHP 5.1) илиmysqli (поддерживается начиная с PHP 4.1). Если вы не уверены, какой из них использовать,read this article.

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

    какой смысл его блокировать для конкретного подключения mysql? Почему мой сценарий хочет вставить что-то, когда я ничего не вставляю?

    У вас неправильное представление о том, что делают замки. Блокировки не препятствуют доступу данных к другим скриптам, вместо этого блокировки влияют на время, когда другие скрипты будут обращаться к данным. Когда сценарий 2 пытается получить доступ или изменить данные, которые ему не разрешены из-за блокировки, он приостановит работу и будет ждать снятия блокировки. После того, как сценарий 1 разблокирует таблицу, сценарий 2 продолжится и завершится без проблем.

    Если вы не хотите, чтобы другие имели доступ к этой таблице, используйте

    Другой сценарий не вернет ошибку, но будет ожидать снятия блокировки.

    Я попробовал это. Все еще ничего не блокирует. Второй скрипт может легко получить доступ к данным.

    Кажется, что из вашего первого сценария сначала вы устанавливаете блокировку записи на test1, затем выполняете запрос, затем спите в течение 20 секунд, а затем разблокируете таблицу. Пока вы не разблокируете, второй скрипт ожидает разблокировки таблицы. Как только таблица разблокируется, запрос во втором скрипте получает доступ к таблице и возвращает данные. Попробуйте увеличить время сна до 100 или, скажем, 200, а затем проверьте результаты.

    Вы должны предоставить права на блокировку таблиц пользователю БД.

    Вы read блокировка стола $query_ = «lock tables test1 as test11 read»; — это означает, что другие запросы все еще могут читать его без каких-либо проблем (релевантноссылка на сайт — прокрутите вниз до раздела типов блокировки):

    Информация о read тип замка:

    • The session that holds the lock can read the table (but not write it).
    • Multiple sessions can acquire a READ lock for the table at the same time.
    • Other sessions can read the table without explicitly acquiring a READ lock.

    Если вы хотите остановитьсяanything еще столько, сколько нужно перечитать таблицу, вам нужно использовать write заблокировать следующим образом:

    @ pain.reign Блокировки для таблиц зависят от сеанса, это произвольный вопрос (что здорово) или вы пытаетесь эмулировать транзакцию для таблиц, которые вы блокируете?

    @ still_dreaming_1 Блокировка чтения предотвратит запись любого сеанса в таблицу, пока блокировка установлена, хотя другие сеансы могут также захватить блокировку чтения одновременно. Сеанс сохраняется на месте со времени, когда исполняющее приложение устанавливает соединение, до момента, когда соединение разрывается (либо в коде, либо когда код завершает выполнение).

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

    Я изменяю модификатор на «написать» еще второй скрипт возвращает все записи.

    Я не понимаю вашего вопроса. Но я попытался сделать все запросы в одной транзакции для одного сценария и без транзакции. Все еще не работает. $ query_ = & quot; начать транзакцию & quot ;; mysql_query ($ query_); $ query_ = & quot; заблокировать таблицы test1 как test11 write & quot ;; mysql_query ($ запроса); $ query_ = & quot; выберите * из test11 & quot ;; сна (20); $ query_ = & quot; разблокировать таблицы & quot ;; mysql_query ($ query_); mysql_query (& Quot; совершают & Quot;);

    Добавить комментарий