김영한 님의 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 강의를 보고 작성한 내용입니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

1. 웹 서버, 웹 어플리케이션 서버

1-1. 웹

• 웹은 HTTP를 기반으로 통신을 함

• 클라이언트와 서버는 HTTP 프로토콜을 기반으로 동작

• HTTP는 거의 모든 형태의 데이터 전송 가능

• 서버 간의 데이터를 주고 받을 때도 대부분 HTTP를 사용

1-2. 웹 서버 (Web Server)

• HTTP 기반으로 동작하는 서버

• 정적 리소스 제공

  • 정적 리소스는 특정 사용자마다 다른 페이지를 보여줄 수 없음

• 정적(파일) HTML, CSS, JS, 이미지, 영상

• ex> NGINX, APACHE

1-3. 웹 어플리케이션 서버 (WAS - Web Application Server)

• 웹 서버와 마찬가지로 HTTP 기반으로 동작

• 웹 서버 기능 포함

  • ex> 정적 리소스 제공

• 프로그램 코드를 실행해서 어플리케이션 로직 수행

  • 사용자마다 서로 다른 페이지를 보여줄 수 있음

  • 동적 HTML, HTTP API(JSON) 제공 가능

  • 서블릿, JSP, 스프링 MVC 등이 WAS에서 동작

• ex> 톰캣(Tomcat) Jetty, Undertow

1-4. 웹 서버와 웹 어플리케이션 서버의 차이

• 웹 서버와 WAS는 둘의 경계가 모호하다

  • 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함

  • 웹 어플리케이션 서버도 웹 서버의 기능을 제공함

• 언어마다 둘을 구분하는 방식이 다르다

  • 자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 부른다

• 웹 서버는 정적 리소스, WAS는 어플리케이션 로직까지 실행 가능

• WAS는 어플리케이션 코드를 실행하는데 더 특화

2. 웹 시스템 구성

2-1. WAS + DB

• WAS가 정적 리소스, 어플리케이션 로직 모두 제공 가능

• 그러나, WAS가 너무 많은 역할을 담당하기 때문에 서버 과부하 우려

• 어플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음

• WAS에서 장애가 발생하면 웹 브라우저에서 접근조차 할 수 없기 때문에 오류 화면도 노출 불가능

2-2. 웹 서버 + WAS + DB

• 정적 리소스는 웹 서버가 처리하고 WAS는 어플리케이션 로직 처리 전담

• 웹 서버는 어플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임

• 효율적인 리소스 관리가 가능하다

  • 정적 리소스가 많이 사용되면 Web 서버 증설

  • 어플리케이션 리소스가 많이 사용되면 WAS 증설

• WAS, DB 장애시 웹 서버가 오류 화면 제공 가능

3. 서블릿

3-1. 서블릿 특징

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response){
		//어플리케이션 로직
        ...
	}
}

• 비지니스 로직 실행 외 모든 부가 기능들을 지원

  • TCP 연결 / HTTP 메세지 파싱 / 응답 메세지 생성 등 서버에서 처리해야하는 업무를 자동으로 처리해준다

• urlPatterns(/hello)의 URL이 호출되면 (웹 브라우저에서 서버로 요청이 오면)

• 서블릿 코드가 실행 (service 메소드 실행)

• HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest

• HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse

• 개발자는 응답 객체에 원하는 정보를 넣기만 하면 된다

3-2. HTTP 요청, 응답 과정

• WAS는 HTTP 요청 메세지를 기반으로 Request 객체를 새로 만들어서 서블릿 객체를 실행

  • Request 객체가 생성될 때 Response 객체도 같이 생성

  • request, response 객체는 요청이 올 때마다 새로 생성된다

• 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용

• 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력

• WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성해서 웹 브라우저에 전송

3-3. 서블릿 컨테이너

• 서블릿을 지원하는 WAS 안에는 서블릿 컨테이너가 존재

  • 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함

• 서블릿 컨테이너는 서블릿 객체를 관리한다

  • 서블릿 객체를 자동으로 생성, 초기화, 호출

  • WAS가 종료될 때 서블릿을 같이 종료한다

• 서블릿 객체는 싱글톤으로 관리

  • 최초 로딩 시점에 미리 서블릿 객체를 단 하나만 만들어두고 공유해서 사용

  • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근

  • 공유 변수 사용 주의

  • 서블릿 컨테이너 종료 시 함께 종료

• JSP도 서블릿으로 변환 되어서 사용

• 동시 요청을 위한 멀티 Thread 처리 지원

  • 개발자가 신경쓰지 않아도 WAS가 자동으로 처리해준다

4. 동시 요청 - 멀티 Thread

• 클라이언트가 요청을 하면 TCP/IP 커넥션이 연결되고 servlet을 호출

• servlet을 호출하는 것이 Thread

4-1. Thread

• 어플리케이션 코드를 하나하나 순차적으로 실행하는 것은 Thread

  • Thread가 없다면 자바 어플리케이션 실행이 불가능

  • Thread는 한번에 하나의 코드 라인만 수행

• 요청이 오면 Thread를 할당 -> servlet 호출 -> 응답 과정이 끝나면 해제

• Thread를 하나만 사용하는 경우

  • 요청 수행 중에 다른 요청이 들어오면 Thread를 할당 받기 위해 대기

  • 수행 중인 요청 처리가 지연되면 두 개의 요청 모두 Timeout 가능성이 높다

  • 이를 해결하려면 동시 처리가 필요한 경우에 Thread를 추가로 생성하면 된다

4-2. 요청마다 Thread를 생성하는 경우

