개발자를 위한 네트워크 기초 완전 정복: TCP/IP, HTTP, DNS, TLS부터 gRPC, WebSocket까지

• 1. 왜 개발자에게 네트워크 지식이 필수인가
  • 면접에서 빠지지 않는 단골 주제
  • 디버깅과 성능 최적화의 핵심
  • 아키텍처 설계의 기반
  • OSI 7계층 vs TCP/IP 4계층 비교
• 2. TCP vs UDP 심화
  • TCP: 신뢰성 있는 연결 지향 프로토콜
    • 3-Way Handshake (연결 수립)
    • 4-Way Termination (연결 종료)
    • 흐름 제어 (Flow Control) — Sliding Window
    • 혼잡 제어 (Congestion Control)
    • Nagle 알고리즘과 TCP_NODELAY
  • UDP: 비연결형 프로토콜
  • TCP vs UDP 비교표
• 3. IP, 서브넷, 라우팅
  • IPv4 vs IPv6 비교
  • CIDR 표기법과 서브넷 마스크
  • NAT(Network Address Translation)
  • Docker/K8s 네트워킹과의 연결
• 4. DNS 완전 정복
  • DNS 질의 과정
  • DNS 레코드 종류
  • TTL과 캐싱 전략
  • DNS over HTTPS (DoH) / DNS over TLS (DoT)
  • dig/nslookup 실전 명령어
• 5. HTTP 진화: 1.0 에서 1.1, 2, 3까지
  • HTTP/1.0: 요청마다 새 연결
  • HTTP/1.1: Keep-Alive와 파이프라이닝
  • HTTP/2: 멀티플렉싱 혁명
  • HTTP/3: QUIC (UDP 기반)
  • HTTP 버전 비교표
• 6. HTTPS와 TLS 1.3
  • 대칭 vs 비대칭 암호화
  • TLS 1.2 vs TLS 1.3 핸드셰이크
  • 인증서와 CA
  • OCSP Stapling
  • mTLS (상호 TLS 인증)
• 7. REST vs GraphQL vs gRPC vs WebSocket
  • REST (Representational State Transfer)
  • GraphQL
  • gRPC
  • WebSocket
  • SSE (Server-Sent Events)
  • 통신 방식 비교표
• 8. CDN과 로드 밸런싱
  • CDN 동작 원리
  • CDN 비교
  • 로드 밸런서: L4 vs L7
  • 로드 밸런싱 알고리즘
  • 주요 로드 밸런서 제품
• 9. 실전 디버깅 도구
  • curl — HTTP 요청의 스위스 아미 나이프
  • tcpdump — 패킷 캡처
  • netstat / ss / lsof — 연결 상태 확인
  • traceroute / mtr — 경로 추적
  • Chrome DevTools Network 탭 활용
• 10. 면접 예상 질문 15선
  • 기본 개념
  • 심화 질문
  • 설계/실무 질문
• 11. 퀴즈
• 12. 참고 자료
  • 공식 문서 및 RFC
  • 서적
  • 온라인 자료

1. 왜 개발자에게 네트워크 지식이 필수인가

면접에서 빠지지 않는 단골 주제

개발자 면접에서 "브라우저에 URL을 입력하면 무슨 일이 일어나는가?" 라는 질문은 거의 단골입니다. 이 질문 하나에 DNS, TCP, TLS, HTTP, 라우팅, 로드 밸런싱, 렌더링까지 전부 들어갑니다. 네트워크를 모르면 이 질문에 대한 깊이 있는 답변이 불가능합니다.

디버깅과 성능 최적화의 핵심

API가 느린데 원인을 모르겠다면? 네트워크 레벨에서 봐야 합니다. DNS 해석에 500ms가 걸리는지, TCP 연결 수립에 시간이 걸리는지, TLS 핸드셰이크가 병목인지, 아니면 서버 응답 자체가 느린지. 네트워크를 이해하면 curl -w 하나로 어디가 병목인지 즉시 파악할 수 있습니다.

아키텍처 설계의 기반

마이크로서비스 간 통신에 REST를 쓸지 gRPC를 쓸지, WebSocket이 필요한지 SSE로 충분한지, CDN을 어디에 배치할지 — 이 모든 판단의 기반이 네트워크 지식입니다.

