Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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