infra
Platform

모듈 맵

[Network] OSI 7계층과 TCP/IP 4계층 모델 실무적 관점 분석

0 / 35 완료

펼치기
0 / 35 완료0%

Networking · 01 / 35

[Network] OSI 7계층과 TCP/IP 4계층 모델 실무적 관점 분석

네트워크 통신의 기본 뼈대인 OSI 7계층과 TCP/IP 모델을 이해하고, 계층별 도구(ping/telnet/curl)로 장애 위치를 좁히는 방법을 배웁니다.

초급451 / 35
🚨INCIDENT ALERT
HIGH

장애 채널에 "네트워크가 안 됩니다"라는 한 줄만 올라왔습니다. ping은 되는지, 포트는 열렸는지, HTTP 응답은 오는지 구분하지 않으면 모두가 각자 다른 문제를 상상합니다.

OSI 계층은 외우는 표가 아니라 장애를 쪼개는 언어입니다. 계층별 도구를 쓰면 원인을 좁힐 수 있습니다.

OSI 7계층과 TCP/IP 모델

네트워크 문제가 발생했을 때 "어디서 막혔는지"를 빠르게 좁히려면 계층 모델을 이해해야 합니다. 인프라 엔지니어가 가장 먼저 배우는 개념이면서, 실무에서도 매일 사용하는 사고 프레임워크입니다.

이번 챕터에서 배울 것
  • 1OSI 7계층 모델의 각 계층 역할과 데이터 단위
  • 2TCP/IP 4계층 모델과 OSI 계층 간 매핑
  • 3계층별 식별자: MAC 주소(L2), IP 주소(L3), 포트 번호(L4)
  • 4ping(ICMP)으로 L3 통신 검증하기
  • 5telnet/nc으로 L4 TCP 포트 열림 여부 확인하기
  • 6curl로 L7 HTTP/HTTPS 응답 검증 및 장애 계층 좁히기
실습 환경 준비
ping 사용 가능 여부 확인
ping -c 1 8.8.8.8
netcat(nc) 설치 확인 또는 설치
nc -h 2>&1 | head -1 || sudo apt-get install -y netcat
curl 설치 확인
curl --version | head -1
telnet 설치 확인 또는 설치
telnet 2>&1 | head -1 || sudo apt-get install -y telnet
💡개념

OSI 7계층 모델이란?

서버에 배포한 서비스가 갑자기 안 된다는 신고가 들어왔습니다. 어디서부터 확인해야 할까요? 서버 자체가 살아있는지, 포트가 열려있는지, 애플리케이션이 응답하는지 — 순서 없이 여기저기 찔러보다가 시간만 가는 상황을 막으려면 계층별 사고 프레임이 필요합니다. OSI 7계층 모델이 바로 이 프레임입니다.

OSI 7계층 모델이란?

건물에 비유하면, 전기가 들어오는지(L1), 인터폰이 작동하는지(L2), 주소를 찾아오는지(L3), 문이 열리는지(L4), 안에 사람이 있는지(L7) — 각 층을 차례로 확인하면 어디가 문제인지 빠르게 좁혀집니다. 네트워크 장애 대응이 정확히 이 방식으로 이루어집니다.

OSI(Open Systems Interconnection) 모델은 ISO가 1984년에 정의한 네트워크 통신의 표준 참조 모델입니다. 네트워크 통신을 7개의 계층으로 나누어, 각 계층이 하는 역할을 명확하게 정의했습니다.

실제 구현에서는 TCP/IP 모델을 사용하지만, 장애 진단과 개념 설명에서는 OSI 7계층이 훨씬 세밀하기 때문에 지금도 표준 언어로 사용됩니다.

L7  애플리케이션 계층  (Application)   HTTP, HTTPS, DNS, SMTP, FTP
L6  표현 계층        (Presentation)   TLS/SSL, 인코딩, 압축
L5  세션 계층        (Session)        세션 관리, 인증
L4  전송 계층        (Transport)      TCP, UDP — 포트 번호
L3  네트워크 계층    (Network)        IP — 라우팅, 논리 주소
L2  데이터링크 계층  (Data Link)      Ethernet, MAC 주소
L1  물리 계층        (Physical)       케이블, 광섬유, 전기 신호