OSI 7계층 vs TCP/IP 4계층 비교

실무에서는 OSI 7계층보다 TCP/IP 4계층을 더 자주 사용합니다. 아래 비교표를 참고하세요.

면접 팁: "OSI 7계층을 설명하세요"라는 질문이 나오면, TCP/IP 4계층과의 매핑까지 함께 설명하면 차별화됩니다.

2. TCP vs UDP 심화

TCP: 신뢰성 있는 연결 지향 프로토콜

TCP(Transmission Control Protocol)는 데이터의 순서 보장, 손실 복구, 흐름 제어를 제공하는 프로토콜입니다.

3-Way Handshake (연결 수립)

클라이언트                    서버
    |--- SYN (seq=x) -------->|
    |<-- SYN-ACK (seq=y, ack=x+1) ---|
    |--- ACK (ack=y+1) ------>|
    |     연결 수립 완료        |

1. SYN: 클라이언트가 서버에 연결 요청 (시퀀스 번호 x 전송)
2. SYN-ACK: 서버가 요청을 수락하고 자신의 시퀀스 번호 y와 함께 응답
3. ACK: 클라이언트가 확인 응답을 보내고 연결 수립 완료

4-Way Termination (연결 종료)

클라이언트                    서버
    |--- FIN ----------------->|
    |<-- ACK ------------------|
    |<-- FIN ------------------|
    |--- ACK ----------------->|
    |   TIME_WAIT (2MSL)       |

연결 종료 시 4단계가 필요한 이유는 양방향 스트림을 각각 독립적으로 종료하기 때문입니다. TIME_WAIT 상태는 지연된 패킷이 새 연결에 영향을 주지 않도록 보호하는 역할을 합니다.

흐름 제어 (Flow Control) — Sliding Window

수신자의 버퍼가 넘치지 않도록 **윈도우 크기(Window Size)**를 통해 한 번에 보낼 수 있는 데이터 양을 조절합니다.

Sender Window:
[Sent & ACKed] [Sent, Not ACKed] [Can Send] [Cannot Send]
               |<--- Window Size --->|

수신자는 ACK에 자신의 수신 윈도우(rwnd) 값을 포함하여 송신자에게 알려줍니다.

혼잡 제어 (Congestion Control)

네트워크 혼잡을 감지하고 전송 속도를 조절하는 메커니즘입니다.

• Slow Start: cwnd(congestion window)를 1 MSS에서 시작하여 지수적으로 증가
• Congestion Avoidance (AIMD): ssthresh 도달 후 선형적으로 증가, 패킷 손실 시 절반으로 감소
• Fast Retransmit: 3개의 중복 ACK 수신 시 타임아웃 전에 재전송
• Fast Recovery: Fast Retransmit 이후 Slow Start가 아닌 Congestion Avoidance로 진입

cwnd
 ^
 |        /\
 |       /  \     /\
 |      /    \   /  \    /
 |     /      \ /    \  /
 |    /        X      \/
 |   /    ssthresh
 |  /
 | /  Slow Start
 |/__________________ time

Nagle 알고리즘과 TCP_NODELAY

Nagle 알고리즘은 작은 패킷을 모아서 한 번에 전송하여 네트워크 효율을 높입니다. 하지만 실시간 애플리케이션(게임, 트레이딩)에서는 지연이 문제가 됩니다.

// Nagle 알고리즘 비활성화
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));

UDP: 비연결형 프로토콜

UDP(User Datagram Protocol)는 연결 설정 없이 데이터그램을 전송합니다. 신뢰성은 없지만, 오버헤드가 적고 빠릅니다.

UDP 사용 사례:

• DNS 질의: 단일 요청-응답, 빠른 응답이 중요
• 온라인 게임: 약간의 패킷 손실보다 낮은 지연이 중요
• 실시간 스트리밍: 음성/영상에서 재전송은 의미 없음
• QUIC (HTTP/3): UDP 위에 신뢰성을 자체 구현

TCP vs UDP 비교표

3. IP, 서브넷, 라우팅

