[Server] 정적 페이지 vs 동적 페이지

원래 Java는 웹 개발을 할 수 있는 언어가 아니다. 근데 우리는 어떻게 자바로 웹 개발을 할 수 있을까?

바로 '웹 구현' 이라는 확장팩을 설치했기 때문에 자바로 웹 개발이 가능한 것이다!

 

서블릿(Servlet)은 자바(JDK, JRE) 베이스에 웹 구현 기능(.jar)이 추가된 것이다.

❓ 나도 모르는 새에 웹 구현 기능.jar은 언제 설치가 되었을까?

⇒ 아파치 톰캣이 가져왔다!!

💡 아파치 톰캣의 역할

• 웹 서버의 역할
• 자바로 서블릿 or JSP를 구현할 수 있는 수많은 *.jar 파일 제공
• 서버 측에서 서블릿과 JSP를 동작하게 만드는 역할

 

💡 아파치 vs 톰캣
: 사실 아파치와 톰캣은 서로 다른 프로그램이다.
- 아파치: 웹 서버 → 정적인 페이지 → 페이지를 요청받으면 찾아서 돌려주는 역할 ⇒ 굉장히 단순한 역할
- 톰캣: 응용 프로그램 서버(Web Application Server, WAS), 서블릿 컨테이너 → 동적인 페이지

 

정적 페이지 vs 동적 페이지

💡 .html: 정적인 페이지

         .do: 동적인 페이지

⇒ 클라이언트는 특정 페이지를 봤을 때, 해당 페이지가 정적 vs 동적인 페이지 중 무엇으로 만들어졌는지 구분하지 못한다.
But 2개의 상이한 페이지가 우리에게 도달해서 올 때까지의 과정은 상이하다.

이제부터 페이지가 우리에게 도달해서 오는 과정을 알아보자!

 

 

 

정적인 페이지

1. 우리가 웹 클라이언트(브라우저)에 URL을 입력하면

2. 웹 클라이언트(브라우저)가 웹 서버(아파치)에게 요청을 한다. → HTTP Request

3. 웹서버는 해당 페이지를 검색을 해서 찾고

4. 페이지의 확장자를 확인한 후,

5. 소스를 읽는다.

6. 읽은 소스를 별도 처리 없이 웹 클라이언트(브라우저)에게 응답(전달)하고 → HTTP Response

7. 웹 클라이언트(브라우저)는 우리의 컴퓨터 하드디스크에 해당 페이지의 캐시를 저장한다.

8. 하드디스크에 저장한 캐시를 불러와 페이지를 실행하여 사용자(우리)는 페이지를 볼 수 있다.

 

 

 

 

동적인 페이지

1. 우리가 웹 클라이언트(브라우저)에 URL을 입력하면

2. 웹 클라이언트(브라우저)가 웹 서버(아파치)에게 요청을 한다. → HTTP Request

3. 웹서버는 해당 페이지가 있는지 mapping 정보를 확인한 후

4. 자바 소스 파일을 찾아서

5. 컴파일을 진행한다.

6. 컴파일 후 해당 자바 클래스 파일을 실행하여

7. doGet 메서드를 호출한다.

8. doGet메서드가 반환한 동적 페이지를(서블릿이 만든 결과물에는 java 코드가 들어가지 않는다. 결과물에는 HTML 페이지만 존재한다. → java는 서버 측에서 이미 실행했고, HTML은 브라우저가 받아서 실행할 것이기 때문)

9. 웹 서버(톰캣)에 전달한 후,

10. 웹 서버는 웹 클라이언트(브라우저)에게 응답한다.  → HTTP Response

11. 웹 클라이언트(브라우저)는 우리의 컴퓨터 하드디스크에 해당 페이지의 캐시를 저장한다.

12. 하드디스크에 저장한 캐시를 불러와 페이지를 실행하여 사용자(우리)는 페이지를 볼 수 있다.

 

동적인 페이지를 위의 과정을 통해 한 번 실행 후, 재 실행한다면 4~6번 과정은 재 실행되지 않는다.(Why? 실행 파일을 어디엔가 살려두었기 때문이다.) 따라서 3번 과정 후에 7번 doGet 메서드 호출이 진행된다.

 

❓ 왜 서버 측에서는 별도 처리 없이 소스 그대로 돌려줄까?

   : HTML, CSS, JavaScript 언어는 실행하는 주체가 브라우저이다. 일을 처리하는 주체인 브라우저가 클라이언트이기 때문에 별도 처리 없이 소스 그대로 돌려준다!(웹 서버의 입장에서는 저 코드들이 이해할 수 없는 코드라고 인식을 하기 때문!)

❓ 왜 하드디스크에 저장을 해서 실행할까?

   : 과거에는 회선이 굉장히 느렸었다. 방금 껐던 창을 다시 불러오는 등의 행위로 페이지가 재 실행 될 때마다 불러오는데 많은 시간이 소요되었다. → 비효율적

따라서 브라우저는 한 번이라도 열람한 자원들을 나의 하드디스크 캐시에 저장을 한 후, 페이지 재 방문 시 이를 재활용한다. 페이지를 방문하면 하드디스크의 캐시를 먼저 돌면서 캐시를 불러오고, 만일 캐시가 없다면 새로 불러오는 방법을 채택하게 된 것이다.

✓ 캐싱의 장점: 실행 속도가 빠르다, 트래픽이 발생되지 않아서 회선 비용도 절감할 수 있다.

❓ 그렇다면 회선이 빨라진 지금은 왜 아직 이 방법을 사용할까?
: 회선이 빨라진 만큼 주고받는 데이터의 크기도 커졌기 때문에 아직 이 구조가 물리적으로 유효하기 때문이다.