QPACK: HTTP/3용 필드 압축

동적 테이블에 항목을 삽입하는 것이 불가능할 수 있으며, 특히 테이블에 축출할 수 없는 항목이 포함된 경우가 있습니다.

동적 테이블 항목은 삽입 직후 즉시 축출될 수 없습니다. 삽입이 확인(ack)되고, 확인되지 않은 표현들에서 해당 항목에 대한 미해결 참조가 없을 때 그 항목은 축출 가능해집니다. 인코더 스트림에서의 참조는 해당 항목을 축출하는 명령이 처리되기 전에 항상 처리된다는 보장이 있으므로 이러한 참조는 항목의 축출을 방해하지 않습니다.

만약 새 항목을 추가하기 위해 다른 항목을 축출해야 하는데, 축출되어야 할 항목들이 축출 불가능한 경우, 인코더는 해당 항목(이미 존재하는 항목의 중복 포함)을 동적 테이블에 삽입해서는 안 됩니다(MUST NOT). 이를 피하려면, 동적 테이블을 사용하는 인코더는 디코더가 확인할 때까지 각 필드 섹션이 참조하는 동적 테이블 항목을 추적해야 합니다(섹션 4.4.1 참조).

QUIC은 서로 다른 스트림 간의 데이터 순서를 보장하지 않기 때문에, 디코더는 아직 수신하지 못한 동적 테이블 항목을 참조하는 표현을 만날 수 있습니다.

각 인코딩된 필드 섹션은 Required Insert Count(섹션 4.5.1)를 포함하며, 이는 해당 필드 섹션을 디코딩할 수 있는 Insert Count의 최저 가능 값을 나타냅니다. 동적 테이블 참조를 사용하여 인코딩된 필드 섹션의 경우 Required Insert Count는 참조된 모든 동적 테이블 항목의 가장 큰 절대 인덱스보다 하나 큽니다. 동적 테이블 참조가 없는 필드 섹션의 경우 Required Insert Count는 0입니다.

디코더가 자신의 Insert Count보다 큰 Required Insert Count를 가진 인코딩된 필드 섹션을 수신하면, 해당 스트림은 즉시 처리할 수 없으며 "차단됨"으로 간주됩니다(섹션 2.2.1 참조).

디코더는 SETTINGS_QPACK_BLOCKED_STREAMS 설정을 사용하여 차단될 수 있는 스트림 수의 상한을 지정합니다(섹션 5 참조). 인코더는 항상 SETTINGS_QPACK_BLOCKED_STREAMS 값으로 차단될 수 있는 스트림 수를 제한해야 합니다(MUST). 만약 디코더가 지원하겠다고 약속한 것보다 더 많은 차단된 스트림을 만나면, 이는 QPACK_DECOMPRESSION_FAILED 유형의 연결 오류로 처리되어야 합니다.

디코더가 위험할 수 있는 모든 스트림에서 실제로 차단 상태가 되는 것은 아님에 유의하십시오.

인코더는 스트림이 차단되는 위험을 감수할지 여부를 결정할 수 있습니다. SETTINGS_QPACK_BLOCKED_STREAMS의 값이 허용하는 경우, 전송 중인 동적 테이블 항목을 참조함으로써 종종 압축 효율을 개선할 수 있지만, 손실이나 재정렬이 발생하면 해당 스트림이 디코더에서 차단될 수 있습니다. 인코더는 확인된 항목만 참조하여 차단 위험을 피할 수 있지만, 이는 리터럴을 사용해야 할 수 있음을 의미합니다. 리터럴은 인코딩된 필드 섹션을 더 크게 만들기 때문에, 인코더가 혼잡 또는 흐름 제어 제한으로 인해 차단되는 결과를 초래할 수 있습니다.

흐름 제어에 의해 제한되는 스트림에 명령을 쓰는 것은 교착 상태를 초래할 수 있습니다.

