Library / Documentation

RFC 9114: HTTP/3

The standard that defines HTTP semantics over QUIC.

AdvancedHTTP and QUIC

By IETF · IETF · Added 2026-10-12

Open the docs

All content belongs to IETF. We only link to it and give credit. Report a problem

Learn this doc

About 30 min left. Your work is saved as you go.

What you want from these docs

IETF documents a tool you may use. Decide what you want to do with it, then read only what answers that.

Ideas you will meet

HTTP and QUIC: HTTP versions, QUIC, caching headers and web performance.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

Classic System Designs · 12 minDesign a rate limiterCap how often a client can call an API: the common algorithms, where to put the limiter and how to make it work across many servers.Read here

The problem

A rate limiter restricts how many requests a client may make in a period. It protects a service from abuse, accidental floods and runaway scripts, keeps costs predictable and shares capacity fairly.

Requirements

Limit by user, API key or IP, with different limits per rule or plan.
Add very little latency to each request.
Work across many servers, not just one.
Tell rejected clients clearly what happened.
If the limiter itself fails, the API should not go down with it.

Heavy traffic on a road: without limits, demand beyond capacity makes everyone slower Image: Digitura · CC0 · Source · Wikimedia Commons: Gulf, traffic jam 1970s

Where to put it

Figure SDA-CSD-01-1 · Rate limiter in front of the service · © forcsguy.com

The usual home is the API gateway or a middleware layer, because it sees every request early and rejects cheaply. Building it into each service duplicates effort, and a client-side limiter cannot be trusted.

Here is the same service without a limiter, and with one in front. Switch on Simulate and raise the traffic to see what each version does when a script floods it.

Before: Nothing in front

After: Limiter at the gateway

What changed

The abusive client is stopped at the gateway, not at the service
Counters sit in one shared store, so every server sees the same count
Blocked requests cost almost nothing to answer

Algorithms

Algorithm	Idea	Good	Bad
Token bucket	A bucket refills at a steady rate; each request takes a token	Allows bursts, tiny memory	Two numbers to tune
Leaky bucket	Requests join a queue processed at a fixed rate	Smooth output rate	Bursts fill the queue, old requests delayed
Fixed window counter	Count per minute, reset at the boundary	Simplest	Burst across a boundary doubles the limit
Sliding window log	Keep a timestamp per request, count those within the window	Exact	Memory per request
Sliding window counter	Weight the previous window's count by overlap	Cheap and close to exact	Approximate

Token bucket is a strong default: it is cheap, and bursts are usually fine for real clients. The sliding window counter is a good choice when you need smoother accuracy.

Token bucket in a few lines

For each key store (tokens, last_refill_time). On a request:

Add elapsed x refill_rate tokens, up to the bucket size.
If at least one token is available, take it and allow the request.
Otherwise reject.

The algorithms in pictures

Token bucket. Tokens drip into a bucket of fixed size; every request must take one.

Figure SDA-CSD-01-2 · Token bucket decision · © forcsguy.com

A walk through time (bucket of 4, refilled to full each minute):

Figure SDA-CSD-01-3 · Token bucket over a minute · © forcsguy.com

Leaky bucket. Requests wait in a bounded queue and leave at a fixed rate.

Figure SDA-CSD-01-4 · Leaky bucket · © forcsguy.com

Fixed window counter and its boundary problem. One counter per clock window is simple, but two bursts on either side of the boundary can pass double the limit.

Figure SDA-CSD-01-5 · Fixed window boundary burst · © forcsguy.com

Sliding window log. Keep a timestamp for every accepted request and count those inside the last window.

Figure SDA-CSD-01-6 · Sliding window log (2 per minute) · © forcsguy.com

Sliding window counter. Blend the previous window's count with the current one, weighted by how much of the previous window still overlaps the last minute.

Figure SDA-CSD-01-7 · Sliding window counter estimate · © forcsguy.com

Making it work across servers

Counters must be shared, otherwise each server enforces its own limit and a client gets N times the allowance. A fast in-memory store such as Redis works well.

