Как веб-сервер обрабатывает запросы?
Я использую php и laravel в качестве своего веб-сервиса.
Я хочу знать, хранит ли Laravel и обрабатывает ли запросы в этой ситуации?
- запросы к разным контроллерам от многих пользователей;
- запросы к тому же контроллеру от того же пользователя.
Хранит ли laravel эти запросы в очереди в той последовательности, в которой они были получены?
Является ли Laravel параллельным процессом запросов для разных пользователей и последовательно для одного и того же пользователя?
Например, есть два запроса от пользователя. Два запроса направляются к двум методам в одном контроллере. В то время как первый запрос будет долго обрабатываться на стороне сервера, второй будет стоить совсем немного времени. Когда пользователь устанавливает первый запрос, а затем второй, хотя второй стоит очень мало времени, серверная сторона не будет обрабатывать второй запрос, пока не завершит обработку первого.
Итак, я хочу знать, как laravel хранит и обрабатывает запросы?
Решение
Laravel не обрабатывает запросы напрямую, этим управляет ваш веб-сервер и PHP. Laravel получает запрос, уже обработанный вашим веб-сервером, потому что это всего лишь инструмент, написанный на PHP, который обрабатывает данные, относящиеся к вызову запроса. Таким образом, если ваш веб-сервер знает, как выполнять PHP и вызывает соответствующий файл index.php, Laravel будет загружен и обработает данные запроса, полученные от веб-сервера.
Итак, если ваш веб-сервер может принимать 2 разных вызова (обычно они делают это сотнями), он попытается создать 2 PHP (под) процесса, и у вас должно быть 2 экземпляра Laravel в памяти, работающих параллельно.
Поэтому, если у вас есть код, который зависит от другого кода, выполнение которого может занять слишком много времени в зависимости от многих других факторов, вам придется справиться с этим самостоятельно, в своем приложении Laravel.
Обычно мы просто добавляем данные в базу данных, а затем получаем результат из расчета, выполненного с данными, уже находящимися в хранилище данных. Поэтому не должно иметь значения порядок, в котором данные попадают в хранилище данных, которое было получено первым, конечный результат всегда одинаков. Если вы не можете полагаться на такую методологию, вам придется подготовить свое приложение к ней.
Другие решения
Все в PHP начинается как отдельный процесс. Эти процессы независимы друг от друга, пока какой-то общий ресурс не появится в Picture.
В вашем случае один пользователь обрабатывает один сеанс, а сеансы являются файловыми по умолчанию. Файл сеанса является общим ресурсом для процессов, что означает, что вы можете сделать только один вызов PHP за один раз для одного пользователя.
Несколько пользователей могут вызывать любое количество процессов одновременно в зависимости от возможностей вашей системы.
Web сервер php запросы нет
Веб-сервер предназначен для помощи в разработке приложений. Он также может быть полезным в тестовых целях или для демонстрации приложения, запускаемого в полностью контролируемом окружении. Он не выполняет функции полноценного веб-сервера и не должен использоваться в общедоступных сетях.
Модуль CLI SAPI содержит встроенный веб-сервер.
Веб-сервер выполняет только один однопоточный процесс, поэтому приложения PHP будут останавливаться, если запрос заблокирован.
URI запросы обслуживаются из текущей директории, в которой был запущен PHP, если не используется опция -t для явного указания корневого документа. Если URI запроса не указывает на определённый файл, то будет возвращён index.php или index.html в указанной директории. Если ни один из файлов не существует, то поиск этих файлов будет продолжен в родительской директории и так далее до тех пор, пока они не будут найдены или был достигнут корень документа. Если найден index.php или index.html, он возвращается, а в $_SERVER[‘PATH_INFO’] будет находится последняя часть URL. В противном случае возвращается 404 код ответа.
Если PHP-файл указывается в командной строке, когда запускается веб-сервер, то он рассматривается как скрипт «маршрутизации» (router). Скрипт выполняется в самом начале каждого HTTP-запроса. Если этот скрипт возвращает false , то запрашиваемый ресурс возвращается как есть. В противном случае браузеру будет возвращён вывод этого скрипта.
Стандартные MIME-типы возвращаются для файлов со следующими расширениями: .3gp, .apk, .avi, .bmp, .css, .csv, .doc, .docx, .flac, .gif, .gz, .gzip, .htm, .html, .ics, .jpe, .jpeg, .jpg, .js, .kml, .kmz, .m4a, .mov, .mp3, .mp4, .mpeg, .mpg, .odp, .ods, .odt, .oga, .ogg, .ogv, .pdf, .pdf, .png, .pps, .pptx, .qt, .svg, .swf, .tar, .text, .tif, .txt, .wav, .webm, .wmv, .xls, .xlsx, .xml, .xsl, .xsd и .zip.
| Версия | Описание |
|---|---|
| 5.5.12 | .xml, .xsl, и .xsd |
| 5.5.7 | .3gp, .apk, .avi, .bmp, .csv, .doc, .docx, .flac, .gz, .gzip, .ics, .kml, .kmz, .m4a, .mp3, .mp4, .mpg, .mpeg, .mov, .odp, .ods, .odt, .oga, .pdf, .pptx, .pps, .qt, .swf, .tar, .text, .tif, .wav, .wmv, .xls, .xlsx и .zip |
| 5.5.5 | |
| 5.4.11 | .ogg, .ogv, и .webm |
| 5.4.4 | .htm и .svg |
| Версия | Описание |
|---|---|
| 7.4.0 | Вы можете настроить встроенный веб-сервер так, чтобы он выполнял разветвление нескольких воркеров для проверки кода, который требует нескольких одновременных запросов к встроенному веб-серверу. Задайте в переменной окружения PHP_CLI_SERVER_WORKERS количество требуемых воркеров перед запуском сервера. Не поддерживается в Windows. Эта экспериментальная функция не предназначена для продакшен использования. Обычно встроенный веб-сервер не предназначен для продакшен использования. Пример #1 Запуск веб-сервера $ cd ~/public_html $ php -S localhost:8000 Работа с Веб-сокетами на PHPPHP — едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов. Практически каждая статья в интернете будет пестрить предложениями использовать для этого NodeJS, Python или Go. Но поскольку PHP — это однозначно первое, что приходит в голову, когда речь идет о веб-приложениях, почему бы не попробовать? На самом деле, запуск сервера веб-сокетов на PHP довольно прост. Существует превосходная библиотека Ratchet, позволяющая работать на любом фреймворке (или вовсе без него) полноценно и легко. Казалось бы, на этом разговор можно заканчивать, но мы неизбежно столкнемся с некоторыми ограничениями и проблемами, связанными с архитектурой конечного приложения и природой самого протокола веб-сокетов. АвторизацияПо умолчанию, сервер веб-сокетов открыт для любого подключения. Конечно, можно поставить сетевые ограничения по доменам или IP адресам, но для веб-приложения — это, мягко говоря, не эффективный подход. В обычной ситуации мы используем для таких ограничений тот или иной вариант сервиса авторизации — токены, сессии и т.д. Здесь же проблема в том, что мы не сможем отправить через протокол ws:// ни HTTP заголовок, ни cookies. Значительная часть привычных методов, таким образом, не сработает. АрхитектураОсновное приложение != сервер веб-сокетов. Для работы с ними всегда необходимо держать в голове, что мы имеем дело с двумя отдельными приложениями, вне зависимости от того, насколько тесно они взаимодействуют между собой. На первый взгляд это может показаться незначительным нюансом, однако такое положение вещей требует особого внимания к подготовке интерфейсов для интеграции основного приложения и сервера веб-сокетов. Ко всему прочему, это порождает еще одну проблему. База данныхПоскольку сервер веб-сокетов — это отдельное от основного бэкенда приложение, он ничего не знает о существующей базе данных. Сложно представить себе современное приложение на PHP, написанное без использование какого-либо фреймворка и ORM, так что перед разработчиком встанет дополнительная задача интегрировать службы, сервисы и библиотеки для работы с БД в сторонний скрипт. РешенияДля каждой из названных проблем вполне возможно отыскать соответствующее решение. Некоторые из потенциальных решений могут показаться шероховатыми, но главное, что они рабочие. Авторизуем пользователейВ процессе подключения к серверу веб-сокетов существует этап, на котором исходный HTTP запрос преобразуется в WS запрос. Используемая нами библиотека Ratchet сохраняет этот начальный запрос в объекте Connection. Хотя возможности подцепить Bearer заголовок к запросу нет (для клиентского приложения запрос строится сразу как ws://websocket-server), мы можем передать токен (например, JWT) в параметрах запроса. При использовании HTTPS — это вполне безопасный способ передачи. В итоге, запрос на подключение может выглядеть примерно так: Строку параметров затем можно извлечь из упомянутого ранее объекта Connection. После извлечения токен может использоваться в любом уже применяющемся механизме авторизации, реализованном в основном приложении. Интегрируем базу данныхВ 9 из 10 случаев основное приложение будет написано на одном из популярных фреймворков вроде Laravel или Symfony. Все, что нам необходимо реализовать в такой ситуации — внедрение службы, отвечающей за ORM, в конструктор сервера веб-сокетов. При условии, что для запуска сервера используется консольная команда, использующая компонент Symfony Console, мы можем сделать это в два этапа: первоначальной инъекцией в конструктор консольной команды, а оттуда передачей в конструктор основного класса веб-сокетов. Разделяем приложенияРаз уж мы вынуждены расценивать основное приложение и сервер веб-сокетов как два отдельных компонента, ничто не мешает нам использовать API основного приложения внутри сервера веб-сокетов. Пожалуй, самый распространенный сценарий — сохранение сообщений в БД и последующая отдача их фронтенд-приложению. В целом, после внедрения ORM в обработчик веб-сокетов, мы могли бы выполнять все это с помощью обычных CRUD-операций. Но гораздо более эффективным решением было бы использовать уже готовый API. Почему? Во-первых, это позволит избежать дублирования кода (ровно такие же CRUDы используются в контроллерах, отвечающих за API). Во-вторых, таким способом мы укладываемся в общую архитектуру разделенных компонентов, даже внутри монолитного решения. Более того, имея одновременно токен из исходного запроса и внедренный ORM, мы получаем возможность авторизовывать действия и валидировать данные при абсолютно каждом событии веб-сокетов, а это уже полноценная имперсонификация пользователя. ВыводыPHP все еще может быть не первым вариантом для работы с веб-сокетами, но на нем все еще вполне возможен запуск и эксплуатация полноценного сервера веб-сокетов со всеми необходимыми соображениями безопасностями и прозрачной архитектуры. |