디코더는 필요한 업데이트가 인코더 스트림에서 수신될 때까지 인코딩된 필드 섹션을 전달하는 스트림에 대한 흐름 제어 크레딧을 중단할 수 있습니다. 만약 인코더 스트림(또는 연결 전체)에 대한 흐름 제어 크레딧 부여가 인코딩된 필드 섹션을 포함하는 스트림의 데이터 소비 및 해제에 의존한다면 교착 상태가 발생할 수 있습니다.

일반적으로, 큰 명령을 포함하는 스트림은 디코더가 그 명령이 완전히 수신될 때까지 흐름 제어 크레딧을 보류하면 교착 상태에 빠질 수 있습니다.

이러한 교착 상태를 피하기 위해, 인코더는 전체 명령에 대해 충분한 스트림 및 연결 흐름 제어 크레딧이 있는 경우에만 명령을 작성하는 것이 권고됩니다(SHOULD NOT 쓰지 말아야 합니다).

Known Received Count는 디코더가 확인한 동적 테이블 삽입 및 중복의 총 수입니다. 인코더는 어떤 동적 테이블 항목을 잠재적으로 차단 없이 참조할 수 있는지 식별하기 위해 Known Received Count를 추적합니다. 디코더는 Insert Count Increment 명령을 보낼 수 있도록 Known Received Count를 추적합니다.

섹션 확인 명령(4.4.1)은 디코더가 해당 필드 섹션을 디코딩하는 데 필요한 모든 동적 테이블 상태를 수신했음을 의미합니다. 만약 확인된 필드 섹션의 Required Insert Count가 현재 Known Received Count보다 크면, Known Received Count는 그 Required Insert Count 값으로 업데이트됩니다.

Insert Count Increment 명령(4.4.3)은 그 Increment 매개변수만큼 Known Received Count를 증가시킵니다. 지침은 섹션 2.2.2.3을 참조하십시오.

인코딩된 필드 섹션을 수신하면, 디코더는 Required Insert Count를 검사합니다. Required Insert Count가 디코더의 Insert Count 이하이면 해당 필드 섹션은 즉시 처리할 수 있습니다. 그렇지 않으면 필드 섹션이 수신된 스트림은 차단됩니다.

차단 상태 동안 인코딩된 필드 섹션 데이터는 차단된 스트림의 흐름 제어 윈도우에 남아 있어야 합니다(SHOULD). 이 데이터는 스트림이 차단 해제될 때까지 사용할 수 없으며, 흐름 제어를 조기에 해제하면 디코더가 메모리 고갈 공격에 취약해집니다. 스트림은 디코더가 해당 스트림에서 읽기 시작한 모든 인코딩된 필드 섹션에 대해 Insert Count가 Required Insert Count 이상이 될 때 차단 해제됩니다.

인코딩된 필드 섹션을 처리할 때, 디코더는 Required Insert Count가 해당 필드 섹션을 디코딩할 수 있는 Insert Count의 최저 가능 값과 일치할 것으로 기대합니다(섹션 2.1.2 참조). 만약 기대보다 작은 Required Insert Count를 만나면, 이는 QPACK_DECOMPRESSION_FAILED 유형의 연결 오류로 처리되어야 합니다(섹션 2.2.3 참조). 기대보다 큰 Required Insert Count를 만나면, 디코더는 QPACK_DECOMPRESSION_FAILED 유형의 연결 오류로 처리할 수 있습니다(MAY).

디코더는 디코더 스트림에서 디코더 명령(섹션 4.4)을 발행함으로써 다음 이벤트들을 신호합니다.

디코더가 필드 라인 표현에서 이미 축출되었거나 선언된 Required Insert Count(섹션 4.5.1)보다 크거나 같은 절대 인덱스를 가진 동적 테이블 항목을 참조하는 것을 만나면, 이는 QPACK_DECOMPRESSION_FAILED 유형의 연결 오류로 처리되어야 합니다(MUST).

