[JSP] 필수 이해 요소

JHJeong·2024년 5월 7일
jsp필수 이해 요소
0

JSP

목록 보기
3/5
post-custom-banner

1. JSP 처리 과정

웹브라우저에 주소를 입력하면 JSP가 실행되는 것 처럼 보이지만, 실제로 JSP를 실행하는 과정은 꽤 복잡하다.


(그림 출처 : blog )

(1) 클라이언트 요청 수신

  • 웹 브라우저(클라이언트)에서 사용자가 URL을 통해 JSP 페이지에 접근한다. 예를 들어, 사용자가 'https://example.com/app/page.jsp' 주소를 입력한다.
  • 클라이언트는 HTTP 프로토콜을 사용하여 웹 서버에 요청을 보낸다. 이 요청은 HTTP 메서드(GET, POST등), Header(컨텐츠 타입, 쿠키 정보, 사용자 에이전트 등), URL 및 필요한 경우 Body(POST 데이터)를 포함한다.

(2) 웹 서버에서 서블릿 컨테이너로 요청 전달

  • 웹 서버(Apache, Nginx 등)는 요청을 받고, 이를 처리하기 위해 서블릿 컨테이너(Tomcat, Jetty 등)로 전달한다.
  • 데이터 전달 : 웹 서버는 HTTP 요청을 파싱하여 서블릿 컨테이너에 전달한다. 이 때, 요청 정보는 서블릿 API를 통해 'HttpServletRequest' 객체로 변환된다.

(3) 서블릿 컨테이너 내 JSP 처리

  • 서블릿 컨테이너는 요청된 URL과 매핑된 JSP 파일을 확인한다. JSP 파일이 이미 서블릿으로 컴파일된 경우, 해당 서블릿을 실행한다. 처음 요청된 JSP의 경우, 서블릿으로 변환 및 컴파일 과정이 이루어진다.
  • JSP 파일은 Java 코드로 변환되고, 이 코드는 서블릿으로 컴파일된다. 컴파일된 서블릿은 요청 데이터를 처리하여 동적으로 HTML을 생성한다.

(4) 서블릿 실행 및 응답 생성

  • 변환된 서블릿이 실행되며, 이 과정에서 서블릿은 'service()'메소드를 호출하여 요청을 처리한다. 서블릿은 요청 정보를 분석하고, 필요한 비즈니스 로직을 수행한 후 응답 데이터를 생성한다.
  • 서블릿 HTML, CSS, JavaScript 등을 포함한 응답 데이터를 생선한다. 이 데이터는 'HttpServletResponse'객체에 저장되며, HTTP 응답 형태로 클라이언트에 전송된다.

(5) 응답 전송

  • 서블릿 컨테이너는 생성된 응답 데이터를 웹 서버로 전송하고, 웹 서버는 이를 클라이언트에게 전달한다.
  • 생성된 HTML 응답은 HTTP 응답 포맷(상태 코드, 헤더, 바디)으로 클라이언트에게 전송된다. 이 응답은 최종적으로 클라이언트의 웹 브라우저에서 렌더링되어 사용자에게 표시된다.

(6) 세션 및 쿠키 관리

  • 서블릿 실행 중 세션 및 쿠키를 관리하여 사용자의 상태를 유지한다. 쿠키는 클라이언트와 서버 간에 상태 정보를 저장하는 데 사용된다.
  • 필요한 경우, 서블릿은 쿠키 정보를 생성하거나 수정하고, 이 정보를 HTTP 응답의 헤더에 포함시켜 클라이언트에게 전송한다.

이 과정을 통해 JSP 페이지는 동적 웹 컨텐츠를 생성하고, 이를 클라이언트에게 효과적으로 제공한다. 각 단계는 웹 어플리케이션의 성능, 확장성 및 사용자 경험을 최적화하는 데 중요한 역할을 한다.

