컴넷) (11.08)

게이트웨이의 MAC 주소가 필요한 이유는

내 컴퓨터가 인터넷 세상으로 데이터를 내보내기 위해, 그 데이터를 가장 먼저 받아줄 '물리적인 다음 장치(게이트웨이)'에게 데이터를 직접 전달해야 하기 때문입니다.

그리고 로컬 네트워크(우리 동네) 안에서 장치 간에 데이터를 직접 전달할 때 사용하는 유일한 주소가 바로 MAC 주소입니다. IP 주소는 최종 목적지에 대한 정보일 뿐, 바로 옆 장비에게 가는 길을 알려주지는 못합니다.

 

 

 

 

 

 

 

 

 

맞다, 라우터 내에서는, l2계층이엇던가

그게 이더넷 뭐시기?

• 사용자님께서 질문하신 "라우터 내에서는" 이라는 부분이 바로 이 영역을 뜻합니다.
• 이 로컬 네트워크 안에서의 통신은 전적으로 **2계층(데이터 링크 계층)**의 규칙을 따릅니다.
• 그리고 이 2계층에서 사용하는 가장 대표적인 기술(프로토콜)이 바로 **이더넷(Ethernet)**입니다.

 

 

 

 

 

"IP 주소가 어차피 다 다른데, 그냥 IP 주소로 (로컬 네트워크에서도) 구분하면 안 되냐는 거야"

결론부터 말씀드리면, '그렇게 할 수 없도록 기술이 처음부터 설계되었기 때문' 입니다.

 

ㅇㅇ;

이유 1: 스위치는 'IP 주소'를 모르는 기계입니다.

로컬 네트워크의 교통정리를 담당하는 **스위치(Switch)**는 2계층(L2) 장비입니다. 이는 스위치가 IP 주소(3계층 정보)를 해석할 능력이 전혀 없다는 것을 의미합니다.

 

 

 

 

 

• 스위치의 유일한 임무: 스위치는 들어온 데이터 뭉치(프레임)의 겉봉투에 적힌 **'목적지 MAC 주소'**만 봅니다. 그리고 자신의 목록(MAC 주소 테이블)을 보고 "아, 이 MAC 주소는 3번 포트에 연결되어 있군" 하고 해당 포트로 데이터를 전달하는, 아주 빠르고 단순한 작업만 반복합니다.
• 스위치에게 IP 주소란?: 스위치에게 IP 주소는 그저 의미 없는 숫자의 나열, 즉 데이터의 '내용물' 중 일부일 뿐입니다. 스위치는 원칙적으로 그 내용물을 뜯어보지 않습니다. 겉봉투의 MAC 주소만 보고 전달할 뿐입니다.

 

 

 

 

 

아 맞다 그리고 궁금햇던게, ip 주소<mac주소 몰라도 이더넷 스위치의 self -learning으로 알아낼수있는줄 알았는데, 그거는, 해당 mac주소가 몇번 포트에 연결되어있는지에 대한거엿고 >?

 

 

MAC 주소 → 포트 번호

 

 

 

 

 

 

 

 

 

 

1. "이거 언제 했더라?": ARP 요청이 발생한 순간

ARP 요청은 크롬 브라우저 주소창에 가이아 서버 주소를 넣고 엔터를 치는 바로 그 직후, 실제 데이터(HTTP 요청)를 보내기 직전에 발생했습니다.

컴퓨터의 생각 흐름은 이렇습니다.

1. 목표 설정: "좋아, 미국에 있는 가이아 서버(gaia.cs.umass.edu)에게 웹페이지를 달라고 요청해야지!"
2. 주소 확인: DNS를 통해 가이아 서버의 IP 주소를 알아냅니다. (예: 128.119.245.12)
3. 경로 판단: "어라? 이 IP 주소(128.119.x.x)는 내 IP 주소(165.29.x.x)랑 동네가 완전히 다르네. 이건 다른 네트워크구나!"
4. 다음 목적지 결정: "직접 보낼 수는 없으니, 일단 우리 학교 네트워크의 출입구인 **'기본 게이트웨이(라우터)'**에게 이 데이터를 넘겨줘야겠다." (게이트웨이 IP 주소는 ipconfig로 확인했듯이 이미 알고 있습니다.)
5. 문제 발생: "게이트웨이에게 데이터를 보내려면 게이트웨이의 MAC 주소가 필요한데, 지금은 모르네?"
6. 해결 시도 (바로 이 순간!): 바로 이 시점에, 내 PC는 네트워크 전체에 ARP 요청을 브로드캐스트합니다.

실습에서 우리가 arp -d * 명령어로 캐시를 일부러 지운 이유가 바로 이것입니다. 캐시를 지우지 않았다면 5번 단계에서 "아, 게이트웨이 MAC 주소는 이미 알고 있네" 하고 ARP 요청 없이 바로 데이터를 보냈을 것이고, 우리는 와이어샤크로 ARP 패킷을 캡처할 수 없었을 것입니다.

2. "미국에 있는 라우터에게 요청했나?": 가장 중요한 포인트

아니요, 절대로 아닙니다.

이것이 가장 중요합니다. ARP 요청은 절대로 라우터를 넘어 다른 네트워크로 가지 못합니다.

우리 PC가 ARP로 물어본 대상은 미국에 있는 그 어떤 서버나 라우터가 아니라, **바로 우리 강의실 네트워크에 함께 연결된, 내 옆에 있는 '나의 기본 게이트웨이(우리 학교 전산실 라우터)'**였습니다.

와이어샤크로 캡처한 ARP 요청 패킷의 내용을 자세히 보면 이렇게 쓰여있었을 겁니다.

"Who has 165.29.252.1? Tell 165.29.252.13"
(해석: "혹시 IP 주소가 **165.29.252.1(우리 학교 라우터)**이신 분, **165.29.252.13(내 PC)**에게 당신의 MAC 주소를 알려주세요!")

 

 

 

 

 

 

 

 

 

 

 

 

두 실습의 공통점과 차이점

구분	실습 1: ARP 실습	실습 2: ICMP (ping) 실습
최종 목적지	미국 가이아 서버	미국 가이아 서버
사용한 프로토콜	HTTP (웹 페이지 요청)	ICMP (네트워크 연결 확인)
관찰 대상	ARP Request / Reply	ICMP Echo Request / Reply
실습의 핵심	**'데이터를 보내기 전'**에 일어나는 **'사전 준비 과정'**을 캡처	**'실제 데이터가 오고 가는 과정'**을 직접 캡처

