Internet-Draft HTTP용 RateLimit 헤더 필드 2026년 5월
Polli 외 2026년 11월 24일 만료 [페이지]
작업 그룹:
HTTPAPI
Internet-Draft:
draft-ietf-httpapi-ratelimit-headers-11
게시일:
예정 상태:
표준 트랙
만료일:
저자:
R. Polli
Team Digitale, 이탈리아 정부
A. Martinez
Red Hat
D. Miller
Microsoft

HTTP용 RateLimit 헤더 필드

초록

이 문서는 서버가 자신의 할당량 정책과 현재 서비스 제한을 알릴 수 있도록 RateLimit-Policy 및 RateLimit HTTP 헤더 필드를 정의하여, 클라이언트가 제한 조치를 받지 않도록 합니다.

이 문서에 관하여

이 참고 사항은 RFC로 게시되기 전에 제거됩니다.

이 문서의 상태 정보는 https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/에서 확인할 수 있습니다.

이 문서에 대한 논의는 HTTPAPI 작업 그룹 메일링 리스트(mailto:httpapi@ietf.org)에서 이루어지며, 이 리스트의 아카이브는 https://mailarchive.ietf.org/arch/browse/httpapi/에 있습니다. 구독은 https://www.ietf.org/mailman/listinfo/httpapi/에서 할 수 있습니다. 작업 그룹 정보는 https://datatracker.ietf.org/wg/httpapi/about/에서 확인할 수 있습니다.

이 초안의 소스와 이슈 트래커는 https://github.com/ietf-wg-httpapi/ratelimit-headers에서 확인할 수 있습니다.

이 메모의 상태

이 Internet-Draft는 BCP 78 및 BCP 79의 조항을 완전히 준수하여 제출됩니다.

Internet-Draft는 Internet Engineering Task Force(IETF)의 작업 문서입니다. 다른 그룹도 작업 문서를 Internet-Draft로 배포할 수 있다는 점에 유의하십시오. 현재 Internet-Draft 목록은 https://datatracker.ietf.org/drafts/current/에 있습니다.

Internet-Draft는 최대 6개월 동안 유효한 초안 문서이며, 언제든지 다른 문서로 갱신, 대체 또는 폐기될 수 있습니다. 이를 참조 자료로 사용하거나 “진행 중인 작업” 이외의 방식으로 인용하는 것은 적절하지 않습니다.

이 Internet-Draft는 2026년 11월 24일에 만료됩니다.

목차

1. 소개

HTTP 클라이언트의 속도 제한은 특히 HTTP API에서 널리 사용되는 관행이 되었습니다. 일반적으로 이를 수행하는 서버는 주어진 시간 윈도우에서 허용 가능한 요청 수를 제한합니다(예: 초당 10개 요청). HTTP에서 속도 제한이 현재 어떻게 사용되는지에 대한 자세한 정보는 부록 A를 참조하십시오.

현재는 클라이언트가 오류를 방지하기 위해 자신의 요청을 스로틀링할 수 있도록 서버가 할당량을 전달하는 표준 방식이 없습니다. 이 문서는 속도 제한을 가능하게 하기 위한 표준 HTTP 헤더 필드 집합을 정의합니다.

이러한 필드는 여러 개의 가변 시간 윈도우와 동적 할당량을 사용하는 것, 그리고 동시성 제한을 구현하는 것을 포함해 복잡한 속도 제한 정책을 수립할 수 있게 합니다.

1.1. 목표

이 문서의 목표는 다음과 같습니다.

상호운용성:

속도 제한 헤더의 이름과 의미를 표준화하여 적용과 도입을 쉽게 합니다.

복원력:

클라이언트가 자신의 요청을 스로틀링하고 4xx 또는 5xx 응답을 방지하는 데 유용한 정보를 제공함으로써 HTTP 인프라의 복원력을 향상합니다.

문서화:

API 문서에 상세한 할당량 제한과 관련 필드를 포함할 필요를 없애 API 문서화를 단순화합니다.

다음 기능은 이 문서의 범위에 포함되지 않습니다.

인가:

RateLimit 헤더 필드는 인가나 다른 종류의 접근 제어를 지원하기 위한 것이 아닙니다.

응답 상태 코드:

RateLimit 헤더 필드는 성공 응답([HTTP]의 Section 15.3 참조)과 실패 응답 모두에서 반환될 수 있습니다. 이 명세는 성공하지 않은 응답이 할당량 사용량에 포함되는지 여부를 다루지 않으며, RateLimit 값과 반환된 상태 코드 사이의 어떤 상관관계도 요구하지 않습니다.

스로틀링 알고리즘:

이 명세는 특정 스로틀링 알고리즘을 요구하지 않습니다. 윈도우 크기를 포함해 필드에 게시되는 값은 정적으로 또는 동적으로 평가될 수 있습니다.

서비스 수준 계약:

전달된 할당량 힌트는 어떤 서비스 보장도 의미하지 않습니다. 서버는 특정 상황에서 서버가 권장한 제한을 준수하는 클라이언트도 자유롭게 스로틀링할 수 있습니다.

1.2. 표기 규칙

이 문서의 핵심어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL"은 여기에서 보인 것처럼 모두 대문자로 나타날 때, 그리고 그때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석됩니다.

Origin이라는 용어는 [WEB-ORIGIN]의 Section 7에 설명된 대로 해석됩니다.

이 문서는 구문과 구문 분석을 지정하기 위해 [SF]의 Section 3에 있는 List, Item 및 Integer 용어와 함께 "bare item" 개념을 사용합니다.

이 문서에서 "problem type"이라는 용어는 [PROBLEM]에 설명된 대로 해석됩니다.

2. 용어

할당량:

할당량은 리소스 서버가 클라이언트 요청을 제한하는 데 사용하는 용량 배정입니다. 이 용량은 클라이언트가 시간 윈도우 안에서 소비할 수 있는 할당량 단위로 측정됩니다.

할당량 단위:

할당량 단위는 클라이언트의 활동을 측정하는 데 사용되는 측정 단위입니다.

할당량 파티션:

할당량 파티션은 서버의 용량을 서로 다른 클라이언트, 사용자 및 소유 리소스에 걸쳐 나눈 것입니다.

시간 윈도우:

시간 윈도우는 배정된 할당량과 관련된 기간을 나타냅니다.

할당량 정책:

할당량 정책은 지정된 할당량 파티션 안에서의 활동을 정의된 시간 윈도우에 걸쳐 할당량 단위로 수량화하여 조절하기 위해 서버가 구현하는 정책입니다. 이 활동은 할당량이라고 알려진 사전 정의된 제한으로 제한됩니다. 할당량 정책은 서버가 알릴 수 있지만 반드시 그렇게 해야 하는 것은 아니며, 둘 이상의 할당량 정책이 클라이언트에서 서버로 가는 특정 요청에 영향을 줄 수 있습니다.

서비스 제한:

서비스 제한은 특정 할당량 정책 아래에서 현재 사용 가능한 할당량이며, 정의된 경우 클라이언트가 사용 가능한 할당량을 초과하지 않고 사용할 수 있는 유효 시간 윈도우입니다.

List:

Items의 [SF] 목록

Item:

관련 매개변수 집합을 가진 [SF] 항목

3. RateLimit-Policy 필드

