[Servlet] 서브렛이란?

자, 서블렛을 왜 해야할까? 바로 백엔드 개발, MVC 모델 구현하기 위해서 라고 하면 된다.

 

이래도 이해가 힘드면 다음과 같다.

---

 

 

1. 서블릿이란 무엇인가?

 

클라이언트 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그램" (클라이언트의 HTTP 요청에 대해 특정 기능을 수행, HTML문서를 생성등의 응답을 하는 인터넷 서버 프로그램)

 #클라이언트= 사용자 = 보통의 사람들

동적 콘텐츠를 생성하기 위한 하나의 기술??

# 참조

서블릿은 단순 인터페이스나 클래스 같은 것이 아닙니다. 사실 이 말은 조금은 거짓말(?)이 섞여있는데요. 뒤에서 더 나오니, 조금만 기다려주세요. 지금은 그저 동적 콘텐츠를 생성하기 위한 하나의 기술이라고 생각해주세요.

 

사실 서블릿 이전에 동적 콘텐츠 생성을 위한 기술이 있었습니다. 초창기 Applets이라는 기술이었는데요. 그 뒤에 CGI라는 기술도 있었습니다. 하지만 CGI는 기본적으로 Java 프로세스 단위로 동작을 했었습니다. 즉 요청이 있을 때마다 프로세스를 하나씩 생성을 했어야 합니다. 요즘같이 멀티스레딩 개발 환경이 당연시 되는 시점에서, 거대한 프로그램이 프로세스 단위로 동작을 하게 되면 비효율적일 것 입니다. 즉 서버의 자원을 많이 사용할 수밖에 없었습니다.

 

하지만 Servlet은 Thread 단위로 동작을 하며, 한번 초기화되어서 메모리에 올라간 서블릿은 다시 부르지 않아도 됩니다. 여기서 다시 부르지 않아도 된다는 말은, 초기화를 통해서 메모리에 다시 올리는 과정이 없어졌다는 의미입니다. 또한 사용하지 않을 때는 destroy를 하기도 합니다. 즉 메모리와 같은 자원을 효율적으로 사용할 수 있게 되었습니다. 

 

앞에서 설명 했듯이 Servlet은 동적 콘텐츠를 생성하기 위한 기술입니다. 그런데 이러한 동적 콘텐츠를 어떻게 생성하는 것일까요? 그냥 아무것도 없는 HTML 페이지가 갑자기 동적으로 움직이지는 않을 것입니다. 기본적으로 HTML은 정적 페이지 입니다. 즉 이미 만들어지고, 정해진 콘텐츠만 보여줍니다. 사용자에 맞게 페이지 안에서 다른 정보를 전해줄 수 없습니다. 하지만 서블릿이 서블릿 컨테이너라는 것을 통해서 서버와 통신을 하며, View 페이지에 알맞은 콘텐츠를 보내줍니다.

 

[Java/Java 이론] - 웹 서버란?

 

---

2. 서블릿 컨테이너

 

우선 이것은 꼭 기억하자. 클라이언는 다음 2가지를 수행해줘야한다. Request/Response

그렇다면 서블릿이라는 놈을 관리해주는 친구가 있어야 하지 않을까? 그냥 서버에 서블릿 만들어서 위치해 둔다고 클라이언트의 Request/Response 를 처리해줄리가 없다. 결론적으로 서블릿을 관리해주는 놈을 서블릿 컨테이너라고 한다. 서블릿 컨테이너는 서블릿의 생명주기를 관리하고 요청에 따른 스레드를 생성해준다. 또, 클라이언트의 Request 를 받아주고 Response 를 보낼 수 있게 웹 서버와 소켓을 만들어서 통신을 해준다. 자세한 서블릿 컨테이너의 역할은 아래와 같다.

 

• 통신 지원
  서블릿과 웹 서버가 통신할 수 있는 손쉬운 방법을 제공한다. 우리가 통신을 한다고 생각할 때 소켓을 만들고, 특정 포트를 리스닝하고, 연결 요청이 들어오면 스트림을 생성해서 요청을 받는다고 알고있는데 이 과정을 서블릿 컨테이너가 대신 해주는 것이다. 서블릿 컨테이너는 이런 통신 과정을 API 로 제공하고 있기 때문에 우리가 쉽게 사용할 수 있다.
