[CS스터디] DNS, DHCP, ARP...

by VICENTE97P4

May 10, 2022, 8:43 p.m.

DNS(Domain Name Service)

웹사이트의 IP주소와 도메인 주소를 이어주는 시스템입니다.

도메인 주소를 쓰는 이유는 사람이 숫자로 된 IP 주소를 일일히 기억하기 힘들기 때문입니다.

ICANN이라는 기관에 편입된 IANA라는 범 국제적인 기관이 문자로 된 도메인을 만들고 관리합니다.

실제 웹사이트의 데이터가 저장되어 있는 호스팅 서버에는 IP주소가 할당되어 있고, 이 주소가 실제 웹사이트 주소라 할 수 있습니다.

DNS 서버는 이 IP 주소를 특정 도메인 주소와 같다는 기록을 저장해두고, 인터넷 사용자들이 도메인 주소를 검색했을 때 IP주소로 연결되도록 해줍니다.

세상에는 도메인 수가 너무 많기 때문에 DNS 서버 종류를 계층화해서 단계적으로 처리합니다.

즉,  DNS 서버도 도메인 이름의 분류와 마찬가지로 디렉토리/계층 형태로 구분됩니다.

- Root DNS Server: ICANN이 직접 관리하는 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 합니다.

- TLD(최상위 도메인) DNS server: 도메인 등록 기관(Registry)이 관리하는 서버로, Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 합니다.

어떤 도메인 묶음이 어떤 Authoritative DNS Server에 속하는지 알 수 있는 이유는 도메인 판매 업체(Registar)의 DNS 설정이 변경되면 도메인 등록 기관(Registry)으로 전달되기 때문입니다.

- Authoritative DNS Server: 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버입니다. 그래서 권한의 의미인 Authoritative가 붙었습니다.

일반적으로 말하는 name server에 해당합니다.

- Recursive DNS Server: 인터넷 사용자가 가장 먼저 접근하는 DNS 서버입니다.

위 3개의 DNS 서버를 매번 거친다면 효율이 매우 떨어질겁니다.

그래서 한 번 얻은 IP 주소를 TTL(Time To Live)동안 캐시라는 형태로 저장해두는 서버입니다.

직접 도메인과 IP 주소의 관계를 기록/저장/변경하지는 않고 캐시만을 보관하기 때문에 Recursive라는 이름이 붙었습니다.

대표적으로 KT/LG/SK같은 ISP(통신사) DNS 서버가 있고, 브라우저 우회용으로 쓰는 구글 DNS, 클라우드 플레어와 같은 public DNS 서버가 있습니다.

브라우저는 캐시가 저장된 Recursive 서버를 이용하고, 실제 네임서버를 설정하는 곳은 Authoritative 서버입니다.

전반적인 DNS 동작 원리

1. 브라우저에서 Nesite.com을 검색하면, 로컬에 있는 DNS cache Table을 먼저 봅니다.

(Window의 경우 hosts 파일을 먼저 찾고 없으면 DNS cache table을 찾습니다.)
거기에 원하는 도메인의 IP가 없으면 사용하고 있는 통신사인 KT DNS 서버

(로컬 DNS 서버에 해당됩니다)에게 도메인 주소에 해당하는 IP 주소를 요청합니다.

2. ISP 서버에서는 캐시 데이터가 없다는 것을 확인하고 루트 DNS 서버에게 어디로 가야 하는지 요청합니다.

(만일 캐시가 있다면 8번으로 건너뜁니다.)

3. 루트 서버는 TLD DNS 서버 주소만 관리하기 때문에 .com 도메인을 보고 

COM 최상위 도메인을 관리하는 TLD DNS 서버 주소를 안내합니다.

4. ISP 서버는 COM 서버에게 어디로 가야 하는지 다시 요청합니다.

5. COM 서버는 가비아 DNS 서버에서 해당 도메인이 관리되고 있는 것을 확인하고 서버 주소를 안내합니다.

6. ISP 서버는 가비아 서버에 또 다시 요청합니다.

