- Backend Engineer @ Umbo Computer Vision
- Taiwan Data Engineering Association Member
- Golang Taiwan Member
- jalex.cpc @ Gmail
- jalex.chang @ Facebook
- JalexChang @ GitHub
 HTTP/3 explained, https://http3-explained.haxx.se/en/
 QUIC-GO, https://github.com/lucas-clemente/quic-go
 Draft-ietf-quic-http-22 (HTTP/3 draft-22), https://tools.ietf.org/html/draft-ietf-quic-http-22
 Draft-ietf-quic-transport-22 (QUIC draft-22), https://tools.ietf.org/html/draft-ietf-quic-transport-22
 RFC-8446 (TLS 1.3) , https://tools.ietf.org/html/rfc8446
- In this tech talk, we are going to introduce HTTP/3 and its underlying transport protocol - QUIC.
- The topics we would cover in the talk:
- Why do we need a new HTTP protocol?
- Why do we need a new transport protocol?
- What is QUIC?
- How does QUIC work?
- What is HTTP/3?
- HTTP/2 vs HTTP/3
- Common concern/criticism of HTTP/3.
What is HTTP?
- There are several HTTP versions have been published:
- HTTP/1.1 (Jun. 1999)
- HTTP/2 (May 2015)
- HTTP/3 (Nov. 2018 -> Jul. 2019 -> TBD)
The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. - Wikipedia
What is the problem?
It is all about head-of-line blocking (HOL blocking).
HOL Blocking in HTTP/1.1
Application layer's HOL blocking.
HOL Blocking in HTTP/2
Transport layer's HOL blocking
With HTTP/2, browsers do parallel transfers over a single TCP connection.
Through stream multiplexing
HTTP/2 eliminates HOL blocking at the application layer
But HOL blocking still exists in the transport layer.
If a single packet is dropped
The entire TCP connection is brought to a halt while the lost packet is re-transmitted.
How can we solve the problem?
- It is caused by TCP => we need a new transport protocol.
- Without HOL blocking in the transport layer.
- But also provide reliable and secure data transfer.
- Can we build a new transport protocol?
- Do you remember the SCTP?
Protocol ossification is always a problem!
- Firewalls, NATs, routers and other middle-devices are old and only allow deploying TCP or UDP.
HTTP-over-QUIC (HTTP/3) Is Born
What is HTTP/3?
A new-generation HTTP protocol
Born to solve the transport HOL blocking issue.
It remains the same paradigms and concepts like HTTP/2.
- Still have headers and bodies, requests and responses, verbs, cookies, and caching.
The most difference between HTTP/2 and HTTP/3
How to send bits during peer communication (TCP -> UDP).
The specification of HTTP/3 is still in progress.
The latest version is draft-22 (Jul. 2019 ).
|Data Transfers||TCP||QUIC (UDP)|
|Streams||Application layer||Transport layer|
|Secure||Optional||✔️ (TLS 1.3)|
|Fast Handshake||✔️ (TCP fast open)||✔️ (TLS 1.3)|
|Header Compression||✔️ (HPACK)||✔️ (QPACK)|
What is QUIC?
- QUIC is a name, not an acronym. It means "quick".
- A new reliable and secure transport protocol implemented on top of UDP.
- Designed to serve general application protocols.
- HTTP is its initial target.
- The initial QUIC protocol "Quick UDP Internet Connections" was designed by Google in 2012.
- Google sent the first draft of QUIC to IETF for standardization in Jun 2015.
- A QUIC working group got approved and started in late 2016.
- in 2017, Google has mentioned that around 7% of Internet traffic in Google was already using Google-QUIC.
- The specification of QUIC is still in progress. The latest version is draft-22 (Jul. 2019 ).
Transfer protocol over UDP
- Avoid protocol ossification.
- Middle-devices can only see encrypted UDP packets.
Reliable data transfers
- Re-transmissions of packets, congestion controls, pacing and other features presented in TCP.
Streams and connections
- It is similar to HTTP/2 but implemented in the transport layer.
- In-order delivery
- It guarantees in-order delivery within a stream, but not between streams.
Secure and transport handshakes
- It is powered by TLS 1.3 and provides two handshakes (0-RTT and 1-RTT).
- A QUIC connection is a single conversation between two endpoints.
To reduce connection establishment latency
- Combine version negotiation, cryptographic and transport handshakes together.
- A connection ID can be used to identify a connection.
- Each connection has multiple connection IDs.
- There are two types of Connection ID: source and destination.
Connection IDs are independent of IP and ports.
- Connections can be migrated between IP and network interfaces.
Connection ID Negotiation
- An ordered byte-stream abstraction.
- A stream can carry multiple messages (request/response).
- There are unidirectional and bidirectional streams.
- Streams are parallel and out-of-order delivery.
- An unsigned 62-bit integer.
- Is increasing and unique numeric within a connection.
- QUIC cannot do prioritization by itself.
- Rely on receiving priority info from the application layer.
Cryptographic and Transport Handshake
- There is no clear-text version in QUIC.
- Only allows TLS 1.3 or greater versions.
- Combine all stuff together in one round trip time.
- Support full TLS handshake and fast TLS handshake.
- The fast TLS handshake (0-RTT handshake)
- Allows clients to include early data during handshake under constraints.
0-RTT Handshake in TLS 1.3
The client has a previous connection to the server.
The secret of the connection has been cached in both of them.
The server has enabled the 0-RTT handshake (accept early data).
Unfortunately, there is no standard API for QUIC.
QUIC is typically implemented in user-space.
No OS kernels support QUIC right now.
- QUIC cannot easily extend the socket API to how existing TCP and UDP functionality do.
Concern and Criticism
- UDP will never work.
- UDP is slow in kernels.
- QUIC takes too much CPU.
- We are not Google.
- Look HTTP/2, will HTTP/3 be popular?
- Too small of an improvement.
We will see, time will prove it.
- Partially support IETF version in draft-22.
- Features are working in progress - contributors are needed!
Discussion Issues in net/http
A list of implementations
Implementations and Issues in Golang
HTTP Servers Based on QUIC-GO
Thanks for listening.
We are hiring now!
Our booth is at 109 1F,
come to chat with us!
By Jalex Chang