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

편집자: M. Thomson

요청 의견: 9113

Mozilla

대체함: 7540, 8740

편집자: C. Benfield

분류: 표준 트랙

Apple Inc.

ISSN: 2070-1721

2022년 6월

HTTP/2

초록

이 명세서는 하이퍼텍스트 전송 프로토콜(HTTP)의 의미론을 최적화하여 표현한 HTTP 버전 2(HTTP/2)를 설명한다. HTTP/2는 필드 압축을 도입하고 동일한 연결에서 여러 동시 교환을 허용함으로써 네트워크 자원을 보다 효율적으로 사용하고 지연 시간을 줄일 수 있게 한다.

이 문서는 RFC 7540 및 RFC 8740을 대체한다.

이 메모의 상태

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

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

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

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. 소개
2. HTTP/2 프로토콜 개요
- 2.1. 문서 구성
- 2.2. 관례 및 용어
3. HTTP/2 시작
4. HTTP 프레임
- 4.1. 프레임 형식
- 4.2. 프레임 크기
- 4.3. 필드 섹션 압축 및 압축 해제
  - 4.3.1. 압축 상태
5. 스트림과 다중화
- 5.1. 스트림 상태
  - 5.1.1. 스트림 식별자
  - 5.1.2. 스트림 동시성
- 5.2. 흐름 제어
- 5.3. 우선순위 지정
  - 5.3.1. RFC 7540의 우선순위 배경
  - 5.3.2. 이 문서의 우선순위 신호
- 5.4. 오류 처리
- 5.5. HTTP/2 확장
6. 프레임 정의
- 6.1. DATA
- 6.2. HEADERS
- 6.3. PRIORITY
- 6.4. RST_STREAM
- 6.5. SETTINGS
  - 6.5.1. SETTINGS 형식
  - 6.5.2. 정의된 설정
  - 6.5.3. 설정 동기화
- 6.6. PUSH_PROMISE
- 6.7. PING
- 6.8. GOAWAY
- 6.9. WINDOW_UPDATE
- 6.10. CONTINUATION
7. 오류 코드
8. HTTP/2에서 HTTP 의미 표현
- 8.1. HTTP 메시지 프레이밍
  - 8.1.1. 잘못된 메시지
- 8.2. HTTP 필드
- 8.3. HTTP 제어 데이터
  - 8.3.1. 요청 의사-헤더 필드
  - 8.3.2. 응답 의사-헤더 필드
- 8.4. 서버 푸시
  - 8.4.1. 푸시 요청
  - 8.4.2. 푸시 응답
- 8.5. CONNECT 메서드
- 8.6. 업그레이드 헤더 필드
- 8.7. 요청 신뢰성
- 8.8. 예제
  - 8.8.1. 간단한 요청
  - 8.8.2. 간단한 응답
  - 8.8.3. 복잡한 요청
  - 8.8.4. 본문 있는 응답
  - 8.8.5. 정보 응답
9. HTTP/2 연결
- 9.1. 연결 관리
  - 9.1.1. 연결 재사용
- 9.2. TLS 기능 사용
  - 9.2.1. TLS 1.2 기능
  - 9.2.2. TLS 1.2 암호 모음
  - 9.2.3. TLS 1.3 기능
10. 보안 고려사항
11. IANA 고려사항
- 11.1. HTTP2-Settings 헤더 필드 등록
- 11.2. h2c 업그레이드 토큰
12. 참고문헌
- 12.1. 규범 참조
- 12.2. 정보 참조
Appendix A. 금지된 TLS 1.2 암호 모음
Appendix B. RFC 7540에서의 변경사항
감사의 말
기여자
저자 주소

1. 소개

하이퍼텍스트 전송 프로토콜(HTTP, [HTTP])을 사용하는 애플리케이션의 성능은 각 HTTP 버전이 기본 전송을 어떻게 사용하는지와 전송이 동작하는 조건에 연결되어 있다.

여러 동시 요청을 만드는 것은 지연 시간을 줄이고 애플리케이션 성능을 향상시킬 수 있다. HTTP/1.0은 주어진 TCP [TCP] 연결에서 한 번에 하나의 요청만 유효할 수 있도록 허용했다. HTTP/1.1 [HTTP/1.1]은 요청 파이프라이닝을 추가했지만, 이는 요청 동시성 문제를 부분적으로만 해결했고 여전히 애플리케이션 계층의 헤드-오브-라인 블로킹에 영향을 받는다. 따라서 HTTP/1.0 및 HTTP/1.1 클라이언트는 동시 요청을 위해 서버에 여러 연결을 사용한다.

게다가 HTTP 필드는 종종 반복적이고 장황하여 불필요한 네트워크 트래픽을 유발하고 초기 TCP 혼잡 창이 빠르게 채워지게 한다. 이는 새로운 TCP 연결에서 여러 요청이 이루어질 때 과도한 지연으로 이어질 수 있다.

HTTP/2는 HTTP 의미론을 기본 연결에 최적화하여 매핑함으로써 이러한 문제를 해결한다. 구체적으로, 동일한 연결에서 메시지의 교차 전송을 허용하고 HTTP 필드에 대해 효율적인 인코딩을 사용한다. 또한 요청의 우선순위를 지정할 수 있어 더 중요한 요청이 더 빨리 완료되도록 하여 성능을 더욱 향상시킨다.

결과 프로토콜은 HTTP/1.x와 비교해 더 적은 TCP 연결을 사용하므로 네트워크에 더 우호적이다. 이는 다른 플로우와의 경쟁이 줄고 더 장기간 유지되는 연결로 이어져 사용 가능한 네트워크 용량을 더 잘 활용하게 한다. 다만, 이 프로토콜은 TCP의 헤드-오브-라인 블로킹을 해결하지는 않는다.

마지막으로, HTTP/2는 이진 메시지 프레이밍을 사용하여 메시지 처리를 보다 효율적으로 수행할 수 있게 한다.

이 문서는 RFC 7540 및 8740을 대체한다. 부록 B에는 주목할 만한 변경 사항이 나열되어 있다.

2. HTTP/2 프로토콜 개요

HTTP/2는 HTTP 의미론을 위한 최적화된 전송을 제공한다. HTTP/2는 HTTP의 모든 핵심 기능을 지원하지만 HTTP/1.1보다 더 효율적이도록 설계되었다.

HTTP/2는 TCP 연결([TCP]) 위에서 동작하는 연결 지향적 애플리케이션 계층 프로토콜이다. 클라이언트가 TCP 연결을 시작하는 측이다.

HTTP/2의 기본 프로토콜 단위는 프레임(섹션 4.1)이다. 각 프레임 유형은 다른 목적을 가진다. 예를 들어, HEADERS와 DATA 프레임은 HTTP 요청과 응답의 기초를 형성한다(섹션 8.1); SETTINGS, WINDOW_UPDATE, PUSH_PROMISE와 같은 다른 프레임 유형은 HTTP/2의 다른 기능을 지원하는 데 사용된다.

요청의 다중화는 각 HTTP 요청/응답 교환을 고유한 스트림(섹션 5)과 연관시켜 이루어진다. 스트림은 서로 대부분 독립적이므로, 하나의 요청이나 응답이 차단되거나 정체되어도 다른 스트림의 진행을 막지 않는다.

다중화의 효과적인 사용은 흐름 제어와 우선순위 지정에 달려 있다. 흐름 제어(섹션 5.2)는 수신자가 처리할 수 있는 범위로 전송되는 데이터를 제한하여 다중화된 스트림을 효율적으로 사용할 수 있도록 보장한다. 우선순위 지정(섹션 5.3)은 제한된 자원이 가장 효과적으로 사용되도록 보장한다. 이 HTTP/2 개정판은 [RFC7540]의 우선순위 신호 방식을 더 이상 권장하지 않는다.

연결에서 사용되는 HTTP 필드에는 중복 데이터가 많이 포함될 수 있으므로, 그것들을 포함하는 프레임은 압축된다(섹션 4.3). 이는 일반적인 경우 요청 크기에 특히 유리하여 여러 요청을 하나의 패킷으로 압축할 수 있게 한다.

마지막으로, HTTP/2는 서버가 클라이언트에 응답을 푸시할 수 있는 선택적 상호작용 모드를 추가한다(섹션 8.4). 이는 서버가 클라이언트가 필요로 할 것으로 예상되는 데이터를 추측하여 보내는 것으로, 잠재적 지연 이득을 위해 일부 네트워크 사용을 거래하는 것이다. 서버는 이를 합성된 요청을 생성하여 PUSH_PROMISE 프레임으로 전송함으로써 수행한다. 그런 다음 서버는 별도의 스트림에서 합성 요청에 대한 응답을 보낼 수 있다.

2.1. 문서 구성

HTTP/2 명세서는 네 부분으로 나뉜다:

Starting HTTP/2 (섹션 3)는 HTTP/2 연결이 어떻게 시작되는지를 다룬다.
프레임(섹션 4) 및 스트림(섹션 5) 레이어는 HTTP/2 프레임이 어떻게 구조화되고 다중화된 스트림으로 형성되는지를 설명한다.
프레임(섹션 6) 및 오류(섹션 7) 정의에는 HTTP/2에서 사용되는 프레임 및 오류 유형의 세부사항이 포함된다.
HTTP 매핑(섹션 8)과 추가 요구사항(섹션 9)은 프레임과 스트림을 사용하여 HTTP 의미론이 어떻게 표현되는지를 설명한다.

일부 프레임 및 스트림 계층 개념은 HTTP로부터 분리되어 있지만, 이 명세서는 완전히 일반적인 프레임 계층을 정의하지는 않는다. 프레임 및 스트림 레이어는 HTTP의 필요에 맞게 조정되어 있다.

2.2. 관례 및 용어

이 문서에서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 나타날 때에 한해 BCP 14 [RFC2119] 및 [RFC8174]에 설명된 대로 해석되어야 한다.

모든 숫자 값은 네트워크 바이트 순서이다. 값은 별도로 명시되지 않는 한 부호 없는 값이다. 리터럴 값은 적절하게 십진수 또는 16진수로 제공된다. 16진수 리터럴은 십진수 리터럴과 구별하기 위해 "0x"로 접두된다.

이 명세서는 이진 형식을 설명할 때 RFC 9000의 섹션 1.3에 설명된 관례를 사용한다. 이 형식은 네트워크 바이트 순서를 사용하며 높은 값의 비트가 낮은 값의 비트보다 먼저 표기된다는 점에 유의하라.

다음 용어들이 사용된다:

client:: HTTP/2 연결을 시작하는 엔드포인트. 클라이언트는 HTTP 요청을 보내고 HTTP 응답을 수신한다.
connection:: 두 엔드포인트 간의 전송 계층 연결.
connection error:: 전체 HTTP/2 연결에 영향을 미치는 오류.
endpoint:: 연결의 클라이언트 또는 서버 중 하나.
frame:: 프레임 유형에 따라 구조화된 헤더와 가변 길이 옥텟 시퀀스로 구성된 HTTP/2 연결 내의 가장 작은 통신 단위.
peer:: 엔드포인트. 특정 엔드포인트를 논할 때 "peer"는 논의의 주체에 원격인 엔드포인트를 가리킨다.
receiver:: 프레임을 수신하는 엔드포인트.
sender:: 프레임을 전송하는 엔드포인트.
server:: HTTP/2 연결을 수락하는 엔드포인트. 서버는 HTTP 요청을 수신하고 HTTP 응답을 전송한다.
stream:: HTTP/2 연결 내의 양방향 프레임 흐름.
stream error:: 개별 HTTP/2 스트림의 오류.

마지막으로, "gateway", "intermediary", "proxy", 및 "tunnel" 용어는 RFC 9110의 섹션 3.7에 정의되어 있다. 중개자는 다른 시점에 클라이언트이자 서버로 동작할 수 있다.

메시지 본문에 적용되는 "content" 용어는 RFC 9110의 섹션 6.4에 정의되어 있다.

3. HTTP/2 시작

HTTP 요청을 생성하는 구현은 서버가 HTTP/2를 지원하는지 여부를 발견해야 한다.

HTTP/2는 http 및 https URI 스킴을 사용하며, 이는 RFC 9110의 섹션 4.2에 정의되어 있고 HTTP/1.1과 동일한 기본 포트 번호를 사용한다. 이러한 URI는 업스트림 서버(클라이언트가 연결을 설정하려는 즉각적인 피어)가 어떤 HTTP 버전을 지원하는지에 대한 표시는 포함하지 않는다.

HTTP/2 지원을 결정하는 수단은 http와 https URI에 대해 다르다. "https" URI에 대한 검색 방법은 섹션 3.2에 설명되어 있다. "http" URI에 대한 HTTP/2 지원은 대역 외 수단으로만 발견할 수 있으며 사전 지식이 필요하다(자세한 내용은 섹션 3.3 참조).

3.1. HTTP/2 버전 식별

이 문서에서 정의한 프로토콜은 두 가지 식별자를 가진다. 어느 하나에 기반한 연결을 생성하는 것은 이 문서에 설명된 전송, 프레이밍 및 메시지 의미론의 사용을 의미한다.

문자열 "h2"는 HTTP/2가 전송 계층 보안(TLS)을 사용할 때의 프로토콜을 식별한다; 자세한 내용은 섹션 9.2를 보라. 이 식별자는 TLS ALPN 확장(TLS Application-Layer Protocol Negotiation (ALPN) extension) 필드와 TLS 위에서의 HTTP/2가 식별되는 모든 장소에서 사용된다.

"h2" 문자열은 ALPN 프로토콜 식별자로 두 옥텟 시퀀스 0x68, 0x32로 직렬화된다.
문자열 "h2c"는 이전에 HTTP 업그레이드 메커니즘의 Upgrade 헤더 필드에서 토큰으로 사용되었다(자세한 내용은 RFC 9110의 섹션 7.8 참조). 이 사용은 널리 배포되지 않았고 이 문서에 의해 사용 중단(deprecated)되었다. "h2c"로의 업그레이드에 사용되었던 HTTP2-Settings 헤더 필드도 동일하게 사용 중단된다.

3.2. "https" URI에서 HTTP/2 시작

"https" URI에 요청을 하는 클라이언트는 TLS ([TLS13])을 ALPN 확장(ALPN extension)과 함께 사용한다.

TLS 위의 HTTP/2는 "h2" 프로토콜 식별자를 사용한다. "h2c" 프로토콜 식별자는 클라이언트가 전송해서는 안 되며(MUST NOT) 서버가 선택해서는 안 된다; "h2c" 식별자는 TLS를 사용하지 않는 프로토콜을 설명한다.

TLS 협상이 완료되면, 클라이언트와 서버는 각각 연결 프리페이스(섹션 3.4)를 전송해야 한다(MUST).

3.3. 사전 지식으로 HTTP/2 시작

클라이언트는 다른 수단으로 특정 서버가 HTTP/2를 지원한다는 것을 알 수 있다. 예를 들어, 클라이언트는 서버가 HTTP/2를 지원한다는 사전 구성 정보를 가질 수 있다.

서버가 HTTP/2를 지원한다는 것을 아는 클라이언트는 TCP 연결을 설정하고 연결 프리페이스(섹션 3.4)를 보낸 다음 HTTP/2 프레임을 전송할 수 있다. 서버는 연결 프리페이스의 존재로 이러한 연결을 식별할 수 있다. 이는 평문 TCP 위의 HTTP/2 연결 수립에만 적용된다; TLS 위의 HTTP/2 연결은 TLS에서의 프로토콜 협상을 사용해야 한다(MUST).

마찬가지로, 서버는 연결 프리페이스(섹션 3.4)를 전송해야 한다(MUST).

추가 정보 없이 과거에 HTTP/2를 지원했었다는 사실만으로는 향후 연결에서 해당 서버가 HTTP/2를 지원할 것이라는 강한 신호가 되지 않는다. 예를 들어 서버 구성은 변경될 수 있고, 클러스터된 서버 인스턴스 간에 구성이 다를 수 있으며, 네트워크 조건이 변경될 수 있다.

3.4. HTTP/2 연결 프리페이스

HTTP/2에서 각 엔드포인트는 사용 중인 프로토콜을 최종 확인하고 HTTP/2 연결의 초기 설정을 확립하기 위해 연결 프리페이스를 전송해야 한다. 클라이언트와 서버는 각각 다른 연결 프리페이스를 전송한다.

클라이언트 연결 프리페이스는 24 옥텟의 시퀀스로 시작하며, 16진 표기법으로는 다음과 같다:

  0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

즉, 연결 프리페이스는 문자열 "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"으로 시작한다. 이 시퀀스는 SETTINGS 프레임(섹션 6.5)이 뒤따라야 하며, 이 프레임은 비어 있을 수 있다(MAY). 클라이언트는 클라이언트 연결 프리페이스를 연결의 첫 번째 애플리케이션 데이터 옥텟으로 전송한다.

서버 연결 프리페이스는 잠재적으로 비어 있을 수 있는 SETTINGS 프레임(섹션 6.5)으로 구성되며, 서버가 HTTP/2 연결에서 보내는 첫 번째 프레임이어야 한다(MUST).

연결 프리페이스의 일부로 피어로부터 수신된 SETTINGS 프레임은 연결 프리페이스 전송 후에 확인되어야 한다(확인 방법은 섹션 6.5.3 참조).

불필요한 지연을 피하기 위해, 클라이언트는 서버 연결 프리페이스를 기다리지 않고 클라이언트 연결 프리페이스를 보낸 직후에 추가 프레임을 서버로 전송할 수 있다. 다만 서버의 연결 프리페이스 SETTINGS 프레임에 클라이언트가 서버와 통신하는 방식에 영향을 주는 설정이 포함될 수 있다는 점을 인지하는 것이 중요하다. SETTINGS 프레임을 수신하면 클라이언트는 설정을 존중해야 한다. 일부 구성에서는 서버가 클라이언트가 추가 프레임을 보내기 전에 SETTINGS를 전송할 수 있어 이 문제를 피할 수 있다.

클라이언트와 서버는 유효하지 않은 연결 프리페이스를 연결 오류(섹션 5.4.1)로 처리해야 한다(MUST). 이 경우 피어가 HTTP/2를 사용하지 않음을 나타내므로 GOAWAY 프레임(섹션 6.8)은 생략될 수 있다(MAY).

4. HTTP 프레임

HTTP/2 연결이 설정되면 엔드포인트들은 프레임 교환을 시작할 수 있다.

4.1. 프레임 형식

모든 프레임은 고정 길이 9옥텟 헤더로 시작하고 이어서 가변 길이의 프레임 페이로드가 온다.

HTTP Frame {
  Length (24),
  Type (8),

  Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Frame Payload (..),
}

그림 1: 프레임 레이아웃

프레임 헤더의 필드들은 다음과 같이 정의된다:

Length:: 프레임 페이로드의 길이로, 옥텟 단위의 부호 없는 24비트 정수로 표현된다. 수신자가 SETTINGS_MAX_FRAME_SIZE에 대해 더 큰 값을 설정하지 않은 한 2¹⁴(16,384)보다 큰 값은 전송해서는 안 된다(MUST NOT).

프레임 헤더의 9 옥텟은 이 값에 포함되지 않는다.
Type:: 프레임의 8비트 유형. 프레임 유형은 프레임의 형식과 의미론을 결정한다. 본 문서에 정의된 프레임은 섹션 6에 열거되어 있다. 구현체는 알 수 없는 유형의 프레임을 무시하고 폐기해야 한다(MUST).
Flags:: 프레임 유형별 불리언 플래그를 위해 예약된 8비트 필드.

플래그는 지정된 프레임 유형에 대해 특정한 의미를 가진다. 사용되지 않는 플래그는 특정 프레임 유형에 대해 정의된 의미가 없는 플래그들이다. 사용되지 않는 플래그는 수신 시 무시되어야 하고(MUST), 전송 시 설정되지 않은 상태(0x00)로 남겨져야 한다(MUST).
Reserved:: 예약된 1비트 필드. 이 비트의 의미론은 정의되어 있지 않으며, 전송 시에는 0x00으로 설정되어 있어야 하고(MUST), 수신 시에는 무시되어야 한다(MUST).
Stream Identifier:: 스트림 식별자(자세한 내용은 섹션 5.1.1 참조)로, 부호 없는 31비트 정수로 표현된다. 값 0x00은 개별 스트림이 아닌 전체 연결과 연관된 프레임에 예약되어 있다.

프레임 페이로드의 구조와 내용은 전적으로 프레임 유형에 의존한다.

4.2. 프레임 크기

프레임 페이로드의 크기는 수신자가 SETTINGS_MAX_FRAME_SIZE 설정에서 광고한 최대 크기로 제한된다. 이 설정은 2¹⁴(16,384)에서 2²⁴-1(16,777,215) 옥텟 사이의 어떤 값이든 가질 수 있다.

모든 구현체는 2¹⁴ 옥텟 길이의 프레임(프레임 헤더 9옥텟 제외)을 수신하고 최소한 처리할 수 있어야 한다(MUST). 프레임 크기를 설명할 때 프레임 헤더의 크기는 포함되지 않는다.

프레임이 SETTINGS_MAX_FRAME_SIZE에 정의된 크기를 초과하거나 프레임 유형에 대해 정의된 어떤 제한을 초과하거나 필수 프레임 데이터를 담기에는 너무 작으면 엔드포인트는 FRAME_SIZE_ERROR 오류 코드를 전송해야 한다(MUST). 전체 연결의 상태를 변경할 수 있는 프레임에서의 프레임 크기 오류는 연결 오류(섹션 5.4.1)로 처리되어야 한다(MUST); 여기에는 필드 블록을 담는 프레임(섹션 4.3)(즉, HEADERS, PUSH_PROMISE, 및 CONTINUATION), SETTINGS 프레임, 및 스트림 식별자가 0인 모든 프레임이 포함된다.

엔드포인트는 프레임에서 사용 가능한 모든 공간을 반드시 사용해야 하는 것은 아니다. 허용된 최대 크기보다 작은 프레임을 사용하면 응답성이 향상될 수 있다. 큰 프레임을 전송하면 시기 민감한 프레임(예: RST_STREAM, WINDOW_UPDATE, 또는 PRIORITY)의 전송이 지연될 수 있으며, 큰 프레임의 전송으로 차단되면 성능에 영향을 줄 수 있다.

4.3. 필드 섹션 압축 및 압축 해제

필드 섹션 압축은 필드 라인 집합(RFC 9110 섹션 5.2 참조)을 압축하여 필드 블록을 형성하는 과정이다. 필드 섹션 압축 해제는 필드 블록을 필드 라인 집합으로 디코딩하는 과정이다. HTTP/2 필드 섹션의 압축 및 압축 해제에 대한 세부사항은 [COMPRESSION]에서 정의되며, 역사적 이유로 이 과정들을 헤더 압축 및 압축 해제라 부른다.

각 필드 블록은 단일 필드 섹션의 모든 압축된 필드 라인을 운반한다. 헤더 섹션은 의사-헤더 필드 형태의 메시지 관련 제어 데이터를 포함하며(섹션 8.3), 이는 필드 라인과 동일한 형식을 사용한다.

필드 블록은 요청, 응답, 약속된 요청 및 푸시된 응답의 제어 데이터와 헤더 섹션을 운반한다(자세한 내용은 섹션 8.4 참조). 임시 응답 및 PUSH_PROMISE(섹션 6.6) 프레임에 포함된 요청을 제외한 모든 이러한 메시지는 선택적으로 트레일러 섹션을 운반하는 필드 블록을 포함할 수 있다.

