[1D1Q | Network] HTTP(Hypertext Transfer Protocol)

1일 1질문으로 개발자가 되어보자. (One Day One Question)

분야: 네트워크

주제: HTTP(Hypertext Transfer Protocol)

---

 

HTTP(Hypertext Transfer Protocol)

 

잘 알고 있는지

 

- 보통

 

내가 아는 만큼 설명

 

주소창에 주소를 입력하면 브라우저가 해당 주소를 찾고,

서버에 요청을 보내서 HTML, CSS, JS 같은 파일을 받아온다.

그 후 브라우저가 화면에 보여준다.

- HTTP는 Hypertext Transfer Protocol, 클라이언트 요청과 서버 응답으로 이루어지는 통신 프로토콜이다.

- 다양한 버전이 있다.

- Stateless이다.

- 스니핑 당할수 있다.(그래서 HTTPS 쓴다)

- 메서드로는 GET, POST, PATCH, PUT, DELETE 등이 있다. 각각 CRUD. 그중 Update는 PATCH가 일부, PUT이 전체.

- 상태코드로는 200번대 = 잘됐다. 300번대 = (잘 기억 안남), 400번대 = 클라이언트 에러, 500번대 = 서버 에러.

- 그 중에서 대표적으로 기억나는건 200 ok, 404 not found, 403 unathorized...?

- 상태코드 공부하자.

- 멱등성???

 

답을 본 뒤 알게 된 것

 

HTTP 정리 요약 — HTTP는 요청/응답 기반의 stateless 애플리케이션 계층 프로토콜. 오늘은 그 "문법"인 메서드 · 상태코드 · 버전 · 메시지 구조를 판다.

1. HTTP 메서드 + 멱등성/안전성

주요 메서드 & CRUD 대응

GET = Read (조회, 바디 없음이 원칙)
POST = Create (새 리소스 생성, 서버가 처리 방식 결정)
PUT = Update 전체 교체 (리소스 전체를 보낸 것으로 덮어씀)
PATCH = Update 부분 수정 (바뀐 필드만 보냄)
DELETE = Delete (삭제)
부가: HEAD(GET인데 헤더만), OPTIONS(허용 메서드·CORS 확인)

안전(Safe): 서버 상태를 바꾸지 않는 메서드. → GET, HEAD, OPTIONS

멱등(Idempotent): 같은 요청을 여러 번 보내도 결과(서버 상태)가 같은 것.
멱등 O: GET, PUT, DELETE, HEAD, OPTIONS
멱등 X: POST (보낼 때마다 새 리소스가 계속 생김), 보통 PATCH도 X로 봄
왜 중요? 네트워크 오류로 재시도(retry)할 때, 멱등하면 안심하고 다시 보낼 수 있음. POST 재시도는 중복 생성 위험 → 그래서 결제 같은 데서 "중복 방지 키(idempotency key)"를 씀.
헷갈림 방지: DELETE는 멱등 (첫 요청에 지워지고, 두 번째는 404여도 "이미 없음"이라는 최종 상태는 동일). 멱등은 "상태가 같음"이지 "응답 코드가 같음"이 아님.

1. 상태 코드 (Status Code)

대역 의미
1xx 정보 (거의 안 봄, 100 Continue 등)
2xx 성공 — 200 OK, 201 Created(POST로 생성됨), 204 No Content(성공했지만 바디 없음)
3xx 리다이렉션
301 Moved Permanently (영구 이동, SEO·북마크 갱신)
302 Found (임시 이동)
304 Not Modified (캐시 그대로 써라 — 조건부 요청)
4xx 클라이언트 에러
400 Bad Request (요청 자체가 잘못됨)
401 Unauthorized = 인증 안 됨 (너 누구야? 로그인부터 해)
403 Forbidden = 인가 안 됨 (누군지 알지만 권한 없음)
404 Not Found (리소스 없음)
405 Method Not Allowed, 429 Too Many Requests(레이트 리밋)
5xx 서버 에러
500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

1. HTTP 버전

HTTP/1.0: 요청 하나당 TCP 연결 하나 → 매번 연결 맺고 끊음 (비쌈).
HTTP/1.1: Keep-Alive(연결 재사용)가 기본. 단, HOL 블로킹(Head-of-Line: 앞 요청이 막히면 뒤가 다 대기)이 남음. 파이프라이닝은 사실상 실패.
HTTP/2: 멀티플렉싱 — 하나의 연결에서 여러 요청/응답을 동시에 주고받음(스트림). 헤더 압축(HPACK), 서버 푸시. HTTP 레벨 HOL은 해결했지만 TCP 레벨 HOL은 남음(패킷 하나 유실되면 전체 대기).
HTTP/3: 전송을 TCP → QUIC(UDP 기반)로 교체. TCP HOL 블로킹까지 해결, 연결 수립도 더 빠름(0-RTT/1-RTT). TLS 1.3 내장.
한 흐름으로: 연결 재사용(1.1) → 멀티플렉싱(2) → TCP 탈출(3).

1. 메시지 구조 & 주요 헤더

요청 메시지 = 시작줄(GET /path HTTP/1.1) + 헤더들 + 빈 줄 + (선택)바디
응답 메시지 = 상태줄(HTTP/1.1 200 OK) + 헤더들 + 빈 줄 + 바디

