TCP/IP 4계층 모델
실제 인터넷이 따르는 TCP/IP 모델의 응용, 전송, 인터넷, 링크 계층을 OSI 모델과 대응시키고, 운영체제의 서비스 목록으로 응용 프로토콜의 기본 포트를 확인합니다. 웹 요청이 네 계층을 지나며 붙는 헤더와 그 비용을 계산하고, 실무에서 계층을 부르는 말을 정리합니다.
앞 글의 OSI 모델은 계층의 역할을 잘게 나누어 이해하기에 좋지만, 실제 인터넷은 이 모델을 그대로 따르지 않습니다. 인터넷의 프로토콜은 처음부터 TCP/IP 모델을 바탕으로 만들어졌고, 운영체제와 장비도 이 모델에 가깝게 구현되어 있습니다. 인터넷 호스트의 요구 사항을 정리한 RFC 1122도 인터넷의 프로토콜을 응용, 전송, 인터넷, 링크의 네 계층으로 설명합니다.
OSI와 TCP/IP의 대응
MODEL MAPPING · 3→1 / 1→1 / 2→1
OSI의 상위 세 기능과 하위 두 기능을 각각 묶어 이해한다
7·6·5는 TCP/IP 응용, 4는 전송, 3은 인터넷, 2·1은 네트워크 액세스로 대응합니다. 화살표는 기능 대응이며 패킷이 모델 사이를 이동하는 경로를 뜻하지 않습니다.
기능을 묶어 이해하는 대응 관계입니다. TLS·세션 관리 등의 구현 위치를 하나로 강제하지 않습니다.
청록 외곽: 여러 OSI 기능을 묶은 응용과 네트워크 액세스. 응용 3개 화살표·액세스 2개 화살표를 각각 한 영역으로 읽습니다.
그림처럼 OSI의 응용, 표현, 세션 계층은 TCP/IP의 응용 계층 하나로, 전송 계층은 전송 계층으로, 네트워크 계층은 인터넷 계층으로, 데이터 링크와 물리 계층은 링크 계층(또는 네트워크 인터페이스 계층) 하나로 묶입니다. 이 대응은 기능을 견주어 본 것일 뿐이며, 실제 구현이 OSI의 일곱 계층으로 나뉘어 있는 것은 아닙니다. 그래서 실무에서는 대화할 때는 L4, L7처럼 OSI의 번호를 쓰고, 프로토콜을 설명할 때는 TCP/IP의 네 계층을 기준으로 삼는 경우가 많습니다.
네 계층이 하는 일
응용 계층
응용 계층(application layer)에는 HTTP, DNS, SMTP, SSH처럼 서비스를 제공하는 모든 프로토콜이 속합니다. 개발자가 가장 많이 다루는 계층으로, 브라우저의 fetch()나 curl이 보내는 HTTP 요청이 여기에 해당합니다.
APPLICATION REFERENCE · DEFAULT PORT / TRANSPORT
포트 번호는 기본 설정의 단서이며 응용 프로토콜의 증거는 아니다
서비스 이름·기본 포트·전송 규약을 함께 확인합니다. HTTPS의 TCP/TLS와 HTTP/3의 QUIC/UDP, DNS의 UDP/TCP, FTP의 제어·별도 데이터 연결을 구분합니다.
| 프로토콜 | 기본 포트·전송 | 용도·범위 |
|---|---|---|
| HTTP | 80 · TCP | 암호화하지 않은 웹 통신 |
| HTTPS | 443 · TCP 또는 QUIC/UDP | 암호화된 웹. HTTP/3는 QUIC/UDP를 사용합니다. |
| DNS | 53 · UDP/TCP | 전통적인 DNS 질의·응답. 도메인 → IP 조회 등이 포함됩니다. |
| SMTP | 25 · TCP | 메일 서버 간 전송 |
| SSH | 22 · TCP | 암호화된 원격 접속 |
| FTP | 21 · TCP | 파일 전송의 제어 연결. 데이터 연결은 별도입니다. |
| DHCP | 67/68 · UDP | DHCPv4 서버/클라이언트의 주소 자동 할당 |
| NTP | 123 · UDP | 시간 동기화 |
- HTTP
- 기본 포트·전송: 80 · TCP
- 용도·범위: 암호화하지 않은 웹 통신
- HTTPS
- 기본 포트·전송: 443 · TCP 또는 QUIC/UDP
- 용도·범위: 암호화된 웹. HTTP/3는 QUIC/UDP를 사용합니다.
- DNS
- 기본 포트·전송: 53 · UDP/TCP
- 용도·범위: 전통적인 DNS 질의·응답. 도메인 → IP 조회 등이 포함됩니다.
- SMTP
- 기본 포트·전송: 25 · TCP
- 용도·범위: 메일 서버 간 전송
- SSH
- 기본 포트·전송: 22 · TCP
- 용도·범위: 암호화된 원격 접속
- FTP
- 기본 포트·전송: 21 · TCP
- 용도·범위: 파일 전송의 제어 연결. 데이터 연결은 별도입니다.
- DHCP
- 기본 포트·전송: 67/68 · UDP
- 용도·범위: DHCPv4 서버/클라이언트의 주소 자동 할당
- NTP
- 기본 포트·전송: 123 · UDP
- 용도·범위: 시간 동기화
기본 포트 예시이며 설정·프로토콜 변형에 따라 달라질 수 있습니다. 포트 번호만으로 실제 응용 프로토콜을 확정하지 않습니다.
67/68은 DHCPv4 서버/클라이언트 순서입니다. 소켓 끝점은 주소·포트·전송 프로토콜을 함께 읽으며, 설정 변경·암호화·캡처 위치에 따라 실제 메시지를 확인할 조건도 달라집니다.
응용 프로토콜마다 관례로 정해 둔 기본 포트가 있고, 운영체제는 그 목록을 서비스 데이터베이스로 가지고 있습니다. Linux에서는 /etc/services 파일이 그것이며, Windows에도 같은 형식의 파일이 있습니다.
import socket
for name, proto in [("http", "tcp"), ("https", "tcp"), ("ssh", "tcp"), ("smtp", "tcp"), ("domain", "udp")]:
print(f"{name}/{proto}: {socket.getservbyname(name, proto)}")http/tcp: 80
https/tcp: 443
ssh/tcp: 22
smtp/tcp: 25
domain/udp: 53domain은 DNS의 서비스 이름입니다. 포트 번호는 어디까지나 기본값의 관례여서, 웹 서버를 8080번 포트에서 실행할 수도 있고 SSH를 443번 포트에서 실행할 수도 있습니다. 그러므로 어떤 연결이 443번 포트를 쓴다고 그 안의 프로토콜이 HTTPS라고 단정할 수는 없으며, 포트는 무엇이 오갈지 짐작하게 하는 단서일 뿐입니다.
전송 계층
전송 계층(transport layer)은 프로세스 사이의 데이터 전달을 맡으며, TCP와 UDP가 중심입니다. 응용 프로그램은 운영체제가 제공하는 소켓(socket)을 통해 전송 계층을 쓰는데, 소켓을 만들 때 TCP라면 스트림 소켓을, UDP라면 데이터그램 소켓을 고릅니다. 소켓을 만드는 것만으로는 아무 데이터도 오가지 않으며, TCP라면 연결을 맺어야 하고 UDP라면 데이터그램을 보내야 비로소 패킷이 나갑니다. 소켓의 사용법은 11장에서 다룹니다. HTTP/3가 쓰는 QUIC은 UDP 위에서 동작하면서 TCP의 신뢰성과 TLS의 암호화를 함께 제공하는 전송 프로토콜입니다.
인터넷 계층
인터넷 계층(internet layer)은 IP로 서로 다른 네트워크 사이에 패킷을 전달하고 경로를 정합니다.
| 프로토콜 | 하는 일 |
|---|---|
| IPv4 | 32비트 주소로 패킷을 전달한다. 지금도 가장 널리 쓰인다 |
| IPv6 | 128비트 주소로 패킷을 전달한다. IPv4 주소의 고갈에 대응한다 |
| ICMP | 오류를 알리고 진단을 돕는다. ping과 traceroute가 쓴다 |
| IGMP | IPv4에서 멀티캐스트 그룹의 가입을 관리한다 |
같은 링크에 있는 상대의 IPv4 주소로 MAC 주소를 알아내는 ARP는 인터넷 계층과 링크 계층 사이를 이어 주며, IPv6에서는 이웃 발견(neighbor discovery)이 같은 일을 합니다.
ip addr show # 인터페이스마다 붙은 IP 주소
ip route show # 라우팅 표: 목적지마다 어느 게이트웨이로 보내는가
ip neigh show # ARP와 이웃 발견으로 알아낸 IP와 MAC의 대응
ping -c 4 8.8.8.8 # ICMP로 상대에게 닿는지네 명령은 인터넷 계층이 패킷을 보낼 때 쓰는 정보를 차례로 보여 줍니다. 내 주소, 목적지별로 보낼 곳, 같은 링크의 상대 MAC 주소입니다. ip neigh show에는 최근에 통신한 상대만 나오므로, 처음 보는 주소는 ping 같은 패킷을 한 번 보낸 뒤에야 나타납니다. ping이 응답을 받지 못해도 상대가 꺼져 있다고 단정할 수는 없습니다. ICMP를 방화벽에서 막아 둔 호스트도 많기 때문입니다.
링크 계층
링크 계층(link layer)은 같은 링크 안에서 프레임을 만들고, 신호로 바꾸어 실어 보내는 일을 맡습니다. 이더넷(IEEE 802.3)은 UTP와 광섬유 위에서 1, 10, 25, 100Gbps 같은 속도를 쓰고, Wi-Fi(IEEE 802.11)는 2.4, 5, 6GHz 대역의 전파를 씁니다. 휴대전화의 5G 망도 이 계층에 해당합니다. 규격에 적힌 최고 속도는 신호를 내보내는 속도의 상한이며, 응용 프로그램이 실제로 얻는 처리량은 채널의 상태와 함께 쓰는 사람 수, 헤더의 몫 때문에 그보다 낮습니다.
웹 요청이 네 계층을 지나는 길
브라우저에서 https://example.com에 접속할 때 각 계층에서 일어나는 일을 단순하게 따라가 봅니다. 먼저 응용 계층의 DNS가 이름을 IP 주소로 바꾸고, 전송 계층의 TCP가 서버의 443번 포트와 연결을 맺습니다. 그 위에서 TLS가 암호화 협상을 마치면, 브라우저는 HTTP 요청을 TLS로 암호화해 TCP에 넘깁니다. TCP는 그 바이트들을 세그먼트로 나누어 인터넷 계층의 IP에 맡기고, IP는 패킷의 목적지를 서버의 IP 주소로 적어 링크 계층에 넘기며, 링크 계층은 다음 홉인 공유기의 MAC 주소로 프레임을 만들어 내보냅니다. HTTP/3라면 TCP와 TLS 대신 QUIC이 UDP 위에서 같은 일을 합니다.
계층마다 헤더가 붙으므로, 링크로 나가는 프레임에는 데이터 말고도 헤더가 차지하는 몫이 있습니다. 다음 코드는 옵션이 없는 IPv4와 TCP, 이더넷을 가정하고 그 비율을 계산합니다.
ETH_HEADER, FCS, IP_HEADER, TCP_HEADER = 14, 4, 20, 20 # 옵션과 VLAN 태그가 없는 경우
MTU = 1500 # 이더넷 프레임에 담는 IP 패킷의 최대 크기
payload = MTU - IP_HEADER - TCP_HEADER # TCP가 담는 데이터
frame = ETH_HEADER + MTU + FCS # 링크로 나가는 프레임 전체
overhead = ETH_HEADER + IP_HEADER + TCP_HEADER + FCS
print(f"헤더와 트레일러: {ETH_HEADER} + {IP_HEADER} + {TCP_HEADER} + {FCS} = {overhead}바이트")
print(f"프레임 {frame}바이트 가운데 TCP 데이터 {payload}바이트, 효율 {payload / frame:.1%}")헤더와 트레일러: 14 + 20 + 20 + 4 = 58바이트
프레임 1518바이트 가운데 TCP 데이터 1460바이트, 효율 96.2%MTU 1500바이트는 IP 패킷이 들어갈 자리이므로, 이더넷 헤더 14바이트와 FCS 4바이트는 그 바깥에 붙어 프레임 전체는 1518바이트가 됩니다. 큰 데이터를 보낼 때 헤더의 몫은 4% 남짓이지만, 1바이트짜리 데이터를 보낼 때도 헤더는 똑같이 58바이트가 붙으므로 작은 패킷을 많이 보내면 효율이 크게 떨어집니다. 또 HTTPS라면 TCP가 담는 1460바이트 안에 TLS 레코드의 헤더와 HTTP 헤더도 들어가므로, 실제 파일 데이터의 비율은 이보다 낮습니다.
실무에서 계층을 부르는 말
| 표현 | 뜻 |
|---|---|
| L7 로드 밸런서 | HTTP의 URL, 헤더, 쿠키를 보고 트래픽을 나눈다(예: AWS의 ALB) |
| L4 로드 밸런서 | IP 주소와 포트, 전송 프로토콜을 보고 연결을 나눈다(예: AWS의 NLB) |
| L3 스위치 | 스위치이면서 IP 주소로 라우팅도 한다 |
| L2 VLAN | 스위치 안에서 링크 계층의 네트워크를 논리적으로 나눈다 |
장애를 진단할 때도 계층별로 보는 정보가 다릅니다. 응용 계층에서는 이름과 메시지를, 전송 계층에서는 포트와 연결 상태를, 인터넷 계층에서는 IP 주소와 라우팅을, 링크 계층에서는 MAC 주소와 프레임을 봅니다. 다만 TLS로 암호화되어 있으면 패킷을 캡처해도 응용 계층의 내용은 보이지 않으므로, 어디에서 무엇을 볼 수 있는지도 함께 따져야 합니다.
정리
- TCP/IP 모델은 실제 인터넷이 따르는 모델로, 응용, 전송, 인터넷, 링크의 네 계층으로 이루어집니다.
- OSI의 응용, 표현, 세션 계층은 TCP/IP의 응용 계층에, 데이터 링크와 물리 계층은 링크 계층에 대응합니다.
- 응용 프로토콜의 기본 포트는 운영체제의 서비스 목록에 있는 관례이며, 포트만으로 프로토콜을 단정할 수는 없습니다.
- 웹 요청은 DNS, TCP, TLS, HTTP를 거쳐 계층마다 헤더가 붙고, 큰 데이터에서는 헤더의 몫이 작지만 작은 패킷이 많으면 효율이 떨어집니다.
- 실무에서는 대화할 때 OSI의 번호를, 프로토콜을 설명할 때 TCP/IP의 계층을 씁니다.
연습 문제
1. MTU가 1280바이트인 링크
다른 조건은 본문과 같고, 이더넷 링크의 IP MTU만 1280바이트로 줄였습니다. 프레임 하나에 담을 수 있는 TCP 데이터의 최대 크기와 프레임 전체의 크기는 얼마인가요?
해설 보기
TCP 데이터는 1280 - 20 - 20 = 1240바이트이고, 프레임 전체는 1280에 이더넷 헤더 14바이트와 FCS 4바이트를 더한 1298바이트입니다. 이더넷 헤더와 FCS는 MTU 안에 들어가지 않는다는 점에 주의합니다. 실제로 보내는 크기는 상대가 알려 준 MSS와 경로의 MTU, 헤더의 옵션에 따라 더 작아질 수도 있습니다.
2. 443번 포트의 정체
방화벽 로그에 사내의 한 서버가 외부의 443번 포트로 오래 연결을 유지하는 기록이 있습니다. 보안 담당자는 "443번이니 HTTPS 트래픽이고 문제없다"고 판단했습니다. 이 판단의 문제는 무엇이고, 무엇을 더 확인해야 하나요?
해설 보기
포트 번호는 관례일 뿐이어서, 443번 포트로 SSH나 VPN, 혹은 악성 코드의 통신이 오갈 수도 있습니다. 방화벽이 443번을 대개 열어 두기 때문에 다른 프로토콜이 일부러 이 포트를 쓰기도 합니다. 연결의 첫 부분이 실제로 TLS 핸드셰이크인지, TLS라면 요청한 서버 이름(SNI)과 인증서가 무엇인지, 상대 주소가 어떤 서비스의 것인지, 트래픽의 양과 시간 패턴이 평범한 웹 사용과 맞는지를 확인해야 합니다. 포트는 짐작의 출발점이지 결론이 아닙니다.
3. 작은 패킷의 효율
센서가 측정값 8바이트를 TCP로 1초마다 하나씩 보냅니다. 옵션이 없는 IPv4와 TCP, 이더넷을 가정할 때, 프레임 하나에서 데이터가 차지하는 비율은 얼마인가요? 이더넷 프레임에는 최소 크기가 있다는 점도 생각해 보세요.
해설 보기
헤더와 트레일러가 58바이트이므로 데이터 8바이트를 담으면 66바이트가 되고, 이는 이더넷의 최소 프레임 크기 64바이트보다 크므로 그대로 보냅니다. 데이터의 비율은 8 ÷ 66 ≈ 12.1%로, 나머지 88%는 헤더입니다. 이처럼 작은 데이터를 자주 보내면 헤더의 비용이 커지므로, 측정값을 몇 개씩 모아 한 번에 보내거나, 헤더가 작은 UDP와 가벼운 응용 프로토콜을 쓰는 방법을 고려합니다.
다음 글 캡슐화와 역캡슐화에서는 계층을 내려가며 헤더가 붙고 올라가며 벗겨지는 과정을 바이트 단위로 따라가고, 라우터를 지날 때 무엇이 바뀌는지 살펴봅니다.