스프링/3. 스프링 MVC 54

4. 서버의 클라이언트에게 제공 방식

그냥 거의 파일만 불러와서 보여주는 거. 동적. 여기서는 WAS에서 직접 html을 만들어서 클라이언트에게 보내줌. html이 아니라 json같은 데이터를 전달하는 거. 거의 json임. 거의 이런 식으로 웹 클라이언트, 앱 클라이언트 등 데이터만 받아와서 뿌려주기만 하면 되는 것 들. 아니면 서버 to 서버 주문 서버 -> 결제 서버 등 SSR 서버 사이드 렌더링. 서버에서 아예 html을 만들어서 주는거임. CSR 클라이언트 사이드 렌더링. html을 js를 통해 웹 브라우저에서 동적으로 생성해 적용.

3. 멀티쓰레드

쓰레드 하나만 사용 시. 요청이 오면 쓰레드 할당 쓰레드란 코드를 한줄 한줄 순차적으로 실행하는 게 쓰레드 동시처리가 필요하면 추가로 쓰레드 생성 다중 요청 시 쓰레드 하나일 경우 이래서 막 몰리는 서버 들어가면 저거 순차적으로 응답 대기하느라 그럼. 저러다 타임아웃.. 요청마다 쓰레드 새로 생성하여 처리 이것도 장단점이 있음 단점은 쓰레드 생성 비용이 비쌈. 그리고 멀티쓰레드 라고 해서 이것도 사실 동시에 처리하는게 아니라 코어가 순차적으로 처리 하는거임. 근데 이 스윗칭 할 때도 비용이 있음. 또 쓰레드 생성에는 제한이 없어서, 하드웨어 임계점을 넘어버리면 서버 죽을 수 있음 그래서 방법이 그 풀 맞음. 객체 삭제는 너무 비용이 많이 드니, 미리 만들어 놨다가 요청 들어올 때 현재 동작중이지 않은 쓰..

2. 서블릿

만약 처음부터 끝까지 웹 요청에 응답하는 서버를 만들면 저렇게 할 일이 많음. 근데, 만약 서블릿을 사용하면 저 초록색만 내가 하면 됨. /hello 라는 url로 들어오면, 저 service라는 메소드를 실행 요청에 대한 정보는 HttpServletRequest request에서 쉽게 알 수 있고, 응답의 제공은 HttpServletResponse response를 통하여 손쉽게 할 수 있다. response에다가 내가 원하는 데이터를 넣으면 된다. /hello로 들어오면, 그 /hello 써놨던 객체의 service가 실행됨. 거기서 request 객체에서 요청으로 들어온 파라미터들을 제공받고, 나는 내가 응답하고 싶은 데이터를 response에 추가 시키면 됨. 따로 service에서 return ..

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

웹서버의 역할은 기본적으로 html을 보내서 브라우저가 그걸 받아 내 브라우저에 뿌려준다. 웹 서버, 웹 애플리케이션 서버(톰캣 등의 애플리케이션 기반으로 동작하는 서버)차이는 그냥.. 더 어떤 로직이나 코드 읽는데 특화된거다. 보통 웹서버는 정적인것으로 보고, WAS(Web Application Server)는 뭔가 html을 사용자마다 바꿔서 뿌려줄 수 있는데, 동적인 것으로 봄. 근데 위의 방식으로 해 놓으면, 문제가 있음. WAS가 너무 많은 역할을 담당하기에 서버 과부하 우려. 거기다 WAS아예 장애나서 꺼질 시 오류 화면 노출도 불가능 함. (사람이 만든 거기에 생각보다 오류 자주 난다고 함.) 정적 리소스는 아예 웹서버가 처리하도록 하고, 거기서 동적인 것이 필요한 것만 WAS에게 요청해서 ..