Tracert/Traceroute

목적지까지의 경로를 추적하기 위해 사용하는 프로그램

• Tracert: Windows용 도구
• Traceroute: Unix, Linux, MacOS 등의 Unix 기반 운영체제용 도구

TTL(Time-to-Live)

• Tracert와 Traceroute에 사용되는 핵심 개념
• 해당 패킷이 몇 번의 홉(hop) 동안 유효한지 명시하는 ICMP 헤더 필드
• TTL값은 한 라우터를 거칠 때마다 1 씩 감소한다.
• 목적지에 도달하기 전에 TTL값이 0이 될 경우 해당 패킷 송신자에게 “시간 초과” ICMP 메시지를 보내고 해당 패킷을 폐기한다.

TTL을 이용한 Tracert/Traceroute 동작 원리

1. <목적지 설정> 명령어 실행 시 목적지 IP 주소나 도메인 이름을 지정한다.
2. <초기 TTL값 설정> 프로그램 시작 시 첫 패킷의 초기 TTL값을 1로 설정한다.
3. <첫번째 패킷 전송> 첫번째 패킷을 전송한다. 이 패킷은 첫번째 라우터에 도달하고 TTL값이 1 감소한다.
4. 첫번째 라우터에서 TTL값이 0이 된 패킷은 폐기되고 송신자에게 시간 초과 ICMP 메시지를 전송한다.
5. 송신자는 3번에서 받은 ICMP 메시지를 통해 첫번째 라우터의 IP 주소와 응답 시간을 기록한다.
6. <두번째 패킷 전송> TTL값이 2로 설정된 두번째 패킷을 전송한다. TTL값이 2가 된 패킷은 두번째 라우터에서 TTL값이 0이 되어 폐기되고, 송신자에게 시간 초과 ICMP 메시지를 전송한다.
7. 송신자는 6번에서 받은 ICMP 메시지를 통해 두번째 라우터의 IP 주소와 응답 시간을 기록한다.
8. TTL값을 1 씩 증가시키며 패킷을 목적지로 전송하는 과정을 반복한다. 패킷이 목적지에 도달하거나, 사용자가 설정한 최대 TTL값에 도달하면 반복을 종료한다.

Tracert와 Traceroute의 차이점

• Tracert 메뉴얼

• Traceroute 메뉴얼

Tracert/Traceroute 사용 목적

• 목적지까지의 경로 추적 가능
• 네트워크 상 각 라우터의 지연 시간 파악 후 네트워크 경로 문제 식별 가능

Tracert/Traceroute 실습

• Tracert 실습
  • OS: Windows 11
  • Host IP address: 192.168.35.167
  • Destination IP address: 142.250.207.110

<첫번째 패킷(TTL=1) 전송>

<두번째 패킷(TTL=2) 전송>

→ 각 라우터에 대해 총 3번의 패킷을 전송하고, 각각의 소요시간을 측정한다.

• Traceroute 실습
  • OS: macOS
  • Host IP address: 192.168.0.50
  • Destination IP address: 74.125.203.102

<첫번째 패킷(TTL=1) 전송>

<두번째 패킷(TTL=2) 전송>

→ 각 라우터에 대해 총 3번의 패킷을 전송하고, 각각의 소요시간을 측정한다.
⇒ tracert와는 다르게 송신할때와 수신할때 사용하는 프로토콜이 다르다.

• CDN을 사용하지 않고 하나의 데이터 센터만 사용할 경우 문제점
  1. 지역적으로 먼 거리 ⇒ 거쳐가는 라우터의 수 증가 ⇒ 병목 지점의 링크를 거쳐갈 확률 증가 ⇒ 전송용량이 낮아질 가능성이 높아진다.
  2. 많은 이들이 여러번 시청하는 콘텐츠는 그만큼 자주 전송해야하고 이로 인해 전송 비용이 중복적으로 발생한다.
  3. 한번의 장애로 전체 서비스가 중단될 위험이 있다.