필드 섹션은 필드 라인의 모음이다. 필드 블록의 각 필드 라인은 단일 값을 운반한다. 직렬화된 필드 블록은 필드 블록 조각이라고 불리는 하나 이상의 옥텟 시퀀스로 나뉘어진다. 첫 번째 필드 블록 조각은 HEADERS(섹션 6.2) 또는 PUSH_PROMISE(섹션 6.6) 프레임의 프레임 페이로드 내에서 전송되며, 이후의 필드 블록 조각은 CONTINUATION(섹션 6.10) 프레임들에 의해 운반될 수 있다.

Cookie header field는 HTTP 매핑에서 특수하게 취급된다(자세한 내용은 섹션 8.2.3 참조).

수신 엔드포인트는 조각들을 연결하여 필드 블록을 재조립한 다음 블록을 압축 해제하여 필드 섹션을 재구성한다.

완전한 필드 섹션은 다음 중 하나로 구성된다:

END_HEADERS 플래그가 설정된 단일 HEADERS 또는 PUSH_PROMISE 프레임, 또는
END_HEADERS 플래그가 설정되지 않은 HEADERS 또는 PUSH_PROMISE 프레임과 하나 이상의 CONTINUATION 프레임, 단 마지막 CONTINUATION 프레임에 END_HEADERS 플래그가 설정되어 있는 경우.

각 필드 블록은 개별 단위로 처리된다. 필드 블록은 다른 유형의 프레임이나 다른 스트림의 프레임과 교차되지 않는 연속적인 프레임 시퀀스로 전송되어야 한다(MUST). HEADERS 또는 CONTINUATION 프레임 시퀀스의 마지막 프레임에는 END_HEADERS 플래그가 설정되어야 한다. PUSH_PROMISE 또는 CONTINUATION 프레임 시퀀스의 마지막 프레임에도 END_HEADERS 플래그가 설정되어야 한다. 이는 필드 블록이 논리적으로 단일 프레임과 동등하도록 한다.

필드 블록 조각은 HEADERS, PUSH_PROMISE 또는 CONTINUATION 프레임의 프레임 페이로드로만 전송될 수 있다. 이 프레임들은 수신자가 유지하는 압축 컨텍스트를 변경할 수 있는 데이터를 운반하기 때문이다. HEADERS, PUSH_PROMISE 또는 CONTINUATION 프레임을 수신하는 엔드포인트는 프레임을 폐기하더라도 필드 블록을 재조립하고 압축 해제를 수행해야 한다. 수신자가 필드 블록을 압축 해제하지 않으면 연결 오류(섹션 5.4.1)인 COMPRESSION_ERROR로 연결을 종료해야 한다(MUST).

필드 블록의 디코딩 오류는 연결 오류(섹션 5.4.1)인 COMPRESSION_ERROR로 처리되어야 한다(MUST).

4.3.1. 압축 상태

필드 압축은 상태 기반이다. 각 엔드포인트는 연결의 모든 필드 블록을 인코딩하고 디코딩하기 위해 HPACK 인코더 컨텍스트와 HPACK 디코더 컨텍스트를 가진다. RFC 7541의 섹션 4는 동적 테이블을 정의하며, 이는 각 컨텍스트의 주요 상태이다.

동적 테이블은 HPACK 디코더가 설정하는 최대 크기를 가진다. 엔드포인트는 자신의 HPACK 디코더 컨텍스트가 선택한 크기를 SETTINGS_HEADER_TABLE_SIZE 설정을 사용하여 통신한다(자세한 내용은 섹션 6.5.2 참조). 연결이 수립되면 양쪽 엔드포인트의 HPACK 디코더와 인코더의 동적 테이블 크기는 SETTINGS_HEADER_TABLE_SIZE 설정의 초기값인 4,096 바이트로 시작한다.

SETTINGS_HEADER_TABLE_SIZE를 사용해 설정된 최대값의 변경은 엔드포인트가 설정을 확인할 때(섹션 6.5.3) 효력이 발생한다. 해당 엔드포인트의 HPACK 인코더는 디코더가 설정한 최대값까지 임의의 크기로 동적 테이블을 설정할 수 있다. HPACK 인코더는 Dynamic Table Size Update 지시어(RFC 7541 섹션 6.3)로 동적 테이블의 크기를 선언한다.

엔드포인트가 동적 테이블의 최대값을 줄이는 SETTINGS_HEADER_TABLE_SIZE 변경을 확인한 후에는, 그 엔드포인트의 HPACK 인코더는 다음 필드 블록을 동적 테이블을 줄여진 최대값 이하의 크기로 설정하는 Dynamic Table Size Update 지시어로 시작해야 한다(RFC 7541 섹션 4.2 참조). 엔드포인트는 축소 확인 이후에 오는 필드 블록이 적합한 Dynamic Table Size Update 지시어로 시작하지 않으면 연결 오류(섹션 5.4.1)인 COMPRESSION_ERROR로 처리해야 한다(MUST).

5. 스트림과 다중화

"스트림"은 HTTP/2 연결 내에서 클라이언트와 서버 간에 교환되는 독립적인 양방향 프레임 연속입니다. 스트림은 다음과 같은 몇 가지 중요한 특성을 가집니다:

단일 HTTP/2 연결은 여러 개의 동시 열린 스트림을 포함할 수 있으며, 어느 한쪽 엔드포인트가 여러 스트림의 프레임을 교차 전송할 수 있습니다.
스트림은 일방적으로 설정되어 사용할 수 있거나 어느 쪽 엔드포인트에서도 공유할 수 있습니다.
스트림은 어느 쪽 엔드포인트라도 닫을 수 있습니다.
프레임이 전송되는 순서는 중요합니다. 수신자는 프레임을 수신된 순서대로 처리합니다. 특히 HEADERS 및 DATA 프레임의 순서는 의미론적으로 중요합니다.
스트림은 정수로 식별됩니다. 스트림 식별자는 스트림을 시작하는 엔드포인트가 스트림에 할당합니다.

5.1. 스트림 상태

스트림의 수명 주기는 그림 2에 나와 있습니다.

그림 2: 스트림 상태

send:: 해당 엔드포인트가 이 프레임을 전송함
recv:: 해당 엔드포인트가 이 프레임을 수신함
H:: HEADERS 프레임 (암묵적인 CONTINUATION 프레임 포함)
ES:: END_STREAM 플래그
R:: RST_STREAM 프레임
PP:: PUSH_PROMISE 프레임 (암묵적인 CONTINUATION 프레임 포함); 상태 전이는 약속된 스트림에 대해 적용됩니다

이 다이어그램은 스트림 상태 전이와 그 전이에 영향을 주는 프레임 및 플래그만을 보여줍니다. 이 점에서 CONTINUATION 프레임은 상태 전이를 일으키지 않으며, 그것들이 뒤따르는 HEADERS 또는 PUSH_PROMISE의 일부로 간주됩니다. 상태 전이를 위해 END_STREAM 플래그는 그것을 포함하는 프레임과 별개의 이벤트로 처리됩니다; END_STREAM 플래그가 설정된 HEADERS 프레임은 두 번의 상태 전이를 일으킬 수 있습니다.

양쪽 엔드포인트는 스트림 상태에 대해 주관적인 관점을 가지며, 프레임이 전송 중일 때 상태가 다를 수 있습니다. 엔드포인트는 스트림의 생성에 대해 조율하지 않으며; 스트림은 어느 쪽 엔드포인트에 의해서든 일방적으로 생성됩니다. 상태 불일치의 부정적 결과는 RST_STREAM 전송 이후의 "closed" 상태로 제한되며, 이 경우 스트림을 닫은 후에도 잠시 동안 프레임이 수신될 수 있습니다.

스트림은 다음 상태를 가집니다:

idle:

모든 스트림은 "idle" 상태에서 시작합니다.

이 상태에서 다음 전이들이 유효합니다:

클라이언트로서 HEADERS 프레임을 전송하거나 서버로서 HEADERS 프레임을 수신하면 스트림은 "open"이 됩니다. 스트림 식별자는 섹션 5.1.1에서 설명한 대로 선택됩니다. 동일한 HEADERS 프레임은 스트림을 즉시 "half-closed"로 만들 수도 있습니다.
다른 스트림에서 PUSH_PROMISE 프레임을 전송하면 나중에 사용할 식별자가 있는 idle 스트림을 예약합니다. 예약된 스트림의 상태는 "reserved (local)"로 전이됩니다. 오직 서버만 PUSH_PROMISE 프레임을 전송할 수 있습니다.
다른 스트림에서 PUSH_PROMISE 프레임을 수신하면 나중에 사용할 식별자가 있는 idle 스트림이 예약됩니다. 예약된 스트림의 상태는 "reserved (remote)"로 전이됩니다. 오직 클라이언트만 PUSH_PROMISE 프레임을 수신할 수 있습니다.
PUSH_PROMISE 프레임은 idle 스트림에서 전송되는 것이 아니라 Promised Stream ID 필드에서 새로 예약된 스트림을 참조한다는 점에 유의하세요.
더 큰 값의 스트림 식별자를 사용하여 스트림을 열면 해당 스트림은 즉시 "closed" 상태로 전이됩니다; 이 전이는 다이어그램에 표시되지 않습니다.

HEADERS 또는 PRIORITY 이외의 모든 프레임을 이 상태의 스트림에서 수신하는 것은 연결 오류(섹션 5.4.1)로 처리되어야 하며, 오류 유형은 PROTOCOL_ERROR입니다. 이 스트림이 서버에 의해 시작된 경우(섹션 5.1.1 참조), HEADERS 프레임을 수신하는 것도 연결 오류(PROTOCOL_ERROR)로 처리되어야 합니다.

reserved (local):

"reserved (local)" 상태의 스트림은 PUSH_PROMISE 프레임을 전송하여 약속된 스트림입니다. PUSH_PROMISE 프레임은 원격 피어가 시작한 열린 스트림과 연관시켜 idle 스트림을 예약합니다(자세한 내용은 섹션 8.4 참조).

이 상태에서는 다음 전이만 가능합니다:

엔드포인트는 HEADERS 프레임을 전송할 수 있습니다. 이는 스트림을 "half-closed (remote)" 상태로 엽니다.
어느 쪽 엔드포인트도 RST_STREAM 프레임을 전송하여 스트림을 "closed"로 만들 수 있습니다. 이는 스트림 예약을 해제합니다.

이 상태에서 엔드포인트는 HEADERS, RST_STREAM, 또는 PRIORITY 이외의 어떤 종류의 프레임도 전송해서는 안 됩니다(MUST NOT).

PRIORITY 또는 WINDOW_UPDATE 프레임은 이 상태에서 MAY 수신될 수 있습니다. 이 상태의 스트림에서 RST_STREAM, PRIORITY, 또는 WINDOW_UPDATE 이외의 어떤 프레임을 수신하면 연결 오류(섹션 5.4.1)로 처리되어야 하며, 오류 유형은 PROTOCOL_ERROR입니다.

reserved (remote):

"reserved (remote)" 상태의 스트림은 원격 피어에 의해 예약된 스트림입니다.

이 상태에서는 다음 전이만 가능합니다:

HEADERS 프레임을 수신하면 스트림은 "half-closed (local)"로 전이됩니다.
어느 쪽 엔드포인트도 RST_STREAM 프레임을 전송하여 스트림을 "closed"로 만들 수 있습니다. 이는 스트림 예약을 해제합니다.

이 상태에서는 RST_STREAM, WINDOW_UPDATE, 또는 PRIORITY 이외의 프레임을 전송해서는 안 됩니다(MUST NOT).

이 상태의 스트림에서 HEADERS, RST_STREAM, 또는 PRIORITY 이외의 어떤 프레임을 수신하면 연결 오류(섹션 5.4.1)로 처리되어야 하며, 오류 유형은 PROTOCOL_ERROR입니다.

open:

"open" 상태의 스트림은 양쪽 피어가 모든 유형의 프레임을 전송하는 데 사용할 수 있습니다. 이 상태에서 전송하는 쪽은 광고된 스트림 수준 흐름 제어 한도를 준수합니다(섹션 5.2).

이 상태에서 어느 쪽 엔드포인트도 END_STREAM 플래그가 설정된 프레임을 전송할 수 있으며, 이는 스트림을 "half-closed" 상태 중 하나로 전이시킵니다. END_STREAM 플래그를 전송한 쪽은 스트림 상태가 "half-closed (local)"가 되고, END_STREAM 플래그를 수신한 쪽은 스트림 상태가 "half-closed (remote)"가 됩니다.

어느 쪽 엔드포인트도 이 상태에서 RST_STREAM 프레임을 전송하여 즉시 "closed"로 전이시킬 수 있습니다.

half-closed (local):

"half-closed (local)" 상태의 스트림은 WINDOW_UPDATE, PRIORITY, 및 RST_STREAM을 제외한 프레임을 전송하는 데 사용할 수 없습니다.

이 상태는 END_STREAM 플래그가 설정된 프레임을 수신하거나 어느 쪽 피어가 RST_STREAM 프레임을 전송하면 "closed"로 전이됩니다.

이 상태에서는 어떤 유형의 프레임도 수신할 수 있습니다. 수신된 흐름 제어 프레임의 처리를 계속하려면 WINDOW_UPDATE 프레임을 사용하여 흐름 제어 크레딧을 제공하는 것이 필요할 수 있습니다. 이 상태에서는 END_STREAM 플래그가 설정된 프레임이 전송된 후에도 잠시 동안 WINDOW_UPDATE 프레임이 도착할 수 있으며 이를 무시할 수 있습니다.

PRIORITY 프레임은 이 상태에서 수신될 수 있습니다.

half-closed (remote):

"half-closed (remote)" 상태의 스트림은 원격 피어가 더 이상 프레임 전송에 사용하지 않습니다. 이 상태에서 엔드포인트는 수신자 흐름 제어 창을 유지할 의무가 없습니다.

이 상태의 스트림에서 WINDOW_UPDATE, PRIORITY, 또는 RST_STREAM 이외의 추가 프레임을 수신하면 스트림 오류(섹션 5.4.2)로 STREAM_CLOSED 유형의 응답을 해야 합니다(MUST).

"half-closed (remote)" 상태의 스트림은 엔드포인트가 모든 유형의 프레임을 전송하는 데 사용할 수 있습니다. 이 상태에서 엔드포인트는 계속해서 광고된 스트림 수준 흐름 제어 한도를 준수합니다(섹션 5.2).

이 상태의 스트림은 END_STREAM 플래그가 설정된 프레임을 전송하거나 어느 쪽 피어가 RST_STREAM 프레임을 전송하면 "closed"로 전이될 수 있습니다.

closed:

"closed" 상태는 종료 상태입니다.

스트림은 엔드포인트가 END_STREAM 플래그가 설정된 프레임을 전송하고 수신한 후 "closed" 상태에 들어갑니다. 또한 엔드포인트가 RST_STREAM 프레임을 전송하거나 수신한 후에도 "closed" 상태가 됩니다.

엔드포인트는 닫힌 스트림에서 PRIORITY 이외의 프레임을 전송해서는 안 됩니다(MUST NOT). 엔드포인트는 닫힌 스트림에서 다른 유형의 프레임을 수신하는 것을 연결 오류(섹션 5.4.1)인 STREAM_CLOSED로 처리할 수 있습니다(MAY), 아래에 언급된 예외를 제외하고는.

엔드포인트가 END_STREAM 플래그가 설정된 프레임 또는 RST_STREAM 프레임을 전송하면, 피어가 스트림을 닫는 프레임을 수신하고 처리하기 전에 WINDOW_UPDATE 또는 RST_STREAM 프레임을 받을 수 있습니다.

엔드포인트가 "open" 또는 "half-closed (local)" 상태의 스트림에서 RST_STREAM 프레임을 전송하면, 해당 엔드포인트는 원격 피어가 전송했거나 전송 대기열에 넣은 어떤 유형의 프레임도 수신할 준비가 되어 있어야 합니다. 이러한 프레임은 무시할 수 있지만, 필드 섹션 압축(섹션 4.3) 또는 흐름 제어와 같은 연결 상태를 수정하는 경우에는 최소한 처리해야 합니다.

엔드포인트는 "closed" 상태에 있는 모든 스트림에 대해 이러한 최소한의 처리를 수행할 수 있습니다. 엔드포인트는 피어가 스트림을 "closed"로 만들게 한 프레임을 수신했음을 감지하기 위해 다른 신호를 사용할 수 있으며, 그 경우 PRIORITY 이외의 프레임 수신을 연결 오류(섹션 5.4.1)인 PROTOCOL_ERROR로 처리할 수 있습니다. 엔드포인트는 설정에 대한 확인을 받은 후 스트림을 닫은 뒤에 도착한 DATA 프레임을 오류로 처리하는 등, 피어가 닫음 신호를 수신했음을 나타내는 프레임을 사용하여 이를 판별할 수 있습니다. 이 목적을 위해 타이머를 사용하는 것은 권장되지 않습니다(SHOULD NOT). 예로는 닫은 뒤에 SETTINGS 프레임을 전송하고 해당 설정 확인을 받은 후에 오는 DATA 프레임을 오류로 처리하는 것이 있습니다. 다른 신호로는 PING 프레임, 닫은 이후 생성된 스트림에서 오는 데이터 수신, 또는 닫은 이후 생성된 요청에 대한 응답 등이 있습니다.

더 구체적인 규칙이 없는 한, 구현체는 상태 설명에서 명시적으로 허용되지 않은 프레임을 수신하면 연결 오류(섹션 5.4.1)인 PROTOCOL_ERROR로 처리하는 것이 좋습니다(SHOULD). PRIORITY는 어떤 스트림 상태에서도 전송 및 수신될 수 있다는 점을 유의하세요.

이 섹션의 규칙은 이 문서에서 정의된 프레임에만 적용됩니다. 의미가 알려져 있지 않은 프레임의 수신은 오류로 처리할 수 없습니다. 이러한 프레임을 전송하거나 수신하는 조건 역시 알려져 있지 않기 때문입니다; 확장성에 대해서는 섹션 5.5를 참조하세요.

HTTP 요청/응답 교환의 상태 전이 예시는 섹션 8.8에서 찾을 수 있습니다. 서버 푸시의 상태 전이 예시는 8.4.1 및 8.4.2 섹션에서 찾을 수 있습니다.

5.1.1. 스트림 식별자

스트림은 부호 없는 31비트 정수로 식별됩니다. 클라이언트가 시작한 스트림은 홀수 번호의 스트림 식별자를 사용해야 합니다(MUST); 서버가 시작한 스트림은 짝수 번호를 사용해야 합니다(MUST). 스트림 식별자 0(0x00)은 연결 제어 메시지에 사용되며, 새 스트림을 생성하는 데는 사용할 수 없습니다.

새로 생성된 스트림의 식별자는 그 스트림을 시작한 엔드포인트가 열거나 예약한 모든 스트림보다 수치적으로 커야 합니다(MUST). 이는 HEADERS 프레임으로 열리는 스트림과 PUSH_PROMISE로 예약되는 스트림에 적용됩니다. 예상치 못한 스트림 식별자를 수신한 엔드포인트는 연결 오류(섹션 5.4.1)인 PROTOCOL_ERROR로 응답해야 합니다.

HEADERS 프레임은 프레임 헤더의 스트림 식별자로 표시된 클라이언트-시작 스트림을 "idle"에서 "open"으로 전이시킵니다. PUSH_PROMISE 프레임은 프레임 페이로드의 Promised Stream ID 필드로 표시된 서버-시작 스트림을 "idle"에서 "reserved (local)" 또는 "reserved (remote)"로 전이시킵니다. 스트림이 "idle" 상태에서 전이될 때, 피어가 더 낮은 값의 스트림 식별자로 열었을 수도 있는 모든 idle 스트림은 즉시 "closed"로 전이됩니다. 즉, 엔드포인트는 스트림 식별자를 건너뛸 수 있으며, 그 결과로 건너뛴 스트림은 즉시 닫힙니다.

스트림 식별자는 재사용할 수 없습니다. 장기간 연결은 엔드포인트가 사용 가능한 스트림 식별자 범위를 소진하게 만들 수 있습니다. 새 스트림 식별자를 생성할 수 없는 클라이언트는 새 스트림을 위해 새 연결을 설정할 수 있습니다. 새 스트림 식별자를 생성할 수 없는 서버는 클라이언트가 새 스트림을 위해 새 연결을 열도록 강제하기 위해 GOAWAY 프레임을 보낼 수 있습니다.

5.1.2. 스트림 동시성

피어는 SETTINGS_MAX_CONCURRENT_STREAMS 매개변수를 사용하여 동시 활성 스트림 수를 제한할 수 있습니다(자세한 내용은 섹션 6.5.2 참조). 최대 동시 스트림 설정은 각 엔드포인트에 특정하며 설정을 수신하는 피어에만 적용됩니다. 즉, 클라이언트는 서버가 시작할 수 있는 동시 스트림의 최대 수를 지정하고, 서버는 클라이언트가 시작할 수 있는 동시 스트림의 최대 수를 지정합니다.

"open" 상태 또는 두 "half-closed" 상태에 있는 스트림은 엔드포인트가 열 수 있는 최대 스트림 수에 포함됩니다. 이 세 상태 중 어느 하나에 있는 스트림은 SETTINGS_MAX_CONCURRENT_STREAMS 설정에 광고된 한도에 포함됩니다. "reserved" 상태들에 있는 스트림은 스트림 한도에 포함되지 않습니다.

엔드포인트는 피어가 설정한 한도를 초과해서는 안 됩니다(MUST NOT). 광고된 동시 스트림 한도를 초과하게 하는 HEADERS 프레임을 수신한 엔드포인트는 이를 스트림 오류(섹션 5.4.2)인 PROTOCOL_ERROR 또는 REFUSED_STREAM로 처리해야 합니다(MUST). 어떤 오류 코드를 선택하느냐에 따라 엔드포인트가 자동 재시도를 허용할지 여부가 결정됩니다(자세한 내용은 섹션 8.7 참조).

SETTINGS_MAX_CONCURRENT_STREAMS 값을 현재 열린 스트림 수보다 더 낮게 줄이려는 엔드포인트는 초과하는 스트림을 닫거나 스트림이 완료될 때까지 허용할 수 있습니다.

5.2. 흐름 제어

스트림을 사용한 다중화는 TCP 연결 사용에 대한 경쟁을 초래하여 스트림이 블록되는 상황을 만듭니다. 흐름 제어 방식은 동일 연결의 스트림들이 서로 파괴적으로 간섭하지 않도록 보장합니다. 흐름 제어는 개별 스트림과 연결 전체에 대해 사용됩니다.

HTTP/2는 WINDOW_UPDATE 프레임(섹션 6.9)을 사용하여 흐름 제어를 제공합니다.

5.2.1. 흐름 제어 원칙

HTTP/2 스트림 흐름 제어는 프로토콜 변경 없이 다양한 흐름 제어 알고리즘을 사용할 수 있도록 설계되었습니다. HTTP/2 흐름 제어는 다음 특성을 가집니다:

흐름 제어는 연결에 특화되어 있습니다. HTTP/2 흐름 제어는 단일 홉의 엔드포인트들 간에서 작동하며 전체 종단간 경로에 걸치지 않습니다.
흐름 제어는 WINDOW_UPDATE 프레임에 기반합니다. 수신자는 스트림별 및 전체 연결에 대해 수신할 준비가 된 옥텟 수를 광고합니다. 이 방식은 크레딧 기반 스킴입니다.
흐름 제어는 방향성이 있으며 전체 제어는 수신자가 제공합니다. 수신자는 각 스트림과 전체 연결에 대해 원하는 어떤 창 크기든 선택할 수 있습니다(MAY). 전송자는 수신자가 설정한 흐름 제어 한도를 존중해야 합니다(MUST). 클라이언트, 서버 및 중개자는 모두 수신자 역할에서 자신들의 흐름 제어 창을 광고하고 전송 시 피어가 설정한 한도를 준수합니다.
초기 흐름 제어 창 값은 새 스트림과 전체 연결 모두에 대해 65,535 옥텟입니다.
프레임 유형은 흐름 제어가 프레임에 적용되는지 여부를 결정합니다. 이 문서에서 지정된 프레임 중 오직 DATA 프레임만 흐름 제어의 대상이며, 다른 모든 프레임 유형은 광고된 흐름 제어 창의 공간을 소비하지 않습니다. 이는 중요한 제어 프레임이 흐름 제어 때문에 차단되지 않도록 보장합니다.
엔드포인트는 자신의 흐름 제어를 비활성화하도록 선택할 수 있지만, 엔드포인트는 피어의 흐름 제어 신호를 무시할 수 없습니다.
HTTP/2는 WINDOW_UPDATE 프레임의 형식과 의미만 정의합니다(섹션 6.9). 수신자가 언제 이 프레임을 보낼지 또는 어떤 값을 보낼지를 결정하는 방법, 또는 전송자가 언제 패킷을 전송할지를 선택하는 방법은 이 문서에서 규정하지 않습니다. 구현체는 자신들의 필요에 맞는 알고리즘을 선택할 수 있습니다.

구현체는 또한 요청 및 응답 전송의 우선순위를 정하고, 요청의 헤드-오브-라인 블로킹을 피하는 방법을 선택하며, 새 스트림 생성 관리를 책임집니다. 이러한 알고리즘 선택은 어떤 흐름 제어 알고리즘과 상호작용할 수 있습니다.

5.2.2. 흐름 제어의 적절한 사용

흐름 제어는 자원 제약 하에 운영되는 엔드포인트를 보호하기 위해 정의되었습니다. 예를 들어, 프록시는 많은 연결 간에 메모리를 공유해야 하고 업스트림 연결은 느리고 다운스트림은 빠를 수 있습니다. 흐름 제어는 수신자가 어떤 스트림의 데이터를 처리할 수 없지만 동일 연결의 다른 스트림 처리는 계속하고자 하는 경우를 다룹니다.

이 기능이 필요하지 않은 배포환경은 최대 크기(2³¹-1)의 흐름 제어 창을 광고하고, 어떤 데이터가 수신될 때마다 WINDOW_UPDATE 프레임을 보내어 이 창을 유지할 수 있습니다. 이는 사실상 그 수신자에 대해 흐름 제어를 비활성화합니다. 반대로 전송자는 항상 수신자가 광고한 흐름 제어 창의 영향을 받습니다.

제한된 자원(예: 메모리)을 가진 배포 환경은 피어가 소비할 수 있는 메모리 양을 제한하기 위해 흐름 제어를 사용할 수 있습니다. 다만, 흐름 제어가 대역폭 * 지연 곱을 모른 채 활성화되면 사용 가능한 네트워크 자원을 비최적으로 사용할 수 있음을 유의하세요(자세한 내용은 [RFC7323] 참조).

대역폭 * 지연 곱을 완전히 인지하고 있더라도 흐름 제어 구현은 어려울 수 있습니다. 엔드포인트는 데이터가 사용 가능해지는 즉시 TCP 수신 버퍼에서 HTTP/2 프레임을 읽고 처리해야 합니다(MUST). 적시에 읽지 못하면 WINDOW_UPDATE와 같은 중요한 프레임이 읽히고 처리되지 않아 교착 상태가 발생할 수 있습니다. 프레임을 신속히 읽는 것은 HTTP/2 흐름 제어가 자원 약탈 공격으로부터 엔드포인트를 노출시키지 않으므로 자원 소진 공격에 취약하게 만들지 않습니다.

5.2.3. 흐름 제어 성능

엔드포인트가 피어가 이 연결에서 항상 피어의 대역폭 * 지연 곱보다 큰 사용 가능한 흐름 제어 창 공간을 가지도록 보장할 수 없다면, 그 수신 처리량은 HTTP/2 흐름 제어에 의해 제한됩니다. 이는 성능 저하로 이어집니다.

적시에 WINDOW_UPDATE 프레임을 전송하면 성능을 향상시킬 수 있습니다. 엔드포인트는 수신 처리량 개선의 필요성과 자원 소진 위험 관리를 균형 있게 해야 하며, 창 크기를 관리하는 전략을 정의할 때 섹션 10.5를 주의 깊게 고려해야 합니다.

5.3. 우선순위 지정

HTTP/2와 같은 다중화된 프로토콜에서는 스트림에 대역폭과 계산 자원을 우선 배분하는 것이 성능 향상에 결정적일 수 있습니다. 잘못된 우선순위 지정 방식은 HTTP/2가 성능이 낮아지게 만들 수 있습니다. TCP 계층에 병렬성이 전혀 없다면, 성능은 HTTP/1.1보다 상당히 나쁠 수 있습니다.

좋은 우선순위 지정 방식은 리소스의 내용, 리소스 간의 관계, 피어가 해당 리소스를 어떻게 사용할지와 같은 문맥적 지식을 적용하면 이점을 얻습니다. 특히 클라이언트는 서버 우선순위 지정에 관련된 요청 우선순위에 관한 지식을 가질 수 있습니다. 이런 경우 클라이언트가 우선순위 정보를 제공하는 것이 성능을 향상시킬 수 있습니다.

5.3.1. RFC 7540의 우선순위 배경

RFC 7540는 요청 우선순위를 신호하는 풍부한 시스템을 정의했습니다. 그러나 이 시스템은 복잡하게 판명되었고, 일관되게 구현되지 않았습니다.

유연한 스킴은 클라이언트가 매우 다양한 방식으로 우선순위를 표현하게 했고, 채택된 접근 방식 사이에 일관성이 거의 없었습니다. 서버에게는 이 스킴에 대한 일반적 지원을 구현하는 것이 복잡했습니다. 클라이언트와 서버 모두에서 우선순위의 구현은 고르지 않았습니다. 많은 서버 배포는 요청 처리에서 클라이언트 신호를 무시했습니다.

요약하면, RFC 7540의 우선순위 신호는 성공적이지 못했습니다.

5.3.2. 이 문서에서의 우선순위 신호

이 HTTP/2 업데이트는 RFC 7540에 정의된 우선순위 신호를 사용 중단(deprecate)합니다. 우선순위 신호와 관련된 본문의 대부분은 이 문서에 포함되지 않습니다. 하지만 이 문서의 구현체가 RFC 7540에서 설명된 우선순위 신호를 사용하는 구현체와 상호운용성을 유지할 수 있도록 일부 프레임 필드 설명과 필수 처리 사항은 유지됩니다.

RFC 7540 우선순위 스킴에 대한 자세한 설명은 RFC 7540의 섹션 5.3에 남아 있습니다.

우선순위 정보를 신호하는 것은 많은 경우에 좋은 성능을 얻기 위해 필요합니다. 우선순위 신호가 중요한 경우, 엔드포인트는 [HTTP-PRIORITY]에 설명된 것과 같은 대체 스킴 사용을 권장합니다.

비록 RFC 7540의 우선순위 신호가 널리 채택되지는 않았지만, 그것이 제공하는 정보는 더 나은 대안이 없는 상황에서는 여전히 유용할 수 있습니다. HEADERS나 PRIORITY 프레임에서 우선순위 신호를 수신하는 엔드포인트는 그 정보를 적용함으로써 이익을 얻을 수 있습니다. 특히 이러한 신호를 소비하는 구현체는 대안이 없을 때 이 우선순위 신호를 버리는 것에서 이익을 얻지 못할 것입니다.

서버는 우선순위 신호가 전혀 없는 경우 요청 우선순위를 결정할 때 다른 문맥 정보를 사용하는 것이 좋습니다(SHOULD). 서버는 신호가 전혀 없는 것을 클라이언트가 해당 기능을 구현하지 않았다는 표시로 해석할 수 있습니다(MAY). RFC 7540의 섹션 5.3.5에 설명된 기본값은 대부분의 조건에서 성능이 좋지 않은 것으로 알려져 있으며, 이를 의도적으로 사용하는 경우는 드뭅니다.

5.4. 오류 처리

HTTP/2 프레이밍은 두 가지 범주의 오류를 허용합니다:

전체 연결을 사용 불가능하게 만드는 오류 조건은 연결 오류입니다.
개별 스트림의 오류는 스트림 오류입니다.

오류 코드 목록은 섹션 7에 포함되어 있습니다.

엔드포인트가 처리 중에 여러 오류를 발견할 수 있습니다. 구현체는 처리 중 여러 오류를 발견할 수 있지만(MAY) 결과로 보고하는 것은 스트림 오류 하나와 연결 오류 하나로 제한하는 것이 좋습니다(SHOULD).

주어진 스트림에 대해 보고된 첫 번째 스트림 오류는 그 스트림에서 다른 오류들이 보고되는 것을 방지합니다. 비교적 프로토콜은 여러 개의 GOAWAY 프레임을 허용하지만, 엔드포인트는 우아한 종료 중에 오류가 발생하지 않는 한 보통 한 종류의 연결 오류만 보고하는 것이 좋습니다(SHOULD). 만약 종료 중에 오류가 발생하면, 엔드포인트는 이전에 NO_ERROR를 포함한 GOAWAY와 더불어 새로운 오류 코드를 가진 추가 GOAWAY 프레임을 보낼 수 있습니다(MAY).

엔드포인트가 여러 다른 오류를 감지하면 그 중 하나를 선택하여 보고할 수 있습니다(MAY). 만약 프레임이 연결 오류를 유발하면 그 오류는 반드시 보고되어야 합니다(MUST). 추가로, 엔드포인트는 오류 조건을 감지할 때 적용 가능한 어떤 오류 코드도 사용할 수 있습니다; 일반 오류 코드(예: PROTOCOL_ERROR 또는 INTERNAL_ERROR)는 더 구체적인 오류 코드 대신 항상 사용할 수 있습니다.

5.4.1. 연결 오류 처리

연결 오류는 프레임 계층의 추가 처리를 방해하거나 어떤 연결 상태를 손상시키는 모든 오류입니다.

연결 오류를 만난 엔드포인트는 먼저 피어로부터 마지막으로 성공적으로 수신한 스트림 식별자를 포함한 GOAWAY 프레임을 보내는 것이 좋습니다(SHOULD). GOAWAY 프레임은 연결이 종료되는 이유를 나타내는 오류 코드(섹션 7)를 포함합니다. 오류 조건에 대해 GOAWAY 프레임을 전송한 후에는 엔드포인트가 TCP 연결을 닫아야 합니다(MUST).

GOAWAY가 수신 엔드포인트에 신뢰성 있게 도달하지 않을 수 있다는 점에 유의하세요. 연결 오류가 발생한 경우 GOAWAY는 피어에게 연결이 종료되는 이유를 알리려는 최선의 시도일 뿐입니다.

엔드포인트는 언제든지 연결을 종료할 수 있습니다. 특히, 엔드포인트는 스트림 오류를 연결 오류로 처리할 수 있습니다(MAY). 엔드포인트는 상황이 허락한다면 연결을 끝낼 때 GOAWAY 프레임을 보내는 것이 좋습니다(SHOULD).

5.4.2. 스트림 오류 처리

스트림 오류는 다른 스트림의 처리를 방해하지 않는 특정 스트림과 관련된 오류입니다.

스트림 오류를 감지한 엔드포인트는 오류가 발생한 스트림의 식별자를 포함하는 RST_STREAM 프레임을 전송합니다(섹션 6.4). RST_STREAM 프레임은 오류 유형을 나타내는 오류 코드를 포함합니다.

RST_STREAM은 엔드포인트가 스트림에서 보낼 수 있는 마지막 프레임입니다. RST_STREAM 프레임을 전송한 피어는 원격 피어가 전송했거나 전송 대기열에 올려둔 프레임들을 수신할 준비가 되어 있어야 합니다. 이러한 프레임은 무시할 수 있지만, 필드 섹션 압축 상태(섹션 4.3)나 흐름 제어와 같이 연결 상태를 변경하는 경우에는 예외입니다.

보통 엔드포인트는 어떤 스트림에 대해서도 RST_STREAM 프레임을 두 번 이상 전송해서는 안 됩니다(SHOULD NOT). 그러나 엔드포인트는 닫힌 스트림에서 프레임을 라운드 트립 시간 이상 수신하면 추가 RST_STREAM 프레임을 보낼 수 있습니다(MAY). 이 동작은 잘못 동작하는 구현체를 다루기 위해 허용됩니다.

루프를 피하기 위해 엔드포인트는 RST_STREAM에 대한 응답으로 다시 RST_STREAM을 보내서는 안 됩니다(MUST NOT).

5.4.3. 연결 종료

스트림이 "open" 또는 "half-closed" 상태로 남아 있는 동안 TCP 연결이 닫히거나 리셋되면, 영향을 받은 스트림은 자동으로 재시도할 수 없습니다(자세한 내용은 섹션 8.7 참조).

5.5. HTTP/2 확장

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

이것은 이 문서에 정의된 프로토콜 요소에 적용됩니다. 이는 새로운 메서드, 상태 코드 또는 필드 정의와 같은 기존의 HTTP 확장 옵션에는 영향을 주지 않습니다(자세한 내용은 RFC 9110의 섹션 16 참조).

확장은 새로운 프레임 유형(섹션 4.1), 새로운 설정(섹션 6.5), 또는 새로운 오류 코드(섹션 7)를 사용할 수 있습니다. 이러한 확장 지점 관리를 위한 레지스트리는 RFC 7540의 섹션 11에 정의되어 있습니다.

구현체는 확장 가능한 프로토콜 요소의 알려지지 않았거나 지원되지 않는 값을 무시해야 합니다(MUST). 구현체는 알려지지 않았거나 지원되지 않는 유형의 프레임을 폐기해야 합니다(MUST). 이는 이러한 확장 지점들이 사전 합의나 협상 없이 확장에 의해 안전하게 사용될 수 있음을 의미합니다. 다만, 필드 블록(섹션 4.3)의 중간에 나타나는 확장 프레임은 허용되지 않으며; 이러한 경우 연결 오류(섹션 5.4.1)인 PROTOCOL_ERROR로 처리되어야 합니다(MUST).

확장은 이 문서에 정의된 프로토콜 요소 또는 확장 메커니즘이 정의되지 않은 요소를 변경하는 것을 피해야 합니다(SHOULD). 여기에는 프레임 레이아웃 변경, 프레임이 HTTP 메시지로 구성되는 방식의 추가 또는 변경(섹션 8.1), 의사-헤더 필드 정의 변경, 또는 호환 엔드포인트가 연결 오류로 처리할 수 있는 어떤 프로토콜 요소의 변경이 포함됩니다.

기존 프로토콜 요소나 상태를 변경하는 확장은 사용되기 전에 협상되어야 합니다(MUST). 예를 들어, HEADERS 프레임의 레이아웃을 변경하는 확장은 피어가 이를 허용한다는 긍정적 신호를 줄 때까지 사용할 수 없습니다. 이 경우 수정된 레이아웃이 언제 효력을 발생하는지 조율할 필요가 있을 수 있습니다. 예로, DATA 프레임 이외의 프레임을 흐름 제어 대상으로 취급하려면 양쪽 엔드포인트가 이해해야 하는 의미 변경이 필요하므로, 이는 협상을 통해서만 가능할 것입니다.

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

6. 프레임 정의

이 명세서는 고유한 8비트 타입 코드로 식별되는 여러 프레임 유형을 정의한다. 각 프레임 유형은 연결 전체나 개별 스트림의 설정 및 관리에서 각각 다른 목적을 수행한다.

특정 프레임 유형의 전송은 연결 상태를 변경할 수 있다. 엔드포인트가 연결 상태에 대해 동기화된 관점을 유지하지 못하면 연결 내에서의 성공적인 통신이 더 이상 불가능해진다. 따라서 엔드포인트가 어떤 프레임의 사용이 상태에 어떤 영향을 미치는지에 대해 공동으로 이해하는 것이 중요하다.

6.1. DATA

DATA 프레임(type=0x00)은 스트림과 연관된 임의의 가변 길이 옥텟 시퀀스를 전달한다. 예를 들어 하나 이상의 DATA 프레임은 HTTP 요청 또는 응답 메시지의 본문을 운반하는 데 사용된다.

DATA 프레임은 패딩을 포함할 MAY 있다. 패딩은 메시지 크기를 숨기기 위해 DATA 프레임에 추가될 수 있다. 패딩은 보안 기능이다; 자세한 내용은 섹션 10.7을 참조하라.

DATA Frame {
  Length (24),
  Type (8) = 0x00,

  Unused Flags (4),
  PADDED Flag (1),
  Unused Flags (2),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Data (..),
  Padding (..2040),
}

그림 3: DATA 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. DATA 프레임은 다음의 추가 필드를 포함한다:

Pad Length:: 프레임 패딩의 길이를 옥텟 단위로 담는 8비트 필드이다. 이 필드는 PADDED 플래그가 설정된 경우에만 존재한다.
Data:: 애플리케이션 데이터. 데이터의 양은 존재하는 다른 필드들의 길이를 제외한 프레임 페이로드의 나머지이다.
Padding:: 애플리케이션 의미를 가지지 않는 패딩 옥텟들. 전송 시 패딩 옥텟은 MUST 0으로 설정되어야 한다. 수신자는 패딩을 검증할 의무는 없지만, 비영(非零) 패딩을 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리할 MAY 있다.

DATA 프레임은 다음과 같은 플래그를 정의한다:

PADDED (0x08):: 설정되면 PADDED 플래그는 Pad Length 필드와 그가 설명하는 패딩이 존재함을 나타낸다.
END_STREAM (0x01):: 설정되면 END_STREAM 플래그는 이 프레임이 식별된 스트림에 대해 엔드포인트가 전송할 마지막 프레임임을 나타낸다. 이 플래그를 설정하면 스트림은 "half-closed" 상태 중 하나 또는 "closed" 상태로 전이된다(섹션 5.1).

DATA 프레임은 반드시 스트림과 연관되어야 한다. Stream Identifier 필드가 0x00인 DATA 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

DATA 프레임은 흐름 제어의 대상이며 스트림이 "open" 또는 "half-closed (remote)" 상태일 때만 전송될 수 있다. 전체 DATA 프레임 페이로드는 Pad Length 및 Padding 필드가 존재하는 경우 이를 포함하여 흐름 제어에 포함된다. 스트림이 "open" 또는 "half-closed (local)" 상태가 아닌 스트림의 DATA 프레임을 수신하면 수신자는 섹션 5.4.2에 규정된 STREAM_CLOSED 유형의 스트림 오류로 응답해야 한다(MUST).

패딩 옥텟의 총 수는 Pad Length 필드의 값으로 결정된다. 패딩의 길이가 프레임 페이로드의 길이 이상인 경우 수신자는 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

6.2. HEADERS

HEADERS 프레임(type=0x01)은 스트림을 열기 위해 사용되며(섹션 5.1) 필드 블록 조각을 함께 운반한다. 이름과 달리 HEADERS 프레임은 헤더 섹션 또는 트레일러 섹션을 운반할 수 있다. HEADERS 프레임은 스트림이 "idle", "reserved (local)", "open" 또는 "half-closed (remote)" 상태일 때 전송될 수 있다.

HEADERS Frame {
  Length (24),
  Type (8) = 0x01,

  Unused Flags (2),
  PRIORITY Flag (1),
  Unused Flag (1),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flag (1),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  [Exclusive (1)],
  [Stream Dependency (31)],
  [Weight (8)],
  Field Block Fragment (..),
  Padding (..2040),
}

그림 4: HEADERS 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. HEADERS 프레임 페이로드에는 다음과 같은 추가 필드가 있다:

Pad Length:: 프레임 패딩의 길이를 옥텟 단위로 담는 8비트 필드이다. 이 필드는 PADDED 플래그가 설정된 경우에만 존재한다.
Exclusive:: 단일 비트 플래그. 이 필드는 PRIORITY 플래그가 설정된 경우에만 존재한다. HEADERS 프레임의 우선순위 신호는 사용 중단되었다; 자세한 내용은 섹션 5.3.2를 보라.
Stream Dependency:: 31비트 스트림 식별자. 이 필드는 PRIORITY 플래그가 설정된 경우에만 존재한다.
Weight:: 부호 없는 8비트 정수. 이 필드는 PRIORITY 플래그가 설정된 경우에만 존재한다.
Field Block Fragment:: 필드 블록 조각(섹션 4.3).
Padding:: 애플리케이션 의미를 가지지 않는 패딩 옥텟들. 전송 시 패딩 옥텟은 MUST 0으로 설정되어야 한다. 수신자는 패딩을 검증할 의무는 없지만, 비영(非零) 패딩을 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리할 MAY 있다.

HEADERS 프레임은 다음과 같은 플래그를 정의한다:

PRIORITY (0x20):: 설정되면 PRIORITY 플래그는 Exclusive, Stream Dependency 및 Weight 필드가 존재함을 나타낸다.
PADDED (0x08):: 설정되면 PADDED 플래그는 Pad Length 필드와 그가 설명하는 패딩이 존재함을 나타낸다.
END_HEADERS (0x04):: 설정되면 END_HEADERS 플래그는 이 프레임이 전체 필드 블록(섹션 4.3)을 포함하며 뒤따르는 CONTINUATION 프레임이 없음을 나타낸다.

END_HEADERS 플래그가 설정되지 않은 HEADERS 프레임은 동일한 스트림에 대한 CONTINUATION 프레임으로 뒤따라야 한다. 수신자는 다른 유형의 프레임이나 다른 스트림의 프레임을 수신하면 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).
END_STREAM (0x01):: 설정되면 END_STREAM 플래그는 이 필드 블록(섹션 4.3)이 식별된 스트림에 대해 엔드포인트가 전송할 마지막 것임을 나타낸다.

END_STREAM 플래그가 설정된 HEADERS 프레임은 스트림의 종료를 신호한다. 다만 END_STREAM 플래그가 설정된 HEADERS 프레임에 이어 동일한 스트림에 대해 CONTINUATION 프레임이 올 수 있다. 논리적으로는 CONTINUATION 프레임은 HEADERS 프레임의 일부이다.

HEADERS 프레임의 프레임 페이로드는 필드 블록 조각(섹션 4.3)을 포함한다. HEADERS 프레임에 맞지 않는 필드 블록은 CONTINUATION 프레임(섹션 6.10)에서 계속된다.

HEADERS 프레임은 반드시 스트림과 연관되어야 한다. Stream Identifier 필드가 0x00인 HEADERS 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

HEADERS 프레임은 섹션 4.3에 설명된 대로 연결 상태를 변경한다.

6.3. PRIORITY

