1.1. 문서 구조

이 문서는 핵심 QUIC 프로토콜을 설명하며 다음과 같이 구성된다:¶

• 스트림은 QUIC가 제공하는 기본 서비스 추상화이다.¶

  • Section 2는 스트림과 관련된 핵심 개념을 설명하고,¶
  • Section 3는 스트림 상태를 위한 참조 모델을 제공하며,¶
  • Section 4는 흐름 제어의 동작을 개괄한다.¶

• 연결은 QUIC 엔드포인트가 통신하는 컨텍스트이다.¶

  • Section 5는 연결과 관련된 핵심 개념을 설명하고,¶
  • Section 6는 버전 협상을 설명하며,¶
  • Section 7은 연결 설정 프로세스를 자세히 설명하고,¶
  • Section 8은 주소 검증과 중요한 서비스 거부 완화책을 설명하며,¶
  • Section 9는 엔드포인트가 연결을 새로운 네트워크 경로로 마이그레이션하는 방법을 설명하고,¶
  • Section 10은 열린 연결을 종료하기 위한 옵션을 나열하며,¶
  • Section 11은 스트림 및 연결 오류 처리를 위한 지침을 제공한다.¶

• 패킷과 프레임은 QUIC가 통신하는 데 사용하는 기본 단위이다.¶

  • Section 12는 패킷 및 프레임과 관련된 개념을 설명하고,¶
  • Section 13은 데이터의 전송, 재전송 및 확인 응답에 대한 모델을 정의하며,¶
  • Section 14는 QUIC 패킷을 운반하는 데이터그램 크기를 관리하기 위한 규칙을 지정한다.¶

• 마지막으로, QUIC 프로토콜 요소의 인코딩 세부사항은 다음에 설명되어 있다:¶

  • Section 15 (버전),¶
  • Section 16 (정수 인코딩),¶
  • Section 17 (패킷 헤더),¶
  • Section 18 (전송 매개변수),¶
  • Section 19 (프레임), 및¶
  • Section 20 (오류).¶

동반 문서들은 QUIC의 손실 감지 및 혼잡 제어 [QUIC-RECOVERY], 그리고 TLS 및 기타 암호화 메커니즘의 사용 [QUIC-TLS]을 설명한다.¶

이 문서는 QUIC 버전 1을 정의하며, 이는 [QUIC-INVARIANTS]의 프로토콜 불변사항을 따른다.¶

QUIC 버전 1을 참조하려면 이 문서를 인용한다. QUIC의 제한된 버전 독립적 속성 집합에 대한 참조는 [QUIC-INVARIANTS]를 인용할 수 있다.¶

1.2. 용어 및 정의

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

이 문서에서 일반적으로 사용되는 용어는 아래에 설명되어 있다.¶

QUIC:

이 문서에서 설명하는 전송 프로토콜. QUIC는 이름이며, 약어가 아니다.¶

엔드포인트:

QUIC 패킷을 생성, 수신 및 처리함으로써 QUIC 연결에 참여할 수 있는 엔티티. QUIC에는 클라이언트와 서버라는 두 가지 유형의 엔드포인트만 있다.¶

클라이언트:

QUIC 연결을 시작하는 엔드포인트.¶

서버:

QUIC 연결을 수락하는 엔드포인트.¶

QUIC 패킷:

UDP 데이터그램에 캡슐화될 수 있는 QUIC의 완전한 처리 가능 단위. 하나 이상의 QUIC 패킷이 단일 UDP 데이터그램에 캡슐화될 수 있다.¶

Ack-eliciting 패킷:

ACK, PADDING 및 CONNECTION_CLOSE 이외의 프레임을 포함하는 QUIC 패킷. 이는 수신자가 확인 응답을 보내게 한다. Section 13.2.1을 참조한다.¶

프레임:

구조화된 프로토콜 정보의 단위. 여러 프레임 유형이 있으며, 각각은 서로 다른 정보를 운반한다. 프레임은 QUIC 패킷에 포함된다.¶

주소:

한정 없이 사용될 때, 네트워크 경로의 한쪽 끝을 나타내는 IP 버전, IP 주소 및 UDP 포트 번호의 튜플.¶

연결 ID:

엔드포인트에서 QUIC 연결을 식별하는 데 사용되는 식별자. 각 엔드포인트는 피어가 해당 엔드포인트로 보내는 패킷에 포함할 하나 이상의 연결 ID를 선택한다. 이 값은 피어에게 불투명하다.¶

스트림:

QUIC 연결 내부의 정렬된 바이트로 이루어진 단방향 또는 양방향 채널. QUIC 연결은 여러 동시 스트림을 운반할 수 있다.¶

애플리케이션:

QUIC를 사용해 데이터를 보내고 받는 엔티티.¶

이 문서는 각 프로토콜의 단위를 가리키기 위해 "QUIC packets", "UDP datagrams", 그리고 "IP packets"라는 용어를 사용한다. 즉, 하나 이상의 QUIC 패킷이 UDP 데이터그램에 캡슐화될 수 있고, 이는 다시 IP 패킷에 캡슐화된다.¶

1.3. 표기 규칙

이 문서의 패킷 및 프레임 다이어그램은 맞춤형 형식을 사용한다. 이 형식의 목적은 프로토콜 요소를 정의하는 것이 아니라 요약하는 것이다. 산문은 구조의 완전한 의미와 세부사항을 정의한다.¶

복합 필드는 이름이 지정된 뒤 한 쌍의 일치하는 중괄호로 둘러싸인 필드 목록이 뒤따른다. 이 목록의 각 필드는 쉼표로 구분된다.¶

개별 필드에는 길이 정보와 함께 고정 값, 선택성 또는 반복에 대한 표시가 포함된다. 개별 필드는 다음 표기 규칙을 사용하며, 모든 길이는 비트 단위이다:¶

x (A):

x가 A비트 길이임을 나타낸다¶

x (i):

x가 Section 16에 설명된 가변 길이 인코딩을 사용하여 정수 값을 보유함을 나타낸다¶

x (A..B):

x가 A부터 B까지 임의의 길이를 가질 수 있음을 나타낸다. A를 생략하면 최소값이 0비트임을 나타내고, B를 생략하면 설정된 상한이 없음을 나타낸다; 이 형식의 값은 항상 바이트 경계에서 끝난다¶

x (L) = C:

x가 고정 값 C를 가짐을 나타낸다; x의 길이는 L로 설명되며, 이는 위의 길이 형식 중 어느 것이든 사용할 수 있다¶

x (L) = C..D:

x가 C부터 D까지의 범위에 있는 값을 가짐을 나타내며, 양끝값을 포함하고, 길이는 위와 같이 L로 설명된다¶

[x (L)]:

x가 선택 사항이며 길이가 L임을 나타낸다¶

x (L) ...:

x가 0회 이상 반복되며 각 인스턴스의 길이가 L임을 나타낸다¶

이 문서는 네트워크 바이트 순서(즉, 빅 엔디언) 값을 사용한다. 필드는 각 바이트의 상위 비트부터 배치된다.¶

관례상, 개별 필드는 복합 필드의 이름을 사용하여 복합 필드를 참조한다.¶

Figure 1은 예를 제공한다:¶

Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Field with Variable-Length Integer (i),
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Field With Minimum Length (16..),
  Field With Maximum Length (..128),
  [Optional Field (64)],
  Repeated Field (8) ...,
}

산문에서 단일 비트 필드를 참조할 때, 그 필드의 위치는 해당 필드의 값이 설정된 상태에서 그 필드를 담고 있는 바이트의 값을 사용해 명확히 할 수 있다. 예를 들어, Figure 1의 One-bit Field처럼 바이트의 최상위 비트에 있는 단일 비트 필드를 가리키기 위해 값 0x80을 사용할 수 있다.¶

2.1. 스트림 유형 및 식별자

스트림은 단방향 또는 양방향일 수 있다. 단방향 스트림은 한 방향으로 데이터를 운반한다: 스트림의 개시자에서 그 피어로. 양방향 스트림은 양방향으로 데이터를 보낼 수 있게 한다.¶

스트림은 연결 내부에서 스트림 ID라고 부르는 숫자 값으로 식별된다. 스트림 ID는 62비트 정수(0부터 2⁶²-1)이며, 연결의 모든 스트림에 대해 고유하다. 스트림 ID는 가변 길이 정수로 인코딩된다. Section 16을 참조한다. QUIC 엔드포인트는 연결 내부에서 스트림 ID를 재사용해서는 MUST NOT 된다.¶

스트림 ID의 최하위 비트(0x01)는 스트림의 개시자를 식별한다. 클라이언트가 개시한 스트림은 짝수 번호의 스트림 ID(해당 비트가 0으로 설정됨)를 가지며, 서버가 개시한 스트림은 홀수 번호의 스트림 ID(해당 비트가 1로 설정됨)를 가진다.¶

스트림 ID의 두 번째 최하위 비트(0x02)는 양방향 스트림(해당 비트가 0으로 설정됨)과 단방향 스트림(해당 비트가 1로 설정됨)을 구분한다.¶

따라서 스트림 ID의 두 최하위 비트는 Table 1에 요약된 것처럼 스트림을 네 가지 유형 중 하나로 식별한다.¶

각 유형의 스트림 공간은 각각 최소값(0x00부터 0x03까지)에서 시작한다; 각 유형의 후속 스트림은 숫자가 증가하는 스트림 ID로 생성된다. 순서를 벗어나 사용된 스트림 ID는 해당 유형에서 더 낮은 번호의 스트림 ID를 가진 모든 스트림도 열린 것으로 만든다.¶

2.2. 데이터 송수신

STREAM 프레임(Section 19.8)은 애플리케이션이 보낸 데이터를 캡슐화한다. 엔드포인트는 STREAM 프레임의 Stream ID 및 Offset 필드를 사용하여 데이터를 순서대로 배치한다.¶

엔드포인트는 스트림 데이터를 정렬된 바이트 스트림으로 애플리케이션에 전달할 수 있어야 MUST 한다. 정렬된 바이트 스트림을 전달하려면 엔드포인트가 광고된 흐름 제어 한도까지 순서가 어긋나 수신된 모든 데이터를 버퍼링해야 한다.¶

QUIC는 스트림 데이터를 순서 없이 전달하는 데 대해 특별한 허용을 하지 않는다. 그러나 구현은 수신 애플리케이션에 데이터를 순서 없이 전달하는 기능을 제공하기로 선택할 수 MAY 있다.¶

엔드포인트는 같은 스트림 오프셋에서 여러 번 데이터를 수신할 수 있다. 이미 수신된 데이터는 버릴 수 있다. 주어진 오프셋의 데이터는 여러 번 전송되더라도 변경되어서는 MUST NOT 안 된다; 엔드포인트는 스트림 내 같은 오프셋에서 서로 다른 데이터를 수신하는 것을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리할 수 MAY 있다.¶

스트림은 QUIC에 보이는 다른 구조가 없는 정렬된 바이트 스트림 추상화이다. STREAM 프레임 경계는 데이터가 전송되거나, 패킷 손실 후 재전송되거나, 수신자에서 애플리케이션에 전달될 때 보존될 것으로 기대되지 않는다.¶

엔드포인트는 피어가 설정한 흐름 제어 한도 내에 있음을 보장하지 않고서는 어떤 스트림에서도 데이터를 보내서는 MUST NOT 안 된다. 흐름 제어는 Section 4에서 자세히 설명한다.¶

2.3. 스트림 우선순위 지정

스트림 다중화는 스트림에 할당된 리소스가 올바르게 우선순위화된다면 애플리케이션 성능에 상당한 영향을 줄 수 있다.¶

QUIC는 우선순위 지정 정보를 교환하기 위한 메커니즘을 제공하지 않는다. 대신 애플리케이션으로부터 우선순위 정보를 받는 데 의존한다.¶

QUIC 구현은 애플리케이션이 스트림의 상대적 우선순위를 나타낼 수 있는 방법을 제공해야 SHOULD 한다. 구현은 애플리케이션이 제공한 정보를 사용하여 활성 스트림에 리소스를 어떻게 할당할지 결정한다.¶

2.4. 스트림에 대한 작업

이 문서는 QUIC용 API를 정의하지 않는다; 대신 애플리케이션 프로토콜이 의존할 수 있는 스트림에 대한 기능 집합을 정의한다. 애플리케이션 프로토콜은 QUIC 구현이 이 섹션에서 설명한 작업을 포함하는 인터페이스를 제공한다고 가정할 수 있다. 특정 애플리케이션 프로토콜과 함께 사용하도록 설계된 구현은 그 프로토콜에서 사용되는 작업만 제공할 수도 있다.¶

스트림의 송신 부분에서 애플리케이션 프로토콜은 다음을 수행할 수 있다:¶

• 쓰기 데이터에 대한 스트림 흐름 제어 크레딧 (Section 4.1)이 성공적으로 예약되어 전송될 수 있음을 이해하면서 데이터를 쓸 수 있다;¶
• 스트림을 종료할 수 있다(정상 종료). 이는 FIN 비트가 설정된 STREAM 프레임 (Section 19.8)을 발생시킨다; 그리고¶
• 스트림을 재설정할 수 있다(갑작스러운 종료). 이는 스트림이 이미 종료 상태가 아닌 경우 RESET_STREAM 프레임 (Section 19.4)을 발생시킨다.¶

스트림의 수신 부분에서 애플리케이션 프로토콜은 다음을 수행할 수 있다:¶

• 데이터를 읽을 수 있다; 그리고¶
• 스트림 읽기를 중단하고 닫기를 요청할 수 있으며, 이는 STOP_SENDING 프레임(Section 19.5)을 발생시킬 수 있다.¶

애플리케이션 프로토콜은 또한 피어가 스트림을 열거나 재설정했을 때, 피어가 스트림 읽기를 중단했을 때, 새 데이터를 사용할 수 있을 때, 그리고 흐름 제어로 인해 스트림에 데이터를 쓸 수 있거나 쓸 수 없을 때를 포함하여 스트림의 상태 변경을 알리도록 요청할 수 있다.¶

3.1. 송신 스트림 상태

Figure 2는 피어에게 데이터를 보내는 스트림 부분의 상태를 보여준다.¶

       o
       | Create Stream (Sending)
       | Peer Creates Bidirectional Stream
       v
   +-------+
   | Ready | Send RESET_STREAM
   |       |-----------------------.
   +-------+                       |
       |                           |
       | Send STREAM /             |
       |      STREAM_DATA_BLOCKED  |
       v                           |
   +-------+                       |
   | Send  | Send RESET_STREAM     |
   |       |---------------------->|
   +-------+                       |
       |                           |
       | Send STREAM + FIN         |
       v                           v
   +-------+                   +-------+
   | Data  | Send RESET_STREAM | Reset |
   | Sent  |------------------>| Sent  |
   +-------+                   +-------+
       |                           |
       | Recv All ACKs             | Recv ACK
       v                           v
   +-------+                   +-------+
   | Data  |                   | Reset |
   | Recvd |                   | Recvd |
   +-------+                   +-------+

엔드포인트가 개시한 스트림의 송신 부분(클라이언트의 경우 유형 0 및 2, 서버의 경우 1 및 3)은 애플리케이션에 의해 열린다. "Ready" 상태는 애플리케이션으로부터 데이터를 받을 수 있는 새로 생성된 스트림을 나타낸다. 이 상태에서는 전송 준비를 위해 스트림 데이터가 버퍼링될 수 있다.¶

첫 번째 STREAM 또는 STREAM_DATA_BLOCKED 프레임을 보내면 스트림의 송신 부분이 "Send" 상태로 들어간다. 구현은 첫 번째 STREAM 프레임을 보내고 이 상태로 들어갈 때까지 스트림 ID를 스트림에 할당하는 것을 지연하기로 선택할 수 있으며, 이는 더 나은 스트림 우선순위 지정을 가능하게 할 수 있다.¶

피어가 개시한 양방향 스트림의 송신 부분(서버의 경우 유형 0, 클라이언트의 경우 유형 1)은 수신 부분이 생성될 때 "Ready" 상태에서 시작한다.¶

"Send" 상태에서 엔드포인트는 STREAM 프레임으로 스트림 데이터를 전송하며, 필요에 따라 재전송한다. 엔드포인트는 피어가 설정한 흐름 제어 한도를 준수하고 MAX_STREAM_DATA 프레임을 계속 수락하고 처리한다. "Send" 상태의 엔드포인트는 스트림 흐름 제어 한도(Section 4.1)로 인해 전송이 차단되면 STREAM_DATA_BLOCKED 프레임을 생성한다.¶

애플리케이션이 모든 스트림 데이터가 전송되었음을 나타내고 FIN 비트가 포함된 STREAM 프레임이 전송되면, 스트림의 송신 부분은 "Data Sent" 상태로 들어간다. 이 상태에서 엔드포인트는 필요한 경우에만 스트림 데이터를 재전송한다. 엔드포인트는 이 상태의 스트림에 대해 흐름 제어 한도를 확인하거나 STREAM_DATA_BLOCKED 프레임을 보낼 필요가 없다. 피어가 최종 스트림 오프셋을 수신할 때까지 MAX_STREAM_DATA 프레임이 수신될 수 있다. 엔드포인트는 이 상태의 스트림에 대해 피어로부터 수신한 모든 MAX_STREAM_DATA 프레임을 안전하게 무시할 수 있다.¶

모든 스트림 데이터가 성공적으로 확인 응답되면, 스트림의 송신 부분은 "Data Recvd" 상태로 들어가며, 이는 종단 상태이다.¶

"Ready", "Send" 또는 "Data Sent" 중 하나의 상태에서, 애플리케이션은 스트림 데이터 전송을 포기하려 한다는 신호를 보낼 수 있다. 또는 엔드포인트가 피어로부터 STOP_SENDING 프레임을 수신할 수 있다. 두 경우 모두 엔드포인트는 RESET_STREAM 프레임을 보내며, 이로 인해 스트림은 "Reset Sent" 상태로 들어간다.¶

엔드포인트는 스트림을 언급하는 첫 번째 프레임으로 RESET_STREAM을 보낼 수 MAY 있다. 이는 해당 스트림의 송신 부분을 열고 즉시 "Reset Sent" 상태로 전이하게 한다.¶

RESET_STREAM을 포함하는 패킷이 확인 응답되면, 스트림의 송신 부분은 "Reset Recvd" 상태로 들어가며, 이는 종단 상태이다.¶

3.2. 수신 스트림 상태

Figure 3은 피어로부터 데이터를 수신하는 스트림 부분의 상태를 보여준다. 스트림의 수신 부분에 대한 상태는 피어의 스트림 송신 부분 상태 중 일부만 반영한다. 스트림의 수신 부분은 "Ready" 상태처럼 관찰할 수 없는 송신 부분의 상태를 추적하지 않는다. 대신 스트림의 수신 부분은 애플리케이션으로의 데이터 전달을 추적하며, 그중 일부는 송신자가 관찰할 수 없다.¶

       o
       | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
       | Create Bidirectional Stream (Sending)
       | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
       | Create Higher-Numbered Stream
       v
   +-------+
   | Recv  | Recv RESET_STREAM
   |       |-----------------------.
   +-------+                       |
       |                           |
       | Recv STREAM + FIN         |
       v                           |
   +-------+                       |
   | Size  | Recv RESET_STREAM     |
   | Known |---------------------->|
   +-------+                       |
       |                           |
       | Recv All Data             |
       v                           v
   +-------+ Recv RESET_STREAM +-------+
   | Data  |--- (optional) --->| Reset |
   | Recvd |  Recv All Data    | Recvd |
   +-------+<-- (optional) ----+-------+
       |                           |
       | App Read All Data         | App Read Reset
       v                           v
   +-------+                   +-------+
   | Data  |                   | Reset |
   | Read  |                   | Read  |
   +-------+                   +-------+

피어가 개시한 스트림의 수신 부분(클라이언트의 경우 유형 1 및 3, 서버의 경우 0 및 2)은 해당 스트림에 대한 첫 번째 STREAM, STREAM_DATA_BLOCKED 또는 RESET_STREAM 프레임이 수신될 때 생성된다. 피어가 개시한 양방향 스트림의 경우, 스트림의 송신 부분에 대한 MAX_STREAM_DATA 또는 STOP_SENDING 프레임을 수신하는 것도 수신 부분을 생성한다. 스트림의 수신 부분에 대한 초기 상태는 "Recv"이다.¶

양방향 스트림의 경우, 엔드포인트가 개시한 송신 부분(클라이언트의 경우 유형 0, 서버의 경우 유형 1)이 "Ready" 상태로 들어갈 때 수신 부분이 "Recv" 상태로 들어간다.¶

엔드포인트는 해당 스트림에 대해 피어로부터 MAX_STREAM_DATA 또는 STOP_SENDING 프레임을 수신하면 양방향 스트림을 연다. 열리지 않은 스트림에 대한 MAX_STREAM_DATA 프레임을 수신하는 것은 원격 피어가 스트림을 열었고 흐름 제어 크레딧을 제공하고 있음을 나타낸다. 열리지 않은 스트림에 대한 STOP_SENDING 프레임을 수신하는 것은 원격 피어가 더 이상 이 스트림에서 데이터를 수신하기를 원하지 않음을 나타낸다. 패킷이 손실되거나 재정렬되는 경우, 두 프레임 모두 STREAM 또는 STREAM_DATA_BLOCKED 프레임보다 먼저 도착할 수 있다.¶

스트림이 생성되기 전에, 같은 유형의 더 낮은 번호의 스트림 ID를 가진 모든 스트림은 생성되어야 MUST 한다. 이는 스트림 생성 순서가 양쪽 엔드포인트에서 일관되도록 보장한다.¶

"Recv" 상태에서 엔드포인트는 STREAM 및 STREAM_DATA_BLOCKED 프레임을 수신한다. 들어오는 데이터는 버퍼링되며 애플리케이션에 전달하기 위해 올바른 순서로 재조립될 수 있다. 애플리케이션이 데이터를 소비하고 버퍼 공간이 사용 가능해지면, 엔드포인트는 피어가 더 많은 데이터를 보낼 수 있도록 MAX_STREAM_DATA 프레임을 보낸다.¶

FIN 비트가 있는 STREAM 프레임이 수신되면, 스트림의 최종 크기를 알 수 있다. Section 4.5를 참조한다. 그런 다음 스트림의 수신 부분은 "Size Known" 상태로 들어간다. 이 상태에서 엔드포인트는 더 이상 MAX_STREAM_DATA 프레임을 보낼 필요가 없으며, 스트림 데이터의 재전송만 수신한다.¶

스트림의 모든 데이터가 수신되면, 수신 부분은 "Data Recvd" 상태로 들어간다. 이는 "Size Known"으로의 전이를 일으킨 동일한 STREAM 프레임을 수신한 결과로 발생할 수 있다. 모든 데이터가 수신된 후에는 해당 스트림에 대한 모든 STREAM 또는 STREAM_DATA_BLOCKED 프레임을 폐기할 수 있다.¶

"Data Recvd" 상태는 스트림 데이터가 애플리케이션에 전달될 때까지 지속된다. 스트림 데이터가 전달되면, 스트림은 "Data Read" 상태로 들어가며, 이는 종단 상태이다.¶

"Recv" 또는 "Size Known" 상태에서 RESET_STREAM 프레임을 수신하면 스트림은 "Reset Recvd" 상태로 들어간다. 이는 애플리케이션으로의 스트림 데이터 전달을 중단시킬 수 있다.¶

RESET_STREAM을 수신했을 때 모든 스트림 데이터가 이미 수신되어 있을 수 있다 (즉, "Data Recvd" 상태). 마찬가지로 RESET_STREAM 프레임을 수신한 후에도 남은 스트림 데이터가 도착할 수 있다("Reset Recvd" 상태). 구현은 이 상황을 원하는 방식으로 자유롭게 관리할 수 있다.¶

RESET_STREAM을 보내는 것은 엔드포인트가 스트림 데이터의 전달을 보장할 수 없음을 의미한다. 그러나 RESET_STREAM이 수신되었다고 해서 스트림 데이터가 전달되지 않아야 한다는 요구사항은 없다. 구현은 스트림 데이터 전달을 중단하고, 소비되지 않은 모든 데이터를 폐기하며, RESET_STREAM의 수신을 알릴 수 MAY 있다. 스트림 데이터가 완전히 수신되어 애플리케이션이 읽을 수 있도록 버퍼링된 경우, RESET_STREAM 신호는 억제되거나 보류될 수 있다. RESET_STREAM이 억제되면, 스트림의 수신 부분은 "Data Recvd" 상태로 남는다.¶

애플리케이션이 스트림이 재설정되었음을 나타내는 신호를 수신하면, 스트림의 수신 부분은 "Reset Read" 상태로 전이되며, 이는 종단 상태이다.¶

3.3. 허용된 프레임 유형

스트림의 송신자는 송신자 또는 수신자 어느 쪽에서든 스트림의 상태에 영향을 주는 세 가지 프레임 유형만 보낸다. STREAM(Section 19.8), STREAM_DATA_BLOCKED(Section 19.13) 및 RESET_STREAM (Section 19.4)이다.¶

송신자는 종단 상태("Data Recvd" 또는 "Reset Recvd")에서 이러한 프레임 중 어느 것도 보내서는 MUST NOT 안 된다. 송신자는 "Reset Sent" 상태 또는 어떤 종단 상태에 있는 스트림에 대해 STREAM 또는 STREAM_DATA_BLOCKED 프레임을 보내서는 MUST NOT 안 된다. 즉, RESET_STREAM 프레임을 보낸 이후에는 보내면 안 된다. 수신자는 이 세 가지 프레임 중 어느 것이든, 이를 운반하는 패킷의 지연 전달 가능성 때문에, 어떤 상태에서도 수신할 수 있다.¶

스트림의 수신자는 MAX_STREAM_DATA 프레임 (Section 19.10)과 STOP_SENDING 프레임(Section 19.5)을 보낸다.¶

수신자는 "Recv" 상태에서만 MAX_STREAM_DATA 프레임을 보낸다. 수신자는 RESET_STREAM 프레임을 아직 수신하지 않은 모든 상태, 즉 "Reset Recvd" 또는 "Reset Read" 이외의 상태에서 STOP_SENDING 프레임을 보낼 수 MAY 있다. 그러나 "Data Recvd" 상태에서는 모든 스트림 데이터가 수신되었으므로 STOP_SENDING 프레임을 보내는 데 큰 가치가 없다. 송신자는 패킷의 지연 전달 결과로 이 두 유형의 프레임 중 어느 것이든 어떤 상태에서도 수신할 수 있다.¶

3.4. 양방향 스트림 상태

양방향 스트림은 송신 부분과 수신 부분으로 구성된다. 구현은 양방향 스트림의 상태를 송신 및 수신 스트림 상태의 합성으로 표현할 수 있다. 가장 단순한 모델은 송신 또는 수신 부분 중 어느 하나가 비종단 상태에 있으면 스트림을 "open"으로, 송신 및 수신 스트림이 모두 종단 상태에 있으면 "closed"로 나타낸다.¶

Table 2는 HTTP/2 [HTTP2]에 정의된 스트림 상태와 느슨하게 대응하는 양방향 스트림 상태의 더 복잡한 매핑을 보여준다. 이는 스트림의 송신 또는 수신 부분에 있는 여러 상태가 동일한 합성 상태에 매핑됨을 보여준다. 이는 이러한 매핑의 한 가지 가능성일 뿐이라는 점에 유의한다. 이 매핑은 "closed" 또는 "half-closed" 상태로 전이하기 전에 데이터가 확인 응답되어야 함을 요구한다.¶

3.5. 요청된 상태 전이

애플리케이션이 스트림에서 수신 중인 데이터에 더 이상 관심이 없다면, 스트림 읽기를 중단하고 애플리케이션 오류 코드를 지정할 수 있다.¶

스트림이 "Recv" 또는 "Size Known" 상태에 있다면, 전송 계층은 반대 방향의 스트림 닫기를 유도하기 위해 STOP_SENDING 프레임을 보내 이를 신호해야 SHOULD 한다. 이는 일반적으로 수신 애플리케이션이 스트림에서 수신하는 데이터를 더 이상 읽지 않음을 나타내지만, 들어오는 데이터가 무시될 것이라는 보장은 아니다.¶

STOP_SENDING 프레임을 보낸 후 수신된 STREAM 프레임은, 수신 시 폐기될 수 있더라도, 여전히 연결 및 스트림 흐름 제어에 계산된다.¶

STOP_SENDING 프레임은 수신 엔드포인트에게 RESET_STREAM 프레임을 보내도록 요청한다. STOP_SENDING 프레임을 수신한 엔드포인트는 스트림이 "Ready" 또는 "Send" 상태에 있으면 RESET_STREAM 프레임을 보내야 MUST 한다. 스트림이 "Data Sent" 상태에 있으면, 엔드포인트는 미처리 데이터를 포함하는 패킷이 확인 응답되거나 손실로 선언될 때까지 RESET_STREAM 프레임 전송을 지연할 수 MAY 있다. 미처리 데이터가 손실로 선언되면, 엔드포인트는 데이터를 재전송하는 대신 RESET_STREAM 프레임을 보내야 SHOULD 한다.¶

엔드포인트는 STOP_SENDING 프레임의 오류 코드를 자신이 보내는 RESET_STREAM 프레임에 복사해야 SHOULD 하지만, 어떤 애플리케이션 오류 코드도 사용할 수 있다. STOP_SENDING 프레임을 보낸 엔드포인트는 이후 해당 스트림에 대해 수신한 모든 RESET_STREAM 프레임의 오류 코드를 무시할 수 MAY 있다.¶

STOP_SENDING은 피어에 의해 재설정되지 않은 스트림에 대해서만 보내야 SHOULD 한다. STOP_SENDING은 "Recv" 또는 "Size Known" 상태의 스트림에 가장 유용하다.¶

이전 STOP_SENDING을 포함하는 패킷이 손실되면 엔드포인트는 또 다른 STOP_SENDING 프레임을 보낼 것으로 예상된다. 그러나 스트림에 대해 모든 스트림 데이터 또는 RESET_STREAM 프레임 중 하나가 수신되면, 즉 스트림이 "Recv" 또는 "Size Known" 이외의 어떤 상태에 있으면, STOP_SENDING 프레임을 보내는 것은 불필요하다.¶

