Я прочитал fcgi spe c, но все еще не могу понять, как работает связь между:
web-Server <-> FCGI-Server <-> Application
. Спецификация FastCGI гласит, что «веб-сервер» оставляет файл-дескриптор FCGI_LISTENSOCK_FILENO (0), который можно использовать для чтения пакетов fcgi. Но как это должно работать, если сервер FCGI находится на сервере, отличном от веб-сервера? Для меня это звучит так, как будто в спецификации предполагается, что процесс FCGI размещен в той же системе, что и веб-сервер, или путает веб-сервер с fcgi-сервером.
Это мое текущее понимание fcgi -livecycle:
- Веб-сервер получает HTTP-запрос и запускает fcgi-запрос к предварительно сконфигурированному сокету / сетевому адресу, скажем:
192.168.20.2:9090. - FastCGI-приложение / Сервер прослушивает порт 9090 на предмет входящих запросов и принимает соединения. Нет
FCGI_LISTENSOCK_FILENO, как указано в спецификации, и нет файлового дескриптора / сокета, созданного веб-сервером. Сервер fcgi делает это без какого-либо существующего сокета. Он отвечает за мультиплексирование входных / выходных данных. - Если на самом FCGI-сервере не реализовано приложение, сервер, выступающий в качестве ответчика, запускает новый процесс с помощью stdin, stdout, передаваемого в FastCGI. сервер. Если CGI-приложение записывает что-то в стандартный вывод, процесс FastCGI инкапсулирует данные в fcgi-пакеты.
Как реально работает жизненный цикл? Какие стороны участвуют? Где FCGI_LISTENSOCK_FILENO входит в игру? Почему в спецификации говорится, что веб-сервер оставляет сокет / fd, для которого приложение должно вызвать Accept (). Для меня это абсолютно бессмысленно, потому что, если веб-сервер создает прослушивающий сокет, другой конец должен вызвать connect, чтобы установить sh соединение, но обычно веб-сервер отвечает за установление FCGI-соединения. Сервер FCGI (/ Application) отвечает на запрос соединения только с помощью вызова Accept ().