[tomcat] 동작원리

출처 : kchanguk.tistory.com/4

 

 

1. Tomcat의 설정($TOMCAT_HOME/conf/server.xml)

 * server.xml의 역할

  TOMCAT의 메인 설정 파일이며 초기 설정을 명세하는 책임이 있습니다.

 1) Server

  최상위 element로, shutdown 요청 처리를 위한 address와 port 속성을 가지고 있습니다.

<Server port="포트번호" shutdown="SHUTDOWN">

 2) Service

  <Connector>의 모음

<Service name="Catalina">

 3) Engine

  <Host>의 모음

<Engine name="Catalina" defaultHost="localhost">

   (1) name: Engine의 이름
   (2) defaultHost: 접속시 기본값으로 대처할 호스트
   (3) jvmRoute: 로드 밸런서가 여러 Tomcat 인스턴스를 구분하기 위해 사용

 4) Host

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">

  appBase: <Host>의 애플리케이션 디렉터리 “/”를 포함한 절대 경로

• <Realm> 엘리먼트
  보안을 위해 role명과 사용자명, 비밀번호의 맵핑을 외부의 데이터베이스로 부터 가져오는 장치다. tomcat은 UserDataBase, Memory, JDBC, JNDI등 몇개의 <Realm>을 가지고 있다.
  각 <Realm>의 차이는 어디로 부터 정보를 가져왔는가의 차이밖에 없다. 기본값으로는 UserDataBase이외의 <Realm>은 주석 처리되어 무효로 되어 있다.
  
  

 5) Context

  <Host>내에 배포된 애플리케이션

<Context docBase="특정경로" path="/application1" reloadable="true">

  이처럼 설정하면 localhost/application1으로 접근하면, docBase에 정의된 특정 경로의 파일을 찾게 됩니다.

 2.Tomcat의 동작 원리

  1) Http Request를 Servlet Container에 전송
  2) Servlet Container는 HttpServletRequest, HttpServletResponse 두 객체를 생성
  3) 사용자가 요청한 URL을 분석해 어느 서블릿에 대한 요청인지 탐색
  4) 만약 해당 서블릿이 한 번도 실행된 적 없거나, 현재 메모리에 생성된 인스턴스가 없다면 새로 인스턴스를 생성하고 init() 메소드     를 실행하여 초기화한 뒤 스레드를 하나 생성 이미 인스턴스가 존재할 경우에는 스레드만 하나 생성
   (각 서블릿 인스턴스는 서블릿 컨테이너 당 하나만 존재하기 때문)
  5) 컨테이너는 서블릿 service() 메소드를 호출하며, POST, GET 여부에 따라 doGet() 또는 doPost()를 호출
  6) 실행된 메소드는 동적인 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보냄
  7) 응답이 완료되면 HttpServletRequest, HttpServletResponse 두 객체를 소멸

------------------------------------------------------

출처 : velog.io/@hyunjae-lee/Tomcat-2-%EA%B5%AC%EC%A1%B0

Tomcat 구성

Tomcat을 구성하는 큰 단위로는 다음의 3가지가 있습니다.

• Coyote (HTTP Component) : Tomcat에 TCP를 통한 프로토콜 지원
• Catalina (Servlet Container) : Java Servlet을 호스팅하는 환경
• Jasper (JSP Engine) : 실제 JSP 페이지의 요청을 처리하는 Servlet

3가지의 구성요소는 다음과 같이 동작합니다.

1. HTTP 요청을 Coyote에서 받아서 Catalina로 전달합니다.
2. 그러면 Catalina (Servlet Container)에서 전달받은 HTTP 요청을 처리할 웹 어플리케이션 (Context)를 찾고, WEB-INF/web.xml 파일 내용을 참조하여 요청을 전달합니다.
3. 요청된 Servlet을 통해 생성된 jsp 파일들이 호출될 때, Jasper (JSP Engine)이 Validation Check / Compile 등을 수행합니다.