양방향 스트림의 양방향 모두를 종료하려는 엔드포인트는 RESET_STREAM 프레임을 보내 한 방향을 종료할 수 있으며, STOP_SENDING 프레임을 보내 반대 방향의 신속한 종료를 유도할 수 있다.¶

4.1. 데이터 흐름 제어

QUIC는 수신자가 특정 스트림 또는 전체 연결에 대해 수신할 준비가 된 총 바이트의 한도를 알리는 한도 기반 흐름 제어 방식을 사용한다. 이는 QUIC에서 두 수준의 데이터 흐름 제어로 이어진다:¶

• 스트림 흐름 제어는 각 스트림에서 전송할 수 있는 데이터 양을 제한하여 단일 스트림이 연결의 전체 수신 버퍼를 소비하지 못하게 한다.¶
• 연결 흐름 제어는 모든 스트림의 STREAM 프레임으로 전송되는 스트림 데이터의 총 바이트 수를 제한하여 송신자가 해당 연결에 대한 수신자의 버퍼 용량을 초과하지 못하게 한다.¶

송신자는 어느 한도도 초과하여 데이터를 보내서는 MUST NOT 안 된다.¶

수신자는 핸드셰이크 중 전송 매개변수 (Section 7.4)를 통해 모든 스트림의 초기 한도를 설정한다. 이후 수신자는 더 큰 한도를 알리기 위해 MAX_STREAM_DATA 프레임(Section 19.10) 또는 MAX_DATA 프레임 (Section 19.9)을 송신자에게 보낸다.¶

수신자는 해당 스트림 ID를 가진 MAX_STREAM_DATA 프레임을 보내 스트림에 대해 더 큰 한도를 알릴 수 있다. MAX_STREAM_DATA 프레임은 스트림의 최대 절대 바이트 오프셋을 나타낸다. 수신자는 해당 스트림에서 소비된 데이터의 현재 오프셋을 기준으로 알릴 흐름 제어 오프셋을 결정할 수 있다.¶

수신자는 모든 스트림의 절대 바이트 오프셋 합계의 최대값을 나타내는 MAX_DATA 프레임을 보내 연결에 대해 더 큰 한도를 알릴 수 있다. 수신자는 모든 스트림에서 수신된 바이트의 누적 합계를 유지하며, 이는 광고된 연결 또는 스트림 데이터 한도의 위반을 확인하는 데 사용된다. 수신자는 모든 스트림에서 소비된 바이트 합계를 기준으로 알릴 최대 데이터 한도를 결정할 수 있다.¶

수신자가 연결 또는 스트림에 대한 한도를 알린 뒤에는, 더 작은 한도를 알리는 것이 오류는 아니지만, 더 작은 한도는 효과가 없다.¶

송신자가 광고된 연결 또는 스트림 데이터 한도를 위반하면, 수신자는 FLOW_CONTROL_ERROR 유형의 오류로 연결을 닫아야 MUST 한다. 오류 처리에 대한 세부사항은 Section 11을 참조한다.¶

송신자는 흐름 제어 한도를 증가시키지 않는 모든 MAX_STREAM_DATA 또는 MAX_DATA 프레임을 무시해야 MUST 한다.¶

송신자가 한도까지 데이터를 보냈다면 새 데이터를 보낼 수 없으며 차단된 것으로 간주된다. 송신자는 쓸 데이터가 있지만 흐름 제어 한도에 의해 차단되었음을 수신자에게 나타내기 위해 STREAM_DATA_BLOCKED 또는 DATA_BLOCKED 프레임을 보내야 SHOULD 한다. 송신자가 유휴 타임아웃(Section 10.1)보다 긴 기간 동안 차단되면, 송신자에게 전송 가능한 데이터가 있더라도 수신자는 연결을 닫을 수 있다. 연결이 닫히지 않도록 하기 위해, 흐름 제어로 제한된 송신자는 전송 중인 ack-eliciting 패킷이 없을 때 주기적으로 STREAM_DATA_BLOCKED 또는 DATA_BLOCKED 프레임을 보내야 SHOULD 한다.¶

4.2. 흐름 제어 한도 증가

구현은 MAX_STREAM_DATA 및 MAX_DATA 프레임에서 언제 얼마나 많은 크레딧을 알릴지 결정하지만, 이 섹션은 몇 가지 고려사항을 제공한다.¶

송신자가 차단되는 것을 피하기 위해, 수신자는 한 왕복 시간 내에 MAX_STREAM_DATA 또는 MAX_DATA 프레임을 여러 번 보내거나, 프레임 손실과 이후 복구를 위한 시간을 허용할 만큼 충분히 일찍 보낼 수 MAY 있다.¶

제어 프레임은 연결 오버헤드에 기여한다. 따라서 작은 변경으로 MAX_STREAM_DATA 및 MAX_DATA 프레임을 자주 보내는 것은 바람직하지 않다. 반면에 업데이트가 덜 빈번하면 송신자가 차단되는 것을 피하기 위해 한도에 더 큰 증분이 필요하며, 이는 수신자에서 더 큰 리소스 약속을 요구한다. 알릴 한도의 크기를 결정할 때 리소스 약속과 오버헤드 사이에는 절충이 있다.¶

수신자는 왕복 시간 추정치와 수신 애플리케이션이 데이터를 소비하는 속도에 기반하여 알릴 추가 크레딧의 빈도와 양을 조정하는 자동 조정 메커니즘을 사용할 수 있으며, 이는 일반적인 TCP 구현과 유사하다. 최적화로서, 엔드포인트는 보낼 다른 프레임이 있을 때만 흐름 제어와 관련된 프레임을 보내도록 할 수 있어, 흐름 제어가 추가 패킷 전송을 유발하지 않도록 할 수 있다.¶

차단된 송신자는 STREAM_DATA_BLOCKED 또는 DATA_BLOCKED 프레임을 보낼 필요가 없다. 따라서 수신자는 MAX_STREAM_DATA 또는 MAX_DATA 프레임을 보내기 전에 STREAM_DATA_BLOCKED 또는 DATA_BLOCKED 프레임을 기다려서는 MUST NOT 안 된다. 그렇게 하면 송신자가 연결의 나머지 동안 차단될 수 있다. 송신자가 이러한 프레임을 보내더라도, 이를 기다리면 송신자는 적어도 전체 왕복 시간 동안 차단된다.¶

송신자가 차단된 후 크레딧을 수신하면, 그 응답으로 많은 양의 데이터를 보낼 수 있어 단기적인 혼잡이 발생할 수 있다. 송신자가 이 혼잡을 피할 수 있는 방법에 대한 논의는 Section 7.7 of [QUIC-RECOVERY]를 참조한다.¶

4.3. 흐름 제어 성능

엔드포인트가 피어가 항상 이 연결의 대역폭-지연 곱보다 큰 사용 가능한 흐름 제어 크레딧을 갖도록 보장할 수 없다면, 그 수신 처리량은 흐름 제어에 의해 제한된다.¶

패킷 손실은 수신 버퍼에 공백을 만들 수 있으며, 이는 애플리케이션이 데이터를 소비하고 수신 버퍼 공간을 해제하는 것을 방해한다.¶

흐름 제어 한도를 적시에 업데이트하면 성능을 향상시킬 수 있다. 흐름 제어 업데이트만 제공하기 위해 패킷을 보내면 네트워크 부하가 증가하고 성능에 악영향을 줄 수 있다. ACK 프레임과 같은 다른 프레임과 함께 흐름 제어 업데이트를 보내면 이러한 업데이트의 비용이 줄어든다.¶

4.4. 스트림 취소 처리

엔드포인트는 연결 수준 흐름 제어를 위해 모든 바이트를 계산할 수 있도록, 모든 스트림에서 소비된 흐름 제어 크레딧의 양에 대해 결국 합의해야 한다.¶

RESET_STREAM 프레임을 수신하면, 엔드포인트는 일치하는 스트림에 대한 상태를 해제하고 해당 스트림에 도착하는 추가 데이터를 무시한다.¶

RESET_STREAM은 스트림의 한 방향을 갑작스럽게 종료한다. 양방향 스트림의 경우, RESET_STREAM은 반대 방향의 데이터 흐름에 영향을 주지 않는다. 두 엔드포인트는 종료되지 않은 방향이 종단 상태에 들어갈 때까지 해당 방향의 스트림 흐름 제어 상태를 유지해야 MUST 한다.¶

4.5. 스트림 최종 크기

최종 크기는 스트림이 소비한 흐름 제어 크레딧의 양이다. 스트림의 모든 연속 바이트가 한 번씩 전송되었다고 가정하면, 최종 크기는 전송된 바이트 수이다. 더 일반적으로는, 스트림에서 전송된 가장 큰 오프셋을 가진 바이트의 오프셋보다 1 큰 값이며, 바이트가 전송되지 않았다면 0이다.¶

송신자는 스트림이 어떻게 종료되든 관계없이 스트림의 최종 크기를 수신자에게 신뢰성 있게 항상 전달한다. 최종 크기는 FIN 플래그가 있는 STREAM 프레임의 Offset 및 Length 필드의 합이며, 이러한 필드가 암시적일 수 있음에 유의한다. 또는 RESET_STREAM 프레임의 Final Size 필드가 이 값을 운반한다. 이는 양쪽 엔드포인트가 해당 스트림에서 송신자가 소비한 흐름 제어 크레딧 양에 대해 합의하도록 보장한다.¶

엔드포인트는 스트림의 수신 부분이 "Size Known" 또는 "Reset Recvd" 상태 (Section 3)에 들어갈 때 스트림의 최종 크기를 알게 된다. 수신자는 연결 수준 흐름 제어기에서 스트림에 전송된 모든 바이트를 계산하기 위해 스트림의 최종 크기를 사용해야 MUST 한다.¶

엔드포인트는 최종 크기 이상에서 스트림에 데이터를 보내서는 MUST NOT 안 된다.¶

스트림의 최종 크기가 알려지면, 이는 변경될 수 없다. 스트림의 최종 크기 변경을 나타내는 RESET_STREAM 또는 STREAM 프레임이 수신되면, 엔드포인트는 FINAL_SIZE_ERROR 유형의 오류로 응답해야 SHOULD 한다. 오류 처리에 대한 세부사항은 Section 11을 참조한다. 수신자는 스트림이 닫힌 후에도 최종 크기 이상에서 데이터를 수신하는 것을 FINAL_SIZE_ERROR 유형의 오류로 처리해야 SHOULD 한다. 이러한 오류를 생성하는 것은 의무가 아니다. 엔드포인트가 이러한 오류를 생성하도록 요구하면, 닫힌 스트림에 대한 최종 크기 상태도 유지해야 하며, 이는 상당한 상태 약속을 의미할 수 있기 때문이다.¶

4.6. 동시성 제어

엔드포인트는 피어가 열 수 있는 수신 스트림의 누적 수를 제한한다. 스트림 ID가 (max_streams * 4 + first_stream_id_of_type)보다 작은 스트림만 열 수 있다. Table 1을 참조한다. 초기 한도는 전송 매개변수에서 설정된다. Section 18.2를 참조한다. 이후 한도는 MAX_STREAMS 프레임을 사용해 알린다. Section 19.11을 참조한다. 단방향 및 양방향 스트림에는 별도의 한도가 적용된다.¶

max_streams 전송 매개변수 또는 MAX_STREAMS 프레임이 2⁶⁰보다 큰 값으로 수신되면, 이는 가변 길이 정수로 표현할 수 없는 최대 스트림 ID를 허용하게 된다. Section 16을 참조한다. 어느 하나가 수신되면, 해당 값이 전송 매개변수에서 수신된 경우 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로, 프레임에서 수신된 경우 FRAME_ENCODING_ERROR 유형의 연결 오류로, 연결을 즉시 닫아야 MUST 한다. Section 10.2를 참조한다.¶

엔드포인트는 피어가 설정한 한도를 초과해서는 MUST NOT 안 된다. 자신이 보낸 한도를 초과하는 스트림 ID를 가진 프레임을 수신한 엔드포인트는 이를 STREAM_LIMIT_ERROR 유형의 연결 오류로 처리해야 MUST 한다. 오류 처리에 대한 세부사항은 Section 11을 참조한다.¶

수신자가 MAX_STREAMS 프레임을 사용해 스트림 한도를 알린 뒤에는, 더 작은 한도를 알리는 것이 효과가 없다. 스트림 한도를 증가시키지 않는 MAX_STREAMS 프레임은 무시되어야 MUST 한다.¶

스트림 및 연결 흐름 제어와 마찬가지로, 이 문서는 구현이 MAX_STREAMS를 통해 언제 얼마나 많은 스트림을 피어에게 알릴지 결정하도록 맡긴다. 구현은 피어에게 제공되는 스트림 수를 대략 일정하게 유지하기 위해, 스트림이 닫힐 때 한도를 늘리기로 선택할 수 있다.¶

피어의 한도로 인해 새 스트림을 열 수 없는 엔드포인트는 STREAMS_BLOCKED 프레임(Section 19.14)을 보내야 SHOULD 한다. 이 신호는 디버깅에 유용한 것으로 간주된다. 엔드포인트는 추가 크레딧을 알리기 전에 이 신호를 수신하기를 기다려서는 MUST NOT 안 된다. 그렇게 하면 피어가 적어도 전체 왕복 시간 동안, 그리고 피어가 STREAMS_BLOCKED 프레임을 보내지 않기로 선택하면 잠재적으로 무기한 차단될 수 있기 때문이다.¶

5.1. 연결 ID

각 연결은 연결 식별자 또는 연결 ID의 집합을 가지며, 각각은 연결을 식별할 수 있다. 연결 ID는 엔드포인트가 독립적으로 선택한다. 각 엔드포인트는 피어가 사용할 연결 ID를 선택한다.¶

연결 ID의 주요 기능은 하위 프로토콜 계층(UDP, IP)의 주소 지정 변경으로 인해 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것이다. 각 엔드포인트는 해당 연결 ID를 가진 패킷이 엔드포인트로 다시 라우팅되고 수신 시 엔드포인트에 의해 식별될 수 있도록 하는 구현별(그리고 아마도 배포별) 방법을 사용해 연결 ID를 선택한다.¶

엔드포인트의 협력 없이 관찰자가 동일한 연결에 대한 것으로 식별할 수 없는 패킷을 엔드포인트가 보낼 수 있도록 하기 위해 여러 연결 ID가 사용된다. Section 9.5를 참조한다.¶

연결 ID는 외부 관찰자(즉, 발급자와 협력하지 않는 관찰자)가 이를 같은 연결의 다른 연결 ID와 연관시키는 데 사용할 수 있는 어떤 정보도 포함해서는 MUST NOT 안 된다. 사소한 예로, 이는 동일한 연결에서 같은 연결 ID가 두 번 이상 발급되어서는 MUST NOT 안 된다는 것을 의미한다.¶

긴 헤더가 있는 패킷은 Source Connection ID 및 Destination Connection ID 필드를 포함한다. 이러한 필드는 새 연결에 대한 연결 ID를 설정하는 데 사용된다. 자세한 내용은 Section 7.2를 참조한다.¶

짧은 헤더가 있는 패킷(Section 17.3)은 Destination Connection ID만 포함하고 명시적 길이는 생략한다. Destination Connection ID 필드의 길이는 엔드포인트에 알려져 있을 것으로 예상된다. 연결 ID 기반으로 라우팅하는 로드 밸런서를 사용하는 엔드포인트는 연결 ID의 고정 길이에 대해 로드 밸런서와 합의하거나 인코딩 방식에 대해 합의할 수 있다. 고정된 부분은 명시적 길이를 인코딩할 수 있으며, 이를 통해 전체 연결 ID가 길이를 달리하면서도 로드 밸런서에서 사용될 수 있다.¶

Version Negotiation(Section 17.2.1) 패킷은 클라이언트가 선택한 연결 ID를 에코한다. 이는 클라이언트 쪽으로의 올바른 라우팅을 보장하고, 해당 패킷이 클라이언트가 보낸 패킷에 대한 응답임을 입증하기 위한 것이다.¶

올바른 엔드포인트로 라우팅하기 위해 연결 ID가 필요하지 않을 때는 길이가 0인 연결 ID를 사용할 수 있다. 그러나 길이가 0인 연결 ID를 사용하면서 동일한 로컬 IP 주소와 포트에서 연결을 다중화하면 피어 연결 마이그레이션, NAT 리바인딩 및 클라이언트 포트 재사용이 있을 때 실패가 발생한다. 엔드포인트는 이러한 프로토콜 기능이 사용되지 않음이 확실하지 않은 한, 길이가 0인 연결 ID를 가진 여러 동시 연결에 동일한 IP 주소와 포트를 사용해서는 MUST NOT 안 된다.¶

엔드포인트가 길이가 0이 아닌 연결 ID를 사용하는 경우, 해당 엔드포인트로 보내는 패킷에 대해 피어가 선택할 수 있는 연결 ID의 공급이 보장되도록 해야 한다. 이러한 연결 ID는 엔드포인트가 NEW_CONNECTION_ID 프레임(Section 19.15)을 사용해 제공한다.¶

5.2. 패킷을 연결에 대응시키기

들어오는 패킷은 수신 시 분류된다. 패킷은 기존 연결과 연관될 수 있거나, 서버의 경우 새 연결을 만들 가능성이 있다.¶

엔드포인트는 패킷을 기존 연결과 연관시키려 한다. 패킷에 기존 연결에 해당하는 길이가 0이 아닌 Destination Connection ID가 있으면, QUIC는 해당 패킷을 그에 따라 처리한다. 둘 이상의 연결 ID가 하나의 연결과 연관될 수 있음에 유의한다. Section 5.1을 참조한다.¶

Destination Connection ID의 길이가 0이고 패킷의 주소 지정 정보가 엔드포인트가 길이 0 연결 ID를 가진 연결을 식별하는 데 사용하는 주소 지정 정보와 일치하면, QUIC는 해당 패킷을 그 연결의 일부로 처리한다. 엔드포인트는 목적지 IP와 포트만 사용하거나 식별을 위해 소스 및 목적지 주소를 모두 사용할 수 있지만, 이는 Section 5.1에 설명된 것처럼 연결을 취약하게 만든다.¶

엔드포인트는 기존 연결에 귀속될 수 없는 모든 패킷에 대해 Stateless Reset(Section 10.3)을 보낼 수 있다. Stateless Reset은 피어가 연결이 사용할 수 없게 되었음을 더 빠르게 식별할 수 있게 한다.¶

기존 연결과 일치한 패킷은 해당 연결의 상태와 일치하지 않으면 폐기된다. 예를 들어, 패킷이 연결의 프로토콜 버전과 다른 프로토콜 버전을 나타내거나, 예상 키가 사용 가능해진 뒤 패킷 보호 제거가 실패하면 패킷이 폐기된다.¶

Initial, Retry 또는 Version Negotiation처럼 강한 무결성 보호가 없는 유효하지 않은 패킷은 폐기될 수 MAY 있다. 엔드포인트는 오류를 발견하기 전에 이러한 패킷의 내용을 처리했다면 연결 오류를 생성해야 MUST 하거나, 그 처리 중 이루어진 모든 변경을 완전히 되돌려야 한다.¶

5.3. 연결에 대한 작업

이 문서는 QUIC용 API를 정의하지 않는다. 대신 애플리케이션 프로토콜이 의존할 수 있는 QUIC 연결을 위한 기능 집합을 정의한다. 애플리케이션 프로토콜은 QUIC 구현이 이 섹션에서 설명한 작업을 포함하는 인터페이스를 제공한다고 가정할 수 있다. 특정 애플리케이션 프로토콜과 함께 사용하도록 설계된 구현은 해당 프로토콜에서 사용되는 작업만 제공할 수 있다.¶

클라이언트 역할을 구현할 때, 애플리케이션 프로토콜은 다음을 수행할 수 있다:¶

• Section 7에 설명된 교환을 시작하는 연결을 열 수 있다;¶
• 사용 가능한 경우 Early Data를 활성화할 수 있다; 그리고¶
• Early Data가 서버에 의해 수락되었는지 거부되었는지 통지받을 수 있다.¶

서버 역할을 구현할 때, 애플리케이션 프로토콜은 다음을 수행할 수 있다:¶

• 들어오는 연결을 수신 대기할 수 있으며, 이는 Section 7에 설명된 교환을 준비한다;¶
• Early Data가 지원되는 경우, 클라이언트에게 보내는 TLS 재개 티켓에 애플리케이션이 제어하는 데이터를 포함할 수 있다; 그리고¶
• Early Data가 지원되는 경우, 클라이언트의 재개 티켓에서 애플리케이션이 제어하는 데이터를 검색하고 해당 정보를 기준으로 Early Data를 수락하거나 거부할 수 있다.¶

어느 역할에서든, 애플리케이션 프로토콜은 다음을 수행할 수 있다:¶

• 전송 매개변수(Section 7.4)로 전달되는 각 유형의 허용된 초기 스트림 수에 대한 최소값을 구성할 수 있다;¶
• 스트림과 연결 모두에 대해 흐름 제어 한도를 설정하여 수신 버퍼의 리소스 할당을 제어할 수 있다;¶
• 핸드셰이크가 성공적으로 완료되었는지 또는 아직 진행 중인지 식별할 수 있다;¶
• PING 프레임 (Section 19.2)을 생성하거나, 유휴 타임아웃이 만료되기 전에 전송 계층이 추가 프레임을 보내도록 요청함으로써(Section 10.1), 연결이 조용히 닫히지 않게 유지할 수 있다; 그리고¶
• 연결을 즉시 닫을 수 있다(Section 10.2).¶

6.1. Version Negotiation 패킷 보내기

클라이언트가 선택한 버전을 서버가 받아들일 수 없으면, 서버는 Version Negotiation 패킷으로 응답한다. Section 17.2.1을 참조한다. 여기에는 서버가 받아들일 버전 목록이 포함된다. 엔드포인트는 Version Negotiation 패킷을 수신한 것에 대한 응답으로 Version Negotiation 패킷을 보내서는 MUST NOT 안 된다.¶

이 시스템은 서버가 상태를 유지하지 않고도 지원되지 않는 버전의 패킷을 처리할 수 있게 한다. 응답으로 전송되는 Initial 패킷이나 Version Negotiation 패킷이 손실될 수 있지만, 클라이언트는 응답을 성공적으로 수신하거나 연결 시도를 포기할 때까지 새 패킷을 보낸다.¶

서버는 자신이 보내는 Version Negotiation 패킷 수를 제한할 수 MAY 있다. 예를 들어, 패킷을 0-RTT로 인식할 수 있는 서버는 결국 Initial 패킷을 수신할 것이라는 예상하에 0-RTT 패킷에 대한 응답으로 Version Negotiation 패킷을 보내지 않기로 선택할 수 있다.¶

6.2. Version Negotiation 패킷 처리

Version Negotiation 패킷은 향후 QUIC가 연결에 사용할 QUIC 버전을 협상할 수 있게 하는 기능을 정의할 수 있도록 설계되었다. 향후 표준 트랙 명세는 여러 QUIC 버전을 지원하는 구현이 이 버전을 사용하여 연결을 설정하려는 시도에 대한 응답으로 수신한 Version Negotiation 패킷에 반응하는 방식을 변경할 수 있다.¶

이 QUIC 버전만 지원하는 클라이언트는 Version Negotiation 패킷을 수신하면 다음 두 예외를 제외하고 현재 연결 시도를 포기해야 MUST 한다. 클라이언트는 이전 Version Negotiation 패킷을 포함하여 다른 어떤 패킷이라도 수신하고 성공적으로 처리했다면 모든 Version Negotiation 패킷을 폐기해야 MUST 한다. 클라이언트는 클라이언트가 선택한 QUIC 버전을 나열하는 Version Negotiation 패킷을 폐기해야 MUST 한다.¶

버전 협상을 수행하는 방법은 향후 표준 트랙 명세에서 정의할 향후 작업으로 남겨둔다. 특히, 그 향후 작업은 버전 다운그레이드 공격에 대한 견고성을 보장할 것이다. Section 21.12를 참조한다.¶

6.3. 예약된 버전 사용

서버가 향후 새 버전을 사용하려면 클라이언트가 지원되지 않는 버전을 올바르게 처리해야 한다. 일부 버전 번호( Section 15에 정의된 0x?a?a?a?a)는 버전 번호를 포함하는 필드에 포함되도록 예약되어 있다.¶

엔드포인트는 알 수 없거나 지원되지 않는 버전이 무시되는 모든 필드에 예약된 버전을 추가하여 피어가 해당 값을 올바르게 무시하는지 테스트할 수 MAY 있다. 예를 들어, 엔드포인트는 Version Negotiation 패킷에 예약된 버전을 포함할 수 있다. Section 17.2.1을 참조한다. 엔드포인트는 피어가 패킷을 올바르게 폐기하는지 테스트하기 위해 예약된 버전의 패킷을 보낼 수 MAY 있다.¶

7.1. 예시 핸드셰이크 흐름

TLS가 QUIC와 통합되는 방식의 세부사항은 [QUIC-TLS]에 제공되지만, 여기에는 몇 가지 예가 제공된다. 클라이언트 주소 검증을 지원하기 위한 이 교환의 확장은 Section 8.1.2에 표시되어 있다.¶

모든 주소 검증 교환이 완료되면, 암호화 핸드셰이크를 사용하여 암호화 키에 합의한다. 암호화 핸드셰이크는 Initial(Section 17.2.2) 및 Handshake (Section 17.2.4) 패킷으로 운반된다.¶

Figure 5는 1-RTT 핸드셰이크의 개요를 제공한다. 각 줄은 먼저 패킷 유형과 패킷 번호가 표시되고, 그 뒤에 일반적으로 해당 패킷에 포함되는 프레임이 표시된 QUIC 패킷을 보여준다. 예를 들어, 첫 번째 패킷은 packet number 0인 Initial 유형이며, ClientHello를 운반하는 CRYPTO 프레임을 포함한다.¶

여러 QUIC 패킷은, 서로 다른 패킷 유형이라도, 단일 UDP 데이터그램으로 병합될 수 있다. Section 12.2를 참조한다. 그 결과, 이 핸드셰이크는 최소 네 개의 UDP 데이터그램만으로 구성될 수도 있고, 더 많을 수도 있다 (혼잡 제어 및 증폭 방지와 같은 프로토콜 고유의 한도에 따른다). 예를 들어, 서버의 첫 번째 flight에는 Initial 패킷, Handshake 패킷 및 1-RTT 패킷의 "0.5-RTT data"가 포함된다.¶

Client                                                  Server

Initial[0]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[0]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] ->

                                          Handshake[1]: ACK[0]
         <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]

Figure 6은 0-RTT 핸드셰이크와 단일 0-RTT 데이터 패킷이 있는 연결의 예를 보여준다. Section 12.3에 설명된 것처럼, 서버는 1-RTT 패킷에서 0-RTT 데이터를 확인 응답하고, 클라이언트는 같은 패킷 번호 공간에서 1-RTT 패킷을 보낸다는 점에 유의한다.¶

Client                                                  Server

Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] ->

                                 Initial[0]: CRYPTO[SH] ACK[0]
                                  Handshake[0] CRYPTO[EE, FIN]
                          <- 1-RTT[0]: STREAM[1, "..."] ACK[0]

Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[1]: STREAM[0, "..."] ACK[0] ->

                                          Handshake[1]: ACK[0]
         <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]

7.2. 연결 ID 협상

연결 ID는 Section 5.1에 설명된 것처럼 패킷의 일관된 라우팅을 보장하는 데 사용된다. 긴 헤더에는 두 개의 연결 ID가 포함된다. Destination Connection ID는 패킷 수신자가 선택하며 일관된 라우팅을 제공하는 데 사용된다. Source Connection ID는 피어가 사용할 Destination Connection ID를 설정하는 데 사용된다.¶

핸드셰이크 중에는 긴 헤더(Section 17.2)가 있는 패킷을 사용하여 양쪽 엔드포인트가 사용할 연결 ID를 설정한다. 각 엔드포인트는 Source Connection ID 필드를 사용하여 자신에게 보내지는 패킷의 Destination Connection ID 필드에 사용될 연결 ID를 지정한다. 첫 번째 Initial 패킷을 처리한 후, 각 엔드포인트는 이후 자신이 보내는 패킷의 Destination Connection ID 필드를 자신이 수신한 Source Connection ID 필드의 값으로 설정한다.¶

서버로부터 Initial 또는 Retry 패킷을 이전에 수신하지 않은 클라이언트가 Initial 패킷을 보낼 때, 클라이언트는 Destination Connection ID 필드를 예측 불가능한 값으로 채운다. 이 Destination Connection ID는 길이가 최소 8바이트이어야 MUST 한다. 서버로부터 패킷을 수신할 때까지, 클라이언트는 이 연결의 모든 패킷에서 같은 Destination Connection ID 값을 사용해야 MUST 한다.¶

클라이언트가 보낸 첫 번째 Initial 패킷의 Destination Connection ID 필드는 Initial 패킷의 패킷 보호 키를 결정하는 데 사용된다. 이러한 키는 Retry 패킷을 수신한 후 변경된다. Section 5.2 of [QUIC-TLS]를 참조한다.¶

클라이언트는 자신이 선택한 값으로 Source Connection ID 필드를 채우고, 길이를 나타내도록 Source Connection ID Length 필드를 설정한다.¶

첫 번째 flight의 0-RTT 패킷은 클라이언트의 첫 번째 Initial 패킷과 동일한 Destination Connection ID 및 Source Connection ID 값을 사용한다.¶

서버로부터 Initial 또는 Retry 패킷을 처음 수신하면, 클라이언트는 서버가 제공한 Source Connection ID를 이후 패킷의 Destination Connection ID로 사용하며, 여기에는 모든 0-RTT 패킷도 포함된다. 이는 클라이언트가 연결 설정 중 Destination Connection ID 필드에 설정하는 연결 ID를 두 번 변경해야 할 수 있음을 의미한다. 한 번은 Retry 패킷에 대한 응답으로, 또 한 번은 서버의 Initial 패킷에 대한 응답으로 변경한다. 클라이언트가 서버로부터 유효한 Initial 패킷을 수신하면, 그 연결에서 이후 수신하는 Source Connection ID가 다른 모든 패킷을 폐기해야 MUST 한다.¶