2. 출력 버퍼와 응답

  • JSP 페이지는 응답 결과를 곧바로 웹 브라우저에 전송하지 않는다. 대신 출력 버퍼에 임시로 응답 결과를 저장했다가 한 번에 웹 브라저에 전송한다.

  • 출력버퍼(Output Buffer) : JSP 페이지의 응답 내용을 임시로 저장하는 메모리 영역, 웹 서버가 최종 응답을 클라이언트에게 전송하기 전에 데이터를 버퍼링한다.

  • 이러한 버퍼링 과정의 장점은 다음과 같다.
    --> 데이터 전송 성능 향상
    --> JSP 실행 도중에 버퍼를 비우고 새로운 내용 전송 가능
    --> 버퍼가 다 차기 전까지 헤더 변경 가능

  • buffer 속성 : JSP 페이지의 출력 버퍼 크기를 설정한다. 기본 값은 보통 8KB이지만, 페이지 디렉티브를 사용하여 이 크기를 조정할 수 있다.

  • autoFlush 속성 : 버퍼가 가득 차면 자동으로 플러시(비우고, 데이터를 전송)할지 여부를 결정한다. 'true'로 설정하면 버퍼가 자동으로 flush되고, 'false'로 설정하면 버퍼 오버플로우시 예외가 발생한다.

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ page buffer="1kb" autoFlush="true" %>
<html>
<head><title>autoFlush 속성값 true 예제</title></head>
<body>
<% for (int i = 0; i < 1000; i++) { %>
1234
<% } %>
</body>
</html>
  • Line2 : buffer 속성을 '1KB'로 설정하여 출력 버퍼의 크기를 1KB로 지정하고, autoFlush 속성을 true로 설정하여 버퍼가 가득 차면 자동으로 플러시하도록 설정된다. 버퍼를 사용하고 싶지 않다면 buffer 속성의 값은 "none"으로 지정하면 된다.
  • Line3-12 : HTML 문서의 기본 구조를 정의하고, 간단한 반복문을 사용하여 1000번 '1234' 문자열을 출력한다. 이 코드는 버퍼 크기를 초과하는 응답 데이터를 생성하므로, 'autoFlush'가 'true'이기 때문에 버퍼가 자동으로 비워지고 클라이언트로 데이터가 전송된다.
    ( 일반적으로 JSP 페이지를 작성할 때에는 buffer 속성을 지정하지 않는다. JSP 규약은 butter 속성을 지정하지 않으면 최소한 8KB 이상의 크기를 갖는 버퍼를 사용하도록 규정하고 있다. )

3. 웹 어플리케이션 폴더 구성과 URL 매핑

  • 웹 어플리케이션 폴더 구성 : 웹 어플리케이션의 구조화된 폴더 시스템으로, 소스 파일, 클래스, 라이브러리, 정적 자원 등이 포함된다.
  • URL 매핑 : 웹 어플리케이션에서 특정 요청 URL이 실제 서버의 어떤 리소스나 서블릿과 연결되는 방식을 정의하는 설정.
  • 웹 어플리케이션 폴더 구성은 URL 매핑과 직접 연결된다. 예를 들어 'WEB-INF' 내부의 리소스는 외부에서 직접 접근할 수 없으며, 서블릿이나 JSP를 통해 간접적으로 접근된다.

4. 웹 어플리케이션 배포

  • 웹 어플리케이션 배포는 웹 서버에 애플리케이션을 설치하여 외부에서 접근 가능하게 만드는 과정이다. 이 과정에는 애플리케이션의 구성 파일, 서블릿, 클래스, 라이브러리 및 자원을 포함하는 WAR 파일 생성이 포함된다.
  • WAR 파일(Web Application Archive) : 웹 어플리케이션의 모든 컴포넌트를 포함하는 압축 파일 형식, JSP, 서블릿, 자바 클래스, XML 등이 포함될 수 있다.
  • WAR 파일은 WEB-INF 폴더 내에 배포 디스크립터와 라이브러리를 포함하며, 이 폴더는 외부에서 직접적인 접근이 제한된다. 배포 후, 웹 서버는 WAR 파일을 압축 해제하고, 애플리케이션을 호스트하여 요청에 응답할 수 있도록 준비한다.

톰캣에서 WAR 파일 배포는 간단한데, WAR 파일을 톰캣의 'webapps' 디렉토리에 복사하기만 하면, 톰캣이 서버를 다시 시작할 때 자동으로 WAR 파일을 인식하고 애플리케이션을 배포한다.

