Jalex Chang



Jalex Chang

- Backend Engineer @ Umbo Computer Vision

- Taiwan Data Engineering Association Member

- Golang Taiwan Member


- jalex.cpc @ Gmail

- jalex.chang @ Facebook

- JalexChang @ GitHub


  • Introduction
  • HTTP/3
  • QUIC
  • Discussion
  • Summary


[1] HTTP/3 explained, https://http3-explained.haxx.se/en/

[2] QUIC-GO, https://github.com/lucas-clemente/quic-go

[3] Draft-ietf-quic-http-22 (HTTP/3 draft-22), https://tools.ietf.org/html/draft-ietf-quic-http-22

[4] Draft-ietf-quic-transport-22 (QUIC draft-22), https://tools.ietf.org/html/draft-ietf-quic-transport-22

[5] 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.

OSI Model

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)
Connections ✔️  ✔️
Connection Migration ✔️
Streams Application layer Transport layer
Stream Multiplexing ✔️ ✔️
Stream Prioritization ✔️ ✔️
Flow Control ✔️ ✔️
Secure Optional ✔️ (TLS 1.3)
Transport Handshake 2/3-RTT 1-RTT
Fast Handshake ✔️ (TCP fast open) ✔️ (TLS 1.3)
Server Push ✔️ ✔️
Header Compression ✔️ (HPACK) ✔️ (QPACK)

HTTP/3 Promotion

HTTP/3 Fallback


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 ).

Protocol Features

  • 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.

Connection ID​

  • 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.

Stream ID

  • An unsigned 62-bit integer.
  • Is increasing and unique numeric within a connection.

Stream prioritization

  • 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.​

TLS 1.3

  • 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


In this tech sharing, we have introduced HTTP/3 and QUIC.

  • Goals of HTTP/3 are reducing latency and solving HOL blocking in the transport layer.

  • ​QUIC  provides data transfers with reliable, secure, but lower-latency.
  • Even though QUIC looks powerful, it still has rooms to improve in the aspect of security and resource consumption.


​HTTP/3 and QUIC are more likely designed for the next decade.

  • What we can do are learning, thinking, and contributing!​ 

Thanks for listening.

We are hiring now!

Our booth is at 109 1F,

come to chat with us!

HTTP/3 Leaks

By Jalex Chang

HTTP/3 Leaks

Introduce http/3 and QUIC.

  • 1,208