HTTP/2, HTTP/3 and QUIC Kristian A. Hiorth University of Oslo, - - PowerPoint PPT Presentation

http 2 http 3 and quic
SMART_READER_LITE
LIVE PREVIEW

HTTP/2, HTTP/3 and QUIC Kristian A. Hiorth University of Oslo, - - PowerPoint PPT Presentation

HTTP/2, HTTP/3 and QUIC Kristian A. Hiorth University of Oslo, Norway September 7, 2020 IN5150: HTTP/2, HTTP/3 and QUIC Kristian A. Hiorth Dept. of Informatics University of Oslo [Photo: Jason Coates] Overview: first, a look back at legacy


slide-1
SLIDE 1

HTTP/2, HTTP/3 and QUIC

Kristian A. Hiorth

University of Oslo, Norway

September 7, 2020

slide-2
SLIDE 2

IN5150: HTTP/2, HTTP/3 and QUIC

Kristian A. Hiorth

  • Dept. of Informatics

University of Oslo

[Photo: Jason Coates]

slide-3
SLIDE 3

Overview: first, a look back at legacy HTTP, followed by what HTTP/2 does differently, and finally the future of HTTP with QUIC

Legacy HTTP HTTP/2 QUIC and HTTP/3

1

slide-4
SLIDE 4

Legacy HTTP HTTP/2 QUIC and HTTP/3

slide-5
SLIDE 5

The Web, and HTTP with it, is pretty old

1989/1990 World wide web invented at CERN

[Photo: Geni @ Wikimedia Commons]

2

slide-6
SLIDE 6

The Web, and HTTP with it, is pretty old

1989/1990 World wide web invented at CERN May 1996 HTTP/1.0 formalised in RFC 1945

  • ne request ⇔ one (TCP) connection

[Photo: Geni @ Wikimedia Commons]

2

slide-7
SLIDE 7

The Web, and HTTP with it, is pretty old

1989/1990 World wide web invented at CERN May 1996 HTTP/1.0 formalised in RFC 1945

  • ne request ⇔ one (TCP) connection

January 1997 HTTP/1.1 in RFC 2068 persistent connections by default request pipelining

  • max. 2 connections per server

[Photo: Geni @ Wikimedia Commons]

2

slide-8
SLIDE 8

Then came two decades of HTTP/1.1 patches

June 1999 HTTP/1.1 updated, given proposed standard status in RFC 2616

3

slide-9
SLIDE 9

Then came two decades of HTTP/1.1 patches

June 1999 HTTP/1.1 updated, given proposed standard status in RFC 2616 ... Countless RFCs (or not) specifying extensions

3

slide-10
SLIDE 10

Then came two decades of HTTP/1.1 patches

June 1999 HTTP/1.1 updated, given proposed standard status in RFC 2616 ... Countless RFCs (or not) specifying extensions June 2014 HTTP/1.1 reformalised as RFCs 7230 – 7235 concurrent connection limit relaxed

3

slide-11
SLIDE 11

HTTP/1.1 pipelined requests remain serial

4

slide-12
SLIDE 12

Web developers came up with creative workarounds to decrease page load times

Spriting with CSS:

#home a:hover { background: url('img_navsprites_hover.gif') 0 -45px; } #prev a:hover { background: url('img_navsprites_hover.gif')

  • 47px -45px; }

#next a:hover { background: url('img_navsprites_hover.gif')

  • 91px -45px; }

[Photo: W3schools]

5

slide-13
SLIDE 13

Web developers came up with creative workarounds to decrease page load times

Inlining Place content directly in HTML; data: URLs.

{background-image:url("data:image/png;base64,iVBOAA...")}

6

slide-14
SLIDE 14

Web developers came up with creative workarounds to decrease page load times

Inlining Place content directly in HTML; data: URLs.

{background-image:url("data:image/png;base64,iVBOAA...")}

Sharding Spread contents among many domain names to circumvent connection limits.

6

slide-15
SLIDE 15

Legacy HTTP HTTP/2 QUIC and HTTP/3

slide-16
SLIDE 16

HTTP/2 was the first major revision to HTTP since 1999

◮ Originated as Google’s SPDY experimental protocol

7

slide-17
SLIDE 17

HTTP/2 was the first major revision to HTTP since 1999

◮ Originated as Google’s SPDY experimental protocol ◮ RFCs 7540 and 7541 published in May 2015

7

slide-18
SLIDE 18

