인터넷 엔지니어링 태스크 포스 (IETF)

M. Bishop, 편집자

요청 의견(Request for Comments): 9114

Akamai

분류: 표준 트랙

2022년 6월

ISSN: 2070-1721

HTTP/3

요약

QUIC 전송 프로토콜은 스트림 다중화, 스트림별 흐름 제어, 저지연 연결 수립과 같이 HTTP 전송에서 바람직한 여러 기능을 제공합니다. 이 문서는 QUIC 위에서의 HTTP 의미 매핑을 설명합니다. 또한 이 문서는 QUIC에 의해 포함된 HTTP/2 기능들을 식별하고 HTTP/2 확장 기능을 HTTP/3로 이식하는 방법을 설명합니다.

이 메모의 상태

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

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

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

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.

1. 소개
- 1.1. HTTP의 이전 버전
- 1.2. QUIC로의 위임
2. HTTP/3 프로토콜 개요
- 2.1. 문서 구성
- 2.2. 관습 및 용어
3. 연결 설정 및 관리
- 3.1. HTTP/3 엔드포인트 검색
  - 3.1.1. HTTP 대체 서비스
  - 3.1.2. 다른 스킴
- 3.2. 연결 수립
- 3.3. 연결 재사용
4. HTTP/3에서 HTTP 의미 표현
- 4.1. HTTP 메시지 프레이밍
  - 4.1.1. 요청 취소 및 거부
  - 4.1.2. 형식이 잘못된 요청 및 응답
- 4.2. HTTP 필드
  - 4.2.1. 필드 압축
  - 4.2.2. 헤더 크기 제한
- 4.3. HTTP 제어 데이터
  - 4.3.1. 요청 의사-헤더 필드
  - 4.3.2. 응답 의사-헤더 필드
- 4.4. CONNECT 메서드
- 4.5. HTTP 업그레이드
- 4.6. 서버 푸시
5. 연결 종료
- 5.1. 유휴 연결
- 5.2. 연결 셧다운
- 5.3. 즉시 애플리케이션 종료
- 5.4. 전송 종료
6. 스트림 매핑 및 사용
- 6.1. 양방향 스트림
- 6.2. 단방향 스트림
7. HTTP 프레이밍 계층
- 7.1. 프레임 레이아웃
- 7.2. 프레임 정의
  - 7.2.1. DATA
  - 7.2.2. HEADERS
  - 7.2.3. CANCEL_PUSH
  - 7.2.4. SETTINGS
  - 7.2.5. PUSH_PROMISE
  - 7.2.6. GOAWAY
  - 7.2.7. MAX_PUSH_ID
  - 7.2.8. 예약된 프레임 유형
8. 오류 처리
- 8.1. HTTP/3 오류 코드
9. HTTP/3 확장
10. 보안 고려사항
11. IANA 고려사항
- 11.1. HTTP/3 식별 문자열 등록
- 11.2. 새 레지스트리
  - 11.2.1. 프레임 유형
  - 11.2.2. 설정 매개변수
  - 11.2.3. 오류 코드
  - 11.2.4. 스트림 유형
12. 참고문헌
- 12.1. 규범 참조
- 12.2. 정보적 참조
Appendix A. HTTP/2에서 전환하기 위한 고려사항
감사의 글
색인
저자 주소

1. 소개

HTTP 의미론([HTTP])은 인터넷에서 광범위한 서비스에 사용됩니다. 이러한 의미론은 보통 HTTP/1.1 및 HTTP/2와 함께 사용되었습니다. HTTP/1.1은 다양한 전송 및 세션 계층 위에서 사용되어 왔고, HTTP/2는 주로 TLS 위의 TCP와 함께 사용되어 왔습니다. HTTP/3은 동일한 의미론을 새로운 전송 프로토콜인 QUIC 위에서 지원합니다.

1.1. HTTP의 이전 버전

HTTP/1.1 ([HTTP/1.1])은 공백으로 구분된 텍스트 필드를 사용하여 HTTP 메시지를 전달합니다. 이러한 교환은 사람이 읽을 수 있지만, 메시지 포맷에 공백을 사용하는 것은 파싱 복잡성과 변형된 동작에 대한 과도한 관용으로 이어집니다.

HTTP/1.1에는 다중화 계층이 포함되어 있지 않기 때문에, 여러 TCP 연결이 병렬로 요청을 처리하는 데 자주 사용됩니다. 그러나 TCP가 여러 연결 간에 혼잡 제어를 공유하지 않기 때문에 이는 혼잡 제어 및 네트워크 효율성에 부정적인 영향을 줍니다.

HTTP/2 ([HTTP/2])는 전송 계층을 변경하지 않고 지연 시간을 개선하기 위해 이진 프레이밍 및 다중화 계층을 도입했습니다. 그러나 HTTP/2의 병렬적 다중화 특성은 TCP의 손실 복구 메커니즘에 보이지 않기 때문에, 패킷 손실이나 재정렬이 발생하면 해당 손실 패킷과 직접적인 관련이 없는 활성 트랜잭션들도 정지(stall)를 겪게 됩니다.

1.2. QUIC로의 위임

QUIC 전송 프로토콜은 HTTP/2 프레이밍 계층이 제공하는 것과 유사한 스트림 다중화 및 스트림별 흐름 제어를 통합합니다. 스트림 수준의 신뢰성(reliability)과 연결 전체에 대한 혼잡 제어를 제공함으로써, QUIC는 TCP 매핑과 비교하여 HTTP 성능을 개선할 수 있는 능력을 가집니다. QUIC은 또한 전송 계층에서 TLS 1.3([TLS])을 통합하여, TCP 위에서 TLS를 실행하는 것과 유사한 기밀성 및 무결성을 제공하면서 TCP Fast Open([TFO])의 향상된 연결 설정 지연을 제공합니다.

이 문서는 QUIC 전송 프로토콜 위에서의 HTTP 의미론 매핑인 HTTP/3를 정의하며, 설계는 HTTP/2에 크게 의존합니다. HTTP/3는 데이터의 기밀성과 무결성 보호, 피어 인증, 그리고 스트림별로 신뢰할 수 있고 순서화된 전달을 제공하기 위해 QUIC에 의존합니다. 스트림 수명 및 흐름 제어 문제를 QUIC에 위임하는 동안에도, 각 스트림에서는 HTTP/2 프레이밍과 유사한 이진 프레이밍이 사용됩니다. 일부 HTTP/2 기능은 QUIC에 의해 포함(subsumed)되며, 다른 기능들은 QUIC 위에 구현됩니다.

QUIC은 [QUIC-TRANSPORT]에서 설명됩니다. HTTP/2의 전체 설명은 [HTTP/2]를 참조하십시오.

2. HTTP/3 프로토콜 개요

HTTP/3는 QUIC 전송 프로토콜과 HTTP/2와 유사한 내부 프레이밍 계층을 사용하여 HTTP 의미론을 위한 전송을 제공합니다.

클라이언트가 특정 엔드포인트에 HTTP/3 서버가 존재한다는 것을 알게 되면 QUIC 연결을 엽니다. QUIC은 프로토콜 협상, 스트림 기반 다중화 및 흐름 제어를 제공합니다. HTTP/3 엔드포인트의 검색은 섹션 3.1에 설명되어 있습니다.

각 스트림 내에서 HTTP/3 통신의 기본 단위는 프레임(섹션 7.2)입니다. 각 프레임 유형은 서로 다른 목적을 가집니다. 예를 들어, HEADERS 및 DATA 프레임은 HTTP 요청과 응답의 기초를 형성합니다(섹션 4.1). 연결 전체에 적용되는 프레임은 전용 제어 스트림에서 전달됩니다.

요청의 다중화는 QUIC 스트림 추상화를 사용하여 수행되며, 이는 섹션 2와 [QUIC-TRANSPORT]에 설명되어 있습니다. 각 요청-응답 쌍은 단일 QUIC 스트림을 소비합니다. 스트림들은 서로 독립적이므로, 하나의 스트림이 차단되거나 패킷 손실을 겪더라도 다른 스트림의 진행을 방해하지 않습니다.

서버 푸시는 HTTP/2([HTTP/2])에서 도입된 상호작용 모드로서, 서버가 클라이언트가 해당 요청을 할 것으로 예상하여 요청-응답 교환을 클라이언트로 푸시할 수 있게 허용합니다. 이는 잠재적 지연 개선을 위해 네트워크 사용을 거래(trade-off)하는 것입니다. 서버 푸시를 관리하기 위해 PUSH_PROMISE, MAX_PUSH_ID, 및 CANCEL_PUSH와 같은 여러 HTTP/3 프레임이 사용됩니다.

HTTP/2에서와 같이 요청 및 응답 필드는 전송을 위해 압축됩니다. HPACK([HPACK])은 압축된 필드 섹션의 순차적 전송에 의존하는데(이는 QUIC이 보장하지 않는 특성), HTTP/3는 HPACK을 QPACK([QPACK])으로 대체합니다. QPACK은 필드 테이블 상태를 수정하고 추적하기 위해 별도의 단방향 스트림을 사용하고, 인코딩된 필드 섹션은 테이블을 수정하지 않고 그 상태를 참조합니다.

2.1. 문서 구성

다음 섹션들은 HTTP/3 연결의 수명 주기에 대한 자세한 개요를 제공합니다:

"연결 설정 및 관리" (섹션 3)은 HTTP/3 엔드포인트가 어떻게 검색되고 HTTP/3 연결이 어떻게 수립되는지를 다룹니다.
"HTTP/3에서 HTTP 의미 표현" (섹션 4)은 프레임을 사용하여 HTTP 의미론이 어떻게 표현되는지를 설명합니다.
"연결 종료" (섹션 5)은 HTTP/3 연결이 정상적으로 또는 갑작스럽게 어떻게 종료되는지를 설명합니다.

와이어 프로토콜의 세부사항과 전송과의 상호작용은 이후 섹션들에서 설명됩니다:

"스트림 매핑 및 사용" (섹션 6)은 QUIC 스트림이 사용되는 방식을 설명합니다.
"HTTP 프레이밍 계층" (섹션 7)은 대부분의 스트림에서 사용되는 프레임들을 설명합니다.
"오류 처리" (섹션 8)은 특정 스트림 또는 연결 전체에 대해 오류 상태가 어떻게 처리되고 표현되는지를 설명합니다.

추가 자원은 문서의 마지막 섹션들에 제공됩니다:

"HTTP/3 확장" (섹션 9)은 향후 문서에서 새로운 기능을 어떻게 추가할 수 있는지를 설명합니다.
HTTP/2와 HTTP/3 간의 보다 자세한 비교는 부록 A에서 찾을 수 있습니다.

2.2. 관례 및 용어

이 문서에서 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 나타나는 경우에 한해 BCP 14의 [RFC2119] 및 [RFC8174]에 설명된 대로 해석됩니다.

이 문서는 [QUIC-TRANSPORT]에서 사용되는 가변 길이 정수 인코딩을 사용합니다.

다음 용어들이 사용됩니다:

중단(abort):: 오류 상태로 인해 발생할 수 있는 연결 또는 스트림의 갑작스러운 종료입니다.
클라이언트(client):: HTTP/3 연결을 시작하는 엔드포인트입니다. 클라이언트는 HTTP 요청을 보내고 HTTP 응답을 수신합니다.
연결(connection):: QUIC을 전송 프로토콜로 사용하는 두 엔드포인트 간의 전송 계층 연결입니다.
연결 오류(connection error) :: 전체 HTTP/3 연결에 영향을 미치는 오류입니다.
엔드포인트(endpoint):: 연결의 클라이언트 또는 서버 중 하나입니다.
프레임(frame):: 헤더와 프레임 유형에 따라 구조화된 가변 길이 바이트 시퀀스로 구성된 HTTP/3에서 스트림상의 가장 작은 통신 단위입니다.

이 문서와 [QUIC-TRANSPORT] 모두에 "프레임"이라 불리는 프로토콜 요소가 존재합니다. [QUIC-TRANSPORT]의 프레임이 참조될 때는 프레임 이름 앞에 "QUIC"이 붙습니다. 예를 들어, "QUIC CONNECTION_CLOSE frames". 이 접두사가 없는 참조는 섹션 7.2에서 정의된 프레임을 가리킵니다.
HTTP/3 연결(HTTP/3 connection):: 협상된 애플리케이션 프로토콜이 HTTP/3인 QUIC 연결입니다.
피어(peer):: 엔드포인트를 의미합니다. 특정 엔드포인트를 논할 때 "피어"는 논의의 주요 대상에서 원격에 있는 엔드포인트를 가리킵니다.
수신자(receiver):: 프레임을 수신하는 엔드포인트입니다.
송신자(sender):: 프레임을 전송하는 엔드포인트입니다.
서버(server):: HTTP/3 연결을 수락하는 엔드포인트입니다. 서버는 HTTP 요청을 수신하고 HTTP 응답을 보냅니다.
스트림(stream):: QUIC 전송이 제공하는 양방향 또는 단방향 바이트 스트림입니다. HTTP/3 연결 내의 모든 스트림은 "HTTP/3 스트림"으로 간주될 수 있지만, HTTP/3 내에서 여러 스트림 유형이 정의됩니다.
스트림 오류(stream error) :: 개별 스트림상의 애플리케이션 수준 오류입니다.

"콘텐츠(content)"라는 용어는 RFC 9110의 섹션 6.4에서 정의됩니다 ([HTTP]).

마지막으로, "리소스(resource)", "메시지(message)", "유저 에이전트(user agent)", "오리진 서버(origin server)", "게이트웨이(gateway)", "중계자(intermediary)", "프록시(proxy)", 및 "터널(tunnel)"이라는 용어들은 RFC 9110의 섹션 3에서 정의됩니다 ([HTTP]).

이 문서의 패킷 다이어그램은 필드의 순서와 크기를 설명하기 위해 RFC 9000의 섹션 1.3에 정의된 형식을 사용합니다 ([QUIC-TRANSPORT]).

3. 연결 설정 및 관리

3.1. HTTP/3 엔드포인트 검색

HTTP는 권한 있는 응답(authoritative response)이라는 개념에 의존합니다: 이는 응답 시점에 대상 리소스의 상태를 고려하여 원본 URI 내에 식별된 오리진 서버에 의해(또는 그 지시에 따라) 해당 요청에 대해 가장 적절하다고 판단된 응답입니다. HTTP URI에 대한 권한 있는 서버를 찾는 방법은 RFC 9110 섹션 4.3에 논의되어 있습니다 ([HTTP]).

"https" 스킴은 권한(authority)을 URI의 권한 구성요소로 식별된 호스트에 대해 클라이언트가 신뢰할 수 있다고 판단하는 인증서의 소유와 연관시킵니다. TLS 핸드셰이크에서 서버 인증서를 수신한 후, 클라이언트는 RFC 9110 섹션 4.3.4에 설명된 절차를 사용하여 인증서가 URI의 오리진 서버와 수락 가능하게 일치하는지 검증해야 합니다(MUST). 인증서가 URI의 오리진 서버와 관련하여 검증될 수 없다면, 클라이언트는 해당 서버를 그 오리진에 대해 권한 있는 것으로 간주해서는 안 됩니다(MUST NOT).

클라이언트는 호스트 식별자를 IP 주소로 해석하고 해당 주소의 지정된 포트로 QUIC 연결을 설정(위에서 설명한 서버 인증서 검증 포함)한 뒤, 해당 보안 연결을 통해 URI를 대상으로 하는 HTTP/3 요청 메시지를 서버로 전송함으로써 "https" URI에 있는 리소스에 접근을 시도할 수 있습니다(MAY). HTTP/3를 선택하기 위한 다른 메커니즘이 사용되지 않는 한, 토큰 "h3"는 TLS 핸드셰이크 동안의 Application-Layer Protocol Negotiation(ALPN; [RFC7301]) 확장에서 사용됩니다.

연결 문제(예: UDP 차단)는 QUIC 연결 수립 실패를 초래할 수 있습니다; 이 경우 클라이언트는 TCP 기반 버전의 HTTP를 사용하려고 시도해야 합니다(SHOULD).

서버는 임의의 UDP 포트에서 HTTP/3를 제공할 수 있습니다(MAY); 대체 서비스 광고는 항상 명시적인 포트를 포함하며, URI는 명시적 포트 또는 스킴과 연관된 기본 포트를 포함합니다.

3.1.1. HTTP 대체 서비스

HTTP 오리진은 Alt-Svc HTTP 응답 헤더 필드 또는 HTTP/2 ALTSVC 프레임([ALTSVC])을 통해 "h3" ALPN 토큰을 사용하여 동등한 HTTP/3 엔드포인트의 가용성을 광고할 수 있습니다.

예를 들어, 오리진은 HTTP 응답에 다음 헤더 필드를 포함하여 동일한 호스트 이름에서 UDP 포트 50781에서 HTTP/3가 사용 가능함을 나타낼 수 있습니다:

Alt-Svc: h3=":50781"

HTTP/3 지원을 나타내는 Alt-Svc 레코드를 수신하면, 클라이언트는 표시된 호스트 및 포트로 QUIC 연결을 수립하려고 시도할 수 있습니다(MAY); 이 연결이 성공하면, 클라이언트는 이 문서에 설명된 매핑을 사용하여 HTTP 요청을 보낼 수 있습니다.

3.1.2. 기타 스킴

HTTP는 전송 프로토콜과 독립적이지만, "http" 스킴은 권한을 해당 권한 구성요소에 식별된 호스트의 지정된 포트에서 TCP 연결을 수신할 수 있는 능력과 연관시킵니다. HTTP/3는 TCP를 사용하지 않기 때문에, "http" URI로 식별된 리소스의 권한 있는 서버에 대한 직접 액세스에는 HTTP/3을 사용할 수 없습니다. 그러나 [ALTSVC]와 같은 프로토콜 확장은 권한 있는 서버가 또한 권한을 가지며 HTTP/3을 통해 접근 가능할 수 있는 다른 서비스를 식별하도록 허용합니다.

"https"가 아닌 스킴을 가진 오리진에 대해 요청을 하기 전에, 클라이언트는 서버가 해당 스킴을 제공할 의사가 있는지 확인해야 합니다(MUST). "http" 스킴을 가진 오리진에 대해 이를 달성하기 위한 실험적 방법은 [RFC8164]에 설명되어 있습니다. 향후 다양한 스킴에 대해 다른 메커니즘이 정의될 수 있습니다.

3.2. 연결 수립

HTTP/3는 기본 전송으로 QUIC 버전 1을 사용합니다. HTTP/3와 함께 다른 QUIC 전송 버전을 사용하는 것은 향후 규격에서 정의될 수 있습니다(MAY).

QUIC 버전 1은 핸드셰이크 프로토콜로 TLS 버전 1.3 이상을 사용합니다. HTTP/3 클라이언트는 TLS 핸드셰이크 동안 대상 호스트를 서버에 표시하는 메커니즘을 지원해야 합니다(MUST). 서버가 도메인 이름으로 식별되는 경우([DNS-TERMS]), 클라이언트는 대상 호스트를 표시하기 위해 Server Name Indication(SNI; [RFC6066]) TLS 확장을 보내야 합니다(MUST), 대체 메커니즘이 사용되지 않는 한.

QUIC 연결은 [QUIC-TRANSPORT]에 설명된 대로 수립됩니다. 연결 수립 동안 HTTP/3 지원은 TLS 핸드셰이크에서 ALPN 토큰 "h3"를 선택함으로써 표시됩니다. 동일한 핸드셰이크에서 다른 애플리케이션 계층 프로토콜에 대한 지원이 제공될 수 있습니다(MAY).

핵심 QUIC 프로토콜과 관련된 연결 수준 옵션은 초기 암호화 핸드셰이크에서 설정되는 반면, HTTP/3에 특정한 설정은 SETTINGS 프레임에서 전달됩니다. QUIC 연결이 설정된 후, 각 엔드포인트는 자신의 HTTP 제어 스트림의 초기 프레임으로 SETTINGS 프레임을 보내야 합니다(MUST).

3.3. 연결 재사용

HTTP/3 연결은 여러 요청에 걸쳐 지속됩니다. 최상의 성능을 위해, 클라이언트는 서버와의 추가 통신이 필요 없다고 판단될 때(예: 사용자가 특정 웹페이지에서 떠날 때)까지 연결을 닫지 않는 것이 예상됩니다. 또는 서버가 연결을 닫을 때까지 유지합니다.

서버 엔드포인트에 대한 연결이 존재하면, 이 연결은 여러 다른 URI 권한 구성요소를 가진 요청들에 대해 재사용될 수 있습니다(MAY). 새로운 오리진에 대해 기존 연결을 사용하려면, 클라이언트는 새 오리진 서버에 대해 서버가 제시한 인증서를 RFC 9110 섹션 4.3.4에 설명된 절차를 사용하여 검증해야 합니다(MUST). 이는 클라이언트가 서버 인증서와 해당 인증서를 검증하는 데 필요한 추가 정보를 보유해야 함을 의미합니다; 이를 보유하지 않는 클라이언트는 추가 오리진에 대해 연결을 재사용할 수 없습니다.