7. 가비아 서버는 Nesite.com = 12.123.123.123 이라는 정보를 확인하고 이 IP를 알려줍니다. 

동시에 ISP 서버는 해당 정보를 캐시로 기록해둡니다.

8. ISP 서버는 브라우저에게 알아낸 12.123.123.123 주소를 안내합니다.

9. DNS cache table에 12.123.123.123 IP 주소를 기록하고, 브라우저는 호스팅 서버에 요청을 날립니다. 

10. 완료

여담으로 구글 클라우드플레어 네임서버가 무료이고 SSL 인증서도 주고 성능도 제일 좋다고 합니다.

DHCP(Dynamic Host Configuration Protocol)

DHCP란 호스트의 IP주소와 각종 TCP/IP 프로토콜의 기본 설정을 클라이언트에게 자동적으로 제공해주는 프로토콜을 말합니다.

DHCP는 네트워크에 사용되는 IP주소를 DHCP 서버가 중앙집중식으로 관리하는 클라이언트/서버 모델을 사용합니다.

클라이언트는 네트워크 부팅 과정에서 DHCP 서버에 IP 주소를 요청하고 이를 얻을 수 있습니다.

즉, 네트워크에 있는 컴퓨터에 자동으로 네임 서버 주소, IP주소, 게이트웨이 주소를 할당해주는 것입니다.

- 장점

PC의 수가 많거나 PC 자체 변동사항이 많은 경우 IP 설정이 자동으로 되기 때문에 효율적으로 사용 가능합니다.

IP를 자동으로 할당해주기 때문에 IP 충돌을 막을 수 있습니다.

- 단점

DHCP 서버에 의존하기 때문에 서버가 다운되면 IP 할당이 제대로 이루어지지 않습니다.

DHCP 구성

1) DHCP 서버

DHCP 서버는 일정한 범위의 IP 주소를 다른 클라이언트에게 할당하여 자동으로 설정하게 해주는 역할을 합니다.

DHCP 서버는 클라이언트에게 할당된 IP주소를 변경없이 유지해줄 수 있습니다.

클라이언트에게 IP 할당 요청이 들어오면 IP를 부여해주고 할당 가능한 IP들을 관리해주게 됩니다.

2) DHCP 클라이언트

클라이언트는 자신의 시스템을 위한 IP 주소를  DHCP 서버에 요청합니다.

DHCP 서버로부터 IP 주소를 부여받으면 TCP/IP 설정이 초기화되고 다른 호스트와 TCP/IP를 사용하여 통신할 수 있게됩니다.

즉, 서버에게 IP를 할당받으면 TCP/IP 통신을 할 수 있습니다.

DHCP 원리

DHCP를 통한 IP 주소 할당은 임대 개념입니다. 

DHCP 서버가 IP 주소를 영구적으로 client에 할당하는 것이 아니고 임대기간(lease time)을 명시하여

그 기간 동안만 단말이 IP 주소를 사용하도록 하는 것입니다.

client가 임대기간 이후에도 계속 해당 IP 주소를 사용하고자 한다면 IP 주소 임대기간 연장(IP Address Renewal)을 DHCP 서버에 요청해야 합니다.

또한 client가 임대 받은 IP 주소가 더 이상 필요치 않게 되면 IP 주소 반납 절차(IP Address Release)를 수행하게 됩니다.

DHCP client가 DHCP 서버로부터 IP 주소를 할당 받는 절차

1) DHCP Discover

메시지 방향: client -> DHCP 서버

broadcast message (Destination MC = FF:FF:FF:FF:FF:FF)

의미: client가 DHCP 서버를 찾기 위한 메시지입니다.

그래서 LAN 상에(동일 subnet 상에) 브로드캐스팅을 하여 'DHCP 서버가 있으면 내게 응답 좀 해주세요!' 라고 client가 외칩니다.

2) DHCP Offer

메시지 방향: DHCP 서버 -> client

브로드캐스트 메시지 또는 유니캐스트일 수도 있습니다.

이는 client가 보낸 Discover 메시지 내의 Broadcast Flag의 값에 따라 달라지는데,

