[스프링 MVC - 백엔드 웹 개발 기술] 01. 웹서버(Web Server), 웹 애플리케이션 서버(WAS) 그리고 서블릿

01. 웹서버, 웹 애플리케이션 서버

01-1. 웹 - HTTP 기반

1. 웹은 HTTP 기반으로 통신을 한다
2. 클라이언트 요청 → 인터넷 → 서버(HTML 생성) 값 반환

01-2. 웹 서버(Web Server)

1. HTTP 기반 동작
2. 정적 리소스 제공, 기타 부가기능 제공
3. 정적(파일) HTML, CSS, JS, 이미지, 영상
4. 예) Nginx, Apache

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

1. HTTP 기반 동작
2. 웹 서버 기능 포함 + (정적 리소스 제공 가능)
3. 애플리케이션 로직 수행
   1. 동적 HTML, HTTP API(JSON)
   2. 서블릿, JSP, 스프링 MVC
4. 예) 톰캣(Tomcat) Jetty, Undertow

01-4. 웹 서버, 웹 어플리케이션 서버(WAS) 차이점

👉🏼 H/W 관점에서의 웹서버는 서버가 설치되어 있는 컴퓨터를 의미합니다. S/W 관점에서의 웹서버는 CSS, JS, Image 등의 정적 컨텐츠를 처리하기 위한 웹서버로 동작합니다. 대표적으로 Nginx, Apache가 있습니다. 이에 반해 WAS는 Web Application Server로 DB 작업이나, 동적으로 처리해야 하는 비즈니스 로직을 처리하기 위한 Web Application Server입니다.

1. 웹 서버는 정적 리소스 파일, WAS는 애플리케이션 로직 제공
2. 사실 둘의 용어도 경계도 모호함
   1. 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
      1. 플러그인 설치해서 실행 가능
   2. 웹 애플리케이션 서버도 웹 서버의 기능 제공함
3. 자바는 서블릿 컨테이너 기능을 제공하면 WAS
   1. 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음
4. WAS는 애플리케이션 코드를 실행하는데 더 특화

01-5. 웹 시스템 구성 - WAS, DB

• WAS, DB 만으로 시스템 구성 가능
• WAS는 정적 리소스, 비즈니스 로직 모두 제공 가능

01-6. 웹 시스템 구성 - WAS, DB

• WAS가 너무 많은 역할을 담당 → 서버 과부하 우려
• 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
• WAS 장애시 오류 화면도 노출 불가능
  • ex) Nginx PM 작업시에 점검 문구 보여준다
  • ex) 서버 점검중으로 인해 서비스가 불가합니다.

01-7. 웹 시스템 구성 - WEB, WAS, DB

• 정적 리소스는 웹 서버가 처리
• 웹 서버는 애플리케이션 로직같은 동적 처리가 필요시 → WAS에 요청 위임
• WAS는 중요한 애플리케이션 로직 처리 전담

01-8. 웹 시스템 구성 - WEB, WAS, DB

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

01-9. 웹 시스템 구성 - WEB, WAS, DB

• 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음
• 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음
• WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

01. 서블릿(Servlet)

1. 요청 플로우
   1. 위와 같은 HTML Form이 있다고 가정 해보자
   2. 이름과 나이를 넣고 전송 버튼을 클릭
   3. 회원 가입 완료
2. 웹 브라우저가 생성한 요청 HTTP 메시지
   1. Method : POST
   2. Host : localhost:8080
   3. Content-Type : application/x-www-form-urlencoded
   4. Body : username=kim&age=20

01-1. 서버에서 처리해야 하는 업무

만약 웹 애플리케이션 서버(WAS)를 직접 구현해야 한다면?

1. 서버 TCP/IP 연결 대기 + 소켓 연결
2. HTTP 요청 메시지 파싱 후 읽기
3. POST 방식, /save URL 인지
4. Content-Type 확인
5. HTTP 메시지 바디 내용 파싱
   1. username, age 데이터 사용할 수 있게 파싱
6. 저장 프로세스 실행
7. 비즈니스 로직 실행
   1. DB에 저장 요청
8. HTTP 응답 메시지 생성 시작
   1. HTTP 시작 라인 생성
   2. Header 생성
   3. 메시지 바디 HTML 생성 후 입력
9. TCP/IP에 응답 전달, 소켓 종료

01-2. 서버에서 처리해야 하는 업무

서블릿을 지원하는 WAS 사용

비즈 로직 말고 나머지는 서블릿이 처리 해준다

1. 서버 TCP/IP 연결 대기 + 소켓 연결
2. HTTP 요청 메시지 파싱 후 읽기
3. POST 방식, /save URL 인지
4. Content-Type 확인
5. HTTP 메시지 바디 내용 파싱
   1. username, age 데이터 사용할 수 있게 파싱
6. 저장 프로세스 실행
7. 비즈니스 로직 실행
   1. DB에 저장 요청
8. HTTP 응답 메시지 생성 시작
   1. HTTP 시작 라인 생성
   2. Header 생성
   3. 메시지 바디 HTML 생성 후 입력
9. TCP/IP에 응답 전달, 소켓 종료

01-3. 서블릿(Servlet)

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

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) {
            // 애플리케이션 로직
    }
}

1. urlPatterns(”/hello”)의 URL이 호출되면 서블릿 코드 실행
2. HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
   1. 파싱 정보 등의 모든 내용을 제공
3. HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
   1. 실제 반환되는 정보를 담고 있음
4. 개발자는 HTTP 스펙을 매우 편리하게 사용

01-4. 서블릿 동작 메커니즘

1. 클라이언트가 서버(http://localhost:8080)에 요청
2. WAS에서 요청 메시지를 기반으로 HttpServletRequest, HttpServletResponse 객체 생성
3. 요청된 URL 분석을 통해 해당 요청에 맞는 서블릿 클래스 탐색 및 실행
4. response에 응답 메시지 담아서 반환

01-5. 서블릿 - HTTP 요청, 응답 흐름

1. HTTP 요청 시
   1. WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
   2. 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내 사용
   3. 개발자는 Response 객체에서 HTTP 응답 정보 를 편리하게 입력
   4. WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보 생성

01-6. 서블릿 컨테이너

1. 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라 함
2. 서블릿 컨테이너는 서블릿 객체를 생성 → 초기화 → 호출 → 종료 하는 생명주기 관리
3. 서블릿 객체(helloServlet) 는 싱글톤 관리
   1. 고객 요청마다 객체 생성은 비효율적
   2. 최초 로딩 시점에 서블릿 객체 미리 만들고 재활용
   3. 모든 고객 요청은 동일 서블릿 객체에 접근
   4. 공유 변수 사용 주의
   5. 서블릿 컨테이너 종료시 함께 종료
4. JSP도 서블릿으로 변환 되어 사용
5. 동시 요청을 위한 멀티 쓰레드 처리 지원