이제 두 실습에서 '우리 학교 라우터의 MAC 주소'와 '가이아 서버'가 각각 어떤 역할을 했는지 설명하겠습니다.

---

실습 1: ARP 실습 (주소 물어보기)

• 가이아 서버의 역할: 이 실습에서 가이아 서버는 ARP를 발생시키기 위한 '미끼' 또는 '방아쇠(Trigger)' 역할만 했습니다.
  • 내 컴퓨터가 "아, 목적지가 멀리 있네? 그럼 라우터에게 보내야겠다!" 라고 생각하게 만드는 원인 제공자였을 뿐입니다.
• 실습의 주인공: ARP 요청(Request)과 응답(Reply) 그 자체였습니다.
  • 실제로 우리가 관찰하고 분석한 것은 가이아 서버와 주고받은 데이터가 아니라, 내 PC와 '우리 학교 라우터' 사이에서 일어난 "MAC 주소 좀 알려줘" / "여기 있어" 라는 대화였습니다.
  • 결론: 네, 말씀하신 대로 이 실습은 사실상 '우리 학교 라우터의 MAC 주소를 알아내는 과정'을 훔쳐보는 것이 목표였습니다. 가이아는 그 과정을 유발하기 위한 도구였을 뿐입니다.

실습 2: ICMP ping 실습 (안부 묻기)

• 가이아 서버의 역할: 이 실습에서 가이아 서버는 대화의 '상대방'이자 실습의 '주인공' 입니다.
  • 우리는 ping 명령어를 통해 가이아 서버에게 직접 "너 거기 잘 있니?"(ICMP Echo Request) 라고 말을 걸었습니다.
  • 그리고 가이아 서버가 직접 "응, 나 잘 있어!"(ICMP Echo Reply) 라고 대답하는 것을 확인했습니다.
• '우리 학교 라우터의 MAC 주소'의 역할: 이 실습에서는 '보이지 않는 조력자' 역할을 했습니다.
  • 우리가 ping 명령어를 실행했을 때, 우리 컴퓨터는 이미 첫 번째 실습(또는 그 이전의 통신)을 통해 라우터의 MAC 주소를 알고 있는 상태였습니다. (ARP 캐시에 저장되어 있음)
  • 그래서 별도의 ARP 요청 없이, 바로 라우터의 MAC 주소를 목적지로 하여 ICMP 패킷을 보낼 수 있었습니다.
  • 만약 이 실습 전에 arp -d * 로 캐시를 지웠다면, ping을 실행하는 순간에도 ARP가 먼저 발생했을 것입니다. 하지만 실습의 초점은 ICMP 자체에 있었기 때문에 그 과정은 생략했습니다.

최종 정리

• ARP 실습: 가이아 서버로 가기 위해, '우리 학교 라우터'의 주소를 물어보는 과정을 관찰했습니다. (주인공: 내 PC와 라우터)
• ICMP 실습: '우리 학교 라우터'를 통해, '가이아 서버'와 직접 안부를 묻는 대화를 관찰했습니다. (주인공: 내 PC와 가이아 서버)

 

 

 

 

 

 

 

 

 

 

 

 

 

와이어샤크 실습 수업 정리 (ARP & ICMP)

이 수업은 네트워크 프로토콜인 ARP와 ICMP의 동작 원리를 와이어샤크(Wireshark)를 통해 직접 패킷을 캡처하고 분석하는 실습입니다.

1. 실습 준비 및 기본 명령어 확인

실습을 진행하기 전에 몇 가지 기본적인 설정과 확인이 필요합니다.

가. 관리자 권한으로 명령 프롬프트 실행

• 이유: ARP 캐시를 수정하는 등 네트워크 관련 명령어는 일반 사용자 권한으로는 실행되지 않으므로 관리자 권한이 반드시 필요합니다.
• 방법: '명령 프롬프트' 아이콘에 마우스 오른쪽 버튼을 클릭하여 '관리자 권한으로 실행'을 선택합니다.

나. 작업 폴더로 이동

• ipconfig, arp와 같은 네트워크 명령어 실행 파일들은 특정 폴더에 모여 있습니다.
• 명령어: cd C:\Windows\System32
• 이 폴더로 이동해야 명령어가 원활하게 실행됩니다. (환경 변수 설정에 따라 이동이 필요 없을 수도 있습니다.)

다. 내 컴퓨터 네트워크 정보 확인 (ipconfig)

ipconfig 명령어는 현재 컴퓨터의 네트워크 인터페이스 설정 정보를 보여줍니다.

1. ipconfig:
   • IPv4 주소: 내 컴퓨터의 IP 주소 (수업 예시: 165.29.x.x 또는 172.20.x.x). 가상 머신(VMware 등)이 만든 가상 인터페이스가 아닌 실제 사용하는 이더넷 인터페이스의 주소를 확인해야 합니다.
   • 서브넷 마스크: 보통 255.255.255.0으로 설정되어 있습니다.
   • 기본 게이트웨이: 인터넷에 접속하기 위해 거쳐야 하는 나와 직접 연결된 라우터의 IP 주소입니다. 이 주소가 설정되어 있어야 외부 인터넷 통신이 가능하며, 보통 내 IP 주소의 마지막 자리만 1로 끝나는 형태일 가능성이 높습니다 (예: 내 IP가 165.29.252.13이면 게이트웨이는 165.29.252.1).
2. ipconfig /all:
   • 더 상세한 정보를 보여주며, 가장 중요한 것은 **물리적 주소(Physical Address)**를 확인할 수 있다는 점입니다.
   • 물리적 주소: 이것이 바로 MAC 주소(MAC Address) 또는 이더넷 주소입니다. 48비트 길이이며, 16진수 12자리로 표현됩니다 (예: A1-B2-C3-D4-E5-F6).

---

2. 첫 번째 실습: ARP (Address Resolution Protocol)

ARP는 IP 주소를 MAC 주소로 변환(매핑)해주는 프로토콜입니다.

가. ARP가 필요한 이유

네트워크 통신은 계층적으로 이루어집니다.

