🚚 전송계층 완전정복 - 택배로 이해하기

📑 목차

• 전송계층 기본
• TCP vs UDP
• 3-way Handshake
• 포트 번호
• QUIC 프로토콜
• 실전 활용

---

1. 전송계층이란? - 택배 서비스

핵심 개념

전송계층은 택배 회사와 같습니다. 네트워크 계층이 “주소”를 찾아준다면, 전송계층은 “어떻게 안전하게 배송할지” 결정합니다.

🏢 전송계층의 역할

애플리케이션 ← 선물 받는 친구
     ↑
전송계층 ← 택배 회사 (TCP/UDP)
     ↑  
네트워크 계층 ← 도로/길찾기 (IP)

📋 주요 서비스

서비스	택배 비유	기술적 설명
신뢰성	등기우편 (분실 시 재발송)	에러 검출, 재전송
순서 제어	번호표 순서 배송	패킷 순서 보장
흐름 제어	받는 창고 크기 확인	수신자 버퍼 관리
혼잡 제어	도로 상황 보고 속도 조절	네트워크 부하 관리

---

2. TCP vs UDP - 등기우편 vs 퀵서비스

쉬운 구분법

TCP = 꼼꼼한 등기우편 / UDP = 빠른 오토바이 퀵

🚛 TCP (꼼꼼이 등기우편)

특징

📦 연결형 서비스
✅ "배송 시작합니다!" (연결 설정)
✅ "1번 물건 받았습니다!" (확인 응답)  
✅ "2번 물건 못 받았어요!" (재전송 요청)
✅ "배송 완료했습니다!" (연결 종료)

💻 실제 동작

# TCP 연결 확인
ss -tuln | grep :80
# LISTEN 상태 확인 가능
 
# 웹 브라우저 → 웹 서버
curl -v http://google.com
# Connection established, data transfer, connection closed

📊 TCP 헤더 구조

┌─────────┬─────────┬─────────┬─────────┬─────────┐
│ 포트번호 │ 순서번호 │ 확인번호 │  플래그  │  윈도우  │
│ (16bit) │ (32bit) │ (32bit) │ (8bit)  │ (16bit) │
└─────────┴─────────┴─────────┴─────────┴─────────┘

🏍️ UDP (빠른 오토바이 퀵)

특징

📦 비연결형 서비스  
🚀 "던지고 간다!" (연결 설정 없음)
❌ 확인 안함 (받았는지 모름)
⚡ 빠르다 (오버헤드 최소)
🎯 실시간성 중요할 때 사용

💻 실제 동작

# UDP 패킷 전송 (DNS 조회)
dig @8.8.8.8 google.com
# 한 번 보내고 응답만 기다림
 
# 비디오 스트리밍
ffmpeg -i input.mp4 -f rtp udp://127.0.0.1:5004

📊 언제 어떤 것을 사용할까?

상황	선택	이유	예시
파일 다운로드	TCP	하나라도 깨지면 안됨	HTTP, HTTPS
화상 통화	UDP	약간 끊어져도 빠르게	Zoom, Discord
온라인 게임	UDP	지연시간이 생명	FPS 게임
이메일	TCP	정확해야 함	SMTP

---

3. 3-way Handshake - 배송 전 확인 절차

실제 상황

친구와 전화 통화를 시작할 때를 생각해보세요!

📞 3단계 연결 과정

클라이언트          서버
    │               │
    │──── SYN ────→ │  1단계: "여보세요?"
    │               │
    │←─ SYN+ACK ──  │  2단계: "네, 안녕하세요!"  
    │               │
    │──── ACK ────→ │  3단계: "좋아, 이제 대화하자!"
    │               │
    │═══ DATA ═══   │  연결 완성! 데이터 전송 시작

💻 실제 패킷 캡처

# tcpdump로 3-way handshake 확인
sudo tcpdump -i any port 80 -nn
 
# 결과 예시:
# 12:34:56 IP 192.168.1.100.12345 > 93.184.216.34.80: Flags [S]
# 12:34:56 IP 93.184.216.34.80 > 192.168.1.100.12345: Flags [S.]  
# 12:34:56 IP 192.168.1.100.12345 > 93.184.216.34.80: Flags [.]

🚨 연결 실패 시나리오

1. 서버 다운 (RST 응답)

클라이언트          서버
    │               │
    │──── SYN ────→ │  
    │               │
    │←─── RST ────  │  "서버가 거부합니다"

2. 방화벽 차단 (응답 없음)

클라이언트          방화벽         서버
    │               │              │
    │──── SYN ────→ │ [차단] ────×  │
    │               │              │
    │     (타임아웃)                │  "응답이 없습니다"

---

4. 포트 번호 - 아파트 호수

포트 번호 개념

IP 주소가 **“아파트 동”**이라면, 포트 번호는 **“몇 호”**입니다.

🏠 포트 번호 체계

잘 알려진 포트 (0-1023) - VIP층

22   ← SSH (서버 관리용 뒷문)
53   ← DNS (주소 변환 서비스)  
80   ← HTTP (일반 웹사이트)
443  ← HTTPS (보안 웹사이트)
3306 ← MySQL (데이터베이스)
5432 ← PostgreSQL
6379 ← Redis  

