[Web]웹개발에 필요한 지식들

웹개발 필수지식

이 게시글은 웹개발에 앞서 필요한 지식들에 대해 알아본다

Web Server vs. Web Application Server(WAS)

Web Server

• HTML, CSS, JS, 이미지 등등 정적 파일을 처리
• eg) NGINX, APACHE

Web Application Server(WAS)

• 애플리케이션의 요구에 따른 동적 로직을 주로 처리
• Web Server처럼 정적 파일을 처리하기도함
• eg) Tomcat, Jetty

=> 사실 웹은 WAS와 DB로만 구성되어도 작동가능하지만, 이럴 경우에 WAS가 동적로직 뿐만 아니라 정적 파일까지 처리하기 때문에 큰 부하가 걸림

=> Client요청을 WAS보다 Web Server가 먼저 받도록 하여 정적 파일을 처리하게 하고, WAS는 중요한 비즈니스 로직을 담당하도록 설계하여 WAS에 오류가 발생해도 Web Server측에서 오류화면을 띄워주면됨

Servlet

• 웹서버의 성능을 향상시키기 위해서 핵심 비즈니스 로직을 제외한 나머지를 처리하는 작업을 수행

• eg) 핵심비즈니스 로직을 제외한 TCP/IP 대기, HTTP 요청 msg 파싱하여 읽기, HTTP 응답 msg 생성하기 등의 작업을 수행함

• @WebServlet을 이용하여 특정 URL이 호출되면 그에 해당되는 코드가 수행되도록 작성
  • HTTP 요청 시마다 WAS가 Request, Response객체를 새로 만들어 Servlet객체를 호출함
  • 단, Servlet객체는 싱글톤 방식으로 최초 한번만 생성
  • HTTP 요청과 응답 정보를 손쉽게 사용할 수 있는 HttpServletRequest와 HttpServletResponse객체를 제공받아 사용
• Servlet 컨테이너가 @WebServlet을 통해 명시한 Servlet의 생명주기를 관리
  • Tomcat과 같이 Servlet을 지원하는 WAS를 Servlet 컨테이너라고 부름
• Servlet 객체는 싱글톤 방식으로 관리
  • 최초 시점에 객체를 생성하고 이후에 요청이 들어올때마다 재활용하는 방식이 싱글톤

멀티 쓰레드

쓰레드

• Client의 요청이 오면 쓰레드를 할당하여 Servlet을 호출하고 Servlet의 작업수행을 마치고 Client에게 응답을 완료하면 쓰레드는 휴식
• 여러 요청이 들어올 경우 2가지 방식으로 처리가능
  1. 모든 요청을 하나의 쓰레드로 처리
     • 먼저 온 요청을 처리하는 도중 오류가 발생하면 쓰레드는 해당 요청에 의해 대기중이기 때문에 이후에 온 요청들 처리에는 오랜시간이 소요됨
  2. 요청마다 쓰레드를 생성
     • 먼저 온 요청에 오류가 발생해 처리가 지연되어도 새로 쓰레드를 만들어 Servlet을 호출하면됨
     • 단, 쓰레드 생성비용이 비싸며 쓰레드가 많아질수록 응답속도가 늦어져 결국엔 Server가 죽을 수도 있음
• 위 2가지 방식 모두 단점이 존재하기에 해결책으로 나온 것이 쓰레드 풀을 이용하는 방식
  • 쓰레드 풀에 임의로 설정한 개수의 쓰레드를 두어 Client 요청 시마다 풀에서 쓰레드를 가져다 쓰도록 하고 응답 후에는 반납하는 방식
  • 쓰레드 풀의 쓰레드를 모두 사용중일 경우 이후에 들어오는 요청들은 대기하거나 거절하도록 설정가능
  • 쓰레드 풀을 이용하여 쓰레드 최대생성 개수를 설정하므로 요청이 무수히 들어와도 Server가 죽는 경우는 발생하지 않음
  • 쓰레드를 사전에 쓰레드 풀에 넣어놓기 때문에 쓰레드를 생성하고 종료하는 시간이 절약됨
• 실무에서 WAS의 주요 튜닝 포인트는 결국 쓰레드 풀을 얼마로 설정할 것인지에 있음
  • 쓰레드 풀을 적게 설정하면 상대적으로 적은 수의 요청만 동시에 처리가능하므로 CPU사용량이 적고 쓸데없이 많은 수의 Server를 증설해야됨
  • 반대로 많게 설정하면 CPU사용량이 한계점을 넘어 Server가 죽는 상황이 발생
  • 적정 쓰레드 풀을 설정하기 위해 실제 서비스와 유사하게 성능 테스트를 사전에 설정할 필요가 있음

=> 멀티 쓰레드는 WAS에서 알아서 처리해주기 때문에 개발자는 Servlet, Spring Bean등 싱글톤 객체들의 공유변수만 주의해서 사용하면됨

데이터 송수신방식

