1. The problem QUIC solves
Most of the internet still runs on TCP. TCP has served the internet well for 40 years. But TCP has three problems that hurt real-time systems. Problem 1: head-of-line blocking. TCP delivers bytes in one strict order. If packet 5 is lost, TCP will not give the application packet 6, even if packet 6 already arrived. The application waits for packet 5 to be resent. One lost packet stalls everything behind it, even data that has nothing to do with the lost packet. Problem 2: connection setup adds delay. A fresh TCP connection followed by TLS 1.3 normally needs two round trips before the client sends an encrypted request. At a round-trip time of 150 ms, those exchanges take about 300 ms. This example excludes DNS, processing time, loss, resumption, and TCP Fast Open. Problem 3: the connection depends on network addresses. Ordinary TCP identifies a connection by the two IP addresses and two ports. If a network change alters those addresses, the application usually needs a new connection. TCP extensions and VPNs can change this behavior. QUIC is a transport protocol designed to fix these three problems. The IETF (the standards body that writes internet protocols) published the core QUIC specification as RFC 9000 in May 2021, alongside RFC 9001 (how QUIC uses TLS) and RFC 9002 (how QUIC controls its sending rate). These three documents, plus a handful of extensions, define everything a QUIC implementation has to do.2. What QUIC actually is
QUIC runs over UDP. It implements reliable streams, encryption, loss recovery, and congestion control above UDP. These QUIC mechanisms provide the benefits below. UDP alone does not provide them. Independent delivery order for each stream. A QUIC connection can carry many streams. Each stream delivers its bytes in order. Missing bytes on one stream do not impose a delivery gap on another stream. For example, a chat stream can deliver received data while a file stream waits for missing bytes. Packets can contain data from several streams, and all streams share congestion control. Application dependencies can also make one stream wait for another. QUIC detects packet loss across the connection; byte ordering belongs to each stream. TLS 1.3 integrated into connection setup. QUIC combines transport setup with the TLS handshake, as RFC 9001 specifies. Under the assumptions above, the client can send its request after one round trip. An eligible returning client can send early data with 0-RTT resumption. The server can reject early data, and applications must account for replay risks. 0-RTT does not apply to a fresh connection. Connection identity can survive an address change. Connection IDs help endpoints associate packets with an existing connection when network addresses change. Supported migration lets a client move from Wi-Fi to mobile data while preserving that connection. The endpoints validate the new path. Connection IDs can rotate during the connection. Migration depends on endpoint support and policy; it does not guarantee uninterrupted delivery. See RFC 9000, sections 8–9 for validation and migration rules. Congestion control that adapts. Every sender, on any network, has to decide how fast it is safe to send before it starts overwhelming the network and losing packets. QUIC uses acknowledgment, loss, and timing information to guide this decision. TCP congestion controllers also use network feedback. Section 4 is dedicated to this — it is a bigger topic than one bullet point can cover, and it directly affects how smooth a video call or a robot control loop feels under bad network conditions.A quick comparison
The visual tour lets you change these conditions.
These comparisons explain protocol behavior. They do not predict a benchmark result.
3. Packet structure and the rules of engagement
A QUIC packet carries protocol frames, such as stream data and acknowledgments. Its handshake establishes keys and transport parameters before normal application traffic proceeds. Address validation and amplification limits constrain what a server sends to an unvalidated address. For field diagrams and a header-size calculation, read the optional packet and handshake lesson.4. How QUIC decides how fast to send
Congestion control limits sending to avoid overwhelming the network. Flow control separately limits data according to the receiver’s advertised allowance. The application can also send less than either allowance because it has no more data ready. RFC 9002 describes a NewReno-style congestion controller, while allowing other suitable algorithms. The choice matters for media because queue growth adds delay. Read the optional congestion-control lesson for slow start, loss response, and media tradeoffs.5. Media over QUIC (MoQ)
QUIC is a general-purpose transport. It moves bytes. It does not know anything about video, audio, or “who wants this stream.” Media over QUIC, usually written MoQ or MoQT (MoQ Transport), is a protocol built on top of QUIC that adds exactly that: a publish-and-subscribe model for live media.Why publish-and-subscribe
Picture a live video stream with 10,000 viewers. If the publisher opened a direct connection to every viewer, the publisher’s own upload bandwidth would need to carry the video 10,000 times over. That does not scale. MoQ solves this with a relay. The publisher sends the video to the relay once. The relay forwards a copy to every subscriber. The publisher’s bandwidth cost stays constant, no matter how many people are watching. This is the same fan-out idea that made IRC and Pub/Sub systems and CDNs successful, applied to live, low-latency media over QUIC.
The MoQ vocabulary
MoQ organizes media into a small hierarchy: a track contains groups, and a group contains objects, optionally organized into subgroups. Learn these words; you will see them again in level 102.- Track. A single named stream of media — one camera’s video, one microphone’s audio, one robot joint’s telemetry. A track has a name and a namespace.
- Group. A track is broken into groups. A group is a self-contained unit a subscriber can join at, without needing anything from before it — for video, typically one group per key frame, so a new viewer never has to wait for the next key frame to start watching.
- Subgroup. Within a group, objects that depend on each other and should be delivered together ride the same subgroup — and, in practice, the same underlying QUIC stream. A codec with multiple quality layers can put each layer in its own subgroup, so a relay under pressure can drop one layer’s stream without touching the others.
- Object. The smallest addressable unit — one frame, one audio packet, one sensor reading. Every object is identified by its track, group ID, and object ID, the same way a postal address identifies one letter.
- Publisher. The endpoint that owns a track and sends objects into it.
- Subscriber. The endpoint that asks the relay for a track and receives its objects.
- Relay. The middle party. It accepts tracks from publishers and forwards their objects to every subscriber of that track. A subscriber never has to connect to the publisher directly.
Why QUIC, specifically, makes a good relay protocol
A relay forwards many independent tracks to many independent subscribers. QUIC’s independent streams (from section 2) map naturally onto MoQ’s subgroups: losing one packet of one subgroup’s video does not stall a different subgroup, a different track, or a different subscriber’s copy of the same track. A protocol built on single-stream TCP would not have this property.6. WebTransport
Everything in sections 2 through 5 works for a program that can open its own QUIC connections: a native app, a robot’s onboard computer, a server. A browser tab cannot do this — browsers only expose specific, safe networking APIs to JavaScript, for security reasons. WebTransport is the browser API that exposes QUIC to JavaScript. It lets a web page open a QUIC connection to a server and use two kinds of channels:- Streams — reliable, ordered, and independent of each other, exactly as described in section 2.
- Datagrams — covered next, in section 7.
7. Web datagrams
A QUIC stream provides reliable, ordered bytes while the stream and connection remain active. WebTransport exposes streams with those properties. A MoQ track can use different delivery mechanisms; a track is not itself a promise of reliable delivery. Reliability is not always what you want. Picture a live audio call. If one 20-millisecond audio packet is lost, the best fix is NOT to resend it. By the time the resend arrives, the conversation has already moved past that instant. A resent, late audio packet is worse than a dropped one — playing it back now would make the audio sound choppy and delayed. The right behavior is to drop it and move on. A datagram is an unreliable, unordered unit of data. QUIC defines datagrams as a first-class feature, separate from streams. QUIC does not retransmit a lost DATAGRAM frame. Its enclosing packet still participates in acknowledgment and congestion control. The application must handle missing or out-of-order messages. WebTransport exposes this same feature to the browser: a web page can send and receive QUIC datagrams in JavaScript, alongside its reliable streams, on the same connection.When to use a stream, and when to use a datagram
This single choice — stream or datagram — is one of the first real design
decisions you will make on top of TeleQuick. Level 102 shows you where
each of our products makes that choice, and why.
8. Putting it together
Here is the full picture, in order:- QUIC is the transport. It runs on UDP, encrypts everything, opens fast, carries independent streams and datagrams, and negotiates its own sending rate through congestion control.
- Its handshake follows a small set of deliberate rules — padding, amplification limits, stateless reset, idle timeout — that exist to keep the protocol safe to run on the open internet.
- MoQ is a publish-and-subscribe protocol built on QUIC. It organizes media into tracks, groups, subgroups, and objects, and it fans out one publisher’s track to many subscribers through a relay.
- WebTransport is the browser’s door into QUIC. It gives JavaScript the same streams and datagrams a native program gets.
- Datagrams are the unreliable option inside QUIC (and, through WebTransport, inside the browser) — the right tool whenever a late delivery is worse than a lost one.
Glossary
Exercise (30 minutes)
Answer these questions in your own words. Do not copy sentences from this page.- A customer says: “Our video call freezes for a second every time someone’s Wi-Fi has one bad packet.” Using the ideas from section 1, explain what is likely happening if their app uses plain TCP, and why QUIC’s streams would help.
- Redo the worked example from the packet and handshake lesson, but assume both connection IDs are the QUIC-v1 maximum, 20 bytes each, and the packet number needs the full 4 bytes. What is the new Initial-packet header overhead? Which fields account for most of the difference from the 28-byte example? Keep the empty token and two-byte Length field assumptions.
- A robot sends its arm position 100 times a second over a MoQ track. Should that track carry its data as streams or as datagrams? Give one reason.
- A teammate asks why their brand-new QUIC connection sends noticeably more data in its first few round trips than it did a second later, right after one lost packet. Explain both halves using the congestion-control lesson. Assume the example RFC 9002 controller and enough application data to send.
- Explain, in your own words, why MoQ’s caveat about “application-limited sending” is a real problem specifically for live media, and not for, say, a large file download.
- Open TeleQuick’s docs and find the page on real-time tracks. Name one track kind it describes, and say whether you would expect it to use streams or datagrams, based on what you learned in section 7.
Further reading
This course teaches the parts of these documents that matter for building on TeleQuick. They go much further:- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
- RFC 9001 — Using TLS to Secure QUIC
- RFC 9002 — QUIC Loss Detection and Congestion Control
- draft-ietf-moq-transport — Media over QUIC Transport (still evolving — check the datatracker for the current draft number)