HTTP용 확장 가능한 우선순위 지정 체계

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이 문서는 IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)의 출판 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 정오표 및 이에 대한 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc9218에서 확인할 수 있습니다.

Copyright (c) 2022 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] 자원의 표현은 하나 이상의 다른 자원과 관계를 갖는 것이 일반적입니다. 클라이언트는 검색한 표현을 처리하는 동안 이러한 관계를 발견하고, 추가적인 검색 요청으로 이어질 수 있습니다. 한편, 관계의 성격은 클라이언트가 로컬에서 사용 가능한 자원의 처리를 계속할 수 있는지를 결정합니다. 예를 들어 HTML 문서의 시각적 렌더링은 문서가 참조하는 Cascading Style Sheets(CSS) 파일의 검색에 의해 차단될 수 있습니다. 반면 인라인 이미지들은 렌더링을 차단하지 않으며 이미지 청크가 도착함에 따라 점진적으로 그려집니다.

HTTP/2 [HTTP/2]와 HTTP/3 [HTTP/3]는 단일 연결에서 요청과 응답의 멀티플렉싱을 지원합니다. 멀티플렉싱을 제공하는 프로토콜 구현의 중요한 기능은 정보 전송의 우선순위를 지정하는 능력입니다. 예를 들어 HTML 문서의 의미 있는 표현을 가능한 한 빨리 제공하려면, HTTP 서버가 클라이언트에 전송하는 HTTP 응답들(또는 그 청크) 중에서 어떤 것을 우선적으로 전송할지 결정하는 것이 중요합니다.

HTTP/2 및 HTTP/3 서버는 선택한 방법으로 동시 응답 데이터의 전송을 스케줄할 수 있습니다. 서버는 클라이언트 우선순위 신호를 무시하고도 성공적으로 HTTP 응답을 제공할 수 있습니다. 그러나 클라이언트가 요청을 어떻게 생성하고 응답을 어떻게 소비하는지 모르는 상태로 운영되는 서버는 클라이언트 애플리케이션 성능을 비최적화하게 만들 수 있습니다. 우선순위 신호는 클라이언트가 요청 우선순위에 대한 관점을 전달할 수 있게 합니다. 서버는 클라이언트의 요구와 독립적인 자체적인 필요를 가지므로, 종종 우선순위 신호를 다른 이용 가능한 정보와 결합하여 응답 데이터 스케줄링에 참고합니다.

RFC 7540 [RFC7540]의 스트림 우선순위는 클라이언트가 "우선순위 트리"를 서버에 전달하는 일련의 우선순위 신호를 보낼 수 있게 했습니다; 이 트리의 구조는 클라이언트가 선호하는 상대적 순서와 대역폭의 가중 분배를 나타냅니다. 서버는 이러한 우선순위 신호를 우선순위 결정의 입력으로 사용할 수 있습니다.

RFC 7540 스트림 우선순위의 설계와 구현에는 단점이 있음이 관찰되었고, 이는 섹션 2에서 설명됩니다. 결과적으로 HTTP/2는 이러한 스트림 우선순위 신호의 사용을 더 이상 권장하지 않습니다. 본 문서에서 정의하는 우선순위 체계와 신호는 RFC 7540 스트림 우선순위를 대체할 수 있습니다.

이 문서는 절대값을 사용하는 확장 가능한 HTTP 응답 우선순위 체계를 설명합니다. 섹션 4은 우선순위 매개변수를 정의하며, 이는 표준화되고 확장 가능한 우선순위 정보 형식입니다. 섹션 5은 프로토콜 버전과 무관한 초기 우선순위를 전달하기 위한 Priority HTTP 헤더 필드를 정의합니다. 클라이언트는 이 헤더 필드를 전송하여 응답 우선순위에 대한 관점을 신호할 수 있습니다. 유사하게, 중개자 뒤의 서버는 이를 사용해 중개자에게 우선순위 힌트를 줄 수 있습니다. 요청 전송 후 클라이언트는 우선순위 관점을 변경할 수 있으며(재우선순위 지정, 섹션 6 참조) 이는 섹션 7.1 및 7.2에서 정의된 HTTP 버전별 프레임을 통해 수행됩니다.