디코더가 인코더 명령에서 이미 축출된 동적 테이블 항목을 참조하는 것을 만나면, 이는 QPACK_ENCODER_STREAM_ERROR 유형의 연결 오류로 처리되어야 합니다(MUST).

동적 테이블의 크기는 그 항목들의 크기의 합입니다.

항목의 크기는 이름의 바이트 길이, 값의 바이트 길이, 그리고 추가로 32바이트를 합한 값입니다. 항목의 크기는 이름과 값에 허프만 인코딩을 적용하지 않은 길이를 사용하여 계산됩니다.

인코더는 동적 테이블의 용량(capacity)을 설정하며, 이는 테이블 크기의 상한으로 작동합니다. 동적 테이블의 초기 용량은 0입니다. 인코더는 0이 아닌 용량으로 Set Dynamic Table Capacity 명령(섹션 4.3.1)을 전송하여 동적 테이블 사용을 시작합니다.

새 항목이 동적 테이블에 추가되기 전에, 동적 테이블의 끝에서부터 항목들을 축출하여 동적 테이블의 크기가 (테이블 용량 - 새 항목 크기) 이하가 될 때까지 진행됩니다. 인코더는 축출될 항목이 축출 가능하지 않은 경우에는 해당 항목을 축출하도록 해서는 안 됩니다(MUST NOT); 관련 내용은 섹션 2.1.1을 참조하십시오. 그런 다음 새 항목이 테이블에 추가됩니다. 만약 인코더가 동적 테이블 용량보다 큰 항목을 추가하려고 시도하면 이는 오류이며, 디코더는 이를 QPACK_ENCODER_STREAM_ERROR 유형의 연결 오류로 처리해야 합니다(MUST).

새 항목은 해당 항목을 추가할 때 축출될 동적 테이블의 항목을 참조할 수 있습니다. 구현체는 참조된 항목이 새 항목을 삽입하기 전에 동적 테이블에서 축출되는 경우 참조된 이름이나 값을 삭제하지 않도록 주의해야 합니다.

인코더가 동적 테이블 용량을 줄이면(섹션 4.3.1 참조), 동적 테이블의 끝에서부터 항목들이 축출되어 동적 테이블의 크기가 새로운 테이블 용량 이하가 될 때까지 진행됩니다. 이 메커니즘은 용량을 0으로 설정하여 동적 테이블의 항목을 완전히 지운 다음 이후에 복원하는 데 사용할 수 있습니다.

디코더의 메모리 요구를 제한하기 위해, 디코더는 인코더가 동적 테이블 용량으로 설정할 수 있는 최대값을 제한합니다. HTTP/3에서는 이 한도가 디코더가 전송하는 SETTINGS_QPACK_MAX_TABLE_CAPACITY 값으로 결정됩니다; 자세한 내용은 섹션 5을 참조하십시오. 인코더는 이 최대값을 초과하는 동적 테이블 용량을 설정해서는 안 되지만(MUST NOT), 더 낮은 용량을 선택할 수 있습니다(섹션 4.3.1 참조).

0-RTT 데이터를 사용하는 클라이언트의 경우, 서버의 최대 테이블 용량은 설정의 기억된 값이며, 이전에 전송되지 않았다면 0입니다. 클라이언트의 0-RTT 설정 값이 0인 경우 서버는 SETTINGS 프레임에서 이를 0이 아닌 값으로 설정할 수 있습니다(MAY). 기억된 값이 0이 아닌 경우 서버는 반드시 동일한 0이 아닌 값을 자신의 SETTINGS 프레임에 보내야 합니다(MUST). 만약 서버가 다른 값을 지정하거나 SETTINGS에서 SETTINGS_QPACK_MAX_TABLE_CAPACITY를 생략하면, 인코더는 이를 QPACK_DECODER_STREAM_ERROR 유형의 연결 오류로 처리해야 합니다.

