요약

  • RFC 9298은 UDP에 연결 핸드셰이크가 없기 때문에 UDP 프록시가 목적지의 패킷을 기다리지 않고 응답하도록 요구합니다. 성공은 프록시가 요청된 대상을 향해 소켓을 열었고 페이로드 전달을 수용할 의사가 있음을 의미합니다.
  • 이 응답 수신은 대상 도달 가능성, 페이로드 전달, 애플리케이션 신원, 애플리케이션 수용 또는 지속적인 양방향 서비스를 확립하지 않습니다. DNS 확인, 소켓 상태, 데이터그램 이동, 내부 프로토콜 결과에는 별도의 근거가 필요합니다.
  • David Schinazi가 여기서 남긴 가장 유용한 기여는 더 넓은 약속이 아니라 명확한 한계 설정입니다. 운영자는 표준이 구분하는 '프록시가 한 일'과 '목적지가 아직 증명하지 못한 것'의 구분을 지키면 더 나은 자동화를 구축할 수 있습니다.

초록 불은 프록시에게 속합니다

한 줄짜리 모니터링 패널을 상상해 보십시오.CONNECT-UDP 200 — 정상. HTTP 교환이 성공했습니다. URI가 호스트와 포트를 지정했습니다. 프록시가 요청을 수락했습니다. 그러나 상태가 초록으로 바뀐 그 순간, 목적지는 오프라인이거나, 필터링되었거나, 블랙홀 처리되었거나, 다른 포트에서 대기 중이거나, 단지 설계상 침묵하고 있을 수도 있습니다.

표준과 모순되는 것은 없습니다. 대시보드가 프록시의 진술을 잘못된 증인에게 배정했을 뿐입니다.

RFC 9298은 UDP를 HTTP 프록시를 통해 전달하는 방법을 정의합니다. 클라이언트는target_host와target_port를 담은 절대 URI 템플릿으로 구성됩니다. 클라이언트는 프록시에 CONNECT-UDP 요청을 보내고, HTTP 버전에 따라 Extended CONNECT 또는 HTTP Upgrade를 사용하며, HTTP 데이터그램이 UDP 페이로드를 운반합니다. 프록시는 요청된 대상을 재구성하고 그 대상을 향해 UDP 소켓을 엽니다.

TCP는 일반적으로 애플리케이션 터널이 데이터를 이동시키기 전에 핸드셰이크를 제공합니다. UDP는 그렇지 않습니다. UDP 소켓을 여는 것은 로컬 운영체제 상태를 만들 뿐, 원격 엔드포인트로부터 SYN-ACK이나 그에 상응하는 동의를 끌어내지 않습니다. 따라서 RFC 9298은 프록시가 소켓을 열 때 목적지가 도달 가능한지 알 방법이 없으며 목적지 패킷을 기다리지 않고 응답해야 한다고 말합니다.

이 문서는 이어서 성공 응답을 특이할 만큼 정직하게 정의합니다. 이 응답은 프록시가 요청된 대상으로 소켓을 열었고 UDP 페이로드를 프록시할 의사가 있음을 나타냅니다. 모든 명사가 중요합니다. 행위자는 프록시입니다. 완료된 행위는 소켓 열기입니다. 정책 결정은 전달 의사입니다. 도달 가능성, 수신, 애플리케이션 결과는 존재하지 않습니다.

이 협소함은 낙관적인 언어로 수리해야 할 결함이 아닙니다. 그것은 연결 없는 프로토콜의 정확한 경계입니다.

이름이 확인되어도 서비스는 여전히 알 수 없을 수 있습니다

RFC 9298은 대상이 DNS 이름일 때 응답 전에 한 가지 조건을 둡니다. 프록시는 그 이름을 확인해야 합니다. DNS 오류가 발생하면 요청을 거부해야 하며, 프록시는 RFC 9209의Proxy-Status필드가 제공하는dns_error어휘를 사용할 수 있습니다.

확인은 근거를 추가하지만, 특정 종류의 근거만 추가합니다. 특정 시점의 캐시와 정책 아래에서 리졸버가 주소 결과를 산출했음을 보여줄 수 있습니다. 그러나 그 주소가 의도한 애플리케이션을 호스팅하는지, 애플리케이션이 트래픽을 수용 중인지, 매핑이 터널 수명 동안 나중에도 유효할지는 보여줄 수 없습니다.

