OSI 7계층, TCP 핸드셰이크, TLS, NAT — 네트워크 심화 개념

계층별로 동작하는 대상

- ICMP (ping): L3
- 포트 기반 필터링 (방화벽): L4
- HTTP 요청/응답: L7
- 로드밸런서: L4 (NLB) vs L7 (ALB)

1. URL 파싱
   브라우저가 https://example.com/api를 프로토콜, 호스트, 경로로 분리

2. DNS 조회
   브라우저 캐시 → OS 캐시 → DNS Resolver → Root → TLD → 권한 DNS
   → IP 주소 획득 (예: 93.184.216.34)

3. TCP 연결 (3-way Handshake)
   SYN → SYN+ACK → ACK
   → 연결 수립 (ESTABLISHED)

4. TLS 핸드셰이크 (HTTPS인 경우)
   ClientHello → ServerHello + 인증서 → 키 교환 → 세션 키 생성
   → 암호화 채널 확립

5. HTTP 요청 전송
   GET /api HTTP/1.1
   Host: example.com

6. 서버 처리 + HTTP 응답
   HTTP/1.1 200 OK
   Content-Type: application/json
   ...

7. 브라우저 렌더링
   HTML 파싱 → DOM 생성 → CSS 적용 → JS 실행 → 화면 표시

8. 연결 유지 또는 종료
   Keep-Alive → 재사용 / 또는 4-way Handshake로 종료

A (10.0.0.5) → "10.0.0.10의 MAC 주소가 뭐야?" (브로드캐스트)
B (10.0.0.10) → "내 MAC은 aa:bb:cc:dd:ee:ff야" (유니캐스트 응답)

1. A가 10.0.0.10에 패킷을 보내려 함
2. ARP 캐시에 10.0.0.10의 MAC이 없음
3. ARP Request 브로드캐스트 (ff:ff:ff:ff:ff:ff)
4. 10.0.0.10이 자신의 MAC으로 ARP Reply
5. A가 ARP 캐시에 저장 → 이후 직접 통신

A (10.0.0.5) → B (10.0.1.20) 로 보내려면:
- 목적지 IP: 10.0.1.20 (다른 서브넷)
- 목적지 MAC: 게이트웨이(라우터)의 MAC ← ARP로 조회
- 라우터가 받아서 다음 홉으로 전달

# ARP 캐시 확인
arp -a
ip neigh show

# ARP 캐시 삭제 (디버깅용)
sudo ip neigh flush all

클라이언트                     서버
    │── SYN (seq=x) ───────────→│
    │←─ SYN+ACK (seq=y, ack=x+1)│
    │── ACK (ack=y+1) ──────────→│
    │     → ESTABLISHED

클라이언트                     서버
    │── FIN ────────────────────→│
    │←─ ACK ─────────────────────│
    │   (서버가 남은 데이터 전송)    │
    │←─ FIN ─────────────────────│
    │── ACK ────────────────────→│
    │     → 연결 종료

# TIME_WAIT 소켓 수 확인
ss -s
netstat -an | grep TIME_WAIT | wc -l

1. Slow Start (느린 시작)
   - 초기 cwnd(IW)는 RFC 3390에서 2~4 세그먼트, RFC 6928에서 10 세그먼트를 제안
   - ACK를 받을 때마다 cwnd를 늘려 RTT마다 약 2배로 증가
   - ssthresh(임계값)에 도달하면 → Congestion Avoidance로 전환

2. Congestion Avoidance (혼잡 회피)
   - cwnd를 RTT당 약 1 SMSS씩 증가 (선형 증가 = AIMD의 AI)
   - 패킷 유실 감지 시 → ssthresh를 줄이고 cwnd 감소

3. Fast Retransmit
   - 중복 ACK 3번 수신 → 타임아웃 기다리지 않고 즉시 재전송

4. Fast Recovery
   - RFC 5681 기준 ssthresh = max(FlightSize/2, 2×SMSS), cwnd = ssthresh + 3×SMSS
   - 재전송 타임아웃(RTO) 시: cwnd를 1 SMSS까지 줄이고 Slow Start부터 다시

정상: cwnd를 조금씩 늘림 (+1 MSS per RTT)
유실: cwnd를 절반으로 줄임 (×0.5)

→ 톱니바퀴 모양 그래프가 그려짐

# 현재 사용 중인 혼잡 제어 알고리즘 확인
sysctl net.ipv4.tcp_congestion_control

# 변경
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

이더넷 프레임:
[이더넷 헤더 14B] [IP 헤더 20B] [TCP 헤더 20B] [데이터 ≤ 1460B] [FCS 4B]
                                                 └── MSS
                  └────────────── MTU (1500B) ───────────────────┘

1. VPN/터널링: 원본 패킷에 터널 헤더가 추가됨
   예: IPsec → 모드와 암호 스위트에 따라 오버헤드가 달라짐 → 유효 MTU 감소

2. 컨테이너 오버레이 네트워크 (VXLAN)
   VXLAN 캡슐화는 50바이트를 추가하므로 내부 인터페이스의 유효 MTU가 그만큼 줄어듦

3. 클라우드 환경별 MTU 상한
   트래픽 종류에 따라 상한이 다름
   - 1500: 인터넷 게이트웨이, VPN 연결, 리전 간 트래픽(Transit Gateway 미사용)
   - 8500: 리전 간 VPC 피어링
   - 9001: 현재 세대 인스턴스의 VPC 내부 점보 프레임

# Path MTU 확인 (DF 비트 설정하여 테스트)
ping -M do -s 1472 target-ip    # Linux
ping -D -s 1472 target-ip       # macOS

