일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- SpringBoot
- 초기 구축
- dto valid
- java9
- spring boot
- 헤더 설정
- NextJS
- docker 설치
- jvm
- java8
- CentOS6
- JPA
- header setting
- custom valid
- 리눅스
- jpa entity자동
- JavaScript
- Java
- 도커
- generate entity
- swagger
- MySQL
- React
- 초기 세팅
- docker
- ollama langflow
- memcached
- Next.js 14
- generate pojos
- spring
- Today
- Total
개발자의 길
web server 및 어플리케이션의 이해와 tomcat 구조 본문
▶ Web 서버
- HTTP 프로토콜을 기반으로 하여, Web 클라이언트(브라우저)로 부터의 요청을 서비스 하는 기능을 담당하는
프로그램(일반적으로 Apache를 많이 사용함)
- Web 서버의 역할은 html, 이미지(jpg, gif.. 등), xml 등에 대한 처리를 담당(CGI 프로그램 요청도 처리)
▶ Web Appication 서버
- 여러 Web 클라이언트(브라우저)의 요구를 Web 서버 혼자 감당하기에는 힘들기 때문에, 구조적으로 Web
서버의 기능을 분리하기 위해 만들어진 것으로 Web Applicatioin Server(WAS)라고 한다.(일반적으로
Tomcat, Weblogic, WebShpare, Jeus, JBoss 등이 이용된다.)
▶ Web 서버와 Web Applicatiion 서버의 차이점
- Web 서버와 Web Application 서버는 위의 설명처럼 사용의 목적이 다르다. Web 서버는 html, 이미지들의 요청을 처리하는데 빠르고 , Web Application 서버는 Servlet이나, JSP의 비지니스 로직을 수행하는데 적합하다.(웹컨테이너란 이러한 Servlet은JSP를 수행하는 역할을 하는 서버를 말한다.) 그렇다고 Web Application Server가 html, 이미지들의 요청을 처리하지 못한다는 얘기는 아니다. 다만 처리 속도가 Web 서버에 비해 느리다는 점 뿐이다. 이렇게 서로 다른 강점을 합해서 사용하기 위해 Web 서버와 Web Application 서버를 연동하여 서비스를 하는 것이 대부분이다.
※ [참조] JSP 기초 http://cafe.naver.com/tonkjsp/6
▶ Tomcat
- Tomcat은 JSP 환경을 포함하고 있는 Servlet 컨테이너
- Servlet 컨테이너는 사용자 입장에서 Servlet을 유지하고 호출하여 실행하는 쉘
- 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보다 좋다.
▶ 톰캣 디렉토리 구조
- tomcat 6.0 에서는 위 그림 처럼 되어 있지 않고 common, server 빠진 상태로 되어 있다.
- common, server 빠진 상태로 정리하면
디렉토리명 |
기능 설명 |
bin |
여기에는 톰캣 서버의 동작을 제어할 수 있는 스크립트 및 실행 파일들이 포함되어 있습니다. |
conf |
톰캣의 기본적인 설정 파일들이 포함되어 있습니다. |
lib |
아파치와 같은 다른 웹 서버와 톰캣을 연결해주는 바이너리 모듈들이 포함되어 있습니다. |
webapps |
톰캣이 제공하는 웹 애플리케이션의 기본 위치입니다. |
logs |
서버의 로그 파일이 저장되는 디렉토리입니다. |
Work |
JSP 컨테이너와 다른 파일들이 생성하는 임시 디렉토리입니다. |
temp |
임시 저장 폴더 |
위의 그림과 같이 항상 같은 구조를 표준 처럼 유지 되어야 한다.
요구되는 형태로 웹 어플리케이션 보관소 생성을 용이하게 하기 위해서, 웹 어플리케이션의 "실행" 파일들(즉, 웹 어플리케이션을 실행할 때 톰캣이 사용하는 파일들)을 WAR 형식에서 요구하는 것과 같은 구성으로 정리하는게 편합니다. 이렇게 하려면, 웹 어플리케이션의 "문서 루트 document root" 디렉토리에 다음 내용으로 구성합니다
- *.html, *.jsp, 등. - 웹 어플리케이션에서 클라이언트 브라우저로 전송이 되는 HTML 과 JSP 페이지와 다른 파일들 (예를 들면 자바스크립트, 스타일시트, 이미지 같은). 대규모 어플리케이션에서 이 파일들을 서브디렉토리 체계로 나누어 놓을 수 있습니다. 그러나 규모가 작은 어플리케이션이라면 보통은 하나의 디렉토리에서 전체를 관리하는 것이 보다 단순하고 쉽습니다.
- /WEB-INF/web.xml - 웹 어플리케이션의 웹 어플리케이션 배치 설명자 Web Application Deployment Descriptor. 서블릿과 웹어플리케이션을 구성하는 다른 컴포넌트들을 설명하고, 각종 초기화 파라메터들과 서버 기능을 활용하기 위한 컨테이너가 관리하는 보안 제한 구역을 지정하는 XML 파일입니다. 다음 섹션에서 좀 더 자세히 알아보도록 하겠습니다.
- /WEB-INF/classes/ - 이 디렉토리에는 웹 어플리케이션에서 사용하는 모든 자바 파일(그리고, 관련 자원)이 들어있습니다. 서블릿과 비서블릿 클래스 파일들이며 jar 형태로 묶여있지 않은 것입니다. 패키지가 선언된 클래스라면 /WEB-INF/classes/ 를 기준으로 패키지의 디렉토리를 만들어 구성하면 됩니다. 예를 들어, 클래스명이 com.mycompany.mypackage.MyServlet 라면 파일의 저장경로는 /WEB-INF/classes/com/mycompany/mypackage/MyServlet.class 이 됩니다.
- /WEB-INF/lib/ - 이 디렉토리에는 웹어플리케이션에서 사용하는 자바 클래스파일을 포함하는 JAR 파일들이 위치합니다. 외부 클래스 라이브러리나 JDBC 드라이버 같은 것들입니다.
톰캣(또는 다른 2.2/2.3 호환 서버)에 어플리케이션을 설치할 때, WEB-INF/classes/ 에 있는 클래스들과 WEB-INF/lib/ 디렉토리에 있는 JAR파일에 있는 모든 클래스들은 같은 웹 어플리케이션에서 사용하는 모든 클래스가 접근가능하게 되어있습니다. 따라서, 만일 이 디렉토리 안에 사용하는 모든 라이브러리 클래스들을 몰아 넣으면 (외부 라이브러리를 사용하는 경우 재배포 권한에 관한 라이센스를 확인하길 바랍니다.), 웹 어플리케이션의 설치가 간단히 끝날 수 있습니다 -- 시스템 클래스패스에 대한 조정(또는 서버에 있는 전체 라이브러리의 설치)도 필요 없습니다.
▶ 톰캣 환경설정(server.xml)
- tomcat에서 주요한 환경설정 파일 중 하나 입니다.
- 컴포넌트에 대한 초기 설정 제공
- tomcat에 대한 구조를 지정
- server.xml 구조 및 계층적 엘리먼트
상위의 속성은 자동적으로 하위의 요소에 계승된다. 예를 들어 <Host>의 구성요소 <Logger> 의 속성은 아무것도 지정하지 않은 경우 <Engine>의 구성 요소 <Logger>의 설정이 사용된다. 변경이 필요한 경우에는 <Host>의 구성요소 <Logger>에 별도의 설정을 함으로서 상위의 설정을 덮어 쓸수 있다.
㉠ server 엘리먼트
tomcat 서버 구성요소의 정의 부분이다. 기본값은 <server port="8005" shutdown="shutdown">로 되어 있으며, 포트 8005를 감시하고 shutdown 명령어를 접수하도록 설정되어 있다. 서버에서는 복수의 서비스를 관련 지울 수 있다.
㉡ service 엘리먼트
tomcat service 구성요소를 정의하고 있다. <service>는 뒤에 기술 할 <Engine>과 그것에 관련된 모든 <Connector>를 그룹화 한 것이다. 기본값은 <Service name="Catalina">로 되어 있다. (name 으로 "Tomcat-Standalone" 설정하는 경우도 있음)
-> 속성
■ name : Catalina라고 하는이름으로 서비스가 정의 되어 있고, 에러 로그 및 관리툴은 이 이름으로 식별한다.
하나의 서버에 복수의 서비스를 정의하는 경우, 다른 name 속성을 기입할 필요가 있다 .
<Serice>는 <Engine>과 하나 이상의 <Connector>를 관련짓는 것이 가능하다. <Service>와 <Engine>의 관계는 1:1
㉢ Engine 엘리먼트
<Engine>은 servlet 컨테이너의 인스턴스를 표시하며, <Connector>로부터 보내진 요구를 처리한다. <Engine name="Catalina" defaultHost="localhost">로 되어 있다.
-> 속성
■ name : <Engine>의 이름을 표시하며, 에러 로그 및 관리툴은 이 이름으로 <Engine>을 식별한다.
■ defaulthost : server.xml에 정의 되어 있지 않은 <Host>에 요구가 있을 경우 발송되는 가상호스트를 지정한다.
<Engine>에는 하나 이상의 <Host>가 관련지어져 있다.
㉤ Connector 엘리먼트
요구를 <Engine>에 건네 주는 역할을 하는 것이 <Connector>다. <Serviced>는 하나 이상의 <Connector>를 갖을 필요 있음
사용자는 HTTP 또는 HTTP/SSL 등 여러가지 방법으로 <Engine>에 요구를 보낸다. 이것들의 접속 요건의 처리는 <Connector>
구성요소에 맡겨진다. 각 프로토콜에 대해 복수의 <Connector>를 갖는 것으로서 어떤 접속에서 요구가 보내져와도 <Engine>
이 동일하게 처리하고 , 응답을 <Connector>에 맡길 수 있다.
tomcat에는 몇개의 표준<connector>가 탑재되어 있으며, 기본값은 HTTP1.1 <Connector>와 AJP<Connector>가 준비되어 있다.
㉥ DefaultContext 엘리먼트
모든 <Conext> 고통의 정의부, 기본적으로 설정되어 있지 않다.
㉦ Realm 엘리먼트
보안을 위해 role명과 사용자명, 비밀번호의 맵핑을 외부의 데이터베이스로 부터 가져오는 장치다. tomcat은 UserDataBase, Memory, JDBC, JNDI등 몇개의 <Realm>을 가지고 있다.
각 <Realm>의 차이는 어디로 부터 정보를 가져왔는가의 차이밖에 없다. 기본값으로는 UserDataBase이외의 <Realm>은 주석 처리되어 무효로 되어 있다.
㉧ Logger 엘리먼트
로그파일의 작성 방법을 설정한다. <Logger>는 server.xml 구조에서 보듯이 <Engine>레벨에서 설정할 수 있다.
<Logger className="org.apache.catalina.logger.FileLogger">
prefix="server-log." suffix=".txt"
timestamp="true"/>
위의 <예>에서는 tomcat의 FileLogger 클래스를 사용, prefix, suffix, timestamp 속성에서 로그파일명을 정의하고 있다. 이 경우, 로그파일은 [server-log.2008_08.txt]과 같은 형식으로 $CATALINA_HOMe/logㄴ 디렉토리에 출력된다.
㉨ Host 엘리먼트
<Engine>에 관련된 가상호스트를 정의한다.. 기본값으로 다음과 같이 되어 있다.
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
가상 호스트명을 "localhost"로 설정하고 appBase 속성에서 어플리케이션이 탑재되어 있는 디렉토리를 "webapps"로 설정하고 있다. 별도로 unpackWARs에서는 WAR파일을 전개하고나서 실행할 것인지의 여부를 , autoDeploy 속성에서는 tomcat이 기동중에 웹어플리케이션을 배치한 경우에 자동으로 읽어 들일 것인지의 여붜를 설정할 수 있다.
㉩ Value 엘리먼트
tomcat 특유의 기능이다. <Value>는 상위 구성요소로의 필터 처리를 담당한다. <Engine>, <Host>, <Context>와 관련짓는 것이 가능하다. 또, Tomat에는 표준으로 다음과 같은 몇개의 <Value>가 준비되어 있다.
AccessLogValue
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="server-log-" fileDateFormat="yyyy-MM-dd" suffix=".txt"/>
RemoteAccessValve
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1,192.168.0.1" />
SingleSignOnValue
<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>
RequestDumpValue
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
- AccessLogValue
$CATALINA_HOME/logs 디렉토리에 server-log-2008-08-04.txt 의 형식으로 로그파일을 작성한다.
- RemoteAccessValue
접근을 IP주소 단위로 제한한다. 지정주소에서의 접근을 허가, 거부를 설정할 수 있다. <예>에서는 로컬 IP주소 192.168.0.1로 부터의 접근을 허가하고 있다. 또 RemoteHostValue를 사용하면 호스트 단위로 접근제한을 설정할 수 있다.
- SingleSignOnValue
요구와 응답의 헤더와 쿠키를 <Logger>로 설정한 로그파일이 작성된다.
㉪ Context 요소
<Host>에는 웹어플리케이션의 복수개의 <Context>가 관련지어져 있다. <Context> 요소에는 웹어플리케이션의 일련의 설정 프로퍼티가 들어간다. 웹어프리케이션 배치에서 소개 한대로 이 설정은 웹어플리케이션마다에 설정파일을 가질 수 있다.
- <Logger> 엘리먼트 사용하는 경우
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="localhost_log." suffix=".txt"
timestamp="true"/>
Logger를 잠시보면 로거로 FileLogger라는 클래스를 사용할 것이며, 디렉토리는 톰캣의
logs 디렉토리를 , 파일명은 localhost_log.yyyy-mm-dd.txt로 하겠다는 것
속성 |
설명 |
backgroundProcessorDelay |
이 값은 컨텍스트와 그 자식 컨테이너에서 background process method가 invoke되는 delay 시간을 나타낸다. 이 값을 양수로 설정하면 어떤 쓰레드가 분기되어 일정 시간 후에 이 쓰레드가 해당 host와 자식 컨테이너에서 background process method를 실행시킵니다 만약 설정하지 않으면 디폴트값인 -1을 가지며 음수의 값은 부모 host의 background processing 정책을 사용한다는 것입니다. 참고로 컨텍스트는 세션을 종료하거나 클래스 리로딩을 위한 모니터링등을 위해 background processing을 사용합니다. |
className |
사용할 Java 구현체 클래스의 이름. 이 클래스는 반드시 org.apache.catalina.Context 인터페이스를 구현해야 합니다. 지정하지 않으면 표준값 (아래에 정의됩니다)이 사용됩니다 |
cookies |
true(디폴트)로 지정하면 클라이언트가 쿠키를 지원하는 경우 세션확인의 통신수단(session identifier communication)으로 쿠키를 사용합니다. false로 지정하면 세션확인의 통신수단으로 쿠키 사용을 하지 않고, 어플리케이션에 의한 URL 다시쓰기(URL rewriting)에만 의존한다는 의미입니다. |
crossContext |
true로 지정하면 이 어플리케이션에서 ServletContext.getContext() 호출을 통해, 이 가상호스트에서 실행중인 다른 웹어플리케이션에 대한 요청디스패쳐(request dispatcher)를 성공적으로 얻을 수 있습니다. 보안상의 이유로 false(디폴트)로 지정하면 getContext()는 언제나 null을 반환하게 됩니다. |
docBase |
이 웹어플리케이션에 대한 Document Base (Context Root로도 알려져 있습니다) 디렉토리, 또는 웹어플리케이션 아카이브 파일의 경로명(웹어플리케이션을 WAR 파일로 직접 실행하는 경우)을 나타냅니다. 이 디렉토리나 WAR 파일에에 대한 절대경로명을 지정할 수도 있고, 이 Context가 정의된 Host의 appBase 디렉토리에 대한 상대경로명을 지정할 수도 있습니다 |
override |
true로 설정하면 DefaultContext element를 관련된 host에서 명백하게 상속받아 사용합니다 기본값으로 Defaultcontext element가 사용됩니다 |
privileged |
true로 설정하면 이 컨텍스트는 관리자서블릿(manager servlet) 같은 컨테이너 서블릿을 사용할 수 있습니다. |
path |
이 웹어플리케이션의 컨텍스트 경로(context path)를 나타내며, 각 요청 URI의 시작부분이 컨텍스트 경로와 같을 때 해당 웹어플리케이션이 그 요청을 처리하게 됩니다. 하나의 특정 Host 내의 컨텍스트 경로들은 모두 각각 유일해야 합니다. 만약 컨텍스트 경로를 빈 스트링("")으로 지정하면, 이 Context는 이 Host에 대한 디폴트 웹어플리케이션으로 정의된 것입니다. 디폴트 웹어플리케이션은 다른 Context 들에 해당되지 않는 모든 요청을 처리할 것입니다. |
reloadable |
true로 지정하면, Catalina는 /WEB-INF/classes/와 /WEB-INF/lib 안 클래스 들의 변경여부를 감시하다가, 변경이 발견되면 웹어플리케이션을 자동으로 재적재(reload)합니다. 이 기능은 개발중에는 매우 유용하지만 얼마간의 실행부하(runtime overhead)가 발생하므로, 실제 운영할 용도로 어플리케이션을 배치(deploy)할 때는 사용하지 않도록 합니다. 그러나 이미 배치가 끝난 어플리케이션이라도 Manager 웹어플리케이션을 이용하면 필요할 때 재적재 하도록 할 수 있습니다 |
wrapperClass |
이 Context로 관리할 서블릿 들에 대해 사용할 org.apache.catalina.Wrapper 구현체 클래스의 Java 클래스명입니다. 지정하지 않으면 표준값이 사용됩니다 |
from http://jakarta.apache.org
=============================================
저자 : GoodBug (unicorn@jakartaproject.com)
최초 : http://www.jakartaproject.com
=============================================
▶ 서블릿 환경설정 (web.xml)
① CATALINA(톰캣 설치 폴더)/conf/web.xml
② invoker를 이용하여 모든 서블릿을 호출할 수 있는 서블릿을 지정합니다.
<servlet>
<servlet-name>invoker</servlet-name>
<servlet-class>
org.apache.catalina.servlets.InvokerServlet
</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
③ 서블렛을 사용 할 수 있도록 환경을 설정하고 Servlet을 URL상에서의 접근할 수 있도록 경로명을 지정합니다.
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
④ 수정된 Servlet,JSP 페이지가 서버를 재시작안해도 인식이 설정
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>modificationTestInterval</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>development</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>reloading</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
'9. TOMCAT' 카테고리의 다른 글
[tomcat] 파라메타(parameter) 넘길 시 한글 깨짐 해결 (1) | 2015.06.24 |
---|---|
[tomcat] jndi 설정 (2) | 2015.06.17 |
tomcat 성능 향상 방법 - 튜닝 (0) | 2010.02.17 |
tomcat ThreadPool (0) | 2009.12.24 |
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.