박시은

(❁´◡`❁)

5 분 소요


[혼자 공부하는 네트워크↗️], 컴퓨터 네트워킹: 하향식 접근 (제8판)을 바탕으로 정리한 글입니다.

  • 이번 포스팅에서는 네트워크 상에서 호스트를 식별할 수 있는 방법 중에 하나인 Host Name과, 호스트 네임을 관리할 수 있는 체계인 DNS에 대해 알아보자.
  • 그리고 네트워크를 통해 주고받을 수 있는 정보의 일환인 자원이란 무엇인지, 네트워크 상에서 자원을 어떻게 식별할 수 있는지 URL에 대해 살펴보자.


1. 메시지 송수신의 기본 요소

1.1 송수신지 파악

  • 메시지를 주고받기 위해 송수신지를 특정해야 한다.
  • IP 주소와 도메인 네임이 이를 담당한다.


1.2 송수신 정보 파악

  • 송수신하려는 자원(resource)을 파악해야 한다.
  • 자원은 주고받는 정보를 의미하며, 이를 URI로 식별한다.



2. 도메인 네임과 네임 서버

2.1 도메인 네임의 필요성

  • IP 주소는 변경 가능하며 기억하기 어렵다.
  • 도메인 네임은 사람이 이해하기 쉽고, 변경된 IP 주소와 매핑 가능하다. (e.g., www.example.com)


2.1 네임 서버(DNS Server)

  • 도메인 네임과 IP 주소의 매핑 정보를 관리하는 시스템이다.
  • 마치 공용 전화번호부와 같다.
  • IP 주소가 변경되더라도 도메인 네임과 다시 매핑하면 된다.


2.2 네임 서버의 계층적 구조

점(.)을 기준으로 계층적으로 분류한다.

  • 주요 계층:
    • 루트 도메인(root domain): 최상위 계층(.)
    • 최상위 도메인(TLD; Top-Level Domain): .com, .org, .kr 등
    • 하위 도메인: 2단계, 3단계 도메인 등 (sub.example.com)


2.3 전체 주소 도메인 네임 (FQDN)

전체 도메인 계층을 모두 포함하는 도메인 네임

  • FQDN; Fully-Qualified Domain Name
  • FQDN까지 알면 비로소 하나의 호스트를 식별할 수 있게 된다.


2.4 서브 도메인 (subdomain)

다른 도메인이 포함된 도메인을 의미한다.

  • google.com의 서브 도메인
    • mail.google.com
    • www.google.com
    • drive.google.com


2.4 네임 서버의 관리, DNS

도메인 네임은 전 세계적으로 분산 관리되며, 이를 DNS(Domain Name System)라고 한다.

  • 이를 관리하기 위한 네임 서버 또한 계층적으로 관리된다.
  • 네임 서버는 전 세계 여러 군데 분산되어 위치한다.
  • 이처럼 계층적이고 분산된 도메인 네임에 대한 관리 체계를 DNS(Domain Name System)라고 한다.



3. 계층적 네임 서버

도메인 네임에 대응하는 IP 주소를 알아내는 과정

  • 이 과정을 domain name resolve라고 한다.
  • 계층적이고 분산된 네임 서버들이 사용된다.
  • 로컬 네임 서버부터 차례대로 리졸빙을 수행하게 된다.
  • 주요 네임 서버의 유형
    • 로컬 네임서버
    • 루트 네임 서버
    • TLD(최상위 도메인) 네임 서버
    • 책임 네임 서버


네임 서버는 아래와 같이 계층적 구조를 띄고 있다.


3.1 로컬 네임 서버

클라이언트와 가장 가까운 네임 서버

  • 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장먼저 찾게 되는 네임 서버이다.
  • 클라이언트는 먼저 로컬 네임 서버에 질의한다.
  • 공개 DNS 서버인 public DNS Server를 이용할 수도 있다.
    • e.g., 구글의 8.8.8.8, 클라우드플레어의 1.1.1.1


3.2 루트 네임 서버

루트 도메인(.)을 관장하는 네임 서버

로컬 네임 서버가 대응되는 IP 주소를 모를 경우, TLD 네임 서버의 IP 주소를 반환한다.


3.3 TLD 네임 서버

TLD(com, .org 등)를 관리하는 네임 서버

  • DNS 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환한다.
  • 하위 도메인 네임을 관리하는 네임 서버는 그보다 하위 도메인 네임을 관리하는 네임 서버 주소를 반환한다.
  • 이렇게 내가 알고자하는 네임 서버를 찾아 나가게 된다.


3.4 책임 네임 서버

특정 도메인 영역(zone)을 관리하는 네임 서버

  • 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버
  • 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버
  • 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어낸다.



4. DNS 질의 방식

네임 서버의 계층적 구조를 토대로 IP 주소를 알아내는 방법은 2가지가 존재한다.


4.1 재귀적 질의

클라이언트 → 로컬 네임 서버 → 루트 → TLD → 책임 네임 서버로 질의가 이어진다.

최종 응답 결과는 역순으로 전달된다.


4.2 반복적 질의

클라이언트가 네임 서버에 반복적으로 직접 질의한다.

루트 → TLD → 책임 네임 서버로 정보를 얻는다.


하지만 앞선 질의 예시처럼 8단게를 거치는 것은 조금 문제가있다.

  1. 시간이 오래 걸리고 네트워크 상의 메시지 수가 지나치게 늘어날 수 있음
  2. 루트 네임 서버에 과부하 우려



5. DNS 캐시

DNS 캐시를 사용하면 위와 같은 문제를 해결할 수 있다.

  • 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후같은 질의에 이를 활용한다.
  • DNS 캐시를 저장하는 용도로만 사용되는 서버도 있다.
  • DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있다.
  • DNS 캐시는 영원히 남아 있는 것이 아니다.
    • 임시 저장된 값은 TTL(Time To Live 캐시될 수 있는 시간) 값과 함께 저장된다. (IP 헤더의 TTL과 다름)



6. 자원을 식별하는 URI

6.1 자원이란?

자원(resource)이란, 네트워크 상의 메시지를 통해 주고받는 대상을 의미한다.

  • IP 주소, 도메인 네임은 메시지를 주고받는 송수신지를 파악하기 위한 정보였다면, 자원은 송수신하고자 하는 정보를 파악하기 위한 정보이다.
  • 즉, 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상이다.
    • HTML 파일
    • 이미지나 동영상 파일
    • 텍스트 파일 등
  • 자원은 “HTTP 요청 메시지의 대상”이라고 보기도 한다.


6.2 자원을 식별할 수 있는 정보, URI

URI(Uniform Resource Identifier)이란, 자원을 식별할 수 있는 정보를 말한다.

오늘날엔 URL을 주로 사용한다.

주요 유형 자원 식별 방법
URL(Uniform Resource Locator) 위치를 이용해 자원을 식별
URN(Uniform Resource Name) 이름을 이용해 자원을 식별



7. URL

7.1 URL의 구조

URL은 오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 식별자이다.

구성 요소 설명
Scheme 자원 접근 방법 (e.g., http://, https://)
Authority 호스트 정보 (도메인 네임 또는 IP 주소)
Path 자원이 위치한 경로 (/path/to/resource)
Query 추가 정보를 전달하는 키-값 쌍 (?key=value)
Fragment 자원의 특정 부분을 가리키는 정보 (#section)


7.1.1 scheme

URL의 첫 부분 scheme는 “자원에 접근하는 방법”을 의미한다.

  • 일반적으로 사용할 프로토콜이 명시된다.
    • HTTP를 사용하여 자원에 접근할 때는 http://를
    • HTTPS를 사용하여 자원에 접근할 때는 https://를 사용


7.1.2 authority

authority에는 “호스트를 특정할 수 있는 정보”, 이를 테면 IP 주소 혹은 도메인 네임이 명시된다.

콜론(:)뒤에 포트 번호를 덧붙일 수도 있다.


7.1.3 path

path에는 “자원이 위치한 경로”가 명시된다.

자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현된다.


7.1.4 query

HTTP는 요청-응답기반의 프로토콜이다.

  • 클라이언트는 서버에게 URI(URL)가 포함된 HTTP 요청 메시지를 보내고,
  • HTTP서버는 이애 대해 HTTP 응답 메시지를 보낸다.


그렇다면 아래와 같은 요청은 scheme, authority, path 만으로 어떻게 표현할 수 있을까? (e.g., 검색 결과, 정렬 결과)


이럴 때 사용 가능할 수 있는 것이 쿼리(query)이다.

  • URL을 기반으로 특정 자원을 식별하는 과정에서 추가 정보가 필요할 때, 그 추가 정보를 표현하기 위한 방법으로써 사용할 수 있는 키-값 형태의 데이터가 쿼리이다.
  • query sring(쿼리 문자열), query parameter(쿼리 파라미터)라고도 부른다.
  • 물음표(?)로 시작되는 <키, 값> 형태의 데이터이다.
  • 앰퍼샌드(&)로 여러 쿼리 문자열을 덧붙일 수 있다.


보통은 어떤 쿼리를 보낼 때 어떤 응답을 보낼 것인지 개발자가 설계하기 나름이다.


7.1.5 fragment

fragment는 “자원의 한 조각을 가리키기 위한 정보”이다.

HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용한다.


7.2 URL의 한계와 URN

URL의 단점

  • 위치를 기반으로 자원을 식별하는데 자원의 위치는 언제든 변할 수 있다.
  • 즉, 자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없다.


URN의 장점

  • 자원의 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별한다.
  • URN은 아직 URL만큼 널리 채택된 방식은 아니다.



8. DNS 레코드 타입

8.1 네임 서버는 무엇을 저장할까?

DNS 자원 레코드 (DNS resource record)를 저장한다.

  • DNS 자원 레코드의 구성 요소
    • 이름(호스트 이름, Record Name)
    • 값(Value)
    • TTL
    • 레코드 유형(타입, Record type)
    • 등


- 예를 들어, 1.2.3.4로 접속 가능한 웹 서비스 배포, example.com 도메인 네임을 구입하였다.
- 이를 1.2.3.4에 대응하고자 한다면, example.com이 1.2.3.4에 대응됨을 네임 서버에 알려야 한다.


8.2 레코드 유형(타입, Record type)

DNS 레코드가 어떤 유형의 값인지 알려주기 위한 정보이다.

  • 레코드 유형이 달라지면 레코드 이름과 값의 의미가 달라진다.
  • 대표적인 레코드 유형은 아래와 같다.


8.3 DNS 레코드 예제

네임 서버에 example.com을 질의하면 1.2.3.4 응답

DNS 캐시는 300초간 저장


아래와 같이 CNAME 레코드 타입을 추가

  • example.com에 대한 별칭으로 www.example.com. 사용
  • www.example.com에 질의하면 1.2.3.4 응답


카테고리:

업데이트:

댓글남기기

참고