#java #web-applications #tomcat #application-server
#java #веб-приложения #tomcat #приложение-сервер
Вопрос:
Цитирую спецификацию Java Servlet API: «Клиент (например, веб-браузер) обращается к веб-серверу и выполняет HTTP-запрос.Этот запрос принимается веб-сервером и передается в контейнер сервлета. «
Может кто-нибудь уточнить, как именно передается этот элемент управления (с веб-сервера в контейнер сервлета)?Использует ли он какие-либо HTTP-соединители, такие как Apache Coyote?
Ответ №1:
Детали реализации зависят от межсерверного взаимодействия. Архитектура Http Connector — это то, что используется Apache Tomcat внутри. Веб-сервер — это не что иное, как приложение Java, которое открывает сокет на порту и продолжает прослушивать этот порт по протоколу HTTP некоторые другие средства. Эти некоторые другие средства состоят из таких вещей, как управление жизненным циклом компонентов и т.д. Основная задача веб-сервера — прослушивать запросы по номеру порта по протоколу http, а затем отвечать на них. Итак, на большинстве распространенных доступных сегодня серверов они продолжают опрашивать порт 80 по протоколу http. Когда вы отправляете некоторый http-запрос на порт 80 на хост, на котором прослушивается программа, программа прослушивания отвечает на это. Теперь при получении запроса серверная программа (которая прослушивает здесь порт 80) получит новый поток из своего пула потоков и в этом потоке вызовет сервисный метод сервлета (экземпляр сервлета будет создан, если его первый запрос см. Здесь Для более подробной информации).
ДОБАВЛЕНИЕ:
Веб-сервер — это машина, на которой запущена служба HTTPD. Когда вы отправляете запрос на сервер, сервер перехватывает его.Веб-сервер отвечает за получение запроса и генерацию ответа. Теперь сервер получает входной поток в сокет, в котором он прослушивал. Отсюда он делегирует входные данные в контейнер сервлета, помещая его в новый поток (чтобы все обрабатывалось асинхронно, а веб-сервер мог обрабатывать другие http-запросы, когда предыдущий запрос обслуживается сервлетом в отдельном потоке). Контейнер сервлета является частью веб-сервера. Контейнер сервлета — это отдельный модуль; он может выполняться на веб-сервере как отдельная автономная программа (tomcat — один из примеров). Теперь контейнер сервлета создает экземпляр нового сервлета, если он еще не существует, и вызывает его метод обслуживания в новом дочернем потоке. Контейнер сервлета обертывает http-запрос в объект HttpRequest и передает его в одном из параметров методу service.
Комментарии:
1. Вопрос в том, как элемент управления передается с веб-сервера в контейнер сервлета. «Теперь при получении запроса серверная программа (которая прослушивает здесь порт 80) получит новый поток из своего пула потоков и в этом потоке вызовет сервисный метод сервлета». Я знаю, но вопрос в том, КАК эта программа получит управление, чтобы она могла запустить свой поток.
2. Пожалуйста, посмотрите редактирование и дайте мне знать, если вам нужны дополнительные пояснения. Спасибо!
3. что делать, если контейнер сервлета и веб-сервер работают в разных JVM
4. В этом случае веб-сервер и JVM контейнера сервлета обмениваются данными, используя некоторый механизм IPC (обычно сокеты TCP / IP).
5. Спасибо.. Вы уверены, что это так, как это реализовано? Почему не RMI, WS, JMX или другие?
Ответ №2:
Например, если вы используете архитектуру apache tomcat, существует протокол для соединителей (AJP). Взгляните на mod_jk и mod_proxy.
Когда оба компонента (веб-сервер и контейнер) находятся в одном программном обеспечении (tomcat может управлять прямыми HTTP-запросами), я не знаю о внутренней реализации. (На самом деле это никогда не было полезно для меня. Напротив, обычно используются соединители AJP)