Web Server
-
웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공
-
HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 하는 기능을 담당
-
동적인 컨텐츠 제공을 위한 요청 전달
-
클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)
(클라이언트는 일반적으로 웹 브라우저를 의미)
WAS
-
DB조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어짐.
-
WAS = Web Server + Web Container
-
Web Server 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
-
분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
-
주로 DB 서버와 같이 수행된다.
(현재는 WAS가 가지고 있는 Web Server도 정적인 컨텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.)
Web Server를 사용하는 이유
Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.
따라서 Web Server에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.
WAS를 사용하는 이유
웹 서비스를 제공할때 사용자의 요청에 맞는 컨텐츠를 그때 그때 상황에 맞게 동적인 컨텐츠를 제공해야 한다.
이때, Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어 놓고 서비스를 해야 하는데
이렇게 하기도 힘들뿐더러 자원 또한 절대적으로 부족하다.
따라서 WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써
자원을 효율적으로 사용해야한다.
Web Server와 WAS를 같이 사용하는 이유
-
기능을 분리하여 서버 부하 방지
-
물리적으로 문리하여 보안강화
-
여러대의 WAS를 연결가능
-
여러 웹 어플리케이션 서비스 가능
(예를 들어, 하나의 서버에 포트만 변경하여 여러 서비스 제공 가능)
-
접근허용IP관리, 세션관리 등 효율적으로 사용 가능
즉, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리함.
추가로 Web Service Architecture
1. Web Server는 웹 브라우저 클라이언트로부터 HTTP 요청을 받는다.
2. Web Server는 클라이언트의 요청(Request)을 WAS에 보낸다.
3. WAS는 관련된 Servlet을 메모리에 올린다.
4. WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다. (Thread Pool 이용)
5. HttpServletRequest와 HttpServletResponse 객체를 생성하여 Servlet에 전달한다.
5-1. Thread는 Servlet의 service() 메서드를 호출한다.
5-2. service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
protected doGet(HttpServletRequest request, HttpServletResponse response)
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된 적절한 동적 페이지를 Response 객체에 담아 WAS에 전달한다.
7. WAS는 Response 객체를 HttpResponse 형태로 바꾸어 Web Server에 전달한다.
8. 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 제거한다
https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html
'Etc > Etc' 카테고리의 다른 글
[Tomcat] MaxPostSize, MaxParameterCount (0) | 2022.12.14 |
---|---|
Log4j.properties를 이용한 로그 파일생성 (0) | 2020.03.31 |
#Git #GitFlow (0) | 2019.12.24 |