"RateLimit-Policy" 응답 헤더 필드는 할당량 정책 항목(Section 3.1)의 비어 있지 않은 List[SF]입니다. Item[SF] 값은 String[SF]이어야 합니다(MUST).

필드 값은 HTTP 응답 시퀀스 전반에서 일관되게 유지되는 것이 좋습니다(SHOULD). 이 특성이 매 요청마다 변경될 수 있는(MAY) 정보를 포함하는 RateLimit (Section 4) 필드와 구분되는 점입니다. "RateLimit-Policy" 필드는 서버가 제공한 정책 정보를 바탕으로 클라이언트가 자신의 요청 흐름을 제어할 수 있게 합니다. 스로틀링 제약이 매우 동적인 상황은 클라이언트가 반응할 수 있는 최신 서비스 정보를 전달하는 RateLimit field (Section 4)를 사용하는 것이 더 적합합니다. 적절한 경우 서버는 두 필드를 모두 전달할 수 있습니다.

할당량 정책 항목(Section 3.1) 목록은 [SF]의 Section 3.1에 설명된 대로 동일한 HTTP 응답 안에서 여러 "RateLimit-Policy" 필드에 나누어 실을 수 있습니다.

   RateLimit-Policy: "burst";q=100;w=60,"daily";q=1000;w=86400

3.1. 할당량 정책 항목

할당량 정책 Item은 정책의 식별자와 해당 정책에 대한 서버의 용량 배정 정보를 포함하는 Parameters[SF] 집합을 포함합니다.

다음 매개변수가 정의됩니다.

q:

필수(REQUIRED) "q" 매개변수는 이 정책이 할당한 할당량을 할당량 단위로 측정하여 나타냅니다.

qu:

선택적(OPTIONAL) "qu" 매개변수 값은 "q" 매개변수와 관련된 할당량 단위를 전달합니다. 기본 할당량 단위는 "requests"입니다.

w:

선택적(OPTIONAL) "w" 매개변수 값은 시간 윈도우를 전달합니다.

pk:

선택적(OPTIONAL) "pk" 매개변수 값은 해당 요청과 관련된 파티션 키를 전달합니다.

다른 매개변수도 허용되며 주석으로 간주될 수 있습니다.

구현별 또는 서비스별 매개변수는 벤더 식별자가 붙은 매개변수로 접두어를 붙이는 것이 좋습니다(SHOULD). 예: acme-policy, acme-burst.

이 필드는 트레일러 섹션에 나타나서는 안 됩니다(MUST NOT).

3.1.1. 할당량 매개변수

"q" 매개변수 값은 음수가 아닌 Integer이어야 합니다(MUST). 이 값은 주어진 할당량 파티션에 대한 클라이언트 활동(할당량 단위로 측정)에 할당된 할당량을 나타냅니다.

3.1.2. 할당량 단위 매개변수

"qu" 매개변수 값은 할당량(Section 3.1.1)에 적용되는 할당량 단위를 전달합니다. 값은 String이어야 합니다(MUST). 허용되는 값은 RateLimit 할당량 단위 레지스트리 (Section 10.3)에 나열되어 있습니다. 이 명세는 세 가지 할당량 단위를 정의합니다.

requests:

이 값은 할당량이 리소스 서버가 처리한 요청 수를 기반으로 함을 나타냅니다. 특정 요청이 실제로 할당량 단위를 소비하는지 여부는 구현별로 다릅니다.

content-bytes:

이 값은 할당량이 리소스 서버가 처리한 콘텐츠 바이트 수를 기반으로 함을 나타냅니다.

concurrent-requests:

이 값은 할당량이 리소스 서버가 처리한 동시 요청 수를 기반으로 함을 나타냅니다.

3.1.3. 윈도우 매개변수

"w" 매개변수 값은 할당량(Section 3.1.1)에 적용되는 시간 윈도우를 전달합니다. 시간 윈도우는 [HTTP]의 Section 10.2.3에 정의된 "delay-seconds" 규칙과 유사하게 초 단위 간격을 표현하는 음수가 아니고 0이 아닌 Integer 값이어야 합니다(MUST). 초 미만 정밀도는 지원되지 않습니다.

3.1.4. 파티션 키 매개변수

"pk" 매개변수 값은 요청과 관련된 파티션 키를 전달합니다. 값은 Byte Sequence이어야 합니다(MUST). 서버는 파티션 키를 사용하여 서버 용량을 서로 다른 클라이언트와 리소스에 나눌 수 있습니다(MAY). 할당량은 파티션 키별로 배정됩니다.

3.2. RateLimit 정책 필드 예

이 예에서 보듯이 이 필드는 할당량과 관련된 시간 윈도우를 전달할 수 있습니다(MAY).

   RateLimit-Policy: "default";q=100;w=10

다음 예는 여러 정책이 반환되는 모습을 보여줍니다.

   RateLimit-Policy: "permin";q=50;w=60,"perhr";q=1000;w=3600

다음 예는 파티션 키가 있는 정책을 보여줍니다.

   RateLimit-Policy: "peruser";q=100;w=60;pk=:cHsdsRa894==:

다음 예는 파티션 키와 할당량 단위가 있는 정책을 보여줍니다.

   RateLimit-Policy: "peruser";q=65535;qu="content-bytes";w=10;pk=:sdfjLJUOUH==:

4. RateLimit 필드

서버는 "RateLimit" 응답 헤더 필드를 사용하여 특정 파티션 키에 대한 할당량 정책의 현재 서비스 제한을 전달합니다.

이 필드는 서비스 제한 항목(Section 4.1)의 List[SF]로 표현됩니다.

서비스 제한 항목 목록은 [SF]의 Section 3.1에 설명된 대로 동일한 HTTP 응답 안에서 여러 "RateLimit" 필드에 나누어 실을 수 있습니다.

   RateLimit: "default";r=50;t=30

4.1. 서비스 제한 항목

각 서비스 제한 Item[SF]은 요청과 관련된 할당량 정책(Section 3.1)을 식별하며, 현재 서비스 제한에 대한 정보를 가진 Parameters[SF]를 포함합니다.

이 명세에서는 다음 매개변수를 정의합니다.

r:

이 필수(REQUIRED) 매개변수 값은 식별된 정책 아래에서 사용 가능한 할당량(Section 4.1.1)을 전달합니다.

t:

이 선택적(OPTIONAL) 매개변수 값은 식별된 정책 아래의 유효 윈도우, 즉 클라이언트가 사용 가능한 할당량을 초과하지 않고 사용할 수 있는 시간(Section 4.1.2)을 전달합니다.

pk:

선택적(OPTIONAL) "pk" 매개변수 값은 해당 요청과 관련된 파티션 키를 전달합니다.

이 필드는 트레일러 섹션에 나타나서는 안 됩니다(MUST NOT). 다른 매개변수도 허용되며 주석으로 간주될 수 있습니다.

구현별 또는 서비스별 매개변수는 벤더 식별자가 붙은 매개변수로 접두어를 붙이는 것이 좋습니다(SHOULD). 예: acme-policy, acme-burst.

4.1.1. 사용 가능한 할당량 매개변수

"r" 매개변수는 식별된 정책 아래에서 사용 가능한 할당량을 나타냅니다.