Flag = 1이면 DHCP 서버는 Offer 메시지를 Broadcast로, Flag=0이면 Unicast로 보내게 됩니다.

의미: DHCP 서버가 응답하는 메시지입니다.

단순히 DHCP 서버의 존재만을 알리는 것이 아니고,

client에 할당할 IP 주소 정보를 포함한 다양한 네트워크 정보를 함께 실어서 단말에 전달합니다.

IP, Subnet Mask, Router(client의 Default Gateway IP 주소), DNS 서버 IP 주소, DHCP 서버의 주소, IP Lease Time(client가 IP를 사용할 수 있는 시간) 을 보냅니다.

(이 정보들을 받았다고 해서 아직 할당 받은 것은 아닙니다!!)

3) DHCP Request

* 2대 이상의 DHCP 서버가 DHCP Offer를 보낸 경우, client는 이 중에 마음에 드는 DHCP 서버 하나를 고르게 됩니다.

고른 서버에 DHCP Request 메시지를 보내어 IP 주소를 포함한 네트워크 정보를 얻습니다.

4) DHCP Ack

메시지 방향: DHCP 서버 -> client

브로드캐스트 또는 유니캐스트일 수도 있습니다.

의미: DHCP 절차의 마지막 메시지로, DHCP 서버가 단말에게 네트워크 정보를 전달해주는 메시지입니다.

앞에서 본 DHCP Offer 메시지에 보냈던 정보와 같은 정보들이 포함됩니다.

이렇게 DHCP Ack을 수신한 client는 이제 IP 주소를 포함한 네트워크 정보를 임대하였고, 이제 인터넷 사용이 가능하게 됩니다.

주소 임대기간 연장 절차

1. DHCP Request를 Unicasting으로 보냅니다.(client -> DHCP server)

2. DHCP Ack를 Unicasting으로 보냅니다.(DHCP server -> client)

주소 반환 시에는(PC 로그오프 또는 ipconfig/release 할 때)

DHCP Release 메시지를 Unicasting으로 DHCP 서버에 전달하여 IP 주소를 반환합니다.

ARP(Address Resolution Protocol)

ARP는 IP 주소를 MAC 주소와 매칭시키기 위한 프로토콜입니다.

네트워크에서 단말과 단말 간 통신을 하기 위해서는 IP 주소와 함께 MAC 주소를 이용하게 되는데,

IP 주소를 MAC address와 매칭파여 목적지 IP의 단말이 소유한 MAC 주소를 향해 제대로 찾아가기 위함입니다.

MAC 주소란?

그럼 MAC 주소가 뭔지 먼저 알아야 합니다.

데이터 링크 계층에서 통신을 위한 네트워크 인터페이스에 할당된 고유 식별자로 NIC(Network Interface Card)

를 가진 단말이라면 공장에서 출고될 때 부여되고 평생 사용하는 고유한 주소를 의미합니다.

즉, LAN에서 목적지와 통신하기 위한 실질적인 주소가 바로 MAC 주소입니다.

네트워크 장비와 컴퓨터는 모두 MAC 주소를 갖습니다. 정확히는 NIC마다 MAC 주소를 갖습니다.

그리고 LAN에서는 IP 주소를 MAC 주소에 매핑하여 통신합니다.

MAC은 왜 필요할까?

IP 주소는 계속 변화합니다. 

MAC이 없다면 IP 주소만 있는 상황에서 사용자의 IP가 바뀐다면 예전 IP만 알고 있던 상대방은 사용자가 바뀌었는지, 통신하는 대상이 맞는지 알 수가 없습니다.

그래서 웬만해서 변하지 않는 MAC 주소가 필요합니다. 

위 그림에서 PC0의 아이피가 PC1과 바뀌어서 192.168.1.2가 된다면 PC0과 통신하던 PC2는 지금 통신하고 있는 상대방이 PC0인지 PC1인지 구분할 방법이 없습니다.

즉, 잘못된 대상과 통신하게 됩니다.

마치 동명이인이어도 주민등록증으로 구별할 수 있는 것과 비슷하죠. 여기서 민증이 MAC에 해당됩니다.

