DNS(Domain Name System) 란?

도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인네임(www.example.com)을 네트워크주소(291.168.1.0)로 변환하거나, 그 반대의 역할을 수행하는 시스템이다.

1. 도메인 주소 exam.com을 브라우저에 입력하게 되면, 도메인 주소들을 가지고 있는 네임서버(DNS 서버)에 접속
2. 네임서버에 접속한 도메인(exam.com)과 연결된 IP 정보를 확인하고, IP를 사용자 PC에 전달
3. 사용자 PC는 전달받은 서버의 IP주소로 접속
4. 서버의 IP로 연결된 브라우저에 서버의 내용(홈페이지)을 출력

DNS 작동 원리

클라이언트가 도메인명을 브라우저에 검색하면, 먼저 도메인 정보가 저장된 네임 서버(DNS 서버)로 가서 도메인과 일치하는 IP주소로 가라고 지시하게 되고, 다시 그 IP주소로 접속하게 되면 홈페이지가 열린다.


이 때 도메인 & IP정보를 얻는 과정이 약간 복잡하다.
전세계에는 도메인 수가 너무나도 많기에 DNS 서버 종류를 계층화해서 단계적으로 처리한다.

DNS 동작 순서

1. 웹 브라우저에 www.naver.com 을 입력하면 먼저 PC에 저장된 Local DNS(기지국 DNS 서버)에게 'www.naver.com'이라는 hostname에 대한 IP 주소를 요청한다. Local DNS에는 "www.naver.com의 IP 주소"가 있을 수도 없을 수도 있다.
   • 만일 과거 접속했었다면 Local DNS에 접속정보가 캐싱되어 있어, 바로 PC에 IP 주소를 주고 끝난다.

Local DNS(기지국 DNS 서버):
    기본적으로 인터넷을 사용하기 위해서 IP를 할당해주는 통신사(KT, SK, LG 등...)에 등록하게 된다.
    컴퓨터의 LAN선을 통해 인터넷이 연결되면, 가입했던 각 통신사의 기지국 DNS 서버가 등록되게 된다.
    그러니까 KT를 사용하는 집이면 KT DNS이 되고, SK통신사 사용하는 집이면 SK DNS가 자동으로 셋팅된다.

2. Local DNS는 이제 'www.naver.com의 IP주소"를 찾아내기 위해 다른 DNS 서버들과 통신(DNS 쿼리)을 시작한다.
   먼저 Root DNS 서버에게 "www.naver.com"의 IP 주소를 요청한다.

Root DNS(루트 네임서버):
    Root DNS는 인터넷의 도메인 네임 시스템의 루트 존이다.
    ICANN이 직접 관리하는 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 한다.
    전세계에 961개의 루트 DNS가 운영되고 있다.

3. Root DNS 서버는 "www.navercom"의 IP주소를 찾을 수 없어 Local DNS 서버에게 "www.naver.com의 IP 주소를 찾을 수 없다고 다른 DNS 서버(TLD DNS 서버)에게 물어봐"라고 응답을 한다.

4. 이제 Local DNS 서버는 com 도메인을 관리하는 TLD DNS 서버(최상위 도메인 서버)에 다시 www.naver.com에 대한 IP주소를 요청한다.

TLD(Top-Level Domain, 최상위 도메인) DNS Server란?
    TLD는 도메인 등록 기관(Registry)이 관리하는 서버로, 도메인 네임의 가장 마지막 부분을 말한다.
    e.g. .com, .co.kr
    또한 Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 한다.

5. com 도메인을 관리하는 DNS 서버에도 해당 정보가 없으면, Local DNS 서버에게 "www.naver.com의 IP주소를 찾을 수 없어. 다른 DNS 서버(Authoritative DNS 서버)에게 물어봐"라고 응답한다.

6. Local DNS 서버는 naver.com DNS 서버(Authoritative DNS 서버)에게 다시 www.naver.com의 IP 주소를 요청한다.