이는 할당량 단위로 표현되는 음수가 아닌 Integer입니다. 클라이언트는 양의 사용 가능한 할당량이 추가 요청이 처리될 것이라는 보장이라고 가정해서는 안 됩니다(MUST NOT). 사용 가능한 할당량이 낮으면 서버가 곧 클라이언트를 스로틀링할 수 있음을 나타냅니다 (Section 6 참조).

4.1.2. 유효 윈도우 매개변수

"t" 매개변수는 식별된 정책 아래의 유효 윈도우, 즉 클라이언트가 사용 가능한 할당량을 초과하지 않고 사용할 수 있는 초 단위 시간을 나타냅니다.

이는 delay-seconds 규칙과 호환되는 음수가 아닌 Integer입니다. 그 이유는 다음과 같습니다.

  • 클록 동기화에 의존하지 않으며, 클라이언트와 서버 사이의 클록 조정과 클록 스큐에 복원력을 가집니다([HTTP]의 Section 5.6.7 참조).

  • 너무 많은 클라이언트가 동일한 타임스탬프로 서비스될 때 발생하는 thundering herd와 관련된 위험을 완화합니다.

클라이언트는 유효 윈도우 매개변수로 표시된 시간이 지나면 자신의 모든 서비스 제한이 완전히 복구될 것이라고 가정해서는 안 됩니다(MUST NOT). 서버는 이후 요청 사이에 사용 가능한 할당량과 유효 윈도우를 임의로 변경할 수 있습니다(MAY). 예를 들어 리소스 포화의 경우나 슬라이딩 윈도우 정책을 구현하기 위해 그렇게 할 수 있습니다.

4.1.3. 파티션 키 매개변수

"pk" 매개변수 값은 요청과 관련된 파티션 키를 전달합니다. 값은 Byte Sequence이어야 합니다(MUST). 서버는 파티션 키를 사용하여 서버 용량을 서로 다른 클라이언트와 리소스에 나눌 수 있습니다(MAY). 할당량은 파티션 키별로 배정됩니다.

4.2. RateLimit 필드 예

이 예는 사용 가능한 할당량이 50단위이고 유효 윈도우가 30초인 RateLimit 필드를 보여줍니다.

   RateLimit: "default";r=50;t=30

이 예는 시간 윈도우가 없는 파티션 키에 대해 사용 가능한 할당량이 999개 요청임을 보여줍니다.

   RateLimit: "default";r=999;pk=:dHJpYWwxMjEzMjM=:

이 예는 다음 60초 동안 애플리케이션에 대해 사용 가능한 300MB 할당량을 보여줍니다.

   RateLimit: "default";r=300000000;t=60;pk=:QXBwLTk5OQ==:

5. 문제 유형

5.1. 할당량 초과

이 섹션은 "https://iana.org/assignments/http-problem-types#quota-exceeded" 문제 유형을 정의합니다. 서버는 클라이언트가 보낸 요청이 하나 이상의 할당량 정책을 초과했음을 클라이언트에게 전달하려는 경우 이 문제 유형을 사용할 수 있습니다(MAY). 이 문제 유형은 확장 멤버 "violated-policies"를 문자열 배열로 정의하며, 그 값은 할당량이 초과된 정책의 이름입니다.

HTTP/1.1 429 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#quota-exceeded",
  "title": "Request cannot be satisfied as assigned quota has been exceeded",
  "violated-policies": ["daily","bandwidth"]
}

5.2. 일시적으로 감소한 용량

이 섹션은 "https://iana.org/assignments/http-problem-types#temporary-reduced-capacity" 문제 유형을 정의합니다. 서버는 서버 용량의 일시적 감소로 인해 클라이언트의 요청이 현재 충족될 수 없음을 전달하려는 경우 이 문제 유형을 사용할 수 있습니다(MAY). 서버는 새롭게 일시적으로 낮아진 할당량을 나타내는 RateLimit-Policy 필드를 포함하도록 선택할 수 있습니다(MAY). 이 문제 유형은 확장 멤버 "violated-policies"를 문자열 배열로 정의하며, 그 값은 할당량이 초과된 정책의 이름입니다.

HTTP/1.1 503 Server Unavailable
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#temporary-reduced-capacity",
  "title": "Request cannot be satisfied due to temporary server capacity constraints",
  "violated-policies": ["hourly"]
}

5.3. 비정상적 사용 감지됨

이 섹션은 "https://iana.org/assignments/http-problem-types#abnormal-usage-detected" 문제 유형을 정의합니다. 서버는 클라이언트 측의 의도치 않은 또는 악의적인 동작을 시사하는 요청 패턴을 감지했음을 클라이언트에게 전달하기 위해 이 문제 유형을 사용할 수 있습니다(MAY). 이 문제 유형은 확장 멤버 "violated-policies"를 문자열 배열로 정의하며, 그 값은 할당량이 초과된 정책의 이름입니다.

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#abnormal-usage-detected",
  "title": "Request not satisifed due to detection of abnormal request pattern",
  "violated-policies": ["hourly"]
}

6. 서버 동작

서버는 응답 상태 코드와 독립적으로 RateLimit 헤더 필드를 반환할 수 있습니다(MAY). 여기에는 스로틀된 응답도 포함됩니다. 이 문서는 RateLimit 헤더 필드 값과 반환된 상태 코드 사이의 어떤 상관관계도 요구하지 않습니다.

서버는 리디렉션 응답(즉, 3xx 상태 코드를 가진 응답)에서 RateLimit 헤더 필드를 반환할 때 주의해야 합니다. 사용 가능한 할당량이 낮으면 클라이언트가 요청을 발행하지 못하게 될 수 있기 때문입니다. 예를 들어 아래 RateLimit 헤더 필드가 주어지면 사용 가능한 할당량이 0이므로 클라이언트는 "Location" 헤더 필드([HTTP]의 Section 10.2.2 참조)를 따르기 전에 10초를 기다리기로 결정할 수 있습니다.

HTTP/1.1 301 Moved Permanently
Location: /foo/123
RateLimit: "problemPolicy";r=0;t=10

응답에 Retry-After와 RateLimit 헤더 필드가 모두 포함된 경우, Retry-After 필드 값은 유효 윈도우의 끝보다 이른 시점을 참조하지 않는 것이 좋습니다(SHOULD NOT).

RateLimit 헤더 필드를 사용하는 서비스는 원치 않는 요청량을 노출하는 값을 전달해서는 안 되며(MUST NOT), 사용 가능한 할당량과 유효 윈도우 값 사이의 비율에 상한을 두는 메커니즘을 구현하는 것이 좋습니다(SHOULD) (Section 8.5 참조). 이는 할당량 정책이 큰 시간 윈도우를 사용할 때 특히 중요합니다.

특정 조건에서 서버는 이후 요청 사이에 RateLimit 헤더 필드 값을 인위적으로 낮출 수 있습니다(MAY). 예를 들어 서비스 거부 공격에 대응하거나 리소스 포화가 있는 경우입니다.

6.1. 파티션 키 생성

서버는 서로 다른 소비자 또는 서로 다른 리소스에 할당된 할당량을 구분하는 파티션 키를 반환하도록 선택할 수 있습니다(MAY). 서버 용량을 파티셔닝하는 전략은 매우 다양하며, 사용자별, 애플리케이션별, HTTP 메서드별, 리소스별, 또는 이러한 값의 조합을 포함합니다. 서버는 클라이언트가 향후 요청에 대한 키 값을 예측하고 해당 요청을 실행하기에 충분한 할당량이 사용 가능한지 판단할 수 있도록 파티션 키가 생성되는 방식을 문서화하는 것이 좋습니다(SHOULD). 서버는 민감한 정보를 포함하는 파티션 키를 반환하지 않아야 합니다. 서버는 파티션 키를 생성할 때 요청에 존재하는 정보만 사용하는 것이 좋습니다(SHOULD).