Use an atomic operation (INCR with expiry, or a small Lua script) so the check and the update happen together. A separate read then write lets two servers both slip through.
Put the key in a predictable shape: rate:{user}:{rule}:{window}.
Partition keys across several Redis nodes for scale (consistent hashing, covered in lesson 2).
To save round trips, some systems keep local counters and sync periodically, accepting small overshoot.

Why counters must be shared when there are several limiter servers:

Figure SDA-CSD-01-8 · Why limiter servers need shared state · © forcsguy.com

The system around the algorithm

Figure SDA-CSD-01-9 · Detailed rate limiter design · © forcsguy.com

The race condition when two servers read the same counter at once, and the fix:

Figure SDA-CSD-01-10 · Read-modify-write race on a counter · © forcsguy.com

Responses and visibility

Return HTTP 429. Include headers so clients can behave: how many requests are allowed, how many remain, and when they reset, plus Retry-After. Log rejections and watch them, since a sudden rise can mean an attack, a bug in a client or a limit set too low.

Going deeper

Two races hide in "read, check, write". If two requests read the counter at 3 at the same moment, both write 4 and one request goes uncounted. A lock fixes it but slows every request; the usual answers are an atomic script that does the read, check and increment in one step inside Redis, or a sorted set that stores one timestamp per request so each request is a single atomic add.

Many limiter servers need shared state. If each server counted only the traffic it sees, a client could send half its requests to each and double its quota. Sticky routing (always the same limiter for a client) helps but breaks when servers change and uneven load builds up. A central store such as Redis, or periodic sync with eventual consistency, is the common fix. Across regions, accept a little over-admission in exchange for not paying a cross-ocean round trip on every request.

Where the rules live. Keep rules as data on disk or in config (for example "login: 5 per minute", "marketing messages: 5 per day"), have workers refresh them into a cache, and let the limiter read them from there, so tightening a rule never needs a deploy.

Measure it. Watch two things: rules that are too strict (many valid users rejected) and an algorithm that cannot absorb a flash-sale burst. In the second case a token bucket, which allows short bursts, is the usual swap.

Other layers and the client's side. The same idea works lower down, for example per IP address in the network layer rather than per user in HTTP. Well-behaved clients cache responses, respect the limit headers, handle the rejection gracefully, and back off before retrying.

An approximate sliding-window counter blends the previous window's count (weighted by how much of it still overlaps) with the current one. It assumes traffic was even in the previous window; published tests by one large CDN found only a tiny fraction of requests were misjudged, so for most uses the saving in memory is worth it.

Failure and edge cases

Limiter store down: usually fail open (let requests through, alert loudly) so you do not turn a limiter outage into an API outage. For security-sensitive endpoints (login attempts) you may prefer failing closed.
Clock differences between servers: base windows on the store's clock, not each server's.
Hard versus soft limits: some rules throttle (delay), others reject.
Many identities: also limit by IP for anonymous traffic, and watch for one client rotating keys.

A worked example: setting the limits

Say your public API has a free plan and a paid plan. You decide a free client may make 60 requests per minute with bursts up to 10, and a paid client 600 per minute.

Token bucket for the free plan: capacity 10, refill 1 token per second. A client idle for 10 seconds can fire 10 requests at once (the burst) and then settles to 1 per second. After a 429, it must wait about a second for the next token.
How much traffic is that? If 50,000 free clients all use their full allowance, that is 3,000,000 requests per minute, or 50,000 per second. You almost never see that, because most clients use a fraction. Sizing from the allowance gives the worst case; sizing from observed use gives the normal case. Plan the limiter and the servers behind it for the first, and alert on the second.
Counter memory: a token bucket needs two numbers per client (tokens, last refill time), about 16 bytes plus key overhead, say 100 bytes. For 10 million active clients that is about 1 GB, comfortably within one Redis node. A sliding window log would store a timestamp per request, up to 60 per client, which is 5 to 10 times more, one reason counters and buckets are the usual choice.

Figure SDA-CSD-01-11 · Choosing limits by plan · © forcsguy.com