유용한 수신(receipt)은 입력된 이름, 선택된 주소, 주소 패밀리, 확인 시점, 캐시 또는 TTL 맥락을 기록합니다. 또한 소켓에 실제로 바인딩된 피어 튜플도 기록합니다. "DNS 성공"과 "대상 응답"은 서로 다른 두 개의 필드로 남아야 합니다.

소켓이 열린 후 이름이 바뀌면 이 구분은 더 선명해집니다. 기존 소켓은 권위 있는 DNS가 변경되었다는 이유만으로 새 주소로 자동 이동하지 않습니다. 이름만 표시하는 운영자는 패킷이 여전히 이전 결과로 이동하고 있음에도 오래된 목적지 상태와 새 목적지 상태가 연속적인 것처럼 보이게 만들 수 있습니다.

RFC 9209는 더 많은 부정적 어휘를 제공합니다. 프록시는 목적지가 사용 불가, 금지, 라우팅 불가임을 알 수 있습니다. 그러한 관찰은 가치가 있습니다. 그러나 기록된 오류의 부재를 긍정적 증명으로 뒤집을 수는 없습니다. ICMP가 도착하지 않을 수 있습니다. 방화벽이 패킷을 조용히 버릴 수 있습니다. 애플리케이션이 문법적으로 유효하지 않은 데이터그램을 응답 없이 폐기할 수 있습니다. 침묵에는 많은 원인이 있고 단일한 의미는 없습니다.

소켓은 원격 주소를 가진 로컬 사실입니다

"요청된 대상으로 소켓을 열었다"는 표현은 대상을 포함하고 있어 종단 간처럼 들립니다. 운영적으로, 소켓은 프록시의 호스트가 소유한 상태입니다.

운영체제가 connected UDP 소켓을 지원하면, 프록시는 이를 사용해 커널이 기대되는 5-튜플과 일치하는 데이터그램만 반환하도록 할 수 있습니다. non-connected 소켓을 사용한다면, RFC 9298은 출발지 IP 주소와 UDP 출발지 포트의 명시적 검사를 요구하고 불일치는 폐기해야 합니다. 이는 중요한 스푸핑 방지 경계입니다.

그러나 이는 애플리케이션 인증이 아닙니다. 요청된 주소와 포트에 일치하는 데이터그램이 여전히 인증되지 않았거나 재생되었거나 무의미한 페이로드를 담을 수 있습니다. 내부 프로토콜—QUIC, DNS, 게임 전송 계층 또는 그 밖의 것—은 피어 신원과 무엇이 수용으로 인정되는지를 정의해야 합니다.

소켓 수명은 HTTP 요청 스트림에 묶여 있습니다. 프록시는 스트림이 열려 있는 동안 소켓을 유지하고, 소켓이 사용 불가능해지면 스트림을 닫습니다. ICMP Destination Unreachable 같은 운영체제 알림이 그 전환을 만들 수 있습니다. 비활성도 폐쇄로 이어질 수 있으며, 다만 RFC 9298은 2분보다 짧은 타임아웃을 권하지 않습니다.

이 관계는 소켓 생성과 소켓 폐쇄(폐쇄 사유 포함)라는 두 개의 강한 수신을 만듭니다. 그러나 그 사이의 목적지 건강에 대한 지속적인 증명서를 만들지는 않습니다. "아직 열려 있음"은 관찰된 폐쇄 조건이 로컬 상태를 끝내지 않았다는 뜻이지, 모든 패킷이 지금 성공할 것이라는 뜻이 아닙니다.

요청된 터널은 합법적으로 데이터그램을 잃을 수 있습니다

RFC 9298은 Schinazi와 Lucas Pardue가 공동 집필한 RFC 9297의 HTTP 데이터그램과 캡슐 프로토콜 기반을 사용합니다. UDP 페이로드는 컨텍스트 ID 0을 사용합니다. 다른 컨텍스트 ID는 요청별 네임스페이스 내에서 확장 의미를 지원합니다.

이 기반은 재정렬을 의도적으로 수용합니다. 알 수 없는 컨텍스트 ID를 가진 데이터그램은 등록이 도착하는 동안 폐기되거나 잠시 버퍼링될 수 있습니다. 해당 요청보다 먼저 프록시에 도착한 데이터그램도 폐기되거나 임시 버퍼링될 수 있습니다. 클라이언트는 CONNECT-UDP 응답을 받기 전에 낙관적으로 전송하는 것도 허용되며, 요청이 실패하거나 프록시가 버퍼링을 거부하면 그 패킷은 영원히 처리되지 않을 수 있다는 경고가 붙습니다.