Authoritative DNS Server
    실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버.
    그래서 권한의 의미인 Authoritative가 붙는다.
    일반적으로 도메인/호스팅 업체의 '네임서버'를 말하지만, 개인이나 회사 DNS 서버 구축을한 경우에도 여기에 해당하게 된다.

7. naver.com DNS 서버에는 "www.naver.com의 IP주소"가 있다. 그래서 Local DNS 서버에게 IP주소 222.122.195.6의 응답을 한다.

8. 이를 수신한 Local DNS는 www.naver.com의 IP주소를 캐싱을 하고 이후 다른 요청이 있을 시 응답할 수 있도록 IP주소 정보를 단말(PC)에 전달해준다.

이렇게 Root DNS -> TLD DNS -> Authoritative DNS의 과정 즉, Local DNS가 여러 DNS에 차례대로 
요청하여 그 답을 찾는 과정을 "재귀적 쿼리(Recursive Query)"라고 부른다.

DNS 서버 종류

1. 기지국 DNS 서버

인터넷을 설치시 각각 통신사가 있다. 그리고 각각의 통신사마다 DNS 서버가 존재한다.

2. Root DNS 서버

Root DNS는 최상위 DNS서버로 해당 DNS부터 시작해서 아래 딸린 node DNS 서버에게로 차례차례 물어보게 되는 구조로 짜여져 있다.

트리구조로 되어 있기에 모든 DNS 서버들은 이 Root DNS Server의 주소를 기본적으로 갖고 있다.
그래서 모르는 Domain Name이 온다면 가장 먼저 Root DNS에게 물어보게 되는 것이다.


Root DNS Server에서의 목록에도 해당 Domain Name의 IP 정보가 없다면 다음 DNS 서버의 IP값을 리턴하는데, 이를 TLD(최상위 도메인) 서버이다.
만일 google.com라면 ".com"을 관리하는 TLD 서버에게 물어보라고 정보를 주는 것이다.

3. TLD 서버(Top-Level Domain, 최상위 도메인 서버)