• 생명주기 관리
  서블릿 컨테이너가 기동되는 순간 서블릿 클래스를 로딩해서 인스턴스화하고, 초기화 메서드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 찾아서 호출한다. 만약 서블릿의 생명이 다하는 순간 가비지 컬렉션을 진행한다.
• 멀티스레딩 관리
  서블릿 컨테이너는 해당 서블릿의 요청이 들어오면 스레드를 생성해서 작업을 수행한다. 즉 동시의 여러 요청이 들어온다면 멀티스레딩 환경으로 동시다발적인 작업을 관리한다.
• 선언적인 보안관리
  서블릿 컨테이너는 보안 관련된 기능을 지원한다. 따라서 서블릿 코드 안에 보안 관련된 메소드를 구현하지 않아도 된다.
• JSP 지원

---

3. 톰캣

 

톰캣이라면 프로그래밍을 하는 사람들은 다 들어봤을 이름이다. 하지만 솔직하게 말해서 나는 톰캣을 "오픈소스 웹 서버 아니야? 그거 돌리면 고양이 웹 페이지 뜨던데" 정도로 알고 있었다. 뭐... 어찌됐든 톰캣은 서블릿 컨테이너이다. 톰캣은 웹 서버와 연동하여 실행할 수 있는 자바 환경을 제공하여 자바 서버 페이지(JSP)와 자바 서블릿이 실행할 수 있는 환경을 제공하고 있다. 톰캣은 관리툴을 통해 설정을 변경할 수 있지만, XML 파일을 편집하여 설정할 수도 있다. 그리고, 톰캣은 HTTP 서버도 자체 내장하기도 한다. 보통 톰캣은 WAS 의 기능을 수행한다. 요즘 톰캣의 버젼이 올라가면서 웹 서버의 기능도 충분히 잘 수행하기 때문에 굳이 웹 서버와 WAS 를 나눠서 생각하지 않아도 되겠다.

출처: https://jusungpark.tistory.com/15 [정리정리정리]

Servlet 이란? 서블릿 이란?

 

다이어그램

 

정리

Servlet 특징

• 클라이언트의 Request에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트
• HTML을 사용하여 리스폰스한다.= 응답
• JAVA의 쓰레드를 이용하여 동작한다.
• MVC 패턴에서의 컨트롤러로 이용된다.
• HTTP 프로토콜 서비스를 지원하는 java.servlet.http.HttpServlet 클래스를 상속받는다.
• UDP보다 속도가 느리다.
• HTML 변경 시 Servlet을 재컴파일해야 하는 단점이 있다.

 

 

클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 큐칙을 지킨 기술

• 자바를 사용하여 웹을 만들기 위해 필요한 기술
• 예를 들어, 유저가 로그인 시도시에 아이디와 비밀번호를 입력하고 로그인 버튼을 누른다. 이 때, 서버가 클라이언트에서 들어오는 아이디와 비밀번호를 확인하고 다음 페이지를 띄워주는데 이러한 역할을 수행하는 것이 Servlet이다.

 

 

Servlet 동작 방식

Client -> Servlet Contatiner로 HTTP Request -> HttpServletRequest, HttpServletResponse 객체 생성 -> 서블릿 분석(Web.xml) -> 찾은 서블릿 -> service() 메소드 호출 -> doGet(), doPost() 호출 -> HttpServletRequest, HttpServletResponse 두 객체 소멸

1. 사용자(클라이언트)가 URL을 치고 엔터치면 HTTP Request를 Servlet Container로 전송
2. Servlet Contatiner는 HttpServletRequest, HttpServletResponse 두 객체 생성
3. web.xml은 사용자가 요청한 URL을 분석하여 어느 서블릿에 대해 요청을 한 것인지 찾는다.
4. 해당 서블릿에서 service 메소드를 호출한 후 클라이언트의 POST, GET 여부에 따라 doGet() 또는 doPost()를 호출한다.
5. doGet(), doPost()는 동적 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보낸다.
6. 응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킨다.

 

 

Servlet Container(서블릿 컨테이너) 란

