TLS 1.3 early data와 QUIC 0-RTT는 연결 재개를 빠르게 하지만, 암호화된 요청을 한 번만 처리한다는 애플리케이션 보장을 제공하지 않습니다. 동일 요청이 여러 실행 경계에 도착할 수 있다는 전제에서, 비멱등 효과를 정상 handshake 뒤로 미루거나 권위 상태의 안정된 멱등 키로 한 번만 확정해야 합니다.
암호화 주문과 중복 처리 가능성
이전 연결 정보를 사용해 핸드셰이크 완료 전에 요청을 보내면 재연결 지연을 줄일 수 있습니다. TLS 1.3 early data와 이를 사용하는 QUIC의 0-RTT가 제공하는 이점입니다. 그러나 early data에는 재생 가능성이라는 별도 조건이 있습니다. 기밀성과 무결성이 있다고 논리 요청이 한 번만 실행되는 것은 아닙니다.
같은 주문 변경이 두 서버에서 수락되면 암호문이 변조되지 않았어도 재고가 두 번 줄 수 있습니다. 클라이언트가 요청을 한 번 만들었다는 사실과 서버가 한 번만 적용했다는 보장은 서로 다릅니다.
주문 요청에 account·order·operation으로 만든 키를 붙였다고 하겠습니다. 서버 A가 효과와 dedupe 기록을 같은 거래로 확정하면, 서버 B가 같은 early data를 받아도 기존 결과를 반환할 수 있습니다. 반대로 기록만 먼저 남기고 실제 차감을 나중에 하면 중단 지점에서 차감 누락이 생기므로 두 경계를 분리하지 않습니다. 서버가 early data를 거절한 뒤에는 같은 논리 요청을 handshake 완료 후 재전송해야 하며 새 주문 ID를 만들지 않습니다.
허용 API와 실제 부수 효과 분류
| 작업 | 판단할 것 | 선택 예 |
|---|---|---|
| 순수 공개 조회 | 반복해도 민감 효과가 없는가 | 정책 아래 early data 허용 |
| 최초 조회 보상 지급 | GET이지만 상태 변경이 있는가 | early data 거절 또는 효과 멱등화 |
| 주문·결제 생성 | 중복 변경·외부 결제가 가능한가 | 정상 handshake 뒤 처리 우선 |
| 같은 논리 변경 재시도 | 안정적 키·거래·결과 보관이 있는가 | 검증된 범위에서만 허용 |
GET이라는 메서드 이름만으로 안전하다고 보지 않습니다. 분석 카운터 같은 부수 효과도 반복에 대한 허용 범위를 따로 정합니다. PUT이 멱등 메서드로 분류된다고 해서 앱 내부의 알림 발송·차감까지 자동으로 한 번이 되는 것도 아닙니다.
anti-replay 상태의 공유 범위와 수락 조건
anti-replay 상태는 같은 early data를 다시 받아들이지 않도록 재수락 여부를 기록하고 거절하는 데 쓰입니다. 그 상태가 한 프로세스 메모리에만 있으면 다른 지역 서버나 재시작한 서버가 같은 ticket을 다시 받을 수 있으므로, ticket을 어디까지 수락하는지, 상태를 어디와 얼마나 오래 공유하는지, 시계와 장애 시 정책이 무엇인지가 실제 보장 범위를 정합니다.
특정 TLS 라이브러리에 anti-replay 기능이 있어도 그 기능이 전체 다중 지역 서비스의 모든 실행 경계에 동일한 효과를 준다고 볼 수는 없습니다.
그림을 글로 읽기
- 동일한 early data
- 서버 A
- 서버 B
- 권위 상태·논리 요청 키: 효과와 결과를 원자 확정
- 동일한 early data → 서버 A: 첫 전달
- 동일한 early data → 서버 B: 재생 가능
- 서버 A → 권위 상태·논리 요청 키: 같은 논리 키
- 서버 B → 권위 상태·논리 요청 키: 같은 논리 키
업무 멱등 키는 같은 논리 요청을 다시 만났을 때 결과를 한 번만 확정하기 위한 값이므로, 주체·대상·입력과 결합해 만듭니다. 이미 처리했는지 적는 dedupe 기록과 실제 상태 변경을 같은 거래로 확정하지 않으면, 기록만 남거나 변경만 남는 중단 뒤 재시도에서 중복 효과가 생길 수 있습니다. 같은 키에 다른 입력이 들어오면 거절하고, 키 기록이 만료된 뒤 오래된 요청을 다시 받아들일지도 별도 정책으로 정합니다.
Early data 거절과 동일 논리 요청 유지
서버가 early data를 거절하면 클라이언트는 핸드셰이크 완료 뒤 정상 요청으로 재시도할 수 있습니다. HTTP의 425 Too Early를 사용하는 경로도 구현·프록시 지원과 함께 확인합니다. 거절 후 retry가 또 early data로 나가지 않도록 해야 하며 새 논리 주문을 생성해서는 안 됩니다.
일부 처리 여부가 불확실하면 안정된 요청 키와 결과 조회로 복구합니다. 전송 계층이 거절했다고 알려 주는 정확한 단계와 애플리케이션이 이미 처리했는지를 섞지 않습니다. 비멱등 변경은 처음부터 정상 handshake 뒤에만 처리하고 지연은 연결 재사용·다른 최적화로 줄이는 선택이 더 단순할 수 있습니다.
재생·재시작·거절 후 재시도 시험
관리하는 격리 환경에서 동일 요청의 반복 전달, 두 서버 수락, anti-replay 상태 재시작, early data 거절 후 일반 요청을 재현합니다. 최종 원장과 외부 부수 효과가 정책대로 한 번인지 확인합니다. 단순 HTTP 성공 응답 수와 논리 효과 수를 구분합니다.
허용 API 목록·전송 라이브러리·배포 토폴로지·멱등 기록 보관 범위를 문서화합니다. 이 노트는 보장 범위 설명이며 실제 QUIC 서버에 재생 트래픽을 실행한 결과는 아닙니다.