[컴퓨터 네트워크] 네트워크의 응용 계층 - DNS와 URI/URL

1. DNS와 URI/URL
2. HTTP의 특징과 메시지 구조
3.  HTTP 메서드와 상태 코드
4. HTTP 주요 헤더

 

1. DNS와 URI/URL

네트워크 상의 호스트를 식별하기 위해 기본적으로 사용되는 정보는 IP 주소입니다. 

그러나 IP 주소만을 사용하면 특정 호스트의 특징을 나타내기 어렵고, IP 주소는 언제든지 바뀔 수 있다는 문제가 있습니다.

-> 도메인 네임으로 해결

도메인 네임 (domain name)

 

 

특징

• 문자열 형태의 호스트 특정 정보이고, 호스트의 IP 주소와 대응됩니다.
• IP 주소에 비해 기억하기 쉽습니다.
• IP 주소가 바뀌더라도 바뀐 IP 주소에 도메인 네임을 다시 대응하면 되므로 IP 주소만으로 호스트를 특정하는 것보다 더 간편합니다.
• 도메인 네임과 그에 대응하는 IP 주소는 네임 서버(name server), DNS 서버(DNS server)라고 불리는 특별한 서버에서 관리됩니다.

네임서버

• 전 세계 여러 곳에 여러 개의 네임 서버가 존재합니다. because of 'single point of failure', 'traffic volume', 'distant centralized database', 'maintenance'
• 호스트는 네임 서버에 '특정 도메인 네임을 가진 호스트의 IP 주소가 무엇인지'를 질의함으로써 호스트의 IP 주소를 얻어낼 수 있습니다. 

         -> 'resolving한다' : IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정

 

 

 

 

#1 도메인 네임의 계층적 구조에 대해 알아보자

하나의 도메인 네임은 점(.)을 기준으로 계층적으로 분류됩니다.

www.example.com.

 

 

- 루트 도메인 (root domain)

• 도메인 네임의 마지막 부분에 점(.)으로 표현됩니다.
• 일반적으로, 도메인 네임을 표기할 때 루트 도메인(.)을 생략합니다.
• www.example.com.

• DNSSES에 의해 보안성을 보장받는다. 
• ICANN(Internet Corporation for Assigned Names and Numbers)과 루트 DNS 도메인을 관리한다.

- 최상위 도메인(TLD) (Top-Level Domain)

• 대표적으로 'com, net, org, kr' 등이 있습니다.
• www.example.com. 
• 직업, 박물관, 국가를 나타냄
• .kr : 한국인터넷정보센터

- 2단계 도메인(second-level domain)

• 최상위 도메인의 하부 도메인

- 3단계 도메인

• 2단계 도메인의 하부 도메인 
• 도메인의 단계는 일반적으로 3~5단계로 구성됩니다.

- Authoritative DNS servers

• Organization's own DNS servers, providing authoritative hostname to IP mappings for organization's named hosts
• can be maintained by organization or service provider

- 전체 주소 도메인 네임(FQDN)(Fully-Qualified Domain Name)

• www.example.com.
• 도메인 네임을 모두 포함하는 도메인 네임
• FQDN을 알면 호스트를 식별할 수 있습니다.

cf) 서브 도메인?

- 다른 도메인이 포함된 도메인

- mail.example.com, www.example.com, developer.example.com은 모두 'example.com'의 서브 도메인 

 

 

 

#2 네임 서버의 계층적 구조 

도메인 네임 시스템(DNS)(Domain Name System)

- 네임 서버는 분산되어 관리되는데, 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계를 말합니다.

- distributed database implemented in hierarchy of many name servers

- application layer protocol 

 

 

도메인 네임이 네임 서버를 바탕으로 어떻게 리졸빙될까?

1. 한 호스트가 fresh.net 이라는 도메인 네임을 통해 IP 주소를 알아내고자 합니다.

2. 먼저 로컬 네임 서버(local name server)에게 도메인 네임을 질의합니다.

3. 로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알고 있다면 클라이언트에게 즉시 해당 IP 주소를 반환합니다.