어떤 이유로든 인증서가 새 오리진에 대해 수락될 수 없다면, 해당 연결은 재사용되어서는 안 되며(MUST NOT) 새 오리진에 대해 새로운 연결을 수립해야 합니다(SHOULD). 인증서 검증 실패의 이유가 연결에 이미 연관된 다른 오리진들에도 적용될 수 있는 경우, 클라이언트는 해당 오리진들에 대해 서버 인증서를 다시 검증하는 것이 바람직합니다(SHOULD). 예를 들어, 인증서가 만료되었거나 폐지된 경우, 이는 해당 인증서를 사용하여 권한을 설정한 다른 모든 오리진을 무효화하는 데 사용될 수 있습니다.

클라이언트는 URI, 선택된 대체 서비스([ALTSVC]), 구성된 프록시 또는 이들 중 어느 것의 이름 해석에서 파생될 수 있는 특정 IP 주소와 UDP 포트에 대해 두 개 이상의 HTTP/3 연결을 열어서는 안 됩니다(SHOULD NOT). 클라이언트는 서로 다른 전송 또는 TLS 구성으로 동일한 IP 주소와 UDP 포트에 대해 여러 HTTP/3 연결을 열 수 있지만(MAY), 동일한 구성으로 여러 연결을 생성하는 것은 피해야 합니다(SHOULD).

서버는 가능한 한 오래 열린 HTTP/3 연결을 유지하는 것이 권장되지만, 필요하다면 유휴 연결을 종료할 수 있습니다. 어느 쪽 엔드포인트가 HTTP/3 연결을 닫기로 선택하면, 종료하는 엔드포인트는 먼저 GOAWAY 프레임(섹션 5.2)을 보내어 양 엔드포인트가 이전에 전송된 프레임들이 처리되었는지 신뢰성 있게 판단하고 필요한 남은 작업을 정상적으로 완료하거나 종료할 수 있도록 해야 합니다(SHOULD).

특정 오리진에 대해 클라이언트가 HTTP/3 연결을 재사용하기를 원치 않는 서버는 해당 요청에 대해 421(잘못된 대상 요청, Misdirected Request) 상태 코드를 응답으로 보내어 자신이 그 요청에 대해 권한이 없음을 표시할 수 있습니다; 자세한 내용은 RFC 9110 섹션 7.4를 참조하십시오 ([HTTP]).

4. HTTP/3에서 HTTP 의미 표현

4.1. HTTP 메시지 프레이밍

클라이언트는 request stream에서 HTTP 요청을 보냅니다. 이는 클라이언트가 시작하는 양방향 QUIC 스트림입니다; 섹션 6.1을 참조하십시오. 클라이언트는 주어진 스트림에서 단 하나의 요청만 전송해야 합니다(MUST). 서버는 같은 스트림에서 0개 이상의 중간(interim) HTTP 응답을 전송한 뒤, 아래에 상세히 설명된 것처럼 단 하나의 최종 HTTP 응답을 전송합니다. 중간 및 최종 HTTP 응답에 대한 설명은 RFC 9110 섹션 15을 참고하십시오.

푸시된 응답은 서버가 시작한 단방향 QUIC 스트림에서 전송됩니다; 섹션 6.2.2를 참조하십시오. 서버는 표준 응답과 동일한 방식으로 0개 이상의 중간 응답을 보내고 이어서 단 하나의 최종 응답을 보냅니다. 푸시에 대한 자세한 내용은 섹션 4.6에 설명되어 있습니다.

주어진 스트림에서 다수의 요청 수신 또는 최종 응답 뒤에 추가 HTTP 응답이 수신되는 경우는 malformed로 취급되어야 합니다(MUST).

HTTP 메시지(요청 또는 응답)는 다음으로 구성됩니다:

메시지 제어 데이터를 포함하는 헤더 섹션으로, 단일 HEADERS 프레임으로 전송됩니다,
선택적으로, 콘텐츠가 있을 경우 일련의 DATA 프레임으로 전송됩니다, 그리고
선택적으로, 트레일러 섹션이 있을 경우 단일 HEADERS 프레임으로 전송됩니다.

헤더 및 트레일러 섹션은 RFC 9110 섹션 6.3 및 섹션 6.5에 설명되어 있으며, 콘텐츠는 섹션 6.4에 설명되어 있습니다.

잘못된 프레임 시퀀스 수신은 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST). 특히, 어떤 DATA 프레임이 어떠한 HEADERS 프레임 전에 오거나, 트레일링 HEADERS 프레임 뒤에 HEADERS 또는 DATA 프레임이 오는 경우는 무효로 간주됩니다. 다른 프레임 유형, 특히 알려지지 않은 프레임 유형은 자체 규칙에 따라 허용될 수 있습니다; 자세한 내용은 섹션 9를 참조하십시오.

서버는 응답 메시지의 프레임들 이전, 이후 또는 교차로 하나 이상 의 PUSH_PROMISE 프레임을 보낼 수 있습니다(MAY). 이러한 PUSH_PROMISE 프레임은 응답의 일부가 아닙니다; 자세한 내용은 섹션 4.6을 참조하십시오. PUSH_PROMISE 프레임은 push streams에서 허용되지 않습니다; 만약 푸시된 응답이 PUSH_PROMISE 프레임을 포함하면 이는 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST).

알려지지 않은 유형의 프레임(섹션 9), 예약된 프레임(섹션 7.2.8)을 포함하여, 이러한 프레임들은 요청 또는 push stream에서 다른 이 절에서 설명된 프레임들 이전, 이후 또는 교차로 전송될 수 있습니다(MAY).

HEADERS 및 PUSH_PROMISE 프레임은 QPACK 동적 테이블에 대한 업데이트를 참조할 수 있습니다. 이러한 업데이트는 메시지 교환의 직접적인 일부는 아니지만, 메시지를 소비하기 전에 수신 및 처리되어야 합니다. 자세한 내용은 섹션 4.2를 참조하십시오.

Transfer codings(자세한 내용은 RFC 9112 섹션 7)은 HTTP/3에 대해 정의되지 않습니다; Transfer-Encoding 헤더 필드는 사용되어서는 안 됩니다(MUST NOT).

응답은 오직 하나 이상의 중간 응답(1xx; RFC 9110 섹션 15.2 참조)이 동일한 요청에 대한 최종 응답에 앞설 때에만 여러 메시지로 구성될 수 있습니다(MAY). 중간 응답에는 콘텐츠나 트레일러 섹션이 포함되지 않습니다.

HTTP 요청/응답 교환은 클라이언트가 시작한 양방향 QUIC 스트림을 완전히 소비합니다. 요청을 전송한 후, 클라이언트는 전송을 위한 스트림을 닫아야 합니다(MUST). CONNECT 메서드를 사용하는 경우를 제외하고(섹션 4.4 참조), 클라이언트는 응답을 수신하는 것을 스트림 닫기 조건으로 삼아서는 안 됩니다(MUST NOT). 서버는 최종 응답을 전송한 후 전송을 위한 스트림을 닫아야 합니다(MUST). 이 시점에서 QUIC 스트림은 완전히 닫힙니다.

스트림이 닫히면 이는 최종 HTTP 메시지의 끝을 나타냅니다. 일부 메시지는 크거나 무한할 수 있기 때문에, 엔드포인트는 메시지의 일부가 도착하여 진행에 충분할 때 부분 HTTP 메시지 처리를 시작하는 것이 권장됩니다(SHOULD). 클라이언트가 시작한 스트림이 HTTP 메시지를 완전하게 제공할 만큼 종료되지 않은 상태로 종료되면, 서버는 응답 스트림을 오류 코드 H3_REQUEST_INCOMPLETE로 중단(abort)하는 것이 권장됩니다(SHOULD).

서버는 요청의 아직 전송되지 않은 부분에 의존하지 않는 경우, 클라이언트가 전체 요청을 보내기 전에 완전한 응답을 보낼 수 있습니다. 서버가 나머지 요청을 받을 필요가 없을 때에는, 요청 스트림의 읽기를 중단(abort)하고(request stream), 완전한 응답을 전송하고 전송 측 스트림을 정상적으로 닫을 수 있습니다. 이때 클라이언트에게 전송 중지를 요청할 때에는 오류 코드 H3_NO_ERROR를 사용하는 것이 권장됩니다(SHOULD). 클라이언트는 요청이 갑작스럽게 중단되었다고 해서 완전한 응답을 폐기해서는 안 되며(MUST NOT), 다른 이유로 언제든 응답을 폐기할 수는 있습니다. 서버가 부분적 또는 완전한 응답을 전송했지만 요청 읽기를 중단하지 않은 경우, 클라이언트는 요청의 콘텐츠 전송을 계속하고 스트림을 정상적으로 닫아야 합니다(SHOULD).

4.1.1. 요청 취소 및 거부

한번 request stream이 열리면, 해당 요청은 어느 엔드포인트에 의해서든 취소될 수 있습니다(MAY). 클라이언트는 응답이 더 이상 필요하지 않을 때 요청을 취소하고, 서버는 응답할 수 없거나 응답하지 않기로 결정할 때 요청을 취소합니다. 가능하면 서버는 요청을 이미 처리하기 시작한 경우에도 요청을 취소하는 대신 적절한 상태 코드를 가진 HTTP 응답을 보내는 것이 권장됩니다(RECOMMENDED).

구현체는 스트림의 아직 열린 방향을 갑작스럽게 종료함으로써 요청을 취소해야 합니다(SHOULD). 이를 위해 구현체는 스트림의 전송 부분을 리셋하고 수신 부분에서는 읽기를 중단해야 합니다; 관련 내용은 RFC 9000 섹션 2.4를 참조하십시오.

서버가 어떤 애플리케이션 처리도 수행하지 않고 요청을 취소할 때, 그 요청은 "rejected"로 간주됩니다. 서버는 응답 스트림을 오류 코드 H3_REQUEST_REJECTED로 중단(abort)해야 합니다(SHOULD). 여기서 "processed"는 스트림의 일부 데이터가 상위 소프트웨어 계층으로 전달되어 그로 인해 어떤 동작이 발생했을 가능성이 있는 상태를 의미합니다. 클라이언트는 서버가 거부한 요청을 마치 전혀 전송되지 않았던 것처럼 취급하여 나중에 재시도할 수 있습니다.

서버는 부분적 또는 전부 처리된 요청에 대해 H3_REQUEST_REJECTED 오류 코드를 사용해서는 안 됩니다(MUST NOT). 서버가 부분 처리 후 응답을 포기하는 경우에는 응답 스트림을 오류 코드 H3_REQUEST_CANCELLED로 중단하는 것이 권장됩니다(SHOULD).

클라이언트는 요청을 취소할 때 오류 코드 H3_REQUEST_CANCELLED을 사용하는 것이 권장됩니다(SHOULD). 이 오류 코드를 수신하면 서버는 어떤 처리도 수행되지 않았다면 응답을 H3_REQUEST_REJECTED로 갑작스럽게 종료할 수 있습니다(MAY). 클라이언트는 서버가 요청 스트림의 종료를 이 오류 코드로 요청하지 않는 한 H3_REQUEST_REJECTED 오류 코드를 사용해서는 안 됩니다(MUST NOT).

스트림이 완전한 응답을 받은 후 취소되면, 클라이언트는 취소를 무시하고 응답을 사용할 수 있습니다(MAY). 그러나 스트림이 부분 응답을 받은 후 취소되면 해당 응답은 사용되어서는 안 됩니다(SHOULD NOT). GET, PUT, DELETE와 같은 멱등(idempotent) 동작만 안전하게 재시도될 수 있습니다; 클라이언트는 요청 메서드와 무관하게 요청 의미가 멱등임을 독립적으로 알거나 원래 요청이 결코 적용되지 않았음을 감지할 수 있는 수단이 없는 한 비멱등 요청을 자동으로 재시도해서는 안 됩니다(SHOULD NOT). 자세한 내용은 RFC 9110 섹션 9.2.2를 참조하십시오.

4.1.2. 형식이 잘못된 요청 및 응답

형식이 잘못된 요청 또는 응답이란, 프레임 시퀀스 자체는 유효하지만 다음과 같은 이유로 무효인 경우를 말합니다:

금지된 필드 또는 의사-헤더 필드의 존재,
필수 의사-헤더 필드의 부재,
의사-헤더 필드의 잘못된 값,
필드 뒤에 오는 의사-헤더 필드,
잘못된 HTTP 메시지 순서,
대문자 필드 이름 포함, 또는
필드 이름 또는 값에 잘못된 문자 포함.

Content-Length 헤더 필드가 있는 경우(자세한 내용은 RFC 9110 섹션 8.6) 콘텐츠를 가진 것으로 정의된 요청 또는 응답은, 수신된 DATA 프레임 길이의 합이 Content-Length 헤더 값과 같지 않으면 형식이 잘못된 것으로 간주됩니다. 콘텐츠를 결코 가지지 않는 것으로 정의된 응답은 Content-Length가 존재하더라도 DATA 프레임에 콘텐츠가 포함되지 않는 한 비제로 Content-Length 값을 가질 수 있습니다.

HTTP 요청 또는 응답을 처리하는 중개자(터널로 동작하지 않는 모든 중개자)는 형식이 잘못된 요청 또는 응답을 전달해서는 안 됩니다(MUST NOT). 감지된 형식이 잘못된 요청 또는 응답은 스트림 오류(stream error) 유형 H3_MESSAGE_ERROR로 처리되어야 합니다(MUST).

형식이 잘못된 요청의 경우, 서버는 스트림을 닫거나 리셋하기 전에 오류를 나타내는 HTTP 응답을 보낼 수 있습니다(MAY). 클라이언트는 형식이 잘못된 응답을 수락해서는 안 됩니다(MUST NOT). 이러한 요구사항은 HTTP에 대한 여러 일반적인 공격 유형으로부터 보호하기 위한 것이며, 관대하게 처리하면 구현체가 취약해질 수 있으므로 의도적으로 엄격하게 설계되었습니다.

4.2. HTTP 필드

HTTP 메시지는 "HTTP 필드"라고 불리는 일련의 키-값 쌍으로 메타데이터를 전달합니다; 섹션 6.3 및 섹션 6.5를 [HTTP]에서 참조하십시오. 등록된 HTTP 필드의 목록은 <https://www.iana.org/assignments/http-fields/>에 보관된 "Hypertext Transfer Protocol (HTTP) Field Name Registry"를 참조하십시오. HTTP/2와 마찬가지로, HTTP/3에서는 필드 이름에 사용되는 문자, Connection 헤더 필드 및 의사-헤더(pseudo-header) 필드의 사용과 관련된 추가적인 고려사항이 있습니다.

필드 이름은 ASCII 문자 하위 집합을 포함하는 문자열입니다. HTTP 필드 이름과 값의 속성은 RFC 9110 섹션 5.1에 더 자세히 설명되어 있습니다. 필드 이름의 문자는 인코딩하기 전에 소문자로 변환되어야 합니다(MUST). 필드 이름에 대문자가 포함된 요청 또는 응답은 malformed로 취급되어야 합니다(MUST).

HTTP/3는 Connection 헤더 필드를 사용하여 연결-특정 필드를 나타내지 않습니다; 이 프로토콜에서는 연결-특정 메타데이터가 다른 수단으로 전달됩니다. 엔드포인트는 연결-특정 필드를 포함하는 HTTP/3 필드 섹션을 생성해서는 안 됩니다(MUST NOT); 연결-특정 필드를 포함하는 모든 메시지는 malformed로 취급되어야 합니다(MUST).

예외는 TE 헤더 필드뿐이며, 이는 HTTP/3 요청 헤더에 포함될 수 있습니다(MAY). 이 필드가 있을 경우 "trailers" 이외의 값을 포함해서는 안 됩니다(MUST NOT).

HTTP/1.x 메시지를 HTTP/3로 변환하는 중개자는 RFC 9110 섹션 7.6.1에서 논의된 대로 연결-특정 헤더 필드를 제거해야 합니다(MUST); 그렇지 않으면 다른 HTTP/3 엔드포인트에 의해 그들의 메시지는 malformed로 처리될 것입니다.

4.2.1. 필드 압축

[QPACK]은 HPACK의 변형을 설명하며, 이는 인코더가 압축으로 인해 발생할 수 있는 head-of-line blocking의 정도를 어느 정도 제어할 수 있게 합니다. 이는 인코더가 압축 효율성과 지연 시간 간의 균형을 맞출 수 있게 해줍니다. HTTP/3는 헤더 및 트레일러 섹션(헤더 섹션에 있는 제어 데이터 포함)을 압축하기 위해 QPACK을 사용합니다.

더 나은 압축 효율을 허용하기 위해 Cookie 헤더 필드([COOKIES])는 압축 전에 하나 이상의 cookie-pair를 포함하는 별도의 필드 라인들로 분할될 수 있습니다(MAY). 압축 해제된 필드 섹션이 여러 개의 cookie 필드 라인을 포함하는 경우, 이들은 HTTP/2 또는 HTTP/3 이외의 컨텍스트(예: HTTP/1.1 연결 또는 일반 HTTP 서버 애플리케이션)에 전달되기 전에 "; "(ASCII 0x3b, 0x20)의 2바이트 구분자를 사용하여 단일 바이트 문자열로 연결되어야 합니다(MUST).

4.2.2. 헤더 크기 제약

HTTP/3 구현체는 개별 HTTP 메시지에서 수용할 최대 헤더 크기에 대한 제한을 둘 수 있습니다(MAY). 서버가 처리하기에 너무 큰 헤더 섹션을 수신하면 HTTP 431 (Request Header Fields Too Large) 상태 코드를 보낼 수 있습니다([RFC6585]). 클라이언트는 처리할 수 없는 응답을 폐기할 수 있습니다. 필드 목록의 크기는 이름과 값의 바이트 길이 및 각 필드에 대해 32바이트의 오버헤드를 포함한 비압축된 필드 크기를 기준으로 계산됩니다.

구현체가 피어에게 이 제한을 알리고자 하는 경우, 이는 SETTINGS_MAX_FIELD_SECTION_SIZE 매개변수에 바이트 수로 전달할 수 있습니다. 이 매개변수를 수신한 구현체는 표시된 크기를 초과하는 HTTP 메시지 헤더를 전송해서는 안 됩니다(SHOULD NOT), 피어가 이를 처리하지 않을 가능성이 높기 때문입니다. 그러나 HTTP 메시지는 오리진 서버에 도달하기 전에 하나 이상의 중개자를 통과할 수 있습니다; 자세한 내용은 RFC 9110 섹션 3.7을 참조하십시오. 이 제한은 메시지를 처리하는 각 구현체에 의해 별도로 적용되므로, 이 제한보다 작은 메시지라도 수락된다고 보장되지 않습니다.

4.3. HTTP 제어 데이터

HTTP/2와 마찬가지로, HTTP/3는 필드 이름이 : 문자(ASCII 0x3a)로 시작하는 일련의 의사-헤더(pseudo-header) 필드를 사용합니다. 이러한 의사-헤더 필드는 메시지 제어 데이터를 전달합니다; 자세한 내용은 RFC 9110 섹션 6.2를 참조하십시오.

의사-헤더 필드는 HTTP 필드가 아닙니다. 엔드포인트는 이 문서에 정의된 것 이외의 의사-헤더 필드를 생성해서는 안 됩니다(MUST NOT). 그러나 확장으로 이 제한의 수정이 협상될 수 있습니다; 자세한 내용은 섹션 9를 참조하십시오.

의사-헤더 필드는 정의된 문맥에서만 유효합니다. 요청에 대해 정의된 의사-헤더 필드는 응답에 나타나면 안 되며(MUST NOT), 응답에 대해 정의된 의사-헤더 필드는 요청에 나타나면 안 됩니다(MUST NOT). 의사-헤더 필드는 트레일러 섹션에 나타나면 안 됩니다(MUST NOT). 엔드포인트는 정의되지 않았거나 잘못된 의사-헤더 필드를 포함하는 요청 또는 응답을 malformed로 처리해야 합니다(MUST).

모든 의사-헤더 필드는 일반 헤더 필드보다 먼저 헤더 섹션에 나타나야 합니다(MUST). 일반 헤더 필드 이후에 나타나는 의사-헤더 필드를 포함하는 요청 또는 응답은 malformed로 처리되어야 합니다(MUST).

4.3.1. 요청 의사-헤더 필드

요청에 대해 다음 의사-헤더 필드들이 정의됩니다:

":method":: HTTP 메서드를 포함합니다(RFC 9110 섹션 9 참조).
":scheme":: 대상 URI의 스킴 부분을 포함합니다(RFC 3986 섹션 3.1 참조).
: :scheme 의사-헤더는 "http"와 "https"로 제한되지 않습니다. 프록시나 게이트웨이는 비-HTTP 스킴에 대한 요청을 번역하여 HTTP를 사용해 비-HTTP 서비스와 상호작용할 수 있게 합니다.
: "https" 이외의 스킴 사용에 관한 지침은 섹션 3.1.2를 참조하십시오.
":authority":: 대상 URI의 authority 부분을 포함합니다(RFC 3986 섹션 3.2 참조). "http" 또는 "https" 스킴을 가진 URI의 경우, 이 authority는 더 이상 사용되지 않는 userinfo 하위 구성요소를 포함해서는 안 됩니다(MUST NOT).
: HTTP/1.1 요청 줄을 정확히 재현하기 위해, 이 의사-헤더 필드는 메서드별 형식의 요청-타깃을 가진 HTTP/1.1 요청을 번역할 때 생략되어야 합니다(MUST); 자세한 내용은 RFC 9110 섹션 7.1을 참조하십시오. HTTP/3 요청을 직접 생성하는 클라이언트는 Host 헤더 필드 대신 :authority 의사-헤더 필드를 사용하는 것이 권장됩니다(SHOULD). HTTP/3 요청을 HTTP/1.1으로 변환하는 중개자는 요청에 Host 필드가 없으면 :authority 의사-헤더 값을 복사하여 Host 필드를 생성해야 합니다(MUST).
":path":: 대상 URI의 경로 및 쿼리 부분을 포함합니다("path-absolute" 생성물과 선택적으로 ?(ASCII 0x3f) 뒤의 "query" 생성물; RFC 3986의 섹션 3.3 및 3.4 참조).
: "http" 또는 "https" URI의 경우 이 의사-헤더 필드는 비어 있을 수 없으며, 경로 구성요소가 없는 "http" 또는 "https" URI는 /(ASCII 0x2f)를 포함해야 합니다(MUST). 경로 구성요소가 없는 OPTIONS 요청은 :path 의사-헤더에 *(ASCII 0x2a)를 포함합니다.

모든 HTTP/3 요청은 :method, :scheme, :path 의사-헤더 필드를 정확히 하나씩 포함해야 합니다(MUST), CONNECT 요청의 경우는 예외입니다; 섹션 4.4를 참조하십시오.

:scheme 의사-헤더가 권한(authority) 구성요소를 필수로 가지는 스킴(예: "http", "https")을 식별하는 경우, 요청은 :authority 의사-헤더 필드 또는 Host 헤더 필드 중 하나를 포함해야 합니다(MUST) . 이러한 필드가 존재할 경우 비어 있어서는 안 되며(MUST NOT), 두 필드가 모두 존재한다면 동일한 값을 가져야 합니다(MUST). 스킴이 권한 구성요소를 필수로 갖지 않으며 요청 타깃에 제공되지 않은 경우, 요청은 :authority 의사-헤더 또는 Host 헤더를 포함해서는 안 됩니다(MUST NOT).

필수 의사-헤더 필드를 생략하거나 해당 의사-헤더 필드에 잘못된 값을 포함하는 HTTP 요청은 malformed입니다.

HTTP/3는 HTTP/1.1 요청 줄에 포함된 버전 식별자를 전달하는 방법을 정의하지 않습니다. HTTP/3 요청은 묵시적으로 "3.0" 프로토콜 버전을 가집니다.

4.3.2. 응답 의사-헤더 필드

응답에 대해서는 HTTP 상태 코드를 전달하는 단일 ":status" 의사-헤더 필드가 정의됩니다; 자세한 내용은 RFC 9110 섹션 15를 참조하십시오. 이 의사-헤더 필드는 모든 응답에 포함되어야 합니다(MUST); 그렇지 않으면 응답은 malformed입니다.

HTTP/3는 HTTP/1.1 상태 줄에 포함된 버전이나 이유 구문(reason phrase)을 전달하는 방법을 정의하지 않습니다. HTTP/3 응답은 묵시적으로 "3.0" 프로토콜 버전을 가집니다.

4.4. CONNECT 메서드

CONNECT 메서드는 수신자가 요청-타깃으로 식별된 대상 오리진 서버에 대해 터널을 설정하도록 요청합니다; 자세한 내용은 RFC 9110 섹션 9.3.6를 참조하십시오. 주로 HTTP 프록시와 함께 사용되어 오리진 서버와 TLS 세션을 설정하고 "https" 리소스와 상호작용하는 데 사용됩니다.

HTTP/1.x에서는 CONNECT가 전체 HTTP 연결을 원격 호스트로의 터널로 변환하는 데 사용됩니다. HTTP/2 및 HTTP/3에서는 CONNECT 메서드가 단일 스트림을 통해 터널을 설정하는 데 사용됩니다.

CONNECT 요청은 다음과 같이 구성되어야 합니다(MUST):

:method 의사-헤더 필드는 "CONNECT"로 설정된다
:scheme 및 :path 의사-헤더 필드는 생략된다
:authority 의사-헤더 필드는 연결할 호스트와 포트를 포함한다(이는 CONNECT 요청의 authority-form 요청-타깃에 해당).

request stream은 전송이 종료된 후에도 전송될 데이터를 담기 위해 요청의 끝에서 열려 있습니다. 이 규칙을 준수하지 않는 CONNECT 요청은 malformed입니다.

CONNECT를 지원하는 프록시는 :authority 의사-헤더 필드에 식별된 서버에 TCP 연결을 설정합니다([RFC0793]). 이 연결이 성공적으로 설정되면, 프록시는 클라이언트에게 2xx 계열 상태 코드를 포함한 HEADERS 프레임을 전송합니다(자세한 내용은 RFC 9110 섹션 15.3).

스트림의 모든 DATA 프레임은 TCP 연결에서 전송되거나 수신된 데이터에 해당합니다. 클라이언트가 전송한 DATA 프레임의 페이로드는 프록시가 TCP 서버로 전송하고, TCP 서버로부터 수신된 데이터는 프록시가 DATA 프레임으로 클라이언트에게 패키징하여 전송합니다. TCP 세그먼트의 크기 및 수가 HTTP DATA 또는 QUIC STREAM 프레임의 크기 및 수와 예측 가능하게 매핑된다고 보장되지 않음을 유의하십시오.

CONNECT 메서드가 완료되면 스트림에서 전송할 수 있는 것은 DATA 프레임뿐입니다. 확장 프레임은 확장 정의에서 명시적으로 허용되는 경우에만 사용할 수 있습니다(MAY). 다른 알려진 프레임 유형의 수신은 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST).

TCP 연결은 어느 피어에 의해서든 닫힐 수 있습니다. 클라이언트가 request stream을 종료하면(즉, 프록시에서 수신 스트림이 "Data Recvd" 상태에 들어감), 프록시는 TCP 서버에 대한 연결에서 FIN 비트를 설정합니다. 프록시가 FIN 비트가 설정된 패킷을 수신하면, 클라이언트에게 보내는 전송 스트림을 닫습니다. 단방향으로 반쪽 닫힌 TCP 연결은 무효는 아니지만 종종 서버에서 제대로 처리되지 않으므로, 클라이언트는 CONNECT 대상에서 데이터를 받을 것으로 예상되는 동안 전송을 위한 스트림을 닫아서는 안 됩니다(SHOULD NOT).

TCP connection error는 스트림을 갑작스럽게 종료함으로써 신호됩니다. 프록시는 RST 비트가 설정된 TCP 세그먼트를 수신하는 것을 포함한 TCP 연결의 모든 오류를 stream error 유형 H3_CONNECT_ERROR로 처리합니다.

마찬가지로, 프록시가 스트림 또는 QUIC 연결에서 오류를 감지하면 TCP 연결을 닫아야 합니다(MUST). 프록시가 클라이언트가 스트림을 리셋하거나 스트림에서 읽기를 중단한 것을 감지하면 TCP 연결을 닫아야 합니다(MUST). 스트림이 리셋되거나 읽기가 클라이언트에 의해 중단된 경우, 프록시는 스트림의 다른 방향에 대해서도 동일한 작업을 수행하여 양 방향 스트림이 취소되도록 하는 것이 권장됩니다(SHOULD). 모든 경우에, 기반 TCP 구현이 허용한다면 프록시는 RST 비트가 설정된 TCP 세그먼트를 보내는 것이 권장됩니다(SHOULD).

CONNECT는 임의의 서버로 터널을 생성하므로, CONNECT를 지원하는 프록시는 그 사용을 알려진 포트 집합이나 안전한 요청 대상 목록으로 제한하는 것이 권장됩니다(SHOULD); 자세한 내용은 RFC 9110 섹션 9.3.6을 참조하십시오.

4.5. HTTP 업그레이드

HTTP/3는 HTTP Upgrade 메커니즘(RFC 9110 섹션 7.8)이나 101 (Switching Protocols) 정보 상태 코드(RFC 9110 섹션 15.2.2)를 지원하지 않습니다.

4.6. 서버 푸시

서버 푸시는 서버가 클라이언트가 해당 요청을 할 것으로 예상하여 요청-응답 교환을 클라이언트로 푸시할 수 있게 하는 상호작용 모드입니다. 이는 잠재적 지연 개선을 위해 네트워크 사용을 거래(trade-off)하는 것입니다. HTTP/3의 서버 푸시는 RFC 9113 섹션 8.2에 설명된 내용과 유사하지만 다른 메커니즘을 사용합니다.

각 서버 푸시에는 서버가 할당하는 고유한 push ID가 있습니다. push ID는 HTTP/3 연결 수명 동안 다양한 문맥에서 푸시를 참조하는 데 사용됩니다.

push ID 공간은 0에서 시작하여 MAX_PUSH_ID 프레임으로 설정된 최대값으로 끝납니다. 특히, 클라이언트가 MAX_PUSH_ID 프레임을 전송한 이후에야 서버는 푸시를 할 수 있습니다. 클라이언트는 서버가 약속할 수 있는 푸시 수를 제어하기 위해 MAX_PUSH_ID 프레임을 전송합니다. 서버는 0부터 시작하여 순차적으로 push ID를 사용하는 것이 권장됩니다(SHOULD). 클라이언트는 push stream을 수신했을 때, 아직 MAX_PUSH_ID 프레임이 전송되지 않았거나 스트림이 최대 push ID보다 큰 push ID를 참조하면 이를 connection error 유형 H3_ID_ERROR로 처리해야 합니다(MUST).

push ID는 요청 메시지의 제어 데이터와 헤더 필드를 운반하는 하나 이상의 PUSH_PROMISE 프레임에서 사용됩니다. 이러한 프레임은 푸시를 생성한 request stream에서 전송됩니다. 이는 서버 푸시를 클라이언트 요청과 연결할 수 있게 합니다. 동일한 push ID가 여러 request streams에서 약속될 때, 압축 해제된 요청 필드 섹션은 동일한 순서로 동일한 필드를 포함해야 하며 각 필드의 이름과 값은 동일해야 합니다(MUST).

그 후 push ID는 해당 약속을 최종적으로 이행하는 push stream에 포함됩니다. 해당 push stream은 자신이 이행하는 약속의 push ID를 식별하고, 이후 섹션 4.1에 설명된 대로 약속된 요청에 대한 응답을 포함합니다.

마지막으로 push ID는 CANCEL_PUSH 프레임에서도 사용될 수 있습니다; 섹션 7.2.3 참조. 클라이언트는 이 프레임을 사용하여 약속된 리소스를 수신하고자 하지 않음을 표시하고, 서버는 이전 약속을 이행하지 않을 것임을 알리기 위해 이 프레임을 사용할 수 있습니다.

모든 요청을 푸시할 수 있는 것은 아닙니다. 서버는 다음 속성을 가진 요청을 푸시할 수 있습니다(MAY):

캐시 가능(cacheable); RFC 9110 섹션 9.2.3 참조
안전(safe); RFC 9110 섹션 9.2.1 참조
요청 콘텐츠나 트레일러 섹션을 포함하지 않음

서버는 자신이 권한을 가지는 :authority 의사-헤더 필드 값을 포함해야 합니다(MUST). 클라이언트가 아직 푸시된 요청으로 표시된 오리진에 대해 연결을 검증하지 않았다면, 클라이언트는 해당 오리진에 대해 요청을 전송하기 전에 수행할 것과 동일한 검증 절차를 수행해야 합니다(섹션 3.3 참조). 이 검증이 실패하면 클라이언트는 해당 오리진에 대해 서버를 권한 있는 것으로 간주해서는 안 됩니다(MUST NOT).

클라이언트는 캐시 불가하거나 안전성이 알려지지 않았거나 요청 콘텐츠가 있음을 나타내는, 또는 서버를 해당 오리진에 대해 권한 있는 것으로 여기지 않는 요청을 전달하는 PUSH_PROMISE 프레임을 수신하면 CANCEL_PUSH 프레임을 보내는 것이 권장됩니다(SHOULD). 해당하는 응답은 사용되거나 캐시되어서는 안 됩니다(MUST NOT).

각 푸시된 응답은 하나 이상의 클라이언트 요청과 연관됩니다. 푸시는 해당 request stream에서 PUSH_PROMISE 프레임이 수신된 요청과 연관됩니다. 동일한 서버 푸시는 동일한 push ID를 가진 PUSH_PROMISE 프레임을 여러 request streams에서 사용하여 추가 클라이언트 요청과 연관될 수 있습니다. 이러한 연관은 프로토콜의 동작에 영향을 주지 않지만, 사용자 에이전트가 푸시된 리소스를 어떻게 사용할지 결정할 때 고려할 수 있습니다(MAY).

PUSH_PROMISE 프레임의 응답 내 특정 부분과의 순서 지정은 중요합니다. 서버는 약속된 응답을 참조하는 HEADERS 또는 DATA 프레임을 보내기 전에 PUSH_PROMISE 프레임을 보내는 것이 권장됩니다(SHOULD). 이는 클라이언트가 서버가 푸시할 리소스를 요청할 가능성을 줄입니다.

재정렬로 인해 push stream 데이터가 관련 PUSH_PROMISE 프레임보다 먼저 도착할 수 있습니다. 클라이언트가 아직 알려지지 않은 push ID를 가진 새 push stream을 수신하면, 관련 클라이언트 요청과 푸시된 요청 헤더 필드는 알 수 없습니다. 클라이언트는 일치하는 PUSH_PROMISE 프레임을 기대하며 스트림 데이터를 버퍼링할 수 있습니다. 클라이언트는 스트림 흐름 제어(RFC 9000 섹션 4.1)를 사용하여 서버가 푸시 스트림에 커밋할 수 있는 데이터 양을 제한할 수 있습니다. 클라이언트는 합리적인 시간 내에 대응하는 PUSH_PROMISE 프레임이 처리되지 않으면 push streams에서의 읽기를 중단하고 이미 읽은 데이터를 폐기하는 것이 권장됩니다(SHOULD).

클라이언트가 푸시를 취소한 이후에 push stream 데이터가 도착할 수도 있습니다. 이 경우 클라이언트는 오류 코드 H3_REQUEST_CANCELLED로 스트림 읽기를 중단(abort)할 수 있습니다. 이는 서버에게 추가 데이터를 전송하지 말 것을 요청하며 수신 시 해당 데이터가 폐기될 것임을 나타냅니다.

캐시 가능(자세한 내용은 RFC 9111 섹션 3)한 푸시된 응답은 클라이언트가 HTTP 캐시를 구현한 경우 클라이언트에 의해 저장될 수 있습니다. 푸시된 응답은 수신 시점에 오리진 서버에서 성공적으로 검증된 것으로 간주됩니다(예: "no-cache" 캐시 응답 지시자가 있는 경우; RFC 9111 섹션 5.2.2.4 참조).

캐시 불가한 푸시된 응답은 어떤 HTTP 캐시에 의해서도 저장되어서는 안 됩니다(MUST NOT). 그러나 애플리케이션에 별도로 제공될 수는 있습니다(MAY).

5. 연결 종료

일단 수립되면, HTTP/3 연결은 연결이 닫힐 때까지 여러 요청과 응답을 오랜 기간에 걸쳐 처리하는 데 사용할 수 있습니다. 연결 종료는 여러 가지 다른 방식으로 발생할 수 있습니다.

5.1. 유휴 연결

각 QUIC 엔드포인트는 핸드셰이크 동안 유휴 타임아웃을 선언합니다. QUIC 연결이 이 기간보다 오래 유휴 상태(패킷 수신 없음)로 유지되면, 피어는 해당 연결이 닫힌 것으로 간주합니다. HTTP/3 구현체는 기존 연결이 QUIC 핸드셰이크 동안 협상된 유휴 타임아웃보다 오래 유휴 상태였을 경우 새 요청을 처리하기 위해 새로운 HTTP/3 연결을 열어야 하며, 유휴 타임아웃에 접근하고 있을 경우에는 그렇게 해야 합니다(SHOULD); 관련 내용은 QUIC-TRANSPORT의 섹션 10.1을 참조하십시오.

HTTP 클라이언트는 요청에 대한 응답이나 서버 푸시가 남아 있는 동안 전송이 연결을 유지하도록 요청하는 것이 예상됩니다(자세한 내용은 QUIC-TRANSPORT 섹션 10.1.2 참조). 클라이언트가 서버로부터 응답을 기대하지 않을 때는 필요하지 않을 수 있는 연결을 유지하려고 노력하기보다는 유휴 연결이 타임아웃되게 놔두는 것이 바람직합니다. 게이트웨이는 서버에 대한 연결 설정 지연을 피하기 위해 필요를 예상하여 연결을 유지할 수 있습니다(MAY). 서버는 적극적으로 연결을 유지해서는 안 됩니다(SHOULD NOT).

5.2. 연결 셧다운

연결이 유휴 상태가 아닐 때에도, 어느 한쪽 엔드포인트는 연결 사용을 중단하고 정상적인 연결 종료를 시작하기로 결정할 수 있습니다. 엔드포인트는 GOAWAY 프레임을 전송하여 HTTP/3 연결의 정상 종료를 시작합니다. GOAWAY 프레임에는 수신자에게 이 연결에서 처리되었거나 처리되었을 수 있는 요청 또는 푸시의 범위를 나타내는 식별자가 포함됩니다. 서버는 클라이언트가 시작한 양방향 스트림 ID를, 클라이언트는 push ID를 보냅니다. 표시된 식별자 이상인 요청이나 푸시는 GOAWAY를 보낸 측에서 거부됩니다(섹션 4.1.1 참조). 처리된 요청이나 푸시가 없다면 이 식별자는 0일 수 있습니다(MAY).

GOAWAY 프레임에 포함된 정보는 클라이언트와 서버가 HTTP/3 연결 종료 이전에 어떤 요청이나 푸시가 수락되었는지 합의하는 데 도움을 줍니다. GOAWAY 프레임을 전송한 후, 해당 엔드포인트는 영향을 받는 스트림의 전송 상태를 정리하기 위해 표시된 식별자보다 크거나 같은 식별자를 가진 모든 요청이나 푸시를 명시적으로 취소(섹션 4.1.1 및 섹션 7.2.3 참조)해야 합니다(SHOULD). 더 많은 요청이나 푸시가 도착하는 동안에도 이를 계속 수행해야 합니다(SHOULD).

엔드포인트는 피어로부터 GOAWAY 프레임을 수신한 후에는 해당 연결에서 새로운 요청을 시작하거나 새로운 푸시를 약속해서는 안 됩니다(MUST NOT). 클라이언트는 추가 요청을 보내기 위해 새 연결을 수립할 수 있습니다(MAY).

일부 요청이나 푸시는 이미 전송 중일 수 있습니다:

GOAWAY 프레임을 수신했을 때, 클라이언트가 이미 GOAWAY 프레임에 포함된 식별자보다 크거나 같은 스트림 ID로 요청을 보냈다면, 해당 요청은 처리되지 않습니다. 클라이언트는 처리되지 않은 요청을 다른 HTTP 연결에서 안전하게 재시도할 수 있습니다. 클라이언트가 요청을 재시도할 수 없는 경우 서버가 연결을 닫을 때 진행 중인 모든 요청을 잃게 됩니다.

GOAWAY 프레임에 있는 스트림 ID보다 작은 스트림 ID의 요청들은 처리되었을 수도 있습니다; 해당 요청에 대한 상태는 응답이 수신되거나 해당 스트림이 개별적으로 리셋되거나 더 낮은 스트림 ID를 포함하는 다른 GOAWAY가 수신되거나 연결이 종료될 때까지 알 수 없습니다.

서버는 처리되지 않은 경우 표시된 ID보다 낮은 스트림의 개별 요청을 거부할 수 있습니다(MAY).
서버가 GOAWAY 프레임을 받은 이후에 push ID가 해당 GOAWAY 프레임에 포함된 식별자보다 크거나 같은 푸시를 약속했다면, 그 푸시는 수락되지 않을 것입니다.