HTTP/2 was the first major revision to HTTP since 1999

◮ Originated as Google’s SPDY experimental protocol ◮ RFCs 7540 and 7541 published in May 2015 ◮ HTTP semantics stay the same

7

slide-19
SLIDE 19

HTTP/2 was the first major revision to HTTP since 1999

◮ Originated as Google’s SPDY experimental protocol ◮ RFCs 7540 and 7541 published in May 2015 ◮ HTTP semantics stay the same ◮ Framing and on-the-wire behaviour see major changes

7

slide-20
SLIDE 20

To understand the impetus for HTTP/2, we need to look at Head of Line blocking

8

slide-21
SLIDE 21

To understand the impetus for HTTP/2, we need to look at Head of Line blocking

[Photos: Vibeke Friis, A. Wee]

8

slide-22
SLIDE 22

The main innovation in HTTP/2 is a better defined and more flexible framing concept

HTTP/1.1 No proper framing concept. Response runs on and on until it is done.

9

slide-23
SLIDE 23

The main innovation in HTTP/2 is a better defined and more flexible framing concept

HTTP/1.1 No proper framing concept. Response runs on and on until it is done. HTTP/2 Clearly defined frames, of several distinct types. Binary format.

9

slide-24
SLIDE 24

Framing enables multiplexing several logical streams onto a single HTTP/2 connection

+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+

10

slide-25
SLIDE 25

HTTP/2 also contains other features intended to improve performance

◮ Stream priorities and dependencies

11

slide-26
SLIDE 26

HTTP/2 also contains other features intended to improve performance

◮ Stream priorities and dependencies ◮ Header compression using HPACK

11

slide-27
SLIDE 27

HTTP/2 also contains other features intended to improve performance

◮ Stream priorities and dependencies ◮ Header compression using HPACK ◮ Streams are resettable

11

slide-28
SLIDE 28

HTTP/2 also contains other features intended to improve performance

◮ Stream priorities and dependencies ◮ Header compression using HPACK ◮ Streams are resettable ◮ Server push

11

slide-29
SLIDE 29

The HTTP/2 spec does not mandate TLS encryption, but in practice it is mandatory

Discovery of HTTP/2 capability at the server side during TLS handshake using Application Layer Protocol Negotiation (ALPN).

12

slide-30
SLIDE 30

Legacy HTTP HTTP/2 QUIC and HTTP/3

slide-31
SLIDE 31

HTTP/3 is simply the mapping of HTTP/2 onto a QUIC transport

QUIC has transport-level features that obviate the need for some of HTTP/2’s application layer features.

13

slide-32
SLIDE 32

To properly eliminate HOL blocking, HTTP/2 is not enough, because TCP itself suffers from HOL blocking

No “clean” way of eliminating TCP-level HOL blocking.

14

slide-33
SLIDE 33

To properly eliminate HOL blocking, HTTP/2 is not enough, because TCP itself suffers from HOL blocking

No “clean” way of eliminating TCP-level HOL blocking.

14

slide-34
SLIDE 34

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking.

15

slide-35
SLIDE 35

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking. ◮ In-order, reliable delivery per stream.

15

slide-36
SLIDE 36

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking. ◮ In-order, reliable delivery per stream. ◮ Shorter handshakes, immediate data (“0-RTT”) without hacks.

15

slide-37
SLIDE 37

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking. ◮ In-order, reliable delivery per stream. ◮ Shorter handshakes, immediate data (“0-RTT”) without hacks. ◮ TLS encryption always mandatory.

15

slide-38
SLIDE 38

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking. ◮ In-order, reliable delivery per stream. ◮ Shorter handshakes, immediate data (“0-RTT”) without hacks. ◮ TLS encryption always mandatory. ◮ In-band connection identifier, separate from IP pseudoheader → connection migration

15

slide-39
SLIDE 39

QUIC brings in the features everyone in the Web space wanted for improving latency, just done better

◮ Multistreaming without HOL blocking. ◮ In-order, reliable delivery per stream. ◮ Shorter handshakes, immediate data (“0-RTT”) without hacks. ◮ TLS encryption always mandatory. ◮ In-band connection identifier, separate from IP pseudoheader → connection migration ◮ Userspace implementation atop UDP, easier to develop, iterate.

15

slide-40
SLIDE 40

QUIC encrypts everything to make interference harder

Interference from middleboxes can cause headaches with TCP, HTTP/1.1.

16

slide-41
SLIDE 41

QUIC encrypts everything to make interference harder

