Jalex Chang

- Backend Engineer @ Umbo Computer Vision

- Taiwan Data Engineering Association Member

- Golang Taiwan Member

Contact:

- jalex.cpc @ Gmail

- jalex.chang @ Facebook

- JalexChang @ GitHub

Introduction

• 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

HTTP/3

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

Comparison

HTTP/3 Promotion

HTTP/3 Fallback

QUIC

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.

History

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

Connections

• 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

Streams

• 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

Requirements

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

API

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

QUIC-GO

• Partially support IETF version in draft-22.
• Features are working in progress - contributors are needed!

Discussion Issues in net/http

• support HTTP/3 

A list of implementations

• quicwg-base-drafts-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!