IPv4 vs IPv6 비교

CIDR 표기법과 서브넷 마스크

CIDR(Classless Inter-Domain Routing)은 IP 주소 뒤에 슬래시와 프리픽스 길이를 붙여 네트워크를 표현합니다.

192.168.1.0/24
├── 네트워크 부분: 192.168.1 (24비트)
└── 호스트 부분: 0~255 (8비트, 256개 주소 중 사용 가능 254개)

10.0.0.0/16
├── 네트워크 부분: 10.0 (16비트)
└── 호스트 부분: 0.0~255.255 (16비트, 65,536개 주소)

자주 사용하는 CIDR:

NAT(Network Address Translation)

사설 IP 주소를 공인 IP 주소로 변환하는 기술입니다.

사설 네트워크                     NAT 라우터              인터넷
[192.168.1.10] ---+
[192.168.1.11] ---+--- [NAT] --- [203.0.113.1] --- [서버]
[192.168.1.12] ---+

사설 IP 대역 (RFC 1918):

• 10.0.0.0/8 (10.0.0.0 ~ 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 ~ 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 ~ 192.168.255.255)

Docker/K8s 네트워킹과의 연결

Docker 네트워킹:

• bridge: 기본 네트워크, 컨테이너 간 통신
• host: 호스트 네트워크 직접 사용
• overlay: 다중 호스트 간 컨테이너 통신 (Docker Swarm)
• none: 네트워크 비활성화

Kubernetes 네트워킹 원칙:

1. 모든 Pod는 고유한 IP를 가진다
2. 모든 Pod는 NAT 없이 다른 Pod와 통신할 수 있다
3. 모든 Node의 에이전트는 모든 Pod와 통신할 수 있다

K8s 클러스터
┌─────────────────────────────────────┐
│  Node 1                Node 2       │
│  ┌─────────┐          ┌─────────┐   │
│  │ Pod A   │          │ Pod C   │   │
│  │ 10.1.1.2│◄────────►│ 10.1.2.3│   │
│  ├─────────┤          ├─────────┤   │
│  │ Pod B   │          │ Pod D   │   │
│  │ 10.1.1.3│          │ 10.1.2.4│   │
│  └─────────┘          └─────────┘   │
│       CNI Plugin (Calico/Flannel)   │
└─────────────────────────────────────┘

Kubernetes에서는 CNI(Container Network Interface) 플러그인(Calico, Flannel, Cilium 등)이 Pod 간 네트워킹을 담당합니다. Service 리소스는 L4 로드 밸런서 역할을 하며, Ingress는 L7 라우팅을 제공합니다.

4. DNS 완전 정복

DNS 질의 과정

DNS(Domain Name System)는 도메인 이름(예: www.example.com)을 IP 주소로 변환하는 분산 데이터베이스 시스템입니다.

사용자 → 로컬 DNS 캐시 → 재귀적 리졸버 → 루트 서버 → TLD 서버 → 권한 서버
                                    ↓              ↓           ↓
                                 "." 루트      ".com" TLD   "example.com"
                                                            → IP: 93.184.216.34

재귀적 질의 (Recursive Query):

• 클라이언트가 재귀적 리졸버에게 최종 답을 요청
• 리졸버가 루트 → TLD → 권한 서버를 차례로 질의하여 IP를 반환

반복적 질의 (Iterative Query):

• 각 서버가 다음에 질의할 서버를 알려주는 방식
• 리졸버가 직접 각 서버에 순차적으로 질의

DNS 레코드 종류

TTL과 캐싱 전략

TTL(Time To Live)은 DNS 레코드가 캐시에 유지되는 시간(초)입니다.

실전 팁: DNS 마이그레이션 전에 TTL을 먼저 낮추고(예: 60초), 충분한 시간이 지난 후 IP를 변경하면 전환 시 다운타임을 최소화할 수 있습니다.

DNS over HTTPS (DoH) / DNS over TLS (DoT)

기존 DNS는 평문(UDP 53번 포트)으로 전송되어 도청 및 변조에 취약합니다.

dig/nslookup 실전 명령어

# A 레코드 조회
dig example.com A