0-RTT 데이터를 사용하지 않는 클라이언트(0-RTT가 시도되지 않았거나 거부된 경우) 및 모든 HTTP/3 서버의 경우, 인코더가 non-zero SETTINGS_QPACK_MAX_TABLE_CAPACITY 값을 처리할 때까지 최대 테이블 용량은 0입니다.

최대 테이블 용량이 0일 때 인코더는 동적 테이블에 항목을 삽입해서는 안 되며(MUST NOT), 인코더 스트림에서 어떤 인코더 명령도 보내서는 안 됩니다(MUST NOT).

각 항목은 그 항목의 생존 기간 동안 고정되는 절대 인덱스를 가집니다. 처음 삽입된 항목의 절대 인덱스는 0이며, 삽입이 진행될수록 인덱스는 하나씩 증가합니다.

상대 인덱스는 0에서 시작하며 절대 인덱스와 반대 방향으로 증가합니다. 상대 인덱스 0이 어떤 항목을 가리키는지는 참조의 문맥에 따라 달라집니다.

인코더 명령(섹션 4.3)에서 상대 인덱스 0은 동적 테이블에 가장 최근에 삽입된 값을 가리킵니다. 따라서 인코더 스트림에서 명령을 해석하는 동안 특정 상대 인덱스로 참조되는 항목은 변경될 수 있습니다.

인코더 명령과 달리, 필드 라인 표현에서의 상대 인덱스는 인코딩된 필드 섹션 시작 시의 Base를 기준으로 합니다(섹션 4.5.1 참조). 이는 인코딩된 필드 섹션과 동적 테이블 업데이트가 순서가 뒤바뀐 상태로 처리되더라도 참조가 안정적임을 보장합니다.

필드 라인 표현에서 상대 인덱스 0은 절대 인덱스가 Base - 1인 항목을 가리킵니다.

포스트-베이스 인덱스는 Base보다 크거나 같는 절대 인덱스를 가진 항목들에 대해 필드 라인 표현에서 사용됩니다. 이 인덱스는 절대 인덱스가 Base인 항목을 0으로 시작하여 절대 인덱스와 동일한 방향으로 증가합니다.

포스트-베이스 인덱스는 인코더가 단일 패스로 필드 섹션을 처리하면서 그 처리 도중(또는 다른 필드 섹션을 처리하는 동안)에 추가된 항목들을 참조할 수 있게 합니다.

문서 전반에서 RFC 7541 섹션 5.1에 정의된 접두사 정수 형식이 광범위하게 사용됩니다. RFC 7541의 형식은 수정 없이 사용됩니다. 다만 QPACK은 HPACK에서 실제로 사용되지 않은 일부 접두사 크기를 사용할 수 있습니다.

QPACK 구현체는 최대 62비트 길이의 정수를 디코드할 수 있어야 합니다(MUST).

문서 전반에서 RFC 7541 섹션 5.2에 정의된 문자열 리터럴 형식도 사용됩니다. 이 문자열 형식은 선택적 허프만 인코딩을 포함합니다.

HPACK은 문자열 리터럴이 바이트 경계에서 시작하도록 정의합니다. 문자열은 본 문서에서 'H'로 표기되는 허프만 플래그 1비트로 시작하고, 이어서 7비트 접두사 정수로 인코딩된 문자열 길이, 마지막으로 지정된 바이트 수의 데이터가 옵니다. 허프만 인코딩이 사용될 때는 RFC 7541의 부록 B의 허프만 테이블을 수정 없이 사용하며, 표시된 길이는 인코딩 후의 문자열 크기입니다.

본 문서는 문자열 리터럴이 바이트 경계가 아닌 위치에서 시작하는 것을 허용하도록 정의를 확장합니다. "N-비트 접두사 문자열 리터럴"은 바이트 중간에서 시작하며 처음 (8-N) 비트는 이전 필드에 할당됩니다. 문자열은 허프만 플래그 1비트를 사용하며, 이어서 (N-1)-비트 접두사 정수로 인코딩된 인코딩된 문자열의 길이가 옵니다. 접두사 크기 N은 2에서 8 사이의 값을 가질 수 있습니다. 문자열 리터럴의 나머지 부분은 변경되지 않습니다.