클라이언트는 처음 수신한 Initial 또는 Retry 패킷에 대한 응답으로만 패킷 전송에 사용하는 Destination Connection ID를 변경해야 MUST 한다. 서버는 처음 수신한 Initial 패킷을 기준으로 패킷 전송에 사용하는 Destination Connection ID를 설정해야 MUST 한다. Destination Connection ID에 대한 추가 변경은 NEW_CONNECTION_ID 프레임에서 가져온 값인 경우에만 허용된다. 이후 Initial 패킷에 다른 Source Connection ID가 포함되면, 이는 폐기되어야 MUST 한다. 이는 Source Connection ID가 서로 다른 여러 Initial 패킷의 상태 없는 처리로 인해 발생할 수 있는 예측 불가능한 결과를 피한다.¶

엔드포인트가 보내는 Destination Connection ID는 연결 수명 동안, 특히 연결 마이그레이션(Section 9)에 대한 응답으로 변경될 수 있다. 자세한 내용은 Section 5.1.1을 참조한다.¶

7.3. 연결 ID 인증

각 엔드포인트가 핸드셰이크 중 연결 ID에 대해 내리는 선택은 모든 값을 전송 매개변수에 포함함으로써 인증된다. Section 7.4를 참조한다. 이는 핸드셰이크에 사용되는 모든 연결 ID가 암호화 핸드셰이크에 의해 인증되도록 보장한다.¶

각 엔드포인트는 자신이 보낸 첫 번째 Initial 패킷의 Source Connection ID 필드 값을 initial_source_connection_id 전송 매개변수에 포함한다. Section 18.2를 참조한다. 서버는 클라이언트로부터 수신한 첫 번째 Initial 패킷의 Destination Connection ID 필드를 original_destination_connection_id 전송 매개변수에 포함한다. 서버가 Retry 패킷을 보낸 경우, 이는 Retry 패킷을 보내기 전에 수신한 첫 번째 Initial 패킷을 가리킨다. Retry 패킷을 보내는 경우, 서버는 Retry 패킷의 Source Connection ID 필드도 retry_source_connection_id 전송 매개변수에 포함한다.¶

피어가 이러한 전송 매개변수에 제공한 값은 엔드포인트가 자신이 보낸 Initial 패킷의 Destination 및 Source Connection ID 필드에 사용한 값과 일치해야 MUST 한다(서버의 경우 수신한 값도 포함). 엔드포인트는 수신한 전송 매개변수가 수신한 연결 ID 값과 일치하는지 검증해야 MUST 한다. 연결 ID 값을 전송 매개변수에 포함하고 이를 검증하면, 공격자가 핸드셰이크 중 공격자가 선택한 연결 ID를 운반하는 패킷을 주입하여 성공적인 연결의 연결 ID 선택에 영향을 줄 수 없도록 보장한다.¶

엔드포인트는 어느 한 엔드포인트에서 initial_source_connection_id 전송 매개변수가 없거나, 서버에서 original_destination_connection_id 전송 매개변수가 없는 것을 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

엔드포인트는 다음을 TRANSPORT_PARAMETER_ERROR 또는 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다:¶

• Retry 패킷을 수신한 후 서버에서 retry_source_connection_id 전송 매개변수가 없음,¶
• Retry 패킷을 수신하지 않았는데 retry_source_connection_id 전송 매개변수가 있음, 또는¶
• 이러한 전송 매개변수에서 피어로부터 수신한 값과, Initial 패킷의 해당 Destination 또는 Source Connection ID 필드에 보낸 값 사이의 불일치.¶

길이가 0인 연결 ID가 선택되면, 해당 전송 매개변수는 길이가 0인 값으로 포함된다.¶

Figure 7은 완전한 핸드셰이크에 사용되는 연결 ID(DCID=Destination Connection ID, SCID=Source Connection ID)를 보여준다. Initial 패킷의 교환과, 핸드셰이크 중 설정된 연결 ID를 포함하는 이후 1-RTT 패킷 교환이 표시되어 있다.¶

Client                                                  Server

Initial: DCID=S1, SCID=C1 ->
                                  <- Initial: DCID=C1, SCID=S3
                             ...
1-RTT: DCID=S3 ->
                                             <- 1-RTT: DCID=C1

Figure 8은 Retry 패킷을 포함하는 유사한 핸드셰이크를 보여준다.¶

Client                                                  Server

Initial: DCID=S1, SCID=C1 ->
                                    <- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 ->
                                  <- Initial: DCID=C1, SCID=S3
                             ...
1-RTT: DCID=S3 ->
                                             <- 1-RTT: DCID=C1

두 경우 모두(Figures 7 및 8), 클라이언트는 initial_source_connection_id 전송 매개변수의 값을 C1으로 설정한다.¶

핸드셰이크가 Retry를 포함하지 않는 경우(Figure 7), 서버는 original_destination_connection_id를 S1로 설정하고(이 값은 클라이언트가 선택한 값임에 유의), initial_source_connection_id를 S3로 설정한다. 이 경우 서버는 retry_source_connection_id 전송 매개변수를 포함하지 않는다.¶

핸드셰이크가 Retry를 포함하는 경우(Figure 8), 서버는 original_destination_connection_id를 S1로, retry_source_connection_id를 S2로, 그리고 initial_source_connection_id를 S3로 설정한다.¶

7.4. 전송 매개변수

연결 설정 중 양쪽 엔드포인트는 자신의 전송 매개변수에 대한 인증된 선언을 한다. 엔드포인트는 각 매개변수가 정의하는 제한을 준수해야 한다. 각 매개변수의 설명에는 그 처리 규칙이 포함된다.¶

전송 매개변수는 각 엔드포인트가 일방적으로 수행하는 선언이다. 각 엔드포인트는 피어가 선택한 값과 독립적으로 전송 매개변수 값을 선택할 수 있다.¶

전송 매개변수의 인코딩은 Section 18에 자세히 설명되어 있다.¶

QUIC는 인코딩된 전송 매개변수를 암호화 핸드셰이크에 포함한다. 핸드셰이크가 완료되면 피어가 선언한 전송 매개변수를 사용할 수 있다. 각 엔드포인트는 피어가 제공한 값을 검증한다.¶

정의된 각 전송 매개변수에 대한 정의는 Section 18.2에 포함되어 있다.¶

엔드포인트는 유효하지 않은 값을 가진 전송 매개변수를 수신한 것을 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

엔드포인트는 주어진 전송 매개변수 확장에서 같은 매개변수를 두 번 이상 보내서는 MUST NOT 안 된다. 엔드포인트는 중복된 전송 매개변수 수신을 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로 처리해야 SHOULD 한다.¶

엔드포인트는 핸드셰이크 중 연결 ID 협상을 인증하기 위해 전송 매개변수를 사용한다. Section 7.3을 참조한다.¶

ALPN([ALPN] 참조)은 클라이언트가 연결 설정 중 여러 애플리케이션 프로토콜을 제안할 수 있게 한다. 클라이언트가 핸드셰이크 중 포함하는 전송 매개변수는 클라이언트가 제안하는 모든 애플리케이션 프로토콜에 적용된다. 애플리케이션 프로토콜은 초기 흐름 제어 한도와 같은 전송 매개변수의 값을 권장할 수 있다. 그러나 전송 매개변수 값에 제약을 설정하는 애플리케이션 프로토콜은 이러한 제약이 충돌할 경우 클라이언트가 여러 애플리케이션 프로토콜을 제안하는 것을 불가능하게 만들 수 있다.¶

7.5. 암호화 메시지 버퍼링

구현은 순서를 벗어나 수신된 CRYPTO 데이터의 버퍼를 유지해야 한다. CRYPTO 프레임에는 흐름 제어가 없기 때문에, 엔드포인트는 잠재적으로 자신의 피어가 제한 없는 양의 데이터를 버퍼링하도록 강제할 수 있다.¶

구현은 순서를 벗어난 CRYPTO 프레임에서 수신한 데이터 중 최소 4096바이트의 버퍼링을 지원해야 MUST 한다. 엔드포인트는 핸드셰이크 중 더 많은 데이터가 버퍼링되도록 허용할 수 MAY 있다. 핸드셰이크 중 더 큰 한도는 더 큰 키나 자격 증명의 교환을 가능하게 할 수 있다. 엔드포인트의 버퍼 크기는 연결 수명 동안 일정하게 유지될 필요가 없다.¶

핸드셰이크 중 CRYPTO 프레임을 버퍼링할 수 없으면 연결 실패로 이어질 수 있다. 핸드셰이크 중 엔드포인트의 버퍼가 초과되면, 핸드셰이크를 완료하기 위해 일시적으로 버퍼를 확장할 수 있다. 엔드포인트가 버퍼를 확장하지 않으면, CRYPTO_BUFFER_EXCEEDED 오류 코드로 연결을 닫아야 MUST 한다.¶

핸드셰이크가 완료된 후 엔드포인트가 CRYPTO 프레임의 모든 데이터를 버퍼링할 수 없으면, 해당 CRYPTO 프레임과 이후에 수신되는 모든 CRYPTO 프레임을 폐기할 수 MAY 있거나, CRYPTO_BUFFER_EXCEEDED 오류 코드로 연결을 닫을 수 MAY 있다. 폐기된 CRYPTO 프레임을 포함하는 패킷은 확인 응답되어야 MUST 한다. CRYPTO 프레임은 폐기되었더라도 해당 패킷은 전송 계층에 의해 수신되고 처리되었기 때문이다.¶

8.1. 연결 설정 중 주소 검증

연결 설정은 양쪽 엔드포인트에 대해 암묵적으로 주소 검증을 제공한다. 특히 Handshake 키로 보호된 패킷을 수신했다는 것은 피어가 Initial 패킷을 성공적으로 처리했음을 확인해 준다. 엔드포인트가 피어로부터 Handshake 패킷을 성공적으로 처리하면, 피어 주소가 검증된 것으로 간주할 수 있다.¶

또한 피어가 엔드포인트가 선택한 연결 ID를 사용하고 그 연결 ID가 최소 64비트의 엔트로피를 포함한다면, 엔드포인트는 피어 주소가 검증된 것으로 간주할 수 MAY 있다.¶

클라이언트의 경우, 첫 번째 Initial 패킷의 Destination Connection ID 필드 값은 임의의 패킷을 성공적으로 처리하는 과정의 일부로 서버 주소를 검증할 수 있게 한다. 서버의 Initial 패킷은 이 값에서 파생된 키로 보호된다(Section 5.2 of [QUIC-TLS] 참조). 또는 이 값은 서버가 Version Negotiation 패킷(Section 6)에서 에코하거나 Retry 패킷의 Integrity Tag(Section 5.8 of [QUIC-TLS])에 포함된다.¶

클라이언트 주소를 검증하기 전에, 서버는 자신이 수신한 바이트 수의 세 배보다 많은 바이트를 보내서는 MUST NOT 안 된다. 이는 스푸핑된 소스 주소를 사용하여 수행될 수 있는 모든 증폭 공격의 규모를 제한한다. 주소 검증 전에 증폭을 피하기 위해, 서버는 단일 연결에 고유하게 귀속되는 데이터그램에서 수신한 모든 페이로드 바이트를 계산해야 MUST 한다. 여기에는 성공적으로 처리된 패킷을 포함하는 데이터그램과 모든 패킷이 폐기되는 데이터그램이 포함된다.¶

클라이언트는 Initial 패킷을 포함하는 UDP 데이터그램의 UDP 페이로드가 최소 1200바이트가 되도록 보장해야 MUST 하며, 필요하다면 PADDING 프레임을 추가한다. 패딩된 데이터그램을 보내는 클라이언트는 서버가 주소 검증을 완료하기 전에 더 많은 데이터를 보낼 수 있게 한다.¶

클라이언트가 추가 Initial 또는 Handshake 패킷을 보내지 않으면, 서버의 Initial 또는 Handshake 패킷 손실이 교착 상태를 일으킬 수 있다. 서버가 증폭 방지 한도에 도달했고 클라이언트가 자신이 보낸 모든 데이터에 대한 확인 응답을 수신한 경우 교착 상태가 발생할 수 있다. 이 경우 클라이언트가 추가 패킷을 보낼 이유가 없으면, 서버는 클라이언트 주소를 검증하지 못했기 때문에 더 많은 데이터를 보낼 수 없게 된다. 이 교착 상태를 방지하기 위해, 클라이언트는 Probe Timeout(PTO)에서 패킷을 보내야 MUST 한다. Section 6.2 of [QUIC-RECOVERY]를 참조한다. 구체적으로, 클라이언트는 Handshake 키가 없으면 최소 1200바이트를 포함하는 UDP 데이터그램에 Initial 패킷을 보내야 MUST 하며, 그렇지 않으면 Handshake 패킷을 보내야 한다.¶

서버는 암호화 핸드셰이크를 시작하기 전에 클라이언트 주소를 검증하고 싶을 수 있다. QUIC는 핸드셰이크를 완료하기 전에 주소 검증을 제공하기 위해 Initial 패킷의 토큰을 사용한다. 이 토큰은 연결 설정 중 Retry 패킷(Section 8.1.2 참조)을 통해 또는 이전 연결에서 NEW_TOKEN 프레임(Section 8.1.3 참조)을 사용하여 클라이언트에게 전달된다.¶

주소 검증 전에 부과되는 전송 한도 외에도, 서버는 혼잡 제어기가 설정한 한도에 의해 무엇을 보낼 수 있는지도 제한된다. 클라이언트는 혼잡 제어기에 의해서만 제한된다.¶

Client                                                  Server

Initial[0]: CRYPTO[CH] ->

                                                <- Retry+Token

Initial+Token[1]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[1]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

8.2. 경로 검증

경로 검증은 연결 마이그레이션 중(Section 9 참조) 주소 변경 후 도달 가능성을 검증하기 위해 양쪽 피어가 사용한다. 경로 검증에서 엔드포인트는 특정 로컬 주소와 특정 피어 주소 사이의 도달 가능성을 테스트한다. 여기서 주소는 IP 주소와 포트의 2-튜플이다.¶

경로 검증은 피어로 향하는 경로에서 보낸 패킷이 그 피어에 의해 수신되는지 테스트한다. 경로 검증은 마이그레이션하는 피어로부터 수신된 패킷이 스푸핑된 소스 주소를 운반하지 않도록 보장하는 데 사용된다.¶

경로 검증은 피어가 반환 방향으로 보낼 수 있는지를 검증하지 않는다. 확인 응답은 엔트로피가 충분하지 않고 스푸핑될 수 있으므로 반환 경로 검증에 사용할 수 없다. 엔드포인트는 경로의 각 방향에 대한 도달 가능성을 독립적으로 결정하므로, 반환 도달 가능성은 피어에 의해서만 설정될 수 있다.¶

경로 검증은 어느 엔드포인트든 언제든 사용할 수 있다. 예를 들어, 엔드포인트는 비활성 기간 이후 피어가 여전히 자신의 주소를 보유하고 있는지 확인할 수 있다.¶

경로 검증은 NAT 통과 메커니즘으로 설계되지 않았다. 여기에 설명된 메커니즘이 NAT 통과를 지원하는 NAT 바인딩을 생성하는 데 효과적일 수는 있지만, 한 엔드포인트가 해당 경로에서 먼저 패킷을 보내지 않고도 패킷을 수신할 수 있다는 것을 전제로 한다. 효과적인 NAT 통과에는 여기에서 제공되지 않는 추가 동기화 메커니즘이 필요하다.¶

엔드포인트는 경로 검증에 사용되는 PATH_CHALLENGE 및 PATH_RESPONSE 프레임과 함께 다른 프레임을 포함할 수 MAY 있다. 특히 엔드포인트는 Path Maximum Transmission Unit Discovery(PMTUD)를 위해 PATH_CHALLENGE 프레임과 함께 PADDING 프레임을 포함할 수 있다. Section 14.2.1을 참조한다. 엔드포인트는 PATH_RESPONSE 프레임을 보낼 때 자신의 PATH_CHALLENGE 프레임도 포함할 수 있다.¶

엔드포인트는 새 로컬 주소에서 전송되는 프로브에 새 연결 ID를 사용한다. Section 9.5를 참조한다. 새 경로를 탐색할 때, 엔드포인트는 피어가 응답에 사용할 미사용 연결 ID를 사용할 수 있도록 보장할 수 있다. 피어의 active_connection_id_limit가 허용한다면, 같은 패킷에 NEW_CONNECTION_ID 및 PATH_CHALLENGE 프레임을 보내면 피어가 응답을 보낼 때 미사용 연결 ID를 사용할 수 있도록 보장된다.¶

엔드포인트는 여러 경로를 동시에 탐색하기로 선택할 수 있다. 프로브에 사용되는 동시 경로 수는 피어가 이전에 제공한 추가 연결 ID 수에 의해 제한된다. 프로브에 사용되는 각 새 로컬 주소에는 이전에 사용되지 않은 연결 ID가 필요하기 때문이다.¶

9.1. 새 경로 탐색

엔드포인트는 연결을 새 로컬 주소로 마이그레이션하기 전에 경로 검증(Section 8.2)을 사용하여 새 로컬 주소에서 피어 도달 가능성을 탐색할 수 MAY 있다. 경로 검증 실패는 단순히 새 경로가 이 연결에 사용할 수 없음을 의미한다. 유효한 대체 경로가 없는 경우를 제외하고, 경로 검증 실패는 연결 종료를 초래하지 않는다.¶

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID 및 PADDING 프레임은 "프로빙 프레임"이고, 그 밖의 모든 프레임은 "비프로빙 프레임"이다. 프로빙 프레임만 포함하는 패킷은 "프로빙 패킷"이고, 다른 어떤 프레임이라도 포함하는 패킷은 "비프로빙 패킷"이다.¶

9.2. 연결 마이그레이션 시작

엔드포인트는 새 로컬 주소에서 비프로빙 프레임을 포함하는 패킷을 보내 연결을 새 로컬 주소로 마이그레이션할 수 있다.¶

각 엔드포인트는 연결 설정 중 피어의 주소를 검증한다. 따라서 마이그레이션하는 엔드포인트는 피어가 피어의 현재 주소에서 수신할 의향이 있음을 알고 피어에게 보낼 수 있다. 따라서 엔드포인트는 먼저 피어의 주소를 검증하지 않고도 새 로컬 주소로 마이그레이션할 수 있다.¶

새 경로에서 도달 가능성을 설정하기 위해, 엔드포인트는 새 경로에서 경로 검증(Section 8.2)을 시작한다. 엔드포인트는 피어가 새 주소로 다음 비프로빙 프레임을 보낸 후까지 경로 검증을 지연할 수 MAY 있다.¶

마이그레이션할 때 새 경로는 엔드포인트의 현재 전송 속도를 지원하지 않을 수 있다. 따라서 엔드포인트는 Section 9.4에 설명된 대로 혼잡 제어기와 RTT 추정치를 재설정한다.¶

새 경로는 같은 ECN 기능을 갖지 않을 수 있다. 따라서 엔드포인트는 Section 13.4에 설명된 대로 ECN 기능을 검증한다.¶

9.3. 연결 마이그레이션에 응답하기

새 피어 주소에서 비프로빙 프레임을 포함하는 패킷을 수신하면, 피어가 해당 주소로 마이그레이션했음을 나타낸다.¶

수신자가 마이그레이션을 허용하는 경우, 이후 패킷을 새 피어 주소로 보내야 MUST 하며, 검증이 이미 진행 중이 아니라면 피어가 그 주소를 소유하고 있음을 검증하기 위해 경로 검증(Section 8.2)을 시작해야 MUST 한다. 수신자가 피어로부터 미사용 연결 ID를 갖고 있지 않다면, 피어가 하나를 제공할 때까지 새 경로에서 아무것도 보낼 수 없다. Section 9.5를 참조한다.¶

엔드포인트는 가장 큰 번호의 비프로빙 패킷에 대한 응답으로만 패킷을 보낼 주소를 변경한다. 이는 엔드포인트가 재정렬된 패킷을 수신하는 경우 이전 피어 주소로 패킷을 보내지 않도록 보장한다.¶

엔드포인트는 검증되지 않은 피어 주소로 데이터를 보낼 수 MAY 있지만, Sections 9.3.1 및 9.3.2에 설명된 잠재적 공격으로부터 보호해야 MUST 한다. 엔드포인트는 해당 주소가 최근에 관찰된 경우 피어 주소 검증을 생략할 수 MAY 있다. 특히 엔드포인트가 어떤 형태의 허위 마이그레이션을 감지한 뒤 이전에 검증된 경로로 돌아가는 경우, 주소 검증을 생략하고 손실 감지 및 혼잡 상태를 복원하면 공격의 성능 영향을 줄일 수 있다.¶

비프로빙 패킷을 보낼 주소를 변경한 후, 엔드포인트는 다른 주소에 대한 모든 경로 검증을 포기할 수 있다.¶

새 피어 주소에서 패킷을 수신하는 것은 피어에서 NAT 리바인딩이 발생한 결과일 수 있다.¶

새 클라이언트 주소를 검증한 후, 서버는 클라이언트에게 새 주소 검증 토큰(Section 8)을 보내야 SHOULD 한다.¶

9.4. 손실 감지 및 혼잡 제어

새 경로에서 사용 가능한 용량은 이전 경로와 같지 않을 수 있다. 이전 경로에서 전송된 패킷은 새 경로의 혼잡 제어나 RTT 추정에 기여해서는 MUST NOT 안 된다.¶

피어가 새 주소를 소유함을 확인하면, 엔드포인트는 피어 주소의 유일한 변경이 포트 번호인 경우를 제외하고, 새 경로에 대한 혼잡 제어기와 왕복 시간 추정기를 즉시 초기값으로 재설정해야 MUST 한다([QUIC-RECOVERY]의 Appendices A.3 및 B.3 참조). 포트만 변경되는 경우는 흔히 NAT 리바인딩이나 다른 미들박스 활동의 결과이므로, 엔드포인트는 이러한 경우 초기값으로 되돌리는 대신 혼잡 제어 상태와 왕복 시간 추정치를 유지할 수 MAY 있다. 이전 경로에서 유지된 혼잡 제어 상태가 상당히 다른 특성을 가진 새 경로에서 사용되는 경우, 송신자는 혼잡 제어기와 RTT 추정기가 적응할 때까지 너무 공격적으로 전송할 수 있다. 일반적으로 구현은 새 경로에서 이전 값을 사용할 때 주의하는 것이 권고된다.¶

마이그레이션 기간 동안 엔드포인트가 여러 주소에서/여러 주소로 데이터와 프로브를 보낼 때, 결과적으로 두 경로의 왕복 시간이 다를 수 있으므로 수신자에게 겉보기 재정렬이 있을 수 있다. 여러 경로에서 패킷을 수신하는 수신자는 여전히 수신한 모든 패킷을 포함하는 ACK 프레임을 보낸다.¶

연결 마이그레이션 중 여러 경로가 사용될 수 있지만, 단일 혼잡 제어 컨텍스트와 단일 손실 복구 컨텍스트([QUIC-RECOVERY]에 설명된 것처럼)로 충분할 수 있다. 예를 들어, 엔드포인트는 이전 경로가 더 이상 필요하지 않다는 것이 확인될 때까지(예: Section 9.3.3에 설명된 경우) 새 혼잡 제어 컨텍스트로 전환하는 것을 지연할 수 있다.¶

송신자는 프로브 패킷에 대해 예외를 두어, 해당 패킷의 손실 감지가 독립적이고 혼잡 제어기가 전송 속도를 부당하게 줄이지 않도록 할 수 있다. 엔드포인트는 PATH_CHALLENGE가 전송될 때 별도 타이머를 설정할 수 있으며, 해당 PATH_RESPONSE가 수신되면 이 타이머는 취소된다. PATH_RESPONSE가 수신되기 전에 타이머가 만료되면, 엔드포인트는 새 PATH_CHALLENGE를 보내고 더 긴 기간으로 타이머를 다시 시작할 수 있다. 이 타이머는 Section 6.2.1 of [QUIC-RECOVERY]에 설명된 대로 설정되어야 SHOULD 하며, 더 공격적이어서는 MUST NOT 안 된다.¶

9.5. 연결 마이그레이션의 프라이버시 영향

여러 네트워크 경로에서 안정적인 연결 ID를 사용하면 수동 관찰자가 해당 경로들 사이의 활동을 상관시킬 수 있다. 네트워크 사이를 이동하는 엔드포인트는 피어 이외의 어떤 엔티티도 자신의 활동을 상관시키는 것을 원하지 않을 수 있으므로, Section 5.1에서 논의된 것처럼 서로 다른 로컬 주소에서 보낼 때 서로 다른 연결 ID를 사용한다. 이것이 효과적이려면, 엔드포인트는 자신이 제공하는 연결 ID가 다른 어떤 엔티티에 의해서도 연결될 수 없도록 보장해야 한다.¶

언제든 엔드포인트는 전송에 사용하는 Destination Connection ID를 다른 경로에서 사용되지 않은 값으로 변경할 수 MAY 있다.¶

엔드포인트는 둘 이상의 로컬 주소에서 보낼 때 연결 ID를 재사용해서는 MUST NOT 안 된다. 예를 들어 Section 9.2에 설명된 대로 연결 마이그레이션을 시작할 때 또는 Section 9.1에 설명된 대로 새 네트워크 경로를 탐색할 때가 그렇다.¶

마찬가지로, 엔드포인트는 둘 이상의 목적지 주소로 보낼 때 연결 ID를 재사용해서는 MUST NOT 안 된다. 피어가 제어할 수 없는 네트워크 변경으로 인해 엔드포인트는 같은 Destination Connection ID 필드 값을 가진 패킷을 새 소스 주소에서 수신할 수 있으며, 이 경우 엔드포인트는 같은 로컬 주소에서 보내는 동안 새 원격 주소와 함께 현재 연결 ID를 계속 사용할 수 MAY 있다.¶

연결 ID 재사용에 관한 이러한 요구사항은 패킷 전송에만 적용된다. 연결 ID 변경 없이도 의도치 않은 경로 변경이 가능하기 때문이다. 예를 들어, 네트워크 비활성 기간 후 클라이언트가 전송을 재개할 때 NAT 리바인딩으로 인해 새 경로에서 패킷이 전송될 수 있다. 엔드포인트는 이러한 이벤트에 Section 9.3에 설명된 대로 응답한다.¶

각 새 네트워크 경로에서 양방향으로 전송되는 패킷에 서로 다른 연결 ID를 사용하면, 서로 다른 네트워크 경로에 걸쳐 같은 연결의 패킷을 연결하는 데 연결 ID가 사용되는 것을 제거한다. 헤더 보호는 패킷 번호가 활동을 상관시키는 데 사용될 수 없도록 보장한다. 이것이 타이밍이나 크기와 같은 패킷의 다른 속성이 활동을 상관시키는 데 사용되는 것을 막지는 않는다.¶

엔드포인트는 길이가 0인 연결 ID를 요청한 피어와 마이그레이션을 시작해서는 SHOULD NOT 안 된다. 새 경로의 트래픽이 이전 경로의 트래픽과 쉽게 연결될 수 있기 때문이다. 서버가 길이가 0인 연결 ID를 가진 패킷을 올바른 연결과 연결할 수 있다면, 이는 서버가 패킷을 역다중화하기 위해 다른 정보를 사용하고 있음을 의미한다. 예를 들어, 서버는 모든 클라이언트에게 고유한 주소를 제공할 수 있다. 예컨대 HTTP 대체 서비스 [ALTSVC]를 사용하는 방식이다. 여러 네트워크 경로에 걸쳐 패킷을 올바르게 라우팅할 수 있게 하는 정보는 피어 이외의 엔티티가 해당 경로의 활동을 연결할 수 있게도 한다.¶

클라이언트는 비활성 기간 후 트래픽을 보낼 때 새 연결 ID, 소스 UDP 포트 또는 IP 주소([RFC8981] 참조)로 전환하여 연결 가능성을 줄이고 싶을 수 있다. 패킷을 보내는 주소를 동시에 변경하면 서버가 연결 마이그레이션을 감지할 수 있다. 이는 NAT 리바인딩이나 실제 마이그레이션을 경험하지 않는 클라이언트의 경우에도 마이그레이션을 지원하는 메커니즘이 실행되도록 보장한다. 주소 변경은 피어가 혼잡 제어 상태를 재설정하게 할 수 있으므로 (Section 9.4 참조), 주소는 드물게만 변경되어야 SHOULD 한다.¶

사용 가능한 연결 ID를 모두 소진한 엔드포인트는 새 경로를 탐색하거나 마이그레이션을 시작할 수 없으며, 피어의 프로브나 마이그레이션 시도에 응답할 수도 없다. 마이그레이션이 가능하고 서로 다른 경로에서 전송된 패킷이 상관되지 않도록 보장하기 위해, 엔드포인트는 피어가 마이그레이션하기 전에 새 연결 ID를 제공해야 SHOULD 한다. Section 5.1.1을 참조한다. 피어가 사용 가능한 연결 ID를 소진했을 수 있는 경우, 마이그레이션하는 엔드포인트는 새 네트워크 경로에서 전송되는 모든 패킷에 NEW_CONNECTION_ID 프레임을 포함할 수 있다.¶

9.6. 서버의 선호 주소

QUIC는 서버가 하나의 IP 주소에서 연결을 수락한 뒤 핸드셰이크 직후 이러한 연결을 더 선호되는 주소로 이전하려 시도할 수 있게 한다. 이는 클라이언트가 처음에는 여러 서버가 공유하는 주소에 연결하지만, 연결 안정성을 보장하기 위해 유니캐스트 주소 사용을 선호하는 경우 특히 유용하다. 이 섹션은 연결을 선호되는 서버 주소로 마이그레이션하기 위한 프로토콜을 설명한다.¶

연결 중간에 새 서버 주소로 연결을 마이그레이션하는 것은 이 문서에 명시된 QUIC 버전에서 지원되지 않는다. 클라이언트가 그 주소로 마이그레이션을 시작하지 않았는데 새 서버 주소에서 패킷을 수신하면, 클라이언트는 이러한 패킷을 폐기해야 SHOULD 한다.¶