• Client와 Server간에 데이터를 송수신하는 방식은 크게 3가지로 나뉨

  1. 정적 리소스
     • HTML, CSS, 이미지 파일 등 정적파일을 제공
  2. 동적 리소스
     • Server에서 DB에 접근하는 등 처리를 거친 후에 동적파일을 제공
  3. HTTP API
     • HTML 형태가 아닌 JSON 형태의 데이터를 제공하는 방식
     • 크게 3가지 방식으로 나뉨
       1. Web Client to Server
       2. App Client to Server
       3. Server to Server

• HTML 최종결과를 Client에서 처리할 것인지 혹은 Server에서 처리할 것인지에 따라 SSR과 CSR로 나뉨

  1. Server Side Rendering
     • HTML 최종결과를 Server에서 만들어 웹브라우저에게 전달
     • 주로 정적인 화면에 사용함
     • eg) JSP, Thymeleaf
  2. Client Side Rendering
     • HTML 최종결과를 웹브라우저에서 JS를 이용하여 처리
     • 주로 동적인 화면에 사용함
     • eg) React, Vue

• HTTP 요청 msg를 통해 Client에서 Server로 데이터를 전달하는 과정을 크게 3가지로 나뉨

  1. Query Parameter(GET)

     • msg body 없이 URL의 query parameter에 데이터를 포함하여 전달하는 방식
     • msg body가 없기 때문에 Content-Type이 설정되지 않음
     • request.getParameter("파라미터명")를 통해 지정한 파라미터값을 가져올 수 있음
     • 검색, 페이징, 필터 등에서 사용

  2. HTML Form(POST)

     • msg body에 query parameter의 형식으로 데이터를 포함하여 전달하는 방식

     • Content-Type: application/x-www-form-urlencoded로 설정됨
     • 1번과 마찬가지 방식으로 request.getParameter("파라미터명")를 통해 지정한 파라미터값을 가져올 수 있음
     • 회원가입, 상품주문 등 Form 전송에서 사용

  3. HTTP msg body(POST, PUT, PATCH)

     • msg body에 데이터를 직접 담아서 전달하는 방식
     • HTTP API 방식에서 주로 사용하고 JSON 형식을 많이 사용
     • JSON 형식의 경우 Content-Type: application/json으로 설정됨

• HTTP 응답 msg를 통해 Server에서 Client로 데이터를 전달하는 과정은 크게 3가지로 나뉨

  1. 단순 Text
     • response.getWriter().println("응답텍스트");과 같은 방식으로 응답
  2. HTML Form
     • 응답으로 HTML을 반환하는 방식
     • Content-Type: text/html으로 설정
     • 한글을 사용하고 싶다면 charset=utf-8으로 설정
  3. HTTP msg body
     • HTTP API 방식에서 주로 사용하고 JSON 형식을 많이 사용
     • Content-Type: application/json으로 설정

Servlet과 JSP 그리고 MVC패턴

• Servlet
  • 응답으로 View화면을 띄우기 위해 HTML을 작성할때 Java코드로 HTML형식을 작성하기 너무 번잡함
• JSP
  • Servlet의 번잡한 코드를 해결하기 위해 JSP가 도입됨
  • JSP는 HTML코드를 기본으로 하고 코드 중간마다 <%, %>를 이용하여 Java코드를 동적으로 집어넣음
  • JSP에 수많은 비즈니스 로직들이 노출되어 유지보수가 힘들다는 단점
• MVC 패턴
  • Servlet과 JSP의 단점을 해결하기 위해 등장한 것이 MVC 패턴
  • 핵심 비즈니스 로직과 View(화면)을 처리하는 로직을 수정하는 과정은 따로 처리되는 경우가 많기 때문에 따로 관리하는 것이 유지보수에 용이함
  • 지금까지 하나의 Servlet 혹은 JSP에서 처리하던 것을 Controller와 View로 역할을 나눠 처리하는 방식
    • Controller: HTTP 요청을 받아 파라미터를 검증하고 비즈니스 로직을 처리하여 View에 전달할 데이터를 Model에 담는 역할
      • Controller에서 모든 비즈니스 로직을 처리하게 되면 Controller의 역할부담이 커지기 때문에 일반적으로 비즈니스 로직은 Service계층을 만들어 따로 처리하고 Controller는 Service를 호출하고 처리한 결과를 넘겨받음
    • Model: View에서 출력할 데이터를 담아 View에게 전달하는 역할
    • View: Model에서 받아온 데이터를 이용하여 화면을 만드는 역할

Front Controller

• MVC 패턴 역시 여전히 개선해야하는 부분이 존재하고 이를 개선하기 위한 해결책이 Front Controller
  • MVC 패턴에서 중복되는 코드들이 존재하고 여러 Controller에서 중복되는 공통 코드들이 존재할 수 밖에 없음
• Front Controller에 공통 코드를 담아 Client가 요청 시에 Controller에 진입하기 전에 Front Controller의 작업을 먼저 처리하도록 설계
• Front Controller 작업 처리 이후 상황에 맞는 Controller를 호출
• Front Controller만 Servlet으로 만들고 이외의 Controller들은 Servlet을 만들지 않아도됨