(물론, IP와 MAC은 계층이 다르니까 사용처가 다르다는 말도 맞지만 원론적인 이야기에는 이게 더 가까운 것 같습니다.)

반면 MAC만 쓰고 IP가 없다고 하면, 고유한 MAC 주소를 일일이 라우팅 테이블에 입력해야 하고 그럼 라우터가 다운되고 말겁니다.

반면 IP는 계층화되어있기 때문에 망이라는 큰 단위로 IP가 속하는 곳을 지정해줄 수 있고, 효율적으로 원하는 IP에 메시지를 전달할 수 있습니다.

(계층화가 필요없는 같은 네트워크 상에 있는 기기끼리는 MAC Address만으로도 통신이 가능합니다.)

그래서 ARP란 무엇인가?

단말간 통신에서 양쪽 단말은 IP를 이용하여 목적지를 지정하지만 실제 데이터 이동을 위해 MAC 주소를 함께 이용합니다.

만일 MAC 주소가 없는 패킷을 받으면 datalink-layer에서 폐기해버리게 때문에 상대방의 MAC 주소를 알아야 프레임이 만들어져서 통신을 할 수 있습니다.

ARP는 IP 주소와 MAC 주소를 일대일 매칭하여 LAN에서 목적지를 제대로 찾아갈 수 있게 해줍니다.(DataLink 계층에서 동작합니다.)

IP 주소와 MAC 주소를 일대일 매칭시킨 정보를 저장해둔 Table을 ARP Table이라고 합니다.

위 그림에서 PC0의 ARP Table에 다른 PC들의 IP 주소와 함께 MAC 주소가 일대일 매칭되어 관리되고 있습니다.

사용자가 데이터를 보내기 위해 목적지 IP 주소를 지정하면 PC0은 ARP Table에 있는 MAC 주소를 보고 해당 MAC 주소의 PC로 전달합니다.

중간에서 데이터를 전달하는 스위치 또한 자신의 Port에 연결된 PC들의 MAC 주소 정보를 갖고 있습니다.

어느 Port에서 어느 PC의 MAC 주소가 올라오는지 알아야 PC에게서 전달받은 데이터를 전달할 때 목적지 MAC 주소를 올바르게 지정할 수 있기 때문입니다.

* RARP(Reverse ARP)

ARP와 반대로 해당 MAC 주소에 맞는 IP 값을 알아오는 프로토콜입니다.

특수한 경우에만 사용되는데, 디스크가 없는 컴퓨터나 단말기가 처음 전원을 켜질 때 RARP 서버로부터 IP를 부여받을 때입니다.

디스크 없는 컴퓨터는 중요한 데이터를 중앙 서버에 배치하며,

각 클라이언트가 디스크 없이 서버의 데이터를 다운로드하여 사용할 수 있도록 합니다.

각 클라이언트에서 사용자가 임의적으로 프로그램을 설치할 수 없도록 하고 전체 하드웨어의 비용을 최소화시키는 이점이 있습니다.

ARP 과정

일단 들어가기 전에 모든 단말들은 자신만의 Routing Table이 있어서 자신이 보내려는 패킷의 목적지 IP가 자신이 소속된 IP 대역인지 아닌지 알 수 있습니다.

1. PC0(192.168.1.1)은 PC2(192.168.1.3)에 데이터를 전달하려고 합니다. 

일단 Routing Table을 보니 자신과 PC2가 같은 LAN에 속한다는 것을 알았습니다. 

2. PC2의 MAC 주소를 알기 위해 ARP Request를 뿌립니다.
Broadcast(FF:FF:FF:FF:FF:FF)로 ARP Request를 날립니다.(목적지의 MAC을 모르니까요)
그럼 PC 1, 2, 3에 전달됩니다.

그리고 ARP Request의 대상이 되는 PC2가 이에 반응하여 ARP Response(PC2의 MAC 주소)를 보냅니다.

(이때는 Unicast로 보냅니다.)