서버는 연결 종료가 사전에 알려진 경우, 설령 사전 통지가 짧더라도 원격 피어가 요청이 부분적으로 처리되었는지 여부를 알 수 있도록 GOAWAY 프레임을 보내는 것이 권장됩니다(SHOULD). 예를 들어, HTTP 클라이언트가 POST를 전송하는 동시에 서버가 QUIC 연결을 닫는 경우, 서버가 어떤 스트림에서 동작했는지 표시하는 GOAWAY 프레임을 보내지 않으면 클라이언트는 서버가 해당 POST 요청 처리를 시작했는지 알 수 없습니다.

엔드포인트는 서로 다른 식별자를 나타내는 여러 개의 GOAWAY 프레임을 보낼 수 있지만, 각 프레임의 식별자는 이전 프레임의 식별자보다 클 수 없습니다(MUST NOT), 왜냐하면 클라이언트는 이미 처리되지 않은 요청을 다른 HTTP 연결에서 재시도했을 수 있기 때문입니다. 이전에 수신한 것보다 더 큰 식별자를 포함한 GOAWAY를 수신하는 경우, 이것은 connection error 유형 H3_ID_ERROR로 처리되어야 합니다(MUST).

연결을 정상적으로 종료하려는 엔드포인트는 최대 가능한 값(서버의 경우 2⁶²-4, 클라이언트의 경우 2⁶²-1)으로 설정된 GOAWAY 프레임을 보낼 수 있습니다. 이는 피어가 새 요청이나 푸시 생성을 중단하도록 보장합니다. 진행 중인 요청이나 푸시가 도착할 시간을 허용한 후, 엔드포인트는 연결 종료 전에 수락할 수 있는 요청이나 푸시를 나타내는 또 다른 GOAWAY 프레임을 보낼 수 있습니다. 이를 통해 요청을 잃지 않고 연결을 깔끔하게 종료할 수 있습니다.

클라이언트는 자신이 전송하는 GOAWAY의 Push ID 필드 값에 대해 더 많은 유연성을 가집니다. 값 2⁶²-1은 서버가 이미 약속한 푸시를 계속 이행할 수 있음을 나타냅니다. 더 작은 값은 클라이언트가 이 값보다 크거나 같은 push ID를 가진 푸시를 거부할 것임을 나타냅니다. 서버와 마찬가지로, 클라이언트는 지정된 push ID가 이전에 전송한 값보다 크지 않은 한 후속 GOAWAY 프레임을 보낼 수 있습니다(MAY).

GOAWAY가 주어진 요청이나 푸시가 처리되거나 수락되지 않을 것임을 나타내더라도, 기본 전송 리소스는 여전히 존재합니다. 이러한 요청을 시작한 엔드포인트는 전송 상태를 정리하기 위해 이를 취소할 수 있습니다.

수락된 모든 요청과 푸시가 처리되면, 엔드포인트는 연결을 유휴 상태가 되도록 허용하거나 즉시 연결을 종료할 수 있습니다(MAY). 정상적인 셧다운을 완료한 엔드포인트는 연결을 닫을 때 H3_NO_ERROR 오류 코드를 사용하는 것이 권장됩니다(SHOULD).

클라이언트가 요청으로 사용 가능한 모든 양방향 스트림 ID를 소비한 경우, 서버는 클라이언트가 더 이상 요청을 할 수 없으므로 GOAWAY 프레임을 보낼 필요가 없습니다.

5.3. 즉시 애플리케이션 종료

HTTP/3 구현체는 언제든지 QUIC 연결을 즉시 닫을 수 있습니다. 이는 애플리케이션 레이어가 연결을 종료했음을 나타내는 QUIC CONNECTION_CLOSE 프레임을 피어에게 전송하는 결과를 초래합니다. 이 프레임의 애플리케이션 오류 코드는 연결이 닫히는 이유를 피어에게 전달합니다. 연결을 닫을 때 사용할 수 있는 오류 코드는 섹션 8을 참조하십시오.

연결을 닫기 전에, 클라이언트가 일부 요청을 재시도할 수 있도록 GOAWAY 프레임을 전송할 수 있습니다(MAY). QUIC CONNECTION_CLOSE 프레임과 동일한 패킷에 GOAWAY 프레임을 포함하면 클라이언트가 프레임을 수신할 가능성이 높아집니다.

명시적으로 닫히지 않은 열린 스트림이 있는 경우, 연결이 닫힐 때 해당 스트림들은 암묵적으로 닫힙니다; 자세한 내용은 QUIC-TRANSPORT 섹션 10.2를 참조하십시오.

5.4. 전송 종료

여러 가지 이유로 QUIC 전송은 애플리케이션 레이어에 연결이 종료되었음을 알릴 수 있습니다. 이는 피어의 명시적 종료, 전송 계층 오류, 또는 연결성을 중단시키는 네트워크 토폴로지의 변화 때문일 수 있습니다.

연결이 GOAWAY 프레임 없이 종료되는 경우, 클라이언트는 전송된 모든 요청(전부 또는 일부)이 처리되었을 수 있음을 가정해야 합니다(MUST).

6. 스트림 매핑 및 사용

QUIC 스트림은 바이트에 대해 신뢰 가능한 순서 전달을 제공하지만, 다른 스트림의 바이트와 관련된 전달 순서에 대해서는 보장을 제공하지 않습니다. QUIC 버전 1에서는 HTTP 프레임을 포함하는 스트림 데이터가 QUIC STREAM 프레임에 의해 운반되지만, 이 프레이밍은 HTTP 프레이밍 계층에 대해서는 보이지 않습니다. 전송 계층은 수신된 스트림 데이터를 버퍼링하고 정렬하여 애플리케이션에 신뢰 가능한 바이트 스트림을 노출합니다. QUIC은 스트림 내에서 순서가 뒤바뀐 전달을 허용하지만, HTTP/3는 이 기능을 사용하지 않습니다.

QUIC 스트림은 발신자에서 수신자 쪽으로만 데이터를 운반하는 단방향일 수도 있고, 양방향으로 데이터를 운반하는 양방향일 수도 있습니다. 스트림은 클라이언트나 서버 중 어느 쪽에서든 시작할 수 있습니다. QUIC 스트림에 대한 자세한 내용은 QUIC-TRANSPORT 섹션 2을 참조하십시오.

HTTP 필드와 데이터가 QUIC을 통해 전송될 때, QUIC 레이어가 대부분의 스트림 관리를 처리합니다. QUIC을 사용할 때는 HTTP가 별도의 다중화 작업을 수행할 필요가 없습니다: QUIC 스트림을 통해 전송된 데이터는 항상 특정 HTTP 트랜잭션이나 전체 HTTP/3 연결 컨텍스트에 매핑됩니다.

6.1. 양방향 스트림

모든 클라이언트가 시작한 양방향 스트림은 HTTP 요청 및 응답에 사용됩니다. 양방향 스트림은 응답이 요청과 쉽게 연관될 수 있도록 보장합니다. 이러한 스트림을 요청 스트림이라고 합니다.

이는 클라이언트의 첫 번째 요청이 QUIC 스트림 0에서 발생하고, 이후 요청은 스트림 4, 8 등에서 발생함을 의미합니다. 이러한 스트림들이 열리도록 허용하기 위해 HTTP/3 서버는 허용된 스트림 수와 초기 스트림 흐름 제어 창에 대해 0이 아닌 최소값을 구성해야 합니다(SHOULD). 병렬성을 불필요하게 제한하지 않기 위해 한 번에 적어도 100개의 요청 스트림을 허용하는 것이 권장됩니다(SHOULD).

HTTP/3는 서버가 시작한 양방향 스트림을 사용하지 않지만, 확장이 이러한 스트림의 사용을 정의할 수 있습니다. 클라이언트는 서버가 시작한 양방향 스트림의 수신을 해당 확장이 협상되지 않은 한 connection error 유형 H3_STREAM_CREATION_ERROR로 처리해야 합니다(MUST).

6.2. 단방향 스트림

단방향 스트림(어느 방향이든)은 다양한 목적에 사용됩니다. 목적은 스트림 시작 부분에 변수 길이 정수로 전송되는 스트림 유형으로 표시됩니다. 이 정수 뒤에 따르는 데이터의 형식과 구조는 스트림 유형에 의해 결정됩니다.

Unidirectional Stream Header {
  Stream Type (i),
}

Figure 1: Unidirectional Stream Header

이 문서에서는 두 가지 스트림 유형을 정의합니다: 제어 스트림(섹션 6.2.1)과 푸시 스트림(섹션 6.2.2). [QPACK]는 두 가지 추가 스트림 유형을 정의합니다. 다른 스트림 유형은 HTTP/3 확장으로 정의될 수 있습니다; 자세한 내용은 섹션 9을 참조하십시오. 일부 스트림 유형은 예약되어 있습니다(섹션 6.2.3).

HTTP/3 연결의 초기 단계에서 단방향 스트림의 생성 및 데이터 교환은 성능에 민감합니다. 엔드포인트가 스트림 수나 이러한 스트림의 흐름 제어 창을 과도하게 제한하면 원격 피어가 조기에 제한에 도달하여 차단될 가능성이 커집니다. 특히 구현체는 원격 피어가 허용된 일부 단방향 스트림에서 예약된 스트림 동작(섹션 6.2.3)을 수행하려 할 수 있음을 고려해야 합니다.

각 엔드포인트는 HTTP 제어 스트림을 위해 최소 하나의 단방향 스트림을 생성해야 합니다. QPACK은 추가로 두 개의 단방향 스트림을 요구하며, 다른 확장도 더 많은 스트림을 요구할 수 있습니다. 따라서 클라이언트와 서버가 전송하는 전송 매개변수는 피어가 적어도 세 개의 단방향 스트림을 생성할 수 있도록 허용해야 합니다(MUST). 또한 이러한 전송 매개변수는 각 단방향 스트림에 대해 적어도 1,024 바이트의 흐름 제어 크레딧을 제공하는 것이 권장됩니다(SHOULD).

피어가 중요한 단방향 스트림을 생성하기 전에 초기 크레딧을 모두 소비하면, 엔드포인트가 추가 단방향 스트림을 생성하는 데 필요한 추가 크레딧을 부여할 필요는 없다는 점에 유의하십시오. 엔드포인트는 HTTP 제어 스트림 및 필수 확장(예: QPACK 인코더 및 디코더 스트림)에 의해 요구되는 단방향 스트림을 먼저 생성한 후 피어가 허용하는 범위 내에서 추가 스트림을 생성하는 것이 바람직합니다(SHOULD).

스트림 헤더가 수신자에서 지원되지 않는 스트림 유형을 나타내면, 해당 스트림의 나머지 부분은 의미를 알 수 없기 때문에 소비될 수 없습니다. 미지의 스트림 유형 수신자는 스트림 읽기를 중단하거나 수신된 데이터를 추가 처리 없이 폐기해야 합니다(MUST). 읽기가 중단되는 경우 수신자는 H3_STREAM_CREATION_ERROR 오류 코드 또는 예약된 오류 코드를 사용하는 것이 권장됩니다(SHOULD). 수신자는 미지의 스트림 유형을 어떠한 종류의 connection error로 간주해서는 안 됩니다(MUST NOT).

특정 스트림 유형이 연결 상태에 영향을 줄 수 있으므로, 수신자는 스트림 유형을 읽기 전에 들어오는 단방향 스트림의 데이터를 폐기하지 않는 것이 바람직합니다(SHOULD NOT).

구현체는 피어가 해당 스트림 유형을 지원하는지 알기 전에 스트림 유형을 보낼 수 있습니다(MAY). 그러나 QPACK이나 다른 확장을 포함하여 기존 프로토콜 구성요소의 상태나 의미를 변경할 수 있는 스트림 유형은 피어가 이를 지원하는 것으로 확인될 때까지 전송해서는 안 됩니다(MUST NOT).

송신자는 별도의 명시가 없는 한 단방향 스트림을 닫거나 리셋할 수 있습니다. 수신자는 단방향 스트림 헤더를 수신하기 전에 단방향 스트림이 닫히거나 리셋되는 것을 허용해야 합니다(MUST).

6.2.1. 제어 스트림

제어 스트림은 스트림 유형 0x00으로 표시됩니다. 이 스트림의 데이터는 섹션 7.2에 정의된 대로 HTTP/3 프레임으로 구성됩니다.

각 측은 연결 시작 시 단일 제어 스트림을 시작하고 해당 스트림의 첫 번째 프레임으로 자신의 SETTINGS 프레임을 전송해야 합니다(MUST). 제어 스트림의 첫 번째 프레임이 다른 프레임 유형이면 이는 connection error 유형 H3_MISSING_SETTINGS로 처리되어야 합니다(MUST). 피어당 하나의 제어 스트림만 허용되며; 제어 스트림을 주장하는 두 번째 스트림을 수신하면 이는 connection error 유형 H3_STREAM_CREATION_ERROR로 처리되어야 합니다(MUST). 전송자는 제어 스트림을 닫아서는 안 되며(MUST NOT), 수신자는 전송자에게 제어 스트림을 닫도록 요청해서는 안 됩니다(MUST NOT). 어느 쪽 제어 스트림이든 닫히면 이는 connection error 유형 H3_CLOSED_CRITICAL_STREAM로 처리되어야 합니다(MUST). 연결 오류는 섹션 8에 설명되어 있습니다.

제어 스트림의 내용은 다른 스트림의 동작을 관리하는 데 사용되므로, 엔드포인트는 피어의 제어 스트림이 차단되지 않도록 충분한 흐름 제어 크레딧을 제공하는 것이 바람직합니다(SHOULD).

단일 양방향 스트림 대신 단방향 스트림 쌍이 사용됩니다. 이는 어느 쪽 피어든 가능한 한 빨리 데이터를 보낼 수 있게 합니다. QUIC 연결에서 0-RTT 사용 가능 여부에 따라 클라이언트 또는 서버가 먼저 스트림 데이터를 보낼 수 있습니다.

6.2.2. 푸시 스트림

서버 푸시는 서버가 요청이 이루어지기 전에 응답을 시작할 수 있게 하는 HTTP/2에서 도입된 선택적 기능입니다. 자세한 내용은 섹션 4.6을 참조하십시오.

푸시 스트림은 스트림 유형 0x01로 표시되며, 이어서 약속을 이행하는 push ID가 변수 길이 정수로 인코딩되어 옵니다. 이 스트림의 나머지 데이터는 섹션 7.2에 정의된 대로 HTTP/3 프레임으로 구성되며, 0개 이상의 중간 HTTP 응답과 단일 최종 HTTP 응답으로 약속된 서버 푸시를 이행합니다(섹션 4.1 참조). 서버 푸시와 push ID에 관한 설명은 섹션 4.6을 참조하십시오.

푸시는 서버만 수행할 수 있습니다; 서버가 클라이언트가 시작한 푸시 스트림을 수신하면 이는 connection error 유형 H3_STREAM_CREATION_ERROR로 처리되어야 합니다(MUST).

Push Stream Header {
  Stream Type (i) = 0x01,
  Push ID (i),
}

Figure 2: Push Stream Header

클라이언트는 푸시 스트림 헤더를 읽기 전에 해당 스트림에서의 읽기를 중단해서는 안 됩니다(SHOULD NOT), 이는 클라이언트와 서버 간에 어떤 push ID가 이미 소비되었는지에 대한 불일치를 초래할 수 있기 때문입니다.

각 push ID는 푸시 스트림 헤더에서 한 번만 사용되어야 합니다(MUST). 클라이언트가 다른 푸시 스트림 헤더에서 이미 사용된 push ID를 포함하는 푸시 스트림 헤더를 감지하면, 클라이언트는 이를 connection error 유형 H3_ID_ERROR로 처리해야 합니다(MUST).

6.2.3. 예약된 스트림 유형

비음수 정수 N에 대해 형식 0x1f * N + 0x21의 스트림 유형은 미지의 유형을 무시해야 한다는 요구사항을 점검하기 위해 예약되어 있습니다. 이러한 스트림은 의미가 없으며, 애플리케이션 레이어 패딩이 필요할 때 전송할 수 있습니다. 또한 현재 데이터가 전송되지 않는 연결에서 전송될 수 있습니다(MAY). 수신자는 이러한 스트림을 수신 시 어떤 의미도 가진 것으로 간주해서는 안 됩니다(MUST NOT).

스트림의 페이로드와 길이는 전송 구현체가 선택하는 방식으로 선택됩니다. 예약된 스트림 유형을 전송할 때 구현체는 스트림을 정상적으로 종료하거나 리셋할 수 있습니다(MAY). 스트림을 리셋할 때에는 H3_NO_ERROR 오류 코드 또는 예약된 오류 코드를 사용하는 것이 권장됩니다(SHOULD).

7. HTTP 프레이밍 계층

HTTP 프레임은 섹션 6에 설명된 대로 QUIC 스트림에서 전달됩니다. HTTP/3는 세 가지 스트림 유형을 정의합니다: 제어 스트림, 요청 스트림, 및 푸시 스트림. 이 절은 HTTP/3 프레임 형식과 허용되는 스트림 유형을 설명합니다; 개요는 표 1을 참조하십시오. HTTP/2와 HTTP/3 프레임의 비교는 부록 A.2에 제공됩니다.

Table 1: HTTP/3 Frames and Stream Type Overview
Frame	Control Stream	Request Stream	Push Stream	Section
DATA	No	Yes	Yes	Section 7.2.1
HEADERS	No	Yes	Yes	Section 7.2.2
CANCEL_PUSH	Yes	No	No	Section 7.2.3
SETTINGS	Yes (1)	No	No	Section 7.2.4
PUSH_PROMISE	No	Yes	No	Section 7.2.5
GOAWAY	Yes	No	No	Section 7.2.6
MAX_PUSH_ID	Yes	No	No	Section 7.2.7
Reserved	Yes	Yes	Yes	Section 7.2.8

SETTINGS 프레임은 제어 스트림의 첫 번째 프레임으로만 발생할 수 있습니다; 이는 표 1에서 (1)로 표시되어 있습니다. 관련 섹션에 구체적인 지침이 제공됩니다.

QUIC 프레임과 달리, HTTP/3 프레임은 여러 패킷에 걸쳐 있을 수 있다는 점에 유의하십시오.

7.1. 프레임 레이아웃

모든 프레임은 다음 형식을 가집니다:

HTTP/3 Frame Format {
  Type (i),
  Length (i),
  Frame Payload (..),
}

Figure 3: HTTP/3 Frame Format

프레임은 다음 필드를 포함합니다:

Type:: 프레임 유형을 식별하는 변수 길이 정수입니다.
Length:: Frame Payload의 바이트 길이를 설명하는 변수 길이 정수입니다.
Frame Payload:: Type 필드에 의해 결정되는 의미를 갖는 페이로드입니다.

각 프레임의 페이로드는 그 설명에 식별된 필드들만 정확히 포함해야 합니다(MUST). 식별된 필드 이후에 추가 바이트를 포함하거나 식별된 필드가 끝나기 전에 종료되는 프레임 페이로드는 connection error 유형 H3_FRAME_ERROR로 처리되어야 합니다(MUST). 특히 중복된 길이 인코딩은 일관성 있는지 검증되어야 합니다; 섹션 10.8를 참조하십시오.

스트림이 정상적으로 종료될 때 스트림의 마지막 프레임이 잘려 있으면 이는 connection error 유형 H3_FRAME_ERROR로 처리되어야 합니다(MUST). 갑작스럽게 종료된 스트림은 프레임의 어느 시점에서든 리셋될 수 있습니다.

7.2. 프레임 정의

7.2.1. DATA

DATA 프레임(type=0x00)은 HTTP 요청 또는 응답 콘텐츠와 관련된 임의의 가변 길이 바이트 시퀀스를 전달합니다.

DATA 프레임은 HTTP 요청 또는 응답과 연관되어야 합니다(MUST). DATA 프레임이 제어 스트림에서 수신되면, 수신자는 connection error 유형 H3_FRAME_UNEXPECTED로 응답해야 합니다.

DATA Frame {
  Type (i) = 0x00,
  Length (i),
  Data (..),
}

Figure 4: DATA Frame

7.2.2. HEADERS

HEADERS 프레임(type=0x01)은 QPACK을 사용해 인코딩된 HTTP 필드 섹션을 운반하는 데 사용됩니다. 자세한 내용은 [QPACK]을 참조하십시오.

HEADERS Frame {
  Type (i) = 0x01,
  Length (i),
  Encoded Field Section (..),
}

Figure 5: HEADERS Frame

HEADERS 프레임은 요청 스트림 또는 푸시 스트림에서만 전송될 수 있습니다. 만약 HEADERS 프레임이 제어 스트림에서 수신되면, 수신자는 connection error 유형 H3_FRAME_UNEXPECTED로 응답해야 합니다(MUST).

7.2.3. CANCEL_PUSH

CANCEL_PUSH 프레임(type=0x03)은 푸시 스트림이 수신되기 전에 서버 푸시의 취소를 요청하는 데 사용됩니다. CANCEL_PUSH 프레임은 서버 푸시를 push ID로 식별합니다(자세한 내용은 섹션 4.6 참조), 이 값은 변수 길이 정수로 인코딩됩니다.

