요약

  • RFC 10036은Incremental:?1을 메시지 전체를 수신하기 전에 중개 장비가 콘텐츠를 전달하도록 발신자가 메시지별로 요청하는 필드로 정의합니다. 요청과 응답은 별개의 메시지이며, 양방향 모두 점진적 전달이 필요하다면 두 방향 모두에 이 필드가 필요합니다.
  • 이 필드를 이해하면서 본문의 점진적 전달을 명시적으로 거부하는 홉은 조용히 버퍼링하는 대신 오류를 반환해야 합니다. 권장 컨텍스트는 지속적인 검사 비호환성(501과incremental_refused)과 일시적인 동시 처리 압박(429와connection_limit_reached)을 구분합니다.
  • 이는 종단 간 스트리밍 보장이 아닙니다. 필드를 모르거나 지원하지 않는 홉은 필드를 무시하고 버퍼링할 수 있으며, 지원하는 홉도 유한한 바이트·시간 기반 버퍼링을 사용할 수 있습니다. 따라서 증명에는 헤더 한 줄의 스크린샷이 아니라 경로에서 결과까지의 영수증이 필요합니다.

어려운 장애는 항상 연결이 끊기는 형태로 나타나지 않습니다. 때로는 요청이 열린 채 유지되고, 서버가 응답을 시작했는데도 클라이언트에게 아무 유용한 데이터도 도달하지 않습니다. 중개 장비는 전체 본문을 기다리고, 애플리케이션은 중개 장비를 기다립니다. 모든 구성 요소는 여전히 살아 있는 것처럼 보입니다.

이 장애는 교환이 양방향일 때 특히 심각합니다. 클라이언트는 시간에 걸쳐 요청 본문을 생성하는 동안 서버는 요청이 끝나기 전에 유용한 응답 데이터를 보낼 수 있습니다. 어떤 홉이 완전한 요청이나 완전한 응답을 기다린다면, 어느 쪽도 계속 진행하는 데 필요한 바이트를 받지 못합니다. 겉보기 최적화는 애플리케이션 수준의 교착 상태가 됩니다.

RFC 10036,Incremental Forwarding of HTTP Messages는 이 문제에 대해 의도적으로 작은 신호를 제공합니다. 2026년 8월에 IETF 제안 표준(Proposed Standard)으로 발표되었으며, Kazuho Oku, Tommy Pauly, Martin Thomson을 저자로 명시합니다. 이 표준은 HTTP를 대체하지 않고, 보편적인 스트리밍 모드를 만들지도 않으며, 이를 이해하지 못하는 중개 장비를 강제하지도 않습니다. 발신자가 의도를 밝힐 수 있게 하고, 참여하는 홉에서 한 부류의 거부를 명시적으로 만듭니다.

Oku의 공개 이력은 표준을 개인의 소유물로 만들지 않으면서도 유용한 맥락을 제공합니다. 2026년 8월 31일에 캡처된 IETF Datatracker 프로필은 RFC 10036을 포함해 네 개의 RFC, 즉 RFC 8297의 Early Hints, RFC 9218의 HTTP Extensible Priorities, 그리고 HTTP 관련 RFC 하나를 나열합니다. Fastly의 공식 저자 페이지는 그를 Principal OSS Engineer로, H2O, quicly, picoTLS의 저자로 소개합니다. 이 사실들은 고성능 인터넷 소프트웨어에 대한 지속적인 작업을 보여줍니다. RFC 10036은 여전히 IETF의 집합적 작업이며, 배포된 각 경로는 각 운영자의 통제 아래에 있습니다.

헤더는 물어보고, 경로가 결정한다

Incremental은 Structured Fields Item입니다. Boolean 값만 유효하며, 수신자는 다른 타입의 값이 오면 이 필드를 무시합니다.?1은 중개 장비가 메시지 전체를 받기 전에 전달을 시작해 달라고 요청하고,?0은 중개 장비가 전체 메시지를 버퍼링할 수 있는, 더 높은 확신을 홉에 줄 수 있는 일반적인 경우를 표현합니다.

메시지 경계가 중요합니다. HTTP 요청과 응답은 별개의 메시지입니다. 요청을?1로 표시한 클라이언트는 응답까지 표시한 것이 아닙니다. 응답을 점진적으로 전달받으려는 서버는 그 응답에 필드를 추가해야 합니다. 양방향 애플리케이션은 양쪽 방향 모두에서 신호가 필요합니다.