헤더 필드 및 프레임 우선순위 신호는 서버의 응답 우선순위 결정 과정에 대한 입력입니다. 이들은 제안일 뿐이며, 한 응답이 다른 응답보다 특정한 처리 또는 전송 순서를 보장하지 않습니다. 섹션 10 및 12는 서버가 이러한 신호를 바탕으로 어떻게 동작할 수 있는지에 대한 고려사항과 지침을 제공합니다.

RFC 7540 스트림 우선순위(자세한 내용은 RFC 7540 섹션 5.3 참조)는 클라이언트가 스트림 의존성과 가중치를 신호하여 불균형 트리를 설명하는 복잡한 시스템입니다. 배포 및 상호운용성의 제한으로 어려움을 겪었고, HTTP/2의 개정에서 사용 중단(deprecated)되었습니다. HTTP/2는 와이어 호환성을 유지하기 위해 이 프로토콜 요소들을 보존하지만(자세한 내용은 RFC 9113 섹션 5.3.2 참조), 이는 본 문서에서 설명하는 대안 신호가 존재하더라도 여전히 사용될 수 있음을 의미합니다.

많은 RFC 7540 서버 구현체는 HTTP/2 우선순위 신호에 대해 동작하지 않습니다.

우선순위 지정은 서버가 자원에 대해 가진 정보나 요청이 생성된 순서에 대한 정보를 사용할 수 있습니다. 예를 들어 서버는 HTML 문서 구조를 알고 있을 때 사용자 경험에 중요한 이미지를 다른 이미지보다 우선하도록 전달하고 싶을 수 있습니다. RFC 7540에서는 동일한 조건이 서로 다른 클라이언트로부터 매우 다른 신호를 발생시킬 수 있으므로 서버가 클라이언트의 신호를 우선순위 지정에 해석하기 어렵습니다. 본 문서는 더 단순하고 제약된 신호를 설명하여 해석 필요성을 줄이고 변동을 적게 하도록 합니다.

RFC 7540는 서버가 중개자들에게 우선순위 신호를 제공하는 방법을 정의하지 않습니다.

RFC 7540 스트림 우선순위는 동일한 연결을 공유하는 다른 요청들에 상대적으로 표현됩니다. 이러한 설계를 요청을 생성하는 애플리케이션(다른 요청이 연결을 어떻게 공유할지 모르는 경우)이나 스트림 간에 강한 순서 보장이 없는 HTTP/3 같은 프로토콜에 통합하기는 어렵습니다.

독립 연구의 실험 결과([MARX])는 단순한 체계가 실제 사용에서 보이는 더 복잡한 RFC 7540 설정과 비교해 적어도 동등한 성능 특성에 도달할 수 있음을 보였습니다(웹 사용 사례 기준).

본 문서에서 정의한 우선순위 체계는 주로 HTTP 응답 메시지의 우선순위 지정에 중점을 둡니다(자세한 내용은 RFC 9110 섹션 3.4 참조). 이는 새로운 우선순위 매개변수(섹션 4)와 해당 매개변수를 전달하는 수단(섹션 5 및 7)을 정의하며, 응답의 우선순위를 결정할 책임이 있는 서버에 우선순위를 전달하는 것을 목표로 합니다. 서버가 신호를 다른 입력 및 요소들과 결합하여 동작하는 방법에 대한 고려사항은 섹션 10에 제공합니다.

CONNECT 메서드(자세한 내용은 RFC 9110 섹션 9.3.6 참조)는 터널을 설정하는 데 사용될 수 있습니다. 터널에 대한 신호도 유사하게 적용됩니다; 서버 우선순위 지정에 대한 추가 고려사항은 섹션 11에 제공됩니다.