9.7. IPv6 흐름 레이블 사용과 마이그레이션

IPv6를 사용하여 데이터를 보내는 엔드포인트는 로컬 API가 IPv6 흐름 레이블 설정을 허용하지 않는 경우를 제외하고, [RFC6437]을 준수하여 IPv6 흐름 레이블을 적용해야 SHOULD 한다.¶

흐름 레이블 생성은 이전에 사용된 흐름 레이블과의 연결 가능성을 최소화하도록 설계되어야 MUST 한다. 안정적인 흐름 레이블은 여러 경로의 활동을 상관시킬 수 있기 때문이다. Section 9.5를 참조한다.¶

[RFC6437]은 흐름 레이블을 생성하기 위해 의사난수 함수를 사용해 값을 파생할 것을 제안한다. 흐름 레이블 생성 시 소스 및 목적지 주소에 더해 Destination Connection ID 필드를 포함하면, 다른 관찰 가능한 식별자의 변경과 변경이 동기화되도록 보장된다. 이러한 입력을 로컬 비밀과 결합하는 암호화 해시 함수는 이를 구현할 수 있는 한 가지 방법이다.¶

10.1. 유휴 타임아웃

어느 한 엔드포인트가 자신의 전송 매개변수(Section 18.2)에서 max_idle_timeout을 지정한 경우, 연결이 양쪽 엔드포인트가 광고한 max_idle_timeout 값의 최소값보다 더 오래 유휴 상태로 남아 있으면, 연결은 조용히 닫히고 그 상태는 폐기된다.¶

각 엔드포인트는 max_idle_timeout을 광고하지만, 엔드포인트에서의 유효 값은 두 광고 값의 최소값(또는 한 엔드포인트만 0이 아닌 값을 광고하는 경우 그 유일한 광고 값)으로 계산된다. max_idle_timeout을 알림으로써, 엔드포인트는 유효 값 이전에 연결을 포기하는 경우 즉시 닫기(Section 10.2)를 시작하겠다고 약속한다.¶

엔드포인트는 피어로부터 패킷을 수신하고 성공적으로 처리하면 자신의 유휴 타이머를 다시 시작한다. 또한 엔드포인트는 마지막으로 패킷을 수신하고 처리한 이후 다른 ack-eliciting 패킷을 보내지 않았다면, ack-eliciting 패킷을 보낼 때도 유휴 타이머를 다시 시작한다. 패킷을 보낼 때 이 타이머를 다시 시작하면 새 활동이 시작된 후 연결이 닫히지 않도록 보장한다.¶

지나치게 작은 유휴 타임아웃 기간을 피하기 위해, 엔드포인트는 유휴 타임아웃 기간을 현재 Probe Timeout(PTO)의 최소 세 배로 늘려야 MUST 한다. 이는 여러 PTO가 만료되어 여러 프로브가 전송되고 손실될 수 있도록 한 뒤 유휴 타임아웃이 발생하게 한다.¶

10.2. 즉시 닫기

엔드포인트는 연결을 즉시 종료하기 위해 CONNECTION_CLOSE 프레임 (Section 19.19)을 보낸다. CONNECTION_CLOSE 프레임은 모든 스트림이 즉시 닫힌 상태가 되게 한다. 열린 스트림은 암묵적으로 재설정된 것으로 간주할 수 있다.¶

CONNECTION_CLOSE 프레임을 보낸 후, 엔드포인트는 즉시 closing 상태에 들어간다. Section 10.2.1을 참조한다. CONNECTION_CLOSE 프레임을 수신한 후, 엔드포인트는 draining 상태에 들어간다. Section 10.2.2를 참조한다.¶

프로토콜 위반은 즉시 닫기로 이어진다.¶

즉시 닫기는 애플리케이션 프로토콜이 연결 닫기를 준비한 후 사용할 수 있다. 이는 애플리케이션 프로토콜이 정상 종료를 협상한 이후일 수 있다. 애플리케이션 프로토콜은 양쪽 애플리케이션 엔드포인트가 연결을 닫아도 된다는 것에 동의하는 데 필요한 메시지를 교환할 수 있으며, 그 후 애플리케이션은 QUIC에게 연결을 닫도록 요청한다. 결과적으로 QUIC가 연결을 닫을 때, 애플리케이션이 제공한 오류 코드가 있는 CONNECTION_CLOSE 프레임이 피어에게 닫힘을 신호하는 데 사용된다.¶

closing 및 draining 연결 상태는 연결이 깔끔하게 닫히고 지연되거나 재정렬된 패킷이 올바르게 폐기되도록 보장하기 위해 존재한다. 이러한 상태는 [QUIC-RECOVERY]에 정의된 현재 PTO 간격의 최소 세 배 동안 지속되어야 SHOULD 한다.¶

closing 또는 draining 상태를 벗어나기 전에 연결 상태를 폐기하면, 늦게 도착한 패킷을 수신할 때 엔드포인트가 불필요하게 Stateless Reset을 생성할 수 있다. 늦게 도착한 패킷이 응답을 유발하지 않도록 보장할 수 있는 다른 수단이 있는 엔드포인트, 예를 들어 UDP 소켓을 닫을 수 있는 엔드포인트는 더 빠른 리소스 회수를 위해 이러한 상태를 더 일찍 종료할 수 MAY 있다. 새 연결을 수락하기 위해 열린 소켓을 유지하는 서버는 closing 또는 draining 상태를 일찍 종료해서는 SHOULD NOT 안 된다.¶

closing 또는 draining 상태가 끝나면, 엔드포인트는 모든 연결 상태를 폐기해야 SHOULD 한다. 엔드포인트는 이 연결에 속하는 이후의 모든 들어오는 패킷에 대한 응답으로 Stateless Reset을 보낼 수 MAY 있다.¶

10.3. 상태 없는 재설정

상태 없는 재설정은 연결 상태에 접근할 수 없는 엔드포인트를 위한 최후의 수단 옵션으로 제공된다. 충돌이나 중단으로 인해 피어가 연결을 제대로 계속할 수 없는 엔드포인트로 데이터를 계속 보낼 수 있다. 엔드포인트는 활성 연결과 연관시킬 수 없는 패킷을 수신한 것에 대한 응답으로 Stateless Reset을 보낼 수 MAY 있다.¶

상태 없는 재설정은 활성 연결의 오류를 나타내는 데 적절하지 않다. 치명적인 연결 오류를 전달하려는 엔드포인트는 가능하다면 CONNECTION_CLOSE 프레임을 사용해야 MUST 한다.¶

이 과정을 지원하기 위해, 엔드포인트는 추측하기 어려운 16바이트 값인 stateless reset token을 발급한다. 피어가 이후 해당 stateless reset token으로 끝나는 UDP 데이터그램인 Stateless Reset을 수신하면, 피어는 즉시 연결을 종료한다.¶

stateless reset token은 연결 ID에 특정된다. 엔드포인트는 NEW_CONNECTION_ID 프레임의 Stateless Reset Token 필드에 값을 포함하여 stateless reset token을 발급한다. 서버는 핸드셰이크 중 자신이 선택한 연결 ID에 적용되는 stateless_reset_token 전송 매개변수도 발급할 수 있다. 이러한 교환은 암호화로 보호되므로 클라이언트와 서버만 그 값을 안다. 클라이언트의 전송 매개변수에는 기밀성 보호가 없기 때문에 클라이언트는 stateless_reset_token 전송 매개변수를 사용할 수 없다는 점에 유의한다.¶

토큰은 관련된 연결 ID가 RETIRE_CONNECTION_ID 프레임(Section 19.16)을 통해 폐기될 때 무효화된다.¶

처리할 수 없는 패킷을 수신한 엔드포인트는 다음 레이아웃의 패킷을 보낸다 (Section 1.3 참조):¶

Stateless Reset {
  Fixed Bits (2) = 1,
  Unpredictable Bits (38..),
  Stateless Reset Token (128),
}

이 설계는 Stateless Reset이 가능한 한 짧은 헤더가 있는 일반 패킷과 구별되지 않도록 보장한다.¶

Stateless Reset은 패킷 헤더의 처음 두 비트부터 시작하여 전체 UDP 데이터그램을 사용한다. 첫 바이트의 나머지 부분과 그 뒤의 임의 개수의 바이트는 무작위와 구별되지 않아야 SHOULD 하는 값으로 설정된다. 데이터그램의 마지막 16바이트는 stateless reset token을 포함한다.¶

의도된 수신자 이외의 엔티티에게 Stateless Reset은 짧은 헤더가 있는 패킷처럼 보일 것이다. Stateless Reset이 유효한 QUIC 패킷처럼 보이려면, Unpredictable Bits 필드가 최소 38비트의 데이터(또는 5바이트에서 두 고정 비트를 뺀 값)를 포함해야 한다.¶

그 결과 최소 크기인 21바이트는 수신자가 연결 ID 사용을 요구하는 경우 Stateless Reset을 다른 패킷과 구별하기 어렵다는 것을 보장하지 않는다. 이를 달성하기 위해, 엔드포인트는 자신이 보내는 모든 패킷이 피어에게 패킷에 포함하도록 요청한 최소 연결 ID 길이보다 최소 22바이트 더 길도록 해야 SHOULD 하며, 필요하다면 PADDING 프레임을 추가한다. 이는 피어가 보내는 모든 Stateless Reset이 엔드포인트로 보내진 유효한 패킷과 구별되지 않도록 보장한다. 43바이트 이하의 패킷에 대한 응답으로 Stateless Reset을 보내는 엔드포인트는 응답 대상 패킷보다 1바이트 더 짧은 Stateless Reset을 보내야 SHOULD 한다.¶

이 값들은 stateless reset token이 패킷 보호 AEAD의 최소 확장과 같은 길이라고 가정한다. 엔드포인트가 더 큰 최소 확장을 가진 패킷 보호 방식을 협상할 수 있었다면 추가적인 예측 불가능한 바이트가 필요하다.¶

엔드포인트는 증폭에 사용되는 것을 피하기 위해 자신이 수신한 패킷보다 세 배 이상 큰 Stateless Reset을 보내서는 MUST NOT 안 된다. Section 10.3.3은 Stateless Reset 크기에 대한 추가 한도를 설명한다.¶

엔드포인트는 유효한 QUIC 패킷이 되기에 너무 작은 패킷을 폐기해야 MUST 한다. 예를 들어, [QUIC-TLS]에 정의된 AEAD 함수 집합에서는 21바이트보다 작은 짧은 헤더 패킷은 결코 유효하지 않다.¶

엔드포인트는 짧은 헤더가 있는 패킷으로 형식화된 Stateless Reset을 보내야 MUST 한다. 그러나 다른 QUIC 버전에서는 긴 헤더 사용을 허용할 수 있으므로, 엔드포인트는 유효한 stateless reset token으로 끝나는 모든 패킷을 Stateless Reset으로 처리해야 MUST 한다.¶

엔드포인트는 긴 헤더가 있는 패킷에 대한 응답으로 Stateless Reset을 보낼 수 MAY 있다. Stateless Reset 전송은 stateless reset token이 피어에게 사용 가능해지기 전에는 효과적이지 않다. 이 QUIC 버전에서 긴 헤더가 있는 패킷은 연결 설정 중에만 사용된다. stateless reset token은 연결 설정이 완료되거나 완료에 가까워질 때까지 사용할 수 없으므로, 알 수 없는 긴 헤더 패킷을 무시하는 것이 Stateless Reset을 보내는 것만큼 효과적일 수 있다.¶

엔드포인트는 짧은 헤더가 있는 패킷에서 Source Connection ID를 결정할 수 없다. 따라서 Stateless Reset에서 Destination Connection ID를 설정할 수 없다. 그러므로 Destination Connection ID는 이전 패킷에서 사용된 값과 달라진다. 임의의 Destination Connection ID는 연결 ID가 NEW_CONNECTION_ID 프레임을 사용해 제공된 새 연결 ID로 이동한 결과처럼 보이게 한다. Section 19.15를 참조한다.¶

무작위화된 연결 ID 사용은 두 가지 문제를 초래한다:¶

• 패킷이 피어에 도달하지 않을 수 있다. Destination Connection ID가 피어 쪽 라우팅에 중요하다면, 이 패킷은 잘못 라우팅될 수 있다. 이는 응답으로 또 다른 Stateless Reset을 트리거할 수도 있다. Section 10.3.3을 참조한다. 올바르게 라우팅되지 않은 Stateless Reset은 효과적인 오류 감지 및 복구 메커니즘이 아니다. 이 경우 엔드포인트는 연결 실패를 감지하기 위해 타이머와 같은 다른 방법에 의존해야 한다.¶
• 무작위로 생성된 연결 ID는 피어 이외의 엔티티가 이를 잠재적 Stateless Reset으로 식별하는 데 사용할 수 있다. 때때로 다른 연결 ID를 사용하는 엔드포인트는 이에 대해 어느 정도 불확실성을 도입할 수 있다.¶

이 상태 없는 재설정 설계는 QUIC 버전 1에 특정된다. 여러 QUIC 버전을 지원하는 엔드포인트는 자신이 지원할 수 있는(또는 상태를 잃기 전에 지원했을 수 있는) 모든 버전을 지원하는 피어가 수락할 Stateless Reset을 생성해야 한다. 새로운 QUIC 버전 설계자는 이를 인식하고 (1) 이 설계를 재사용하거나 (2) 마지막 16바이트가 아닌 패킷의 다른 부분을 데이터 운반에 사용해야 한다.¶

11.1. 연결 오류

프로토콜 의미론의 명백한 위반이나 전체 연결에 영향을 주는 상태 손상처럼 연결을 사용할 수 없게 만드는 오류는 CONNECTION_CLOSE 프레임 (Section 19.19)을 사용하여 신호해야 MUST 한다.¶

애플리케이션별 프로토콜 오류는 프레임 유형이 0x1d인 CONNECTION_CLOSE 프레임을 사용하여 신호된다. 이 문서에 설명된 모든 오류를 포함하여 전송에 특정된 오류는 프레임 유형이 0x1c인 CONNECTION_CLOSE 프레임에 운반된다.¶

CONNECTION_CLOSE 프레임은 손실되는 패킷으로 전송될 수 있다. 엔드포인트는 종료된 연결에서 더 많은 패킷을 수신하면 CONNECTION_CLOSE 프레임을 포함하는 패킷을 재전송할 준비가 되어 있어야 SHOULD 한다. 재전송 횟수와 이 최종 패킷이 전송되는 시간을 제한하면 종료된 연결에 소비되는 노력이 제한된다.¶

CONNECTION_CLOSE 프레임을 포함하는 패킷을 재전송하지 않기로 선택한 엔드포인트는 피어가 첫 번째 그러한 패킷을 놓칠 위험이 있다. 종료된 연결에 대해 계속 데이터를 수신하는 엔드포인트가 사용할 수 있는 유일한 메커니즘은 상태 없는 재설정 절차(Section 10.3)를 시도하는 것이다.¶

Initial 패킷에 대한 AEAD는 강한 인증을 제공하지 않으므로, 엔드포인트는 유효하지 않은 Initial 패킷을 폐기할 수 MAY 있다. 이 명세가 달리 연결 오류를 요구하는 경우에도 Initial 패킷을 폐기하는 것은 허용된다. 엔드포인트는 패킷 안의 프레임을 처리하지 않거나, 처리의 효과를 되돌리는 경우에만 패킷을 폐기할 수 있다. 유효하지 않은 Initial 패킷을 폐기하는 것은 서비스 거부에 대한 노출을 줄이는 데 사용될 수 있다. Section 21.2를 참조한다.¶

11.2. 스트림 오류

애플리케이션 수준 오류가 단일 스트림에 영향을 주지만 그 외에는 연결을 복구 가능한 상태로 남긴다면, 엔드포인트는 적절한 오류 코드가 있는 RESET_STREAM 프레임(Section 19.4)을 보내 영향받은 스트림만 종료할 수 있다.¶

애플리케이션 프로토콜의 관여 없이 스트림을 재설정하면 애플리케이션 프로토콜이 복구할 수 없는 상태로 들어갈 수 있다. RESET_STREAM은 QUIC를 사용하는 애플리케이션 프로토콜에 의해서만 시작되어야 MUST 한다.¶

RESET_STREAM에 운반되는 애플리케이션 오류 코드의 의미론은 애플리케이션 프로토콜이 정의한다. 애플리케이션 프로토콜만 스트림이 종료되도록 만들 수 있다. 애플리케이션 프로토콜의 로컬 인스턴스는 직접 API 호출을 사용하고, 원격 인스턴스는 STOP_SENDING 프레임을 사용하며, 이는 자동 RESET_STREAM을 트리거한다.¶

애플리케이션 프로토콜은 어느 엔드포인트에 의해 조기에 취소된 스트림을 처리하는 규칙을 정의해야 SHOULD 한다.¶

12.1. 보호된 패킷

QUIC 패킷은 패킷 유형에 따라 서로 다른 수준의 암호화 보호를 가진다. 패킷 보호의 세부사항은 [QUIC-TLS]에 있으며, 이 섹션은 제공되는 보호의 개요를 포함한다.¶

Version Negotiation 패킷에는 암호화 보호가 없다. [QUIC-INVARIANTS]를 참조한다.¶

Retry 패킷은 우발적 수정을 방지하기 위해 AEAD 함수 [AEAD]를 사용한다.¶

Initial 패킷은 AEAD 함수를 사용하며, 이 함수의 키는 네트워크상에서 보이는 값을 사용해 파생된다. 따라서 Initial 패킷에는 효과적인 기밀성 보호가 없다. Initial 보호는 패킷의 송신자가 네트워크 경로상에 있음을 보장하기 위해 존재한다. 클라이언트로부터 Initial 패킷을 수신하는 모든 엔티티는 패킷의 내용을 읽고 어느 엔드포인트에서든 성공적으로 인증될 Initial 패킷을 생성할 수 있게 하는 키를 복구할 수 있다. AEAD는 또한 Initial 패킷을 우발적 수정으로부터 보호한다.¶

다른 모든 패킷은 암호화 핸드셰이크에서 파생된 키로 보호된다. 암호화 핸드셰이크는 통신하는 엔드포인트만 Handshake, 0-RTT 및 1-RTT 패킷에 해당하는 키를 수신하도록 보장한다. 0-RTT 및 1-RTT 키로 보호된 패킷은 강한 기밀성 및 무결성 보호를 가진다.¶

일부 패킷 유형에 나타나는 Packet Number 필드에는 헤더 보호의 일부로 적용되는 대체 기밀성 보호가 있다. 자세한 내용은 Section 5.4 of [QUIC-TLS]를 참조한다. 기본 패킷 번호는 주어진 패킷 번호 공간에서 전송되는 각 패킷마다 증가한다. 자세한 내용은 Section 12.3을 참조한다.¶

12.2. 패킷 병합

Initial(Section 17.2.2), 0-RTT(Section 17.2.3), 및 Handshake (Section 17.2.4) 패킷은 패킷의 끝을 결정하는 Length 필드를 포함한다. 길이는 Packet Number 및 Payload 필드를 모두 포함하며, 이 둘은 모두 기밀성 보호가 적용되고 처음에는 길이를 알 수 없다. Payload 필드의 길이는 헤더 보호가 제거된 후 알게 된다.¶

Length 필드를 사용하면 송신자는 여러 QUIC 패킷을 하나의 UDP 데이터그램으로 병합할 수 있다. 이는 암호화 핸드셰이크를 완료하고 데이터 전송을 시작하는 데 필요한 UDP 데이터그램 수를 줄일 수 있다. 또한 Path Maximum Transmission Unit(PMTU) 프로브를 구성하는 데 사용할 수 있다. Section 14.4.1을 참조한다. 수신자는 병합된 패킷을 처리할 수 있어야 MUST 한다.¶

암호화 수준이 증가하는 순서(Initial, 0-RTT, Handshake, 1-RTT; Section 4.1.4 of [QUIC-TLS] 참조)로 패킷을 병합하면 수신자가 단일 패스로 모든 패킷을 처리할 가능성이 높아진다. 짧은 헤더가 있는 패킷은 길이를 포함하지 않으므로 UDP 데이터그램에 포함된 마지막 패킷일 수밖에 없다. 엔드포인트는 같은 암호화 수준에서 보내야 하는 프레임들이라면, 같은 암호화 수준의 여러 패킷을 병합하는 대신 단일 패킷에 여러 프레임을 포함해야 SHOULD 한다.¶

수신자는 UDP 데이터그램에 포함된 첫 번째 패킷의 정보를 기반으로 라우팅할 수 MAY 있다. 송신자는 서로 다른 연결 ID를 가진 QUIC 패킷을 단일 UDP 데이터그램으로 병합해서는 MUST NOT 안 된다. 수신자는 데이터그램의 첫 번째 패킷과 다른 Destination Connection ID를 가진 모든 후속 패킷을 무시해야 SHOULD 한다.¶

단일 UDP 데이터그램으로 병합된 모든 QUIC 패킷은 분리되어 있으며 완전하다. 병합된 QUIC 패킷의 수신자는 각 QUIC 패킷을 개별적으로 처리하고, 서로 다른 UDP 데이터그램의 페이로드로 수신된 것처럼 별도로 확인 응답해야 MUST 한다. 예를 들어 복호화가 실패하면(키를 사용할 수 없거나 다른 이유로), 수신자는 그 패킷을 폐기하거나 나중 처리를 위해 버퍼링할 수 MAY 있으며, 남은 패킷 처리를 시도해야 MUST 한다.¶

Retry 패킷(Section 17.2.5), Version Negotiation 패킷(Section 17.2.1), 및 짧은 헤더가 있는 패킷(Section 17.3)은 Length 필드를 포함하지 않으므로 같은 UDP 데이터그램에서 다른 패킷이 뒤따를 수 없다. 또한 Retry 또는 Version Negotiation 패킷이 다른 패킷과 병합되는 상황은 없다는 점에 유의한다.¶

12.3. 패킷 번호

패킷 번호는 0부터 2⁶²-1 범위의 정수이다. 이 번호는 패킷 보호를 위한 암호화 nonce를 결정하는 데 사용된다. 각 엔드포인트는 송신 및 수신을 위해 별도의 패킷 번호를 유지한다.¶

패킷 번호는 ACK 프레임(Section 19.3)의 Largest Acknowledged 필드에 전체로 표현될 수 있어야 하므로 이 범위로 제한된다. 그러나 긴 헤더나 짧은 헤더에 존재할 때, 패킷 번호는 줄어들고 1~4바이트로 인코딩된다. Section 17.1을 참조한다.¶

Version Negotiation(Section 17.2.1) 및 Retry(Section 17.2.5) 패킷은 패킷 번호를 포함하지 않는다.¶

QUIC에서 패킷 번호는 세 공간으로 나뉜다:¶

Initial 공간:

모든 Initial 패킷(Section 17.2.2)은 이 공간에 있다.¶

Handshake 공간:

모든 Handshake 패킷(Section 17.2.4)은 이 공간에 있다.¶

애플리케이션 데이터 공간:

모든 0-RTT(Section 17.2.3) 및 1-RTT(Section 17.3.1) 패킷은 이 공간에 있다.¶

[QUIC-TLS]에 설명된 것처럼, 각 패킷 유형은 서로 다른 보호 키를 사용한다.¶

개념적으로 패킷 번호 공간은 패킷을 처리하고 확인 응답할 수 있는 컨텍스트이다. Initial 패킷은 Initial 패킷 보호 키로만 보낼 수 있고, 역시 Initial 패킷인 패킷에서만 확인 응답될 수 있다. 마찬가지로, Handshake 패킷은 Handshake 암호화 수준에서 전송되며 Handshake 패킷에서만 확인 응답될 수 있다.¶

이는 서로 다른 패킷 번호 공간에서 전송되는 데이터 사이의 암호화적 분리를 강제한다. 각 공간의 패킷 번호는 패킷 번호 0에서 시작한다. 같은 패킷 번호 공간에서 이후 전송되는 패킷은 패킷 번호를 최소 1만큼 증가시켜야 MUST 한다.¶

0-RTT 및 1-RTT 데이터는 두 패킷 유형 사이에서 손실 복구 알고리즘을 더 쉽게 구현할 수 있도록 같은 패킷 번호 공간에 존재한다.¶

QUIC 엔드포인트는 하나의 연결에서 같은 패킷 번호 공간 안의 패킷 번호를 재사용해서는 MUST NOT 안 된다. 송신용 패킷 번호가 2⁶²-1에 도달하면, 송신자는 CONNECTION_CLOSE 프레임이나 추가 패킷을 보내지 않고 연결을 닫아야 MUST 한다. 엔드포인트는 이후 수신하는 패킷에 대한 응답으로 Stateless Reset(Section 10.3)을 보낼 수 MAY 있다.¶

수신자는 같은 패킷 번호 공간에서 같은 패킷 번호를 가진 다른 패킷을 처리하지 않았다는 것이 확실하지 않은 한, 새로 보호가 해제된 패킷을 폐기해야 MUST 한다. 중복 억제는 Section 9.5 of [QUIC-TLS]에 설명된 이유 때문에 패킷 보호를 제거한 후 수행되어야 MUST 한다.¶

중복 감지를 위해 모든 개별 패킷을 추적하는 엔드포인트는 과도한 상태를 축적할 위험이 있다. 중복 감지에 필요한 데이터는, 그보다 낮은 번호의 모든 패킷이 즉시 삭제되는 최소 패킷 번호를 유지하여 제한할 수 있다. 모든 최소값은 왕복 시간의 큰 변동을 고려해야 하며, 여기에는 피어가 훨씬 더 큰 왕복 시간을 가진 네트워크 경로를 탐색할 가능성도 포함된다. Section 9를 참조한다.¶

송신자의 패킷 번호 인코딩과 수신자의 디코딩은 Section 17.1에 설명되어 있다.¶

12.4. 프레임과 프레임 유형

패킷 보호를 제거한 후 QUIC 패킷의 페이로드는 Figure 11에 표시된 것처럼 완전한 프레임의 시퀀스로 구성된다. Version Negotiation, Stateless Reset 및 Retry 패킷은 프레임을 포함하지 않는다.¶

Packet Payload {
  Frame (8..) ...,
}

프레임을 포함하는 패킷의 페이로드는 최소 하나의 프레임을 포함해야 MUST 하며, 여러 프레임과 여러 프레임 유형을 포함할 수 MAY 있다. 엔드포인트는 프레임을 포함하지 않는 패킷의 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다. 프레임은 항상 단일 QUIC 패킷 안에 들어가며 여러 패킷에 걸칠 수 없다.¶

각 프레임은 그 유형을 나타내는 Frame Type으로 시작하고, 그 뒤에 유형에 따라 달라지는 추가 필드가 이어진다:¶

Frame {
  Frame Type (i),
  Type-Dependent Fields (..),
}

Table 3은 이 명세에 정의된 각 프레임 유형에 대한 정보를 나열하고 요약한다. 이 요약에 대한 설명은 표 뒤에 포함되어 있다.¶

각 프레임 유형의 형식과 의미론은 Section 19에서 더 자세히 설명된다. 이 섹션의 나머지는 중요하고 일반적인 정보의 요약을 제공한다.¶

ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED 및 CONNECTION_CLOSE 프레임의 Frame Type은 다른 프레임별 플래그를 운반하는 데 사용된다. 다른 모든 프레임의 경우 Frame Type 필드는 단순히 프레임을 식별한다.¶

Table 3의 "Pkts" 열은 각 프레임 유형이 나타날 수 있는 패킷 유형을 나열하며, 다음 문자로 표시된다:¶

I:

Initial(Section 17.2.2)¶

H:

Handshake(Section 17.2.4)¶

0:

0-RTT(Section 17.2.3)¶

1:

1-RTT(Section 17.3.1)¶

ih:

type 0x1c의 CONNECTION_CLOSE 프레임만 Initial 또는 Handshake 패킷에 나타날 수 있다.¶

이러한 제한에 대한 자세한 내용은 Section 12.5를 참조한다. 모든 프레임은 1-RTT 패킷에 나타날 수 있음에 유의한다. 엔드포인트는 허용되지 않는 패킷 유형에서 프레임을 수신한 것을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다.¶

Table 3의 "Spec" 열은 다음 문자로 표시되는, 해당 프레임 유형의 처리 또는 생성에 적용되는 특수 규칙을 요약한다:¶

N:

이 표시가 있는 프레임만 포함하는 패킷은 ack-eliciting이 아니다. Section 13.2를 참조한다.¶

C:

이 표시가 있는 프레임만 포함하는 패킷은 혼잡 제어 목적의 비행 중 바이트에 포함되지 않는다. [QUIC-RECOVERY]를 참조한다.¶

P:

이 표시가 있는 프레임만 포함하는 패킷은 연결 마이그레이션 중 새 네트워크 경로를 탐색하는 데 사용할 수 있다. Section 9.1을 참조한다.¶

F:

이 표시가 있는 프레임의 내용은 흐름 제어를 받는다. Section 4를 참조한다.¶

Table 3의 "Pkts" 및 "Spec" 열은 IANA 레지스트리의 일부를 구성하지 않는다. Section 22.4를 참조한다.¶

엔드포인트는 알 수 없는 유형의 프레임 수신을 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

이 QUIC 버전의 모든 프레임은 멱등적이다. 즉, 유효한 프레임은 두 번 이상 수신되어도 바람직하지 않은 부작용이나 오류를 일으키지 않는다.¶

Frame Type 필드는 한 가지 예외를 제외하고 가변 길이 정수 인코딩 (Section 16 참조)을 사용한다. 프레임 파싱의 단순하고 효율적인 구현을 보장하기 위해, 프레임 유형은 가능한 가장 짧은 인코딩을 사용해야 MUST 한다. 이 문서에 정의된 프레임 유형의 경우, 이는 이 값들을 2바이트, 4바이트 또는 8바이트 가변 길이 정수로 인코딩할 수 있더라도 단일 바이트 인코딩을 의미한다. 예를 들어 0x4001은 값이 1인 가변 길이 정수의 정당한 2바이트 인코딩이지만, PING 프레임은 항상 값 0x01의 단일 바이트로 인코딩된다. 이 규칙은 현재와 향후의 모든 QUIC 프레임 유형에 적용된다. 엔드포인트는 필요한 것보다 긴 인코딩을 사용하는 프레임 유형의 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리할 수 MAY 있다.¶