서블릿을 관리해주는 컨테이너

예를 들자면, 서블릿이 어떠한 역할을 수행하는 정의서라고 보면, 서블릿 컨테이너는 그 정의서를 보고 수행한다고 볼 수 있다. 서블릿 컨테이너는 클라이언트의 Request를 받고 Response를 할 수 있게 웹서버와 소켓을 만들어 통신한다. 대표적인 예로 Tomcat이 있다. 톰캣은 실제로 웹서버와 통신하여 JSP(자바 서버 페이지)와 Servlet이 작동하는 환경을 제공해준다.

Servlet Container 역할

1. 웹서버와의 통신 지원
   • 서블릿 컨테이너는 서블릿과 웹서버가 손쉽게 통신할 수 있게 해준다. 일반적으로 소켓을 만들고 listen, accept 등을 해야하지만 서블릿 컨테이너는 이러한 기능을 API로 제공하여 복잡한 과정을 생략할 수 있게 해준다. 그래서 개발자가 서블릿에 구현해야 할 비지니스 로직에 대해서만 초점을 두게끔 도와준다.
2. 서블릿 생명주기 관리
   • 서블릿 컨테이너는 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출한다. 또한 수명이 다 된 서블릿을 적절하게 가비지 콜렉터를 호출하여 필요없는 자원 낭비를 막아준다.
3. 멀티쓰레드 지원 및 관리
   • 서블릿 컨테이너는 Request가 올 때마다 새로운 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를 실행하고 나면, 쓰레드는 자동으로 죽게 된다. 원래는 쓰레드를 관리해야 하지만 서버가 다중 쓰레드를 생성 및 운영해주니 쓰레드의 안정성에 대해서 걱정하지 않아도 된다.
4. 선언적인 보안 관리
   • 서블릿 컨테이너를 사용하면 개발자는 보안에 관련된 내용을 서블릿 또는 자바 클래스에 구현해 놓지 않아도 된다. 일반적으로 보안관리는 XML 배포 서술자에다가 기록하므로, 보안에 대해 수정할 일이 생겨도 자바 소스 코드를 수정하여 다시 컴파일 하지 않아도 보안관리가 가능하다.

 

 

 

3. Servlet Package

서버와 통신을 하는 서블릿은 당연히 HTTP 프로토콜을 이용합니다. javax.servlet / javax.servlet.http 2개의 패키지가 서블릿 기술을 사용하기 위한 핵심적인 인터페이스와 클래스를 제공합니다. IDE에서 서블릿 클래스를 생성하시면, 자동으로 javax.servlet.http 패키지의 HttpServlet 클래스를 상속받는 것을 볼 수 있습니다. HttpServlet 클래스는 웹사이트를 구현하기 위해서 HTTP를 다룰 수 있는 메서드들을 오버라이딩할 수 있게 하는데요. 흔히 우리가 사용하는 doGet, doPost 같은 메서드들입니다. 이러한 패키지를 통해서 서블릿이 단순 클래스이지만 HTTP 프로토콜의 요청을 받고, 응답할 수 있는 기능을 할 수 있습니다. 

 

4. Servlet Class Hierarchy

위에서 언급한 HttpServlet는 어떻게 작동을 하는 것일까요? 분명한 건 프로그래밍을 함에 있어서 아무런 기능을 구현하지 않았는데도, 자동으로 동작하는 것은 없습니다. 

 

먼저 아래의 그림을 보겠습니다.

 

서블릿 계층

 

서블릿 기술을 구현하는 javax.servlet 패키지에는 뿌리에 해당하는 Servlet 인터페이스가 있습니다. GenericServlet 클래스는 Servlet 인터페이스를 구현하고 있으며, 동시에 ServletConfig 인터페이스도 구현하고 있습니다. 서블릿 컨테이너가 서블릿들을 초기화하는 동안 정보를 넘겨주는 역할을 합니다.  그리고 마지막으로 MyServlet, 즉 우리가 작성한 서블릿 클래스가 HttpServlet 클래스를 상속하는 구조입니다.  당연히 MyServlet의 이름은 사용자가 자유롭게 지을 수 있습니다. 정해진 이름이 아닙니다.

 