섹션 9은 클라이언트가 생성하는 요청 메시지에 이 체계의 요소를 로컬에서 선택적으로 적용하는 방법을 설명합니다.

어떤 형태의 HTTP 확장은 HTTP/2 또는 HTTP/3 스트림 동작을 변경하거나 새로운 데이터 전달 메커니즘을 정의할 수 있습니다. 그러한 확장들은 이 우선순위 체계가 어떻게 적용되어야 하는지를 자체적으로 정의할 수 있습니다.

우선순위 정보는 향후 확장을 위한 여지를 남긴 일련의 키-값 쌍입니다. 각 키-값 쌍은 우선순위 매개변수를 나타냅니다.

Priority HTTP 헤더 필드(섹션 5)는 요청 또는 응답이 발행될 때 이 우선순위 매개변수 집합을 전송하는 종단 간 방식입니다. 요청 전송 후 클라이언트는 재우선순위 지정(섹션 6)을 위해 HTTP 버전별 PRIORITY_UPDATE 프레임을 전송할 수 있으며, 이는 섹션 7.1 및 7.2에서 정의됩니다. 프레임은 우선순위 매개변수를 단일 홉에만 전송합니다.

중개자는 PRIORITY_UPDATE 프레임 또는 Priority 헤더 필드에서 우선순위 신호를 소비하고 생성할 수 있습니다. 중개자가 Priority 요청 헤더 필드만 다음 홉으로 전달하면 클라이언트의 원래 종단 간 신호를 보존합니다; 자세한 내용은 섹션 14를 참조하세요. 중개자는 Priority 헤더 필드를 전달하면서 추가로 PRIORITY_UPDATE 프레임을 전송할 수도 있습니다. 이는 원래의 클라이언트 종단 간 신호를 보존하면서도 다음 홉에게 다른 우선순위를 사용하도록 지시하는 효과가 있습니다(섹션 7의 지침 참조). Priority 요청 헤더 필드를 교체하거나 추가하는 중개자는 원래 클라이언트의 종단 간 신호를 재정의하게 되며, 이는 요청의 이후 수신자들에게 우선순위에 영향을 줄 수 있습니다.

Priority 헤더 필드와 PRIORITY_UPDATE 프레임 모두에서 우선순위 매개변수 집합은 Dictionary 형식으로 인코딩됩니다(참조: RFC 8941 섹션 3.2).

이 문서는 urgency(u) 및 incremental(i) 우선순위 매개변수를 정의합니다. 이 매개변수가 없는 HTTP 요청을 받으면, 서버는 이들의 기본값이 지정된 것으로 간주하여 동작하는 것이 권장됩니다(SHOULD).

중개자는 포워딩하는 요청 및 응답으로부터 신호를 결합할 수 있습니다. 응답에서 우선순위 매개변수의 생략은 요청에서의 생략과 다르게 처리된다는 점에 유의하세요; 관련 내용은 섹션 8을 참조하세요.

수신자는 Dictionary를 RFC 8941 섹션 4.2에 설명된 대로 파싱합니다. Dictionary가 성공적으로 파싱된 경우, 본 문서는 알 수 없는 우선순위 매개변수, 범위를 벗어난 값, 또는 예상 타입과 다른 값은 무시되어야 한다는 추가 요구사항을 둡니다(MUST).

Priority HTTP 헤더 필드는 우선순위 매개변수들을 담는 Dictionary입니다(참조 섹션 4). 이 헤더는 요청과 응답에 나타날 수 있습니다. 이는 엔드투엔드 신호로, HTTP 응답을 어떻게 우선순위화해야 하는지에 대한 엔드포인트의 관점을 나타냅니다. 섹션 8에서는 중개자가 클라이언트와 서버가 보낸 우선순위 정보를 어떻게 결합할 수 있는지 설명합니다. 클라이언트는 Priority 응답 헤더 필드의 존재 여부나 생략만으로 어떤 우선순위 처리가 수행되었음을 인정(acknowledge)할 수는 없습니다. 엔드포인트가 Priority 헤더 값에 따라 어떻게 행동할 수 있는지에 대한 지침은 섹션 9 및 10에 제공됩니다.