• 상황 1 (같은 네트워크 통신): 같은 이더넷 망에 있는 컴퓨터 A가 B에게 IP 패킷을 보내려 할 때, IP 주소는 알지만 실제 데이터를 전달하려면 이더넷 프레임으로 감싸야 합니다. 이 프레임 헤더에는 목적지의 MAC 주소가 반드시 필요합니다. A는 B의 IP 주소는 알지만 MAC 주소는 모르기 때문에 통신할 수 없습니다.
• 상황 2 (다른 네트워크 통신): 내 컴퓨터가 미국에 있는 구글 서버(다른 네트워크)에 접속하려 할 때, 패킷을 일단 우리 학교 전산실에 있는 **라우터(기본 게이트웨이)**에게 보내야 합니다. 내 컴퓨터는 라우터의 IP 주소는 알지만, 패킷을 전달하기 위해 필요한 라우터의 MAC 주소는 모릅니다.

이처럼 "IP 주소는 아는데, 그 IP에 해당하는 기기의 MAC 주소를 모를 때" ARP가 사용됩니다.

나. ARP 동작 방식

ARP는 두 종류의 메시지로 동작합니다.

1. ARP Request (요청):
   • "IP 주소 165.29.252.1을 가진 분, 당신의 MAC 주소는 무엇입니까?"라고 외치는 메시지입니다.
   • 이 메시지는 브로드캐스트(Broadcast) 방식으로 해당 네트워크에 연결된 모든 기기에게 전송됩니다.
2. ARP Reply (응답):
   • 요청을 받은 기기들 중, 해당 IP 주소를 가진 기기만이 "그 IP는 제 것입니다. 제 MAC 주소는 A1-B2-C3-D4-E5-F6입니다."라고 응답합니다.
   • 이 응답은 요청을 보낸 기기에게만 유니캐스트(Unicast) 방식으로 전송됩니다.

다. ARP 캐시 (Cache)

• 매번 통신할 때마다 ARP 요청/응답을 주고받는 것은 비효율적입니다.
• 그래서 한 번 알아낸 IP-MAC 주소 매핑 정보는 컴퓨터의 메모리(캐시)에 일정 시간 동안 저장해 둡니다. 이를 ARP 캐시라고 합니다.
• arp -a: 현재 내 컴퓨터의 ARP 캐시에 저장된 정보 목록을 보여줍니다. (인터넷 주소 = IP 주소, 물리적 주소 = MAC 주소)

라. ARP 실습 절차

실습 목표는 ARP Request와 Reply 패킷을 직접 발생시켜 와이어샤크로 캡처하는 것입니다.

1. 와이어샤크 캡처 시작: 실제 사용하는 이더넷 인터페이스를 더블클릭하여 패킷 캡처를 시작합니다.
2. ARP 캐시 삭제: 캐시에 정보가 남아있으면 ARP 요청을 보내지 않으므로, 기존 캐시를 모두 삭제합니다.
   • 명령어: arp -d *
   • 주의: 캐시를 지우자마자 바로 다음 단계를 진행해야 합니다. 잠시만 지체해도 다른 통신 때문에 캐시가 다시 채워질 수 있습니다.
3. ARP 요청 유발: 외부 사이트(예: 수업에서 사용된 가이아 서버)에 접속을 시도하여 기본 게이트웨이(라우터)의 MAC 주소를 묻는 ARP Request를 강제로 발생시킵니다.
   • 주의: 브라우저 자체의 캐시도 삭제해야 패킷이 확실히 발생합니다. (인터넷 사용 기록 삭제)
4. 와이어샤크 캡처 중지 및 분석:
   • 캡처를 중지하고, 필터 창에 arp를 입력하여 ARP 패킷만 확인합니다.
   • ARP Request 찾기: Destination이 Broadcast로 되어 있고, Info 창에 "Who has [라우터 IP 주소]? Tell [내 IP 주소]" 라고 쓰인 패킷을 찾습니다.
   • ARP Reply 찾기: 바로 다음에 따라오는 패킷으로, Source에 라우터의 정보가, Destination에 내 정보가 있으며 Info 창에 "[라우터 IP 주소] is at [라우터 MAC 주소]" 라고 쓰인 패킷을 찾습니다.
   • 이 두 패킷을 분석하여 과제를 해결합니다.

---

3. 두 번째 실습: ICMP (Internet Control Message Protocol)

ICMP는 네트워크 상태를 진단하고 오류를 보고하기 위해 사용되는 "디버깅용" 프로토콜입니다. IP 프로토콜을 도와주는 역할을 합니다.

가. ICMP의 특징

• IP 계층 바로 위에서 동작하며, 일반 데이터 전송이 아닌 제어 및 관리 메시지를 전달합니다.
• ICMP 메시지는 **타입(Type)**과 코드(Code) 두 숫자의 조합으로 메시지의 의미가 결정됩니다.

나. ping 명령어와 ICMP

• ping은 가장 대표적인 네트워크 진단 유틸리티로, ICMP를 사용하여 특정 목적지까지 네트워크 연결이 원활한지 확인합니다.
• ping의 동작 원리:
  1. 출발지 컴퓨터가 목적지 컴퓨터로 ICMP Echo Request (요청) 메시지 (Type 8, Code 0)를 보냅니다. "너 살아있니?"라고 묻는 것과 같습니다.
  2. 메시지를 받은 목적지 컴퓨터는 ICMP Echo Reply (응답) 메시지 (Type 0, Code 0)를 되돌려 보냅니다. "나 여기 살아있어."라고 대답하는 것과 같습니다.
  3. 응답이 돌아오면 '연결 성공'이며, 돌아오지 않으면('요청 시간이 만료되었습니다') 네트워크에 문제가 있거나 상대방이 응답을 안 하도록 설정한 것입니다. (수업 예: 네이버는 응답 안 함, 구글은 응답 함)

다. ICMP 실습 절차

1. 와이어샤크 캡처 시작.
2. ping 명령어 실행: 명령 프롬프트에서 특정 서버(예: ping gaia.cs.umass.edu)로 ping을 실행합니다.
   • Windows는 기본적으로 4번의 ping을 보냅니다.
3. 와이어샤크 캡처 중지 및 분석:
   • 캡처를 중지하고 필터 창에 icmp를 입력합니다.
   • 총 8개의 패킷(요청 4개, 응답 4개)이 캡처됩니다.
   • 이 중 첫 번째 Echo Request와 첫 번째 Echo Reply 패킷을 찾아 분석하여 과제를 해결합니다.

 

 

 

 

 

 

1. 기본 게이트웨이 & MAC 주소

Q: "기본 게이트웨이 > 나와 붙어있는 라우터의 IP 주소 < 왜 컴마다 다르지?"

A: 아주 정확한 지적입니다! 하지만 약간의 오해를 바로잡으면 완벽해집니다.