이것은 단순한 문법 이상입니다. "이 엔드포인트는 스트리밍을 지원한다"는 막연한 주장이 어느 방향이 테스트되었는지를 숨기는 것을 막아줍니다. 업로드는 흘러가는데 초기 응답은 갇혀 있을 수 있고, 응답 스트림은 제때 도착하는데 요청 본문은 여전히 상류에서 누적되고 있을 수 있습니다. 유용한 영수증은 결과를 언급하기 전에 메시지와 방향을 명명해야 합니다.

지원하는 중개 장비가?1을 받으면, RFC 10036은 전체 본문을 버퍼링해서는 안 된다고 규정합니다. 헤더 섹션을 다운스트림으로 전송하고 도착하는 콘텐츠 바이트를 계속 전달해야 합니다. 다만 이 필드는 HTTP 메시지의 모든 섹션이 아니라 메시지 콘텐츠에만 적용되므로, 헤더·트레일러 섹션은 여전히 전체를 버퍼링할 수 있습니다.

따라서 이 신호는 새로운 전송 방식이 아니라, 기능을 갖춘 홉에서의 전달 동작에 대한 지시입니다. 두 메시지가 모두 이 필드를 담으면 양방향 바이트 채널을 촉진할 수 있지만, RFC는 양방향 프로토콜에 대해서는 Extended CONNECT가 일반적으로 HTTP 아키텍처와 더 일관된다고 언급합니다. 필드 선택만으로 애플리케이션이 다른 프로토콜 형태를 써야 하는지라는 엔지니어링 문제가 사라지지는 않습니다.

거부가 관찰 가능한 분기가 된다

RFC에서 가장 강력한 문장은 요청을 이해하면서 그에 반대하는 의식적 결정을 내리는 홉에 관한 것입니다. 그런 중개 장비가 본문의 점진적 전달을 명시적으로 거부한다면, 전체 메시지를 버퍼링한 뒤 나중에 전달하는 것이 아니라 오류 응답을 생성해야 합니다.

이 규칙은 애플리케이션을 가짜 성공으로부터 보호합니다. 무음 버퍼링은 기존 HTTP 의미론을 만족시키면서 애플리케이션이 의존하는 타이밍 속성을 파괴할 수 있습니다. 요청은 결국 완료될 수 있지만, 사용자는 멈춘 콘솔, 지연된 모델 응답, 쓸 수 없는 이벤트 피드, 대화형이 되지 않는 제어 채널을 경험합니다. 명확한 오류는 엔드포인트가 폴백을 선택하거나, 다른 곳에서 재시도하거나, 다른 프로토콜을 사용하거나, 해당 작업을 이용할 수 없다고 설명할 수 있게 합니다.

의무의 범위는 좁습니다. 이는 중개 장비가Incremental을 이해하고 본문의 점진적 전달을 명시적으로 거부하기로 결정했을 때 적용됩니다. 관찰된 어떤 지연도 거부가 아니며, 홉이 각 바이트를 즉시 전달해야 한다는 말도 아닙니다. 이 경계가 결과를 유용하게 만듭니다. 명시적인 분기는 참여 정책이 작동했음을 의미하고, 무음은 여전히 모호합니다.

Running-Code Primacy는 이 구분을 테스트로 바꿉니다. 실제 운영 경로를 통해 식별 가능한 청크로 구성된 제어된 응답을 보냅니다. 각 참여 홉이 첫 바이트와 마지막 바이트를 언제 수신·전달했는지 기록합니다. 거부 조건을 실행해 보고, 의도한 상태와 프록시 컨텍스트가 엔드포인트에 도달하는지 확인합니다. "스트리밍 활성화"라고 적힌 설계 문서는 동등한 증거가 아닙니다.

두 오류가 두 가지 운영 제약을 설명한다

RFC 10036은 의식적인 거부의 두 가지 흔한 이유를 설명합니다.

첫 번째는 구조적 이유입니다. 일부 중개 장비는 완전한 메시지를 검사하고 내용이 안전하다고 판단한 후에야 전달합니다. 전체 본문을 요구하는 기능은 점진적 전달과 호환되지 않습니다. 보안 상의 이유로 점진적 전달이 불가능할 때, 중개 장비는 501 Not Implemented로 응답하고 Proxy-Status 오류로incremental_refused를 붙여야 합니다.