Priority 헤더 필드가 포함된 HTTP 요청은 캐시되어 이후 요청에 재사용될 수 있습니다; 참조 [CACHING]. 오리진 서버가 수신한 HTTP 요청의 속성에 기초해 Priority 응답 헤더 필드를 생성할 때, 서버는 캐시 동작을 제어하는 헤더 필드(예: Cache-Control, Vary)를 사용하여 캐시 가능성 또는 캐시된 응답의 적용성을 제어하는 것이 기대됩니다.

클라이언트가 요청을 보낸 후 응답의 우선순위를 변경하는 것이 유익할 수 있습니다. 예를 들어, 웹 브라우저가 JavaScript 파일에 대해 Priority 요청 헤더 필드의 urgency 매개변수를 u=7(백그라운드)로 설정하여 프리페치 요청을 보낼 수 있습니다. 이후 사용자가 새 JavaScript 파일을 참조하는 페이지로 이동하면, 프리페치가 진행 중인 동안 브라우저는 Priority Field Value를 u=0으로 설정한 재우선순위 신호를 보낼 것입니다. 이러한 재우선순위를 위해 PRIORITY_UPDATE 프레임(섹션 7)을 사용할 수 있습니다.

이 문서는 HTTP/2 [HTTP/2]와 HTTP/3 [HTTP/3]용 새로운 PRIORITY_UPDATE 프레임을 규정합니다. 이 프레임은 우선순위 매개변수를 운반하고 버전별 식별자에 따라 우선순위의 대상(타깃)을 참조합니다. HTTP/2에서는 이 식별자가 스트림 ID이고, HTTP/3에서는 식별자가 스트림 ID 또는 push ID입니다. Priority 헤더 필드와 달리 PRIORITY_UPDATE 프레임은 홉-바이-홉(hop-by-hop) 신호입니다.

PRIORITY_UPDATE 프레임은 클라이언트가 컨트롤 스트림에서 전송합니다. 이는 응답을 운반하는 스트림과 독립적으로 전송할 수 있음을 의미합니다. 따라서 응답이나 푸시 스트림을 재우선순위화하거나 Priority 헤더 필드 대신 응답의 초기 우선순위를 신호하는 데 사용할 수 있습니다.

PRIORITY_UPDATE 프레임은 Priority Field Value 필드에 모든 우선순위 매개변수의 전체 세트를 전달합니다. 우선순위 매개변수를 생략하는 것은 해당 매개변수의 기본값을 사용하라는 신호입니다. Priority Field Value를 파싱하지 못하면 연결 오류로 처리할 수 있습니다(MAY). HTTP/2에서는 오류가 PROTOCOL_ERROR 유형이고, HTTP/3에서는 H3_GENERAL_PROTOCOL_ERROR 유형입니다.

클라이언트는 참조하는 스트림이 열리기 전에 PRIORITY_UPDATE 프레임을 보낼 수 있습니다(MAY)(HTTP/2 푸시 스트림은 예외; 섹션 7.1 참조). 또한 HTTP/3는 스트림 간에 보장된 순서를 제공하지 않으므로 프레임이 의도보다 일찍 수신될 수 있습니다. 이 두 경우 모두 서버가 아직 열리지 않은 요청 스트림을 참조하는 PRIORITY_UPDATE 프레임을 수신하는 경쟁(race) 상태가 발생할 수 있습니다. 이를 해결하기 위해 스케줄링 관점에서는 가장 최근에 수신된 PRIORITY_UPDATE 프레임을 최신 정보로 간주하여 다른 신호를 무시하도록 할 수 있습니다. 서버는 가장 최근에 수신된 PRIORITY_UPDATE 프레임을 버퍼링하고 참조된 스트림이 열리면 적용하는 것이 권장됩니다(SHOULD). 각 스트림에 대해 PRIORITY_UPDATE 프레임을 보류하면 서버 자원이 필요하므로, 로컬 구현 정책으로 자원을 제한할 수 있습니다. 전송할 수 있는 PRIORITY_UPDATE 프레임 수에 제한은 없지만, 가장 최근 프레임만 저장하면 자원 부담을 제한할 수 있습니다.

