네트워크 통신의 원리 (3) - 프로토콜 스택과 데이터 흐름 - soo:bak
작성일 :
규칙 없이는 통신할 수 없다
Part 1에서 물리적 신호 전송을, Part 2에서 디지털 데이터 처리를 살펴보았습니다.
이제 비트를 주고받을 수 있게 되었습니다.
하지만 비트를 전송할 수 있다는 것과 의미 있는 통신을 할 수 있다는 것은 다른 문제입니다.
두 컴퓨터가 통신한다고 해봅시다.
컴퓨터 A가 B에게 “11001010 01010011…“을 보냈습니다.
B는 이것을 어떻게 해석해야 할까요?
텍스트일까요? 이미지일까요? 동영상일까요?
데이터가 어디서 시작하고 어디서 끝나는지 어떻게 알까요?
이 데이터가 B를 위한 것인지, B를 경유해서 다른 곳으로 가는 것인지 어떻게 구분할까요?
규약(Protocol)이 필요합니다.
프로토콜은 통신의 규칙입니다.
데이터 형식, 순서, 오류 처리 방법, 주소 지정 방식 등을 정의합니다.
프로토콜 없이는 서로 다른 컴퓨터, 서로 다른 운영체제, 서로 다른 제조사의 장비가 통신할 수 없습니다.
왜 계층 구조인가
네트워크 통신은 복잡합니다.
물리적 신호 전송, 오류 검출, 주소 지정, 경로 선택, 데이터 순서 보장, 애플리케이션 프로토콜…
이 모든 것을 하나의 프로토콜로 처리하면 어떻게 될까요?
엄청나게 복잡해지고, 하나를 바꾸면 전체를 바꿔야 합니다.
해결책은 계층(Layer)으로 나누는 것입니다.
각 계층은 특정 기능만 담당합니다.
아래 계층의 서비스를 사용하고, 위 계층에 서비스를 제공합니다.
이 구조의 핵심은 계층 간 독립성입니다.
웹 브라우저(응용 계층)는 데이터가 Wi-Fi로 전송되든 이더넷으로 전송되든 신경 쓰지 않습니다.
이더넷 카드(데이터링크 계층)는 그 위에서 TCP를 쓰든 UDP를 쓰든 상관하지 않습니다.
덕분에 기술을 독립적으로 발전시킬 수 있습니다.
Wi-Fi가 802.11n에서 802.11ac로, 다시 802.11ax(Wi-Fi 6)로 발전해도, 웹 브라우저를 수정할 필요가 없습니다.
HTTP가 1.1에서 2.0으로, 다시 3.0으로 발전해도, 이더넷 드라이버를 수정할 필요가 없습니다.
실제 인터넷은 TCP/IP 4계층 모델을 사용합니다.
1
2
3
4
5
6
7
응용 계층 (Application)
↓ ↑
전송 계층 (Transport)
↓ ↑
인터넷 계층 (Internet)
↓ ↑
네트워크 접근 계층 (Network Access)
각 계층이 어떤 문제를 해결하는지 살펴봅시다.
네트워크 접근 계층: 같은 네트워크 안에서
가장 아래에 있는 네트워크 접근 계층(Network Access Layer)은 같은 물리적 네트워크 안에서 데이터를 전달합니다.
물리 계층(케이블, 무선 신호)과 데이터링크 계층(프레이밍, MAC 주소)을 포함합니다.
비트 스트림을 프레임으로
Part 2에서 비트를 물리 신호로 변환하는 방법을 살펴보았습니다.
하지만 연속된 비트 스트림에서 어디가 데이터의 시작이고 끝인지 알 수 없습니다.
프레이밍(Framing)은 비트 스트림을 의미 있는 단위인 프레임(Frame)으로 나누는 것입니다.
이더넷 프레임의 구조를 살펴봅시다.
1
2
3
4
5
┌─────────┬────────┬────────┬──────┬─────────────────┬─────┐
│프리앰블 │ 목적지 │ 출발지 │ 타입 │ 데이터 │ FCS │
│ (8) │ MAC(6) │ MAC(6) │ (2) │ (46-1500) │ (4) │
└─────────┴────────┴────────┴──────┴─────────────────┴─────┘
(바이트)
프리앰블(Preamble)은 프레임의 시작을 알립니다.
수신측은 이 패턴(10101010…)을 보고 프레임이 시작됨을 알고 동기화를 맞춥니다.
FCS(Frame Check Sequence)는 CRC-32 체크섬으로, 프레임이 손상되었는지 검사합니다.
MAC 주소: 누구에게 보내는가
같은 네트워크 안에 여러 장치가 있습니다.
이 프레임이 누구를 위한 것인지 어떻게 알까요?
MAC 주소(Media Access Control Address)가 각 장치를 식별합니다.
1
MAC 주소: 00:1A:2B:3C:4D:5E (48비트, 16진수 표기)
MAC 주소는 네트워크 인터페이스 카드(NIC)에 제조 시 부여됩니다.
앞 24비트(00:1A:2B)는 제조사 식별 코드이고, 뒤 24비트(3C:4D:5E)는 해당 제조사 내에서의 고유 번호입니다.
이더넷 프레임에는 목적지 MAC 주소와 출발지 MAC 주소가 들어갑니다.
프레임을 받은 장치는 목적지 MAC 주소를 확인합니다.
자신의 MAC 주소와 일치하면 프레임을 처리하고, 아니면 무시합니다.
특수 MAC 주소: 브로드캐스트
목적지 MAC 주소가 FF:FF:FF:FF:FF:FF이면, 같은 네트워크의 모든 장치가 이 프레임을 받습니다.
이것을 브로드캐스트(Broadcast)라고 합니다.
네트워크에서 “모든 장치에게” 메시지를 보낼 때 사용합니다.
스위치: MAC 주소로 전달
스위치(Switch)는 MAC 주소를 보고 프레임을 적절한 포트로 전달합니다.
스위치가 없던 시절에는 허브(Hub)를 사용했습니다.
허브는 받은 프레임을 모든 포트로 전송합니다.
컴퓨터 A가 B에게 보내면, 같은 허브에 연결된 C, D, E도 모두 이 프레임을 받습니다.
대역폭 낭비이고, 보안에도 좋지 않습니다.
스위치는 다릅니다.
스위치는 MAC 주소 테이블을 유지합니다.
어떤 MAC 주소가 어느 포트에 연결되어 있는지 기록합니다.
1
2
3
4
MAC 주소 포트
00:1A:2B:3C:4D:5E 1
00:AA:BB:CC:DD:EE 3
00:11:22:33:44:55 5
스위치는 프레임을 받으면 출발지 MAC 주소를 보고 테이블에 기록합니다.
“이 MAC 주소는 이 포트에 있구나.”
그리고 목적지 MAC 주소를 보고 테이블에서 찾습니다.
있으면 해당 포트로만 전송하고, 없으면 모든 포트로 전송합니다(플러딩).
이렇게 스위치는 필요한 포트로만 프레임을 전달하여 대역폭을 효율적으로 사용합니다.
인터넷 계층: 다른 네트워크로
MAC 주소로는 같은 네트워크 안에서만 통신할 수 있습니다.
서울에 있는 컴퓨터가 뉴욕에 있는 서버와 통신하려면?
중간에 수많은 네트워크를 거쳐야 합니다.
인터넷 계층(Internet Layer)이 이 문제를 해결합니다.
IP 주소: 논리적 주소
IP 주소(Internet Protocol Address)는 전 세계 네트워크에서 장치를 식별하는 논리적 주소입니다.
1
IPv4 주소: 192.168.1.100 (32비트)
MAC 주소와의 차이점은 무엇일까요?
MAC 주소는 하드웨어에 고정된 물리적 주소입니다.
IP 주소는 네트워크 구성에 따라 할당되는 논리적 주소입니다.
노트북을 집에서 카페로 가져가면, MAC 주소는 그대로지만 IP 주소는 바뀝니다.
집 네트워크에서는 192.168.1.100이었지만, 카페에서는 192.168.0.50이 될 수 있습니다.
IP 주소가 필요한 이유는 라우팅(Routing) 때문입니다.
IP 주소는 계층적 구조를 가집니다.
네트워크 부분과 호스트 부분으로 나뉩니다.
1
2
3
192.168.1.100 (서브넷 마스크: 255.255.255.0)
192.168.1 . 100
←네트워크→ ←호스트→
라우터는 네트워크 부분만 보고 어느 방향으로 보낼지 결정합니다.
전 세계의 모든 IP 주소를 기억할 필요 없이, 네트워크 블록 단위로 라우팅합니다.
IP 주소에 대한 자세한 내용은 IP 주소의 개념과 구조를 참조하세요.
IP 패킷
인터넷 계층의 데이터 단위는 패킷(Packet)입니다.
IP 패킷에는 출발지 IP 주소와 목적지 IP 주소가 들어갑니다.
1
2
3
4
5
6
7
8
┌────────────────────────────────────────┐
│ IP 헤더 (20바이트~) │
│ 출발지 IP: 192.168.1.100 │
│ 목적지 IP: 142.250.196.110 (구글) │
│ TTL: 64, 프로토콜: TCP, ... │
├────────────────────────────────────────┤
│ 데이터 │
└────────────────────────────────────────┘
TTL(Time To Live)은 패킷이 네트워크에서 무한히 떠도는 것을 방지합니다.
라우터를 지날 때마다 TTL이 1씩 감소합니다.
0이 되면 패킷은 폐기됩니다.
라우터와 라우팅
라우터(Router)는 서로 다른 네트워크를 연결합니다.
라우터는 패킷을 받으면 목적지 IP 주소를 확인하고, 라우팅 테이블을 참조하여 어느 방향으로 보낼지 결정합니다.
1
2
3
4
5
라우팅 테이블 예시:
목적지 네트워크 다음 홉(Next Hop) 인터페이스
192.168.1.0/24 직접 연결 eth0
10.0.0.0/8 192.168.1.1 eth0
0.0.0.0/0 203.0.113.1 eth1 (기본 경로)
목적지 IP와 일치하는 가장 구체적인 항목을 찾아 해당 방향으로 전송합니다.
일치하는 항목이 없으면 기본 경로(Default Route)로 보냅니다.
패킷이 서울에서 뉴욕까지 가는 과정을 생각해봅시다.
1
2
3
4
5
6
7
8
9
10
11
12
13
내 PC (192.168.1.100)
↓
홈 라우터 (목적지가 내 네트워크가 아님 → ISP로)
↓
ISP 라우터 (목적지가 한국 내 아님 → 해외 경로로)
↓
여러 라우터를 거침 (해저 케이블, 국제 백본)
↓
미국 ISP 라우터
↓
목적지 네트워크 라우터
↓
목적지 서버 (142.250.196.110)
각 라우터는 전체 경로를 알지 못합니다.
“이 목적지로 가려면 다음 홉은 어디인가”만 알면 됩니다.
이것이 인터넷이 확장 가능한 이유입니다.
ARP: IP 주소를 MAC 주소로
IP 패킷을 보내려면 결국 프레임으로 캡슐화해야 합니다.
프레임에는 MAC 주소가 필요합니다.
IP 주소는 알지만 MAC 주소는 모릅니다.
어떻게 알아낼까요?
ARP(Address Resolution Protocol)가 이 문제를 해결합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
PC A가 192.168.1.20에게 데이터를 보내려 함
↓
A: "192.168.1.20의 MAC 주소는?"
(브로드캐스트, 목적지 MAC: FF:FF:FF:FF:FF:FF)
↓
네트워크의 모든 장치가 이 요청을 받음
↓
IP가 192.168.1.20인 장치(B)만 응답:
B: "192.168.1.20은 00:AA:BB:CC:DD:EE입니다"
(유니캐스트, A에게만)
↓
A는 이 정보를 ARP 캐시에 저장
이후 통신에서 캐시 참조
DNS: 이름을 IP 주소로
사람은 IP 주소를 외우지 않습니다.
www.google.com 같은 도메인 이름을 사용합니다.
DNS(Domain Name System)가 도메인 이름을 IP 주소로 변환합니다.
1
2
3
4
5
6
7
브라우저: www.google.com 접속
↓
DNS 쿼리: "www.google.com의 IP는?"
↓
DNS 서버 응답: "142.250.196.110"
↓
브라우저: 142.250.196.110에 연결
DNS는 계층적 구조로 되어 있습니다.
루트 DNS 서버 → .com DNS 서버 → google.com DNS 서버
각 단계에서 “모르면 다음 단계에 물어봐라”고 알려줍니다.
전송 계층: 종단간 통신
IP는 패킷을 목적지 컴퓨터까지 전달합니다.
하지만 컴퓨터에서는 여러 프로그램이 동시에 실행됩니다.
이 패킷이 웹 브라우저를 위한 것인지, 이메일 클라이언트를 위한 것인지, 카카오톡을 위한 것인지 어떻게 구분할까요?
전송 계층(Transport Layer)이 이 문제를 해결합니다.
포트 번호: 프로세스 구분
포트 번호(Port Number)는 같은 컴퓨터에서 실행되는 여러 프로세스를 구분합니다.
1
2
3
4
IP 주소: 192.168.1.100 (어느 컴퓨터?)
포트: 80 (어느 프로세스?)
소켓 주소: 192.168.1.100:80
웹 서버는 보통 포트 80(HTTP) 또는 443(HTTPS)에서 대기합니다.
브라우저가 웹 서버에 연결하면, 서버는 목적지 포트가 80인 패킷을 웹 서버 프로세스에 전달합니다.
포트 번호는 0 ~ 65535 범위입니다.
0 ~ 1023은 잘 알려진 포트(Well-known Ports)로, 표준 서비스가 사용합니다.
1
2
3
4
5
22: SSH
25: SMTP (이메일)
53: DNS
80: HTTP
443: HTTPS
TCP: 신뢰성 있는 전송
IP는 최선형(Best Effort) 서비스입니다.
패킷이 손실되거나, 순서가 뒤바뀌거나, 중복될 수 있습니다.
IP는 이것을 고치지 않습니다.
TCP(Transmission Control Protocol)는 신뢰성 있는 전송을 제공합니다.
데이터가 손실 없이, 순서대로, 중복 없이 도착하도록 보장합니다.
연결 설정: 3-Way Handshake
TCP는 데이터를 보내기 전에 연결을 설정합니다.
1
2
3
4
5
6
7
8
9
10
11
12
클라이언트 서버
│ │
│───── SYN (seq=100) ──────────→ │
│ "연결하고 싶습니다" │
│ │
│←──── SYN+ACK (seq=300, ack=101) ──│
│ "좋습니다, 저도요" │
│ │
│───── ACK (ack=301) ──────────→ │
│ "확인했습니다" │
│ │
│ 연결 수립됨 │
SYN(Synchronize)과 ACK(Acknowledge)를 교환하여 양측이 준비되었음을 확인합니다.
시퀀스 번호와 확인 응답
TCP는 보내는 모든 바이트에 시퀀스 번호(Sequence Number)를 부여합니다.
수신측은 받은 바이트를 확인하고 확인 응답(ACK)을 보냅니다.
1
2
3
4
5
6
7
8
9
10
송신자 수신자
│ │
│── seq=1000, 1000바이트 데이터 ──→ │
│ │ 수신 성공
│←──────── ack=2000 ───────────── │
│ "2000번 바이트 기대" │
│ │
│── seq=2000, 500바이트 데이터 ───→ │
│ │ 수신 성공
│←──────── ack=2500 ───────────── │
ACK가 오지 않으면?
타임아웃 후 재전송합니다.
시퀀스 번호 덕분에 수신측은 순서대로 데이터를 재조립할 수 있습니다.
패킷 2, 3, 1 순서로 도착해도, 시퀀스 번호를 보고 1, 2, 3 순서로 정렬합니다.
흐름 제어: 수신자 속도에 맞추기
수신자가 처리할 수 있는 속도보다 빠르게 보내면 데이터가 버려집니다.
TCP는 윈도우(Window) 메커니즘으로 흐름을 제어합니다.
수신자는 “나는 현재 N 바이트를 받을 수 있다”고 알려줍니다.
송신자는 그 이상 보내지 않습니다.
혼잡 제어: 네트워크 상태에 맞추기
네트워크가 혼잡하면 패킷이 손실됩니다.
TCP는 패킷 손실을 혼잡의 신호로 해석하고 전송 속도를 줄입니다.
혼잡이 해소되면 속도를 점진적으로 높입니다.
이 메커니즘 덕분에 전 세계 수십억 장치가 동시에 인터넷을 사용해도, 대부분의 경우 공평하게 대역폭을 나눠 쓸 수 있습니다.
UDP: 빠른 전송
UDP(User Datagram Protocol)는 TCP와 다릅니다.
연결 설정 없이 바로 데이터를 보냅니다.
손실, 순서 변경, 중복에 대한 보장이 없습니다.
왜 이런 프로토콜이 필요할까요?
TCP의 신뢰성에는 비용이 따릅니다.
연결 설정에 왕복 시간(RTT)이 소요됩니다.
재전송으로 인한 지연이 발생할 수 있습니다.
실시간 통신에서는 늦은 데이터보다 없는 데이터가 나을 수 있습니다.
화상 통화에서 0.5초 전의 영상을 재전송 받아봐야 의미가 없습니다.
그냥 건너뛰고 현재 영상을 보여주는 것이 낫습니다.
UDP를 사용하는 경우:
- 실시간 스트리밍 (영상, 음성)
- 온라인 게임 (빠른 반응이 중요)
- DNS 쿼리 (작은 데이터, 빠른 응답)
UDP 헤더는 8바이트뿐입니다. (TCP는 20바이트 이상)
1
2
3
4
5
┌─────────────────────────────────────────────┐
│ 출발지 포트 (16비트) │ 목적지 포트 (16비트) │
├─────────────────────────────────────────────┤
│ 길이 (16비트) │ 체크섬 (16비트) │
└─────────────────────────────────────────────┘
출발지/목적지 포트, 길이, 체크섬. 그게 전부입니다.
응용 계층: 사용자와 만나다
전송 계층까지 왔으면 프로세스 간에 데이터를 주고받을 수 있습니다.
하지만 어떤 형식으로 데이터를 주고받을지는 정해지지 않았습니다.
응용 계층(Application Layer)이 각 서비스에 맞는 프로토콜을 정의합니다.
HTTP: 웹의 언어
HTTP(HyperText Transfer Protocol)는 웹에서 사용하는 프로토콜입니다.
요청(Request)과 응답(Response) 구조로 되어 있습니다.
HTTP 요청
1
2
3
4
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
첫 줄: 메서드(GET), 경로(/index.html), 버전(HTTP/1.1)
헤더: 추가 정보 (호스트, 브라우저 종류, 원하는 형식 등)
HTTP 응답
1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
...
</html>
상태 코드(200 OK), 헤더(콘텐츠 종류, 길이), 본문(실제 데이터)
HTTP는 무상태(Stateless) 프로토콜입니다.
각 요청은 독립적입니다.
서버는 이전 요청을 기억하지 않습니다.
로그인 상태 같은 정보는 쿠키(Cookie)나 세션(Session)으로 별도 관리합니다.
HTTPS: 암호화된 HTTP
HTTP는 평문으로 전송됩니다.
누구나 중간에서 내용을 읽을 수 있습니다.
HTTPS는 HTTP에 TLS(Transport Layer Security)를 추가합니다.
데이터가 암호화되어 중간에서 읽을 수 없습니다.
또한 서버의 신원을 인증서로 확인합니다.
브라우저 주소창의 자물쇠 아이콘이 HTTPS를 의미합니다.
현대 웹에서는 HTTPS가 기본입니다.
캡슐화: 계층을 내려가며
데이터가 송신측에서 수신측으로 가는 과정을 살펴봅시다.
응용 계층에서 HTTP 요청을 생성합니다.
1
GET /index.html HTTP/1.1...
전송 계층(TCP)은 이것을 받아 세그먼트(Segment)를 만듭니다.
TCP 헤더(출발지/목적지 포트, 시퀀스 번호 등)를 붙입니다.
1
[TCP 헤더][HTTP 요청]
인터넷 계층(IP)은 세그먼트를 받아 패킷(Packet)을 만듭니다.
IP 헤더(출발지/목적지 IP, TTL 등)를 붙입니다.
1
[IP 헤더][TCP 헤더][HTTP 요청]
네트워크 접근 계층(이더넷)은 패킷을 받아 프레임(Frame)을 만듭니다.
이더넷 헤더(출발지/목적지 MAC)와 FCS를 붙입니다.
1
[이더넷 헤더][IP 헤더][TCP 헤더][HTTP 요청][FCS]
물리 계층에서 프레임은 비트로 변환되어 전송됩니다.
이것을 캡슐화(Encapsulation)라고 합니다.
각 계층이 자신의 헤더를 추가하여 상위 계층의 데이터를 “캡슐”로 감쌉니다.
1
2
3
4
5
6
7
응용: [ HTTP 요청 ]
전송: [TCP 헤더][ HTTP 요청 ]
네트워크: [IP 헤더][TCP 헤더][HTTP 요청]
링크: [Eth 헤더][IP][TCP][HTTP][FCS]
수신측에서는 반대로 역캡슐화(Decapsulation)가 일어납니다.
각 계층에서 자신의 헤더를 확인하고 제거합니다.
최종적으로 응용 계층은 원래의 HTTP 요청만 받습니다.
전체 흐름: URL을 입력하면
브라우저에서 https://www.google.com 을 입력하면 어떤 일이 일어날까요?
1. DNS 조회
브라우저는 www.google.com의 IP 주소를 모릅니다.
DNS 서버에 물어봅니다.
1
"www.google.com의 IP는?" → "142.250.196.110"
2. TCP 연결
브라우저는 142.250.196.110의 포트 443에 TCP 연결을 요청합니다.
3-Way Handshake가 일어납니다.
3. TLS 핸드셰이크
HTTPS이므로 TLS 연결을 설정합니다.
암호화 방식 협상, 서버 인증서 확인, 세션 키 교환이 일어납니다.
4. HTTP 요청
암호화된 채널을 통해 HTTP GET 요청을 보냅니다.
1
2
GET / HTTP/1.1
Host: www.google.com
5. 캡슐화
1
2
3
4
5
6
7
8
9
응용: GET / HTTP/1.1 ...
↓
TCP: 세그먼트 (출발지 포트: 52000, 목적지 포트: 443)
↓
IP: 패킷 (출발지: 192.168.1.100, 목적지: 142.250.196.110)
↓
이더넷: 프레임 (목적지 MAC: 게이트웨이 MAC)
↓
물리: 비트 → 전기 신호
6. 라우팅
프레임이 홈 라우터로 전송됩니다.
라우터는 IP 헤더를 보고 다음 홉을 결정합니다.
여러 라우터를 거쳐 구글 서버까지 도달합니다.
7. 서버 응답
구글 서버는 패킷을 받아 역캡슐화합니다.
HTTP 요청을 처리하고 HTML 응답을 생성합니다.
같은 과정을 거쳐 응답이 브라우저로 돌아옵니다.
8. 렌더링
브라우저는 HTML을 파싱하고 화면에 표시합니다.
추가 리소스(이미지, CSS, JavaScript)가 필요하면 각각에 대해 이 과정을 반복합니다.
이 모든 것이 순식간에 일어납니다.
사용자는 그냥 구글 페이지가 뜨는 것만 봅니다.
마무리: 계층이 만드는 통신
네트워크 통신은 계층적 프로토콜 스택으로 구성됩니다.
네트워크 접근 계층은 같은 네트워크 내에서 MAC 주소로 프레임을 전달합니다.
인터넷 계층은 IP 주소로 서로 다른 네트워크 간에 패킷을 라우팅합니다.
전송 계층은 포트 번호로 프로세스를 구분하고, TCP는 신뢰성을, UDP는 속도를 제공합니다.
응용 계층은 HTTP, DNS 등 각 서비스에 맞는 프로토콜을 정의합니다.
캡슐화와 역캡슐화를 통해 각 계층은 독립적으로 동작합니다.
위 계층은 아래 계층의 구현을 몰라도 되고, 아래 계층은 위 계층의 내용을 해석하지 않아도 됩니다.
이 시리즈에서 살펴본 내용을 정리하면:
Part 1의 물리적 신호 전송이 비트를 실어 나르고,
Part 2의 디지털 처리가 그 비트를 신뢰할 수 있게 만들고,
Part 3의 프로토콜 스택이 그 비트들을 의미 있는 통신으로 조직합니다.
전자기파의 물리 법칙부터 HTTP 요청까지, 모든 계층이 협력하여 인터넷이 동작합니다.
관련 글