HTTP 심화

학습 목표

HTTP/1.1 연결 재사용(Keep-Alive) 과 비영속 연결의 차이를 설명할 수 있다.

쿠키·세션으로 무상태 HTTP 위에 상태를 흉내 내는 방식을 설명할 수 있다.

캐시 헤더와 조건부 GET(304) 으로 대역폭·지연을 줄이는 원리를 설명할 수 있다.

REST 가 리소스·메서드·표현으로 API를 조직하는 아키텍처 스타일임을 설명할 수 있다.

문제 상황

• API 호출 100번에 TCP 핸드셰이크가 100번 찍힌다
  • 요청마다 연결을 닫는지, 재사용하는지 모른다
• 로그인 직후 Set-Cookie가 보이는데, 다음 요청엔 Cookie만내면 된다
  • 서버가 어떻게 나를 기억하는지, Redis 세션과 무엇이 다른지 헷갈린다
• 정적 파일은 바뀌지 않았는데 매번 전체 HTML을 받는다
  • Cache-Control, ETag, 304의 역할 분담이 안 보인다
• URL에 /getUser, /createOrder처럼 동사가 붙은 API를 REST라고 부른다
  • REST는 프로토콜이 아니라 설계 스타일이라는 점이 불명확하다

HTTP 메시지·메서드·상태 코드를 봤다. 실무에서 매일 마주치는 연결·상태·캐시·API 설계를 이어서 본다.

1. 연결 관리: Keep-Alive

HTTP/1.0은 기본적으로 요청 하나 끝나면 TCP 연결을 닫았다. HTTP/1.1은 기본이 persistent connection(Keep-Alive)이다.

	Non-persistent	Persistent (Keep-Alive)
TCP	요청마다 새 연결 (또는 명시적 close)	한 연결에 여러 요청·응답
오버헤드	3-way handshake·TLS 재협상 반복	연결·세션 재사용으로 지연·CPU 절감
종료	응답 후 Connection: close	유휴 타임아웃 또는 Connection: close

# HTTP/1.1 — 같은 TCP에서 연속 요청 (개념)
GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

GET /style.css HTTP/1.1
Host: example.com
Connection: keep-alive

• 파이프라ining(요청을 응답 전에 연속 전송)은 HTTP/1.1에 정의돼 있으나, HOL blocking 때문에 브라우저·프록시에서 거의 쓰이지 않는다
• HTTP/2는 한 TCP(또는 QUIC) 위에 멀티플렉싱 프레임 — Keep-Alive의 다음 단계로 보면 된다
• 로드 밸런서·프록시의 idle timeout이 클라이언트 Keep-Alive보다 짧으면 중간에 끊긴다 → 재연결·502 디버깅 시 확인

# 연결이 재사용되는지 (HTTP/1.1, 동일 호스트 반복)
curl -v --http1.1 https://example.com/ https://example.com/ 2>&1 | grep -E '^(<|>) Connection|Re-used'

2. 쿠키와 세션

HTTP는 무상태지만, 웹은 로그인·장바구니처럼 연속 맥락이 필요하다. 프로토콜 위에 쿠키와 서버 측 세션 저장소를 얹는다.

개념	역할
Cookie	서버가 Set-Cookie로 내려준 키·값을 클라이언트가 이후 요청에 Cookie 헤더로 되돌려줌
Session	서버(또는 Redis)에 session id → 사용자 상태를 저장; 쿠키는 often 세션 ID만 운반
Token	JWT 등 자체 포함(self-contained) 인증 정보를 헤더(Authorization: Bearer)로 전달 — 쿠키 없이도 가능

Set-Cookie 주요 속성

속성	의미
HttpOnly	JavaScript document.cookie 접근 차단 (XSS 완화)
Secure	HTTPS에서만 전송
SameSite	크로스 사이트 요청 시 전송 제한 (CSRF 완화)
Max-Age / Expires	쿠키 수명 (세션 쿠키는 브라우저 종료까지)
Domain / Path	어떤 URL에 쿠키를 붙일지 범위

HTTP/1.1 200 OK
Set-Cookie: sessionid=7f3a; Path=/; HttpOnly; Secure; SameSite=Lax

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: sessionid=7f3a