Walking through a rejected request

A client sends its 61st request in a minute.
The edge gateway extracts the key (API key, falling back to IP address) and asks the limiter for that key.
The limiter reads the bucket from the shared store, sees no tokens, and answers "no" without touching the application servers.
The gateway returns HTTP 429 with a Retry-After header and, if you publish them, headers such as X-RateLimit-Limit and X-RateLimit-Remaining, so well-behaved clients can slow themselves down.
The rejection is counted in metrics. A rapid rise from one key suggests abuse; a rise from many keys suggests your limit is too tight or a new client release is misbehaving.

The cost of refusing is tiny compared with the cost of doing the work, which is the whole point: the limiter's decision must be much cheaper than the request it protects.

When the limiter itself fails

A limiter is in the path of every request, so decide in advance what happens when its shared store is slow or down:

Fail open (let requests through): users keep working, but you lose protection exactly when something odd is happening. Good for most public APIs, usually with a local fallback limit per server.
Fail closed (reject everything): safe for anything where overload is worse than refusal, such as an expensive or sensitive operation.
Keep a small local, in-memory limit on each server as a backstop, so even with the shared store down a single server cannot be flooded.

Figure SDA-CSD-01-12 · Fail open with a local backstop · © forcsguy.com

Mistakes people make

Limiting only by IP address. Many users share one address (offices, mobile carriers), and attackers rotate addresses. Prefer an API key or user id, with IP as a fallback.
Using the wrong clock. Limiter servers whose clocks drift apart count windows differently. Take time from the shared store, not each server.
Race conditions on counters. Reading a counter, adding one and writing it back lets two requests slip through together. Use an atomic increment or a small server-side script.
No visibility. Without rejection metrics you cannot tell abuse from a limit set too low.
Rejecting without guidance. Send Retry-After so clients can back off properly instead of retrying immediately and making things worse.

Try it yourself

Open the System Builder challenge A noisy client. One abusive client sends 97% of the traffic. Try to survive it by adding servers (you cannot, within 12), then switch on the rate limiter and watch the real users' errors disappear. Then build the sliding window rate limiter lab and see the boundary burst for yourself. You can also open the noisy-client design on the free canvas and place the rate limiter where you think it belongs.

More on this site

The same job, four ways

An API lets one program ask another to do something. The main styles differ in format, contract and how the client asks for data.

	SOAP	REST	GraphQL	gRPC
Format	XML envelopes	JSON (usually) over HTTP	JSON over HTTP, one endpoint	Binary Protocol Buffers over HTTP/2
Contract	WSDL, very formal	OpenAPI (optional)	A typed schema	A `.proto` schema, required
Client asks by	Calling named operations	Resource URLs and HTTP verbs	Sending a query describing the fields wanted	Calling typed methods
Caching	Hard	Natural (HTTP caching)	Harder (usually one POST endpoint)	Not HTTP-cache friendly
Streaming	No	Limited (SSE, WebSockets separately)	Subscriptions	Built in (four modes)
Browser use	Possible, heavy	Native	Native	Needs a proxy (gRPC-Web)
Typical home	Banks, enterprise, older systems	Public and general-purpose APIs	Client-driven apps, mobile	Internal service-to-service

SOAP

An older, XML-based protocol with a formal contract (WSDL) and a family of standards (WS-Security, transactions, reliable messaging). Verbose and tooling-heavy, but still common where strict contracts and built-in enterprise standards matter, such as banking, telecom and government. You will mostly meet it when integrating with existing systems.

REST

Design around resources identified by URLs (/orders/42), manipulated with standard HTTP verbs (GET, POST, PUT/PATCH, DELETE), and described with status codes. Strengths: simple, cacheable, works with every tool. Weaknesses: over-fetching (you get fields you do not need), under-fetching (several calls to assemble a screen), and no enforced schema unless you add one.

Figure SDA-CORE-20-1 · Three ways to call an API · © forcsguy.com

GraphQL