접두사 길이가 명시되지 않은 문자열 리터럴은 8비트 접두사 문자열 리터럴로 간주되며 RFC 7541의 정의를 수정 없이 따릅니다.

인코더는 '001' 3비트 패턴으로 시작하는 명령을 사용하여 동적 테이블 용량 변경을 디코더에 알립니다. 그 뒤에는 5비트 접두사 정수로 표현된 새로운 동적 테이블 용량이 옵니다(섹션 4.1.1 참조).

새 용량은 섹션 3.2.3에 설명된 한도 이하이어야 합니다(MUST). HTTP/3에서는 이 한도가 디코더가 보낸 SETTINGS_QPACK_MAX_TABLE_CAPACITY 값입니다(섹션 5). 디코더는 이 한도를 초과하는 새 동적 테이블 용량 값을 QPACK_ENCODER_STREAM_ERROR 유형의 연결 오류로 처리해야 합니다(MUST).

동적 테이블 용량을 줄이면 항목이 축출될 수 있습니다(섹션 3.2.2 참조). 이 명령은 항목을 삽입하는 명령이 아니므로 용량 변경은 확인(ack)되지 않습니다. 또한 축출 불가능한 항목의 축출을 유발해서는 안 됩니다(섹션 2.1.1 참조).

인코더는 필드 이름이 정적 또는 동적 테이블의 항목 이름과 일치하는 항목을 동적 테이블에 추가할 때 '1' 1비트 패턴으로 시작하는 명령을 사용합니다. 두 번째 비트('T')는 참조가 정적 테이블인지 동적 테이블인지를 나타냅니다. 뒤따르는 6비트 접두사 정수(섹션 4.1.1)는 필드 이름에 대한 테이블 항목을 찾는 데 사용됩니다. T=1인 경우 숫자는 정적 테이블 인덱스를 나타내고, T=0인 경우 숫자는 동적 테이블의 상대 인덱스입니다.

필드 이름 참조 다음에는 문자열 리터럴로 표현된 필드 값이 옵니다(섹션 4.1.2 참조).

인코더는 필드 이름과 필드 값이 모두 문자열 리터럴로 표현되는 항목을 동적 테이블에 추가할 때 '01' 2비트 패턴으로 시작하는 명령을 사용합니다.

그 다음에는 이름이 6비트 접두사 문자열 리터럴로, 값이 8비트 접두사 문자열 리터럴로 표현됩니다(섹션 4.1.2 참조).

인코더는 '000' 3비트 패턴으로 시작하는 명령을 사용하여 동적 테이블의 기존 항목을 복제합니다. 그 뒤에는 5비트 접두사 정수로 표현된 기존 항목의 상대 인덱스가 옵니다(섹션 4.1.1 참조).

기존 항목은 이름이나 값을 다시 전송하지 않고 동적 테이블에 재삽입됩니다. 이는 오래된 항목을 참조하는 것을 피하여 새 항목 삽입을 차단하는 것을 방지하는 데 유용합니다.

선언된 Required Insert Count가 0이 아닌 인코딩된 필드 섹션을 처리한 후에, 디코더는 섹션 확인 명령을 발행합니다. 이 명령은 '1' 1비트 패턴으로 시작하며, 이어서 해당 필드 섹션과 연관된 스트림 ID가 7비트 접두사 정수로 인코딩되어 옵니다(참조 섹션 4.1.1).

이 명령은 섹션 2.1.4 및 섹션 2.2.2에서 설명된 대로 사용됩니다.

인코더가 이미 비영(非零) Required Insert Count를 가진 모든 인코딩된 필드 섹션을 확인한 스트림을 참조하는 섹션 확인 명령을 수신한 경우, 이는 QPACK_DECODER_STREAM_ERROR 유형의 연결 오류로 처리되어야 합니다(MUST).