• Sticky session: LB가 같은 서버로만 보내는 방식 — 세션이 로컬 메모리에만 있을 때. Redis 등 중앙 세션이면 sticky 없이도 확장 가능
• 무상태 API는 쿠키 대신 Bearer 토큰이 흔하다 — 프로토콜은 여전히 stateless, 인증 정보를 매 요청에 실음

3. HTTP 캐싱

캐시는 클라이언트(브라우저), 프록시(CDN), 서버 어디에나 있을 수 있다. 목표는 같은 표현을 다시 받지 않기다.

헤더	방향	역할
Cache-Control	응답(·요청)	max-age, no-cache, no-store, private/public
ETag	응답	리소스 버전 지문(해시 등)
Last-Modified	응답	마지막 수정 시각
If-None-Match	요청	이전 ETag와 같으면 본문 생략
If-Modified-Since	요청	Last-Modified 이후 변경 없으면 생략

조건부 GET 흐름:

1. 첫 요청 → 200 OK + 본문 + ETag: "abc123" + Cache-Control: max-age=3600
2. 캐시 만료 후(또는 no-cache로 재검증 필요 시) → GET + If-None-Match: "abc123"
3. 서버가 변경 없음 → 304 Not Modified (본문 없음) → 클라이언트가 로컬 캐시 사용

# ETag 확인
curl -sI https://example.com/ | grep -iE 'etag|cache-control|last-modified'

# 조건부 요청 (ETag 값을 직접 넣어 테스트)
curl -sI -H 'If-None-Match: "값"' https://example.com/

• no-store — 저장 자체 금지 (민감 데이터). no-cache — 저장은 하되 사용 전 재검증
• API JSON은 기본적으로 캐시하기 어렵다 → Cache-Control: no-store 또는 짧은 max-age + 버전 URL이 흔하다
• CDN은 엣지 캐시 + 원본 재검증으로 지연·원본 부하를 동시에 줄인다

4. REST 관점

REST(Representational State Transfer) 는 Roy Fielding이 정의한 아키텍처 스타일이다. HTTP를 REST API에 쓰는 것과 동일하지 않다 — 다만 HTTP의 리소스·메서드·무상태가 REST 원칙과 잘 맞는다.

REST 원칙 (요약)	HTTP에서의 실천
리소스 식별	URL은 명사 (/users/42, /orders)
표현(Representation)	JSON·XML 등 본문으로 상태 전달
무상태	서버는 요청 간 맥락을 저장하지 않음 — 토큰·쿠키로 보완
통일 인터페이스	GET 조회, POST 생성, PUT/PATCH 수정, DELETE 삭제
계층화	LB, CDN, API Gateway — 클라이언트는 중간 계층을 모름

GET    /api/users/42          → 200 + user JSON
POST   /api/users             → 201 Created + Location
PUT    /api/users/42          → 200 or 204
DELETE /api/users/42          → 204 No Content

• HATEOAS(응답에 다음 링크 포함)까지 지키면 "순수 REST"에 가깝지만, 실무 API는 JSON + 고정 URL이 대부분 → RESTful-ish 또는 HTTP API라고 부르는 경우도 많다
• RPC 스타일(/api/createUser)도 HTTP 위에서 동작하지만, 캐시·프록시·의미 측면에서 리소스 스타일이 유리한 경우가 많다

5. 정리

• Keep-Alive로 TCP·TLS 오버헤드를 줄이고, HTTP/2는 멀티플렉싱으로 한 단계 더 간다
• 쿠키는 클라이언트가 들고 다니는 식별자, 세션은 서버 측 상태 — 무상태 HTTP 위의 앱 패턴
• 캐시 + 304로 변경 없는 리소스의 대역폭·지연을 줄인다
• REST는 리소스 중심 API 설계 스타일 — HTTP 메서드·상태 코드와 함께 쓰면 운영·디버깅이 수월하다

다음에 다룰 것

• HTTPS와 TLS
• 암호화 필요성, TLS 핸드셰이크, 인증서

---

해당 내용은 Computer Networking: A Top-Down Approach, 8/E (James Kurose, Keith Ross) 의 내용을 기반으로 합니다.