3. PC0 은 PC2가 보낸 ARP Response를 받고 ARP Table에 PC2의 IP와 MAC 주소를 적습니다.
그리고 이제부터는 데이터를 보내려 목적지 IP를 192.168.1.3(PC2)로 지정하면 

ARP Table을 보고 PC2의 MAC 주소를 목표로 전달합니다.

정리하면

1. ARP Request 2. 해당하는 PC만 수신 3. ARP Reply (MAC 보냄)

ARP Table

한 번 수신된 주소는 캐시 테이블에 저장되어 다음 몇 분 동안 같은 수신자로 보내지는 통신에 이용됩니다.

보통 스위치에서 ARP Table Aging Time(ARP를 저장하고 있다가, 일정시간 통신을 하지 않으면 ARP Table에서 지워버리는 시간)

은 300초(5분)입니다. 다시 Ping이라도 쏴서 통신이 이루어지면 ARP Table이 다시 생성됩니다.

ICMP(Internet Control Message Protocol)

ICMP는 TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜입니다.

IP 프로토콜은 전송상태에 대한 관리가 이루어지지 않는 신뢰할 수 없는 프로토콜입니다. 

IP는 패킷을 목적지에 도달시키기 위한 내용들로만 구성되어있죠.

정상적으로 목적지 호스트에 도달하는 경우에는 IP에서 통신이 성공하고 종료되므로 문제가 없습니다.

하지만 전달해야 할 호스트가 꺼져있거나, 선이 단절된 경우와 같이 비정상적인 경우에는

이 패킷 전달을 의뢰한 출발지 호스트에 이러한 사실을 알려야 합니다.

하지만 IP에는 그러한 에러 처리 방법이 없죠.

이러한 IP의 부족한 부분을 보완하기 위해 사용되는 것이 ICMP입니다.

즉, ICMP는 패킷 전송 중 에러 발생 시 원인을 알려주거나 네트워크 상태를 진단해주는 기능을 제공합니다.

ICMP는 해당 호스트가 없거나, 해당 포트에 대기 중인 서버 프로그램이 없는 등의 에러 상황이 발생할 경우

IP 헤더에 기록되어 있는 출발지 호스트로 이러한 에러에 대한 상황을 보내주는 역할을 수행하게 됩니다.

이러한 에러에 대한 상황(에러메시지 - 타입, 코드)을 받게 된 출발지 호스트에서는 목적지 호스트 상태에 대한 정보를 대략적으로 확인이 가능합니다.

Error-Reporting Message: 전송 중 오류 발생 시 에러 메시지를 생성하여 응답

Query Message: 네트워크 상태를 진단하기 위해 쿼리 요청 및 응답메시지 생성

ICMP Type: ICMP의 메시지 구별

ICMP Code: 메시지 내용에 대한 추가 정보

ICMP Checksum: ICMP의 값 변조 여부 확인

ICMP 메시지 1, 2: ICMP Type에 따라 내용이 가변적으로 들어감

에러 메시지(Error-Reporting Message)

ICMP의 Type을 보고 다음과 같은 상황을 파악할 수 있습니다. 

Destination Unreachable: 목적지에 도달하지 못함(Type 3)

Time Exceeded: Time limit을 넘어서 IP 패킷이 폐기되어 목적지에 도달하지 못함(Type 11)

Redirect: 라우팅 경로가 잘못되어 새로운 경로를 이전 경우지 또는 호스트에게 알려주는 메시지(Type 5)

ICMP Redirect 공격 시 이용되는 메시지입니다.

그 밖에도 source quench 등의 에러메시지가 있습니다.

에러메시지 안에 에러 코드가 존재하여 원인을 조금 더 깊이 파악할 수 있습니다.

예를 들어 Destination Unreachable 관련 에러 코드는

Network Unreachable: Code 0

Host Unreachable: Code 1

Protocol Unreachable: Code 2

Port Unreachable: Code 3

등이 있습니다.

해당 코드를 통해서 어떤 식의 문제가 있는지 파악이 가능하죠.

예를 들어 code 3번의 경우 해당 port가 열려있지 않아 에러가 발생한다고 생각하면 됩니다.