클라이언트가 HTTP 응답을 어떻게 우선순위화해야 하는지에 대해 항상 최선의 이해를 갖고 있는 것은 아닙니다. 서버는 응답의 우선순위 결정을 개선하기 위해 클라이언트가 표시한 우선순위와 결합할 수 있는 추가 정보를 가질 수 있습니다. 예를 들어, HTML 문서의 사용은 인라인 이미지 중 하나에 크게 의존할 수 있으며, 이러한 의존성의 존재는 일반적으로 서버가 가장 잘 알고 있습니다. 또는 폰트([RFC8081])와 동일한 긴급도를 가진 이미지 요청을 받는 서버는 시각적 클라이언트가 텍스트 정보를 조기에 렌더링할 수 있도록 폰트에 더 높은 우선순위를 부여할 수 있습니다.

오리진은 Priority 응답 헤더 필드를 사용하여 HTTP 응답을 어떻게 우선순위화해야 하는지에 대한 자신의 관점을 나타낼 수 있습니다. HTTP 응답을 포워딩하는 중개자는 Priority 응답 헤더 필드에서 찾은 우선순위 매개변수와 클라이언트 Priority 요청 헤더 필드를 결합하여 자신의 우선순위화 프로세스의 입력으로 사용할 수 있습니다. 병합 방법에 대한 지침은 제공되지 않으며, 이는 구현상의 결정으로 남습니다.

HTTP 응답에서 우선순위 매개변수가 없는 것은 서버가 클라이언트가 제공한 값을 변경하는 데 관심이 없음을 나타냅니다. 이는 요청 헤더 필드와는 다르며, 요청 헤더 필드에서 우선순위 매개변수를 생략하면 해당 매개변수의 기본값을 사용함을 의미합니다(참조 섹션 4).

비규범적 예로, 클라이언트가 urgency 매개변수를 5로, incremental 매개변수를 true로 설정한 HTTP 요청을 보낼 때

:method = GET
:scheme = https
:authority = example.net
:path = /menu.png
priority = u=5, i

오리진이 다음과 같이 응답하면

:status = 200
content-type = image/png
priority = u=1

중개자는 우선순위를 클라이언트가 제시한 5에서 서버가 제공한 값인 1로 변경할 수 있습니다. 이는 중개자가 서버 제공 값을 클라이언트 값보다 선호했기 때문입니다. incremental 값은 서버가 incremental(i) 매개변수를 지정하지 않았으므로 계속 true입니다(즉, 클라이언트가 지정한 값).

클라이언트는 로컬 처리나 자신이 시작한 요청들에 대한 스케줄링 선택을 하기 위해 우선순위 값을 사용할 수 있습니다(MAY).

일반적으로 HTTP 서버가 가능한 한 모든 응답을 가능한 한 일찍 전송하는 것이 유리합니다. 그러나 단일 연결에서 여러 요청을 제공할 때는 연결 대역폭과 같은 자원을 놓고 요청들 간에 경쟁이 발생할 수 있습니다. 이 절에서는 그러한 경쟁이 있을 때 서버가 경쟁하는 응답들을 어떤 순서로 전송할지 스케줄링하는 방법에 대한 고려사항을 설명합니다.