• 같은 네트워크 안에서는 동일합니다: 예를 들어, 여러분의 집 공유기에 연결된 모든 컴퓨터, 스마트폰, TV는 모두 동일한 기본 게이트웨이 주소(보통 192.168.0.1 같은 공유기 자신의 IP)를 가집니다. 학교의 같은 강의실에 있는 컴퓨터들도 마찬가지입니다. 왜냐하면 '기본 게이트웨이'는 그 네트워크의 '유일한 출입문' 역할을 하기 때문입니다.
• 다른 네트워크에 있으면 다릅니다: 컴마다 다른 경우는, 그 컴퓨터들이 서로 다른 네트워크에 속해있을 때입니다. 여러분의 집 네트워크와 학교 네트워크, 카페의 와이파이 네트워크는 모두 별개의 네트워크입니다. 따라서 각 네트워크의 '출입문'인 라우터(게이트웨이) IP 주소도 당연히 다릅니다.

결론: '모든' 컴퓨터마다 다른 것이 아니라, '서로 다른 네트워크에 있는' 컴퓨터마다 다른 것입니다.

Q: "물리적 주소 < MAC주소, 이더넷 주소. 아, 장치마다 부여된다고 했으니까? 나의 랜카드?"

A: 네, 100% 정확하게 이해하셨습니다.

• MAC 주소는 전 세계의 모든 네트워크 장치(랜카드, 와이파이 칩 등)가 공장에서 출고될 때부터 부여받는 고유한 하드웨어 식별 번호입니다.
• 절대 바뀌지 않으며, 마치 사람의 지문이나 주민등록번호와 같습니다.
• 따라서 '나의 물리적 주소'는 곧 '내 컴퓨터에 장착된 랜카드의 MAC 주소'를 의미합니다.

---

2. ICMP

Q: "icmp 머였니?" (ICMP가 뭐였지?)

A: ICMP는 "네트워크 진단 및 오류 보고용 프로토콜" 입니다.

• Internet Control Message Protocol의 약자입니다.
• 우리가 웹서핑을 하거나 파일을 다운로드하는 '실제 데이터'를 나르는 역할이 아닙니다.
• 대신, 네트워크가 제대로 동작하는지 상태를 점검하고, 문제가 생겼을 때 "목적지에 도달할 수 없습니다" 와 같은 에러 메시지를 알려주는 역할을 합니다.
• 가장 대표적인 사용 예가 바로 ping 명령어입니다. ping은 ICMP를 이용해서 "너 살아있니?" (Echo Request)라는 메시지를 보내고, 상대방이 "응, 나 살아있어!" (Echo Reply)라고 대답하는지를 확인하여 네트워크 연결성을 테스트합니다.

---

3. ARP (주소 변환)

이 부분이 가장 중요하고 헷갈리는 부분입니다. 메모하신 내용을 순서대로 따라가며 설명해 드릴게요.

Q: "주소변환, 레솔루션 > 한 명의 사람에게 식별자 여러 개, 이거 뭔 관련?"

A: 이것은 ARP가 왜 필요한지를 설명하는 최고의 비유입니다.

• 한 명의 사람 (One Person) = 내 컴퓨터의 랜카드 (One Interface)
• 이 랜카드에는 두 종류의 주소가 있습니다.
  1. IP 주소 (논리적 주소): 네트워크 상의 '주소'. 이사를 가면 바뀌듯이, 다른 네트워크에 접속하면 바뀝니다. (예: 192.168.1.10)
  2. MAC 주소 (물리적 주소): 랜카드 자체의 '고유번호'. 절대 바뀌지 않습니다. (예: A1-B2-C3-D4-E5-F6)

네트워크 통신은 이 두 주소를 모두 사용합니다. IP 주소는 멀리 있는 목적지까지의 '최종 경로'를 찾을 때 쓰고, MAC 주소는 바로 '옆집'으로 데이터를 건네줄 때 씁니다. ARP는 "IP 주소는 아는데, 그 녀석의 MAC 주소를 모를 때" 물어보는 프로토콜입니다. 이것이 바로 주소 변환(Address Resolution)입니다.

Q: "이더넷 프레임으로 포장하면 가겠지? ... 이더넷, MAC 주소 써야 ... 나는 IP 주소밖에 모른다고 가정. 그래서 변환 필요."

A: 네, 완벽한 흐름입니다.

1. A 컴퓨터가 B 컴퓨터(같은 네트워크에 있는)에게 데이터를 보내려 합니다. A는 B의 IP 주소는 알고 있습니다.
2. 하지만 실제 데이터는 이더넷 프레임이라는 택배 상자에 담아서 보내야 합니다.
3. 이 택배 상자의 운송장(이더넷 헤더)에는 받는 사람의 MAC 주소를 반드시 적어야 합니다.
4. A는 B의 MAC 주소를 모릅니다. 운송장을 쓸 수 없으니 택배를 보낼 수 없는 상황!
5. 바로 이때 ARP를 사용해 "IP 주소 OOO인 사람, MAC 주소 좀 알려줘!" 라고 물어보는 것입니다.

Q: "가이아(외부 서버)로 보낼 때 ... 나는 라우팅할 수 없으니 라우터까지는 줘야지. ... 이거 왜 self-learning으로 안 되지?"

A: 이 부분이 ARP의 핵심입니다.

• 내 컴퓨터가 멀리 있는 가이아 서버로 데이터를 보낼 때, 직접 가이아 서버의 MAC 주소를 묻지 않습니다. 어차피 직접 갈 수 없기 때문이죠.
• 내 컴퓨터는 "이건 우리 동네(네트워크) 밖이네. 일단 우리 동네 출입구인 기본 게이트웨이(라우터)에게 맡겨야겠다"라고 판단합니다.
• 즉, 최종 목적지는 가이아 서버이지만, 당장 데이터를 전달해야 할 다음 목적지는 우리 학교 라우터인 셈입니다.
• 그래서 내 컴퓨터는 가이아 서버가 아닌, 라우터의 MAC 주소를 알아내기 위해 ARP를 사용합니다. ("라우터 IP 주소 아시는 분, MAC 주소 좀 알려주세요!")
• 'self-learning' (스위치의 학습 기능)은 MAC 주소 테이블을 만드는 기능이고, ARP는 IP를 MAC으로 '변환'하는 질문-응답 프로토콜이라 역할이 다릅니다. 모르는 주소를 알아내려면 일단 물어보는 과정(ARP)이 먼저 필요합니다.

Q: "질문 패킷-브로드캐스팅 ... 딱 한 명만 손듦 ... 유니캐스트로 온 게 대답"