클라이언트가 CANCEL_PUSH 프레임을 보낼 때 이는 약속된 리소스를 받고 싶지 않음을 나타냅니다. 서버는 리소스 전송을 중단하는 것이 권장되지만, 이를 수행하는 메커니즘은 해당 푸시 스트림의 상태에 따라 다릅니다. 서버가 아직 푸시 스트림을 생성하지 않았다면 생성하지 않습니다. 푸시 스트림이 열려 있다면 서버는 해당 스트림을 갑작스럽게 종료해야 합니다(SHOULD). 푸시 스트림이 이미 종료된 경우 서버는 스트림을 갑작스럽게 종료할 수도 있고 아무 조치도 취하지 않을 수도 있습니다(MAY).

서버는 이전에 전송된 약속을 이행하지 않겠다는 것을 알리기 위해 CANCEL_PUSH 프레임을 전송합니다. 클라이언트는 해당 약속이 이미 수신되어 처리되지 않는 한 약속이 이행될 것으로 기대해서는 안 됩니다. 푸시 스트림이 이미 열렸더라도 서버는 약속이 이행되지 않음을 결정하면 CANCEL_PUSH 프레임을 보내는 것이 권장됩니다(SHOULD). 스트림이 이미 열려 있는 경우, 서버는 H3_REQUEST_CANCELLED 오류 코드로 해당 스트림 전송을 중단할 수 있습니다.

CANCEL_PUSH 프레임 전송은 기존 푸시 스트림의 상태에 직접적인 영향을 주지 않습니다. 클라이언트는 이미 해당 푸시 스트림을 수신한 경우 CANCEL_PUSH 프레임을 보내서는 안 됩니다(SHOULD NOT). 서버가 CANCEL_PUSH를 처리하지 않아 푸시 스트림이 클라이언트에게 도착할 수 있으므로, 클라이언트는 H3_REQUEST_CANCELLED 오류 코드로 스트림 읽기를 중단하는 것이 권장됩니다(SHOULD).

CANCEL_PUSH 프레임은 제어 스트림에서 전송됩니다. 제어 스트림이 아닌 다른 스트림에서 CANCEL_PUSH 프레임을 수신하면 이는 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST).

CANCEL_PUSH Frame {
  Type (i) = 0x03,
  Length (i),
  Push ID (i),
}

Figure 6: CANCEL_PUSH Frame

CANCEL_PUSH 프레임은 push ID를 변수 길이 정수로 인코딩한 값을 운반합니다. Push ID 필드는 취소되는 서버 푸시를 식별합니다(자세한 내용은 섹션 4.6 참조). 만약 CANCEL_PUSH 프레임이 현재 연결에서 허용되는 값보다 큰 push ID를 참조하면, 이는 connection error 유형 H3_ID_ERROR로 처리되어야 합니다(MUST).

클라이언트가 CANCEL_PUSH 프레임을 수신하면, 해당 프레임은 재정렬로 인해 아직 PUSH_PROMISE 프레임에 의해 언급되지 않은 push ID를 식별할 수 있습니다. 서버가 아직 PUSH_PROMISE 프레임으로 언급하지 않은 push ID에 대해 CANCEL_PUSH를 받으면, 이는 connection error 유형 H3_ID_ERROR로 처리되어야 합니다(MUST).

7.2.4. SETTINGS

SETTINGS 프레임(type=0x04)은 엔드포인트 간의 통신 방식에 영향을 미치는 구성 매개변수를 전달합니다. 예를 들어 피어 동작에 대한 선호사항과 제약이 있습니다. 개별적으로 SETTINGS 매개변수는 "setting"이라고도 불리며, 각 설정 매개변수의 식별자와 값은 각각 "setting identifier"와 "setting value"로 참조될 수 있습니다.

SETTINGS 프레임은 항상 전체 HTTP/3 연결에 적용되며 단일 스트림에는 적용되지 않습니다. 각 피어는 제어 스트림의 첫 번째 프레임으로 SETTINGS 프레임을 전송해야 하며(MUST), 이후에는 전송해서는 안 됩니다. 제어 스트림에서 두 번째 SETTINGS 프레임을 수신하면, 해당 엔드포인트는 connection error 유형 H3_FRAME_UNEXPECTED로 응답해야 합니다(MUST).

SETTINGS 프레임은 제어 스트림 이외의 어떤 스트림에서도 전송되어서는 안 됩니다(MUST NOT). 만약 다른 스트림에서 SETTINGS 프레임을 수신하면, 해당 엔드포인트는 connection error 유형 H3_FRAME_UNEXPECTED로 응답해야 합니다(MUST).

SETTINGS 매개변수는 협상되지 않습니다; 이들은 전송하는 피어의 특성을 설명하며 수신 피어가 이를 사용할 수 있습니다. 그러나 SETTINGS의 사용으로 암묵적인 협상이 이루어질 수 있습니다: 각 피어는 지원되는 값 집합을 광고하기 위해 SETTINGS를 사용합니다. 설정의 정의는 각 피어가 두 집합을 결합하여 어떤 선택이 사용될지를 결론내는 방법을 설명합니다. SETTINGS는 선택이 언제 효력을 발생하는지 식별하는 메커니즘을 제공하지 않습니다.

같은 매개변수에 대해 서로 다른 값이 각 피어에 의해 광고될 수 있습니다. 예를 들어, 클라이언트는 매우 큰 응답 필드 섹션을 소비할 의향이 있을 수 있지만 서버는 요청 크기에 대해 더 신중할 수 있습니다.

동일한 설정 식별자가 SETTINGS 프레임에서 두 번 이상 나타나서는 안 됩니다(MUST NOT). 수신자는 중복된 설정 식별자의 존재를 connection error 유형 H3_SETTINGS_ERROR로 처리할 수 있습니다(MAY).

SETTINGS 프레임의 페이로드는 0개 이상의 매개변수로 구성됩니다. 각 매개변수는 식별자와 값으로 구성되며, 둘 다 QUIC 변수 길이 정수로 인코딩됩니다.

Setting {
  Identifier (i),
  Value (i),
}

SETTINGS Frame {
  Type (i) = 0x04,
  Length (i),
  Setting (..) ...,
}

Figure 7: SETTINGS Frame

구현체는 자신이 이해하지 못하는 식별자를 가진 매개변수를 무시해야 합니다(MUST).

7.2.4.1. 정의된 SETTINGS 매개변수

다음 설정들이 HTTP/3에서 정의됩니다:

SETTINGS_MAX_FIELD_SECTION_SIZE (0x06) :: 기본값은 무제한입니다. 사용법은 섹션 4.2.2를 참조하십시오.

비음수 정수 값 N에 대해 형식 0x1f * N + 0x21의 설정 식별자는 미지의 식별자가 무시되어야 한다는 요구사항을 점검하기 위해 예약되어 있습니다. 이러한 설정은 정의된 의미가 없습니다. 엔드포인트는 SETTINGS 프레임에 적어도 하나의 그러한 설정을 포함하는 것이 권장됩니다(SHOULD). 수신자는 이러한 설정을 수신 시 어떤 의미도 가진 것으로 간주해서는 안 됩니다(MUST NOT).

해당 설정에 정의된 의미가 없으므로, 설정의 값은 구현체가 선택한 임의의 값일 수 있습니다.

[HTTP/2]에서 정의되었으나 HTTP/3에 대응하는 설정이 없는 설정 식별자들도 예약되어 있습니다(섹션 11.2.2). 이러한 예약된 설정은 전송해서는 안 되며(MUST NOT), 수신되면 connection error 유형 H3_SETTINGS_ERROR로 처리되어야 합니다(MUST).

추가 설정은 HTTP/3 확장으로 정의될 수 있습니다; 자세한 내용은 섹션 9을 참조하십시오.

7.2.4.2. 초기화

HTTP 구현체는 피어의 현재 이해에 근거하여 무효한 프레임이나 요청을 전송해서는 안 됩니다(MUST NOT).

모든 설정은 초기값에서 시작합니다. 각 엔드포인트는 피어의 SETTINGS 프레임이 도착하기 전에 이러한 초기값을 사용하여 메시지를 전송하는 것이 권장됩니다(SHOULD), 왜냐하면 SETTINGS를 포함한 패킷이 손실되거나 지연될 수 있기 때문입니다. SETTINGS 프레임이 도착하면 설정은 새로운 값으로 변경됩니다.

이는 SETTINGS 프레임을 기다릴 필요를 제거합니다. 엔드포인트는 SETTINGS 프레임을 전송하기 전에 피어로부터 어떤 데이터를 수신해야 한다고 요구해서는 안 됩니다(MUST NOT); SETTINGS는 전송이 데이터를 보낼 준비가 되면 가능한 한 빨리 전송되어야 합니다(MUST).

서버의 경우, 각 클라이언트 설정의 초기값은 기본값입니다.

1-RTT QUIC 연결을 사용하는 클라이언트의 경우, 각 서버 설정의 초기값은 기본값입니다. 1-RTT 키는 서버가 즉시 SETTINGS를 전송하더라도 SETTINGS를 포함한 패킷이 QUIC에 의해 처리되기 전에 항상 사용 가능해집니다. 클라이언트는 SETTINGS가 도착하기를 무기한 기다려서는 안 되지만(SHOULD NOT), SETTINGS가 첫 요청을 전송하기 전에 처리될 가능성을 높이기 위해 수신된 데이터그램을 처리해야 합니다(SHOULD).

0-RTT QUIC 연결을 사용하는 경우, 각 서버 설정의 초기값은 이전 세션에서 사용된 값입니다. 클라이언트는 재개 정보가 제공된 HTTP/3 연결에서 서버가 제공한 설정을 저장하는 것이 권장됩니다(SHOULD), 그러나 특정 경우에는 설정을 저장하지 않을 수 있습니다(MAY), 예: 세션 티켓이 SETTINGS 프레임보다 먼저 수신된 경우. 클라이언트는 0-RTT 시 저장된 설정(또는 저장된 값이 없으면 기본값)을 준수해야 합니다(MUST). 서버가 새 설정을 제공하면, 클라이언트는 그 값을 준수해야 합니다(MUST).

서버는 자신이 광고한 설정을 기억하거나 티켓에 값의 무결성 보호된 복사본을 저장하고 0-RTT 데이터를 허용할 때 정보를 복구할 수 있습니다. 서버는 HTTP/3 설정 값을 사용하여 0-RTT 데이터를 수락할지 여부를 결정합니다. 서버가 클라이언트가 기억한 설정이 현재 설정과 호환된다는 것을 판단할 수 없으면 0-RTT 데이터를 수락해서는 안 됩니다(MUST NOT). 기억된 설정은 클라이언트가 해당 설정을 준수할 경우 서버의 현재 설정을 위반하지 않는 경우 호환되는 것으로 간주됩니다.

서버는 0-RTT를 수락할 수 있으며 이후 SETTINGS 프레임에서 다른 설정을 제공할 수 있습니다(MAY). 만약 서버가 0-RTT 데이터를 수락하면, SETTINGS 프레임은 클라이언트의 0-RTT 데이터로 인해 클라이언트가 위반할 수 있는 어떤 제한도 줄이거나 값을 변경해서는 안 됩니다(MUST NOT). 서버는 기본값과 다른 모든 설정을 포함해야 합니다(MUST). 서버가 0-RTT를 수락했지만 이후에 클라이언트가 이전에 지정한 설정과 호환되지 않는 SETTINGS 프레임을 전송하면, 이는 connection error 유형 H3_SETTINGS_ERROR로 처리되어야 합니다(MUST). 서버가 0-RTT를 수락했지만 이후에 클라이언트가 이해하는 설정 값(예약된 식별자를 제외하고) 중 이전에 비기본값으로 지정된 값을 누락한 SETTINGS 프레임을 보낸다면, 이는 connection error 유형 H3_SETTINGS_ERROR로 처리되어야 합니다(MUST).

7.2.5. PUSH_PROMISE

PUSH_PROMISE 프레임(type=0x05)은 요청 스트림에서 서버가 클라이언트에게 약속된 요청 헤더 섹션을 전달하는 데 사용됩니다.

PUSH_PROMISE Frame {
  Type (i) = 0x05,
  Length (i),
  Push ID (i),
  Encoded Field Section (..),
}

Figure 8: PUSH_PROMISE Frame

페이로드는 다음으로 구성됩니다:

Push ID:: 서버 푸시 작업을 식별하는 변수 길이 정수입니다. push ID는 푸시 스트림 헤더(섹션 4.6) 및 CANCEL_PUSH 프레임에서 사용됩니다.
Encoded Field Section:: PROMISED 응답을 위한 QPACK 인코딩된 요청 헤더 필드입니다. 자세한 내용은 [QPACK]을 참조하십시오.

서버는 클라이언트가 MAX_PUSH_ID 프레임에서 제공한 값보다 더 큰 push ID를 사용해서는 안 됩니다(MUST NOT). 클라이언트는 자신이 광고한 값보다 큰 push ID를 포함하는 PUSH_PROMISE 프레임을 수신하면, 이를 connection error 유형 H3_ID_ERROR로 처리해야 합니다(MUST).

서버는 동일한 push ID를 여러 PUSH_PROMISE 프레임에서 사용할 수 있습니다(MAY). 이 경우 압축 해제된 요청 헤더 집합은 동일한 순서로 동일한 필드를 포함해야 하며, 각 필드의 이름과 값이 정확히 일치해야 합니다(MUST). 클라이언트는 동일한 리소스에 대해 여러 번 약속된 경우 요청 헤더 섹션을 비교하는 것이 권장됩니다(SHOULD). 클라이언트가 이미 약속된 push ID를 받고 불일치를 감지하면, 이는 connection error 유형 H3_GENERAL_PROTOCOL_ERROR로 처리되어야 합니다(MUST). 압축 해제된 필드 섹션이 정확히 일치하면, 클라이언트는 PUSH_PROMISE 프레임이 수신된 각 스트림에 대해 푸시된 콘텐츠를 연관시키는 것이 권장됩니다(SHOULD).

동일한 push ID에 대한 중복 참조를 허용하는 주된 이유는 동시 요청으로 인한 중복을 줄이기 위함입니다. 서버는 장기간에 걸쳐 push ID를 재사용하는 것을 피하는 것이 권장됩니다(SHOULD). 클라이언트는 서버 푸시 응답을 소비하고 장기간 재사용을 위해 보유하지 않을 가능성이 높습니다. 이미 소비하고 폐기한 push ID를 사용하는 PUSH_PROMISE 프레임을 수신한 클라이언트는 해당 약속을 무시해야 합니다.

만약 PUSH_PROMISE 프레ーム이 제어 스트림에서 수신되면, 클라이언트는 이를 connection error 유형 H3_FRAME_UNEXPECTED로 응답해야 합니다(MUST).

클라이언트는 PUSH_PROMISE 프레임을 전송해서는 안 됩니다(MUST NOT). 서버는 PUSH_PROMISE 프레임 수신을 connection error 유형 H3_FRAME_UNEXPECTED로 처리해야 합니다(MUST).

전체 서버 푸시 메커니즘에 대한 설명은 섹션 4.6을 참조하십시오.

7.2.6. GOAWAY

GOAWAY 프레임(type=0x07)은 어느 한쪽 엔드포인트가 HTTP/3 연결의 정상 종료를 시작하는 데 사용됩니다. GOAWAY는 엔드포인트가 이전에 수신된 요청과 푸시의 처리를 마치면서 새 요청이나 푸시 수락을 중지할 수 있게 합니다. 이는 서버 유지보수와 같은 관리 작업을 가능하게 합니다. GOAWAY 자체는 연결을 닫지 않습니다.

GOAWAY Frame {
  Type (i) = 0x07,
  Length (i),
  Stream ID/Push ID (i),
}

Figure 9: GOAWAY Frame

GOAWAY 프레임은 항상 제어 스트림에서 전송됩니다. 서버→클라이언트 방향에서는 클라이언트가 시작한 양방향 QUIC 스트림에 대한 QUIC 스트림 ID를 변수 길이 정수로 포함합니다. 클라이언트는 다른 유형의 스트림 ID를 포함한 GOAWAY 프레임을 수신하면 이를 connection error 유형 H3_ID_ERROR로 처리해야 합니다(MUST).

클라이언트→서버 방향에서는 GOAWAY 프레임이 변수 길이 정수로 인코딩된 push ID를 포함합니다.

GOAWAY 프레임은 특정 스트림이 아니라 전체 연결에 적용됩니다. 클라이언트는 제어 스트림이 아닌 스트림에서 GOAWAY 프레임을 수신하면 이를 connection error 유형 H3_FRAME_UNEXPECTED로 처리해야 합니다(MUST).

GOAWAY 프레임 사용에 관한 추가 정보는 섹션 5.2를 참조하십시오.

7.2.7. MAX_PUSH_ID

MAX_PUSH_ID 프레임(type=0x0d)은 클라이언트가 서버가 시작할 수 있는 서버 푸시 수를 제어하는 데 사용됩니다. 이는 서버가 PUSH_PROMISE 및 CANCEL_PUSH 프레임에서 사용할 수 있는 push ID의 최대값을 설정합니다. 결과적으로 이는 QUIC 전송이 유지하는 제한과 더불어 서버가 시작할 수 있는 푸시 스트림의 수를 제한합니다.

MAX_PUSH_ID 프레임은 항상 제어 스트림에서 전송됩니다. 다른 스트림에서 MAX_PUSH_ID 프레임을 수신하면 이는 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST).

서버는 MAX_PUSH_ID 프레임을 전송해서는 안 됩니다(MUST NOT). 클라이언트는 MAX_PUSH_ID 프레임 수신을 connection error 유형 H3_FRAME_UNEXPECTED로 처리해야 합니다(MUST).

HTTP/3 연결이 생성될 때 최대 push ID는 설정되지 않으므로 서버는 MAX_PUSH_ID 프레임을 수신하기 전까지 푸시를 수행할 수 없습니다. 약속된 서버 푸시 수를 관리하려는 클라이언트는 서버가 푸시를 이행하거나 취소할 때 MAX_PUSH_ID 프레임을 전송하여 최대 push ID를 증가시킬 수 있습니다.

MAX_PUSH_ID Frame {
  Type (i) = 0x0d,
  Length (i),
  Push ID (i),
}

Figure 10: MAX_PUSH_ID Frame

MAX_PUSH_ID 프레임은 서버가 사용할 수 있는 push ID의 최대값을 식별하는 단일 변수 길이 정수를 운반합니다(자세한 내용은 섹션 4.6 참조). MAX_PUSH_ID 프레임은 최대 push ID를 줄일 수 없습니다; 이전에 수신한 값보다 작은 값을 포함하는 MAX_PUSH_ID 프레임의 수신은 connection error 유형 H3_ID_ERROR로 처리되어야 합니다(MUST).

7.2.8. 예약된 프레임 유형

비음수 정수 N에 대해 형식 0x1f * N + 0x21의 프레임 유형은 미지의 유형을 무시해야 한다는 요구사항을 점검하기 위해 예약되어 있습니다(섹션 9 참조). 이러한 프레임은 의미가 없으며, 프레임이 허용되는 모든 스트림에서 전송될 수 있습니다(MAY). 이는 애플리케이션 레이어 패딩에 사용될 수 있도록 합니다. 수신자는 이러한 프레임을 수신 시 어떤 의미도 가진 것으로 간주해서는 안 됩니다(MUST NOT).

프레임의 페이로드와 길이는 구현체가 선택하는 방식으로 선택됩니다.

HTTP/2에서 사용되었지만 HTTP/3에 대응하는 프레임이 없는 프레임 유형들도 예약되어 있습니다(섹션 11.2.1). 이러한 프레임 유형은 전송해서는 안 되며(MUST NOT), 수신되면 connection error 유형 H3_FRAME_UNEXPECTED로 처리되어야 합니다(MUST).

8. 오류 처리

스트림을 정상적으로 완료할 수 없을 때, QUIC은 애플리케이션이 해당 스트림을 갑작스럽게 종료(리셋)하고 이유를 전달할 수 있도록 허용합니다; 자세한 내용은 Section 2.4의 [QUIC-TRANSPORT]를 참조하십시오. 이를 "스트림 오류"라고 부릅니다. HTTP/3 구현체는 QUIC 스트림을 닫고 오류 유형을 전달하도록 결정할 수 있습니다. 오류 코드의 와이어 인코딩은 섹션 8.1에 정의되어 있습니다. 스트림 오류는 오류 상태를 나타내는 HTTP 상태 코드와는 구별됩니다. 스트림 오류는 송신자가 전체 요청 또는 응답을 전송하거나 소비하지 않았음을 나타내는 반면, HTTP 상태 코드는 성공적으로 수신된 요청의 결과를 나타냅니다.

연결 전체를 종료해야 하는 경우에도 QUIC은 유사한 방식으로 이유를 전달하는 메커니즘을 제공합니다; 자세한 내용은 Section 5.3의 [QUIC-TRANSPORT]를 참조하십시오. 이를 "연결 오류"라고 부릅니다. 스트림 오류와 유사하게, HTTP/3 구현체는 QUIC 연결을 종료하고 섹션 8.1의 오류 코드를 사용하여 이유를 전달할 수 있습니다.

