스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - ~ 섹션1. 웹 애플리케이션 이해

현재 인터넷은 대부분 HTTP로 통신한다. 앞에서 배웠던거.

웹서버는 이 클라이언트에서 온 HTTP 요청을 형식에 알맞게 응답해주는 것 뿐이다.

 

웹서버는 종류가 정적인 파일만 다루었던 그냥 웹 서버(nginx 등), 실제로 코드를 실행시켜서 매번 다른 결과를 반환해줄 수 있는 동적 웹 서버(Web Application Server)(스프링 MVC등)가 있다. 요즘은 둘 다 어느정도 할 줄 알아서 경계가 애매하긴 하다.

따로 두면 좋은점이, WAS는 코드를 실행하다보니 자주 죽는걸 방지겸 업무 분담해서 부담을 좀 줄일 수 있다. 그리고 각자가 필요한 부분만 확장시켜서 사용 가능.

 

아까 위에서 웹 서버는 HTTP 요청이 오면 알맞은 HTTP 응답을 보내는 것이라고 했는데, 요청 내용 POST /save이런 string들 분해해서 알아내고 응답메세지는 또 만들고... 해야된다. 너무 반복되는 내용이다 보니 이걸 서블릿이라는 애가 자동으로 해줌.

웹 브라우저에서 요청이 오면 웹 서버에선 request 인스턴스와 response 인스턴스를 만들고 코드를 실행시킨 뒤 그 코드의 결과물을 아까 생성한 response에 담아 전달해준다. 즉, 웹 서버는 서블릿의 컨테이너이기도 함.

자원 낭비를 줄이기 위해 기본적으로 싱글톤으로 사용되서 공유 변수를 주의해야 한다.

 

 

멀티쓰레드는 뭐냐면 일단 쓰레드가 실제 코드를 한 줄 한 줄 실행하는 놈인데 그게 여러개 있는거다. 진짜 한개만 있으면 하나 요청하느라 다른요청은 못봐준다.

그래서 다중 쓰레드를 하는것인데, 요청할 때마다 쓰레드를 생성하는 방법과, 일정 양 만큼만 생성하는 쓰레드 풀 방법이 있다. 요청할 때마다 생성하면 CPU가 허용할 때까지 처리할 수 있고 동시처리를 잘 하지만, 컨텍스트 스위치가 너무 자주 일어날 수 있고(cpu 안에 있는 코어 개수가 사실 동시 한계니까) 너무 많은 요청이 일어나면 서버가 죽는다. 쓰레드 풀은 미리 생성해놔서 풀에 보관중이므로 빨리 실행되서 반응속도가 빠르고 안전하다.

쓰레드 풀 방식을 사용할 것인데 WAS가 관리할 것이다. 그럼 최대 몇 개의 쓰레드를 허용할 것인가를 조절 포인트로 한다. 이건 WAS가 알아서 하니 개발자는 굳이 신경 쓸 필요 없다.

 

 

그 다음은 HTML, HTTP API, CSR(클라이언트 사이드 렌더링), SSR(서버사이드 렌더링)을 설명해주는데, 정적 리소스는 이미 서버에 저장되어 있는 html, javascript, css등을 그냥 읽어오는 것이고, html은 요청이 들어오면 WAS가 html 자체를 만들어서 클라이언트에게 주는 것. HTTP API는 클라이언트가 html과 javascript를 가지고 있어서 서버에서 정보만(json 등) 주면 알아서 화면을 표현하는 것이다.

 

서버 사이드 렌더링은 HTML 자체를 주는 건 같지만, 코드가 작동해서 나오는 동적 HTML 결과를 주는것. 클라이언트 사이드 렌더링은 클라이언트는 서버에서 HTML, javascript를 요청해서 가지고 있고 후에 서버에서 정보를 보내주면 그걸 기반으로 HTML를 만든다.

 

 

자바 뷰는 HTML를 편리하게 생성하는 뷰 기능인데 타임리프(Thymeleaf) 쓰라고 함