HTTP

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

웹 서버

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가기능
• 정적(파일) HTML, CSS, JS, 이미지, 영상

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

• HTTP 기반으로 동작
• 웹 서버 기능 포함+ (정적 리소스 제공 기능)
• 프로그램 코드를 실행해서 애플리케이션 로직 수행
  • 동적 HTML, HTTP API(JSON)
  • 서블릿, JSP, 스프링 MVC

웹서버와 WAS 차이

• 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직

• 둘다 비슷함

  • 웹 서버도 프로그램 실행하는 기능 있음
  • 웹 애플리케이션 서버도 웹 서버 기능 있음

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

웹 시스템 구성 - WAS, DB

• WAS, DB 만으로 시스템 구성 가능
  
• WAS가 너무 많은 역할을 담당, 서버 과부하 우려
• 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
• WAS 장애시 오류 화면도 노출이 안됨.

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

그래서 일반적으로 이와 같이 사용한다.

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

장점

효율적인 리소스 관리가 가능해진다.

• WEB이 많이 사용되면 Web 서버 증설 WAS는 WAS 증설

• 정적 리소스만 제공하는 웹 서버는 잘 안죽음
• WAS는 잘죽음
• 하지만 WAS가 죽었을때 Sorry 같은 오류화면을 제공할 수 있음

서블릿

HTML Form 데이터 전송

POST 전송 - 저장

서블렛이 서버에서 처리해야 하는 업무의 대부분을 처리해준다.

클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술

특징

• urlPatterns에 있는 /hello라는 URL이 호출되면 코드가 실행된다.
• request를 통해 username, age 등의 정보를 가져올 수 있다.
• reponse를 통해 응답 정보를 제공해줄 수 있다.
• 개발자는 HTTP 스펙을 매우 편리하게 사용

하지만, 기본적은 HTTP 스펙은 꼭 인지하고 사용하는 것이 좋다.

서블릿 컨테이너

톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
서블릿 객체는 싱글톤으로 관리

• 공유 변수 사용 주의
  동시 요청을 위한 멀티 쓰레드 처리 지원

동시요청 - 멀티 쓰레드

쓰레드

• 애플리케이션 코드를 하나하나 순차적으로 실행하는 것
• 메인을 실행하면 main이라는 이름의 쓰레드가 실행

다중 쓰레드

요청마다 쓰레드를 생성한다면
장점

• 동시 요청을 처리할 수 있다.
• 리소스(CPU, 메모리)가 허용할 때까지 처리 가능
• 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 작동한다.

단점

• 비싸다. 무겁다.
• 컨텍스트 스위칭 비용이 발생한다. (쓰레드를 이동할때 발생하는 비용)
• 제한이 없기 때문에 너무 많이 만들면 서버가 죽어버린다.

쓰레드 풀

특징

• 픨요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
• 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. 톰캣은 최대 200개 기본 설정(변경 가능 - 톰캣 맥스 커넥션 등등 검색해서 찾아보면 됨)

사용

• 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.
• 사용을 종료하면 쓰레드 풀에 반납
• 쓰레드가 다 사용중이여서 쓰레드가 없으면 거절하거나 특정 숫자만큼 대기하도록 따로 설정가능

실무팁

• WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.

• 이 값을 너무 낮게 설정하면?
  동시요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연

설정을 그냥 잘못한 것이다.

• 이 값을 너무 높게 설정하면?
  서버가 죽어버릴 수 있다.

그럼 적정 숫자를 어떻게 찾지?
상황에 따라 다 다르다. 프로도 알 수 없기 때문에 대략적으로 감으로 잡는 것.
그렇기 때문에 성능 테스트가 필요하다.

• 최대한 실제 서비스와 유사하게 성능 테스트 시도
• 툴: 아파치 ab, 제이미터, nGrinder

정리

멀티 쓰레드 지원의 핵심

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

HTML, HTTP API, CSR, SSR

정적 리소스

고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공하면 된다.

주로 웹 브라우저

/hello.html을 요청했을때 웹 서버에서 이미 생성된 리소스 파일을 그대로 주면 된다.

HTML 페이지

동적인 HTML 페이지를 보낼 수 있다.

애플리케이션 로직을 수행할 수 있는 WAS가 데이터베이스에서 주문 정보를 조회하고 그 결과를 동적으로 JSP나 타입리프 등을 이용해 HTML 생성을 한다. 그러면 웹 브라우저는 이 HTML을 해석해서 우리에게 보여준다.