이 루트도메인 바로 아래단계에 있는 것을 1단계 도메인이라고 하며 이를 TLD(최상위 도메인)이라고 한다.
TLD(최상위 도메인은 국가명을 나타내는 국가 최상위 도메인과 일반적으로 사용되는 일반 최상위 도메인으로 구분된다.


도메인을 구입할 경우 1단계의 도메인 중에 하나를 선태갛고 원하는 도메인명을 지정하여 등록한다.

.biz : 사업 
.com : 영리 목적의 기업이나 단체 
.co.국가로 쓰기도 한다.(co.kr 등) 
.edu : 미국의 4년제 이상 교육기관
.info : 정보 관련 
.jobs : 취업 관련 사이트 
.name : 개인 사용자 
.net : 네트워크를 관리하는 기관 
.org : 비영리 기관

4. Second-level DNS 서버(2차 도메인)

Root DNS 서버에서 return한 TLD 서버주소를 기지국 DNS서버에서 받아서 다시 TLD 서버에 요청을 했었다.
그리고 TLD 서버에서는 Second-level DNS 서버를 return 해준다.


만일 naver.com이나 google.com을 요청했다면, TLD 서버에서 .com을 파악하고 그 앞에 달린 문자열을 보고 네이버나 구글 서버에 요청을 하는 것이다.


그렇게 요청 받은 Second DNS 서버는 자체적으로 sub 도메인 서버로 또 넘기게 된다.

5. Sub DNS 서버(최하위 서버)

서브 도메인 서버는 www. dev. mail. cafe. 등등을 구분하는 최하위 서버를 말한다.
naver 서버라도 그 안에서 네이버 홈, 메일, 블로그, 카페 등 여러 서비스가 있다. 이 서비스들을 구분하는 도메인 네임이라고 보면 된다.

정리

예를 들어 www.naver.com을 접속한다고 가정하자.

1. 사용자 브라우저: www.naver.com에 접속 시도
2. 로컬 DNS 캐시 확인: 캐시에 정보가 없으면 DNS 서버로 쿼리 전송
3. Root DNS 서버: '.com' TLD 서버 주소 반환
4. TLD DNS 서버: naver.com의 2차 DNS 서버 주소 반환
5. 2차 DNS 서버: www.naver.com에 대한 IP주소 또는 서브 도메인 서버 주소 반환.
6. 서브 도메인 서버: (필요한 경우)최종 IP주소 반환

DNS 서버는 다음과 같은 구조로 되어 있다.

DNS 문자열 구조

도메인 URI는 다음과 같이 구성되어 있다.
blog.naver.com. 에서 "blog"는 sub, "naver"은 Second-level, "com"은 Top-level, "."은 Root이다.


모든 Computer들은 Root domain DNS server의 IP 주소는 알고 있다.

• Root Domain을 담당하는 "DNS서버"에서는 TLD(Top-Level Domain)을 담당하는 서버목록과 IP를,
• TLD(Top-Level Domain)을 담당하는 DNS 서버는 Second-Level Domain을 담당하는 서버 목록과 IP를,
• Second-Level Domain을 담당하는 DNS 서버는 Sub Domain을 담당하는 서버 목록과 IP를 알고 있는 것이고,

결국, blog.naver.com의 IP주소는 Sub domain을 전담하고 있는 DNS 서버가 알고 있는 것이다.

DNS Cache

만일 위의 과정을 거쳐 www.gigigi.com의 IP 주소를 성공적으로 받았다고 하자.
몇 분후 다시 "www.naver.com"에 방문하려고 한다면, 또 다시 위의 같은 복잡한 과정을 반복해서 IP 주소를 받아오지 않는다.


그렇기에, PC에는 DNS Cache라는 Cache를 활용해 Cache안에 자주쓰는 Domain Name 주소를 저장해 놓는다.

출처

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

브라우저란?

웹 브라우저는 동기(Synchronous)적으로 (HTML + CSS), Javascript 언어를 해석하여 내용을 화면에 보여주는 응용 소프트웨어이다.

웹 브라우저가 웹 서버에 필요한 자원(웹 페이지)를 요청하면 서버는 응답하고 웹 브라우저는 이를 해석한 후 사용자(Client)에게 보여준다.
보통 자원은 HTML문서지만, PDF, 이미지 등 다양한 형태일 수 있다.

브라우저의 구조

1. 사용자 인터페이스(UserInterface)

사용자가 접근할 수 있는 영역. URI를 입력할 수 있는 주소 표시줄, 이전/다음 버튼, 북마크 메뉴, 새로 고침 버튼, 현재 문서의 로드를 중단할 수 있는 정지 버튼, 홈 버튼 등 요청한 페이지를 보여주는 창 등의 모든 부분

2. 브라우저 엔진

사용자 인터페이스와 렌더링 엔진 사이에서 중개자 역할을 한다.
사용자 인터페이스의 주소 입력창에 github.com 을 입력했다고 하자. 그 다음에는 브라우저 엔진이 작동하게 된다.
만약 자료 저장소(Data Storage)에 데이터가 없다면 입력받은 URI 값을 렌더링 엔진에 전달해준다.

• 웹 브라우저마다 전용 브라우저 엔진을 사용한다.
  1. Gecko: 파이어 폭스
  2. Webkit: 사파리
  3. Blink: 크롬, 오페라
  4. Trident: 마이크로소프트

-moz-border-radius: 1em; // 파이어폭스 브라우저에 적용
-ms-border-radius: 2em; // 익스플로어에 적용, 보통 생략
-o-border-radius: 3em; // 오페라에 적용
-webkit-border-radius: 4em; // 구글, 사파리 브라우저에 적용

3. 자료 저장소(Data Storage)

자료 저장소를 거치지 않고 URI를 입력할 때마다 서버로 가서 데이터를 받아오면, 불필요한 메서드 통신이 발생한다.
따라서 자료 저장소로부터 자주 다운로드 받는 데이터를 저장해두고, 사용할 때마다 서버로부터 데이터를 요청(통신)할 필요 없이 바로 받아올 수 있다. 캐싱이라고도 한다.

4. 통신

서버에게 HTTP 요청을 하고, 서버로부터 응답받은 데이터(HTML, CSS, JS)를 렌더링 엔진에 전달해준다.

5. 자바스크립트 해석기

자료 저장소 또는 통신 단계를 거쳐 데이터를 응답 받은 렌더링 엔진은 javascript 해석기를 통해 javascript를 파싱하게 된다.
Chrome에서는 V8이라는 javascript 엔진을 사용한다. 이것을 통해 javascript를 파싱하게 되는 것이다.

6. UI 백엔드

select, input 등 기본적인 위젯을 그리는 인터페이스이다.

7. 렌더링 엔진

렌더링 엔진은 요청받은 내용을 브라우저 화면에 표시해주는 역할을 한다. 브라우저마다 사용되는 렌더링 엔진이 각각 다르기에 모든 브라우저가 동일한 소스를 화면에 동일하게 그려주지 아니한다. 또한 엔진마다 읽을 수 있는 코드의 버전도 다르기에 크로스 브라우징(cross browsing) 이슈가 발생한다.

크로스 브라우징(cross browsing): 웹 페이지 제작 시 모든 브라우저에서 깨지지 않고 의도한 대로 올바르게 나오게 하는 작업을 말한다. 

렌더링 엔진의 동작 과정

'HTML 파싱 단계'와 '렌더 트리 구축, 배치, 페인팅' 단계는 병렬적으로 일어난다. 즉 DOM 트리가 완성이 되는 순간 바로바로 렌더 트리가 구축이 되고 그려지게 된다. 따라서 사용자는 DOM 트리가 완벽하게 구축될 때까지 기다릴 필요 없이 렌더 트리가 그려짐으로 인해서 브라우저가 렌더링 될 때 위에서부터 조금씩 표시되는 것이다.

1. DOM(Document Object Model), CSSOM(CSS Object Model) 생성 -> Parsing

• HTML을 파싱하여 DOM 노드를 만든다. 이 DOM 노드들을 병합하여 DOM 트리를 만든다.
• CSS를 파싱하여, CSSOM(CSS Object Model) 트리를 만들게 된다.

브라우저는 렌더링 할 문서를 HTML과 CSS로 나눠서 읽는데 각각 HTML Parser, CSS Parser가 담당한다. 이후 이들은 각각 Object Model을 만든다.

HTML 파싱과 DOM 생성 과정

1. 서버는 브라우저로부터 요청받은 HTML 파일을 읽은 후 메모리에 저장, 그리고 메모리에 저장된 바이트(1101010101010...)를 응답한다.
2. 브라우저는 응답받은 바이트 형태의 문서를 meta태그의 charset 속성에 지정된 인코딩 방식(UTF-8)에 따라 문자열로 반환
3. 문자열로 변환된 HTML문서를 이번에는 문법적 의미를 갖는 코드의 최소 단위인 토큰(token)으로 분해한다.
4. 토큰들의 내용에 따라 객체로 변환하여 각 노드들을 생성한다.(문서 노드, 요소 노드. 속성 노드, 텍스트 노드)
5. HTML은 요소 간의 부자 관계인 중첩 관계를 갖는데, 이를 반영하여 모든 노드들을 트리 구조로 구성하여 DOM을 만든다.

CSS파싱과 CSSOM 생성 과정

렌더링 엔진은 HTML 문서를 한줄 한줄 순차적으로 파싱하여 DOM을 생성. 이때 CSS를 로드하는 link태그, 혹은 style태그를 만나면 DOM 생성을 중지한 후 CSS파싱의 결과물인 CSSOM을 생성하는 과정을 진행

<!DOCTYPE html>
<html>
 <head>
  <meta charset="UTF-8"> // 여기까지 해석 후, 
  <link rel="stylesheet" href="style.css"> //link를 만나면 DOM생성을 중지하고 CSS파일을 서버에 요청한 후 응답받아 CSS파싱을 시작한다. 
  ...

css파싱 과정은 바이트 > 문자 > 토큰 > 노드 > CSSOM 생성 순으로 HTML의 파싱과정과 동일하다.

자바스크립트 파싱 과정

렌더링 엔진은 HTML 문서를 한 줄씩 순차적으로 파싱하다가 자바스크립트 파일을 로드하는 script 태그를 만나면 DOM 생성을 일시 중단한다.


script 태그의 src에 정의된 자바스크립트 파일을 서버에 요청하여 응답받으면 자바스크립트 코드를 파싱하기 위해 자바스크립트 엔진에게 제어권을 넘긴다.


자바스크립트 파싱이 끝나면 렌더링 엔진으로 다시 제어권을 넘기고 DOM 생성을 이어나간다.


만약 생성되지 않은 DOM을 조작한다면 에러가 발생할 수 있다. 따라서 body 요소 아래에 자바스크립트를 위치시키거나 DOM 생성이 완료된 시점에 자바스크립트가 실행되도록 한다.

1. 자바스크립트 코드를 토크나이저가 어휘 분석하여 문법적 의미를 갖는 코드의 최소 단위인 토큰들로 분해하는데 이것을 토큰나이징이라 한다.
2. parser가 토큰들을 구문분석하여 AST(Abstract Syntax Tree: 추상 구문 트리)로 파싱한다.
3. 바이트 코드 생성기가 AST를 바이트코드로 변환한다.
4. 인터프리터에 의해 바이트코드를 실행한다.

2. 렌더 트리 구축(Attachment)

CSSOM 트리와 DOM 트리를 결합하여, 표시해야 할 순서로 내용을 그려낼 수 있도록 하기 위해 렌더 트리를 형성한다. 이 과정을 Attachment라고 한다.


렌더 트리는 화면에 표시되는 각 노드의 위치를 계산하여 레이아웃에 사용되고 픽셀을 화면에 그리는 페인트 과정에도 사용된다.

렌더 트리의 생성을 위해 브라우저는 다음과 같은 작업을 한다.

1. DOM 트리의 루트부터 노드 각각을 모두 탐색한다.
   • 이 때 화면에 표시되지 않는 일부 노드들(script, meta 태그 등...)은 렌더 트리에서 제외된다.
   • CSS 속성 중 'display:none' 같이 화면에서 숨겨지는 속성도 렌더 트리에서 반영되지 않는다.
2. 화면에 표시되는 각 노드에 대해 적절하게 일치하는 CSSOM 규칙을 찾아 적용한다.
3. 화면에 표시되는 노드를 콘텐츠 및 계산된 스타일과 함께 렌더트리로 생성된다.

3. 렌더 트리 배치(Layout of Reflow)

렌더 트리가 생성되고, 기기의 뷰포트 내에서 렌더 트리의 노드가 정확한 위치와 크기를 계산한다.
이때 모든 상대적인 값이 픽셀값으로 변환된다. CSS에 상대적인 값 %, rem, vh으로 할당된 값들은 절대적인 값인 px 단위로 변환된다.
이러한 배치 과정을 Layout 또는 Reflow라고 한다.

4. 렌더 트리 그리기(Paint)

렌더 트리의 각 노드를 화면의 실제 픽셀로 나타날 때 Painting메서드가 호출된다. Painting 과정 후 브라우저 화면에 UI가 나타나게 된다.

웹서버와 WAS 서버의 비교

웹 서버

웹 브라우저 클라이언트로부터 HTTP 요청을 받아들이고 HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램

웹 서버는 사용자가 웹 브라우저에서 어떠한 페이지 요청을 하면 웹 서버에서 그 요청을 받아 정적 컨텐츠를 제공하는 서버이다. 여기서 정적 컨텐츠란 단순 HTML 문서, CSS, Javascript, 이미지, 파일 등 즉시 응답가능한 컨텐츠이다. 또한 웹 서버가 동적 컨텐츠를 요청 받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트(사용자)에게 전달해주는 역할도 한다.

대표적인 웹 서버로는 Apache가 있다.

웹 서버의 역할

웹 서버는 클라이언트가 웹 브라우저를 통해 요청한 정적 컨텐츠를 제공하는 역할을 한다. 웹 서버는 주로 HTTP 프로토콜을 사용하여 작동하며, 클라이언트가 URL을 통해 요청한 웹 페이지를 찾아 전송해준다.

e.g. 회사 홈페이지, 블로그, 뉴스 사이트 등

WAS 서버

인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별이 되며, 주로 DB 서버와 같이 수행한다.

WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태이다. 웹 서버 단독으로는 처리할 수 없는 DB의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다. WAS는 JSP, Servlet 구동환경을 제공해주기 때문에 웹 컨테이너 혹은 서블릿 컨테이너라고도 불린다.

대표적인 WAS 종류로는 Tomcat이 있다.

웹 컨테이너: 웹 서버가 보낸 JSP, PHP 등의 파일을 수행한 결과를 다시 웹 서버로 보내주는 역할을 함

WAS 서버의 역할

WAS 서버는 웹 애플리케이션을 실행하여 동적 컨텐츠를 생성하고, 웹 서버와 클라이언트 간의 데이터 처리를 담당하는 역할을 한다. WAS 서버는 클라이언트의 요청에 따라 DB에서 정보를 가져오거나, 웹 애플리케이션을 실행하여 동적인 웹 페이지를 생성한 후 결과를 웹 서버에 전달한다.
웹 서버는 이를 받아 클라이언트에게 전달한다.

e.g. 온라인 쇼핑몰, 은행 인터넷 뱅킹, SNS 등

Web Service Architecture

웹 어플리케이션은 요청 처리 방식에 따라 다양한 구조를 가질 수 있다.

1. 클라이언트(사용자) -> 웹 서버 -> DB
2. 클라이언트(사용자) -> WAS -> DB
3. 클라이언트(사용자) -> 웹 서버 -> WAS -> DB

Web Server와 WAS를 구분하는 이유

• Web Server가 필요한 이유: Web Server에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.
  • 클라이언트에 정적 컨텐츠(이미지, 문서...)를 보낸다고 하자. 이미지 파일과 같은 정적인 파일들은 웹 문서(HTML문서)가 클라이언트로 보내질 때 함께 가는 것이 아니다. 클라이언트는 HTML 문서를 먼저 받고 그에 맞게 필요한 이미지 파일들을 다시 서버로 요청하면 그때서야 이미지 파일을 받아온다.
  • Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.
• WAS가 필요한 이유: WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용할 수 있다.
  • Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어 놓고 서비스를 해야한다. 허나 이를 수행하기 위한 자원은 절대적으로 부족하다.
  • WAS가 Web Server의 기능도 모두 수행하면 되지 않는가?
    1. 기능을 분리하여 서버 부하 방지: 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라 수행 속도가 느려진다.
       2. 물리적으로 분리하여 보안 강화: SSL에 대한 암복호화 처리에 Web Server를 사용
       3. 여러 대의 WAS를 연결 가능
       • Load Balancing을 위해서 Web Server를 사용
       • fail over(장애 극복), fail back 처리에 유리
       • 큰 서비스의 경우 Web Server와 WAS를 분리하여, 또 여러 대의 서버를 사용하여 장애에 쉽게 대응할 수 있다.
       • 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

load balancing: 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법