본문 바로가기

개발 지식/Java

[Java] Jetty 란?

반응형

[Java] Jetty 란?

Jetty는 자바 HTTP 웹 서버이자 자바 서블릿 컨테이너다. 웹 서버가 보통 문서를 사람들에게 제공하는 것과 관련된 반면, 제티는 대규모 소프트웨어 프레임워크에서 기계와 기계의 커뮤니테이션에 사용된다.

- 위키백과 (ko.wikipedia.org/wiki/제티_(웹_서버))

 

서블릿 컨테이너(servlet container)는 뭔데?

서블릿(servlet)이란 SUN 사에서 제안한 웹서비스를 위한 인터페이스로, 원칙적으로는 javax.servlet.Servlet 인터페이스의 구현체다. 일반적인 자바 독립 실행 프로그램과 달리 main 메소드가 없으며, 서블릿 컨테이너에 등록된 후 서블릿 컨테이너에 의해 생성, 호출, 소멸이 이루어진다. 즉, 클라이언트가 request를 보내면 그에 대한 결과를 다시 전송해주어야 하는데, 이러한 역할을 하는 자바 프로그램이 바로 서블릿이다.

일반적으로 웹서버는 정적인 페이지만 제공하지만, 동적인 페이지를 제공할 수 있게 도와주는 어플리케이션이 서블릿이다.

  • 정적인 페이지 : 서버에 미리 저장된 파일(HTML 파일, 이미지, Javascript 파일 등)이 그대로 전달되는 웹 페이지. 즉, 사용자는 서버에 저장된 데이터가 변경되지 않는 한 고정된 웹 페이지를 보게 됨
  • 동적인 페이지 : 서버에 있는 데이터들을 스크립트에 의해 가공처리한 후 생성되어 전달되는 웹 페이. 즉, 사용자는 상황, 시간, 요청 등에 따라 달라지는 웹 페이지를 보게 됨

서블릿 컨테이너(servlet container)는 이러한 서블릿을 관리하며 네트워크 통신, 서블릿의 생명주기 관리, 스레드 기반의 병렬처리를 대행한다. 즉, 웹 클라이언트로부터 HTTP Request가 들어오면 해당 Request를 해석하여 적정한 서블릿의 service 메소드를 ServletRequest, ServletResponse 매개변수와 함께 호출한다. 서블릿 컨테이너의 예시로는 톰캣(Tomcat), 그리고 제티(Jetty) 등이 있다.

서블릿 컨테이너의 역할은 다음과 같다.

  • 웹서버와의 통신지원
    • 서블릿 컨테이너는 서블릿과 웹서버가 손쉽게 통신할 수 있게 해준다. 일반적으로는 소켓을 만들고 listen, accept 등을 해야하지만 서블릿 컨테이너는 이러한 기능을 API로 제공하여 복잡한 과정을 생략할 수 있게 해준다.
  • 서블릿 생명주기 관리
    • 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출한다. 또한 서블릿이 죽게되면 Garbage Collection을 진행하여 적절하게 메모리 관리도 해준다.
  • 멀티쓰레드 지원 및 관리
    • 서블릿 컨테이너는 요청이 올 때마다 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를 실행하고 나면 쓰레드는 자동으로 죽게된다. 원래는 쓰레드를 관리해야 하지만 서버가 멀티 스레드를 생성 및 운영해주니 스레드의 안정성에 대해서 걱정하지 않아도 된다.
  • 선언적인 보안 관리

Jetty Architecture

제티서버는 커넥션을 받아들이는 'Connector'의 모음과 연결 요청을 처리하고 응답을 생성하는 'Handler' 모음과 작업을 수행하는 ThreadPool의 스레드 사이에서의 plumbing(배관) 역할을 한다.

Jetty의 request/response 서블릿 API로부터 나오지만 서블릿 API의 모든 기능은 적절한 핸들러를 설정한 경우에만 사용할 수 있다. 예를 들어, request 위에 있는 세션 API는 해당 request가 SessionHandler로 통과될 때까지 비활성화 된다. 서블릿 자체의 개념은 ServletHandler에 의해 구현된다. 만약 서블릿들이 필요하지 않으면 서블릿 request/response API을 사용함에 있어 오버헤드가 거의 없을 것이다. 그러므로, 서블릿을 사용하지 않고 Connector들과 Handler들만으로 제티 서버를 빌드할 수 있다.

 

Patterns