서버 스케줄링은 여러 입력에 기반한 우선순위화 프로세스이며, 우선순위 신호는 그 입력의 한 형태에 불과합니다. 구현 선택이나 배포 환경과 같은 요인들도 역할을 합니다. 연결 하나에는 많은 동적 변형이 있을 수 있습니다. 이러한 이유로 보편적인 스케줄링 알고리즘을 설명하는 것은 불가능합니다. 본 문서는 서버가 우선순위 매개변수에 대해 어떻게 동작할 수 있는지에 대한 기본적이고 비포괄적인 권고를 제공합니다. 또한 서버가 우선순위 신호를 다른 요인들과 어떻게 결합할지는 상세히 설명하지 않습니다. 엔드포인트는 우선순위 신호에 기반한 특정 처리에 의존할 수 없습니다. 우선순위 표시는 제안일 뿐입니다.

가능할 때 서버는 urgency 매개변수(섹션 4.1)를 존중하여 더 높은 긴급도의 응답을 더 낮은 긴급도의 응답보다 먼저 전송하는 것이 권장됩니다(RECOMMENDED).

incremental 매개변수는 클라이언트가 응답 바이트를 도착 시 어떻게 처리하는지를 나타냅니다. 가능한 경우 서버는 incremental 매개변수(섹션 4.2)를 존중하는 것이 권장됩니다(RECOMMENDED).

동일한 긴급도의 비점진적(non-incremental) 응답들은 스트림 ID의 오름차순으로 대역폭 할당을 우선하는 방식으로 제공하는 것이 바람직합니다(SHOULD). 이는 클라이언트가 요청 순서를 사용하여 응답 순서에 영향을 줄 수 있게 합니다.

동일한 긴급도의 점진적(incremental) 응답들은 대역폭을 공유하여 제공하는 것이 바람직합니다(SHOULD). 점진적 응답의 메시지 내용은 부분(part) 또는 청크로서 수신될 때 사용됩니다. 클라이언트는 전체 자원 한 개를 완전히 받는 것보다 여러 자원의 일부를 받는 것이 더 유익할 수 있습니다. 실제로 어느 정도의 자원 부분이 성능 향상에 유용한지는 다양합니다. 일부 자원 유형은 중요 요소를 초기에 포함하고, 다른 자원은 점진적으로 정보를 사용할 수 있습니다. 본 체계는 서버가 크기, 유형 또는 기타 입력을 사용하여 어떻게 우선순위를 결정해야 하는지에 대한 명시적 의무를 제공하지 않습니다.

1. 동일한 긴급도에서 큰 리소스에 대한 비점진적 요청이 뒤따르는 작은 리소스에 대한 점진적 요청보다 먼저 있는 경우.
2. 동일한 긴급도에서 길이를 예측할 수 없는 점진적 요청이 뒤따르는 큰 비점진적 리소스 요청이 있는 경우.

가능한 경우 서버는 이러한 기아(starvation)를 피하는 것이 권장됩니다(RECOMMENDED). 이를 수행하는 방법은 구현상의 결정입니다. 예를 들어 서버는 콘텐츠 크기와 같은 다른 정보를 기반으로 특정 유형의 점진적 응답을 사전적으로 전송할 수 있습니다.

서버 푸시의 최적 스케줄링은 특히 푸시된 리소스가 활성 동시 요청과 경쟁할 때 어렵습니다. 서버는 푸시 스케줄링 시 푸시되는 리소스의 유형이나 크기, 푸시를 유발한 요청의 우선순위, 활성 동시 응답의 수, 다른 활성 동시 응답의 우선순위 등 여러 요인을 고려할 수 있습니다. 이를 적용하는 최선의 방법에 대한 일반적 지침은 없습니다. 너무 단순한 서버는 너무 높은 우선순위로 푸시하여 클라이언트 요청을 차단할 수 있고, 또는 너무 낮은 우선순위로 푸시하여 응답을 지연시켜 서버 푸시의 목적을 무력화할 수 있습니다.

