Блог

Я нахожусь в процессе реализации приложения fastcgi, после прочтения спецификации FastCGI я нашел функцию под названием «мультиплексирование запросов». Это напомнило мне мультиплексирование Adobe RTMP в те дни, когда протокол был проприетарным и закрытым.

Насколько я понимаю, мультиплексирование позволяет сократить накладные расходы на создание новых подключений к клиентам FCGI, эффективно переплетая блоки запросов и в то же время позволяя подключать модель «keep-alive» к соединению. Последнее позволяет отправлять несколько запросов по одному соединению.

Первый вопрос: правильно ли я понял?

Следующий — после некоторого поиска в Google я обнаружил, что нет сервера, который реализует мультиплексирование FCGI, в первую очередь меня интересовали «популярные» серверы, я имею в виду nginx и lighttpd. Я даже нашел некоторое обсуждение устаревания мультиплексирования запросов FCGI.

Итак, вопрос в том, есть ли какой-либо сервер, который поддерживает эту функцию?

Вопрос: мультиплексирование позволяет сократить накладные расходы на создание новых подключений к клиентам FCGI, эффективно переплетая блоки запросов

Ответ: Верно. Но сохранение работоспособности также сокращает количество новых подключений.

Вопрос: и в то же время включить модель «keep-alive» для подключения

Ответ: мультиплексирование не требуется для поддержания работоспособности.

В: Последнее позволяет отправлять несколько запросов по одному соединению

Ответ: функция keep-alive позволяет выполнять несколько запросов друг за другом. Мультиплексирование позволяет выполнять несколько запросов параллельно.

Не существует широко используемого веб-сервера с поддержкой FastCGI, поддерживающего мультиплексирование. Но nginx поддерживает поддержку FastCGI.

Мультиплексирование FastCGI, как правило, является плохой идеей, потому что FastCGI не поддерживает управление потоком. Это означает: если серверная часть FastCGI отправляет данные, но http-клиент не может получить данные достаточно быстро, веб-сервер должен сохранять все эти данные, пока они не будут отправлены клиенту.

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

Пытаюсь более точно сформулировать приведенные выше ответы (и исправить некоторые части)…

мультиплексирование позволяет сократить накладные расходы на создание новых подключений к клиентам FCGI, эффективно переплетая блоки запросов

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

и в то же время включение модели «keep-alive» для подключения

Хотя мультиплексирование не требуется для поддержания работоспособности, но для мультиплексирования практически требуется сохранение работоспособности (в противном случае это имело бы мало смысла).

Я обнаружил, что нет сервера, который реализует мультиплексирование FCGI

Существует несколько серверов, которые поддерживают мультиплексирование из коробки, но…
Я уже видел несколько модулей других разработчиков, и у меня есть собственный fcgi-модуль для nginx (в качестве замены), который поддерживает запросы мультиплексирования FastCGI. Это может показать реальное увеличение производительности на практике, особенно если восходящие потоки подключены по сети. Если кому-то это нужно, я постараюсь найти время и сделать его доступным на github и т. Д.

[из ответа выше] Мультиплексирование FastCGI, как правило, является плохой идеей, потому что FastCGI не поддерживает управление потоком. Это означает: если серверная часть FastCGI отправляет данные, но http-клиент не может получить данные достаточно быстро, веб-сервер должен сохранять все эти данные, пока они не будут отправлены клиенту.

Это неправда. Обычно обработчики FastCGI полностью асинхронны, пул рабочих отделен от доставляющих рабочих и т. Д. Таким образом, каждый фрагмент получает идентификатор запроса, поэтому, если два или более вышестоящих рабочих записывают в одно соединение одновременно, фрагменты, которые получит nginx, будут просто меньше. Это единственный минус. Что касается «веб-сервер должен сохранять все эти данные», он делает это в любом случае (независимо от используемого мультиплексирования или нет), потому что в противном случае может возникнуть ситуация нехватки памяти, если слишком много ожидающих ответа данных доступно для ответа. Таким образом, либо серверная часть должна выдавать меньше данных (или быть заблокирована), либо веб-сервер должен получить их как можно скорее и передать клиенту или сохранить в каком-либо промежуточном хранилище (и, например, nginx делает это, если ожидающий размер данных превышает значения, настроенные с помощью директив fastcgi_buffer_size и fastcgi_buffers).

[из ответа выше] При использовании мультиплексирования веб-серверу необходимо считывать все данные из серверной части fastcgi, даже если один из клиентов получает данные недостаточно быстро.

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

Я не знаю, реализует ли какой-либо сервер мультиплексирование FASTCGI (которое, я полагаю, вы правильно поняли, но подробности указаны в спецификациях протокола FASTCTI), и я бы не стал беспокоиться.

Вы, скорее всего, будете использовать FASTCGI через существующую библиотеку FASTCGI (например, Ocamlnet, если вы кодируете на Ocaml и т.д.). И эта библиотека будет выполнять мультиплексирование, если она это сделает. С вашей точки зрения (этого пользователя библиотеки) вам должно быть все равно, если вы сами не кодируете такую библиотеку.

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