5. DNS + 웹 통신 흐름

TCP / IP 4계층 모델 - 애플리케이션 계층

: FPT, HTTP, SSH, SMTP, DNS 등 응용 프로그램이 사용되는 프로토콜 계층

 

DNS(Domain Name System Servers)

: 도메인 이름과 IP 주소를 저장하고 있는 분산 데이터베이스

- 웹 사이트를 위한 주소록

- 숫자로 된 IP 주소 대신 사용자가 사용하기 편리하도록 주소를 매핑해주는 역할

1. 분산 계층 데이터베이스

- 중앙 집중 데이터베이스는 서버의 고장, 트래픽 양, 먼 거리의 중앙 집중 데이터베이스, 유지 관리 등의 문제를 고려하면

-> 확장성이 없음

- So, DNS는 많은 서버를 이용해 계층 형태로 분산

1) 루트 DNS 서버

• 1000개 이상의 루트 서버 인스턴스가 전세계에 흩어져있음
• 루트 네임 서버는 TLD 서버의 IP 주소들을 제공

2) 최상위 레벨 도메인 네임(Top-Level Domain, TLD) DNS 서버

• com, org, net, edu, gov와 같은 상위 레벨 도메인과 kr, uk, fr와 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있음
• TLD 서버는 책임 DNS 서버에 대한 IP 주소를 제공

3) 책임(Authotitative) DNS 서버

• 조직의 자체 DNS 서버, 조직의 명명된 호스트에 대한 IP 매핑에 권한이 있는 호스트 이름을 제공

2. DNS query

- ISP(Internet Service Provider)의 DNS 서버(DNS Recursor)가 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날림

- 목적)

• DNS 서버들을 검색해서 해당 사이트의 IP 주소를 찾는 데에 있음
• IP 주소를 찾을 때까지 DNS 서버에서 다른 DNS 서버를 오가며 에러가 날 때까지 반복적으로 검색
• 재귀적 질의(Recursive Search), 반복적 질의(Iterative Query)

- 요청한 호스트에게 매핑 결과를 전달하기 위해 많은 질의 메세지가 필요

-> 질의 전송을 줄이기 위해 DNS 캐싱 방법을 사용

- EX)

• 'http://www.google.com' 주소에 대해 검색할 때,
  1. DNS recursor가 루트 DNS 서버에 요청
  2. .com 도메인 TLD 서버로 리다이렉트
  3. google.com 책임 DNS 서버로 리다이렉트
  4. 최종적으로 DNS기록에서 'http://www.google.com' 에 매칭되는 IP주소 찾기
  5. 찾은 주소를 DNS recursor로 보내기

3. DNS 캐싱

- DNS 지역 성능 향상과 네트워크의 DNS 메세지 수를 줄이기 위해서 캐싱을 사용

• DNS 서버가 DNS 응답을 받았을 때, 그것을 로컬 메모리에 응답 정보를 저장할 수 있음
• 호스트 이름과 IP 주소 쌍이 DNS 서버에 저장되면 처음 브라우저가 캐싱된 DNS를 확인하고 캐싱된 기록이 없을 때 DNS 질의로 넘어감
• 호스트 이름과 IP 주소 사이 매핑과 호스트는 영구적이지 않기 때문에 특정 기간마다 저장된 정보를 제거
• 브라우저에 입력된 도메인 이름을 통해 해당 도메인의 IP 주소를 얻은 뒤 통신을 시작할 수 있음

웹 통신의 흐름

1) 사용자가 웹 브라우저 검색창에 "www.google.com" 입력

 

2) 웹 브라우저는 해당 도메인 주소와 상응하는 IP 주소를 찾기 위해 캐싱된 DNS 기록을 확인

• 이때, 브라우저는 DNS 기록을 찾기 위해 BROWSER -> OS -> ISP 순으로 확인
• 이 단계에서 캐싱된 기록에 없을 경우, 다음 단계로 넘어감