4. 로컬 네임 서버가 IP 주소를 모른다면, 로컬 네임 서버는 FQDN에 대응하는 IP 주소를 알아낼 때까지 도메인 네임의 루트 도메인을 관장하는 서버(루트 네임 서버)에게 질의합니다.

5. 그 다음은 TLD 네임 서버(TLD name server), 

6. 그 다음은 그 하위 레벨의 도메인 네임을 관장하는 네임 서버... 등에 걸쳐 질의합니다.

7. 최종적으로 클라이언트가 원하는 IP 주소를 반환받으면 해당 주소를 클라이언트에게 전달하게 됩니다.

 

▶ 리졸빙에는 iterated query와 recursive query가 있음. (위 설명과 같이 책에서는 recursive query를 말한 듯)

Iterated query : 클라이언트가 서버에게 쿼리를 보내면, 해당 DNS 서버가 직접 답을 찾지 못한 경우, 다른 DNS 서버의 주소를 클라이언트에게 알려주고,클라이언트가 다음 DNS 서버에게 직접 쿼리를 보내는 방식

recursive query : 클라이어늩가 서버에게 쿼리를 보내면, 해당 DNS 서버가 다른 DNS 서버에게 직접 쿼리를 보내서 최종 답을 찾은 후, 클라이언트에게 전달해주는 방식. 클라이언트는 처음 쿼리를 보낸 DNS 서버로부터 최종 답을 받게 됨. 

-> 즉, iterated query는 클라이언트가 여러 DNS 서버와 직접 소통하는 방식, recursive query는 처음 쿼리를 보낸 DNS 서버가 다른 서버와 소통해서 최종 답을 클라이언트에게 주는 방식~

 

 

 

 

 

-> 이 과정이 너무 많이 반복되면 트래픽이 많아지고, 오랜 시간이 걸립니다.

-> 해결: DNS 캐시(DNS cache) 

•  네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가, 추후 같은 질의에 활용하는 방법
•  클라이언트가 자주 접속하는 웹사이트와 같이 자주 질의되는 도메인 네임인 경우의 대부분이 로컬 네임 서버 선에서 캐시되어 있음. 
•  DNS 서버에 캐시된 값은 저마다 TTL(Time To Live)(캐시될 수 있는 시간) 값이 정해져 있음. (IP 헤더의 TTL 필드와 용어는 같지만 무관~)
• TLD servers은 일반적으로 local name servers 들에 캐시되어 있음. (따라서, 루트 네임 서버는 자주 방문되지 않음)
• IETF standard에 의해 update/notigy mechanisms

리졸빙에는 iterated query와 recursive query가 있음

 

 

 

로컬 네임 서버 local name server

• 클라이언트와 맞닿아 있는 네임 서버
• 클라이언트가 리졸빙할 때 가장 먼저 찾게 되는 네임 서버
• 클라이언트는 로컬 네임 서버의 주소를 알고 있어야 함. (대부분 ISP가 로컬 네임 서버의 주소를 자동으로 할당해 주지만, 공개 DNS 서버(public DNS server)를 이용할 수도 있음. 공개 DNS 서버의 대표적인 예는 구글의 8.8.8.8, 8.8.4.4, 클라우드플레어의 1.1.1.1)
• does not strictly belong to hierarchy
• each ISP(residential ISP, company, university) has one 
• default name server 라고도 불림

 

DNS 레코드 타입 

- 클라이언트가 IP 주소가 아닌 도메인 네임을 통해 내 서버와 상호작용할 수 있도록 하기 위해서는 도메인 네임을 구입해야 하는데, 이때 구입한 도메인 네임이 내 서버 IP 주소에 대응된다는 사실을 네임 서버에 알려야 합니다. 

- 네임 서버에 도메인 네임 관련 설정 정보를 추가해야 하는데, 이 정보가 바로 DNS 레코드(DNS resource record) 입니다.

