웹 서버에서의 데이터 전달과 처리
34. 웹 서버에서의 데이터 전달과 처리
클라이언트에서 출발한 HTTP 요청이 여러 네트워크 장비를 거쳐 웹 서버에 도착하면, 웹 서버는 역캡슐화 과정을 통해 데이터를 처리하고 응답을 생성합니다. 이 과정은 OSI 모델의 하위 계층부터 상위 계층으로 진행됩니다.
34-1. 웹 서버에서의 데이터 수신 과정
전체 역캡슐화 과정
데이터가 전기 신호로 웹 서버에 도착하면, 다음과 같은 순서로 처리됩니다:
[물리 계층]
전기 신호 수신
━━━━┓ ┏━━━━┓ ┏━━━━┓ ┏━━━━
┗━━━━┛ ┗━━━━┛ ┗━━━━┛
↓
디지털 데이터로 변환
↓
[데이터링크 계층]
┌──────────────────────────────────────────┐
│ 이더넷 프레임 │
├──────────────────────────────────────────┤
│ 목적지 MAC: CC:DD:EE:FF:00:11 │ ← 웹 서버의 MAC
│ 출발지 MAC: 99:AA:BB:CC:DD:EE │ ← 라우터의 MAC
│ 타입: 0x0800 (IPv4) │
├──────────────────────────────────────────┤
│ IP 헤더 + TCP 세그먼트 + HTTP 데이터 │
├──────────────────────────────────────────┤
│ FCS: 0x12345678 │
└──────────────────────────────────────────┘
1. 목적지 MAC 주소 확인
CC:DD:EE:FF:00:11 == 내 MAC? ✓ Yes
2. FCS 체크 (오류 검사)
CRC-32 체크섬 계산 → 일치 ✓
3. 이더넷 헤더와 트레일러 제거 (역캡슐화)
↓
[네트워크 계층]
┌──────────────────────────────────────────┐
│ IP 패킷 │
├──────────────────────────────────────────┤
│ 출발지 IP: 172.16.0.1 │
│ 목적지 IP: 192.168.10.100 │ ← 웹 서버의 IP
│ TTL: 62 │
│ 프로토콜: 6 (TCP) │
├──────────────────────────────────────────┤
│ TCP 세그먼트 + HTTP 데이터 │
└──────────────────────────────────────────┘
4. 목적지 IP 주소 확인
192.168.10.100 == 내 IP? ✓ Yes
5. IP 헤더 체크섬 검증
6. IP 헤더 제거 (역캡슐화)
↓
[전송 계층]
┌──────────────────────────────────────────┐
│ TCP 세그먼트 │
├──────────────────────────────────────────┤
│ 출발지 포트: 54321 │
│ 목적지 포트: 80 │ ← HTTP 서비스
│ 시퀀스 번호: 1000 │
│ ACK 번호: 5000 │
│ 플래그: PSH, ACK │
├──────────────────────────────────────────┤
│ HTTP 메시지 │
└──────────────────────────────────────────┘
7. 목적지 포트 번호 확인
포트 80 → HTTP 서비스 (웹 서버 프로세스)
8. TCP 체크섬 검증
9. 시퀀스 번호 확인 및 ACK 준비
10. TCP 헤더 제거 (역캡슐화)
↓
[응용 계층]
┌─────────────────────────────────────────┐
│ HTTP 요청 메시지 │
├─────────────────────────────────────────┤
│ GET /index.html HTTP/1.1 │
│ Host: www.example.com │
│ User-Agent: Mozilla/5.0 │
│ Accept: text/html │
│ ... │
└─────────────────────────────────────────┘
11. 웹 서버 애플리케이션이 HTTP 요청 처리34-2. 계층별 상세 처리 과정
물리 계층 (Physical Layer)
┌─────────────────────────────────────────────┐
│ 물리 계층 처리 │
└─────────────────────────────────────────────┘
네트워크 케이블
↓
전기 신호 수신
━━━━┓ ┏━━━━┓ ┏━━━━┓ ┏━━━━
┗━━━━┛ ┗━━━━┛ ┗━━━━┛
↓
NIC (Network Interface Card)
↓
디지털 데이터로 변환
01010101 10101010 ...
↓
프리앰블 제거
↓
데이터링크 계층으로 전달역할:
- 전기 신호를 비트로 변환
- 동기화 (프리앰블 확인)
- 신호 품질 확인
데이터링크 계층 (Data Link Layer)
┌─────────────────────────────────────────────┐
│ 데이터링크 계층 처리 │
└─────────────────────────────────────────────┘
이더넷 프레임 수신
┌──────────┬──────┬──────┬──────┬──────┐
│이더넷헤더│IP헤더│TCP헤더│HTTP │ FCS │
└──────────┴──────┴──────┴──────┴──────┘
1단계: 목적지 MAC 주소 확인
┌──────────────────────────────────┐
│ 수신한 MAC: CC:DD:EE:FF:00:11 │
│ 내 MAC: CC:DD:EE:FF:00:11 │
│ 일치? ✓ Yes → 계속 처리 │
│ 일치? ✗ No → 프레임 폐기 │
└──────────────────────────────────┘
2단계: FCS (Frame Check Sequence) 검사
┌──────────────────────────────────┐
│ 수신한 데이터로 CRC-32 계산 │
│ 계산 결과와 FCS 비교 │
│ 일치? ✓ 오류 없음 → 계속 │
│ 일치? ✗ 오류 발생 → 프레임 폐기 │
└──────────────────────────────────┘
3단계: 이더넷 타입 확인
┌──────────────────────────────────┐
│ 0x0800 → IPv4 │
│ 0x86DD → IPv6 │
│ 0x0806 → ARP │
└──────────────────────────────────┘
4단계: 역캡슐화 (이더넷 헤더/트레일러 제거)
┌──────┬──────┬──────┐
│IP헤더│TCP헤더│HTTP │ → 네트워크 계층으로 전달
└──────┴──────┴──────┘주요 검증:
- MAC 주소 일치 확인
- FCS 오류 검사
- 이더넷 타입 확인
네트워크 계층 (Network Layer)
┌─────────────────────────────────────────────┐
│ 네트워크 계층 처리 │
└─────────────────────────────────────────────┘
IP 패킷 수신
┌───────────┬───────────┬─────────────────┐
│ IP 헤더 │ TCP 헤더 │ HTTP 메시지 │
└───────────┴───────────┴─────────────────┘
1단계: IP 버전 확인
┌──────────────────────────────────┐
│ 버전 필드: 4 → IPv4 │
│ 버전 필드: 6 → IPv6 │
└──────────────────────────────────┘
2단계: IP 헤더 체크섬 검증
┌──────────────────────────────────┐
│ IP 헤더의 체크섬 계산 │
│ 계산 결과와 헤더의 체크섬 비교 │
│ 일치? ✓ 오류 없음 │
│ 일치? ✗ 패킷 폐기 │
└──────────────────────────────────┘
3단계: 목적지 IP 주소 확인
┌──────────────────────────────────┐
│ 목적지 IP: 192.168.10.100 │
│ 내 IP: 192.168.10.100 │
│ 일치? ✓ Yes → 내가 처리 │
│ 일치? ✗ No → 라우팅 필요 │
└──────────────────────────────────┘
4단계: TTL 확인
┌──────────────────────────────────┐
│ TTL: 62 │
│ 0이 아니므로 정상 │
│ (0이면 패킷 폐기) │
└──────────────────────────────────┘
5단계: 프로토콜 확인
┌──────────────────────────────────┐
│ 프로토콜 필드: 6 → TCP │
│ 프로토콜 필드: 17 → UDP │
│ 프로토콜 필드: 1 → ICMP │
└──────────────────────────────────┘
6단계: 역캡슐화 (IP 헤더 제거)
┌───────────┬─────────────────┐
│ TCP 헤더 │ HTTP 메시지 │ → 전송 계층(TCP)으로 전달
└───────────┴─────────────────┘주요 검증:
- IP 헤더 체크섬 검증
- 목적지 IP 주소 확인
- TTL 확인
- 프로토콜 타입 확인
전송 계층 (Transport Layer)
┌─────────────────────────────────────────────┐
│ 전송 계층 처리 (TCP) │
└─────────────────────────────────────────────┘
TCP 세그먼트 수신
┌───────────┬─────────────────────────────┐
│ TCP 헤더 │ HTTP 메시지 │
└───────────┴─────────────────────────────┘
1단계: 목적지 포트 번호 확인
┌──────────────────────────────────┐
│ 목적지 포트: 80 │
│ → HTTP 서비스 │
│ 어떤 프로세스로 전달할지 결정 │
└──────────────────────────────────┘
포트 번호 → 서비스 매핑:
┌──────┬────────────────┐
│ 포트 │ 서비스 │
├──────┼────────────────┤
│ 80 │ HTTP │
│ 443 │ HTTPS │
│ 22 │ SSH │
│ 21 │ FTP │
│ 25 │ SMTP │
└──────┴────────────────┘
2단계: TCP 체크섬 검증
┌──────────────────────────────────┐
│ TCP 헤더 + 데이터로 체크섬 계산 │
│ 계산 결과와 헤더의 체크섬 비교 │
│ 일치? ✓ 오류 없음 │
│ 일치? ✗ 세그먼트 폐기 │
└──────────────────────────────────┘
3단계: 시퀀스 번호 확인
┌──────────────────────────────────┐
│ 시퀀스 번호: 1000 │
│ 예상 번호와 비교 │
│ 일치? ✓ 순서대로 도착 │
│ 일치? ✗ 재정렬 필요 또는 재전송 │
└──────────────────────────────────┘
4단계: ACK 번호 처리
┌──────────────────────────────────┐
│ ACK 번호: 5000 │
│ 상대방이 받을 준비가 된 번호 │
│ 송신 윈도우 조정 │
└──────────────────────────────────┘
5단계: 플래그 확인
┌──────────────────────────────────┐
│ PSH: 즉시 애플리케이션에 전달 │
│ ACK: 확인 응답 │
│ SYN: 연결 시작 │
│ FIN: 연결 종료 │
└──────────────────────────────────┘
6단계: ACK 응답 준비
┌──────────────────────────────────┐
│ ACK 번호 = 받은 시퀀스 + 데이터크기│
│ 예: 1000 + 200 = 1200 │
│ "1200까지 잘 받았어요" │
└──────────────────────────────────┘
7단계: 역캡슐화 (TCP 헤더 제거)
┌─────────────────────────────────┐
│ HTTP 메시지 │ → 응용 계층으로 전달
└─────────────────────────────────┘주요 검증:
- 목적지 포트 번호로 애플리케이션 식별
- TCP 체크섬 검증
- 시퀀스 번호 확인 (순서 보장)
- ACK 처리 (신뢰성 보장)
응용 계층 (Application Layer)
┌─────────────────────────────────────────────┐
│ 응용 계층 처리 (HTTP) │
└─────────────────────────────────────────────┘
HTTP 요청 메시지 수신
┌─────────────────────────────────────────┐
│ GET /index.html HTTP/1.1 │
│ Host: www.example.com │
│ User-Agent: Mozilla/5.0 │
│ Accept: text/html,application/xhtml+xml │
│ Accept-Language: ko-KR,ko;q=0.9 │
│ Accept-Encoding: gzip, deflate │
│ Connection: keep-alive │
└─────────────────────────────────────────┘
1단계: HTTP 메서드 확인
┌──────────────────────────────────┐
│ GET → 리소스 요청 │
│ POST → 데이터 전송 │
│ PUT → 리소스 생성/수정 │
│ DELETE → 리소스 삭제 │
└──────────────────────────────────┘
2단계: 요청 URI 파싱
┌──────────────────────────────────┐
│ /index.html │
│ → 파일 시스템 경로 매핑 │
│ → /var/www/html/index.html │
└──────────────────────────────────┘
3단계: HTTP 버전 확인
┌──────────────────────────────────┐
│ HTTP/1.1 → 지원 │
│ HTTP/2.0 → 지원 여부 확인 │
└──────────────────────────────────┘
4단계: 헤더 파싱
┌──────────────────────────────────┐
│ Host: 가상 호스트 결정 │
│ User-Agent: 브라우저 정보 │
│ Accept: 응답 형식 협상 │
│ Accept-Encoding: 압축 협상 │
│ Connection: 연결 유지 여부 │
└──────────────────────────────────┘
5단계: 파일 읽기 및 응답 생성
┌──────────────────────────────────┐
│ /var/www/html/index.html 읽기 │
│ 파일 존재? ✓ → 200 OK │
│ 파일 없음? ✗ → 404 Not Found │
└──────────────────────────────────┘
6단계: HTTP 응답 생성
┌─────────────────────────────────────────┐
│ HTTP/1.1 200 OK │
│ Date: Wed, 08 Jan 2025 10:00:00 GMT │
│ Server: Apache/2.4.41 (Ubuntu) │
│ Content-Type: text/html; charset=UTF-8 │
│ Content-Length: 1234 │
│ Connection: keep-alive │
│ │
│ <!DOCTYPE html> │
│ <html> │
│ <head><title>Example</title></head> │
│ <body><h1>Hello World!</h1></body> │
│ </html> │
└─────────────────────────────────────────┘주요 처리:
- HTTP 메서드 해석
- URI 파싱 및 파일 경로 매핑
- 헤더 파싱 및 협상
- 파일 읽기
- HTTP 응답 생성
34-3. 웹 서버의 응답 생성 및 전송
캡슐화 과정 (응답)
웹 서버가 HTTP 응답을 생성한 후, 클라이언트로 전송하기 위해 캡슐화를 수행합니다:
[응용 계층]
HTTP 응답 메시지 생성
┌─────────────────────────────────┐
│ HTTP/1.1 200 OK │
│ Content-Type: text/html │
│ Content-Length: 1234 │
│ │
│ <html>...</html> │
└─────────────────────────────────┘
↓
[전송 계층]
TCP 헤더 추가
┌───────────┬─────────────────────┐
│ TCP 헤더 │ HTTP 응답 │
│ 출발지: 80│ │
│ 목적지: │ │
│ 54321 │ │
│ ACK: 1200 │ │
└───────────┴─────────────────────┘
↓
[네트워크 계층]
IP 헤더 추가
┌──────┬──────┬──────────┐
│IP헤더│TCP헤더│HTTP 응답 │
│출발지:│ │ │
│192. │ │ │
│168. │ │ │
│10.100│ │ │
│목적지:│ │ │
│172. │ │ │
│16.0.1│ │ │
└──────┴──────┴──────────┘
↓
[데이터링크 계층]
이더넷 헤더/트레일러 추가
┌──────┬────┬────┬────┬────┐
│이더넷│IP헤더│TCP │HTTP│FCS │
│헤더 │ │헤더│응답│ │
│출발지:│ │ │ │ │
│CC:DD:│ │ │ │ │
│EE:FF:│ │ │ │ │
│00:11 │ │ │ │ │
│목적지:│ │ │ │ │
│99:AA:│ │ │ │ │
│BB:CC:│ │ │ │ │
│DD:EE │ │ │ │ │
└──────┴────┴────┴────┴────┘
↓
[물리 계층]
전기 신호로 변환 및 전송
━━━━┓ ┏━━━━┓ ┏━━━━
┗━━━━┛ ┗━━━━┛34-4. 웹 서버 소프트웨어
주요 웹 서버
Apache HTTP Server
├─ 가장 널리 사용되는 웹 서버
├─ 모듈 기반 확장 가능
├─ .htaccess 지원
├─ 안정성과 호환성
└─ MPM (Multi-Processing Module)
Nginx
├─ 고성능, 경량 웹 서버
├─ 역방향 프록시
├─ 로드 밸런서
├─ 이벤트 기반 아키텍처
└─ 적은 메모리 사용
Microsoft IIS
├─ Windows 기반 웹 서버
├─ ASP.NET 지원
├─ Active Directory 통합
└─ GUI 관리 도구
LiteSpeed
├─ Apache 호환
├─ 높은 성능
└─ 내장 캐싱
Node.js (Express)
├─ JavaScript 기반
├─ 비동기 I/O
└─ 단일 스레드 이벤트 루프웹 서버 동작 모드
Apache MPM (Multi-Processing Module):
1. Prefork MPM
┌──────────────────────────────────┐
│ 프로세스 기반 │
│ 각 요청 → 별도 프로세스 │
│ 메모리 많이 사용 │
│ 안정성 높음 │
└──────────────────────────────────┘
[요청 1] → [프로세스 1]
[요청 2] → [프로세스 2]
[요청 3] → [프로세스 3]
2. Worker MPM
┌──────────────────────────────────┐
│ 스레드 기반 │
│ 프로세스 내 여러 스레드 │
│ 메모리 효율적 │
│ 성능 우수 │
└──────────────────────────────────┘
[프로세스 1]
├─ [스레드 1] ← [요청 1]
├─ [스레드 2] ← [요청 2]
└─ [스레드 3] ← [요청 3]
3. Event MPM
┌──────────────────────────────────┐
│ 이벤트 기반 │
│ Keep-Alive 연결 효율적 처리 │
│ 높은 동시 접속 지원 │
└──────────────────────────────────┘
Nginx:
┌──────────────────────────────────┐
│ 이벤트 기반 비동기 아키텍처 │
│ 마스터 프로세스 + 워커 프로세스 │
│ 이벤트 루프로 다중 연결 처리 │
└──────────────────────────────────┘
[마스터 프로세스]
├─ [워커 1] → 이벤트 루프
│ ├─ [요청 1]
│ ├─ [요청 2]
│ └─ [요청 3]
└─ [워커 2] → 이벤트 루프
├─ [요청 4]
└─ [요청 5]34-5. 정적 라우팅과 동적 라우팅
정적 라우팅과 동적 라우팅
라우팅은 패킷을 목적지 컴퓨터까지 보낼 때 최적의 경로를 선택하여 전송하는 것을 뜻합니다.
라우팅은 크게 정적 라우팅과 동적 라우팅, 이 두 가지 방법으로 나뉩니다.
정적 라우팅 (Static Routing)
정적 라우팅은 관리자가 미리 라우팅 테이블에 경로를 수동으로 추가하는 방법입니다.
┌─────────────────────────────────────────┐
│ 정적 라우팅 특징 │
├─────────────────────────────────────────┤
│ • 관리자가 수동으로 경로 설정 │
│ • 경로 고정 │
│ • 소규모 네트워크에 적합 │
│ • 대역폭 부담 적음 │
│ • 장애 시 자동 우회 불가 │
└─────────────────────────────────────────┘정적 라우팅 예시:
네트워크 구성:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 네트워크 │─────│라우터 A │─────│라우터 B │─────목적지
│ A │ │ │ │ │
│192.168. │ │eth0: │ │eth0: │
│1.0/24 │ │192.168. │ │172.16. │
│ │ │1.1 │ │0.1 │
│ │ │eth1: │ │eth1: │
│ │ │172.16. │ │192.168. │
│ │ │0.254 │ │10.1 │
└─────────┘ └─────────┘ └─────────┘
라우터 A의 정적 라우팅 테이블:
┌──────────────┬──────────────┬──────────┬──────┐
│ 목적지 │ 넷마스크 │게이트웨이│인터페이스│
├──────────────┼──────────────┼──────────┼──────┤
│ 192.168.1.0 │ /24 │ * │ eth0 │ ← 직접 연결
│ 172.16.0.0 │ /16 │ * │ eth1 │ ← 직접 연결
│ 192.168.10.0 │ /24 │172.16.0.1│ eth1 │ ← 수동 설정
│ 0.0.0.0 │ /0 │172.16.0.1│ eth1 │ ← 기본 경로
└──────────────┴──────────────┴──────────┴──────┘정적 라우팅 설정:
# Linux
sudo ip route add 192.168.10.0/24 via 172.16.0.1 dev eth1
# 영구 설정 (Ubuntu)
# /etc/netplan/*.yaml
network:
version: 2
ethernets:
eth1:
routes:
- to: 192.168.10.0/24
via: 172.16.0.1
# Cisco 라우터
Router(config)# ip route 192.168.10.0 255.255.255.0 172.16.0.1
# Windows
route add 192.168.10.0 mask 255.255.255.0 172.16.0.1장점:
✓ 라우팅 정보 교환 없음 → 대역폭 절약
✓ CPU 사용량 적음
✓ 보안 (경로 정보 노출 없음)
✓ 예측 가능한 경로
✓ 설정 단순 (소규모 네트워크)단점:
✗ 관리자가 모든 경로 수동 설정
✗ 네트워크 변경 시 수동 업데이트 필요
✗ 장애 발생 시 자동 우회 불가
✗ 대규모 네트워크에 부적합
✗ 확장성 부족사용 시나리오:
1. 소규모 네트워크
- 라우터 2-3대
- 경로 변경 거의 없음
2. 기본 경로 (Default Route)
- 인터넷 게이트웨이
- 0.0.0.0/0 → ISP 라우터
3. 스터브 네트워크 (Stub Network)
- 하나의 경로만 존재
- 예: 지사 네트워크
4. 보안이 중요한 네트워크
- 경로 정보 노출 방지동적 라우팅 (Dynamic Routing)
동적 라우팅은 네트워크 변경을 자동으로 감지하여 라우팅 테이블을 업데이트하거나 네트워크 장애가 발생했을 때 라우터끼리 정보를 교환하여 최적의 경로로 전달하는 기능을 합니다.
┌─────────────────────────────────────────┐
│ 동적 라우팅 특징 │
├─────────────────────────────────────────┤
│ • 라우터가 자동으로 경로 학습 │
│ • 네트워크 변경 자동 감지 │
│ • 장애 시 자동 우회 │
│ • 대규모 네트워크에 적합 │
│ • 라우팅 프로토콜 사용 │
└─────────────────────────────────────────┘동적 라우팅 예시:
네트워크 구성:
┌─────────┐ ┌─────────┐ ┌─────────┐
│네트워크A│─────│라우터 A │─────│라우터 B │─────목적지
│ │ │ RIP │ │ RIP │
│ │ ┌──│ OSPF │──┬──│ OSPF │
│ │ │ └─────────┘ │ └─────────┘
└─────────┘ │ │
│ ┌─────────┐ │
└──│라우터 C │──┘
│ RIP │
│ OSPF │
└─────────┘
라우팅 프로토콜이 자동으로:
1. 인접 라우터 발견
2. 경로 정보 교환
3. 라우팅 테이블 업데이트
4. 최적 경로 계산
5. 장애 감지 및 우회주요 동적 라우팅 프로토콜:
┌──────────────────────────────────────────────────────┐
│ 동적 라우팅 프로토콜 │
├────────────┬──────────┬──────────┬──────────────────┤
│ 프로토콜 │ 타입 │ 메트릭 │ 특징 │
├────────────┼──────────┼──────────┼──────────────────┤
│ RIP │ IGP │ 홉 수 │ 소규모, 최대 │
│ (v1, v2) │ 거리벡터 │ │ 15홉 │
├────────────┼──────────┼──────────┼──────────────────┤
│ OSPF │ IGP │ 비용 │ 대규모, 빠른 │
│ │ 링크상태 │ (대역폭) │ 수렴 │
├────────────┼──────────┼──────────┼──────────────────┤
│ EIGRP │ IGP │ 복합 │ Cisco 독점, │
│ │ 하이브리드│ 메트릭 │ 빠름 │
├────────────┼──────────┼──────────┼──────────────────┤
│ BGP │ EGP │ 경로 │ 인터넷, │
│ │ 경로벡터 │ 속성 │ AS 간 라우팅 │
└────────────┴──────────┴──────────┴──────────────────┘
IGP (Interior Gateway Protocol): 내부 라우팅
EGP (Exterior Gateway Protocol): 외부 라우팅 (인터넷)RIP (Routing Information Protocol)
┌─────────────────────────────────────────┐
│ RIP 특징 │
├─────────────────────────────────────────┤
│ • 거리 벡터 알고리즘 │
│ • 메트릭: 홉 수 (최대 15) │
│ • 업데이트: 30초마다 │
│ • 소규모 네트워크 │
│ • 설정 간단 │
└─────────────────────────────────────────┘
홉 수 계산:
라우터 A → 라우터 B → 라우터 C → 목적지
홉 1 홉 2 홉 3
총 3홉
RIP 패킷:
┌──────────────┬──────┬─────────────┐
│ 목적지 │ 홉 수│ 다음 홉 │
├──────────────┼──────┼─────────────┤
│ 192.168.1.0 │ 1 │ 172.16.0.1 │
│ 192.168.2.0 │ 2 │ 172.16.0.1 │
│ 192.168.3.0 │ 3 │ 172.16.0.1 │
└──────────────┴──────┴─────────────┘RIP 설정 (Cisco):
Router(config)# router rip
Router(config-router)# version 2
Router(config-router)# network 192.168.1.0
Router(config-router)# network 172.16.0.0
Router(config-router)# no auto-summaryOSPF (Open Shortest Path First)
┌─────────────────────────────────────────┐
│ OSPF 특징 │
├─────────────────────────────────────────┤
│ • 링크 상태 알고리즘 │
│ • 메트릭: 비용 (대역폭 기반) │
│ • 빠른 수렴 │
│ • 대규모 네트워크 │
│ • Area 개념 (계층 구조) │
└─────────────────────────────────────────┘
비용 계산:
비용 = 100,000,000 / 대역폭(bps)
┌────────────┬─────────┐
│ 인터페이스 │ 비용 │
├────────────┼─────────┤
│ 10 Gbps │ 10 │
│ 1 Gbps │ 100 │
│ 100 Mbps │ 1000 │
│ 10 Mbps │ 10000 │
└────────────┴─────────┘
OSPF 영역 (Area):
┌──────────────────────────────────┐
│ Area 0 (Backbone) │
│ ┌─────────────┐ │
│ │ ABR │ │
│ └─────────────┘ │
│ │ │ │
│ ┌────────┘ └────────┐ │
│ │ │ │
│ ┌──▼────┐ ┌────▼──┐ │
│ │Area 1 │ │Area 2 │ │
│ └───────┘ └───────┘ │
└──────────────────────────────────┘
ABR: Area Border RouterOSPF 설정 (Cisco):
Router(config)# router ospf 1
Router(config-router)# network 192.168.1.0 0.0.0.255 area 0
Router(config-router)# network 172.16.0.0 0.0.255.255 area 0BGP (Border Gateway Protocol)
┌─────────────────────────────────────────┐
│ BGP 특징 │
├─────────────────────────────────────────┤
│ • 경로 벡터 프로토콜 │
│ • 인터넷 라우팅 프로토콜 │
│ • AS (Autonomous System) 간 라우팅 │
│ • 정책 기반 라우팅 │
│ • 매우 큰 라우팅 테이블 (80만+ 경로) │
└─────────────────────────────────────────┘
AS (자율 시스템):
┌─────────────┐ ┌─────────────┐
│ AS 100 │ │ AS 200 │
│ (ISP A) │─────│ (ISP B) │
│ BGP │ BGP │ BGP │
└─────────────┘ └─────────────┘
│ │
│ │
┌──────▼───────┐ ┌─────▼──────┐
│ AS 300 │ │ AS 400 │
│ (기업 네트워크)│ │ (기업 네트워크)│
└──────────────┘ └────────────┘장점:
✓ 자동 경로 학습
✓ 장애 시 자동 우회
✓ 최적 경로 선택
✓ 대규모 네트워크에 적합
✓ 확장성 우수단점:
✗ CPU, 메모리 사용량 높음
✗ 대역폭 사용 (라우팅 정보 교환)
✗ 설정 복잡
✗ 수렴 시간 (RIP의 경우 느림)정적 vs 동적 라우팅 비교
┌────────────┬─────────────────┬─────────────────┐
│ 특성 │ 정적 라우팅 │ 동적 라우팅 │
├────────────┼─────────────────┼─────────────────┤
│ 설정 │ 수동 │ 자동 │
│ 관리 부담 │ 높음 │ 낮음 │
│ 확장성 │ 낮음 │ 높음 │
│ 장애 대응 │ 수동 │ 자동 │
│ 대역폭 │ 사용 안 함 │ 사용함 │
│ CPU 사용 │ 낮음 │ 높음 │
│ 보안 │ 높음 │ 중간 │
│ 적합 규모 │ 소규모 │ 대규모 │
└────────────┴─────────────────┴─────────────────┘
사용 조합:
┌──────────────────────────────────────┐
│ 일반적으로 혼용 │
├──────────────────────────────────────┤
│ • 내부 네트워크: 동적 라우팅 (OSPF) │
│ • 기본 경로: 정적 라우팅 │
│ • 스터브 네트워크: 정적 라우팅 │
│ • ISP 연결: BGP (동적) │
└──────────────────────────────────────┘34-6. 라우팅 테이블 확인
라우팅 테이블 명령어
# Linux - ip route
ip route show
# 출력 예시
default via 192.168.1.1 dev eth0 proto static
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
192.168.10.0/24 via 172.16.0.2 dev eth1 proto static
# 각 필드 설명:
# default: 기본 경로 (0.0.0.0/0)
# via: 게이트웨이 (다음 홉)
# dev: 네트워크 인터페이스
# proto: 경로 출처 (static, kernel, dhcp 등)
# scope: 경로 범위 (link, host, global)
# src: 출발지 IP 주소
# Linux - route -n
route -n
# 출력 예시
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 172.16.0.2 255.255.255.0 UG 0 0 0 eth1
# Flags:
# U: Up (경로 활성)
# G: Gateway (게이트웨이 사용)
# H: Host (호스트 경로)
# Windows - route print
route print
# Cisco - show ip route
Router# show ip route
# 출력 예시
Codes: C - connected, S - static, R - RIP, O - OSPF, B - BGP
Gateway of last resort is 172.16.0.254 to network 0.0.0.0
C 192.168.1.0/24 is directly connected, GigabitEthernet0/0
S 192.168.10.0/24 [1/0] via 172.16.0.2
O 10.0.0.0/8 [110/20] via 172.16.0.1, 00:10:00, GigabitEthernet0/1
S* 0.0.0.0/0 [1/0] via 172.16.0.254
# [AD/Metric]
# AD: Administrative Distance (관리 거리, 신뢰도)
# Metric: 메트릭 (비용)Administrative Distance (관리 거리)
여러 라우팅 프로토콜이 동일한 목적지에 대한 경로를 제공할 때, 어떤 경로를 선택할지 결정하는 값:
┌─────────────────┬────┐
│ 경로 출처 │ AD │
├─────────────────┼────┤
│ 직접 연결 │ 0 │ ← 가장 신뢰
│ 정적 라우트 │ 1 │
│ EIGRP (내부) │ 90 │
│ OSPF │110 │
│ RIP │120 │
│ EIGRP (외부) │170 │
│ BGP (외부) │200 │
│ 알 수 없음 │255 │ ← 사용 안 함
└─────────────────┴────┘
낮을수록 우선순위가 높음정리
웹 서버의 데이터 처리
물리 계층:
- 전기 신호를 디지털 데이터로 변환
- NIC에서 처리
데이터링크 계층:
- 목적지 MAC 주소 확인
- FCS 오류 검사
- 이더넷 헤더/트레일러 제거
네트워크 계층:
- 목적지 IP 주소 확인
- IP 헤더 체크섬 검증
- TTL 확인
- IP 헤더 제거
전송 계층:
- 목적지 포트 번호로 애플리케이션 식별
- TCP 체크섬 검증
- 시퀀스 번호 확인
- ACK 처리
- TCP 헤더 제거
응용 계층:
- HTTP 메시지 파싱
- 요청 처리
- 응답 생성라우팅 방식
정적 라우팅:
장점:
- 대역폭 사용 없음
- CPU 부하 낮음
- 보안 우수
단점:
- 수동 설정
- 확장성 부족
- 장애 대응 수동
사용:
- 소규모 네트워크
- 기본 경로
- 스터브 네트워크
동적 라우팅:
장점:
- 자동 경로 학습
- 장애 자동 우회
- 확장성 우수
단점:
- 대역폭 사용
- CPU 부하 높음
- 설정 복잡
프로토콜:
- RIP: 소규모, 홉 수
- OSPF: 대규모, 비용
- BGP: 인터넷, AS 간관련 문서:
- 32. 랜카드에서의 데이터 전달과 처리 - 캡슐화 과정
- 33. 스위치와 라우터에서의 데이터 전달과 처리 - 라우팅 테이블
- 29. 웹 서버의 구조 - HTTP 프로토콜
- 28. 응용 계층의 역할 - 응용 계층 프로토콜