• CDN(Contents Distribution Network)
  : 여러 서버 클러스터를 두고 이들 서버에 콘텐츠의 복사본을 저장해두고 사용하는 방식
  
  • 대부분의 비디오 스트리밍 서비스에서 사용하는 방식
  • 이용하려는 서버 클러스터에 콘텐츠의 복사본이 없는 경우, 중앙 서버나 다른 클러스터로부터 해당 콘텐츠를 전송 받아 제공하는 동시에 복사본을 만든다.
    • PULL 방식을 사용하여, 요청이 들어오는 비디오에 대한 처리만 한다.
    • 복사본을 저장할 공간이 가득찬 경우 인터넷 캐시처럼 자주 이용되지 않은 것을 삭제
  • 사설 CDN 또는 제3자가 운영하는 CDN을 사용할 수 있다.
  • CDN 서버 클러스터를 구축하는 방식 (아래 두 가지 중 하나 선택 사용)
    1. 서버 클러스터를 최대한 사용자에 가까이 두어 전송 속도를 높이기 위해, 수많은 서버 클러스터들을 ISP의 접속 네트워크 안에 위치시키는 방법
       1. 장점 : 지연 시간 및 처리율이 향상된다.
       2. 단점 : 고도로 분산된 설계로 인해 유지 관리 비용이 증가한다.
    2. 보다 적은 수의 핵심 지점(IXPs)에만 큰 규모의 서버 클러스터를 위치 시키는 방법
       1. 장점 : 유지 관리 비용이 줄어든다.
       2. 단점 : 지연 시간 및 처리율이 상대적으로 저하된다.

• CDN 동작
  • CDN이 사용자의 요청을 가로채 해당 사용자에게 가장 적절한 서버 클러스터를 찾아 그 서버로 요청을 보낸다. 요청을 가로챌 때 DNS를 사용한다.
  • 동작 단계

• 서버 클러스터 선택 정책
  • LDNS(로컬 DNS)에서 CDN 책임 서버로 요청을 보내는 과정에 의해 CDN은 LDNS의 IP를 알게 되고 이 주소를 바탕으로 사용자에게 가장 적합한 콘텐츠 서버를 선택한다.
  • 각 CDN 별로 고유한 클러스터 선택 정책을 사용한다.
  • 일반적으로 사용하는 정책은 “클라이언트에게 지리적으로 가장 가까운 클러스터"를 선택하는 것
    • 일부 클라이언트에게는 지리적으로 가장 가까운 클러스터가 가장 가까운 클러스터가 아닐 수 있다. (네트워크 경로 상의 홉 수에 의해)
    • 클라이언트가 멀리 떨어진 LDNS를 사용할 경우 LDNS의 IP를 기반으로 한 선택이 최선이 아닐 수 있다.
    • 같은 위치라면 매번 같은 클러스터가 배정되는데, 이 때 경로의 지연이나 가용 대역폭의 변화 등은 고려하지 않는다.
  • CDN은 네트워크 트래픽 상황을 고려하여 클러스터를 선택하기 위해 클러스터와 클라이언트 간 경로 상의 지연 및 손실 성능을 실시간으로 측정하도록 할 수 있다.
    • 다만, 대부분의 LDNS에서 실시간 측정을 위해 사용되는 메시지에 응답하지 않도록 설정되어 있는 것이 문제...

호스트 식별 방법

• 호스트 네임(hostname)
  • (ex. www.naver.com, www.google.com)
  • 가변 길이의 알파뉴메릭 문자로 구성된다.
  • 호스트의 위치에 대한 정보는 제공하지 않는다.
• IP 주소
  • 4바이트 (32비트)
  • xxx.xxx.xxx.xxx 형태의 계층 구조
  • 호스트가 속한 네트워크의 위치와 호스트의 위치에 대한 정보를 제공한다.

DNS가 제공하는 서비스

• DNS(Domain Name System)
  1. DNS 서버가 계층 구조로 구현된 분산형 데이터베이스
     • 서버 : BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터
  2. 호스트가 분산형 데이터베이스에 질의할 수 있게 하는 애플리케이션 계층 프로토콜
     • 프로토콜 : UDP 기반으로 수행되고, 포트 번호 53번을 사용한다.
• 사용자가 제공한 호스트 네임을 IP 주소로 변환하는데 사용된다.
  • 인터넷 애플리케이션에서 URL로의 요청을 보낼 때 우선 DNS 클라이언트를 이용하여 DNS 서버에 호스트 이름에 대한 질의를 보내 IP 주소를 얻는다.
  • 가까운 DNS 서버에 원하는 IP 주소가 캐시되어 있어 평균 지연 시간을 줄여준다.
• 호스트 엘리어싱(host aliasing) : 복잡한 호스트 네임을 가진 호스트에 대해 하나 이상의 별칭도 함께 저장한다.
  • 원래 호스트 네임을 **정식 호스트 네임(canonical hostname)**이라고 한다.
  • 별칭 호스트 네임으로부터 정식 호스트 네임을 얻을 수 있도록 한다. (google.com 별칭 이름 → www.google.com 정식 이름)
• 메일 서버 엘리어싱(mail server aliasing) : 메일 애플리케이션으로부터 메일 서버에 대한 정식 호스트 네임을 얻기 위해 사용된다.
  • 기억하기 쉬운 전자메일 주소를 위해 주소로는 별칭을 사용하고 정식 호스트 네임이 필요할 때 DNS에 질의한다.