- 모든 DNS 레코드에는 기본적으로 이름(Record name)과 그에 대응하는 값(Value), 그 <이름, 값> 쌍의 유형을 나타내는 레코드 타입(Record Type)도 포함되어 있습니다. (레코드 타입이 달라지면 레코드의 이름과 값의 의미가 달라져, 써 넣어야 할 내용도 사라집니다.)

- DNS 레코드가 캐시될 수 있는 시간인 TTL도 설정 가능합니다.

레코드 유형	설명
A	특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
AAAA	특정 호스트에 대한 도메인 네임과 Ipv6 주소와의 대응 관계
CNAME	호스트 네임에 대한 별칭 지정
NS	특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
MX	해당 도메인과 연동되어 있는 메일 서버

 

레코드 유형	이름	값	TTL
A	example.com	1.2.3.4	300
CNAME	www.example.com	example.com	300

- 두번째 레코드 유형 : example.com에 대한 별칭(CNAME)으로 www.example.com을  사용하겠다는 의미 이므로, www.example.com을  질의하면 1.2.3.4를 응답받게 됨.

 

 

 

 

 

자원과 URI/URL

 

자원(resource)

• 네트워크 상의 메시지를 통해 주고받는 최종 대상 (html 파일, 이미지, 동영상, 텍스트 파일 등등)

 

URI(Uniform Resource Identifier)

• 웹 상에서의 자원(Resource)를 식별(Identifier)하는 통일된 방식(Uniform)
• URN(Uniform Resource Name)(이름 기반 식별)과 URL(Uniform Resource Locator)(위치 기반 식별)이 존재합니다.
• URN보다는 URL이 더 많이 사용되는 방식.

 

URL(Uniform Resource Locator)

foo://example.com:8042/over/there?name=ferret#nose

 

- scheme

• 자원에 접근하는 방법을 나타냅니다.
• 일반적으로 사용할 프로토콜이 명시됩니다. 
• scheme이 http://일 경우, HTTP를 사용하여 자원에 접근함을 나타내고, https://일 경우 HTTPS를 사용하여 자원에 접근함을 나타냅니다.
• foo://example.com:8042/over/there?name=ferret#nose

- authority

• 호스트를 특정할 수 있는 IP주소나 도메인 네임이 명시됩니다.
• 콜론 뒤에 포트 번호를 명시할 수도 있습니다.
• foo://example.com:8042/over/there?name=ferret#nose

- path

• 자원이 위치하고 있는 경로가 명시됩니다.
• / 를 기준으로 계층적으로 표현됩니다. (최상위 경로 또한 슬래시로 표현)
• foo://example.com:8042/over/there?name=ferret#nose

 

- query

• URL에 대한 매개변수 역할을 하는 문자열입니다.
• scheme, authority, path만으로는 표현하기 어려운 추가 정보입니다.
• ex) 단어 목록 중에서 '특정 단어를 검색한 결과'에 해당하는 자원, 상품 목록 중에서 '특정 상품을 검색한 뒤 그 결과를 내림차순으로 정렬한 결과'
• ? 로 시작되는 <키=값> 형태의 데이터로, &를 사용하여 여러 쿼리 문자열을 연결할 수 있습니다.
• 쿼리 문자열(query string), 쿼리 파라미터(query parameter) 라고도 불립니다.
• foo://example.com:8042/over/there?name=ferret#nose

- fragment

• 일반적으로 HTML 과 같은 자원에서 특정 부분을 가리키는 데 사용됩니다.
• foo://example.com:8042/over/there?name=ferret#nose

 

http://example.com/home/images/a.png 

-> http 프로도콜로 접근 가능한 도메인 네임 example.com의 자원 중 /home/images/a.png에 위치한 자원 

 

 

DNS query and reply messages Format

• DNS query와 reply messages 모두 같은 메시지 형식을 사용한다.
• message header에는 identification과 flags로 구성된다.
• identification : 16 bit # for query, reply to query uses same #
• flags : (QR-Query or Reply) (RD-Recursion Desired) (RA-Recursion Available) (AA-reply is Authoritative Answer)