HTTP API

HTML이 아니라 데이터를 전달해준다. 주로 JSON 형식을 사용한다.
다양한 웹 브라우저에서 사용한다.

데이터만 주고받고, UI 화면이 필요하면 클라이언트가 처리하는 방식이고
HTTP API는 3가지 상황에서 주로 사용된다.

1. 앱 개발자가 UI는 컴포넌트로 알아서 만들기 때문에 상품에 대한 데이터만 받고 싶을때 WAS서버로 주문 데이터를 바로 받을 수 있다.

2. 웹 브라우저에서 AJAX등을 이용해 WAS 서버에서 데이터를 받아올 수 있고 자바 스크립트가 이를 조합하여 결과를 나타낼 수 있다. (이를 잘 사용하기 위해 React, Vue.js 등등이 나옴)

3. 주문 서버와 결제 서버가 서로 통신을 해야할 때 데이터만 주고받으면 되기 때문에 이때도 사용된다.

 

그래서 개발자는 3가지를 고민해야 한다.

• 정적 리소스 어떻게 제공할거야
• 동적 HTML 페이지 어떻게 제공할거야
• HTTP API를 어떻게 제공할거야

이 3가지 방식에 대하여 어떻게 할것인가 고민을 해야 한다.

서버 사이드 렌더링, 클라이언트 사이드 렌더링

SSR - 서버 사이드 렌더링

웹 브라우저에서 서버로 요청을 보내면 서버에서 데이터베이스를 조회하여 결과를 이용해 동적으로 HTML을 생성하여 웹 브라우저로 보내면
웹 브라우저는 이 HTML을 렌더링하여 보여준다.
이처럼 서버에서 만들고, 웹에서 보여주는 방식을 SSR(서버 사이드 렌더링)이라고 한다.

• 관련기술: JSP, 타임리프 -> 백엔드 개발자

CSR - 클라이언트 사이트 렌더링

웹 브라우저에서 HTML을 요청하면 빈 HTML파일을 주고 대신에 자바스크립트 링크를 준다. 그러면 웹 브라우저는 자바스크립트를 요청하게 되고 여기서 클라이언트 로직을 통해 HTML 렌더링을 하고 다시 보내면 웹 브라우저는 HTTP API를 통해 데이터 요청을 한다. 그러면 데이터베이스에서 데이터를 조회해 온것을 HTML 렌더링한 코드를 통해 웹 페이지가 동적으로 생성된다.

HTML 결과를 자바 스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용하는 것이다.

앱처럼 필요한 부분부분을 변경할 수 있다.
예) 구글 지도

• 관련기술: React, Vue.js -> 웹 프론트엔드 개발자

 

참고로 CSR + SSR을 동시에 지원하는 웹 프레임워크도 있고,
SSR에서도 자바스크립트를 사용해서 화면 일부를 동적으로 변경할 수도 있다.

어디까지 알아야 하느냐

백엔드 개발자 입장에서 UI 기술

• 백엔드 - 서버 사이드 랜더링 기술
  • JSP, 타임리프 - 새로 배운 사람들은 타입리프 쓰는게 좋다. 스프링이 밀고 있어서
  • 금방할 수 있다.
  • 백엔드 개발자는 서버 사이드 렌더링 기술 학습 필수
• 웹 프론트엔드 - 클라이언트 사이드 렌더링 기술
  • React, Vue.js
  • 복잡하고 동적인 UI 사용
  • 웹 프론트엔드 개발자의 전문 분야
• 선택과 집중
  • 백엔드 개발자의 웹 프론트엔드 기술 학습은 옵션
  • 백엔드 개발자는 서버, DB, 인프라 등등 수많은 백엔드 기술을 공부해야 하므로 이것만 해도 벅차다
  • 웹 프론트엔드도 깊이있게 잘 하려면 숙련에 오랜 시간이 필요하다.

풀 스택에 대한 환상은 실무를 하면 깨진다. 진짜 풀스택을 잘하는 사람은 손에 꼽을 정도로 몇 없다.

백엔드는 어차피 프론트엔드의 지식을 어느 정도 알고 있긴 해야한다. 그러므로 딱 그 정도의 공부는 해두는 것이 좋다.

자바 백엔드 웹 기술 역사