# 특정 DNS 서버로 조회
dig @8.8.8.8 example.com

# 전체 질의 과정 추적
dig +trace example.com

# 간략한 결과만 출력
dig +short example.com

# MX 레코드 조회
dig example.com MX

# 역방향 DNS 조회
dig -x 8.8.8.8

# nslookup 사용
nslookup example.com
nslookup -type=MX example.com 8.8.8.8

# DNS 캐시 클리어 (macOS)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

5. HTTP 진화: 1.0 에서 1.1, 2, 3까지

HTTP/1.0: 요청마다 새 연결

초기 HTTP는 매 요청마다 TCP 연결을 새로 수립했습니다. HTML 페이지 하나에 이미지 10개가 있으면 TCP 연결을 11번 맺어야 했습니다.

[TCP 연결] → [요청] → [응답] → [TCP 종료]
[TCP 연결] → [요청] → [응답] → [TCP 종료]
... 반복

HTTP/1.1: Keep-Alive와 파이프라이닝

주요 개선사항:

• Persistent Connection (Keep-Alive): 하나의 TCP 연결에서 여러 요청/응답 처리
• Pipelining: 응답을 기다리지 않고 여러 요청을 연속 전송 (하지만 HOL blocking 문제)
• Host 헤더: 하나의 IP에서 여러 도메인 호스팅 가능 (가상 호스팅)
• Chunked Transfer Encoding: 응답 크기를 모르는 상태에서 스트리밍 전송

[TCP 연결] → [요청1] → [응답1] → [요청2] → [응답2] → ... → [TCP 종료]

HOL(Head-of-Line) Blocking 문제: 첫 번째 응답이 느리면 뒤의 모든 요청이 대기해야 합니다.

HTTP/2: 멀티플렉싱 혁명

단일 TCP 연결
┌──────────────────────────────────┐
│  Stream 1: GET /index.html       │
│  Stream 3: GET /style.css        │  ← 동시에 처리
│  Stream 5: GET /script.js        │
│  Stream 7: GET /image.png        │
└──────────────────────────────────┘

핵심 기능:

1. 멀티플렉싱(Multiplexing): 하나의 TCP 연결에서 여러 스트림을 동시에 처리. HTTP/1.1의 HOL blocking을 해결합니다.

2. Header Compression (HPACK): 반복되는 헤더를 정적/동적 테이블로 압축하여 헤더 오버헤드를 크게 줄입니다.

3. Server Push: 서버가 클라이언트의 요청 없이 리소스를 미리 전송합니다.

4. Binary Framing: 텍스트 기반이 아닌 바이너리 프레임으로 전송하여 파싱 효율 향상.

5. Stream Priority: 스트림 간 우선순위를 설정하여 중요한 리소스를 먼저 전송.

HTTP/3: QUIC (UDP 기반)

HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용합니다.

HTTP/2 스택         HTTP/3 스택
┌──────────┐       ┌──────────┐
│  HTTP/2  │       │  HTTP/3  │
├──────────┤       ├──────────┤
│  TLS 1.2+│       │   QUIC   │ ← TLS 1.3 내장
├──────────┤       ├──────────┤
│   TCP    │       │   UDP    │
├──────────┤       ├──────────┤
│    IP    │       │    IP    │
└──────────┘       └──────────┘

HTTP/3의 핵심 장점:

• 0-RTT 연결: 이전에 연결한 서버에 대해 첫 패킷부터 데이터 전송 가능
• HOL Blocking 완전 제거: 각 스트림이 독립적으로 관리되므로 하나의 스트림 손실이 다른 스트림에 영향을 주지 않음
• Connection Migration: 네트워크가 변경되어도(Wi-Fi에서 셀룰러) 연결이 유지됨

HTTP 버전 비교표

언제 무엇을 사용하는가?

• HTTP/1.1: 레거시 시스템, 단순 API
• HTTP/2: 대부분의 웹사이트와 API (현재 기본)
• HTTP/3: 모바일 환경, 글로벌 서비스, 낮은 지연이 중요한 경우

6. HTTPS와 TLS 1.3

대칭 vs 비대칭 암호화