A: 맞습니다.

• ARP Request (요청): "이 IP 주소 가진 사람 누구야?" -> 동네 전체에 외칩니다 (브로드캐스트).
• ARP Reply (응답): 해당 IP를 가진 컴퓨터가 "그거 난데, 내 MAC 주소는 이거야" -> 물어본 컴퓨터에게만 조용히 알려줍니다 (유니캐스트).

Q: Frame Type: 0x0806의 의미는?

A: 이것은 이더넷 프레임이라는 택배 상자에 붙어있는 '내용물 스티커'입니다.

• 0x0806은 "이 상자 안에는 ARP 관련 내용물이 들어있습니다" 라는 뜻입니다.
• 참고로, 인터넷 데이터를 담고 있는 IP 패킷의 경우 이 값이 0x0800으로 표시됩니다.

---

4. 추가 질문 정리

Q: 내가 보낸 ARP 요청 패킷에 왜 내 MAC 주소가 들어가는가?

A: 답장을 받기 위한 '반송 주소' 입니다. 요청을 받은 상대방이 응답(Reply)을 해줘야 하는데, 누구에게 답을 보내야 할지 알려줘야 합니다. 그래서 요청 패킷에 "나는 OOO인데, 너의 주소는 뭐니?" 라고 내 주소(MAC)를 함께 실어 보내는 것입니다.

Q: ping 결과에서 TTL 값이 왜 다른가요?

A: TTL (Time To Live)은 패킷이 인터넷 세상에서 영원히 떠도는 것을 막기 위한 '수명' 값입니다. 라우터를 하나 거칠 때마다 1씩 줄어듭니다. ping 응답에서 보이는 TTL 값이 다른 이유는 크게 두 가지입니다.

1. 초기 TTL 값이 달라서: Windows, Linux, macOS 등 운영체제마다 설정하는 초기 TTL 값이 다릅니다. (예: Windows는 128, Linux는 64)
2. 거쳐온 라우터 수가 달라서 (홉 카운트): 응답 패킷이 나에게 돌아오기까지 몇 개의 라우터를 거쳤는지에 따라 최종적으로 보이는 TTL 값이 달라집니다. (최종 TTL = 초기 TTL - 거쳐온 라우터 수)

메모하신 내용 모두가 네트워크의 핵심을 찌르는 중요한 개념들입니다. 이 내용만 완벽히 이해하셔도 네트워크의 기본 동작 원리를 거의 마스터하신 것과 같습니다.

 

 

 

 

 

 

 

 

 

 

 

 

아 라우터 l3는 다른 ㄴ네트워크를 연결하는거고 2계층은 같은 네트워크를 연결하는건데
만약 l2에 있는게 일반 pc라서 한개면 상관없지만,ㅡ 학교등이면, 같은 네트워크로 ,
즉, 이더넷 스위치로 공유링크로 여러개 연결되어있을수있기때문인가

 

 

근데 ip주소는 어차피 pc마다 다르잖아

그리고 궁금한게 ip주소는 갯수가 적어서 사용안할떄는 다시 가져가지는데, 그러면, 길찾기할때 혼동이 안생기나, 
라우팅 알고리즘 돌릴떄, 테이블이 바껴야하잔항, 어떨떄는

 

 

168.126.0.0/16 이라는 거대한 네트워크 덩어리(Network Block)로 가려면, 저쪽 B 라우터에게 넘겨라."

즉, 라우터는 개별 집 주소 하나하나를 기억하는 것이 아니라, **"부산시 해운대구'라는 동네(네트워크)로 가려면 경부고속도로를 타야 한다"**는 식으로 거대한 네트워크 덩어리의 경로만을 기억합니다.

IP 주소 변경은 '우리 동네 안에서' 일어나는 일

사용자님의 PC가 카페에 가서 새로운 IP 주소를 받는 것은, '우리 동네(로컬 네트워크)' 안에서 일어나는 작은 변화일 뿐입니다.

 

 

 

 

 

 

 

 

 

상황: 내 PC가 같은 강의실에 있는 친구 PC에게 데이터를 보낸다.

• 내 PC 정보: IP 192.168.1.10, MAC AA-AA-AA-AA-AA-AA
• 친구 PC 정보: IP 192.168.1.20, MAC BB-BB-BB-BB-BB-BB
• 연결 장비: 두 PC는 모두 **'이더넷 스위치'**에 연결되어 있습니다.

1. 데이터 전송 시작 (내 PC의 OS, 3계층)

• 내가 친구에게 보낼 데이터(예: "안녕")를 만듭니다.
• OS는 이 데이터를 IP 패킷으로 포장합니다.
  • 출발지 IP: 192.168.1.10
  • 목적지 IP: 192.168.1.20
• OS는 판단합니다. "목적지 IP를 보니 나랑 같은 동네(192.168.1 네트워크)네. 이건 라우터로 보낼 필요 없이 직접 전달하면 되겠다."

2. 마지막 포장 단계 (내 PC의 OS, 2계층)

• 이제 이 IP 패킷을 실제로 케이블에 실어 보낼 이더넷 프레임으로 마지막 포장을 해야 합니다.
• 이 프레임 헤더에는 목적지 MAC 주소를 반드시 적어야 합니다.
• 문제 발생: 내 OS는 친구 PC의 IP 주소 192.168.1.20은 알지만, MAC 주소는 모릅니다.

3. ARP 요청 (Address Resolution Protocol)

• 내 PC는 이더넷 프레임을 완성할 수 없으므로, 잠시 데이터 전송을 멈춥니다.
• 그리고 스위치에 연결된 모든 PC에게 소리칩니다. (브로드캐스트)
• "혹시 IP 주소가 192.168.1.20인 분 계신가요? 계시면 당신의 MAC 주소 좀 알려주세요! 저는 AA-AA-... 입니다."

4. ARP 응답

• 강의실의 다른 모든 PC는 이 외침을 무시합니다.
• 오직 친구 PC(192.168.1.20)만이 응답합니다. (유니캐스트)
• "네, 그 IP 주소는 저입니다. 제 MAC 주소는 BB-BB-... 입니다."

5. 진짜 데이터 전송 (다시 2계층)

• 이제 내 PC는 친구의 MAC 주소를 알게 되었습니다. (이 정보는 ARP 캐시에 저장해 둡니다)
• 드디어 멈췄던 이더넷 프레임 포장을 완성할 수 있습니다.
  • 출발지 MAC: AA-AA-...
  • 목적지 MAC: BB-BB-...
  • 내용물: [출발지 IP: 192.168.1.10, 목적지 IP: 192.168.1.20, 데이터: "안녕"]