12.5. 프레임과 번호 공간

일부 프레임은 서로 다른 패킷 번호 공간에서 금지된다. 여기의 규칙은 TLS의 규칙을 일반화한 것으로, 연결 설정과 관련된 프레임은 일반적으로 어떤 패킷 번호 공간의 패킷에도 나타날 수 있는 반면, 데이터 전송과 관련된 프레임은 애플리케이션 데이터 패킷 번호 공간에만 나타날 수 있다:¶

• PADDING, PING 및 CRYPTO 프레임은 어떤 패킷 번호 공간에도 나타날 수 MAY 있다.¶
• QUIC 계층의 오류를 신호하는 CONNECTION_CLOSE 프레임 (type 0x1c)은 어떤 패킷 번호 공간에도 나타날 수 MAY 있다. 애플리케이션 오류를 신호하는 CONNECTION_CLOSE 프레임 (type 0x1d)은 애플리케이션 데이터 패킷 번호 공간에만 나타나야 MUST 한다.¶
• ACK 프레임은 어떤 패킷 번호 공간에도 나타날 수 MAY 있지만, 해당 패킷 번호 공간에 나타난 패킷만 확인 응답할 수 있다. 그러나 아래에 언급된 것처럼, 0-RTT 패킷은 ACK 프레임을 포함할 수 없다.¶
• 다른 모든 프레임 유형은 애플리케이션 데이터 패킷 번호 공간에서만 전송되어야 MUST 한다.¶

다음 프레임은 여러 이유로 0-RTT 패킷에서 보낼 수 없음에 유의한다: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE 및 RETIRE_CONNECTION_ID. 서버는 0-RTT 패킷에서 이러한 프레임을 수신한 것을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리할 수 MAY 있다.¶

13.1. 패킷 처리

패킷 보호가 성공적으로 제거되고 패킷에 포함된 모든 프레임이 처리되기 전에는 패킷에 확인 응답해서는 MUST NOT 안 된다. STREAM 프레임의 경우, 이는 데이터가 애플리케이션 프로토콜에 의해 수신될 준비로 큐에 들어갔음을 의미하지만, 데이터가 전달되고 소비되어야 함을 요구하지는 않는다.¶

패킷이 완전히 처리되면, 수신자는 수신한 패킷의 패킷 번호를 포함하는 하나 이상의 ACK 프레임을 보내 수신을 확인 응답한다.¶

엔드포인트는 조건을 감지할 수 있다면, 자신이 보내지 않은 패킷에 대한 확인 응답의 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 SHOULD 한다. 이를 달성하는 방법에 대한 추가 논의는 Section 21.4를 참조한다.¶

13.2. 확인 응답 생성

엔드포인트는 자신이 수신하고 처리하는 모든 패킷에 확인 응답한다. 그러나 ack-eliciting 패킷만 최대 ack 지연 내에 ACK 프레임이 전송되게 한다. ack-eliciting이 아닌 패킷은 다른 이유로 ACK 프레임이 전송될 때만 확인 응답된다.¶

어떤 이유로든 패킷을 보낼 때, 엔드포인트는 최근에 ACK 프레임이 전송되지 않았다면 ACK 프레임을 포함하려고 시도해야 SHOULD 한다. 그렇게 하면 피어에서 적시에 손실을 감지하는 데 도움이 된다.¶

일반적으로 수신자의 빈번한 피드백은 손실 및 혼잡 대응을 개선하지만, 이는 모든 ack-eliciting 패킷에 대한 응답으로 ACK 프레임을 보내는 수신자가 생성하는 과도한 부하와 균형을 이루어야 한다. 아래에 제공되는 지침은 이 균형을 맞추려 한다.¶

13.3. 정보의 재전송

손실된 것으로 판단된 QUIC 패킷은 전체가 재전송되지 않는다. 손실된 패킷 안에 포함된 프레임에도 같은 원칙이 적용된다. 대신 프레임에 운반될 수 있었던 정보는 필요에 따라 새 프레임으로 다시 전송된다.¶

손실된 것으로 판단된 정보를 운반하기 위해 새 프레임과 패킷이 사용된다. 일반적으로 해당 정보를 포함하는 패킷이 손실된 것으로 판단되면 정보가 다시 전송되고, 해당 정보를 포함하는 패킷이 확인 응답되면 전송이 중단된다.¶

• CRYPTO 프레임으로 전송된 데이터는 모든 데이터가 확인 응답될 때까지 [QUIC-RECOVERY]의 규칙에 따라 재전송된다. Initial 및 Handshake 패킷용 CRYPTO 프레임의 데이터는 해당 패킷 번호 공간의 키가 폐기될 때 폐기된다.¶
• STREAM 프레임으로 전송된 애플리케이션 데이터는 엔드포인트가 해당 스트림에 대해 RESET_STREAM을 보낸 경우를 제외하고 새 STREAM 프레임으로 재전송된다. 엔드포인트가 RESET_STREAM 프레임을 보내면 더 이상의 STREAM 프레임은 필요하지 않다.¶
• ACK 프레임은 Section 13.2.1에 설명된 것처럼 가장 최근의 확인 응답 집합과 가장 큰 확인 응답된 패킷으로부터의 확인 응답 지연을 운반한다. ACK 프레임을 포함하는 패킷의 전송을 지연하거나 오래된 ACK 프레임을 다시 보내면, 피어가 부풀려진 RTT 샘플을 생성하거나 ECN을 불필요하게 비활성화할 수 있다.¶
• RESET_STREAM 프레임에 운반되는 스트림 전송 취소는 확인 응답될 때까지 또는 모든 스트림 데이터가 피어에 의해 확인 응답될 때까지 (즉, 스트림의 송신 부분에서 "Reset Recvd" 또는 "Data Recvd" 상태에 도달할 때까지) 전송된다. RESET_STREAM 프레임의 내용은 다시 전송될 때 변경되어서는 MUST NOT 안 된다.¶
• 마찬가지로, STOP_SENDING 프레임으로 인코딩된 스트림 전송 취소 요청은 스트림의 수신 부분이 "Data Recvd" 또는 "Reset Recvd" 상태에 들어갈 때까지 전송된다. Section 3.5를 참조한다.¶
• CONNECTION_CLOSE 프레임을 포함하는 패킷을 비롯한 연결 닫기 신호는 패킷 손실이 감지될 때 다시 전송되지 않는다. 이러한 신호를 다시 보내는 것은 Section 10에 설명되어 있다.¶
• 현재 연결 최대 데이터는 MAX_DATA 프레임으로 전송된다. 가장 최근에 전송된 MAX_DATA 프레임을 포함하는 패킷이 손실된 것으로 선언되거나 엔드포인트가 한도를 업데이트하기로 결정하면, 업데이트된 값이 MAX_DATA 프레임으로 전송된다. 한도는 자주 증가할 수 있고 불필요하게 많은 MAX_DATA 프레임이 전송되도록 만들 수 있으므로, 이 프레임을 너무 자주 보내지 않도록 주의해야 한다. Section 4.2를 참조한다.¶
• 현재 최대 스트림 데이터 오프셋은 MAX_STREAM_DATA 프레임으로 전송된다. MAX_DATA와 마찬가지로, 스트림에 대한 가장 최근의 MAX_STREAM_DATA 프레임을 포함하는 패킷이 손실되거나 한도가 업데이트되면 업데이트된 값이 전송되며, 프레임이 너무 자주 전송되지 않도록 주의한다. 엔드포인트는 스트림의 수신 부분이 "Size Known" 또는 "Reset Recvd" 상태에 들어가면 MAX_STREAM_DATA 프레임 전송을 중단해야 SHOULD 한다.¶
• 주어진 유형의 스트림에 대한 한도는 MAX_STREAMS 프레임으로 전송된다. MAX_DATA와 마찬가지로, 스트림 유형에 대한 가장 최근의 MAX_STREAMS 프레임을 포함하는 패킷이 손실된 것으로 선언되거나 한도가 업데이트되면 업데이트된 값이 전송되며, 프레임이 너무 자주 전송되지 않도록 주의한다.¶
• 차단 신호는 DATA_BLOCKED, STREAM_DATA_BLOCKED 및 STREAMS_BLOCKED 프레임으로 운반된다. DATA_BLOCKED 프레임은 연결 범위를 가지며, STREAM_DATA_BLOCKED 프레임은 스트림 범위를 가지고, STREAMS_BLOCKED 프레임은 특정 스트림 유형에 범위가 지정된다. 어떤 범위에 대한 가장 최근 프레임을 포함하는 패킷이 손실되면 새 프레임이 전송되지만, 엔드포인트가 해당 한도에서 차단되어 있는 동안에만 전송된다. 이러한 프레임은 항상 전송 시점에 차단을 일으키는 한도를 포함한다.¶
• PATH_CHALLENGE 프레임을 사용하는 활성 여부 또는 경로 검증 검사는 일치하는 PATH_RESPONSE 프레임이 수신될 때까지 또는 활성 여부나 경로 검증 검사가 더 이상 필요하지 않을 때까지 주기적으로 전송된다. PATH_CHALLENGE 프레임은 전송될 때마다 서로 다른 페이로드를 포함한다.¶
• PATH_RESPONSE 프레임을 사용하는 경로 검증 응답은 한 번만 전송된다. 피어는 추가 PATH_RESPONSE 프레임을 유도하기 위해 필요에 따라 더 많은 PATH_CHALLENGE 프레임을 보낼 것으로 예상된다.¶
• 새 연결 ID는 NEW_CONNECTION_ID 프레임으로 전송되며, 이를 포함하는 패킷이 손실되면 재전송된다. 이 프레임의 재전송은 같은 시퀀스 번호 값을 운반한다. 마찬가지로 폐기된 연결 ID는 RETIRE_CONNECTION_ID 프레임으로 전송되며, 이를 포함하는 패킷이 손실되면 재전송된다.¶
• NEW_TOKEN 프레임은 이를 포함하는 패킷이 손실되면 재전송된다. 프레임 내용의 직접 비교 외에는 재정렬되거나 중복된 NEW_TOKEN 프레임을 감지하기 위한 특별한 지원은 제공되지 않는다.¶
• PING 및 PADDING 프레임은 정보를 포함하지 않으므로, 손실된 PING 또는 PADDING 프레임은 복구가 필요하지 않다.¶
• HANDSHAKE_DONE 프레임은 확인 응답될 때까지 재전송되어야 MUST 한다.¶

애플리케이션이 지정한 우선순위가 달리 나타내지 않는 한, 엔드포인트는 새 데이터를 보내는 것보다 데이터 재전송을 우선해야 SHOULD 한다. Section 2.3을 참조한다.¶

송신자가 패킷을 보낼 때마다 최신 정보를 포함하는 프레임을 조립하는 것이 권장되지만, 손실된 패킷의 프레임 복사본을 재전송하는 것이 금지되지는 않는다. 프레임 복사본을 재전송하는 송신자는 패킷 번호 길이, 연결 ID 길이 및 경로 MTU의 변경으로 사용 가능한 페이로드 크기가 줄어드는 경우를 처리해야 한다. 수신자는 오래된 패킷에서 발견된 값보다 작은 최대 데이터 값을 운반하는 MAX_DATA 프레임과 같은 오래된 프레임을 포함하는 패킷을 수락해야 MUST 한다.¶

송신자는 패킷이 확인 응답된 후 해당 패킷의 정보를 재전송하는 것을 피해야 SHOULD 한다. 여기에는 손실된 것으로 선언된 후 확인 응답되는 패킷도 포함되며, 이는 네트워크 재정렬이 있을 때 발생할 수 있다. 이를 위해서는 송신자가 패킷이 손실된 것으로 선언된 후에도 패킷에 대한 정보를 유지해야 한다. 송신자는 PTO(Section 6.2 of [QUIC-RECOVERY])와 같이 재정렬을 충분히 허용하는 시간이 지난 후, 또는 메모리 한도에 도달하는 것과 같은 다른 이벤트를 기준으로 이 정보를 폐기할 수 있다.¶

손실을 감지하면 송신자는 적절한 혼잡 제어 조치를 취해야 MUST 한다. 손실 감지 및 혼잡 제어의 세부사항은 [QUIC-RECOVERY]에 설명되어 있다.¶

13.4. 명시적 혼잡 알림

QUIC 엔드포인트는 네트워크 혼잡을 감지하고 이에 대응하기 위해 ECN [RFC3168]을 사용할 수 있다. ECN은 엔드포인트가 IP 패킷의 ECN 필드에 ECN-Capable Transport(ECT) 코드포인트를 설정할 수 있게 한다. 그러면 네트워크 노드는 패킷을 삭제하는 대신 ECN 필드에 ECN-CE 코드포인트를 설정하여 혼잡을 나타낼 수 있다 [RFC8087]. 엔드포인트는 [QUIC-RECOVERY]에 설명된 대로, 보고된 혼잡에 대응해 전송 속도를 줄인다.¶

ECN을 활성화하기 위해, 송신 QUIC 엔드포인트는 먼저 경로가 ECN 표시를 지원하는지와 피어가 수신한 IP 헤더의 ECN 값을 보고하는지 판단한다. Section 13.4.2를 참조한다.¶

14.1. Initial 데이터그램 크기

클라이언트는 Initial 패킷에 PADDING 프레임을 추가하거나 Initial 패킷을 병합하여(Section 12.2 참조) Initial 패킷을 운반하는 모든 UDP 데이터그램의 페이로드를 허용되는 가장 작은 최대 데이터그램 크기인 최소 1200바이트로 확장해야 MUST 한다. Initial 패킷은 수신자가 폐기할 유효하지 않은 패킷과도 병합될 수 있다. 마찬가지로 서버는 ack-eliciting Initial 패킷을 운반하는 모든 UDP 데이터그램의 페이로드를 허용되는 가장 작은 최대 데이터그램 크기인 최소 1200바이트로 확장해야 MUST 한다.¶

이 크기의 UDP 데이터그램을 보내면 네트워크 경로가 양방향으로 합리적인 Path Maximum Transmission Unit(PMTU)을 지원함을 보장한다. 또한 Initial 패킷을 확장하는 클라이언트는 검증되지 않은 클라이언트 주소로 향하는 서버 응답으로 인한 증폭 공격의 진폭을 줄이는 데 도움이 된다. Section 8을 참조한다.¶

Initial 패킷을 포함하는 데이터그램은 송신자가 네트워크 경로와 피어가 자신이 선택한 크기를 모두 지원한다고 믿는 경우 1200바이트를 초과할 수 MAY 있다.¶

서버는 허용되는 가장 작은 최대 데이터그램 크기인 1200바이트보다 작은 페이로드를 가진 UDP 데이터그램에 운반된 Initial 패킷을 폐기해야 MUST 한다. 서버는 PROTOCOL_VIOLATION 오류 코드가 있는 CONNECTION_CLOSE 프레임을 보내 연결을 즉시 닫을 수도 MAY 있다. Section 10.2.3을 참조한다.¶

서버는 클라이언트의 주소를 검증하기 전 자신이 보내는 바이트 수도 제한해야 MUST 한다. Section 8을 참조한다.¶

14.2. Path Maximum Transmission Unit

PMTU는 IP 헤더, UDP 헤더 및 UDP 페이로드를 포함한 전체 IP 패킷의 최대 크기이다. UDP 페이로드에는 하나 이상의 QUIC 패킷 헤더와 보호된 페이로드가 포함된다. PMTU는 경로 특성에 따라 달라질 수 있으므로 시간이 지남에 따라 변경될 수 있다. 엔드포인트가 특정 시점에 보내는 가장 큰 UDP 페이로드를 엔드포인트의 최대 데이터그램 크기라고 한다.¶

엔드포인트는 목적지까지의 경로가 조각화 없이 원하는 최대 데이터그램 크기를 지원할지 판단하기 위해 DPLPMTUD(Section 14.3) 또는 PMTUD(Section 14.2.1)를 사용해야 SHOULD 한다. 이러한 메커니즘이 없는 경우 QUIC 엔드포인트는 허용되는 가장 작은 최대 데이터그램 크기보다 큰 데이터그램을 보내서는 SHOULD NOT 안 된다.¶

DPLPMTUD와 PMTUD는 모두 현재 최대 데이터그램 크기보다 큰 데이터그램을 보내며, 이를 PMTU 프로브라고 한다. PMTU 프로브로 전송되지 않는 모든 QUIC 패킷은 데이터그램이 조각화되거나 삭제되는 것을 피하기 위해 최대 데이터그램 크기 안에 맞도록 크기가 정해져야 SHOULD 한다 [RFC8085].¶

QUIC 엔드포인트가 로컬 및 원격 IP 주소 쌍 사이의 PMTU가 허용되는 가장 작은 최대 데이터그램 크기인 1200바이트를 지원할 수 없다고 판단하면, 해당 경로에서 PMTU 프로브 안의 패킷이나 CONNECTION_CLOSE 프레임을 포함하는 패킷을 제외하고 QUIC 패킷 전송을 즉시 중단해야 MUST 한다. 대체 경로를 찾을 수 없으면 엔드포인트는 연결을 종료할 수 MAY 있다.¶

로컬 주소와 원격 주소의 각 쌍은 서로 다른 PMTU를 가질 수 있다. 따라서 어떤 종류의 PMTU 발견이든 구현하는 QUIC 구현은 로컬 및 원격 IP 주소의 각 조합에 대해 최대 데이터그램 크기를 유지해야 SHOULD 한다.¶

QUIC 구현은 알 수 없는 터널 오버헤드나 IP 헤더 옵션/확장을 고려하기 위해 최대 데이터그램 크기를 더 보수적으로 계산할 수 MAY 있다.¶

14.3. Datagram Packetization Layer PMTU Discovery

DPLPMTUD [DPLPMTUD]는 PMTU 프로브에 운반되는 QUIC 패킷의 손실 또는 확인 응답 추적에 의존한다. PADDING 프레임을 사용하는 DPLPMTUD용 PMTU 프로브는 Section 4.1 of [DPLPMTUD]에 정의된 "Probing using padding data"를 구현한다.¶

엔드포인트는 BASE_PLPMTU(Section 5.1 of [DPLPMTUD])의 초기값을 QUIC의 허용되는 가장 작은 최대 데이터그램 크기와 일치하도록 설정해야 SHOULD 한다. MIN_PLPMTU는 BASE_PLPMTU와 같다.¶

DPLPMTUD를 구현하는 QUIC 엔드포인트는 로컬 및 원격 IP 주소의 각 조합에 대해 DPLPMTUD Maximum Packet Size(MPS) (Section 4.4 of [DPLPMTUD])를 유지한다. 이는 최대 데이터그램 크기에 해당한다.¶

14.4. QUIC PMTU 프로브 보내기

PMTU 프로브는 ack-eliciting 패킷이다.¶

엔드포인트는 PMTU 프로브의 내용을 PING 및 PADDING 프레임으로 제한할 수 있다. 현재 최대 데이터그램 크기보다 큰 패킷은 네트워크에 의해 삭제될 가능성이 더 높기 때문이다. 따라서 PMTU 프로브에 운반되는 QUIC 패킷의 손실은 혼잡의 신뢰할 수 있는 지표가 아니며 혼잡 제어 반응을 트리거해서는 SHOULD NOT 안 된다. Section 3 of [DPLPMTUD]의 Item 7을 참조한다. 그러나 PMTU 프로브는 혼잡 윈도우를 소비하며, 이는 애플리케이션의 후속 전송을 지연시킬 수 있다.¶

17.1. 패킷 번호 인코딩 및 디코딩

패킷 번호는 0부터 2⁶²-1 범위의 정수이다 (Section 12.3). 긴 패킷 헤더나 짧은 패킷 헤더에 존재할 때, 패킷 번호는 1~4바이트로 인코딩된다. 패킷 번호를 나타내는 데 필요한 비트 수는 패킷 번호의 최하위 비트만 포함함으로써 줄어든다.¶

인코딩된 패킷 번호는 Section 5.4 of [QUIC-TLS]에 설명된 대로 보호된다.¶

패킷 번호 공간에 대한 확인 응답을 수신하기 전에는, 아래에 설명된 것처럼 잘라내지 말고 전체 패킷 번호가 포함되어야 MUST 한다.¶

패킷 번호 공간에 대한 확인 응답을 수신한 후, 송신자는 가장 큰 확인 응답된 패킷 번호와 전송 중인 패킷 번호 사이의 차이보다 두 배 넘게 큰 범위를 나타낼 수 있는 패킷 번호 크기를 사용해야 MUST 한다. 그러면 패킷을 수신하는 피어는, 더 높은 번호의 많은 패킷을 수신한 후에야 패킷이 도착할 정도로 전송 중 지연되지 않는 한, 패킷 번호를 올바르게 디코딩한다. 엔드포인트는 이후 전송된 패킷들 뒤에 패킷이 도착하더라도 패킷 번호가 복구될 수 있도록 충분히 큰 패킷 번호 인코딩을 사용해야 SHOULD 한다.¶

그 결과, 패킷 번호 인코딩의 크기는 새 패킷을 포함하여 연속된 확인 응답되지 않은 패킷 번호 수의 2진 로그보다 최소 1비트 더 크다. 패킷 번호 인코딩에 대한 의사코드와 예는 Appendix A.2에서 찾을 수 있다.¶

수신자에서는 전체 패킷 번호를 복구하기 전에 패킷 번호의 보호가 제거된다. 그런 다음 전체 패킷 번호는 존재하는 유효 비트 수, 그 비트들의 값, 그리고 성공적으로 인증된 패킷에서 수신된 가장 큰 패킷 번호를 기준으로 재구성된다. 전체 패킷 번호를 복구하는 것은 패킷 보호 제거를 성공적으로 완료하는 데 필요하다.¶

헤더 보호가 제거되면, 패킷 번호는 다음으로 기대되는 패킷에 가장 가까운 패킷 번호 값을 찾아 디코딩된다. 다음으로 기대되는 패킷은 수신된 가장 높은 패킷 번호에 1을 더한 것이다. 패킷 번호 디코딩에 대한 의사코드와 예는 Appendix A.3에서 찾을 수 있다.¶

17.2. 긴 헤더 패킷

Long Header Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2),
  Type-Specific Bits (4),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..160),
  Source Connection ID Length (8),
  Source Connection ID (0..160),
  Type-Specific Payload (..),
}

긴 헤더는 1-RTT 키가 설정되기 전에 전송되는 패킷에 사용된다. 1-RTT 키를 사용할 수 있게 되면 송신자는 짧은 헤더를 사용하여 패킷을 보내도록 전환한다(Section 17.3). 긴 형식은 Version Negotiation 패킷과 같은 특수 패킷이 이 균일한 고정 길이 패킷 형식으로 표현될 수 있게 한다. 긴 헤더를 사용하는 패킷은 다음 필드를 포함한다:¶

Header Form:

byte 0(첫 번째 바이트)의 최상위 비트(0x80)는 긴 헤더의 경우 1로 설정된다.¶

Fixed Bit:

byte 0의 다음 비트(0x40)는 패킷이 Version Negotiation 패킷이 아닌 한 1로 설정된다. 이 비트에 0 값을 포함하는 패킷은 이 버전에서 유효한 패킷이 아니며 폐기되어야 MUST 한다. 이 비트의 값이 1이면 QUIC가 다른 프로토콜과 공존할 수 있다. [RFC7983]을 참조한다.¶

Long Packet Type:

byte 0의 다음 두 비트(마스크 0x30을 가진 비트)는 패킷 유형을 포함한다. 패킷 유형은 Table 5에 나열되어 있다.¶

Type-Specific Bits:

byte 0의 하위 네 비트(마스크 0x0f를 가진 비트)의 의미론은 패킷 유형에 의해 결정된다.¶

Version:

QUIC Version은 첫 번째 바이트 뒤에 오는 32비트 필드이다. 이 필드는 사용 중인 QUIC 버전을 나타내며, 나머지 프로토콜 필드가 어떻게 해석되는지 결정한다.¶

Destination Connection ID Length:

버전 뒤의 바이트는 그 뒤에 오는 Destination Connection ID 필드의 길이를 바이트 단위로 포함한다. 이 길이는 8비트 부호 없는 정수로 인코딩된다. QUIC 버전 1에서 이 값은 20바이트를 초과해서는 MUST NOT 안 된다. 20보다 큰 값을 가진 버전 1 긴 헤더를 수신하는 엔드포인트는 패킷을 삭제해야 MUST 한다. Version Negotiation 패킷을 올바르게 형성하기 위해, 서버는 다른 QUIC 버전의 더 긴 연결 ID를 읽을 수 있어야 SHOULD 한다.¶

Destination Connection ID:

Destination Connection ID 필드는 이 필드의 길이를 나타내는 Destination Connection ID Length 필드 뒤에 온다. Section 7.2는 이 필드의 사용을 더 자세히 설명한다.¶

Source Connection ID Length:

Destination Connection ID 뒤의 바이트는 그 뒤에 오는 Source Connection ID 필드의 길이를 바이트 단위로 포함한다. 이 길이는 8비트 부호 없는 정수로 인코딩된다. QUIC 버전 1에서 이 값은 20바이트를 초과해서는 MUST NOT 안 된다. 20보다 큰 값을 가진 버전 1 긴 헤더를 수신하는 엔드포인트는 패킷을 삭제해야 MUST 한다. Version Negotiation 패킷을 올바르게 형성하기 위해, 서버는 다른 QUIC 버전의 더 긴 연결 ID를 읽을 수 있어야 SHOULD 한다.¶

Source Connection ID:

Source Connection ID 필드는 이 필드의 길이를 나타내는 Source Connection ID Length 필드 뒤에 온다. Section 7.2는 이 필드의 사용을 더 자세히 설명한다.¶

Type-Specific Payload:

패킷의 나머지 부분이 있다면 유형별로 다르다.¶

이 QUIC 버전에서는 긴 헤더를 가진 다음 패킷 유형이 정의된다:¶

긴 헤더 패킷의 header form 비트, Destination 및 Source Connection ID 길이, Destination 및 Source Connection ID 필드, 그리고 Version 필드는 버전 독립적이다. 첫 번째 바이트의 다른 필드는 버전별로 다르다. 서로 다른 QUIC 버전의 패킷이 어떻게 해석되는지에 대한 자세한 내용은 [QUIC-INVARIANTS]를 참조한다.¶

필드와 페이로드의 해석은 버전 및 패킷 유형에 특정된다. 이 버전의 유형별 의미론은 다음 섹션들에서 설명되지만, 이 QUIC 버전의 여러 긴 헤더 패킷은 다음 추가 필드를 포함한다:¶

Reserved Bits:

byte 0의 두 비트(마스크 0x0c를 가진 비트)는 여러 패킷 유형에 걸쳐 예약되어 있다. 이 비트들은 헤더 보호를 사용하여 보호된다. Section 5.4 of [QUIC-TLS]를 참조한다. 보호 전에 포함되는 값은 0으로 설정되어야 MUST 한다. 엔드포인트는 패킷 보호와 헤더 보호를 모두 제거한 후 이 비트들에 0이 아닌 값을 가진 패킷을 수신하면 이를 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다. 헤더 보호만 제거한 후 그러한 패킷을 폐기하면 엔드포인트가 공격에 노출될 수 있다. Section 9.5 of [QUIC-TLS]를 참조한다.¶

Packet Number Length:

Packet Number 필드를 포함하는 패킷 유형에서 byte 0의 최하위 두 비트(마스크 0x03을 가진 비트)는 Packet Number 필드의 길이를 포함한다. 이는 바이트 단위의 Packet Number 필드 길이보다 하나 작은 부호 없는 2비트 정수로 인코딩된다. 즉 Packet Number 필드의 길이는 이 필드의 값에 1을 더한 값이다. 이 비트들은 헤더 보호를 사용하여 보호된다. Section 5.4 of [QUIC-TLS]를 참조한다.¶

Length:

이는 패킷의 나머지 부분(즉 Packet Number 및 Payload 필드)의 길이를 바이트 단위로 나타내며, 가변 길이 정수 (Section 16)로 인코딩된다.¶

Packet Number:

이 필드는 1~4바이트 길이이다. 패킷 번호는 헤더 보호를 사용하여 보호된다. Section 5.4 of [QUIC-TLS]를 참조한다. Packet Number 필드의 길이는 byte 0의 Packet Number Length 비트에 인코딩된다. 위를 참조한다.¶

Packet Payload:

이는 프레임의 시퀀스를 포함하는 패킷의 페이로드이며, 패킷 보호를 사용하여 보호된다.¶

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}

Initial Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 0,
  Reserved Bits (2),
  Packet Number Length (2),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..160),
  Source Connection ID Length (8),
  Source Connection ID (0..160),
  Token Length (i),
  Token (..),
  Length (i),
  Packet Number (8..32),
  Packet Payload (8..),
}

0-RTT Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 1,
  Reserved Bits (2),
  Packet Number Length (2),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..160),
  Source Connection ID Length (8),
  Source Connection ID (0..160),
  Length (i),
  Packet Number (8..32),
  Packet Payload (8..),
}

Handshake Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 2,
  Reserved Bits (2),
  Packet Number Length (2),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..160),
  Source Connection ID Length (8),
  Source Connection ID (0..160),
  Length (i),
  Packet Number (8..32),
  Packet Payload (8..),
}

Retry Packet {
  Header Form (1) = 1,
  Fixed Bit (1) = 1,
  Long Packet Type (2) = 3,
  Unused (4),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..160),
  Source Connection ID Length (8),
  Source Connection ID (0..160),
  Retry Token (..),
  Retry Integrity Tag (128),
}

17.3. 짧은 헤더 패킷

이 QUIC 버전은 짧은 패킷 헤더를 사용하는 단일 패킷 유형을 정의한다.¶

1-RTT Packet {
  Header Form (1) = 0,
  Fixed Bit (1) = 1,
  Spin Bit (1),
  Reserved Bits (2),
  Key Phase (1),
  Packet Number Length (2),
  Destination Connection ID (0..160),
  Packet Number (8..32),
  Packet Payload (8..),
}