우선순위 신호는 서버 푸시 스케줄링의 한 요인입니다. 기본값 적용 개념은 클라이언트가 명시적으로 초기 우선순위를 신호하지 않았기 때문에 약간 다르게 적용됩니다. 서버는 오리진 응답에 제공된 우선순위 신호를 적용할 수 있습니다; 병합에 대한 지침은 섹션 8을 참조하세요. 오리진 신호가 없는 경우 기본 매개변수 값을 적용하는 것은 최적이 아닐 수 있습니다. 서버가 푸시된 응답을 스케줄링하는 방법에 따라, PUSH_PROMISE 또는 HEADERS 프레임에 Priority 필드를 포함하여 클라이언트에 의도된 우선순위를 신호할 수 있습니다.

스트림이 CONNECT 요청을 운반할 때, 본 문서의 스케줄링 지침은 스트림의 프레임에 적용됩니다. 다수의 CONNECT 요청을 발행하는 클라이언트는 incremental 매개변수를 true로 설정할 수 있습니다. incremental 매개변수 처리에 대한 권고를 구현한 서버(섹션 10)는 이러한 스트림들을 공정하게 스케줄링하여 한 CONNECT 스트림이 다른 스트림을 차단하지 않도록 할 가능성이 높습니다.

TCP 및 QUIC과 같은 전송 프로토콜은 패킷 손실을 감지하고 손실된 정보를 재전송함으로써 신뢰성을 제공합니다. 섹션 10의 고려사항 외에도, 재전송 데이터의 스케줄링은 새로운 데이터와 경쟁할 수 있습니다. 이 절의 나머지 부분은 QUIC을 사용할 때의 고려사항을 논의합니다.

RFC 9000 섹션 13.3는 다음과 같이 명시합니다: "엔드포인트는 애플리케이션이 지정한 우선순위를 제외하고는 재전송 데이터를 새 데이터보다 우선시해야 한다(SHOULD)." HTTP/3 애플리케이션이 본 문서에서 정의한 우선순위 체계를 사용하고 QUIC 전송 구현이 애플리케이션이 지정한 스트림 우선순위를 지원하는 경우, 새 데이터와 재전송 데이터를 스케줄링할 때 스트림의 상대적 우선순위를 고려하는 전송은 애플리케이션의 기대에 더 잘 부합할 수 있습니다. 그러나 이러한 정보를 기반으로 전송이 어떻게 스케줄링할지는 여러 요인과 절충에 따라 달라지므로 요구사항은 없습니다. 예를 들어, 높은 긴급도의 스트림에 대해 새 데이터를 낮은 우선순도의 스트림에 대한 재전송보다 우선시하거나, 우선순위와 관계없이 재전송 데이터를 새 데이터보다 우선시할 수 있습니다.

RFC 9002 섹션 6.2.4는 Probe Timeout 타이머 만료 후 프로브 패킷 전송과 관련된 응용 계층 우선순위 고려사항도 강조합니다. 애플리케이션 우선순위를 지원하는 QUIC 구현은 프로브 데이터 선택 시 스트림의 상대적 우선순위를 사용할 수 있습니다.

일반적으로 HTTP 구현체는 대역폭을 놓고 경쟁하는 연결 간의 공정성을 유지하는 역할을 전송 계층에 의존합니다. 중개자가 클라이언트 연결에서 HTTP 요청을 수신하면 이를 백엔드 연결로 전달합니다. 중개자가 요청을 어떻게 병합(coalesce)하거나 분할(split)하느냐에 따라 서로 다른 클라이언트들이 서로 다른 성능을 경험할 수 있습니다. 중개자가 포워딩 시 우선순위 신호를 사용하는 경우 이 불균형은 더 확대될 수 있습니다. 섹션 13.1 및 13.2는 이러한 불공정성 확대의 완화책을 논의합니다.