계층의 핵심 원칙: 각 계층은 자신의 역할만 담당하고, 위아래 계층에 서비스를 제공합니다. 데이터는 송신 측에서 L7→L1 방향으로 **캡슐화(Encapsulation)**되고, 수신 측에서 L1→L7 방향으로 **역캡슐화(Decapsulation)**됩니다.

각 계층 상세 설명

L1 — 물리 계층 (Physical Layer)

전기 신호, 광 신호를 물리적으로 전송합니다. 케이블, NIC 카드, 허브, 리피터 등이 여기에 해당합니다.

  • 데이터 단위: 비트(Bit)
  • 장비: 케이블, 허브, 리피터
  • 장애 증상: 링크 다운, 케이블 불량, NIC 오류
  • 확인 방법: ip link showUP/DOWN 상태 확인
로컬 터미널
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part1/exam_1 && cd /tmp/networking/part1/exam_1

# 물리 계층 상태 확인
ip link show eth0
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
#                                    ↑ UP이면 물리 연결 정상
🔍실행 후 확인할 것
  • 계층별 성공 지점ping, telnet/nc, curl 중 어디까지 성공하는지 확인합니다
  • 실패 계층L3, L4, L7 중 처음 실패하는 지점을 장애 후보로 잡습니다
  • 다음 도구성공한 계층 다음 단계의 도구로 좁혀 갑니다

L2 — 데이터링크 계층 (Data Link Layer)

같은 네트워크 세그먼트(LAN) 내에서 프레임을 전달합니다. MAC 주소로 목적지를 식별합니다.

  • 데이터 단위: 프레임(Frame)
  • 주소 체계: MAC 주소 (48비트, 예: aa:bb:cc:dd:ee:ff)
  • 장비: 스위치, 브리지
  • 확인 방법: arp -n — MAC 주소 테이블 확인
로컬 터미널
# ARP 테이블 확인 (L2 통신이 이루어진 호스트 목록)
arp -n
# Address          HWtype  HWaddress           Flags Iface
# 192.168.1.1      ether   aa:bb:cc:dd:ee:ff   C     eth0

L3 — 네트워크 계층 (Network Layer)

IP 주소를 기반으로 다른 네트워크까지 패킷을 라우팅합니다. 인터넷이 동작하는 핵심 계층입니다.

  • 데이터 단위: 패킷(Packet)
  • 주소 체계: IP 주소 (IPv4 32비트, IPv6 128비트)
  • 장비: 라우터
  • 프로토콜: IP, ICMP, OSPF, BGP
로컬 터미널
# L3 통신 확인 — ping
ping -c 3 8.8.8.8

# 라우팅 경로 확인
ip route show
# default via 192.168.1.1 dev eth0
# 192.168.1.0/24 dev eth0 proto kernel

L4 — 전송 계층 (Transport Layer)

포트 번호를 사용해 프로세스 간 통신을 관리합니다. TCP(신뢰성)와 UDP(속도)가 대표적입니다.

  • 데이터 단위: 세그먼트(TCP) / 데이터그램(UDP)
  • 식별자: 포트 번호 (0~65535)
  • 프로토콜: TCP, UDP
로컬 터미널
# L4 통신 확인 — telnet으로 특정 포트 열림 여부 확인
telnet 192.168.1.10 80
# Connected to 192.168.1.10. ← 연결 성공 (L4 정상)

# 현재 열려있는 포트 확인
ss -tlnp
# State   Recv-Q  Send-Q  Local Address:Port
# LISTEN  0       128     0.0.0.0:80

L5, L6 — 세션/표현 계층

현대의 TCP/IP 구현에서는 L5(세션)와 L6(표현)이 애플리케이션 계층에 통합되는 경우가 많습니다. TLS/SSL 암호화가 L6에 해당합니다.

L7 — 애플리케이션 계층 (Application Layer)

사용자가 직접 사용하는 프로토콜 계층입니다. HTTP, HTTPS, DNS, SMTP 등이 여기에 해당합니다.

  • 데이터 단위: 메시지(Message)
  • 프로토콜: HTTP, HTTPS, DNS, FTP, SSH, SMTP
로컬 또는 서버
# L7 통신 확인 — curl로 HTTP 응답 확인
curl -I http://example.com
# HTTP/1.1 200 OK          ← L7 애플리케이션 응답 정상
# Content-Type: text/html

💡개념

TCP/IP 4계층 모델