PRIORITY 프레임(type=0x02)은 사용 중단(deprecated)되었다; 자세한 내용은 섹션 5.3.2를 보라. PRIORITY 프레임은 idle 또는 closed 스트림을 포함하여 어떤 스트림 상태에서도 전송될 수 있다.

PRIORITY Frame {
  Length (24) = 0x05,
  Type (8) = 0x02,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Exclusive (1),
  Stream Dependency (31),
  Weight (8),
}

그림 5: PRIORITY 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. PRIORITY 프레임의 페이로드는 다음의 추가 필드를 포함한다:

Exclusive:: 단일 비트 플래그.
Stream Dependency:: 31비트 스트림 식별자.
Weight:: 부호 없는 8비트 정수.

PRIORITY 프레임은 어떤 플래그도 정의하지 않는다.

PRIORITY 프레임은 항상 스트림을 식별한다. Stream Identifier가 0x00인 PRIORITY 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

PRIORITY 프레임의 전송 또는 수신은 어떤 스트림의 상태에도 영향을 미치지 않는다(섹션 5.1). PRIORITY 프레임은 "idle" 또는 "closed"를 포함한 어떤 상태의 스트림에서도 전송될 수 있다. PRIORITY 프레임은 단일 필드 블록을 구성하는 연속된 프레임들 사이에 전송되어서는 안 된다(섹션 4.3).

길이가 5 옥텟이 아닌 PRIORITY 프레임은 섹션 5.4.2에 규정된 FRAME_SIZE_ERROR 유형의 스트림 오류로 처리되어야 한다(MUST).

6.4. RST_STREAM

RST_STREAM 프레임(type=0x03)은 스트림을 즉시 종료할 수 있게 해 준다. RST_STREAM은 스트림 취소를 요청하거나 오류 조건이 발생했음을 알리기 위해 전송된다.

RST_STREAM Frame {
  Length (24) = 0x04,
  Type (8) = 0x03,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Error Code (32),
}

그림 6: RST_STREAM 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. 추가로 RST_STREAM 프레임은 오류 코드를 식별하는 부호 없는 32비트 정수 하나를 포함한다(섹션 7). 오류 코드는 스트림이 종료되는 이유를 나타낸다.

RST_STREAM 프레임은 어떤 플래그도 정의하지 않는다.

RST_STREAM 프레임은 참조된 스트림을 완전히 종료시키고 해당 스트림을 "closed" 상태로 만든다. 스트림에서 RST_STREAM을 수신한 후 수신자는 해당 스트림에 대해 추가 프레임을 전송해서는 안 된다(MUST NOT), 단 PRIORITY는 예외이다. 그러나 RST_STREAM을 전송한 후 전송한 엔드포인트는 RST_STREAM 도착 전에 피어가 전송했거나 전송 대기열에 올려둔 추가 프레임을 수신하고 처리할 준비를 MUST 해야 한다.

RST_STREAM 프레임은 반드시 스트림과 연관되어야 한다. Stream Identifier가 0x00인 RST_STREAM 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

RST_STREAM 프레임은 "idle" 상태의 스트림에 대해 전송해서는 MUST NOT 한다. "idle" 스트림을 식별하는 RST_STREAM 프레임을 수신하면 수신자는 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

길이가 4 옥텟이 아닌 RST_STREAM 프레임은 섹션 5.4.1에 규정된 FRAME_SIZE_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).

6.5. SETTINGS

SETTINGS 프레임(type=0x04)은 피어 동작의 선호도 및 제약과 같이 엔드포인트 간 통신 방식에 영향을 미치는 구성 매개변수를 전달한다. 또한 SETTINGS 프레임은 이러한 설정의 수신을 확인하는 데 사용된다. SETTINGS 프레임의 개별 구성 매개변수는 "setting"이라고 불린다.

설정은 협상되는 것이 아니라 전송자 피어의 특성을 설명하며 수신 피어가 사용한다. 동일한 설정에 대해 서로 다른 값을 각 피어가 광고할 수 있다. 예를 들어, 클라이언트는 높은 초기 흐름 제어 창을 설정할 수 있고, 서버는 자원 보존을 위해 더 낮은 값을 설정할 수 있다.

SETTINGS 프레임은 연결 시작 시 양쪽 엔드포인트가 MUST 전송해야 하며, 연결 생애주기 중 다른 시점에 어느 쪽 엔드포인트든 전송할 수 있다(MAY). 구현체는 이 명세서에서 정의한 모든 설정을 지원해야 한다(MUST).

SETTINGS 프레임의 각 매개변수는 해당 매개변수의 기존 값을 대체한다. 설정은 표시되는 순서대로 처리되며, SETTINGS 프레임의 수신자는 각 설정의 현재 값 외에는 어떤 상태도 유지할 필요가 없다. 따라서 SETTINGS 매개변수의 값은 수신자가 마지막으로 본 값이다.

SETTINGS 프레임은 수신 피어에 의해 확인된다. 이를 위해 SETTINGS 프레임은 ACK 플래그를 정의한다:

ACK (0x01):: 설정되면 ACK 플래그는 이 프레임이 피어의 SETTINGS 프레임 수신 및 적용을 확인함을 나타낸다. 이 비트가 설정되면 SETTINGS 프레임의 페이로드는 MUST 비어 있어야 한다. ACK 플래그가 설정된 SETTINGS 프레임을 길이 필드 값이 0이 아닌 상태로 수신하면 수신자는 섹션 5.4.1에 규정된 FRAME_SIZE_ERROR 유형의 연결 오류로 처리해야 한다. 자세한 내용은 섹션 6.5.3("Settings Synchronization")을 보라.

SETTINGS 프레임은 항상 연결에 적용되며, 단일 스트림에는 적용되지 않는다. SETTINGS 프레임의 Stream Identifier 필드는 0(0x00)이어야 한다(MUST). Stream Identifier 필드가 0x00이 아닌 SETTINGS 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

SETTINGS 프레임은 연결 상태에 영향을 준다. 잘못 형성되었거나 불완전한 SETTINGS 프레임은 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).

길이가 6 옥텟의 배수가 아닌 SETTINGS 프레임은 섹션 5.4.1에 규정된 FRAME_SIZE_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).

6.5.1. SETTINGS 형식

SETTINGS 프레임의 페이로드는 16비트 설정 식별자와 32비트 값으로 구성된 0개 이상의 설정들로 이루어진다.

SETTINGS Frame {
  Length (24),
  Type (8) = 0x04,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Setting (48) ...,
}

Setting {
  Identifier (16),
  Value (32),
}

그림 7: SETTINGS 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. SETTINGS 프레임의 페이로드는 임의 개수의 Setting 필드를 포함하며, 각 Setting 필드는 다음으로 구성된다:

Identifier:: 16비트 설정 식별자; 섹션 6.5.2 참조.
Value:: 설정에 대한 32비트 값.

6.5.2. 정의된 설정

다음의 설정들이 정의되어 있다:

SETTINGS_HEADER_TABLE_SIZE (0x01):: 이 설정은 송신자가 필드 블록을 디코딩하는 데 사용하는 압축 테이블의 최대 크기를 옥텟 단위로 원격 엔드포인트에 알릴 수 있게 한다. 인코더는 이 값 이하의 임의 크기를 압축 형식 내부의 신호를 사용하여 선택할 수 있다(자세한 내용은 [COMPRESSION] 참조). 초기 값은 4,096 옥텟이다.
SETTINGS_ENABLE_PUSH (0x02):: 이 설정은 서버 푸시를 활성화하거나 비활성화하는 데 사용될 수 있다. 서버는 이 파라미터가 0으로 설정된 경우 PUSH_PROMISE 프레임을 전송해서는 안 된다(MUST NOT); 자세한 내용은 섹션 8.4를 보라. 클라이언트가 이 파라미터를 0으로 설정하고 이를 확인받았다면, PUSH_PROMISE 프레임을 수신하는 것을 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

SETTINGS_ENABLE_PUSH의 초기 값은 1이다. 클라이언트에게 이 값은 PUSH_PROMISE 프레임을 수신하길 원함을 나타낸다. 서버에 대해서는 이 초기 값은 효과가 없으며 값 0과 동등하다. 0 또는 1 이외의 값은 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

서버는 이 값을 명시적으로 1로 설정해서는 안 된다(MUST NOT). 서버는 SETTINGS 프레임을 보낼 때 이 설정을 생략할 수 있으며, 포함한다면 그 값은 MUST 0이어야 한다. 클라이언트는 SETTINGS_ENABLE_PUSH가 1로 설정된 SETTINGS 프레임을 수신하면 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).
SETTINGS_MAX_CONCURRENT_STREAMS (0x03):: 이 설정은 송신자가 허용할 최대 동시 스트림 수를 나타낸다. 이 제한은 방향성적이며, 송신자가 수신자가 생성할 수 있도록 허용하는 스트림 수에 적용된다. 초기에는 이 값에 제한이 없다. 병렬성을 불필요하게 제한하지 않기 위해 이 값을 100보다 작게 설정하지 않는 것이 권장된다.

SETTINGS_MAX_CONCURRENT_STREAMS의 값이 0인 경우 엔드포인트는 이를 특별하게 처리해서는 안 된다(SHOULD NOT). 0 값은 새로운 스트림 생성 자체를 방지하긴 하지만, 활성 스트림으로 소진되는 다른 어떤 제한에서도 동일한 현상이 발생할 수 있다. 서버는 짧은 기간 동안만 0을 설정해야 한다(SHOULD); 만약 서버가 요청을 수락하고 싶지 않다면 연결을 닫는 것이 더 적절하다.
SETTINGS_INITIAL_WINDOW_SIZE (0x04):: 이 설정은 스트림 수준 흐름 제어를 위한 송신자의 초기 창 크기(옥텟 단위)를 나타낸다. 초기 값은 2¹⁶-1(65,535) 옥텟이다.

이 설정은 모든 스트림의 창 크기에 영향을 준다(자세한 내용은 섹션 6.9.2 참조).

2³¹-1을 초과하는 값은 섹션 5.4.1에 규정된 FLOW_CONTROL_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).
SETTINGS_MAX_FRAME_SIZE (0x05):: 이 설정은 송신자가 수신할 의향이 있는 최대 프레임 페이로드 크기를 옥텟 단위로 나타낸다.

초기 값은 2¹⁴(16,384) 옥텟이다. 엔드포인트가 광고하는 값은 초기 값과 허용되는 최대 프레임 크기(2²⁴-1 또는 16,777,215 옥텟) 사이여야 하며 포함된다. 이 범위를 벗어난 값은 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).
SETTINGS_MAX_HEADER_LIST_SIZE (0x06):: 이 권고 설정은 송신자가 수신할 준비가 된 최대 필드 섹션 크기를 옥텟 단위로 피어에게 알린다. 값은 필드 라인의 비압축 크기를 기준으로 하며, 이름과 값의 길이(옥텟 단위)와 각 필드 라인에 대해 32 옥텟의 오버헤드를 더한 것이다.

특정 요청에 대해 광고된 값보다 더 낮은 한도를 강제할 MAY 있다. 이 설정의 초기 값은 무제한이다.

알려지지 않았거나 지원되지 않는 식별자를 가진 SETTINGS 프레임을 수신한 엔드포인트는 해당 설정을 무시해야 한다(MUST).

6.5.3. 설정 동기화

대부분의 SETTINGS 값은 피어가 변경된 매개변수 값을 수신하고 적용했을 때를 이해하는 것이 유익하거나 필요하다. 이러한 동기화 시점을 제공하기 위해, ACK 플래그가 설정되지 않은 SETTINGS 프레임의 수신자는 가능한 한 빨리 업데이트된 설정을 적용해야 한다(MUST). SETTINGS 프레임은 수신된 순서대로 확인된다.

SETTINGS 프레임의 값들은 다른 값 처리가 개입되지 않은 채 표시된 순서대로 처리되어야 한다(MUST). 지원되지 않는 설정은 무시되어야 한다(MUST). 모든 값이 처리된 후 수신자는 즉시 ACK 플래그가 설정된 SETTINGS 프레임을 전송해야 한다(MUST). ACK 플래그가 설정된 SETTINGS 프레임을 수신하면 변경된 설정을 전송한 쪽은 가장 오래된 미확인 SETTINGS 프레임의 값이 적용되었음을 신뢰할 수 있다.

발신자가 합리적인 시간 내에 확인을 받지 못하면 섹션 5.4.1에 규정된 SETTINGS_TIMEOUT 유형의 연결 오류를 발생시킬 MAY 있다. 타임아웃을 설정할 때 피어의 처리 지연을 고려해야 한다; 단지 엔드포인트 간 왕복 시간만을 근거로 한 타임아웃은 잘못된 오류를 초래할 수 있다.

6.6. PUSH_PROMISE

PUSH_PROMISE 프레임(type=0x05)은 송신자가 시작할 의도가 있는 스트림을 미리 피어에게 알리기 위해 사용된다. PUSH_PROMISE 프레임은 엔드포인트가 생성할 계획인 스트림의 부호 없는 31비트 식별자와 해당 스트림에 대한 추가 문맥을 제공하는 필드 섹션을 포함한다. PUSH_PROMISE 프레임의 사용에 대한 자세한 설명은 섹션 8.4에 있다.

PUSH_PROMISE Frame {
  Length (24),
  Type (8) = 0x05,

  Unused Flags (4),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Reserved (1),
  Promised Stream ID (31),
  Field Block Fragment (..),
  Padding (..2040),
}

그림 8: PUSH_PROMISE 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. PUSH_PROMISE 프레임 페이로드에는 다음과 같은 추가 필드가 있다:

Pad Length:: 프레임 패딩의 길이를 옥텟 단위로 담는 8비트 필드이다. 이 필드는 PADDED 플래그가 설정된 경우에만 존재한다.
Promised Stream ID:: PUSH_PROMISE에 의해 예약된 스트림을 식별하는 부호 없는 31비트 정수이다. 약속된 스트림 식별자는 송신자가 다음에 전송할 새 스트림에 대한 유효한 선택이어야 한다(섹션 5.1.1의 "new stream identifier" 참조)(MUST).
Field Block Fragment:: 요청 제어 데이터와 헤더 섹션을 포함하는 필드 블록 조각(섹션 4.3).
Padding:: 애플리케이션 의미를 가지지 않는 패딩 옥텟들. 전송 시 패딩 옥텟은 MUST 0으로 설정되어야 한다. 수신자는 패딩을 검증할 의무는 없지만, 비영(非零) 패딩을 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리할 MAY 있다.

PUSH_PROMISE 프레임은 다음과 같은 플래그를 정의한다:

PADDED (0x08):: 설정되면 PADDED 플래그는 Pad Length 필드와 그가 설명하는 패딩이 존재함을 나타낸다.
END_HEADERS (0x04):: 설정되면 END_HEADERS 플래그는 이 프레임이 전체 필드 블록(섹션 4.3)을 포함하며 뒤따르는 CONTINUATION 프레임이 없음을 나타낸다.

END_HEADERS 플래그가 설정되지 않은 PUSH_PROMISE 프레임은 동일한 스트림에 대한 CONTINUATION 프레임으로 뒤따라야 한다(MUST). 수신자는 다른 유형의 프레임이나 다른 스트림의 프레임을 수신하면 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다.

PUSH_PROMISE 프레임은 반드시 피어가 시작한 스트림에서만 전송되어야 하며 해당 스트림은 "open" 또는 "half-closed (remote)" 상태여야 한다(MUST). PUSH_PROMISE의 Stream Identifier 필드는 그것이 연관된 스트림을 나타낸다. Stream Identifier 필드가 0x00을 지정하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

약속된 스트림은 약속된 순서대로 사용될 필요가 없다. PUSH_PROMISE는 단지 나중에 사용할 스트림 식별자를 예약할 뿐이다.

SETTINGS 프레임의 상대 피어의 SETTINGS_ENABLE_PUSH 설정이 0으로 설정된 경우 PUSH_PROMISE는 전송되어서는 안 된다(MUST NOT). 이 설정을 0으로 설정하고 확인을 받은 엔드포인트는 PUSH_PROMISE 프레임을 수신하면 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

PUSH_PROMISE 프레임의 수신자는 약속된 스트림을 거부하기 위해 해당 약속된 스트림 식별자를 참조하는 RST_STREAM을 전송할 수 있다.

PUSH_PROMISE 프레임은 연결 상태를 두 가지 방식으로 변경한다. 첫째, 필드 블록의 포함(섹션 4.3)은 필드 섹션 압축을 위해 유지되는 상태를 변경할 수 있다. 둘째, PUSH_PROMISE는 나중에 사용하기 위해 스트림을 예약하여 약속된 스트림을 "reserved (local)" 또는 "reserved (remote)" 상태로 만든다. 송신자는 해당 스트림이 "open" 또는 "half-closed (remote)" 상태인 경우에만 PUSH_PROMISE를 전송해야 하며(MUST NOT), 약속된 스트림이 새 스트림 식별자에 대한 유효한 선택인지 보장해야 한다(섹션 5.1.1)(즉, 약속된 스트림은 "idle" 상태여야 한다)(MUST).

PUSH_PROMISE는 스트림을 예약하므로 PUSH_PROMISE 프레임을 무시하면 스트림 상태가 불확정 상태가 된다. 수신자는 연관된 스트림이 "open"도 아니고 "half-closed (local)"도 아닌 스트림에서 PUSH_PROMISE를 수신하면 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST). 다만 연관된 스트림에서 RST_STREAM을 전송한 엔드포인트는 해당 RST_STREAM 프레임이 수신되고 처리되기 전에 생성되었을 수 있는 PUSH_PROMISE 프레임을 처리해야 한다.

약속된 스트림 식별자가 불법적인 경우(섹션 5.1.1), 수신자는 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST). 불법적인 스트림 식별자는 현재 "idle" 상태가 아닌 스트림의 식별자이다.

6.7. PING

PING 프레임(type=0x06)은 송신자로부터 최소 왕복 시간을 측정하고 유휴 연결이 여전히 작동하는지 확인하기 위한 메커니즘이다. PING 프레임은 어느 엔드포인트에서나 보낼 수 있다.

PING Frame {
  Length (24) = 0x08,
  Type (8) = 0x06,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Opaque Data (64),
}

그림 9: PING 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다.

프레임 헤더 외에도 PING 프레임은 페이로드에 8 옥텟의 불투명 데이터를 포함해야 한다(MUST). 송신자는 임의의 값을 포함할 수 있으며 그 옥텟들을 어떤 방식으로든 사용할 수 있다.

ACK 플래그가 설정되지 않은 PING 프레임을 수신한 수신자는 동일한 프레임 페이로드로 ACK 플래그가 설정된 PING 프레임을 응답으로 전송해야 한다(MUST). PING 응답은 다른 어떤 프레임보다 높은 우선순위로 처리되는 것이 바람직하다(SHOULD).

PING 프레임은 다음과 같은 플래그를 정의한다:

ACK (0x01):: 설정되면 이 PING 프레임이 PING 응답임을 나타낸다. 엔드포인트는 PING 응답에서 이 플래그를 MUST 설정해야 한다. 또한 이 플래그가 설정된 PING 프레임에 응답해서는 안 된다(MUST NOT).

PING 프레임은 어떤 개별 스트림과도 연관되지 않는다. Stream Identifier 필드 값이 0x00이 아닌 PING 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

길이가 8이 아닌 PING 프레임을 수신하면 수신자는 이를 섹션 5.4.1에 규정된 FRAME_SIZE_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

6.8. GOAWAY

GOAWAY 프레임(type=0x07)은 연결 종료를 시작하거나 심각한 오류 상태를 알리는 데 사용된다. GOAWAY는 엔드포인트가 새 스트림 수락을 점차 중단하면서 이전에 설정된 스트림의 처리는 완료할 수 있게 한다. 이는 서버 유지보수와 같은 관리 작업을 가능하게 한다.

엔드포인트가 새 스트림을 시작하는 것과 원격 피어가 GOAWAY를 보내는 것 사이에는 본질적인 경쟁 조건이 있다. 이를 다루기 위해 GOAWAY는 이 연결에서 송신자가 처리했거나 처리할 수 있었던 마지막 피어-시작 스트림의 스트림 식별자를 포함한다. 예를 들어 서버가 GOAWAY를 보낼 경우 식별된 스트림은 클라이언트가 시작한 가장 높은 번호의 스트림이다.

GOAWAY를 보낸 이후 송신자는 포함된 마지막 스트림 식별자보다 높은 식별자를 가진 수신자가 시작한 스트림에 대해 전송된 프레임을 무시할 것이다. GOAWAY 프레임의 수신자는 연결에서 추가 스트림을 열어서는 안 된다(MUST NOT), 다만 새 스트림을 위해 새 연결을 설정할 수는 있다.

GOAWAY 수신자가 GOAWAY에 표시된 것보다 더 높은 스트림 식별자에 대해 데이터를 전송한 경우, 해당 스트림들은 처리되지 않았거나 처리되지 않을 것이다. GOAWAY 프레임의 수신자는 해당 스트림들을 마치 전혀 생성되지 않았던 것처럼 취급하고 나중에 새 연결에서 재시도할 수 있다.

엔드포인트는 연결을 닫기 전에 항상 GOAWAY 프레임을 보내어 원격 피어가 스트림이 일부만 처리되었는지 여부를 알 수 있게 하는 것이 바람직하다(SHOULD). 예를 들어 HTTP 클라이언트가 POST를 전송한 동시에 서버가 연결을 닫으면 서버가 어떤 스트림에 대해 작업을 시작했는지 알려주는 GOAWAY를 보내지 않으면 클라이언트는 그 POST 요청이 처리되었는지 알 수 없다.

엔드포인트는 불량 피어에 대해 GOAWAY를 보내지 않고 연결을 닫기로 선택할 수 있다.

GOAWAY 프레임은 항상 연결을 닫기 직전에 전송될 필요는 없다; GOAWAY를 수신한 쪽이 연결을 더 이상 필요로 하지 않는 경우에도 연결을 종료하기 전에 GOAWAY를 보내는 것이 바람직하다(SHOULD).

GOAWAY Frame {
  Length (24),
  Type (8) = 0x07,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31) = 0,

  Reserved (1),
  Last-Stream-ID (31),
  Error Code (32),
  Additional Debug Data (..),
}

그림 10: GOAWAY 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다.

GOAWAY 프레임은 어떤 플래그도 정의하지 않는다.

GOAWAY 프레임은 특정 스트림이 아니라 연결에 적용된다. Stream Identifier가 0x00이 아닌 GOAWAY 프레임을 수신한 엔드포인트는 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

GOAWAY 프레임의 마지막 스트림 식별자는 송신자가 어떤 스트림에 대해 어떤 조치를 취했거나 아직 조치를 취할 수 있는 가장 높은 번호의 스트림 식별자를 포함한다. 식별된 스트림까지의 모든 스트림은 어떤 방식으로든 처리되었을 수 있다. 처리된 스트림이 없다면 마지막 스트림 식별자는 0으로 설정될 수 있다.

연결이 GOAWAY 없이 종료되면 마지막 스트림 식별자는 사실상 가능한 가장 높은 스트림 식별자가 된다.

마지막 스트림 식별자보다 작거나 같은 번호의 스트림에서 완전히 닫히지 않은 작업은 재시도할 수 없는 경우가 많다(예: 비멱등 작업 제외). 그러나 더 높은 번호의 스트림에서의 프로토콜 활동은 새 연결에서 안전하게 재시도할 수 있다.