스트림과 연결을 닫는 이유가 "오류"라고 불리더라도, 이러한 동작이 반드시 연결이나 어느 한 구현체의 문제를 의미하지는 않습니다. 예를 들어, 요청한 리소스가 더 이상 필요하지 않은 경우 스트림을 리셋할 수 있습니다.

엔드포인트는 특정 상황에서 스트림 오류를 연결 오류로 처리하여 단일 스트림의 조건에 대응하여 전체 연결을 닫기로 선택할 MAY 있습니다. 구현체는 이러한 선택을 하기 전에 미결 요청에 미칠 영향을 고려해야 합니다.

새로운 오류 코드는 협상 없이 정의될 수 있으므로(자세한 내용은 섹션 9 참조), 예기치 않은 문맥에서 오류 코드를 사용하거나 알 수 없는 오류 코드를 수신하는 경우 그것을 MUST H3_NO_ERROR와 동등하게 처리해야 합니다. 그러나 스트림을 닫는 것은 오류 코드와 관계없이 다른 효과를 가질 수 있습니다; 예를 들어 섹션 4.1를 참조하십시오.

8.1. HTTP/3 오류 코드

다음 오류 코드들은 스트림을 갑작스럽게 종료하거나 스트림 읽기를 중단하거나 HTTP/3 연결을 즉시 닫을 때 사용하기 위해 정의됩니다.

H3_NO_ERROR (0x0100) :: 오류 없음. 연결이나 스트림을 닫아야 하지만 신호할 오류가 없을 때 사용됩니다.
H3_GENERAL_PROTOCOL_ERROR (0x0101) :: 피어가 더 구체적인 오류 코드에 맞지 않는 방식으로 프로토콜 요구사항을 위반했거나, 엔드포인트가 더 구체적인 오류 코드를 사용하지 않기로 한 경우.
H3_INTERNAL_ERROR (0x0102) :: HTTP 스택에서 내부 오류가 발생했습니다.
H3_STREAM_CREATION_ERROR (0x0103) :: 엔드포인트가 피어가 생성한 스트림을 수용하지 않기로 감지했습니다.
H3_CLOSED_CRITICAL_STREAM (0x0104) :: HTTP/3 연결에 필요했던 스트림이 닫히거나 리셋되었습니다.
H3_FRAME_UNEXPECTED (0x0105) :: 현재 상태나 해당 스트림에서 허용되지 않는 프레임이 수신되었습니다.
H3_FRAME_ERROR (0x0106) :: 레이아웃 요구사항을 만족하지 못하거나 유효하지 않은 크기의 프레임이 수신되었습니다.
H3_EXCESSIVE_LOAD (0x0107) :: 피어가 과도한 부하를 발생시키는 행태를 보이는 것으로 감지되었습니다.
H3_ID_ERROR (0x0108) :: 스트림 ID 또는 push ID가 제한 초과, 제한 축소, 재사용 등 잘못 사용되었습니다.
H3_SETTINGS_ERROR (0x0109) :: 엔드포인트가 SETTINGS 프레임의 페이로드에서 오류를 감지했습니다.
H3_MISSING_SETTINGS (0x010a) :: 제어 스트림(control stream)의 시작에서 SETTINGS 프레임이 수신되지 않았습니다.
H3_REQUEST_REJECTED (0x010b) :: 서버가 애플리케이션 처리를 전혀 수행하지 않고 요청을 거부했습니다.
H3_REQUEST_CANCELLED (0x010c) :: 요청 또는 그 응답(푸시된 응답 포함)이 취소되었습니다.
H3_REQUEST_INCOMPLETE (0x010d) :: 클라이언트의 스트림이 완전한 요청을 포함하지 않은 채 종료되었습니다.
H3_MESSAGE_ERROR (0x010e) :: HTTP 메시지가 형식이 잘못됨으로 처리할 수 없습니다.
H3_CONNECT_ERROR (0x010f) :: CONNECT 요청에 응답하여 설정된 TCP 연결이 리셋되었거나 비정상적으로 종료되었습니다.
H3_VERSION_FALLBACK (0x0110) :: 요청된 작업을 HTTP/3로 제공할 수 없습니다. 피어는 HTTP/1.1로 재시도해야 합니다.

비음수 정수 값 N에 대해 형식 0x1f * N + 0x21의 오류 코드는 미지의 오류 코드가 H3_NO_ERROR와 동등하게 처리되어야 한다는 요구사항을 점검하기 위해 예약되어 있습니다(섹션 9). 구현체는 H3_NO_ERROR를 보낼 가능성이 있었던 경우에 이러한 공간에서 오류 코드를 선택하는 것이 권장됩니다(SHOULD).

9. HTTP/3 확장

HTTP/3는 프로토콜의 확장을 허용합니다. 이 절에 설명된 제한 내에서, 프로토콜 확장은 추가 서비스를 제공하거나 프로토콜의 어느 측면이든 변경하는 데 사용될 수 있습니다. 확장은 단일 HTTP/3 연결의 범위 내에서만 유효합니다.

이는 이 문서에서 정의된 프로토콜 요소에 적용됩니다. 이는 새로운 메서드, 상태 코드 또는 필드를 정의하는 등 HTTP를 확장하는 기존 옵션들에는 영향을 미치지 않습니다.

확장은 새로운 프레임 유형(섹션 7.2), 새로운 설정(섹션 7.2.4.1), 새로운 오류 코드(섹션 8), 또는 새로운 단방향 스트림 유형(섹션 6.2)을 사용할 수 있습니다. 이러한 확장 포인트를 관리하기 위한 레지스트리가 설정되어 있습니다: 프레임 유형(섹션 11.2.1), 설정(섹션 11.2.2), 오류 코드(섹션 11.2.3), 스트림 유형(섹션 11.2.4).

구현체는 모든 확장 가능한 프로토콜 요소에서 알 수 없거나 지원되지 않는 값을 무시해야 합니다(MUST). 구현체는 알 수 없거나 지원되지 않는 유형의 단방향 스트림에서 데이터를 폐기하거나 읽기를 중단해야 합니다(MUST). 이는 이러한 확장 포인트들이 사전 합의나 협상 없이 확장에 의해 안전하게 사용될 수 있음을 의미합니다. 그러나 SETTINGS 프레임이 제어 스트림(섹션 6.2.1)의 첫 번째 프레임으로 있어야 한다는 것과 같이 알려진 프레임 유형이 특정 위치에 있어야 하는 경우, 미지의 프레임 유형은 그 요구사항을 만족하지 못하므로 오류로 처리되는 것이 권장됩니다(SHOULD).

기존 프로토콜 구성요소의 의미를 변경할 수 있는 확장은 사용되기 전에 협상되어야 합니다(MUST). 예를 들어, HEADERS 프레임의 레이아웃을 변경하는 확장은 피어가 이를 수용할 긍정적 신호를 주기 전까지 사용할 수 없습니다. 이러한 수정된 레이아웃이 언제 효력을 발생하는지를 조정하는 것은 복잡할 수 있습니다. 따라서 기존 프로토콜 요소의 새로운 정의에 대해 새로운 식별자를 할당하는 것이 더 효과적일 수 있습니다.

이 문서는 확장 사용을 협상하는 특정 방법을 규정하지 않지만, 설정(섹션 7.2.4.1)이 그 목적에 사용될 수 있음을 지적합니다. 양쪽 피어가 확장 사용에 동의하는 값을 설정하면 확장을 사용할 수 있습니다. 설정이 확장 협상에 사용되는 경우, 설정의 기본값은 설정이 누락되면 확장이 비활성화되도록 정의되어야 합니다(MUST).

10. 보안 고려사항

HTTP/3의 보안 고려사항은 TLS를 사용하는 HTTP/2의 고려사항과 비교해 유사해야 합니다. 그러나 RFC 9113 섹션 10의 많은 고려사항이 [QUIC-TRANSPORT]에 적용되며 해당 문서에서 논의됩니다.

10.1. 서버 권한

HTTP/3는 권한(authority)의 HTTP 정의에 의존합니다. 권한 설정의 보안 고려사항은 RFC 9110 섹션 17.1에 논의되어 있습니다.

10.2. 교차 프로토콜 공격

TLS와 QUIC 핸드셰이크에서 ALPN을 사용하는 것은 애플리케이션 레이어 바이트가 처리되기 전에 대상 애플리케이션 프로토콜을 확립합니다. 이는 피어들이 동일한 프로토콜을 사용하고 있다는 강한 확신을 갖도록 합니다.

이는 모든 교차 프로토콜 공격으로부터의 보호를 보장하지는 않습니다. RFC 9000 섹션 21.5는 인증되지 않은 전송을 사용하지 않는 엔드포인트를 대상으로 평문 QUIC 패킷을 사용해 요청 위조를 수행할 수 있는 몇 가지 방법을 설명합니다.

10.3. 중개자 캡슐화 공격

HTTP/3 필드 인코딩은 HTTP 구문에서 유효한 필드 이름이 아닌 이름을 표현할 수 있게 합니다(RFC 9110 섹션 5.1 참조). 유효하지 않은 필드 이름을 포함하는 요청 또는 응답은 MUST 형식이 잘못된 것으로 처리해야 합니다. 따라서 중개자는 유효하지 않은 필드 이름을 포함한 HTTP/3 요청 또는 응답을 HTTP/1.1 메시지로 번역할 수 없습니다.

유사하게, HTTP/3는 유효하지 않은 필드 값을 전송할 수 있습니다. 인코딩 가능한 대부분의 값은 필드 파싱을 변경하지 않겠지만, 캐리지 리턴(ASCII 0x0d), 라인 피드(ASCII 0x0a), 널 문자(ASCII 0x00)는 공격자가 이를 그대로 번역할 경우 악용될 수 있습니다. 필드 값에 허용되지 않는 문자를 포함하는 모든 요청 또는 응답은 MUST 형식이 잘못된 것으로 처리해야 합니다. 유효한 문자는 RFC 9110 섹션 5.5의 "field-content" ABNF 규칙에 의해 정의됩니다.

10.4. 푸시된 응답의 캐시 가능성

푸시된 응답은 클라이언트의 명시적 요청이 없으며, 요청은 서버가 PUSH_PROMISE 프레임에서 제공합니다.

푸시된 응답을 캐시하는 것은 오리진 서버가 Cache-Control 헤더 필드에서 제공하는 지침에 따라 가능합니다. 그러나 단일 서버가 둘 이상의 테넌트를 호스팅하는 경우 문제가 발생할 수 있습니다. 예를 들어, 서버가 각 사용자에게 URI 공간의 작은 부분을 제공할 수 있습니다.

여러 테넌트가 동일 서버에서 공간을 공유하는 경우, 해당 서버는 테넌트가 권한이 없는 리소스의 표현을 푸시할 수 없도록 보장해야 합니다(MUST). 이를 강제하지 못하면 테넌트가 캐시에서 제공되어 권한 있는 테넌트가 제공하는 실제 표현을 덮어쓸 수 있습니다.

클라이언트는 오리진 서버에 대해 권한이 없는 푸시된 응답을 거부해야 합니다; 자세한 내용은 섹션 4.6을 참조하십시오.

10.5. 서비스 거부(DoS) 고려사항

HTTP/3 연결은 HTTP/1.1 또는 HTTP/2 연결보다 운영을 위해 더 많은 자원 할당을 요구할 수 있습니다. 필드 압축과 흐름 제어의 사용은 더 많은 상태를 저장하기 위한 자원 할당에 의존합니다. 이러한 기능에 대한 설정은 이러한 기능들의 메모리 할당이 엄격하게 제한되도록 보장합니다.

PUSH_PROMISE 프레임의 수는 유사한 방식으로 제약됩니다. 서버 푸시를 수락하는 클라이언트는 동시에 발행하는 push ID의 수를 제한하는 것이 권장됩니다(SHOULD).

처리 용량은 상태 용량만큼 효과적으로 보호할 수 없습니다.

피어가 무시해야 하는 정의되지 않은 프로토콜 요소를 전송할 수 있는 능력은 피어가 추가 처리 시간을 소비하게 하도록 악용될 수 있습니다. 이는 다수의 미정의 SETTINGS 매개변수, 알려지지 않은 프레임 유형 또는 알려지지 않은 스트림 유형을 설정함으로써 이루어질 수 있습니다. 다만 일부 사용은 완전히 정당할 수 있는데, 예를 들어 옵션-이해 확장이나 트래픽 분석에 대한 저항을 높이기 위한 패딩 등이 그렇습니다.

필드 섹션의 압축 또한 처리 자원을 낭비할 수 있는 기회를 제공합니다; 잠재적 악용에 관한 자세한 내용은 RFC 9204 섹션 7의 [QPACK]를 참조하십시오.

서버 푸시, 미지의 프로토콜 요소, 필드 압축 등 이 모든 기능은 정당한 사용 사례가 있습니다. 이러한 기능들은 불필요하거나 과도하게 사용될 때에만 부담이 됩니다.

이러한 행태를 모니터링하지 않는 엔드포인트는 서비스 거부 공격의 위험에 노출됩니다. 구현체는 이러한 기능의 사용을 추적하고 사용에 대한 제한을 설정해야 합니다(SHOULD). 엔드포인트는 의심스러운 활동을 연결 오류 유형 H3_EXCESSIVE_LOAD로 처리할 MAY 있지만, 오탐은 정상적인 연결과 요청을 중단시키는 결과를 초래합니다.

10.5.1. 필드 섹션 크기 제한

큰 필드 섹션(섹션 4.1)은 구현체가 많은 양의 상태를 할당하게 만들 수 있습니다. 라우팅에 중요한 헤더 필드가 헤더 섹션 끝부분에 나타날 수 있어 헤더 섹션을 최종 목적지로 스트리밍하는 것을 방해할 수 있습니다. 이러한 순서와 캐시 정확성 보장과 같은 다른 이유로 인해 엔드포인트는 전체 헤더 섹션을 버퍼링해야 할 가능성이 큽니다. 필드 섹션의 크기에 대한 하드 제한이 없으므로 일부 엔드포인트는 헤더 필드를 위해 사용할 수 있는 많은 메모리를 할당해야 할 수 있습니다.

엔드포인트는 SETTINGS_MAX_FIELD_SECTION_SIZE (섹션 4.2.2) 설정을 사용하여 피어에게 필드 섹션 크기에 적용될 수 있는 제한을 알릴 수 있습니다. 이 설정은 권고적이므로 엔드포인트는 이 제한을 초과하는 필드 섹션을 보낼 수 있으며, 그 경우 요청 또는 응답이 형식이 잘못된 것으로 처리될 위험을 감수할 수 있습니다. 이 설정은 HTTP/3 연결에 특정하므로, 어떤 요청이나 응답이 더 낮은, 알려지지 않은 제한을 가진 홉을 만날 수 있습니다. 중개자는 서로 다른 피어가 제시한 값을 전달하여 이 문제를 피하려 할 수 있지만, 그렇게 할 의무는 없습니다.

서버가 자신이 처리할 수 있는 것보다 큰 필드 섹션을 수신하면 HTTP 431 (Request Header Fields Too Large) 상태 코드를 보낼 수 있습니다([RFC6585]). 클라이언트는 처리할 수 없는 응답을 폐기할 수 있습니다.

10.5.2. CONNECT 관련 문제

CONNECT 메서드는 프록시에서 불균형한 부하를 생성할 수 있습니다. 스트림 생성은 TCP 연결 생성 및 유지에 비해 상대적으로 저렴하기 때문입니다. 따라서 CONNECT를 지원하는 프록시는 동시 요청 수에 대해 보다 보수적일 수 있습니다.

프록시는 또한 CONNECT 요청을 운반한 스트림이 닫힌 이후에도 TCP 연결에 대한 일부 자원을 유지할 수 있습니다. 이는 발신 TCP 연결이 TIME_WAIT 상태에 남아있기 때문입니다. 이를 고려하여 프록시는 TCP 연결이 종료된 직후 QUIC 스트림 한도를 증가시키는 것을 지연할 수 있습니다.

10.6. 압축 사용

압축은 공격자가 동일한 컨텍스트에서 공격자가 제어하는 데이터와 함께 압축된 비밀 데이터를 회복하게 할 수 있습니다. HTTP/3는 필드의 압축을 허용합니다(섹션 4.2); 다음 우려사항은 HTTP 압축된 콘텐츠 인코딩의 사용에도 적용됩니다; 자세한 내용은 RFC 9110 섹션 8.4.1을 참조하십시오.

웹의 특성을 악용하는 압축 공격이 입증되어 있습니다(예: [BREACH]). 공격자는 다양한 평문을 포함하는 여러 요청을 유도하고, 그 결과 암호문 길이를 관찰하여 비밀에 대한 추측이 맞을 때 더 짧은 길이를 드러내는 방식으로 정보를 얻습니다.

보안 채널에서 통신하는 구현체는 기밀 데이터와 공격자가 제어하는 데이터를 동일한 컨텍스트에서 포함하는 콘텐츠를 별도의 압축 컨텍스트를 사용하지 않는 한 압축해서는 안 됩니다(MUST NOT). 데이터의 출처를 신뢰할 수 없으면 압축을 사용해서는 안 됩니다(MUST NOT).

필드 섹션의 압축에 관한 추가 고려사항은 [QPACK]에 설명되어 있습니다.

10.7. 패딩 및 트래픽 분석

패딩은 프레임 콘텐츠의 정확한 크기를 흐리게 하는 데 사용될 수 있으며, 예를 들어 압축된 콘텐츠에 공격자가 제어하는 평문과 비밀 데이터가 모두 포함된 경우와 같은 특정 공격을 완화하기 위해 제공됩니다(예: [BREACH]).

HTTP/2가 PADDING 프레임과 다른 프레임의 Padding 필드를 사용하여 트래픽 분석에 대한 저항성을 높이는 것과 달리, HTTP/3는 전송 계층 패딩에 의존하거나 섹션 7.2.8 및 섹션 6.2.3에서 논의된 예약된 프레임 및 스트림 유형을 사용할 수 있습니다. 이러한 패딩 방법들은 패딩의 세분성, 보호되는 정보와의 관계에서 패딩이 어떻게 배치되는지, 패킷 손실의 경우에 패딩이 적용되는지 여부, 그리고 구현체가 패딩을 어떻게 제어할 수 있는지에 따라 서로 다른 결과를 생성합니다.

예약된 스트림 유형은 연결이 유휴 상태일 때에도 트래픽을 전송하는 것처럼 보이게 하는 데 사용될 수 있습니다. HTTP 트래픽은 종종 버스트로 발생하므로, 겉보기 트래픽은 이러한 버스트의 타이밍이나 지속 시간을 흐리게 하는 데 사용될 수 있으며, 심지어 일정한 데이터 스트림을 전송하는 것처럼 보이게 할 수도 있습니다. 그러나 이러한 트래픽은 여전히 수신자에 의해 흐름 제어되므로, 해당 스트림을 신속히 비워 추가 흐름 제어 크레딧을 제공하지 못하면 발신자의 실제 트래픽 전송 능력이 제한될 수 있습니다.

압축에 의존하는 공격을 완화하기 위해서는 패딩보다 압축을 비활성화하거나 제한하는 것이 바람직할 수 있습니다.

패딩 사용은 즉시 명백해 보이는 것보다 덜 효과적일 수 있습니다. 중복된 패딩은 오히려 역효과를 낳을 수 있습니다. 최선의 경우 패딩은 공격자가 관찰해야 하는 프레임 수를 늘려 길이 정보를 추론하기 어렵게 만들 뿐입니다. 잘못 구현된 패딩 스킴은 쉽게 무력화될 수 있습니다. 특히 예측 가능한 분포를 가진 무작위 패딩은 거의 보호 효과를 제공하지 않으며, 고정 크기로 페이로드를 패딩하면 페이로드 크기가 고정 경계를 넘을 때 정보를 노출할 수 있습니다. 이는 공격자가 평문을 제어할 수 있는 경우 가능할 수 있습니다.

10.8. 프레임 파싱

여러 프로토콜 요소는 일반적으로 가변 길이 정수를 포함하는 명시적 길이를 가진 프레임 형태로 중첩된 길이 요소를 포함합니다. 이는 부주의한 구현자에게 보안 위험을 초래할 수 있습니다. 구현체는 프레임의 길이가 그 안에 포함된 필드들의 길이와 정확히 일치하는지 확인해야 합니다(MUST).

10.9. 조기 데이터

HTTP/3에서 0-RTT 사용은 재전송(replay) 공격에 노출될 수 있습니다. 0-RTT를 사용할 때는 [HTTP-REPLAY]의 재전송 방지 완화책을 적용해야 합니다(MUST). HTTP/3에 [HTTP-REPLAY]를 적용할 때, TLS 계층에 대한 참조는 QUIC 내에서 수행되는 핸드셰이크를 가리키고, 애플리케이션 데이터에 대한 모든 참조는 스트림의 내용을 가리킵니다.