17.4. 지연 시간 Spin Bit

1-RTT 패킷에 대해 정의된 지연 시간 spin bit(Section 17.3.1)는 연결 기간 전체에 걸쳐 네트워크 경로상의 관찰 지점에서 수동 지연 시간 모니터링을 가능하게 한다. 서버는 수신한 spin 값을 반영하고, 클라이언트는 한 RTT 후에 이를 "회전"시킨다. 경로상 관찰자는 두 spin bit 토글 이벤트 사이의 시간을 측정하여 연결의 종단 간 RTT를 추정할 수 있다.¶

핸드셰이크를 관찰하여 연결의 초기 RTT를 측정할 수 있으므로, spin bit는 1-RTT 패킷에만 존재한다. 따라서 spin bit는 버전 협상과 연결 설정이 완료된 후 사용할 수 있다. 경로상 측정과 지연 시간 spin bit의 사용은 [QUIC-MANAGEABILITY]에서 추가로 논의된다.¶

spin bit는 이 QUIC 버전의 OPTIONAL 기능이다. 이 기능을 지원하지 않는 엔드포인트는 아래에 정의된 대로 이를 비활성화해야 MUST 한다.¶

각 엔드포인트는 연결에 대해 spin bit를 활성화할지 비활성화할지 독립적으로 결정한다. 구현은 클라이언트와 서버의 관리자가 전역적으로 또는 연결별로 spin bit를 비활성화할 수 있게 해야 MUST 한다. 관리자가 spin bit를 비활성화하지 않았더라도, 엔드포인트는 spin bit를 비활성화한 QUIC 연결이 네트워크에서 일반적으로 관찰되도록 보장하기 위해, 네트워크 경로 16개 중 최소 하나의 무작위 선택 또는 연결 ID 16개 중 하나에 대해 spin bit 사용을 비활성화해야 MUST 한다. 각 엔드포인트가 독립적으로 spin bit를 비활성화하므로, 이는 spin bit 신호가 대략 네트워크 경로 8개 중 하나에서 비활성화되도록 보장한다.¶

spin bit가 비활성화되면, 엔드포인트는 spin bit를 어떤 값으로도 설정할 수 MAY 있으며 들어오는 값을 무시해야 MUST 한다. 엔드포인트는 각 패킷마다 독립적으로 선택하거나 각 연결 ID마다 독립적으로 선택한 무작위 값으로 spin bit를 설정하는 것이 RECOMMENDED 된다.¶

연결에 대해 spin bit가 활성화된 경우, 엔드포인트는 각 네트워크 경로에 대한 spin 값을 유지하고 해당 경로에서 1-RTT 패킷이 전송될 때 패킷 헤더의 spin bit를 현재 저장된 값으로 설정한다. spin 값은 각 네트워크 경로에 대해 엔드포인트에서 0으로 초기화된다. 각 엔드포인트는 또한 각 경로에서 피어로부터 본 가장 큰 패킷 번호를 기억한다.¶

서버가 주어진 네트워크 경로에서 클라이언트로부터 서버가 본 가장 큰 패킷 번호를 증가시키는 1-RTT 패킷을 수신하면, 그 경로의 spin 값을 수신한 패킷의 spin bit와 같게 설정한다.¶

클라이언트가 주어진 네트워크 경로에서 서버로부터 클라이언트가 본 가장 큰 패킷 번호를 증가시키는 1-RTT 패킷을 수신하면, 그 경로의 spin 값을 수신한 패킷의 spin bit의 반대로 설정한다.¶

엔드포인트는 해당 네트워크 경로에서 사용 중인 연결 ID를 변경할 때 그 네트워크 경로의 spin 값을 0으로 재설정한다.¶

18.1. 예약된 전송 매개변수

정수 값 N에 대해 31 * N + 27 형식의 식별자를 가진 전송 매개변수는 알 수 없는 전송 매개변수가 무시되어야 한다는 요구사항을 실행하기 위해 예약되어 있다. 이러한 전송 매개변수는 의미론이 없으며 임의의 값을 운반할 수 있다.¶

18.2. 전송 매개변수 정의

이 섹션은 이 문서에 정의된 전송 매개변수를 자세히 설명한다.¶

여기에 나열된 많은 전송 매개변수는 정수 값을 가진다. 정수로 식별된 전송 매개변수는 가변 길이 정수 인코딩을 사용한다. Section 16을 참조한다. 달리 명시되지 않는 한, 전송 매개변수가 없으면 전송 매개변수의 기본값은 0이다.¶

다음 전송 매개변수가 정의된다:¶

original_destination_connection_id (0x00):

이 매개변수는 클라이언트가 보낸 첫 Initial 패킷의 Destination Connection ID 필드 값이다. Section 7.3을 참조한다. 이 전송 매개변수는 서버에 의해서만 전송된다.¶

max_idle_timeout (0x01):

최대 유휴 타임아웃은 밀리초 단위의 값이며 정수로 인코딩된다. (Section 10.1)을 참조한다. 두 엔드포인트가 모두 이 전송 매개변수를 생략하거나 0 값을 지정하면 유휴 타임아웃은 비활성화된다.¶

stateless_reset_token (0x02):

stateless reset token은 상태 없는 재설정을 검증하는 데 사용된다. Section 10.3을 참조한다. 이 매개변수는 16바이트 시퀀스이다. 이 전송 매개변수는 클라이언트가 보내서는 MUST NOT 안 되지만 서버가 보낼 수 MAY 있다. 이 전송 매개변수를 보내지 않는 서버는 핸드셰이크 중 협상된 연결 ID에 대해 상태 없는 재설정 (Section 10.3)을 사용할 수 없다.¶

max_udp_payload_size (0x03):

최대 UDP 페이로드 크기 매개변수는 엔드포인트가 수신할 의향이 있는 UDP 페이로드 크기를 제한하는 정수 값이다. 이 한도보다 큰 페이로드를 가진 UDP 데이터그램은 수신자에 의해 처리될 가능성이 낮다.¶

이 매개변수의 기본값은 허용되는 최대 UDP 페이로드인 65527이다. 1200보다 작은 값은 유효하지 않다.¶

이 한도는 경로 MTU와 같은 방식으로 데이터그램 크기에 대한 추가 제약으로 작용하지만, 이는 경로의 속성이 아니라 엔드포인트의 속성이다. Section 14를 참조한다. 이는 엔드포인트가 들어오는 패킷을 보관하기 위해 할당하는 공간으로 기대된다.¶

initial_max_data (0x04):

초기 최대 데이터 매개변수는 연결에서 보낼 수 있는 데이터의 최대량에 대한 초기값을 포함하는 정수 값이다. 이는 핸드셰이크 완료 직후 연결에 대해 MAX_DATA(Section 19.9)를 보내는 것과 같다.¶

initial_max_stream_data_bidi_local (0x05):

이 매개변수는 로컬에서 시작된 양방향 스트림의 초기 흐름 제어 한도를 지정하는 정수 값이다. 이 한도는 전송 매개변수를 보내는 엔드포인트가 연 새로 생성된 양방향 스트림에 적용된다. 클라이언트 전송 매개변수에서는 식별자의 최하위 두 비트가 0x00으로 설정된 스트림에 적용되고, 서버 전송 매개변수에서는 최하위 두 비트가 0x01로 설정된 스트림에 적용된다.¶

initial_max_stream_data_bidi_remote (0x06):

이 매개변수는 피어가 시작한 양방향 스트림의 초기 흐름 제어 한도를 지정하는 정수 값이다. 이 한도는 전송 매개변수를 수신하는 엔드포인트가 연 새로 생성된 양방향 스트림에 적용된다. 클라이언트 전송 매개변수에서는 식별자의 최하위 두 비트가 0x01로 설정된 스트림에 적용되고, 서버 전송 매개변수에서는 최하위 두 비트가 0x00으로 설정된 스트림에 적용된다.¶

initial_max_stream_data_uni (0x07):

이 매개변수는 단방향 스트림의 초기 흐름 제어 한도를 지정하는 정수 값이다. 이 한도는 전송 매개변수를 수신하는 엔드포인트가 연 새로 생성된 단방향 스트림에 적용된다. 클라이언트 전송 매개변수에서는 식별자의 최하위 두 비트가 0x03으로 설정된 스트림에 적용되고, 서버 전송 매개변수에서는 최하위 두 비트가 0x02로 설정된 스트림에 적용된다.¶

initial_max_streams_bidi (0x08):

초기 최대 양방향 스트림 매개변수는 이 전송 매개변수를 수신하는 엔드포인트가 시작할 수 있도록 허용된 양방향 스트림의 초기 최대 수를 포함하는 정수 값이다. 이 매개변수가 없거나 0이면, 피어는 MAX_STREAMS 프레임이 전송될 때까지 양방향 스트림을 열 수 없다. 이 매개변수를 설정하는 것은 같은 값을 가진 해당 유형의 MAX_STREAMS(Section 19.11)를 보내는 것과 같다.¶

initial_max_streams_uni (0x09):

초기 최대 단방향 스트림 매개변수는 이 전송 매개변수를 수신하는 엔드포인트가 시작할 수 있도록 허용된 단방향 스트림의 초기 최대 수를 포함하는 정수 값이다. 이 매개변수가 없거나 0이면, 피어는 MAX_STREAMS 프레임이 전송될 때까지 단방향 스트림을 열 수 없다. 이 매개변수를 설정하는 것은 같은 값을 가진 해당 유형의 MAX_STREAMS(Section 19.11)를 보내는 것과 같다.¶

ack_delay_exponent (0x0a):

확인 응답 지연 지수는 ACK 프레임(Section 19.3)의 ACK Delay 필드를 디코딩하는 데 사용되는 지수를 나타내는 정수 값이다. 이 값이 없으면 기본값 3이 가정된다(승수 8을 나타냄). 20보다 큰 값은 유효하지 않다.¶

max_ack_delay (0x0b):

최대 확인 응답 지연은 엔드포인트가 확인 응답 전송을 지연할 최대 시간을 밀리초 단위로 나타내는 정수 값이다. 이 값은 수신자가 예상하는 알람 발생 지연을 포함해야 SHOULD 한다. 예를 들어 수신자가 5ms 타이머를 설정하고 알람이 흔히 최대 1ms 늦게 발생한다면, max_ack_delay를 6ms로 보내야 한다. 이 값이 없으면 기본값 25밀리초가 가정된다. 2¹⁴ 이상의 값은 유효하지 않다.¶

disable_active_migration (0x0c):

disable active migration 전송 매개변수는 엔드포인트가 핸드셰이크 중 사용되는 주소에서 능동적 연결 마이그레이션 (Section 9)을 지원하지 않는 경우 포함된다. 이 전송 매개변수를 수신한 엔드포인트는 피어가 핸드셰이크 중 사용한 주소로 보낼 때 새 로컬 주소를 사용해서는 MUST NOT 안 된다. 이 전송 매개변수는 클라이언트가 preferred_address 전송 매개변수에 따라 행동한 후의 연결 마이그레이션을 금지하지 않는다. 이 매개변수는 길이가 0인 값이다.¶

preferred_address (0x0d):

서버의 선호 주소는 Section 9.6에 설명된 것처럼 핸드셰이크 끝에서 서버 주소 변경을 실행하는 데 사용된다. 이 전송 매개변수는 서버에 의해서만 전송된다. 서버는 다른 주소 계열에 대해 모두 0인 주소와 포트(0.0.0.0:0 또는 [::]:0)를 보내 하나의 주소 계열에 대한 선호 주소만 보내도록 선택할 수 MAY 있다. IP 주소는 네트워크 바이트 순서로 인코딩된다.¶

preferred_address 전송 매개변수는 IPv4와 IPv6 모두에 대한 주소와 포트를 포함한다. 4바이트 IPv4 Address 필드 뒤에는 연결된 2바이트 IPv4 Port 필드가 온다. 그 뒤에는 16바이트 IPv6 Address 필드와 2바이트 IPv6 Port 필드가 온다. 주소와 포트 쌍 뒤에는 Connection ID Length 필드가 이어지는 Connection ID 필드의 길이를 설명한다. 마지막으로 16바이트 Stateless Reset Token 필드는 연결 ID와 연관된 stateless reset token을 포함한다. 이 전송 매개변수의 형식은 아래 Figure 22에 표시되어 있다.¶

Connection ID 필드와 Stateless Reset Token 필드는 시퀀스 번호 1을 가진 대체 연결 ID를 포함한다. Section 5.1.1을 참조한다. 이러한 값을 선호 주소와 함께 전송하면 클라이언트가 선호 주소로 마이그레이션을 시작할 때 사용되지 않은 활성 연결 ID가 최소 하나 존재하도록 보장된다.¶

선호 주소의 Connection ID 및 Stateless Reset Token 필드는 NEW_CONNECTION_ID 프레임(Section 19.15)의 해당 필드와 구문 및 의미론이 동일하다. 길이가 0인 연결 ID를 선택한 서버는 선호 주소를 제공해서는 MUST NOT 안 된다. 마찬가지로 서버는 이 전송 매개변수에 길이가 0인 연결 ID를 포함해서는 MUST NOT 안 된다. 클라이언트는 이러한 요구사항의 위반을 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

Preferred Address {
  IPv4 Address (32),
  IPv4 Port (16),
  IPv6 Address (128),
  IPv6 Port (16),
  Connection ID Length (8),
  Connection ID (..),
  Stateless Reset Token (128),
}

active_connection_id_limit (0x0e):

이는 엔드포인트가 저장할 의향이 있는 피어의 연결 ID 최대 수를 지정하는 정수 값이다. 이 값에는 핸드셰이크 중 수신한 연결 ID, preferred_address 전송 매개변수에서 수신한 연결 ID, 그리고 NEW_CONNECTION_ID 프레임에서 수신한 연결 ID가 포함된다. active_connection_id_limit 매개변수의 값은 최소 2여야 MUST 한다. 2보다 작은 값을 수신한 엔드포인트는 TRANSPORT_PARAMETER_ERROR 유형의 오류로 연결을 닫아야 MUST 한다. 이 전송 매개변수가 없으면 기본값 2가 가정된다. 엔드포인트가 길이가 0인 연결 ID를 발급하면 NEW_CONNECTION_ID 프레임을 보내지 않으므로 피어로부터 수신한 active_connection_id_limit 값을 무시한다.¶

initial_source_connection_id (0x0f):

이는 엔드포인트가 연결을 위해 보내는 첫 Initial 패킷의 Source Connection ID 필드에 포함한 값이다. Section 7.3을 참조한다.¶

retry_source_connection_id (0x10):

이는 서버가 Retry 패킷의 Source Connection ID 필드에 포함한 값이다. Section 7.3을 참조한다. 이 전송 매개변수는 서버에 의해서만 전송된다.¶

존재하는 경우, 초기 스트림별 흐름 제어 한도를 설정하는 전송 매개변수 (initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote 및 initial_max_stream_data_uni)는 해당 유형의 모든 스트림에서, 열리자마자 MAX_STREAM_DATA 프레임(Section 19.10)을 보내는 것과 같다. 전송 매개변수가 없으면 해당 유형의 스트림은 흐름 제어 한도 0으로 시작한다.¶

클라이언트는 서버 전용 전송 매개변수인 original_destination_connection_id, preferred_address, retry_source_connection_id 또는 stateless_reset_token을 포함해서는 MUST NOT 안 된다. 서버는 이러한 전송 매개변수 중 하나라도 수신하면 이를 TRANSPORT_PARAMETER_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

19.1. PADDING 프레임

PADDING 프레임(type=0x00)은 의미론적 값을 가지지 않는다. PADDING 프레임은 패킷의 크기를 늘리는 데 사용할 수 있다. 패딩은 Initial 패킷을 필요한 최소 크기로 늘리거나 보호된 패킷에 대한 트래픽 분석 방지를 제공하는 데 사용할 수 있다.¶

PADDING 프레임은 Figure 23에 표시된 것처럼 형식화되며, 여기서는 PADDING 프레임에 내용이 없음을 보여준다. 즉, PADDING 프레임은 프레임을 PADDING 프레임으로 식별하는 단일 바이트로 구성된다.¶

PADDING Frame {
  Type (i) = 0x00,
}

19.2. PING 프레임

엔드포인트는 PING 프레임(type=0x01)을 사용하여 피어가 아직 살아 있는지 검증하거나 피어에 대한 도달 가능성을 확인할 수 있다.¶

PING 프레임은 Figure 24에 표시된 것처럼 형식화되며, 여기서는 PING 프레임에 내용이 없음을 보여준다.¶

PING Frame {
  Type (i) = 0x01,
}

PING 프레임의 수신자는 이 프레임을 포함하는 패킷을 확인 응답하기만 하면 된다.¶

PING 프레임은 애플리케이션 또는 애플리케이션 프로토콜이 연결이 타임아웃되는 것을 방지하려는 경우 연결을 유지하는 데 사용할 수 있다. Section 10.1.2를 참조한다.¶

19.3. ACK 프레임

수신자는 자신이 수신하고 처리한 패킷을 송신자에게 알리기 위해 ACK 프레임(types 0x02 및 0x03)을 보낸다. ACK 프레임은 하나 이상의 ACK Range를 포함한다. ACK Range는 확인 응답된 패킷을 식별한다. 프레임 유형이 0x03이면 ACK 프레임은 이 시점까지 연결에서 수신된, 관련 ECN 표시가 있는 QUIC 패킷의 누적 카운트도 포함한다. QUIC 구현은 두 유형을 모두 올바르게 처리해야 MUST 하며, 자신이 보내는 패킷에 대해 ECN을 활성화했다면 혼잡 상태를 관리하기 위해 ECN 섹션의 정보를 사용해야 SHOULD 한다.¶

QUIC 확인 응답은 취소할 수 없다. 일단 확인 응답된 패킷은 향후 ACK 프레임에 나타나지 않더라도 확인 응답된 상태로 남는다. 이는 TCP Selective Acknowledgments(SACKs) [RFC2018]에서의 reneging과 다르다.¶

서로 다른 패킷 번호 공간의 패킷은 같은 숫자 값을 사용하여 식별될 수 있다. 패킷에 대한 확인 응답은 패킷 번호와 패킷 번호 공간을 모두 나타내야 한다. 이는 각 ACK 프레임이 ACK 프레임이 포함된 패킷과 같은 공간의 패킷 번호만 확인 응답하게 함으로써 달성된다.¶

Version Negotiation 및 Retry 패킷은 패킷 번호를 포함하지 않으므로 확인 응답될 수 없다. ACK 프레임에 의존하는 대신, 이러한 패킷은 클라이언트가 보내는 다음 Initial 패킷에 의해 암시적으로 확인 응답된다.¶

ACK 프레임은 Figure 25에 표시된 것처럼 형식화된다.¶

ACK Frame {
  Type (i) = 0x02..0x03,
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  [ECN Counts (..)],
}

ACK 프레임은 다음 필드를 포함한다:¶

Largest Acknowledged:

피어가 확인 응답하는 가장 큰 패킷 번호를 나타내는 가변 길이 정수이다. 이는 보통 피어가 ACK 프레임을 생성하기 전에 수신한 가장 큰 패킷 번호이다. QUIC 긴 헤더나 짧은 헤더의 패킷 번호와 달리, ACK 프레임의 값은 잘리지 않는다.¶

ACK Delay:

확인 응답 지연을 마이크로초 단위로 인코딩하는 가변 길이 정수이다. Section 13.2.5를 참조한다. 이는 ACK 프레임의 송신자가 보낸 ack_delay_exponent 전송 매개변수의 거듭제곱인 2를 필드의 값에 곱하여 디코딩된다. Section 18.2를 참조한다. 지연을 단순히 정수로 표현하는 것과 비교할 때, 이 인코딩은 해상도를 낮추는 대신 같은 바이트 수 안에서 더 큰 값 범위를 허용한다.¶

ACK Range Count:

프레임 안의 ACK Range 필드 수를 지정하는 가변 길이 정수이다.¶

First ACK Range:

Largest Acknowledged 앞에 연속적으로 있으며 확인 응답되는 패킷 수를 나타내는 가변 길이 정수이다. 즉, 범위에서 확인 응답되는 가장 작은 패킷은 Largest Acknowledged 필드에서 First ACK Range 값을 빼서 결정된다.¶

ACK Ranges:

확인 응답되지 않은 범위(Gap)와 확인 응답된 범위 (ACK Range)가 번갈아 나타나는 추가 패킷 범위를 포함한다. Section 19.3.1을 참조한다.¶

ECN Counts:

세 개의 ECN 카운트이다. Section 19.3.2를 참조한다.¶

ACK Range {
  Gap (i),
  ACK Range Length (i),
}

   smallest = largest - ack_range

   largest = previous_smallest - gap - 2

ECN Counts {
  ECT0 Count (i),
  ECT1 Count (i),
  ECN-CE Count (i),
}

19.4. RESET_STREAM 프레임

엔드포인트는 RESET_STREAM 프레임(type=0x04)을 사용하여 스트림의 송신 부분을 갑작스럽게 종료한다.¶

RESET_STREAM을 보낸 후 엔드포인트는 식별된 스트림에서 STREAM 프레임의 전송 및 재전송을 중단한다. RESET_STREAM 수신자는 해당 스트림에서 이미 수신한 모든 데이터를 폐기할 수 있다.¶

send-only 스트림에 대한 RESET_STREAM 프레임을 수신한 엔드포인트는 STREAM_STATE_ERROR 오류로 연결을 종료해야 MUST 한다.¶

RESET_STREAM 프레임은 Figure 28에 표시된 것처럼 형식화된다.¶

RESET_STREAM Frame {
  Type (i) = 0x04,
  Stream ID (i),
  Application Protocol Error Code (i),
  Final Size (i),
}

RESET_STREAM 프레임은 다음 필드를 포함한다:¶

Stream ID:

종료되는 스트림의 스트림 ID를 인코딩한 가변 길이 정수이다.¶

Application Protocol Error Code:

스트림이 닫히는 이유를 나타내는 애플리케이션 프로토콜 오류 코드(Section 20.2 참조)를 포함하는 가변 길이 정수이다.¶

Final Size:

RESET_STREAM 송신자가 지정하는 스트림의 최종 크기를 바이트 단위로 나타내는 가변 길이 정수이다. Section 4.5를 참조한다.¶

19.5. STOP_SENDING 프레임

엔드포인트는 STOP_SENDING 프레임(type=0x05)을 사용하여 애플리케이션 요청에 따라 수신 데이터가 수신 시 폐기되고 있음을 전달한다. STOP_SENDING은 피어에게 스트림에서 전송을 중단하도록 요청한다.¶

STOP_SENDING 프레임은 "Recv" 또는 "Size Known" 상태의 스트림에 대해 보낼 수 있다. Section 3.2를 참조한다. 아직 생성되지 않은 로컬 시작 스트림에 대한 STOP_SENDING 프레임 수신은 STREAM_STATE_ERROR 유형의 연결 오류로 처리되어야 MUST 한다. receive-only 스트림에 대한 STOP_SENDING 프레임을 수신한 엔드포인트는 STREAM_STATE_ERROR 오류로 연결을 종료해야 MUST 한다.¶

STOP_SENDING 프레임은 Figure 29에 표시된 것처럼 형식화된다.¶

STOP_SENDING Frame {
  Type (i) = 0x05,
  Stream ID (i),
  Application Protocol Error Code (i),
}

STOP_SENDING 프레임은 다음 필드를 포함한다:¶

Stream ID:

무시되고 있는 스트림의 스트림 ID를 운반하는 가변 길이 정수이다.¶

Application Protocol Error Code:

송신자가 스트림을 무시하는 애플리케이션 지정 이유를 포함하는 가변 길이 정수이다. Section 20.2를 참조한다.¶

19.6. CRYPTO 프레임

CRYPTO 프레임(type=0x06)은 암호화 핸드셰이크 메시지를 전송하는 데 사용된다. 이는 0-RTT를 제외한 모든 패킷 유형에서 전송될 수 있다. CRYPTO 프레임은 암호화 프로토콜에 순서가 있는 바이트 스트림을 제공한다. CRYPTO 프레임은 STREAM 프레임과 기능적으로 동일하지만, 스트림 식별자를 가지지 않고, 흐름 제어를 받지 않으며, 선택적 오프셋, 선택적 길이 및 스트림의 끝을 나타내는 표식을 운반하지 않는다는 점이 다르다.¶

CRYPTO 프레임은 Figure 30에 표시된 것처럼 형식화된다.¶

CRYPTO Frame {
  Type (i) = 0x06,
  Offset (i),
  Length (i),
  Crypto Data (..),
}

CRYPTO 프레임은 다음 필드를 포함한다:¶

Offset:

이 CRYPTO 프레임의 데이터에 대한 스트림 내 바이트 오프셋을 지정하는 가변 길이 정수이다.¶

Length:

이 CRYPTO 프레임의 Crypto Data 필드 길이를 지정하는 가변 길이 정수이다.¶

Crypto Data:

암호화 메시지 데이터이다.¶

각 암호화 수준에는 별도의 암호화 핸드셰이크 데이터 흐름이 있으며, 각각은 오프셋 0에서 시작한다. 이는 각 암호화 수준이 별도의 CRYPTO 데이터 스트림으로 취급됨을 의미한다.¶

스트림에서 전달된 가장 큰 오프셋, 즉 오프셋과 데이터 길이의 합은 2⁶²-1을 초과할 수 없다. 이 한도를 초과하는 프레임의 수신은 FRAME_ENCODING_ERROR 또는 CRYPTO_BUFFER_EXCEEDED 유형의 연결 오류로 처리되어야 MUST 한다.¶

데이터가 어떤 스트림에 속하는지 나타내는 스트림 ID를 포함하는 STREAM 프레임과 달리, CRYPTO 프레임은 암호화 수준마다 단일 스트림의 데이터를 운반한다. 스트림에는 명시적인 끝이 없으므로 CRYPTO 프레임에는 FIN 비트가 없다.¶

19.7. NEW_TOKEN 프레임

서버는 향후 연결을 위한 Initial 패킷의 헤더에 보낼 토큰을 클라이언트에게 제공하기 위해 NEW_TOKEN 프레임(type=0x07)을 보낸다.¶

NEW_TOKEN 프레임은 Figure 31에 표시된 것처럼 형식화된다.¶

NEW_TOKEN Frame {
  Type (i) = 0x07,
  Token Length (i),
  Token (..),
}

NEW_TOKEN 프레임은 다음 필드를 포함한다:¶

Token Length:

토큰의 길이를 바이트 단위로 지정하는 가변 길이 정수이다.¶

Token:

클라이언트가 향후 Initial 패킷에서 사용할 수 있는 불투명 blob이다. 토큰은 비어 있어서는 MUST NOT 안 된다. 클라이언트는 빈 Token 필드가 있는 NEW_TOKEN 프레임 수신을 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리해야 MUST 한다.¶

프레임을 포함하는 패킷이 잘못 손실된 것으로 판단되면, 클라이언트는 같은 토큰 값을 포함하는 여러 NEW_TOKEN 프레임을 수신할 수 있다. 클라이언트는 중복 값을 폐기할 책임이 있으며, 이러한 값은 연결 시도를 연결하는 데 사용될 수 있다. Section 8.1.3을 참조한다.¶

클라이언트는 NEW_TOKEN 프레임을 보내서는 MUST NOT 안 된다. 서버는 NEW_TOKEN 프레임 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다.¶

19.8. STREAM 프레임

STREAM 프레임은 암시적으로 스트림을 생성하고 스트림 데이터를 운반한다. STREAM 프레임의 Type 필드는 0b00001XXX 형식(또는 0x08부터 0x0f까지의 값 집합)을 가진다. 프레임 유형의 하위 세 비트는 프레임에 존재하는 필드를 결정한다:¶

• 프레임 유형의 OFF 비트(0x04)는 Offset 필드가 존재함을 나타내기 위해 설정된다. 1로 설정되면 Offset 필드가 존재한다. 0으로 설정되면 Offset 필드는 없고 Stream Data는 오프셋 0에서 시작한다(즉, 프레임이 스트림의 첫 바이트를 포함하거나 데이터가 없는 스트림의 끝을 포함한다).¶
• 프레임 유형의 LEN 비트(0x02)는 Length 필드가 존재함을 나타내기 위해 설정된다. 이 비트가 0으로 설정되면 Length 필드는 없고 Stream Data 필드는 패킷 끝까지 확장된다. 이 비트가 1로 설정되면 Length 필드가 존재한다.¶
• FIN 비트(0x01)는 프레임이 스트림의 끝을 표시함을 나타낸다. 스트림의 최종 크기는 이 프레임의 오프셋과 길이의 합이다.¶

엔드포인트는 아직 생성되지 않은 로컬 시작 스트림이나 send-only 스트림에 대한 STREAM 프레임을 수신하면 STREAM_STATE_ERROR 오류로 연결을 종료해야 MUST 한다.¶

STREAM 프레임은 Figure 32에 표시된 것처럼 형식화된다.¶

STREAM Frame {
  Type (i) = 0x08..0x0f,
  Stream ID (i),
  [Offset (i)],
  [Length (i)],
  Stream Data (..),
}

STREAM 프레임은 다음 필드를 포함한다:¶

Stream ID:

스트림의 스트림 ID를 나타내는 가변 길이 정수이다. Section 2.1을 참조한다.¶

Offset:

이 STREAM 프레임의 데이터에 대한 스트림 내 바이트 오프셋을 지정하는 가변 길이 정수이다. 이 필드는 OFF 비트가 1로 설정되었을 때 존재한다. Offset 필드가 없으면 오프셋은 0이다.¶

Length:

이 STREAM 프레임의 Stream Data 필드 길이를 지정하는 가변 길이 정수이다. 이 필드는 LEN 비트가 1로 설정되었을 때 존재한다. LEN 비트가 0으로 설정되면 Stream Data 필드는 패킷의 남은 모든 바이트를 소비한다.¶

Stream Data:

전달될 지정된 스트림의 바이트이다.¶

Stream Data 필드의 길이가 0이면, STREAM 프레임의 오프셋은 다음에 전송될 바이트의 오프셋이다.¶