마지막 스트림 식별자보다 작은 번호의 스트림에서의 활동은 여전히 성공적으로 완료될 수 있다. GOAWAY를 보낸 측은 GOAWAY를 전송한 후 진행 중인 모든 스트림이 완료될 때까지 연결을 "open" 상태로 유지하여 우아하게 종료할 수 있다.

엔드포인트는 상황 변화 시 여러 GOAWAY 프레임을 보낼 MAY 있다. 예를 들어, 우아한 종료 중 NO_ERROR와 함께 GOAWAY를 보냈던 엔드포인트가 이후 즉시 연결을 종료해야 하는 조건을 만날 수 있다. 마지막으로 수신된 GOAWAY의 마지막 스트림 식별자는 어떤 스트림이 처리되었을 수 있는지를 나타낸다. 엔드포인트는 이미 보낸 마지막 스트림 식별자의 값을 증가시켜서는 안 된다(MUST NOT), 왜냐하면 피어가 이미 처리되지 않은 요청을 다른 연결에서 재시도했을 수 있기 때문이다.

클라이언트가 재시도할 수 없을 경우 서버가 연결을 닫을 때 전송 중인 모든 요청을 잃게 된다. 이는 중개자가 HTTP/2가 아닌 클라이언트에 서비스를 제공할 때 특히 해당된다. 서버가 우아하게 연결을 종료하려 하면 초기 GOAWAY 프레임을 마지막 스트림 식별자를 2³¹-1로 설정하고 NO_ERROR 코드를 사용하여 전송하는 것이 바람직하다(SHOULD). 이는 클라이언트에게 종료가 임박했으므로 추가 요청을 시작해서는 안 됨을 신호한다. 인플라이트 스트림 생성에 시간이 허용된 후(최소 한 왕복 시간) 서버는 업데이트된 마지막 스트림 식별자를 가진 또 다른 GOAWAY 프레임을 전송할 수 있다. 이는 요청을 잃지 않으면서 깨끗하게 연결을 종료할 수 있게 한다.

GOAWAY를 보낸 후 송신자는 포함된 마지막 스트림 식별자보다 높은 식별자를 가진 수신자에 의해 시작된 스트림에 대한 프레임을 폐기할 수 있다. 그러나 연결 상태를 변경하는 프레임은 완전히 무시될 수 없다. 예를 들어 HEADERS, PUSH_PROMISE, 및 CONTINUATION 프레임은 필드 섹션 압축을 위한 상태가 일관되도록 최소한 처리되어야 한다(자세한 내용은 섹션 4.3 참조); 마찬가지로 DATA 프레임은 연결 흐름 제어 창에 반영되어야 한다. 이러한 프레임을 처리하지 않으면 흐름 제어나 필드 섹션 압축 상태가 비동기화될 수 있다.

GOAWAY 프레임은 또한 연결 종료 이유를 담은 32비트 오류 코드(섹션 7)를 포함한다.

엔드포인트는 어떤 GOAWAY 프레임의 페이로드에 불투명 데이터를 추가할 MAY 있다. 추가 디버그 데이터는 진단 목적으로만 의도되며 의미론적 가치는 갖지 않는다. 디버그 정보에는 보안 또는 개인정보 민감 데이터가 포함될 수 있다. 기록되거나 지속적으로 저장되는 디버그 데이터는 무단 접근을 방지하기 위한 적절한 보호 조치를 가져야 한다(MUST).

6.9. WINDOW_UPDATE

WINDOW_UPDATE 프레임(type=0x08)은 흐름 제어를 구현하는 데 사용된다; 개요는 섹션 5.2를 보라.

흐름 제어는 두 수준에서 작동한다: 개별 스트림별과 전체 연결에 대해.

두 유형의 흐름 제어는 홉 단위이며, 즉 양 엔드포인트 간에서만 작동한다. 중개자는 종속된 연결들 사이에서 WINDOW_UPDATE 프레임을 전달하지 않는다. 그러나 어떤 수신자에 의한 데이터 전송 제한은 원래 송신자 쪽으로 흐름 제어 정보의 전파를 간접적으로 초래할 수 있다.

흐름 제어는 흐름 제어의 대상이 되는 프레임에만 적용된다. 이 문서에서 정의된 프레임 중에서는 오직 DATA 프레임만 흐름 제어의 대상이다. 흐름 제어에서 면제된 프레임은 수신 가능하고 처리되어야 하며(MUST), 수신자가 해당 프레임을 처리할 자원을 할당할 수 없으면 수신자는 섹션 5.4.2 또는 섹션 5.4.1에 규정된 FLOW_CONTROL_ERROR 유형의 스트림 오류나 연결 오류로 응답할 MAY 있다.

WINDOW_UPDATE Frame {
  Length (24) = 0x04,
  Type (8) = 0x08,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Window Size Increment (31),
}

그림 11: WINDOW_UPDATE 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. WINDOW_UPDATE 프레임의 페이로드는 하나의 예약 비트와 송신자가 기존 흐름 제어 창에 추가로 전송할 수 있는 옥텟 수를 나타내는 부호 없는 31비트 정수로 이루어져 있다. 흐름 제어 창의 증가량에 대한 합법적 범위는 1부터 2³¹-1(2,147,483,647) 옥텟이다.

WINDOW_UPDATE 프레임은 어떤 플래그도 정의하지 않는다.

WINDOW_UPDATE 프레임은 특정 스트림에 적용될 수도 있고 전체 연결에 적용될 수도 있다. 전자의 경우 프레임의 Stream Identifier가 영향을 받는 스트림을 나타내며, 후자의 경우 값 "0"이 전체 연결을 주제로 함을 나타낸다.

수신자는 흐름 제어 창 증가량이 0인 WINDOW_UPDATE 프레임을 수신하면 이를 섹션 5.4.2에 규정된 PROTOCOL_ERROR 유형의 스트림 오류로 처리해야 한다(MUST); 연결 흐름 제어 창에 대한 오류는 연결 오류로 처리되어야 한다(섹션 5.4.1)(MUST).

WINDOW_UPDATE는 END_STREAM 플래그가 설정된 프레임을 전송한 피어가 보낼 수 있다. 이는 수신자가 "half-closed (remote)" 또는 "closed" 상태의 스트림에서 WINDOW_UPDATE 프레임을 받을 수 있음을 의미한다. 수신자는 이를 오류로 처리해서는 안 된다(자세한 내용은 섹션 5.1 참조).

수신자가 흐름 제어 대상 프레임을 수신하면, 수신자는 이를 연결 흐름 제어 창에 대해 항상 반영하여 계산해야 한다. 이는 프레임이 오류인 경우에도 필요하다. 송신자가 프레임을 흐름 제어 창에 포함하여 계산하지만 수신자가 이를 반영하지 않으면 송신자와 수신자의 흐름 제어 창이 달라질 수 있다.

길이가 4 옥텟이 아닌 WINDOW_UPDATE 프레임은 섹션 5.4.1에 규정된 FRAME_SIZE_ERROR 유형의 연결 오류로 처리되어야 한다(MUST).

6.9.1. 흐름 제어 창

HTTP/2의 흐름 제어는 각 송신자가 모든 스트림에 대해 유지하는 창을 사용하여 구현된다. 흐름 제어 창은 송신자가 전송할 수 있는 옥텟 수를 나타내는 정수 값으로, 그 크기는 수신자의 버퍼링 용량을 측정한다.

적용되는 흐름 제어 창은 스트림 흐름 제어 창과 연결 흐름 제어 창의 두 가지가 있다. 송신자는 수신자가 광고한 어느 한 흐름 제어 창의 여유 공간을 초과하는 길이의 흐름 제어 대상 프레임을 전송해서는 안 된다(MUST NOT). END_STREAM 플래그가 설정된 길이 0 프레임(예: 빈 DATA 프레임)은 두 흐름 제어 창 중 어느 쪽에 여유 공간이 없더라도 전송할 수 있다(MAY).

흐름 제어 계산에서는 9 옥텟의 프레임 헤더는 포함되지 않는다.

송신자는 흐름 제어 대상 프레임을 전송한 후 전송한 프레임의 길이만큼 두 창에서 이용 가능한 공간을 감소시킨다.

프레임의 수신자는 데이터를 소비하고 흐름 제어 창의 공간을 확보함에 따라 WINDOW_UPDATE 프레임을 보낸다. 스트림 및 연결 수준의 흐름 제어 창에 대해 별도의 WINDOW_UPDATE 프레임이 전송된다. 수신자는 매우 작은 증가량의 WINDOW_UPDATE를 보내는 것을 피하기 위한 메커니즘을 마련하는 것이 권장된다(자세한 내용은 RFC 1122 섹션 4.2.3.3 참조).

송신자는 WINDOW_UPDATE 프레임을 수신하면 해당 창을 프레임에 지정된 양만큼 업데이트한다.

송신자는 흐름 제어 창이 2³¹-1 옥텟을 초과하도록 허용해서는 안 된다(MUST NOT). 송신자가 WINDOW_UPDATE를 수신하여 흐름 제어 창이 이 최대를 초과하게 되면 송신자는 적절히 스트림이나 연결을 종료해야 하며, 스트림의 경우 RST_STREAM을 FLOW_CONTROL_ERROR 오류 코드와 함께 전송하고, 연결의 경우 GOAWAY를 FLOW_CONTROL_ERROR 오류 코드와 함께 전송해야 한다(MUST).

송신자의 흐름 제어 대상 프레임과 수신자의 WINDOW_UPDATE 프레임은 서로 완전히 비동기적이다. 이 특성은 수신자가 송신자의 창 크기를 공격적으로 업데이트하여 스트림이 정체되는 것을 방지할 수 있게 한다.

6.9.2. 초기 흐름 제어 창 크기

HTTP/2 연결이 처음 설정될 때 새 스트림은 초기 흐름 제어 창 크기 65,535 옥텟을 갖는다. 연결 흐름 제어 창도 65,535 옥텟이다. 양쪽 엔드포인트는 SETTINGS_INITIAL_WINDOW_SIZE에 값을 포함하여 새 스트림의 초기 창 크기를 조정할 수 있다. 연결 흐름 제어 창은 WINDOW_UPDATE 프레임을 사용해서만 변경할 수 있다.

SETTINGS 프레임을 수신하여 SETTINGS_INITIAL_WINDOW_SIZE 값을 설정받기 전까지 엔드포인트는 전송 시 기본 초기 창 크기만 사용할 수 있다. 유사하게, 연결 흐름 제어 창은 WINDOW_UPDATE 프레임을 받을 때까지 기본 초기 창 크기에 따라 설정된다.

ACTIVATED되지 않은 스트림들 뿐만 아니라 활성화된 흐름 제어 창을 가진 스트림들(즉 "open" 또는 "half-closed (remote)" 상태)에 대해서도 SETTINGS 프레임은 초기 흐름 제어 창 크기를 변경할 수 있다. SETTINGS_INITIAL_WINDOW_SIZE 값이 변경되면 수신자는 유지하는 모든 스트림 흐름 제어 창의 크기를 새 값과 이전 값의 차이만큼 조정해야 한다(MUST).

SETTINGS_INITIAL_WINDOW_SIZE의 변경은 흐름 제어 창의 이용 가능 공간을 음수로 만들 수 있다. 송신자는 음수의 흐름 제어 창을 추적해야 하며, WINDOW_UPDATE가 창을 양수로 만들 때까지 새로운 흐름 제어 대상 프레임을 전송해서는 안 된다(MUST NOT).

예를 들어, 클라이언트가 연결 수립 직후 60KB를 전송했고 서버가 초기 창 크기를 16KB로 설정하면, 클라이언트는 SETTINGS 프레임 수신 시 사용 가능한 흐름 제어 창을 -44KB로 재계산한다. 클라이언트는 WINDOW_UPDATE 프레임이 창을 양수로 복원할 때까지 음수 창을 유지하고 이후에 전송을 재개할 수 있다.

SETTINGS 프레임은 연결 흐름 제어 창을 변경할 수 없다.

SETTINGS_INITIAL_WINDOW_SIZE 변경으로 인해 어떤 흐름 제어 창이라도 최대 크기를 초과하게 되면 수신자는 이를 섹션 5.4.1에 규정된 FLOW_CONTROL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

6.9.3. 스트림 창 크기 축소

수신자가 현재 크기보다 작은 흐름 제어 창을 사용하려면 새로운 SETTINGS 프레임을 보낼 수 있다. 그러나 수신자는 송신자가 SETTINGS 프레임을 처리하기 전에 그보다 큰 데이터를 보낼 수 있으므로 이러한 경우에도 초과하는 데이터를 수신할 준비가 되어 있어야 한다(MUST).

초기 흐름 제어 창 크기를 축소하는 SETTINGS 프레임을 전송한 후 수신자는 그보다 큰 스트림들을 계속 처리할 수 있다(MAY). 스트림을 계속 허용하면 흐름 제어 창을 즉시 줄여서 확보한 공간을 감소시키는 것을 허용하지 않는다. 이러한 스트림들의 진행은 WINDOW_UPDATE 프레임이 필요하므로 정체될 수 있다. 수신자는 대신 영향을 받는 스트림들에 대해 RST_STREAM을 FLOW_CONTROL_ERROR 오류 코드와 함께 전송할 수 있다(MAY).

6.10. CONTINUATION

CONTINUATION 프레임(type=0x09)은 필드 블록 조각들의 연속을 계속하기 위해 사용된다(섹션 4.3). 이전 프레임이 동일한 스트림에 있고 END_HEADERS 플래그가 설정되지 않은 HEADERS, PUSH_PROMISE 또는 CONTINUATION 프레임인 한 임의의 수의 CONTINUATION 프레임을 전송할 수 있다.

CONTINUATION Frame {
  Length (24),
  Type (8) = 0x09,

  Unused Flags (5),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  Field Block Fragment (..),
}

그림 12: CONTINUATION 프레임 형식

Length, Type, Unused Flag(s), Reserved 및 Stream Identifier 필드는 섹션 4에 설명되어 있다. CONTINUATION 프레임 페이로드는 필드 블록 조각(섹션 4.3)을 포함한다.

CONTINUATION 프레임은 다음과 같은 플래그를 정의한다:

END_HEADERS (0x04):: 설정되면 END_HEADERS 플래그는 이 프레임이 필드 블록(섹션 4.3)을 종료함을 나타낸다.

END_HEADERS 플래그가 설정되지 않으면 이 프레임은 MUST 다른 CONTINUATION 프레임으로 이어져야 한다. 수신자는 다른 유형의 프레임이나 다른 스트림의 프레임을 수신하면 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 한다(MUST).

CONTINUATION 프레임은 섹션 4.3에 정의된 바와 같이 연결 상태를 변경한다.

CONTINUATION 프레임은 반드시 스트림과 연관되어야 한다. Stream Identifier 필드가 0x00인 CONTINUATION 프레임을 수신하면 수신자는 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

CONTINUATION 프레임은 END_HEADERS 플래그가 설정되지 않은 HEADERS, PUSH_PROMISE 또는 CONTINUATION 프레임에 의해 선행되어야 한다. 이 규칙 위반을 관찰한 수신자는 이를 섹션 5.4.1에 규정된 PROTOCOL_ERROR 유형의 연결 오류로 응답해야 한다(MUST).

7. 오류 코드

오류 코드는 스트림 또는 연결 오류의 이유를 전달하기 위해 RST_STREAM 및 GOAWAY 프레임에서 사용되는 32비트 필드입니다.

오류 코드는 공통 코드 공간을 공유합니다. 일부 오류 코드는 스트림에만 적용되거나 연결 전체에만 적용되며, 다른 문맥에서는 정의된 의미가 없습니다.

다음의 오류 코드들이 정의되어 있습니다:

NO_ERROR (0x00):: 관련된 상태가 오류의 결과가 아님을 나타냅니다. 예를 들어, GOAWAY는 연결의 정상 종료를 나타내기 위해 이 코드를 포함할 수 있습니다.
PROTOCOL_ERROR (0x01):: 엔드포인트가 특정하지 않은 프로토콜 오류를 감지했음을 나타냅니다. 더 구체적인 오류 코드가 없을 때 사용하는 코드입니다.
INTERNAL_ERROR (0x02):: 엔드포인트가 예기치 않은 내부 오류를 만났음을 나타냅니다.
FLOW_CONTROL_ERROR (0x03):: 피어가 흐름 제어 프로토콜을 위반했음을 엔드포인트가 감지했음을 나타냅니다.
SETTINGS_TIMEOUT (0x04):: 엔드포인트가 SETTINGS 프레임을 보냈으나 적시에 응답을 받지 못했음을 나타냅니다. 자세한 내용은 섹션 6.5.3("Settings Synchronization")을 보십시오.
STREAM_CLOSED (0x05):: 스트림이 반닫힘(half-closed) 상태인 후에 프레임을 수신했음을 나타냅니다.
FRAME_SIZE_ERROR (0x06):: 유효하지 않은 크기의 프레임을 수신했음을 나타냅니다.
REFUSED_STREAM (0x07):: 엔드포인트가 어떤 애플리케이션 처리도 수행하기 전에 스트림을 거부했음을 나타냅니다(자세한 내용은 섹션 8.7 참조).
CANCEL (0x08):: 스트림이 더 이상 필요하지 않음을 나타내기 위해 엔드포인트가 사용하는 오류 코드입니다.
COMPRESSION_ERROR (0x09):: 연결에 대한 필드 섹션 압축 컨텍스트를 유지할 수 없음을 엔드포인트가 나타냅니다.
CONNECT_ERROR (0x0a):: CONNECT 요청(섹션 8.5)에 대한 응답으로 설정된 연결이 재설정되었거나 비정상적으로 닫혔음을 나타냅니다.
ENHANCE_YOUR_CALM (0x0b):: 피어가 과도한 부하를 유발할 수 있는 행동을 보이고 있음을 엔드포인트가 감지했음을 나타냅니다.
INADEQUATE_SECURITY (0x0c):: 기저 전송 계층이 최소 보안 요구사항을 충족하지 않음을 나타냅니다(자세한 내용은 섹션 9.2 참조).
HTTP_1_1_REQUIRED (0x0d):: 엔드포인트가 HTTP/2 대신 HTTP/1.1 사용을 요구함을 나타냅니다.

알려지지 않았거나 지원되지 않는 오류 코드는 어떤 특별한 동작을 유발해서는 MUST NOT 합니다. 이러한 코드들은 구현체에서 INTERNAL_ERROR와 동등하게 처리될 수 있습니다(MAY).

8. HTTP/2에서의 HTTP 의미 표현

HTTP/2는 HTTP 메시지 추상화의 한 구체화입니다(RFC 9110 섹션 6 참조).

8.1. HTTP 메시지 프레이밍

클라이언트는 새 스트림에서 이전에 사용되지 않은 스트림 식별자를 사용하여 HTTP 요청을 전송합니다(섹션 5.1.1 참조). 서버는 동일한 스트림에서 해당 요청에 대한 HTTP 응답을 전송합니다.

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

헤더 섹션을 포함하는 하나의 HEADERS 프레임(그 뒤에 0개 이상의 CONTINUATION 프레임이 올 수 있음; 자세한 내용은 RFC 9110 섹션 6.3 참조),
메시지 본문을 포함하는 0개 이상의 DATA 프레임(자세한 내용은 RFC 9110 섹션 6.4 참조),
선택적으로, 트레일러 섹션이 있는 경우 하나의 HEADERS 프레임(그 뒤에 0개 이상의 CONTINUATION 프레임이 올 수 있음).

응답의 경우에 한해, 서버는 최종 응답을 담은 HEADERS 프레임 전에 임의의 수의 중간 응답(interim responses)을 보낼 MAY 있습니다. 중간 응답은 임시(1xx) HTTP 응답의 제어 데이터와 헤더 섹션을 포함하는 HEADERS 프레임(그 뒤에 0개 이상의 CONTINUATION 프레임이 올 수 있음)으로 구성됩니다. 상태 코드가 정보 코드(1xx)인 HEADERS 프레임에 END_STREAM 플래그가 설정된 경우 이는 잘못된 형식입니다(섹션 8.1.1 참조).

시퀀스의 마지막 프레임은 END_STREAM 플래그를 가지며, END_STREAM 플래그가 설정된 HEADERS 프레임은 남아 있는 필드 블록 조각들을 전송하는 CONTINUATION 프레임들로 뒤따를 수 있음을 나타냅니다.

다른 스트림의 프레임(어떤 스트림에서든)은 HEADERS 프레임과 그에 뒤따르는 CONTINUATION 프레임들 사이에는 발생해서는 안 됩니다(MUST NOT).

HTTP/2는 메시지 본문을 전송하기 위해 DATA 프레임을 사용합니다. chunked 전송 인코딩(HTTP/1.1의 섹션 7.1)은 HTTP/2에서 사용할 수 없습니다; 관련 내용은 섹션 8.2.2를 보십시오.

트레일러 필드는 스트림을 종료시키는 필드 블록으로 운반됩니다. 즉, 트레일러는 END_STREAM 플래그가 설정된 HEADERS 프레임으로 시작하고 0개 이상의 CONTINUATION 프레임을 따르며, 해당 HEADERS 프레임에 END_STREAM 플래그가 설정되어야 합니다. 트레일러에는 의사-헤더 필드들이 포함되어서는 안 됩니다(섹션 8.3). 트레일러에서 의사-헤더 필드가 수신되면 해당 요청 또는 응답은 잘못된 형식으로 처리되어야 합니다(섹션 8.1.1).

요청을 여는 HEADERS 프레임을 받은 후에 END_STREAM 플래그가 설정되지 않은 다른 HEADERS 프레임을 수신하면 해당 요청 또는 응답은 잘못된 형식으로 간주되어야 합니다(섹션 8.1.1).

HTTP 요청/응답 교환은 단일 스트림을 완전히 소비합니다. 요청은 스트림을 "open" 상태로 만드는 HEADERS 프레임으로 시작합니다. 요청은 END_STREAM 플래그가 설정된 프레임으로 끝나며, 이는 클라이언트에 대해 스트림을 "half-closed (local)"로, 서버에 대해 "half-closed (remote)"로 만듭니다. 응답 스트림은 0개 이상의 중간 응답(HEADERS 프레임)으로 시작한 뒤 최종 상태 코드를 포함하는 HEADERS 프레임으로 끝납니다.

서버가 END_STREAM 플래그가 설정된 프레임을 전송하거나 클라이언트가 이를 수신하면 응답이 완료됩니다(필요한 CONTINUATION 프레임 포함). 서버는 요청의 아직 전송되지 않은 일부에 의존하지 않는 경우 전체 응답을 클라이언트가 전체 요청을 보내기 전에 전송할 수 있습니다. 이 경우 서버는 완전한 응답을 전송한 후 요청의 전송을 오류 없이 중단하도록 클라이언트에 요청하기 위해 RST_STREAM을 NO_ERROR 오류 코드로 보낼 수 있습니다. 클라이언트는 이러한 RST_STREAM을 수신했다고 해서 응답을 폐기해서는 안 되지만, 다른 이유로 응답을 폐기할 수는 있습니다.

8.1.1. 잘못된 형식의 메시지

