Прокси управляет конфигурацией исходных серверов и их параметров связи в объектах, называемых рабочими . Есть два встроенных воркера: прямой прокси-воркер по умолчанию и обратный прокси-воркер по умолчанию. Дополнительные рабочие могут быть настроены явно.

Два рабочих процесса по умолчанию имеют фиксированную конфигурацию и будут использоваться, если ни один другой рабочий процесс не соответствует запросу. Они не используют HTTP Keep-Alive или повторное использование соединения. Вместо этого TCP-соединения с исходным сервером будут открываться и закрываться для каждого запроса.

Явно настроенные рабочие процессы идентифицируются по их URL. Обычно они создаются и настраиваются с использованием ProxyPass или ProxyPassMatch при использовании обратного прокси:

ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30

Это создаст работника, связанного с URL-адресом исходного сервера http://backend.example.com , который будет использовать заданные значения тайм-аута. При использовании в прямом прокси-сервере рабочие обычно определяются с помощью ProxySet директивы:

ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30

или, альтернативно, используя Proxy и ProxySet :

<Proxy "http://backend.example.com">
 ProxySet connectiontimeout=5 timeout=30
</Proxy>

Использование явно настроенных воркеров в режиме переадресации не очень распространено, поскольку прокси-серверы пересылки обычно взаимодействуют со многими разными исходными серверами. Создание явных рабочих процессов для некоторых исходных серверов может быть полезным, если они используются очень часто. Явно настроенные рабочие процессы сами по себе не имеют понятия прямого или обратного проксирования. Они инкапсулируют общую концепцию связи с исходными серверами. Рабочий процесс, созданный ProxyPass для использования в обратном прокси-сервере, также будет использоваться для запросов прямого прокси-сервера всякий раз, когда URL-адрес исходного сервера совпадает с URL-адресом рабочего, и наоборот.

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

ProxyPass "/examples" "http://backend.example.com/examples"
ProxyPass "/docs" "http://backend.example.com/docs"

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

Обмен работниками

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

ProxyPass "/apps" "http://backend.example.com/" timeout=60
ProxyPass "/examples" "http://backend.example.com/examples" timeout=10

второй рабочий фактически не создается. Вместо этого используется первый рабочий. Преимущество в том, что существует только один пул соединений, поэтому соединения чаще используются повторно. Обратите внимание, что все атрибуты конфигурации, заданные явно для более позднего рабочего процесса, будут игнорироваться. Это будет зарегистрировано как предупреждение. В приведенном выше примере результирующее значение времени ожидания для URL-адреса /examples будет 60 вместо 10 !

Если вы хотите избежать совместного использования рабочих процессов, отсортируйте определения рабочих операций по длине URL-адресов, начиная с самых длинных URL-адресов рабочих операций. Если вы хотите максимизировать совместное использование работников, используйте обратный порядок сортировки. См. также соответствующее предупреждение о ProxyPass директивах заказа.

Явно настроенные воркеры бывают двух видов: прямые воркеры и воркеры (балансировщики нагрузки) . Они поддерживают множество важных атрибутов конфигурации, которые описаны ниже в ProxyPass директиве. Те же атрибуты можно также установить с помощью ProxySet .

Набор параметров, доступных для прямого работника, зависит от протокола, который указан в URL-адресе исходного сервера. Доступные протоколы включают ajp , fcgi , и . ftp http scgi

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

Рабочий балансировщик создается, если его рабочий URL используется balancer в качестве схемы протокола. URL-адрес балансировщика однозначно идентифицирует работника балансировщика. Участники добавляются в балансировщик с помощью BalancerMember .

Разрешение DNS для исходных доменов

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