10.10. 마이그레이션

일부 HTTP 구현체는 로깅이나 접근 제어 목적으로 클라이언트 주소를 사용합니다. QUIC 클라이언트의 주소는 연결 중에 변경될 수 있으므로(향후 버전에서 여러 주소의 동시 사용을 지원할 수 있음), 이러한 구현체는 관련 시점에 클라이언트의 현재 주소를 적극적으로 검색하거나 원래 주소가 변경될 수 있음을 명시적으로 수용해야 합니다.

10.11. 프라이버시 고려사항

HTTP/3의 몇 가지 특성은 관찰자에게 시간 경과에 따른 단일 클라이언트 또는 서버의 동작을 연관시킬 기회를 제공합니다. 여기에는 설정 값, 자극에 대한 반응의 타이밍, 설정으로 제어되는 기능의 처리 방식 등이 포함됩니다.

이러한 것들이 동작에서 관찰 가능한 차이를 만들어낼 경우, 특정 클라이언트를 지문화(fingerprinting)하는 근거로 사용될 수 있습니다.

HTTP/3가 단일 QUIC 연결 사용을 선호하면 사이트에서 사용자의 활동을 연관시키기 쉽습니다. 서로 다른 오리진에 대해 연결을 재사용하면 그 오리진들 간의 활동을 연관시킬 수 있습니다.

QUIC의 몇몇 기능은 즉각적인 응답을 요구하며, 엔드포인트가 피어에 대한 지연을 측정하는 데 사용할 수 있습니다. 이는 특정 시나리오에서 프라이버시에 영향을 미칠 수 있습니다.

11. IANA 고려사항

이 문서는 새로운 ALPN 프로토콜 식별자 등록(섹션 11.1)을 수행하고 HTTP/3에서 코드 포인트 할당을 관리하는 새로운 레지스트리들을 생성합니다.

11.1. HTTP/3 식별 문자열 등록

이 문서는 "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" 레지스트리에 HTTP/3를 식별하기 위한 새로운 등록을 생성합니다. 이 레지스트리는 [RFC7301]에서 확립되었습니다.

"h3" 문자열이 HTTP/3를 식별합니다:

Protocol:: HTTP/3
Identification Sequence:: 0x68 0x33 ("h3")
Specification:: 이 문서

11.2. 새 레지스트리

이 문서에서 생성된 새로운 레지스트리들은 RFC 9000 섹션 22.1에 문서화된 QUIC 등록 정책에 따라 운영됩니다. 이러한 레지스트리는 모두 RFC 9000 섹션 22.1.1에 나열된 공통 필드 집합을 포함합니다. 이들 레지스트리는 "Hypertext Transfer Protocol version 3 (HTTP/3)" 항목 아래에 수집됩니다.

이들 레지스트리에 대한 초기 할당은 모두 영구 상태로 지정되며 IETF가 변경 제어자(change controller)로, HTTP 작업 그룹(ietf-http-wg@w3.org)이 연락처로 기재됩니다.

11.2.1. 프레임 유형

이 문서는 HTTP/3 프레임 타입 코드에 대한 레지스트리를 설정합니다. "HTTP/3 Frame Types" 레지스트리는 62비트 공간을 관리합니다. 이 레지스트리는 QUIC 레지스트리 정책을 따릅니다; 자세한 내용은 섹션 11.2를 참조하십시오. 이 레지스트리의 영구 등록은 Specification Required 정책에 따라 할당됩니다([RFC8126]), 다만 16진수로 0x00에서 0x3f(포함) 사이의 값은 섹션 4.9 및 섹션 4.10에 정의된 대로 Standards Action 또는 IESG 승인으로 할당됩니다.

이 레지스트리는 [HTTP/2]에 정의된 "HTTP/2 Frame Type" 레지스트리와는 별개이지만, 코드 공간이 겹치는 경우 할당이 서로 병행되도록 하는 것이 바람직합니다. 한 레지스트리에 항목이만 존재하는 경우, 대응 값이 관련 없는 동작에 할당되지 않도록 가능한 모든 노력을 기울여야 합니다(SHOULD). 전문가 검토자는 해당 값이 대응 레지스트리의 동일 값과 충돌하는 경우 관련 없는 등록을 거부할 수 있습니다(MAY).

섹션 11.2에 설명된 공통 필드 외에도, 이 레지스트리의 영구 등록은 다음 필드를 반드시 포함해야 합니다(MUST):

Frame Type:: 프레임 유형의 이름 또는 레이블.

프레임 유형의 명세는 프레임 레이아웃과 의미(조건부로 존재하는 프레임 부분을 포함)를 반드시 포함해야 합니다(MUST).

표 2의 항목들은 이 문서에 의해 등록됩니다.

Table 2: 초기 HTTP/3 프레임 유형
프레임 유형	값	명세
DATA	0x00	섹션 7.2.1
HEADERS	0x01	섹션 7.2.2
Reserved	0x02	이 문서
CANCEL_PUSH	0x03	섹션 7.2.3
SETTINGS	0x04	섹션 7.2.4
PUSH_PROMISE	0x05	섹션 7.2.5
Reserved	0x06	이 문서
GOAWAY	0x07	섹션 7.2.6
Reserved	0x08	이 문서
Reserved	0x09	이 문서
MAX_PUSH_ID	0x0d	섹션 7.2.7

비음수 정수 N에 대해 형식 0x1f * N + 0x21인 각 코드는(IANA에 의해) 할당되어서는 안 되며(MUST NOT) 할당 값 목록에 나타나서도 안 됩니다.

11.2.2. 설정 매개변수

이 문서는 HTTP/3 설정을 위한 레지스트리를 설정합니다. "HTTP/3 Settings" 레지스트리는 62비트 공간을 관리합니다. 이 레지스트리는 QUIC 레지스트리 정책을 따릅니다; 섹션 11.2를 참조하십시오. 이 레지스트리의 영구 등록은 Specification Required 정책에 따라 할당됩니다([RFC8126]), 다만 16진수로 0x00에서 0x3f(포함) 사이의 값은 Standards Action 또는 IESG 승인으로 할당됩니다.

이 레지스트리는 [HTTP/2]에 정의된 "HTTP/2 Settings" 레지스트리와는 별개이지만, 가능한 경우 할당이 서로 병행되도록 하는 것이 바람직합니다. 한 레지스트리에만 항목이 있는 경우에도 해당 값이 관련 없는 동작에 할당되지 않도록 가능한 모든 노력을 기울여야 합니다(SHOULD). 전문가 검토자는 동일 값과 충돌하는 관련 없는 등록을 거부할 수 있습니다(MAY).

섹션 11.2에 설명된 공통 필드 외에도, 이 레지스트리의 영구 등록은 다음 필드를 반드시 포함해야 합니다(MUST):

Setting Name:: 설정의 상징적 이름. 설정 이름 지정은 선택 사항입니다.
Default:: 명시되지 않을 경우 설정의 값. 기본값은 가능한 한 가장 제한적인 값이어야 합니다(SHOULD).

표 3의 항목들은 이 문서에 의해 등록됩니다.

Table 3: 초기 HTTP/3 설정
설정 이름	값	명세	기본값
Reserved	0x00	이 문서	해당 없음
Reserved	0x02	이 문서	해당 없음
Reserved	0x03	이 문서	해당 없음
Reserved	0x04	이 문서	해당 없음
Reserved	0x05	이 문서	해당 없음
MAX_FIELD_SECTION_SIZE	0x06	섹션 7.2.4.1	무제한

형식상의 이유로, 설정 이름은 'SETTINGS_' 접두사를 제거하여 줄여 쓸 수 있습니다.

비음수 정수 N에 대해 형식 0x1f * N + 0x21인 각 코드는 IANA에 의해 할당되어서는 안 되며(MUST NOT) 할당 값 목록에 나타나서도 안 됩니다.

11.2.3. 오류 코드

이 문서는 HTTP/3 오류 코드에 대한 레지스트리를 설정합니다. "HTTP/3 Error Codes" 레지스트리는 62비트 공간을 관리합니다. 이 레지스트리는 QUIC 레지스트리 정책을 따릅니다; 섹션 11.2를 참조하십시오. 이 레지스트리의 영구 등록은 Specification Required 정책에 따라 할당됩니다([RFC8126]), 다만 16진수로 0x00에서 0x3f(포함) 사이의 값은 Standards Action 또는 IESG 승인으로 할당됩니다.

오류 코드 등록은 오류 코드의 설명을 포함해야 합니다. 전문가 리뷰어는 새로운 등록이 기존 오류 코드와 중복되지 않는지 검토할 것을 권고받습니다. 기존 등록의 사용을 권장하지만 의무화하지는 않습니다. "HTTP/2 Error Code" 레지스트리에 등록된 값을 사용하는 것은 권장되지 않으며, 전문가 리뷰어는 그러한 등록을 거부할 수 있습니다(MAY).

섹션 11.2에 설명된 공통 필드 외에도, 이 레지스트리는 두 개의 추가 필드를 포함합니다. 이 레지스트리의 영구 등록은 다음 필드를 반드시 포함해야 합니다(MUST):

Name:: 오류 코드의 이름.
Description:: 오류 코드 의미에 대한 간단한 설명.

표 4의 항목들은 이 문서에 의해 등록됩니다. 이 오류 코드들은 HTTP/2 오류 코드와의 충돌을 피하기 위해 Specification Required 정책 범위에서 선택되었습니다.

Table 4: 초기 HTTP/3 오류 코드
이름	값	설명	명세
H3_NO_ERROR	0x0100	오류 없음	섹션 8.1
H3_GENERAL_PROTOCOL_ERROR	0x0101	일반 프로토콜 오류	섹션 8.1
H3_INTERNAL_ERROR	0x0102	내부 오류	섹션 8.1
H3_STREAM_CREATION_ERROR	0x0103	스트림 생성 오류	섹션 8.1
H3_CLOSED_CRITICAL_STREAM	0x0104	필수 스트림이 닫힘	섹션 8.1
H3_FRAME_UNEXPECTED	0x0105	현재 상태에서 허용되지 않는 프레임	섹션 8.1
H3_FRAME_ERROR	0x0106	프레임이 레이아웃 또는 크기 규칙을 위반함	섹션 8.1
H3_EXCESSIVE_LOAD	0x0107	피어가 과도한 부하를 발생시킴	섹션 8.1
H3_ID_ERROR	0x0108	식별자가 잘못 사용됨	섹션 8.1
H3_SETTINGS_ERROR	0x0109	SETTINGS 프레임에 유효하지 않은 값이 포함됨	섹션 8.1
H3_MISSING_SETTINGS	0x010a	SETTINGS 프레임이 수신되지 않음	섹션 8.1
H3_REQUEST_REJECTED	0x010b	요청이 처리되지 않음	섹션 8.1
H3_REQUEST_CANCELLED	0x010c	데이터가 더 이상 필요하지 않음	섹션 8.1
H3_REQUEST_INCOMPLETE	0x010d	스트림이 조기에 종료됨	섹션 8.1
H3_MESSAGE_ERROR	0x010e	형식이 잘못된 메시지	섹션 8.1
H3_CONNECT_ERROR	0x010f	CONNECT 요청에서의 TCP 리셋 또는 오류	섹션 8.1
H3_VERSION_FALLBACK	0x0110	HTTP/1.1로 재시도	섹션 8.1

비음수 정수 N에 대해 형식 0x1f * N + 0x21인 각 코드는 IANA에 의해 할당되어서는 안 되며(MUST NOT) 할당 값 목록에 나타나서도 안 됩니다.

11.2.4. 스트림 유형

이 문서는 HTTP/3 단방향 스트림 유형에 대한 레지스트리를 설정합니다. "HTTP/3 Stream Types" 레지스트리는 62비트 공간을 관리합니다. 이 레지스트리는 QUIC 레지스트리 정책을 따릅니다; 섹션 11.2를 참조하십시오. 이 레지스트리의 영구 등록은 Specification Required 정책에 따라 할당됩니다([RFC8126]), 다만 16진수로 0x00에서 0x3f(포함) 사이의 값은 Standards Action 또는 IESG 승인으로 할당됩니다.

섹션 11.2에 설명된 공통 필드 외에도, 이 레지스트리의 영구 등록은 다음 필드를 반드시 포함해야 합니다(MUST):

Stream Type:: 스트림 유형의 이름 또는 레이블.
Sender:: 이 스트림 유형을 시작할 수 있는 HTTP/3 연결상의 엔드포인트. 값은 "Client", "Server", 또는 "Both".

영구 등록에 대한 명세는 스트림 유형의 설명과 스트림 내용의 레이아웃 및 의미를 포함해야 합니다(MUST).

표 5의 항목들은 이 문서에 의해 등록됩니다.

Table 5: 초기 스트림 유형
스트림 유형	값	명세	발신자
Control Stream	0x00	섹션 6.2.1	Both
Push Stream	0x01	섹션 4.6	Server

비음수 정수 N에 대해 형식 0x1f * N + 0x21인 각 코드는 IANA에 의해 할당되어서는 안 되며(MUST NOT) 할당 값 목록에 나타나서도 안 됩니다.

12. 참고문헌

12.1. 규범 참조

[ALTSVC]: Nottingham, M., McManus, P., and J. Reschke, “HTTP Alternative Services”, RFC 7838, DOI 10.17487/RFC7838, 2016년 4월, <https://www.rfc-editor.org/info/rfc7838>.
[COOKIES]: Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, 2011년 4월, <https://www.rfc-editor.org/info/rfc6265>.
[HTTP-CACHING]: Fielding, R., 편집., Nottingham, M., 편집., and J. Reschke, 편집., “HTTP Caching”, STD 98, RFC 9111, DOI 10.17487/RFC9111, 2022년 6월, <https://www.rfc-editor.org/info/rfc9111>.
[HTTP-REPLAY]: Thomson, M., Nottingham, M., and W. Tarreau, “Using Early Data in HTTP”, RFC 8470, DOI 10.17487/RFC8470, 2018년 9월, <https://www.rfc-editor.org/info/rfc8470>.
[HTTP]: Fielding, R., 편집., Nottingham, M., 편집., and J. Reschke, 편집., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, 2022년 6월, <https://www.rfc-editor.org/info/rfc9110>.
[QPACK]: Krasic, C., Bishop, M., and A. Frindell, 편집., “QPACK: Field Compression for HTTP/3”, RFC 9204, DOI 10.17487/RFC9204, 2022년 6월, <https://www.rfc-editor.org/info/rfc9204>.
[QUIC-TRANSPORT]: Iyengar, J., 편집. 및 M. Thomson, 편집., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, 2021년 5월, <https://www.rfc-editor.org/info/rfc9000>.
[RFC0793]: Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, 1981년 9월, <https://www.rfc-editor.org/info/rfc793>.
[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997년 3월, <https://www.rfc-editor.org/info/rfc2119>.
[RFC6066]: Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, 2011년 1월, <https://www.rfc-editor.org/info/rfc6066>.
[RFC7301]: Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, 2014년 7월, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017년 6월, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]: Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.
[URI]: Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005년 1월, <https://www.rfc-editor.org/info/rfc3986>.

12.2. 정보 참조

[BREACH]: Gluck, Y., Harris, N., and A. Prado, “BREACH: Reviving the CRIME Attack”, 2013년 7월, <http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[DNS-TERMS]: Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2019년 1월, <https://www.rfc-editor.org/info/rfc8499>.
[HPACK]: Peon, R. and H. Ruellan, “HPACK: Header Compression for HTTP/2”, RFC 7541, DOI 10.17487/RFC7541, 2015년 5월, <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.1]: Fielding, R., 편집., Nottingham, M., 편집., and J. Reschke, 편집., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, 2022년 6월, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2]: Thomson, M., 편집. 및 C. Benfield, 편집., “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, 2022년 6월, <https://www.rfc-editor.org/info/rfc9113>.
[RFC6585]: Nottingham, M. and R. Fielding, “Additional HTTP Status Codes”, RFC 6585, DOI 10.17487/RFC6585, 2012년 4월, <https://www.rfc-editor.org/info/rfc6585>.
[RFC8164]: Nottingham, M. and M. Thomson, “Opportunistic Security for HTTP/2”, RFC 8164, DOI 10.17487/RFC8164, 2017년 5월, <https://www.rfc-editor.org/info/rfc8164>.
[TFO]: Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, “TCP Fast Open”, RFC 7413, DOI 10.17487/RFC7413, 2014년 12월, <https://www.rfc-editor.org/info/rfc7413>.
[TLS]: Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, 2018년 8월, <https://www.rfc-editor.org/info/rfc8446>.

부록 A. HTTP/2에서의 전환 고려사항

HTTP/3는 HTTP/2의 설계에서 많은 영향을 받았으며 여러 유사성을 지닙니다. 이 절에서는 HTTP/3 설계에 사용된 접근 방식을 설명하고, HTTP/2와의 중요한 차이점을 지적하며, HTTP/2 확장을 HTTP/3로 매핑하는 방법을 설명합니다.

HTTP/3는 HTTP/2와의 유사성이 바람직하다는 전제에서 출발하지만, 반드시 충족해야 할 엄격한 요구사항은 아닙니다. HTTP/3는 QUIC이 TCP와 다른 점에서 HTTP/2와 달라집니다. 이는 QUIC 기능(예: 스트림)을 활용하거나 전체 순서 보장의 부재와 같은 중요한 단점을 보완하기 위한 것입니다. 요청과 응답이 스트림과 연관되는 관계 같은 핵심 측면에서 HTTP/3는 HTTP/2와 유사하지만, 설계 세부사항은 상당히 다릅니다.

이 절에서는 몇 가지 중요한 차이점을 언급합니다.

A.1. 스트림

HTTP/3는 HTTP/2보다 더 많은 수의 스트림(2⁶²-1)을 허용합니다. 스트림 식별자 공간의 고갈에 대한 동일한 고려사항이 적용되지만, 공간이 훨씬 커서 연결 흐름 제어 창의 제한 같은 QUIC의 다른 한계에 먼저 도달할 가능성이 큽니다.

HTTP/2와 달리, HTTP/3에서의 스트림 동시성은 QUIC에 의해 관리됩니다. QUIC은 모든 데이터가 수신되고 송신된 데이터가 피어에 의해 확인되면 스트림이 닫힌 것으로 간주합니다. HTTP/2는 END_STREAM 비트를 포함하는 프레임이 전송 계층에 기록되었을 때 스트림이 닫힌 것으로 간주합니다. 결과적으로 동등한 교환의 스트림이 더 오랜 기간 "활성" 상태로 남을 수 있습니다. HTTP/3 서버는 예상 사용 패턴에 따라 HTTP/2와 동등한 동시성을 달성하기 위해 더 많은 수의 클라이언트 시작 양방향 스트림을 허용할 수 있습니다.

HTTP/2에서는 요청 및 응답 본문(즉, DATA 프레임의 페이로드)만 흐름 제어의 대상입니다. 모든 HTTP/3 프레임은 QUIC 스트림에서 전송되므로 HTTP/3에서는 모든 스트림의 모든 프레임이 흐름 제어의 대상이 됩니다.

다른 단방향 스트림 유형의 존재로 인해, HTTP/3는 단방향 스트림의 동시 개수만으로 인플라이트 푸시의 수를 제어하지 않습니다. 대신 HTTP/3 클라이언트는 MAX_PUSH_ID 프레임을 사용하여 서버가 전송하는 푸시 수를 제어합니다.

A.2. HTTP 프레임 유형

QUIC에서는 전송 계층이 여러 프레이밍 개념을 처리하므로 HTTP/2의 많은 프레이밍 개념을 제거할 수 있습니다. 프레임이 이미 스트림 위에 있으므로 스트림 번호를 생략할 수 있습니다. QUIC의 다중화는 이 계층 아래에서 발생하므로 가변 최대 길이 패킷 지원을 제거할 수 있습니다. 스트림 종료는 QUIC이 처리하므로 END_STREAM 플래그가 필요 없습니다. 이는 일반 프레임 레이아웃에서 Flags 필드를 제거할 수 있게 합니다.

프레임 페이로드는 대체로 [HTTP/2]에서 가져왔습니다. 그러나 QUIC에는(예: 흐름 제어) HTTP/2에도 있는 많은 기능이 포함되어 있습니다. 이런 경우 HTTP 매핑은 이를 재구현하지 않습니다. 그 결과 몇몇 HTTP/2 프레임 유형은 HTTP/3에서 필요하지 않습니다. HTTP/2에서 정의된 프레임이 더 이상 사용되지 않는 경우, HTTP/2와 HTTP/3 구현 간의 이식성을 극대화하기 위해 해당 프레임 ID가 예약되었습니다. 다만 양쪽 매핑에 모두 등장하는 프레임 유형이라도 의미가 완전히 동일하지는 않습니다.