잘못된 요청 또는 응답이란 HTTP/2 프레임들의 유효한 연속이지만 불필요한 프레임, 금지된 필드 또는 의사-헤더 필드의 존재, 필수 의사-헤더 필드의 부재, 대문자 필드 이름의 포함, 또는 특정 상황에서 허용되지 않는 필드 이름/값 등으로 인해 무효가 되는 경우를 말합니다(자세한 내용은 섹션 8.2 참조).

메시지 본문을 포함하는 요청 또는 응답은 content-length 헤더 필드를 가질 수 있습니다. 만약 content-length 헤더의 값이 실제로 전송된 DATA 프레임 페이로드의 합계와 일치하지 않으면(메시지가 본문이 없도록 정의되지 않은 경우) 그 요청 또는 응답은 잘못된 형식입니다. 예를 들어 204 또는 304 응답과 HEAD 요청의 응답은 본문을 포함하지 않습니다. 본문이 없도록 정의된 응답은 DATA 프레임에 내용이 포함되지 않더라도 비영(非零) content-length 헤더를 가질 MAY 있습니다.

HTTP 요청 또는 응답을 처리하는 중개자(터널로 동작하지 않는 중개자)는 잘못된 형식의 요청이나 응답을 전달해서는 MUST NOT 합니다. 감지된 잘못된 요청 또는 응답은 스트림 오류(섹션 5.4.2)로 처리되어야 하며, 오류 유형은 PROTOCOL_ERROR입니다(MUST).

잘못된 형식의 요청에 대해 서버는 스트림을 닫거나 리셋하기 전에 응답을 보낼 MAY 있습니다. 클라이언트는 잘못된 형식의 응답을 수락해서는 MUST NOT 합니다.

메시지를 점진적으로 처리하는 엔드포인트는 잘못된 형식으로 식별하기 전에 일부 처리를 수행했을 수 있습니다. 예를 들어, 전체 요청을 받기 전에 정보 응답이나 404 상태 코드를 생성할 수 있습니다. 유사하게, 중개자는 오류를 감지하기 전에 불완전한 메시지를 전달할 수 있습니다. 서버는 요청의 나머지 부분이 정확할 필요가 없는 경우 전체 요청을 수신하기 전에 최종 응답을 생성할 MAY 있습니다.

이러한 요구사항은 HTTP에 대한 몇 가지 일반적인 공격으로부터 보호하기 위한 것이며, 관대하게 처리하면 취약점을 노출할 수 있으므로 엄격하게 규정되어 있습니다.

8.2. HTTP 필드

HTTP 필드(RFC 9110 섹션 5)는 HEADERS, CONTINUATION, PUSH_PROMISE 프레임에서 HPACK(HPACK)으로 압축되어 전송됩니다.

필드 이름은 HTTP/2 메시지를 구성할 때 소문자로 변환되어야 합니다(MUST).

8.2.1. 필드 유효성

HPACK이 전달할 수 있는 문자를 HTTP의 필드 이름과 값 정의가 금지할 수 있습니다. HTTP/2 구현체는 RFC 9110의 해당 섹션(5.1 및 5.5)에 따라 필드 이름과 값을 검증하는 것이 권장됩니다. 금지된 문자가 포함된 메시지는 잘못된 형식으로 처리되어야 합니다(섹션 8.1.1).

필드를 검증하지 않으면 요청 스머글링(request smuggling) 공격에 악용될 수 있습니다. 특히, 검증되지 않은 필드는 HTTP/1.1로 전달될 때 구분자(CR, LF, COLON 등)를 악용하는 공격을 가능하게 할 수 있습니다. 구현체는 최소한 다음과 같은 필드 이름 및 값에 대한 검증을 수행해야 합니다:

필드 이름은 0x00-0x20, 0x41-0x5a, 또는 0x7f-0xff 범위의 문자를 포함해서는 MUST NOT 합니다(모든 범위 포함). 이는 모든 비가시 ASCII 문자, ASCII 공백(SP, 0x20), 및 대문자('A'~'Z', 0x41~0x5a)를 제외합니다.
의사-헤더 필드(섹션 8.3)를 제외하고, 필드 이름에 콜론(ASCII COLON, 0x3a)을 포함해서는 MUST NOT 합니다.
필드 값은 어떤 위치에도 널 문자(ASCII NUL, 0x00), 라인 피드(ASCII LF, 0x0a), 또는 캐리지 리턴(ASCII CR, 0x0d)을 포함해서는 MUST NOT 합니다.
필드 값은 ASCII 공백 문자(ASCII SP 또는 HTAB, 0x20 또는 0x09)로 시작하거나 끝나서는 MUST NOT 합니다.

위 조건을 위반하는 필드를 포함하는 요청 또는 응답은 잘못된 형식으로 간주되어야 합니다(섹션 8.1.1). 특히, 필드를 처리하지 않는 중개자는 위에서 금지된 값을 포함하는 필드를 전달해서는 MUST NOT 합니다.

요청 메시지가 이러한 요구사항을 위반할 경우 구현체는 적절한 경우 400(Bad Request) 상태 코드를 생성하는 것이 권장됩니다(RFC 9110 섹션 15.5.1 참조), 단 더 적절한 상태 코드가 정의되어 있거나 상태 코드를 보낼 수 없는 경우(예: 오류가 트레일러 필드에서 발생한 경우)에는 예외입니다.

8.2.2. 연결-특정 헤더 필드

HTTP/2는 연결-특정 헤더 필드를 나타내기 위해 Connection 헤더 필드를 사용하지 않습니다(RFC 9110 섹션 7.6.1 참조). 이 프로토콜에서는 연결-특정 메타데이터가 다른 수단으로 전달됩니다. 엔드포인트는 연결-특정 헤더 필드를 포함하는 HTTP/2 메시지를 생성해서는 MUST NOT 합니다. 여기에는 Connection 헤더 필드와 RFC 9110 섹션 7.6.1에 나열된 연결-특정 의미를 가진 필드들(예: Proxy-Connection, Keep-Alive, Transfer-Encoding, Upgrade)이 포함됩니다. 연결-특정 헤더 필드를 포함하는 모든 메시지는 잘못된 형식으로 처리되어야 합니다(섹션 8.1.1).

예외는 TE 헤더 필드뿐이며, 이는 HTTP/2 요청에 포함될 수 MAY 있고 포함되는 경우 "trailers" 이외의 값을 포함해서는 MUST NOT 합니다.

HTTP/1.x 메시지를 HTTP/2로 변환하는 중개자는 연결-특정 헤더 필드를 제거해야 합니다(RFC 9110 섹션 7.6.1 참조), 그렇지 않으면 해당 메시지는 다른 HTTP/2 엔드포인트에서 잘못된 형식으로 처리될 것입니다(섹션 8.1.1).

8.2.3. Cookie 헤더 필드의 압축

Cookie header field는 세미콜론(" ; ")으로 쿠키-페어(또는 "crumbs")를 구분합니다. 이 헤더 필드는 여러 값을 포함하지만 COMMA(",")를 구분자로 사용하지 않으므로 쿠키-페어들이 여러 필드 라인으로 분할되어 전송되지 않습니다. 이로 인해 개별 쿠키-페어의 업데이트가 HPACK 테이블에 저장된 필드 라인을 무효화하여 압축 효율이 크게 감소할 수 있습니다.

압축 효율을 개선하기 위해 Cookie 헤더 필드는 1개 이상의 쿠키-페어를 포함하는 별도의 헤더 필드들로 분할될 수 있습니다(MAY). 만약 복원 후에 여러 개의 Cookie 헤더 필드가 존재하면, 이를 HTTP/1.1 연결과 같은 비-HTTP/2 컨텍스트로 전달하기 전에 0x3b, 0x20(ASCII 문자열 "; ")의 두 옥텟 구분자로 단일 옥텟 문자열로 연결해야 합니다(MUST).

따라서 다음 두 가지 Cookie 헤더 목록은 의미상 동등합니다.

cookie: a=b; c=d; e=f

cookie: a=b
cookie: c=d
cookie: e=f

8.3. 의사-헤더 필드(HTTP 제어 데이터)

HTTP/2는 메시지 제어 데이터를 전달하기 위해 ':' 문자(ASCII 0x3a)로 시작하는 특수한 의사-헤더 필드를 사용합니다(자세한 내용은 RFC 9110 섹션 6.2 참조).

의사-헤더 필드는 HTTP 헤더 필드가 아닙니다. 엔드포인트는 이 문서에 정의된 것 이외의 의사-헤더 필드를 생성해서는 MUST NOT 합니다. 확장이 추가 의사-헤더 필드 사용을 협상할 수 있다는 점에 유의하세요(섹션 5.5).

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

모든 의사-헤더 필드는 일반 필드 라인보다 먼저 필드 블록에 나타나야 합니다. 일반 필드 라인 이후에 의사-헤더가 나타나는 요청 또는 응답은 잘못된 형식으로 간주되어야 합니다(섹션 8.1.1).

동일한 의사-헤더 필드 이름이 하나의 필드 블록에 두 번 이상 나타나서는 MUST NOT 합니다. 요청 또는 응답의 필드 블록에 중복된 의사-헤더 필드 이름이 포함되면 해당 메시지는 잘못된 형식으로 처리되어야 합니다(섹션 8.1.1).

8.3.1. 요청 의사-헤더 필드

HTTP/2 요청에 대해 다음의 의사-헤더 필드들이 정의되어 있습니다:

":method" 의사-헤더 필드는 HTTP 메서드를 포함합니다(RFC 9110 섹션 9 참조).
":scheme" 의사-헤더 필드는 요청 대상의 스킴 부분을 포함합니다. 스킴은 요청을 직접 생성할 때 대상 URI에서 가져오거나(예: RFC 3986 섹션 3.1) 변환된 요청의 스킴에서 가져옵니다. CONNECT 요청의 경우 ":scheme"는 생략됩니다(섹션 8.5).

":scheme"은 "http" 및 "https"에만 국한되지 않습니다. 프록시나 게이트웨이는 비-HTTP 스킴에 대한 요청을 변환할 수 있습니다.
":authority" 의사-헤더 필드는 대상 URI의 권한(authority) 부분을 전합니다. HTTP/2 요청의 수신자는 ":authority"가 존재하는 경우 Host 헤더 필드를 사용하여 대상 URI를 결정해서는 MUST NOT 합니다.

직접 HTTP/2 요청을 생성하는 클라이언트는 권한 정보를 전달하기 위해 ":authority"를 사용해야 하며(권한 정보가 없는 경우에는 생성해서는 안 됩니다).

클라이언트는 ":authority"와 다른 값을 가진 Host 필드를 생성해서는 MUST NOT 합니다. 서버는 ":authority"와 다른 Host 필드를 포함한 요청을 잘못된 형식으로 처리하는 것이 권장됩니다. 비교를 위해 값들은 정규화되어야 합니다(정규화 방법 참조: RFC 3986 섹션 6.2).

HTTP/2로 요청을 전달하는 중개자는 원래 요청의 제어 데이터에서 권한 정보를 사용하여 ":authority"를 구성해야 하며(원래 요청에 권한 정보가 없는 경우에는 ":authority"를 생성해서는 안 됩니다).

중개자가 HTTP/1.1 요청을 구성하기 위해 Host 헤더 필드를 생성해야 하는 경우, 중개자는 ":authority"의 값을 Host 필드 값으로 사용해야 하며(요청 대상이 변경되지 않는 한) 기존 Host 필드를 대체해야 합니다.

중개자는 HTTP/2로 요청을 전달하면서 기존 Host 헤더 필드를 유지할 수도 있습니다(MAY).

CONNECT 또는 별표(asterisk) 형태의 OPTIONS 요청의 요청 대상에는 권한 정보가 포함되지 않습니다.

":authority"는 "http" 또는 "https" 스킴에 대해 더 이상 권장되지 않는 userinfo 하위 구성요소를 포함해서는 MUST NOT 합니다.
":path" 의사-헤더 필드는 대상 URI의 경로 및 쿼리 부분을 포함합니다(absolute-path 및 선택적 '?'와 query). asterisk 형태의 OPTIONS 요청은 ":path"에 '*' 값을 포함합니다.

이 의사-헤더는 "http" 또는 "https" URI에 대해 비어 있어서는 MUST NOT 하며, 경로 구성요소가 없는 경우에는 '/'를 포함해야 합니다. 예외는 다음과 같습니다:
- 경로 구성요소가 없는 "http" 또는 "https" URI에 대한 OPTIONS 요청은 ":path"에 '*' 값을 포함해야 합니다.
- CONNECT 요청의 경우 ":path" 의사-헤더는 생략되어야 합니다.

모든 HTTP/2 요청은 ":method", ":scheme", 및 ":path" 의사-헤더 필드를 정확히 하나씩 포함해야 합니다(단 CONNECT 요청은 예외). 이러한 필드를 생략한 요청은 잘못된 형식입니다(섹션 8.1.1).

개별 HTTP/2 요청은 명시적인 프로토콜 버전 표시를 포함하지 않습니다. 모든 HTTP/2 요청은 암묵적으로 프로토콜 버전 "2.0"을 갖습니다.

8.3.2. 응답 의사-헤더 필드

HTTP/2 응답에 대해서는 하나의 ":status" 의사-헤더 필드가 정의되어 있으며, 이는 HTTP 상태 코드 필드를 담습니다. 이 의사-헤더는 중간 응답을 포함한 모든 응답에 포함되어야 하며, 그렇지 않으면 응답은 잘못된 형식입니다(섹션 8.1.1).

HTTP/2 응답은 암묵적으로 프로토콜 버전 "2.0"을 가집니다.

8.4. 서버 푸시

HTTP/2는 서버가 이전의 클라이언트-시작 요청과 관련하여 클라이언트에 대해 응답(및 해당 "약속된" 요청)을 사전 전송(또는 "푸시")할 수 있도록 허용합니다.

서버 푸시는 서버가 수신한 요청 이후에 따라올 요청을 예측하여 클라이언트가 느끼는 성능을 개선하도록 설계되었습니다. 예를 들어 HTML 요청은 종종 해당 페이지에 참조된 스타일시트나 스크립트 요청을 동반합니다. 이러한 요청들을 푸시하면 클라이언트는 HTML에서 참조를 받을 때까지 기다릴 필요가 없어 개별 요청에 대한 왕복 시간을 제거할 수 있습니다.

실무에서는 서버가 클라이언트의 캐싱 상태, 콘텐츠 협상 및 사용자 동작과 같은 요소를 고려하여 클라이언트가 추가로 요청할 정확한 항목을 예측해야 하므로 서버 푸시는 효과적으로 사용하기 어렵습니다. 예측 실패는 추가 데이터 전송으로 인한 기회비용 때문에 성능 저하로 이어질 수 있습니다. 특히 상당한 양의 데이터를 푸시하면 더 중요한 응답들과 자원 경쟁을 초래할 수 있습니다.

클라이언트는 서버 푸시를 비활성화하도록 요청할 수 있으며, 이는 홉(hop)마다 독립적으로 협상됩니다. SETTINGS_ENABLE_PUSH 설정을 0으로 설정하면 서버 푸시가 비활성화되었음을 나타냅니다.

약속된 요청은 안전(safe)하고 캐시 가능(cacheable)해야 합니다(관련 RFC 섹션 참조). 약속된 요청은 본문이나 트레일러 섹션을 포함할 수 없습니다. 클라이언트가 캐시 가능하지 않거나 안전하지 않거나 요청 본문이 있음을 나타내는 약속된 요청을 수신하면 해당 약속된 스트림을 섹션 5.4.2에 따라 RST_STREAM으로 재설정하고 오류 유형으로 PROTOCOL_ERROR를 사용해야 합니다.

캐시 가능한 푸시된 응답은 클라이언트가 HTTP 캐시를 구현한 경우 저장될 수 있습니다. 푸시된 응답은 약속된 스트림 식별자에 의해 식별되는 스트림이 아직 열려 있는 동안 원본 서버에서 성공적으로 검증된 것으로 간주될 수 있습니다.

캐시할 수 없는 푸시된 응답은 어떤 HTTP 캐시에도 저장되어서는 MUST NOT 합니다. 다만, 애플리케이션에 별도로 제공될 MAY 있습니다.

서버는 ":authority" 의사-헤더 필드에 서버가 권한을 가진 값을 포함해야 합니다(섹션 10.1 참조). 클라이언트는 서버가 권한이 없는 대상에 대해 PUSH_PROMISE를 보낸 경우 이를 스트림 오류로 처리해야 합니다(섹션 5.4.2), 오류 유형은 PROTOCOL_ERROR입니다.

중개자는 서버로부터 푸시를 수신하고 이를 클라이언트에 전달하지 않기로 선택할 수 있습니다. 즉, 푸시된 정보를 어떻게 활용할지는 중개자의 선택사항입니다. 또한 중개자는 서버의 추가 동작 없이 클라이언트에 추가 푸시를 만들 수도 있습니다.

클라이언트는 푸시를 할 수 없습니다. 따라서 서버는 PUSH_PROMISE 프레임을 수신하는 것을 연결 오류(섹션 5.4.1)로 처리해야 하며, 오류 유형은 PROTOCOL_ERROR입니다. 또한 서버는 SETTINGS_ENABLE_PUSH 설정을 0 이외의 값으로 설정해서는 안 됩니다.

8.4.1. 푸시 요청

서버 푸시는 의미상 서버가 요청에 응답하는 것과 동등하지만, 이 경우 그 요청이 서버에 의해 PUSH_PROMISE 프레임으로 전송된다는 점이 다릅니다.

PUSH_PROMISE 프레임은 서버가 해당 요청에 귀속시키는 제어 데이터와 완전한 요청 헤더 필드 집합을 포함하는 필드 블록을 포함합니다. 메시지 본문을 포함하는 요청으로는 응답을 푸시할 수 없습니다.

약속된 요청은 항상 클라이언트의 명시적 요청과 연관됩니다. 서버가 전송하는 PUSH_PROMISE 프레임들은 해당 명시적 요청의 스트림에서 전송됩니다. 또한 약속된 스트림 식별자를 포함하며, 이는 서버가 사용할 수 있는 스트림 식별자 중에서 선택됩니다(섹션 5.1.1 참조).

PUSH_PROMISE 및 이후의 CONTINUATION 프레임의 헤더 필드들은 완전하고 유효한 요청 헤더 필드 집합이어야 합니다(섹션 8.3.1). 서버는 ":method" 의사-헤더에 안전하고 캐시 가능한 메서드를 포함해야 합니다. 클라이언트가 유효한 헤더 집합을 포함하지 않거나 안전하지 않은 메서드를 식별하는 PUSH_PROMISE를 수신하면, 해당 약속된 스트림에서 섹션 5.4.2에 따라 RST_STREAM을 PROTOCOL_ERROR로 전송해야 합니다.

서버는 약속된 응답을 참조하는 어떤 프레임을 보내기 전에 가능하면 PUSH_PROMISE 프레임을 먼저 보내는 것이 권장됩니다. 이는 클라이언트가 PUSH_PROMISE 프레임을 받기 전에 리소스를 요청하는 경합을 피하는 데 도움이 됩니다.

예를 들어, 서버가 여러 이미지 파일에 대한 링크를 포함하는 문서 요청을 받았고 해당 이미지를 푸시하기로 선택한 경우, 이미지 링크를 포함하는 DATA 프레임을 보내기 전에 PUSH_PROMISE를 보내면 클라이언트는 리소스가 푸시될 것임을 발견하기 전에 해당 리소스를 요청하지 않게 됩니다.

PUSH_PROMISE 프레임은 클라이언트가 전송해서는 MUST NOT 합니다.

PUSH_PROMISE 프레임은 서버가 어떤 클라이언트-시작 스트림에서든 보낼 수 있지만, 해당 스트림은 서버 관점에서 "open" 또는 "half-closed (remote)" 상태여야 합니다. 또한 PUSH_PROMISE는 하나의 필드 블록을 구성하는 HEADERS 및 CONTINUATION 프레임 사이에 끼어들 수 없습니다.

PUSH_PROMISE를 전송하면 새로운 스트림이 생성되고 서버에게는 "reserved (local)", 클라이언트에게는 "reserved (remote)" 상태로 설정됩니다.

8.4.2. 푸시 응답

PUSH_PROMISE 프레임을 보낸 후, 서버는 약속된 스트림 식별자를 사용하는 서버-시작 스트림에서 푸시된 응답을 전송하기 시작할 수 있습니다. 서버는 이 스트림에서 섹션 8.1에 정의된 것과 동일한 순서의 프레임을 사용하여 HTTP 응답을 전송합니다. 이 스트림은 초기 HEADERS 프레임이 전송된 후 클라이언트에 대해 "half-closed (local)" 상태가 됩니다.

클라이언트가 PUSH_PROMISE를 수신하고 푸시 응답을 수락하기로 결정하면, 약속된 스트림이 닫힐 때까지 해당 응답에 대한 요청을 발행해서는 SHOULD NOT 합니다.

클라이언트가 어떤 이유로 푸시된 응답을 원하지 않거나 서버가 약속된 응답을 보내기 시작하는 데 너무 오래 걸리는 경우, 클라이언트는 RST_STREAM 프레임을 보내 푸시된 스트림을 취소할 수 있으며, 이때 CANCEL 또는 REFUSED_STREAM 코드를 사용할 수 있습니다.

클라이언트는 SETTINGS_MAX_CONCURRENT_STREAMS 설정을 사용하여 서버가 동시에 푸시할 수 있는 응답 수를 제한할 수 있습니다. 값이 0이면 서버가 응답을 푸시하는 데 필요한 스트림을 열 수 없게 됩니다. 그러나 예약된 스트림은 동시 스트림 한도에 포함되지 않으므로 PUSH_PROMISE로 스트림을 예약하는 것을 방지하지는 못합니다. 푸시된 리소스를 원하지 않는 클라이언트는 원하지 않는 예약된 스트림을 리셋하거나 SETTINGS_ENABLE_PUSH를 0으로 설정해야 합니다.

푸시된 응답을 받는 클라이언트는 서버가 권한이 있는지(섹션 10.1 참조) 또는 푸시된 응답을 제공한 프록시가 해당 요청에 대해 구성되어 있는지 검증해야 합니다. 예를 들어, 특정 인증서가 example.com에만 유효한 경우에는 https://www.example.org/doc에 대한 응답을 푸시할 수 없습니다.

PUSH_PROMISE 스트림에 대한 응답은 HEADERS 프레임으로 시작하여(이로써 서버 측에서 스트림이 "half-closed (remote)"가 되고 클라이언트 측은 "half-closed (local)"가 됨) END_STREAM 플래그가 설정된 프레임으로 끝나면 스트림은 "closed" 상태가 됩니다.

8.5. CONNECT 메서드

CONNECT 메서드(RFC 9110 섹션 9.3.6 참조)는 HTTP 연결을 원격 호스트로의 터널로 전환하는 데 사용됩니다. CONNECT는 주로 프록시와 함께 사용되어 원본 서버와 TLS 세션을 설정하고 "https" 리소스와 상호작용하는 데 사용됩니다.

HTTP/2에서는 CONNECT 메서드가 전체 연결을 터널로 전환하는 대신 단일 HTTP/2 스트림을 통해 원격 호스트로의 터널을 설정합니다. CONNECT 헤더 섹션은 섹션 8.3.1에 정의된 방식으로 구성되나 몇 가지 차이가 있습니다. 구체적으로:

":method" 의사-헤더 필드는 CONNECT로 설정됩니다.
":scheme" 및 ":path" 의사-헤더 필드는 MUST 생략되어야 합니다.
":authority" 의사-헤더 필드는 연결할 호스트와 포트를 포함합니다(이는 CONNECT 요청의 authority-form과 동등합니다).

이 제한을 준수하지 않는 CONNECT 요청은 잘못된 형식으로 간주됩니다(섹션 8.1.1).

CONNECT를 지원하는 프록시는 ":authority" 의사-헤더 필드에 지정된 호스트와 포트에 대해 TCP 연결을 설정합니다. 연결이 성공적으로 설정되면 프록시는 클라이언트에 2xx 계열 상태 코드를 포함하는 HEADERS 프레임을 보냅니다.

각 피어가 보낸 초기 HEADERS 프레임 이후의 모든 후속 DATA 프레임은 TCP 연결에서 전송되는 데이터에 해당합니다. 클라이언트가 보낸 DATA 프레임의 페이로드는 프록시가 TCP 서버로 전송하고, TCP 서버로부터 수신된 데이터는 프록시가 DATA 프레임으로 조립하여 전송합니다. 연결된 스트림에서 DATA 이외의 프레임 유형이나 스트림 관리 프레임(RST_STREAM, WINDOW_UPDATE, PRIORITY) 이외의 프레임은 전송해서는 안 되며 수신 시 스트림 오류로 처리되어야 합니다.

TCP 연결은 어느 쪽 피어에 의해든 닫힐 수 있습니다. DATA 프레임의 END_STREAM 플래그는 TCP FIN 비트와 동등하게 처리됩니다. 클라이언트는 END_STREAM 플래그가 설정된 DATA 프레임을 수신한 후 END_STREAM 플래그가 설정된 DATA 프레임을 전송할 것으로 기대됩니다. 프록시는 END_STREAM 플래그가 설정된 DATA 프레임을 받으면 마지막 TCP 세그먼트에 FIN 비트를 설정하여 데이터를 전송하고, FIN 비트를 가진 TCP 세그먼트를 수신하면 END_STREAM 플래그가 설정된 DATA 프레임을 전송합니다. 마지막 TCP 세그먼트나 DATA 프레임은 비어있을 수도 있습니다.

TCP 연결 오류는 RST_STREAM으로 신호됩니다. 프록시는 TCP 연결에서의 모든 오류(예: RST 비트가 설정된 TCP 세그먼트 수신)를 섹션 5.4.2에 따라 CONNECT_ERROR 유형의 스트림 오류로 처리해야 하며, 반대로 스트림 또는 HTTP/2 연결에서 오류를 감지하면 TCP RST 비트를 설정한 세그먼트를 보내야 합니다.

8.6. 정보 상태 응답(Upgrade 헤더 필드)

HTTP/2는 101 (Switching Protocols) 정보 상태 코드를 지원하지 않습니다(RFC 9110 섹션 15.2.2 참조).

101의 의미는 다중화된 프로토콜에는 적용되지 않습니다. 유사한 기능은 확장된 CONNECT(RFC8441)를 통해 제공될 수 있으며, 다른 프로토콜들도 HTTP/2가 사용하는 동일한 메커니즘을 사용하여 사용 협상을 할 수 있습니다(시작 방법은 섹션 3 참조).

8.7. 요청 신뢰성

일반적으로, HTTP 클라이언트는 오류 발생 시 비멱등(non-idempotent) 요청을 재시도할 수 없습니다. 이는 오류의 성격을 결정할 수 있는 수단이 없기 때문입니다. 오류 이전에 일부 서버 처리가 이루어졌을 수 있으므로 재시도 시 원치 않는 부작용이 발생할 수 있습니다.

HTTP/2는 클라이언트에게 요청이 처리되지 않았음을 보장하기 위한 두 가지 메커니즘을 제공합니다:

GOAWAY 프레임은 처리되었을 수 있는 최대 스트림 번호를 나타냅니다. 따라서 더 높은 번호의 스트림에 대한 요청은 안전하게 재시도할 수 있습니다.
REFUSED_STREAM 오류 코드는 RST_STREAM 프레임에 포함되어 스트림이 어떤 처리도 이루어지기 전에 닫혔음을 나타낼 수 있습니다. 리셋된 스트림에서 전송된 요청은 안전하게 재시도할 수 있습니다.

처리되지 않은 요청은 실패한 것이 아니므로, 클라이언트는 이러한 요청을 자동으로 재시도할 MAY 있습니다(비멱등 메서드도 포함).

서버는 스트림이 처리되지 않았음을 보장할 수 없는 경우 해당 스트림에 대해 그러한 표시를 해서는 MUST NOT 합니다. 만약 어떤 스트림에 대해 프레임들이 애플리케이션 레이어로 전달되었다면, 그 스트림에 대해 REFUSED_STREAM을 사용해서는 안 되며, 대신 GOAWAY 프레임은 해당 스트림 식별자보다 크거나 같은 값을 포함해야 합니다.

이 메커니즘들 외에도 PING 프레임은 클라이언트가 연결을 쉽게 테스트할 수 있게 합니다. 유휴 상태의 연결은 일부 중간 장치(예: NAT 또는 로드 밸런서)가 연결 바인딩을 조용히 제거할 수 있어 끊어질 수 있습니다. PING 프레임은 요청을 보내지 않고 연결이 여전히 활성 상태인지 안전하게 검사할 수 있게 해줍니다.

8.8. 예시

이 절에서는 동등한 HTTP/2 요청 및 응답을 보여주기 위해 HTTP/1.1 요청과 응답을 예시로 제시합니다.

8.8.1. 단순 요청

HTTP GET 요청은 제어 데이터와 메시지 본문이 없는 요청 헤더를 포함하므로 단일 HEADERS 프레임으로 전송되며, 직렬화된 요청 헤더 블록을 포함하는 0개 이상의 CONTINUATION 프레임이 뒤따를 수 있습니다. 아래의 HEADERS 프레임은 END_HEADERS 및 END_STREAM 플래그가 모두 설정되어 있으므로 CONTINUATION 프레임은 전송되지 않습니다.

  GET /resource HTTP/1.1           HEADERS
  Host: example.org          ==>     + END_STREAM
  Accept: image/jpeg                 + END_HEADERS
                                       :method = GET
                                       :scheme = https
                                       :authority = example.org
                                       :path = /resource
                                       host = example.org
                                       accept = image/jpeg

8.8.2. 단순 응답

동일하게, 제어 데이터와 응답 헤더만 포함하는 응답은 직렬화된 응답 헤더 블록을 포함하는 HEADERS 프레임(뒤에 0개 이상의 CONTINUATION 프레임 가능)으로 전송됩니다.

  HTTP/1.1 304 Not Modified        HEADERS
  ETag: "xyzzy"              ==>     + END_STREAM
  Expires: Thu, 23 Jan ...           + END_HEADERS
                                       :status = 304
                                       etag = "xyzzy"
                                       expires = Thu, 23 Jan ...

8.8.3. 복합 요청

메시지 본문을 포함하는 HTTP POST 요청은 하나의 HEADERS 프레임, 그 뒤를 따르는 0개 이상의 CONTINUATION 프레임(요청 헤더), 그리고 하나 이상의 DATA 프레임으로 전송됩니다. 마지막 CONTINUATION(또는 HEADERS) 프레임에는 END_HEADERS 플래그가 설정되고 마지막 DATA 프레임에는 END_STREAM 플래그가 설정됩니다.

  POST /resource HTTP/1.1          HEADERS
  Host: example.org          ==>     - END_STREAM
  Content-Type: image/jpeg           - END_HEADERS
  Content-Length: 123                  :method = POST
                                       :authority = example.org
                                       :path = /resource
  {binary data}                        :scheme = https

                                   CONTINUATION
                                     + END_HEADERS
                                       content-type = image/jpeg
                                       host = example.org
                                       content-length = 123

                                   DATA
                                     + END_STREAM
                                   {binary data}

어떤 필드 라인에 기여하는 데이터는 필드 블록 조각들 사이에 분산될 수 있습니다. 이 예에서 필드 라인을 프레임에 할당한 방식은 단지 예시입니다.

8.8.4. 본문을 포함한 응답

메시지 본문을 포함하는 응답은 HEADERS 프레임(및 0개 이상의 CONTINUATION 프레임)으로 시작하고, 하나 이상의 DATA 프레임이 뒤따르며, 시퀀스의 마지막 DATA 프레임에 END_STREAM 플래그가 설정됩니다.

  HTTP/1.1 200 OK                  HEADERS
  Content-Type: image/jpeg   ==>     - END_STREAM
  Content-Length: 123                + END_HEADERS
                                       :status = 200
  {binary data}                        content-type = image/jpeg
                                       content-length = 123

                                   DATA
                                     + END_STREAM
                                   {binary data}

8.8.5. 정보 응답

101을 제외한 1xx 상태 코드를 사용하는 정보 응답은 HEADERS 프레임으로 전송되며 뒤에 0개 이상의 CONTINUATION 프레임이 올 수 있습니다.

트레일러 섹션은 요청 또는 응답 필드 블록과 모든 DATA 프레임이 전송된 후에 필드 블록으로 전송됩니다. 트레일러 섹션을 시작하는 HEADERS 프레임은 END_STREAM 플래그가 설정되어야 합니다.

다음 예시는 Expect 헤더 필드에 "100-continue" 토큰이 포함된 요청에 대한 100 (Continue) 상태 코드와 트레일러 섹션을 모두 포함합니다:

  HTTP/1.1 100 Continue            HEADERS
  Extension-Field: bar       ==>     - END_STREAM
                                     + END_HEADERS
                                       :status = 100
                                       extension-field = bar

  HTTP/1.1 200 OK                  HEADERS
  Content-Type: image/jpeg   ==>     - END_STREAM
  Transfer-Encoding: chunked         + END_HEADERS
  Trailer: Foo                         :status = 200
                                       content-type = image/jpeg
  123                                  trailer = Foo
  {binary data}
  0                                DATA
  Foo: bar                           - END_STREAM
                                   {binary data}

                                   HEADERS
                                     + END_STREAM
                                     + END_HEADERS
                                       foo = bar

9. HTTP/2 연결

이 섹션은 상호운용성을 향상시키고, 알려진 보안 취약점에 대한 노출을 줄이며, 구현 차이를 줄이기 위한 HTTP의 특성들을 개괄합니다.

9.1. 연결 관리

HTTP/2 연결은 지속적입니다. 최적의 성능을 위해 클라이언트는 서버와의 추가 통신이 불필요하다고 판단되거나(예: 사용자가 특정 웹 페이지에서 이동한 경우) 서버가 연결을 닫을 때까지 연결을 닫지 않는 것이 기대됩니다.

클라이언트는 URI로부터 파생된 호스트, 선택된 alternative service 또는 구성된 프록시에 대해 주어진 호스트-포트 쌍으로 하나 이상의 HTTP/2 연결을 열어서는 안 됩니다(SHOULD NOT).

클라이언트는 사용 가능한 스트림 식별자 공간이 거의 소진되어 대체 연결을 만들거나(섹션 5.1.1), TLS 연결의 키 재료를 갱신하거나, 오류가 발생한 연결을 대체하기 위해 추가 연결을 생성할 수 있습니다(섹션 5.4.1).

클라이언트는 서로 다른 Server Name Indication 값이나 서로 다른 TLS 클라이언트 인증서를 사용하여 동일한 IP 주소와 TCP 포트에 대해 여러 연결을 열 수 있으나(MAY), 동일한 구성으로 여러 연결을 생성하는 것은 피하는 것이 좋습니다(SHOULD).

서버는 가능한 한 오랫동안 열린 연결을 유지하는 것이 권장되지만, 필요하면 유휴 연결을 종료할 수 있습니다. 어느 쪽 엔드포인트든 전송 계층의 TCP 연결을 닫기로 선택할 때 종료하는 엔드포인트는 먼저 GOAWAY 프레임(섹션 6.8)을 보내어 양쪽 엔드포인트가 이전에 전송된 프레임이 처리되었는지 신뢰성 있게 판단하고 필요한 잔여 작업을 우아하게 완료하거나 종료할 수 있도록 하는 것이 바람직합니다(SHOULD).

9.1.1. 연결 재사용

CONNECT 메서드(섹션 8.5)를 사용하여 직접 또는 터널을 통해 생성된 원본 서버에 대한 연결은 서로 다른 URI authority 구성요소를 가진 요청들에 대해 재사용할 수 있습니다(MAY). 원본 서버가 권한을 가지고 있는 한 연결은 재사용될 수 있습니다(섹션 10.1). TLS가 없는 TCP 연결의 경우에는 호스트가 동일한 IP 주소로 해결(resolved)되는지에 따라 달라집니다.

"https" 자원에 대해서는 연결 재사용이 URI의 호스트에 대해 유효한 인증서를 갖고 있는지에도 의존합니다. 서버가 제시한 인증서는 클라이언트가 해당 호스트에 대해 새 TLS 연결을 형성할 때 수행하는 모든 검사를 충족해야 합니다(MUST). 단일 인증서는 여러 오리진에 대한 권한을 확립하는 데 사용될 수 있습니다. 상세한 권한 판단 방법은 RFC 9110 섹션 4.3에 설명되어 있습니다.

일부 배포 환경에서는 여러 오리진에 대해 동일한 연결을 재사용하면 요청이 잘못된 원본 서버로 향할 수 있습니다. 예를 들어, TLS 종단 처리를 수행하는 미들박스가 TLS의 Server Name Indication 확장을 사용해 오리진 서버를 선택하는 경우가 그렇습니다. 이로 인해 클라이언트가 의도한 대상이 아닌 서버로 요청을 보낼 가능성이 생길 수 있습니다(그럼에도 서버는 다른 면에서 권한이 있을 수 있음).

서버가 클라이언트가 연결을 재사용하기를 원하지 않는 경우, 해당 요청에 대해 자신이 권한을 가지지 않음을 나타내기 위해 421 (Misdirected Request) 상태 코드를 응답으로 보낼 수 있습니다(자세한 내용은 RFC 9110 섹션 15.5.20 참조).

프록시 사용을 위해 구성된 클라이언트는 해당 프록시로의 요청을 단일 연결을 통해 보냅니다. 즉, 프록시를 통해 전송되는 모든 요청은 프록시로의 연결을 재사용합니다.

9.2. TLS 기능의 사용

HTTP/2 구현체는 TLS 위에서의 HTTP/2에 대해 TLS version 1.2 이상을 사용해야 합니다(MUST). TLS 일반 사용 지침([TLSBCP])을 따르는 것이 권장되며, HTTP/2에 특화된 몇 가지 추가 제한이 있습니다(SHOULD).

TLS 구현체는 TLS 확장의 Server Name Indication (SNI)를 지원해야 합니다(MUST). 서버가 도메인 이름으로 식별되는 경우(domain name) 클라이언트는 대상 호스트를 나타내는 대체 메커니즘을 사용하지 않는 한 server_name TLS 확장을 반드시 전송해야 합니다(MUST).

TLS 1.3을 협상하는 HTTP/2 배포에 대한 요구사항은 섹션 9.2.3에 포함되어 있습니다. TLS 1.2 배포는 9.2.1 및 9.2.2의 요구사항을 따릅니다. 구현체는 준수를 만족하는 기본값을 제공하는 것이 권장되지만, 최종적으로 배포 환경이 준수 책임을 집니다.

9.2.1. TLS 1.2 기능

이 절은 HTTP/2와 함께 사용할 수 있는 TLS 1.2 기능 집합에 대한 제한을 설명합니다. 배포 제약으로 인해 이러한 제한이 충족되지 않을 때 TLS 협상을 실패시키지 못할 수도 있습니다. 요구사항을 충족하지 않는 HTTP/2 연결에 대해 엔드포인트는 즉시 연결을 종료할 수 있으며(MAY) 이 경우 연결 오류(섹션 5.4.1) 유형으로 INADEQUATE_SECURITY를 보낼 수 있습니다.

TLS 1.2 위의 HTTP/2 배포는 압축을 비활성화해야 합니다(MUST). TLS 압축은 노출될 수 있는 정보를 유발할 수 있습니다([RFC3749]). 일반적인 압축은 HTTP/2가 제공하는 문맥 인지 압축 기능에 비해 불필요하므로 사용하지 않아야 합니다.

TLS 1.2 위의 HTTP/2 배포는 재협상(renegotiation)을 비활성화해야 합니다(MUST). 엔드포인트는 TLS 재협상을 프로토콜 오류(PROTOCOL_ERROR) 유형의 연결 오류로 처리해야 합니다(MUST). 단, 재협상 비활성화로 인해 장기 연결이 암호화된 메시지 수의 한계로 인해 사용할 수 없게 될 수 있습니다.

엔드포인트는 클라이언트 자격증명 보호를 위해 재협상을 사용할 수 있으나(MAY), 모든 재협상은 연결 사전(preface)을 보내기 전에 발생해야 하며(MUST) 서버는 연결 직후 재협상 요청이 보이면 클라이언트 인증서를 요청하는 것이 바람직합니다(SHOULD).

이는 특정 보호된 자원에 대한 요청에 응답하여 재협상을 사용하는 것을 사실상 방지합니다. 향후 명세는 이 사용 사례를 지원할 방법을 제공할 수 있습니다. 또는 서버는 클라이언트에게 재협상을 지원하는 프로토콜 사용을 요청하기 위해 HTTP_1_1_REQUIRED 유형의 오류를 사용할 수 있습니다.

구현체는 임시 키 교환(ephemeral key exchange)에 대해 DHE(유한체 Diffie-Hellman)를 사용하는 암호 제품군의 경우 최소 2048비트, ECDHE(타원곡선 Diffie-Hellman)를 사용하는 암호 제품군의 경우 최소 224비트의 키 교환 크기를 지원해야 합니다(MUST). 클라이언트는 최대 4096비트의 DHE 크기를 받아들여야 합니다(MUST). 엔드포인트는 하한보다 작은 키 크기 협상을 INADEQUATE_SECURITY 유형의 연결 오류로 처리할 수 있습니다(MAY).

9.2.2. TLS 1.2 암호 제품군

TLS 1.2 위의 HTTP/2 배포는 부록 A(Prohibited TLS 1.2 Cipher Suites)에 나열된 금지된 암호 제품군을 사용해서는 SHOULD NOT 합니다.

엔드포인트는 금지된 암호 제품군이 협상된 경우 INADEQUATE_SECURITY 유형의 연결 오류를 생성하기로 선택할 수 있습니다(MAY). 금지된 암호 제품군을 사용하기로 선택한 배포는 해당 암호 제품군을 수락할 것으로 알려진 피어 집합과만 상호작용할 경우에만 연결 오류를 피할 수 있습니다.

구현체는 금지되지 않은 암호 제품군의 협상에 대해 이 오류를 발생시켜서는 안 됩니다(MUST NOT). 따라서 클라이언트가 금지되지 않은 암호 제품군을 제안하면, HTTP/2에서 해당 암호 제품군을 사용할 준비가 되어 있어야 합니다.

금지된 암호 제품군 목록에는 TLS 1.2가 필수로 요구하는 암호 제품군도 포함되어 있어, TLS 1.2 배포가 허용되는 암호 제품군 집합이 서로 교집합이 없을 수 있습니다. 이 문제를 피하기 위해, TLS 1.2를 사용하는 HTTP/2 배포는 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256을 P-256 타원곡선과 함께 반드시 지원해야 합니다(MUST).

클라이언트는 HTTP/2를 지원하지 않는 서버와의 연결을 허용하기 위해 금지된 암호 제품군을 광고할 수 있습니다. 이는 서버가 HTTP/1.1을 선택하도록 함으로써 연결을 허용하지만, 애플리케이션 프로토콜과 암호 제품군이 독립적으로 선택될 경우 금지된 암호 제품군으로 HTTP/2가 협상될 위험이 있습니다.

9.2.3. TLS 1.3 기능

TLS 1.3에는 이전 버전에서 사용할 수 없었던 여러 기능이 포함되어 있습니다. 이 절은 이러한 기능들의 사용에 대해 논의합니다.

HTTP/2 서버는 핸드셰이크 이후의 TLS 1.3 CertificateRequest 메시지를 전송해서는 안 됩니다(MUST NOT). HTTP/2 클라이언트는 TLS 핸드셰이크 이후의 CertificateRequest 메시지를 PROTOCOL_ERROR 유형의 연결 오류로 처리해야 합니다(MUST).

핸드셰이크 이후 인증(post-handshake authentication)에 대한 금지는 클라이언트가 "post_handshake_auth" TLS 확장을 제공했더라도 적용됩니다. 이 기능은 다른 프로토콜에서 사용될 수 있도록 독립적으로 광고될 수 있으나, 확장의 포함이 HTTP/2 내에서의 지원을 의미하지는 않습니다.

[TLS13]는 NewSessionTicket 및 KeyUpdate와 같은 다른 핸드셰이크 이후 메시지를 정의하며, 이들은 HTTP/2와 직접 상호작용하지 않으므로 사용할 수 있습니다. TLS 메시지 유형의 사용이 애플리케이션-레이어 프로토콜과의 상호작용에 의존하지 않는 한, 해당 TLS 메시지는 핸드셰이크 완료 후 전송될 수 있습니다.

TLS early data는 [RFC8470]의 지침을 준수하는 한 요청 전송에 사용할 수 있습니다(MAY). 클라이언트는 초기 서버 설정 값을 가정하여 early data에서 요청을 전송합니다.

10. 보안 고려사항

TLS의 사용은 이 프로토콜의 많은 보안 속성을 제공하는 데 필요합니다. 이 섹션의 많은 주장들은 Section 9.2에 설명된 대로 TLS가 사용되지 않으면 성립하지 않습니다.

10.1. 서버 권한

HTTP/2는 특정 응답을 제공하는 서버가 권한이 있는지 판단하기 위해 HTTP의 권한(authority) 정의에 의존합니다(자세한 내용은 RFC 9110 섹션 4.3 참조). 이는 "http" URI 스킴에 대해 로컬 이름 해석 및 "https" 스킴에 대해 인증된 서버 신원에 의존합니다.

10.2. 교차-프로토콜 공격

교차-프로토콜 공격에서 공격자는 클라이언트를 다른 프로토콜을 이해하는 서버로 트랜잭션을 시작하게 만듭니다. 공격자는 해당 트랜잭션이 두 번째 프로토콜에서 유효한 트랜잭션으로 보이도록 만들 수 있습니다. 웹 문맥의 기능과 결합되면, 이는 사설 네트워크의 적절히 보호되지 않은 서버와 상호작용하기 위해 악용될 수 있습니다.

ALPN 식별자를 사용한 TLS 핸드셰이크 완료는 교차-프로토콜 공격에 대한 충분한 보호로 간주될 수 있습니다. ALPN은 서버가 HTTP/2 진행에 동의함을 긍정적으로 표시하여 다른 TLS 기반 프로토콜에 대한 공격을 방지합니다.

TLS의 암호화는 공격자가 평문 프로토콜에 대한 교차-프로토콜 공격에 사용할 데이터를 제어하기 어렵게 만듭니다.

평문 버전의 HTTP/2는 교차-프로토콜 공격에 대해 최소한의 보호만 제공합니다. 연결 프리페이스(섹션 3.4)에는 HTTP/1.1 서버를 혼란시키도록 설계된 문자열이 포함되어 있지만, 다른 프로토콜에 대한 특별한 보호는 제공되지 않습니다.