A single endpoint and a typed schema. The client sends a query naming exactly the fields it wants, even across related objects, and receives exactly that shape. It removes over- and under-fetching and suits varied clients (web, mobile). Costs: query cost control (a client can ask for something expensive), more complex caching, and server complexity (resolvers, the N+1 problem solved with batching).

gRPC (a form of RPC)

Remote procedure call: call a method on another service as if it were local. gRPC uses Protocol Buffers (compact binary, generated typed clients in many languages) over HTTP/2 with streaming. It is fast and has strong contracts, which is why it is popular between internal services. It is awkward to call straight from a browser and harder to debug by eye.

Choosing

Who are the clients? Public developers and the broad ecosystem: REST. A few first-party apps with varied screens: GraphQL. Your own services: gRPC. A partner or legacy system: whatever they provide, often SOAP.
How sensitive is performance and payload size? Internal high-volume calls favour gRPC.
Do you need HTTP caching? REST makes it easy.
Do you need streaming? gRPC, or WebSockets and server-sent events.
Team skills and tooling: the best style is one your team can run well.

Many systems mix styles: REST publicly, gRPC internally, and GraphQL as a gateway layer over both.

Good habits in any style

Version the API and avoid breaking changes.
Use consistent errors and clear status codes.
Paginate lists, and make unsafe operations idempotent with keys.
Document with a machine-readable schema (OpenAPI, GraphQL SDL, .proto).
Apply authentication, authorisation and rate limits at the edge (see the API security lesson).

Real-world reading

Attacker mindset

Most web attacks share one cause: the application trusts input, or trusts the browser, more than it should. The fixes are few and repeatable. This lesson covers five of the most important attacks; the full checklist is in the OWASP lesson. (Authentication and sessions are in the passwords and securing-an-API lessons.)

1. Cross-site scripting (XSS)

What: attacker-controlled text is put into a page and the browser runs it as script. The script runs as your site, so it can read the page, act as the user and steal tokens.

Types: stored (saved in your database, such as a comment), reflected (echoed from a URL parameter), DOM-based (client-side code writes untrusted data into the page unsafely).

// vulnerable: untrusted text inserted as HTML
el.innerHTML = comment.text;             // <img src=x onerror=stealCookies()> runs!

// safe: insert as text
el.textContent = comment.text;

Defences

Escape output for its context (HTML, attribute, JavaScript, URL). Modern frameworks (React, Vue and others) escape by default; avoid raw-HTML escape hatches such as dangerouslySetInnerHTML or v-html with untrusted data.
If you must allow rich text, sanitise with a well-maintained library and an allow-list.
A Content Security Policy header limits where scripts can come from, reducing damage if something slips through.
Mark session cookies HttpOnly so scripts cannot read them.

2. Cross-site request forgery (CSRF)

What: a malicious site makes the victim's browser send a request to your site, and the browser automatically attaches the victim's cookies. If the user is logged in, the action happens (change email, transfer money).

Defences

SameSite cookies (Lax or Strict) stop browsers sending cookies on most cross-site requests; now the browser default for many cases but set it explicitly.
Anti-CSRF tokens: a random value tied to the session that must accompany state-changing requests.
Never change state with GET; check the Origin header; require re-authentication for sensitive actions.
APIs that use an Authorization header (not cookies) are not vulnerable in the same way, because the browser does not attach it automatically.

3. Injection (SQL, command, and others)

What: input is concatenated into an interpreter's command, so the input changes the command's meaning.

// vulnerable
db.query(`SELECT * FROM users WHERE email = '${email}'`);   // email = ' OR '1'='1  returns everyone

// safe: a parameterised query keeps data and command separate
db.query("SELECT * FROM users WHERE email = $1", [email]);

Defences

Parameterised queries / prepared statements for SQL; ORMs do this for normal calls (beware raw-SQL escape hatches).
Avoid building shell commands from input; use library calls with argument arrays, not strings.
Validate input against an allow-list of expected formats, and apply least privilege to database accounts (the web app should not be able to drop tables).
The same pattern applies to NoSQL queries, LDAP, XML and template engines. Rule: never build code or queries by joining strings with untrusted data.

