framework/spring

스프링 MVC 0 - 웹애플리케이션 이해

wooweee 2023. 4. 26. 14:01
728x90

1. web server, web app server

  • 웹
    • http 기반으로 작동 = http protocol의 규칙을 따라서 요청과 응답이 오고 간다.
  • http 메시지
    • 거의 모든 형태의 데어터 전송 가능
      ex) HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML (API)
    • 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 

 

1.1. 용어

    1.1.1. 웹 서버(WEB)

  1. HTTP 기반으로 동작
  2. 정적 리소스 제공, 기타 부가기능
    • webServer가 가지고 있는 html,css.js.img,avi 를 client가 요청시, http로 응답해주는 것
    • ex) NGINX, APACHE

 

    1.1.2. 웹 애플리케이션 서버(WAS)

  1. HTTP 기반으로 동작
  2. 웹 서버 기능 포함 + (정적 리소스 제공 가능)
  3. 프로그램 코드를 실행해서 애플리케이션 로직 수행    - web server와의 차이점
    • 동적 HTML, HTTP API(JSON)
    • 서블릿, JSP, 스프링 MVC • 예) 톰캣(Tomcat) Jetty, Undertow
    • ex) 톰캣(Tomcat) Jetty, Undertow

 

    1.1.3. WEB, WAS 차이점

  • 구분하기 모호함 - WEB도 프로그램 실행하는 기능 포함하기도 하고 WAS도 WEB기능 제공함
  • 주요 차이점     : WEB(정적 리소스)  -  WAS(app logic = 동적)
  • 구체적 차이점  : WAS는 application code 실행하는데 더 특화

  • 자바: 서블릿 컨테이너 기능 제공하면 WAS   
    ex) 톰켓

 

1.2. 구성

  • 웹 시스템 구성 - WEB, WAS, DB

  • WEB
    • 정적 리소스 처리, WAS 서버 과부하 방지 및 역할 분담, 오류 화면 노출 가능  ex) 정적 리소스: html, css, js, img
    • applicaion logic 처리가 필요시(=동적 처리 필요시) WAS에 요청 위임
  • WAS
    • 위임 받은 app logic 처리 전담

웹 시스템 구성

  •  장점
    • 효율적인 리소스 관리: 정적 리소스 많이 사용시 web 서버 증설, app 리소스 많이 사용시 WAS 증설
    • web은 잘 안죽음 -> WAS, DB 죽을 시 WEB에서 오류 화면 제공 가능

 

1.3. 경로

    1.3.1. 경로 방식 개요

  • 경로 방식은 jsp 파일 사용 여부에 따라서 spring 경로, spring boot 경로로 나뉜다
    이유: jsp 파일은 webapp/WEB-INF를 사용하기 때문
    • spring 프로젝트는 옛날 프로젝트라 보통 jsp를 사용해서 spring 경로 방식을 권장
    • springboot 프로젝트는 thymeleaf 사용을 권장해서 springboot 경로 방식을 권장
      cf) spring-boot에서 굳이 jsp를 사용할 경우 spring 경로를 따른다. 반대로 spring project에서 thymeleaf 사용시 springboot 경로 따른다.
  • web server의 경우 아래 2가지 방식이 존재하는데 뭘 쓰든 상관 없다. 하지만 권장하는 방식을 따르는 것을 추천
    1. spring의 (src/main/webapp/resources/css,js,img && src/main/webapp/html ) 방식
    2. springboot의 (src/main/resources/static/css,js,img,html) 방식
  • jsp, thymeleaf를 섞어 사용하지 않기 때문에 복잡하게 생각하지 말 것. 그냥 각 프로젝트별 권장 방식을 이용할 것

  • 화면은 보여주는 기준은 동적 view를 우선적으로 찾아서 반환하고 없을 경우 정적 view를 찾아서 반환한다.

 

    1.3.2. default view 화면

  • root("/") 경로로 접근하는 controller가 없을 경우 보여주는 default html이 있다. - default 설정은 커스텀 할 수 있다.
  • 만약 "/" 경로로 접근하는 controller가 있을 경우 (return "index.html")
    • 동적 view 경로에  index.html이 있을 경우 default html을 보여주지 않고 동적 view 파일을 반환
    • 동적 view 경로에  index.html이 없을 경우 default html을 보여줌

 

  • Spring 프로젝트의 경우 :  src/main/webapp/index.html 
    • root 경로 (/)에 디폴트로 서비스하는 정적 HTML 파일은 일반적으로 src/main/webapp/html 디렉토리에 위치하며 파일 이름은 보통 index.html입니다.

  • Spring Boot 프로젝트의 경우 : src/main/resources/static/index.html
    • root 경로 (/)에 디폴트로 서비스하는 정적 HTML 파일은 src/main/resources/static 디렉토리에 위치할 것이며, 파일 이름은 마찬가지로 index.html입니다.

 

    1.3.3. Spring

  • web server:  정적 자원 (CSS, 이미지, JavaScript, 정적 html 등)
    • src/main/webapp/resources/css
    • src/main/webapp/resources/js
    • src/main/webapp/resources/img
    • src/main/webapp/html
  • was server : JSP 파일 및 동적 뷰
    • src/main/webapp/WEB-INF/views/jsp

 

  • 경로(권장)