이 결과는 현재 검사 정책 하에서 경로가 요청된 속성을 제공할 수 없다는 뜻입니다. 경로, 자원 또는 정책이 바뀌지 않는 한 나중에 같은 요청을 반복해도 결과가 달라질 가능성은 낮습니다. 해결은 아키텍처적입니다. 호환되는 경로를 선택하거나, 검사 모델을 바꾸거나, 민감한 교환을 옮기거나, 전체 메시지 버퍼링 없이 중개 장비가 처리할 수 있는 프로토콜을 사용하는 것입니다.

두 번째 이유는 일시적 용량입니다. 중개 장비는 동시에 전달하는 요청이나 연결 수를 제한하고 초과 작업을 버퍼링하는 경우가 많습니다. 점진적 교환은 더 오래 자원을 점유할 수 있으므로, 홉은 일반 요청에 대한 서비스를 보존하기 위해 더 좁은 동시 처리 풀에 배정할 수 있습니다. 한도에 도달하면, RFC에 따르면 중개 장비는 429 Too Many Requests와 Proxy-Status의connection_limit_reached로 응답해야 합니다.

이 결과는 다른 대응을 뒷받침합니다. 자원은 호환되지만 용량이 현재 부족할 수 있습니다. 백오프, 어드미션 제어, 우선순위, 더 큰 풀 또는 통제된 폴백이 도움이 될 수 있습니다. 두 사례를 "스트리밍 실패"로 묶어버리면 표준이 노출하도록 설계된 운영적 구분이 사라집니다.

상태 코드만으로는 불충분합니다. 501은 점진적 전달과 무관한 이유로 발생할 수 있고, 429는 많은 레이트 리밋을 반영할 수 있습니다. 결합된 증거에는 Proxy-Status, 책임 홉, 자원 식별자, 정책 버전, 시각이 포함됩니다. 반대로 Proxy-Status는 참여하는 중개 장비가 제공하는 만큼만 완전합니다. 경로 위의 모든 장치를 조사하는 마법의 인구조사가 아닙니다.

지원하지 않는 홉이 사각지대다

본질적 한계는 HTTP 확장성에서 바로 따라옵니다. 이 필드를 모르는 중개 장비는 동작을 바꾸지 않습니다. 필드의 존재는 알지만 지원하지 않는 홉도 발신자의 요청에도 불구하고 버퍼링할 수 있습니다. 따라서 RFC 10036은 클라이언트와 서버가 모든 중개 장비가?1을 이해하고 존중하리라고 기대할 수 없다고 말합니다.

그렇기 때문에 "오류 없음"은 지원을 증명하지 못합니다. 거부하는 참여 홉은 가시가 되지만, 모르는 홉은 전체 본문을 보유한 채 무음일 수 있습니다. 같은 클라이언트 트레이스가 필드가 나가는 것과 결국 도착하는 응답은 보여주지만, 지연이 어디서 유입되었는지는 드러내지 않습니다.

사전 지식은 불확실성을 좁힐 수 있습니다. 운영자가 고정된 서비스 경로의 모든 홉을 통제하고 테스트된 능력 기록을 유지한다면 그렇습니다. 그 외의 경우, RFC는 개별 자원 단위로 지원 여부를 탐색할 것을 제안합니다. 자원 특이성이 중요합니다. 하나의 호스트명도 경로, 지역, 고객 등급, 본문 유형, 트래픽 조건에 따라 다른 정책을 거칠 수 있기 때문입니다. 성공한 탐색은 그것이 수행된 경로 조건에 대한 증거이지, 브랜드에 대한 영구 인증이 아닙니다.

대리 권한의 경계는 정확합니다. 발신자는 선호를 표현할 뿐이고, 각 중개 장비는 자신의 전달·보안·용량 결정을 소유하며, 수신 엔드포인트는 결과를 해석합니다. 필드는 자신을 이해하지 못하는 소프트웨어에 권한을 행사할 수 없고, 한 엔드포인트가 전체 체인을 대신해 적합성을 부여할 수도 없습니다.

작은 버퍼도 여전히 지연 결과를 움직인다