ICMP 프로토콜의 사용 예시에는 대표적으로 ping이 있습니다.

컴퓨터 A가 B에게 ping 192.100.1.3 으로 ping을 보내면 윈도우에서는 ICMP 프로토콜을 이용하여 B로 보내게 됩니다.

그러면 B로 가는 도중 생기는 에러들을 유형에 맞게끔 에러메시지(Destination Unreachable, Time Exceeded 등), 에러코드(code 3 등)로 회신하게 됩니다.

해당 정보를 바탕으로 송신자 컴퓨터(A)의 경우 수신자 컴퓨터(B)와의 현재 통신 상태를 확인할 수 있습니다.

추가적으로 IGMP(Internet Group Management Protocol)

멀티캐스팅 데이터의 수신을 위해서 IGMP 프로토콜을 사용합니다. 인터넷 그룹 관리 규약이라고 불립니다.

Routing

데이터를 전달하는 과정에서 여러 네트워크들을 통과해야 하는 경우가 생길 수 있습니다.

여러 네트워크들의 연결을 담당하고 있는 라우터 장비가 데이터의 목적지가 어디인지 확인하여

빠르고 정확한 길을 찾아 전달해주는 것을 routing이라고 합니다.

라우터가 전달받은 패킷을 전달하기 위해 가장 먼저 목적지가 어디인지 IP 주소를 확인합니다.

그 후 가장 빠른 경로가 어디인지를 확인하고 그 경로로 가기 위해서 자신의 어느 인터페이스로 패킷을 보내야 하는지 결정합니다.

그 뒤에 결정한 인터페이스로 패킷을 전달하면 그 패킷은 또 다른 라우터로 전달되어 위와 같은 과정을 목적지 네트워크에 도착할 때까지 반복합니다.

이처럼 데이터를 목적지까지 전달하기 위한 모든 일련의 과정들을 routing이라고 합니다.

Routing을 하기 위해 필요한 것

- 출발지와 목적지의 네트워크 정보

- 목적지로 가는 경로

출발지와 목적지 사이에 어떤 경로들이 있는지 알고 있어야 그 중에서 최적 경로를 선택할 수 있습니다.

- 최적 경로

데이터를 전달하기 위한 최적의 경로를 저장하는 곳을 routing table이라고 합니다.

라우터는 전달받은 패킷의 목적지 주소를 자신의 routing table과 비교하여 어느 라우터에게 넘겨줄지를 판단하게 됩니다.

routing table에 포함해야 하는 필수 정보는 (목적지 호스트, 다음 홉) 조합입니다.

목적지 호스트에는 패킷의 최종 목적지가 되는 호스트의 주소 값을,

다음 홉에는 목적지 호스트까지 패킷을 전달하기 위한 인정 경로를 지정합니다.

즉, 바로 다음 홉에 위치한 라우터의 주소를 기록합니다.

routing table 구성 요소

Mask

목적지 주소

다음 홉 주소

Flag(U, G, H 등)

참조 횟수(reference count)

사용(Use): 목적지로 전달된 패킷 수

인터페이스(interface): 인터페이스 명칭 표시

- 지속적인 네트워크 상태 확인

데이터를 전달해주려는 경로는 알지만 만일 그 경로가 down된 상태여서 사용할 수 없다면 그 경로는 사용할 수 없습니다.

routing table에 저장된 경로로 전달이 가능한 상태인지 지속적으로 네트워크 상태를 확인해서 항상 올바른 최신 정보로 유지해야 합니다.

* 라우팅 결정에 이용하는 주요 정보들

토폴로지

트래픽 부하

링크 비용: 홉 수(거쳐가야 하는 지점의 개수), 비용, 지연(latency), 처리율 등

Routing Table 경로탐색 우선 순위

1. 직접 전달 여부 확인(네트워크 주소로 확인)

2. 호스트 지정 전달 여부 확인(라우팅 테이블 참조)

- 목적지에 대한 호스트 정보를 저장해서 경로 점검, 보안을 위한 특정 경로 사용 시에 사용