- src
  - main
    - resources
    - webapp
      - html (정적 html) 
      - resources
        - css
        - js
        - img
      - WEB-INF
        - jsp (동적 html)

 

    1.3.4. Spring boot

  • web server
    • src/main/resources/static/html
    • src/main/resources/static/css
    • src/main/resources/static/js
    • src/main/resources/static/img
  • WAS : HTML 파일 또는 Thymeleaf, Freemarker 등의 동적 뷰
    • src/main/resources/templates/thymeleaf
    • cf) 정적 html 파일을 넣을 순 있는데 권장 안함
- src
  - main
    - resources
      - static
        - css
        - js
        - img
        - html
      - templates
        - HTML 파일 <- (가능은 하지만 권장 안함)
        - 뷰 템플릿

 

2. 서블릿

  • 필요한 이유
    • client 요청을 받아서 server에서 요청의 정보를 이용하여 응답을 보내는 과정에서
      1) http 규약에 맞춰서 온 요청을 파싱해서 읽어야하고
      2) http 규약에 맞추어서 응답을 보내야한다.
  • 아래 그림과 같이 녹색 box를 제외한 우리가 수행해야되는 로직은 반복적이고 기계적인 과정이다.
  • 이 부분을 서블릿이 대신 수행해 주면서 우리는 비즈니스 로직에만 집중할 수 있게 된다.

 

 

2.1. servlet

 

1. app에서 @ServletComponentScan으로 먼저 서블릿 적용할 class scan

// springboot web 실행 source code

@ServletComponentScan // 다른 source code에서 서블릿을 적용한 class를 scan한다.
@SpringBootApplication
public class ServletApplication {
	public static void main(String[] args) {
		SpringApplication.run(ServletApplication.class, args);
	}

}

 

2. servlet 적용한 class

  • @WebServlet
    • name: servlet 이름 지정(큰 의미 X) - 서블릿 컨테이너 내부 빈으로 등록될 때 빈 이름이 된다.
    • urlPatterns: 해당 url로 갈 때 그 class의 servlet 작동
  • HttpServlet: 요청과 응답을 객체로 생성해서 파라미터로 넘겨준다.
    - 요청할때마다 새로 생성됨. singleton 아니다.

  • request: client 요청 http 정보 받음

  • response: 응답 정보로 보낼 data를 http 규약에 편리하게 넣을 수 있도록 해줌

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

 

 

2.2. Servlet container

  • tomcat이 was인데 was 중에서도 서블릿을 제공하는 was가 존재한다. tomcat이 그렇다.
  • tomcat과 같이 was를 제공하는 was의 내부를 보면 2개의 직사각형이 존재하는 데 request, response를 생성하는 부분, 서블릿 컨테이너가 존재
    • request, response box : client마다 다른 객체가 생성
    • 서블릿 컨테이너 : 공통 부분으로 spring에서 작성한 service 로직 부분
      1. 싱글톤
      2. helloservlet이라는 class file 자체가 객체로 등록( bean 이름은 @Webservlet name="bean 이름")

 

servlet container

복습

  • servlet container: 톰켓처럼 서블릿을 지원하는 WAS
  • 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리   
  • 서블릿 객체: name 만들어준 class, 싱글톤으로 관리
    • 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
    • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근 • 공유 변수 사용 주의 • 서블릿 컨테이너 종료시 함께 종료
  • JSP도 서블릿으로 변환 되어서 사용
  • 동시 요청을 위한 멀티 쓰레드 처리 지원 - 제일 큰 특징, 개발자가 신경 안써도 WAS가 알아서 잘 해줌

 

 