4. Server-side request forgery (SSRF)

What: the app fetches a URL supplied by the user (a preview, an image import, a webhook test). The attacker supplies an internal address; the server, which sits inside your network, fetches it and may return secrets, such as cloud instance credentials from the metadata endpoint, or probe internal services.

Defences

Prefer an allow-list of destinations; if not possible, block private, loopback and link-local ranges after resolving the name, and re-check on every redirect (and beware of DNS tricks that change the answer between check and use).
Allow only http and https; set short timeouts and size limits.
Run fetchers in an isolated network with no route to sensitive services; use cloud settings that require a session token for metadata access.
Do not return the raw response to the user.

5. Clickjacking

What: your page is loaded in a hidden or disguised frame on an attacker's site, and the user is tricked into clicking buttons they cannot see (like "delete account").

Defences

Send Content-Security-Policy: frame-ancestors 'none' (or 'self'), and the older X-Frame-Options: DENY.
Require confirmation for sensitive actions.

One table to remember

Attack	Root cause	Main defence
XSS	Untrusted data becomes script in a page	Output escaping, CSP, HttpOnly cookies
CSRF	Browser sends cookies on forged requests	SameSite cookies, anti-CSRF tokens
Injection	Data joined into a command	Parameterised queries, validation, least privilege
SSRF	Server fetches attacker-chosen URLs	Allow-lists, block internal ranges, isolation
Clickjacking	Page framed by another site	frame-ancestors / X-Frame-Options

Habits

Defence in depth: assume one layer will fail.
Validate on the server always; client checks are only for user experience.
Use framework defaults and keep dependencies updated.
Log and alert on suspicious input patterns and blocked requests.
Test: automated scanners, code review checklists and, for important systems, independent penetration tests.

Real-world reading

Go deeper on this

A path through videos, articles, other case studies and code on the same ideas as RFC 9114: HTTP/3.

1
Warm upGet the vocabulary first.
- Documentation
  RFC 9000: QUIC
  The standard for QUIC, the UDP-based transport under HTTP/3.
  IETFAdvanced
  Study this Original (opens in a new tab)
- Books · Free from the author
  High Performance Browser Networking
  How TCP, TLS, HTTP/2, WebSocket and mobile networks affect web performance; free to read.
  O'ReillyIntermediate
  Study this Original (opens in a new tab)
WatchHow others solve the same problem, on video.
Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)
3
ReadEngineers explain it in their own words.
- Blogs
  Cloudflare Blog
  Deep technical posts on networking, DNS, CDN, security and edge computing from a company that runs a huge global network.
  CloudflareIntermediate
  Study this Original (opens in a new tab)
- Blogs
  Android Developers Blog
  The latest updates from the Android team: new features and platform releases, looks at what’s launching and why it matters.
  GoogleIntermediate
  Study this Original (opens in a new tab)

Keep learning

Loading community…

Cookie preferences

RFC 9114: HTTP/3

Learn this doc

What you want from these docs

The problem

Where to put it

Algorithms

Token bucket in a few lines

The algorithms in pictures

Making it work across servers

The system around the algorithm

Responses and visibility

Going deeper

Failure and edge cases

A worked example: setting the limits

Walking through a rejected request

When the limiter itself fails

Mistakes people make

Try it yourself

More on this site

The same job, four ways

SOAP

REST

GraphQL

gRPC (a form of RPC)

Choosing

Good habits in any style

Real-world reading

Attacker mindset

1. Cross-site scripting (XSS)

2. Cross-site request forgery (CSRF)

3. Injection (SQL, command, and others)

4. Server-side request forgery (SSRF)

5. Clickjacking

One table to remember

Habits

Real-world reading

Go deeper on this

Warm upGet the vocabulary first.

RFC 9000: QUIC

High Performance Browser Networking

WatchHow others solve the same problem, on video.

ReadEngineers explain it in their own words.

Cloudflare Blog

Android Developers Blog

Keep learning