제티를 구현하는데에는 몇 가지 스탠다드 패턴들을 따른다. Connector와 Handler 등의 대부분의 추상적인 개념들은 인터페이스들에 의해 캡쳐된다. 일반적으로 그러한 인터페이스들을 핸들링하는 것은 AbstractConnector와 AbstractHandler 등과 같은 추상 구현에서 제공한다.

 

Connectors

커넥터는 TCP 커넥션을 받아들이는 컴포넌트다. accept된 각각의 TCP 커넥션은, Connector가 특정 프로토콜을 위한 바이트들을 생성하고 파싱하는 TCP 커넥션에 있는 네트워크 트레픽을 조절하는 Connection 오브젝트를 생성하기 위해 ConnectionFactory에 요청을한다.

이에 따라, ServerConnector는 하나 이상의 ConnectionFactory로 구성 할 수 있다.

가장 간단한 예시로는 HTTP/1.1 프로토콜을 위한 바이트를 생성하고 파싱하는 오브젝트인 HttpConnection을 만드는 HttpConnectionFactory와 같은 단일 ConnectionFactory가 있다.

Jetty의 고급 사용법을 통해 사용자는 Jetty 프로젝트에 의해 직접 구현되지 않은 사용자 정의 프로토콜을 처리하기 위해 자신의 ConnectionFactory를 작성할 수 있으므로 Jetty를 일반 네트워크 서버로 사용한다.

 

Handlers

핸들러는 HTTP request와 response를 다루는 컴포넌트다. 핸들러의 코어 API는 handle이라는 메소드다.

public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException

파라미터 :

  • target - URI 나 이름 같은 request의 타겟
  • baseRequest - the original unwrapped request object
  • request - baseRequest 오브젝트 혹은 baseRequest 레퍼 같은 요청 오브젝트. 필요하다면 HttpConnection.getCurrnetConnection() 메소드를 사용해 리퀘스트 오브젝트에 접근할 수 있다.
  • response - response로 unwrapped된 것 혹은 그 response의 레퍼 같은 response 오브젝트. 필요하다면 HttpConnection.getCurrnetConnection() 메소드를 사용해 리퀘스트 오브젝트에 접근할 수 있다.

해당 메소드의 구현은 요청을 처리하거나 다른 핸들러 (또는 서블릿)에 요청을 전달하거나 요청을 수정 및 / 또는 랩핑 한 다음 전달할 수 있다. 이는 3가지 스타일의 핸들러를 제공한다:

  • 조정 핸들러(Coordinating handlers) - 한 request를 다른 핸들러로 라우팅 해주는 핸들러(HandlerCollection, ContextHandlerCollection)
  • 필터링 핸들러(Filtering handlers) - request를 보강하고 다른 핸들러로 전달하는 핸들러 (HandlerWrapper, ContextHandler, SessionHandler)
  • 생산 핸들러(Generating handlers) - content를 생산하는 핸들러(ResourceHandler, ServletHandler)

 

Servlet Handler

서블릿 핸들러는 request를 설정된 서블릿필터로 전달한 후, URI 패턴으로 맵핑된 서블릿에 전달하여 content를 생성하는 핸들러다.

서블릿 핸들러는 보통 ServletContext의 범위 안에서 배포되는데, 이 ServletContext라 함은, URI들을 서블릿에 맵핑하기 위한 편리한 메소드들을 제공하는 ContextHandler다.

 

Contexts

Contexts는 특정 URI context path나 가상 호스트 아래에 있는 핸들러들을 그룹화하는 핸들러다. 일반적으로 context는 다음과 같은 것들을 가질 수 있다.

  • A context path that defines which requests are handled by the context (e.g. /myapp)
  • A resource base for static content (a document root)
  • A class loader to obtain classes specific to the context (typically from /WEB-INF/classes and /WEB-INF/lib)
  • Virtual host names

 


  • Reference : https://mangkyu.tistory.com/14
  • Reference : https://www.eclipse.org/jetty/documentation/current/architecture.html

 

 

 

반응형

'개발 지식 > Java' 카테고리의 다른 글

[Java] Producer - Consumer 패턴 구조  (0) 2020.05.03
[JAVA] JDBC, JPA/Hibernate, MyBatis 차이점  (0) 2020.04.21
Thread Pool이란?  (0) 2020.04.04
빌더 패턴(Builder Pattern) 이란  (0) 2020.02.24
[JAVA] Logback 사용법  (0) 2020.02.19