3) 만약 캐시가 없다면 ISP의 DNS 서버는 IP 주소를 찾기 위해 DNS query를 시작

• DNS query는 IP 주소를 찾을 때까지 반복 -> RECURSIVE SEARCH

4) DNS가 웹 브라우저에게 찾는 사이트의 IP 주소를 응답

 

5) IP 주소를 받으려면 일반적으로 TCP 통신을 시작

• TCP 연결은 3-way handshake 과정을 통해서 만들어짐

6) HTTP 프로토콜로 요청

• TCP로 연결이 되면, 브라우저는 GET 요청을 통해 서버에게 "www,google.com" 웹 페이지를 요구함

7) 웹 어플리케이션 서버(WAS)와 데이터베이스에서 우선 웹 페이지 작업 처리

• 웹 서버 혼자서 모든 로직 처리 및 데이터 관리를 하게 되면 서버에 과부하가 일어날 가능성이 높음
• 그렇기에 서버의 일을 돕는 조력자 역할을 하는 것이 WAS

cf) 웹 서버 vs WAS

▶ 서버
: 클라이언트가 요청하는 서비스를 제공하는 프로그램 혹은 하드웨어

▶ 웹 서버
: 정적인 컨텐츠(HTML, CSS, IMAGE 등)를 요청받아 처리하여 제공하는 서버
- 웹 서버는 정적인 컨텐츠만 처리할 수 있기 때문에 동적 컨텐츠를 요청받았을 때 WAS에게 요청하고 응답받아 클라이언트에게 전달
- Apache Server, Nginx 등

▶ WAS
: 동적인 컨텐츠(JSP, ASP, PHP 등)를 요청받아 처리하여 제공하는 서버 
-> 주로 DB 서버와 함께 사용

8) WAS에서의 작업 처리 결과들을 웹 서버로 전송

 

9) 웹 서버는 웹 브라우저에게 HTML 문서 결과를 응답

• 응답 status code로 서버 요청에 따른 상태를 보냄
• 1xx : 정보만 담긴 메세지
• 2xx : response 성공
• 3xxx : 클라이언트를 다른 URL로 리다이렉트
• 4xxx : 클라이언트 측에서 에러 발생
• 5xx : 서버 측에서 에러 발생

10) 웹 브라우저는 HTML 컨텐츠를 표시

 

WAS(Web Application Server)

: 동적인 컨텐츠(JSP, ASP, PHP 등)를 요청받아 처리하여 제공하는 서버

- 정적 리소스 제공 가능

- 웹 서버(Web Server)와 웹 컨테이너(Web Container)가 합쳐진 형태

- HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어

- 주로 DB 서버와 함께 사용

- Tomcat, JBoss, Jeus, Web Sphere 등

- WAS 필요성)

• 웹 페이지는 정적 컨텐츠와 동적 컨텐츠가 모두 존재
• 사용자의 요청에 맞게 적절한 동적 컨텐츠를 만들어서 제공해야 함 -> 로그인 정보에 따라 화면에 표시되는 이름은 변경될 수 있음
• 이때, Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어놓고 서비스해야 함 -> 이렇게 수행하기엔 자원이 절대적으로 부족
• So, WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용할 수 있음

1. WAS + DB

- WAS는 동적, 정적 컨텐츠를 모두 제공할 수 있기 때문에 웹 서버(Web Server) 없이도 시스템을 구성할 수 있음

- But, WAS에 모든 역할이 부여되었을 경우 서버 과부하로 가장 비싼 애플리케이션 로직이 정적 리소스로 인해 수행이 어려울 수 있음

2. WEB + WAS + DB

- 정적 컨텐츠는 웹 서버가 처리하고, 동적인 애플리케이션 로직은 WAS에 요청

- 이렇게 시스템을 나누었을 때, 정적 리소스가 많이 사용될 경우에는 웹 서버를 증설하고 애플리케이션 리소스가 많이 사용될 경우에는 WAS를 증설하면 돼서 효율적인 리소스 관리를 할 수 있게 됨