섹션 확인 명령은 Known Received Count를 증가시킬 수 있습니다; 관련 내용은 섹션 2.1.4를 참조하십시오.

스트림이 리셋되거나 읽기를 중단할 때, 디코더는 스트림 취소 명령을 발행합니다. 이 명령은 '01' 2비트 패턴으로 시작하며, 이어서 영향을 받는 스트림의 스트림 ID가 6비트 접두사 정수로 인코딩되어 옵니다.

이 명령은 섹션 2.2.2에서 설명된 대로 사용됩니다.

삽입 수 증가 명령은 '00' 2비트 패턴으로 시작하며, 이어서 Increment가 6비트 접두사 정수로 인코딩되어 옵니다. 이 명령은 Known Received Count(섹션 2.1.4)를 Increment 매개변수 값만큼 증가시킵니다. 디코더는 지금까지 처리된 동적 테이블 삽입 및 복제의 총 수까지 Known Received Count를 증가시키는 Increment 값을 보내야 합니다.

Increment 필드가 0이거나, 인코더가 보낸 것보다 Known Received Count를 초과하도록 증가시키는 Increment를 수신한 인코더는 이를 QPACK_DECODER_STREAM_ERROR 유형의 연결 오류로 처리해야 합니다(MUST).

각 인코딩된 필드 섹션은 두 정수로 접두사가 붙습니다. Required Insert Count는 8비트 접두사를 사용하는 정수로 인코딩됩니다(인코딩 방법은 섹션 4.5.1.1 참조). Base는 부호 비트('S')와 7비트 접두사를 사용하는 Delta Base 값으로 인코딩됩니다(참조 섹션 4.5.1.2).

인덱스된 필드 라인 표현은 정적 테이블의 항목이나 Base 값보다 작은 절대 인덱스를 가진 동적 테이블의 항목을 식별합니다.

이 표현은 '1' 1비트 패턴으로 시작하며, 이어서 참조가 정적 테이블인지 동적 테이블인지를 나타내는 'T' 비트가 옵니다. 뒤따르는 6비트 접두사 정수(섹션 4.1.1)는 필드 라인에 대한 테이블 항목을 찾는 데 사용됩니다. T=1이면 숫자는 정적 테이블 인덱스를 나타내고, T=0이면 숫자는 동적 테이블에서의 상대 인덱스입니다.

포스트-베이스 인덱스를 가진 인덱스된 필드 라인 표현은 절대 인덱스가 Base보다 크거나 같은 동적 테이블의 항목을 식별합니다.

이 표현은 '0001' 4비트 패턴으로 시작합니다. 이어서 일치하는 필드 라인의 포스트-베이스 인덱스(섹션 3.2.6)가 4비트 접두사 정수로 표현되어 옵니다(참조 섹션 4.1.1).

이 표현은 필드 이름이 정적 테이블의 항목 이름과 일치하거나 Base 값보다 작은 절대 인덱스를 가진 동적 테이블 항목의 필드 이름과 일치하는 필드 라인을 인코딩합니다.

이 표현은 '01' 2비트 패턴으로 시작합니다. 다음 비트인 'N'은 중개자가 이후 홉에서 이 필드 라인을 동적 테이블에 추가할 수 있는지를 나타냅니다. 'N' 비트가 설정된 경우, 인코딩된 필드 라인은 항상 리터럴 표현으로 인코딩되어야 합니다(MUST). 특히, 피어가 'N' 비트가 설정된 리터럴로 표현된 필드 라인을 수신하고 이를 전달하는 경우에는, 해당 필드 라인을 전달할 때 반드시 리터럴 표현을 사용해야 합니다(MUST). 이 비트는 압축으로 인해 노출되어서는 안 되는 필드 값을 보호하기 위한 목적으로 사용됩니다; 자세한 내용은 섹션 7.1를 참조하십시오.

