HTTP 기초

학습 목표

HTTP가 애플리케이션 계층 프로토콜로 요청/응답을 주고받는 방식을 설명할 수 있다.

요청·응답 메시지 구조(시작줄, 헤더, 본문)를 읽을 수 있다.

주요 HTTP 메서드와 상태 코드 범주를 구분할 수 있다.

HTTP가 무상태(stateless) 인 이유와 그로 인한 설계 영향을 설명할 수 있다.

문제 상황

• curl -v https://api.example.com/users 출력에 GET /users HTTP/1.1과 HTTP/2 200이 섞여 보인다
  • 어디까지가 HTTP이고 TCP/TLS와 경계가 어디인지 모른다
• POST로 주문을 넣었는데 서버가 "이미 처리됨"이라고만 한다
  • 멱등·안전 메서드 차이를 모르면 API 설계가 꼬인다
• 404와 500을 둘 다 "에러"로만 본다
  • 클라이언트 문제인지 서버 문제인지 구분이 안 된다
• 로그인 후 두 번째 요청에도 매번 쿠키를 보낸다
  • HTTP는 세션을 기억하지 않는다는 말의 의미가 불명확하다

앞서 소켓 위에서 앱이 메시지를 주고받는다고 봤다. 웹·API의 사실상 표준인 HTTP 메시지 형식부터 잡는다.

1. HTTP란

HTTP(HyperText Transfer Protocol) 는 웹·REST API에서 쓰는 애플리케이션 계층 프로토콜이다.

특징	설명
클라이언트-서버	클라이언트가 요청, 서버가 응답
텍스트 기반(1.x)	요청/응답이 읽을 수 있는 형식 (HTTP/2는 프레임화)
기본 전송	대부분 TCP 위 (포트 80/443)
무상태	서버가 이전 요청 맥락을 기본적으로 저장하지 않음

• URL의 https://host/path?query 중 path·query가 요청 대상
• https는 HTTP 위에 TLS를 얹은 것 (별도 편에서 TLS 상세)

2. 요청과 응답 흐름

한 번의 HTTP 교환은 요청 메시지 하나와 응답 메시지 하나로 이루어진다.

Client                              Server
  |  TCP connect (e.g. port 443)        |
  |------------------------------------>|
  |  HTTP Request                       |
  |------------------------------------>|
  |  HTTP Response                      |
  |<------------------------------------|
  |  (connection may stay open)         |

• HTTP/1.1 Keep-Alive면 같은 TCP 연결에서 여러 요청 가능 (다음 편에서 상세)
• 브라우저·curl은 소켓 연결 후 HTTP 메시지를 직렬화해 보낸다

curl -v http://example.com/ 2>&1 | head -30
# > GET / HTTP/1.1
# > Host: example.com
# < HTTP/1.1 200 OK

3. 메시지 구조

HTTP 메시지는 시작줄(start line), 헤더, 빈 줄, 본문(body) 로 구성된다.

요청 (Request)

부분	예	역할
요청줄	GET /api/users HTTP/1.1	메서드, 경로, 버전
헤더	Host: api.example.com	메타데이터 (인증, 타입, 길이 등)
본문	JSON, form data	POST/PUT 등에서 페이로드 (GET은 보통 없음)

응답 (Response)

부분	예	역할
상태줄	HTTP/1.1 200 OK	버전, 상태 코드, reason phrase
헤더	Content-Type: application/json	캐시, 쿠키, 길이 등
본문	HTML, JSON	실제 리소스 표현

• Content-Length 또는 Transfer-Encoding: chunked로 본문 경계 결정
• 헤더 이름은 대소문자 무관 (HTTP/2는 소문자 권장)

4. HTTP 메서드

메서드는 리소스에 대한 의도를 나타낸다. REST API 설계의 기준이 된다.

메서드	일반적 용도	안전	멱등
GET	조회	예	예
HEAD	메타만 조회 (본문 없음)	예	예
POST	생성·비멱등 동작	아니오	아니오
PUT	전체 교체·생성	아니오	예
PATCH	부분 수정	아니오	아니오
DELETE	삭제	아니오	예

• 안전(safe): 서버 상태를 바꾸지 않아야 함 (GET은 데이터 읽기만)
• 멱등(idempotent): 같은 요청을 여러 번 해도 결과가 같아야 함
  • POST 결제 두 번 = 이중 청구 위험 → Idempotency-Key 등 앱 레벨 보완
• 실제 서버는 메서드 규칙을 강제하지 않는 경우도 있어, API 문서·계약이 중요

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 28

{"item_id":1,"qty":2}

5. 상태 코드

서버는 3자리 상태 코드로 결과를 요약한다.

범주	의미	대표 코드
1xx	정보	100 Continue
2xx	성공	200 OK, 201 Created, 204 No Content
3xx	리다이렉션	301 Moved, 302 Found, 304 Not Modified
4xx	클라이언트 오류	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	서버 오류	500 Internal Error, 502 Bad Gateway, 503 Service Unavailable

• 4xx — 요청 형식·권한·리소스 문제 → 클라이언트·호출 측 점검
• 5xx — 서버·업스트림 장애 → 로그·헬스체크·롤백
• 502/503은 로드 밸런서·게이트웨이 뒤 장애에서 자주 보인다

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/

6. 무상태성 (Stateless)

HTTP 서버는 요청 하나하나를 독립으로 처리한다. 이전 요청에서 누가 로그인했는지 기본적으로 모른다.

	Stateless HTTP	Stateful (대비)
서버 기억	요청마다 필요 정보를 다시 받음	연결·세션에 상태 유지
확장	아무 서버가 요청 처리 가능 (수평 확장 용이)	특정 서버에 세션 고정(sticky) 필요할 수 있음
인증 보완	쿠키, Bearer 토큰, 세션 ID를 매 요청에 실어 보냄	서버 메모리/Redis에 세션

• "무상태"는 HTTP 프로토콜 이야기 — 앱은 Redis·DB에 세션을 둘 수 있음
• 로그인 유지 = 클라이언트가 쿠키/토큰을 보내고, 서버가 그걸 검증하는 패턴

7. 정리

• HTTP는 요청/응답 메시지로 리소스에 접근하는 애플리케이션 프로토콜
• 시작줄 + 헤더 + 본문 구조를 읽을 수 있어야 curl -v·프록시 로그를 해석할 수 있다
• 메서드는 의도, 상태 코드는 결과 범주 — API·운영 디버깅의 공통 언어
• 무상태라서 확장에 유리하고, 인증·세션은 앱·헤더로 보완한다

다음에 다룰 것

• HTTP 심화
• Keep-Alive, 쿠키·세션, 캐시, REST 관점

---

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