정적 웹서버에서 MVC까지

 

1. 초기의 서버

 

왜 웹을 쓰는가?

1. 컴퓨터하나에 모든 정보를 담기에는 정보의 양도 많고 복잡도 증가
2. 원격지에 있는 정보를 가져와서 보고 싶음

 

그럼 서버가 뭐야?

1. 클라이언트가 요청하는 자료를 전달하는 프로그램

• 클라이언트는 자료가 있는 컴퓨터의 ip로 요청을 한다.
• 서버는 요청이 들어오면 자기 컴퓨터의 저장매체에서 해당 자료를 찾는다.
• 해당 자료를 읽어서 응답을 보내준다. html 혹은 파일

 

주요 서버 프로그램들은 뭐가잇어?

1. CERN httpd - 연구원 간의 자료 공유로 목적으로 시작
2. apache - 90 중반등장, 오픈 소스로 커뮤니티의 지원으로 가장 보편화 (프로세스 기반)
3. nginx -  00 이후 등장 (이벤트 기반 아키텍쳐)

 

 

클라이언트 요청의 다양성, 복잡성 증가

1. 기존에는 있는 파일을 달라는 요청을 했는데 더 많은 것을 원하게됨 (정적파일)
2. 동적으로 파일을 생성해서 전달해야하는 상황이 발생함 (페이지에 현재날짜표기 등)
3. 데이터를 저장하고 싶은 니즈도 발생함 (디비 저장)

 

 

초기 동적 페이징 웹서버 with CGI

1. 기존에 정적 파일만 처리하던 웹서버가 직접 동적 파일도 처리 하게됨
2. 웹서버가 클라이언트의 호출에 새로운 프로세스를 만들고 스크립트를 실행함
3. 해당 스크립트의 결과를 웹서버가 클라이언트에게 반환
4. 동적처리를 하는 스크립트와 웹서버의 호환성을 위해 cgi 도입
5. 하지만 클라이언트의 요청마다 프로세스가 만들어져서 부하 증가
6. 간단한 요청처리는 가능하나 디비 풀링, 세션관리 등은 추가 개발필요
6. 요즘은 동적 처리 니즈는 was에게 이관하고 웹서버는 정적처리 위주로

 

> 아파치와 perl 사용해서 실습해보기

 

 

 

---

 

 

2.  동적 요소 처리 서버

 

CGI 대신에 Servlet을 쓰자

1. 인터넷 사용자는 획기적으로 늘어났는데, 요청마다 프로세스를 만드는 방법(CGI)으로는 대응이 안됨
2. 자바 진영에서 Servlet이라는 인터페이스를 만듬
3. Servlet 명세는 Servlet api 와 컨테이너 동작명세를 갖는다.
4. 매번 프로세스를 만드는 cgi와 다르게 쓰레드 기반으로 운영
5. 동적처리만 전담하는 프로그램(웹컨테이너)을 하나 띄우고 그 프로그램이 동적 처리를 전담하고 웹서버는 다시 정적파일 처리만
6. 시스템이 커지면 웹 컨테이너 + @의 기능을 가진 WAS를 사용

 

 

웹 컨테이너

1. 서블릿을 사용하기 위한 프로그램
2. Servlet명세에 컨테이너의 동작 명세를 가지고 있다.
3. 컨테이너는 서블릿의 라이프사이클, 보안, 디비, 세션 등등을 핸들링함

 

 

TOMCAT(tomcat = 웹 컨테이너 + @)

1. 톰캣은 카탈리나, 코요테, 제스퍼, cluster, realm 등으로 구성되어있음
2. 웹컨테이너(카탈리나)는 서블릿의 생명주기를 관리
3. 웹컨테이너 이외에도 약간의 기능은 있으나 WAS로 분류하기는 기능이 약함.

 

 

시스템의 규모가 크다면 WAS ( WAS = tomcat + @ )

 

1. was는 기본적인 웹 컨테이너 기능 뿐만아니라 추가적인 엔터프라이즈 레벨의 기능을 갖음
2. 로드 밸런싱, 모니터링, 분산처리 등등

 

 

 

---

 

 

3.  서블릿과 서블릿 컨테이너

 

localhost:8080/test 요청이 발생한다면

1. http커넥터(coyote)가 http를 수신 받는다.
2. 요청을 기반으로 컨테이너(카탈리나)가 web.xml을 확인해서 서블릿을 확인
3. 초기에 1번 init으로 서블릿인스턴스 생성, 이후에 클라이언트 요청이 올 때마다 service 호출(HttpServletRequest, HttpServletResponse 을 받음)
4. 서블릿에서 처리된 결과를 정적서버 혹은 클라이언트로 반환

 

 

서블릿 컨테이너

1. 호스트 엔진: http 요청을 받음
2. 서블릿 라이프사이클 매니저: 서블릿 라이프 사이클 관리

 

 

서블릿

1. servlet 인터페이스를 준수하는 자바 코드
2. http 요청 메소드에 맞는 서블릿 메소드를 가지고 있음
3. httpReqest와 httpResponse를 받음
4. response에 있는 writer 메소드를 사용해서 html응답가능
5. 로직과 뷰가 혼재하는 상황이 발생 > 이후에 mvc로 발전
6. mvc에서 컨트롤러를 맡음

 

 

서블릿 라이프 사이클

1. load > instantiate > init(1번만) > service >> doGet, doPost (반복) > destroy (1번만)

 

2. 인터페이스

• service(req, res)
• init(config)
• destroy()

 

 

---

 

 

4.  MVC

 

서블릿 한곳에서 모두다

1. 처음에 서블릿에서 http 응답도 받고 데이터도 가져오고 view도 그림
2. 점점 복잡해짐 > 분리필요

 

MVC - Controller

 

1. 서블릿에서 html로직과 db 로직을 덜어냄
2. html로직은 view라고 칭하고, db + 비즈니스 로직을 model이라고칭함
3. 컨트롤러는 http 응답을 받아서 model에 요청을하고 
4. model로 부터 받은 값을 view에 전달
5. view와 모델은 서로를 몰라도 되게됨

 

 

MVC - Model

1. real-back-end 코드, 웹 이전의 레거시 코드가 단지 웹에 올라간것
2. 웹이 등장하기 전의 자바 코드들이라고 볼 수 잇다. 따라서 그냥 플레인 자바 코드로서 동작하게 만들어짐
3. 웹 혹은 서블릿과 관련된 내용은 빠지고 비즈니스 로직 + db 로직이 남는다.
4. 본인이 웹 프로그램인지 스탠드얼론 프로그램인지 조차 알필요가 없음
5. 모델 코드는 어느 웹에 종속적일 필요가 없음.

 

 

 

 

 

---

[이미지 출처]

https://www.flaticon.com/kr/free-icon/world-wide-web_1006771 (글 대표 이미지)