이 문서는 의문을 가지고 있던 지점을 AI 에이전트와 대화하며 정리한 메모입니다. IP와 MAC의 역할 차이부터 ARP, TCP/UDP, NAT/PAT까지 실제 패킷 흐름에 맞춰 정리합니다.
목차#
- 기초 — IP 주소 vs MAC 주소
- ARP (Address Resolution Protocol)
- TCP — 연결 지향 프로토콜
- TCP 3-Way Handshake (연결 수립)
- TCP 4-Way Handshake (연결 종료)
- UDP
- NAT (Network Address Translation)
- PAT 포트 번호 변환 메커니즘
1. 기초 — IP 주소 vs MAC 주소#
비유로 이해하기#
| 개념 | 비유 |
|---|---|
| IP 주소 | 집의 도로명 주소 (논리 주소, 네트워크에 따라 바뀔 수 있음) |
| MAC 주소 | 같은 LAN에서 프레임을 전달할 때 참고하는 인터페이스 주소 (보통 NIC에 할당되지만 변경될 수도 있음) |
- IP 주소:
192.168.0.10같은 형태. 네트워크 상에서 “어디로 보낼지” 경로를 찾는 데 사용 - MAC 주소:
AA:BB:CC:DD:EE:FF같은 형태. 같은 네트워크(LAN) 안에서 이더넷 프레임을 어느 인터페이스로 보낼지 식별할 때 사용
💡 핵심: 인터넷 전체의 라우팅은 IP 기준이고, 이더넷 같은 로컬 링크에서 다음 홉까지 프레임을 보낼 때 MAC 주소가 쓰인다.
2. ARP (Address Resolution Protocol)#
ARP가 왜 필요한가?#
이더넷 LAN에서 같은 링크의 상대나 다음 홉에게 프레임을 보내려면 그 대상의 MAC 주소가 필요하다.
애플리케이션이나 운영체제는 보통 먼저 IP 주소를 알고 있으므로, 이 IP를 MAC 주소로 해석하는 과정이 필요하다.
“IP는 알겠는데, MAC 주소는 어떻게 알지?” → ARP가 해결해준다.
ARP 동작 과정#
시나리오 1: PC가 처음 외부 네트워크로 나가려 할 때 (Gateway MAC 주소 찾기)#
[내 PC] ─────────── [Gateway/공유기] ─────── [인터넷]Step 1. PC가 외부 통신을 시도
- PC는 외부 네트워크로 나가려는 시점에 Gateway(공유기)의 MAC 주소가 필요해질 수 있음
- 하지만 Gateway의 MAC 주소를 모름!
Step 2. ARP Request (요청) — Broadcast
PC가 네트워크 전체에 외침:
"나는 192.168.0.1 (Gateway IP)를 가진 장치를 찾고 있어!
MAC 주소 가진 분 대답해주세요!"- 이걸 Broadcast 라고 함 → 같은 네트워크의 모든 장치에게 전송
- Broadcast 주소:
FF:FF:FF:FF:FF:FF
Step 3. ARP Reply (응답) — 보통 Unicast
Gateway가 응답:
"나야! 내 MAC 주소는 AA:BB:CC:DD:EE:FF 야!"- 일반적인 응답은 Unicast → 요청한 호스트에게 1:1 전송
Step 4. ARP 캐시 저장
- PC는 받은 MAC 주소를 ARP 캐시 테이블에 저장
- 다음번엔 또 물어보지 않아도 됨 (일정 시간 후 만료)
# Windows에서 ARP 캐시 확인하는 명령어
arp -a시나리오 2: 네이버에 접속할 때#
[내 PC] → [Gateway/공유기] → [인터넷] → [네이버 서버]핵심 질문: “네이버 서버의 MAC 주소로 직접 보내야 하나?”
❌ 아니다! 이유:
- 네이버 서버는 다른 네트워크에 있음
- MAC 주소는 같은 링크/LAN 안에서만 직접 의미가 있음
- 다른 네트워크로 나가려면 Gateway(공유기) 를 거쳐야 함
따라서 PC가 실제로 하는 일:
목적지 IP → 네이버 서버 IP (203.xxx.xxx.xxx)
목적지 MAC → Gateway의 MAC 주소 ← 핵심 포인트!📌 다른 서브넷으로 나가는 패킷은 원격 서버의 MAC이 아니라, 먼저 기본 게이트웨이의 MAC으로 전달한다.
Gateway는 받은 패킷을 보고:
- 목적지 IP를 확인
- 어디로 라우팅할지 결정
- 다음 경로로 전달
같은 서브넷 안의 다른 호스트에게 보내는 경우라면, 이때는 상대 호스트의 MAC 주소를 ARP로 찾는다.
시나리오 3: DHCP + ARP 결합#
PC가 부팅 시 IP를 자동으로 받는 과정을 단순화해서 보면:
1. PC 부팅
2. DHCPDISCOVER → Broadcast
3. DHCPOFFER ← DHCP 서버 응답
4. DHCPREQUEST → 사용할 주소 요청
5. DHCPACK ← IP 주소와 설정 확정
6. 이후 같은 링크에서 Gateway의 MAC 주소가 필요하면 ARP 수행💡 DHCP는 기본 게이트웨이의 IP 주소를 옵션으로 줄 수 있지만, 게이트웨이의 MAC 주소까지 주는 건 아니다.
그래서 로컬 링크에서 실제 프레임을 보내기 전에는 여전히 ARP가 필요하다.
매번 ARP를 하면 낭비니까 ARP 캐싱으로 저장해두고 재사용한다.
3. TCP — 연결 지향 프로토콜#
TCP vs UDP 비교#
| 특성 | TCP | UDP |
|---|---|---|
| 연결 | 연결 후 통신 (Connection) | 연결 없이 바로 전송 |
| 신뢰성 | 높음 (재전송, 순서 보장) | 낮음 |
| 속도 | 상대적으로 느림 | 빠름 |
| 사용처 | 웹, 이메일, 파일 전송 | 스트리밍, 게임, DNS |
| 헤더 크기 | 보통 20~60 byte | 8 byte |
TCP의 핵심 개념: 시퀀스 번호 (Sequence Number)#
TCP는 데이터를 조각(Segment) 으로 나눠서 보낸다.
시퀀스 번호 1, 크기: 1460 byte → ACK 번호 1461
시퀀스 번호 1461, 크기: 1460 byte → ACK 번호 2921이렇게 동작하는 이유:
- 패킷이 중간에 유실되거나 순서가 바뀔 수 있음
- 시퀀스 번호로 “몇 번째 바이트까지 잘 받았는지” 추적 가능
- 빠진 번호가 있으면 → 재전송 요청
TCP 연결 자체는 보통 출발지 IP/포트 + 목적지 IP/포트 조합으로 구분되고, Sequence 번호는 그 연결 안에서 바이트 스트림의 위치를 추적한다.
4. TCP 3-Way Handshake (연결 수립)#
왜 3번이나 주고받나?#
양쪽이 서로 확인해야 한다:
- “나 보낼 수 있어?” → “응, 너 보내는 거 받았어”
- “나도 보낼 수 있어?” → “응, 너 보내는 거 받았어”
이걸 효율적으로 합치면 3번이 된다.
상세 과정#
Client Server
| |
| ① SYN (seq=100) |
| ─────────────────────────────────> |
| |
| ② SYN+ACK (seq=300, ack=101) |
| <───────────────────────────────── |
| |
| ③ ACK (seq=101, ack=301) |
| ─────────────────────────────────> |
| |
| [연결 수립 완료!] |① Client → Server: SYN#
- SYN: Synchronize (동기화) 플래그
- Client가 말함: “나 seq=100에서 시작할게. 연결하자!”
② Server → Client: SYN + ACK#
- SYN: “나는 seq=300에서 시작할게!”
- ACK: “너의 100번 잘 받았어. 다음엔 101번 줘” (ack=100+1=101)
- 두 개를 한 번에 보냄 → 효율적!
③ Client → Server: ACK#
- “네 300번 잘 받았어. 다음엔 301번 줘” (ack=300+1=301)
- 이 시점부터 연결 완료! 데이터 전송 가능
3-Way Handshake에서 교환하는 것#
TCP 3-way handshake의 핵심은 초기 시퀀스 번호 동기화이고, SYN 구간에서 필요하면 MSS 같은 TCP 옵션도 함께 전달된다.
1. Sequence Number 교환
- 서로의 초기 시퀀스 번호 공유
- 이걸로 앞으로 주고받는 바이트를 추적
2. MSS (Maximum Segment Size)
- “나는 이 연결에서 이 크기까지의 TCP 데이터 조각을 받을 수 있어”
- MSS는 흔히 “협상"처럼 설명되지만, 정확히는 각 방향에서 자신의 수신 가능 크기를 알리는 값
- 실제 전송 크기는 상대가 광고한 MSS와 경로 MTU 등을 함께 고려해 결정됨
5. TCP 4-Way Handshake (연결 종료)#
왜 4번이나 필요한가?#
3-Way와 달리, 종료는 단방향씩 따로 닫을 수 있기 때문이다.
이유: TCP는 양방향 통신이라 각 방향을 독립적으로 종료할 수 있음.
아래 예시는 Client가 먼저 종료를 시작하는 Active Close 상황이다. 실제로는 어느 쪽이든 먼저 종료를 시작할 수 있다.
상세 과정#
Client (Active Close) Server (Passive Close)
| |
| ① FIN (seq=1000) |
| ─────────────────────────────────> |
| |
| ② ACK (ack=1001) |
| <───────────────────────────────── |
| |
| (FIN_WAIT_2 상태로 대기) | ← 서버가 남은 데이터
| | 마저 전송하는 시간
| ③ FIN (seq=2000) |
| <───────────────────────────────── |
| |
| ④ ACK (ack=2001) |
| ─────────────────────────────────> |
| |
| (TIME_WAIT 대기 후 완전 종료) | 완전 종료① Client → Server: FIN#
- “나는 더 보낼 데이터 없어. 연결 끊자”
- 하지만 아직 받는 건 가능한 상태 (Half-Close)
② Server → Client: ACK#
- “알겠어, 네 FIN 받았어”
- Server는 아직 보낼 데이터가 남아있을 수 있음
- 이 사이에 Server가 남은 데이터를 마저 전송
③ Server → Client: FIN#
- “나도 이제 다 보냈어. 연결 끊자”
④ Client → Server: ACK#
- “알겠어, 완전히 종료할게”
- Client는 바로 종료 안 하고 TIME_WAIT 상태로 잠시 대기
- 이유: 마지막 ACK 재전송이 필요할 수 있고, 지연된 중복 세그먼트가 네트워크에 남아 있을 수 있어서
FIN + ACK가 왜 자주 따로따로 보이나?#
설명 편의상
FIN → ACK → FIN → ACK4단계를 많이 그리지만, 항상 네 개의 개별 패킷으로 분리되는 것은 아니다.
3-Way에서 SYN+ACK를 한 번에 합쳤던 것과 달리, 종료 구간은 다음처럼 동작할 수 있다.
- Server는 Client의 FIN을 받으면 우선 ACK 로 수신 사실을 알려야 함
- 하지만 Server 쪽에 아직 보낼 데이터가 남아 있다면, 자기 FIN은 나중에 보냄
- 반대로 보낼 데이터가 더 없다면, ACK와 FIN을 같은 세그먼트에 실어 보낼 수도 있음
즉, 대표적인 상태 전이는 4-way close로 설명하지만, 실제 패킷 수는 상황에 따라 합쳐질 수 있다.
6. UDP#
UDP 헤더가 간단한 이유#
TCP 헤더: 출발지 포트, 목적지 포트, 순서번호, ACK번호,
플래그, 윈도우 크기, 체크섬, 긴급 포인터... (보통 20~60 byte)
UDP 헤더: 출발지 포트, 목적지 포트, 길이, 체크섬 (8 byte)UDP 특징#
- 내장된 재전송/순서 보장/흐름 제어가 없음: TCP처럼 상대가 얼마나 받을 수 있는지 확인하며 전송 속도를 조절하는 기능이 프로토콜에 기본 포함되어 있지 않음
- 필요한 제어는 애플리케이션 레벨에서 구현해야 함
- 멀티미디어에 많이 쓰이는 이유: 영상/음성 스트리밍은 약간의 손실보다 실시간성이 더 중요할 때가 많음
7. NAT (Network Address Translation)#
NAT가 필요한 이유 — IPv4 주소 부족 문제#
IPv4 주소 총 개수: 약 43억 개
전 세계 인터넷 기기: 수십억 대 이상IPv4 주소가 한정적이라 나온 대표적인 해결책 중 하나: “공인 IP 1개로 여러 기기가 인터넷을 쓰자” → NAT
💡 여기서 말하는 NAT/PAT는 주로 가정용 IPv4 환경 기준 설명이다.
공인 IP vs 사설 IP#
| 구분 | 공인 IP (Public IP) | 사설 IP (Private IP) |
|---|---|---|
| 부여 주체 | ISP (KT, SKT 등) | 보통 내부 DHCP 서버/라우터 |
| 인터넷 통신 | 글로벌 인터넷에서 직접 라우팅 가능 | 글로벌 인터넷에서 직접 라우팅되지 않음 |
| 유일성 | 전 세계에서 유일 | 같은 사설망 안에서만 유일 |
| 예시 | 203.245.10.5 | 192.168.0.x, 10.x.x.x, 172.16.x.x ~ 172.31.x.x |
[인터넷]
|
| ← 공인 IP: 203.245.10.5 (ISP가 우리 집에 부여)
|
[공유기/Gateway] ← 공인 IP + 사설 IP 둘 다 가짐!
|
|── 192.168.0.2 (내 노트북)
|── 192.168.0.3 (내 폰)
|── 192.168.0.4 (내 TV)NAT 동작 원리#
📤 나갈 때 (내부 → 외부)#
[노트북 192.168.0.2 : 포트 5000]
↓
[공유기] 출발지 IP/포트를 바꿔치기!
↓
출발지: 192.168.0.2:5000 → 203.245.10.5:12345 (공인 IP)
목적지: 네이버 서버공유기가 NAT 테이블에 기록:
사설 IP:포트 공인 IP:포트
192.168.0.2:5000 ↔ 203.245.10.5:12345
192.168.0.3:6000 ↔ 203.245.10.5:12346
192.168.0.4:7000 ↔ 203.245.10.5:12347📥 들어올 때 (외부 → 내부)#
[네이버 서버] → 203.245.10.5:12345 로 응답 전송
↓
[공유기] NAT 테이블 조회!
"12345 포트는 192.168.0.2:5000 이었지"
↓
목적지를 192.168.0.2:5000 으로 복원해서 전달💡 포트 번호로 어느 기기의 요청인지 구분하는 게 핵심!
이걸 PAT (Port Address Translation) 또는 NAPT 라고도 부름
NAT의 종류#
| 종류 | 설명 | 사용 예 |
|---|---|---|
| Static NAT | 사설 IP 1개 ↔ 공인 IP 1개 고정 매핑 | 사내 서버 외부 노출 |
| Dynamic NAT | 공인 IP 풀에서 동적으로 할당 | 기업 환경 |
| PAT (가장 흔함) | 공인 IP 1개 + 포트로 여러 기기 구분 | 가정용 공유기 |
NAT의 장단점#
✅ 장점
- IP 주소 절약 — 공인 IP 1개로 여러 기기 인터넷 사용
- 주소 은닉 — 내부 사설 IP 체계가 외부에 직접 드러나지 않음
❌ 단점
- 외부에서 내부로 먼저 접근하기 어려움
- 전통적인 outbound-initiated NAT에선, NAT 테이블이나 정적 매핑이 없으면 외부에서 내부 호스트로 먼저 들어오기 어려움
- 이게 게임할 때 “포트 포워딩” 이 필요한 대표적인 이유
- 추적 어려움 — 같은 공인 IP에서 여러 사용자가 나오니 로그 분석이 복잡
📌 NAT는 주소 변환 기능이다. 실무에선 상태 기반 필터링과 함께 동작하는 경우가 많지만, NAT 자체가 방화벽과 동일한 개념은 아니다.
포트 포워딩 (NAT의 응용)#
“외부에서 내 집 서버에 접근하고 싶어”
외부 사용자 → 203.245.10.5:8080 으로 접근
↓
공유기 설정: "8080 포트로 오는 건 192.168.0.2:8080으로 전달해"
↓
내 노트북 서버에 도달 ✅공유기 관리 페이지에서 포트 포워딩 규칙을 직접 만들어두면 된다.
8. PAT 포트 번호 변환 메커니즘#
핵심 문제 상황#
노트북 192.168.0.2:51234 → 네이버:443
폰 192.168.0.3:51234 → 네이버:443 ← 포트까지 같음!
TV 192.168.0.4:51234 → 네이버:443공유기 입장에서 이걸 공인 IP 하나로 내보내면 누구 거지? → 응답이 돌아왔을 때 누구한테 줘야 할지 모름
클라이언트 포트 번호의 특성#
TCP/UDP에서 클라이언트가 사용하는 포트는 보통 Ephemeral Port (임시 포트):
Well-Known Port: 0 ~ 1023 (HTTP:80, HTTPS:443 등 서버용)
Registered Port: 1024 ~ 49151 (등록된 애플리케이션용)
Ephemeral Port: 49152 ~ 65535 ← 클라이언트가 동적으로 사용클라이언트는 서버에 연결할 때 이 범위에서 OS가 동적으로 포트를 하나 골라 쓴다.
포트 변환 방식 — 3가지 케이스#
✅ Case 1: 충돌이 없는 경우 (그냥 통과)#
노트북 192.168.0.2:51234 → 공유기 203.245.10.5:51234 → 네이버
폰 192.168.0.3:62891 → 공유기 203.245.10.5:62891 → 네이버출발지 포트가 다르면 그대로 같은 외부 포트로 매핑될 수도 있음.
NAT 테이블에 기록만 해두면 끝.
NAT 테이블:
사설측 공인측
192.168.0.2:51234 ↔ 203.245.10.5:51234
192.168.0.3:62891 ↔ 203.245.10.5:62891🔥 Case 2: 포트 충돌 발생 (핵심!)#
노트북 192.168.0.2:51234 → 이미 NAT 테이블에 있음!
폰 192.168.0.3:51234 → 같은 외부 포트를 쓰려는데 이미 사용 중!이때 공유기가 하는 일:
1. NAT 테이블에서 해당 외부 포트 사용 여부 확인
2. 충돌 감지
3. 사용 가능한 다른 외부 포트 선택
4. 예: 51235가 비어있다 → 폰의 패킷 포트를 51235로 교체
5. 변환해서 내보냄NAT 테이블:
사설측 공인측
192.168.0.2:51234 ↔ 203.245.10.5:51234 (원본 유지)
192.168.0.3:51234 ↔ 203.245.10.5:51235 ← 포트 번호 변경됨어떤 외부 포트를 고르는지는 NAT 구현마다 다르다.
Case 3: NAT 테이블은 생각보다 더 많은 정보를 본다#
실제 NAT 구현은 포트만 보는 게 아니라 세션 정보를 더 정밀하게 추적한다.
RFC 4787은 UDP NAT 동작을 설명할 때 세션을 다음과 같은 endpoint tuple 관점으로 본다.
(출발지 IP : 출발지 포트 : 목적지 IP : 목적지 포트)예를 들어:
192.168.0.2:51234 → 네이버:443
192.168.0.2:51234 → 구글:443같은 내부 포트를 쓰더라도 목적지가 다르면 별도 세션으로 관리될 수 있다.
다만 외부 포트 재사용 방식은 endpoint-independent / address-dependent / address-and-port-dependent 처럼 NAT 구현마다 다를 수 있다.
전체 흐름 예시#
① 노트북(192.168.0.2:51234) → 네이버:443 요청
공유기: 테이블 확인 → 비어있음 → 그대로 51234 사용
NAT 테이블 등록: 0.2:51234 ↔ 공인:51234 → 네이버:443
② 폰(192.168.0.3:51234) → 네이버:443 요청
공유기: 테이블 확인 → 공인:51234→네이버:443 이미 사용 중
→ 다른 외부 포트 선택 → 예: 51235로 변환
NAT 테이블 등록: 0.3:51234 ↔ 공인:51235 → 네이버:443
③ 네이버 → 공인:51234 응답
공유기: 51234 → 노트북(192.168.0.2:51234) 으로 전달 ✅
④ 네이버 → 공인:51235 응답
공유기: 51235 → 폰(192.168.0.3:51234) 으로 전달 ✅한계 — 포트 공간은 유한하다#
사용 가능한 포트 번호 범위: 0 ~ 65535공인 IP 1개만으로 유지할 수 있는 동시 세션 수에는 포트 공간의 한계가 있다.
실제 사용 가능 수는 예약 포트, 구현 방식, 프로토콜별 분리 등에 따라 달라질 수 있다.
대형 기업/ISP 환경에선 이것도 부족해서:
- 공인 IP 여러 개를 풀로 운영
- 또는 Carrier-Grade NAT (CGNAT) 처럼 NAT를 대규모로 운용
전체 그림 최종 정리#
PC 부팅
└─→ DHCP로 IP 받기
└─→ ARP로 Gateway MAC 주소 찾기
└─→ NAT로 사설 IP → 공인 IP 변환
└─→ TCP 3-Way Handshake로 서버와 연결
└─→ 데이터 주고받기 (Seq/ACK로 신뢰성 보장)
└─→ TCP 4-Way Handshake로 연결 종료전 세계 인터넷
|
공인 IP (203.245.10.5)
|
[공유기] ← NAT/PAT 수행
/ | \
폰 PC TV
192. 192. 192.
168. 168. 168.
0.3 0.2 0.4
(사설 IP들)핵심 요약 카드#
| 개념 | 한 줄 요약 |
|---|---|
| ARP | IP 주소로 링크 계층 주소를 찾아내는 프로토콜 |
| MAC 주소 | 같은 LAN 안에서 프레임을 전달할 때 참고하는 인터페이스 주소 |
| TCP 3-Way | SYN → SYN+ACK → ACK 로 연결 수립, 초기 Seq 번호 동기화와 SYN 옵션 교환 |
| TCP 4-Way | 대표적으로 FIN → ACK → FIN → ACK 로 연결 종료, 실제 패킷은 상황에 따라 합쳐질 수 있음 |
| NAT | 사설 IP ↔ 공인 IP 변환으로 IPv4 사설망이 외부와 통신하도록 돕는 방식 |
| PAT | 포트 번호까지 함께 변환해 여러 사설 호스트를 공인 IP 1개에 매핑 |
| 포트 충돌 | 공유기가 다른 외부 포트를 선택해 NAT 테이블에 기록 |
| UDP | 연결 없이 최소한의 헤더로 전송하며, 신뢰성 제어는 애플리케이션이 담당 |
참고 자료#
- RFC 826 - An Ethernet Address Resolution Protocol
- RFC 2131 - Dynamic Host Configuration Protocol
- RFC 2132 - DHCP Options and BOOTP Vendor Extensions
- RFC 768 - User Datagram Protocol
- RFC 9293 - Transmission Control Protocol (TCP)
- RFC 1918 - Address Allocation for Private Internets
- RFC 3022 - Traditional IP Network Address Translator (Traditional NAT)
- RFC 4787 - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
- RFC 6335 - Service Name and Port Number Registry Procedures