OSI 7계층을 외웠는데 실제 코드나 문서에서는 "인터넷 계층", "전송 계층"이라는 말이 나옵니다. 팀원이 "L4에서 막힌 것 같다"고 할 때 OSI 기준인지 TCP/IP 기준인지 헷갈립니다. 두 모델을 자유롭게 오가며 매핑할 줄 알아야 문서를 읽고 장비 설정을 이해할 수 있습니다.

실제 인터넷 구현에 사용되는 모델입니다. OSI 7계층을 실용적으로 단순화하여 4계층으로 표현합니다.

TCP/IP 4계층 모델

TCP/IP 4계층          OSI 7계층 대응
────────────────────────────────────────
애플리케이션 계층     L5(세션) + L6(표현) + L7(애플리케이션)
  (Application)       HTTP, HTTPS, DNS, FTP, SSH, SMTP

전송 계층             L4 (전송)
  (Transport)         TCP, UDP

인터넷 계층           L3 (네트워크)
  (Internet)          IP, ICMP, ARP

네트워크 접근 계층    L1(물리) + L2(데이터링크)
  (Network Access)    Ethernet, Wi-Fi, PPP

실무에서 OSI와 TCP/IP를 모두 알아야 하는 이유:

  • 장비/제조사 문서, RFC, 교재 → OSI 계층 용어 사용
  • 실제 프로토콜/코드 이해 → TCP/IP 모델
  • 두 모델 간 매핑을 자유롭게 할 수 있어야 합니다.

계층별 핵심 식별자 정리

각 계층은 서로 다른 주소 체계로 통신 대상을 식별합니다. 방화벽 규칙을 설정하거나 장애 원인을 좁힐 때 어느 계층의 식별자를 다루고 있는지 알면 명령어와 도구 선택이 명확해집니다.

계층식별자예시담당 장비
L7URL, 호스트명https://api.example.com/users로드밸런서(L7)
L4포트 번호:443, :3306방화벽, L4 LB
L3IP 주소10.0.1.25라우터
L2MAC 주소aa:bb:cc:dd:ee:ff스위치

계층별 도구로 장애 좁히기

네트워크 장애가 발생하면 L1부터 L7까지 순서대로 확인하는 것이 기본입니다. 하위 계층이 정상이어야 상위 계층이 동작할 수 있기 때문입니다.

L3 확인 — ping으로 IP 통신 검증

ping은 ICMP Echo Request/Reply를 사용하는 L3 진단 도구입니다.

로컬 터미널
# 기본 ping (4회)
ping -c 4 8.8.8.8

# 예상 출력
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.45 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=3.21 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=3.67 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=3.33 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 3.21/3.41/3.67/0.17 ms

출력 해석:

  • 4 received, 0% packet loss → L3 통신 정상
  • time=3.45 ms → RTT(왕복 지연 시간), 낮을수록 좋음
  • ttl=118 → 경유한 라우터 수를 역산 가능 (보통 초기값 128 또는 64)

ping 실패 시나리오:

로컬 터미널
ping -c 4 10.0.1.99
# PING 10.0.1.99: 56 data bytes
# Request timeout for icmp_seq 0
# Request timeout for icmp_seq 1
# --- 10.0.1.99 ping statistics ---
# 4 packets transmitted, 0 packets received, 100% packet loss

→ L1~L3 중 어딘가 문제. 또는 ICMP가 방화벽에서 차단됨.

L4 확인 — telnet으로 TCP 포트 연결 검증

telnet으로 특정 호스트의 TCP 포트가 열려있는지 확인합니다.

로컬 터미널
# 80번 포트 연결 테스트
telnet 192.168.1.10 80

# 연결 성공 시:
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
# → 빈 커서가 깜빡임 (HTTP 요청을 기다리는 상태)
# Ctrl+] 후 quit으로 종료

# 연결 실패 시:
Trying 192.168.1.10...
telnet: connect to address 192.168.1.10: Connection refused
# → 포트가 닫혀 있거나 방화벽에서 차단됨

telnet 대신 nc(netcat) 사용:

로컬 터미널
# nc로 포트 열림 여부 확인 (-z: 연결만 확인, -v: 상세 출력)
nc -zv 192.168.1.10 80
# Connection to 192.168.1.10 80 port [tcp/http] succeeded!

# 타임아웃 설정 (5초)
nc -zvw5 192.168.1.10 443
L7 확인 — curl로 HTTP 응답 검증

