[Spring] 스프링 MVC : 웹 애플리케이션 이해, 서블릿

[1] 웹 서버, 웹 애플리케이션 이해

웹

• HTTP 기반으로 통신. 모든것이 HTTP!
• 클라이언트에서 서버로 데이터를 전송할 때, 서버에서 클라이언트로 데이터를 응답할 때, 서버간 데이터 통신 등 모두 HTTP 프로토콜을 기반으로 동작

 

웹 서버 (Web Server)

• HTTP 기반으로 동작
• 정적 리소스 제공(html,css,js,이미지,같은 정적 데이터를 그냥 던져줌), 기타 부가기능
• 정적(파일) HTML, JSON, XML,CSS, JS, 이미지, 영상.. 전부 HTTP 기반으로 주고받음 (서버간의 데이터를 주고받을 때에도)
• 예) NGINX, APACHE

 

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

• HTTP 기반으로 동작
• 웹 서버 기능 포함+ (정적 리소스 제공 가능)
• 프로그램 코드를 실행해서 애플리케이션 로직 수행 가능 (정적 리소스를 사용하는 웹 서버와의 차이점)
  • 사용자의 요청에 따라 다른 화면 보여줄 수 있음 (프로그래밍이 가능)
  • 동적 HTML 생성, REST API=HTTP API(JSON) 제공
  • 서블릿, JSP, 스프링 MVC이 동작
• 예) 톰캣(Tomcat) Jetty, Undertow

 

웹 서버, 웹 애플리케이션 서버의 차이

• 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직까지 실행 가능
• 사실은 둘의 용어도 경계도 모호함
  • 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
  • 웹 애플리케이션 서버도 웹 서버의 기능을 제공함
• 자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 부름
  • 요즘은 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음
• 정리하면, WAS는 애플리케이션 코드를 실행하는데 더 특화
• 실무에서 나눠지는 용도를 보자.

 

웹 시스템 구성 - WAS, DB

• WAS, DB 만으로 최소한의 시스템 구성 가능
• WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능

• WAS 하나만 가지고 운영시 ⇒ WAS가 너무 많은 역할을 담당, 서버 과부하 우려
• 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
• (정적 리소스에 비해 애플리케이션 로직은 복잡한 과정을 거쳐 내려주어야 한다는 의미)
• WAS 장애시 접근조차 불가. 오류 화면조차도 노출 불가능
• 큰 시스템을 구축하기에는 부담이 있음

• 가장 일반적인 방식
• 웹 서버를 앞에 두고 정적 리소스(html,css..)는 웹 서버가 처리
  • 업무 분담하여 부담 줄이기
• 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임
• 장점) WAS는 중요한 애플리케이션 로직 처리 전

• 효율적인 리소스 관리
  • 정적 리소스가 많이 사용되면 Web 서버 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS 증설

• 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음 (복잡한 과정이 거의 없음)
• 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음
• WAS, DB 장애시에도 WEB 서버가 오류 화면 제공 가능
• CDN 같은 정적 리소스를 캐시할 수 있는 중간 서버를 놓기도 하고.. 이 구조를 기본 기반으로 발전
• 화면 제공이 아닌 API로 데이터만 제공하게 되면 웹 서버가 굳이 없어도 됨. WAS 서버만 구축해도 됨.

 

[2] 서블릿

 

HTML Form 데이터 전송

 

POST 전송 - 저장

• 회원가입 form
• html을 POST로 저장하기 위해 클라이언트가 POST로 서버에 전송 ⇒ 웹 브라우저가 요청 HTTP 메세지를 생성
• 데이터, 컨텐츠 타입(내용) 등의 정보가 있음

 

서버에서 처리해야 하는 업무

웹 애플리케이션 서버 직접 구현

만약 웹 애플리케이션 서버(WAS)를 직접 구현해야 하면, 다음 프로세스를 거치도록 코드를 직접 작성해야 함

1. 먼저 서버에 TCP/IP 연결을 대기하고, 인터넷 망에서 연결이 들어오면 소켓을 연결하도록 함
2. HTTP 요청 메시지는 단순 텍스트이기 때문에, 파싱을 수행해 POST 방식과 /save URL을 인식
3. Content-Type을 확인하고, 이에 따라 메시지 body의 내용도 파싱해서 읽음
4. 저장에 대한 비즈니스 로직을 실행하고, DB에 저장 요청을 수행
   • 의미있는 비즈니스 로직
5. 저장 결과를 웹 브라우저에 전달하기 위해 HTTP 응답 메시지를 직접 생성
   • 시작 라인 생성, 헤더 생성, 메시지 body에 HTML 작성
6. TCP/IP로 HTTP 응답 메시지를 전달하고 소켓 종료

(4)만 의미있는 비즈니스 로직인데 전후로 단계가 너무 많음

• 전세계 개발자가 이 프로세스를 똑같이 개발하는 것은 너무 비효율적

→ 서블릿의 등장

 

서블릿을 지원하는 WAS 사용

• 서블릿은 의미있는 비즈니스 로직(초록 상자)를 제외한 모든 일들을 지원해준다! 다 자동화

 

서블릿

특징

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

• 웹 브라우저에서 요청이 왔을 때 urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행
• HttpServelet을 생속해서 사용
• HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest를 사용 ⇒ HTTP 메세지의 값을 얻어낼 수 있음.
• HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse ⇒ HTTP 응답 메세지를 생성하는 등의 편의 기능 제공.
• 개발자는 HTTP 스펙을 매우 편리하게 사용 ⇒ 기본적인 HTTP 스펙을 어느 정도는 알아야 함..!
  • Req, Res를 직접 파싱하려했다면 어려웠을 것

 

HTTP 요청, 응답 흐름

• HTTP 요청시
  • WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
  • 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
  • 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
  • WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성→ 웹 브라우저에 전달

서블릿 컨테이너

• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
• 개발자가 서블릿 컨테이너를 직접 생성하지 않아도 서블릿을 지원하는 WAS를 사용시
• 서블릿 컨테이너는 서블릿 객체를 자동으로 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리
  • 객체를 하나만 생성해서 모두가 공유해서 사용하는 방식
  • 왜? Request-Response는 요청마다 항상 새롭게 생성해야함
  • 그러나, 고객의 요청이 올 때 마다 계속 서블릿 객체를 생성하는 것은 비효율
  • 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
  • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
  • 공유 변수 사용 주의
  • 잘못 설정하면 다른 사용자가 내 정보를 보거나.. 할 수 있음
  • 서블릿 컨테이너 종료시 함께 종료
• JSP도 서블릿으로 변환 되어서 사용
• 동시 요청을 위한 멀티 쓰레드 처리 지원

 

 

이 포스트는 인프런의 김영한 강사님의 스프링 mvc 강좌를 기반으로 작성되었습니다.