KR_Net_HTTP

네트워크 HTTP & HTTPS (Q1-Q5)

HTTP & HTTPS (1~5번)

Q1. HTTP와 HTTPS의 동작 원리 차이를 상세히 설명하세요.

HTTP 동작 과정:

• ① 클라이언트가 HTTP 요청 메시지 전송 (GET, POST 등 메서드 + URI)
• ② 서버가 요청 처리 후 HTTP 응답 메시지 반환 (상태 코드 + 응답 본문)
• ③ 클라이언트가 응답 해석 및 추가 요청 가능 (HTML, CSS, JavaScript 등)
• ④ 평문 전송으로 중간자 공격에 취약

HTTPS 동작 과정 (TLS Handshake):

• ① 클라이언트가 HTTPS 서버에 접속, ClientHello 메시지 전송 (지원 암호화 스위트 목록)
• ② 서버가 ServerHello + SSL/TLS 인증서 전송 (공개키 포함)
• ③ 클라이언트가 인증서 검증 (CA의 공개키로 서명 확인)
• ④ 클라이언트가 세션 키(대칭키) 생성 후 서버의 공개키로 암호화하여 전송
• ⑤ 서버가 비공개키로 세션 키 복호화
• ⑥ 이후 세션 키를 사용한 대칭키 암호화 통신
• ⑦ Finished 메시지 교환 후 암호화된 데이터 전송

주요 차이점:

• HTTP: 포트 80, 평문 전송, 빠름, 보안 취약
• HTTPS: 포트 443, 암호화 전송, TLS Handshake 오버헤드, 기밀성/무결성/인증 보장

Q2. HTTP 메서드의 멱등성(Idempotent)과 안전성(Safe)을 설명하세요.

안전한 메서드 (Safe Methods):

• 서버 상태를 변경하지 않는 읽기 전용 메서드
• GET, HEAD, OPTIONS, TRACE
• 여러 번 호출해도 서버 리소스에 영향 없음

멱등한 메서드 (Idempotent Methods):

• 동일한 요청을 여러 번 수행해도 결과가 동일
• GET, HEAD, PUT, DELETE, OPTIONS, TRACE
• POST, PATCH는 비멱등적: 매번 새로운 리소스 생성 또는 다른 결과

실무 예시:

GET /users/123       → 안전 + 멱등 (여러 번 조회해도 동일)
POST /users          → 비안전 + 비멱등 (매번 새 사용자 생성)
PUT /users/123       → 비안전 + 멱등 (같은 내용으로 덮어쓰기)
DELETE /users/123    → 비안전 + 멱등 (이미 삭제된 리소스 재삭제 시 404지만 상태 동일)
PATCH /users/123     → 비안전 + 비멱등 (증가 연산 등 누적 가능)

네트워크 재시도 전략:

• 멱등한 메서드는 자동 재시도 안전
• 비멱등한 메서드는 Idempotency Key 사용 (결제 API 등)

Q3. HTTP/1.1, HTTP/2, HTTP/3의 주요 차이점과 성능 개선 방법은?

HTTP/1.1 (1997):

• Connection per Request: 요청마다 새로운 TCP 연결 (Keep-Alive로 완화)
• Head-of-Line Blocking: 이전 요청 완료 전까지 대기
• 텍스트 기반 프로토콜: 파싱 오버헤드
• 개선 방법: Pipelining (제한적 지원), Domain Sharding (다중 도메인)

HTTP/2 (2015):

• Multiplexing: 하나의 TCP 연결에서 여러 스트림 동시 전송
• Header Compression (HPACK): 헤더 중복 제거 및 압축
• Server Push: 클라이언트 요청 전 리소스 선제 전송
• Binary Framing: 바이너리 프레임으로 효율적 파싱
• 한계: TCP 레벨 Head-of-Line Blocking 여전히 존재 (패킷 손실 시 전체 스트림 대기)

HTTP/3 (2022):

• QUIC over UDP: TCP 대신 QUIC 프로토콜 사용
• Stream-level 독립성: 하나의 스트림 패킷 손실이 다른 스트림에 영향 없음
• 0-RTT Connection: 이전 연결 정보 재사용으로 Handshake 생략
• Connection Migration: IP 변경 시에도 연결 유지 (모바일 환경)
• 내장 TLS 1.3: 암호화 필수

성능 비교:

HTTP/1.1: 6개 병렬 연결 → 리소스 로딩 직렬화
HTTP/2:   단일 연결 Multiplexing → 2~3배 빠름
HTTP/3:   QUIC 기반 → 패킷 손실 환경에서 10~30% 추가 개선

Q4. HTTPS의 TLS Handshake 과정과 성능 최적화 방법은?

Full TLS 1.2 Handshake (2-RTT):