• 장점

  • 동시 요청을 처리할 수 있다

  • 리소스(CPU, 메모리)가 허용할 때 까지 처리가능

  • 하나의 Thread가 지연 되어도, 나머지 Thread는 정상 동작한다

• 단점

  • 고객의 요청이 올 때 마다 Thread를 생성하면, 응답 속도가 늦어진다
    

  • Thread는 context switching 비용이 발생한다

  • Thread 생성에 제한이 없다

  • 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다

• ➡️ 단점을 보완하기 위해 Thread 풀을 사용

4-3. Thread 풀

• WAS는 내부에 Thread 풀을 가짐

  • 필요한 Thread를 Thread 풀에 보관하고 관리한다

• 요청이 오면 Thread 풀에 요청을 해 Thread를 꺼내서 사용

• 사용이 끝나면 Thread를 죽이지 않고 다시 Thread 풀에 반납

• Thread 풀에 사용 가능한 Thread가 없다면 대기하거나 거절

• Thread 풀에 생성 가능한 Thread의 최대치를 관리

• 장점

  • Thread가 미리 생성되어 있으므로, Thread를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다

  • 생성 가능한 Thread의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다

4-4. WAS의 멀티 Thread 지원

• 멀티 쓰레드에 대한 부분은 WAS가 처리

• 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않고 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발

• 멀티 쓰레드 환경이므로 싱글톤 객체 (서블릿, 스프링 빈) 는 주의해서 사용해야함

5. HTML

• 정적 리소스

  • 이미 작성되어진 HTML (고정 HTML), CSS, JS, 이미지 등을 전달

• 동적 HTML 페이지

  • 요청이 들어오면 WAS가 DB를 통해 정보를 조회하고

  • 템플릿 엔진(JSP, Thymeleaf)을 통해 동적으로 HTML 생성해서 전달

  • 웹 브라우저가 HTML을 해석해서 보여준다

6. HTTP API

• HTML이 아닌 데이터를 전달

• 요청이 들어오면 WAS가 DB를 통해 정보를 조회하고 JSON 형식의 데이터를 전달 ( 주로 JSON 형식을 사용 )

• HTML을 보여주는 전송을 제외한 모든 곳에서 사용됨

  • JSON 형식으로 데이터만 주고 받는다

  • UI 화면이 필요하면 클라이언트가 별도로 처리

• 서버, 웹 클라이언트, 앱 클라이언트와 서버 사이에서 데이터가 전달 시 사용

  • 웹 브라우저에서 자바스크립트를 통한(AJAX) HTTP API 호출

7. SSR - 서버 사이드 렌더링

• 서버에서 최종 HTML을 생성해서 웹 브라우저(클라이언트)에 전달

  • 웹 브라우저는 생성된 HTML을 보여주는 역할만 수행

• 주로 정적인 화면에 사용

• 관련기술: JSP, Thymeleaf (백엔드 개발자)

8. CSR - 클라이언트 사이드 렌더링

• 자바스크립트를 사용해 웹 브라우저에서 HTML을 동적으로 생성

• 주로 동적인 화면에 사용, 웹 환경을 마치 앱 처럼 필요한 부분만 변경할 수 있음

• ex> 구글지도 : 확대하거나 축소해도 url이 달라지지 않고 부분만 변경되는 앱처럼 동작

• 관련기술: React, Vue.js (프론트엔드 개발자)

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

9-1. 과거 기술

• 서블릿 - 1997

  • 자바 코드로 작성해야하기 때문에 HTML 생성이 어려움

• JSP - 1999

  • HTML 생성이 편리하고 내부에서 자바 코드까지 작성할 수 있다

  • but> 비즈니스 로직까지 너무 많은 역할을 담당 ( 하나의 파일 안에 너무 많은 로직이 들어가있음 )

• 서블릿, JSP를 조합한 MVC 패턴 사용

  • 모델, 뷰 컨트롤러로 역할을 나누어 개발 (MVC)

  • 비즈니스 로직과 화면 랜더링 부분을 나누어서 개발

• 수 많은 MVC 프레임워크가 등장 ( MVC 프레임워크 춘추 전국 시대 ) - 2000년 초 ~ 2010년 초

9-2. 현재 사용 기술

• 어노테이션 기반의 스프링 MVC

  • @Controller

  • MVC 프레임워크의 춘추 전국 시대 마무리

• 스프링 부트의 등장

  • 스프링 부트는 서버를 내장

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

  • 스프링 부트는 빌드 결과(Jar)에 WAS 서버를 포함 -> 빌드 배포 단순화

9-3. 최신 기술 ( 스프링 웹 기술 분화 )

• Web Servlet - Spring MVC

  • 서블릿을 기반으로 동작

• Web Reactive - Spring WebFlux

  • 비동기 넌 블러킹 처리

  • 최소 Thread로 최대 성능 - Thread 컨텍스트 스위칭 비용 효율화

  • 함수형 스타일로 개발 - 동시처리 코드 효율화

  • 서블릿 기술 사용 X

  • but> 기술적 난이도가 매우 높고, 아직 관계형 DB 쪽 지원이 부족

9-4. 자바 뷰 템플릿 역사 ( HTML을 편리하게 생성 )

• JSP

  • 속도 느림, 기능 부족

• 프리마커 ( Freemarker ) , 벨로시티 ( Velocity )

  • 속도 문제 해결, 다양한 기능

• 타임리프 ( Thymeleaf )

  • 내추럴 템플릿 : HTML의 모양을 유지하면서 뷰 템플릿 적용 가능

  • 스프링 MVC와 강력한 기능 통합

  • 최선의 선택이지만 성능은 프리마커, 벨로시티가 더 빠름