6.2. 성능 고려 사항

서버는 모든 응답에서 RateLimit 헤더 필드를 반환할 필요가 없으며, 클라이언트는 이를 고려해야 합니다. 예를 들어 성능을 우려하는 구현자는 주어진 할당량이 고갈에 가까울 때에만 RateLimit 헤더 필드를 제공할 수 있습니다.

응답 필드의 크기를 우려하는 구현자는 콘텐츠 길이에 대한 비율을 고려하거나, [HPACK]과 같은 헤더 압축 HTTP 기능을 사용할 수 있습니다.

7. 클라이언트 동작

RateLimit 헤더 필드는 관련 요청이 서버의 할당량 정책을 준수했는지 판단하고, 이후 요청이 성공할지 여부에 대한 표시로 클라이언트가 사용할 수 있습니다. 그러나 서버는 향후 요청을 처리할 때 다른 기준을 적용할 수 있으므로, 할당량 정책은 요청 성공 여부를 완전히 반영하지 않을 수 있습니다.

예를 들어 다음 필드를 가진 성공 응답은:

   RateLimit: "default";r=1;t=7

다음 요청이 성공한다는 것을 보장하지 않습니다. 서버의 동작은 다른 조건의 영향을 받을 수 있습니다.

클라이언트는 반환된 RateLimit 헤더 필드 값이 처리량과 지연 시간 측면에서 합리적인 클라이언트 동작을 유발하도록 보장할 책임이 있습니다 (Section 8.5Section 8.5.1 참조).

RateLimit 헤더 필드를 받은 클라이언트는 향후 응답에 동일한 RateLimit 헤더 필드가 포함되거나, 어떤 RateLimit 헤더 필드든 포함될 것이라고 가정해서는 안 됩니다(MUST NOT).

형식이 잘못된 RateLimit 헤더 필드는 무시되어야 합니다(MUST).

클라이언트는 유효 윈도우 매개변수에 표현된 시간 안에서 사용 가능한 할당량을 초과하지 않는 것이 좋습니다(SHOULD NOT).

유효 윈도우 매개변수의 값은 응답 시점에 생성됩니다. 상당한 네트워크 지연 시간을 알고 있는 클라이언트는 이에 맞게 동작하고 다른 정보(예: "Date" 응답 헤더 필드 또는 별도로 수집한 메트릭)를 사용하여 요청을 예약할 수 있습니다(MAY).

RateLimit-Policy 헤더 필드에 제공된 세부 정보는 정보 제공용이며 무시될 수 있습니다(MAY).

응답에 RateLimit 및 Retry-After 필드가 모두 포함된 경우, Retry-After 필드가 우선해야 하며(MUST) 유효 윈도우는 무시될 수 있습니다(MAY).

이 명세는 특정 스로틀링 동작을 요구하지 않으며, 구현자는 다음을 포함해 선호하는 정책을 채택할 수 있습니다.

7.1. 파티션 키 사용

단일 클라이언트가 서로 다른 할당량 배정을 소비하는 요청을 만들 가능성이 있는 경우 파티션 키는 클라이언트에게 유용합니다. 예를 들어 서로 다른 사용자 대신 요청을 만들거나 독립적인 할당량 배정을 가진 서로 다른 리소스에 대해 요청하는 클라이언트가 이에 해당합니다.

서버가 파티션 키 생성 알고리즘을 문서화한 경우, 클라이언트는 향후 요청에 대한 파티션 키를 생성할 수 있습니다(MAY). 이 키를 사용하고 서버가 반환한 키와 비교함으로써 클라이언트는 요청을 실행하기에 충분한 할당량이 사용 가능한지 판단할 수 있습니다.

서버의 파티션 키 생성 알고리즘을 알 수 없는 경우, 클라이언트는 이전 요청과의 유사성을 바탕으로 향후 요청이 성공할지 추측하기 위해 휴리스틱을 사용할 수 있습니다(MAY).

7.2. 중개자

이 섹션은 [HTTP]의 Section 16.3.2에서 권고된 고려 사항을 문서화합니다.

원 출처 서비스 인프라의 일부가 아니고 Origin Server가 사용하는 할당량 정책 의미를 알지 못하는 중개자는 더 관대한 할당량 정책을 전달하는 방식으로 RateLimit 헤더 필드 값을 변경하지 않는 것이 좋습니다(SHOULD NOT). 여기에는 RateLimit 헤더 필드를 제거하는 것도 포함됩니다.

중개자는 다음과 같은 경우 더 제한적인 할당량 정책을 전달하는 방식으로 RateLimit 헤더 필드를 변경할 수 있습니다(MAY).

  • Origin Server가 사용하는 할당량 단위 의미를 알고 있는 경우;

  • 이 명세를 구현하고 필드에 전달된 것보다 더 제한적인 할당량 정책을 적용하는 경우.

중개자는 요청이 처리되지 않을 수 있다고 추정하더라도 요청을 전달하는 것이 좋습니다(SHOULD). RateLimit 헤더 필드를 반환하는 서비스가 전달된 할당량 정책을 적용하는 유일한 책임 주체이며, 들어오는 요청을 처리하는 것은 항상 자유입니다.

이 명세는 재시도와 관련해 중개자에게 어떤 동작도 요구하지 않으며, 중개자가 할당량 정책을 존중하는 데 어떤 역할을 해야 한다고 요구하지도 않습니다. 예를 들어 프록시가 클라이언트에게 알리지 않고 요청을 재전송하여 할당량 단위를 소비하는 것은 적법합니다.

프라이버시 고려 사항 (Section 9)은 중개자에 대한 추가 지침을 제공합니다.

7.3. 캐싱

[HTTP-CACHING]은 RateLimit 헤더 필드를 가진 응답을 포함해 응답을 저장하고 이후 요청에 재사용할 수 있는 방법을 정의합니다. 캐시된 응답의 RateLimit 헤더 필드에 있는 정보는 최신이 아닐 수 있으므로, 캐시에서 온 응답(즉, positive current_age를 가진 응답; [HTTP-CACHING]의 Section 4.2.3 참조)에서는 이를 무시하는 것이 좋습니다(SHOULD).

8. 보안 고려 사항

8.1. 스로틀링은 클라이언트가 요청을 발행하는 것을 막지 않습니다

이 명세는 클라이언트가 요청을 만드는 것을 막지 않습니다. 서버는 항상 리소스 고갈을 방지하는 메커니즘을 구현해야 합니다.

8.2. 정보 공개

서버는 자신의 인프라 리소스를 포화시키는 데 사용될 수 있는 운영 용량 정보를 신뢰할 수 없는 당사자에게 공개하지 않아야 합니다.

이 명세는 성공하지 않은 응답이 할당량을 소비하는지 여부를 요구하지 않지만, 오류 응답(예: 401 (Unauthorized) 및 403 (Forbidden))이 할당량에 포함된다면, 악의적인 클라이언트가 엔드포인트를 탐색하여 다른 사용자의 트래픽 정보를 얻을 수 있습니다.