자주 나오는 헤더
요청: Host, User-Agent, Accept, Authorization(토큰), Cookie, Content-Type
응답: Content-Type, Content-Length, Set-Cookie, Cache-Control, Location(리다이렉트 목적지)

stateless 보완: 서버가 상태를 기억 안 하므로 Cookie/Authorization 헤더로 매 요청마다 신원을 실어 보냄.

 

틀렸거나 부족했던 부분

 

- 403, 401, 멱등성. (공부한 것 복붙)

 

- 멱등성이란게 나옴 같은 연산을 하면 상태나 결과는 항상 같은거

- f(f(x)) = f(x).

 

- 여기서 GET(당연), PUT(당연), DELETE(몇번 하든 없어진다는 결과는 같음) = 안전하다. 멱등하다.

 

- POST와 PATCH는 멱등하지 않다 = 안전하지 않다고 본다.

 

- 여기서 안전이란건, 위험하다기보다는, 재시도해도 되느냐를 묻는다.

 

- 이를테면 DELETE를 쓸 때,

- 서버에 요청이 전달되어 삭제된후,

- 클라이언트로 삭제 잘 되었다는 응답 전달에 실패했다고 하자.

 

- 그러면 클라이언트는 모르니까 재전송 할 수 있다.

- 그러나 이미 삭제되었기 때문에 이런 행위는 안전하다고 간주하는 것이다.

- 서버 상태는 그대로라는 점에서도 그렇다.

 

- POST는, 아니다. 게시판에 글을 쓸때, 재전송을 하게 되면 글이 2개가 생긴다.

- 글이 3개가 생긴다, 4개가 생긴다. 이는 같은 서버 상태라고 볼 수 없다. 그렇기 때문에 멱등하지 않다.

- 그렇기 때문에 ‘중복방지 키’를 사용한다. HTTP 요청 헤더에 위치한다. Idempotency-Key. PG사 연동 시 볼 수 있다.

 

- POST /orders

- Idempotency-Key: a1b2c3-유니크한-랜덤값

- { "item": "커피", "price": 4500 }

 

- 서버의 동작:

 

1. 요청 오면 Idempotency-Key 값을 봄.

2. 처음 보는 키 → 정상 처리하고, "이 키 = 이 결과"를 저장(보통 Redis/DB).

3. 이미 본 키 → 재처리 안 하고, 저장해둔 그때 결과를 그대로 반환.

 

- PATCH는, 미묘하다. “이 값으로 설정해” -> 멱등, “이 값만큼 변화시켜” -> 비-멱등.

  그렇기 때문에 PATCH에 버전 검사(if-Match / ETag)를 붙이기도 한다.

 

면접용 1분 답변

 

⭐ 단골 질문 (거의 나옴 — 우선순위)

 

1. "멱등성이 뭔가요? 어떤 메서드가 멱등한가요?"

 

- 멱등성이란 같은 행위의 원인으로 같은 결과를 보장하는 성질입니다. HTTP 메서드에서, GET, PUT, DELETE 등이 멱등성을 보장하며, POST와 PATch는 멱등을 보장하지 않아요.

 

2. "GET과 POST의 차이는?"

 

- GET은 요청에 Body가 없고, POST는 Body가 있네요.

 

3. "401과 403의 차이는?"

 

- 401은 Unauthorized, 인증되지 않은 사용자를 거부하는 상태코드입니다.

- 403은 Forbbiden, 인가되지 않은 사용자를 거부하는 상태코드입니다.

 

🔹 자주 나오는 질문

 

4. "HTTP 버전별 차이 / HTTP/2가 1.1보다 나은 점?"

 

- HTTP/1.1은 연결을 재사용(Keep-Alive)하지만, 한 연결에서 앞 요청이 막히면 뒤가 다 기다리는 HOL 블로킹이 있습니다. HTTP/2는 멀티플렉싱으로 한 연결에서 여러 요청·응답을 동시에 주고받아 이 문제를 해결하고, 헤더 압축도 지원합니다. HTTP/3는 전송을 TCP에서 UDP 기반 QUIC으로 바꿔 TCP 레벨의 HOL 블로킹까지 없애고 연결 수립도 더 빠릅니다.

 

5. "REST API에서 상태 코드를 어떻게 설계하나요?" 또는 "201과 200의 차이?"

 

- 성공도 상황별로(200/201/204), 실패도 상황별로(400/401/403/404). "왜 잘 써야 하나 = 클라가 코드만 보고 판단"

 

6. "HTTP는 stateless인데 로그인 상태는 어떻게 유지하나요?"

 

- 쿠키/세션/JWT를 이용합니다.

 

🔸 가끔/심화

 

7. "PUT과 PATCH의 차이?" (전체 교체 vs 부분 수정 + 멱등성)

 

- PUT은 전체를 교체하

 

한 줄 요약

 

- HTTP 정의(요청/응답 기반 stateless 프로토콜), 구조(시작줄+헤더+빈줄+바디), 메서드(GET·POST·PUT·PATCH·DELETE)와 안전성/멱등성(멱등=여러 번 보내도 최종 상태 동일, 재시도 안전성 기준 / GET·PUT·DELETE는 멱등, POST는 X → 중복방지 키), 상태코드(2xx 성공·3xx 리다이렉트·4xx 클라 잘못·5xx 서버 잘못, 401 인증 vs 403 인가), 버전(1.1 연결재사용 → 2 멀티플렉싱 → 3 QUIC/UDP)까지.