Interference from middleboxes can cause headaches with TCP, HTTP/1.1. QUIC solution: hide (almost) everything!

16

slide-42
SLIDE 42

QUIC encrypts everything to make interference harder

Interference from middleboxes can cause headaches with TCP, HTTP/1.1. QUIC solution: hide (almost) everything! Exception: 1 single “spin bit” to allow RTT derivation.

16

slide-43
SLIDE 43

QUIC streams do not suffer from HOL blocking and can be prioritized

UDP datagrams carrying QUIC frames are delivered immediately, even out of order → No HOL blocking at transport layer.

17

slide-44
SLIDE 44

QUIC streams do not suffer from HOL blocking and can be prioritized

UDP datagrams carrying QUIC frames are delivered immediately, even out of order → No HOL blocking at transport layer. Stream prioritization as part of QUIC (still a bit fuzzy in the specs).

17

slide-45
SLIDE 45

QUIC connections are congestion controlled

Still based on TCP congestion control.

18

slide-46
SLIDE 46

QUIC tries to be future-proof and easier to change

Version negotiation when setting up connection.

19

slide-47
SLIDE 47

HTTP/3 adapts the HTTP/2 framing and protocol to take advantage of QUIC

Multistreaming drop HTTP-level multistreaming, use QUIC streams instead.

20

slide-48
SLIDE 48

HTTP/3 adapts the HTTP/2 framing and protocol to take advantage of QUIC

Multistreaming drop HTTP-level multistreaming, use QUIC streams instead. Special control streams Separate request/response streams from header streams

20

slide-49
SLIDE 49

HTTP/3 adapts the HTTP/2 framing and protocol to take advantage of QUIC

Multistreaming drop HTTP-level multistreaming, use QUIC streams instead. Special control streams Separate request/response streams from header streams Different header compression HPACK relies on TCP bytestream concept, replaced by QPACK

20

slide-50
SLIDE 50

HTTP/3 adapts the HTTP/2 framing and protocol to take advantage of QUIC

Multistreaming drop HTTP-level multistreaming, use QUIC streams instead. Special control streams Separate request/response streams from header streams Different header compression HPACK relies on TCP bytestream concept, replaced by QPACK Prioritization HTTP/2 priority concept remains, but maps onto QUIC stream priorities

20

slide-51
SLIDE 51

HTTP/3 adapts the HTTP/2 framing and protocol to take advantage of QUIC

Multistreaming drop HTTP-level multistreaming, use QUIC streams instead. Special control streams Separate request/response streams from header streams Different header compression HPACK relies on TCP bytestream concept, replaced by QPACK Prioritization HTTP/2 priority concept remains, but maps onto QUIC stream priorities Server push Client explicitly limits number of allowable push streams

20

slide-52
SLIDE 52

HTTP/3 support announced using Alt-Svc header

Tell HTTP/1.1 and HTTP/2 clients that HTTP/3 is available using the Alt-Svc (Alternative Services) header in responses.

21

slide-53
SLIDE 53

The QUIC working group is currently primarily focused on HTTP-over-QUIC, more general QUIC coming later

Extend QUIC to be a more general message-oriented transport.

22

slide-54
SLIDE 54

The QUIC working group is currently primarily focused on HTTP-over-QUIC, more general QUIC coming later

Extend QUIC to be a more general message-oriented transport. ◮ Unreliable delivery streams: active Internet-Draft

22

slide-55
SLIDE 55

The QUIC working group is currently primarily focused on HTTP-over-QUIC, more general QUIC coming later

Extend QUIC to be a more general message-oriented transport. ◮ Unreliable delivery streams: active Internet-Draft ◮ Multipath support: active Internet-Draft (MP-QUIC)

22

slide-56
SLIDE 56

The QUIC working group is currently primarily focused on HTTP-over-QUIC, more general QUIC coming later

Extend QUIC to be a more general message-oriented transport. ◮ Unreliable delivery streams: active Internet-Draft ◮ Multipath support: active Internet-Draft (MP-QUIC) ◮ Features catering to protocols other than HTTP (active I-Ds

  • n SSH, NETCONF, tunnels...)

22

slide-57
SLIDE 57

QUIC and HTTP/3 are nearing RFC submission

Primary QUIC WG documents went to WG Last Call this summer. ◮ QUIC transport ◮ QUIC invariants ◮ Security (TLS) ◮ Congestion control ◮ HTTP/3 and QPACK header compression

23