자세하게 적어보면 다음과 같은 과정으로 진행된다.

(1) 웹 어플리케이션의 패키징

  • WAR 파일 : 웹 어플리케이션의 모든 구성요소는 WAR 파일안에 패키징된다. 이 파일은 Java 클래스, JSP, HTML, CSS, JavaScript 파일, 메타데이터(XML 설정 파일), 그리고 의존성 라이브러리(JAR파일들)을 포함한다.
  • 패키징 도구 : 이 패키징 과정은 Maven이나 Gradle 같은 빌드 도구를 사용하여 자동화할 수 있다. 이 도구들은 의존성 관리를 자동화하고, 빌드 및 패키징 과정을 표준화한다.

(2) 배포 및 초기화

  • 배포 : 생성된 WAR 파일은 웹 서버의 'webapps' 디렉토리에 복사되어 배포된다. Apache Tomcat 같은 서버는 이 디렉토리를 주기적으로 확인하고 새로운 WAR 파일을 자동으로 감지한다.
  • 압축 해제 및 로드 : 서버는 WAR파일을 압축 해제하고, 파일 내의 애플리케이션 구성을 읽기 시작한다. 'WEB-INF'폴더에 위치한 'web.xml'파일은 애플리케이션의 배포 디스크립터로서, 서블릿 매핑, 세션 구성, 보안 설정 등을 정의한다.

(3) 클래스 로딩

  • 클래스 로더 계층 : JAVA의 클래스 로딩은 계층적으로 이루어지는데, Tomcat의 경우에는 각 웹 어플리케이션 마다 별도의 클래스 로더를 생성하여 어플리케이션 간의 클래스 충돌을 방지하게 한다.
  • 로드 과정 : 클래스 로더는 'WEB-INF/classes'와 같이 'WEB-INF/lib'디렉토리에 있는 클래스와 JAR파일들을 JVM에 로드한다. 이 과정에서 보안 매니저가 활성화 되어있으면, 각 클래스의 로딩은 보안 정책에 따라 검사된다.

(4) 서블릿 및 JSP 컴파일

  • 서블릿 초기화 : 최초 요청이 서블릿에 도달하면, 서블릿의 'init()' 메소드가 호출되어 필요한 리소스를 초기화한다.
  • JSP 처리 : JSP파일은 서블릿으로 변환되고, 이 변환된 서블릿은 컴파일되어 JVM에서 실행 가능한 바이트 코드로 변환된다. JSP 페이지에 대한 첫 요청이 처리되는 동안, 이 컴파일 과정이 일어난다.

(5) 요청 처리 및 응답 생성

  • 요청 처리 : 서블릿은 'service()'메소드를 통해 들어오는 요청을 처리한다. 이 메소드는 요청 유형(GET, POST)에 따라 적절한 메소드(doGet, doPost)를 호출한다.
  • 응답 생성 : 처리 결과는 응답 스트림을 통해 클라이언트로 전송된다. HTTP 응답 헤더가 설정되며, 컨텐츠 타입, 캐싱 정책, 쿠키 등이 포함될 수 있다.

(6) 세션 및 리소스 관리

  • 세션 관리 : 웹 서버는 사용자의 세션과 쿠키들을 관리하고, 세션 타임아웃, 세션 데이터 저장등을 처리한다.
  • 리소스 정리 : 애플리케이션 종료시, 'destory()'메소드가 호출되어 개방된 리소스를 해제하고, 가비지 컬렉션을 통해 불필요한 메모리를 정리한다.

이러한 과정을 통해 JAVA 웹 어플리케이션은 효율적으로 배포되고, 유지보수가 이루어지며, 클라이언트에 안정적으로 서비스를 제공한다. 이 모든 과정은 웹 어플리케이션의 성능, 안정성, 보안을 보장하는 데 중요한 역할을 한다.

profile
JHJeong
이것저것하고 싶은 개발자
이전 포스트

[JSP] 기본 코드 구조

다음 포스트

[JSP] 쿠키

post-custom-banner

0개의 댓글