• 이 완성된 프레임을 스위치로 보냅니다.

6. 스위치의 역할 (물리적 전달)

• 스위치는 이 프레임을 받습니다.
• 스위치는 프레임 헤더에 있는 목적지 MAC 주소 BB-BB-... 만을 봅니다. (IP 주소는 쳐다보지도 않습니다.)
• 스위치는 자신의 MAC 주소 테이블을 보고 "아, BB-BB-...는 5번 포트에 연결된 PC구나" 라는 것을 알고, 오직 5번 포트로만 이 프레임을 전달합니다.

---

결론: 왜 IP 주소만으로는 안되는가?

위 6단계 프로세스에서 보셨듯이, **3단계(ARP 요청)**와 6단계(스위치의 역할) 때문입니다.

1. OS 입장: IP 패킷을 최종적으로 포장할 '이더넷 프레임'을 만들려면 물리적인 주소(MAC)가 반드시 필요합니다. IP 주소만으로는 프레임 포장을 시작조차 할 수 없습니다.
2. 스위치 입장: 스위치는 IP 주소를 해석할 능력이 없는 기계입니다. 스위치가 데이터를 올바른 포트로 전달하기 위해 사용하는 유일한 정보는 MAC 주소입니다.

따라서, 비록 공유 링크 안의 호스트들이 서로 다른 IP 주소를 가지고 있더라도, 그들 사이의 통신을 물리적으로 중개해주는 '스위치'라는 장비를 통과하고, '이더넷'이라는 통신 규칙(프로토콜)을 준수하기 위해서는 반드시 IP 주소를 MAC 주소로 변환하는 과정(ARP)이 필수적인 것입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

"왜 IP 주소는 당연히 아는 것처럼 말하면서, MAC 주소는 모른다고 가정하는가?"

이 질문에 대한 답은 **'어떻게 그 주소를 알게 되었는가'**의 출처(Source)가 다르기 때문입니다.

---

IP 주소를 알게 되는 방법 (사용자 또는 프로그램이 알려준다)

우리가 통신을 시작할 때, 목적지의 IP 주소는 애초에 우리가 먼저 알고 있거나, 쉽게 알아낼 수 있습니다.

1. 직접 입력: ping 192.168.1.20 처럼 우리가 IP 주소를 직접 칩니다. 당연히 OS는 이 IP 주소를 알게 됩니다.
2. 도메인 이름 변환 (DNS): 우리가 웹 브라우저에 www.google.com 을 칩니다. 그러면 우리 컴퓨터는 가장 먼저 DNS 서버에 접속해서 "google.com의 IP 주소가 뭐야?" 라고 물어봅니다. DNS 서버가 "그건 172.217.25.142 야" 라고 알려주면, 비로소 우리 컴퓨터는 통신을 시작할 목적지 IP 주소를 알게 됩니다.
3. 프로그램에 설정: 온라인 게임을 할 때, 게임 클라이언트 프로그램은 접속해야 할 게임 서버의 IP 주소를 이미 내부적으로 알고 있습니다.

이처럼, 3계층(네트워크 계층) 통신은 '목적지 IP 주소를 아는 것'에서부터 시작합니다. IP 주소는 통신의 출발점이며, 사용자나 DNS 같은 시스템을 통해 OS에게 가장 먼저 주어지는 정보입니다.

 

 

 

 

 

 

 

 

 

상황 1: 같은 네트워크 통신 (옆집에 배달하기)

• 비유: 제가 101동 501호에 살고, 같은 동 친구(101동 804호)에게 직접 물건을 갖다 주려는 상황입니다.
• 실제 상황: 내 PC(IP 192.168.1.10)가 같은 네트워크에 있는 프린터(IP 192.168.1.50)로 인쇄 명령을 보내려 합니다.
  • 아는 것: 프린터의 IP 주소 (192.168.1.50)
  • 모르는 것: 프린터의 MAC 주소
• 해결책 (ARP): 내 PC가 "IP 주소 192.168.1.50인 분, MAC 주소 알려주세요!" 라고 ARP 요청을 보냅니다. 프린터가 "제 MAC 주소는 CC-CC-CC-CC-CC-CC 입니다" 라고 응답하면, 비로소 인쇄 데이터를 보낼 수 있습니다.

이 상황은 우리 실습에서는 직접 다루지 않았습니다. 왜냐하면 강의실의 모든 PC는 인터넷 접속을 위해 '다른 네트워크'와 통신하는 것이 주된 목적이었기 때문입니다. 하지만 원리는 동일합니다.

---

상황 2: 다른 네트워크 통신 (우체국에 택배 맡기기)

• 비유: 제가 서울에 살면서, 부산에 사는 친구에게 택배를 보내기 위해 일단 '서울 우체국'에 가야 하는 상황입니다.
• 실제 상황: 이것이 바로 우리 ARP 실습에서 했던 상황입니다!
  • 내 PC(IP 165.29.x.x)가 미국에 있는 가이아 서버(다른 네트워크)로 웹 페이지를 요청하려 합니다.
  • 내 PC는 "이건 다른 네트워크니까, 일단 우리 학교의 출입구인 **기본 게이트웨이(라우터)**에게 보내야겠다"고 판단합니다.
  • 아는 것: 기본 게이트웨이의 IP 주소 (예: 165.29.252.1, ipconfig로 확인해서 이미 알고 있음)
  • 모르는 것: 기본 게이트웨이의 MAC 주소
• 해결책 (ARP): 내 PC가 "IP 주소 165.29.252.1인 분, MAC 주소 알려주세요!" 라고 ARP 요청을 보냅니다. 라우터가 응답하면, 비로소 가이아 서버로 향하는 첫 번째 데이터 패킷을 라우터에게 보낼 수 있습니다.

---

결론

두 상황은 목적지가 **'같은 동네냐, 다른 동네냐'**의 차이만 있을 뿐, ARP를 사용하는 근본적인 이유는 같습니다.

• 상황 1의 목표: 최종 목적지(친구 PC)의 MAC 주소를 알아내기 위해 ARP를 사용한다.
• 상황 2의 목표: 다음 목적지(게이트웨이)의 MAC 주소를 알아내기 위해 ARP를 사용한다.

 

 

 

 

 

 

 

"외부 사이트 접속 시도" → "ARP 발생" 까지의 5단계 생각 흐름