TLS는 비대칭 암호화로 세션 키를 교환한 후, 대칭 암호화로 실제 데이터를 암호화합니다.

TLS 1.2 vs TLS 1.3 핸드셰이크

TLS 1.2 (2-RTT):

클라이언트                          서버
    |--- ClientHello ----------------->|   RTT 1
    |<-- ServerHello, Certificate -----|
    |<-- ServerKeyExchange, Done ------|
    |--- ClientKeyExchange, Finished ->|   RTT 2
    |<-- Finished ---------------------|
    |===== 암호화 통신 시작 ===========|

TLS 1.3 (1-RTT, 0-RTT 가능):

클라이언트                          서버
    |--- ClientHello + KeyShare ------>|   RTT 1
    |<-- ServerHello + KeyShare -------|
    |<-- EncryptedExtensions, Cert ----|
    |<-- Finished ---------------------|
    |--- Finished -------------------->|
    |===== 암호화 통신 시작 ===========|

TLS 1.3의 핵심 개선:

인증서와 CA

인증서 체인:
┌────────────────────┐
│   Root CA 인증서    │  ← 브라우저/OS에 내장
├────────────────────┤
│  Intermediate CA   │  ← Root CA가 서명
├────────────────────┤
│  서버 인증서        │  ← Intermediate CA가 서명
└────────────────────┘

• Let's Encrypt: 무료 DV(Domain Validation) 인증서, 90일 유효, 자동 갱신 (certbot)
• OV/EV 인증서: 조직 검증/확장 검증으로 더 높은 신뢰 수준

OCSP Stapling

기존 OCSP는 브라우저가 직접 CA에 인증서 유효성을 확인했지만, 이는 느리고 프라이버시 문제가 있었습니다. OCSP Stapling은 서버가 CA로부터 미리 받은 응답을 클라이언트에게 전달합니다.

# Nginx OCSP Stapling 설정
server {
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
}

mTLS (상호 TLS 인증)

일반 TLS에서는 클라이언트만 서버를 인증합니다. mTLS에서는 서버도 클라이언트의 인증서를 확인합니다.

일반 TLS:
  클라이언트 → 서버 인증서 검증 (단방향)

mTLS:
  클라이언트 → 서버 인증서 검증
  서버 → 클라이언트 인증서 검증 (양방향)

mTLS 사용 사례:

• Kubernetes 서비스 메시 (Istio, Linkerd)에서 서비스 간 통신
• Zero Trust 아키텍처에서 서비스 인증
• API 게이트웨이에서 클라이언트 인증

7. REST vs GraphQL vs gRPC vs WebSocket

REST (Representational State Transfer)

REST는 HTTP 메서드(GET, POST, PUT, DELETE)와 리소스 URI를 기반으로 한 아키텍처 스타일입니다.

Richardson 성숙도 모델:

HATEOAS 예시:

{
  "id": 1,
  "name": "John",
  "links": [
    { "rel": "self", "href": "/users/1" },
    { "rel": "orders", "href": "/users/1/orders" },
    { "rel": "update", "href": "/users/1", "method": "PUT" }
  ]
}

GraphQL

GraphQL은 클라이언트가 필요한 데이터만 정확히 요청할 수 있는 쿼리 언어입니다.

# 클라이언트가 필요한 필드만 요청
query {
  user(id: 1) {
    name
    email
    orders(last: 5) {
      id
      total
      items {
        name
        price
      }
    }
  }
}

장점:

• Overfetching / Underfetching 해결
• 단일 엔드포인트
• 강력한 타입 시스템

단점:

• N+1 문제 (DataLoader로 해결)
• 캐싱이 어려움 (URL 기반 캐시 불가)
• 복잡한 쿼리로 인한 서버 부하

gRPC

gRPC는 Google이 개발한 HTTP/2 기반의 고성능 RPC 프레임워크입니다. Protocol Buffers를 사용하여 바이너리 직렬화를 수행합니다.

// user.proto
syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
  rpc CreateUsers (stream CreateUserRequest) returns (CreateUsersResponse);
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message GetUserRequest {
  int32 id = 1;
}

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

gRPC 4가지 통신 패턴:

WebSocket