많은 차이점은 HTTP/2가 모든 스트림에 걸친 프레임 간의 절대적 순서를 제공하는 반면 QUIC은 각 스트림에서만 이 보장을 제공한다는 사실에서 발생합니다. 따라서 프레임 유형이 다른 스트림의 프레임들이 전송된 순서대로 수신될 것이라는 가정을 할 경우, HTTP/3에서는 그러한 가정이 깨질 수 있습니다.

아래에는 기능 적응의 몇 가지 예와 HTTP/2 확장을 HTTP/3로 변환하는 확장 프레임 구현자에 대한 일반 지침이 설명되어 있습니다.

A.2.1. 우선순위 차이

HTTP/2는 PRIORITY 프레임 및(선택적으로) HEADERS 프레임에서 우선순위 할당을 지정합니다. HTTP/3는 우선순위를 신호하는 수단을 제공하지 않습니다.

명시적 우선순위 신호가 없다고 해서 우선순위가 성능 달성에 중요하지 않다는 의미는 아닙니다.

A.2.2. 필드 압축 차이

HPACK은 순서대로 전달된다는 가정 하에 설계되었습니다. 인코딩된 필드 섹션의 시퀀스는 인코딩된 순서대로 도착(및 디코드)해야 합니다. 이는 동적 테이블의 상태가 양 끝점에서 동기화된 상태로 유지되도록 보장합니다.

이런 전체 순서 보장이 QUIC에 의해 제공되지 않기 때문에, HTTP/3는 HPACK의 수정된 버전인 QPACK을 사용합니다. QPACK은 동적 테이블에 대한 모든 수정을 단일 단방향 스트림에서 수행하여 업데이트의 전체 순서를 보장합니다. 인코딩된 필드를 포함하는 모든 프레임은 테이블 상태를 참조만 할 뿐 이를 수정하지 않습니다.

[QPACK]에서 추가 세부사항을 제공합니다.

A.2.3. 흐름 제어 차이

HTTP/2는 스트림 흐름 제어 메커니즘을 지정합니다. 모든 HTTP/2 프레임이 스트림에서 전달되지만 오직 DATA 프레임 페이로드만 흐름 제어의 대상입니다. QUIC은 스트림 데이터에 대한 흐름 제어를 제공하며 이 문서에서 정의된 모든 HTTP/3 프레임 유형은 스트림에서 전송됩니다. 따라서 모든 프레임 헤더와 페이로드가 흐름 제어의 대상입니다.

A.2.4. 새 프레임 유형 정의에 대한 지침

HTTP/3의 프레임 유형 정의는 종종 QUIC 변수 길이 정수 인코딩을 사용합니다. 특히 스트림 ID는 이 인코딩을 사용하며, 이는 HTTP/2에서 사용한 인코딩보다 더 넓은 범위의 값을 허용합니다. 일부 HTTP/3 프레임은 스트림 ID 이외의 식별자(예: push ID)를 사용합니다. 확장 프레임 유형의 인코딩이 스트림 ID를 포함하면 재정의가 필요할 수 있습니다.

Flags 필드가 일반 HTTP/3 프레임에 없으므로, 플래그에 의존하는 프레임은 페이로드의 일부로서 플래그 공간을 할당해야 합니다.

이러한 문제를 제외하면, HTTP/2의 프레임 유형 확장은 일반적으로 HTTP/2의 스트림 0을 HTTP/3의 control stream로 바꾸는 것만으로도 이식 가능합니다. HTTP/3 확장은 순서에 의존하지 않겠지만, 순서가 있어도 해를 입지는 않으며 보통 HTTP/2로 이식 가능할 것으로 예상됩니다.

A.2.5. HTTP/2와 HTTP/3 프레임 유형 비교

DATA (0x00) :: HTTP/3 프레임에서는 패딩이 정의되어 있지 않습니다. 섹션 7.2.1 참조.
HEADERS (0x01) :: HEADERS의 PRIORITY 영역은 HTTP/3 프레임에서 정의되어 있지 않습니다. 패딩도 정의되어 있지 않습니다. 섹션 7.2.2 참조.
PRIORITY (0x02):: 부록 A.2.1에서 설명한 것처럼, HTTP/3는 우선순위를 신호하는 수단을 제공하지 않습니다.
RST_STREAM (0x03):: HTTP/3에는 RST_STREAM 프레임이 존재하지 않으며, 이는 QUIC이 스트림 생명주기 관리를 제공하기 때문입니다. 동일한 코드 포인트는 CANCEL_PUSH 프레임에 사용됩니다(섹션 7.2.3 참조).
SETTINGS (0x04) :: SETTINGS 프레임은 연결의 시작 시에만 전송됩니다. 섹션 7.2.4 및 부록 A.3 참조.
PUSH_PROMISE (0x05) :: PUSH_PROMISE 프레임은 스트림을 참조하지 않습니다. 대신 push stream 이 PUSH_PROMISE 프레임을 push ID로 참조합니다. 섹션 7.2.5 참조.
PING (0x06):: QUIC이 동등한 기능을 제공하므로 HTTP/3에는 PING 프레임이 없습니다.
GOAWAY (0x07) :: GOAWAY는 오류 코드를 포함하지 않습니다. 클라이언트→서버 방향에서는 서버가 시작한 스트림 ID 대신 push ID를 포함합니다. 섹션 7.2.6 참조.
WINDOW_UPDATE (0x08):: QUIC이 흐름 제어를 제공하므로 HTTP/3에는 WINDOW_UPDATE 프레임이 없습니다.
CONTINUATION (0x09):: HTTP/3에는 CONTINUATION 프레임이 존재하지 않습니다. 대신 HTTP/2보다 더 큰 HEADERS / PUSH_PROMISE 프레임이 허용됩니다.

HTTP/2 확장에서 정의된 프레임 유형은 여전히 적용 가능하다면 HTTP/3용으로 별도 등록해야 합니다. [HTTP/2]에서 정의된 프레임 ID는 단순성을 위해 예약되어 있습니다. HTTP/3의 프레임 유형 공간은 훨씬 크기(62비트 대 8비트)이므로 많은 HTTP/3 프레임 유형이 HTTP/2의 대응 코드 포인트를 가지지 않습니다. 섹션 11.2.1 참조.

A.3. HTTP/2 SETTINGS 매개변수

HTTP/2와의 중요한 차이점 중 하나는 설정이 control stream의 첫 번째 프레임으로서 한 번 전송되고 이후에는 변경될 수 없다는 점입니다. 이는 변경 동기화에 관한 많은 모서리 케이스를 제거합니다.

HTTP/2가 SETTINGS 프레임을 통해 지정하는 일부 전송 계층 옵션은 HTTP/3에서는 QUIC 전송 매개변수로 대체됩니다. HTTP/3에 남겨진 HTTP 수준의 설정은 HTTP/2와 동일한 값을 갖습니다. 대체된 설정은 예약되며, 이들의 수신은 오류입니다. 보존된 값과 예약된 값에 대한 논의는 섹션 7.2.4.1을 참조하십시오.

아래는 각 HTTP/2 SETTINGS 매개변수가 어떻게 매핑되는지의 목록입니다:

SETTINGS_HEADER_TABLE_SIZE (0x01):: [QPACK] 참조.
SETTINGS_ENABLE_PUSH (0x02):: 이는 더 세분화된 서버 푸시 제어를 제공하는 MAX_PUSH_ID 프레임으로 대체되었습니다. HTTP/3 SETTINGS 프레임에서 식별자 0x02(SETTINGS_ENABLE_PUSH에 해당)를 지정하는 것은 오류입니다.
SETTINGS_MAX_CONCURRENT_STREAMS (0x03):: 최대 열린 스트림 ID는 QUIC이 흐름 제어 로직의 일부로 제어합니다. HTTP/3 SETTINGS 프레임에서 식별자 0x03(SETTINGS_MAX_CONCURRENT_STREAMS에 해당)을 지정하는 것은 오류입니다.
SETTINGS_INITIAL_WINDOW_SIZE (0x04):: QUIC은 초기 전송 핸드셰이크에서 스트림 및 연결 흐름 제어 창 크기를 지정할 것을 요구합니다. HTTP/3 SETTINGS 프레임에서 식별자 0x04(SETTINGS_INITIAL_WINDOW_SIZE에 해당)를 지정하는 것은 오류입니다.
SETTINGS_MAX_FRAME_SIZE (0x05):: 이 설정은 HTTP/3에 상응하는 항목이 없습니다. HTTP/3 SETTINGS 프레임에서 식별자 0x05(SETTINGS_MAX_FRAME_SIZE에 해당)를 지정하는 것은 오류입니다.
SETTINGS_MAX_HEADER_LIST_SIZE (0x06):: 이 설정 식별자는 SETTINGS_MAX_FIELD_SECTION_SIZE로 이름이 변경되었습니다.

HTTP/3에서는 설정 값이 가변 길이 정수(6, 14, 30 또는 62비트)로 인코딩되며, HTTP/2의 고정 32비트 필드보다 종종 더 짧은 인코딩을 생성하지만 전체 32비트 공간을 사용하는 경우 더 긴 인코딩이 될 수 있습니다. HTTP/2에서 이식된 설정은 더 효율적인 인코딩을 위해 값을 30비트로 제한하거나 30비트보다 많은 비트가 필요한 경우 62비트 공간을 사용하도록 재정의할 수 있습니다.

설정은 HTTP/2와 HTTP/3에 대해 별도로 정의되어야 합니다. [HTTP/2]에서 정의된 설정 식별자는 단순성을 위해 예약되어 있습니다. HTTP/3의 설정 식별자 공간은 훨씬 넓으므로(62비트 대 16비트) 많은 HTTP/3 설정은 HTTP/2에 해당하는 코드 포인트가 없습니다. 섹션 11.2.2 참조.

QUIC 스트림이 도착 순서가 뒤바뀔 수 있으므로, 엔드포인트는 피어의 설정이 도착할 때까지 다른 스트림에 응답하기 위해 기다리지 않는 것이 좋습니다. 섹션 7.2.4.2 참조.

A.4. HTTP/2 오류 코드

QUIC은 HTTP/2가 제공하는 것과 동일한 개념의 "스트림" 및 "연결" 오류를 가집니다. 다만 HTTP/2와 HTTP/3의 차이로 인해 오류 코드는 버전 간에 직접 이식 가능하지 않습니다.

Section 7에 정의된 HTTP/2 오류 코드는 논리적으로 다음과 같이 HTTP/3 오류 코드로 매핑됩니다:

NO_ERROR (0x00):: H3_NO_ERROR (섹션 8.1).
PROTOCOL_ERROR (0x01):: 이는 더 구체적인 오류 코드가 정의된 경우를 제외하고 H3_GENERAL_PROTOCOL_ERROR로 매핑됩니다. 그런 경우로는 H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, 및 H3_CLOSED_CRITICAL_STREAM 등이 있습니다(모두 섹션 8.1에 정의됨).
INTERNAL_ERROR (0x02):: H3_INTERNAL_ERROR (섹션 8.1).
FLOW_CONTROL_ERROR (0x03):: 적용되지 않음 — QUIC이 흐름 제어를 처리합니다.
SETTINGS_TIMEOUT (0x04):: 적용되지 않음 — SETTINGS에 대한 확인(acknowledgment)이 정의되어 있지 않습니다.
STREAM_CLOSED (0x05):: 적용되지 않음 — QUIC이 스트림 관리를 처리합니다.
FRAME_SIZE_ERROR (0x06):: H3_FRAME_ERROR (섹션 8.1).
REFUSED_STREAM (0x07):: 요청이 처리되지 않았음을 나타내기 위해 H3_REQUEST_REJECTED를 사용합니다(관련 내용은 섹션 8.1 참조). 그 외에는 QUIC이 스트림 관리를 처리하므로 적용되지 않습니다.
CANCEL (0x08):: H3_REQUEST_CANCELLED (섹션 8.1).
COMPRESSION_ERROR (0x09):: 여러 오류 코드가 [QPACK]에 정의되어 있습니다.
CONNECT_ERROR (0x0a):: H3_CONNECT_ERROR (섹션 8.1).
ENHANCE_YOUR_CALM (0x0b):: H3_EXCESSIVE_LOAD (섹션 8.1).
INADEQUATE_SECURITY (0x0c):: 적용되지 않음 — QUIC은 모든 연결에서 충분한 보안을 제공한다고 가정됩니다.
HTTP_1_1_REQUIRED (0x0d):: H3_VERSION_FALLBACK (섹션 8.1).

오류 코드는 HTTP/2와 HTTP/3에 대해 별도로 정의되어야 합니다. 섹션 11.2.3 참조.

A.4.1. HTTP/2와 HTTP/3 오류 간 매핑

HTTP/2와 HTTP/3 간 변환을 수행하는 중개자는 상류에서 오류 조건을 만날 수 있습니다. 다운스트림에 오류 발생을 전달하는 것은 유용하지만, 오류 코드는 대개 연결-로컬 문제를 반영하므로 전파하는 것이 적절하지 않을 수 있습니다.

중개자가 상류 오리진에서 오류를 만난 경우 502 (Bad Gateway)와 같은 HTTP 상태 코드를 전송하여 오류 발생을 표시할 수 있으며, 이는 넓은 범위의 오류에 적합합니다.

오류를 수신 측에 매핑하여 전파하는 것이 유익한 드문 경우가 있습니다. 예를 들어 중개자가 상류에서 HTTP/2의 REFUSED_STREAM 스트림 오류를 받으면 요청이 처리되지 않았고 안전하게 재시도할 수 있다는 명확한 신호를 얻게 됩니다. 이 오류 상태를 HTTP/3의 스트림 오류인 H3_REQUEST_REJECTED로 클라이언트에게 전파하면 클라이언트가 적절한 조치를 취할 수 있습니다. 반대 방향에서는 중개자가 H3_REQUEST_CANCELLED로 스트림을 종료하여 표시된 클라이언트 요청 취소를 전달하는 것이 유익할 수 있습니다; 섹션 4.1.1 참조.

오류 간 변환은 논리적 매핑에 설명되어 있습니다. 오류 코드는 대상 버전에서 부적절하거나 알 수 없는 오류 코드 사용으로 이어지는 우발적 변환을 방지하기 위해 겹치지 않는 공간에 정의되어 있습니다. 중개자는 스트림 오류를 연결 오류로 승격할 수 있지만, 이는 일시적이거나 간헐적인 오류에 대해 HTTP/3 연결에 대한 비용을 수반할 수 있음을 인지해야 합니다.

감사의 글

Robbie Shade와 Mike Warres는 이 문서의 전신인 draft-shade-quic-http2-mapping의 저자였습니다.

IETF QUIC 작업 그룹은 많은 사람들로부터 엄청난 지원을 받았습니다. 그중에서도 다음 사람들은 이 문서에 중요한 기여를 했습니다:

Bence Beky
Daan De Meyer
Martin Duke
Roy Fielding
Alan Frindell
Alessandro Ghedini
Nick Harper
Ryan Hamilton
Christian Huitema
Subodh Iyengar
Robin Marx
Patrick McManus
Luca Niccolini
奥一穂 (Kazuho Oku)
Lucas Pardue
Roberto Peon
Julian Reschke
Eric Rescorla
Martin Seemann
Ben Schwartz
Ian Swett
Willy Taureau
Martin Thomson
Dmitri Tikhonov
Tatsuhiro Tsujikawa

Mike Bishop의 일부 기여는 그가 Microsoft에 재직 중일 때 Microsoft의 지원을 받았습니다.

색인

C
- CANCEL_PUSH 2, 4.6, 4.6, 7, 7.2.3, 7.2.5, 7.2.7, 11.2.1, A.2.5
- connection error 2.2, 4.1, 4.1, 4.4, 4.4, 4.6, 5.2, 6.1, 6.2, 6.2.1, 6.2.1, 6.2.1, 6.2.2, 6.2.2, 7.1, 7.1, 7.2.1, 7.2.2, 7.2.3, 7.2.3, 7.2.3, 7.2.4, 7.2.4, 7.2.4, 7.2.4.1, 7.2.4.2, 7.2.4.2, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.6, 7.2.6, 7.2.7, 7.2.7, 7.2.7, 7.2.8, 8, 10.5, A.4.1
- control stream 2, 3.2, 6.2, 6.2, 6.2, 6.2.1, 7, 7.2.1, 7.2.2, 7.2.3, 7.2.3, 7.2.4, 7.2.4, 7.2.4, 7.2.5, 7.2.6, 7.2.6, 7.2.7, 8.1, 9, A.2.4, A.3
D
- DATA 2, 4.1, 4.1, 4.1, 4.1.2, 4.1.2, 4.4, 4.4, 4.4, 4.4, 4.4, 4.6, 7, 7.2.1, 11.2.1, A.1, A.2.3, A.2.5
G
- GOAWAY 3.3, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 5.3, 5.3, 5.4, 7, 7.2.6, 11.2.1, A.2.5, A.2.5
H
- H3_CLOSED_CRITICAL_STREAM 6.2.1, 8.1, 11.2.3, A.4
- H3_CONNECT_ERROR 4.4, 8.1, 11.2.3, A.4
- H3_EXCESSIVE_LOAD 8.1, 10.5, 11.2.3, A.4
- H3_FRAME_ERROR 7.1, 7.1, 8.1, 11.2.3, A.4
- H3_FRAME_UNEXPECTED 4.1, 4.1, 4.4, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.4, 7.2.5, 7.2.5, 7.2.6, 7.2.7, 7.2.7, 7.2.8, 8.1, 11.2.3, A.4
- H3_GENERAL_PROTOCOL_ERROR 7.2.5, 8.1, 11.2.3, A.4
- H3_ID_ERROR 4.6, 5.2, 6.2.2, 7.2.3, 7.2.3, 7.2.5, 7.2.6, 7.2.7, 8.1, 11.2.3
- H3_INTERNAL_ERROR 8.1, 11.2.3, A.4
- H3_MESSAGE_ERROR 4.1.2, 8.1, 11.2.3, A.4
- H3_MISSING_SETTINGS 6.2.1, 8.1, 11.2.3
- H3_NO_ERROR 4.1, 5.2, 6.2.3, 8, 8.1, 8.1, 8.1, 11.2.3, A.4
- H3_REQUEST_CANCELLED 4.1.1, 4.1.1, 4.6, 7.2.3, 7.2.3, 8.1, 11.2.3, A.4, A.4.1
- H3_REQUEST_INCOMPLETE 4.1, 8.1, 11.2.3
- H3_REQUEST_REJECTED 4.1.1, 4.1.1, 4.1.1, 4.1.1, 8.1, 11.2.3, A.4, A.4.1
- H3_SETTINGS_ERROR 7.2.4, 7.2.4.1, 7.2.4.2, 7.2.4.2, 8.1, 11.2.3
- H3_STREAM_CREATION_ERROR 6.1, 6.2, 6.2.1, 6.2.2, 8.1, 11.2.3
- H3_VERSION_FALLBACK 8.1, 11.2.3, A.4
- HEADERS 2, 4.1, 4.1, 4.1, 4.1, 4.1, 4.1, 4.4, 4.6, 7, 7.2.2, 9, 11.2.1, A.2.1, A.2.5, A.2.5, A.2.5
M
- malformed 4.1, 4.1.2, 4.2, 4.2, 4.2, 4.3, 4.3, 4.3.1, 4.3.2, 4.4, 8.1, 10.3, 10.3, 10.5.1
- MAX_PUSH_ID 2, 4.6, 4.6, 4.6, 4.6, 7, 7.2.5, 7.2.7, 11.2.1, A.1, A.3
P
- push ID 4.6, 5.2, 5.2, 5.2, 6.2.2, 6.2.2, 6.2.2, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.5, 7.2.6, 7.2.7, 7.2.7, 7.2.7, 7.2.7, 7.2.7, 8.1, A.2.5, A.2.5
- push stream 4.1, 4.1, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 6.2, 6.2.2, 7, 7.2.2, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 7.2.5, 7.2.7, A.2.5
- PUSH_PROMISE 2, 4.1, 4.1, 4.1, 4.1, 4.1, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 7, 7.2.3, 7.2.3, 7.2.5, 7.2.7, 10.4, 10.5, 11.2.1, A.2.5, A.2.5, A.2.5, A.2.5
R
- request stream 4.1, 4.1, 4.1, 4.1.1, 4.1.1, 4.4, 4.4, 4.6, 4.6, 4.6, 4.6, 6.1, 7, 7.2.2, 7.2.5
S
- SETTINGS 3.2, 3.2, 6.2.1, 7, 7, 7.2.4, 8.1, 8.1, 9, 10.5, 11.2.1, 11.2.3, 11.2.3, A.2.5, A.2.5, A.3, A.3, A.3, A.3, A.3, A.3, A.4
- SETTINGS_MAX_FIELD_SECTION_SIZE 4.2.2, 7.2.4.1, 10.5.1, A.3
- stream error 2.2, 4.1.2, 4.4, 8, A.4.1, A.4.1, A.4.1

저자 연락처

Mike Bishop (editor)
Akamai
EMail: mbishop@evequefou.be