이 사이트의 실습은 자바스크립트를 켜야 움직입니다. 아래는 같은 내용을 글로 적은 것입니다.
공부 › 네트워크 › HTTP
재시도와 멱등성
응답을 못 받아서 다시 보냈더니
네트워크에서는 요청이나 응답이 사라질 수 있고, 클라이언트는 응답이 없으면 같은 요청을 다시 보냅니다. HTTP 메서드에 따라 여러 번 실행돼도 결과가 같은 것(멱등)과 그렇지 않은 것이 있습니다.
문서·표준 대조 · HTTP 표준(RFC 9110)
이 실습에 나오는 개념
- 안전한 메서드와 멱등한 메서드
- 안전한 메서드는 서버의 상태를 바꾸지 않는 읽기 전용 메서드로 GET, HEAD, OPTIONS, TRACE가 해당한다. 멱등한 메서드는 같은 요청을 여러 번 보내도 서버에 미치는 효과가 한 번 보낸 것과 같은 메서드로, 안전한 메서드 전부와 PUT, DELETE가 해당한다. POST와 PATCH는 멱등이 보장되지 않아 두 번 보내면 두 번 처리될 수 있다. 응답을 받지 못했을 때 다시 보내도 되는지를 판단하는 기준이 된다.
- HTTP 메서드
- 요청이 자원에 대해 수행하려는 동작을 나타낸다. GET은 조회, POST는 생성이나 처리 요청, PUT은 전체 교체, PATCH는 일부 수정, DELETE는 삭제를 뜻한다. 메서드의 의미에 맞게 사용해야 캐시, 재시도 같은 HTTP의 동작이 기대대로 이뤄진다.
- 멱등성과 멱등키
- 멱등성은 같은 요청을 여러 번 수행해도 결과가 한 번 수행한 것과 같은 성질이다. 네트워크 문제로 같은 요청이 다시 전송될 수 있으므로, 결제처럼 중복되면 안 되는 작업은 멱등하게 만들어야 한다. 멱등키는 클라이언트가 요청마다 붙이는 고유한 값으로, 서버는 이미 처리한 키의 요청이 다시 오면 다시 처리하지 않고 이전 결과를 돌려준다.
- HTTP 상태 코드
- 서버가 요청을 처리한 결과를 나타내는 세 자리 숫자다. 2xx는 성공, 3xx는 다른 위치로의 이동(리다이렉션), 4xx는 클라이언트의 요청에 문제가 있음, 5xx는 서버 쪽 오류를 뜻한다. 200(성공), 201(생성됨), 400(잘못된 요청), 401(인증 필요), 403(권한 없음), 404(없음), 500(서버 오류)이 자주 쓰인다.
이렇게 바꿔 보세요
- 처음 설정으로 — POST의 응답이 한 번 사라집니다. 주문이 두 건 만들어집니다.
- 같은 상황에서 PUT — 두 번 실행돼도 결과는 한 번 실행한 것과 같습니다.
- DELETE를 다시 보내면 — 두 번째 응답 코드는 다르지만 서버 상태는 같습니다.
- 증가시키는 PATCH — 재시도한 만큼 수량이 더 올라갑니다.
- POST에 멱등키를 붙이면 — 서버가 같은 요청임을 알아보고 한 번만 처리합니다.
- 요청이 사라진 경우 — 서버가 처리한 적이 없으므로 재시도해도 문제없습니다.
처음 설정으로 실행하면
- 처음 서버 상태입니다. 주문 1(마우스, 수량 2)이 있습니다.
- 첫 요청: 서버가 요청을 처리했습니다(201 Created (주문 2)). 그런데 응답이 돌아오는 길에 사라졌습니다. 클라이언트는 서버가 처리했는지 알 수 없어서 같은 요청을 다시 보냅니다.
- 1번째 재시도: 서버가 요청을 처리하고 201 Created (주문 3) 응답을 돌려줍니다. 이번에는 응답이 클라이언트에 도착했습니다.
실행 결과
- POST는 멱등하지 않습니다. 실행될 때마다 새 주문이 생겨서 같은 주문이 2건 만들어졌습니다. 결제나 주문에서 중복 처리가 생기는 전형적인 경로입니다.
코드
POST /orders HTTP/1.1
Content-Type: application/json
{ "item": "키보드", "quantity": 2 }
// 클라이언트: 응답이 3초 안에 오지 않으면
// 같은 요청을 그대로 다시 보낸다
이 모형의 전제
멱등성의 정의는 HTTP 표준(RFC 9110)을 따랐습니다. 같은 요청을 여러 번 보냈을 때 서버에 의도한 효과가 한 번 보낸 것과 같으면 멱등이며, GET·HEAD·OPTIONS·TRACE(안전한 메서드)와 PUT·DELETE가 여기에 속합니다. POST와 PATCH는 표준상 멱등이 보장되지 않습니다(PATCH는 내용에 따라 멱등하게 설계할 수도 있습니다). Idempotency-Key 헤더는 결제 API 등에서 널리 쓰이는 관례이며, 아직 표준으로 확정된 것은 아닙니다.
앞 실습: HTTP 캐시와 ETag · 다음 실습: 리다이렉션