우리는 웹 브라우저를 사용할 때,
클라이언트 <---> 인터넷 <---> 서버
위와 같은 통신을 사용한다.
이때, HTTP 프로토콜이라는 응용 계층의 프로토콜을 사용하여 통신한다.
아래는 스프링 MVC를 시작하기 앞서 알아두어야 할 기초 개념들을 설명해 놓았다.
1. 웹 서버란?
2. 웹 애플리케이션 서버란?
3. 웹 서버와 웹 애플리케이션 서버의 사용
4. 웹 애플리케이션 서버의 서블릿에 대하여
5. 쓰레드 풀
천천히 살펴보자.
1. 웹 서버란?
웹 서버는 HTTP기반으로 동작하는 정적 리소스(HTML, CSS, JS, 이미지, 영상)을 다루는 서버이다.
2. 웹 애플리케이션 서버란?
WAS(Web Application Server)는 웹서버 + 프로그램 코드이다.
예시로 톰캣이 있다.
3. 웹 서버와 웹 애플리케이션 서버의 사용
위의 두 설명을 보면 웹 애플리케이션 서버는 웹 서버 + 프로그램 코드이다.
그렇다면, 웹 애플리케이션 서버만 사용해서 시스템을 구성할 수 있는지에 대한 의문이 들 수 있다.
그에 대한 답은 할 수 있지만, 보통 웹 서버와 WAS를 동시에 사용한다.
웹 서버를 왜 사용하는가?
위에 대한 답이다.
1. WAS와 웹 서버를 나누어 서버를 두어 WAS 서버의 과부하를 막는다.
2. WAS에서 오류나 장애 시 웹 서버의 오류 화면을 노출 시켜준다.
3. WAS의 로직이 정적 리소스 때문에 수행이 안될 수 있음.
4. 정적 리소스가 많이 사용될 시 웹 서버 증설. 반대일 시, WAS 증설
즉, WAS는 중요한 로직들이 담겨야 하기 때문에, 로직에만 집중하는 반면, 웹 서버는 정적 리소스에만 집중한다.
그렇다면, 어떻게 구성하여 사용할까?
1. 클라이어트 요청
2. 웹 서버에서 정적 리소스 처리
3. 로직 필요 시 WAS에서의 로직 처리
4. WAS는 DB의 사용과 로직의 처리를 전담
4-1. WAS에서 로직 장애 시 웹 서버의 오류 HTML 띄워줌.
즉, 나눠줌으로 더욱 체계적이고 효율적 관리를 할 수 있는 것이다.
4. 웹 애플리케이션 서버의 서블릿에 대하여
서블릿을 알아보기 전에 우선, WAS의 동작에 대해 알아보자.
1. 웹 브라우저(클라이언트)에서 정보 입력 후 입력 버튼을 클릭한다.
2. 그때, On-Demand 연결 즉, 클릭 시 바로 TCP/IP 간 소캣이 생성되고 연결된다.
3. 입력된 정보를 HTTP 메시지로 바꾼 후 7계층의 프로토콜에 따라 전달된다.
4. 서버는 HTTP 요청 메시지를 파싱한다.
5. WAS는 헤더 확인, 바디 내용 확인한다.
6. 헤더에 맞춰 Request, Resposne 객체를 생성한다.
여기서 잠깐!
이때, 6번 다음에서 서블릿이 사용된다.
7번부터는 다음 그림을 본 후 계속 이어가겠다.
7. Reqeust에 포함된 URL정보를 보고 WAS는 어떠한 서블릿이 사용되어야 하는지 판단한다.(@WebServlet의 urlPattern)
8. 그 서블릿을 실행하기 위한 쓰레드를 쓰레드 풀에서 매칭해준다.(후에 설명)
9. 서블릿의 로직 실행(service 메소드이다.)
10. Response 객체에 응답할 내용을 입력(서블릿 로직에서 실행)
11. WAS는 Response 객체에 있는 내용을 http 응답 메시지로 보낸다.
12. 쓰레드 할당을 해제하고, 모든 객체, 소캣 연결을 해제한다.
이처럼 서블릿은 쓰레드를 할당받아, service라는 로직에 개발자가 수행해야할 로직만 써주면 위의 과정을 다 알아서 해준다.
5. 쓰레드 풀
위의 8번을 보면, 쓰레드 풀이라는 처음 듣는 단어가 나온다.
아래의 그림을 보자.
대부분의 로직은 실행되기 위해 쓰레드가 필요하다.
만약, 여러 클라이언트가 요청을 하면, 싱글톤으로 관리되는 서블릿 객체는 쓰레드의 할당을 받고, 수행된다.
하지만, 이때, 처리중에 장애가 발생된다면, 아래의 클라이언트는 쓰레드를 사용하지 못해 무한 대기를 하게된다.
이때, 해결방안으로 새로운 쓰레드를 생성해 할당해줄 수 있지만,
이렇게 하면
1. 쓰레드를 생성 비용은 매우 비싸다.
2. 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
즉, 적절한 쓰레드를 생성해주어야 한다.
그렇기 때문에 쓰레드 풀이라는 적당한 쓰레드를 생성시켜놓고 모아두는 곳을 만들어, 처리, 해제 식으로 멀티 요청을 해결하는 것이다.
<본 글은 김영한님의 강의를 듣고 작성되었습니다.>
'스프링 프레임 워크' 카테고리의 다른 글
빈과 빈 컨텍스트 그리고 @Transactional에 대하여 (0) | 2025.03.18 |
---|---|
스프링 mvc의 전체적인 동작 과정(argument resolver, returnvalue handler) (0) | 2023.10.10 |
HTTP 응답 다루기(HTML-정적, 동적) (0) | 2023.10.09 |
HTTP 요청 메시지(데이터를 다루기) (0) | 2023.10.05 |
HTTP 요청 파라미터(데이터를 다루기) (0) | 2023.09.27 |