10.3. 중개자 캡슐화 공격

HPACK은 다른 HTTP 버전에서 구분자로 처리될 수 있는 필드 이름과 값을 인코딩할 수 있게 허용합니다. HTTP/2 요청 또는 응답을 변환하는 중개자는 메시지를 다른 HTTP 버전으로 변환하기 전에 섹션 8.2의 규칙에 따라 필드를 검증해야 합니다(MUST). 잘못된 구분자를 포함한 필드를 변환하면 수신자가 메시지를 잘못 해석하도록 만들 수 있으며, 이는 공격자에게 악용될 수 있습니다.

섹션 8.2는 의사-헤더 필드의 검증에 대한 구체적 규칙을 포함하지 않습니다. 이러한 필드 값이 사용되는 경우 추가 검증이 필요합니다. 특히 ":scheme", ":authority" 및 ":path"가 하나의 URI 문자열로 결합될 때 추가 검증이 필요합니다([RFC3986]). 유사한 문제는 해당 URI 또는 ":path"가 ":method"와 결합되어 요청 라인을 구성할 때도 발생할 수 있습니다. 단순 연결은 입력 값이 완전히 검증되지 않는 한 안전하지 않습니다.

중개자는 필드 이름이나 값이 유효하지 않은 필드를 다른 이유로 거부할 수 있습니다 — 특히 RFC 9110의 섹션 5에 정의된 HTTP ABNF 문법에 부합하지 않는 필드들입니다. 최소한의 검증(섹션 8.2)이 수행되지 않는 중개자는 유효하지 않은 필드 이름 또는 값을 포함한 메시지를 전달할 수 있습니다.

중개자는 전달 전에 제거해야 하는 필드를 수신하면(예: RFC 9110 섹션 7.6.1 참조) 해당 헤더 필드를 제거하거나 대체해야 합니다(MUST). 또한 중개자는 Content-Length 필드를 포함한 메시지를 전달할 때 메시지가 올바르게 형성되었는지 주의해야 합니다(섹션 8.1.1). 이는 메시지가 이후 HTTP/1.1로 변환되더라도 프레이밍이 올바르게 유지되도록 보장합니다.

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

푸시된 응답은 클라이언트의 명시적 요청을 가지고 있지 않습니다; 요청은 서버가 PUSH_PROMISE 프레임에서 제공합니다.

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

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

원본 서버가 권한을 갖지 않은 푸시된 응답은 사용되거나 캐시되어서는 안 됩니다(MUST NOT).

10.5. 서비스 거부 고려사항

HTTP/2 연결은 HTTP/1.1 연결보다 더 많은 자원 할당을 요구할 수 있습니다. 필드 섹션 압축과 흐름 제어는 더 많은 상태를 유지해야 하며, 이러한 기능의 설정은 메모리 약속을 엄격히 제한하도록 보장합니다.

PUSH_PROMISE 프레임의 수는 동일한 방식으로 제약되지 않습니다. 서버 푸시를 수용하는 클라이언트는 "reserved (remote)" 상태로 허용되는 스트림 수를 제한해야 합니다(SHOULD). 과도한 수의 서버 푸시 스트림은 섹션 5.4.2의 ENHANCE_YOUR_CALM 유형의 스트림 오류로 처리할 수 있습니다.

여러 HTTP/2 구현이 서비스 거부 취약점이 있음이 발견되었습니다([NFLX-2019-002]). 아래는 구현체가 서비스 거부 공격에 취약해질 수 있는 알려진 방식들의 목록입니다:

아웃바운드 대기 프레임을 비효율적으로 추적하면 공격자가 대량의 프레임을 송신 대기열에 쌓이게 하여 과부하를 일으킬 수 있습니다. 피어는 여러 기법으로 대량의 프레임 생성을 유발할 수 있습니다:
- WINDOW_UPDATE 프레임에 작은 증가량을 제공하면 송신자가 많은 수의 DATA 프레임을 생성하게 만들 수 있습니다.
- 엔드포인트는 PING 프레임에 응답해야 합니다.
- 각 SETTINGS 프레임은 확인 응답을 필요로 합니다.
- 잘못된 요청(또는 서버 푸시)은 피어가 RST_STREAM 프레임을 응답으로 보내게 할 수 있습니다.
공격자가 HTTP/2 계층에서 많은 양의 흐름 제어 크레딧을 제공하지만 TCP 계층에서는 크레딧을 보류함으로써 프레임 전송을 막을 수 있습니다. TCP 한계를 고려하지 않고 프레임을 생성하고 보관하는 엔드포인트는 자원 소진에 취약할 수 있습니다.
작거나 비어 있는 많은 수의 프레임은 피어가 프레임 헤더 처리에 많은 시간을 소비하게 만들 수 있습니다. 다만 스트림 종료 시 보낼 수 있는 빈 DATA 또는 CONTINUATION 프레임과 같이 작은 프레임의 일부 사용은 정당할 수 있습니다.
SETTINGS 프레임은 피어가 추가 처리 시간을 소비하도록 악용될 수 있습니다. 이는 설정을 쓸데없이 변경하거나 여러 정의되지 않은 설정을 보내거나 동일한 설정을 한 프레임 내에서 여러 번 변경함으로써 발생할 수 있습니다.
PRIORITY 프레임으로 재우선순위 처리를 하는 것은 상당한 처리 시간을 필요로 하며 많은 PRIORITY 프레임이 전송되면 과부하로 이어질 수 있습니다.
필드 섹션 압축은 공격자가 처리 자원을 낭비하도록 하는 기회를 제공합니다; 잠재적 남용에 대한 자세한 내용은 HPACK 명세([COMPRESSION])를 참조하십시오.
SETTINGS에서의 제한은 즉시 줄일 수 없으므로 엔드포인트는 피어의 동작으로 인해 새 제한을 초과할 위험에 노출됩니다. 특히 연결을 설정한 직후에는 서버가 설정한 제한을 클라이언트가 알 수 없어 쉽게 초과될 수 있습니다.

서비스 거부에 악용될 수 있는 대부분의 기능 — 예를 들어 SETTINGS 변경, 작은 프레임, 필드 섹션 압축 — 은 정당한 사용 사례도 있습니다. 이러한 기능들은 불필요하거나 과도하게 사용될 때만 부담이 됩니다.

이러한 기능의 사용을 모니터링하지 않는 엔드포인트는 서비스 거부 위험에 노출됩니다. 구현체는 이러한 기능 사용을 추적하고 사용 한도를 설정해야 합니다(SHOULD). 의심스러운 활동은 ENHANCE_YOUR_CALM 유형의 연결 오류로 처리할 수 있습니다(MAY).

10.5.1. 필드 블록 크기 제한

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

엔드포인트는 SETTINGS_MAX_HEADER_LIST_SIZE를 사용하여 피어에게 비압축 필드 블록 크기에 적용될 수 있는 한도를 알릴 수 있습니다. 이 설정은 권고적(advisory)이므로 엔드포인트는 이 한도를 초과하는 필드 블록을 보낼 수 있으며, 그 결과 요청 또는 응답이 잘못된 형식으로 처리될 위험을 감수할 수 있습니다. 이 설정은 연결별이므로 어떤 요청이나 응답이 더 낮은 알 수 없는 한도를 가진 홉을 만날 가능성이 있습니다. 중개자는 서로 다른 피어가 제시한 값을 전달하여 이 문제를 회피하려 시도할 수 있지만, 그렇게 할 의무는 없습니다.

서버가 처리할 수 있는 것보다 큰 필드 블록을 수신하면 HTTP 431(헤더 필드가 너무 큼) 상태 코드를 보낼 수 있습니다([RFC6585]). 클라이언트는 처리할 수 없는 응답을 폐기할 수 있습니다. 필드 블록은 연결 상태를 일관되게 유지하기 위해 처리되어야 합니다(MUST), 단 연결이 닫히는 경우는 제외입니다.

10.5.2. CONNECT 관련 문제

CONNECT 메서드는 프록시에 불균형적인 부하를 생성할 수 있습니다. 스트림 생성은 TCP 연결의 생성 및 유지에 비해 상대적으로 비용이 적기 때문입니다. 또한 프록시는 CONNECT 요청을 운반한 스트림이 닫힌 이후에도 아웃고잉 TCP 연결을 위해 자원을 유지할 수 있으며, 이는 해당 연결이 TIME_WAIT 상태에 있기 때문입니다. 따라서 프록시는 SETTINGS_MAX_CONCURRENT_STREAMS만으로 CONNECT 요청이 소비하는 자원을 제한할 수 없습니다.

10.6. 압축 사용

압축은 공격자가 동일한 문맥에서 공격자가 제어하는 데이터와 비밀 데이터를 함께 압축할 때 비밀 데이터를 복구하도록 허용할 수 있습니다. HTTP/2는 필드 라인(섹션 4.3)의 압축을 가능하게 하며, 다음의 우려사항은 HTTP 압축된 콘텐츠 인코딩의 사용에도 적용됩니다.

웹의 특성을 악용하는 압축 공격(예: [BREACH])이 입증되어 있습니다. 공격자는 다양한 평문을 포함하는 여러 요청을 유도하고 결과 암호문 길이를 관찰하여, 비밀에 대한 추측이 맞을 때 길이가 짧아지는 것을 이용합니다.

보안 채널로 통신하는 구현체는 기밀 데이터와 공격자가 제어하는 데이터를 동일한 압축 컨텍스트에서 압축하지 않아야 합니다(MUST NOT), 또는 각 데이터 원천에 대해 별도의 압축 사전(dictionary)을 사용해야 합니다. 데이터의 출처를 신뢰성 있게 판단할 수 없는 경우 압축을 사용해서는 안 됩니다. TLS가 제공하는 일반적인 스트림 압축은 HTTP/2에서 사용해서는 안 됩니다 (섹션 9.2 참조).

헤더 필드 압축에 대한 추가 고려사항은 HPACK 명세([COMPRESSION])에 설명되어 있습니다.

10.7. 패딩 사용

HTTP/2 내의 패딩은 TLS와 같은 일반 목적 패딩을 대체하기 위한 것이 아닙니다([TLS13]). 중복된 패딩은 오히려 역효과를 낼 수 있습니다. 올바른 적용은 패딩되는 데이터에 대한 구체적 지식을 필요로 할 수 있습니다.

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

패딩은 프레임 내용의 정확한 크기를 흐리게 하여 HTTP 내의 특정 공격(예: 공격자가 제어하는 평문과 비밀 데이터를 모두 포함하는 압축된 콘텐츠에 대한 공격)을 완화하는 데 사용될 수 있습니다.

패딩의 사용은 즉시 명확하게 보이는 만큼의 보호를 제공하지 않을 수 있습니다. 최선의 경우 패딩은 공격자가 관찰해야 하는 프레임 수를 증가시켜 길이 정보를 추론하기 어렵게 만들 뿐입니다. 잘못 구현된 패딩 스킴은 쉽게 우회될 수 있습니다. 예를 들어 예측 가능한 분포를 가진 무작위 패딩은 거의 보호를 제공하지 않으며, 프레임 페이로드를 고정 크기로 패딩하면 크기가 고정 경계를 넘을 때 정보가 노출될 수 있습니다.

중개자는 DATA 프레임의 패딩을 유지하는 것이 권장되지만(SHOULD), HEADERS 및 PUSH_PROMISE 프레임의 패딩은 제거할 수 있습니다(MAY). 중개자가 프레임의 패딩 양을 변경하는 합당한 이유는 패딩이 제공하는 보호를 개선하기 위함일 수 있습니다.

10.8. 개인정보 보호 고려사항

HTTP/2의 여러 특성은 관찰자에게 단일 클라이언트나 서버의 동작을 시간에 따라 상관관계로 연결할 기회를 제공합니다. 여기에는 설정 값, 흐름 제어 창 관리 방식, 스트림에 대한 우선순위 할당 방식, 자극에 대한 반응의 타이밍, 설정으로 제어되는 기능의 처리 방식 등이 포함됩니다.

이러한 특성들이 행동에서 관찰 가능한 차이를 만들면, 이는 특정 클라이언트를 식별하기 위한 지문(fingerprinting)의 근거로 사용될 수 있습니다(RFC 6973 섹션 3.2 참조).

HTTP/2가 단일 TCP 연결 사용을 선호하는 것은 사이트에서 사용자의 활동을 연관시키는 것을 가능하게 합니다. 서로 다른 오리진에 대해 연결을 재사용하면 오리진 간 추적이 가능해집니다.

PING 및 SETTINGS 프레임은 즉각적인 응답을 요구하므로, 이들은 엔드포인트가 피어에 대한 지연(latency)을 측정하는 데 사용될 수 있습니다. 이는 특정 시나리오에서 프라이버시에 영향을 미칠 수 있습니다.

10.9. 원격 타이밍 공격

원격 타이밍 공격은 서버가 비밀을 사용하여 요청을 처리할 때 소요 시간의 변동을 관찰하여 비밀을 추출합니다. HTTP/2는 동시 요청 생성 및 처리를 가능하게 하여 공격자가 요청 처리 시작 시점을 더 잘 제어할 수 있게 합니다. 여러 HTTP/2 요청은 동일한 IP 패킷이나 TLS 레코드에 포함될 수 있으므로, HTTP/2는 요청 전달의 변동성을 제거하여 원격 타이밍 공격을 더 효율적으로 만들 수 있습니다.

타이밍 공격에 대한 최선의 방어는 처리 시간이 비밀 값에 의존하지 않도록 하는 것입니다.

11. IANA 고려사항

이 HTTP/2 개정판은 HTTP2-Settings 헤더 필드와 h2c 업그레이드 토큰(둘 다 [RFC7540]에서 정의됨)을 더 이상 사용되지 않음으로 지정합니다.

섹션 11은 [RFC7540]에서 PRI HTTP 메서드와 함께 h2 및 h2c ALPN 식별자를 등록했습니다. RFC 7540는 또한 프레임 유형, 설정 및 오류 코드에 대한 레지스트리를 확립했습니다. 이러한 등록 및 레지스트리는 HTTP/2에 적용되며, 이 문서에서 재정의되지는 않습니다.

IANA는 다음 레지스트리들에서 RFC 7540에 대한 참조를 이 문서를 가리키도록 업데이트했습니다: "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs", "HTTP/2 Frame Type", "HTTP/2 Settings", "HTTP/2 Error Code", 및 "HTTP Method Registry". PRI 메서드의 등록은 섹션 3.4를 가리키도록 업데이트되었으며; 다른 모든 섹션 번호는 변경되지 않았습니다.

IANA는 RFC 7540에서 실험적 사용(Experimental Use)으로 예약되었던 "HTTP/2 Frame Type" 및 "HTTP/2 Settings" 레지스트리의 해당 부분에 대한 정책을 변경했습니다. 이들 레지스트리 부분은 각 레지스트리의 나머지 부분과 동일한 정책으로 운영됩니다.

11.1. HTTP2-Settings 헤더 필드 등록

이 섹션은 섹션 11.5에서 [RFC7540]에 의해 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 등록된 HTTP2-Settings 헤더 필드를 더 이상 사용되지 않음으로 표시합니다. 이 기능은 제거되었습니다: 섹션 3.1을 참조하세요. 등록은 RFC 9110 섹션 18.4에서 요구하는 세부사항을 포함하도록 다음과 같이 업데이트됩니다:

필드 이름:: HTTP2-Settings
상태:: 사용 중단됨
참조:: 섹션 3.2.1 of [RFC7540]
주석:: 더 이상 사용되지 않음; 이 문서의 섹션 11.1을 참조하세요.

11.2. h2c 업그레이드 토큰

이 섹션은 섹션 11.8에서 [RFC7540]에 의해 "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"에 등록된 h2c 업그레이드 토큰을 더 이상 사용되지 않음으로 기록합니다. 이 기능은 제거되었습니다: 섹션 3.1을 참조하세요. 등록은 다음과 같이 업데이트됩니다:

값:: h2c
설명:: (더 이상 사용되지 않음) Hypertext Transfer Protocol version 2 (HTTP/2)
예상 버전 토큰:: 없음
참조:: 섹션 3.1 of this document

12. 참고문헌

12.1. 규범적 참조

[CACHING]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Caching”, STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[COMPRESSION]: Peon, R. and H. Ruellan, “HPACK: Header Compression for HTTP/2”, RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[COOKIE]: Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[HTTP]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[QUIC]: Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC8174]: Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422]: Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier”, RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8470]: Thomson, M., Nottingham, M., and W. Tarreau, “Using Early Data in HTTP”, RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.
[TCP]: Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[TLS-ALPN]: Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[TLS-ECDHE]: Rescorla, E., “TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)”, RFC 5289, DOI 10.17487/RFC5289, August 2008, <https://www.rfc-editor.org/info/rfc5289>.
[TLS-EXT]: Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[TLS12]: Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[TLS13]: Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLSBCP]: Sheffer, Y., Holz, R., and P. Saint-Andre, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”, BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

12.2. 참고자료

[ALT-SVC]: Nottingham, M., McManus, P., and J. Reschke, “HTTP Alternative Services”, RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[BREACH]: Gluck, Y., Harris, N., and A. Prado, “BREACH: Reviving the CRIME Attack”, July 2013, <https://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, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[HTTP-PRIORITY]: Oku, K. and L. Pardue, “Extensible Prioritization Scheme for HTTP”, RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/info/rfc9218>.
[HTTP/1.1]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[NFLX-2019-002]: Netflix, “HTTP/2 Denial of Service Advisory”, August 2019, <https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md>.
[PRIVACY]: Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, “Privacy Considerations for Internet Protocols”, RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC1122]: Braden, R., Ed., “Requirements for Internet Hosts - Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC3749]: Hollenbeck, S., “Transport Layer Security Protocol Compression Methods”, RFC 3749, DOI 10.17487/RFC3749, May 2004, <https://www.rfc-editor.org/info/rfc3749>.
[RFC6125]: Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)”, RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6585]: Nottingham, M. and R. Fielding, “Additional HTTP Status Codes”, RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/info/rfc6585>.
[RFC7323]: Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., “TCP Extensions for High Performance”, RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7540]: Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC8441]: McManus, P., “Bootstrapping WebSockets with HTTP/2”, RFC 8441, DOI 10.17487/RFC8441, September 2018, <https://www.rfc-editor.org/info/rfc8441>.
[RFC8740]: Benjamin, D., “Using TLS 1.3 with HTTP/2”, RFC 8740, DOI 10.17487/RFC8740, February 2020, <https://www.rfc-editor.org/info/rfc8740>.
[TALKING]: Huang, L., Chen, E., Barth, A., Rescorla, E., and C. Jackson, “Talking to Yourself for Fun and Profit”, 2011, <https://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf>.

부록 A. 금지된 TLS 1.2 Cipher Suites

HTTP/2 구현은 MAY 다음의 암호 모음들 중 어느 하나가 TLS 1.2로 협상되는 것을 연결 오류(섹션 5.4.1)의 유형 INADEQUATE_SECURITY로 처리할 수 있습니다:

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_RC4_128_SHA
TLS_KRB5_WITH_IDEA_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_IDEA_CBC_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_PSK_WITH_NULL_SHA
TLS_DHE_PSK_WITH_NULL_SHA
TLS_RSA_PSK_WITH_NULL_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
TLS_PSK_WITH_RC4_128_SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_RC4_128_SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_RC4_128_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_DH_DSS_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_SEED_CBC_SHA
TLS_DHE_DSS_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_DH_anon_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_NULL_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
TLS_DHE_PSK_WITH_NULL_SHA256
TLS_DHE_PSK_WITH_NULL_SHA384
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
TLS_RSA_PSK_WITH_NULL_SHA256
TLS_RSA_PSK_WITH_NULL_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_anon_WITH_NULL_SHA
TLS_ECDH_anon_WITH_RC4_128_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA
TLS_SRP_SHA_WITH_AES_128_CBC_SHA
TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
TLS_SRP_SHA_WITH_AES_256_CBC_SHA
TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_RC4_128_SHA
TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
TLS_ECDHE_PSK_WITH_NULL_SHA
TLS_ECDHE_PSK_WITH_NULL_SHA256
TLS_ECDHE_PSK_WITH_NULL_SHA384
TLS_RSA_WITH_ARIA_128_CBC_SHA256
TLS_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
TLS_RSA_WITH_ARIA_128_GCM_SHA256
TLS_RSA_WITH_ARIA_256_GCM_SHA384
TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
TLS_PSK_WITH_ARIA_128_CBC_SHA256
TLS_PSK_WITH_ARIA_256_CBC_SHA384
TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
TLS_PSK_WITH_ARIA_128_GCM_SHA256
TLS_PSK_WITH_ARIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_RSA_WITH_AES_128_CCM
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_128_CCM_8
TLS_RSA_WITH_AES_256_CCM_8
TLS_PSK_WITH_AES_128_CCM
TLS_PSK_WITH_AES_256_CCM
TLS_PSK_WITH_AES_128_CCM_8
TLS_PSK_WITH_AES_256_CCM_8

자세한 내용은 섹션 9.2.2를 참조하세요.

부록 B. RFC 7540로부터의 변경 사항

이 개정판에는 다음과 같은 실질적인 변경사항이 포함되어 있습니다:

TLS 1.3의 사용은 [RFC8740]에 따라 정의되었으며, 이 문서는 해당 문서를 대체합니다.
RFC 7540에서 정의한 우선순위(priority) 체계는 더 이상 권장되지 않습니다. PRIORITY 프레임의 형식과 HEADERS 프레임의 우선순위 필드에 대한 정의는 유지되었고, PRIORITY 프레임을 송수신할 수 있는 시점에 대한 규칙도 유지되었지만, 이러한 필드의 의미론(semantics)은 RFC 7540에만 기술되어 있습니다. RFC 7540의 우선순위 신호 방식은 성공적이지 못했습니다. 대신 [HTTP-PRIORITY]의 단순화된 신호 방식을 사용하는 것이 권장됩니다.
HTTP/1.1의 Upgrade 메커니즘은 권고되지 않으며 이 문서에서 더 이상 명세되지 않습니다. 이는 널리 배포되지 않았고, 평문 HTTP/2 사용자는 대신 prior-knowledge 구현을 사용하는 쪽을 선택했습니다.
필드 이름과 값에 대한 검증이 좁혀졌습니다. 중개자(intermediaries)에 대해 필수적인 검증이 정확하게 정의되었고, 요청에 대한 오류 보고는 400번대 상태 코드를 전송하도록 권장되도록 수정되었습니다.
실험용(Experimental Use)으로 예약되었던 설정 및 프레임 유형의 코드포인트 범위가 이제 일반 사용을 위해 사용 가능하게 되었습니다.
금지된 연결 전용 헤더 필드(connection-specific header fields)가 보다 정확하고 포괄적으로 식별되었습니다.
Host와 ":authority"가 서로 다를 수 없습니다.
설정 변경 이후 동적 테이블 크기 업데이트(Dynamic Table Size Update) 지시를 전송하는 규칙이 섹션 4.3.1에서 명확해졌습니다.

편집상의 변경도 포함되어 있습니다. 특히, 용어와 문서 구조의 변경은 핵심 HTTP 의미론([HTTP])의 업데이트에 대한 응답으로 이루어졌습니다. 이들 문서는 이제 RFC 7540에서 처음 정의된 일부 개념들(예: 421 상태 코드 또는 연결 병합(connection coalescing))을 포함합니다.