почему Tomcat ajp, соединение по умолчанию включило

Конфигурация сервера Tomcat (server.xml) имеет коннектор AJP, включенный по умолчанию. И таким образом, кот по умолчанию слушает в порте 8009.

Почему это по умолчанию включено?
Я думал, что будет только немного людей, которые используют Apache, как инвертирует прокси, или мы должны всегда использовать Apache в качестве фронтенда (веб-сервер) и держать кота только для страниц JSP и сервлетов?

3
задан 31 January 2015 в 05:03
1 ответ

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

Не стесняйтесь комментировать коннектор, если вы не собираетесь его использовать, и не чувствуете себя обязанным измените свою производственную среду, чтобы использовать AJP, если все работает нормально. Я do , кажется, вспоминаю несколько менее очевидных головных болей конфигурации с httpd, с которыми можно столкнуться при проксировании AJP вместо HTTP. К сожалению, прошло несколько лет с тех пор, как я последний раз был администратором Tomcat, поэтому я не могу ничего сказать.

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

  • Производительность. Программное обеспечение выделенного веб-сервера обычно намного лучше оптимизировано для доставки статического содержимого из файловой системы. Их реализации многозадачности почти полностью посвящены этому. Возможно, вам это не покажется большой экономией, но когда вы начинаете обрабатывать тысячи запросов в секунду, эти накладные расходы имеют значение.
  • Меньше состояния, за которым нужно следить. Серверы веб-приложений обременены гораздо большим количеством того, что им необходимо отслеживать в своей памяти. Объем памяти на запрос обычно намного меньше для выделенного веб-сервера, и это состояние в основном является одноразовым: дочерние процессы часто повторно используются, когда они завершают обслуживание запроса. Также не имеет смысла выполнять код, ориентированный на соединение, каждый раз, когда приложению необходимо обслуживать файл. (случается неаккуратный код, намеренно или непреднамеренно)
  • Изоляция процесса. Это гораздо важнее, чем думает большинство людей. Если ваш контейнер webapp работает со сбоями (обычно у Java заканчивается куча), степень вашей поломки уменьшается. Это особенно важно, если ваш бизнес не удосужился профинансировать хороший набор балансировщиков нагрузки, которые автоматически извлекают неисправные веб-приложения из пула служб.

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

1
ответ дан 3 December 2019 в 07:27

Теги

Похожие вопросы