3. 네트워크 지정 전달 여부 확인(라우팅 테이블 참조)

- 목적지에 대한 모든 호스트 정보 대신 네트워크 주소에 대한 정보만을 저장합니다.

라우팅 테이블의 크기를 줄일 수 있습니다.

 ( ex. 100개의 호스트가 단일 네트워크 상으로 연결되어 있다면, 라우팅 테이블은 1개의 네트워크 정보만 저장 )

4. 디폴트 전달

- 라우팅 테이블에 명시되어 있지 않은 주소에 대하여 사용합니다.

인터넷이 너무 광범위하여 모든 정보를 저장할 수 없기 때문에 만들어졌습니다.

위와 같은 우선순위로 패킷을 보낼 interface를 결정합니다.

HELLO/ECHO 패킷

라우터 초기화 과정에서 가장 먼저 할 일은 주변 라우터의 정보를 파악하는 것입니다.

각 라우터는 주변에 연결된 라우터에 초기화를 위한 HELLO 패킷을 전송해 경로 정보를 얻습니다.

라우터 사이의 전송 지연 시간을 측정하기 위해서 ECHO 패킷을 전송하는데, ECHO 패킷을 수신한 호스트는 송신 호스트에 즉각 회신하게 됩니다.

임의의 라우터가 획득한 정보를 각 라우터에 통보함으로써 경로 정보를 공유합니다.

라우팅 처리 방법

라우팅 정보 관리 방법에는 소스 라우팅, 분산 라우팅, 계층 라우팅 등이 있습니다.

소스 라우팅(Source Routing)

패킷을 전송하는 호스트가 목적지 호스트까지의 전달 경로를 스스로 결정하는 방식입니다.

소스 라우팅을 지원하기 위해서는 전송 경로 정보를 직접 라우팅 테이블에 관리해야 합니다.

또한 이러한 경로 정보를 전송 패킷에 기록해야 합니다.

중간 라우터에서는 전송 패킷에 포함된 경로 정보를 이용해 패킷을 중개함으로써 최종 목적지까지 올바르게 전달할 수 있습니다.

따라서 소스 라우팅 방식은 모든 라우팅 정보를 송신 호스트가 관리하므로 중간 라우터는 라우팅 테이블을 따로 관리할 필요가 없습니다.

분산 라우팅(Distributed Routing)

라우팅의 정보가 분산되는 방식입니다.

패킷의 전송 경로에 위치한 각 라우터가 효율적인 경로 선택에 참여하며, 데이터그램 방식에서 많이 사용합니다.

장점은 네트워크에 존재하는 호스트 수가 많아질 수록 다른 방식보다 효과적일 수가 있다는 것입니다.

라우터가 관리하는 경로 정보는 다음 경로를 선택하기 위한 내용을 포함하는데 네트워크 상황에 따라 적절히 변경하는 동적 특징이 있습니다.

중앙 라우팅(Centralized Routing)

RCC(Routing Control Center)라는 특별한 호스트를 사용해 전송 경로에 관한 모든 정보를 관리하는 방식입니다.

따라서 패킷 전송을 원하는 송신 호스트는 반드시 RCC로부터 목적지 호스트까지 도착하기 위한 경로 정보를 미리 얻어야 합니다.

이 정보를 이용해 송신 호스트는 소스 라우팅과 동일한 원리로 패킷을 전송할 수 있습니다.

장점은 경로 정보를 특정 호스트가 관리하기 때문에 다른 일반 호스트가 경로 정보를 관리하는 부담을 줄일 수 있다는 것입니다.

그러나 네트워크 규모가 커짐에 따라 RCC에 과중한 트래픽을 주어 RCC가 병목이 되어 전체 효율이 떨어질 수 있다는 단점이 있습니다.

계층 라우팅(Hierarchical Routing)

분산 라우팅 기능과 중앙 라우팅 기능을 적절히 조합하는 방식으로, 전체 네트워크의 구성을 계층 형태로 관리합니다.

일반적으로 네트워크 규모가 계속 커지는 환경에 효과적입니다.