0-RTT 고속 핸드셰이크가 일회성 트랜잭션을 보장하지 않는 이유

요약

0-RTT 데이터 수용은 전송 계층의 결정을 입증할 뿐, 비즈니스 작업이 정확히 한 번 커밋되었음을 입증하지는 않는다.
안전한 배포에는 조기 데이터 처리, 재시도 경로, 재생 방지 범위, 권위 있는 커밋 결과를 함께 연결한 애플리케이션 수준의 영수증이 필요하다.

클라이언트가 서비스를 프로비저닝하기 위해 연결을 재개한다고 상상해 보자. 클라이언트는 핸드셰이크가 완료되기 전에 POST를 보낸다. 한 엣지는 조기 데이터를 수용하지만, 응답이 중단되면서 클라이언트나 중개자가 다른 엣지를 통해 재시도한다. 대시보드에는 빠른 연결과 성공적인 응답이 기록된다. 해결되지 않은 질문이야말로 핵심이다. 애플리케이션이 서비스 인스턴스를 하나 만들었는가, 아니면 둘 만들었는가?

이 시나리오는 특정 공급자에 대한 의혹이 아니다. 이는 표준이 그리는 경계에서 직접 따라 나온다. TLS 1.3은 클라이언트와 서버가 재개 자료를 공유할 때 조기 데이터를 허용하지만, RFC 8446은 0-RTT가 일반 애플리케이션 데이터보다 보안 속성이 약하다고 말한다. 특히 연결 간 재생이 없음을 보장하지 않는다. 하나의 연결 안에서는 레코드를 단순히 복제해 두 번 수용할 수 없지만, 분산 서비스 시스템 전반에서는 증거 문제가 달라진다.

배포 전체에 걸친 강력한 재생 방지는 이미 무엇이 수용되었는지에 대한 공통된 개념을 필요로 한다. RFC 8446은 최근에 본 ClientHello 정보를 보관하거나 다른 방식으로 재생 방지 상태를 조정하는 접근법을 설명한다. 또한 모든 배포가 전 세계적으로 일관된 상태를 유지하는 것은 아니라는 운영상 어려움도 인정한다. 따라서 한 엔드포인트에서 수용된 티켓은 그 엔드포인트가 조기 데이터를 받아들였다는 사실을 말해 줄 수 있지만, 다른 엔드포인트가 동일한 논리적 작업을 받아들일 수 없었다는 점을 입증하지는 못한다.

QUIC도 이 책임을 시야 밖으로 옮기지 않는다. RFC 9001은 0-RTT와 함께 수신된 애플리케이션 데이터로 인해 애플리케이션이 이를 여러 번 처리할 수 있다고 경고한다. 이는 애플리케이션 프로토콜이 허용 가능한 사용과 재생 완화책을 정의하도록 요구한다. 완료된 핸드셰이크는 의미가 있다. 즉, 인증을 수행하고 연결 상태를 수립한다. 그러나 그렇다고 해서 이전의 애플리케이션 작업이 소급해 일회성 트랜잭션이 되지는 않는다.

HTTP는 필요한 신호를 추가한다. RFC 8470은Early-Data: 1을 정의하여 이전 홉에서 조기 데이터로 전송된 요청이 중개자를 거치면서도 그 사실을 유지할 수 있게 한다. 서버는 자체 핸드셰이크가 끝나기를 기다리는 것만으로 그러한 요청을 안전하게 만들 수 없다. 잠재적으로 재생된 요청을 처리할 위험을 감수하지 않으려면425 Too Early를 반환할 수 있으며, 이후 재시도는 핸드셰이크가 끝난 뒤 전송된다.

이 통제는 신호가 경로 전체에서 살아남고 애플리케이션이 해당 메서드의 동작을 이해할 때만 유용하다. RFC 9110은 여러 동일한 요청이 하나의 요청과 같은 의도된 효과를 낼 때 그 메서드를 멱등적이라고 부른다. 안전한 메서드는 멱등적이며, PUT과 DELETE도 멱등적이지만 안전하지는 않다. POST는 클라이언트가 멱등성 키를 붙였다는 이유만으로 멱등성 의미를 얻지 않는다. 반대로 애플리케이션은 특정 POST를 재시도 안전으로 정의할 수 있지만, 키의 범위, 보존 기간, 충돌 규칙, 권위 있는 결과가 실제 운영 통제일 때만 그렇다.

실무적 실수는 잘못된 계층을 측정하는 것이다. 0-RTT 수용 카운터는 지연 시간 경로 사용을 측정한다. TLS 또는 QUIC 핸드셰이크 로그는 연결 상태를 측정한다. HTTP 상태는 하나의 응답 경로를 기록한다. 어느 것도 내구성 있는 애플리케이션 커밋이 몇 번 발생했는지, 재시도가 다른 재생 도메인에 도달했는지, 또는 부작용이 리소스 트랜잭션을 벗어났는지를 독립적으로 입증하지 못한다.

수용 기록은 이 계층들을 하나의 사건인 척하지 않으면서 연결해야 한다. 중대한 상태 변경 요청의 경우 요청 식별자 또는 멱등성 키, 메서드와 대상, 재개 및 조기 데이터 결정, 엣지·오리진·재생 방지 도메인, Early-Data 신호의 전파, 425 응답과 재시도 여부, 애플리케이션 트랜잭션 식별자, 권위 있는 커밋 횟수와 결과를 기록한다. 비밀 정보는 기록에 포함되어서는 안 되지만, 그 수용을 규율하는 범위는 포함되어야 한다.

목적은 0-RTT를 금지하는 것이 아니다. 읽기 전용 작업과 의도적으로 재생을 허용하는 작업은 0-RTT의 이점을 누릴 수 있다. 목적은 지연 시간 최적화가 감당할 수 없는 보증 주장을 물려받지 않게 하는 것이다.