등록된 포트 (1024-49151) - 일반층

3000  ← Node.js 개발 서버
8080  ← Tomcat, 개발용 HTTP
8443  ← 대안 HTTPS
9000  ← PHP-FPM

동적 포트 (49152-65535) - 임시 사용

# 클라이언트가 연결할 때 임시로 할당받는 포트
netstat -an | grep ESTABLISHED
# 192.168.1.100:52341 → google.com:443

💻 포트 확인 실습

현재 사용 중인 포트 확인

# 리스닝 포트 확인
ss -tuln
# 또는
netstat -tuln
 
# 특정 포트 사용 프로세스 확인  
lsof -i :8080
sudo fuser 8080/tcp

포트 스캔 (보안 점검)

# nmap으로 포트 스캔
nmap -p 1-1000 localhost
 
# 특정 포트 연결 테스트
nc -zv google.com 80  # 연결 성공
nc -zv google.com 23  # 연결 실패

---

5. 현대의 배송 혁신 - QUIC 📦⚡

QUIC이란?

**“UDP의 속도 + TCP의 신뢰성”**을 결합한 차세대 프로토콜입니다.

🚀 QUIC의 혁신

기존 방식 (HTTP/2 over TCP)

연결 설정: TCP 3-way + TLS handshake = 최소 2 RTT
데이터 전송: Head-of-line blocking 발생

QUIC 방식 (HTTP/3)

연결 설정: 0-1 RTT (매우 빠름!)
데이터 전송: 스트림별 독립적 전송

💻 QUIC 실제 확인

Chrome에서 QUIC 사용 확인

# Chrome 주소창에 입력
chrome://net-internals/#quic
 
# 또는 개발자 도구에서
# Network 탭 → Protocol 열에서 "h3" 확인

QUIC 지원 사이트 예시

• Google 서비스: YouTube, Gmail, Google Search
• Cloudflare: 대부분의 CDN 서비스
• Facebook: Instagram, WhatsApp

---

🎯 실전 시나리오

💻 웹 개발자 시나리오

API 응답 속도 최적화

상황: REST API 응답이 느려서 사용자 불만 증가

1단계 - 연결 분석

curl -w "%{time_connect}, %{time_total}\n" https://api.company.com
# 0.150, 1.200 (연결: 150ms, 전체: 1200ms)

2단계 - 문제 식별

• 매번 새로운 TCP 연결 생성 (3-way handshake 오버헤드)
• HTTP/1.1 사용으로 인한 대기시간

3단계 - 해결방안

// Keep-Alive 연결 재사용
const agent = new https.Agent({
  keepAlive: true,
  maxSockets: 10
});
 
// HTTP/2 클라이언트 사용
const http2 = require('http2');
const client = http2.connect('https://api.company.com');

🛡️ 보안 엔지니어 시나리오

포트 스캔 공격 탐지

상황: 서버에 대한 포트 스캔 공격 감지

탐지 방법:

# 짧은 시간 내 다양한 포트 연결 시도 감지
netstat -an | grep SYN_RECV | wc -l
 
# 방화벽 로그 분석
tail -f /var/log/iptables.log | grep "DPT="

대응 방안:

# fail2ban으로 자동 차단
# /etc/fail2ban/jail.local
[port-scan]
enabled = true
filter = port-scan
action = iptables[name=portscan, protocol=tcp, port=1-65535]
logpath = /var/log/syslog
maxretry = 5
bantime = 3600

☁️ 클라우드 엔지니어 시나리오

Kubernetes 서비스 포트 설정

상황: 마이크로서비스 간 통신 설정

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80        # 서비스 포트
      targetPort: 8080 # 컨테이너 포트
      protocol: TCP
  type: ClusterIP

포트 확인:

# 서비스 포트 확인
kubectl get svc web-service
 
# Pod 포트 확인  
kubectl get pods -o wide
kubectl exec -it web-pod -- netstat -tuln

---

🔍 핵심 Takeaway

⭐ 반드시 기억할 3가지

1. TCP = 신뢰성 중심 (파일, 웹, 이메일)
2. UDP = 속도 중심 (게임, 스트리밍, DNS)
3. 포트 = 서비스 구분 (같은 서버에서 다양한 서비스)

🚀 실무 활용 팁

# 네트워크 상태 점검 명령어
ss -tuln           # 리스닝 포트
ss -tun            # 활성 연결  
netstat -i         # 인터페이스 통계
tcpdump -i any     # 패킷 캡처

📈 성능 최적화 포인트

1. 연결 재사용: Keep-Alive, Connection Pooling
2. 프로토콜 업그레이드: HTTP/2, HTTP/3 (QUIC)
3. 적절한 프로토콜 선택: 용도에 맞는 TCP/UDP 선택

추가 학습 방향

• 심화: Wireshark로 패킷 분석 실습
• 성능: TCP 윈도우 크기 튜닝
• 보안: 포트 보안 및 방화벽 설정
• 최신: QUIC/HTTP3 적용 사례 연구