3. 동시 요청 - 멀티 쓰레드

  • 쓰레드
    • application 코드를 하나하나 순차적으로 실행하는 것 = WAS에서 서블릿 객체를 호출해줌
    • ex) main method
    • thread는 한번에 하나의 코드 라인만 수행, 동시 처리 필요시 쓰레드를 추가로 생성

 

  • 쓰레드 하나만 사용할 때 단점
    • 다중 요청이 들어왔는데 첫 요청에서 처리 지연이 발생하면 대기 요청들은 무한대기 상태에 빠진다.

 

  • 쓰레드를 요청할 때마다 생성
    • 장점: 동시 요청 처리 가능, 하나의 쓰레드가 지연 되어도 나머지는 정상 동작
    • 단점: 쓰레드 생성 비용이 높아서 응답 속도가 늦어진다. = 생성하는데 드는 시간이 오래 걸려서
      • 컨텍스트 스위칭 비용 발생
      • 쓰레드 생성에 제한이 없다 - 너무 많은 요청 때 CPU, 메모리 임계점을 넘어서 서버가 죽음

 

  • 쓰레드 풀(WAS 대부분 이거 사용)
    • 특징: 필요한 쓰레드를 쓰레드 풀에 보관 관리, 생성 가능한 쓰레드 최대치 관리 (톰켓은 최대 200개 설정 가능)
    • 사용: 쓰레드 필요시 풀에 있는거 쓰고 종료시 반납, 풀에 쓰레드 없을 시 요청 거절 or 대기
    • 장점: 응답 시간 빠름, 최대치 제한으로 기존 요청 안전하게 처리
    • 쓰레드 풀 적정 숫자: 성능 테스트 실행 - nGrinder 추천

  • WAS의 멀티 쓰레드 지원

  • WAS가 알아서 다 해주니깐 관련 코드 신경 안써도 됨

  • max thread(최대 쓰레드 수)와 singleton 객체만 주의

 

 

 

4. HTML, HTTP API, CSR, SSR

4.1. 정적 리소스

 

 

4.2. 동적 리소스

4.2.1. HTML page

   

웹 브라우저: html 해석 contentType:text/html

4.2.2. HTTP API

  • html이 아닌 데이터 전달,
  • 주로 JSON 형식 사용

web browser: json 해석 application/json

  • WAS에선 data만 전달하고 data를 받은 1) 앱 client 2) web browser 3) server 는 자신의 필요에 맞게 data 이용
  • 1) 2) 같은 경우는 UI를 frontEnd 쪽에서 만들어서 WAS로부터 받은 data 를 자신의 ui에 적절히 사용 - react.js

 

4.2.3. SSR, CSR 

SSR(좌) CSR(우)

  • SSR : backEnd 자체 html 사용  - 타임리프 추천, jsp는 이제 한물 갔음
  • CSR : frontEnd html+css+JS 사용 -react.js

 

5. 자바 백엔드 웹 기술 역사

5.1. mvc

5.1.1. 과거

서블릿(1997) : HTML 생성이 어려움

JSP(1999)    : HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할 담당

 

서블릿, JSP 조합 MVC 패턴 사용 : 모델, 뷰 컨트롤러로 역할을 나누어 개발

MVC 프레임워크 춘추 전국 시대(2000~2010) : MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원
                                                                           ex) 스트럿츠, 웹워크, 스프링 MVC(과거 버전)

 

5.1.2. 현재

    애노테이션 기반의 스프링 MVC
       @Controller

    스프링 부트
       스프링 부트는 서버를 내장
       스프링 부트는 빌드 결과(Jar)에 WAS(톰켓) 서버 포함 -> 빌드 배포 단순화    = 개발자가 불편해하는 것을 자동화 해줌

            - 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포

       

     기술 분화

        Web Servlet - Spring MVC : servlet 위에 MVC 가 존재한다.

        Web Reactive - Spring WebFlux() : node.js 처럼 작동하는 것인데 아직은 지켜볼 단계

 

 

5.2. template

자바 View template = backEnd 쪽 HTML

 

JSP
    속도 느림, 기능 부족

 

프리마커(Freemarker), Velocity(벨로시티)
    속도 문제 해결, 다양한 기능 - 근데 발전을 안함

 

타임리프(Thymeleaf)
    내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능
    스프링 MVC와 강력한 기능 통합
    최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠름

 

 

 

 

다음 발행글: 스프링 MVC 1 - 서블릿

 

출처 인프런 김영한의 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

저작자표시 비영리 변경금지

'framework/spring'의 다른글

  • 현재글스프링 MVC 0 - 웹애플리케이션 이해

관련글

티스토리툴바