# 1472 + 28 (IP+ICMP 헤더) = 1500 → 통과하면 MTU ≥ 1500
# 안 되면 -s 값을 줄여가며 최대 MTU 탐색

# 인터페이스 MTU 확인/변경
ip link show eth0
sudo ip link set eth0 mtu 1450

연결 비용:
- TCP 3-way Handshake: 1 RTT
- TLS Handshake: 1~2 RTT
- 합계: 2~3 RTT를 매 요청마다 소비

계산 예시: RTT가 50ms인 경우 → 2~3 RTT = 매 요청마다 100~150ms 오버헤드

기존 (HTTP/1.0):
  연결 → 요청 → 응답 → 끊기 → 연결 → 요청 → 응답 → 끊기

Keep-Alive (HTTP/1.1 기본):
  연결 → 요청 → 응답 → 요청 → 응답 → ... → 타임아웃 후 끊기

[App] ←→ [Connection Pool]  ←→ [DB]
         미리 연결 생성 + 반납 후 재사용

HTTP/1.1: 하나의 연결에서 요청은 순차적 (Head-of-Line Blocking)
HTTP/2:   하나의 연결에서 여러 요청을 동시에 (스트림 기반)
HTTP/3:   QUIC (UDP 기반) → 연결 수립 0-RTT 가능

# nginx keepalive 설정
upstream backend {
    server 10.0.0.10:8080;
    keepalive 32;    # 백엔드와의 연결 풀 크기
}

# Node.js HTTP agent
const agent = new http.Agent({
    keepAlive: true,
    maxSockets: 50,
    keepAliveMsecs: 30000
});

[PC: 192.168.0.10:54321] → [NAT Gateway] → [인터넷: 203.0.113.5:10001]
                            사설 IP:포트 → 공인 IP:포트

AWS:
[Private Subnet EC2/Pod] → [NAT Gateway (EIP)] → [인터넷]

- 프라이빗 서브넷의 아웃바운드 트래픽은 라우트 테이블이 가리키는 NAT 장치를 거침
- 반대로 외부→내부는 ALB/NLB가 담당
- AWS 문서는 AZ 단위 장애 영향을 줄이기 위해 가용 영역마다 NAT Gateway를 두는 구성을 설명함

Pod IP (10.244.1.5) → Node의 IP로 SNAT → 외부

- Pod에서 외부 API 호출 시 외부에서 보이는 IP = Node IP (또는 NAT GW IP)
- externalTrafficPolicy: Local → 클라이언트 원본 IP 보존

# NAT 규칙 확인
iptables -t nat -L -n -v
# 현재 공인 IP 확인
curl -s ifconfig.me

클라이언트                           서버
    │── ClientHello + 키 공유 ──────→│  (1 RTT)
    │←─ ServerHello + 인증서 + Finished│
    │── Finished ──────────────────→│
    │     → 암호화 통신 시작

Root CA (브라우저/OS에 내장)
  └── Intermediate CA
         └── 서버 인증서 (example.com)

일반 TLS: 클라이언트가 서버를 검증
mTLS:    서버도 클라이언트를 검증 (양방향)

→ 서비스 메시(Istio, Linkerd)에서 Pod 간 통신 인증에 사용

# 인증서 체인 + 만료일 확인
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

# TLS 버전 확인
curl -vI https://example.com 2>&1 | grep "SSL connection"

# 인증서 디버깅
openssl s_client -connect example.com:443 -showcerts

# 로컬 포트포워딩
# 내 PC:3306 → jump-server 경유 → db-server:3306
ssh -L 3306:db-server:3306 user@jump-server

# 이후 localhost:3306으로 DB 접속
mysql -h 127.0.0.1 -P 3306

# 다이나믹 포트포워딩 (SOCKS 프록시)
ssh -D 8080 user@jump-server
# 브라우저 프록시를 localhost:8080으로 설정

┌──────────── VPC: 10.0.0.0/16 ────────────┐
│                                           │
│  Public Subnet (10.0.1.0/24)              │
│  → ALB, NAT Gateway, Bastion             │
│                    │                      │
│  Private Subnet (10.0.10.0/24)            │
│  → App Server, EKS Pod                   │
│                    │                      │
│  DB Subnet (10.0.20.0/24)                 │
│  → RDS, ElastiCache                      │
│                                           │
└───────────────────────────────────────────┘

AZ-a: Public-a, Private-a, DB-a
AZ-b: Public-b, Private-b, DB-b
(필요 시 AZ-c도)

→ 하나의 AZ 장애 시에도 서비스 유지

VPC Peering: VPC 간 직접 연결 (1:1, 비전이적)
Transit Gateway: 허브 역할. 여러 VPC + VPN을 중앙 연결

TTL: 리졸버가 응답을 캐시에 유지할 수 있는 시간(초)
캐시된 TTL이 남아 있는 동안 리졸버는 권한 서버에 다시 질의하지 않음
→ 레코드를 변경해도 TTL이 만료되기 전까지 이전 값이 반환될 수 있음

example.com → Primary: Seoul ALB (헬스체크 OK)
            → Secondary: Tokyo ALB (Primary 실패 시 전환)

헬스체크 실패 → DNS가 자동으로 Secondary IP 반환

글로벌 라우팅: DNS Latency-based → 가장 가까운 리전
리전 내 분산:  ALB/NLB → 여러 인스턴스/Pod

예:
미국 사용자 → us-east-1 ALB → Pod A, B, C
한국 사용자 → ap-northeast-2 ALB → Pod D, E, F