| RFC 10036 | HTTP 메시지의 점진적 전달 | 2026년 8월 |
| Oku 외 | 표준 트랙 | [페이지] |
이 문서는 HTTP 중개자에게 HTTP 메시지를 점진적으로 전달하도록 지시하는 "Incremental" HTTP 헤더 필드를 명세합니다.¶
이 문서는 인터넷 표준 트랙 문서입니다.¶
이 문서는 인터넷 엔지니어링 태스크 포스 (IETF)의 산출물입니다. 이 문서는 IETF 커뮤니티의 합의를 나타냅니다. 이 문서는 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹 (IESG)의 게시 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.¶
이 문서의 현재 상태, 모든 정오표 및 이에 대한 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc10036에서 확인할 수 있습니다.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
HTTP [HTTP]는 수신자가 전체 HTTP 메시지를 수신한 후에 처리하도록 기다릴 필요 없이 HTTP 메시지의 일부가 도착하는 즉시 처리를 시작할 수 있도록 허용합니다.¶
일부 애플리케이션은 이 기능을 활용하도록 특별히 설계되어 있습니다.¶
예를 들어 Server-Sent Events [SSE]는 장시간 지속되는 HTTP 응답을 사용하며, 여기서 서버는 알림을 사용할 수 있게 되는 즉시 계속해서 전송합니다.¶
Chunked Oblivious HTTP Messages [CHUNKED-OHTTP]의 경우 클라이언트는 HTTP 요청을 열고 애플리케이션 데이터를 점진적으로 전송하며, 서버는 HTTP 요청이 완전히 완료되기 전에도 응답을 시작할 수 있습니다. 이러한 방식으로 HTTP 요청-응답 쌍은 사실상 양방향 통신 채널을 만들 수 있습니다.¶
데이터의 점진적 전달에 의존하는 애플리케이션은 HTTP 중개자가 개입하면 취약해집니다. 이는 HTTP 중개자가 전체 HTTP 메시지를 다운스트림으로 전달하기 전에 버퍼링하는 것이 허용될 뿐만 아니라 실제로 자주 그렇게 배포되기 때문입니다(섹션 7.6 of [HTTP]).¶
클라이언트와 서버 사이에 이러한 버퍼링 HTTP 중개자가 존재하면 이러한 애플리케이션은 의도한 대로 작동하지 않을 수 있습니다.¶
Server-Sent Events의 경우 HTTP 응답을 전달하기 전에 완전히 버퍼링하려는 중개자는 무기한 기다리게 될 수 있습니다. 클라이언트는 응답의 어떤 부분도 받지 못할 수 있습니다.¶
양방향 교환이 포함된 요청의 경우, 요청 또는 응답 중 하나의 전체 메시지를 버퍼링하려는 중개자는 어떤 데이터도 전달되지 못하게 합니다.¶
이러한 동작을 방지하기 위해 이 문서는 HTTP 중개자가 완전한 메시지를 수신하기 전에 HTTP 메시지를 다운스트림으로 전달하기 시작하도록 요청하는 "Incremental" HTTP 헤더 필드를 명세합니다.¶
이 표시는 중개자에서 지원되지 않을 수 있습니다. 이 필드를 인식하지 못하는 중개자는 동작을 변경하지 않습니다. 이 필드를 지원하는 중개자는 대신 요청을 거부하도록 선택할 수 있습니다. 섹션 4를 참조하십시오.¶
이 문서에서 핵심어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 및 "OPTIONAL"은 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.¶
이 문서는 Item 및 Boolean의 구조화된 필드 정의 [STRUCTURED-FIELDS]를 사용합니다.¶
Incremental HTTP 헤더 필드는 전체 메시지가 수신되기 전에 HTTP 중개자가 메시지를 다운스트림으로 전달하기 시작하기를 바라는 송신자의 의도를 나타냅니다.¶
Incremental 헤더 필드는 Item 유형의 구조화된 필드 [STRUCTURED-FIELDS]로 정의됩니다. Boolean 값(섹션 3.3.6 of [STRUCTURED-FIELDS])만 유효하며, 다른 유형이 포함된 경우 수신자는 해당 필드를 무시합니다.¶
참 값("?1")은 아래에 설명된 대로 송신자가 중개자에게 메시지를 점진적으로 전달하도록 요청함을 나타냅니다.¶
거짓 값("?0")은 [HTTP]에 정의된 기본 동작을 나타내며, 이 경우 중개자는 전체 메시지를 전달하기 전에 버퍼링할 수 있습니다. 그러나 이 명시적 신호는 중개자가 버퍼링을 선택할 때 더 큰 확신을 줄 수 있습니다.¶
Incremental HTTP 헤더 필드는 각 HTTP 메시지에 적용됩니다. 따라서 HTTP 요청과 응답 모두를 점진적으로 전달해야 하는 경우 Incremental HTTP 헤더 필드는 HTTP 요청과 응답 모두에 MUST 설정되어야 합니다.¶
참 값을 가진 Incremental 헤더 필드가 포함된 헤더 섹션을 수신하면 HTTP 중개자는 전체 메시지를 전달하기 전에 SHOULD NOT 버퍼링해야 합니다. 대신 중개자는 헤더 섹션을 다운스트림으로 SHOULD 전송하고 메시지 콘텐츠의 바이트가 도착하는 즉시 계속 전달해야 합니다. Incremental 헤더 필드는 메시지 콘텐츠가 전달되는 방식만을 나타내므로, 중개자는 메시지의 전체 헤더 및 트레일러 섹션을 다운스트림으로 전달하기 전에 여전히 버퍼링할 수 있습니다.¶
중개자가 메시지 본문을 점진적으로 전달하는 것을 전면적으로 거부하기로 결정한 경우 중개자는 전체 메시지를 버퍼링한 후 전달하는 대신 오류 응답을 MUST 생성해야 합니다. 중개자가 거부할 수 있는 일반적인 시나리오는 섹션 4에서 설명합니다.¶
점진적 전달 사용 요청은 HTTP 구현에도 적용됩니다. 대부분의 HTTP API는 메시지 콘텐츠를 점진적으로 전송하는 기능을 제공하지만, 어떤 이유로든 이를 제공하지 않는 경우 Incremental 헤더 필드의 존재를 활용하여 버퍼링을 줄이거나 비활성화하는 것이 SHOULD 권장됩니다.¶
Incremental 필드는 중개자에서 지원되지 않을 수 있습니다. 이 필드를 인식하지 못하거나 지원하지 않는 중개자는 명시적으로 달리 요청하더라도 메시지를 버퍼링할 수 있습니다. 따라서 클라이언트와 서버는 모든 중개자가 메시지를 점진적으로 전달하라는 요청을 이해하고 준수할 것이라고 기대할 수 없습니다. 점진적 전달 지원에 의존하는 클라이언트는 사전 지식을 활용하거나 개별 리소스에 대한 지원 여부를 탐색할 수 있습니다.¶
Incremental 헤더 필드는 요청과 응답 모두에 존재할 경우 중개자에게 조기 응답(섹션 7.5 of [HTTP])을 전달하고 양방향에서 메시지 콘텐츠를 점진적으로 전송하도록 요청하므로 HTTP를 통한 양방향 바이트 채널의 구축을 용이하게 합니다. 그러나 HTTP를 통해 양방향 프로토콜을 개발할 때는 Extended CONNECT [RFC8441][RFC9220]가 일반적으로 HTTP의 아키텍처와 더 일관됩니다.¶
이 문서는 Incremental 헤더 필드 값에 대한 매개변수를 정의하지 않지만 향후 문서에서 매개변수를 정의할 수 있습니다. 수신자는 알 수 없는 매개변수를 MUST 무시해야 합니다.¶
점진적 전달을 요청하는 요청이나 응답을 수신할 때 중개자는 보안상의 이유로 HTTP 요청을 거부할 수 있습니다. 다음 하위 섹션에서는 중개자가 요청을 거부할 수 있는 일반적인 시나리오를 살펴봅니다.¶
Incremental 필드의 값을 근거로 요청을 거부하는 것은 중개자가 해당 필드를 이해하는 경우에만 발생한다는 점에 유의하십시오.¶
일부 중개자는 HTTP 메시지의 콘텐츠를 검사하고 해당 콘텐츠가 안전한 것으로 판단되는 경우에만 전달합니다. 이러한 방식으로 메시지 전체를 확인해야 하는 모든 기능은 점진적 전달과 호환되지 않습니다.¶
중개자가 메시지를 점진적으로 전달하도록 요청받았지만 그렇게 할 수 없는 경우, 해당 메시지가 요청이든 응답이든 관계없이 메시지 콘텐츠에 대한 보안상의 우려 때문이라면 중개자는 incremental_refused Proxy-Status 응답 헤더 필드를 포함한 501 (Not Implemented) 오류로 SHOULD 응답해야 합니다 (섹션 5).¶
HTTP 요청 또는 연결을 처리하는 데 필요한 리소스를 절약하기 위해 중개자가 전달하는 동시 HTTP 요청의 최대 수를 제한하고 이 한도를 초과하는 요청을 버퍼링하는 것이 일반적입니다.¶
이러한 중개자는 점진적 요청의 최대 수에 도달한 경우에도 비점진적 요청에 사용할 용량이 남도록 점진적이라고 표시된 요청에 더 제한적인 동시성 제한을 적용할 수 있습니다. 이 방식은 서로 다른 유형의 요청 처리를 균형 있게 하고 모든 요청에 대한 서비스 가용성을 유지하는 데 도움이 됩니다.¶
동시성 제한에 도달하여 점진적 요청을 거부할 때 중개자는 429 (Too Many Requests) 오류로 SHOULD 응답해야 하며 (섹션 4 of [EXTRA-STATUS]), connection_limit_reached Proxy-Status 응답 헤더 필드를 함께 제공해야 합니다 (섹션 2.3.12 of [PROXY-STATUS]).¶
성능과 효율성을 위해 점진적 메시지에도 중개자가 소량의 버퍼링을 사용할 수 있습니다. 즉시 전달은 중개자가 많은 작은 패킷을 처리하는 데 불필요한 작업을 하도록 악용될 수 있습니다. 점진적 전달을 활성화하면 대신 버퍼링되는 바이트 수 또는 전달하기 전에 버퍼를 유지하는 시간에 제한을 설정할 수 있습니다. 모든 버퍼링은 효율성을 높이더라도 애플리케이션 지연 시간에 부정적인 영향을 줄 수 있습니다. 모든 경우에 중개자는 데이터를 버퍼에 무기한 보관할 수 없으므로 시간 제한 또는 바이트 제한 중 하나에 도달하면 데이터를 전달해야 합니다.¶
Incremental이라는 이름의 HTTP 필드가 섹션 18.4 of [HTTP]의 절차에 따라 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 등록되었습니다. 다음 값이 등록되었습니다.¶
HTTP 프록시 오류 유형이 아래와 같이 "HTTP Proxy Error Types" 레지스트리에 등록되었습니다.¶