네 번째 비트인 'T' 비트는 참조가 정적 테이블인지 동적 테이블인지를 나타냅니다. 뒤따르는 4비트 접두사 정수(섹션 4.1.1)는 필드 이름에 대한 테이블 항목을 찾는 데 사용됩니다. T=1이면 숫자는 정적 테이블 인덱스를 나타내고, T=0이면 숫자는 동적 테이블의 상대 인덱스입니다.

동적 테이블 항목에서 가져오는 것은 필드 이름뿐이며, 필드 값은 8비트 접두사 문자열 리터럴로 인코딩됩니다(참조 섹션 4.1.2).

이 표현은 필드 이름이 Base 값보다 크거나 같은 절대 인덱스를 가진 동적 테이블 항목의 필드 이름과 일치하는 필드 라인을 인코딩합니다.

이 표현은 '0000' 4비트 패턴으로 시작합니다. 다섯 번째 비트는 섹션 4.5.4에서 설명한 'N' 비트입니다. 이어서 동적 테이블 항목의 포스트-베이스 인덱스(섹션 3.2.6)가 3비트 접두사 정수로 인코딩되어 옵니다(참조 섹션 4.1.1).

동적 테이블 항목에서 가져오는 것은 필드 이름뿐이며, 필드 값은 8비트 접두사 문자열 리터럴로 인코딩됩니다(참조 섹션 4.1.2).

이 표현은 필드 이름과 필드 값을 문자열 리터럴로 인코딩합니다.

이 표현은 '001' 3비트 패턴으로 시작합니다. 네 번째 비트는 섹션 4.5.4에서 설명한 'N' 비트입니다. 그 다음에 이름이 4비트 접두사 문자열 리터럴로, 그 뒤에 값이 8비트 접두사 문자열 리터럴로 따라옵니다(참조 섹션 4.1.2).

QPACK은 추측이 개별 문자가 아닌 전체 필드 라인과 일치하도록 강제함으로써 CRIME 기반 공격을 완화하지만 완전히 방지하지는 못합니다. 공격자는 추측이 맞는지 여부만 알 수 있으므로 해당 필드 이름에 연관된 필드 값에 대해 무차별 대입 공격을 수행해야 합니다.

따라서 특정 필드 값을 복구할 수 있는 가능성은 값의 엔트로피에 달려 있습니다. 엔트로피가 높은 값은 성공적으로 복구될 가능성이 낮습니다. 반면 엔트로피가 낮은 값은 여전히 취약합니다.

이러한 유형의 공격은 서로 신뢰하지 않는 두 주체가 단일 HTTP/3 연결에 요청 또는 응답을 올리는 경우 언제든지 가능할 수 있습니다. 공유된 QPACK 압축기가 한 주체에게 동적 테이블에 항목을 추가할 권한을 주고 다른 주체에게 선택된 필드 라인을 인코딩할 때 해당 항목을 참조할 권한을 준다면, 공격자(두 번째 주체)는 인코딩된 출력의 길이를 관찰함으로써 테이블 상태를 알 수 있습니다.

• 원본 서버로 향하는 단일 연결에 여러 클라이언트의 요청을 전송하거나,
• 여러 원본 서버의 응답을 수집하여 클라이언트로 향하는 공유된 연결에 배치하는 경우.

웹 브라우저는 동일한 연결에서 다른 웹 오리진([RFC6454])이 만든 요청들이 서로 신뢰하지 않는 주체에 의해 만들어질 수 있음을 가정해야 합니다. 이외에도 서로 신뢰하지 않는 주체가 관련되는 다른 시나리오가 존재할 수 있습니다.

헤더 또는 트레일러 필드에 대한 기밀성이 필요한 HTTP 사용자는 추측을 불가능하게 만들 정도의 엔트로피를 가진 값을 사용할 수 있습니다. 그러나 이는 모든 HTTP 사용자가 공격을 완화하기 위한 조치를 강제하므로 일반적인 해결책으로는 비현실적입니다. 또한 HTTP 사용 방식에 대한 새로운 제약을 부과합니다.