지원하는 중개 장비조차 효율을 위해 소량을 버퍼링할 수 있습니다. 아주 작은 패킷마다 즉시 전달하는 것은 작업을 낭비하고 남용 표면을 만들 수 있습니다. 따라서 RFC 10036은 바이트·시간 임계값을 허용합니다. 어느 한도에 도달하면 데이터를 전달해야 하며, 무기한 보유할 수 없습니다.

이 유한한 재량은 운영적으로 중요합니다. 두 구현이 모두 필드를 지원하면서도 실질적으로 다른 첫 바이트 지연을 제공할 수 있습니다. 5킬로바이트 임계값은 빠른 응답에서는 보이지 않지만 저변동성 이벤트 스트림에는 해가 될 수 있습니다. 짧은 타이머는 사람을 위한 출력에는 허용되지만 피드백 제어 루프에는 너무 느릴 수 있습니다. "지원"은 필요한 분류일 뿐, 애플리케이션 SLO는 아닙니다.

운영자는 결과를 낳은 정책 값을 보존해야 합니다. 지연 인시던트는 필드와 최종 상태만으로 재구성할 수 없습니다. 홉의 버퍼 임계값, 점유율, 스케줄링 등급, 수신/전달 타임스탬프가 필요합니다. 정책이 바뀌면 같은 소프트웨어 버전이라도 다른 경험을 제공할 수 있으므로 탐색을 반복해야 합니다.

Minimum Initial Specification은 유용한 억제 장치를 제공합니다. 공유 표준은 최소한의 상호운용 가능한 신호와 가시적인 거부 동작을 정의해야 합니다. 지역 운영자는 자신의 환경에 필요한 자원 자격, 임계값, 동시 처리 예산, 검사 제약, 폴백 규칙을 공개하거나 보존해야 합니다. 그러한 지역적 선택을 보편적 의무로 만들면 필드는 더 신뢰할 수 있기는커녕 배포하기 더 어려워집니다.

경로에서 결과까지의 영수증을 만들어라

식별 정보로 시작합니다. 클라이언트·서버 빌드, 자원, 요청 식별자, 관찰이 요청인지 응답인지 여부를 기록합니다. 정확한 필드 값을, Structured Fields Boolean 파싱을 통과했는지 여부를 보존합니다. 어떤 구성 요소가 필드를 설정했는지, 애플리케이션이 왜 점진적 전달에 의존했는지 기록합니다.

그다음 실제로 알 수 있는 경로를 매핑합니다. 통제하거나 참여하는 각 중개 장비에 대해 프로토콜 세그먼트, 인식/지원 상태, 콘텐츠 검사 규칙, 본문·헤더·트레일러 정책, 바이트·시간 임계값, 동시 처리 풀, 점유율, 우선순위 등급을 보존합니다. 사전 지식에는 소유자와 만기가 필요합니다. 그렇지 않으면 어제의 능력 진술이 오늘의 가정이 됩니다.

결과를 결합합니다. HTTP 상태, 전체 Proxy-Status 멤버, 프록시 오류 유형, 책임 홉을 유지합니다. 첫 바이트 수신·전달 시각, 마지막 바이트 수신·전달 시각, 애플리케이션의 지연 또는 정지 결과를 측정합니다. 교환이 수락되었는지, 유한한 버퍼링으로 성능이 저하되었는지, 구조적으로 거부되었는지, 일시적으로 거부되었는지, 알 수 없는 지점에서 무음 버퍼링되었는지, 결론이 불확실한지를 기록합니다.

마지막으로 결정을 보존합니다. 폴백, 재시도, 경로 변경, 프로토콜 변경, 용량 조치, 보안 예외, 운영자, 복구 절차입니다. 타이밍을 증명하기 위해 민감한 본문을 보존하지 마십시오. 상관 안전 식별자, 정책 버전, 타임스탬프는 관찰성을 콘텐츠 보관함으로 만들지 않고도 권한 체인을 보여줄 수 있습니다.

영수증은 자신의 결론을 반증할 수 있어야 합니다. 어떤 홉이 알려지지 않았다면 그렇게 말하십시오. 탐색이 응답만 다루었다면 요청 동작을 추론하지 마십시오. Proxy-Status가 제거되었다면 그 공백을 보존하십시오. 불확실성이 초록 배지로 변환되지 않고 필드를 갖게 될 때 신뢰가 개선됩니다.

출처