위의 3가지 구성요소는 다음의 5단계 구조에 포함됩니다. 더 자세한 내용은 아래 Tomcat 구조를 통해 살펴보도록 하겠습니다.

---

Tomcat 구조

Tomcat 은 Java로 작성된 Program이기 때문에 JVM (Java Virtual Machine) 위에서 동작합니다. 하나의 JVM 에서 하나의 Tomcat Instance (Server)가 하나의 Process 로써 동작합니다.

하나의 Server 에는 여러 개의 Service 가 존재할 수 있습니다. 각각의 Service는 1개의 1개의 Engine 과 여러 개의 Connector 로 구성됩니다.

Engine 은 Catalina Servlet Engine이라고도 불리며, 정의된 Connector로 들어온 요청을 하위에 있는 해당 Host에게 전달해주는 역할을 수행합니다.

하나의 Engine 에는 여러 개의 Host 가 존재할 수 있습니다. Host는 가상호스트 이름을 나타내며, 호스트 이름이 곧 url에 매핑됩니다. (ex : http://hostname/ ).

하나의 Host 에는 여러 개의 Context 가 존재할 수 있습 니다. Context는 하나의 Web Application을 나타내며 주로 *.war 파일의 형태로 배포가 됩니다.

Tomcat Server가 요청을 받으면, Catalina (Tomcat Engine)가 요청에 맞는 Context (Context path)를 찾고, Context는 자신이 설정된 어플리케이션의 deployment descriptor file (web.xml)을 기반으로 전달받은 요청을 서블릿에게 전달하여 처리되도록 합니다.

즉, 클라이언트 HTTP request > Catalina > Context > Servlet > 클라이언트 response 순으로 처리됩니다.

아래는 Tomcat의 5-tier architecture를 나타낸 그림입니다. 각 tier마다 설정해야 할 parameter들과 설명들 도 일부 작성하였습니다. (설정을 한다는 것은, CATALINA HOME/conf/server.xml에서 값을 수정하는 것을 뜻합니다.)

 

1depth Server(1JVM- 1 Tomcat Instance)

• className : org.apache.catalina.Server 인터페이스를 구현한 클래스명( default : org.apache.catalina.core.StandardServer)
• address : Shutdown 명령을 보낼 수 있는 TCP/IP주소 (default : localhost)
• *port : Shutdown명령을 받을 수 있는 port number(default : 8005)
• *shutdown : Shutdown 될 때 받는 문자열

2depth Service (1개의 Service는 1개의 Engine + N개의 Connector를 갖는다)

• className : org.apache.catalina.Service인터페이스를 구현한 클래스명 (default : org.apache.catalina.core.StandartService)
• *name :  Service의 유일한 이름. Log를 남길 때 사용한다.

3depth Engine (Catalina Servlet Engine)

• className : org.apache.catalina.Engine 인터페이스를 구현한 클래스명(default : org.apache.catalina.core.StandardEngine)
• *defaultHost : 하위에 속한<Host>중에 하나. 처리되지 않은 요청을 처리할 <Host>이다.
• *name : Engine의 유일한 이름 Log를 남길 때 사용한다.
• jvmRoute : Apache HTTP Web Server 등 front-end에 위치한 Load Balancer가 여러 Tomcat instance를 구분하기 위해 사용

4depth Host (localhost)

•  className : org.apache.catalina.Host인터페이스를 구현한 클래스명 (default : org.apache.catalina.StandardHost)
• *Name : 유일한 가상 Host명. http://hostname/~
• *appBase : <Host>dml app폴더 (webapps). Host마다 다른 appBase지정가능(여러 개의 Domain을 효율적으로 고나리하기 위해)
• xmlBase : <Host>의 app의 context XML파일을 포함하는 폴더 ($CATALINA_BASE/<Engine>/<Host>)
• *autoDeploy : web app이 새롭게 생기거나 수정된 경우 <Host>에 배치된다. (default: true) 주로 개발-true/운영-false
• deployIgnore : 정규 표현식. "EX" 입력시 EX파일들을 제외하고 배치됨.
• unpackWARs : true이면 WAR file 압축해제(default:true)
• workDir : *.jsp 파일이 실제로 Class로 변경이 되어 구동이 될 위치($CATALINA_HOME/work)
• deployXML : /META-INF/context.xml을 반영할지 여부 (default : true)
• copyXML

5depth Context (a web application)

• className : org.apache.catalina.Context 인터페이스를 구현한 클래스명 (default : org.apache.catalina.core.StandardContext)
• cookies : session 식별자로 cookie를 인식함( true)
• crossContext : ServletContext.getContext()를 이용하여 다른 ServletContext(Web app)을 가져올 수 있음(false)
• docBase : <Context>의 application폴더를 지정함. 해당 위치에 web자원이 들어가야함.
• path :  web app에서 사용자web path를 지정해야 한다. <Host>에서 유일한 값이어야 함.
• reloadable : web app내의 jsp, classes, web.xml등의 변경을 확인하여 다지 적재(load)함. 운영 시 false
• sessionCookieName : session의 cookie의 변수 값을 설정(JSESSIONID)
• unpackWAR : true면 WAR파일 압축 해제(true)
• workDIR : jsp파일이 실제로 class로 변경이 되어 구동이 될 위치 ($CATALINA_BASE/work)
• copyXML

Tomcat Connector

connector는 특정 TCP port에서 request들을 listen하여 engine으로 보내준다.

HTTP/1.1 Connector (standalone Tomcat server or other web servers)

• 각각의 incoming request는 a thread가 필요하다. [default] HTTP/1.1 : NIO와 APR auto-switching. 혹은 Nio, Nio2, Apr 중에 명시적으로 선택가능.
• maxThreads : 동시에 처리할 수 있는 requests의 수 default :200?
• acceptCount : 모든 thread가 사용중일 때 대기할 수 있는 queue길이 (default:100?)

HTTP/2 Connector (참고 : http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html)

• Non blocking I/O를 사용한다. *a container thread from thread pool를 사용한다. 

AJP Connector (with Apache HTTP web server) : 특수 Protocol처리

• AJP/1.3 : NIO와 APR auto-switching. 혹은 Nio, Nio2, Apr중에 명시적으로 선택가능.
• maxThreads(200) < acceptCount(100)

Connector마다 동작하는 방식을 설정할 수 있습니다. 동작하는 방식으로는 BIO, NIO, NIO2, APR 로 총 4 종류가 있습니다. (Tomcat 버전별로 지원하는 동작방식이 상이합니다.)

• BIO : Tomcat 7의 기본방식이며, 하나의 thread가 하나의 connection을 담당하는 것입니다. 레스토랑으로 생각해보자면, 한명의 종업원이 하나의 손님 그룹 (하나의 테이블)을 전담하는 것으로 비유 할 수 있습니다.
maxConnections = maxThreads = 200 이라는 기본 값으로 설정됩니다.

• NIO : Tomcat 8.5 부터의 기본방식이며, 하나의 thread가 하나 이상의 connection을 담당하는 것입니다. 레스트랑으로 생각해보자면, 한명의 종업원이 여러 손님 그룹을 위해 주문을 받거나 서빙하는 등의 업무를 수행하는 것으로 비유할 수 있습니다.
maxConnections는 default가 10,000 이고, maxThreads는 default가 200입니다.

• APR : Apache Portable Protocol 이라는 특수한 Protocol입니다.
maxConnections는 default가 8,192 입니다. https://github.com/apache/tomcat/blob/master/TOMCAT-NEXT.txt 을 보면, 10.x 버전부터는 APR 방식이 삭제된다고 합니다.

 

사용할 Protocol을 지원하는 Connector를 선정하고 그 후 해당 Connector의 동작방식을 선택하고 나면 반드시 고려해야 할 parameter 들은 다음과 같습니다. (위에서 일부 언급된 내용입니다)

• maxThreads : Connector가 생성할 수 있는 최대 Thread 수 (Active user 수를 의미합니다) (default = 200), Connector를 Executor (Shared Thread Pool)로 설정했다면 값이 무시됨.
• maxConnections : 동시 처리 가능한 최대 Connection 수 (현재 사용중인 fd의 수) (default) BIO는 maxThreads 값과 동일, NIO = 10,000, ARP = 8,192
• maxSpareThreads : 최소로 실행을 유지할 thread 수 (default = 10)
• acceptCount : 모든 thread가 사용 중일때, queue에 저장 가능한 최대 request 수 (backlog를 의미합니 다)
(default = 100)

Thread Pool 은 Dedicated Thread Pool과 Shared Thread Pool가 있습니다. Dedicated Thread Pool은 Connector마다 개별적인 Thread Pool을 가지는 것이고, Shared Thread Pool은 Engine에 할당된 여러 개의 Connector가 공유하는 Thread Pool을 뜻합니다. 실제 운영환경에서는 Dedicated Thread Pool을 주로 사용합 니다.

 

 

 

------------------------------------------------------

출처 : greatlaboratory.github.io/web/web-02/

 

 

버전에 따른 Servlet 작성 방법

1. Servlet 3.0 spec 이상에서 사용하는 방법

• web.xml 파일을 사용하지 않는다.
• 자바 어노테이션(annotation)을 사용한다.

2. Servlet 3.0 spec미만에서 사용하는 방법

• servlet을 등록할 때 web.xml 파일에 등록한다

------------------------------------------------------

 

클라이언트 요청 ~ Servlet Container에 Servlet 객체 생성

http://www.libqa.com/wiki/155

JSP 실행 원리
JSP -> Servlet (.java) -> 컴파일 -> 바이트코드 (.class) -> Servlet 객체 생성됨 -> Servlet Container


//좀더 자세히
1. Webserver나 Servlet 엔진에서 클라이언트의 요청을 받게 됩니다. 
2. JSP Handler 즉, JSP Container Process라고 불리우는 루틴을 거치게 되면서 Servlet 객체존재여부와 파일변경여부를 확인하게 됩니다. 
3. 변경되었다면 새로 source파일을 생성하고 그리고 compile과정을 거쳐 실행하게 되고 그리고 이미 로딩되어 있는데 변경처리되지 않았다면 기존에 존재하는 것을 이용하게 됩니다. 
4. 로딩을 하지않았다면 처음부터 로딩을 시작하여 source파일을 만들고 compile과정을 거쳐 새로 실행합니다. 
5. 다른 서블릿들도 Servlet Container에 적재하는 과정을 반복하게 됩니다. 

jsp변환 서블릿 프로그램은 jspInit(), _jspService(), jspDestroy()세가지 메서드에 의해서 초기화, 서비스, 파괴의 과정을 거친다고 위에서 언급했습니다. 
아래의 그림과 같이 jspInit 메서드를 단 한번 호출한 후 _jspService 메서드를 서비스 요청이 있을 때마다 호출하게 됩니다. 



Servlet Container 내부 동작

http://www.libqa.com/wiki/171

"컨테이너" 컨테이너는 서블릿과 웹 서버가 서로 통신할 수 있는 손쉬운 방법을 제공한다. 다시 말하면, 서버와 대화하기 위하여 개발자가 직접 ServerSocket을 만들고 특정포트에 리스닝하고, 연결 요청이 들어오면 스트림을 생성하는 등 이런 복잡한 일련을 할 필요가 없단 얘기이다. 컨테이너는 어떻게 웹 서버와 통신해야 하는지 잘 알고 있으며 이런 통신 기능을 api로 제공한다.따라서 웹 서버와 서블릿이 서로 통신하기 위한 통로인 통신 API에 대해서 고민할 필요가 없다. 개발자가 고민해야 할 부분은 서블릿에 구현해야 할 비즈니스 로직이다. 


* 컨테이너가 요청다루기 * 1. 사용자가 서블릿에 대한 요청을 클릭 2. 컨테이너는 들어온 요청이 서블릿이라는 것을 간파하곤 HttpservletRequest, HttpServletResponse 객채생성 3. 사용자가 날린 url을 분석하여 어떤 서블릿에 대한 요청인지 알아내고 해당 서블릿의 스레드를 생성하여 request,response 전달 4. 컨테이너는 서블릿의 service() 메소드를 호출 -> service()에서는 doGet()을 호출할지 doPost를 호출할지 결정(일단 doGet으 로 간주) 5. doGet()메소드는 동적인 페이지를생성한 다음, 이를 response객체에 실어 보낸다. 보내고 난 후에도 response에 대한 레퍼런스를 가지고 있다. 6. 스레드 작업이 끝나면 컨테이너는 response객체 를 HttpResponse로 전환하여 클라이언트로 내려보낸다. 이제 마지막으로 Request와 Response 객체를 소멸. 


https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88

웹 컨테이너

웹 컨테이너(web container, 또는 서블릿 컨테이너)는 웹 서버의 컴포넌트 중 하나로 자바 서블릿과 상호작용한다. 웹 컨테이너는 서블릿의 생명주기를 관리하고, URL과 특정 서블릿을 맵핑하며 URL 요청이 올바른 접근 권한을 갖도록 보장한다. [1]

웹 컨테이너는 서블릿, 자바서버 페이지(JSP) 파일, 그리고 서버-사이드 코드가 포함된 다른 타입의 파일들에 대한 요청을 다룬다. 웹 컨테이너는 서블릿 객체를 생성하고, 서블릿을 로드와 언로드하며, 요청과 응답 객체를 생성하고 관리하고, 다른 서블릿 관리 작업을 수행한다.

웹 컨테이너는 웹 컴포넌트 자바 EE 아키텍처 제약을 구현하고, 보안, 병행성, 생명주기 관리, 트랜잭션, 배포 등 다른 서비스를 포함하는 웹 컴포넌트의 실행 환경을 명세한다.

 

• 아파치 톰캣 (예전 자카르타 톰캣) 은 아파치 소프트웨어 라이선스 하에 사용할 수 있는 오픈 소스 웹 컨테이너다.

--------------------------------------------------------

출처 : jang8584.tistory.com/72

 

- Tomcat은 크게 3가지로 컨테이너로 구분한다.
① Stand-alone servlet containers(Tomcat의 기본 모드)
- 내장된 웹서버의 기능을 사용하는 것
- 기능면에서 JavaWebServer의 부분인 Serlvet 컨테이너와 Java 근간 웹 서버를 사용

② In-process servlet containers
- Servlet 컨테이너는 웹서버 플러그인과 Java 컨테이너 구현
- 웹서버 플러그인은 웹서버의 주소 공간 내에 JVM을 열고 그 안에서 JAVA 컨테이너가 실행되도록 한다.
- 다중 스레드의 단일 프로세스 서버에 적당하고 퍼포먼스도 좋지만 확장성에 한계가 있음

③ Out-of-process servlet containers
- 웹서버 플러그인과 웹서버의 외부 JVM에서 실행하는 JAVA 컨테이너 구현
- 웹서버 플러그인과 JAVA 컨테이너 JVM은 몇몇 IPC(보통은 TCP/IP 소켓)를 사용해서 통신
- Out-of-process 엔진의 반응 시간은 in-process 만큼 좋지 않지만 out-of-process 엔진은 확장성과 안전성 면은 In-process보다 좋다.