HTTP 사용자에게 제약을 가하기보다는 QPACK 구현이 압축 적용 방식을 제약하여 동적 테이블 탐지 가능성을 제한할 수 있습니다.

이상적인 해결책은 메시지를 구성하는 주체에 따라 동적 테이블에 대한 접근을 분리하는 것입니다. 테이블에 추가된 필드 값은 특정 주체에 귀속되며, 해당 값을 생성한 주체만 그 값을 추출할 수 있어야 합니다.

이 옵션의 압축 성능을 향상시키기 위해 특정 항목은 공개(public)로 태그될 수 있습니다. 예를 들어, 웹 브라우저는 Accept-Encoding 헤더 필드의 값을 모든 요청에서 사용 가능하도록 만들 수 있습니다.

필드 값의 출처에 대한 충분한 지식이 없는 인코더는 대신 동일한 필드 이름에 대해 서로 다른 값이 많은 경우 패널티를 도입할 수 있습니다. 이 패널티는 필드 값을 추측하려는 많은 시도가 이후 메시지에서 해당 필드가 동적 테이블 항목과 비교되지 않도록 만들 수 있어 추가 추측을 사실상 방지합니다.

이 대응은 필드 값의 길이에 반비례하여 적용될 수 있습니다. 즉, 짧은 값에 대해 더 빠르게 또는 더 높은 확률로 동적 테이블 접근을 비활성화할 수 있습니다.

이 완화책은 두 엔드포인트 간에서 가장 효과적입니다. 중개자가 주어진 메시지를 생성한 주체를 알지 못한 채로 재인코딩하는 경우, 중개자는 원래 인코더가 의도적으로 분리해 둔 압축 컨텍스트를 의도치 않게 병합할 수 있습니다.

구현체는 민감한 필드를 압축하지 않고 대신 그 값을 리터럴로 인코딩하여 보호할 수도 있습니다.

필드 라인을 동적 테이블에 삽입하지 않기로 거부하는 것은 모든 홉에서 그렇게 했을 때만 효과적입니다. never-indexed 리터럴 비트(섹션 4.5.4 참조)는 특정 값이 의도적으로 리터럴로 전송되었음을 중개자에게 알리는 데 사용할 수 있습니다.

중개자는 'N' 비트가 설정된 리터럴 표현을 다른 표현으로 재인코딩하여 인덱싱해서는 안 됩니다(MUST NOT). QPACK을 재인코딩에 사용하는 경우, 'N' 비트가 설정된 리터럴 표현을 사용해야 합니다(MUST). HPACK을 재인코딩에 사용하는 경우에는 HPACK의 never-indexed 리터럴 표현(참조 RFC 7541 섹션 6.2.3)을 사용해야 합니다(MUST).

필드 값을 절대 인덱싱하지 않도록 표시하는 선택은 여러 요인에 따라 달라집니다. QPACK은 전체 필드 값을 추측으로부터 보호하지 못하므로, 짧거나 엔트로피가 낮은 값은 공격자에 의해 더 쉽게 복구될 수 있습니다. 따라서 인코더는 엔트로피가 낮은 값을 인덱싱하지 않기로 선택할 수 있습니다.

인코더는 Cookie 또는 Authorization 헤더와 같이 노출될 경우 가치가 높거나 복구가 민감한 필드에 대해서는 값들을 인덱싱하지 않기로 선택할 수도 있습니다.

반대로, 인코더는 노출되더라도 거의 가치가 없는 필드에 대해서는 인덱싱을 선호할 수 있습니다. 예를 들어 User-Agent 헤더 필드는 요청 간에 일반적으로 거의 변하지 않으며 어떤 서버에도 전송됩니다. 이 경우 특정 User-Agent 값이 사용되었음을 확인하는 것은 거의 가치가 없습니다.

이러한 never-indexed 리터럴 표현을 사용할지 결정하는 기준은 시간이 지나면서 새로운 공격이 발견됨에 따라 진화할 것입니다.