크기도 또 하나의 전달 공백을 만듭니다. 컨텍스트 ID 0은 65,527바이트를 넘는 UDP 페이로드를 운반할 수 없습니다. 더 흔하게는, 송신 경로의 MTU가 더 작습니다. 프록시는 IP 단편화를 도입해서는 안 되며, 과대한 HTTP 데이터그램을 조용히 폐기할 수밖에 없을 수도 있습니다.

그 결과는 터널 수용과 개별 데이터그램 전달이 의도적으로 분리된 이벤트인 프로토콜입니다. 첫 번째에서 파생된 상태는 두 번째의 손실을 설명할 수 없습니다. 데이터그램 카운터는 프록시가 트래픽을 관찰하고 전달을 시도했음을 보여줄 수 있습니다. 의도한 애플리케이션이 그 트래픽을 받았고 기대대로 행동했음을 보여줄 수 있는 것은 오직 인증된 내부 교환뿐입니다.

Schinazi의 기여는 절제된 경계 설정입니다

2022년 8월, IETF는 David Schinazi를 저자로 명시한 표준 트랙 문서로 RFC 9298을 발행했습니다. 이 기사를 위해 2026년 9월 2일에 캡처된 IETF Datatracker 프로필은 그를 Google의 senior staff 소프트웨어 엔지니어이자 senior manager로 묘사하며, 그의 작업에 Privacy Proxy, MASQUE, OHTTP가 포함된다고 기록합니다. 또한 이전의 QUIC과 Chrome Networking 리더십, 그리고 Apple에서의 이전 네트워킹 작업도 기록합니다. 이러한 사실은 캡처 시점 기준이며, 맥락이지 영구적인 자격 증명도 배포의 증명도 아닙니다.

더 넓은 아키텍처는 협업적입니다. RFC 9297은 Lucas Pardue와 공동 집필되었습니다. Tommy Pauly, Schinazi, Alex Chernyakhovsky, Mirja Kühlewind, Magnus Westerlund가 집필한 RFC 9484는 이후 이 계열을 IP 프록시로 확장하고masquewell-known URI 등록을 갱신합니다. MASQUE 워킹 그룹 자체도 집단적 IETF 프로그램입니다. Schinazi를 RFC 9298의 한 문장으로 축소해서도 안 되고, 그 주변의 모든 구성 요소를 그의 공으로 기록해서도 안 됩니다.

RFC 9298이 운영적 사고에 기여하는 것은 잘 한정된 성공 진술입니다. 표준은 제품 대시보드에서 종종 진실성이 약해집니다. 초록 배지 하나가 편리하기 때문에 여러 상태 전환이 한 단어로 압축되기 때문입니다. 여기서 원문 문서는 그 압축을 거부합니다. 응답이 정확히 무엇을 의미하는지 독자에게 말해주고 무엇이 여전히 알려지지 않았는지 드러냅니다.

Lu Heng의 running-code 우선 원칙은 다른 방향에서 같은 결론에 도달합니다. 시스템은 실제 실행이 산출한 사실만을 주장해야 합니다. 여기서 프록시는 자신의 인가 결정, 확인 단계, 소켓 생성, 전달 관찰을 증명할 수 있습니다. 그러나 목적지가 근거를 내놓기 전까지 목적지로부터 권위를 빌릴 수는 없습니다.

최소 초기 사양에 관한 노트는 보완적 설계 원칙을 더합니다. CONNECT-UDP는 작고 상호운용 가능한 터널 계약으로 남아야 합니다. 서로 다른 내부 프로토콜이 서로 다른 확인, 인증, 실패 의미를 정의할 수 있습니다. 보편적인 애플리케이션 성공 주장을 터널 계층에 강제하는 것은 모든 UDP 애플리케이션이 하나의 결과 모델을 공유한다는 가장을 통해 공통 기반을 불필요하게 키우는 일이 됩니다.

발명된 확실성 하나 대신 다섯 개의 수신

운영 시스템은 이벤트 체인으로 이 경계를 지킬 수 있습니다.