Client                                Server
  |                                     |
  |-------- ClientHello --------------->| (지원 암호화 스위트, 랜덤 값)
  |                                     |
  |<------- ServerHello ----------------| (선택 암호화 스위트, 인증서, 랜덤 값)
  |<------- Certificate ----------------| (서버 공개키)
  |<------- ServerHelloDone ------------|
  |                                     |
  |-------- ClientKeyExchange --------->| (Pre-Master Secret 암호화 전송)
  |-------- ChangeCipherSpec ---------->|
  |-------- Finished ------------------>|
  |                                     |
  |<------- ChangeCipherSpec -----------|
  |<------- Finished -------------------|
  |                                     |
  |======== Application Data ==========| (암호화된 HTTP 데이터)

TLS 1.3 Handshake (1-RTT):

Client                                Server
  |-------- ClientHello + KeyShare ---->| (암호화 키 교환 동시 전송)
  |                                     |
  |<------- ServerHello + KeyShare -----| (암호화 키 + 인증서)
  |<------- {EncryptedExtensions} ------|
  |<------- {Certificate} --------------|
  |<------- {Finished} -----------------|
  |                                     |
  |-------- {Finished} ---------------->|
  |======== Application Data ==========|

성능 최적화 방법:

1. TLS Session Resumption:

Session ID: 서버가 세션 정보 저장 (메모리 부담)
Session Ticket: 클라이언트가 암호화된 티켓 저장 (stateless)

2. TLS 1.3 0-RTT (Zero Round Trip Time):

• 이전 연결의 PSK(Pre-Shared Key) 재사용
• Handshake 없이 바로 데이터 전송
• 보안 트레이드오프: Replay Attack 위험 (멱등한 요청만 사용)

3. OCSP Stapling:

• 서버가 인증서 상태를 미리 확인하여 응답에 포함
• 클라이언트의 CA 조회 시간 절약

4. HTTP/3 (QUIC):

• 0-RTT Connection 기본 지원
• TLS 1.3 내장

실무 설정 (Nginx):

ssl_protocols TLSv1.3 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;

Q5. HTTP 상태 코드별 실무 활용과 캐싱 전략은?

2xx 성공 응답:

• 200 OK: GET 성공, 응답 본문 포함
• 201 Created: POST로 리소스 생성 성공, Location 헤더에 새 URI
• 204 No Content: 요청 성공하지만 응답 본문 없음 (DELETE, PUT 성공 시)
• 206 Partial Content: Range 요청에 대한 부분 응답 (동영상 스트리밍)

3xx 리다이렉션:

• 301 Moved Permanently: 영구 이동, 검색 엔진이 새 URL 인덱싱
• 302 Found: 임시 이동, 원본 URL 유지
• 304 Not Modified: 캐시된 리소스 유효, 본문 전송 안 함 (If-Modified-Since, ETag 활용)
• 307 Temporary Redirect: 302와 유사하지만 메서드 변경 금지 (POST → POST)
• 308 Permanent Redirect: 301과 유사하지만 메서드 변경 금지

4xx 클라이언트 오류:

• 400 Bad Request: 잘못된 요청 문법
• 401 Unauthorized: 인증 필요 (WWW-Authenticate 헤더)
• 403 Forbidden: 인증되었지만 권한 없음
• 404 Not Found: 리소스 존재하지 않음
• 405 Method Not Allowed: 허용되지 않은 메서드
• 429 Too Many Requests: Rate Limit 초과 (Retry-After 헤더)

5xx 서버 오류:

• 500 Internal Server Error: 서버 내부 오류
• 502 Bad Gateway: 게이트웨이/프록시 오류
• 503 Service Unavailable: 서버 과부하 또는 유지보수 (Retry-After 헤더)
• 504 Gateway Timeout: 게이트웨이/프록시 타임아웃

캐싱 전략 (Cache-Control):

Cache-Control: public, max-age=31536000, immutable
→ 정적 리소스 (CSS, JS), 1년 캐시, 브라우저 재검증 불필요

Cache-Control: private, max-age=3600
→ 사용자별 데이터, 1시간 캐시, CDN 캐시 불가

Cache-Control: no-cache
→ 캐시 가능하지만 사용 전 재검증 필요 (ETag, Last-Modified)

Cache-Control: no-store
→ 캐시 금지 (민감한 정보)

조건부 요청:

Request:
  If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
  If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

Response (캐시 유효):
  304 Not Modified
  ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
  (본문 없음, 대역폭 절약)

💡 용어 설명:

• HTTP/HTTPS 관련 질문들(Q1-Q5)에서 사용된 용어들(TLS Handshake, 멱등성, HTTP/2 Multiplexing, Cache-Control, ETag 등)에 대한
• 상세한 설명은 문서 상단의 주요 용어 통합 정리 > 프로토콜 & 통신 섹션을 참고하세요.

참고 자료

• ← KR_네트워크.md로 돌아가기