4. 1. Servlet Interface

앞에서 언급드렸듯이 Servlet 인터페이스는 javax.servlet 패키지의 뿌리에 해당합니다. 이 인터페이스는 Servlet Engine안에 Load(적재) 되고 Run 합니다. 이때 Servlet Engine은 Tomcat과 같은 웹 서버를 뜻 합니다. Servlet 인터페이스는 서블릿 컨테이너에 의해서 호출됩니다. 아마도 스프링 프레임워크를 배우신 분들이라면 익숙한 개념일 것 입니다. 스프링 컨테이너가 여러 빈들을 관리하는 것과 같습니다. 그렇기 때문에 지금의 서블릿에 대한 개념을 명확히 해둔다면, 스프링 프레임워크를 배울 때도 조금 더 익숙하게 배울 수 있습니다.

 

Servlet 인터페이스에는 서블릿 컨테이너에 의해서 call 되는 중요한 메서드들이 있는데요. init(), service(), destroy()입니다. 이러한 3개의 메서드들을 묶어서 Servlet life-cycle(생명주기)이라고 합니다. 즉 서블릿이 생기고, 일하고, 없어지는 과정을 메서드로 나타내 놓은 것입니다. 사람도 태어나고, 일하고, 죽는 생명주기가 있습니다. 조금은 슬픕니다.

 

어쨌든 위에서도 언급했지만, 프로그래밍에서 아무것도 없는데 저절로 생기고, 작동하는 것은 없습니다. 모든 기능은 메서드에 의해서 작동하는데요. 

 

 

 

+) 아래의 모든 과정은 서블릿 컨테이너에 의해서 필요한 동적 콘텐츠를 제공하기 위한, 서블릿이 요청되었다는 가정을 하고 있습니다. 그리고 이 서블릿 클래스는 이미 적재되어 인스턴스화 된 상태입니다. 

 

4. 1. 1. init()

서블릿이 처음으로 요청될 때 초기화를 합니다. 자바에서 변수를 초기화하는 것과 같습니다. 우리가 작성한 각 서블릿 클래스도 초기화를 해야 사용할 수 있습니다. 서블릿 컨테이너에 의해서 호출되며, 사용하기 위한 준비과정입니다. 

 

하지만 여기서 알아야 할 것은, 서블릿 클래스는 처음 요청될 때 초기화가 되고 나면, 다시 한번 해당 서블릿 클래스를 호출해도 초기화가 되지 않습니다. 단순히 자바 코드를 생각하시면 됩니다. 이미 초기화한 변수를 또 초기화할 필요는 없으니까요. 

 

4. 1. 2. service()

서브릿 컨테이너가 Request(요청)을 받고 Response(응답)에 필요한 서블릿의 service 메서드를 호출합니다. 여기서 service 메서드는 보통 그 자체를 사용하는 것이 아닌, Servlet interface를 구현한 HttpServlet 클래스의 doGet, doPost 같은 메서드를 사용합니다. 

 

당연하지만 service() 메서드는 서블릿 클래스가 init() 메서드가 실행되어 초기화된 후에 호출됩니다. 절대로 그전에 호출될 수 없습니다.

 

또한 기본적으로 서블릿 컨테이너는 멀티스레드 환경이며, 동시에 여러 요청들을 받을 수 있습니다. 즉 여러 service()가 실행될 수 있습니다. 그렇기 때문에 모든 멀티스레드 환경과 마찬가지로 동기화 문제에 신경을 써야 합니다. 

---

서브렛

• 필요한 SW :  아파치 톰켓,  

 

• 

  자바 환경 구축 확인 : JAVA EE

• 서버 연결

 

이론

• 웹통신 

 

•  

  



• 크게 3파트로 나뉜다. 
• 프론트엔드 : 웹페이지개발
• 소프트웨어 엔지니어(백엔드) : WAS
• 또는 풀스택( 프론트엔드_+백엔드)?
• 3 Tier : 물리적으로 나뉘어지는 계층
• 웹프로그래밍 언어 중에서 JSP/Servlet을 사용하는 이유

부가설명 (참조)

WAS가 필요한 이유