WebSocket은 HTTP 업그레이드를 통해 전이중 양방향 통신을 제공합니다.

HTTP 업그레이드:
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

→ 이후 양방향 프레임 기반 통신

사용 사례:

• 실시간 채팅
• 주식/암호화폐 실시간 시세
• 온라인 게임
• 협업 도구 (Google Docs 등)

SSE (Server-Sent Events)

SSE는 서버에서 클라이언트로의 단방향 실시간 스트리밍입니다. WebSocket보다 간단하며, HTTP 위에서 동작합니다.

// 서버 (Node.js)
res.writeHead(200, {
  'Content-Type': 'text/event-stream',
  'Cache-Control': 'no-cache',
  Connection: 'keep-alive',
})

setInterval(() => {
  res.write('data: ' + JSON.stringify(data) + '\n\n')
}, 1000)

// 클라이언트
const eventSource = new EventSource('/events')
eventSource.onmessage = (event) => {
  console.log(JSON.parse(event.data))
}

통신 방식 비교표

8. CDN과 로드 밸런싱

CDN 동작 원리

CDN(Content Delivery Network)은 전 세계에 분산된 엣지 서버에 콘텐츠를 캐싱하여 사용자에게 가장 가까운 서버에서 콘텐츠를 제공합니다.

사용자 (서울) → 엣지 서버 (서울) → [캐시 히트] → 즉시 응답
                                   [캐시 미스] → 오리진 서버 (미국) → 캐시 저장 → 응답

핵심 기술:

• Anycast: 동일한 IP를 여러 엣지 서버가 공유하고, BGP 라우팅으로 가장 가까운 서버로 라우팅
• Edge Caching: Cache-Control 헤더를 기반으로 콘텐츠를 캐싱
• Cache-Control 헤더: public, max-age=31536000, immutable (1년 캐시, 불변 콘텐츠)

Cache-Control 주요 지시어:

CDN 비교

로드 밸런서: L4 vs L7

로드 밸런싱 알고리즘

Consistent Hashing의 장점:

해시 링:
    0 ─── Server A ─── Server B ─── Server C ─── 2^32
         ↑                ↑                ↑
      Key1, Key4       Key2, Key5       Key3, Key6

Server D 추가 시:
    0 ─── Server A ── Server D ── Server B ─── Server C ─── 2^32
         ↑            ↑           ↑                ↑
      Key1, Key4    Key2       Key5             Key3, Key6

→ Server D와 Server B 사이의 키만 재분배 (전체 아님)

주요 로드 밸런서 제품

# Nginx L7 로드 밸런서 설정 예시
upstream backend {
    least_conn;
    server backend1.example.com:8080 weight=3;
    server backend2.example.com:8080 weight=2;
    server backend3.example.com:8080 weight=1;
    server backend4.example.com:8080 backup;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

9. 실전 디버깅 도구

curl — HTTP 요청의 스위스 아미 나이프

# 기본 GET 요청
curl https://api.example.com/users

# 상세 정보 출력 (TLS 핸드셰이크 포함)
curl -v https://api.example.com/users

# POST 요청 (JSON)
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "John", "email": "john@example.com"}'

# 응답 시간 분석 (핵심!)
curl -w "\n
    DNS 조회:     %{time_namelookup}s\n
    TCP 연결:     %{time_connect}s\n
    TLS 핸드셰이크: %{time_appconnect}s\n
    첫 바이트:    %{time_starttransfer}s\n
    총 시간:      %{time_total}s\n" \
  -o /dev/null -s https://api.example.com/users

# HTTP/2로 요청
curl --http2 https://api.example.com/users

# 헤더만 출력
curl -I https://api.example.com/users

tcpdump — 패킷 캡처

# 특정 포트의 TCP 패킷 캡처
sudo tcpdump -i eth0 port 80 -n

# 특정 호스트와의 통신 캡처
sudo tcpdump host 192.168.1.100

# 패킷을 파일로 저장 (Wireshark에서 분석)
sudo tcpdump -i eth0 -w capture.pcap port 443

# SYN 패킷만 캡처 (연결 시작 추적)
sudo tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'

# HTTP 요청만 캡처
sudo tcpdump -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