curl은 HTTP, HTTPS 등 애플리케이션 계층 프로토콜을 직접 테스트합니다.

로컬 또는 서버
# HTTP 헤더만 확인 (-I: HEAD 요청)
curl -I http://example.com

# HTTP/1.1 200 OK
# Content-Type: text/html; charset=UTF-8
# Content-Length: 1256
# Server: nginx/1.24.0

# 상세 연결 정보 포함 (-v: verbose)
curl -v https://api.example.com/health

# * Trying 93.184.216.34:443...
# * Connected to api.example.com (93.184.216.34) port 443
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
# > GET /health HTTP/2
# < HTTP/2 200
# {"status":"ok"}

# 응답 시간 측정
curl -o /dev/null -s -w \
  "연결: %{time_connect}s\nTLS: %{time_appconnect}s\n전체: %{time_total}s\n" \
  https://example.com

계층별 장애 진단 플로우

사용자로부터 "웹사이트에 접속이 안 된다"는 신고를 받았습니다. 체계적으로 계층을 좁혀 나가겠습니다.

1단계: 물리/링크 확인 (L1/L2)

로컬 터미널
# NIC 상태 확인
ip link show
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> → UP이면 L1/L2 정상

# 만약 DOWN 상태라면:
# eth0: <BROADCAST,MULTICAST> → 링크 다운, 케이블/포트 확인 필요

2단계: IP 통신 확인 (L3)

로컬 터미널
# 게이트웨이 ping
ping -c 3 192.168.1.1

# 인터넷 IP ping
ping -c 3 8.8.8.8

3단계: TCP 포트 확인 (L4)

로컬 터미널
# 웹 서버의 80/443 포트 확인
telnet web-server.example.com 80
nc -zv web-server.example.com 443

4단계: HTTP 응답 확인 (L7)

로컬 또는 서버
# HTTP 응답 코드와 헤더 확인
curl -I http://web-server.example.com
curl -v https://web-server.example.com

진단 결과 매트릭스:

L1/L2L3 pingL4 telnetL7 curl원인
DOWN실패실패실패케이블/NIC 문제
UP실패실패실패라우팅/방화벽(L3)
UP성공실패실패포트 차단/서비스 미기동
UP성공성공실패애플리케이션 오류
UP성공성공성공클라이언트 측 문제

ping이 성공하면 L3까지는 정상입니다. 그런데 브라우저에서 접속이 안 된다면?

로컬 터미널
# 1. ping 성공 확인 (L3 정상)
ping -c 3 web-server.example.com
# 64 bytes from 93.184.216.34: icmp_seq=1 ttl=64 time=2.1 ms ← 성공

# 2. TCP 443 포트 확인 (L4)
nc -zv web-server.example.com 443
# nc: connect to web-server.example.com port 443 (tcp) failed: Connection refused

# 원인 파악: HTTPS 포트(443)가 닫혀 있음
# 가능한 원인:
# a) nginx/apache가 실행 중이지 않음
# b) 방화벽(iptables, 보안그룹)에서 443 차단
# c) 서비스가 443이 아닌 다른 포트에서 실행 중

# 3. 서버에서 서비스 상태 확인
ss -tlnp | grep ':443'
# (아무 출력 없음) → nginx가 실행 중이지 않음

systemctl status nginx
# Active: inactive (dead) ← nginx 중지 상태

교훈: ping 성공 ≠ 서비스 정상. 반드시 L4(포트), L7(응답) 확인까지 해야 합니다.


실전 진단 스크립트

계층별 통신 진단 원라이너 모음

자주 사용하는 계층별 진단 명령어를 정리합니다.

로컬 터미널
#!/bin/bash
# 네트워크 계층별 진단 스크립트
TARGET="example.com"
TARGET_IP="93.184.216.34"

echo "=== L1/L2: 네트워크 인터페이스 상태 ==="
ip link show | grep -E "^[0-9]+:|state"

echo ""
echo "=== L3: IP 통신 (ping) ==="
ping -c 3 -W 2 $TARGET_IP && echo "L3 정상" || echo "L3 실패"

echo ""
echo "=== L3: 라우팅 경로 ==="
ip route get $TARGET_IP

echo ""
echo "=== L4: TCP 포트 확인 ==="
for PORT in 80 443; do
    nc -zvw3 $TARGET $PORT 2>&1 && echo "Port $PORT: 열림" || echo "Port $PORT: 닫힘"