반대로, 섹션 13.3는 서버가 우선순위 신호에 따라 일부 연결에 의도적으로 불균등한 대역폭을 할당할 수 있는 방법을 논의합니다.

홉-바이-홉 프레임을 사용하는 HTTP/2의 우선순위 지정 체계와 대조적으로, Priority 헤더 필드는 "종단 간(end-to-end)"로 정의됩니다.

클라이언트가 응답을 처리하는 방식은 그 요청을 생성한 클라이언트에 연관된 속성이며 중개자의 속성이 아닙니다. 따라서 이는 종단 간 속성입니다. Priority 헤더 필드로 전달되는 이러한 종단 간 속성이 동일한 연결을 공유하는 응답들 간의 우선순위화에 어떻게 영향을 미치는지는 홉-바이-홉의 문제입니다.

Priority 헤더 필드를 종단 간으로 정의해 두는 것은 캐싱 중개자에게 중요합니다. 이러한 중개자는 응답과 함께 Priority 헤더 필드 값을 캐시할 수 있으며, 헤더 필드가 종단 간으로 정의되어 있기 때문에 캐시된 응답을 제공할 때 캐시된 헤더 필드 값을 활용할 수 있습니다. 홉-바이-홉으로 정의되어 있었다면 이것이 불가능했을 것입니다.

섹션 7은 PRIORITY_UPDATE 프레임의 서버 버퍼링에 대한 고려사항을 설명합니다.

섹션 10에는 특정 방식으로 응답에 우선순위를 부여하는 서버가 응답을 전송할 능력을 고갈시킬 수 있는 사례들이 제시되어 있습니다.

[STRUCTURED-FIELDS]의 보안 고려사항은 섹션 4에서 정의된 우선순위 매개변수 처리에 적용됩니다.

Field Name:

Priority

Status:

permanent

Reference:

이 문서

Code:

0x9

Name:

SETTINGS_NO_RFC7540_PRIORITIES

Initial Value:

0

Reference:

이 문서

Code:

0x10

Frame Type:

PRIORITY_UPDATE

Reference:

이 문서

Value:

0xF0700-0xF0701

Frame Type:

PRIORITY_UPDATE

Status:

permanent

Reference:

이 문서

Change Controller:

IETF

Contact:

ietf-http-wg@w3.org

IANA는 <https://www.iana.org/assignments/http-priority>에 "Hypertext Transfer Protocol (HTTP) Priority" 레지스트리를 생성했으며, 표 1의 항목들로 채워 놓았습니다. 관련 절차는 섹션 4.3.1을 참조하십시오.

Roy Fielding은 <https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf>에서 우선순위를 표현하기 위해 헤더 필드를 사용하는 아이디어를 제시했습니다. <https://github.com/pmeenan/http3-prioritization-proposal>에서 Patrick Meenan은 긴급도와 동시성의 튜플을 사용해 우선순위를 표현하는 것을 지지했습니다. HTTP/2 우선순위 비활성화 기능의 영감은 Brad Lassey와 Lucas Pardue가 작성한 [PRIORITY-SETTING]에서 얻었으며, 그 문서에 반영되지 않은 피드백을 바탕으로 일부 수정이 이루어졌습니다.

HTTP/2 우선순위의 대안 정의에 대한 동기는 광범위한 HTTP 커뮤니티 내의 논의에서 도출되었습니다. 본 문서에 명시적으로 통합된 텍스트를 제공해 준 Roberto Peon, Martin Thomson 및 Netflix에 특별한 감사를 표합니다.

위에 열거된 인물들 외에도, 이 문서는 Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Fielding 및 이 문서의 저자들로 구성된 HTTP 우선순위 설계 팀의 광범위한 논의에 크게 빚지고 있습니다.

Yang Chi는 재전송 스케줄링 섹션에 기여했습니다.