중개자가 사용자 에이전트의 사전 인지 없이 요청을 재전송하고 할당량 단위를 소비할 수 있으므로, RateLimit 헤더 필드는 사용자 에이전트에게 중개자의 존재를 드러낼 수 있습니다.

파티션 키가 클라이언트 애플리케이션 또는 사용자의 식별 정보를 포함하는 경우, 서버는 가장 가능성을 인식하고 적절한 보안 메커니즘을 적용해야 합니다.

8.3. 사용 가능한 할당량 단위는 요청 허가가 아닙니다

RateLimit 헤더 필드는 클라이언트가 스로틀링으로 배제되는 것을 피하도록 돕기 위해 서버에서 클라이언트로 힌트를 전달합니다.

클라이언트는 사용 가능한 할당량 매개변수 (Section 4.1.1)를 서비스 수준 계약으로 간주해서는 안 됩니다(MUST NOT).

리소스 포화의 경우 서버는 반환된 값을 인위적으로 낮추거나 알린 할당량과 관계없이 요청을 처리하지 않을 수 있습니다(MAY).

8.4. 유효 윈도우의 변동성

유효 윈도우 매개변수 (Section 4.1.2)는 서버가 언제 사용 가능한 할당량을 늘릴지에 대해 어떤 것도 의미하지 않습니다. 유효 윈도우가 반드시 고정된 시점에 끝나는 것은 아닙니다.

이후 요청은 동시성을 제한하거나 동적 또는 적응형 스로틀링 정책을 구현하기 위해 더 높은 유효 윈도우 값을 반환할 수 있습니다.

8.5. 리소스 고갈

유효 윈도우 값을 반환할 때 서버는 많은 스로틀된 클라이언트가 지정된 바로 그 순간에 다시 돌아올 수 있음을 인지해야 합니다.

이는 Retry-After에도 해당됩니다.

예를 들어 할당량이 매일 18:00:00에 재설정되고 서버가 이에 맞춰 유효 윈도우를 반환한다면

   Date: Tue, 15 Nov 1994 18:00:00 GMT
   RateLimit: "daily";r=1;t=86400

모든 클라이언트가 18:00:00에 나타날 가능성이 높습니다.

이는 유효 윈도우에 약간의 지터를 추가하여 완화할 수 있습니다.

리소스 고갈 문제는 큰 시간 윈도우를 사용하는 할당량 정책과 관련될 수 있습니다. 사용자 에이전트가 우연히 또는 의도적으로 훨씬 짧은 간격 안에서 자신의 할당량 단위 대부분을 소비할 수 있기 때문입니다.

이러한 동작은 제공된 RateLimit 헤더 필드에 의해 유발될 수도 있습니다. 다음 예는 1000초당 10000 할당량 단위의 미소비 할당량 정책을 가진 서비스를 설명합니다.

RateLimit-Policy: "somepolicy";q=10000;w=1000
RateLimit: "somepolicy";r=10000;t=10

사용 가능한 할당량과 유효 윈도우 사이의 단순 비율을 구현하는 클라이언트는 평균 처리량을 초당 1000 할당량 단위로 추론할 수 있는 반면, 정책의 할당량 및 윈도우 매개변수는 초당 평균 10 할당량 단위를 전달합니다. 서비스가 이러한 부하를 처리할 수 없다면 더 낮은 사용 가능한 할당량이나 더 높은 유효 윈도우를 반환해야 합니다. 또한 큰 시간 윈도우 할당량 정책에 짧은 시간 윈도우 정책을 보완하면 이러한 위험을 완화합니다.

8.5.1. 서비스 거부

RateLimit 헤더 필드는 우연히 또는 의도적으로 예상치 못한 값을 포함할 수 있습니다. 예를 들어 과도하게 높은 사용 가능한 할당량은 다음과 같이 사용될 수 있습니다.

  • 악의적인 중개자가 서비스 거부 공격을 유발하거나 요청을 늘려 클라이언트 리소스를 소비하는 데 사용될 수 있음;

  • 잘못 구성된 서버에 의해 전달될 수 있음;

또는 큰 유효 윈도우는 클라이언트가 서버에 접촉하는 것을 억제할 수 있습니다(예: "Retry-after: 1000000"을 받는 것과 유사하게).

이 위험을 완화하기 위해 클라이언트는 할당량 단위, 시간 윈도우, 동시 요청 또는 처리량 측면에서 합리적이라고 판단하는 임계값을 설정하고, RateLimit가 그 임계값을 초과할 때 일관된 동작을 정의할 수 있습니다. 예를 들어 이는 초당 최대 요청 수를 제한하거나, 유효 윈도우가 10분을 초과할 때 재시도를 구현하는 것을 의미합니다.

위 고려 사항은 RateLimit 헤더 필드에만 국한되지 않고, 클라이언트가 이후 요청에서 어떻게 동작하는지에 영향을 주는 모든 필드(예: Retry-After)에 적용됩니다.

9. 프라이버시 고려 사항

속도 제한 요청에 따라 동작하는 클라이언트는 잠재적으로 재식별될 수 있습니다([PRIVACY]의 Section 5.2.1 참조). 이는 오직 자신에게만 주어졌을 수 있는 정보에 반응하기 때문입니다. 이것이 다른 필드에도 적용될 수 있음에 유의하십시오(예: Retry-After).

속도 제한은 보통 클라이언트가 식별되거나 프로파일링되는 맥락에서 구현되기 때문에 (예: 서로 다른 사용자에게 서로 다른 할당량 단위를 배정), 이는 거의 문제가 되지 않습니다.

RateLimit 헤더 필드를 사용하는 프라이버시 강화 인프라는 재식별 위험을 완화하기 위한 특정 기법을 정의할 수 있습니다.

10. IANA 고려 사항

IANA는 두 개의 레지스트리를 갱신하고 하나의 새 레지스트리를 만들도록 요청받습니다.

10.1. HTTP 필드 이름 레지스트리 갱신

"Hypertext Transfer Protocol (HTTP) Field Name Registry" 레지스트리 ([HTTP])에 다음 항목을 추가하십시오.

표 1
필드 이름 구조화된 유형 상태 명세
RateLimit List 영구 RFC nnnn의 Section 4
RateLimit-Policy List 영구 RFC nnnn의 Section 3

10.2. HTTP 문제 유형 레지스트리 갱신

IANA는 https://www.iana.org/assignments/http-problem-types의 "HTTP Problem Types" 레지스트리에 다음 항목을 등록하도록 요청받습니다.

10.2.1. "quota-exceeded" 문제 유형 등록

유형 URI: https://iana.org/assignments/http-problem-types#quota-exceeded

제목: 할당량 초과

권장 HTTP 상태 코드: 429

참조: 이 문서의 Section 5.1

10.2.2. "temporary-reduced-capacity" 문제 유형 등록

유형 URI: https://iana.org/assignments/http-problem-types#temporary-reduced-capacity

제목: 일시적으로 감소한 용량

권장 HTTP 상태 코드: 503

참조: 이 문서의 Section 5.2

10.2.3. "abnormal-usage-detected" 문제 유형 등록

유형 URI: https://iana.org/assignments/http-problem-types#abnormal-usage-detected

제목: 비정상적 사용 감지됨

권장 HTTP 상태 코드: 429