netstat / ss / lsof — 연결 상태 확인

# 열린 포트 확인 (ss가 netstat보다 빠름)
ss -tulnp

# 특정 포트 사용 프로세스 확인
ss -tulnp | grep :8080
lsof -i :8080

# TIME_WAIT 상태 연결 수 확인
ss -s
ss -tan state time-wait | wc -l

# ESTABLISHED 연결 목록
ss -tan state established

traceroute / mtr — 경로 추적

# 기본 경로 추적
traceroute example.com

# TCP 기반 traceroute (ICMP가 차단된 경우)
traceroute -T -p 443 example.com

# mtr (traceroute + ping 결합, 실시간 모니터링)
mtr example.com

# 특정 횟수만 실행
mtr -c 10 --report example.com

Chrome DevTools Network 탭 활용

주요 분석 포인트:

1. Waterfall 차트: 각 요청의 DNS, TCP, TLS, TTFB(Time To First Byte) 시간 확인
2. Size vs Transferred: 압축 효과 확인 (gzip, br)
3. Initiator: 어떤 리소스가 해당 요청을 트리거했는지
4. Timing 탭: Queued, Stalled, DNS, Initial Connection, SSL, TTFB, Content Download 세분화
5. Throttling: Slow 3G, Fast 3G 등으로 느린 네트워크 시뮬레이션

10. 면접 예상 질문 15선

기본 개념

Q1. "브라우저에 URL을 입력하면 어떤 일이 일어나는지 설명해주세요."

1. URL 파싱 (프로토콜, 도메인, 경로)
2. DNS 조회 (브라우저 캐시 → OS 캐시 → 리졸버 → 루트 → TLD → 권한 서버)
3. TCP 3-Way Handshake
4. TLS 핸드셰이크 (HTTPS인 경우)
5. HTTP 요청 전송
6. 서버 처리 및 HTTP 응답
7. 브라우저 렌더링 (HTML 파싱, DOM 구성, CSSOM, Layout, Paint)

Q2. "TCP와 UDP의 차이를 설명하고, 각각 언제 사용하나요?"

TCP는 신뢰성 있는 연결 지향 프로토콜로 데이터 순서 보장과 재전송을 제공합니다. 웹, 이메일, 파일 전송에 사용합니다. UDP는 비연결형으로 빠르지만 신뢰성이 없습니다. DNS, 실시간 스트리밍, 게임에 사용합니다.

Q3. "HTTP/2와 HTTP/3의 주요 차이점은?"

HTTP/2는 TCP 위에서 멀티플렉싱을 지원하지만 TCP 수준의 HOL blocking이 남아있습니다. HTTP/3는 UDP 기반 QUIC를 사용하여 HOL blocking을 완전히 제거하고, 0-RTT 연결과 Connection Migration을 지원합니다.

심화 질문

Q4. "TCP 3-Way Handshake를 SYN Flood 공격과 연관지어 설명해주세요."

SYN Flood는 대량의 SYN 패킷을 보내 서버의 반개방(half-open) 연결 테이블을 가득 채우는 DoS 공격입니다. 방어 방법으로 SYN Cookies, SYN Proxy, Rate Limiting이 있습니다.

Q5. "CORS란 무엇이고, 왜 필요한가요?"

Cross-Origin Resource Sharing는 브라우저의 동일 출처 정책(Same-Origin Policy)을 안전하게 완화하는 메커니즘입니다. 서버가 Access-Control-Allow-Origin 헤더로 허용할 출처를 명시합니다.

Q6. "DNS의 TTL 값이 낮으면 어떤 장단점이 있나요?"

장점: DNS 변경 시 빠른 전파, 장애 복구 시 빠른 전환. 단점: DNS 서버 부하 증가, 질의 빈도 증가로 인한 지연.

Q7. "TLS 1.3이 1.2보다 빠른 이유는?"

TLS 1.3은 핸드셰이크를 1-RTT로 줄이고 (1.2는 2-RTT), 0-RTT 재개를 지원합니다. 또한 취약한 암호 스위트를 제거하고 키 교환을 단순화했습니다.

Q8. "REST API에서 멱등성(Idempotency)이란?"