첫 번째 수신은 프록시 인가입니다. 인증된 클라이언트 또는 인가 클래스, 요청된 대상, 적용되는 대상 정책, 속도 또는 바이트 예산, 허용 또는 거부 결정을 기록합니다. 무단 프록시 접근은 유해한 트래픽이 프록시에서 발생하는 것처럼 보이게 만들 수 있으므로, RFC 9298은 인증된 사용자와 localhost, 링크-로컬, 멀티캐스트, 브로드캐스트 주소 같은 취약한 목적지에 대한 제한을 권고합니다.

두 번째 수신은 확인입니다. DNS 대상의 경우 리졸버 결과, 선택된 주소, 주소 패밀리, 시각을 기록합니다. 주소 리터럴의 경우 리터럴과 정책 검사를 기록합니다. 확인은 결코 애플리케이션 탐색으로 재명명되어서는 안 됩니다.

세 번째는 소켓 상태입니다. 소켓 생성, 로컬 이그레스 신원, connected 또는 non-connected 모드, 피어 튜플, 소유 요청 스트림, 최종 폐쇄 사유를 기록합니다. 모든 네트워크가 제공한다는 약속 없이 ICMP에서 파생된 오류를 포함할 수 있습니다.

네 번째는 데이터그램 이동입니다. 방향별 카운터, 첫/마지막 패킷 시각, 바이트, 사유별 폐기, 과대 페이로드, 알 수 없는 컨텍스트 ID, 버퍼 소진은 프록시 경계를 넘은 것이 무엇인지 보여줍니다. 이들은 범위가 제한되고 접근이 통제되어야 하며, 이동의 증명은 민감한 페이로드의 보존을 요구하지 않습니다.

다섯 번째는 내부 프로토콜의 결과입니다. QUIC 핸드셰이크, 인증된 응답, DNS 트랜잭션 식별자, 애플리케이션 확인, 명시적 오류가 여기에 속합니다. 타임아웃과 재시도도 여기에 속합니다. "목적지가 응답했다"가 실제 애플리케이션에서 무엇을 의미하는지 정의할 수 있는 유일한 계층입니다.

이 수신들을 갖추면, 컨트롤 플레인은 여러 정직한 상태를 표시할 수 있습니다. 프록시 준비 완료. 이름 확인 완료. 송신 데이터그램 관찰됨. 수신 데이터그램 관찰됨. 내부 핸드셰이크 완료. 애플리케이션 응답 수용됨. 사용자는 초록의 거짓보다 더 많은 정보를 얻고 불확실성이 정확히 어디서 시작되는지 볼 수 있습니다.

빌린 증언 없는 성공

RFC 9298의 가장 깊은 교훈은 UDP가 신뢰할 수 없다는 것이 아닙니다. 엔지니어는 이미 그것을 압니다. 핵심은 잘 설계된 프로토콜은 아직 말하지 않은 행위자의 증언을 주장하지 않는다는 것입니다.

프록시는 자신이 의사가 있고 준비되었다고 말할 수 있습니다. 리졸버는 자신이 어떤 주소를 반환했는지 말할 수 있습니다. 운영체제는 소켓 상태 전환을 보고할 수 있습니다. 프록시는 자신의 경계에서 데이터그램을 셀 수 있습니다. 애플리케이션은 인증된 교환이 완료되었는지 말할 수 있습니다. 각 진술에는 소유자, 시각, 한정된 범위가 있습니다.

자동화는 이 진술들을 병합하고 가장 이른 것을 가장 강한 것으로 승격할 때 위험해집니다. 로드 밸런서는 HTTP 터널이 여전히 열리기 때문에 침묵한 목적지로 계속 전송할 수 있습니다. 인시던트 대응자는 MTU 경계에서 폐기된 패킷을 애플리케이션 탓으로 돌릴 수 있습니다. 컴플라이언스 보고서는 출발지 검증을 피어 인증으로 서술할 수 있습니다. 용량 모델은 응답 없이 오래 유지되는 소켓을 유용한 트래픽으로 취급할 수 있습니다.

David Schinazi의 RFC는 운영자에게 더 나은 어휘를 줍니다. CONNECT-UDP 성공은 비어 있지 않습니다. 정확합니다. 프록시가 자신의 몫을 완료했음을 알려줍니다. 책임 있는 다음 질문은 "왜 이 상태는 더 많은 것을 약속하지 않는가?"가 아니라 "목적지가 응답했다고 말하기 전에 우리는 아직 누구의 수신이 필요한가?"입니다.

출처