참조: 이 문서의 Section 5.3

10.3. RateLimit 할당량 단위 레지스트리

이 명세는 https://www.iana.org/assignments/http-ratelimit-quota-units에 위치할 레지스트리 "Hypertext Transfer Protocol (HTTP) RateLimit Quota Units"를 수립합니다. 등록은 IESG 또는 그 위임자가 임명한 지정 전문가의 조언에 따라 이루어집니다. 모든 항목은 Specification Required입니다([IANA], Section 4.6).

레지스트리의 초기 내용은 다음과 같습니다.

표 2
할당량 단위 참조 참고
request RFC nnnn
content-bytes RFC nnnn
concurrent-requests RFC nnnn

10.3.1. 등록 템플릿

RateLimit 할당량 단위 레지스트리의 등록 템플릿은 다음과 같습니다.

  • 할당량 단위: 할당량 단위의 이름입니다.

  • 참조: 할당량 단위를 지정하는 문서에 대한 참조입니다.

  • 참고: 할당량 단위에 대한 추가 참고 사항입니다.

11. 참고문헌

11.1. 규범 참고문헌

[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[IANA]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[PROBLEM]
Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, , <https://www.rfc-editor.org/rfc/rfc9457>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[SF]
Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, , <https://www.rfc-editor.org/rfc/rfc9651>.
[WEB-ORIGIN]
Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, , <https://www.rfc-editor.org/rfc/rfc6454>.

11.2. 정보 참고문헌

[HPACK]
Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, , <https://www.rfc-editor.org/rfc/rfc7541>.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, , <https://www.rfc-editor.org/rfc/rfc9111>.
[PRIVACY]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <https://www.rfc-editor.org/rfc/rfc6973>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/rfc/rfc3339>.
[RFC6585]
Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, , <https://www.rfc-editor.org/rfc/rfc6585>.
[UNIX]
The Open Group, "The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98", .

부록 A. 속도 제한과 할당량

서버는 시스템 과부하를 피하고, 계산 리소스의 공정한 배분을 보장하거나, 다른 정책(예: 수익화)을 적용하기 위해 할당량 메커니즘을 사용합니다.

기본 할당량 메커니즘은 주어진 시간 윈도우에서 허용 가능한 요청 수를 제한합니다. 예: 초당 10개 요청.

할당량이 초과되면 서버는 보통 요청을 처리하지 않고 대신 4xx HTTP 상태 코드(예: 429 또는 403)로 응답하거나, 연결을 끊는 것과 같은 더 공격적인 정책을 채택합니다.

할당량은 서로 다른 기준(예: 사용자별, IP별, 지리적 영역별 등)과 서로 다른 수준에서 적용될 수 있습니다. 예를 들어 사용자는 다음을 발행하도록 허용될 수 있습니다.

또한 시스템 메트릭, 통계 및 휴리스틱을 사용하여 허용 가능한 요청 수와 시간 윈도우가 동적으로 계산되는 더 복잡한 정책을 구현할 수 있습니다.

클라이언트가 자신의 요청을 스로틀링하도록 돕기 위해, 서버는 HTTP 헤더 필드를 통해 할당량 정책을 평가하는 데 사용되는 카운터를 노출할 수 있습니다.

이러한 응답 헤더는 API 게이트웨이와 리버스 프록시 같은 HTTP 중개자에 의해 추가될 수 있습니다.

웹에서는 다양한 속도 제한 헤더를 찾을 수 있으며, 보통 주어진 시간 윈도우에서 허용된 요청 수와 윈도우가 재설정되는 시점을 포함합니다.

일반적인 선택은 다음을 포함하는 세 개의 헤더를 반환하는 것입니다.

A.1. 상호운용성 문제

스로틀링의 주요 상호운용성 문제는 표준 헤더의 부재입니다. 그 이유는 다음과 같습니다.

  • 각 구현이 동일한 헤더 필드 이름에 서로 다른 의미를 연결함;

  • 헤더 필드 이름이 난립함.

서로 다른 서버와 인터페이스하는 사용자 에이전트는 따라서 서로 다른 헤더를 처리해야 할 수 있으며, 서로 다른 리버스 프록시 뒤에 있는 동일한 애플리케이션 인터페이스가 서로 다른 스로틀링 헤더로 응답할 수도 있습니다.

부록 B.

B.1. 정책을 정의하지 않은 응답

일부 서버는 RateLimit-Policy 헤더 필드에 정책 제한을 노출하지 않을 수 있습니다. 클라이언트는 여전히 RateLimit 헤더 필드를 사용해 자신의 요청을 스로틀링할 수 있습니다.

B.1.1. 응답의 스로틀링 정보

클라이언트는 다음 50초 동안의 할당량을 모두 사용했습니다. 제한과 시간 윈도우는 대역 외로 전달됩니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "default";r=0;t=50

{"hello": "world"}

필드 값은 반드시 응답 상태 코드와 상관관계가 있는 것은 아니므로, 이후 요청이 반드시 실패해야 하는 것은 아닙니다. 아래 예는 사용 가능한 할당량이 0이어도 서버가 요청을 처리하기로 결정했음을 보여줍니다. 다른 서버 또는 다른 부하 조건 아래의 동일한 서버는 대신 요청을 스로틀링하기로 결정했을 수 있습니다.

요청:

GET /items/456 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "default";r=0;t=48

{"still": "successful"}

B.1.2. 응답의 여러 정책

서버는 클라이언트의 요청을 제한하기 위해 두 가지 서로 다른 정책을 사용합니다.

  • 일일 5000 할당량 단위;

  • 시간당 1000 할당량 단위.

클라이언트는 첫 14시간 동안 4900 할당량 단위를 소비했습니다.

다음 시간당 제한이 1000 할당량 단위임에도, 도달하기 가장 가까운 제한은 일일 제한입니다.

그런 다음 서버는 클라이언트에게 다음을 알리기 위해 RateLimit 헤더 필드를 노출합니다.

  • 일일 할당량에는 100 할당량 단위만 남아 있으며 윈도우는 10시간 후에 끝납니다;

서버는 시간당 정책이 일일 정책과 동일한 할당량 단위를 사용하고 일일 정책이 고갈에 가장 가까운 정책이므로, 시간당 정책을 반환하지 않도록 선택할 수 있습니다(MAY).

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "dayLimit";r=100;t=36000

{"hello": "world"}

B.1.3. 동시성 제한에 사용

RateLimit 헤더 필드는 동시성을 제한하는 데 사용될 수 있으며, 포화 상태에서는 평소보다 낮은 제한을 알림으로써 가용성을 높일 수 있습니다.

서버는 분당 100 할당량 단위의 기본 정책을 채택했고, 리소스 고갈 시 반환되는 값을 조정하여 사용 가능한 할당량과 유효 윈도우 값을 모두 줄입니다.

2초 후 클라이언트는 40 할당량 단위를 소비했습니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "basic";q=100;w=60
RateLimit: "basic";r=60;t=58

{"elapsed": 2, "issued": 40}

이후 요청에서 리소스 고갈 때문에 서버는 r=20만 알립니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "basic";q=100;w=60
RateLimit: "basic";r=20;t=56

{"elapsed": 4, "issued": 41}

B.1.4. 스로틀된 응답에서 사용

클라이언트가 할당량을 모두 사용했고 서버가 Retry-After를 보내며 이를 스로틀링합니다.

이 예에서는 Retry-After와 RateLimit 헤더 필드의 값이 동일한 순간을 참조하지만, 이것이 요구 사항은 아닙니다.

429 (Too Many Request) HTTP 상태 코드는 단지 예로 사용되었습니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Date: Mon, 05 Aug 2019 09:27:00 GMT
Retry-After: Mon, 05 Aug 2019 09:27:05 GMT
RateLimit: "default";r=0;t=5

{
"type": "https://iana.org/assignments/http-problem-types#quota-exceeded"
"title": "Too Many Requests",
"status": 429,
"violated-policies": ["default"]
}

B.2. 정의된 정책이 있는 응답

B.2.1. 매개변수로 지정된 스로틀링 윈도우

클라이언트는 다음 50초 동안 99 할당량 단위가 남아 있습니다. 시간 윈도우는 w 매개변수로 전달되므로 처리량이 분당 100 할당량 단위임을 알 수 있습니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "fixedwindow";r=99;t=50
RateLimit-Policy: "fixedwindow";q=100;w=60
{"hello": "world"}

B.2.2. 매개변수화된 윈도우가 있는 동적 제한

RateLimit-Policy 헤더 필드가 전달한 정책은 서버가 분당 100 할당량 단위를 허용한다고 명시합니다.

리소스 고갈을 피하기 위해 서버는 스로틀링 헤더에 반환되는 실제 제한을 인위적으로 낮춥니다.

그런 다음 RateLimit 헤더 필드는 클라이언트를 늦추기 위해 다음 50초 동안 9 할당량 단위만 알립니다.

서버는 RateLimit 헤더 필드의 다른 값도 낮출 수 있었음에 유의하십시오. 이 명세는 이후 응답에 포함된 필드 값 사이의 어떤 관계도 요구하지 않습니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "dynamic";q=100;w=60
RateLimit: "dynamic";r=9;t=50


{
  "status": 200,
  "detail": "Just slow down without waiting."
}

B.2.3. 밀어내고 속도를 늦추기 위한 동적 제한

이전 예를 계속해서, 클라이언트가 10초를 기다린 후 새 요청을 수행했는데, 리소스 고갈 때문에 서버가 이를 거부하고 밀어내며 다음 20초 동안 r=0을 알린다고 가정해 보겠습니다.

서버는 20초가 지난 뒤 원래 윈도우의 나머지 시간 동안 클라이언트의 속도를 늦추기 위해 더 작은 윈도우와 더 낮은 제한을 알립니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
RateLimit-Policy: "dynamic";q=15;w=20
RateLimit: "dynamic";r=0;t=20

{
  "status": 429,
  "detail": "Wait 20 seconds, then slow down!"
}

B.3. Retry-After와 속도 저하를 사용해 밀어내기 위한 동적 제한

또는 이전 예가 시작되는 동일한 맥락에서, Retry-After를 통해 클라이언트에게 동일한 정보를 전달할 수 있습니다. 이 경우 서버는 재시도 시간이 지난 뒤 적용될 정책의 명목상 제한과 윈도우를 지정할 수 있다는 장점이 있습니다. 예를 들어 그때쯤에는 리소스 고갈이 사라질 가능성이 높다고 가정하면, 알리는 정책을 조정할 필요가 없으면서도 잠시 요청을 멈추고 현재 윈도우의 나머지 시간 동안 속도를 늦추는 데 성공한 것입니다.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 20
RateLimit-Policy: "dynamic";q=100;w=60
RateLimit: "dynamic";r=15;t=40

{
  "status": 429,
  "detail": "Wait 20 seconds, then slow down!"
}

이 마지막 응답에서 클라이언트는 Retry-After를 준수하고 지정된 시간 동안 아무 요청도 수행하지 않을 것으로 기대됩니다. 반면 이전 예는 유효 윈도우가 끝나기 전까지 클라이언트가 요청을 중단하도록 강제하지 않았습니다. 요청이 거부될 가능성이 높더라도 클라이언트는 여전히 서버에 다시 질의할 자유가 있기 때문입니다.

B.3.1. 여러 윈도우와 함께 사용

이는 부록 B.1.2에 상세히 설명된 정책을 표현하는 표준화된 방식입니다.

  • 일일 5000 할당량 단위;

  • 시간당 1000 할당량 단위.

클라이언트는 첫 14시간 동안 4900 할당량 단위를 소비했습니다.

다음 시간당 제한이 1000 할당량 단위임에도, 도달하기 가장 가까운 제한은 일일 제한입니다.

그런 다음 서버는 클라이언트에게 다음을 알리기 위해 RateLimit 헤더 필드를 노출합니다.

  • 100 할당량 단위만 남아 있음;

  • 유효 윈도우는 10시간임;

  • expiring-limit는 5000임.

요청:

GET /items/123 HTTP/1.1
Host: api.example

응답:

HTTP/1.1 200 OK
Content-Type: application/json
RateLimit-Policy: "hour";q=1000;w=3600, "day";q=5000;w=86400
RateLimit: "day";r=100;t=36000

{"hello": "world"}

FAQ

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  1. 스로틀링을 위한 표준 필드를 왜 정의하나요?

    스로틀링 정책의 적용을 단순화하고 클라이언트가 스로틀링을 피하기 위해 자신의 요청을 제한할 수 있게 하기 위해서입니다.

  2. 스로틀된 응답(예: 상태 코드 429)에서 RateLimit 헤더 필드를 사용할 수 있나요?

    예, 사용할 수 있습니다.

  3. 이 명세는 RFC 6585에 묶여 있나요?

    아닙니다. [RFC6585]429 상태 코드를 정의하며, 우리는 이를 스로틀된 요청의 예로 사용할 뿐입니다. 대신 403이나 어떤 상태 코드든 사용할 수 있습니다.

  4. 파티션 키가 왜 필요한가요?

    파티션 키가 없으면 서버는 사실상 하나의 범위(즉, 파티션)만 가질 수 있는데, 이는 대부분의 서비스에 비실용적입니다. 또는 서버가 범위를 대역 외로 전달해야 합니다. 이는 요청이 스로틀링되는 것을 방지하는 데 사용할 수 있는 범용 커넥터 코드의 개발을 막습니다. 많은 API는 할당량을 배정하기 위해 API 키, 사용자 ID 또는 클라이언트 ID에 의존합니다. 단일 클라이언트가 둘 이상의 파티션에 대한 요청을 처리하기 시작하는 즉시, 클라이언트는 배정된 할당량에 대해 요청을 제대로 추적하기 위해 해당 파티션 키를 알아야 합니다.

  5. UNIX Timestamp 대신 delay-seconds를 사용하는 이유는 무엇인가요? 초 미만 정밀도를 사용하지 않는 이유는 무엇인가요?

    delay-seconds를 사용하면 429 응답과 같은 유사한 맥락에서 반환되는 Retry-After와 정렬됩니다.

    타임스탬프는 클록 동기화 프로토콜이 필요합니다 ([HTTP]의 Section 5.6.7 참조). 이는 문제가 될 수 있습니다(예: 클록 조정, 클록 스큐, 하드코딩된 클록 동기화 서버의 장애, IoT 기기 등). 또한 타임스탬프는 클록 조정 때문에 단조 증가하지 않을 수 있습니다. Another NTP client failure story를 참조하십시오.

    초 미만 정밀도를 사용하지 않은 이유는 다음과 같습니다.

    • adjtime() Linux 시스템 호출을 통해 구현되는 것과 같은 시스템 클록 보정의 영향을 더 많이 받습니다;

    • 응답 시간 지연 때문에 그만한 가치가 없을 수 있습니다. 이 주제에 대한 간단한 논의는 httpwg ml에 있습니다.

    • 거의 모든 속도 제한 헤더 구현이 이를 사용하지 않습니다.

  6. 요청 속도 대신 동시성을 제한해야 하지 않나요?

    이 명세를 사용하여 HTTP 수준에서 동시성을 제한하고 ({#use-for-limiting-concurrency} 참조), 클라이언트가 스로틀링으로 배제되지 않도록 자신의 요청을 구성하는 데 도움을 줄 수 있습니다.

    동시성을 제한하는 문제가 있는 방식은 연결을 끊는 것입니다. 특히 연결이 다중화되어 있을 때(예: HTTP/2) 이는 클라이언트 요청이 처리되지 않는 결과를 낳는데, 이것은 우리가 피하고자 하는 것입니다.

    동시성을 제한하는 의미론적 방식은 리소스 포화(예: 스래싱, 너무 긴 연결 큐, Service Level Objectives 미충족 등)의 경우 503 + Retry-After를 반환하는 것입니다. 포화 조건은 동적일 수도 정적일 수도 있습니다. 이 모든 것은 현재 문서의 범위를 벗어납니다.

  7. remaining 매개변수의 양의 값이 향후 요청이 처리될 것이라는 어떤 서비스 보장을 의미하나요?

    아니요. FAQ는 Section 4.1.1에 통합되었습니다.

  8. quota-policy 정의가 너무 복잡한가요?

    언제든지 가장 단순한 형태를 반환할 수 있습니다.

RateLimit:"default";r=50;t=60

정책 키는 정책의 현재 사용 상태를 정의된 제한과 명확히 연결합니다. 따라서 다음 필드의 경우:

RateLimit-Policy: "sliding";q=100;w=60;burst=1000
RateLimit-Policy: "fixed";q=5000;w=3600;burst=0
RateLimit: "sliding";r=50;t=44

값 "sliding"은 보고되는 정책을 식별합니다.

  1. 중개자가 RateLimit 헤더 필드를 변경할 수 있나요?

    일반적으로 변경하지 않아야 합니다. 요청이 처리되지 않는 결과를 낳을 수 있기 때문입니다. 그러나 중개자가 RateLimit 헤더 필드를 조작하는 합리적인 사용 사례도 있습니다. 예를 들어 더 엄격한 할당량 정책을 적용하거나, 서비스의 능동 구성 요소인 경우입니다. 이러한 경우 우리는 그것들을 원 출처 인프라의 일부로 간주합니다.

  2. w 매개변수가 단지 정보 제공용인 이유는 무엇인가요? 클라이언트가 요청 속도를 판단하는 데 사용할 수 있나요?

    클라이언트와 서버가 밀접하게 결합된 환경에서는 정보 제공용이 아닌 w 매개변수가 괜찮을 수 있습니다. 이 정도의 세부 사항으로 정책을 대규모로 전달하는 것은 매우 복잡하며 구현은 상호운용되지 않을 가능성이 큽니다. 따라서 우리는 w를 정보 제공용 매개변수로 남겨두고, 스로틀링 동작을 정의하는 데 limit, remaining 및 reset 매개변수에만 의존하기로 결정했습니다.

  3. 트레일러에서 RateLimit 필드를 사용할 수 있나요? 서버는 보통 응답을 생성하기 전에 요청이 할당량 내에 있는지 결정하므로, RateLimit 필드 값은 그 시점에 이미 사용 가능해야 합니다. 트레일러를 지원하는 유일한 장점은 느린 응답의 경우 클라이언트에게 더 최신 정보를 제공할 수 있다는 것입니다. 그러나 이는 헤더와 트레일러의 필드를 결합하고 트레일러를 삭제하는 중개자를 고려해야 한다는 점에서 클라이언트 구현을 복잡하게 합니다. 현재 트레일러를 사용하는 구현이 없으므로, 우리는 이를 향후 작업으로 남기기로 결정했습니다.

현재 웹에서 사용되는 RateLimit 헤더 필드

이 섹션은 RFC로 게시되기 전에 제거됩니다.

일반적으로 사용되는 헤더 필드 이름은 다음과 같습니다.

헤더 필드 이름에 윈도우가 지정되는 변형도 있습니다. 예:

다음은 몇 가지 상호운용성 문제입니다.

RateLimit의 의미는 윈도잉 알고리즘에 따라 달라집니다. 예를 들어 슬라이딩 윈도우 정책은 남은 매개변수 값이 현재 처리량과 최대 처리량 사이의 비율과 관련되도록 만들 수 있습니다. 예:

RateLimit-Policy: "sliding";q=12;w=1
; using 50% of throughput, that is 6 units/s
RateLimit: "sliding";q=12;r=6;t=1

이 경우 최적의 해결책은 다음에 도달하는 것입니다.

RateLimit-Policy: "sliding";q=12;w=1
; using 100% of throughput, that is 12 units/s
RateLimit: "sliding";q=12;r=1;t=1

이 시점에서 요청 속도를 늘리는 것을 멈춰야 합니다.

감사의 말

이 명세의 초기 기여자인 Willi Schoenborn, Alejandro Martinez Ruiz, Alessandro Ranellucci, Amos Jeffries, Martin Thomson, Erik Wilde 및 Mark Nottingham에게 감사드립니다. 첫 커뮤니티 구현자인 Aapo Talvensaari, Nathan Friedly 및 Sanyam Dogra에게도 찬사를 보냅니다.

위의 사람들 외에도 이 문서는 Rich Salz와 Julian Reschke를 포함한 HTTPAPI 작업 그룹의 광범위한 논의에 크게 빚지고 있습니다.

변경 사항

이 섹션은 RFC로 게시되기 전에 제거됩니다.

draft-ietf-httpapi-ratelimit-headers-08 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • 문제 유형 추가

  • RateLimit-Policy와 RateLimit 필드를 언제 사용하는지 명확히 함

draft-ietf-httpapi-ratelimit-headers-07 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • 정책을 식별하고 매개변수를 사용하는 Items의 목록으로 두 필드를 모두 리팩터링함

  • 할당량 단위 매개변수 추가

  • 파티션 키 매개변수 추가

draft-ietf-httpapi-ratelimit-headers-03 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • RateLimit-Policy #81에서 정책 정보를 분리함

draft-ietf-httpapi-ratelimit-headers-02 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • 스로틀링 범위 #83 처리

draft-ietf-httpapi-ratelimit-headers-01 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • IANA 고려 사항 #60 갱신

  • Structured fields #58 사용

  • 문서 #67 재구성

draft-ietf-httpapi-ratelimit-headers-00 이후

이 섹션은 RFC로 게시되기 전에 제거됩니다.

  • delta-seconds 대신 delay-seconds를 참조하는 I-D.httpbis-semantics 사용. #5

저자 주소

Roberto Polli
Team Digitale, 이탈리아 정부
이탈리아
Alejandro Martinez Ruiz
Red Hat
Darrel Miller
Microsoft