스트림의 첫 바이트는 오프셋 0을 가진다. 스트림에서 전달된 가장 큰 오프셋, 즉 오프셋과 데이터 길이의 합은 해당 데이터에 대한 흐름 제어 크레딧을 제공할 수 없으므로 2⁶²-1을 초과할 수 없다. 이 한도를 초과하는 프레임의 수신은 FRAME_ENCODING_ERROR 또는 FLOW_CONTROL_ERROR 유형의 연결 오류로 처리되어야 MUST 한다.¶

19.9. MAX_DATA 프레임

MAX_DATA 프레임(type=0x10)은 흐름 제어에서 연결 전체에서 보낼 수 있는 최대 데이터 양을 피어에게 알리는 데 사용된다.¶

MAX_DATA 프레임은 Figure 33에 표시된 것처럼 형식화된다.¶

MAX_DATA Frame {
  Type (i) = 0x10,
  Maximum Data (i),
}

MAX_DATA 프레임은 다음 필드를 포함한다:¶

Maximum Data:

전체 연결에서 보낼 수 있는 최대 데이터 양을 바이트 단위로 나타내는 가변 길이 정수이다.¶

STREAM 프레임에서 전송된 모든 데이터는 이 한도에 계산된다. 종료 상태의 스트림을 포함하여 모든 스트림의 최종 크기의 합은 수신자가 광고한 값을 초과해서는 MUST NOT 안 된다. 엔드포인트는 자신이 보낸 maximum data 값보다 더 많은 데이터를 수신하면 FLOW_CONTROL_ERROR 유형의 오류로 연결을 종료해야 MUST 한다. 여기에는 Early Data에서 기억된 한도 위반이 포함된다. Section 7.4.1을 참조한다.¶

19.10. MAX_STREAM_DATA 프레임

MAX_STREAM_DATA 프레임(type=0x11)은 흐름 제어에서 스트림에서 보낼 수 있는 최대 데이터 양을 피어에게 알리는 데 사용된다.¶

MAX_STREAM_DATA 프레임은 "Recv" 상태의 스트림에 대해 보낼 수 있다. Section 3.2를 참조한다. 아직 생성되지 않은 로컬 시작 스트림에 대한 MAX_STREAM_DATA 프레임 수신은 STREAM_STATE_ERROR 유형의 연결 오류로 처리되어야 MUST 한다. receive-only 스트림에 대한 MAX_STREAM_DATA 프레임을 수신한 엔드포인트는 STREAM_STATE_ERROR 오류로 연결을 종료해야 MUST 한다.¶

MAX_STREAM_DATA 프레임은 Figure 34에 표시된 것처럼 형식화된다.¶

MAX_STREAM_DATA Frame {
  Type (i) = 0x11,
  Stream ID (i),
  Maximum Stream Data (i),
}

MAX_STREAM_DATA 프레임은 다음 필드를 포함한다:¶

Stream ID:

영향받는 스트림의 스트림 ID이며, 가변 길이 정수로 인코딩된다.¶

Maximum Stream Data:

식별된 스트림에서 보낼 수 있는 최대 데이터 양을 바이트 단위로 나타내는 가변 길이 정수이다.¶

이 한도에 대해 데이터를 계산할 때, 엔드포인트는 스트림에서 전송되거나 수신된 데이터의 가장 큰 수신 오프셋을 고려한다. 손실이나 재정렬로 인해 스트림에서 가장 큰 수신 오프셋이 해당 스트림에서 수신된 데이터의 총 크기보다 클 수 있다. STREAM 프레임을 수신해도 가장 큰 수신 오프셋이 증가하지 않을 수 있다.¶

스트림에서 전송되는 데이터는 수신자가 광고한 가장 큰 maximum stream data 값을 초과해서는 MUST NOT 안 된다. 엔드포인트는 영향받는 스트림에 대해 자신이 보낸 가장 큰 maximum stream data보다 더 많은 데이터를 수신하면 FLOW_CONTROL_ERROR 유형의 오류로 연결을 종료해야 MUST 한다. 여기에는 Early Data에서 기억된 한도 위반이 포함된다. Section 7.4.1을 참조한다.¶

19.11. MAX_STREAMS 프레임

MAX_STREAMS 프레임(type=0x12 또는 0x13)은 피어에게 열 수 있도록 허용된 주어진 유형의 누적 스트림 수를 알린다. type 0x12의 MAX_STREAMS 프레임은 양방향 스트림에 적용되고, type 0x13의 MAX_STREAMS 프레임은 단방향 스트림에 적용된다.¶

MAX_STREAMS 프레임은 Figure 35에 표시된 것처럼 형식화된다.¶

MAX_STREAMS Frame {
  Type (i) = 0x12..0x13,
  Maximum Streams (i),
}

MAX_STREAMS 프레임은 다음 필드를 포함한다:¶

Maximum Streams:

연결 수명 동안 열 수 있는 해당 유형의 누적 스트림 수이다. 이 값은 2⁶⁰을 초과할 수 없다. 2⁶²-1보다 큰 스트림 ID를 인코딩할 수 없기 때문이다. 이 한도보다 큰 스트림을 여는 것을 허용하는 프레임 수신은 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리되어야 MUST 한다.¶

손실이나 재정렬은 엔드포인트가 이전에 수신한 것보다 낮은 스트림 한도를 가진 MAX_STREAMS 프레임을 수신하게 할 수 있다. 스트림 한도를 증가시키지 않는 MAX_STREAMS 프레임은 무시되어야 MUST 한다.¶

엔드포인트는 피어가 설정한 현재 스트림 한도보다 더 많은 스트림을 열어서는 MUST NOT 안 된다. 예를 들어, 단방향 스트림 한도 3을 수신한 서버는 스트림 3, 7, 11을 열 수 있지만 스트림 15는 열 수 없다. 엔드포인트는 피어가 허용된 것보다 더 많은 스트림을 열면 STREAM_LIMIT_ERROR 유형의 오류로 연결을 종료해야 MUST 한다. 여기에는 Early Data에서 기억된 한도 위반이 포함된다. Section 7.4.1을 참조한다.¶

이러한 프레임(및 해당 전송 매개변수)은 동시에 열 수 있는 스트림 수를 설명하지 않는다는 점에 유의한다. 한도에는 닫힌 스트림뿐 아니라 열린 스트림도 포함된다.¶

19.12. DATA_BLOCKED 프레임

송신자는 데이터를 보내고자 하지만 연결 수준 흐름 제어 때문에 그렇게 할 수 없을 때 DATA_BLOCKED 프레임(type=0x14)을 보내야 SHOULD 한다. Section 4를 참조한다. DATA_BLOCKED 프레임은 흐름 제어 알고리즘 조정의 입력으로 사용할 수 있다. Section 4.2를 참조한다.¶

DATA_BLOCKED 프레임은 Figure 36에 표시된 것처럼 형식화된다.¶

DATA_BLOCKED Frame {
  Type (i) = 0x14,
  Maximum Data (i),
}

DATA_BLOCKED 프레임은 다음 필드를 포함한다:¶

Maximum Data:

차단이 발생한 연결 수준 한도를 나타내는 가변 길이 정수이다.¶

19.13. STREAM_DATA_BLOCKED 프레임

송신자는 데이터를 보내고자 하지만 스트림 수준 흐름 제어 때문에 그렇게 할 수 없을 때 STREAM_DATA_BLOCKED 프레임(type=0x15)을 보내야 SHOULD 한다. 이 프레임은 DATA_BLOCKED (Section 19.12)와 유사하다.¶

send-only 스트림에 대한 STREAM_DATA_BLOCKED 프레임을 수신한 엔드포인트는 STREAM_STATE_ERROR 오류로 연결을 종료해야 MUST 한다.¶

STREAM_DATA_BLOCKED 프레임은 Figure 37에 표시된 것처럼 형식화된다.¶

STREAM_DATA_BLOCKED Frame {
  Type (i) = 0x15,
  Stream ID (i),
  Maximum Stream Data (i),
}

STREAM_DATA_BLOCKED 프레임은 다음 필드를 포함한다:¶

Stream ID:

흐름 제어 때문에 차단된 스트림을 나타내는 가변 길이 정수이다.¶

Maximum Stream Data:

차단이 발생한 스트림의 오프셋을 나타내는 가변 길이 정수이다.¶

19.14. STREAMS_BLOCKED 프레임

송신자는 스트림을 열고자 하지만 피어가 설정한 최대 스트림 한도 때문에 그렇게 할 수 없을 때 STREAMS_BLOCKED 프레임(type=0x16 또는 0x17)을 보내야 SHOULD 한다. Section 19.11을 참조한다. type 0x16의 STREAMS_BLOCKED 프레임은 양방향 스트림 한도에 도달했음을 나타내는 데 사용되고, type 0x17의 STREAMS_BLOCKED 프레임은 단방향 스트림 한도에 도달했음을 나타내는 데 사용된다.¶

STREAMS_BLOCKED 프레임은 스트림을 열지 않지만, 새 스트림이 필요했고 스트림 한도가 스트림 생성을 막았음을 피어에게 알린다.¶

STREAMS_BLOCKED 프레임은 Figure 38에 표시된 것처럼 형식화된다.¶

STREAMS_BLOCKED Frame {
  Type (i) = 0x16..0x17,
  Maximum Streams (i),
}

STREAMS_BLOCKED 프레임은 다음 필드를 포함한다:¶

Maximum Streams:

프레임이 전송될 당시 허용된 최대 스트림 수를 나타내는 가변 길이 정수이다. 이 값은 2⁶⁰을 초과할 수 없다. 2⁶²-1보다 큰 스트림 ID를 인코딩할 수 없기 때문이다. 더 큰 스트림 ID를 인코딩하는 프레임의 수신은 STREAM_LIMIT_ERROR 또는 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리되어야 MUST 한다.¶

19.15. NEW_CONNECTION_ID 프레임

엔드포인트는 연결을 마이그레이션할 때 연결 가능성을 끊는 데 사용할 수 있는 대체 연결 ID를 피어에게 제공하기 위해 NEW_CONNECTION_ID 프레임(type=0x18)을 보낸다. Section 9.5를 참조한다.¶

NEW_CONNECTION_ID 프레임은 Figure 39에 표시된 것처럼 형식화된다.¶

NEW_CONNECTION_ID Frame {
  Type (i) = 0x18,
  Sequence Number (i),
  Retire Prior To (i),
  Length (8),
  Connection ID (8..160),
  Stateless Reset Token (128),
}

NEW_CONNECTION_ID 프레임은 다음 필드를 포함한다:¶

Sequence Number:

송신자가 연결 ID에 할당한 시퀀스 번호이며, 가변 길이 정수로 인코딩된다. Section 5.1.1을 참조한다.¶

Retire Prior To:

어떤 연결 ID가 폐기되어야 하는지 나타내는 가변 길이 정수이다. Section 5.1.2를 참조한다.¶

Length:

연결 ID의 길이를 포함하는 8비트 부호 없는 정수이다. 1보다 작거나 20보다 큰 값은 유효하지 않으며 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리되어야 MUST 한다.¶

Connection ID:

지정된 길이의 연결 ID이다.¶

Stateless Reset Token:

연관된 연결 ID가 사용될 때 상태 없는 재설정에 사용될 128비트 값이다. Section 10.3을 참조한다.¶

엔드포인트는 현재 피어가 길이가 0인 Destination Connection ID로 패킷을 보내야 한다고 요구하는 경우 이 프레임을 보내서는 MUST NOT 안 된다. 연결 ID의 길이를 0으로 또는 0에서 변경하면 연결 ID 값이 언제 변경되었는지 식별하기 어렵다. 길이가 0인 Destination Connection ID로 패킷을 보내는 엔드포인트는 NEW_CONNECTION_ID 프레임 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다.¶

전송 오류, 타임아웃 및 재전송으로 인해 같은 NEW_CONNECTION_ID 프레임이 여러 번 수신될 수 있다. 같은 프레임을 여러 번 수신하는 것은 연결 오류로 처리되어서는 MUST NOT 안 된다. 수신자는 NEW_CONNECTION_ID 프레임에 제공된 시퀀스 번호를 사용하여 같은 NEW_CONNECTION_ID 프레임을 여러 번 수신하는 것을 처리할 수 있다.¶

엔드포인트가 이전에 발급된 연결 ID를 다른 Stateless Reset Token 필드 값이나 다른 Sequence Number 필드 값으로 반복하는 NEW_CONNECTION_ID 프레임을 수신하거나, 하나의 시퀀스 번호가 서로 다른 연결 ID에 사용되면, 엔드포인트는 그 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리할 수 MAY 있다.¶

Retire Prior To 필드는 연결 설정 중 수립된 연결 ID와 preferred_address 전송 매개변수에 적용된다. Section 5.1.2를 참조한다. Retire Prior To 필드의 값은 Sequence Number 필드의 값보다 작거나 같아야 MUST 한다. Retire Prior To 필드에서 Sequence Number 필드의 값보다 큰 값을 수신하는 것은 FRAME_ENCODING_ERROR 유형의 연결 오류로 처리되어야 MUST 한다.¶

송신자가 Retire Prior To 값을 나타내면, 이후 NEW_CONNECTION_ID 프레임에서 전송되는 더 작은 값은 효과가 없다. 수신자는 수신한 가장 큰 Retire Prior To 값을 증가시키지 않는 모든 Retire Prior To 필드를 무시해야 MUST 한다.¶

이전에 수신한 NEW_CONNECTION_ID 프레임의 Retire Prior To 필드보다 작은 시퀀스 번호를 가진 NEW_CONNECTION_ID 프레임을 수신한 엔드포인트는, 해당 시퀀스 번호에 대해 이미 그렇게 하지 않았다면 새로 수신한 연결 ID를 폐기하는 해당 RETIRE_CONNECTION_ID 프레임을 보내야 MUST 한다.¶

19.16. RETIRE_CONNECTION_ID 프레임

엔드포인트는 피어가 발급한 연결 ID를 더 이상 사용하지 않을 것임을 나타내기 위해 RETIRE_CONNECTION_ID 프레임(type=0x19)을 보낸다. 여기에는 핸드셰이크 중 제공된 연결 ID가 포함된다. RETIRE_CONNECTION_ID 프레임을 보내는 것은 또한 향후 사용을 위한 추가 연결 ID를 보내도록 피어에게 요청하는 역할을 한다. Section 5.1을 참조한다. 새 연결 ID는 NEW_CONNECTION_ID 프레임(Section 19.15)을 사용하여 피어에게 전달될 수 있다.¶

연결 ID를 폐기하면 해당 연결 ID와 연관된 stateless reset token이 무효화된다.¶

RETIRE_CONNECTION_ID 프레임은 Figure 40에 표시된 것처럼 형식화된다.¶

RETIRE_CONNECTION_ID Frame {
  Type (i) = 0x19,
  Sequence Number (i),
}

RETIRE_CONNECTION_ID 프레임은 다음 필드를 포함한다:¶

Sequence Number:

폐기되는 연결 ID의 시퀀스 번호이다. Section 5.1.2를 참조한다.¶

이전에 피어에게 보낸 어떤 것보다 큰 시퀀스 번호를 포함하는 RETIRE_CONNECTION_ID 프레임의 수신은 PROTOCOL_VIOLATION 유형의 연결 오류로 처리되어야 MUST 한다.¶

RETIRE_CONNECTION_ID 프레임에 지정된 시퀀스 번호는 그 프레임이 포함된 패킷의 Destination Connection ID 필드를 참조해서는 MUST NOT 안 된다. 피어는 이를 PROTOCOL_VIOLATION 유형의 연결 오류로 처리할 수 MAY 있다.¶

엔드포인트는 피어로부터 길이가 0인 연결 ID를 제공받은 경우 이 프레임을 보낼 수 없다. 길이가 0인 연결 ID를 제공하는 엔드포인트는 RETIRE_CONNECTION_ID 프레임 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다.¶

19.17. PATH_CHALLENGE 프레임

엔드포인트는 PATH_CHALLENGE 프레임(type=0x1a)을 사용하여 피어에 대한 도달 가능성을 확인하고 연결 마이그레이션 중 경로 검증을 수행할 수 있다.¶

PATH_CHALLENGE 프레임은 Figure 41에 표시된 것처럼 형식화된다.¶

PATH_CHALLENGE Frame {
  Type (i) = 0x1a,
  Data (64),
}

PATH_CHALLENGE 프레임은 다음 필드를 포함한다:¶

Data:

이 8바이트 필드는 임의의 데이터를 포함한다.¶

PATH_CHALLENGE 프레임에 64비트 엔트로피를 포함하면 값을 올바르게 추측하는 것보다 패킷을 수신하는 것이 더 쉽도록 보장된다.¶

이 프레임의 수신자는 같은 Data 값을 포함하는 PATH_RESPONSE 프레임 (Section 19.18)을 생성해야 MUST 한다.¶

19.18. PATH_RESPONSE 프레임

PATH_RESPONSE 프레임(type=0x1b)은 PATH_CHALLENGE 프레임에 대한 응답으로 전송된다.¶

PATH_RESPONSE 프레임은 Figure 42에 표시된 것처럼 형식화된다. PATH_RESPONSE 프레임의 형식은 PATH_CHALLENGE 프레임의 형식과 동일하다. Section 19.17을 참조한다.¶

PATH_RESPONSE Frame {
  Type (i) = 0x1b,
  Data (64),
}

PATH_RESPONSE 프레임의 내용이 엔드포인트가 이전에 보낸 PATH_CHALLENGE 프레임의 내용과 일치하지 않으면, 엔드포인트는 PROTOCOL_VIOLATION 유형의 연결 오류를 생성할 수 MAY 있다.¶

19.19. CONNECTION_CLOSE 프레임

엔드포인트는 연결이 닫히고 있음을 피어에게 알리기 위해 CONNECTION_CLOSE 프레임(type=0x1c 또는 0x1d)을 보낸다. type 0x1c의 CONNECTION_CLOSE 프레임은 QUIC 계층의 오류만 신호하거나 오류가 없음을(NO_ERROR 코드로) 신호하는 데 사용된다. type 0x1d의 CONNECTION_CLOSE 프레임은 QUIC를 사용하는 애플리케이션의 오류를 신호하는 데 사용된다.¶

명시적으로 닫히지 않은 열린 스트림이 있으면, 연결이 닫힐 때 이들은 암시적으로 닫힌다.¶

CONNECTION_CLOSE 프레임은 Figure 43에 표시된 것처럼 형식화된다.¶

CONNECTION_CLOSE Frame {
  Type (i) = 0x1c..0x1d,
  Error Code (i),
  [Frame Type (i)],
  Reason Phrase Length (i),
  Reason Phrase (..),
}

CONNECTION_CLOSE 프레임은 다음 필드를 포함한다:¶

Error Code:

이 연결을 닫는 이유를 나타내는 가변 길이 정수이다. type 0x1c의 CONNECTION_CLOSE 프레임은 Section 20.1에 정의된 공간의 코드를 사용한다. type 0x1d의 CONNECTION_CLOSE 프레임은 애플리케이션 프로토콜이 정의한 코드를 사용한다. Section 20.2를 참조한다.¶

Frame Type:

오류를 유발한 프레임의 유형을 인코딩하는 가변 길이 정수이다. 프레임 유형을 알 수 없을 때 값 0(PADDING 프레임 언급과 동등)이 사용된다. 애플리케이션별 CONNECTION_CLOSE 변형(type 0x1d)은 이 필드를 포함하지 않는다.¶

Reason Phrase Length:

reason phrase의 길이를 바이트 단위로 지정하는 가변 길이 정수이다. CONNECTION_CLOSE 프레임은 패킷 사이에서 분할될 수 없으므로, 패킷 크기에 대한 모든 한도는 reason phrase에 사용할 수 있는 공간도 제한한다.¶

Reason Phrase:

닫힘에 대한 추가 진단 정보이다. 송신자가 Error Code 값 이상의 세부 정보를 제공하지 않기로 선택하면 길이가 0일 수 있다. 이는 UTF-8로 인코딩된 문자열 [RFC3629]이어야 SHOULD 하지만, 프레임은 언어 태그와 같이 텍스트를 생성한 엔티티 외의 다른 엔티티가 이해하는 데 도움이 되는 정보를 운반하지 않는다.¶

애플리케이션별 CONNECTION_CLOSE 변형(type 0x1d)은 0-RTT 또는 1-RTT 패킷을 사용해서만 전송될 수 있다. Section 12.5를 참조한다. 애플리케이션이 핸드셰이크 중 연결을 포기하려는 경우, 엔드포인트는 Initial 또는 Handshake 패킷에서 APPLICATION_ERROR 오류 코드가 있는 CONNECTION_CLOSE 프레임(type 0x1c)을 보낼 수 있다.¶

19.20. HANDSHAKE_DONE 프레임

서버는 HANDSHAKE_DONE 프레임(type=0x1e)을 사용하여 핸드셰이크의 확인을 클라이언트에게 신호한다.¶

HANDSHAKE_DONE 프레임은 Figure 44에 표시된 것처럼 형식화되며, 여기서는 HANDSHAKE_DONE 프레임에 내용이 없음을 보여준다.¶

HANDSHAKE_DONE Frame {
  Type (i) = 0x1e,
}

HANDSHAKE_DONE 프레임은 서버만 보낼 수 있다. 서버는 핸드셰이크를 완료하기 전에 HANDSHAKE_DONE 프레임을 보내서는 MUST NOT 안 된다. 서버는 HANDSHAKE_DONE 프레임 수신을 PROTOCOL_VIOLATION 유형의 연결 오류로 처리해야 MUST 한다.¶

19.21. 확장 프레임

QUIC 프레임은 자기 설명적 인코딩을 사용하지 않는다. 따라서 엔드포인트는 패킷을 성공적으로 처리하기 전에 모든 프레임의 구문을 이해해야 한다. 이는 프레임의 효율적인 인코딩을 가능하게 하지만, 엔드포인트가 피어에게 알려지지 않은 유형의 프레임을 보낼 수 없다는 의미이다.¶

새 유형의 프레임을 사용하려는 QUIC 확장은 먼저 피어가 그 프레임을 이해할 수 있음을 보장해야 MUST 한다. 엔드포인트는 확장 프레임 유형을 수신할 의향을 신호하기 위해 전송 매개변수를 사용할 수 있다. 하나의 전송 매개변수는 하나 이상의 확장 프레임 유형에 대한 지원을 나타낼 수 있다.¶

핵심 프로토콜 기능(프레임 유형 포함)을 수정하거나 대체하는 확장은, 그 조합의 동작이 명시적으로 정의되지 않는 한 같은 기능을 수정하거나 대체하는 다른 확장과 결합하기 어렵다. 그러한 확장은 같은 프로토콜 구성요소를 수정하는 이전에 정의된 확장과의 상호작용을 정의해야 SHOULD 한다.¶

확장 프레임은 혼잡 제어를 받아야 MUST 하며 ACK 프레임이 전송되도록 해야 MUST 한다. 예외는 ACK 프레임을 대체하거나 보완하는 확장 프레임이다. 확장 프레임은 확장에서 명시하지 않는 한 흐름 제어에 포함되지 않는다.¶

프레임 유형 할당을 관리하기 위해 IANA 레지스트리가 사용된다. Section 22.4를 참조한다.¶

20.1. 전송 오류 코드

이 섹션은 type 0x1c의 CONNECTION_CLOSE 프레임에서 사용할 수 있는 정의된 QUIC 전송 오류 코드를 나열한다. 이러한 오류는 전체 연결에 적용된다.¶

NO_ERROR (0x00):

엔드포인트는 오류가 없는 상태에서 연결이 갑작스럽게 닫히고 있음을 신호하기 위해 CONNECTION_CLOSE와 함께 이를 사용한다.¶

INTERNAL_ERROR (0x01):

엔드포인트가 내부 오류를 만나 연결을 계속할 수 없다.¶

CONNECTION_REFUSED (0x02):

서버가 새 연결 수락을 거부했다.¶

FLOW_CONTROL_ERROR (0x03):

엔드포인트가 자신이 광고한 데이터 한도에서 허용한 것보다 더 많은 데이터를 수신했다. Section 4를 참조한다.¶

STREAM_LIMIT_ERROR (0x04):

엔드포인트가 해당 스트림 유형에 대해 광고한 스트림 한도를 초과한 스트림 식별자에 대한 프레임을 수신했다.¶

STREAM_STATE_ERROR (0x05):

엔드포인트가 해당 프레임을 허용하지 않는 상태의 스트림에 대한 프레임을 수신했다. Section 3을 참조한다.¶

FINAL_SIZE_ERROR (0x06):

(1) 엔드포인트가 이전에 설정된 최종 크기를 초과하는 데이터를 포함한 STREAM 프레임을 수신했거나, (2) 엔드포인트가 이미 수신된 스트림 데이터의 크기보다 낮은 최종 크기를 포함한 STREAM 프레임 또는 RESET_STREAM 프레임을 수신했거나, (3) 엔드포인트가 이미 설정된 것과 다른 최종 크기를 포함한 STREAM 프레임 또는 RESET_STREAM 프레임을 수신했다.¶

FRAME_ENCODING_ERROR (0x07):

엔드포인트가 형식이 잘못된 프레임을 수신했다. 예를 들어 알 수 없는 유형의 프레임이나 패킷의 나머지 부분이 운반할 수 있는 것보다 더 많은 확인 응답 범위를 가진 ACK 프레임이 이에 해당한다.¶

TRANSPORT_PARAMETER_ERROR (0x08):

엔드포인트가 형식이 잘못되었거나, 유효하지 않은 값을 포함했거나, 필수 전송 매개변수를 생략했거나, 금지된 전송 매개변수를 포함했거나, 그 외의 오류가 있는 전송 매개변수를 수신했다.¶

CONNECTION_ID_LIMIT_ERROR (0x09):

피어가 제공한 연결 ID의 수가 광고된 active_connection_id_limit를 초과했다.¶

PROTOCOL_VIOLATION (0x0a):

엔드포인트가 더 구체적인 오류 코드로 다루어지지 않는 프로토콜 준수 오류를 감지했다.¶

INVALID_TOKEN (0x0b):

서버가 유효하지 않은 Token 필드를 포함한 클라이언트 Initial을 수신했다.¶

APPLICATION_ERROR (0x0c):

애플리케이션 또는 애플리케이션 프로토콜이 연결을 닫게 했다.¶

CRYPTO_BUFFER_EXCEEDED (0x0d):

엔드포인트가 버퍼링할 수 있는 것보다 더 많은 데이터를 CRYPTO 프레임에서 수신했다.¶

KEY_UPDATE_ERROR (0x0e):

엔드포인트가 키 업데이트를 수행하는 중 오류를 감지했다. Section 6 of [QUIC-TLS]을 참조한다.¶

AEAD_LIMIT_REACHED (0x0f):

엔드포인트가 주어진 연결에서 사용되는 AEAD 알고리즘의 기밀성 또는 무결성 한도에 도달했다.¶

NO_VIABLE_PATH (0x10):

엔드포인트가 네트워크 경로가 QUIC를 지원할 수 없다고 판단했다. 경로가 충분히 큰 MTU를 지원하지 않는 경우를 제외하면, 엔드포인트가 이 코드를 운반하는 CONNECTION_CLOSE 프레임을 수신할 가능성은 낮다.¶

CRYPTO_ERROR (0x0100-0x01ff):

암호화 핸드셰이크가 실패했다. 사용되는 암호화 핸드셰이크에 특정된 오류 코드를 운반하기 위해 256개 값의 범위가 예약되어 있다. TLS가 암호화 핸드셰이크에 사용될 때 발생하는 오류 코드는 Section 4.8 of [QUIC-TLS]에 설명되어 있다.¶

새 오류 코드 등록에 대한 자세한 내용은 Section 22.5를 참조한다.¶

이러한 오류 코드를 정의할 때 여러 원칙이 적용된다. 수신자 측의 특정 조치가 필요할 수 있는 오류 조건에는 고유한 코드가 부여된다. 일반적인 조건을 나타내는 오류에는 특정 코드가 부여된다. 이러한 조건 중 어느 것도 없으면, 흐름 제어나 전송 매개변수 처리처럼 스택의 일반 기능을 식별하는 데 오류 코드가 사용된다. 마지막으로 구현이 더 구체적인 코드를 사용할 수 없거나 사용하려 하지 않는 조건에 대해 일반 오류가 제공된다.¶

20.2. 애플리케이션 프로토콜 오류 코드

애플리케이션 오류 코드의 관리는 애플리케이션 프로토콜에 맡겨진다. 애플리케이션 프로토콜 오류 코드는 RESET_STREAM 프레임 (Section 19.4), STOP_SENDING 프레임(Section 19.5), 그리고 type 0x1d의 CONNECTION_CLOSE 프레임(Section 19.19)에 사용된다.¶

21.1. 보안 속성 개요

QUIC에 대한 완전한 보안 분석은 이 문서의 범위를 벗어난다. 이 섹션은 구현자를 돕고 프로토콜 분석을 안내하기 위해 원하는 보안 속성을 비공식적으로 설명한다.¶

QUIC는 [SEC-CONS]에 설명된 위협 모델을 가정하며, 그 모델에서 발생하는 많은 공격에 대한 보호를 제공한다.¶

이 목적을 위해 공격은 수동 공격과 능동 공격으로 나뉜다. 수동 공격자는 네트워크에서 패킷을 읽을 수 있는 능력을 가지며, 능동 공격자는 네트워크에 패킷을 쓸 수 있는 능력도 가진다. 그러나 수동 공격에는 연결을 구성하는 패킷이 지나가는 경로의 라우팅 변경이나 기타 수정을 유발할 수 있는 능력을 가진 공격자가 포함될 수 있다.¶

공격자는 추가로 경로상 공격자 또는 경로 밖 공격자로 분류된다. 경로상 공격자는 관찰한 모든 패킷을 읽거나, 수정하거나, 제거하여 그 패킷이 더 이상 목적지에 도달하지 못하게 할 수 있다. 반면 경로 밖 공격자는 패킷을 관찰하지만 원래 패킷이 의도된 목적지에 도달하는 것을 막을 수는 없다. 두 유형의 공격자 모두 임의의 패킷을 전송할 수도 있다. 이 정의는 경로 밖 공격자가 패킷을 관찰할 수 있다는 점에서 Section 3.5 of [SEC-CONS]의 정의와 다르다.¶