상황: 내 PC가 arp -d * 로 ARP 캐시를 막 지운 상태에서, 크롬 브라우저에 http://gaia.cs.umass.edu를 입력하고 엔터를 눌렀다.

1. [목표 인식] "웹 페이지를 가져와야겠다."

• 크롬 브라우저가 OS에게 명령합니다. "저기 gaia.cs.umass.edu 서버에 가서 웹 페이지 좀 달라고 요청해 줘."

2. [주소 변환] "IP 주소부터 알아내자."

• OS는 가장 먼저 DNS 서버에 접속해서 "gaia.cs.umass.edu의 IP 주소가 뭐야?"라고 묻습니다.
• DNS 서버가 "그건 128.119.245.12 야"라고 알려줍니다.
• 이제 OS는 최종 목적지의 IP 주소를 알게 되었습니다.

3. [경로 판단] "이건 우리 동네가 아니군!"

• OS는 목적지 IP(128.119.245.12)와 자신의 IP(예: 165.29.252.13)를 비교합니다.
• IP 주소의 네트워크 부분이 완전히 다른 것을 보고, "이건 다른 네트워크에 있는 서버구나. 내가 직접 데이터를 전달할 수는 없겠다." 라고 판단합니다.

4. [다음 목적지 결정] "일단 게이트웨이에게 맡기자."

• OS는 "다른 네트워크로 가려면, 우리 네트워크의 출입구인 **'기본 게이트웨이(Default Gateway)'**를 통해 나가야 해." 라고 생각합니다.
• OS는 자신의 설정 정보(ipconfig로 확인 가능)를 보고 기본 게이트웨이의 IP 주소가 165.29.252.1 이라는 것을 확인합니다.
• 이제 '최종 목적지'는 가이아 서버지만, '당장 데이터를 전달해야 할 다음 목적지(Next Hop)'는 게이트웨이로 결정되었습니다.

5. [물리적 전달 준비] "어라? 게이트웨이의 MAC 주소를 모르네?" (★ 여기가 핵심!)

• OS는 이제 가이아 서버로 가는 데이터(IP 패킷)를 이더넷 프레임으로 포장해서 게이트웨이에게 보내려고 합니다.
• 이더넷 프레임의 규칙상, 겉봉투에는 반드시 받는 곳의 MAC 주소를 적어야 합니다.
• OS는 자신의 ARP 캐시(IP-MAC 주소록)를 찾아봅니다. "게이트웨이 IP(165.29.252.1)의 MAC 주소가 뭐지?"
• 하지만 방금 arp -d * 로 캐시를 지웠기 때문에, 주소록이 텅 비어있습니다.
• 바로 이 순간! 데이터를 보내기 위한 마지막 준비물인 MAC 주소가 없다는 것을 깨달은 OS는 모든 작업을 일시 중단하고 ARP 요청을 먼저 보냅니다.
• "IP 주소 165.29.252.1 가진 분, MAC 주소 알려주세요!"

이것이 바로 외부 사이트 접속을 '시도'하면, 실제 데이터 통신이 일어나기 '직전에' ARP Request가 '강제로 발생'하는 이유입니다. ARP는 성공적인 통신을 위한 필수적인 사전 준비 작업이기 때문입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

* 실험 1: ARP (Address Resolution Protocol)

이 실습의 핵심 목표는 다른 네트워크에 있는 서버(gaia.cs.umass.edu)로 통신을 시도할 때, 내 PC가 인터넷으로 나가기 위한 첫 번째 관문인 '기본 게이트웨이(라우터)'의 MAC 주소를 알아내기 위해 ARP를 사용하는 과정을 직접 확인하는 것입니다.

ARP Request Packet (요청 패킷) 분석

Q1) 그 packet의 Ethernet source address와 destination address를 16진수로 표기하라.

• 정답:
  • Source address (출발지): [여러분의 PC MAC 주소] (예: A1:B2:C3:D4:E5:F6)
  • Destination address (목적지): ff:ff:ff:ff:ff:ff (브로드캐스트 주소)
• 풀이:
  • Source: 요청을 보내는 주체는 '내 PC'이므로 출발지 MAC 주소는 여러분의 PC 랜카드 주소입니다.
  • Destination: 내 PC는 게이트웨이의 MAC 주소를 모르기 때문에 특정 대상에게 보낼 수 없습니다. 그래서 "이 네트워크에 있는 모든 사람 들어보세요!"라는 의미의 브로드캐스트(Broadcast) 주소(ff:ff:ff:ff:ff:ff)를 사용하여 요청을 뿌리는 것입니다.

Q2) 그 packet의 Ethernet header의 “Frame Type” field 값은 (16진수로 표기)? 해당 “Frame Type”이 의미하는 바는?

• 정답:
  • Frame Type 값 (16진수): 0x0806
  • 해당 "Frame Type"의 의미: 이 이더넷 프레임이 담고 있는 내용물이 ARP(Address Resolution Protocol) 패킷임을 나타냅니다.
• 풀이:
  • 이더넷 프레임은 다양한 종류의 데이터(IP 패킷, ARP 패킷 등)를 실어 나를 수 있습니다. 'Frame Type' 필드는 내용물의 종류를 알려주는 스티커와 같습니다. 0x0806은 "이 안에는 ARP 메시지가 들어있습니다"라는 약속된 코드입니다. (참고로, 일반적인 인터넷 데이터인 IP 패킷의 타입 코드는 0x0800입니다.)

Q3) 그 packet에는 송신자의 IP address와 Ethernet address가 포함되어 있는가?

• 정답: 예, 포함되어 있습니다.
• 풀이:
  • ARP 요청 패킷 안에는 "저는 [내 PC의 IP]와 [내 PC의 MAC 주소]를 사용하는 사람인데, 혹시 [궁금한 대상의 IP]를 가진 분의 MAC 주소를 아시나요?" 라는 정보가 모두 담겨있습니다. 응답을 해주는 쪽에서 누구에게 답장을 보내야 할지 알아야 하므로, 요청자의 주소(IP, MAC)는 반드시 포함되어야 합니다.

Q4) 그 packet은 어떤 IP address에 대한 Ethernet address를 묻고 있는가?

• 정답: 여러분의 PC에 설정된 기본 게이트웨이(Default Gateway)의 IP 주소
• 풀이:
  • 최종 목적지는 미국 가이아 서버지만, ARP는 라우터를 넘어가지 못하는 '로컬 통신'입니다. 따라서 내 PC는 인터넷으로 나가기 위한 첫 번째 관문인 '기본 게이트웨이(라우터)'의 MAC 주소를 물어봅니다. ipconfig 명령어로 확인한 게이트웨이 IP 주소와 일치할 것입니다.