• 부하 분산(load distribution) : 여러 중복 서버 사이에 부하를 분산하는 데에 사용한다.
  • 여러 중복된 서버는 서로 다른 IP 주소를 가지고 있는데, 이들 모두 하나의 연관된 호스트 네임을 가진다.
  • 해당 호스트 네임으로 질의를 받은 DNS 서버는 서로 다른 IP 주소들을 모두 응답해준다.
  • 이 때 응답하는 IP 주소의 순서를 순환되도록 하여, 가장 앞에 있는 IP 주소를 사용하는 클라이언트가 분산된 여러 서버에 순환적으로 요청을 보낼 수 있도록 한다.

DNS 동작 원리

분산 계층 데이터베이스

• DNS 서버 계층
  • 루트 DNS 서버
    • 13개의 다른 기관에서 관리하며 400개 이상의 루트 DNS 서버가 존재한다.
    • DNS 서버 계층으로 질의가 들어올 때 제일 먼저 루트 DNS 서버로 전달된다.
    • 호스트 네임의 TLD에 맞는 TLD 서버의 IP 주소를 응답한다.
  • TLD(Top-Level Domain) DNS 서버
    • com, org, net, edu 같은 TLD 서버와 kr, fr, ca 같은 모든 국가에 대한 TLD 서버가 존재한다.
    • 각 TLD 서버는 각각에 속한 책임 DNS 서버들의 IP 주소를 가지고 있고, 이를 응답한다.
  • 책임(authoritative) DNS 서버
    • 자신의 서버에서 관할하는 호스트 네임과 그의 IP 주소가 매핑된 공개적인 DNS 레코드를 가진다.
    • 웹 서버나 메일 서버들은 자신의 호스트 네임과 IP 주소가 매핑된 DNS 레코드를 책임 DNS 서버에 저장해야 한다.
    • 이를 위해 자신들이 직접 책임 DNS 서버를 구현하여 저장하는 방법과 책임 DNS 서버 서비스를 제공하는 제공자에게 비용을 지불하고 저장하는 방법(ex. 가비아, 카페24) 중 선택할 수 있다.
• 로컬 DNS 서버
  • ISP들은 로컬 DNS 서버(default name server)를 갖는다.
  • 호스트가 ISP에 접속할 때 일반적으로 DHCP를 이용하여 호스트에게 IP 주소를 할당한다.
  • 호스트가 DNS 질의를 보낼 때 제일 먼저 로컬 DNS 서버로 보내고, 이 서버에 원하는 호스트명이 없을 경우 로컬 DNS 서버에서 DNS 서버 계층으로 DNS 질의를 보낸다.
  • 로컬 DNS 서버를 중심으로 DNS 서버 계층과의 질의가 이루어지며 이렇게 얻어진 DNS 레코드는 캐싱되어 로컬 DNS 서버에 저장된다.
  • 재귀적 질의(recursive query)와 반복적 질의(iterative query)
    
    • 재귀적 질의 : 요청 호스트 - LDNS - DNS 서버
    • 반복적 질의 : LDNS - DNS 서버

DNS 캐싱(caching)

• 로컬 DNS 서버는 질의 결과로 얻은 DNS 레코드를 로컬 메모리에 저장할 수 있다.
  • 저장할 때 저장해 둘 기간(대게 2일)을 설정해두고, 이 기간이 지난 레코드는 삭제한다.
  • 저장된 DNS 레코드에 해당하는 질의가 들어올 경우 추가적인 질의 없이 곧바로 이 레코드의 정보를 이용하여 응답할 수 있다.
• 로컬 DNS 서버는 호스트에 대한 정보 뿐만 아니라 TLD 서버의 IP 주소도 저장할 수 있다.
  • DNS 서버 계층으로 질의할 경우 루트 DNS 서버로의 질의를 우회할 수 있다.

DNS 레코드와 메시지

(RFC1034, RFC1035)

자원 레코드(resource record, RR) : DNS 서버에서 호스트명과 IP 주소를 매핑하는데 사용하는 레코드

• 각 DNS는 DNS 질의에 대해 하나 이상의 자원 레코드를 가지는 메시지로 응답한다.
• 자원 레코드가 갖는 필드
  • Name(16bits), Value, Type(16bits), TTL(32bits, 자원 레코드가 캐시에 남아있는 기간)