핸드셰이크, 보호된 패킷 및 연결 마이그레이션의 속성은 별도로 고려된다.¶

21.2. 핸드셰이크 서비스 거부

암호화되고 인증된 전송으로서, QUIC는 서비스 거부에 대한 다양한 보호를 제공한다. 암호화 핸드셰이크가 완료되면 QUIC 엔드포인트는 인증되지 않은 대부분의 패킷을 폐기하여, 공격자가 기존 연결을 방해할 수 있는 능력을 크게 제한한다.¶

연결이 설정되면 QUIC 엔드포인트는 일부 인증되지 않은 ICMP 패킷 (Section 14.2.1 참조)을 수락할 수 있지만, 이러한 패킷의 사용은 극히 제한적이다. 엔드포인트가 수락할 수 있는 유일한 다른 패킷 유형은 상태 없는 재설정(Section 10.3)이며, 이는 토큰이 사용될 때까지 비밀로 유지되는 것에 의존한다.¶

연결 생성 중에 QUIC는 네트워크 경로 밖에서 오는 공격에 대해서만 보호를 제공한다. 모든 QUIC 패킷은 수신자가 자신의 피어로부터 이전 패킷을 보았다는 증거를 포함한다.¶

핸드셰이크 중에는 주소가 변경될 수 없으므로, 엔드포인트는 다른 네트워크 경로에서 수신된 패킷을 폐기할 수 있다.¶

Source 및 Destination Connection ID 필드는 핸드셰이크 중 경로 밖 공격에 대한 주요 보호 수단이다. Section 8.1을 참조한다. 이들은 피어가 설정한 값과 일치해야 한다. Initial 및 Stateless Reset을 제외하면, 엔드포인트는 자신이 이전에 선택한 값과 일치하는 Destination Connection ID 필드를 포함하는 패킷만 수락한다. 이는 Version Negotiation 패킷에 제공되는 유일한 보호이다.¶

Initial 패킷의 Destination Connection ID 필드는 클라이언트가 예측할 수 없도록 선택하며, 이는 추가 목적을 수행한다. 암호화 핸드셰이크를 운반하는 패킷은 이 연결 ID와 QUIC 버전에 특정된 salt에서 파생된 키로 보호된다. 이를 통해 엔드포인트는 암호화 핸드셰이크가 완료된 후 사용하는 것과 같은 프로세스로 수신한 패킷을 인증할 수 있다. 인증할 수 없는 패킷은 폐기된다. 이런 방식으로 패킷을 보호하면 패킷의 송신자가 Initial 패킷을 보았고 이를 이해했다는 강한 보장을 제공한다.¶

이러한 보호는 연결이 설정되기 전에 QUIC 패킷을 수신할 수 있는 공격자에 대해 효과적이도록 의도된 것이 아니다. 그러한 공격자는 QUIC 엔드포인트가 수락할 패킷을 보낼 가능성이 있다. 이 버전의 QUIC는 이러한 종류의 공격을 감지하려고 시도하지만, 엔드포인트가 복구하기보다는 연결 설정에 실패할 것으로 기대한다. 대부분의 경우 암호화 핸드셰이크 프로토콜 [QUIC-TLS]이 핸드셰이크 중 변조 감지를 담당한다.¶

엔드포인트는 핸드셰이크 간섭을 감지하고 복구를 시도하기 위해 다른 방법을 사용할 수 있다. 유효하지 않은 패킷은 다른 방법을 사용하여 식별되고 폐기될 수 있지만, 이 문서는 특정 방법을 요구하지 않는다.¶

21.3. 증폭 공격

공격자는 서버로부터 주소 검증 토큰 (Section 8)을 수신한 뒤, 그 토큰을 얻는 데 사용한 IP 주소를 해제할 수 있다. 나중에 공격자는 같은 주소를 스푸핑하여 서버와 0-RTT 연결을 시작할 수 있으며, 이 주소는 이제 다른 (피해자) 엔드포인트를 가리킬 수 있다. 따라서 공격자는 잠재적으로 서버가 피해자에게 초기 혼잡 윈도우만큼의 데이터를 보내게 할 수 있다.¶

서버는 주소 검증 토큰의 사용과 수명을 제한하여 이 공격에 대한 완화책을 제공해야 SHOULD 한다. Section 8.1.3을 참조한다.¶

21.4. 낙관적 ACK 공격

수신하지 않은 패킷에 대해 확인 응답하는 엔드포인트는 혼잡 제어기가 네트워크가 지원하는 것 이상의 속도로 전송을 허용하게 할 수 있다. 엔드포인트는 이 동작을 감지하기 위해 패킷을 보낼 때 패킷 번호를 건너뛸 수 MAY 있다. 그러면 엔드포인트는 PROTOCOL_VIOLATION 유형의 연결 오류로 즉시 연결을 닫을 수 있다. Section 10.2를 참조한다.¶

21.5. 요청 위조 공격

요청 위조 공격은 엔드포인트가 자신의 피어로 하여금 피해자를 향해 요청을 발행하게 하며, 그 요청을 엔드포인트가 제어하는 경우 발생한다. 요청 위조 공격은 공격자가 아니면 사용할 수 없을 수 있는 피어의 능력에 접근하는 것을 목표로 한다. 네트워킹 프로토콜에서 요청 위조 공격은 흔히 네트워크에서 피어의 위치 때문에 피해자가 피어에게 부여한 암묵적 권한을 악용하는 데 사용된다.¶

요청 위조가 효과적이려면, 공격자는 피어가 어떤 패킷을 보내고 그 패킷이 어디로 전송되는지에 영향을 줄 수 있어야 한다. 공격자가 제어된 페이로드로 취약한 서비스를 대상으로 삼을 수 있다면, 해당 서비스는 공격자의 피어에게 귀속되지만 공격자가 결정한 동작을 수행할 수 있다.¶

예를 들어, 웹의 cross-site request forgery [CSRF] 익스플로잇은 클라이언트가 authorization cookies [COOKIE]를 포함하는 요청을 발행하게 하여, 한 사이트가 다른 사이트로 제한되도록 의도된 정보와 동작에 접근할 수 있게 한다.¶

QUIC는 UDP 위에서 실행되므로, 주요 우려 공격 방식은 공격자가 피어가 UDP 데이터그램을 보내는 주소를 선택하고 그 패킷의 보호되지 않은 내용 일부를 제어할 수 있는 경우이다. QUIC 엔드포인트가 보내는 데이터의 대부분이 보호되므로, 여기에는 암호문에 대한 제어도 포함된다. 공격자가 피어로 하여금 데이터그램의 내용에 기반하여 어떤 동작을 수행할 호스트로 UDP 데이터그램을 보내게 할 수 있다면 공격은 성공한다.¶

이 섹션은 QUIC가 요청 위조 공격에 사용될 수 있는 방식을 논의한다.¶

이 섹션은 또한 QUIC 엔드포인트가 구현할 수 있는 제한적인 대응책을 설명한다. 이러한 완화책은 요청 위조 공격의 잠재적 대상이 조치를 취하지 않더라도 QUIC 구현 또는 배포가 독자적으로 사용할 수 있다. 그러나 UDP 기반 서비스가 요청을 적절히 인가하지 않는다면 이러한 대응책은 충분하지 않을 수 있다.¶

Section 21.5.4에 설명된 마이그레이션 공격은 매우 강력하고 적절한 대응책이 없으므로, QUIC 서버 구현은 공격자가 서버로 하여금 임의의 목적지에 임의의 UDP 페이로드를 생성하게 할 수 있다고 가정해야 한다. QUIC 서버는 ingress filtering [BCP38]을 배포하지 않고 또한 부적절하게 보호된 UDP 엔드포인트가 있는 네트워크에 배포되어서는 SHOULD NOT 안 된다.¶

클라이언트가 취약한 엔드포인트와 같은 위치에 있지 않음을 보장하는 것은 일반적으로 불가능하지만, 이 버전의 QUIC는 서버가 마이그레이션하는 것을 허용하지 않으므로 클라이언트에 대한 스푸핑된 마이그레이션 공격을 방지한다. 서버 마이그레이션을 허용하는 향후 확장은 위조 공격에 대한 대응책도 정의해야 MUST 한다.¶

21.6. Slowloris 공격

일반적으로 Slowloris [SLOWLORIS]로 알려진 공격은 대상 엔드포인트에 대한 많은 연결을 열린 상태로 유지하고 가능한 한 오래 유지하려고 시도한다. 이러한 공격은 비활성으로 인해 닫히지 않도록 필요한 최소한의 활동을 생성함으로써 QUIC 엔드포인트에 대해 실행될 수 있다. 여기에는 소량의 데이터를 보내거나, 송신 속도를 제어하기 위해 흐름 제어 창을 점진적으로 열거나, 높은 손실률을 시뮬레이션하는 ACK 프레임을 만들어내는 것이 포함될 수 있다.¶

QUIC 배포는 서버가 허용할 최대 클라이언트 수를 늘리거나, 단일 IP 주소가 만들 수 있는 연결 수를 제한하거나, 연결이 가질 수 있는 최소 전송 속도에 제한을 부과하거나, 엔드포인트가 연결된 상태로 있을 수 있는 시간을 제한하는 등 Slowloris 공격에 대한 완화책을 제공해야 SHOULD 한다.¶

21.7. 스트림 단편화 및 재조립 공격

악의적인 송신자는 의도적으로 스트림 데이터의 일부를 보내지 않아 수신자가 전송되지 않은 데이터에 대한 리소스를 할당하게 할 수 있다. 이는 수신 버퍼 메모리의 불균형한 할당 및/또는 수신자에서 크고 비효율적인 데이터 구조의 생성을 초래할 수 있다.¶

악의적인 수신자는 송신자가 확인 응답되지 않은 스트림 데이터를 재전송을 위해 저장하도록 강제하려는 시도로 스트림 데이터를 포함하는 패킷을 의도적으로 확인 응답하지 않을 수 있다.¶

수신자에 대한 공격은 흐름 제어 창이 사용 가능한 메모리에 대응하면 완화된다. 그러나 일부 수신자는 메모리를 과다 할당하고 실제 사용 가능한 메모리를 초과하는 흐름 제어 오프셋을 전체적으로 광고한다. 과다 할당 전략은 엔드포인트가 잘 동작할 때 더 나은 성능으로 이어질 수 있지만, 엔드포인트를 스트림 단편화 공격에 취약하게 만든다.¶

QUIC 배포는 스트림 단편화 공격에 대한 완화책을 제공해야 SHOULD 한다. 완화책은 메모리 과다 할당 회피, 추적 데이터 구조의 크기 제한, STREAM 프레임 재조립 지연, 재조립 hole의 나이와 지속 시간에 기반한 휴리스틱 구현, 또는 이들의 조합으로 구성될 수 있다.¶

21.8. 스트림 커밋먼트 공격

악의적인 엔드포인트는 많은 수의 스트림을 열어 엔드포인트의 상태를 고갈시킬 수 있다. 악의적인 엔드포인트는 TCP의 SYN flooding 공격과 유사한 방식으로 많은 수의 연결에서 이 과정을 반복할 수 있다.¶

일반적으로 클라이언트는 Section 2.1에 설명된 것처럼 순차적으로 스트림을 연다. 그러나 짧은 간격으로 여러 스트림이 시작되면, 손실이나 재정렬로 인해 스트림을 여는 STREAM 프레임이 순서를 벗어나 수신될 수 있다. 더 높은 번호의 스트림 ID를 수신하면, 수신자는 같은 유형의 사이에 있는 모든 스트림을 열어야 한다. Section 3.2를 참조한다. 따라서 새 연결에서 스트림 4000000을 열면 클라이언트가 시작한 양방향 스트림 100만 1개가 열린다.¶

활성 스트림의 수는 수신된 MAX_STREAMS 프레임에 의해 업데이트되는 initial_max_streams_bidi 및 initial_max_streams_uni 전송 매개변수에 의해 제한된다. Section 4.6에 설명된 것과 같다. 신중하게 선택된다면 이러한 한도는 스트림 커밋먼트 공격의 영향을 완화한다. 그러나 한도를 너무 낮게 설정하면 애플리케이션이 많은 수의 스트림을 열 것으로 기대하는 경우 성능에 영향을 줄 수 있다.¶

21.9. 피어 서비스 거부

QUIC와 TLS는 일부 맥락에서 정당한 용도가 있는 프레임이나 메시지를 모두 포함하지만, 이러한 프레임이나 메시지는 연결 상태에 관찰 가능한 영향을 주지 않으면서 피어가 처리 리소스를 소비하게 하는 데 남용될 수 있다.¶

메시지는 흐름 제어 한도에 작은 증가분을 보내는 것처럼 작거나 중요하지 않은 방식으로 상태를 변경하고 되돌리는 데도 사용될 수 있다.¶

처리 비용이 대역폭 소비나 상태에 대한 영향과 비교해 불균형하게 크다면, 이는 악의적인 피어가 처리 용량을 고갈시킬 수 있게 할 수 있다.¶

모든 메시지에는 정당한 용도가 있지만, 구현은 진행 대비 처리 비용을 추적하고, 생산적이지 않은 패킷의 과도한 수량을 공격의 징후로 처리해야 SHOULD 한다. 엔드포인트는 이 조건에 연결 오류로 응답하거나 패킷을 삭제할 수 MAY 있다.¶

21.10. 명시적 혼잡 알림 공격

경로상 공격자는 IP 헤더의 ECN 필드 값을 조작하여 송신자의 속도에 영향을 줄 수 있다. [RFC3168]은 조작과 그 영향을 더 자세히 논의한다.¶

제한된 경로상 공격자는 수정된 ECN 필드가 있는 패킷을 복제하고 보내 송신자의 속도에 영향을 줄 수 있다. 수신자가 중복 패킷을 폐기한다면, 공격자가 이 공격에 성공하려면 중복 패킷을 원래 패킷과 경합시켜야 한다. 따라서 QUIC 엔드포인트는 해당 IP 패킷 안의 최소 하나의 QUIC 패킷이 성공적으로 처리되지 않는 한 IP 패킷의 ECN 필드를 무시한다. Section 13.4를 참조한다.¶

21.11. 상태 없는 재설정 오라클

상태 없는 재설정은 TCP reset injection과 유사한 가능한 서비스 거부 공격을 만든다. 이 공격은 공격자가 선택한 연결 ID를 가진 연결에 대해 상태 없는 재설정 토큰이 생성되게 할 수 있는 경우 가능하다. 이 토큰이 생성되게 할 수 있는 공격자는 같은 연결 ID를 가진 활성 연결을 재설정할 수 있다.¶

패킷이 정적 키를 공유하는 서로 다른 인스턴스로 라우팅될 수 있다면, 예를 들어 IP 주소나 포트를 변경함으로써, 공격자는 서버가 상태 없는 재설정을 보내게 할 수 있다. 이러한 방식의 서비스 거부를 방어하기 위해, 상태 없는 재설정을 위한 정적 키를 공유하는 엔드포인트 (Section 10.3.2 참조)는 해당 연결이 더 이상 활성 상태가 아닌 경우를 제외하고, 주어진 연결 ID를 가진 패킷이 항상 연결 상태를 가진 인스턴스에 도착하도록 배치되어야 MUST 한다.¶

더 일반적으로, 서버는 해당 연결 ID를 가진 연결이 같은 정적 키를 사용하는 어떤 엔드포인트에서든 활성 상태일 수 있다면 상태 없는 재설정을 생성해서는 MUST NOT 안 된다.¶

동적 로드 밸런싱을 사용하는 클러스터의 경우, 활성 인스턴스가 연결 상태를 보유하는 동안 로드 밸런서 구성 변경이 발생할 수 있다. 인스턴스가 연결 상태를 보유하더라도 라우팅 변경과 그 결과인 상태 없는 재설정은 연결 종료로 이어진다. 패킷이 올바른 인스턴스로 라우팅될 가능성이 없다면, 연결이 타임아웃되기를 기다리는 것보다 상태 없는 재설정을 보내는 것이 낫다. 그러나 이는 라우팅이 공격자의 영향을 받을 수 없는 경우에만 허용된다.¶

21.12. 버전 다운그레이드

이 문서는 두 엔드포인트 사이에서 사용되는 QUIC 버전을 협상하는 데 사용할 수 있는 QUIC Version Negotiation 패킷(Section 6)을 정의한다. 그러나 이 문서는 이 버전과 이후의 향후 버전 사이에서 이 협상이 어떻게 수행될지 지정하지 않는다. 특히 Version Negotiation 패킷은 버전 다운그레이드 공격을 방지하는 메커니즘을 포함하지 않는다. Version Negotiation 패킷을 사용하는 향후 QUIC 버전은 버전 다운그레이드 공격에 강건한 메커니즘을 정의해야 MUST 한다.¶

21.13. 라우팅에 의한 표적 공격

배포는 공격자가 새 연결을 특정 서버 인스턴스로 표적화할 수 있는 능력을 제한해야 한다. 이상적으로 라우팅 결정은 주소를 포함하여 클라이언트가 선택한 값과 독립적으로 이루어진다. 인스턴스가 선택되면, 이후 패킷이 같은 인스턴스로 라우팅되도록 연결 ID를 선택할 수 있다.¶

21.14. 트래픽 분석

QUIC 패킷의 길이는 해당 패킷 내용의 길이에 대한 정보를 드러낼 수 있다. PADDING 프레임은 엔드포인트가 패킷 내용의 길이를 어느 정도 숨길 수 있도록 제공된다. Section 19.1을 참조한다.¶

트래픽 분석을 물리치는 것은 어렵고 활발한 연구 주제이다. 길이는 정보가 유출될 수 있는 유일한 방식이 아니다. 엔드포인트는 패킷의 타이밍과 같은 다른 side channel을 통해서도 민감한 정보를 드러낼 수 있다.¶

22.1. QUIC 레지스트리에 대한 등록 정책

모든 QUIC 레지스트리는 코드포인트의 임시 등록과 영구 등록을 모두 허용한다. 이 섹션은 이러한 레지스트리에 공통으로 적용되는 정책을 문서화한다.¶

22.2. QUIC Versions 레지스트리

IANA는 "QUIC" heading 아래에 "QUIC Versions" 레지스트리를 추가했다.¶

"QUIC Versions" 레지스트리는 32비트 공간을 관리한다. Section 15를 참조한다. 이 레지스트리는 Section 22.1의 등록 정책을 따른다. 이 레지스트리의 영구 등록은 Specification Required 정책 (Section 4.6 of [RFC8126])을 사용하여 할당된다.¶

프로토콜에 대한 코드포인트 0x00000001은 이 문서에 정의된 프로토콜에 permanent 상태로 할당된다. 코드포인트 0x00000000은 영구적으로 예약되며, 이 코드포인트의 note는 이 버전이 버전 협상을 위해 예약되었음을 나타낸다.¶

패턴 0x?a?a?a?a를 따르는 모든 코드포인트는 예약되어 있고, IANA에 의해 할당되어서는 MUST NOT 안 되며, 할당된 값 목록에 나타나서는 MUST NOT 안 된다.¶

22.3. QUIC Transport Parameters 레지스트리

IANA는 "QUIC" heading 아래에 "QUIC Transport Parameters" 레지스트리를 추가했다.¶

"QUIC Transport Parameters" 레지스트리는 62비트 공간을 관리한다. 이 레지스트리는 Section 22.1의 등록 정책을 따른다. 이 레지스트리의 영구 등록은 Specification Required 정책(Section 4.6 of [RFC8126])을 사용하여 할당된다. 단, 0x00부터 0x3f(16진수)까지의 값은 예외로, [RFC8126]의 Sections 4.9 및 4.10에 정의된 Standards Action 또는 IESG Approval을 사용하여 할당된다.¶

Section 22.1.1에 나열된 필드에 더해, 이 레지스트리의 영구 등록은 다음 필드를 포함해야 MUST 한다:¶

Parameter Name:

매개변수에 대한 짧은 mnemonic.¶

이 레지스트리의 초기 내용은 Table 6에 표시되어 있다.¶

정수 값 N에 대해 31 * N + 27 형식의 각 값(즉, 27, 58, 89, ...)은 예약된다. 이러한 값은 IANA에 의해 할당되어서는 MUST NOT 안 되며, 할당된 값 목록에 나타나서는 MUST NOT 안 된다.¶

22.4. QUIC Frame Types 레지스트리

IANA는 "QUIC" heading 아래에 "QUIC Frame Types" 레지스트리를 추가했다.¶

"QUIC Frame Types" 레지스트리는 62비트 공간을 관리한다. 이 레지스트리는 Section 22.1의 등록 정책을 따른다. 이 레지스트리의 영구 등록은 Specification Required 정책(Section 4.6 of [RFC8126])을 사용하여 할당된다. 단, 0x00부터 0x3f(16진수)까지의 값은 예외로, [RFC8126]의 Sections 4.9 and 4.10에 정의된 Standards Action 또는 IESG Approval을 사용하여 할당된다.¶

Section 22.1.1에 나열된 필드에 더해, 이 레지스트리의 영구 등록은 다음 필드를 포함해야 MUST 한다:¶

Frame Type Name:

프레임 유형에 대한 짧은 mnemonic.¶

Section 22.1의 조언에 더해, 새로운 영구 등록에 대한 명세는 엔드포인트가 식별된 유형의 프레임을 보낼 수 있음을 판단할 수 있는 수단을 설명해야 SHOULD 한다. 대부분의 등록에는 동반되는 전송 매개변수 등록이 기대된다. Section 22.3을 참조한다. 영구 등록에 대한 명세는 또한 프레임 안의 모든 필드의 형식과 할당된 의미론을 설명해야 한다.¶

이 레지스트리의 초기 내용은 Table 3에 표로 정리되어 있다. 레지스트리는 Table 3의 "Pkts" 및 "Spec" 열을 포함하지 않는다는 점에 유의한다.¶

22.5. QUIC Transport Error Codes 레지스트리

IANA는 "QUIC" heading 아래에 "QUIC Transport Error Codes" 레지스트리를 추가했다.¶

"QUIC Transport Error Codes" 레지스트리는 62비트 공간을 관리한다. 이 공간은 서로 다른 정책이 적용되는 세 범위로 나뉜다. 이 레지스트리의 영구 등록은 Specification Required 정책(Section 4.6 of [RFC8126])을 사용하여 할당된다. 단, 0x00부터 0x3f(16진수)까지의 값은 예외로, [RFC8126]의 Sections 4.9 및 4.10에 정의된 Standards Action 또는 IESG Approval을 사용하여 할당된다.¶

Section 22.1.1에 나열된 필드에 더해, 이 레지스트리의 영구 등록은 다음 필드를 포함해야 MUST 한다:¶

Code:

매개변수에 대한 짧은 mnemonic.¶

Description:

오류 코드 의미론에 대한 간단한 설명이며, 명세 참조가 제공된 경우 요약일 수 MAY 있다.¶

이 레지스트리의 초기 내용은 Table 7에 표시되어 있다.¶

A.1. 샘플 가변 길이 정수 디코딩

Figure 45의 의사코드는 바이트 스트림에서 가변 길이 정수를 읽는 방법을 보여준다. ReadVarint 함수는 단일 인수, 즉 네트워크 바이트 순서로 읽을 수 있는 바이트 시퀀스를 받는다.¶

ReadVarint(data):
  // The length of variable-length integers is encoded in the
  // first two bits of the first byte.
  v = data.next_byte()
  prefix = v >> 6
  length = 1 << prefix

  // Once the length is known, remove these bits and read any
  // remaining bytes.
  v = v & 0x3f
  repeat length-1 times:
    v = (v << 8) + data.next_byte()
  return v

예를 들어, 8바이트 시퀀스 0xc2197c5eff14e88c는 십진수 값 151,288,809,941,952,652로 디코딩된다. 4바이트 시퀀스 0x9d7f3e7d는 494,878,333으로 디코딩된다. 2바이트 시퀀스 0x7bbd는 15,293으로 디코딩된다. 그리고 단일 바이트 0x25는 37로 디코딩된다(2바이트 시퀀스 0x4025도 마찬가지이다).¶

A.2. 샘플 패킷 번호 인코딩 알고리즘

Figure 46의 의사코드는 구현이 패킷 번호 인코딩에 적절한 크기를 선택하는 방법을 보여준다.¶

EncodePacketNumber 함수는 두 인수를 받는다:¶

• full_pn은 전송되는 패킷의 전체 패킷 번호이다.¶
• largest_acked는 현재 패킷 번호 공간에서 피어가 확인 응답한 가장 큰 패킷 번호이며, 있는 경우에 해당한다.¶

EncodePacketNumber(full_pn, largest_acked):

  // The number of bits must be at least one more
  // than the base-2 logarithm of the number of contiguous
  // unacknowledged packet numbers, including the new packet.
  if largest_acked is None:
    num_unacked = full_pn + 1
  else:
    num_unacked = full_pn - largest_acked

  min_bits = log(num_unacked, 2) + 1
  num_bytes = ceil(min_bits / 8)

  // Encode the integer value and truncate to
  // the num_bytes least significant bytes.
  return encode(full_pn, num_bytes)

예를 들어, 엔드포인트가 패킷 0xabe8b3에 대한 확인 응답을 수신했고 번호 0xac5c02인 패킷을 전송하고 있다면, outstanding 패킷 번호는 29,519(0x734f)개이다. 이 범위의 최소 두 배(59,038개 패킷, 즉 0xe69e)를 표현하려면 16비트가 필요하다.¶

같은 상태에서 번호 0xace8fe인 패킷을 전송하면 24비트 인코딩을 사용한다. 이 범위의 두 배(131,222개 패킷, 즉 0x020096)를 표현하려면 최소 18비트가 필요하기 때문이다.¶

A.3. 샘플 패킷 번호 디코딩 알고리즘

Figure 47의 의사코드는 헤더 보호가 제거된 후 패킷 번호를 디코딩하는 예시 알고리즘을 포함한다.¶

DecodePacketNumber 함수는 세 인수를 받는다:¶

• largest_pn은 현재 패킷 번호 공간에서 성공적으로 처리된 가장 큰 패킷 번호이다.¶
• truncated_pn은 Packet Number 필드의 값이다.¶
• pn_nbits는 Packet Number 필드의 비트 수(8, 16, 24 또는 32)이다.¶

DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
   expected_pn  = largest_pn + 1
   pn_win       = 1 << pn_nbits
   pn_hwin      = pn_win / 2
   pn_mask      = pn_win - 1
   // The incoming packet number should be greater than
   // expected_pn - pn_hwin and less than or equal to
   // expected_pn + pn_hwin
   //
   // This means we cannot just strip the trailing bits from
   // expected_pn and add the truncated_pn because that might
   // yield a value outside the window.
   //
   // The following code calculates a candidate value and
   // makes sure it's within the packet number window.
   // Note the extra checks to prevent overflow and underflow.
   candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
   if candidate_pn <= expected_pn - pn_hwin and
      candidate_pn < (1 << 62) - pn_win:
      return candidate_pn + pn_win
   if candidate_pn > expected_pn + pn_hwin and
      candidate_pn >= pn_win:
      return candidate_pn - pn_win
   return candidate_pn

예를 들어, 성공적으로 인증된 가장 높은 패킷의 패킷 번호가 0xa82f30ea라면, 16비트 값 0x9b32를 포함하는 패킷은 0xa82f9b32로 디코딩된다.¶

A.4. 샘플 ECN 검증 알고리즘

엔드포인트가 새 네트워크 경로에서 전송을 시작할 때마다, 해당 경로가 ECN을 지원하는지 판단한다. Section 13.4를 참조한다. 경로가 ECN을 지원하면 목표는 ECN을 사용하는 것이다. 엔드포인트는 ECN을 지원하지 않는 것으로 판단된 경로를 주기적으로 재평가할 수도 있다.¶

이 섹션은 새 경로를 테스트하는 한 가지 방법을 설명한다. 이 알고리즘은 ECN 지원 여부를 경로에서 어떻게 테스트할 수 있는지 보여주기 위한 것이다. 엔드포인트는 다른 방법을 구현할 수 있다.¶

경로에는 "testing", "unknown", "failed" 또는 "capable" 중 하나인 ECN 상태가 할당된다. "testing" 또는 "capable" 상태의 경로에서는 엔드포인트가 ECT 표시가 있는 패킷을 보낸다. 기본값은 ECT(0)이다. 그렇지 않으면 엔드포인트는 표시되지 않은 패킷을 보낸다.¶

경로 테스트를 시작하려면 ECN 상태가 "testing"으로 설정되고, 기존 ECN 카운트가 기준선으로 기억된다.¶

테스트 기간은 엔드포인트가 결정한 패킷 수 또는 제한된 시간 동안 실행된다. 목표는 테스트 기간의 지속 시간을 제한하는 것이 아니라, 수신된 ECN 카운트가 경로가 표시된 패킷을 어떻게 처리하는지에 대한 명확한 표시를 제공할 수 있도록 충분한 표시된 패킷이 전송되도록 보장하는 것이다. Section 13.4.2는 이를 10개 패킷 또는 PTO의 세 배로 제한할 것을 제안한다.¶

테스트 기간이 끝나면 경로의 ECN 상태는 "unknown"이 된다. "unknown" 상태에서, ACK 프레임의 ECN 카운트 검증 성공(Section 13.4.2.1 참조)은 표시된 패킷이 하나도 확인 응답되지 않은 경우를 제외하고, 경로의 ECN 상태를 "capable"로 만든다.¶

ECN 카운트 검증이 언제든 실패하면, 영향을 받는 경로의 ECN 상태는 "failed"가 된다. 엔드포인트는 표시된 패킷이 모두 손실로 선언되었거나 모두 ECN-CE 표시가 된 경우에도 경로의 ECN 상태를 "failed"로 표시할 수 있다.¶

이 알고리즘을 따르면 ECN을 적절히 지원하는 경로에서 ECN이 비활성화되는 경우가 드물도록 보장된다. 표시를 잘못 수정하는 경로는 ECN이 비활성화되게 한다. 표시된 패킷이 경로에서 폐기되는 드문 경우에는, 테스트 기간이 짧아 발생하는 손실 수가 제한된다.¶