ARP Reply Packet (응답 패킷) 분석

Q5) 그 packet의 Ethernet source address와 destination address를 16진수로 표기하라.

• 정답:
  • Source address (출발지): [게이트웨이의 MAC 주소]
  • Destination address (목적지): [여러분의 PC MAC 주소]
• 풀이:
  • 이제는 역할을 바꿔서, 질문에 대한 답을 해주는 **게이트웨이가 출발지(Source)**가 됩니다. 그리고 답장을 받는 **내 PC가 목적지(Destination)**가 됩니다. 요청과 달리 응답은 특정 대상에게만 보내는 유니캐스트(Unicast) 통신입니다.

Q6) 그 packet의 “Operation” field 값은 (16진수로 표기)?

• 정답: 0x0002 (Reply)
• 풀이:
  • ARP 헤더의 'Operation' 필드는 이 패킷이 요청인지 응답인지를 구분합니다. 1은 Request(요청)를, 2는 Reply(응답)를 의미합니다.

Q7) ARP request의 “Target IP address”에 대응되는 Ethernet address는 ARP reply packet의 어느 부분에 명시되어 있는가?

• 정답: ARP Reply 패킷의 "Sender MAC address" 필드
• 풀이:
  • 요청 패킷에서 "Target IP 주소(게이트웨이 IP)를 가진 사람"을 찾았습니다. 응답 패킷에서는 그 IP 주소를 가진 당사자(게이트웨이)가 이제 **"보내는 사람(Sender)"**이 됩니다. 따라서 게이트웨이의 MAC 주소, 즉 우리가 원했던 그 답은 응답 패킷의 "Sender MAC address" 필드에 담겨 있습니다.

---

* 실험 2: ICMP (Internet Control Message Protocol)

이 실습은 ping 명령어를 통해 ICMP라는 프로토콜이 어떻게 네트워크 연결성을 확인하는지 직접 확인하는 것이 목표입니다.

ICMP Echo Request Packet (요청 패킷) 분석

Q1) 해당 패킷의 IP header에서 송신자 IP 주소와 수신자 IP 주소는 각각 무엇인가?

• 정답:
  • 송신자(Source) IP 주소: [여러분의 PC IP 주소]
  • 수신자(Destination) IP 주소: [gaia.cs.umass.edu의 IP 주소]
• 풀이:
  • ping은 내가(송신자) 가이아 서버(수신자)에게 "잘 있니?"라고 묻는 것이므로, 출발지와 목적지가 명확합니다.

Q2) 해당 패킷의 IP header에서 “Time-To-Live” 필드 값은 얼마이며, 그 의미가 무엇인지 간단히 설명하시오.

• 정답:
  • TTL 값: (Windows의 경우) 128 또는 (Linux/macOS의 경우) 64
  • 의미: TTL은 "Time To Live"의 약자로, 패킷이 인터넷 상에서 영원히 떠도는 것을 방지하기 위한 '수명' 값입니다. 패킷이 라우터를 하나 거칠 때마다 이 값이 1씩 감소하며, 0이 되면 패킷은 소멸됩니다.

Q3) 해당 패킷의 IP header에서 “Protocol” 필드 값은 무엇이며, 그 의미가 무엇인지 간단히 설명하시오.

• 정답:
  • Protocol 값: 1 (ICMP)
  • 의미: 이 IP 패킷이 담고 있는 내용물의 종류가 ICMP임을 나타냅니다. 받는 쪽 컴퓨터는 이 값을 보고 "아, 이 데이터는 ICMP 관련 처리 부서로 보내야겠군"이라고 판단합니다. (참고: TCP는 6, UDP는 17)

Q4) 해당 패킷의 ICMP header에서 “Type” 필드 값과 “Code” 필드 값은 각각 무엇인가?

• 정답: Type: 8, Code: 0
• 풀이:
  • ICMP 메시지는 Type과 Code의 조합으로 의미가 결정됩니다. Type 8, Code 0은 "네트워크 연결이 잘 되어 있는지 확인하기 위해 메아리(Echo)를 요청합니다" 라는 의미의 Echo Request를 뜻하는 약속된 번호입니다.

ICMP Echo Reply Packet (응답 패킷) 분석

Q5) 해당 패킷의 IP header에서 송신자 IP 주소와 수신자 IP 주소는 각각 무엇인가?

• 정답:
  • 송신자(Source) IP 주소: [gaia.cs.umass.edu의 IP 주소]
  • 수신자(Destination) IP 주소: [여러분의 PC IP 주소]
• 풀이:
  • 이제는 가이아 서버가 "응, 나 잘 있어!"라고 대답하는 것이므로, 가이아 서버가 송신자, 내 PC가 수신자가 됩니다.

Q6) 해당 패킷의 IP header에서 “Time-To-Live” 필드 값은 얼마이며, ICMP echo request 패킷의 TTL필드 값과 다를 수 있는 이유를 간단히 설명하시오.

• 정답:
  • TTL 값: 128 또는 64보다 작은 특정 값 (예: 52, 245 등)
  • 값이 다를 수 있는 이유 (2가지):
    1. 초기 TTL 값이 달라서: 내 PC(Windows, 초기값 128)와 가이아 서버(Linux, 초기값 64 또는 255)의 운영체제가 달라 설정된 초기 TTL 값이 다르기 때문입니다.
    2. 거쳐온 라우터 수가 달라서 (홉 카운트): 응답 패킷이 가이아 서버에서 내 PC까지 오면서 거친 라우터의 수만큼 초기 TTL 값에서 차감되었기 때문입니다. (경로가 비대칭일 경우 오고 가는 홉 카운트가 다를 수도 있습니다.)

Q7) 해당 패킷의 IP header에서 “Protocol” 필드 값은 무엇인가?

• 정답: 1 (ICMP)
• 풀이: 응답 패킷 또한 여전히 ICMP 메시지이므로 Protocol 값은 1로 동일합니다.

Q8) 해당 패킷의 ICMP header에서 “Type” 필드 값과 “Code” 필드 값은 각각 무엇인가?

• 정답: Type: 0, Code: 0
• 풀이: Type 0, Code 0은 "당신이 보낸 Echo 요청에 대한 메아리(Echo) 응답입니다" 라는 의미의 Echo Reply를 뜻하는 약속된 번호입니다.