• Type 값에 따른 Name과 Value의 값
  • Type = A
    • Name : 호스트 명
    • Value : 호스트 명에 대한 IP 주소
    • Type A의 레코드 예시 : (relay1.bar.foo.com, 145.37.93.126, A)
  • Type = NS
    • Name : 도메인
    • Value : 도메인에 대한 책임 DNS 서버의 호스트 네임
    • Type NS의 레코드 예시 : (foo.com, dns.foo.com, NS)
  • Type = CNAME
    • Name : 별칭 호스트 명
    • Value : 별칭 호스트 명에 대한 정식 호스트 명
    • Type CNAME의 레코드 예시 : (foo.com, relay1.bar.foo.com, CNAME)
  • Type = MX
    • Name : 별칭 호스트 명
    • Value : 별칭 호스트 명에 대한 메일 서버의 정식 이름
    • Type MX의 레코드 예시 : (foo.com, mail.bar.foo.com, MX)
    → 하나의 별칭이 해당 회사의 메일 서버와 다른 서버들을 통칭하는 이름으로 사용될 수 있음.

• 하나 이상의 자원 레코드를 전송하는 경우
  • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버일 경우
    1. 호스트의 IP 주소를 알기 때문에 이를 응답하기 위한 Type A 레코드를 응답
  • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버가 아닐 경우
    1. 해당 호스트를 포함하고 있는 DNS 서버의 호스트 명을 응답하기 위한 Type NS 레코드를 응답
    2. 알려주려고 하는 DNS 서버의 IP 주소를 응답하기 위한 Type A 레코드를 응답

DNS 메시지

• 헤더 영역 (12 bytes)
  • 질의 식별자 (16 bits) : 질의/응답 메시지에 동일한 값을 사용하는 것으로 질의/응답 간의 일치를 식별한다.
  • 플래그
    • 질의/응답 플래그(1 bit) : 메세지가 질의(0)인지 응답(1)인지 구분
    • 책임 플래그(1 bit) : 응답하는 DNS 서버가 책임 DNS 서버일 때 설정되는 플래그
    • 재귀 요구 플래그(1 bit) : DNS 서버가 질의에 맞는 레코드를 가지고 있지 않을 때 재귀적 질의를 수행하길 원할 경우 클라이언트 측에서 설정하는 플래그
    • 재귀 - 가능 플래그(1 bit) : DNS 서버가 재귀적 질의를 지원할 수 있는 경우 응답 메시지에 설정되는 플래그
  • 질문 수, 답변 RR 수, 책임 RR 수, 추가 RR 수(각 16 bits 씩 4개)
    : 헤더영역 이후에 오는 영역들에 대한 갯수 정보
• 질문 영역
  : 현재 질의에 대한 정보
  
  • 이름 필드 : 질의되는 이름을 포함할 필드
  • 타입 필드 : 이름에 대해 문의되는 질문 타입을 지정할 필드
• 답변 영역
  : (응답에 포함) 처음 질의된 이름에 대한 자원 레코드
  
  • 하나의 호스트 명에 대응되는 IP 주소가 여러 개가 존재할 수 있기 때문에 한 개 이상의 응답 레코드를 가진다.
• 책임 영역
  : 다른 책임 서버의 레코드
• 추가 영역
  : 그 밖에 도움이 되는 레코드
  
  • MX 질의에 대한 응답의 응답 필드로 MX 서버의 정식 호스트 네임을 가진다.
    → 이 때 추가 영역에는 정식 호스트 네임의 IP 주소를 제공하는 Type A 레코드가 있다.

DNS 데이터베이스에 레코드 삽입

• 도메인 네임을 등록기관에 등록하는 절차
  1. 등록기관 : 도메인 네임의 유일성을 확인하고 해당 도메인 네임을 DNS 데이터베이스에 넣는다.
     (ICANN에 의해 승인된 등록기관의 리스트 확인 사이트 : http://www.internic.net)
  2. 등록 시 주책임 DNS서버와 부책임 DNS서버의 이름과 IP주소를 등록기관에 제공해야 한다.
     1. 이렇게 제공된 이름과 IP 주소를 각각 type NS와 type A RR을 이용하여 TLD DNS 서버에 저장한다.
     2. (ex) (networkutopia.com, dns1.networkutopia.com, NS)
                (dns1.networkutopia.com, 212.212.212.1, A)
  3. networkutopia.com이 책임 DNS 서버에 Type A RR 로 저장되는지 확인한다.
     → 최근에는 이를 DNS 동적 갱신 방식으로 기술하고 있다.
• 등록된 도메인 네임을 불러오는 절차

네트워크를 제대로 공부해봐야지.. 라고 생각하며 네트워크 스터디를 시작했다.

네트워크 전반에 대해서 본격적으로 공부해보는게 처음이라 아직 엉성하지만 중간점검 한다고 생각하고 기록용으로 올려둔다.

이제부터는 여기에 살을 붙여가면서 공부할 예정이다. 파이팅!