• 웹 페이지에 존재하는 동적 컨텐츠를 처리하기 위함.
• 웹서버만을 이용한다면 동적으로 동작해야 하는 컨텐츠의 결과를 웹서버에서 모두 미리 로드해두고 클라이언트에 Response를 보내야함.
• -> 이에 따른 자원낭비를 막기 위해 WAS를 통해 클라이언트의 요청에 맞는 컨텐츠를 그때 그때 제공할 수 있음.

결론

• WAS는 웹서버와 외부프로그램을 연결하는 미들웨어이고, WSGI는 WAS가 파이썬 프로그램과 연결되는 경우에 웹서버와 WAS를 연결하는 미들웨어 역할을 한다고 생각하면 된다.
• CGI 방식은 웹서버와 외부프로그램을 직접 연결시켜 웹서버 위에서 외부 프로그램이 실행되는 방식이다.
• WAS 방식은 외부 프로그램을 웹서버와 분리시키고 WAS라는 별개의 서버 위에서 실행되게 한다.

웹 서버 구조

• 정적 처리 : 클라이언트 -> (Request) -> 웹서버
• 기본적인 동적 처리의 경우 : 클라이언트 -> (Request) -> 웹서버 -> (Request) -> WAS -> 외부 프로그램 실행(WAS에서 동작)
• CGI를 사용하는 경우 : 클라이언트 -> Request -> 웹서버 -> CGI -> 외부 프로그램 실행(웹서버에서 동작)
• WSGI를 사용하는 경우 : 클라이언트 -> Request -> 웹서버 -> Request -> WSGI (미들웨어) -> Requset -> WAS -> 외부 프로그램

웹 서버

• 소프트웨어 + 하드웨어로 이루어짐.
• 하드웨어 : 웹서버가 설치된 시스템 컴퓨터
• 소프트웨어 : 웹 브라우저 클라이언트로부터 Requset를 받아 정적인 컨텐츠(html , css 등등)을 Response 하는 프로그램.
• 기능 : 클라이언트의 요청에 응답을 보내는 역할을 한다.
• 웹서버 소프트웨어의 예) Apache, Nginx, IIS 등등

CGI (Common Gateway Interface)

• 정적으로 동작하는 웹서버를 동적으로 기능하게 만들기 위함.
• 웹서버에 들어온 Request를 외부 프로그램과 연결하여 해당 프로그램이 그 요청을 처리하게 연결해주는 역할.
• 들어온 요청을 연결해주는 역할만 할 뿐, 웹 서버가 외부 프로그램을 직접 실행함.
• WAS와의 차이는 연결되는 외부 프로그램을 서버가 직접 실행하는지, WAS가 대신 실행하는지 차이.
• -> 요청이 들어올 때 마다 서브프로세스를 fork함.

WAS web application server

• 웹서버 + CGI = WAS. 일반적으로는 웹서버와 WAS를 굳이 구분할 필요가 없음.
• DB조회, 다양한 로직 처리등등의 동적인 컨텐츠 제공을 위해 만들어짐.
• http/https 를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)임.
• 웹 컨테이너/서블릿 컨테이너 라고도 불림 -> jsp, servlet 구동 환경을 제공함.
• 웹서버+웹컨테이너 -> 웹서버의 기능을 구조적으로 분리하여 처리하기 위한 목적.
• ->분산처리 환경을 구성하고, 주로 DB 서버를 따로 분리하는 식으로 구성된다.
• 예)Tomcat(Apache), JBoss(Redhat), Jeus(Tmax),, Web Sphere(IBM),Django 등

웹 서버가 필요한 이유

• 클라이언트가 서버로부터 Response를 받을때 HTML문서와 이미지 파일등의 정적 컨텐츠를 한꺼번에 받는것이 아닌, 웹 문서를 모두 받고 나면 그에 맞는 이미지 파일을 재 요청하여 받아오는 식임.
• 이때 웹서버 프로그램이 이미지 파일 요청까지 한번에 처리해서 Response 해주면 WAS에 요청을 다시 보낼 필요가 없어짐
• -> 웹서버가 정적 요청을 처리하면 WAS의 요청/응답 과정이 생략되어 서버의 부담을 줄일 수 있음.