동일한 요청을 여러 번 수행해도 결과가 같은 것입니다. GET, PUT, DELETE는 멱등적이고, POST는 그렇지 않습니다. 결제 API에서 중복 요청을 방지하기 위해 Idempotency Key를 사용합니다.

설계/실무 질문

Q9. "WebSocket과 SSE를 비교하고 언제 각각을 사용하나요?"

WebSocket은 양방향, SSE는 서버에서 클라이언트로의 단방향입니다. 채팅이나 게임은 WebSocket, 알림이나 실시간 피드는 SSE가 적합합니다.

Q10. "CDN을 사용하면 어떤 이점이 있나요?"

지연 시간 감소(지리적 근접), 오리진 서버 부하 감소, DDoS 방어, 글로벌 가용성 향상, 대역폭 비용 절감.

Q11. "L4 vs L7 로드 밸런서의 차이는?"

L4는 TCP/UDP 수준에서 IP와 포트 기반으로 라우팅하여 빠르지만 제한적입니다. L7은 HTTP 헤더, URL, 쿠키 기반으로 라우팅하여 더 유연하지만 오버헤드가 있습니다.

Q12. "마이크로서비스 간 통신에 gRPC를 쓰면 어떤 장점이 있나요?"

HTTP/2 기반 멀티플렉싱, Protobuf 바이너리 직렬화로 높은 성능, 강력한 타입 시스템, 양방향 스트리밍, 다중 언어 지원, K8s 환경에서 서비스 메시와 잘 통합됩니다.

Q13. "Consistent Hashing이란 무엇이고, 왜 사용하나요?"

서버 추가/제거 시 전체 키를 재분배하지 않고 해시 링에서 인접한 키만 이동시키는 기법입니다. 분산 캐시(Memcached, Redis Cluster)와 로드 밸런서에서 사용합니다.

Q14. "NAT가 필요한 이유와 동작 방식을 설명하세요."

IPv4 주소 부족으로 사설 IP를 사용하고, NAT를 통해 공인 IP로 변환합니다. 출발지/목적지 IP와 포트를 변환하며, 사설 네트워크의 보안을 높여줍니다.

Q15. "HTTP Keep-Alive와 WebSocket의 차이는?"

Keep-Alive는 TCP 연결을 유지하지만 여전히 요청-응답 모델입니다. WebSocket은 프로토콜 업그레이드 후 양방향 전이중 통신이 가능합니다.

11. 퀴즈

지금까지 배운 내용을 점검해봅시다.

12. 참고 자료

공식 문서 및 RFC

1. RFC 793 - Transmission Control Protocol
2. RFC 768 - User Datagram Protocol
3. RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
4. RFC 9114 - HTTP/3
5. RFC 8446 - TLS 1.3
6. RFC 7540 - HTTP/2
7. RFC 1035 - Domain Names - Implementation and Specification

서적

8. Computer Networking: A Top-Down Approach (Kurose, Ross) - 네트워크 기초 교과서
9. TCP/IP Illustrated, Volume 1 (W. Richard Stevens) - TCP/IP 바이블
10. High Performance Browser Networking (Ilya Grigorik) - 무료 온라인 서적, 웹 성능 최적화

온라인 자료

11. MDN Web Docs - HTTP - HTTP 가이드
12. Cloudflare Learning Center - 네트워크 개념 시각적 설명
13. Julia Evans - Networking Zines - 네트워킹 개념을 만화로 쉽게 설명
14. gRPC Official Documentation - gRPC 공식 문서
15. Beej's Guide to Network Programming - 네트워크 프로그래밍 가이드
16. DNS 101 - How DNS Works - DNS 동작 원리 시각화
17. Wireshark User's Guide - Wireshark 사용법

네트워크는 개발자의 기본 소양입니다. 이 글에서 다룬 내용을 한 번에 다 외울 필요는 없습니다. 실무에서 API 성능 문제를 디버깅하거나, 시스템 설계를 논의하거나, 면접을 준비할 때 이 글을 다시 찾아보세요. 각 프로토콜의 "왜"를 이해하면, 새로운 기술이 나와도 빠르게 적응할 수 있습니다.