done

echo ""
echo "=== L7: HTTP 응답 ==="
curl -s -o /dev/null -w "HTTP 상태: %{http_code}, 시간: %{time_total}s\n" \
    http://$TARGET

echo ""
echo "=== L7: HTTPS 응답 ==="
curl -s -o /dev/null -w "HTTPS 상태: %{http_code}, TLS: %{time_appconnect}s\n" \
    https://$TARGET

💼
실무 맥락
현업 패턴

실제 업무에서 OSI 계층 모델은 다음과 같이 활용됩니다.

온콜 장애 대응 시:

새벽 2시, 모니터링 알람 — "API 서버 응답 없음"

1. L3 확인: ping → 성공 (서버는 살아있음)
2. L4 확인: nc -zv api-server 8080 → 실패
3. 결론: 애플리케이션 프로세스가 죽었거나 포트가 닫힘
4. 조치: systemctl restart api-server

ACL(방화벽 규칙) 요청 시: 팀원이 "방화벽 열어주세요"라고 요청할 때, 계층을 명확히 해야 합니다:

  • L3: 어떤 소스 IP → 어떤 목적지 IP
  • L4: 어떤 프로토콜(TCP/UDP), 어떤 포트
  • L7: 특정 URL 패턴 (L7 방화벽/WAF의 경우)

인프라 문서 작성 시: "L4 로드밸런서", "L7 라우팅", "L2 스위치" 같은 용어를 정확히 사용하면 동료와의 소통이 명확해집니다.

면접에서 자주 나오는 질문:

  • "HTTPS 통신에서 각 계층이 하는 역할을 설명해보세요."
  • "L4 LB와 L7 LB의 차이는 무엇인가요?"
  • "ping은 성공하는데 서비스 접속이 안 될 때 어떻게 디버깅하시나요?"

요약

개념핵심 내용
OSI 7계층L1(물리)~L7(애플리케이션)으로 통신을 표준화한 참조 모델
TCP/IP 4계층OSI를 실용화한 실제 인터넷 프로토콜 스택
L2 식별자MAC 주소 — 같은 LAN 내 통신
L3 식별자IP 주소 — 라우팅을 통한 네트워크 간 통신
L4 식별자포트 번호 — 프로세스/서비스 구분
L7 식별자URL, 호스트명 — 애플리케이션 수준 통신
pingICMP, L3 검증 도구
telnet/ncL4 TCP 포트 열림 여부 확인 도구
curlL7 HTTP/HTTPS 응답 확인 도구
장애 진단 원칙하위 계층(L1)부터 순서대로 확인하며 범위를 좁힘

다음 챕터에서는 L3의 핵심인 **IP 주소 체계와 서브네팅(CIDR)**을 학습합니다.

지식 확인

퀴즈 — 5문제

Q1

같은 서브넷의 서버A(192.168.1.10)→서버B(192.168.1.20) 통신에서 ping은 성공하는데 telnet 3306은 실패합니다. 어느 계층에 문제가 있는 건가요?

Q2

ping 명령어는 OSI 몇 계층까지 동작을 검증하나요?

Q3

HTTP 응답 코드 404를 반환한다는 것은 어느 계층까지 정상적으로 동작하고 있음을 의미하나요?

Q4

telnet 192.168.1.10 80 명령어로 무엇을 확인할 수 있나요?

Q5

TCP/IP 4계층 모델에서 '인터넷 계층'에 해당하는 OSI 계층은?

0 / 5 답변

🧪 실습으로 확인하기

포트는 열렸다는데 왜 안 되지? — ss/netstat/telnet으로 TCP 진단

초급

"포트 8080 열었는데요?"와 "왜 안 돼요?" 사이의 간극을 메우는 실습. ss로 바인딩 상태를 확인하고, telnet/nc으로 원격 연결을 테스트하고, iptables 방화벽을 진단하고, 바인딩 주소(0.0.0.0 vs 127.0.0.1)까지 수정하는 4단계 TCP 포트 진단 플로우를 완성한다.

35📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

networking입문 · 40
[Network] 라우팅 테이블(Route Table) 조회와 게이트웨이 추가/삭제
Networking 트랙 계속
docker입문 · 30
[Docker] 백엔드 개발자에게 Docker와 컨테이너 가상화가 필수인 이유
Docker 트랙 시작점