Abstract
- Stands for Quick UDP Internet Connections
- Think of QUIC as being similar to TCP+TLS+HTTP 2.0 implemented on UDP (Like TCP 2.0)
- Built on top of UDP but the mechanism is based on TCP
- Comes with 0-RTT (Zero Round Trip Time Resumption) which sends an encrypted request using a key from a previous connection. The server cannot tell if the data is a replay, so use it only for idempotent requests
Why not build it on top of TCP?
We can’t change TCP in the same way we change HTTP to solve the TCP Head-of-Line Blocking issue, because modifying TCP requires changes to the kernel codes, which is much harder than changing a browser codes.
Tool
QUIC Handshake
- TCP lives in the kernel and TLS runs above it, so TLS cannot start until the TCP connection is established. HTTPS combines the two into one layer, letting the TCP and TLS handshakes happen at the same time
QUIC Stream
- Introduce HTTP Stream in the transport layer
- Abstracting HTTP Request/HTTP Response into QUIC Frame
Important
Solves TCP Head-of-Line Blocking issue.
QUIC Frame
- Similar to the HTTP Frame, there isn’t HTTP frame in QUIC
QUIC vs TCP
- TCP has one ordered byte stream per connection, so a single lost packet blocks the whole connection. QUIC has multiple streams per connection, a single lost packet only blocks one stream, assets on other streams can still be transmitted
- QUIC has packet number which is similar to sequence number but only used for loss detection and RTT measurement. This avoid TCP head of line blocking as stream id is in charge of ordering and reassembly
Is stream expensive?
No, all streams share the same connection, so no connection or handshake needed